It's not that hard to create a simple editor, but the more complex you want your editor, the harder it'll be.
If you can make a specific game, then you have the skill to make an editor for that game. How fancy and pretty the editor is, and how far you take it, is up to you (but in the end, don't let creating the editor get in the way of creating your game itself).
You can also look at more generic solutions like
Tiled and
Mappy.
The question of whether or not it is worth it is something you'll have to determine for yourself. How much will it ease development of the game? How much time will it cost? Have you already tried available tools? How much of your game's code can you re-use for the editor, and how much will have to be coded from scratch?
Here's a few tips:
1) Integrate the editor with the game itself. This has two benefits:
- You don't even have to 'reuse' most the code, you can just use the code directly.
- You can walk around inside the game world, push a button and switch to editing mode on that area you just were in, then push a button and switch back and interact with what you made (if you code it that way).
2) If only you are using the editor, don't waste time polishing the editor - spend the time polishing the game itself.
3) Figure out in advance what map features your game will need - don't keep changing the map format, or you'll have to convert all your old maps each time you make a change (unless your map format plans in advance to tolerate changes, which can be done in a number of different ways).
4) Don't have hard limitations. Hard limitations are where you say, "I'll only ever allow x of something, I doubt I'll need more". Just allow infinite of everything. Here's some examples:
- Tiles. Don't limit the amount of tiles you can use on a map. Some editors only let 100 (or some other hard limit) different tile images on a single map.
- Layers. Don't limit yourself to 'x' amount of layers of tiles. Your map designers (In this case, yourself) will complain unendingly until you finally relent later anyway.
- Entities. Don't limit yourself to 'x' entities on a map either. All three of these limitations I have encountered in (three different) editors in the past, and they all hinder map maker creativity.
5) Don't pre-optmize your map format (or anything else for that matter). Make it work, then move on with your game. Only if your game is slowing down due to slow map loading,
then you can give yourself permission to optimize the map format, or the map loading functions.
If you do happen to need to optimize your map format, here's some tricks:
1) Think of every calculation that the
Editor can do for you when
saving, that can speed up the
Game map
loading. Pre-calculations on saving can bring big benefits on loading.
2) Another optimization trick* is if your map files are text-based (XML, script files, or some other text file), if they are loading to slow, switch to binary instead, and load the map straight into the structs by copying the binary bits. Major speed up results.
*[size=2]Okay, that's not really a trick, just plain common sense, but sometimes I focus my optimizations on the code itself, I forget to optimize the format of the file.
3) If the previous loaded map uses resources that are needed by the next map you are loading, just pass over the resources so you don't free the resources when you free the old map, and reload the same resources when you load the new map.
Remember that speed comes at the cost of convenience of development, which is why you don't want to optimize pre-maturely - because pre-mature optimization is not always free speed - sometimes you have to trade for that speed, whether ease-of-use, memory space, or simply time-shifting the slowdown to an earlier or later point in time. Sometimes the cost of an optimization is not anything related to the code, but it's a cost to your real-life time. The indie developer Jonathan Blow says, "
Optimize for development time, not for speed" (unless the game is running too slow).
