The map

To make life easy, I've opted to use a paint package (Gimp) to design maps, where pixel colour is used to determine what a particular area of the map contains, using the following rules.

• dark green = forest
• brown = scrub
• black = road
• light green = residential
• blue = commercial
• yellow = industrial
• red = infrastructure
• light gray = parking
• light blue = water

This is the sort of thing I'll be using to create the city.

It looks a lot like a Sim-City mini-map, doesn't it?

The terrain

Initially, I'll be keeping the terrain as a large flat plane, with the city streets and buildings all on the same vertical level which is actually pretty normal for real world cities. As the testing map is 128 pixels on each side, and I've decided to have 1 map pixel equal 256 in game units, the terrain will be a single large polygon (well, two triangles arranged to form a square actually) that's 32,768 units on a side. Eventually, I'll revisit the terrain and break the brown and dark green areas down into smaller arrays of triangles which can be used to form low hills to give the map some character, but the terrain under the city itself will remain flat.

Roads

The easy way out for making roads would be to simply create a map texture that included roads drawn on it, but that would look awful on such a large map as the road edges would be blurry and indistinct. Additionally, it's supposed to be a living city, so cars and trucks would require some fancy coding or elaborate rules to ensure that they stayed on the black stuff.

Instead, I'm going to scan the map looking for where there are black pixels and build an array of textured polygons that can be position slightly above the terrain surface. By constructing the roads this way, the program will know the exact locations and dimensions of all road pieces, so it should make it a lot easier to get traffic moving around.

The scanning process is very simple. Simply examine each pixel on the map, one row at a time looking for black pixels. When one is found, check the 8 pixels around it. If there is a black pixel above and below, or a black pixel to the left and the right, then the road is a straight, otherwise it's a corner or intersection. Because each pixel equals 256 game units, it's now easy to calculate the position and size of a road piece. Additionally, I went one step further and had the program reprocess the lists containing the straight pieces and merge any run of straights into one long piece to reduce the polygon count.

Texturing these road pieces became quite a challenge. It turns out that there are 13 different join types (four corners, four three way intersections, four dead ends and one four way intersection piece), one horizontal straight and one vertical straight piece. As I'm always looking for the easy way out, I simply created one tile-able 256 pixel bitumen image, one transparent white stripe and a transparent curb image and wrote a python script to overlay them in various arrangements to produce the necessary textures for every piece.

Ideally, the number of textures used should be kept to a minimum, since switching textures while rendering is a pretty expensive process. The closest I could come to using one texture for all the roads was to merge all the join images into one texture, and keep the two straight pieces separate. The reason for this is that the join pieces are all 256 units square, so it's possible to use UV coordinates to clip part of the larger texture. The road pieces are however long thin polygons, so they need to have their textures repeated, which meant that using UV coordinates for clipping simply wasn't possible.

And this is the end result, both close up and zoomed out.

According to the stats, the road layout has 297 pieces, comprised of 42 corners, 89 intersections, 162 straights and and 4 dead ends, totaling 594 triangles.  The 12 extra triangles being drawn are part of the clipping cube which you can see as the diagonal white line running through the picture. I'll be removing is shortly.