A challenge that is arguably sharpest when it comes to game development is the constantly shifting, advancing, growing nature of computer hardware and the software that we use to bend it to our creative will. There is no doubt that the tools of our trade directly influence both the quality of our output and the quality of the path we take toward delivering it. A good tool can mean the difference between consecutive late nights of problem tracking and a dinner at home with the family.
The Big Tools
When asked about tools used in their daily development lives, most developers turn immediately toward the Big Tools – major pieces of convoluted software that occupy the majority of their thought and, often, frustration. Graphics programming protocols, 3-D modeling software, massive middleware engines designed to solve All Our Problems. Maybe the tool is commonly accepted to be the best of its kind; maybe the platform we’re developing for demands it; maybe our studio cut a deal with the tool provider and it’s what we’ve got for the next five years, like it or not.
In order to focus the discussion away from these large, labyrinthine tools that have plenty of their own discussion groups, this column will address tools that impact the deepest ‘slice’ of developers – tools used to organize development on a daily basis, across all disciplines.
Whether for management or simple asset organization, production tools are simultaneously the most widely-impacting of all development tools – everyone uses them at some point in the process – and the most frequently resented. Something in the mindset of a person trained or interested in management loves a new tool, and switching tools mid-project in order to stay ahead of technology or harness some new development power is not uncommon. Precisely because top-level production tools impact across all disciplines, the pain of their implementation is often shared and amplified. Some, like Microsoft Project, seem to have such a high learning curve as to make their implementation a full and cumbersome endeavor all on its own.
It wasn’t long ago that the concept of version control itself was a repulsive idea to developers; for some that revulsion persists today. As projects grew larger, version control became increasingly critical, costing hundreds of hours if underutilized or used improperly. Proper use of this simple but powerful tool – whether an open source variant like TortoiseSVN or the much more expensive Perforce – saves amazing amounts of development time and energy. These days, most software developers take its use as a matter of course, but as with most tools, a little extra education in its advanced use can go a long way.
Bug-tracking tools also fall under the category of production tools and are perhaps, after version control, the most widely-used and important tools in the development process. A good piece of bug-tracking software, properly configured, becomes invisible but critical; flawed or obtuse bug-tracking software can act like barbed wire coiled around the center of a project. Bugzilla, a popular open source bug-tracking solution, is a beginning to an answer; it is so flexible and open-ended that, when used in different ways or configured differently, it can practically become a hundred different tools on its own – for good and for ill.
What most of these tools have in common is the flexibility and adaptability of their use. Teams that retain high energy and a positive outlook on their project often share an opportunistic attitude toward their tools, making as creative a use of the methods of their production as their desired final product.
One of the most neglected areas of tools use and development is also one of the most intensely utilized. Communication tools not only speed (or slow) development, they play a role in defining company culture. The use or prohibition of open Instant Messaging services is one of the many questions a studio must answer when deciding whether to go internet-free in the office.
IM services seem to be the rule in most studios, though they have their variations; some studios use proprietary instant messenger tools on local intranets only, while others use open nets but make specific “work” IM accounts and separate them from personal IM use. In either case, IM tools are the tip of the iceberg when it comes to potential communication tools.
Many studios use a system of daily reports to monitor and organize individual development and production. For some, this is as simple as saving a daily report to a text file that is checked in to a production folder on the project server or source control. Some use email. Some even use proprietary reporting software, or functions integrated with a larger project management tool.
What I have not seen, and remain curious to the possibility of, is the use of existing communication tools in an office setting. One of the objectives of the allegedly game-like Darkstar Project is Sun’s intention to create a terrifyingly comprehensive and amazing virtual office tool. With increasing numbers of teams bringing on contractors or remote full-time employees, tools like this, as well as other existing virtual production software like Adobe’s Breeze, are becoming more prevalent, and more important.
Darkstar is a large and weighty example of a simpler principle: taking a tool used outside the workplace and bending it to a use in office communication. We do this with instant messaging, but rarely with anything else. Could blogging software be used as a reporting tool? Some studios do use blogs internally, but I would be interested in the potential of a community blogging software like LiveJournal for shared reporting. LiveJournal’s community features could be used to organize reports based on project for multi-project studios, or to track development archives long after a project’s completion. Using the ‘friends’ list of a system like LiveJournal could allow a production coordinator to instantaneously view the daily reports of a team, organized by date.
Ultimately, the differentiating factors that separate game development from other forms of software development demand custom tools. The IGDA Tools SIG, started in 2006, exists primarily to discuss these developments, with the eventual goal of compiling lists of tools in a user-friendly Wiki (yet another transformative tool – this column could be a book). Such a resource would be a valuable industry meta-tool, particularly if it could be used to organize feedback on the use of various tools from studios across the world.
Increasingly, individual studios are noticing that the use of a separate Tools Programmer greatly enhances the productivity of their developers across the board. Tools Programmers are a relatively new development in mainstream game dev, indicative of a further maturing of the industry and streamlining of process.
It doesn’t take a Tools Programmer to think of innovative ways to improve process, however. When we become fully invested not just in what we create but how we create it, we enjoy our jobs more, we feel more empowered about our careers – and we make better games. While we tend to think of development tools as limited to the specific hardware and software specifically designed for fulfilling our specialized development roles, considering outside-the-box tools as a way of potentially streamlining our daily tasks can improve production and quality of life on a comprehensive level. We should also be focusing on tools that help us organize and communicate, as well as code and create art.
If you have a Tools Programmer, give them a hug! Then tell them how you could be minimizing repetitive tasks with a nice new tool.