A tool is a software application used in either the construction or modification of game-related content, where the content can be virtually anything that makes up a game. Tools can be extremely simple, such as an application that removes all the tab characters from a text file, or an application that copies files from one location to another. Tools can also be quite complex, such as a full-featured world editing suite. The complexity of the tool is directly proportional to the complexity of the problem the tool is supposed to solve.
A toolset is a collection of tools that make up the content production pipeline of a game. Any tool from a toolset can be reused in multiple projects as long as the tool was designed with reusability in mind. Some tools are created for a single purpose, in which the tool cannot be reused because a lot of the tool was hard coded to reduce development time. A tool that is hard coded for a single purpose is often referred to as a throw-away or skunk works tool.
As games move toward higher expectations of the quality and quantity of content displayed, so do the tools that produce the content. Without producing exceptional tools, you cannot produce an exceptional game.
Defined as anyone who stands to gain or lose from the success or failure of an application, the stakeholders greatly affect the quality and functionality of a tool. They are the users who are most affected by the introduction of a tool, and they ultimately contribute to the design and goals. If the tool is meant only for internal use, there is typically little to no documentation, and the user interface is generally unintuitive or “messy.” If the tool is meant to ship with a game to provide modification abilities, then the tool is typically feature and user interface rich, and is accompanied with excellent documentation and tutorials.
Most tools never ship with the game, and constantly evolve as the game is developed. Many tools are developed for internal use and, if written properly, can be reused across multiple projects as well.
If the tool is designed for use by the developer only, it is typically as featureless and unintuitive as possible. The code is usually horrible to navigate, and maintainability is almost impossible. Since tools are generally designed to produce content for the game itself, far less time is spent developing good tools. There is a fine balance between wasting too much time and resources on the tools for a game, and not spending enough time making tools that are actually worthwhile. Ideally, you would want to build the tools as quickly as possible, but with a reasonable level of quality. This is where improvements to development workflow and component reusability play a large part in the success of a tool and the developers behind it.
If the common components of your tools have a loosely coupled design and solid modularity, then more time can be spent making better tools because you do not have to keep redeveloping common functionality duplicated across different projects.
To describe an example later detailed in this book, imagine that you have three batch file processing tools that each process files differently, yet share the same logic behind traversing the directory structure and selecting target files using pattern matching. If you hard code three tools as quickly as possible, you end up debugging the common functionality three times, individually debugging the logic each tool performs, and limiting yourself in terms of future improvements and maintainability.
Now, if that core functionality were separated into a reusable library and extra time spent ensuring that the code was stable and generically configurable, all three tools could interface with the library and debugging time would be minimized to just the tool logic itself. The result is a better tool, and one change to the base framework propagates to all three tools. This common functionality could now be used for any batch file processing tool needed in the future, drastically reducing development and debugging time.
The time saved thanks to reusability can allow you to build more tools of decent quality, or the time can be spent improving the user interface or accompanying documentation so that the stakeholders have an easier time understanding and using the tool.
Well written and fairly bug-free tools can make everyone’s life easier on the development team, whereas poorly documented or written tools can hamper development or even jeopardize the success of the project.
There are five main models a game development studio can be classified into in regards to the creation and support of tools. Keep in mind that the models described are generalizations, and some studios can use a hybrid of multiple models. The different organizational models for tools development are shown in Table 1.1.
Table 1.1. Organizational Models of Tools Development
Organizational Model | Description |
|---|---|
Dedicated Tools Team | This model is based around a team that takes a tool from inception all the way to supporting it. This model works extremely well, though it generally requires a liaison with both technical and design skills to help facilitate effective communication between the tools team and the target audience when discussing features and workflow using the tool. |
| A strong example of a game development studio following this model is BioWare Corp. |
Developer Ownership | “You build it, you support it.” |
| This model is where the individual or team responsible for a particular game system is in charge of creating and supporting the tools that interact with it. This model works reasonably well since the developers creating the tools are the most knowledgeable about how the game system works. |
| There are some issues with this method; the team does not generally put a lot of care into the accompanying tools, so the usability, documentation, and user interface typically suffer as a result. An example of a game development studio that successfully uses this model is Raven Software. |
| Tools are sometimes developed by one individual or group, and later end up being supported by another individual or group. |
Game Team Develops; Tools Team Supports | This model attempts to solve the issues with the developer ownership model by still having the game team build the tools. But when the tool matures, it is handed off to a dedicated tools team where it is updated and supported for future projects and use. |
| A game development studio that successfully uses this model is Microsoft Game Studios. |
Engine Team Develops; Game Team Supports | This model is similar to “Game Team Develops, Tools Team Supports,” except the engine team builds the tools to work with the core engine technology, and then the tool is passed off to the game team. They adapt the tool to work with their own project-specific data and content requirements. |
| A game development studio that successfully uses this model is High Voltage Software. |
Content Team Develops and Supports | This model is typically used in specific situations where the content creators wish to build tools to help them be more productive or test logic through the creation of rules simulators, for example. |
| BioWare has successfully used this model for certain situations. |
Third-party middleware could be thought of as a model, but it is felt that middleware can fit into one of the above models when used. Middleware sometimes requires enhancements or customizations, and someone within the game development studio has to do them.
Often the structure of the tools department in a studio is largely determined by available financing. Some studios may feel it more desirable to have a dedicated tools team, but budget constraints can force a studio into using a less desirable model.
Every studio manages its tools development differently, but generally any studio will fit into one of the above categories. One of the biggest differences between studios is the size of the tools development team.
At Game Developers Conference 2005, 16 professional game developers were surveyed on the ratio between the number of tool programmers and game programmers in their company. The results from the survey are listed in Table 1.2.
Table 1.2. Ratio of Tool Programmers to Game Programmers
% Tools | % Game | # Studios |
|---|---|---|
20 | 80 | 1 |
30 | 70 | 5 |
40 | 60 | 2 |
50 | 50 | 2 |
* Six developers did not know the ratio used in their company or did not wish to discuss it. | ||
The results indicate that currently only a third of the programmers in most game development studios are involved with the production of tools.
This ratio has fairly little to do with the actual performance of the above teams, though, as different ratios work for different companies. When it comes down to it, if the company has put out great games, they must be doing something right! It is interesting to see how much variation there is between companies regarding the structure of their tools programming department.
This chapter covered defining what a tool and toolset is, and how the gaming industry views tools development. There is currently a lot of variation in how tools teams are structured in the industry, and it is unlikely that this will ever become consistent and uniform. Different structures and techniques work differently for various companies, and they will continue to use whatever approach works for them. However, we can believe that studios will need to standardize how tools are designed and developed in order to adapt for the next generation games driven by a multitude of content.
No single technology or programming language is better than another, as each has a shining role to play in different problem domains. However, it is our firm belief that the .NET platform is best suited for tools development, and migrating to managed code will bring a number of benefits to a development studio and its projects.
Next-generation games will require more and higher-quality content. The only foreseeable way to adapt to this need is to produce better tools that create content at both a higher volume and quality in a shorter amount of time. It is absolutely vital that tools be available to designers earlier, and with very few bugs. Additionally, the tools should also have user interfaces that are intuitive to designers, and require as few clicks as possible to perform common tasks.
Reusability is also tremendously important, so that technology may be reused across multiple projects, saving additional time and money. The .NET platform is geared towards componential architectures and distributed software reusability, making it an excellent choice in this regard.
The .NET platform even offers improvements to software deployment. One common problem plaguing deployment managers is the issue of “DLL Hell,” where an older version of a library can be referenced on a system that has multiple versions installed, generally causing software instability. .NET assemblies support a built-in versioning system that solves the issue of incorrect library referencing, reducing many problems related to deployment. The .NET platform is covered in greater detail in the next chapter.