Category Archives: Level editing

Construct 2 as Level Editor

Construct 2 is actually a complete game engine that I often mention to artists or designers who want to experiment with their own projects. The free version has plenty of features and the pro and commercial versions are affordable, too. It uses an XML project format so importing a Pingus level is quite straightforward:

Pingus in Construct 2

Pingus in Construct 2

Editing and scrolling are very fast and I like the controls for placing and moving objects. When I wrote the importer it was mildly irritating that many of the XML tags have a dash in them, which breaks word selection when copy and pasting tags into sourcecode.

Construct 2 manages sprite and animation bitmaps itself, which may add a bit of extra work if you want to manage your own sprite sheets for editing. You can add your own properties to an object type.

It would be useful if you could group layouts or object types into folders, because the flat lists get a bit awkward to browse in a huge project.

(Comments disabled because of spam. Come on, guys! Is that really necessary?)

GLEED2D as Level Editor

GLEED2D is written in C# and XNA. It uses an XML file format so it was easy to import a Pingus level:

Pingus in GLEED2D

Pingus in GLEED2D

The editor rounds up texture sizes to the next power of two, and scale factors and the rotation origin are relative to this scaled up size. That makes importing and exporting levels slightly more complicated. In most cases I would pack background sprites into an atlas before rendering, so I can’t think of many reasons for expanding individual sprites to power of two.

Level drawing and editing is very fast, and the image browser makes it very fast to add new sprites to a level. You can specify custom properties, but they are attached to a sprite instance and not a sprite definition. It is possible to specify programs to run after a level is saved or to preview a level in a game.

Documentation seems to be only available as videos, which I find more time consuming than reading documentation, especially when I need to look up specific features.

The image browser caused an exception when displaying a large sprite directory. I’m not sure if it ran into a windows resource limit or just failed to load a file, but I think for a proper project you would organise sprites into smaller subdirectories anyway.

OGMO as Level Editor

OGMO is another editor written in C#. The main focus is tile based editing, but it supports a free form entity layer. This is a Pingus level imported into OGMO:

Pingus in OGMO

Pingus in OGMO

Editing and scrolling a level becomes very slow, even in small levels. To be fair, though, the entity layer is good enough for placing enemies and traps. Changes to the project definition require levels to be closed and reloaded. It is possible to attach custom data to levels and sprites.

OGMO writes project and level data in XML format that is easy to read and write. One thing to watch out for is that the file format uses localised floating point format, so an international team with mixed locales may run into problems when exchanging levels. The rotation origin seems to be the unscaled origin, and scale is the top left corner.

There doesn’t seem to be any written documentation and at the moment the website only contains a few tutorial videos, so a lot of the user interface needs to be explored by trial and error.

Spriter as Level Editor

Spriter is an animation package for sprites, so trying to edit levels with it is probably not fair. I quite like a lot about its user interface and general performance, so I imported a Pingus level into it:

Pingus in Spriter

Pingus in Spriter

There is no way to add custom attributes (at least in the version I tried), and no way to specify groups or layers. It seems to stall whenever it needs to go through sprite data, for example after zooming or scrolling, or after changing the selection. This is most likely caused by the number of sprites, and with a more appropriate scene size for animation it shouldn’t be a problem.

I do quite like the user interface, and I imagine a more organic looking level with many animated elements would look very good. For now it may be a better idea to just animate parts of a level in Spriter and use a different editor to build the complete level.

DAME as Level Editor

DAME is a level editor developed on the Adobe Air platform. Air gives it cross-platform compatibility but seems to require quite a lot of CPU performance. Many of DAME’s features are for editing tile based or isometric maps but it is possible to edit free form layouts as well. This is a Pingus level in DAME using sprite layers:

Pingus level in DAME

Pingus level in DAME

Zooming out is disabled by default and enabling it can break map rendering. Air renders everything through the Flash player which seems to eat up quite a bit of rendering performance. It uses custom UI widgets which look and feel slightly different to the platform default widgets.

DAME uses an XML based file format that is easy to read and write, you can attach custom properties to sprites, and you can set a scroll factor on each layer to preview parallax effects. Sprites can be animated and can have per-frame collision data. It is possible to group the sprite information into folders to make it easier to find specific sprites. DAME uses Lua to implement custom level exporters.

R.U.B.E as Level Editor

R.U.B.E is an editor designed to edit scenes for the Box2D physics engine, but it is flexible enough for general level editing. So this is a Pingus level in R.U.B.E:


Pingus in R.U.B.E

R.U.B.E is very fast, but feels very low level. I don’t like that editing different elements requires mode switches and that some functionality is only bound to keyboard shortcuts, but that probably makes it very fast to use once you’ve learned them. Some of the editing keys feel familiar from Blender, so a Blender user may be at an advantage. R.U.B.E embeds AngelScript as a scripting language to extend and customise the editor.

It would be useful to be able to organise a scene into different layers. Similar to Inkscape I am missing some kind of library to store reusable gameplay elements, but this could probably be implemented using the scripting language.

The file format is designed around the Box2D runtime, but with a bit of work it is possible to use it in a different engine. It is a JSON document that can be easily accessed from many programming languages.

Update: For some reason the spambots like this post, so I disabled comment posting. Sorry about that!

Inkscape as a Level Editor

Ubisoft recently released Rayman Legends and I was quite impressed by the UBIart Framework demos:

They developed a free form level editor, with what looks like procedural texture generation to fit graphics to collision data. It looks very powerful, but for now it is only available for Ubisoft projects. I am sure we will see some open source clones at some point, and there are already some interesting developments for Unity3D.

Many of the level editors accessible to independent developers so far focus on grid and tile based level layouts, but I wanted to investigate what editors are available for a more free form level layout.

To start I had a look at Inkscape, which is an open source vector graphics editor available on many platforms, that reads and writes SVG files. SVG is a standard format, so you can import and export it from many applications, and you can even preview it in many web browsers. You can add custom data that can be picked up by a game engine to control collisions or gameplay elements. To test this out I took a test level from Pingus and imported it into Inkscape, similar to the way that is described in this blog post.

Pingus in Inkscape

Pingus in Inkscape

Pingus has a built in level editor and uses a simple text based level format based on LISP. It’s easy to read with a simple Python script and to write out as a SVG scene graph.

Inkscape performance on OSX is not very good, which I assume is a combination of the SVG rendering code in combination with using GTK+ through X11. Though the performance isn’t very good on Windows either. I am sure one of the key reasons for that is the complexity (and power) of SVG rendering, which makes it important to post process a SVG scene into more hardware-friendly data. You will have to decide which subset of features can be used to build levels or you may have to spend a lot of time implementing SVG features.

Inkscape doesn’t seem to have a built in mechanism to organise clip art or object libraries. A workaround for that is to put templates for your game objects onto a different layer outside the level and to clone them onto your level.