This talk was given by Lesley Mathieson from High Impact Games, a 10 year veteran of the games industry who had worked on past titles, including Ratchet & Clank for Insomniac Games and with other companies like Microprose, Ubisoft, INterplay and 7th Level. Her official title is Design Director, which would naturally lead one to the question of "what's she doing talking about the game's production process?" That's basically the idea behind her talk, which was the way that High IMpact structured their team for the production of these two debut titles. Specifically though, Mathieson spent the majority of the talk on Ratchet & Clank: Size Matters. The team started off with no PSP technology or tools, and did not borrow any engine or gameplay from Insomniac Games. A few assets from Insomniac were lent to the production such as Ratchet & Clank models, animations and sounds, but the vast majority of the game was built from scratch. Even still, the timeline from the start of the project to gold master was approximately 18 months. The game turned to to be largely successful, becoming one of the top-selling PSP games of 2007 and scoring an average of 85 in game reviews (based on Metacritic).
So they obviously did something right, and Mathieson was here to share what that was. The fist thing she revealed was the personnel breakdown for the project, which stood at:
1 Project Manager
3 Designers
16 Artists
15 Programmers
1 Tester (on developer side)
(sound was outsourced)
Obviously you can see here one of the main rules they instigated when forming their team, which was to minimize non-content related personnel, although she did note that you still need a minimum number of these people in order for your studio to run (the amount of non-content personnel on High Impact's team was only 10%). This includes people such as HR, Financial, IT, Producers... ahhh there it is. No Producers? How do you get away with that?
Well, High Impact had the pleasure of employing many very experienced game developers, and so they ended up with a lot of generalists, not specialists, which came up as another slide of its own in the presentation. One example of a generalist would be a lead designer who is also a planner. The upsides to generalists are many, if you can nab any:
They are good for a process where everyone is involved withe the game's creation
They are more flexible about addressing unexpected problems
Thanks to them, you will need to hire less people overall to address a wider range of issues
One of the ways they tested this "generalist" talent was asking their programmers, during the hiring process, to draw a mole. They didn't care whether what they got back actually looked like a mole or not, the only way a programmer could fail the test was to not draw the mole. Those that did, especially those that didn't hesitate, showed the leaders of High Impact that they were willing to break from their norms and work out tasks given to them they weren't used to.
Another advantage that High Impact took hold of (and that was discussed also in the N+ Postmortem) was the use of good developer tools. This mainly referenced build tools that made it easier for developers to push out a new build and run tests, but also applied to implementation tools (like level editors). If you're using tools, you have to recognize how critical they are and how your talent will only work at the speed of their tools. Even small delays in tools get exaggerated by employee frustration and wait time. The easier it is to build and test your game, the more iteration that you have and the better your game is as a result.
To keep the development process running smoothly, they insulated their technology by doing things like maintaining separate level executables so that if one level gets broken it doesn't immediately break the entire game. Their engine also handled error cases and missing data in a non-intrusive way. Furthermore, they had a strict rule against scripting to prevent spaghetti code introduced by designers. Instead, simple tools allowed the designer to move objects around or enter values like enemy damage, but anything more complex had to be implemented by a programmer. While that saddles your programmers with extra work, at the same time it opens up your designers creatively. High Impact sees creating a tool for a designer as creating a pre-set box of limitations for them to work within. To them a designer should spend more time reviewing and re-reviewing a game since no one else will do it as effectively as they can.
To help keep things on track, the team used gameplay tests as build milestones to provide intermediary deadlines. Although things will always tend to slip off track despite your best efforts, the tests helped he team see where they were amiss and how they could go about fixing the issues with the least amount of time wasted - or whether they should just drop a feature and move on entirely. These are also deadlines that your team will actually care about.
Southwest Gaming Expo
