Flash Scroll Engine: Super Tiles (Part 1)
This is based on Strille's tile based tutorial.
I was quite impressed when I saw his Sonic Demo in action, essentially for 2 points:
- Speed.
- Map size.
These characteristics were severely limited on my previous games Fire Man Incoming Storm and Fall of 21XX whose maps were art based instead of tile based. In order to keep up speed, I had to slice the map in multiple sections, showing only one part at once, and usually with no way to return to a previous section. That trick worked well inspired on the NES Mega Man games (probably they also had to do that for performance reasons), but I wanted to have huge maps like in Mega Man X. So, with the given documentation, I adapted Strille's engine and extended it for my games.
Here's the map of Fall of 21XX implemented to draw and remove the tiles dynamically. For comparison, the original Fall of 21XX can be played here.
The difference? Well, the whole map is available. You can reach the boss room and return to the beginning of the map with no performance impact. This is the normal way I do maps now but back then it was a huge milestone.
The fewer tiles visible at a given time, the faster the engine moves. On slow system, the game will slow down on places where there are many tiles on the scene. I've placed many tiles in purpose here and there in order to test. Definitely this engine (or more specific, Flash) can't handle screens filled with tiles, let alone, a screen filled with 16x16 tiles. Luckily, with every passing year, computers get faster and this is less of an issue. The key in this engine is that it uses Super Tiles, this is, 16x16 tiles grouped on larger sections. These can be repeated to create the map. For more information check Strille's tutorial.
Actually I have found another advantage on the Super Tiles model and it was on the level editor.
The engine can actually be used to create more traditional maps with only 16x16 tiles (in this case the Super Tiles contain only a single 16x16 tile). Though it works, some performance penalty is experimented hen the map is rendered at runtime. But the real problem comes when editing the map. As a level editor, I use the Flash IDE. In another FLA file, I create the Super Tiles, and start to lay out the map. Then when publishing, a script writes on the output window an array with the information about the map layout. Then this text is pasted on the actual FLA file of the game, where the map data is parsed and the scene is created. XML or any format of your preference can be used for this, but for testing purposes I just used simple arrays.
The Flash IDE performs rather well with huge maps consisting of big super tiles, and writes the array fast. However on very large maps, with tiny 16x16 super tiles, the Flash IDE performs very bad, and may even crash on slow systems. So save your work often just in case.
Now the question is, how big can these maps be?