Don't be blind-sighted by the "purpose" of content tools

You should always use the right tool for the job...right? If you have lots of time / money, then yes. Otherwise, it can be helpful to use a little imagination and use almost the right tool for the job. The hard part of creating a tool is often the interface. So choose an application that already has the interface, build in some smart logic, and you have a tool to go.

2D vector art tool as a path editor

Paths are used by AI (in racing games, for example) and cameras. They can simplify the intelligence of an agent or camera considerably, but they are a pain to construct, especially if the basic level structure change often.

One approach that works well is to use a vector art tool (such as InkScape) to build paths. You can save files in SVG format (and SVG is XML), so you can easily grab the coordinates of a curve. Of course, you will need to scale and offset the values to make it work in game.

InkScape can be used as a path editor

2D vector art tool as a level editor

Any tool that allows you to place 2D objects can be used as a level editor; but it is usually only feasible for very simple scenarios. For example, you could use colours from a palette to distinguish different objects, and only use rectangles to represent them. This is probably only viable for a small amount of different objects – if you cannot remember the appropriate colours for all objects, production will grind to a halt; it will be error-prone and painful.

As with the curve editor, you cannot annotate objects with properties. Well, not easily – in simple cases, you might want to use text boxes to put in properties. Again, for objects that have too many properties, this approach will be error-prone and painful.

Spreadsheet program as a level editor

For grid-based games, spread-sheet programmes can make nice tile-placement editors. There are many ways you can do this; here is one:

• Make cells square – make sure they are large enough for their contents.
  
• Use characters to represent different tiles ('w' for water, 's' for soil, etc.)
  
• Use conditional formatting to get a nice visual feedback.
  
• Save the file in some XML format that is easy to parse in from the game or game engine.

You can also use multiple cells per tile. Using four cells, for example, lets you specify the tile, a monster type, the number of monsters that will spawn, and a special object.

A simple spread sheet representation of a game level. Blue is water, orange is sand, grey is rock, and green is grass.

A more complicated spreadsheet representation of a level. The tiles are as before, now only occupying the top-left corner of each tile. Items have black backgrounds, and mnemonic font colours. The number of enemies is shown (colour-coded) in the right-bottom corner of each tile.

Normally I would not recommend character codes for any kind of information. However, when building a level with the keyboard in a spreadsheet editor, it is important to type rapidly. As long as you do not have too many types of tiles and other info, this is a sane approach. Just remember to document your codes! (This can be done in the file itself).

You can also include other pieces of level information in the file (for instance, in a specially allocated column (typically the first), multiple levels are easily stored in a single file, and you can copy, paste and drag sections. After getting used to this kind of level editing, you will find other tools cumbersome.

It is easy to go overboard with this method. Be careful to keep it simple. Except for the importer, the hard work is implementing the formatting rules. Make sure that you allow enough flexibility to add rules without needing to redo old ones. If you try to visualise too much information, you will not be able to see anything!