Games bound for today's marketplace require the development of software tools. Whether the tool is a simple script to search text files for art asset file names, a complex model and animation exporter, or a massive world builder, these tools help game developers get the job done quickly and efficiently. The subject of tools arises in practically every Game Developer Postmortem, falling evenly into the "What Went Right" and "What Went Wrong" categories. Our tools development process at Turbine Entertainment Software underwent a lot of change during the Asheron's Call 2: Fallen Kings product cycle. This is what we learned.

	Editing an animation on the Gurog Lord using AC2's art asset tools.

During development of the original Asheron's Call, we created tools as needed - even the world-building tools were left until the alpha timeframe. While this off-the-cuff approach to tools development allowed the engineers to spend their time creating fundamental engine features, it left the artists and content designers out in the cold, forcing them to edit many text files by hand. The process of text-file manipulation was error-prone and lengthy; Turbine resolved to do things better.

For AC2, Turbine made a conscious effort to be more tools-aware when developing its next-generation engine. The core engineering group developed tools in tandem with the graphics, client/server, animation, and physics systems. Engineers were asked to expand their object interfaces, encompassing functionality not only for the client but for the tools as well. Tools-awareness was not limited solely to the core engineering group as it was with AC1.

We had several goals in mind while planning for AC2 tools functionality: First, we did not want to lag behind the engine development. The tools would reflect the current state of the engine, allowing users to test and use features immediately. Second, because AC2 would be much larger than AC1, we needed to speed up content iteration. The ability to preview and tweak engine assets without having to reload the client after each modification was critical. Finally, we wanted to hide the complexity of the engine from our users. Interfaces to revision control, logically organized dialog boxes, and a rendering window that was identical to the client facilitated use of the tools. We found that being so closely tied to the development of the Turbine Engine greatly benefited our tools.