At one company I worked for, we wrote our level design tool, as well as a cinematic tool on top of Maya.  The idea was that Maya already had an interface for drawing 3D objects and moving them around in the scene using well known controls.  Unfortunately, the design staff, many of which never used Maya, didn’t really get any benefit from a tool that was well understood by 3D artists. 

With the number of interface elements visible in Maya, to a designer or even a programmer, it can seem overly complex and cluttered.  Add to that the fact that we added additional interface for the design tool itself, and you’ve got something completely unwieldy for the Maya novice.

In addition, as levels became more complex, load times in the tool became longer and longer, and the responsiveness when doing the simplest operations became slower and slower.  In order for the tool to be usable, everything except what you were interacting with had to be turned off, the management of which became another task that slowed down the users.  One programmer on the game team actually refused to ever open the tool, so when testing of a feature or fixing a design bug was required, he’d get someone else to do it for him.

I’ve been in other situations where building a level design tool inside of an art package was a consideration.  In those cases, it’s often recommended as a stop-gap solution.  The argument goes that getting something up and running in an interface that is well known and already supports certain features will be quicker than writing the tool from scratch.  Saving time is usually the best policy, but thinking that time will actually be saved by this method is a fallacy, and stop-gap solutions often become permanent ones.

Time saved on initial development of a 3D viewport with picking and move controls is wasted figuring out how to cram every new feature required by the design team into a limited interface.  The designers’ time is wasted navigating an overly complex tool with buttons and menu options they will never use, nor understand. 

In this situation, we eventually learned our lesson.  The next level design tool was a stand-alone program, but that was for the next project…

Two of the most important concepts in software engineering are abstraction and modularity.  Abstraction allows us to categorize problems and write general code to handle all problems within a group, while modularity allows us to combine disparate abstract components to create unique solutions for a particular problem.  These two concepts give us the ability to write elegant, yet powerful systems that can solve many problems at once.

These systems often rely heavily on data, which is the glue that holds the abstract techniques together.  Data is used to configure which components plug into one another and how they behave. 

As programmers, it makes a lot of sense to us to expose the raw data in the tool to the people responsible for making something useful with it.  After all, not only is this the easiest implementation, it’s also difficult to see another implementation that would not constrict the end user’s ability to get the full benefit of the system’s power.

If the tool was in our own hands, or even in the hands of another programmer, this would all be true.  Unfortunately, this is usually not the case.  The end users have to figure our very clever system out for themselves, often with no knowledge of our intention, the underlying data structures, or even basic software engineering or programming concepts.

Instead of empowering the end users with our uber-system that can handle any problem, we’ve saddled them with a system so intricate and burdensome, that they can’t wrap their minds around it, let alone do anything useful with it.

Training can help to a degree, but that turns into one-on-one training with every user for any one person to understand.  Documentation also helps, but often ignored, in reading as well as in writing/updating.  Usually, one person ends up being the expert that everyone relies on, but when only one person can use a tool, you know that it’s doomed to failure.

The answer is simple, yet hard to swallow.  The tool interface can not be designed around the data structures used by the underlying system.  The tool must be designed around the users, and the very specific things they want to do with it. 

That will probably handle about 90% of the problems the system was designed to solve.  Most users will get along happily with that, and even find their own clever ways of getting some of the additional 10%.  They’ll be much happier with a tool that is easy to use than one that is all-powerful.

While at GDC this year, the idea of usability came up at the Tools Round Table.  Now, I’m pretty sure John had included the topic at the round table, in part because he had gotten a very early preview (and several revisions) of my article before it went up on Gamasutra.  I appreciated the effort on his part, but I was a little surprised at the total lack of response from the group.  When asked who was using what techniques for usability, the room was completely silent.  I expected that if anyone in the industry was doing anything at all with usability, surely this was the group.

Although it was a bit disheartening, it illuminated a real issue in game development that most of us have known in our hearts for quite a while.  Very few people are serious about making game development tools accessible to their users.  Artists, designers and even programmers spend a great deal of time dealing with tool issues for the length of every new project.  The tools developers wonder why they have so much trouble, without ever realizing that there are techniques in existence that could answer that very question and could help them make better tools that got fewer complaints and more work done.

I recommend every tool developer out there take a look at these resources:

The Usability Professionals’ Association website

 Jeff Sauro’s Measuring Usability website

Also, read Alan Cooper’s excellent books on usability:

About Face 

and

The Inmates Are Running the Asylum

So, how do we get tools into the developer’s hands as quickly and cheaply as possible, while still delivering high quality software?  Well, if you’ve heard of the quality-speed-cost triangle, you know that if you have to have high quality, and you need it fast, then it’s going to be expensive.  Most game companies choose cheap, fast and low quality when it comes to tools, but I believe we can wrangle the schedule a bit to get pretty fast, pretty cheap and very high quality.  Unfortunately, it takes a great deal of upfront planning to get there – something game developers aren’t very inclined to do.

First of all, schedule in design.  At least 25% of your total time should be devoted to designing the tool.  If you have a week, schedule an entire day (or two).  If you have a month, schedule a week.  If it’s a large project with a GUI, include a mock-up of the the UI.  The design should also include a list of features for each of the other milestones in as much detail as possible as well as goals for each one.  These go beyond features to explain what all the features are meant to achieve.  A milestone should meet these goals, and not just the features, to be considered complete.

After the design is finished, the next major milestone (there may be smaller milestones in-between) comes halfway through the development process and is what I’m calling the “first usable version”.  This is similar to the “vertical slice” almost every game has to go through these days, and includes core functionality only.  The goal is to deliver a tool that the developers can use to get their work done, and isn’t meant to be pretty or user-friendly.  Subsequent milestones will add usability features to the tool.  It take a great deal of planning to pull this off without creating work that will get thrown away later, which should be carefully considered in the design phase.

The alpha and beta milestones deliver the final promises on quality.  It’s useful to sit with the representative users and get feedback on remaining issues. Formal usability studies can be performed if time permits and those problems addressed.  The final deliverable should include documentation on using the tool, something that has been sorely lacking in the game industry.  Too many times, frustrated users turn to the developers for help on common problems which could be easily documented, saving everyone a great deal of time.  Tutorials are also important, as they can give users a chance to see how the developers intended the tools to be used. 

 As you can see, we’re able to extended the speed side of the triangle to reduce cost and improve quality, and add a stop-gap in the middle to get users up and running quickly and cheaply.  When these components are included in the schedule, then we are not only able to get something to the users in a timely fashion, but we can also (eventually) deliver something of high quality, as long as management doesn’t see the first usable version as finished.  They must be informed that the first usable is something to build on, and not at all final, and that increasing the usability of the tool beyond basic functionality will improve the development process greatly.

Of course, this is just one aspect of scheduling tools, but any more detail would too long for this blog.  Maybe we’ll talk about the other issues in an upcoming post, or you could leave a comment describing your own process.

This is the level editor I’m using for a roguelike game I’m building for my Meggy Jr. The level is just a 16×16 bitmap array. Each cell of the array is a different color, and each color is a different object. 6 is blue, and it’s a wall; 5 is purple, and it’s a door.

A level editor in Excel

I built this level editor in Excel. I set the cells to be 20×20 pixels, big enough for me to work with conveniently, and I used conditional formatting to map the background fill colors to correspond to the Meggy Jr’s color mapping. If you look to the right, you’ll see that I’m using CONCATENATE statements to pull together the numbers into the bracketed statements that I literally just copy and paste into my array declaration in code. With this system I can make a level in a minute, and drop it into my code with a couple of mouse clicks. It only took me five minutes to build this level editor.

I’m always pulling crap like this: I love using Excel to abstract things out and then generate code for me. I would never do it for a big project, but for my own hacking it saves me a ton of time.

1. Design as you go
All too often, game companies are in too much of a hurry to allow proper upfront design of tools.  As a result, programmers end up designing the tools, anyway.  Unfortunately, since they have to continually show progress, the tools are designed as they are coded, which doesn’t really save any time at all, and leads to a host of problems.  As tool development gains inertia, the earlier code becomes more and more difficult to change without breaking the entire system.  When given a choice between rewriting code  and creating a workaround, the least expensive of the two (in the short run) is generally preferred.  Major changes to support new features or a more desirable workflow become more and more difficult as the code becomes too brittle to support it’s own weight.

2. The system model of design
When programmers design interfaces, they tend to expose the underlying data structures directly.  That is the most logical method for someone who understands the inner workings of the system, and often gives the most flexibility the the users.  The end user, however, has a different view of the system based on his his own goals.  He doesn’t need to know the underlying implementation details, just the end result. The system model can give the desired effect, but may seem overly complicated or downright illogical to the user.

3. Leveraging the wrong technology
A lot of us, especially with engineering backgrounds, cringe at the thought of “reinventing the wheel.” Recreating something that already exists somewhere else goes against everything we’ve learned, but taking a tool designed for one thing and turning it into something it was never destined to be, will cost more time in the long run than just writing a new tool from scratch.  Often, the remains of the old tool clutter the interface or drag down the performance.

4. Complicating the interface
“The simpler, the better,” should be every tool designer’s motto.  The more interface the user has to deal with, the more difficult it is to use the tool. Focusing on the goals of the end user, should make apparent what interface items should be readily available, and which should be hidden away in a menu somewhere.  The most common operations should be the most accessible and easiest to use.

5. Extraneous features
Often, the tool designers aren’t communicating with the tool users, which always leads to a handful of features that just aren’t used.  They probably seemed really important during design (at least in the programmer’s mind), but time constraints or misunderstanding on the part of the users keep them from fully utilizing these features.  The time wasted on such things should have been used to improve the most commonly used functionality.  Instead, they clutter the interface or add additional steps to a process that should have been much simpler.

6. Designing for advanced users
Let’s face it, there are some people in your company that are more technically skilled than others, and I’m not talking about programmers.  Often, the more technical designers (the ones with scripting or programming backgrounds) are the ones who are able to use the internally developed tools more effectively, leaving the rest of the design staff to struggle.  This is also true of other disciplines, but design has it the worst, in most cases.  Game development tools should target the average user, with advanced functionality neatly tucked away where the more technically savvy users can find it, if necessary, while the more common functionality should be out in plain sight, easily accessible and understandable.

All of these issues lead to one overarching problem — low usability.  Tools that are unusable, do little good to anyone, and higher usability leads to happier and more productive employees.  Every minute that an employee spends fighting with the tools is a minute that could have been spent making a better, more polished game, something every game company struggles to achieve, and addressing problems like the ones above will help tremendously.  I’ll talk more about these and other issues more in-depth in future blog posts.