2004 Montréal Game Summit Report

What do Neverwinter Nights, Splinter Cell, and Prince of Persia have in common? They were all developed in Canada. The latter two right in Montréal. Some of the giants of the game industry either originate, or have large studios in Canada as well: Ubi Soft, Electronic Arts, Microïds, Softimage, and ATI among others. People might not realize it, but our friendly cousins in the North are quite influential in the games industry.

The Québec region (where Montréal is located) has some impressive statistics to boast about: over 40 companies involved in game development, and over 2000-full time employees (with the giant Ubi-Soft topping the charts with over 1000 employees alone).

Having said that, it shouldn’t come as a surprise that the first Montréal Games Summit was organized this year. It brought together some great speakers from both Canadian and US companies, and it attracted almost 600 attendees for the two days of its duration.

I attended to give a talk on agile game development, but I really enjoyed the rest of the sessions I got the chance to see. Overall, the conference had a feel of a mini-GDC, somewhat like the GDC roadtrips that they used to do years ago (what happened with those, by the way? They were great little events and had a much more personal feel to them since they brought together people local to the industry in each area).

Even though it was a quick in-and-out trip (red-eye flight in one day, late flight out the following day), I also got a chance to walk around the center of Montréal (and to practice my rusty French right away with an insistent taxi driver who spoke no English at all and wanted to know why Bush had been re-elected). Walking around Montréal, it was easy to think I was wandering around a city in France, especially in the old city section, around the Rue Saint-Paul and the Rue de la Commune. The city was really clean and walkable, and it was a real pleasure to stroll around in a chilly November morning.

The conference started with a keynote by Ray Muzyka on the organization of Bioware. I already knew a lot of what was covered from earlier presentations (and here) and articles, but it always strikes me that they really have their act together at Bioware. They clearly have some very sharp people running the business. It’s interesting that they started the company without anybody having any previous industry experience (which goes to show that previous industry experience is not always necessary, and people can bring lots of new knowledge and experience from the outside).

I was also interested to learn that they use a matrix organization internally. On one axis they have individual projects, and on the other axis they have departments. They have clearly differentiated goals between departments (dealing with career growth and long-term plans) and the projects themselves (dealing with project-specific goals). They also continue having a lot of people per team, a trend they started with Baldur’s Gate (having about 80 developers back in 1999) and that continues today with Jade Empire having over 120. Whatever they do, they keep putting out quality title after quality title, and they only have a 3% yearly turnover rate, so they are clearly doing something right!

I was pleasantly surprised to see that my talk on agile game development was completely packed. Even though it’s not in widespread usage, people are clearly very curious about agile development in the games industry. It’s also always one of the favorite topics that comes up in the software engineering roundtables at GDC. Maybe in a few years we’ll start seeing some games shipped using agile methodologies from companies other than Sammy Studios.

That same afternoon there was an extremely interesting session on the AI of Full Spectrum Warrior by Quinn Dunki. She described some of the major goals of the AI development for Full Spectrum Warrior and how they went about doing it. She stressed the important of keeping things simple and the ease of debugging. To that end, they used simple, tried and true AI methods (mostly state machines), and completely avoided messaging systems, preferring to call functions directly and being able to stop the game at any time and look at the call stack. They also had some great visual debugging tools superimposed on the game to know what was going on with the AI at runtime. They also chose to avoid dynamic memory allocation (at least in the AI systems).

I totally agree with the idea of keeping things simple, but I think that code design and architecture considerations should come before debugging benefits. If something like a messaging system improves the architecture or maintainability, then I’d rather use it and find some ways to improve debugging. Also, with heavy use of unit tests, debugging should become almost unnecessary. Still, she did present a compelling case for her argument.

One of the most interesting goals for Full Spectrum Warrior was that they wanted to have zero foot slide. If you don’t know what that means, fire up any current 3D game with characters that move around and look closely at their feet. They’ll range from slight sliding, to major skating over ice like crazy. In either case, they make human animations look obviously fake and it makes animations lose their “weight”. If you think that’s a solved problem, fire up that game again. Turn the character around, transition between a walk and a run, stop suddenly. Chances are you will see feet slide all over the place. It’s one of those problems that seems trivial until you start trying to solve it. Only then you realize how difficult it really is.

The character animation of Full Spectrum Warrior is outstanding, so even if they didn’t reach their goal of 100% no foot slide, they still managed to do great job. Here’s one scary fact she mentioned: The game had a total of about 60,000 animations (yes, that’s the correct amount of zeros). Most of us don’t even come within an order of magnitude of that. Just thinking of managing all those animations makes my head spin!

The following day I attended a session dealing with the use of Softimage in the Half Life 2 asset pipeline. I was very impressed with some of the in-game sequences they showed us when the player gets to interact with other characters in the game. They had great tools to quickly set up a scene like that and all the interactions between the characters. It was particularly interesting how they imported specific assets or parts of a level into Softimage to create unique animations tailored to fit those assets. For example, animations where characters handle some objects or run over level obstacles were all created specifically for those assets. The results were very natural-looking animations that interacted with the environment almost to perfection. One fact that absolutely amazed me: Apparently they used no version control system for the assets of Half Life 2. I hope I misunderstood that! In any case, there’s one game I can’t wait to play.

Another keynote was supposed to deal with the making of Halo 2, by Michel Bastien, one of the producers from Bungie. Unfortunately, it got watered down to being the making of the cinematic sequences in Halo 2. Frankly, there was nothing new in that. They go through the usual different phases: scripts, storyboards, blocking shots, adding animations, lighting, music, etc. That’s all pretty standard stuff. We were treated to a few minutes of Halo 2 running on the Xbox, but I suspect you had to be a Halo fan to appreciate it (I only managed to play the first one for about 20 minutes for some reason).

Finally, Mario Rodriguez, a test engineer from Microsoft, gave an interesting talk on optimizing the build system. The talk was actually a lot broader than it sounds. It dealt with issues such as how to improve build times (through precompiled headers, structuring of code, or distributed systems–a lot of which I covered in an earlier article), running build verification tests, and distributing game assets to different people and machines, which, if you have 4 or 5 GB to pass around, it can be quite time consuming. Interestingly, they moved away from using xcopy to using a custom program and they’re getting much better results (not to mention also having a lot more control).

On that note, one of the things that I want to research in the next few days is the use of Scons as a code build system. It’s written in Python (which means you extend it in Python instead of strange Make or Jam rules), it’s correct (using data CRC instead of timestamps to determine when a file has changed), and, most interestingly, uses a network cache. If that works as I think it does, it might mean that developers can cut down build times by a huge amount if they sync to code that was used by the automated build machine for a build because the object files are already available in the network. If that’s the case, I will consider very strongly making it the build backend for our future projects at Sammy Studios.

Overall, the conference was a hit. The location was great, the quality of the talks was comparable to GDC, and it really managed to put Montréal on the map from a game development perspective. It was a bit out of the way for those of us living in the West Coast, but it’s really nice to have an industry event like this that is not based in California for a change. I hope it continues growing in upcoming years and attracts even more developers from the US.