If you find this article contains errors or problems rendering it unreadable (missing images or files, mangled code, improper text formatting, etc) please contact the editor so corrections can be made. Thank you for helping us improve this resource
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.
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.
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 aposition 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? Thismeans 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 isacceptable 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 evenrecognize 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  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.
"http://www.escapistmagazine.com/articles/view/conferences/tgc_2009/6021-TGC-2009-How-a-Board-Game-Can-Make-You-Cry">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
"http://www.sirlin.net/blog/2009/11/23/migs-brenda-brathwaite.html">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
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.