Ad-hoc Usability


The Backworlds editor is, as we’ve previously mentioned, a set of menus in the game itself allowing us to make changes to the levels as they are being played – rather than being built from the ground up as a level building instrument it has been patched together over time as tool for manipulating game data within the context of the game. While this has the advantage of really short iteration times, it has the disadvantage of being slightly inconsistent and with a quirkier workflow than an actual level editor. I am no expert in either usability or data mangling, but for a small project such as ours I have noted a few small changes that had a big effect on workflow.


The engine was originally built for another game, at the time I had added the first few pieces of the editor in order to facilitate the fine-tuning of art placement in exiting levels. As I was working on a laptop with only a touchpad for input, I opted to add per-pixel movement of objects with the arrowkeys to help with precision placement. A couple of weeks later, one of the artists working with the editor came and asked me if I could maybe add a bigger step size for moving things around with the arrowkeys since it was taking her a really long time to place things – she had not realized she could use the mouse for dragging objects around directly. My mistake, really, that game did not have any mouse input and I had not mentioned it to her, but it illustrates how tools can seem much less malleable than they are – even though the problem had a crippling effect on her workflow (imagine only being allowed to move the mouse cursor with arrowkeys in any other application) she still waited a long time to let me know. A nice side effect of building levels myself is that I can get a sense of some of the workflow issues that come up and fix them as they become a nuisance to myself.

Gizmo selection


This is a picture from the first demo level Juha made – I still do not know how he managed to put it together as well as he did with the editor in as a crappy state as it was. Objects could only be moved one at a time, clicking the screen would cycle through the objects whose bounding box you hit, but as there were several scroll layers (and two paint layers!) as well as objects that were mostly transparent, it was really difficult to find out how to move a particular object. I made a lot of improvements at the same time after we released the demo but one of the smallest one with the the biggest payoff was borrowing the idea of gizmos from 3D modeling software – in essence, each game object that can be manipulated is represented (as can be seen in the screenshot) by a small gray-black box and a descriptor tag that is rendered on top of all the other graphics. Rather than clicking the general area where an object was, you instead clicked the labeled box – this removed a lot of misclicks and made it easy to find objects even if they were mostly hidden.

Render order

Rendering order – which graphic objects are in front of which – could in the beginning only be controlled by selecting an object, then bringing up a list of all objects in the level and deciding between which the selected object should be drawn. The prototype levels only ever had 10-20 graphics objects so it never became an issue when I worked with it, but it quickly became a bottleneck when we got more objects than we could print on screen or got duplicates of the same object so it became unclear which was which.

Adding the traditional “Send to Front/Send to Back” options may have been sufficient but it would have made mistakes tedious to correct, so instead I opted to let the user use the mousewheel to change render order – the selected object checks what bounding boxes of other objects are overlapping itself, then creates a localized priority list and moves itself one step up or down depending on the scroll direction. This covered almost all of our sorting needs but was still easy to use.

Script support

Juha has mentioned our lua scripting support in some videos – the editor itself runs a lua context and we can define personal keybindings and menu items with a specific editor library in our lua interface. There are ways in the editor to manage prefabs and change  game object properties, but some times you need to do things like create random objects in a connected pattern or perform a long set of predictable inputs a large number of times, and in these cases it has been nice to not have to muddy the editor code with overly specific features. Also, working with the editor gives me some idea of the bottlenecks I run into myself but Juha will occasionally use it differently and this way he can, to some extent, make adjustments to optimize his own workflow without having to change the underlying C++ code himself.

… If you are building an editor from scratch with the sole intent of editing game data, there are much better ways to plan your input and structure the data around how you might want to change it. So far, we have been satisfied with the integrated editor though and since there are only the two of us the question of where we can get the most workflow improvement is a simple one to answer and often small changes lead to big wins.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.