CarneyVale: Showtime promotion continuing through April 2010
We reduced the price of CarneyVale: Showtime on Xbox Live Indie Games to 240 MS Points (US$3) for PAX, and we realized that folks might actually want to, y'know, get back home before downloading new games to their consoles. So we're keeping the promotion going until the end of April! If you played CarneyVale: Showtime during PAX, there's a lot more to unlock in the game: Rocket rodeos, mid-air boosts, accelerators, plus different cities and music!
Pick it up from the Xbox Marketplace today. Tell your friends! Let everyone know!
The big show, PAX East, is 24 hours away and there are still two more games left to showcase as part of our pre-PAX coverage. The next two games were developed at our Singapore lab by graduates from the Singapore-MIT GAMBIT Game Lab's summer program. Carneyvale: Showtime is the first game created by GAMBIT for distribution and sale on a video game console, the Xbox 360 via the Xbox LIVE Indie Games platform. Carneyvale: Showtime has received numerous accolades, winner of the DreamBuildPlay 2008 Grand Prize, Finalist at the 2009 Independent Games Festival, and featured as one of the PAX10 at PAX 2009.
Carneyvale: Showtime will soon be available for the Games for Windows platform, and to celebrate we are pleased to offer the Xbox version at a reduced price of 240 points for the duration of PAX East 2010, starting Thursday at 9PM, Eastern time!
Unlike the first four games showcased this week, Carneyvale: Showtime did not begin with a research question. Instead, the game served as the first commercial game created from one of our summer program's prototype games. Wiip, created during our first summer program in 2007, was a game to explore use of the Wii controller with a specific challenge: create a game based around an expressive physical interface, in this case a whip. Carneyvale: Showtime is a spiritual sequel to Wiip, not just in its art style, but in the use of 'physicality' as a mechanic. Rather than a literal physical interface as in Wiip, Carneyvale: Showtime uses the Farseer physics engine to create a unique experience of acrobatics through a rag-doll physics simulation.
Aside from the accolades the game has received, Carneyvale: Showtime's other achievement, and what truly makes it a GAMBIT game, is that it was developed in under five months by a young team using an agile production method, Scrum, and with much emphasis put on systematic testing as part of the full development process. For more information on the development process, check out the audio and slides from Lead Programmer Bruce Chia's Postmortem given at Casual Connect Seattle 2009.
Carneyvale: Showtime will soon come to the Games for Windows platform, featuring:
> New arenas!
> An improved level editor with level sharing with other players.
> More levels! Secret unlockables!
More information about the Games for Windows version will be posted to our site as it comes out.
You can purchase Carneyvale: Showtime for Xbox LIVE today for 240 Microsoft Points (US$3) starting Thursday (9PM Eastern) through the end of PAX via the Xbox Marketplace.
The labyrinth surrounds you interminably. Your way is unclear, though it is evident that a moment's hesitation will be your end; the labyrinth's monster draws nearer every second. In your arms you cradle your infant child who is recovering from a grave illness. You know you must find the way out.
Playtest 1: Matt
Our day commenced by having Matt play our now physically imagined prototype (designed at the previous week's meeting). Initially, he had virtually no concept of the mechanics, story, or props to be used in the game, other than it was in the survival horror genre. The setup, which was ready before Matt walked through the door, was as such:
A small cardboard box, painted pitch-black, approximately the size of a cinder block, fixed upright on the desk.
Roughly centered on the box's face was a small hole, shaped like an upside-down triangle.
Through the hole passed a length of wine-colored string, about eight inches or so of which lay outside the box, while the rest of the string (about 4 feet long) was hidden inside
A pencil, which rested on the desk inside a small, red rectangle, and a pad of ruled paper
Rules used for the first game (before any sort of feedback) were as follows:
After a brief exposition (see beginning of post) is read to the player, he is given the string to hold in his dominant hand.
A list of words is then given, one at a time, in succession, beginning with the shortest (three letters) and ending with the longest (thirteen letters).
The player is required to write each word, using his non-dominant hand, within a certain time limit (1 second less than the amount of letters in the corresponding word - 8 seconds for a 9-letter word, et cetera).
If the player fails to complete a word, one unit of string is pulled from the box, measured by regularly-spaced knots along the length of the string, and the player must re-write a word of the same length
Every three turns, a die is thrown to determine if the player's "child" sneezes, which will attract the Minotaur to your position (resulting in one unit's worth of string being pulled from the box). The player is asked if he wants to cover the child's mouth to stifle its sneezing.
Victory is attained if the player manages to successfully get to - and write -- the 13-letter word before the string is pulled completely out of the box
For Matt, the two most evocative components to the game were the use of the non-dominant hand and the "oh my God, what's in the box" aesthetic. The weak hand as a mechanic not only provides the challenge, but it evokes in a very elegant way a situation of being helpless and crippled. The black box, with the red string pulled slowly from its depths, provokes a nervous curiosity in the player as he anticipates what might be concealed.
Similarly, the kinds of words we used as obstacles were important to the flavor of the game. The language, either ominous or violent, was a big part of what qualified this prototype as "horror."
Matt succeeded at winning the game, but wanted to know what would have happened had he lost. We pulled all the string out of the box to reveal a rather underwhelming "death tassel" at the end. We had been conflicted about what to put at the end - what physical object could rival the bizarre, paranoid thoughts racing through the player's head as he plays? The imagined threat will always be much stronger than the real one. We wanted to convey "death" or "gore" with something vivid and tactile that would shoot out of the box and into the player's hand as we pulled the string. We also wanted to make it abstract and symbolic, as any literal representation (of the Minotaur, a child, or intestines) might come off as somewhat kitschy. But the result was not compelling.
Before the second playtest, we had a chance to make a couple revisions based on Matt's feedback. He commented that we were operating on a high level of abstraction. Improving the game was largely a matter of solidifying our symbols: Is the tassel at the end of the string the Minotaur? Is it the character's viscera? Is it the child? Is the physical act of writing a metaphor for running, or is it literal, as in an incantation or divination the player must perform to progress?
Playtest 2: Gene
For round two, some dramatic adjustments were made to the game interface. First, we decided concretely that the "death tassel" represented the Minotaur, and the string represented its proximity to the player - if the player botches a word, this is interpreted as stumbling or failing to make the right turn, and the Minotaur catches up a bit.
On a suggestion from Matt, we fashioned a makeshift baby from spare materials. The player could then cradle an actual soft, physical object in the crook of his arm whilst grappling with the writing portion of the game. This led to a more involved version of the sneezing mechanic, in which the player would be prompted to cover the baby's "face" with his writing hand, with the threat of receiving an additional penalty if he failed to do so. This would hopefully make the sneezing mechanic more grounded in the rest of the gameplay.
Gene also enjoyed the mystery of the box and string. He found himself with a strange desire to pull the string, but refrained for the fear of what might be on the other end.
However, the baby was not an entirely successful addition to the game. While Gene found the object endearing in a morbid sort of way, the entire sneezing ordeal did little more than jar the flow of game play. The baby became irritating - not the object of a protective instinct.
Gene was also unclear as to the eventual goal of the game. To him, it seemed that we would eventually be throwing twenty-letter words at him to write in under fifteen seconds. He didn't have a good sense of his own progress, which we felt was essential to feelings of tension as the player nears the end.
Playtest 3: Rik
The third iteration of the game marked a turning point in our procedure. We had made some considerable changes to the rules:
The labyrinth was represented by three stacks of cards, and the player had the option of going left, right, or straight, by choosing the respective deck.
The three decks were assorted into three categories: easy, medium, and difficult (most difficult being the longest words).
Instead of having the string drift off the end of the table after it passes through the player's hand, the player would now be required to wind it around his child's throat with each penalty. Holding both the baby and the string with one arm had been awkward for Gene, so we attempted to combine them in this way.
Amusingly, these additions resulted in a rather awkward playtest. The three decks seemed arbitrary, and Rik quickly found that his decisions had little impact on the outcome of the game.
We had wanted the difficulty of the word given to the player to be randomly determined to reflect running through the labyrinth and picking a path haphazardly, desperately hoping it's the right way. But the element of choice implied that the player should be able to guess properly and be rewarded for doing so, when this was not the case.
Additionally, Rik pointed out that the longer words were not necessarily harder than the short ones - he in fact preferred doing mid-length words of 7 letters or so, because he was more accustomed to them.
By jumbling our cards together, we also lost the feeling of tense progression as the player writes longer and longer words. This progression had also served to give the player an idea of how close he was to the end. In Rik's playthrough, the idea of progress was not as intuitive, and the game seemed meandering.
Finally, the act of wrapping the string around the "baby," while macabre, had the bizarre effect of making it seem like a tendril or tongue. The idea of the string as a measure of physical proximity to the Minotaur was lost.
Playtest 4: Philip
When Philip sat down to play, we had done away with the baby and its sneezing shenanigans (though it was still part of the flavor text) and the "path choice". This was our most simplified version - keeping only what seemed to be the most effective parts.
Philip was the first player to have only a moderate reaction to the box and string: since the game was clearly still a crude prototype, he did not expect the box to harbor anything profoundly menacing.
However, with just the words, box, and string in the equation, smaller elements became more important. The string did feel like a burden, and the knots that slid through the palm of his hand were like time ticking by.
In conclusion, the more we tried to add to the game, the more confusing and awkward it became. The most compelling experience came from the simple symbols of the box and the string and the simple mechanic of struggling to write with the wrong hand. We believe that this mechanic can be incorporated into a larger game, or translated into a digital prototype, but the mechanic itself should be kept pure in order to be most effective.
One final, curious result of game was the sheets written on by the players. Each player developed a strategy to cope with having to write with his weaker hand. Most found that using larger arm muscles to write was quite a good way to do it--Gene at times devoted entire sheets to single words--with varying degrees of success. None of the players reached the level of clarity that they had with their dominant hands, particularly with the longer words. We ended up with a series of quickly scrawled lists of violent words which resembled pages from the diary of a homicidal maniac--an unanticipated but nicely creepy souvenir of our playtests.
We're only two days from PAX East, but we've got three more games in our booth to tell you about! This next game, like the first three also made during the Summer 2009 session at the Singapore-MIT GAMBIT Game Lab, also serves as a research tool as well as a standalone game to be played on its own. Set in a town where the townspeople have lost their shadows, Shadow Shoppe is a matching game in which the player matches traits (descriptive adjectives) to shadows. Unlike other matching games, this one pits the player not against a preset list of matches, Concentration-style, but against the player's own actions. It is this gameplay that serves as the research tool.
The challenge put to the team of students that created Shadow Shoppe was to create a game to collect character design perception data from the game player. Shadow Shoppe, when boiled down to the basics is a survey. The player is presented with a number of character silhouettes and is asked to assign traits to each silhouette based on the player's perception and judgment of what trait best fits the silhouette. In order for the data to be useful, however, required that the player play the game for an extended period of time. The team went through a number of prototypes and design ideas to try to figure out how to get the data from the player while keeping the player engaged. To satisfy these requirements, the team decided to create a game design that would pit the player against their own memory, to introduce challenge, and wrap it up in an engaging and polished fiction that fit well with the gameplay mechanic.
As part of our Game of the Week video series, Embedded Staff Jason Beene gives insight into the game's development, both in its design and its art style:
This video is also available to watch via YouTube.
Our pre-PAX East coverage continues with another of the games made during the Summer 2009 session at the Singapore-MIT GAMBIT Game Lab. Dearth was an ambitious project for the lab, an attempt to create a two-player co-operative action-puzzler which could be played with either two human players or one human player and one computer-controlled character using an artificial intelligence method that does not require a programmer to create AI behavior by hand, but rather a separate program creates the AI behavior based on the game's rules.
The game plays a lot like the old Daleks/Robots game, but with two players instead of one. Each player traverses a maze. They goad the enemy characters into following them, but when two of the enemies are lead into occupying the same square on the maze, they burst, destroying themselves. Or, to use the 'back of the box' language:
Play as the tribal shamans. Force the mysterious water-sucking creatures to smash into each other, allowing stolen water to gush from their engorged bodies and be returned to the land. Plan movements with your partner carefully or be ready to make split-second decisions if things don't go according to plan. The future of the Tribal Lands will depend on how well you work together!
The artificial intelligence method used, a Markov Decision Process (MDP) problem solver, is not new, but until its use in Dearth it was largely untested in the domain of video games. Researchers Leslie Pack Kaebling and Tomas Lozano-Perez from MIT's Computer Science and Artificial Intelligence Lab (CSAIL) and Lee Wee Sun from the National University of Singapore, along with GAMBIT Embedded Staff Andrew Grant met before the student team was formed to discuss exactly what kind of problems an MDP could solve. It was up to the nine-person student team to take this advice and apply it to a video game. Early on it was decided that the game would be the starting point for research into how to use an MDP to solve the kinds of complex problems an AI sidekick would be confronted with.
Without getting too dry on details, an MDP works by taking as input every conceivable state of the world of the game. Meaning for each level, it needs a coordinate representation of where each player and enemy could be. Based on this, the MDP calculates a probability table whereby each possible action is given a score based on how much the action would help the other player (part of the description of the game given the MDP is what actions are helpful). When a human player plays with the AI sidekick, the AI is calculating what move it by looking up on the probability table what action it should take based on where the other player is and where the enemies are. To the human player, they're playing a game in real-time, but if you look at the game from the AI sidekick's point of view, it's a discrete set of moves (turn-based, like chess) but played very rapidly. The difference between this and most AI methods is that the programmers did not code behavior for the AI. The AI character behaviors were created automatically purely by examining the game rules and applying the MDP method onto them. The resulting sidekick AI behavior is unusual, in that it models several strategies that the player could be using, and tries to determine which one is most like the strategy that the player is using.
In the current version of the game, there are four levels that have been tuned to work for single-person (AI sidekick) play. The real meat of the game is in the two-player version, where there are 20 levels available to play with a human partner. The second life of the game is to use the two-player levels to continue to refine the MDP problem solver to solve more and more complex challenges.
As part of our Game of the Week video series, Embedded Staff Andrew Grant gives an explanation and insight into the games' development:
Dearth was selected to be in this years' Boston Indie Showcase at PAX East. If you drop by our kiosk at the Boston Indie Showcase booth (#117), you'll be able to see Lead Programmer Alec Thomson impress with his one player, two-handed approach to the two-player game!
Come by the GAMBIT Game Lab's booth (#1119) and bring a friend to play two-player as it was meant to be played: side-by-side on a full-size arcade game cabinet!
You can play this game today, online for free (by yourself or with a friend!):
This Friday Games rant, Andrew Grant will talk to us about simplicity in game design. Citing various examples Andrew will explore how over-complication can be the ruin of otherwise great games. Simplicity and Elegance are what Andrew is looking for, and he's gonna rant about it.
As part of our pre-PAX East coverage, I'd like to re-introduce two games made during the Summer 2009 session at the Singapore-MIT GAMBIT Game Lab. Waker and Woosh are practically the same game, that is if you don't consider a game's story, characters, and narrative an important part of a game. That sounds ridiculous right? Of course story is important, what would Quake be without an engrossing storyline and memorable cast of characters?
Okay, that was a cheap shot. But seriously - just how important is story, character, and narrative to you when you play a game? Waker and Woosh were created to explore this idea in a very specific context. The team of students that would call themselves Poof Productions were given a very complicated (and difficult!) task of creating a game that would teach middle- and high-school-age children about two basic physics concepts: displacement and velocity. Actually, they attempted to cover a third, acceleration, but were unable to get it into the game in the 9 weeks they had to develop the two games. That's right: one team of 10 students created two games in 9 weeks!
The common basis of Waker and Woosh are the controls, the basic mechanics and the levels. In Waker, the player maneuvers a cat-like entity through a dream world of platformer levels, to collect wisps needed in order to awaken a dreamer from her sleep. In Woosh, the player does the exact same thing, except all of the graphics and cutscenes have been replaced with abstract graphics (your cat-like thing becomes a ball) and the voice-over and story explanation has been completely removed! Everything else is the same: maneuver the ball through the levels, manipulate the graphs using displacement and velocity mechanics to create new platforms, and collect the abstract items to get from beginning to the end.
What an odd setup! Researchers Scot Osterweil, Lan Xuan Le, and Eric Klopfer gave the team the challenge to create these two games in order to study whether either the narrative or abstract form of the game is more effective in promoting student engagement with, and understanding of, the physics topics.
We're putting both games on display and side-by-side in our booth so that Expo goers can experience both games at the same time. Let our staff and students know what you think - is the story important? Which game do you like best? At the lab, we're split fairly evenly about which one is our favorite. What this means for the research question, however, we won't know until the researchers publish the study they'll be conducting.
As part of our Game of the Week video series, Embedded Staff Sara Verrilli gives an explanation and insight into the games' development:
PAX East is only 7 days away?!? I'm back in Cambridge and GDC is but a memory to me now; I vaguely remember having a great time in San Francisco. I haven't been able to process any of the great talks, panels, and parties I went to, I've got work to do!
If you weren't already aware, PAX East is the East Coast edition of the Penny Arcade Expo, a 3-day long gaming convention, that is being held at the Hynes Convention Center in Boston, MA on March 26-28, 2010. Over 60,000 people from across the nation will converge to play together: video games, board games, tabletop roleplaying games, LARPs (Live-Action Role Playing games), card games - basically, anything that has 'game' in the description is fair game.
The Lab is going to have an amazing presence on the Expo Hall. We'll have students, staff, and a few special guests at our booth and at the Boston Indie Showcase booth during each hour the Expo Hall is open.
Boston Indie Showcase
Two of the games made at the lab this summer by our students will be demonstrated at the Boston Indie Showcase booth: Dearth and Waker. I don't think there's a link available to the official press release yet, but it's been reported at DIYGamer and Bytejacker so far. We'll post the official link when it's live. Current MIT students who worked on these games will be at the Boston Indie Showcase booth to talk about the process of making games based on research, and how (or if!) their studies at MIT prepared them for it. Two of the staff members will also be present to talk about the challenges they gave the student team and why they were so mean to them.
Special Guests
Special Guests? How special are they? We are featuring five other independent game developers at our booth: Dejobaan Games, Firehose Games, the Learning Games Network, MacGuffin Games, and Pangea Online! Two of these companies, Dejobaan and Firehose are also in the Boston Indie Showcase for their games AaaaaAAaa... and Slam Bolt Scrappers. How exciting! But why are they at our booth? We at the Lab pride ourselves in collaborating with the local game development scene in Boston and New England: everyone from independent developers to larger companies, individual academics and researchers to other institutions' departments, labs, and centers (that's DLC's for all you MIT people out there).
Our booth will be the place to be if you want to see how people in the research and education sector (faculty, researchers, students) can collaborate with the game industry. Each group that we've given space to in our booth is different from the rest and collaborates with us in different ways.
Featured Games
We will also have a number of our games featured and playable at our booth. I'll be posting about them in the days that lead up to PAX East. You can play them all from home today:
PAX POX
We are also going to be playing a live-action 'big game' during the convention called PAX POX. We've teased about it in a previous post and will have more information about the game (and the live website) in the next week. If you love booth swag, playing this game will be the only way to get ours! (Don't worry - it's fun and it won't hurt a bit.)
It's going to be an exciting three-days and I can't wait for just get it over with! While I was at GDC getting my nails done and enjoying myself, three of the students on my PAX POX team were plugging away making badges for use during the game. We'll have pictures of their travails in the future, but for now, feel my pain. I've been locked in a room for the past week with various people coming up and yelling at me all while I've been trying to set up all of the computing equipment we need for the booth:
Rik says 'HALP?'
Generoso, our outreach coordinator and otherwise loveable guy, has been driven to beating up on defenseless Mass Art students like Garrett (see picture below). True we've got a great amount of video footage that we'll be featuring in our booth as well as in our Research Video Podcast, but that's no way to treat starving students!
Generoso and Garrett in a Bonding Moment
Please come by the booth and visit us! We'll be in booth 1119, right next to an admittedly odd (but kinda awesome) crew of exhibitors: Disney, Alienware/Dell, and AMD. Unlike the rest of the exhibitors, we aren't looking to sell anything - we just want to get the word out that Boston is the place for innovative game development and game studies.
Be sure to check out the Boston Indie Showcase on the other side of the hall (booth 117), where another friend of the Lab, Marc ten Bosch, will be demonstrating his IGF-nominated game, Miegakure!
The Expo Hall hours are Friday, 2pm to 7pm, Saturday 10am to 6pm, and Sunday 10am to 6pm.
After the WILD success of our Shadow of the Colossus prototypes, Matt asked us to make a paper prototype of a survival horror game. Unlike last time, this would not be an adaptation of a specific, existing digital game but rather completely new that would fit into the survival horror genre. He also asked that we avoid using a standard 52 card deck (presumably because playing cards figured heavily in our Shadow of the Colossus prototypes), and to make use of space and an avatar with core verbs (two things which we had not really included in our previous games).
This struck us as a difficult task, since horror--survival or otherwise--seems to depend so much on instinctive reactions to frightening things that the player sees and hears, and a constant feeling of danger and vulnerability. Paper, Play-Doh, dice, and the other materials available to us aren't really the ideal tools for creating such effects.
Our first task was thus to try to pinpoint the elements that define the genre and that are essential in creating that feeling of horror, and then to figure out how to translate those elements into a form that was compatible with paper prototyping.
In our discussions on this topic, we identified a handful of concepts that we believed to be central to the survival horror genre. One is the idea of rationing: the player doesn't have enough of some vital resource and must plan carefully to conserve it. In many cases, ammunition is this limited resource, but there are other possibilities, including non-physical concepts like an action that one can only perform a set number of times.
We also concluded that combat should be de-emphasized in favor of evasion and avoidance, i.e. sneaking around and running away from antagonists. In the event that combat did play a part in our prototype, we thought that it should be weighted more toward strategy and planning--setting traps, for example.
Finally, we decided that we needed to find a way to include an atmosphere of strangeness and "eeriness" in our survival horror prototype. In our Shadow of the Colossus adaptations, we had focused more on gameplay and mechanics and had downplayed things like atmosphere.
Not only did we want to try a different approach with this new prototype, we also felt that such things were essential to conveying the feel of the genre, and that our prototype would be less effective without an appropriate fiction.
From this starting point, we created two different prototypes. The first grew out of discussion on how to handle space in the game. Early on, we decided that we wanted to avoid standard representations like tokens moving around a grid. We considered ideas like having the player explore a world in which space doesn't behave normally (for example, if the player moved two units to the left and then two to the right, he wouldn't end up in the space he started from), but couldn't figure out a way to effectively represent the warping of space in a prototype.
Eventually, we came up with a game in which the player takes on the role of a person who is hiding in a "panic room" inside his house and has to conceal his presence from an antagonist (controlled by a GM) who is searching the house for him. To do this, he would have to find a way to get rid of clues that show that he is in the house, or prevent the searcher from noticing those clues--for example, he might have to find a way to extinguish a fire burning in a fireplace, or distract the antagonist so that he doesn't notice the fact that the master bedroom is too short by a few feet because of the false wall hiding the panic room.
However, the player has to do all this without leaving the panic room, with only a map of the house and the items in the room to help him. In addition, the player has to keep track of his enemy's movements through the house and time his actions so that they don't attract attention. If the player wants to, say, use the fuse box in the room to cut power to the kitchen where a kettle is heating on the stove, he will have to make sure that his enemy is not anywhere near the kitchen when he does so, using pipes and ducts that conduct sound from different points of the house. Finally, the player can only complete a few actions per turn, and so has to choose carefully which to perform.
We also discussed aesthetic elements that we could add to the game: putting the player alone in a darkened room, with recorded sounds that would play--fire crackling, stairs creaking, footsteps on wood floors--to represent the searcher's movement about the house. These elements, unfortunately, were complex and not feasible for a paper prototype developed in a few hours.
As a result, we could not playtest the game entirely as we imagined it. We were able to play through and try out the puzzle-solving elements (figuring out where the antagonist is and what actions to take to prevent discovery), but we couldn't gather much data about whether our ideas for creating a feeling of horror were effective.
We also tried to take a novel approach to representing space in our second prototype, in which the player is trying to escape from a monster pursuing them through a labyrinth. We decided that it would heighten the feeling of dread if the player was not certain how far away the monster was, but only knew that the monster was getting nearer.
Thus, we came up with a system in which the distance between monster and player is represented by a length of string, most of which is concealed inside a box (so that the player cannot see how much string remains). Every time the monster moves closer to the player, the player pulls a unit of string out of the box, and when the entire string has been pulled out, the monster has caught up to the player and the player loses.
On each turn, the player is given a word that they must write with their left hand (or whichever hand is not dominant) in a certain amount of time--the word is presented as a spell or incantation which will indicate the correct way to go, and writing it successfully represents the player having cast the spell and moved forward.
If the player fails to write the word within the time limit, or writes it illegibly, then they are unable to make progress and the monster moves closer. If the player manages to write enough words (which increase in length as time goes on) before pulling the entire string from the box, then the player has reached the end of the maze (or other goal).
At the same time, the player is told that he is carrying his sick infant child that has a chance of sneezing at every turn--in fact, with each successive turn, the chance that the baby will sneeze increases. If the baby does sneeze (as determined by the roll of a die), the monster moves closer. However, the player has the option of briefly covering the baby's mouth to stifle a sneeze. What the player is not told is that if he does this more than three times over the course of the game, the child suffocates. If this happens, the player is not immediately informed, but the baby ceases to sneeze. Only if the player reaches the end of the maze do they learn that they have inadvertently smothered the baby that they were trying to keep safe.
As with the first prototype, we also tried to include some non-gameplay-based elements that would add to the horror feeling of the game. The words that the player has to write are all of a violent or gruesome nature ("cut", "stab", "eviscerate", etc.); the string that the player pulls starts out white but gets gradually redder as the player pulls it out, and ends in a quantity of red silk (originally we wanted to put something disgusting or frightening at the end of the string, but couldn't figure out how the mechanism that would reveal it would work); even the potential revelation at the end that you've suffocated the infant you carried with you is a fictional element not strictly necessary for gameplay but an addition that hopefully creates a sensation of shock and horror.
Overall, the most difficult part of creating a survival horror prototype may have been the "atmosphere" requirement. It was not terribly hard to put elements of rationing (limiting the number of times you could suppress the baby's sneeze, for example, or the number of actions you could perform in a certain turn) and evasion (escaping the minotaur, concealing your presence from the searcher) in our prototypes. Nor was it hard to test the prototypes to see how those elements worked during actual gameplay.
But making a game where the atmosphere or fiction is important automatically adds a second level of difficulty, because you have to make sure not only that the mechanics you have work and are fun, but that the game is creating the effect that you desire. This was where we ran into trouble with our games--we could playtest the puzzles of the first prototype, or the difficulty level of the word-writing mechanic for the second prototype, but without actually recording spooky sounds or constructing the box with the blood-red string, we couldn't predict how our attempts at unsettling the player would really work.
This may be the biggest advantage that digital games have over our paper prototypes: they can rely on graphics of terrifying zombies, grisly grunge maps, and ominous music to create an emotional effect, but we have to devise with more indirect and unconventional ways of eliciting fear or horror using simpler resources.
On the other hand, forcing us to figure out new ways of inflicting dread in players means that, should we wish to make a survival horror video game, we do have a greater repertoire of techniques at hand -- techniques we might not normally have come up with.
Next post: prototyping and playtesting the handwriting game!
Following our previous prototyping endeavor, which involved conveying the feeling of exploring and searching, we decided to try and adapt the combat mechanic in Shadow of the Colossus into the format of a card game.
We kept the game two-player to reflect the conflict between hero and colossus. In addition, we weighted the rules so that the colossus would have more cards but fewer opportunities to use them, and the protagonist would have fewer cards but could cycle through them quickly and play them at a higher rate.
The idea was to establish an even playing field that demanded different tactics from either party: in the digital game, the colossi are strong but ponderous, while the player is comparatively lithe and agile.
In our first iteration, the "hero" was dealt a hand of five cards and a deck of 13, and the colossus began with a hand of ten and a deck of 24. The colossus would put the game into play by placing five different cards in numerical succession (though not necessarily consecutively) on the playing field. Each player would then attempt to complete a straight using the cards on the field in addition to their hands.
For example, if the colossus put down King, Queen, ten, four, two, then the players would simultaneously rush to complete the straight from King to two. The protagonist had the option of playing any card he liked (as long as that card had not already been played), but the colossus could only play cards that directly preceded or followed a card already in play.
In this version of the game, whichever player completed the straight would win all the cards in the straight, and would then shuffle them into his deck. The overall winner would be the first person to acquire all 52 cards in this manner. The cards belonging to a player thus represented a slew of concepts - health (since you would lose cards if you lost a round), elevation (since losing was also a metaphor for falling off a colossus), and advantage (since gaining all the cards would equal a victory).
When Matt played through our game, he questioned the idea of having the cards represent all of these gameplay aspects. By trying to contain so much meaning in the cards, we ended up obscuring some of the concepts that we were trying to illustrate. Clearly having more cards in your deck was better and meant that you were winning (the "advantage" aspect), but the relation to climbing or elevation didn't come across. The cards became a "winningness meter," as Matt termed it: not a reflection of any particular aspect of Shadow of the Colossus, simply a task in which performing well translated into winning.
In the second version of the game, we decided to include a separate "health" mechanic that would be closer to that in the digital version of Shadow of the Colossus. Since the card game phase of battle focused on the climbing mechanic, we developed another phase for the action of actually dealing damage to the opposing player.
The first person to complete the straight would roll a d10 and bet on the outcome. If he rolled higher than the number bet, he would deal damage equal to the bet. But if he rolled lower, he would take damage equal to the bet.
This rule was an attempt to recreate the game experience of taking a risk when stabbing a colossus. In the game, an action button is pressed and held to "charge" strength for your stab. A quick press causes only a very weak attack, but the longer the button is held, the greater the risk of being thrown from the colossus.
We also changed the rules of the card game that represented the climbing phase. In this version, the players battled by playing on different straights: the protagonist would first put down the lowest card in his starting hand and build upwards, and the colossus would put down his highest card and do the opposite.
In addition, play was no longer turn-based: players could put down and draw cards as soon as they saw the opportunity to do so, without waiting for the other player to play. Finally, the acquiring-cards-to-win mechanic was discarded--players no longer had separate decks, but drew from a central draw pile, and the first to complete their straight got a shot at dealing damage to his foe in the die-rolling phase. The loser was the first player to have his health (represented by a stack of poker chips) totally depleted.
An anonymous play-tester was brought in at this point to get a fresh perspective on the game. After a round or so, the tester pointed out that even though a real-time system made the game feel more like a frantic struggle, Shadow of the Colossus also has many aspects that are turn-based. Climbing a colossus often falls into a pattern of struggling up the colossus as fast as you can for a few seconds, then pausing and hanging on for your life while the colossus tries to shake you off. When it's done shaking, you can continue climbing and the process repeats - essentially, you and the colossus take turns. Curiously enough, our game was inadvertently turn-based as both players would politely refrain from taking a card if their opponent was also reaching for the draw pile.
Our solution to this issue was to have the players draw from either of two central draw piles, but discard into their own discard pile. This prevented any lulls in play in which neither player could do anything. Players were also allowed to draw from their opponent's discard pile, motivating each to keep track of his opponent's progress and only discard cards the opponent couldn't use. By forcing players to remain aware of the enemy's behavior, the game felt more like an actual physical struggle.
Matt played through the final iteration of our game and was happy to see that we had made our level of abstraction more concrete and specific. He was also interested in some of the elements that we had eliminated by trying to streamline the game. For example, we lost the clumsiness generated by two players trying to desperately draw cards from the same deck. Having just one deck made the game awkward, but the emotional experience was truer to the spirit of the videogame. Making the card game more urgent also removed any traces of what Matt called the "epic tedium" of scaling a colossus.
Our biggest conflict was between accurately recreating the videogame and making a card game that was upbeat and consistent.
GAMBIT Game Lab at GDC 2010, Day Five Video Podcast
From March 9-13th, the staff of The Singapore-MIT GAMBIT Game Lab will be participating in the 2010 Game Developers Conference in San Francisco. Each day a collection of experiences from GAMBIT Staff from the conference will be assembled for this podcast. DAY FIVE, the last day of GDC, begins with a controversial lecture on the positive effects of "Giving up your IP", followed by a GDC overview with CMS/GAMBIT Graduate Student, Eliot Pincus, scenes from the MIT Luncheon and the incredibly entertaining "Jobless Rant".
GAMBIT Game Lab at GDC 2010, Day Four Video Podcast
From March 9-13th, the staff of The Singapore-MIT GAMBIT Game Lab will be participating in the 2010 Game Developers Conference in San Francisco. Each day a collection of experiences from GAMBIT Staff from the conference will be assembled for this podcast. DAY FOUR began with a keynote speech from "Civilization" creator, Sid Meier. Our Sound Director Abe Stein talks about GDC and introduces us to the GDC Expo floor and GAMBIT's own Mia Consalvo contributed to a panel discussion on race in video games.
GAMBIT Game Lab at GDC 2010, Day Three Video Podcast
From March 9-13th, the staff of The Singapore-MIT GAMBIT Game Lab will be participating in the 2010 Game Developers Conference in San Francisco. Each day a collection of experiences from GAMBIT Staff from the conference will be assembled for this podcast. On DAY 3s highlights are scenes from the 12th Annual Independent Games Festival and 10th Annual Game Developers Choice Awards, GAMBIT's Rik Eberhardt, Matthew Weise and Marleigh Norton reflect on their favorite moments from the first two days of GDC and our Technical Director Andrew Grant invents a dangerous lunch (not suitable for children)
GAMBIT Game Lab at GDC 2010, Day Two Video Podcast
From March 9-13th, the staff of The Singapore-MIT GAMBIT Game Lab will be participating in the 2010 Game Developers Conference in San Francisco. Each day a collection of experiences from GAMBIT Staff from the conference will be assembled for this podcast. On DAY TWO, the GAMBIT Staff meets for breakfast to discuss the previous day's highlights, former GAMBIT researcher Jesper Juul weighs in on the FARMVILLE phenomenon and we end with a clip from the founders of The Global Game Jam.
GAMBIT Game Lab at GDC 2010, Day One Video Podcast
From March 9-13th, the staff of The Singapore-MIT GAMBIT Game Lab will be participating in the 2010 Game Developers Conference in San Francisco. Each day a collection of experiences from GAMBIT Staff from the conference will be assembled for this podcast. In today's video podcast, the GAMBIT Staff settles into GDC for Day One and discusses their favorite and not so favorite summits and lectures. Watch and enjoy!
PAX POX live action game to be played at PAX East in Boston
Despite being on a plane 35,000 miles up from Sioux City and en route to the Game Developer's Conference with the rest of the GAMBIT lab's US staff, PAX East (the new east coast Penny Arcade Expo) is huge in my mind right now. Taking place in Boston over 3 days at the end of this month (Friday-Sunday, March 26-28), PAX East 2010 will bring over 60,000 gamers of all kinds to the Boston area. GAMBIT is going to have a huge presence at the Expo. We are featuring 6 of our games at our booth, 2 from the Singapore lab, 4 from our Summer 2009 program, more information about which will be posted to our blog after GDC. Being a game lab, we've created a game especially for PAX East, to be played during the convention.
First off, PAX POX is "not a research experiment" (unlike many of our games) but instead a light-hearted GAME about infection vectors and hygiene set in the temporary community that will form around the PAX East 2010 attendees. You might've heard that there was an outbreak of swine flu at PAX 2009 in Seattle. As an attendee of more than a few conventions over the years, it's no surprise to me that these things happen - import a few thousand people from all over the US to a convention hall (it doesn't matter what kind of people or what kind of convention) and you're bound to have some amount of sickness travel from person to person. This is no laughing matter in itself, but it provides opportunity for a very light-hearted barely-serious game that I hope will bring attention to basic sanitary practices that I hope all attendees follow: wash your hands! cover your mouth! You know, those things you learn in Kindergarten but forget sometime between then and adulthood.
It's been really fun trying to figure out how to set a game like this up. Our lab doesn't often have the opportunity to work with the kind of design problems this game has presented to us, in particular, how do you make a live-action game that any number from 10 to 60,000 people can play? Three students and three staff members spent the IAP period in January (Independent Activities Period) coming up with a number of different designs, incorporating influences from Jane MacGonigal's 'Cruel 2 B Kind', LARP-style games designed and played by the MIT Assassin's Guild, and improvisational theater exercises. In the end, we decided on the least intensive game for our students to game master, with plenty of opportunity for any type of player to participate. Our team added a programmer to the team for the Spring semester to create some of the technical requirements for the game, and has been incrementally improving the initial design so that things will run smoothly during PAX East.
If you're in Boston for PAX East 2010, I hope you drop by our booth and play our games! The PAX POX team will be manning the GAMBIT booth in the Expo Hall during the entirety of the show hours (Friday 2p-7p, Saturday and Sunday 10a-6p).
The following paragraphs are notes documenting the first meeting of the spring prototyping team at Gambit. We had a working lunch, during which our team leader challenged us to take a preexisting videogame and translate it into a paper prototype. We began by brainstorming some games. Out of the twenty-odd games discussed, we chose Shadow of the Colossus--a game that nearly everyone on the team had played, or at least understood in terms of fundamental mechanics.
The team then generated a list of verbs that were integral to or somehow represented the player's immersion in the experience.
Most of these were directly related to gameplay:
Stabbing, slashing, calling your horse, running, shooting an arrow, swimming, grabbing, climbing, divining the locations of colossi
Other actions were less grounded in the mechanics, and more a part of the unique experience of a given player:
Falling, breathing, stumbling, searching, discovering, escape, yearning for exploration
We narrowed the list down to a smaller, more specific set of verbs:
Search, climb, grab, and fall.
We felt we could use these verbs in a way that conveyed the objective of the game as well as the aesthetic experience of playing it.
With an assortment of game pieces at our disposal (cards, poker chips, dice, go stones, cubes, post-its, graph paper), we first attempted to recreate the experience of traversing a vast terrain. We had the idea to have the player search through a deck of cards to find one that represented a colossus. The cards were then set up as a sort of terrain in which the player would navigate. Cards that were placed face-down were evocative of unexplored areas.
As the player moves a token from card to card, he has the option of searching the stack on which the token sits (limited to one card per turn). In order to prevent the game from simply becoming a pixel hunt, we organized the cards so that the player could intuit where cards of a certain suit and rank could be found. As the player advances, the path before him becomes more evident, but breaking down steps into turns necessitated a more gradual progression.
Among the issues that surfaced during the first trial game, one was the question of adapting the rules to include a second player in order to include the role of an active opposing entity, or instead allowing the inherent rules of playing cards work against the player. We also wanted to extend the theme of "searching" to the combat. In the video game, when a colossus is found, the player must then search for its weak point, and then must in turn search for a tactic to reach it.
We also thought we could convey hopelessness and desperation by forcing the player to use cards of a lower and lower denomination as they lost each round, making their failure eventually inevitable (unless they worked out a secret pattern, or tactic, that would ensure victory). Using lower and lower cards (picked up from lower rows on the board) would also symbolize "falling." Conversely, if the player began to successfully fight the colossus, they would feel "climbing" when the colossus had to use cards closer and closer to themselves.
When Matt played the game, more issues were raised. We wanted to have him play without much instruction, similar to how the game throws the player directly into play. But the rules of the game weren't clear enough from the bare setup, so we had to explain, taking away from the feeling of immersion.
He progressed quickly through the terrain, making us wonder if there wasn't a way to better emulate the feeling of crossing a great expanse. The use of graphics, space, and sound design all contribute to the immense atmosphere of the game, but is there a way to replicate this with a deck of cards and simple gameplay mechanics?
He did identify the pattern in the card layout, allowing him to "divine" his intended destination, and even had an "aha!" moment when he discovered the King of Diamonds (which we had instructed him to find at the beginning). Play was then paused at this point, until further development. Additional ideas we had from this experiment are as follows:
The game contains 16 "boss" battles, and after each battle you are brought back to a central point. Is there a way to represent the cyclical nature of this journey?
Can the variety of 16 different bosses be represented with 16 different kinds of gameplay? That is, one involving cards, another involving poker chips or dice?
Can we reproduce the feeling of the ending, which involves "letting go" of ultimate victory but still embracing a rewarding emotional experience?
Is there a way to involve the horse at all? In the game, the horse is a mode of transportation that you can control, but it sometimes disobeys you. We forgive this disobedience because it's a reflection of its characterization, but how would that translate into gameplay elements?
GAMBIT Inks CarneyVale: Showtime Distribution Contract
In a press release issued yesterday by the Singapore Media Development Authority, it was announced that a new distribution contract has been inked with Microsoft Games for Windows-LIVE for a modified version of the XBOX Live Indie Game hit CarneyVale: Showtime.
Slated for release later this year, the PC version of CarneyVale: Showtime will be
slightly modified to improve the game play for PC gamers, including enhanced game features such as a built-in map editor for players to create and share custom maps
with family and friends worldwide.
Of this latest achievement by CarneyVale: Showtime, Dr Christopher Chia, CEO, MDA said: "We are delighted that Carneyvale: Showtime has scored yet another triumph. The research collaboration with MIT has indeed benefited our local games sector in terms of research and development and such positive result underscores the commitment between us and MIT. We hope that more of GAMBIT's projects will lead to commercialization. We also appreciate Microsoft's continuous support of our games. We hope this relationship with Microsoft will open doors for more made-by-Singapore
games to be published on such international platforms."
Mr. Erik Ford, Senior Regional Marketing Manager of Xbox 360 in Southeast Asia, said: "We are proud of Team GAMBIT's achievements on the Xbox LIVE platform and are excited to see CarneyVale: Showtime coming onto the Windows platform. Team GAMBIT has set a standard in gameplay design for budding developers to aspire to and all this would not have been possible without the strong support of MDA."
Check back here for more information about CarneyVale: Showtime in the near future.
Today's Friday games at GAMBIT will feature a mini-talk by superstar Elliot Pinkus. here is what he is going to talk about:
The Devil May Cry series is known for it's brutal difficulty, but the director's recent follow-up, Bayonetta, takes a different approach. Elliot will be ranting about the point when difficulty impedes progression and how different players want that balance point in different places. Also including how I'm a wimp when it comes to hard games (I actually Don't Want To Be The Guy).
It may be fair to say that all Metal Gears up to and including MGS2 had similar design agendas. They were attempts to model, at increasingly levels of complexity, the core concepts of military espionage. Basic things like sneaking around, taking down enemies silently, and what to do when they found you were the main things being experimented with and revised. This all changes with MGS3.
Metal Gear Solid 3: Snake Eater (PS2 2004)on the surface seems much like MGS2. It has the same basic controls, the same mechanics of sneaking, of holding enemies at gunpoint. It has the same enemy alert phases from MG2, with their expanded enemy behavior from MGS2. It has the choking from MGS1, and (in a fashion) the same radar system. MGS3 reshuffled these familiar elements, however, giving them new meaning in a different context. A lot of it grew out of a decision to partially remove the radar, by breaking it up into two separate radars that (thanks to finite battery life) could not be used indefinitely. The radar first introduced in MG2 and revised in MGS1 showed enemy position, movement, and terrain with 100% accuracy. The radars in MGS3 showed neither terrain nor enemy vision. One showed moving life forms; the other stationary life forms. And since screens in MGS3 (thanks to its wilderness setting) were filled with animals as well as enemy soldiers, using these radars became a game of detective work, one that required cross-referencing with the player's knowledge of the current terrain and its wildlife. If the difference between soldiers and animals could not be determined, the player's directional mic (which could hear footsteps) was often the only way to definitively tell. The directional mic was introduced in MGS2, where it had limited, special-case application. In MGS3 it became part of the player's core gameplay vocabulary. Unlike MGS2 the player began the game with the directional mic, which made listening a new core action at the player's disposal. By limiting the player's ability to see, but enhancing their ability to hear, MGS3 made the process of simply finding enemies a major aspect of play.
Fighting an invisible enemy--of finding them before they found you--became the defining tension of play, which gave the expanded enemy interrogation mechanics a whole new value. Interrogation went from a cheap way to get items (in MGS2) to the primary mode of gaining gameplay-related information in MGS3. The choke action from MGS1 was retooled to be non-lethal: now a grabbed enemy could be squeezed for info. A chatty enemy could give away the positions of his comrades, which showed up on a sub-screen map. This effectively recreated the same radar information enjoyed in past games, though only after significant thought and planning. Discovering enemy positions in order to avoid (or subdue) them was much more important in MGS3 because the alert phases were much, much longer. Enemies would now search for a matter of minutes, not seconds. Even if the player escaped with their life, they were punished by having to wait for an agonizingly long time for enemy units to perform their sweep-and-clear patterns. Impatience could result in endless chases and gunfights over a wide variety of terrain. And although the player could sometimes call off an alert using the enemy's radio frequency (another useful bit of info that could be procured through interrogation) the only surefire way to achieve your objectives was patiently shaking down soldiers for field info, until you were 100% certain your imaginary map of the situation matched reality.
Interacting with these re-tooled old systems were MGS3's new systems, namely its camouflage and stamina systems. The camo system allowed the player to change Snake's outfit at any time, into a variety of patterns and colors. The closer the pattern and color was to the texture Snake was currently on (grass, gravel, tree bark, mud, sand, etc.) the higher the "camo index". An index of 0 was total visibility. An index of 100 was total invisibility. What was interesting about this system is how it reconfigured the entire game map in an instant based on the player's chosen camo. Similar to Ikaruga, which involved as its principle player action the inversion of hot (dangerous) and cold (safe) space, MGS3 offered players the strategic affordance of deciding for themselves what spaces would be hot or cold. A tree trunk was as perfect hiding place in tree bark camo; a horrible one in snow camo. In past Metal Gear games the configurations of hot and cold space were always fixed, and this fluidity made MGS3 a different strategic animal than other games. It wasn't about finding safe spots so much as creating them, something which was only made possible by its organic (and often vast) wilderness environments. Although there were a few indoor locations that required the symmetrical, ordered thinking of past games, most spaces in MGS3 were messy and sprawling. Some screens contained acres of chaotic, tangled undergrowth, where textures and colors mixed and swirled together in crazy ways. Learning to read and exploit the potential of the natural world was really the main challenge of MGS3. Both you and your enemies were at its mercy, rendered obscure by its twisty madness. Using nature better than your foe (who were also somewhat camouflaged but, unlike you, couldn't change their camouflage) was the order of the day, and it meant the difference between success and failure.
The theme of wilderness survival reached much farther than just manipulating visibility (and therefore combat advantage). It was also woven into the mechanics of health, which departed sharply from past Metal Gear games. Health was no longer replenished by healing items. The player had to wait for their health to recover naturally over time, which was essentially an expansion of the bleeding-recovery mechanic from MGS2. Like bleeding had previously, overall health in MGS3 would recover faster if the player lied still. Lack of stamina would also impede health recovery, as well as cause a host of other ill conditions. Like the directional mic, MGS3's stamina meter was a core game system generalized from a past game's special-case function. It was essentially a re-tooling of the grip meter from MGS2, which governed how long a player could hold onto a ledge. Unlike the grip meter, the stamina meter was on-screen at all times, and would deplete for a variety of reasons. Running, swimming, fighting, hanging, or just natural hunger: all these things would make stamina deplete. Low stamina caused not only slower health regeneration but also diminished aiming ability. The screen would shudder while in first-person mode, making it harder for the player to perform effectively in battle. All this necessitated catching and eating the live animals littered throughout MGS3's wild world. Only by eating the right animals (and avoiding the wrong ones) could the player maintain their health and their physical combat performance.
Far from being just a localized mechanic, eating and stamina in MGS3 was a global system that governed all human behavior, not just Snake's. All enemies had stamina, which depended on stores of food rations scattered throughout the wilderness. Sneaking into and blowing up one of these store houses would cause all enemies in the nearby area to starve, giving them all the same low-stamina effects you would suffer under similar conditions. Their aim became worse, and a single punch would cause them to fall unconscious. Destroying the enemy's non-food resources was another way to manipulate their behavior. Blowing ammo stores made them less likely to waste bullets unless they had a clear shot. This, combined with the fact that enemy soldiers would not shoot a comrade you were holding, gave shrewd players enormous leverage should they find themselves cornered by an group of numerous--but tired and under-equipped--enemies. Taking a hostage, backing towards an exit, and then making a break for it as the few bullets your opponents had missed you by a mile was just one way to bend these logics to your ever improvisational advantage.
Metal Gear Solid 3 is a great example of existing game mechanics reconfigured to create a different game from its predecessors. With the core mechanics of military espionage more or less solidified after MGS2, MGS3 feels like a conscious experiment to explore new flavors of (rather than just better or more complicated) stealth gameplay. It does this by focusing on a setting and a theme, and allowing that setting and theme to both inspire new mechanics and reshape existing mechanics. As a result MGS3 is a game about wilderness survival as much as it is a game about sneaking behind enemy lines, a fact that can be felt coherently in every aspect of its design. This man versus nature conflict, embodied globally in the game system, might explain why enemy soldiers seem a bit more human than before, for now they are unambiguously subject to the same forces as the player. In many games the rules that govern non-player characters and those that govern player-characters are different, but in this game they are the same. Understanding this, that your foe contains all the same human frailties you do, is your key to to defeating him in MGS3's unforgiving world. As we'll see, this gradual humanization of the enemy will only increase as the series progresses.
Research Video Podcast Episode 1: DEFINING GAMBIT RESEARCH
Episode 1: DEFINING GAMBIT RESEARCH is a discussion amongst the GAMBIT Staff as to the nature of GAMBIT's particular methodology in regards to video games and the state of game studies as practiced here and elsewhere.
GAMBIT Named 8th Best Game Design Program by The Princeton Review!
The Princeton Review "surveyed 50 collegiate game design programs in order to handpick the best schools you should attend if you're interested in going into game development" (so sayeth GamePro magazine, who published the results), and of these 50 American and Canadian undergraduate programs GAMBIT came in 8th! This is particularly awesome since, as GamePro also notes, "MIT doesn't offer a game-specific degree; it only has degrees in disciplines like computer science and media studies. Through these programs, however, students can access the Singapore-MIT GAMBIT Game Lab to work with other schools in collaboration to create games."
The complete Top 8 list is as follows:
University of Southern California, Interactive Media Division
DigiPen Institute of Technology
Drexel University, RePlay (Digital Media & Computer Science)
Becker College, Game Design and Game Programming
Rensselaer Polytechnic Institute, Games and Simulation Arts and Sciences
The Art Institute of Vancouver, Game Art & Design/Visual & Games Programming
Worcester Polytechnic Institute, Interactive Media and Game Development (IMGD)
Massachusetts Institute of Technology, Singapore-MIT GAMBIT Game Lab
"Our core mission is providing parents and students with good admission advice," says David Soto, director of content development at The Princeton Review. "We're hoping this can add legitimacy to an emerging market."
In all, The Princeton Review surveyed 500 schools before arriving at its top 50 with game design studies.
Programs were evaluated on four main criteria: academics (courses and skills fostered), faculty (especially the percentage who had worked in the industry), infrastructure (technology and game laboratories) and career (internships, job placement). "The schools that scored exceptionally well, the top eight, were really top-notch when it came to all four," he says.
