VinegaBlog

Special Note: This was a series that I started a while back. I’ve moved it under the blog for consistency’s sake. I’ll be adding to it in the future. Click on VinegaBlog above to get to the main blog.

Everyone who’s been in the game business long enough has had to deal with Bad Tools — buggy, poorly documented, ill-conceived, or just plain useless. But that’s not what I’m going to talk about here. Instead I’m going to discuss an even more insidious problem: Potentially Good or Well Meaning tools that, for one reason or another, derail, disappoint their parents, and take up with a shiftless drugged-out saxophonist. Of course wayward tools can happen in any discipline, but this series will be devoted to design and in particular level designers and builders as these are the folks most likely to deal with proprietary, home-grown and therefore potentially southbound tools. The reasons that good tools go bad are legion but I’ll be limiting this to the ones that top my own personal list. Even so it’s a loooooong list so I’ll be adding material for some to come. So without further ado:

 WHEN…GOOD…TOOLS…GO…BAD!

#1: If you Build it for Idiots, They Will Come.
Have you ever had to deal with a tool that almost anyone could use, but no one wanted to? One of those designed so that any idiot could use it? One with any real power or functionality throttled out of it or buried so deep that even a badger with an overactive thyroid couldn’t dig it out? Then you’ve probably been a victim of the “any idiot can be a designer” school of tool design.

To begin with let me clear something up. I’m not talking about idiot proofing here. I’m all in favor of you protecting me from smashing my own thumb with the hammer.  What I’m talking about here is a desire to make tools that can be used to take someone with minimal, or even no design experience and allow them to do the things a designer does. Note that I specifically didn’t say, “allow them to become a designer”. Because there’s no guarantee that being able to use the tool will make them a designer.

Part of this is driven by just how difficult it is to find a good level designer. It requires a melding of several skills: the talent to design a fun and challenging level, the ability to build it and make it look and play well, and the knowledge to script it so that it flows, reacts, engages and rewards the player. In addition the advent of 3d environments has raised the bar, requiring skills with tools such as Maya or 3Dmax which are aimed primarily at artists. Even tools specifically aimed at level design frequently bear more than a passing resemblance to those 3D art tools and require many of the same sensibilities. Finding all of these talents in a single person is no trivial task and indeed many teams spread these abilities across two or more people who work as a team. However, there is also a tendency to try and shoehorn these skills into a single person with little or no prior design experience. And to compensate for this they design tools that work well for non-designers, but are an anathema to anyone with real talent.

This usually shows up in the scripting tools as this is the skill set that can be the most time consuming and difficult to pick up. What you usually end up with is a point and click tool that simplifies the scripting process at the cost of power, utility, and efficiency - a sort of one-size-fits-all affair that indeed makes things easier for the uninitiated, but rapidly turns into an albatross around the necks of any experienced or even intermediate level designer.  Please note that I’m not talking about streamlining or automating common tasks. Nor am I denigrating control systems that use a different approach than scripting. What I’m really railing against is the dumbing down of a tool to the point that it becomes an impediment to efficient and advanced design.

In general this sort of tool is not designed by an experienced designer. Sometimes a designer isn’t even involved in the process (scary but true). As a result the hidden costs of using such a tool are rarely realized until it is too late to do anything about it:

· Advanced functionality will have to be developed by the programming team, rather than being scripted by the designers. This will cost programming bandwidth and resources, as well as the usual attendant inefficiencies involved in one group developing for another. This will also result in delays on the design side as the designers wait for the programmers to provide the functionality.
· The best and most proficient designers will actually be slowed down and limited by the tool. In some cases this can delay or limit a team’s ability to react in time-critical situations. In the worst case scenario it can cost you a deadline or a ship date.
· Dealing with the tool leads to frustration. This exacerbates the pressures always present in such projects and contributes to the loss of designers (usually the best ones).
· The limited flexibility of the tools precludes many design solutions and can severely limit the ability of the designers to tune and adapt to changing requirements.

And last but not least: You’ll end up with exactly the people the tool was aimed at — poor, inexperienced or non-designers — designing your game. Now these people aren’t necessarily “idiots” as I flippantly described them above and some of might turn out to be quite good, but that’s the exception rather than the rule.

Sometimes the compulsion to build such a tool comes from a legitimate concern, such as a desire to reduce the learning curve or make the tools more accessible to new designers or other developers who have to share the tools. But the answer isn’t to develop to the least common denominator.

So here’s a plea to all of the folks that make the decisions that result in such tools: Save us all a lot of trouble and create tools that do not limit the power or flexibility of your design team. Then create utilities layered on top of those tools, that simplify or make the tools more accessible to new designers or non-designers who might have to use them. Trust me, the last thing you want is a cornfield full of idiots…

Next: Deeply Nested Interfaces are for the Birds…

© 2005 Daniel C. Carver