22 juil. 2008
Paris GDC'08 - Conference Coverage (Frank Hauselmann)
This is a preview of a GameDev.Net article which is available here
How to Expand your Game Engine: Customization for Everyone
Frank Hauselman works at Ubisoft Quebec, and his role there is to develop a new game pipeline, which is used internally on 30 different projects. There is a good reason for this: Ubisoft is developing many different games, and many of these games are using very similar technologies. Unfortunately, not all games are using the same exact set of technologies, which makes it difficult for code reuse. To alleviate this problem, Ubisoft created a special technology unit that roughly works as a middleware provider for all Ubisoft studios.
Why is it necessary? Frank gave us an example of what could happen without a centralized engine development team. Team A sends the engine to Team B in order to allow them to develop a PS3 game. Team B modifies the engine. Team A begins to work on a new game, and gets the engine back from Team B. They now have an engine that works on XBox360 and PS3, but with different features and interfaces. Woot.
The number of teams that work at Ubisoft, the number of hardware targets to support, and the different game genres are growing fast, and this growth needs to be addressed.
First question to answer: what part of the development is the most expensive? Development of a typical game can be split into 3 phases: pre-production (technology update, SDK upgrade, tools development), game development and game debug. During pre-production, nothing really happens to the game. The ratio investment vs. added fun is 0. During development, fun is added to the game at a good rate – and as time goes on, it is more and more easy to add fun to the game. When the debug phase comes, the ratio investment vs. added fun diminishes abruptly. To summarize: there are two development phases that doesn’t add much fun to the game but still cost a lot.
You have understood this by yourself: the idea is to provide up-to-date tools to the development team so that they can add fun to the game as soon as possible, and to limit their debugging time to the minimum. But to handle that properly, the technology team must take many factors into account: the game genres, the number of possible target platforms and so on.
This is done by considering three development axis: modularity (in order to extend it easily), accessibility (the technology shall be easy to use) and working with the development community (ensure that they will use it).
Ubisoft is developing a full game solution that can be used to prototype games as well as to produce real games. Why do they call that a game solution? Because such a solution is not tied to a particular pipeline. Coupling has been extensively researched in order to allow different pipelines to be plugged in. Your game is using a very specific physics engine? No problem. They identified 4 areas where coupling must be taken into
- Game objects should be loosely coupled, in order to allow reuse.
- The different editors (the production pipeline) can be coupled a bit more, but flexibility is still very important.
- Engine shall be flexible as well – as pipelines might be removed, added or modified.
- The coupling between the game editor and the engine is less important – the engine is not likely to change, and the editor is supposed to be standard. But that doesn’t mean that this cannot happen.
Accessibility – for artist – is done by creating a bridge between the different tools. Click an object in the game editor and it will be opened into 3DS Max. A single button in the modeling package directly exports the engine into the game editor. Source control is done transparently, and without any action from the user. In fact, the user doesn’t have to know that assets are stored into a source control database – and this is a good thing, because he shouldn’t care.
A useful tool that users really like: automatic discovery of the tools that are needed to configure a property. Reflection and source code level information are used by the different tools to bind properties of game objects to specialized tools (for example, a color is bound to a color picker). This allows fast iterations for both the programmer and the artists.
Even for a programmer, accessibility is very important: if you limit learning, you can save loads of money during the pre-production phase. But that’s not the only reason. If you have a technology that is simple enough, you also reduce errors and limit context switch within the programmer’s brain.
But it’s not enough to have a good solution, because the best solution in the world isn’t worth anything without support from the target users. Ubisoft therefore created an internal community of users to support the technology. There are immediate benefits to this: team-centric NIH syndrome is avoided as teams can now share their knowledge and tricks, experts can be called to the rescue more easily, and so on. An interesting part of the community is the Feature Shop, where game programmers implement new features that are added to the game solution as some kind of plugins. Another interesting part: the demo group, whose role is to create game demos to show specific features of the Ubisoft game solution.
In the end, the creation of a specialized technology team allowed Ubisoft to create synergies between different studios all around the world. They cut their development costs and ensured they remain up-to-date with respect to the technology.