Monthly Archives: October 2013

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.

Importing Layered Textures from Blender into Unity3D

dwarf_layers

Dwarf in Unity

This is a first experiment to import layered textures from Blender into Unity3D. This still uses the default Unity3D lighting function, but combines the texture layers that are on the Blender shader. The left dwarf is imported with the default exporter, the middle dwarf uses the improved exporter I am working on, and the right dwarf uses an improved material importer.

dwarf_render

Dwarf in Blender

To compare, this is the dwarf rendered in Blender.

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-rube

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.