Developing Map Editor

1) Yes, the simplistic approach would be to store your tile-map as a 2D array. There are all kinds of exotic options available though to suit any needs or wants.
2) Most map editors usually employ some sort of export format that is in the developer's favorite markup-like language. Common export formats are XML, INI, JSON, or even a binary file format. Which one you use is up to you.
3) That is your decision. You could embed the files in your map format, or you could hold paths to external files as you said. One thing you will want to consider is the referential integrity of your file format. Basically, if the original file changes, is deleted, or moved, then how does your file format cope with that?
4) You could. You don't have to, but you could.
5) A layers system is useful whenever you find it useful.

The map data is the foundation of the editor. Figure out what kind of data you need in your game, and build the editor to create that data in as user-friendly of a way as possible :)

Yes, tilemaps are just 2D arrays. Well, conceptually anyway. It's easier to use a 1D array and access tiles by map.tile[y*map.width+x]

Collision can be manually edited, or set up in the tileset so you only have do it once and then make as many levels as you want with the tileset. Most of the time a ground tile will be solid, slope tile a slope, etc. so it's kind of a waste of time to plot matching collision tiles every time.

In my side scroller game, I use the separate collision layer style. In the map editor for it, I use a combination of the two styles. You set up collision in the tileset, and the map starts out filled with a "default" tile, which means to pull from the graphical tile at that location on export. So you can draw any special collision you want, but most of the time just use the tileset. If I was going to do only one or the other, I'd do tileset style.

Layers are useful mainly if you want to give some depth to the background by having several layers that scroll at different speeds, or if you want to have some foreground objects that you can walk behind.

And now, the saving part... In the map editor, I only save filenames of tilesets and things. The maps (layer settings, tile map arrays, enemy placement, etc.) are all saved into one big project file. For your first editor, I'd recommend having one project file, and a separate file for each map. With a single big file, it's harder to deal with file format changes, if you add any new features to the editor later. Single big file has the advantage of being easier to create backups (just change the filename next time you save, rather than having to go and copy the whole folder)

For mine, the data formats used by the map editor and the game are a little different. One thing is the collision, which it runs through and replaces any tiles set to "default" with the corresponding collision tile for the graphical tile there. I also convert the tilesets from their original .bmp format into a custom format, which strings it out to a tall bitmap the width of one tile, and RLE compresses it. In the process, I compare all tiles to eachother and discard any duplicates (this is pretty tricky, because all the maps are still referencing the duplicates, plus any time you remove a tile, then the tile numbers of all the ones after it get shifted down by one, and need to be corrected in the map data as well)

As for loader DLL or not... I say either way. I have the map editor with an "export" function to convert all the editable map and project files into a single giant data file for the game, including all map data and tile data and sprite graphics and music, everything. I also copy/pasted the export code into the game, so it can load the map editor project directly as well. Allows editing sprite and tileset .bmp files without going and re-exporting from the editor. That copy/pasted code won't be included in the final game, so maybe a DLL would be more appropriate.

If you want to talk file formats, I'd be happy to describe mine in more detail. It can get pretty hairy converting everything from the in-memory editing data to the editor file format (and back again), and from editor file format to game file format. But it makes the game code much simpler when all the data is in the most directly usable formats possible, and it's convenient when your distributable is just the .exe and one big data file.

You can give my map editor a try.

Quote:

Original post by iliak You can give my map editor a try.

Double fail, not only is it a 404, but its a FRENCH 404 :p

I'll go ahead and answer this aswell!

1. Map for 2d game is 2D array, right?
Both yes and no. As someone already mentioned there are many ways to store the map. I am using a struct, containing tile iformation, triggers, textures and more. But a normal 2D array is very simple, and still powerfull enough to suite your needs, so i would go with that!

2. I want to manage coliision system...
Once more, there are many ways to solve this. Programming in it's bare bones is just problem solveing :) But as a key rule, always try to make things as simple as possible. I found it easiest to make use of layers for this. I have three layers, where as the first is my "Walkable layer", the second is my "Solid layer" and the third is my "Effects layer". The walkable layer contain all tiles i can walk on. The solid layer contain all tiles i can collide with, and the effects layer contain all tiles that are drawn above the player.

3. I have no idea how to save all that tiles...
Saving is basicly writing your map data to a file. You could have each tile represented by a number, then just write the numbers to a plaintext file. OR! You use a struct, and write the struct to a binary file. This way you don't have to parse the file to load all tiles. You just read the struct data an assign it to a struct in the game.

4. ...should I make DLL with that function?
I have no experience with DLLs, so i can't answer that for you. But keep to the key rule of keeping things simple. A DLL might be a bit overkill for just one function.

5. When excatly layers system is useful?
Depends on the complexity of your game. If you intend to draw just some tiles in the background, a layer system is too much. But if you want to draw ontop of the player, then you kind of need it :)

And what if I would go with 3D array where first array is layer on which You are on, second and third would be a x and y positions.
I would do 2 layers, first one a "walkable layer" and the second "solid layer" as Zomgbie mentioned and I would go with binary saving.
I am just curious how would that solid layer work.
On the walkable layer I would just put tiles etc and on that solid layer I would put some kinds of collision titles which would be non walkable? And then durning loading map I would put all that solid tiles into list and durning game loop I would check if character collide with any of that object by using some sort of collision algorithm?

And big thanks for answers.

P.S Have any of You guys ever used GTK+? I don't know which packets should I download and which not x_x

[Edited by - darekg11 on December 14, 2010 9:57:31 AM]

As others have pointed out, you don't necessarily need to lock yourself into a 2D array for your format. It really does depend on the game though! Are you ever going to need tiles or sprites or entities that are halfway between one tile and the next? Walls that are only half a tile thick? Tiles that move smoothly? You might consider just storing a list of entities with X and Y positions which may or may not lie on a 'grid'. Need a section of your map to contain two tiles on top of each other? No problem, just create two entities with the same position, and perhaps add a 'height' or 'layer' value to each entity.

From your post, and considering you're talking about collision, it sounds like you're going to have objects moving around fluidly, as opposed to something like chess where tiles truly are appropriate. Make sure you think about your decision, hopefully this is helpful!