Jump to content

  • Log In with Google      Sign In   
  • Create Account

2) Getting rid of the tile map

Posted by AFS, 28 May 2013 · 300 views

Even in college, I still managed to dedicate some time on the editor.

There was one thing that bothered me, and it was its tedious usage. If you watched the video, the map and the collision are independent from each other; if I modified the terrain, I had to manually modify the collision as well. It consumed a lot of time to create a small map.

There was also another problem: when I started with the editor, I wanted it to create huge maps, and I mean huge. However, the editor saved all the tiles in memory, so creating a big map would consume a lot of it. While I had some idea of how to fix that and make it load only some tiles, it was very hard to implement it without rewriting the whole thing.

Oh, and there was another problem as well: using tiles is a pain. they have no flexibility, unless the tiles are really small. I really wanted more precision while still using big images.

So, how to fix all three problems? Getting rid of the tile map, of course!

Well, maybe that was not the only solution, but I really hated the map.

While using tiles, I had one big text file with numbers indicating the texture of each tile. Something like this...
0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 2 0 0 0 0 0 0
0 0 0 2 2 2 2 0 0 0 0
1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1
0 0 0 0 0 0 0 0 0 0 0
... but HUGE. Every single tile had a number, even the "empty" ones (the zeroes, which are not actually empty, but are a tile that is simply light blue, corresponding to the sky). That's just a waste of space.

I decided to split the map in sections of 2000x2000 pixels each, and have the content of each section stored in a separated text file, so that way I could only read one section at a time. For instance, the file named "0x0" has all the objects placed between 0 and 1999 pixels both horizontally and vertically; the file "1x0" has all the objects placed between 2000-3999 px. horizontally and 0-1999 vertically, and so on.

Of course, this leads to a folder with a huge amount of text files, but that doesn't bother me for now. Besides, that doesn't mean that all possible files must be in the folder: if a file doesn't exist, then the editor will simply get that there's nothing in that section.

The actual content of each file is something like this:
5 (number of objects in that section)
posX/posY/ID (Position and ID of each object in the section).
Now I can save the position of the objects with pixel-precision instead of being forced to a grid, and the objects now can be of any size instead of whatever size the tile was. This already made the editor much more friendly, with better looking maps.

This solves two of the mentioned problems: the editor is now more flexible instead of being forced to a grid, and considering that now it only loads the current section instead of the whole thing [1], it also solves the memory problem with big maps: memory usage will be as high as the amount of objects on the screen at a time (the objects are stored in a linked list, by the way).

To solve the third problem -the tedious placement of collision nodes- I simply made the collision dependent of each object. If a put an object to the map, it automatically creates the collision, because they are part of the object. To archieve this I made a "pattern editor". I'm way too lazy to explain it, but it's nothing fancy.

Anyway, here's a video of it in action. Keep in mind that the graphics are not mine, they are from the game "Braid", and I used them just for the video (Still, I felt bad about using the assets from another game, so I will create my own graphics from now on, even if they are ugly)

In the video, the camera starts at section 1,000 x 1,000, not 0 x 0. The reason behind this was to have enough space both on the left and up, as the editor can't handle sections with negative indexes: 0 x 0 is actually the most to the left and up you can go.

Considering that each section is 2,000 x 2,000 pixels each, starting at section 1,000 x 1,000 means that, at least in the video, I had 2 million pixels of space both to the left and up, or in other words, a zone of 2 million px2, and that's not counting the space to the right and down, which I don't know exactly the limit. With that in consideration, plus counting that it only loads a small section at a time, the editor can officialy handle huge maps without trouble.

While this may not be a huge archievement in gaming per sé, is a huge personal archievement to me, because I really was struggling with a solution to make big maps efficiently for quite a good amount of time.

Anyway, getting rid of the tile map was a huge step forward for the maturity of my little monster: Now it's not as tedious to use and I can make big maps with no problems: I'm happy with that. Posted Image

[1] .- Well, I don't actually load ONE section at a time, I load nine: the central section plus all eight surrounding ones. I made this to avoid on-screen "pop-ups" when I approach a border and load a different section. With nine sections, the pop-ups happen off-screen, if that makes sense.

July 2014 »

6789 10 1112