Maps with s-tile

The tool guy is back with some a lot more dirty inside secrets on the improvement. This post was meant to speak a bit about the Level Editor, but 1st I want to tell you about one thing you may not know... and it is known as tilemapping.

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

• Size in pixels (width x height): these values inform how massive our image is - 64x64, 320x200, 1280x800...
• Color depth/bits per pixel(bpp): precision employed to retailer an individual pixel in the image - eight bpp, 16 bpp, 24 bpp, 32 bpp. This parameter fairly a lot depends on the format we are using to show our image.
  

To recognize the want for such a method, we have to consider in terms of the hardware accessible back in the day. We are talking about machines with veeery limited resources, i.e. actual slow CPU's and really low on memory (far from a single megabyte), so 1 had to be actually cautious and always hold an eye on these limits when establishing... and even a lot more if establishing a game.
Numerous older 2D games out there show a very large and detailed globe where the game action requires location, and with big right here I mean several occasions the screen (Turrican's huge maps getting a genuine excellent example of this). So, let's do a easy 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 3 times the screen width). The very first answer that comes to thoughts is generating a 960x200 drawing that represents the map. Undertaking the math, that is 960*200*8 bits = 960x200 bytes = 187.5 KB in memory at runtime. Not that a lot, I agree, but back in the day we could have limits like 256 KB in our primary memory, so in this case we would have small room left for the rest of the game information (not to mention the worst and most common case would actually be possessing even reduced limits and a lot higher requirements)

So here's where the tilemapping method comes in. The strategy itself is rather basic: we have an array of small (e.g. 16x16, 24x24,...) pictures named tiles, containing all the graphic specifics 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 instance, making use of a moderate set of 20 diverse 24x24 tiles and a 20x9 sized int array, we manage to develop a large sufficient map to fit our needs, with a cost of 20*24*24 + 20*9*two = 11880 bytes = 11.6 KB. Now that's saving memory, do not you feel? ).

Even though nowadays we have tech advanced adequate to kiss tilemapping goodbye, it's nonetheless utilised, specially in games for tiny and restricted devices such as cellphones and hand-held consoles. Actually,Fiend and Energetic use tilemapping for levels :)

Tiny 2D horror gem

The Energetic map editor, in all its glory

Following having bored you all with all this seemingly pointless babble, I will inform you how most 3D games do for levels. There are numerous ways of obtaining a 3D world. Most common is producing a huge 3D model in the modeling plan of option, that is all the geometry and texture mapping accomplished there. Even though this is cool, any 3D artist out there would say it is a fairly time-consuming task, and does not enable a lot reuse of stuff.

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

What we are undertaking in Unknown is to generate a number of sets of 3D pieces and make maps making use of them as creating blocks. 1 can have a production-quality map in less than 4 days with this approach, and thanks to the outstanding job from our artists, the results are truly nice to the eye as effectively.

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

As you may possibly have noticed, there is very a similarity in each instances. We can make a close analogy among the large 2D drawing and the huge 3D model map, and our current mapping method to the ancient tilemapping technique, even though our point is not associated to saving memory truly, but to save time and sanity. Nonetheless, our method makes it possible for for much more flexibility, such as going back to the "huge 3D model" entirely (by producing a piece containing the entire map geometry), or partially (just a space). Also, we have a grid, but only to ease the process of aligning pieces, so we are not constrained by it.

There is little left to add really. I hope this served at the extremely least to give you guys a little overview on a single of the most popular game improvement tactics that has been around for very a lot of time, and how its standard principle can nevertheless apply to today's methods.

Just couldn't aid myself