Building Better Tools For Game Design

As featured at liveware.problem

The barrier of entry for game design and development has been significantly lowered since the days of Pong, but it's still not low enough for most people to participate in the process. In this article I try to point out the largest problems with todays game design tools and offer suggestions how to create cleaner and more intuitive tools with benefit for everyone. (focused on entry-level design tools)

So what distinguishes the accessibility of tools like Construct, Game Maker or Unity compared to tools like Garage Band, Music Maker or iMovie for example?

It's not unfair to compare these tools, even though they have different uses and do different things, but they are designed to allow amateurs or hobbyists to create something without extensive knowledge in the subject. The first hurdle any user has to take is getting to grips with the tool they want to use, and it doesn't matter which activity we are talking about here.

The most intuitive activities of course being the ones that do not require any sophisticated tools, or any tools at all.

Football (soccer, for the yanks) might be a good example, the entry-barrier to play football is low. Playing football requires only the knowledge of how to use your body to kick the ball and a rudimentary understanding of the rules. Of course there's more to it than just that, but it has a reasonably low barrier of entry, as soon as you can control your body to kick a ball, you are good to go (around 5 years of age).

Videog-game design is of course more complicated, it's an umbrella-term that unifies under it many different activities like graphics, interface, software or sound design (etc.). That in itself makes it a problem as a hobbyist activity, it's hard to create a video game because it's hard to unite all these aspects into one person. The most rare aspect is on the software developer side, the one that makes things "go" inside an electronic device (be it a PC, a console or a smartphone).

Visual (re)Presentation

One major difference is the intuitive minimalist design of the application and the visual representation of what you are actually doing. While all new interfaces are daunting at first, the trick is to design an interface that is not only easy to use, but also easy to learn and understand from just looking at it. Apple has polished their interface-design over years of studying usability and it shows.

Tools like Garage Band have a first-time interface that might seem "infantile" at first, but is in actuality a masterfully crafted piece of interface design. It's not so much the colorful, friendly buttons but rather a clear structure to the application that makes it intuitive and pleasant to use, as well as a start-up configuration of the application that shows the most important and frequently used aspects of the tool.

37274221_2bfc7a4615

The start-up screen of Garage Band, with sample-project.

2

The start-up screen of Game Maker, no project loaded (it doesn't matter, it looks the same with a project loaded).

1

Unity3D start-up screen with loaded sample project.

The difference between these screenshots is the interface and how each tool represents the functions its supposed to perform. Garage Band shows us the most useful elements right away, you will be constantly using these elements throughout your work with the tool (loading samples, previewing samples, adjusting volume and pitch, putting samples into tracks, transforming samples).

Game Maker in contrast gives us nothing, all functions are accessed through property-inspectors hidden inside the tool. Furthermore there are hidden hierarchies that are never visually represented (objects, rooms, sprites, backgrounds, etc.). Unity3D makes the same mistakes, although presenting it in a slightly more familiar fashion for users of other 3D programs (Blender, Cinema4D).

An optimal tool for game design would have a visual representation not only of what the parts do, but also how they interconnect and how the hierarchy works. Current tools are very concerned in presenting a coder-friendly environment. Their UIs and interfaces display variables, functions and properties reasonably well but lack any sort of feedback of game-logic and visual representation of said functions.

4

For example, to create an object and add a behavior (here: move left, if left arrow is pressed) in Game Maker, you have to follow these 'easy' steps. Note that I skipped showing how to create an empty sprite, which is another 3 windows/steps.

The problem is that the interface doesn't really tell us what a sprite, object, event, or action is in the context of the tool we are using. Sprite would be the easiest to identify for anyone that ever heard anything about game design, but what is an "object"? A "behavior"? An "action?" What can objects do? Can actions be assigned to sprites or only objects? Can rooms have events?

I will not go into detail how to "fix" this instance of UI design, but already 3 steps could be skipped if there was a "make object from..." context command for sprites/etc., or a visual representation of the sprite that you can interact with (maybe similar to a node-system in Blender/Maya).

Untitled-1

Example of a visual representation with contextual elements, it's not perfect, but you get my drift.

I made the above example to illustrate containing a maximum of information in a visual representation of what later will become code. As far as I could gather in my rather short time with Game Maker, objects behave like containers for sprites and can have several behaviors (actions) that are triggered by events. Game Maker for some unknown reason has set an unintuitive hierarchy where events are parents to actions, I'm guessing thats because an event can have multiple actions/behaviors. In my above example this hierarchy is reversed, if thats "better" is debatable, but it's just a visual example after all.

A similar system, without the visual feedback of being in the 3D view, is present in the Blender Game Engine.

5

Blenders "Logic Bricks" node-system displayed on the left hand side of the screenshot. Ironically, the rest of Blenders UI is horribly unintuitive (yet very flexible if you take the time to learn it), but they got the logic-bricks right.

Flexibility, Emergent Depth And Complexity

In my experience the best tools and programs feature variable layers of depth to their functionality.

As an example After Effects has a first layer of functionality that is easy to understand and learn. You have tracks, you put things on the tracks, apply effects and transform them. Once you get deeper into the functionality and discover scripting a whole new world of possibilities and automation opens up. Automatically synchronize time-warps and jump-cuts with background music? No problem. Make animated characters react to transformation-events? Done. etc.

The beauty is, all those things are achievable "by hand" as well, without one single line of code, it's just less efficient. This goes back to tools like Garage Band offering enough "simple" behaviors/actions that can be combined in many different ways to create something of complexity. Current entry-level design tools don't provide this emergent complexity. If you want a complex game (read, an interesting game), you will need to go into the coding side of things, even though in your head the "logic" of the game might be simple. We need more logic-tools to create this emergent complexity without being bothered with scripting and calling on code.

Similarly game design and development tools should aim at providing enough 'premade' elements for complexity, while allowing for increased complexity by adding to the tool through code and scripting. Blender, while having the most intuitive logic-interface unfortunately gives little to no "premade" solutions for common game functions (any mouse-control needs to be scripted for example). Game Maker is better in this department, certainly better than Construct and Unity, yet it's still too simplistic. Now I might be wrong because I only spent a short amount of time with Game Maker, but as far as I know there is no function to assign what I would call a "sensor" to an object that would check for other function-variables (properties) without scripting (BGE does it with drag and drop to link properties to sensors).

Now lets get back to Unity for a second because it has one feature that is really appealing.

I'm talking about the integrated asset store here, it's one of these features you can't go without if you once experienced it. Having one central place to collect assets and elements was a stroke of genius. This functionality gives the tool almost infinite flexibility. For BGE its a pain to find premade assets or scripts for example, thats because the program is open-source and resources are dispersed all over the internet with varying degrees of quality and function. Having the community expand the tool publicly, building a library of assets, was a very clever move.

Premade Assets

The best tool with the greatest interface and functions is still nothing without assets.

A sample-mixing studio like Sony ACID is a great tool, except it doesn't come with loops, so it's usability for first-time users already is worse than Garage Band that comes with samples and loops.

Game design tools need to come with free assets. This doesn't necessarily mean integrated into the program, the Unity asset-store proves that, what is important is that there is a simple and intuitive way to access assets from the program in a central place, without going on a hour-long hunt on the internet.

It's simple for me to create a few graphics assets quickly to prototype a game-idea, for others, not so much. Similarly it can be easy for someone to come up with a script/sound loop but for me it would be hard and time-consuming to create or learn even the basic skills to produce it.

Reinventing the wheel might sometimes be educational, but it gets in the way equally as often.

Summary

Making the UI and visualization of our tools and processes better will benefit everyone, a clean and intuitive work-flow will increase efficiency for veterans and amateurs alike. Creating more intuitive tools will not "dumb down" game-design and it will not make dev-tools "less professional", it will simply make them better for everyone. Removing the layer of arcane sorcery involved can only benefit the industry in the long run.

Creating games doesn't have to be about reinventing the wheel every time, it doesn't have to invent new conventions or technology, all it has to do is create ways to put old and tried concepts together to create something new and interesting.

If we want game design to be viewed as a hobby, our future tools will need to reflect this. They should give us the ability to create emergent complexity from basic logic-interactions as well as providing us with flexibility for the more ambitious amongst us.

I see the problem being that current design tools are made by developers for developers.

The example again springs to mind of how Blenders UI is structured, because that is a prime case of the "from professionals for professionals" problem. Blenders UI is amazingly efficient at what it does, once you stop hitting your head against the wall and start understanding how the UI and functions in the program are linked and how the programs internal "logic" works, the interface becomes transparent and the usability goes through the roof.

I honestly can't model in any other program than Blender anymore because of how smooth the experience is, but that was not always the case. I spent countless hours trying to reign in the program and get it to do what I wanted because the UI was just that bad (I started with Blender 2.1, its -much- better now with 2.5).

Blender is in that really weird place where it's hard to learn, easy to use once you learned it, but even harder to master than to learn.

I feel that current game design tools are in a very similar place.