Maps with s-tile

The tool guy is back with some more dirty inside secrets on the development. This post was meant to talk a bit about the Level Editor, but first I need to tell you about something you might not know... and it's called tilemapping.

The term tilemapping refers to a technique born in the mid 80's or so, back when videogames were pretty much down to 2D. These games used 2D images to represent the game world and entities in it. A 2D image is, in a nutshell, a grid of color values or pixels, with the following parameters:

• Size in pixels (width x height): these values tell how big our image is - 64x64, 320x200, 1280x800...
• Color depth/bits per pixel(bpp): precision used to store an individual pixel in the image - 8 bpp, 16 bpp, 24 bpp, 32 bpp. This parameter pretty much depends on the format we are using to display our image.
  

To understand the need for such a technique, we have to think in terms of the hardware available back in the day. We are talking about machines with veeery limited resources, i.e. real slow CPU's and quite low on memory (far from a single megabyte), so one had to be really careful and always keep an eye on those limits when developing... and even more if developing a game.
Many older 2D games out there display a quite big and detailed world where the game action takes place, and with big here I mean many times the screen (Turrican's huge maps being a real good example of this). So, let's do a simple example:

1. Figure our system has a graphic mode with a screen size of 320x200 pixels and 8 bpp for color depth (and we are talking high tech here).
2. Now, we want our game to have maps with a moderate size of 960x200 (that's only three times the screen width). The first solution that comes to mind is making a 960x200 drawing that represents the map. Doing the math, that is 960*200*8 bits = 960x200 bytes = 187.5 KB in memory at runtime. Not that much, I agree, but back in the day we could have limits like 256 KB in our main memory, so in this case we would have little room left for the rest of the game data (not to mention the worst and most common case would actually be having even lower limits and much higher needs)

So here's where the tilemapping technique comes in. The technique itself is rather simple: we have an array of small (e.g. 16x16, 24x24,...) images called tiles, containing all the graphic details we need in our level, plus a 2D collection of integer values (almost like an image), which would act as the actual map, indicating which tile goes where. In our example, using a moderate set of 20 different 24x24 tiles and a 20x9 sized int array, we manage to build a big enough map to fit our needs, with a cost of 20*24*24 + 20*9*2 = 11880 bytes = 11.6 KB. Now that's saving memory, don't you think? ;).

Although nowadays we have tech advanced enough to kiss tilemapping goodbye, it's still used, specially in games for small and limited devices such as cellphones and hand-held consoles. Actually,Fiend and Energetic use tilemapping for levels :)

Little 2D horror gem

The Energetic map editor, in all its glory

After having bored you all with all this seemingly pointless babble, I'll tell you how most 3D games do for levels. There are many ways of having a 3D world. Most common is creating a huge 3D model in the modeling program of choice, that is all the geometry and texture mapping done there. While this is cool, any 3D artist out there would say it is a pretty time-consuming task, and doesn't allow much reuse of stuff.

I know it looks untextured and that... but does this ring a bell?

What we are doing in Unknown is to create several sets of 3D pieces and make maps using them as building blocks. One can have a production-quality map in less than four days with this method, and thanks to the excellent job from our artists, the results are really nice to the eye as well.

Quite impressive what you can do with such simple pieces I must say... kudos to Jens

As you might have noticed, there's quite a similarity in both cases. We can make a close analogy between the big 2D drawing and the huge 3D model map, and our current mapping method to the ancient tilemapping technique, although our point is not related to saving memory really, but to save time and sanity. Still, our technique allows for more flexibility, such as going back to the "huge 3D model" totally (by creating a piece containing the whole map geometry), or partially (just a room). Also, we have a grid, but only to ease the task of aligning pieces, so we are not constrained by it.

There's little left to add really. I hope this served at the very least to give you guys a little overview on one of the most famous game development techniques that has been around for quite a lot of time, and how its basic principle can still apply to today's methods.

Just couldn't help myself