Map Editor

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.

ya i really looking in to making my own,thanks though.

This was a good link also.
http://www.gamedev.net/reference/list.asp?categoryid=44

I've seen a lot of good editor on google, and I just wondering about a couple important things.(probly should have mentioned it in the first post) I'm trying to plan ahead of time before I start actully programming. I'm not extremely new at c/c++ (and willing to use different lang) but I'm not a any good yet either.

I would like to understand how to:
1.save
2.load the map into a game
3.load the actual sprites/texture...(so on)
4.making different layers
5.how if possible to applie a clock (to make the game have a day/night)
6.The differences between an rpg and a platform map editor

I am searching (google and gameDev) alot and looking for tips, and explaintions. I am very stubbon however and would like to code it myself(examples are still welcomed..alot) but I never expect someone to be so kind, lol. Just trying to hone my game making skills.

There is no tutorial for experince.

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.

earlier in the year while working on an rpg I had to figure out how to make a map editor, the engine was written in C++ but for the map editor I found it far quicker to work with C# and its forms editor(Oh and I had barely any C# experience at the time). For the saving and loading code there were only a few minor obstacles I had to overcome but other than that it turned out perfectly!( except for a few bugs here and there ;) )

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.

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?


thanks to everyone who posted already, and those who are still going to post. everyones been a great help.

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.

Hi,

Take a look at Nick Gravelyn's Tile Engine video tutorial which covers the beginning of a basic RPG and a map-editor. The language of choice is C#, and the editor is a standalone winform app. Even if you do not want a .NET editor, the tutorials itself is a great introduction to basic features in order to get your own RPG up and running.

So, a good level editor would actully already have the physics/engine programmed into it?

I know that sounds like a dumb question, but im actully trying to make the game from scratch so if there is anything i should probly have done prior to just the map editor could you mention it?

also has anyone ever made an object become transparent (can still see the item but you can see threw it, like a ghost). if so, was it just a function of allegero(or whatever) or do you actully have to program that?

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?

That's up to you. Though personally, I think developing an editor without having a game is a bit like shooting in the dark. If you have a game in place already, you have a much clearer target. Simple test levels can be created by hand or with a few basic scripts during initial development.

Above all, keep in mind just why you're building a specialized editor. A good level editor, imho, allows the designer to focus on designing levels, rather than tedious data formatting. WYSIWYG. An editor doesn't need 'physics' or 'a game-engine' to be good. Those are implementation details. If that serves the ultimate goal of your editor, then yes, you could use them. If not, then don't bother with it just because you feel it'll make your editor better.

That's why I'd suggest (again) to use an existing editor. Not only will it likely save you a lot of time, you'll also learn what's valuable about an editor and what's not. Ah, time. You may think you have plenty of it but there is something like running out of motivation. Use it wisely. :)


For a turn-based strategy game I worked on a while ago, we simply used a few text files and a conversion script written in Python for the levels. Writing a full-blown editor would've cost much more time, especially since we didn't need too many levels.

Quote:

Original post by NimbleSpeed So, a good level editor would actully already have the physics/engine programmed into it?

An editor usually just outputs your work into some data format like a basic text file or xml file which the game can load. During development, this makes it very easy to make quick changes without having to load the map into the editor, or recompile etc. So no, the editor does not have to know about the engine code, but it would make it a lot easier if you develop them both. You don't need to know about the physics. You would probably need some way to define collision control of tiles, though. I compile all my different layer files into XNA's binary content format as a map file which the game loads when needed.

Quote:

Original post by NimbleSpeed I know that sounds like a dumb question, but im actully trying to make the game from scratch so if there is anything i should probly have done prior to just the map editor could you mention it?

Do watch at least some of the video tutorials I posted a little up. They give a lot of insight in where and how to start. They are really great learing material for any tile game, not just RPG.

Quote:

Original post by NimbleSpeed also has anyone ever made an object become transparent (can still see the item but you can see threw it, like a ghost). if so, was it just a function of allegero(or whatever) or do you actully have to program that?

Check allegro's drawing routines. I've never used allegro, but I would think this is a basic feature of all graphic libraries/engines/frameworks and pretty easy to hit with a some searching.