Minimap:
The minimap is a simple but effective — it is actually a scaled down version of the map picture from the previous post, with a little box that shows the current location. It really helps show the scale of the world while you are flying around in it.

Stars:
The stars were taken almost straight from MUA Space, a demo game for the framework. They are randomly placed in the sky tiles, with more stars per tile the higher it goes, until the top (black) tiles are quite ‘starry’. The stars vary slightly in size and twinkle. Simple, but nice.

Sky at Level 167

Sky at Level 188

Sky at Level 216

Sky at Level 249

Ground Texture:
Next, I replaced the old placeholder ground code that made that boring brown texture. Now, the generated terrain becomes an alpha image used as a mask with the underground image to texture the tile. It works really well and the entire operation only takes about .01 seconds. I botched the ground texture itself — it doesn’t exactly wrap right, but otherwise you can see it working nicely here.

Ground Texture

Optimization:
This was a big one. After adding the new things, particularly the texturing, the on-the-fly generation of tiles I was doing was causing tiny little blips in the FPS. It wasn’t much, but it WAS noticeable. I have a pretty good machine, so I knew I needed to iron this out. I cut out ugly parts of code where I could, but the operations themselves are pretty heavy (terrain generation, texturing, converting from PIL images to Pyglet textures), so I needed to take it a step further. Two steps actually – I approached the optimization in 2 ways.

First, and by far the most important, was splitting up the loading tasks into distinct phases and spreading them out across frames. Before I was loading the entire tile (for a ground tile this means generating the terrain heightmap, applying the ground texture via a mask, generating the sky color and applying it, then converting it to a Pyglet sprite) when it was initialized, which was way too slow. Each of the surface tiles were taking about .03 seconds, and I am loading 3 tiles at a time (I briefly had some code to only load 2 at a time, but I took that out because it was poorly written. If I need to, I’ll go back and do that again).

So, I wrote a new tile class that handles all its own loading. The idea is simple enough – each tile has a stack of ‘steps’ it needs to do to be fully loaded. Some require just one step like underground tiles (copy the cached underground texture), and some require a long series of them like surface tiles (generate terrain array, create terrain mask, apply background sky texture, use mask to apply ground texture over terrain, convert image to texture for rendering). On the very first step, the tile gets its tile type from the main map and sets the necessary steps accordingly. Now, each frame, if there are still steps left in the todo stack, it pops one off and processes it. The tile comes a little closer to being fully loaded, and it only takes as much time as one step, instead of all of them together. When the to-do stack is empty, the tile is finished, and it just renders itself like normal.

While that took care of my frame lag problem, my design made me worried about wasting some loading. Here is my MS Paint explanation of the how the map loads tiles as the player moves.

How the 9 rendered tiles change as the player moves

In the situation above, the player is now on the far left of the new center tile (f). If it moves just one pixel back to the left, the process happens again in reverse – dropping the JKL column and reloading the tiles for ADG. So wasteful!

Solution: Caching. Now the map keeps around the last handful of tiles it drops. When the user crosses to the right and ADG gets dropped, they get saved. If the user then comes back to the left (without going too much further away), those tiles are still available and the map can just use the saved copies (fast) instead of generating new ones (very slow).

Map tasks still ahead:

• clouds
• platforms
• regions & their specific terrain
• foilage
• wrapping the world

Currently I have the world set at 1000 tiles wide and 250 tiles tall. Each tile is 800×600 at the moment (subject to change!), which makes the world map 800,000 pixels wide and 150,000 pixels tall. That is a huge amount of real estate, so I expect it will be more than enough for our needs, even if we get a few hundred players (crossing fingers).

Naturally, the player is only going to see a tiny slice of this massive world at a time, so we don’t want to waste any time or memory loading and storing any more than we have to. I’ve been pretty frugal and decided to load only the tile the player is on and the 8 tiles surrounding it. As the player moves, the game automatically throws away the tiles in the other direction and loads new ones where the player is headed. I was worried this much processing would introduce some lag (remember the client’s computer has to generate and render the terrain on the fly), but as you can see in the video below, it runs very smoothly.

This is how the game renders the world to the player. These nine tiles are loaded and displayed, with the screen starting centered around the middle tile (Middle Center). If, for example, the player moved to the left, the nine tiles would move to the right as a group. When the player crossed from Middle Center into Middle Left, the game would throw away the three tiles in the Right column, move the other two columns over, and load three new tiles for the new left. The player never notices and the game never has more than the nine tiles loaded at once.

9 Tiles of Rendering

Here is a simple video of the system in action (if you follow the link and watch it at the youtube site, you can see my annotations explaining things a bit more). You can see how the tiles work together to make it appear that the entire world has already been loaded. The line on the screen is from the center to the mouse position, which is how I control the scroll direction and scroll speed (further from center = go faster). The video simply flies around a bit following the procedural terrain, then takes off at top speed vertically, climbing all the way to the top of the map (250 tiles high) to show off the gradient of the sky. Unfortunately, clouds, stars, and platforms are not yet implemented, so the sky is pretty lonely. Still, you can get a glimpse of just how big this world is.

Click here to view the embedded video.

After I got this working, I created a tool to generate a small ‘world map’ image so I could get (and show) an overview of the world as a whole. It is scaled down from the actual game world by a factor of 1/100, but that still makes it a giant image at 8000×1500 pixels. My first attempt at the code had the world map rendering the 250,000 tiles (!) in just under 3 DAYS. That wouldn’t do at all, so I jumped in and optimized everything I could and wrote some code to cache the sky gradient and the underground texture. After that and lots of fiddling, I now have it down to about 100 seconds (a respectable 2500 tiles/second).

Here is scaled down version of the world map – this one is ‘only’ 1600×300. Click to open it, or follow this link to check out the full map.

Scaled down world map

One of the key features of the game is the large world it takes place in. We (the design team) want a really big world, but I (the one who has to actually do it) certainly don’t want to hand edit/model the terrain and platforms that would go into creating it. So, in comes step 1/1000 – procedural terrain generation. Basically, the goal is to create an algorithm that can be used to automatically create each piece of the world, as broken down into ’tiles’. To manage memory, we want to only load the tiles surrounding the player’s current position, so the algorithm needs to be able to get just the tiles we need and render them in real time.

The first thing I did was create a terrain generation algorithm to make simple, smooth ground for a single tile. For this I used a technique called ‘midpoint displacement’. It sounds fancy, but it is actually a very simple algorithm where you simply bisect a line and adjust its middle by a random number over and over until you get terrain. I set it up to seed the random number generator first so I could create exactly the same tile by just passing in the same seed. This also means that it generates different tiles for each new seed. Each tile has a unique location in the world, so by passing that in as the seed, I effectively have a function that will create every tile in the game! Simple, but cool!

I also added in a region dynamic so I can break the world into regions and the tiles within those regions will get created with different parameters. For example, mountain tiles will be generated with more steep cliffs, while plains tiles will be mostly flat.

Behold, some random heightmaps for tiles! The first three were created with exactly the same parameters, but different seed values. Note, these are NOT rendered ground tiles – this is just a silhouette of the 2D landscape for each tile. The last three are more random tiles, but this time I have tweaked the generation parameters to give much smoother terrain.

This is great so far, but it is still missing something. At the moment, all the tiles start and end at the same height, which is totally boring and unpractical for the game itself. What we need instead is a way to add variety to all their end points while making sure each tile lines up with the ones on either side of it. I still didn’t want to do this by hand though, so I decided to just make another algorithm. This one does exactly the same thing, except instead of telling the program where to render land, it tells each tile how high to go when generating terrain.

This controls the shape of the entire world, and since there is only one of them, it is important to pick a good one. To make it easier on myself, I created a little ‘world viewer’ program that generates these world maps and displays them along with all the parameters used to create it. It also allows me to zoom in and out to inspect certain areas, change parameters on the fly, and drag the map itself around for better viewing. You can see it in action below:

Click here to view the embedded video.

Next time: putting the tiles together to create one huge map, then picking regions and texturing the tiles so they look like ground instead of weird lines.