Map

I have noticed a serious lack of tutorials on how to go about making a level editor. I think the reason behind this is that it tends to be more time consuming than writing the engine. I have started over writing my own editor 4 or 5 times because I keep running into different problems that force me to rethink my aproach towards it. The biggest setback in doing this is the fact that (in my case anyway) a tile is not just an image on a surface. It has values like what type of tile it is, different flag values like walkable/animated/portal/switch/etc, animation data etc, all besides just a source rect and a source surface. Then comes deciding how you want to load/save this information into the engine. This of course will be pretty individual per game/engine. This information happens to be a pretty important part of the game and it has to come from somewhere but I haven''t seen anywhere that gives a good tutorial on how to go about doing it with decent applicable source code. So if anyone knows of a good tutorial, I and lots of others would be most greatful...

Thanks

while the idea of an article dedicated to the creation of level editors may seem like a good idea, you simply have to think about this: each game has its own map structure, and you design that map structure based on the needs of the game. in the past i have designed very simple map editors that i then used to make several different games, but of course by necessity the editor did not have many features that a more complicated game would require. so the format of the maps that the editor generated limited what i could do with them.

also, you may wish to reconsider the manner in which you think about the concept of a "tile". i do not equate a graphical image with a tile, as i assume many other people do. a graphical image serves only to communicate with the player(you see a tree, you see a rock, your character faces northwest, a monster approaches your character, etc), and in reality has almost nothing to do with what happens inside of the game. games still take place in a 2 or 3 dimensional cartesian grids(because cartesian grids easily abstract positional information and make work easier), and the graphical representation of the game information matters not as long as it communicates the game state to the player.

so, if the graphical information means nothing to the game itself, it behooves us to find a meaningful way to represent game state data that has a relationship to the graphical data (the game state data must relate to the graphical data, as the graphics represent and communicate the internal game state), but does not equal the game state.

consider for a moment a diamond shaped, flat isometric map, which has no discernable difference from a square map. take any square map, rotate it by 45 degrees, and squash the y aspect by 50%, and you shall see that you have the same exact thing. i find it much easier to work with a square map than an isometric map, and so i will choose to represent the game state internally with a square map. formulae exist that will translate from the internal coordinate system into the coordinate system of graphics, and so i shall make use of them when it comes time to render.

since the internal representation is non-visible, you can use non-visible objects to represent game objects, such as unwalkable areas, or rocks, trees, characters, monsters, or whatever you need to represent.

you must remember--graphics infer meaning based on the game state, but you can represent the game state internally with something other than your graphical representation, and often this will ease your job.

I''m currently doing 3D Isometric game in OpenGL (Tile based map, 3D characters, objects etc), so if you need any help on editor''s general implementation, just mail me at acolyte@ozforces.com.au, and we will figure out how to help you, ok?

Good luck.

" Do we need us? "

Ionware Productions - Games and Game Tools Development