Gamasutra: The Art & Business of Making Gamesspacer
Building Better Tools For Game Design
Printer-Friendly VersionPrinter-Friendly Version
View All     RSS
April 19, 2014
arrowPress Releases
April 19, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM TechWeb sites:


 
Building Better Tools For Game Design
by Aleksander Adamkiewicz on 08/05/12 09:30:00 pm   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

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.

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

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

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.

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).

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.

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.


Related Jobs

Penny Publications, LLC
Penny Publications, LLC — Norwalk, Connecticut, United States
[04.18.14]

Game Designer
Hasbro
Hasbro — Pawtucket, Rhode Island, United States
[04.18.14]

Sr. Designer/Producer, Integrated Play
Nexon America, Inc.
Nexon America, Inc. — El Segundo , California, United States
[04.17.14]

Web Designer - Temporary - 3 month
Darkside Game Studios
Darkside Game Studios — Sunrise, Florida, United States
[04.17.14]

Mid-Senior Graphics Programmer






Comments


Ferdinand Joseph Fernandez
profile image
I don't see why you're miffed that a tool that's meant for programmers is coder-friendly. If you want visual programming, check kismet, playmaker, uscript, etc.

If you feel like Unity should change its direction, for example, you can suggest so in their feedback site feedback.unity3d.com

One thing you have to understand with these "intuitive" tools is they can end up being not optimized for the task. Once you are building something more complex, things start slowing down. Its not about reinventing the wheel, its about making a custom-built one that suits your needs at the moment. Some people don't have this as a priority, I understand, and for them, I suggest checking out the visual programming tools I mentioned.

Andrew Traviss
profile image
Most game development tools are created by developers, who see programming as the primary task of a game developer. It's currently where game developers spend the most time, but that doesn't make it the primary task. It just means that game developers spend a lot of time being distracted by coding instead of expressing the game design.

Programming is not a tool "optimized" for game development. The signal:noise ratio for game design expression with even the best languages available is pretty dismal.

Hakim Boukellif
profile image
"Expressing game design" consists mostly of describing the behaviour of game elements. Describing behaviour in such a way that a computer can execute IS programming, regardless of whether you're using code or some kind logic graph. It only makes sense that the most time is spent on the part that defines the game the most.

The problem with games is that there's no universal way how games work. You can make some assumptions about what most games need, like displaying graphics, collision detection, some kind of entity system etc. and game engines usually have solutions for that, but when it comes to describing actual behaviour, you can no longer make any assumptions unless you're only targeting a specific type of game. Sure, you can make a character walk in many games, but what that actually means in terms of behaviour can be very different depending on whether you're making a platformer, FPS or RTS.

As long as no assumptions can be made, you're going to have to be very specific when describing behaviours. And in order to do that, you're going to need the flexibility a traditional programming language has to implement any game more complex that tic-tac-toe. It's possible to make a visual tool that's just as flexible, but in that case expressing it in code is going to be more efficient and clear for anything but the most high-level of problems.

Aleksander Adamkiewicz
profile image
"The problem with games is that there's no universal way how games work. You can make some assumptions about what most games need, like displaying graphics, collision detection, some kind of entity system etc. and game engines usually have solutions for that, but when it comes to describing actual behaviour, you can no longer make any assumptions unless you're only targeting a specific type of game. Sure, you can make a character walk in many games, but what that actually means in terms of behaviour can be very different depending on whether you're making a platformer, FPS or RTS."

I would wager the guess that if we sat down and actually tried to define most used behaviors, we could actually do it. We have by now well established "gameplay genres" and control methods, it shouldn't be too hard.

Most of game behavior can be reduced to interactions between objects, i.e. checks of values against other values.

The tool doesn't need to come with everything ever needed, (thats why i'm talking about a centralized marketplace in my article) but rather provide a wide variety of behaviors that are not only common but combined would create true complexity.

Hakim Boukellif
profile image
"I would wager the guess that if we sat down and actually tried to define most used behaviors, we could actually do it. We have by now well established "gameplay genres" and control methods, it shouldn't be too hard."

I'm not sure how I feel about beginning game developers having their imagination dampened by being limited to what's common... Anyway, even when limiting to what's common and established, I think you're underestimating just how fundamentally different games can be from each other. To the point that if you managed to do this with a universal user interface and without non-trivial "behaviour descriptions" (for lack of a better term) ending up at least as complicated as the equivalent in code would be, you'd have solved not just a problem in game development, but in software development in general.

"Most of game behavior can be reduced to interactions between objects, i.e. checks of values against other values."

You don't just have to compare values to other values, you also have to react appropriately to the result. For example: "If the character's ledge-detection shape intersects with a ledge's collision shape while the character is airborne, switch the character to 'ledge-hanging' mode, in which the current animation is set to 'hanging from a ledge', most other character behaviours won't be applied and the character will stay in place until it is made to jump, climb or drop".
In that case, what's part of the behaviour "unit" and what isn't? Is the check part of the same unit (in which case, what if you want other things to trigger that behaviour?) or is the check a separate unit that triggers the other? What defines the ledge-detection shape, is it a property of the behaviour? (What if that shapes is used for other things as well?) How do you define a "ledge" when in one game, collision detection is done using tiles and in another using shapes? What behaviours should stop in "ledge-hanging" mode and what behaviours should continue?
By the time you're done configuring it to suit your needs, it'll end up being pretty complex, and that's just one small part of player character behaviour.

Aleksander Adamkiewicz
profile image
"I'm not sure how I feel about beginning game developers having their imagination dampened by being limited to what's common..."

You still are misunderstanding that im not talking -to- or -about- game DEVELOPERS but game DESIGNERS.

Especially -beginners- that want to get into video-game design.

Full-on developer tools will not go away if we start adding to the market with easier and more intuitive tools.
The same way Flame, Smoke, Inferno, Flint and Toxic don't disappear because Premiere/FinalCut and After Effects exist.

Hakim Boukellif
profile image
I don't think I excluded game designers when I said "developers"; that's why I explicitly didn't use the term "programmers" (to begin with, the distinction is usually a lot fuzzier when it comes to hobbyists). Still, does it change anything? Hammering in too much "common sense" at an early stage can do more harm than good in any field (or indeed, life itself).

Either way, the practical implications don't change. When you're designing a game, you're designing a piece of software. Perhaps not in terms of software architecture and such, but you're still defining the behaviour of a computer program. When you're expressing that design in a form that a computer can execute, no matter what form that takes, you're programming. Furthermore, the kind of logic games run on isn't specific enough that it can be divorced from software development in general, unlike say, digital music creation, that once required programming the behaviour of FM synthesizers.

Aleksander Adamkiewicz
profile image
"Either way, the practical implications don't change. When you're designing a game, you're designing a piece of software."

Thats I think where we disagree, I don't see game-design as something that has inherently a software component to it.

I can design board games or card games aplenty without ever writing a line of code.

All I'm asking is for the tools to make the same happen on a computer without hiring a programmer or learning the code-side of things.

Ferdinand Joseph Fernandez
profile image
@Andrew Traviss: you misunderstand. when I say unoptimized I mean they are not performant. the result of a high-level editor goes around unnecessary overhead for computer's processing.

programming is simply another step in the process, of course design is important.

Jeff Alexander
profile image
I wonder if the author has looked at Kodu Game Lab. Figure 5 in this article reminded me of its interface style.

Aleksander Adamkiewicz
profile image
No I didn't, it's hard to keep up with all the tools.

I will look into it, from a quick google I can see it seems close to what I'm talking about, not sure how far it goes in context of my second point though (Flexibility and Complexity).

Axel Cholewa
profile image
I haven't truly tried out Kodu (I will, though), but it surely looks promising. It also highlights part of the problem: Kudo is for Kids, and tool developers don't think such an intuitive interface is useful for "real" game development.

Evan Combs
profile image
I agree with the author. Most game creation tools are very very obtuse. Some of it is just the nature of the beast, but we are a long ways off from being able to say we have well designed tools. I don't think this is limited to just game tools either, most creative tools on the computer are not as well designed as they need to be.

Aleksander Adamkiewicz
profile image
I agree, the problem is only exacerbated in game-design because it unifies so many aspects of creative tools (visual, audio, logic, etc.) .

Adam Bishop
profile image
I feel like the comparisons to music creation programs are misleading. The hard part of audio recording isn't mixing (though a good mix can go a long way) it's *learning to play an instrument*. Similarly, the hard part of game programming is learning to code. Learning to code is analogous to learning to play guitar.

You want game-creation tools that are similar to playing with pre-recorded loops in Garage Band? Then open up the creation tools in Mod Nation Racers or Little Big Planet. Even something like the most recent version of RPG Maker provides plenty of graphics, audio, and fairly intuitive menus to work with. Those toolsets restrict the kind of functionality that you have available to you, but so too does working with pre-recorded loops. If you want to make brand new games then you probably need to learn some technical skill. If you want to make brand new music you have to do that too.

I'm working on a post myself about how non-programmery types can get into game design, hopefully I'll have it up in a day or two. I think it's actually much easier to get into game creation than you suggest here.

Aleksander Adamkiewicz
profile image
"I feel like the comparisons to music creation programs are misleading. The hard part of audio recording isn't mixing (though a good mix can go a long way) it's *learning to play an instrument*."

I'd disagree, because there is enough music out there (very good music) that doesn't necessitate learning to play an instrument at all.

I know a guy that makes amazing orchestral tracks purely from loops.

Nicholas Edwards
profile image
I haven't found anything with a fantastic set of intuitive pre-made game loops. I agree that this is a missing part of the learning curve for game development. Some editors come close.
You mention Construct not having pre-made elements, but Construct 2 has some great ones, with excellent documentation.
It's also a great way to learn to "play the instrument."
http://www.scirra.com/blog/82/a-new-way-to-learn-how-to-program

Random list of other tools:
UDK, Flixel, FlashPunk, Multimedia Fusion, GameSalad, Stencyl, ImpactJS, Alice, Ogre3D.

Aleksander Adamkiewicz
profile image
It seems I can find all elements I'm talking about dispersed through several tools in varying degrees of implementation.

Yes construct2 has some good logic premades but it lacks the visual representation of said logic (event sheet instead of directly editable visual object representation).

Blender has the visual representation but lacks the premades.

Unity has a good centralized place to search for additional functionality.

etc.

[User Banned]
profile image
This user violated Gamasutra’s Comment Guidelines and has been banned.

Nick Putnam
profile image
I agree and like the ideas expressed in this article. A game engines UI and tools should be simple and clear at first glance to understand, while also not restricting someone from dreaming up a whole new world of unique interesting experiences if they choose to dive deeper into the engine.

Very few people are an expert in all fields of game development(audio, graphics/art, programming, etc.) though each person needs to be able to look at the engine and feel comfortable with it. While a programmer may create logic for the physics of a car for instance, someone coming in thats not a programmer to change a few properties or variables to affect the drag or friction of the car may look at your code and be overwhelmed no matter how clear you are in naming variables, and structuring ur code.

Though, I feel many engines are slowly going this route to make the interface and its functionality clear, simple, flexible, and mostly easier understood by all expertise of game development. Its just a matter of time until someone comes up with the new latest engine, that is flexible and general enough for a novice to be able to create any basic game with basic functionality easliy, while also allowing the people who choose to dive deeper into it, the ability to expand and take it to new realms.

Axel Cholewa
profile image
Completely agree with you, Aleksander. An intuitive interface could save developers lots of time (spent by game designers et. al. learning to use a tool) and therefore money.

I downloaded blender just to try it out, and I couldn't even figure out how to turn the camera. In a 3D modeling software!

Aleksander Adamkiewicz
profile image
middle mouse button for orbiting the viewport.
numpad for incremental movement, "," centers on selected object, ctrl+alt+numpad 0 aligns the camera to the viewport but i personally prefer moving the camera manually.

basic shortcuts:

G - grab and move selected objects
S - scale
R - Rotate
W - special (contextual, different dropdown menus in context to mode)
E - Extrude
Tab - edit mode
MMB while moving, scaling, rotating, - constrain transformation to axis (alternatively pressing X,Y,Z during transformation does the same thing)

Blender is centered around learning keyboard shortcuts and internalizing the logic of said shortcuts, there are no easy buttons for everything like in C4D or 3DsMax.

have fun and good luck ;)

Nick Harris
profile image
I agree with your criticism. Tools are empirical and abstract, when they should be contextual and plastic. If they weren't designed by programmers for programmers, but by game designers for game designers (who knew a little supplementary coding), the situation wouldn't be so desperate. Building variations on a theme in the Halo 3 Forge will only get you so far.

However, I feel that the lack of User Centred Design in tools is merely a symptom of a general lack of rapid feedback - which is as important to the process of creation as it is to their eventual consumption. Having to wait for your tools to compile changes, breaks "flow" and hinders experimentation. Prefabricated "parts" should be able to be phased-merged into existing scenery, so the construction of an operable portcullis in a Skyrim dungeon becomes an unnecessarily finicky procedure:

http://www.youtube.com/watch?v=PN5vCtlxvwk

Something that should have taken all of ten seconds takes more than ten minutes. Yet, games are dynamic systems of interrelated feedback, so what we really need are tools that let us explore these multi-variable possibility spaces:

http://www.youtube.com/watch?v=9eCzIaBkH6M&feature=related

I personally feel that the problem is so hard that more productive designer-oriented tools require similarly designer-oriented an extensible, articulate, programming language ideally supporting concurrency elegantly. This has been my main focus, with the creation of next-generation tools having been postponed along with the game I planned to write with them. If I wasn't doing this as an entertaining hobby, my "boss" would not have indulged all of my extensive R&D, and I can well appreciate why all modern games that have shipped are built with ugly, "good enough", tools: given the choice between spending a couple of months improving the tools your team works with and doing work that will impact the next project milestone, deadlines must tend to force out investing in the production pipeline itself.

Aleksander Adamkiewicz
profile image
"Having to wait for your tools to compile changes, breaks "flow" and hinders experimentation. Prefabricated "parts" should be able to be phased-merged into existing scenery, so the construction of an operable portcullis in a Skyrim dungeon becomes an unnecessarily finicky procedure:"

Check out the Legend Of Grimrock dungeon editor. Real-time update of scripting and asset placement:

http://www.youtube.com/watch?feature=player_embedded&v=hDmF-h9dRF
8

Nick Harris
profile image
@Aleksander Adamkiewicz

The Legend of Grimrock seems to be making life easier for itself than Skyrim by having what seem to be grid-based levels. Nothing wrong in that, I'd prefer the pace of prototyping from Grimrock's toolset over Skyrim's any day. At least I would have a result before my patience had worn out!

However, Grimrock could be even simpler with the use of defaults. All locks would take Iron Keys, unless optionally specified otherwise. So, there would be no blank field that you would need to fill in. Furthermore, the action-target (or similar "parenting" in Skyrim that was so awkward), where you have to specify what the lock unlocks isn't object-oriented. You should put in the Portcullis object ("snaps" into a legal position only if there are walls on both sides), and it should have a default Lock taking a default Iron Key associated with it on its righthand wall. This would be the adjacent righthand wall, one grid square away. Again, a menu could be optionally adjusted to make this Lock appear on the adjacent lefthand wall, one (or in the case of the video: two grid-squares away). It wouldn't matter if the left wall was at a right-angle to the Portcullis and the right wall was flush, the position of the lock would always go centrally in the specified adjacent wall. This means for a map needing a common case Iron Key in a commonly placed right of door Lock there would be nothing to do beyond dropping in the door itself.

After all, all doors need locks... otherwise, why have them there?

Halo 3's Forge is rather like this. Lots of sensible defaults.

Luciano Lombardi
profile image
'Reinventing the wheel might sometimes be educational, but it gets in the way equally as often.'

I really liked that part, and I think it applies to many other areas of education

Ferdinand Joseph Fernandez
profile image
A high level game design tool that spews out a polished game out of the box is unrealistic in my opinion.

But a tool that simulates a game's mechanics is far more feasible. Check this out: http://www.gamasutra.com/view/feature/176033/the_designers_notebo
ok_.php


none
 
Comment: