next »

[Mikademus]

I am making an editor for a game I am working on. It is a platformer/adventure game where levels/worlds are composed of layers. Tile layers are built up by square tiles, props layers have images placed as decoration (and items of interaction). These are the two most important kinds of layers. The platforms are vector drawings.

Now, I want to manage my time carefully and spend effort on what is most critical. However, I am not fully certain what tends to be most critical in tile editors.

What are must-have features, and what are common stuff to implement that are rarely used?

F.i. a thing like moving entire blocks of tiles at once, is it critical or is it something that seems great but seldom used? Copy and pasting of blocks of tiles? Etc.

[MadWatch]

I made an editor like this for my previous game (a platformer as well). I didn't want to spend to much time developing it so I didn't put anything but the bear minimal features into it. I regretted that choice later 

Without a good editor level building becomes a pain. I'm currently making a new editor for my new game project (yet another platformer, sort of...) and this time I'm doing it well.

So, in my humble opinion, the most important feature of all is the ability to play your level as you edit it. Placing a spawn point and clicking a button makes the editor switch to game mode and then pressing esc make it go back to edit mode.

Aside that I would say the ability to select several tiles at a time with a selection rectangle or a ctrl-click is nice to have. Copy past is pretty useful too.

Since my levels are limited in size (1024x1024 tiles) I'm making a rustic minimap system that will let me have a quick look at how much space I have left and a shifting tool that will let me split the whole level in half in any direction and move one half away from the other, I really missed that in my previous editor.

Finally, if, like me, you're going to have a lot of different tiles types but won't use them all in a single level then a kind of pallet of already used tiles types (so you can quickly select them without searching them again in the menu) is a nice tool as well.

Hope this help.

[Paul Eres]

- being able to save and load levels
- being able to edit them with a mouse and with keyboard shortcuts
- arranging the objects you place by type/category in a "palette" so that you can see a row of them at a time and select from that row
- being able to copy and paste groups of selected tiles. i.e. to draw a rectangle with the mouse, and use ctrl+c and ctrl+v to copy and paste that rectangle to other places
- a 'fill' tool that fills in enclosed areas with a tile

[Danmark]

• zoom
• mouse-controlled camera pan that doesn't require moving to the screen edges
• free selection (rectangles being only marginally better than nothing)
• move selection; more important than copy/paste unless repetition is important
• draw tool that connects consecutive pointer samples (i.e. doesn't draw a bunch of dots)

- a 'fill' tool that fills in enclosed areas with a tile

If this is implemented, undo/redo functionality is essential. Accidental fills destroy much information.

[Paul Eres]

yeah i agree, i forgot an undo/redo feature, that's pretty important even without a fill option

[Mikademus]

Excellent advice. You've suggested some things I had hoped to delay or scratch altogether, which is what I needed to hear.

@MadWatch: The editor is in-game. Pressing tab switch between game and edit mode so changes are instantaneous. I am not limited in level size but if levels grow large a minimap sounds like a good idea. And yeah, your suggestions help!

@Paul: Thanks! I had reached almost the same conclusions, but I forgot about a fill tool. I had hoped to not have to do undo, but it seems like it is a pretty essential thing.

@Veracity: Dang, the game engine that renders the world isn't supporting zooming... Is that a show stopper issue according to you? About mouse panning: right now the arrow keys pan. Is that sufficient or is being forced to use the keyboard a nuisance?

[Fallsburg]

I would suggest something along the lines of:
Mouse Wheel         -- Move up/down
Mouse Wheel + Shift -- Move left/right
Mouse Wheel + Ctrl  -- Zoom in/out

You can swap those to be whatever works best for you (or better yet make it a configurable option). Of course, if you can't zoom, then you just drop that and keep the others.

Undo/Redo is very important.

A way to put some sort of metadata and/or comments is nice too.

[Moczan]

If you want to release it for other game developers, custom output is a must. I'm amazed how hard it is to output a plain Array of tiles in some of the tile editors out there.

[Mikademus]

@Fallburg: Photoshop movement, eh? That's a good idea since I aren't using the mouse wheel for anything atm. Comments is a nice idea. I will consider it.

@Moczan: This is an in-game editor, and as such quite connected with the engine and formats I use. I also don't have a powerful GUI (like Qt etc) so dialogues and drop-down boxes with options would be a chore. I see your point, though. Would external converter tools be ok? Perhaps saving could be automatically chained through those by config commands... Hmm...

[baconman]

If you're going with a minimap; have a function that can enable/disable it to the player. Sometimes the outcome of a game is that it's broken without a minimap (like Metroid), or sometimes it can be broken by HAVING one (like Dark Souls, if it did).

[increpare]

Being able to seamlessly transition between editing and playing.

Other than that, painting by hand is usually fine for me (clicking+dragging), autotiling can help as well but that's not an editor thing strictly.  I do occasionally use brushes in mappy, but have never felt the need for it in my own games.  But none of the games I've made an editor for have been that expansive.

[Paul Eres]

undo is actually pretty easy to code; when i coded SD's undo for the level editor i thought it was going to take a lot longer than it did. basically all you do is save the level after every action in an 'undo' folder, to the same file name. then load that file when someone presses the undo button. simple

doing multiple levels of undo is harder, though. but just a basic undo as described above takes a few minutes to code

[Mikademus]

Level reload as undo would be a bit slow, but better than nothing I suppose.

Anyway, I bit the bullet and implemented a real unlimited-depth undo/redo solution. For every operation (move, paste, erase, etc) I store the affected tiles with the operation type and push it on an undo stack. The same state is passed to a "perform" method where it is effected. The same data structure can be used to reverse the change == undo, and since the level is now in the previous state it can be reapplied == redo.

@Increpare: in this game the game mode and editor modes are program state that acts on the same data set. TAB switches between them, with the editor pausing the game, and any level changes are therefore there in the game when you step back to it.

It is the first in-game on-the-fly game editor I've made and I can't see myself ever doing a game without one again!

[rivon]

Anyway, I bit the bullet and implemented a real unlimited-depth undo/redo solution. For every operation (move, paste, erase, etc) I store the affected tiles with the operation type and push it on an undo stack. The same state is passed to a "perform" method where it is effected. The same data structure can be used to reverse the change == undo, and since the level is now in the previous state it can be reapplied == redo.

I thought about exactly the same solution. Just create a class which has two variables - array of affected tiles and the used operation. Probably also the previous version of the tiles.

[Mikademus]

For those interested, undo/redo is an example of when the "Command Pattern" is actually really useful.
though I guess that's more technical than design...