It depends on how you want to do it, zelda styled, as in square tiles, there are editors out there that can do it for you. If you want to build it yourself, then you need to know everything about your map that you want to be able to modify. are there different heights, how many textures, can multiple objects occupy one tile etc.

Once you know that, you can decide how you want to implement the map editor, for example, the map editor i use for my own project allows clicking on a tile, which locks it for editing, then the data for it can be modified and updated. There are more efficient methods i'm sure, but this one was simple to code and sufficient for my needs since my maps are mostly randomly generated.

Having said that, i would look into the following thread http://www.gamedev.net/community/forums/topic.asp?topic_id=496897
It has a link to a map editor that may work for what you need.

For a map editor you're going to have to get familiar with GUI programming. For Windows specifically there's various ways of handling windows/menus/controls and whatnot and they run the gamut in terms of ease of use and effectiveness. Personally I'd probably put native Win32 programming using C/C++ at the "very hard and tedious" end, and .NET w/ WinForms at "easy and delightful" end. Either way you'll probably end up having to learn how basic things like messages/events, common controls, menus, input, and dialogs work in a typical Windows GUI app.

If you plan to make your own, step one is to know what you need to know about the map. Unfortunately my map editor is in Visual Basic and it runs on a hexmap system, so it's probably less useful to you.

The theory though will work just the same. My method is not the best, nor the only method of course, but it's a general idea that you can apply to your specific requirements. As far as a platformer editor, i'm not going to be useful on that, i've never worked on one and i don't want to steer you wrong.

My own implementation is very very very very (ad infinitum) simplistic, using only bitmaps, for me that's because it's good enough for me to complete the functional code beneath before moving on.

1. Save a map: You'll just use a file reader/writer to output your data, for a zelda style, it works effectively enough to use a 2 dimensional array and jout output the data, keep in mind that you need to read and write it in the same order.
My save files for example have the first 4 bytes as the x and y dimensions (2 bytes each), following this, for each tile 1 byte stores the texture ID, 1 byte stores the height. Since my maps never have units on them (no saving on the map) i don't need the additional information stored. Also whether the tile is passable is determined by the texture ID, that's something else you might need.

For a 256x256 map for example, i store 4 bytes for the dimensions, and then 65536 pairs which tell everything about the tile. You don't need to save the image of the map to a file, just the data about it.

2. Load a map: at this point you just read the data from the file, since you know how it was written it makes it easy for you.
In my case, i will read 2 sets of 2 bytes, that tells me the dimensions of my storage array, i then read in each byte to fill the items in the array (2 per array index)

3. Draw the textures: for my implementation, i have a single bitmap that has all the tiles lined up beside each other, i use the textureID and the known width of the texture to read the block at that pixel within the bitmap. This just gets drawn on the screen based on the location of the player. For example, you may have a 128x128 map, the character may be at (40,60) and you might want to draw just the 10 squares either side, you would use the array location of your character, find all the surrounding squares and draw them to the screen one at a time from your texture file.

4. Make different layers: This depends entirely on what you mean. if you want different layers that move at different speeds, it's beyond the scope of my knowledge, if you just want to specify which units go on top of what, just draw them from the bottom up (higher things are drawn last).

5. Applying a clock: If you use the drawing method i use, this is probably not going to work, however if allegro has the functions you could just use a timer and change the tint or lighting amount based on that timer, you can use a Sin wave to change the amount of light for example or you could use an arbitrary change (day to night instantly)

6. This is beyond the scope of my knowledge.



Having never used Allegro, i'm not the best person to give advice on implementation for drawing, however as far as the data structures for a tilemap, this system is effective enough.

I hope this has been helpful

Quote:Original post by nightech
My save files for example have the first 4 bytes as the x and y dimensions (2 bytes each), following this, for each tile 1 byte stores the texture ID, 1 byte stores the height. Since my maps never have units on them (no saving on the map) i don't need the additional information stored. Also whether the tile is passable is determined by the texture ID, that's something else you might need.

You can easily extend this with layers by saving multiple blocks. You can then also easily use one layer for the visuals and another for collision purposes. You may also want to store a list of texture filenames in the file somewhere, or, in your case, the name of the tileset bitmap. It's a bit more flexible than using a single bitmap for all levels. Especially when you're working with multiple levels and when you have a variety of styles that may become very useful.

Then again, it may also be feature creep for your game. ;)

Quote:3. Draw the textures: for my implementation, i have a single bitmap that has all the tiles lined up beside each other, i use the textureID and the known width of the texture to read the block at that pixel within the bitmap. This just gets drawn on the screen based on the location of the player. For example, you may have a 128x128 map, the character may be at (40,60) and you might want to draw just the 10 squares either side, you would use the array location of your character, find all the surrounding squares and draw them to the screen one at a time from your texture file.

You're more or less using the player position as a camera offset. Personally I find it useful to separate these concepts. I'd then tie the camera to the player, and when doing cut-scenes, I'd tie it to something else. Parallax scrolling becomes easier, too.

Quote:4. Make different layers: This depends entirely on what you mean. if you want different layers that move at different speeds, it's beyond the scope of my knowledge, if you just want to specify which units go on top of what, just draw them from the bottom up (higher things are drawn last).

A layer can simply be a group of sprites. If you use a camera as a drawing offset, then different movement speeds are easy: every layer multiplies the camera position with a certain value and uses the result. A layer that moves equally fast as the camera would use factor 1, a background layer that's moving very slow would use a smaller factor, and so on.


@NimbleSpeed: Point 6 depends a lot on the specific requirements of the games, but it's not impossible to use one editor for both, if you take a generic enough approach.

However, if your goal is to write games, then write games. There's quite a few editors around already, so just take one and perhaps modify it a bit. You know what? You'll learn what's valuable about and editor and what's not, which will help you develop your own when you need to. Besides, you'll be building levels much earlier, which is helpful when testing your game.

An alternative would be to build an editor interface on top of your game. Might allow for rapid testing if you make the switch between editor and game seamless.

In the end, it depends on your skills. If most of this sounds too complex for you, then start out simpler. Don't take on too many new elements all at once, gradually work your way up.

Quote:Original post by NimbleSpeed
When trying to make the editor, what should i already have done. by this i mean do i need an already functional version of the game?

You will need a version of the game that can display the map, of course.

Another approach is to use the same engine for the map editor and the game. This cuts down on the amount of work that has to be done, as changes in the map display routines are only done once. This was a popular way of doing things 'back in the day'.

Quote:Original post by Captain P
You can easily extend this with layers by saving multiple blocks. You can then also easily use one layer for the visuals and another for collision purposes. You may also want to store a list of texture filenames in the file somewhere, or, in your case, the name of the tileset bitmap. It's a bit more flexible than using a single bitmap for all levels. Especially when you're working with multiple levels and when you have a variety of styles that may become very useful.

Then again, it may also be feature creep for your game. ;)

Layers at this point is definitely feature creep, right now as long as it displays i just want the functionality, when everything works i'll be looking at adding such features. Thanks for the insight, i'm keeping this bookmarked.
As far as the tileset, that will become more important later most likely, but for now i have a simple 7-8 different tiles, but i will definitely implement the tileset filename functionality now to save time later, thanks.
I don't currently need collision detection because it's turn based and everything is calculated off skill, so the collision rolls will determine the animations, for unit collisions, i currently check the occupant of the next hex, if it's empty then moving is okay, if it's occupied, then movement isn't allowed.

Quote:
You're more or less using the player position as a camera offset. Personally I find it useful to separate these concepts. I'd then tie the camera to the player, and when doing cut-scenes, I'd tie it to something else. Parallax scrolling becomes easier, too.

Actually more than just useful, in my case it's necessary, i will look into implementing this shortly, i guess i'll just need mousedrag on the map to implement that, or use border scrolling.

Quote:
A layer can simply be a group of sprites. If you use a camera as a drawing offset, then different movement speeds are easy: every layer multiplies the camera position with a certain value and uses the result. A layer that moves equally fast as the camera would use factor 1, a background layer that's moving very slow would use a smaller factor, and so on.

Quote:
@NimbleSpeed: Point 6 depends a lot on the specific requirements of the games, but it's not impossible to use one editor for both, if you take a generic enough approach.

However, if your goal is to write games, then write games. There's quite a few editors around already, so just take one and perhaps modify it a bit. You know what? You'll learn what's valuable about and editor and what's not, which will help you develop your own when you need to. Besides, you'll be building levels much earlier, which is helpful when testing your game.

An alternative would be to build an editor interface on top of your game. Might allow for rapid testing if you make the switch between editor and game seamless.

In the end, it depends on your skills. If most of this sounds too complex for you, then start out simpler. Don't take on too many new elements all at once, gradually work your way up.

In hindsight it might have been a better option to include the map editor in the client application, i think the idea of including the map editor as part of the main game is definitely a simpler method, you could just use a boolean to pause the main game loop while editing for example.

Quote:Original post by cdoty
You will need a version of the game that can display the map, of course.

Another approach is to use the same engine for the map editor and the game. This cuts down on the amount of work that has to be done, as changes in the map display routines are only done once. This was a popular way of doing things 'back in the day'.

If you implement the editor as part of the game, then it will probably be a lot easier, if you do it separately you will know the loading routines etc required for displaying the map. You could build a basic map using a base tile (see most commercial map editors) at the click of a button, and from there initialise the game and edit it real time by walking around it with your character for example.