We're getting into programming of what we discussed lately but where should we start? We know that we'll need tiles, a tile set and a level map. We also know that the map holds indices and those refer to the tiles in the tile set. What we'll do now is to create the corresponding data structures (in C/C++ called: struct, in VB: Type, in Java: not available) and functions.
The first Type is quite simple to understand, it only contains the tile data. We're getting into graphics later, therefore we'll include the DC property but I won't explain it yet. You can think of the DC being the picture itself. In fact it's just another reference used for internal resource mapping. We'll get back to this later when working with the Win32 API. So here's the definition:
Public Type tTile
DC as Long 'Picture
Walkable as Boolean
End Type
But where to put this code? Since it's a public declaration it needs to be in a Module, let's name it mTiles.
For the moment we don't care too much about tile sets so we'll just make one big array of tiles:
Public TileCount as Long Public Tile() as tTile
Why did I choose the name Tile() instead of Tiles()? That's because arrays are a list of items rather than single objects. I'd chose plural names for Collections since these are truly single objects that hold multiple items.
Not familiar with all the programming techniques above? Read through the following articles to learn more:
(You can find those and some more techniques in the Common section of this website)
(note: Links fixed)
So what do we have now? We have a list of tiles and each tile can hold a DC and a value for Walkable. So why did I put that Walkable in here? Well imagine a game with a map that has only 2 different tiles, water and grass. We could just check where the player wants to walk and if it's water (which is non-walkable) we'll reject the movement.
This is a great example for properties that are stored directly into the tiles, because all tiles will react the same. For example all water-tiles are non-walkable. If you prefer lava we could add a value LavaDamage or something that'll hit the player if he walks on any lava tile in the game. Other examples for tile-based properties are:
Note that not all properties can be stored that generally! If we want to make a door tile that teleports the player into another level we can't just save the target position in the door tile directly. Simply because not all doors will bring you to the same direction. Actually there should be no more than 1 door bringing you there, so this problem has to be solved somewhere else. In a script for example.
Of course there are also properties that apply to many, but not all tiles (eg. scripts to run, if a player walks over the tile). In this case you have to decide by yourself if it's worth to give all tiles the capability to run scripts.