With AltDevConf around the corner, we are all busy with preparations to make sure it becomes a success. I would like to announce Mike Acton‘s talk titled “Game Tools as a WebApp: Lessons from Insomniac’s Next-Gen Tools and Engine”.
Mike’s talk addresses a tools design framework, that might make a couple of challenges easier in game production. With team sizes > 1000 people in AAA development, many team members might not be onsite or just work from the other end of the world. In those cases, distributing workload easily is an important feature.
It also helps that building game tools as WebApps makes them easier to approach, so that people can be trained faster than with proprietary tools.
From the programming side, it forces a wall between your game code and your editor code that might lead to a cleaner engine design. In other words it cleanly separates the UI from the underlying model & engine tech.
To use Mike’s own words from his proposal:
Insomniac, like many developers, has traditionally treated development tools as a second-class development effort. While we have had dedicated Tools programmers for many years, very little effort was put into the overall user experience and runtime performance was always valued over development effort. This resulted in a systematic increase in development cost and an entire “Engine Economy” based on brute-force effort. Two years ago, we decided to tackle this problem head-on. The result is an entirely new suite of tools, written from the ground up to fundamentally change the way we work as a studio.
It was also clear that the world was changing. The explosion of web-based enterprise applications, fully-web enabled mobile devices (like the iPhone and iPad) and browser-based gaming sent a clear signal that the era of native applications living in a sandbox was over. Not just for games, but also for the tools we use to develop games. We felt this was an opportunity to make a strategic change that would position us much better and net us valuable experience for the inevitable changes to operating systems, development tools and user expectations.
This is the story of our experience so far. The first game Insomniac will ship on these tools is Overstrike. We will share our most significant choices and the costs of those choices. We will suggest alternatives where we feel that better results can still be achieved.
And we will share details of the technical architecture of the new tools suite.
Details such as:
Usability is not random. We needed first-class information to develop first-class tools. We set up a formal usability practice without a lab or additional budget using a single PC. We will also share specific, novel tools features such as our “neighbor” and “tile” mode which allowed us to increase production time on common tasks by as much as 20x.
The choice to go webapp. The initial version of the tools was not web-based. It was a native application which used Flash for the front-end. This model was not significantly improved over the traditional native model and introduced the same data complexities.
Webapp tools allowed us to not only take advantage of many available development tools, it forced a clean separation of UI and back-end data.
Client/Local-server model. One of the concerns of browser-based tools is adding latency. We largely solved this issue by running a mongoose-based web server local to each machine.
Additional details. We will also share our experience with allowing custom tools and UI development by non-tools programmers. Our take on the Flash vs. HTML5 debate. Details of integrating a native engine.
And browser and security workarounds.
We’ll share enough about how we made our tools and why so that you could begin to duplicate the process. We’ll share why we made the choices we made so that you can justify the effort and search for reasonable alternatives. And we’ll share where we went wrong so that you can avoid the same costly mistakes.