Our Properties: Gamasutra GameCareerGuide IndieGames Indie Royale GDC IGF Game Developer Magazine GAO
My Message close
Latest News
spacer View All spacer
 
February 9, 2012
 
Analyst questions validity of unusual January NPD results [2]
 
DICE 2012: Blizzard's Pearce on World Of Warcraft's launch hangover
 
DICE 2012: Insomniac's Price on Quality Of Life, ditching the 'Loser' badge
spacer
Latest Features
spacer View All spacer
 
February 9, 2012
 
arrow Principles of an Indie Game Bottom Feeder [14]
 
arrow Postmortem: CyberConnect 2's Solatorobo: Red the Hunter [1]
 
arrow Jerked Around by the Magic Circle - Clearing the Air Ten Years Later [37]
spacer
Latest Jobs
spacer View All     Post a Job     RSS spacer
 
February 9, 2012
 
Airtight Games
Art Director
 
Telltale Games
Core Technology - Senior Systems Engineer
 
High 5 Games
Technical Artist
 
XEOPlay Inc
Game Developer (Mobile)
 
Kabam
Lead Software Engineer - Flash
 
Kabam
Lead Software Engineer-Ruby
spacer
Blogs

  The 6 Reasons Your Game Development Tools Suck
by Dan Goodman on 03/02/09 05:41:00 pm   Expert Blogs   Featured Blogs
3 comments Share on Twitter Share on Facebook RSS
 
 
  Posted 03/02/09 05:41:00 pm
 

There are many reasons game development tools fail.  Perhaps not all of these apply to you, but every game studio I’ve seen has had one or more of the following problems.

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.

 
 
Comments

Winston Miller
profile image
Great read, I strongly agree with all the principles listed. Low usability is the biggest problems with many tools out today, and I feel the "system design" you mention is a huge contributer. Many designers try hard to break down the intended process into the smallest manageable pieces, but oftentimes i fear they go to far and forget about the end user. Many forget that "good" design isn't just making every possible tool available and in the right section, it means making sure that arrangement is done in such a way that provides ease and intuitive control to the user.

Mike Lopez
profile image
Very nice article. Poor tool usability and accessibility are indeed the Achilles Heel of content production for both artists and designers.

I would add that a team needs to involve the eventual tool users heavily into the tool design process and along the way the tool programmers need to periodically sit down for a few hours with those users to see how they are being used and to determine the real-world work-flow and feature access frequency. Too often we designers and artists are frustrated by tools that are ill designed and/or too generic so they might support every possible feature (whether many features will ever be needed or not), but are painful to use for the tasks we will frequently need to access many times a day. So a work-flow optimization on a task that takes 8 steps and 6 minutes to perform but is utilized 22 times a day is much more valuable than for a task that takes 37 steps and 22 minutes but is only accessed once or twice a week.

Another valuable implementation strategy is one that supports preference-controlled interface customization - say for a simple and advanced layer of the interface. This is especially true for tools that are used by multiple types of users (say mission scripters, world builders and systems/mechanics designers). Having each user be able to hide features, windows and menu items from the simple layer of interface and ideally even from the advanced layer can gain additional efficiencies in the long run and will help keep some of the tool frustrations at bay.

Michael Gehri
profile image
Great article. I this is a good guild line to follow when creating a tools set. One of the hardest things going for our project is that we are developing the tools along side developing the game. So our engineers have a harder time devoting time to the polishing the tool set. But we are also looking at this as an investment, because as time goes on, we will continue to use the same engine, while streamlining and improving the tool set. I'm looking forward to what come next :)

Thank you.


none
 
Comment:
 




 
UBM Techweb
Game Network
Game Developers Conference | GDC Europe | GDC Online | GDC China | Gamasutra | Game Developer Magazine | Game Advertising Online
Game Career Guide | Independent Games Festival | Indie Royale | IndieGames

Other UBM TechWeb Networks
Business Technology | Business Technology Events | Telecommunications & Communications Providers

Privacy Policy | Terms of Service | Contact Us | Copyright © UBM TechWeb, All Rights Reserved.