Discussion topic

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 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, since they understand how the system works. The end user has a different view of the system is based on his own goals. He doesn't need to know the underlying implementation details, just the result. The system model can give the desired effect, but may seem illogical to the user, making the tool difficult to understand.

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.

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 the tool will be to use. 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.

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, but wasted time spent on these features should have been used to improve the commonly used functionality. They just end up cluttering the interface or adding 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, by 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.

I think something that every game developer comes to grips with when developing tools and game code is dealing with design problems in C++ STL. The C++ standard library has some really nice features (stream-based i/o, map, algorithm), but its lacking some features that are deal-breakers for use in modern game technology:

* The allocator API design cannot support instanced allocators (allocators cannot be specified at object construction time)
* It impossible to use relocatable blocks of memory (due to internal pointer storage within the STL classes)
* Some aspects of STL make debugging hard (examining set and map contents using expressions or watch windows)

Does anyone know of an open source project that addresses any of these shortcomings? I for one would love to see an alternative standard library that addresses these issues well.

Some more thoughts after the jump.

An interesting discussion was happening at ChaosEngine regarding middleware - what general criteria do folks look at when evaluating whether a particular middleware meets their needs or not? Thoughts?

Aaron Walker and Raquel are kicking off a whitepaper. Let's help out!

XNA Game Studio Express 1.0 was released on December 11, 2006. XNA is a great way for hobbyists to create high-quality games with faster turnaround times. XNA puts the power of a large code framework at your fingertips at a fairly low cost. You can even publish your game for Xbox 360 if you join the Creators Club (membership is $99 a year).

Check out the wikipedia page for uber-amounts of information about the tool (including links to video tutorials) and the offical XNA blog for news related to the tool.

Also on the same date, Garage Games released a version of its Torque engine that has been ported to the XNA framework titled Torque X. Torque X is a 2D and 3D game engine that has a multitude of features built-in right out of the box. This is a great tool particularly in academia, where students/hobbyists may want to start a game curriculum but don't necessarily have the funds to plunge into expensive engines and tools.

Thanks to Jay Koottarappallil for keeping an eye on some recent trends in tools development! Here are some innovative tools that have caught his attention.

Intuitive Modeling

Ever since the popularity rise we’ve seen out of Z-Brush, we’re starting to see more and more of a trend towards surfacing through camera placement, gestures, simple curve editing and scene analysis (not to mention the glut of hi-resolution modelers that have hit the streets). A few products catch my eye here:

Google Sketchup
A simple concept modeler with CAD level accuracy and a very smart surfacing method based on the users placement of points in space. A lot of devs are using SketchUp to rough out levels due to its ease of use and cross-platform interoperability.

(Edit: See the SketchUp page on game development here, and review of an attempt to get SketchUp models into SecondLife).

Moment of Inspiration
Works in a similar fashion to SketchUp, but more tools geared towards organic shapes. Also a heavy emphasis on pen/tablet workflow.

Free Design FreeDimension
FreeDimension is a product that makes NURBS modeling much more accessible and practical for games application. Similar to T-Splines (http://www.tsplines.com), FreeD uses N-Sided Surfacing, which allows the user to break free from the quad patch requirement of NURBS.

CB Model Pro
This modeler works through the concept of “sticky” surfaces. There are a few basic modifiers, but where CB Model Pro gets interesting is in its use of spline drawing that sticks to the surface and allows the user to modify the surface through the spline shape.

NaturalMotion Endorphin 2.7

NaturalMotion has updated it’s behavioral animation tool, Endorphin to 2.7. I’ve had great success using this tool and Euphoria and Morphine are equally impressive.