MIGS 2009 Conference Overvew

The Montreal International Games Summit returned for it's 6th consecutive year, this time gathering 1500 developers in the Hilton Bonaventure Hotel, a few blocks southwest from the summit's traditional location at the Palais des congr?s, which is the major convention hall for Montreal. Having attended conferences in both types of locations, I have to admit that ones held in hotels generally seem to do a better job at gathering attendees together, given the fact that the majority of them are actually rooming in that hotel. Whereas a convention center may have a primary recommended hotel, the majority of people are scattered about at various hotels around the area. The Hilton Bonaventure handled the large crowd of developers very well, with plenty of room for people to sit and chat, including a nice lobby bar, and generally mill about. I wasn't ducking and dodging between people very often at all.

The sessions that I attended were all set up very well, and I especially liked how the keynotes were laid out, with three session rooms opened up to form a large ballroom and which also lent 3 seperate projector screens to display slides, so people on the far edges of the room weren't craning their necks around to see. Last year the keynotes were held adjacent to one of the Expo areas, and so a lot of noise bled between the two. Speaking of the Expo, it featured the usual suspects from around the Montreal area, but the main lack was in aesthetics. It's not a big deal, but I have noted in previous years that the lighting they would do for the Expo was always so nice - I guess that was largely the Palais des congr?s staff at work for that.

Everyone I talked to had a great time, as did I, and all the sessions I attended were very good. MIGS will be returning in early November next year.

External Coverage

I can't be everywhere at once, so while I did attend my fair share of sessions, that covers a small slice of all the conference has to offer. Here's some more from around the web.

Looking Ahead: MIGS 2009 - interview with director Alain Lachapelle
Another interview with director Alain Lachapelle
Ken Rolston (Big Huge Games) - A Narrative Designer's Toolkit
Chris Hecker (Definition Six) - Meaningfully Mass Market
Yiochi Wada (Square Enix) - Fostering Cultural Diversity in Game Development
Reid Schneider (EA Montreal) - Preaching to the Choir: Do We Make Games For Ourselves?
David Sirlin (Sirlin Games) - Every Click Counts
Randy Van Der Vlag (Big Blue Bubble) - Big Worlds on Small Screens
Jason Holtman (Valve) - Games Entertainment in the Age of Connectivity
Joe Booth (EA Montreal) - You'll Never Beat Nintendo
Jon Jones - How To Love Outsourcing (slides only)
Glenn Fiedler (Sony Santa Monica) - Solving the Networked Physics Puzzle (slides only)
#migs09 twitter hash | #migs twitter hash

In additon, MIGS Advisory Committee chair Jason Dell Rocca has his own perspective on his blog.

Select Session Coverage

Here's thoughts on some of the lectures I was able to attend.

Designing Assassin's Creed 2

I'm going to augment the Gamasutra coverage of this talk, because author Chris Remo does a good job of covering the core of the lecture, but there were a couple of things that he left out. The first were the 4 specific reasons that Patrick stated in his defense of using a design document (in a proper fashion). They weren't explicitly defined.

• As you are writing things down, you are forced to face them right away and answer any questions that may arise - this was mentioned in the Gamasutra coverage
• If you keep proper notes, and don't simply delete and rewrite sections of the design document (bad idea) then you will have a running log of your design decisions from start to finish. How bad a position do you think you'll be in if someone else on the team argues against a feature, and you can't even recall exactly why you wanted that feature included in the first place? Remember, AC2 had over 230 features to track.
• Having something people can reference limits the amount of time they need to stop working and ask questions. Why does this have to be done like this? Why does that object need to go there? This means they can focus on being more productive. The key to this, as mentioned in the Gamasutra coverage (really, it's required reading for this), is creating the documentation in a form that is acceptable to the end-users. PowerPoint presentations and huge design bibles are out of the question.
• As with any project, failing earlier is cheaper than failing later. To fail in design is cheaper than failing in production. However your design has to be created deep enough so that you can even recognize possible failures that would crop up during the production process. This takes a lot of experience to pull off, it should be noted.

As Patrick was describing the core pillars of the game's design (the fighting, the navigation, and the social stealth) he shared an interesting anecdote, where during playtesting of the crowd-hiding feature, the player originally had to press an action button in order to hide within a crowd of people. This, according to data from focus testing, turned out to be very unintuitive and testers kept having problems completing scenarios where blending into the crowd was a requirement to completing an objective. Patrick was convinced that making the system automatic would solve the problem, but programmers insisted that it would be too complex to reconfigure - but no one actually took the time to look. The process of sticking strictly to design throughout production was about to bite back at them. Exasperated, Patrick used clear tape to hold down the crowd-blending action button and set up the specific scenario for testers to try. Thinking the auto-blend feature was already enabled in the game code, the testers found the scenarios much more intuitive to play. When Patrick took the results to the team and the programmers actually looked into it, they found the code needed to enable the auto-blending was actually quite trivial.

I'd also like to quickly mention the scope of this game's development, which spanned 300+ developers in 3 world-wide studios. Ubisoft Montreal handled the core of the game, while satellite Ubisoft offices in Singapore and France handled other aspects, like the villa and linear missions. That's pretty impressive.

Finally, Patrick mentioned a neat little design document trick he used. In the design, whenever he was forced to define some arbitrary value, like perhaps the length of time it took for a player to be lost amid a crowd, he would enclose the numeric vlaue within brackets - []. So if you were designing a FPS and wanted to list how many bullets a clip in a gun would hold, you would list the gun as holding [100] rounds of ammo. This is data that you don't want to exclude from a design document, but also data you know you can't accurately define without actually play testing the game. So initially this serves as a way for a designer to fully complete documentation, and later during production it serves as a marker for programmers to recognize as being data that will need to be changed/tweaked and not in any way hard coded. I like it.

How I Dumped Electricity and Learned to Love Design

Brenda Brathwaite gave a rambling talk about her journey as a game designer these last few years, and I say "rambling" only because she's one of the few people I know who can give a lecture seemingly without even pausing for breath. However the words flow steady and carry much meaning with them - I certainly don't mean "rambling" as in "crazy", although the way she went about creating her games could be seen by some as a breakdown of sorts. It came as she was wittling down her long playlist of games, which being that she is a designer was of course quite long, that she realized she had pretty much been playing the same game over and over... and over again. She decided she was quite done with reruns, and ditched electronic games almost in their entirety as she went back to what had originally been her "happy place", which was designing games.

Well wait, wasn't that what she had been doing since she first started back when she was 15, playing Dungeons and Dragons and using Legos as (literally) the building bricks for her ideas? Not exactly. She wanted to revisit the time when she designed a game herself. No team. No intermediary. No one else take her vision and create something for people to play. Just her.

It started with a discussion with her young daughter about the Middle Passage, which she had learned in school as part of Black History Month. Understandably, she had not quite grasped the full implications regarding what the Middle Passage actually meant. So Brenda whipped out some craft supplies and threw together a quick game prototype for her daughter to play, with a simple rule set and gave her daughter some additional perspective. From there, her designs led her to designing Train, which is based upon the Holocaust. This, as you may imagine, garnered a lot of attention - but it wasn't based upon the game's basis, although Brenda admits she did have to weather hatred from many people who found the game offensive. The big break came when she gave this very talk at the Triangle Game Conference in Raleigh, NC and a writer from The Escapist happened to be in the audience. The story hit the site and Train was unintentionally launched.

Designing Train (and other similarly-themed) games has brought Brenda back into her "happy place". Not only has she needed to acquire new skills, such as painting the wooden play peices, building rail road tracks, or knitting blades of grass into a burlap sack, but she's had to do them all entirely on her own. All the design decisions were also completely up to her. She's also been able to meet, in person, everyone who has played Train (prior to it's installation at an art gallery in Savannah). Getting that personal feedback and being able to watch play your game isn't something a lot of designers get to take part in these days.

Ultimately I will admit a lot of the detail from Brenda's talk escapes me. However that's where designer David Sirlin comes in, as his writeup of Brenda's lecture delves much deeper into her design and motive behind Train, including his personal take on the matter. As a bonus you'll find yet more MIGS coverage before and after his writeup on Brenda's talk.

And yes, although her next game does again focus on some of the more dismal aspects of human nature (hiring illegal Mexican workers) she has promised that she'll be switching tactics soon, and going after brighter ideals.

How To Make Games That Aren't Fun

Given that the previous day I had attended Brenda's talk about games in which the objectives did not include having fun (although some people did until they realized exactly what they were doing, and some people just never fully got it) it made sense to check out Randy Smith's talk.

Randy admitted halfway through his talk that the title was a lie to draw us all in to the room. "I really don't know how to do it," he said. But he did have some ideas. The premise behind his lecture was to create games that were engaging, but not "fun". In other words, games that focused on serious material and treated that material in a realistic manner. So, you have a game where you're part of a squad of soldiers and have to shoot bad guys. It requires you to make strong tactical decisions, such as a member of your group being wounded and forcing you to leave him behind to complete the mission. You then return to find he's be tortured and shot. It's easy to turn a scenario into something that's not fun, but an entire game? That's a bit daunting, but Randy tries to envision a game where you are working in a hospital and have to make decisions that could end patient's lives. There aren't really any rewards for saving people, if you do then you're just simply doing a good job. Do you send home a tired nurse and risk being shorthanded if a woman gives birth? Or do you keep him on duty and he ends up botching a surgery?

The problem comes from the fact that people engage in games for reasons other than fun all the time. People who play games like SOCOM want to know what it's like to operate in a squad and perform skills that real NAVY Seals do out in the battlefield. They're not neccessarily having fun in the way of shouting and cheering "hey look! I just slit that guy's throat without him even knowing I was there! Yipeee!!" but they are enjoying the experience of pretending to be someone they aren't. Not all games are accompanied by smiles and laughter, many are played with grim-set faces of complete concentration as players try to out-think their opponents. They'll no doubt look back upon the experience as fun, but at the moment they are playing they are either concentrating hard or even cursing at the screen as they die just before escaping a level for the umpteenth time. I can certainly recall plenty of gameplay experiences I wouldn't call "fun", but after completing them I did feel a certain amount of satisfaction. When I didn't, that was just bad game design poking me in the eye.

But again, I've digressed into situations within a game, and not the entire game itself. While Randy's idea for a hospital game fit the parameters of a game that wasn't fun, it was also a game I didn't feel any reason to want to play. Because it didn't sound fun? Or because it didn't seem to suit my tastes? Perhaps a bit of both. But since I keep ending up hypothizing distinct scenarios, it lends me to think that while we can't make an entire game that's not fun, it's certainly a thought we can apply to specific gameplay scenarios to make them darker and impose a greater affect upon the player.

Then again it could also simply open the doors for yet more video game violence controversy. But someone needs to push those buttons as well.

In the end it's all pretty much food for thought. Check out Gamsutra's coverage of the session and the comments there for more to munch on.