Level / Map structure

I actually committed this to the TODO file, but it should be referred to from here on future occasions:

Create a level file, using XML. The file should have the following specifications:
 * Size (width, height)
 * Theme (grass, dessert, ice, etc...)
 * Player start positions (for enemy players)
 * Wall positions
 * Destructable wall positions
 * Special effect positions (e.g. torches, smoke)
All of these objects should follow the architecture below:

Oops I didn't finish writing it. Anyway, I was going to say that all objects should specify a position (in tile coordinates) and a *type of sprite* (wall, destructible, etc) rather than a sprite path to be able to switch between themes easily.
Needless to say, player start positions should be only over floor.
Special effects are not collidable, but may block sight anyway, so be careful where you place them (I think this comment is a little beyond in time hehe)

I was busy thinking about the map file when you submitted this ticket. Reading it made me wonder something. Do you imagine that the floor tiles are all the same for one map ? I mean if you choose the "grass" environment, does it mean that all the tiles will me from one image ? Or do you intend to "build" the floor tiles from a set of different tiles ?

The structure will depend on this feature.

Concerning the non-floor-tile elements, I guess the best is to just have every game entities holding a list of tile coordinates. In good XML (but rather long to type), it could look like :
<Wall>
<Coordinate>
<X>2</X>
<Y>4</Y>
</Coordinate>
<Coordinate>
<X>3</X>
<Y>4</Y>
</Coordinate>
</Wall>

Etc.... This means that with so much typing, we will definitely need a map editor !

Otherwise we could go for another route. We make our own Map parser. We could have .map files with a defined structure. For instance the first line contains a tuple with the map size. Then would come the type of environment (if we go for that feature), and finally a list of game entities, with a list of tile coordinates. Example :
--- level1.map ---
(20,30)
Environment : ice
Wall : (0,0) (0,1) (0,2) (0,3) (0,4) (1,2) (2,2)
Destructible wall : (3,3) (3,4)
Player : (5,5)
Power-up : (1,1)
Etc...

Python has a module called ConfigParser ( http://docs.python.org/library/configparser.html ) which doesn't exactly do what we need. But I mention it because it could be useful for our Settings.

Then the GameMap class would have an abstract factory. The factory consists of method for instantiating the different game entites at the place read from the map file. Different factory can be implemented to instantiate different type of entities. So one factory would be the IceFactory, and another the CastleFactory. Each would have methods like add_entity, add_tile and add_layer, but each would change its implementation to instantiate once an icy wall or a castle wall, etc.

I would go for XML right away. It is a very dynamic file format and as far as I know, widely used in non-commercial games.

It is a possibility we should consider having a base floor tile for each map and *optional* additional tiles to substract monotony from the floor itself.
I had not thought about having these tiles recorded in the map file, I was thinking we could rather place them randomly, but now that you say so, it occurs to me that we could very easily specify their positions in the map. Randomization could be made instead in the map creation process, with a floor randomizer method.

Grouping the object types is a very good idea, but I propose the following changes to the XML structure:
<Object>
  <Instance>(x1,y1)</Instance>
  (...)
  <Instance>(xn,yn)</Instance>
</Object>

Maybe we could even obviate the parentheses.

At loading time, every floor tile will use the base tile image, unless differently specified by the map file. For example:

<floorTile>
  <image></image>
  <instance>(x,y)</instance>
</floorTile>

What the map loader will asume is a floorTile object using the base tile image (specified in the map file somewhere else) in every square where no other object is designated.

Sorry, I forgot to comment on the abstract factory...
Because we want to be able to add new themes, we shouldn't hard-code the map styles. Rather than that, we should have a base map sprite directory, were depending on the theme, different images are loaded. If the specified theme is not found, then the game_map will fall back to the basic theme.

Yes Wolter, you are absolutely right. :) This gave me an excellent idea to integrate that with my new ResourceManager. In the resource.cfg config file, we could have entries like :
[image]
floor : %(sprite_dir)s/map/%(environment)s/floor.jpg

The first part %(sprite_dir)s is just a "default variable" set to the path of our sprite resources. But the interesting part is in the middle : %(environment)s. Because we could make the ResourceManager replace that "variable" with something defined at run-time... and for instance something read from a level map !

So for the folder structure, we would have under /res/sprites/map some folder with the name of the environment. So maybe /res/sprites/map/ice and /res/sprites/map/castle, and /res/sprites/map/grass. They would contain the same image filename, like floor.jpg, wall.jpg, etc... But in each folder, it would be of course a different image.

The GameMap would read from the level xml file the type of environment to use, and would tell the ResourceManager to look for those resources.

In order to fully understand what I'm talking about, you will need first to have a look at my ResourceManager commit notes. :)

Well indeed I am interested in checking out the source code you have so far, but I fully understand what you are talking about, thats how I wanted to manage maps :) Keep us posted!

So should I assign myself to work on this task or will you rather work on it?

Hi,

No problem, there are enough goals to work on, so you can go ahead and pick
up that one. :)

Dan.

No problem, there are enough goals to work on, so you can go ahead and pick up that one. :)