If you have the time to review this section from my forthcoming game design book, I’d appreciate it. Basically I am looking for examples of design tools; I’ve filled in the ones I remember using but I’m sure I have missed some.

Tools

To assess the types of tools you will need look at similar games, either internal to your studio or games made by other studios. If those other games shipped with tools it is easier to assess their tools (though be aware that sometimes the toolset shipping with the game are not the same tools that the developers used, or might not include all the tools). If you are still not certain of the tools used you can scour sites such as gamasutra, GDC archives, or try asking a developer specifically.

The Not-So Obvious Tools

I will start with describing software that is not generally considered game development software but does have a major effect on a designer’s productivity. Here’s an overview of how I have used various generic software in the past to assist in building games.

• Outlook This or any other advanced email program is used primarily for communication. I am a huge fan of email versus other forms of communication though for it to be effective all parties must use their email reasonably. Previous chapters detailed this more thoroughly but at a high level a strong email program should assist with improving a designer’s organizational skills, allow for vacations to be planned and communicated, and to set meetings up.
• Word This is a strong tool for writing design documents. Though I prefer a more advanced approach now (writing text in plaintext with markup and then exporting it to a variety of other formats as required) it is likely that you will be using Word, or an equivalent, to write your design documents. A later book will have more on documentation but there are a few points to keep in mind.Do not spend hours fleshing out features that have not been agreed upon at a high level. This wastes your time. Get approval before digging into the full details.

Standardize your documentation as much as possible. If all your documents look the same it is easier to train others to read them.

• Excel This is always a great tool for creating simple task lists or for a designer to break down a design document into a series of implementation steps. It can also be used for small-scale tracking of assets and bugs. If your company has a limited number of tools programmers available for custom graphing and data analysis work Excel can also be used to manipulate the data generated by your content toolset and display various graphs and other reports.
• Visio This is a great interface mock-up tool for those of us without good art skills (in fact one of my crude Visio maps was turned into a working city-map on Dragon Age: Origins long before artists had the resources to build the real map). Use it for mapping and concepting and to improve the aesthetics of otherwise bland design documents.
• Batch Files Batch files can automate a series of mundane tasks. They are worth exploring if you are often moving content from one location to another or need to convert files from one format to another.

Base Tools

These are the core design tools that I suspect most projects will utilize in some form or another.

• Area Maker This is the tool that the level artist will use to build the actual area, including geometry, texturing and other details. The more user friendly this tool is the larger the pool of potential level artists in the company. The most basic tool should allow for a designer to do a rough version of the level — just the major area contours and locations so they can begin populating the level and play testing. An artist would then go through the area later and finalize it.
• Creature Maker This tool allows the designer to build non player creatures, whether enemies, allies, or neutrals. At its simplest this might involve tweaking a creature built by art, and defining a few basic rules properties. More sophisticated tools might allow for substantial tweaking of form and function.
• Item Maker Like the creature maker but involving items that the player can find, pick up or interact with, and sometimes carry with them. These might be weapons, armor, clothing, or even plot items like keys.
• Sound There should be a method in the toolset to import existing sound and set up various parameters (these will vary based on platform and game type but general parameters might include the range of the sound, where the sound is triggered from and how the sound loops).
• Area Placement Tool Creatures, items, sounds and other objects are placed inside an area that has been made with the Area Maker. This tool should also allow for adding triggers or other devices to make actions happen when players reach particular locations within areas. It might also include subtools to facilitate day/night scheduling of NPCs, laying out walking paths, and so on.
• Scripting Language By this I mean the method in which a designer makes objects in the game do stuff. This might involve setting up a conversation, triggering a cinematic, or building a combat encounter. On projects like Dragon Age the scripting language is a light-weight programming language. On other projects a visual logic editor might be used instead. Regardless this tool should have embedded help for the designers using it and easy ways to test/debug their work.

Genre Specific Tools

A first person shooter probably does not require the same tools as a content heavy role-playing game. Each type of genre will require certain additional tools. Here are the additional tools you are likely to find in a current generation role playing game.

• Dialog editor Many story-driven RPGs require substantial dialog. Often this dialog requires multiple characters to participate in the dialog. A clean and concise dialog editor helps ensure that writers can focus on the quality of what they write rather than the technical details.
• Table Editing Not every aspect of the rule system can (or should) be made into a tool. Elements that are better represented as tables should be used as such. These might be lists of abilities or creature rankings or random encounter lists. However it can be beneficial to have these tables available (at least for viewing) inside the designer tools. Be cautious about allowing editing though… Excel is a better tool for editing tables than any internally developed tool.
• Spell/ability editor Certain rule system elements like spells or special abilities might require an editor or a scripting language hook of some kind and hence be editable in the toolset. If using a custom tool try to be clear on what the implemented ability will do in-game and where possible give hints (i.e., if damage scales depending on various factors give the designer some sliders so they can experiment with different damage models).
• Cinematics If your game will require a lot of cinematics and/or cinematic heavy dialog consider a tool. On the Neverwinter Nights expansion packs the designers were forced to hack cutscenes using the scripting language. Not only was it difficult to create a satisfying visual using this system it was also prone to numerous errors. If a significant portion of your game is going to use cutscenes then create a tool (or incorporate a third party tool). It will reduce cost and result in higher quality cutscenes.

Testing Tools

There are a handful of testing tools that may be worth considering. These are not necessarily tools used only by the quality assurance department but instead are tools that are useful for any team member who needs to test content in the game.
The primary tool to consider is a bug tracking tool.

• Want bug reports? A cumbersome interface will disincline testers from reporting bugs. If there are too many fields to fill in or if the tool is slow testers will only report the important bugs. Your bug reporting tool should make bug reporting fast and easy.
• Visibility All users should easily be able to see the bugs that they have submitted. This assists them in keeping track of which issues they should be harassing somebody about — you want to avoid bugs sitting around and atrophying. A tool that helps bug senders to be vigilant in following up improves overall project efficiency. Also this helps users from filing the same bug over and over!
• Auto-populate fields When possible auto populate fields such as release version, platform, time and day, current area the player is. Also fill in as much details about the player’s in-game status as feasible such as the random seed used to generate numbers and so on. The less the tester has to manually type the more time they will spend detailing the actual events leading up to the bug.
• Dialog If you have sophisticated dialog chaining, you need a method to output the most recent dialog so that it can be copy/pasted into bug reports. For spelling/grammar and localization errors exact text makes fixing the bugs faster.
• Reports There should be methods in which reports of open/closed bugs can easily be generated though I would caution about going overboard here. What you want to use is an open database of some sort to track your bugs. Then it becomes an easy matter later, if necessary, to hire a competent database programmer to build the various data views that managers and quality assurance require. Never choose a bug tool that makes the process of entering bugs difficult simply because it offers attractive looking reports. Reports are easy to make later.