2D map storage structures

I am going to make a 2D top-down racing game, but I'm not sure how I want to deal with levels.

I want to be able to have fairly large levels (you won't be able to see it all at once, they are pretty long) with roads that curve smoothly around corners. I'd like to be able to make the actual level content varied as well, so that you don't see the exact same buildings flashing past every second but rather see a little variation in there. And I'd like to be able to keep the number of textures as low as possible.

Now, I know that adding variation will increase the number of textures required but that is not something I'm too concerned about. The thing I'm worried about is how to efficiently store the levels and still keep it easy for someone to create them.

If I construct the level out of a series of equally-sized squares then it becomes very difficult to have each corner different, as I will have to use the same (or one of a few) textures for each corner and therefore each corner will have the same shape and size. The level designer will have to make lots and lots and lots of different tiles if they want lots of different corners, which is time consuming for them and memory consuming for the computer.

Alternatively, I could have a set of tiles (i.e. a tile for the edge of the road) which can be placed anywhere on the map with any transformation. This would make it easy to keep the number of tiles required low, although the level would turn into a birds-nest of polygons. Unfortunately, curves would no longer be smooth if I did that, and tiles would overlap which would make them look very weird (imagine two rectangles with lines running across them joining each other at different angles).

Another approach is to have a series of tiles for things like trees and buildings which don't occur too often and are fairly similar. Roads would be specified using a series of tiles, one for the road edge, one for the road surface, one for the center etc. The person making the level could then draw a curve defining the road's shape, and the level editor would automatically work out a series of quads to draw the road smoothly with. That is getting pretty complicated though, especially when I start adding things like control points to change the width of the road at a specific point.

I think that the curve idea is the best for ease of use and achieving the overall goal, but it's the worst to program into the game. So - if anyone has any useful advice, I'd love to hear it. I've never done anything like this before, and I have to say I'm a little lost :-p

Personally, I'd not use tiles. I'd use a road description as a bezier curve, which I'd subdivide into short segments, and then draw as quads ( provided the segments are short enough, it'd look like a smooth curve ). The buildings and whatnot would be random -- e.g., a box with random height/width/depth and random texture ( of a set of building textures ) and so on.

Your whole level could exist entirely of a random seed value and a bezier path.

I don't intend to randomly generate levels, although that could be an option. It does seem like the best option (for usability, not programming) is to use some sort of spline to define the road, but like I said that's gonna be pretty hard to program.

Bezier itself is so easy you could implement it while falling down a flight of steps ( at least, recursive bezier subdivision is, quadratic is actually simpler but requires some math ). The issue is how you join the segments.

First, here's some bezier code I wrote -- YEARS ago -- which I posted on CocoaDev when somebody asked me for an implementation. It's primitive ( dating to my programming on BeOS in the late 90's and I didn't trust their implementation of the STL, so I made my own list types... because I was young and brash )

If you don't have *any* sharp turns, it will be straightforward. Say your road is of W width, then, for each point ( junciton between two line segments ) in your subdivided bezier path, you want to project a point W/2 units along the angle bisecting the junction, outwards and inwards. DO this for each junction, and then you have a set of points which you can use to draw quads.

For a higher quality approach, or for situations where you know you'll have sharp turns, you'll treat each segment as a quad ( projecting points perpendicularly from the segment ) and you'll make joining segments in between, perhaps as circles, or as triangles. If you do this, you'll have to handle the situation where the inn projected points of the segments overlap.

TomorrowPlusX Wrote:First, here's some bezier code I wrote -- YEARS ago -- which I posted on CocoaDev when somebody asked me for an implementation. It's primitive ( dating to my programming on BeOS in the late 90's and I didn't trust their implementation of the STL, so I made my own list types... because I was young and brash )