Monsters In My Backyard is a puzzle-action platformer game featuring Pinocchio, an automatic rigging technology for 3-D asset production developed by researchers from MIT CSAIL. On a distant planet of weird creatures, a mad scientist schemes to turn the whole universe boring and flat with a super bomb that turns everything into paper and cardboard. No one escapes the scientist's villainy, except one: a certifiable dork named Domm. Help Domm solve challenging puzzles, manage resources, and collect power-ups in his quest to change a 2-D, linear planar nightmare back into his beautifully vibrant 3-D home.
You can read more about Monsters in My Backyardhere. Enjoy the trailer below and download the game!
I am currently having more fun playing Red Dead Redemption than any other open world game in recent memory, and certainly more fun than I've had with a Rockstar game in several years. The last Rockstar game that felt similar was Grand Thief Auto: San Andreas, largely because of its heavy emphasis on role-playing elements. Grand Theft Auto IV was marketed as if it were a role-playing experience, but it didn't have San Andreas's benefit of a clear genre reference to build its various game systems off of and give them coherence. The clarity with which Redemption identifies itself as a Western, and the surprising extent to which it allows that to inform its world design, puts it head-and-shoulders above every other Rockstar game. Though it suffers from some vestigial design conventions inherited from GTA (mostly having to do with GTA's open world strategy of being a theme park rather than a holistic world simulation) it offers the player more choices, more expressive ways of behaving, than many open world games.
What's striking about Redemption is how unlike GTA it is, in spite of following a lot of the same conventions. It's pretty ironic, considering the associations of Westerns with guns and violence, that Redemption is one of the least violence-centered open world games I've played... even less, I feel, than RPGs like Fallout 3 or platformers like inFAMOUS. The fact of the matter is in the world of Red Dead Redemption there is a whole hell of a lot to do that doesn't involve killing people. I spent the first several hours of my game simply hanging out on a ranch, learning to tame horses, herd cattle, hunt, trade, forage, play cards with the locals, and in general just enjoy the beautiful countryside. I've heard the first few hours of the game criticized as "slow", but I wonder if this is just because no one asks you to kill people until a good while in. The only violence I engaged in (not counting hunting) in my first few hours was night watchman duty for a small ranch, where I was delighted to discover that killing was only one tool in my toolbox of available actions. All it took to scare off some cattle rustlers was pointing my gun at them. More belligerent trouble-makers could easily be disarmed with a well-placed shot, and if they still didn't feel like running they could be wrestled to the ground and knocked unconscious. And this was before I was given the lasso, which is originally for breaking in wild horses but works just fine on people too. Folks can be intimidated, knocked out, humiliated, scared, tied up, carried, untied--all without being murdered. Any combination of these things usually gets the job done, and the job is usually trying to maintain some semblance of order in an already fairly civilized (by video game standards) world. Probably the biggest irony of Red Dead Redemption is that its vision of a frontier civilization feels more peaceful and less violent than most video game worlds. The countryside isn't overwhelmingly hostile like it is in virtually all other open world games. Animals largely mind their own business, and most of the people you meet are friendly. You will occasionally encounter a hungry pack of wolves or some bandits, but these are always the exception, not the rule. You'll hear gunshots often in the distance, but you can simply mind your own business and go along your merry way. Life's too short, after all. And the open sky too beautiful.
The world of Red Dead Redemption is more indifferent than hostile. It isn't trying to kill you by default, and this may be why your range of responses to it involve a lot more than killing. When violence erupts, you know there's a range of ways to respond, depending on what sort of person you want to be and how you want others to regard you. The social simulation aspect of Redemption fits nicely in with the rest of the world. Murdering someone in the street is considered a crime, even if it was part of the duel, as is hogtying or assaulting random citizens. I once shot dead a man threatening a prostitute with a knife, and I was promptly run out of town by the authorities. Murder in defense of the weak or even in self-defense is frowned upon... unless you happen to wear a badge, in which case you basically have a license to kill anyone considered an "outlaw". Bounties always pay better if they are alive, but most gangs refuse to come quietly, so killing tends to become a natural consequence of law enforcement in practice. Of course, you can try to shoot everyone in the leg, hogtie everyone, etc.--and you may even get a few of them--but when you're pinned down in a canyon by seven snipers who have no qualms about killing you where you stand, pacifism becomes the quick road to suicide.
As a simulation Red Dead Redemption isn't as nuanced or as consistent as it could be, which hinders role-playing at times. I blame this primarily on the game's adherence to the "Rockstar formula" for how it attempts to integrate story and world design. Rockstar games have always been more like theme parks than proper world simulations. Story missions and challenges are like rides in a theme park, and the open world mostly serves as a fun space to explore while traveling from one "ride" to another. The rules that govern the open world are built on the story's theme, but they cannot be very complex or have very serious consequences because that would inhibit the players ability to experience all the "rides". There has always therefore been a disconnect between story and world in Rockstar games, and Red Dead Redemption is no exception. As an experience I feel the game would be a lot stronger if your behavior in the game world actually effected the story. For example, it would be nice if the sheriff of Armadillo wouldn't talk to you if you were an outlaw. Likewise it would be nice if all your actions in general had more lasting consequences. The fact that the game responds to you killing everyone in a town by having the town become a ghost town is great, but the fact that everyone respawns six days later is silly... just like the fact that a killing spree gets you in jail, but only for a week or so. Rockstar still doesn't want to prevent players from basically doing whatever they feel like at any given moment... like any paying customer at Disneyland.
The dissonance created by Red Dead Redemption's theme park structure, along with its occasional bugginess and thematic verisimilitude, makes it feel at times like a computerized version of Westworld, that old sci-fi movie from the 70s about a Western theme park populated by robotic cowboys. When the spell of Redemption breaks down, when the simulation suddenly feels shallow or the narrative inconsistent with my personal player behavior, it feels suddenly like I'm a customer in a Western-themed amusement park, not a carefully role-played persona in a richly simulated world. However when the spell holds, when the stars align and none of the various elements contradict each other, it's the wild west simulation I've waited my whole life to play.
This Friday we are hosting our good friends from Lantana Games to come present some of their work and possibly to let us play prototypes of some of their new stuff. Here is a bit from their website about their studio:
Lantana Games™ is an independent game development studio located in the greater Boston, Massachusetts area. We are currently focusing on PC and home console game development for digital distribution. While we do not focus on developing one specific kind of game or for one specific audience, we uphold every game we make to the same standards:
* Innovative but well executed gameplay mechanics.
* Focus on user friendliness and shallow learning curves.
* Unique artistic presentations.
* If we don't love our games, neither will you.
Lantana Games™ released two games in 2009, the expressive and experimental The Longest Night and the addictive rhythm/shooter Zombie Slaughter Tour 2009. 2010 is already looking like a game-filled year for Lantana Games™, with the release of the short prototype game Hunter's Gulch, a Western-style shooter, and it's very likely not the only prototype we will release for free this year.
Recently, Lantana Games™ announced its biggest project to date, Children of Liberty™, a stealth platformer that takes place on the eve of the American Revolution in Boston. We do not have a release date yet, but more info is always on the way.
Festivities start at 4PM, so come on by our TV Lounge this Friday to meet Lantana.
Throughout the spring semester of 2010, GAMBIT's Lead Interaction Designer, Marleigh Norton challenged a group of three MIT UROPs (Nick Ristuccia, Anna Kotova and Michael Lin) with the task of each creating three game prototypes. The game prototypes were to reflect a certain area of cancer research with the final goal of a one of the games be developed for use at the new Koch Institute for Integrative Cancer Research at MIT which is scheduled to be opened in December of 2010. Produced by Generoso Fierro, Edited by Garrett Beazley.
In this episode, Anna Kotova demos the three games she created for the project:
(This post originally appeared on Jason Begy's blog, Game Bitiotics.)
Video games have no magic circle, but board games do.
The difference between these two media is, essentially, one of reaction and proaction. If I may be allowed to indulge in a McLuhan-esque theory for a moment, video games are a reactive medium. As a player, I am continually reacting to the game state as-defined by the computer. The computer communicates the current state to me (the means by which it does so varies considerably from game to game). I then process this information, make a decision, and the feedback loop continues. This is of course the same regardless of the nature or genre of the game: in this sense Farmville, Grand Theft Auto and Quake are all the same thing. In multiplayer games the situation is only slightly different: a varying number of people are affecting the state, but the state is still processed, maintained and communicated by the computer.
Board games, however, are a proactive medium. In these games the state is essentially a mental construct shared amongst the players. Each will have (approximately) the same idea of what the state currently is, and when the state is altered each must update his or her own construct accordingly. The actual bits, cards and so on can be thought of as reminders that communicate the state, used so that we do not have to keep everything in memory. These games are fundamentally proactive: as a player, it is up to me to process and update the game state, in addition to choosing how I will alter it when my chance comes. Without the player's shared understanding of the rules and the state the game breaks down. As such, everyone must actively maintain the information in the system that both defines the state and the rules.
With this in mind, I want to address Huizinga's famed "magic circle." Recent scholarship agrees (seemingly unilaterally) that the magic circle is porous at best. While Huizinga implies that a game is somehow set apart from reality, in practice this is never the case. Anyone who has ever intentionally lost a game, bragged (or annoyed by bragging) about winning, or bet on an outcome knows this firsthand. In short, our real lives permeate the games we play, and they cannot be cleanly separated.
As such, it seems that as a theory the magic circle as-described is incomplete, or even incorrect. However, I propose that we should view the magic circle as the information feedback loop maintained by the players of a board game. The magic circle implies that something special and distinct from ordinary reality is occurring during a game. When we play a board game this is exactly what happens: the objects we play with are imbued with a special significance. Paper money is "worth" something, flat discs can "jump" over each other, placing a token in a certain place earns "points." The meaning and information we attach to these objects belongs to the other half of the information feedback loop, a loop drawn between the players-as-players and players-as-processors. This loop is the magic circle, a circle that transforms random cubes of wood into bits of information that we are then somehow able to act upon in a meaningful way. When the game is over the paper money still has value, but it is of a different type.
Six victory points.
With video games the feedback loop is fundamentally different. We do not need to attach any special meaning to Mario, the computer provides it for us. We see and interact with the objects in a video game without any special manipulation of our own cognitive processes. There is no magic circle here, only reaction to a state that is just partially under our control.
I want to conclude by noting that this is not an attempt at a value judgment that privileges one medium over another, despite whatever connotations "proactive" and "reactive" might have in today's business-jargon-infused world. Rather, I believe that board games and video games have some fundamental differences, and this short piece represents a first stab at delineating them.
Paper Prototyping Your Game Episode 2: Video Podcast
Have you ever wondered about the first stage of creating a video game? GAMBIT's Technical Director Andrew Grant along with GAMBIT's Lead Game Designer, Matthew Weise lead a group of three game designers (Kevin Laughlin, Alexis Brownell and Sophia Foster-Dimino) through the paper prototyping stage of videogame development. Video Produced by Generoso Fierro, Music and Editing by Garrett Beazley.
EPISODE TWO PART ONE: Andrew and Matt present our Game Designer with the challenge of making a prototype based on the classic children's game "IT". To do this our game designers utilize an interesting part of the GAMBIT Game Lab's interior.
EPISODE TWO PART TWO: Design Consultant Tim Stellmach reviews the prototyped version of "IT" that the game designers have created using the frosted walls of the GAMBIT Game Lab.
Chrono Cross (PSX, 40-60 hrs) - A lush, beautiful, and deep Japanese RPG that suffers from a fatal case of bad storytelling. A sequel to Chrono Trigger, which was much better, Chrono Cross pretends to be an unrelated story about alternate dimensions for the first two thirds and then turns into something resembling a bad Chrono Trigger fan-fiction before self-destructing in a fit of hysterical pretension. Not that this necessarily matters if you're in it for the gameplay, which is pretty well-done and notable in particular for its excellent magic system. Though seemingly arbitrary at first, the magic system is deeply integrated into the plot, so that by the end the game cannot even be finished unless the player understands the cosmological significance of the magic system and its symbolic relation to the story world. A long game, but the gorgeous graphics and wonderful music (Yasunori Mitsuda at his finest) make the journey pleasant enough. Those expecting something as elegant, focused, and unpretentious as Chrono Trigger however will want to vomit by the end. Directed and written by Masato Kato, who swiped most of the story material from his equally self-destructive Xenogears. With Hiromichi Tanaka (producer), Kiyoshi Yoshii (main programmer), and Yasuyuki Honne (art director).
Have you ever wondered about the first stage of creating a video game? GAMBIT's Technical Director Andrew Grant along with GAMBIT's Lead Game Designer, Matthew Weise lead a group of three game designers (Kevin Laughlin, Alexis Brownell and Sophia Foster-Dimino) through the paper prototyping stage of videogame development. Video Produced by Generoso Fierro, Music and Editing by Garrett Beazley.
PART ONE: Andrew and Matthew present our game designers with a concept for a game. Here begins the process of creating the gameplay! Our designers use markers on paper, blocks, string and a host of other tools to make the game a reality.
Abe was cleaning out his parents house the other day and uncovered a mysterious old box with ancient runes on it.
Inside, it turns out, was an artifact from his youth, the glorious TI-99/4A next to a host of cartridges. The Texas Instruments TI-99/4A was a home computer released in 1981, and it was, for many, the first console on which they discovered video games.
Jason Begy also loves the TI-99. Through guile and access to necessary resources, he was able to revive the old TI-99 and we have it working at the lab.
Come by GAMBIT this Friday at 4:30 for a trip down memory lane.
If you haven't been to a game jam, it is a gathering of people who are dedicated to creating a game in a short period of time. Attendees work individually or in teams and there's a general feeling of camaraderie as everyone works toward their end goal in a shared space.. Those interested in developing a game should bring a laptop to our site as computers will not be provided.
The event will be held this weekend, 5/21-23, at Microsoft New England Research & Development in Cambridge. To register and for directions, visit our registration page. The event will run Friday through Sunday at the following times:
This phrase appears if you pause Metal Gear Solid 4: Guns of the Patriots. It appears in English under a bit of Kanji, the same Kanji that appeared on ads before the game's release. It also appears in-game on Snake's suit. I'm not sure how diegetic it's supposed to be, if the implication is supposed to be that it's been consciously chosen by Snake and Co. or if its just so supposed to be a symbolic statement by Kojima, but it clearly is important in light of the game's narrative arc... or, more accurately, the series' narrative arc. "Let the world be" is a variation on what Big Boss (the supposed "villain" of the series) tells Snake at the MGS4's end, which sums up his (and assumedly Kojima's) entire world-view, the sum-total of everything he's learned over the course of his political and military career, which spanned most of the major conflicts the 20th century and involved as its principle enterprise the creation of a country in opposition to (among other things) the United States' military hegemony over the world.
This phrase is, at the end of the day, probably the biggest problem I had with MGS4 (and I had many). I felt it was a disappointing cop-out to the provocative 20th century counter-mythology Kojima and his collaborators had developed over the course of 20 years, but which flowered primarily in the latest three installments (MGS2, MGS3, and MPO). I realize Kojima doesn't want to advocate war or revolution, but going so far as to have Big Boss--the series' fascinating ideological enigma--flat out say it's categorically bad to try to change the world was to me a betrayal of every interesting moral/political contradiction the series had previously (and boldly) reveled in.
Not change the world? Let the world be? That's always the right political choice, huh? That's what you've got to say to Gandhi, Malcolm X, and anyone else who ever felt injustice demanded change? Maybe not "by an means necessary", but surely there is change worth fighting for, and surely the means are up to each one of us to either support or denounce based on what we personally consider necessary. Surely the lesson cannot be "fighting for anything is bad". Or am I misunderstanding the phrase "let the world be"?
"Letting the world be" may be the absurd ideological resolution MGS4 attempts to force on otherwise rich material, but it interestingly mirrors the ideological resolution of another great stealth series, one that isn't nearly as absurd. Thief III (or Thief: Deadly Shadows, as it was publically known), the final if little played installment of the (mostly) brilliant Thief trilogy, actually had a similar kind of thematic arc. The Thief series was about Garrett, the greatest thief in the world, rejecting the way of his mentors, the Keepers. The Keepers used stealth to observe the world and be its chroniclers, sort of like historians. But Garrett chose to use the skills they taught him to steal rather than learn. The Keepers have a philosophy of balance, which manifests politically as a strict policy of non-involvement, which is why they practice stealth. Thief III was about Garrett realizing how corrupt the Keepers had become, about how they really were meddling in political affairs, and how he activates an ancient fail-safe designed to wipe out their age old store of knowledge. Garrett does this not out of altruism or a conscious belief in their values (which he thought he had rejected) but out of a desire to keep the Keepers from messing with the delicate political balance he profits from by stealing. (Wars are bad for business.) In doing so he ironically was the one true Keeper left, because he wanted balance, and achieved it through stealth.
The Metal Gear and Thief series both feature central villains whose original intentions to change the world for the better become hopelessly corrupted, which necessitates their destruction by a reluctant, stealthy (anti)hero. "Leaving the world as it is" (to uses Big Boss's phrasing) has an interesting resonance in both cases, especially when one realizes this concept is fundamental to the gameplay DNA of the stealth genre. In stealth games players must ask themselves at any given moment "do I interfere?". Sometimes intervention is best. Someones it is not. But it's not coincidental, I feel, that both these series are stealth-based, which means that "to let the world be or to not let the world be?" is a political question the player answers in microcosm every time they make a decision during play.
Are stealth games fundamentally about the morality of covert versus overt intervention in any given circumstance? Is it worth killing someone to steal something? What about to save the world? Am I just the ultimate non-interventionist if I play Thief or Metal Gear without touching or altering anyone? Have I agreed to "let the world be"?
Funny that I find doing "pacifism runs" of stealth games so satisfying, such an exquisite test of my obsessive-compulsive moral conscience, but still I find the ideological conclusion at the end of MGS4 so infuriating. Maybe it's because MGS4's story is stupid in about 20 other ways, or maybe it's because I feel the real world geopolitical problems Kojima mythologized demand a less bone-headedly sentimental resolution. Thief took place in a steampunk-ish medieval fantasy world, but it still managed to generate a resolution that was subtle and complex, not silly and reductionist. If Big Boss's final lesson had to be that "stealth" is the best political strategy for a war-torn world filled with suffering, that could have been an interesting notion had it been treated as the beginning of a conversation rather than the end of one, as a question rather than (absurdly) an answer.
Part of me thinks Kojima was just so intent on ending the series in MGS4--in tying up all its loose ends, even its thematic ones--that he reached for easy solutions more out of desperation than any genuine ideological agenda. Big Boss's weird apoliticism at the end of MGS4 seems to have been thrown totally out the window, for example, in Peace Walker, which is about Big Boss defending a seemingly defenseless country (Costa Rica circa 1974) from covert U.S. military occupation. Of course, one might assume this just represents a step on his road to regret (he doesn't see the "error" of his ways, according to MGS4, until 2014), but on the other hand it's really hard to imagine Kojima suggesting that letting a super power walk all over a smaller country is the "right" thing to do. Indeed, all advertising for the game seems to suggest precisely the opposite.
The stealth genre may be the ideal one for posing political questions surrounding use of force to the player, precisely because it is the only game genre where violence is always a question. Is violence necessary? Do I really need to kill this person? What if I sneak past him? What if he tries to kill me? Then do I kill him, or do I run away and sneak by him later? I know there's a way to do this without killing anyone, but I also know it's the hardest possible way to do things. Every time I take the easier way out, or try to rationalize my mistakes, and the resulting bloodbath, as inevitable (and therefore justified), have I done what politicians, generals, and soldiers do when they make the decisions we pay them in order to not make ourselves?
It's a question worth asking, and one that the player (not the developer) should be answering.
This Friday we have a special Games at GAMBIT. We will be showcasing our staff and students' work from the past year. Get a sneak peek of a dozen games, most of which are still work in progress, but some of which will be released on our website before the end of the month!
We'll start the presentations at 4:30pm. As always, we're on the 3rd floor of 5 Cambridge Center, above the Legal Sea Foods on Main Street.
In this, the last prototyping session of the semester, the team continued work on the castle-building game that we had begun the week before. By the end of the previous meeting, we had made a good start and we had a fun game. This week was mainly refining, adding new features to make the game more interesting and polishing existing features.
The week before, we had necessarily focused mainly on playability and designing a prototype that would actually be a decent representation of the kind of gameplay we wanted, and we glossed over many of the finer details about the workings of medieval castles. While we incorporated concepts that we had come across in our research, like machicolation, we didn't put too much emphasis on making sure that the way we implemented them was completely historically accurate. So, one of our first tasks this week was to go back to our sources and try to adjust or add to the different elements we had included so that they better reflected the reality of medieval castle building. For example, we had previously made a rule that adding machicolation to the top of a tower extended the range of the archers on top of that tower. However, that was not actually an accurate representation of the effects of machicolation--what it actually does is allow archers to fire nearly straight down on attackers at the base of a tower without exposing themselves to enemy fire, an ability that normal crenellated towers did not afford. We had also fudged a bit in our calculations of damage that attackers could do to the castle--for example, we had included mechanics that permitted attackers to shoot down defenders who were inside towers, but in reality, this would have been impossible, since most towers were equipped with arrow slots that allowed defenders to fire out but stopped outsiders from firing in. This week, we went back to the books to cement our understanding of many of these elements and changed their implementation in the game so that they better reflected reality.
In addition to fixing these inaccuracies, we added or updated a number of elements that players could choose to build. For example, while machicolation was an extremely effective method of wall and tower defense, but sometimes resource availability, time, or knowledge might have prevented its construction. The latest versions of our prototype included other options for tower augmentation, like hoardings, which are a sort of wooden version of machicolation, or crenellations, which are simpler to build but provide slightly less flexibility and protection for defenders.
We also experimented with varying the resources available to the player. In the previous iteration of the prototype, the player had three in-game months to build up their fortress in each building phase, but this was the only limiting factor on what they could build. This week, players were required to keep track of how much lumber and stone they had available, as well. Adding this dimension to the game seemed to give the players more interesting decisions to make during the building phase and was overall successful. We also tried adding water as a resource for the creation of moats, but this didn't actually add anything to the game because no playtesters ever came close to running out of water when they started the round with a reasonable amount. We also tried having food as a resource, so that the player would have to build a fortress capable of repelling attackers before food stores ran out, but this added a dimension to the game that we didn't like--we felt that having to worry about food stores took the focus off the actual castle building.
Sadly, since this was our last week of prototyping, there are a lot of potential improvements and expansions that we didn't have a chance to add. Real-life castles were incredibly complex and although our prototype ended up fairly complicated (at least for a paper prototype), it only explored a tiny number of all the possibilities open to us. There are still a number of ideas we wanted to add but never got around to, like bartisans, turrets that projected from walls and allowed an occupant to rain death down upon enemies from all angles while remaining completely protected, or sally ports, heavily protected doors, just large enough for a mounted knight, that allowed defenders to send out sallies to destroy enemy siege weapons. Additions like sally ports would also give the player the opportunity to do something more in the attack phase. Instead of just passively waiting on the outcome of dice rolls, they would have the chance to decide whether to send out a force to attack a trebuchet and how many men to send. This could also add another angle to resource management, either in the form of a new "knight" resource or by requiring the player to decide how many defenders to take off the tower and hold in reserve at the sally ports.
Another idea we never really got to try involves incorporating the differences in castles in different regions and times. The first medieval fortifications in England and northwestern Europe were relatively simple wooden affairs, usually just a large keep on top of hill surrounded by a fence. As time passed, more innovations and improvements were made to the building process, until eventually castles became massive, near-impenetrable fortresses. For example, when people started making towers from stone, it became possible to build round towers instead of square towers, which were advantageous because they didn't have "dead angles" that couldn't be covered by defender fire and allowed enemy forces to attack the walls. It would have been fun to experiment with setting different rounds of the game in different periods and giving players different levels of technology to how it affected their playing and enjoyment of the game.
And, as always, there are still some issues and problems that we have to work out. The attacking army movement and rules for combat and damage still need some tweaking: obstacles, for example, do far more damage than they probably ought to; the trebuchet is probably more random than it ought to be. Towers also give us a little trouble: should players be able to repair recycle rubble from demolished towers in later rounds? What about the scenario where a player puts hoardings on top of a tower, but then later decides they want to build the tower taller? These are issues it would be interesting to address through further playtesting and revision.
Still, we ended our semester with a game that, while far from perfect, is a lot of fun. Players seemed to enjoy not just the opportunity to juggle resources and play with different castle set-ups, they also got found themselves on the edge of their seats during the attack phases, waiting to see if their constructions would hold. Even the GMs who rolled the dice and calculated the damage done each turn became surprisingly invested in the attack phases and the fates of the two sides, given that they had no decisions to make and no input into how the round played out. One amusing development was the way that the attack phase often seemed to play out as a story, players and GMs exclaiming or groaning as parts of attacking armies accidentally impaled themselves on obstacles or when the trebuchet destroyed a tower. The last playtest worked particularly well in this regard, ending in a nail-biter in which a huge invading army was reduced to its last handful of fighters facing off against a single remaining tower of defenders. It looked like a certain victory for the defenders, protected behind their stone walls, but a lucky hit from the trebuchet at the last possible second brought down the tower and the defenders inside. The attackers "won", since they had destroyed the defending army, but in the end there was only one attacker left. Even a couple weeks after that playtest and the end of our work on the castle-building prototype, we still laugh at the image of that single, solitary viking sitting alone in the keep, maybe hanging out with the cows or other farm animals that were the sole survivors in the castle.
The International Game Developers Association (IGDA), in partnership with the U.S. Department of Agriculture, has announced it is organizing game jams in at least six major U.S. cities on the weekend of May 21st to harness the creative and technical capabilities of video game developers in support of the Apps for Healthy Kids competition (www.appsforhealthykids.com).
The game jams will draw game developers, graphic artists, and local youth together to brainstorm ideas and produce video game prototypes from scratch in just 48 hours. The prototypes will be displayed at the sixth annual Games for Health Conference, to be held May 26-27, 2010 in Boston, further refined, and submitted to the Apps for Healthy Kids competition before the June 30th deadline.
The game jams, hosted by the IGDA and the U.S. Department of Agriculture, are a joint initiative of the Games for Health Project and Health Games Research. The Games for Health Project (www.gamesforhealth.org) works to build the overall field of games for health through a variety of activities including the annual Games for Health Conference, which brings together game developers, technology experts, health professionals, researchers, policy-makers and investors. The Health Games Research national program (www.healthgamesresearch.org), headquartered at the University of California, Santa Barbara, provides resources and scientific leadership to the field and supports 21 research projects across the U.S., all focusing on the research and design of effective health games aimed at improving players' physical activity and or their prevention and self-care behaviors. Both Games for Health and Health Games Research are supported the Robert Wood Johnson Foundation's Pioneer Portfolio, which seeks out innovative ideas that may lead to significant breakthroughs in the future of health and health care.
The origins of our castle game date back to the 20th of April. The task at hand was to prototype a medieval castle-building simulator. The core of the game's flow, around which all other mechanics would stem, was to construct a garrison, with limited time and resources, that could withstand varying degrees of assault. We drew from history for much of the gameplay and context, which facilitated our process.
Sara, who came in at the beginning of our session to talk about some of the basic premises, and to give us some reference material, commissioned the project. She wanted the game to be centered on the historical castle's primary function: to serve as a bastion for its subjects.
Our prototype went through several permutations throughout the course of the day. For a game involving what is essentially urban planning, the natural inclination was to design a strategy game where the interface is a birds-eye view of the terrain, with some arbitrary geographical features scattered about the map. After an awkward play-through with this set up, we switched to a two-dimensional elevation of the map, which allowed us to focus on very specific castle building elements, something that had begun to lose relevance in the original over-head view (side views are also quicker to prototype when using grids and dice).
The next configuration of the castle prototype was as follows: The player begins with a keep, drawn on the right side of the map. He/she can then build three additions or "upgrades" to the keep before the turn ends and the enemies arrive. In addition, the player starts with twenty soldiers at his/her disposal. The upgrades, which range from walls to ditches and moats, are designed to increase the number of turns it took for the enemies to cross the map while the player's archers pelt them with arrows.
When the enemies arrive on the scene, they enter from the left side of the map and move unyieldingly along the grid. Within a certain a certain distance of the player's tower (assuming he/she had built one and garrisoned it), the advancing foes begin to receive damage determined by dice roll. Damage is determined by the number of soldiers in the tower. If there are ten, and they make a successful volley, ten bad guys will be neutralized. As the enemies draw nearer to the tower the probability that the archers will deal damage increases. Should the advancing army find itself in a moat, ditch, or upward slope, the player's archers get two dices rolls to attack. If the enemies happen to reach a tower, they spend a turn to breach it and march forth without hindrance from its bowmen.
We followed this blueprint to a great degree for the remainder of the session. Our abstractions, however, began to grow more specific. The player was given three months in game time to fortify his castle. Each upgrade varied in the amount of time they took to build. For example, a wooden wall would take half a month, while a stone wall took twice that. A moat also took half a month, but required a ditch first, and so forth.
We were fortunate to have detailed references of actual castle defense mechanisms, which we readily adapted to our prototype. We allowed the player to make some very specific modifications to their fortress. For example, adding "machicoulis" to your castle enabled your archers to shoot at enemies that were up against the wall. Obstacles such as sharpened planks were cheap, quick to manufacture, and were super effective against invading marauders.
The amount of foes attacking each turn was predetermined and consistent, despite the player's statistics. Difficulty was keyed to the "type" of enemy: the first and easiest force the player faced were an uprising of seventy-five peasants. Peasants could attack the walls of the castle, but could not return arrow fire, and were usually vanquished with relative ease. Next, the player would be set upon by a hoard of pillaging Vikings, who had archers of their own and were capable of ranged attack on the defending soldiers. The second wave of enemies was also usually quickly overcome. By the third turn, however, the player faced an army equipped with catapults, which had a fifty percent chance of hitting his/her towers. Here we introduced hit points for walls and towers, which were respective to the material they were made of. Only at this stage did the enemy pose a real threat to the player, as the siege weapons fired relentlessly at his/her defenses.
Here we began to reconsider the format of the game. Initially, we wanted no input from the player as soon as building ended and the battle commenced. The introduction of some in-battle decision-making might be crucial to combating enemies with engines of war.
At the end of the day we had a basic three-level prototype, but with components that were easy to redesign and reconfigure as we saw fit. Curiously, we began to see very easily how it could be translated into a digital game; there was considerable amount of dice rolling used to determine the outcome of the battles that could be adapted quite simply.
This session saw us continuing to refine our prototype from the previous weeks, which involved five monsters that each embodied one of the five senses. Our existing prototype had some interesting ideas, but there were still a number of problems with it that we needed to work out. In trying to address these issues, we ended up in a very different place from where we began.
The Starting Point
As readers of the previous posts may remember, the basic concept of the existing prototype was that the player navigated across the game board while avoiding detection by the five monsters that also inhabited that space. The protagonist was a shape-shifter, and had a long list of attributes that they could choose to take on. Each attribute could be perceived by one of the five senses, so the player could choose, say, a taste-related characteristic like "salty" or "savory," or a touch-related characteristic like "rough" or "cold", and so on. The five monsters also reflected the five-senses theme of the game, and each of them had only one sense with which to experience the world.
The game board was overlaid with a grid that was divided into large sections, and each section had a set of characteristics or attributes associated with it. Any objects in a section were supposed to have those associated attributes, and if the player did not have the correct attribute for a given area--for example, if the player had the "bitter" taste attribute in an area designated as "sweet"--they would be detected if a nearby monster had the appropriate sense. A player could only take on three characteristics at any time, and so had to judge which would be the best to choose. In addition, the player had to think of an object which had the three chosen characteristics in order to be allowed to use those characteristics.
In playtests, people found the idea of the five sense-monsters intriguing, and often had a lot of fun trying to think of objects that had a certain set of traits, but the gameplay itself was just too simple. There was very little strategy required, and it was usually very easy to avoid detection. In the event that a player did mess up and was discovered by the monsters, the effects of being detected seemed unimportant or inconsequential.
Fixing the Problems: A First Attempt
Our first try this week at fixing some of these problems involved a complete overhaul of the gameboard layout. Previously, players had found that the layout didn't give them interesting choices about which paths to take, and that it was too easy to tell which monsters would be coming in range and which traits would be required in upcoming turns. In the previous session, we had tried to deal with these problems by adding walls and obstacles to make the player's path more convoluted, but--possibly because of the small size of the board that we were using--we never succeeded in creating a layout that players found interesting or challenging.
So, in this session, we got rid of the walls, and instead of requiring the player to move from one side of the board to the other, we set up the board so that the player had to visit each of the four corners to activate four "switches" and then return to the center. We also changed the monsters' movement patterns to make them a little less predictable and a little more likely to run into the player or each other. Finally, we added the notion of health/HP to the game, so that the player would lose 1 HP each time they were discovered by a monster.
These changes were somewhat successful: the open layout of the board and, in particular, the increased unpredictability of monster movement made the player more likely to end up taking a path they had not originally planned on. Also, since it was harder for the player to predict which monster(s) they would encounter in the next turns, deciding which traits to adopt on each turn was no longer so straightforward. Unfortunately, the changes also had an unforeseen, game-breaking consequence: by the time the player had hit all the switches, the game had reached a state where the player was completely surrounded by monsters at the end of every turn, and thus unable to take on enough different traits to fool them all (because the player was still limited to three traits). Indeed, this was the first playtest where the player was unable to win.
A Dramatic Change
By this point, we were starting to suspect that the issues caused by the overly-simple layout and the system of choosing traits were inherent in the current set up of the prototype, and were unlikely to be resolved as long as we stuck with the idea of a player and monsters running around an abstract space divided up into arbitrary sections with associated attributes.
Thus, the next iteration of the prototype was a huge departure from previous versions. We replaced our large grid with a mysterious house that the player had to explore; we got rid of the extensive list of attributes for the players to choose from; and the monsters no longer wandered around freely. We also added a bit of backstory to the game, with the hopes of creating a more motivating scenario for the player.
The new version played out as follows: at the beginning of the game, the player was told that a friend was deathly ill, and the only hope of a cure lay in a set of six magical artifacts that could be found in a strange house inhabited by bizarre creatures (the five sense monsters). On every turn, the player drew a card from each of five piles of cards--each pile corresponded to one of the senses, and each card had a trait written on it. These five traits would be the only ones that the player could use on that turn.
After drawing the cards, the player then chose which of six rooms to enter (the house contained a bedroom, a kitchen, a workshop, a menagerie, a greenhouse, and a library) and rolled a die to see if they were successful in making it into that room, instead of moving from space to space as in the previous version. Then, a series of die rolls was used to randomly determine which of the monsters would also enter the room, and the player would have to choose which three traits they wanted to take on. As in previous iterations, the player also had to think of an object that had those traits. If the player was successful in convincing the "monsters" (that is, the GM) that the object they had transformed into belonged in the current room (a frying pan, for example, would make sense in the kitchen, but not in the library), then they successfully obtained the magical artifact hidden in that room. If they were unsuccessful in thinking of an object that belonged in the current room, the monsters discovered them and the player lost HP. The player lost the game if all their health was depleted, and won if they managed to acquire all six magical items.
There were a few glitches in our first playtest--for example, it was unclear how the dice rolls determined which room the player ended up in, and some of the aesthetic elements were a little confusing (like our forgetting to include doors leading into the various rooms of the house, which didn't help the player's confusion about movement). Minor hiccups aside, though, it appeared that the dramatic changes we had made had had the desired effects, as the player seemed to enjoy the challenge and we didn't get any comments about the game being too simple.
The addition of drawing attributes from decks was also a success: not only did it avoid overwhelming the player with a huge list of possibilities (something that multiple players of previous versions had commented on), our playtester liked that it gave him the chance to think of possible objects ahead of time and then make a strategic choice about which room to enter.
This new version was not perfect, of course. One big problem our playtester had was that he was unable to tell what determined whether an object he came up with would be accepted by the GM. He couldn't figure out what, if any, criteria were being used to judge the ideas, and he felt like anything he came up with would be accepted, which eliminated all tension. There was also still one nagging problem from previous versions that we hadn't fixed, namely, the consequences of being discovered. Losing 1 HP was not interesting to the player, particularly in the scenario we had concocted, where (the playtester felt) there were opportunities for more compelling, narrative-based consequences.
An Unexpected Suggestion
Based on the feedback from the first playtest, we made a number of tweaks to our new version of the game. First, we fixed some of the obvious glitches, like putting in doors (we learned a good lesson about how even seemingly inconsequential design decisions can have significant effects on players and player expectations). We also made the player's movement simpler--now they could just choose which room to go to next, instead of having to roll to determine if they made it to their intended destination. However, we did add another hurdle for the player by concealing the names of the rooms at the beginning of the game, so that the player would not know the identity of a room until the first time they entered it. We also tried to simplify the framing fiction of the game.
We also added to the consequences of being discovered, since the first playtester had felt that just losing 1 HP wasn't enough. This time, when the monsters found the player, the player would be tossed from the house and one of the magical artifacts that they had acquired would be taken from them and randomly placed in one of the rooms of the house, requiring the player to do more exploring to find the artifact again.
Finally, we tried to work out a more concrete system for deciding whether to accept or reject a player's choice of object, but this was difficult--indeed, the problem of how to create an objective set of rules to govern this part of the game was something that had worried us from the very beginning. While it was fine to have a human being doing the judging during the paper prototyping phase, we couldn't see how we would adapt that for a digital version of the game.
In an unexpected development, our final playtester came to our rescue by pointing out that the prototype we had would probably work best as a multiplayer or party game. The players themselves could take on the role of the GM or judge, and decide among themselves whether a certain object should be accepted as appropriate for a certain room or not. In addition, competing against other players to be the first to collect six artifacts would add tension and make the game a lot more interesting than just trying to find those artifacts before you lost all your health.
This idea had never crossed our minds during development, but our tester was definitely onto something. It might mean abandoning our original idea of this prototype as a precursor to a digital game, but it would resolve so many of our issues--it would even allow us to get rid of the problematic health mechanic, since the win/loss state would just be whether it was you or one of your opponents who collected the six items first. By the time we finished that last playtest, it was time to go and we didn't have time to work on the multiplayer aspect that day, but it was definitely an intriguing concept and opened up a lot of new avenues for us to explore.
Final Reflections
We made good progress during this session, and although we were by no means finished with the prototype by the end of the day, we had a fun, playable game and a good idea of possible future paths.
In addition, this week's prototyping also brought home a lesson that was probably good for us to learn: sometimes when there's an aspect of a game that's really giving you trouble, the best thing to do may be quite drastic--you may have to just get rid of it. We were attached to the idea of having the player move their token from square to square across the play space, but keeping that mechanic meant that we were unable to get around the problem of overly simple navigation that it caused. However, it turned out that the ability to choose the character's exact path through the space was not as important as we had believed, and getting rid of that aspect improved the game dramatically. Removing the grid system also freed us from the system of associating a specific set of attributes with each section of the board, a system that all our playtesters found too obvious. It took us two weeks and a certain amount of desperation to reach the point where we were mentally able to scrap these broken mechanics, but it ended up being worthwhile.
For our next prototyping challenge, Drew and Matt asked us to create a prototype based on an idea, a general list of goals and constraints, and a dramatic "minute of gameplay" that describes, in narrative form, how the gameplay should feel. An excerpt follows --
"I survey the floorplan. There are only 5 people left to rescue. I think I can get one more out the window. I click the old man in the rocking chair and take control. He hobbles to his feet and down the hall... the fire is getting closer, so I push into the old drunk in front of me. Things are tight, but the drunk gets on the ladder just in time... the next person won't be able to make it out this way."
This game, temporarily dubbed "Fire Escape," is obviously intended to be a digital experience. The gist of the gameplay is that the player must evacuate five characters out of a burning building. The player takes control of them one at a time.
However, when he evacuates one person and goes back to get another, he actually takes control of the second character at the same time (in the game's narrative timeline) as the first. The actions of the first character he controlled are now programmed into the game, and the first character will go through these actions automatically, alongside the second character (which is currently being controlled by the player).
The ultimate result would be a synchronous evacuation attempt where all five characters are simultaneously going through the motions that had been individually determined by the player's actions. The challenge comes from issues with characters blocking one another or otherwise preventing each other from escaping.
For example, if the first character bolts right for the elevator, that elevator will not be available to the second character if the second character doesn't arrive at the elevator before (or at the same time as) the first. If the first character is slow and is navigating a narrow hallway, a second, faster character who comes up behind them will be trapped behind.
Orchestrating this mass evacuation is a matter of careful planning and coordination. The player also effectively gains foreknowledge of things that will happen in the building - falling walls, collapsing floors, spreading fires - because after taking control of the first character, the player essentially experiences the entirety of the game's timeline - he just goes on to experience it four further times.
We thought carefully about how best to translate this important and innovative mechanic into a paper prototype. Drew had suggested having the trajectory of a character's egress be represented by a drawn line, with multiple paths being drawn simultaneously to determine if they collided. We decided against this for a couple of reasons - firstly, regulating the path and the speed of drawing would be difficult, and secondly, with five characters, there would be too much drawing for one player. We wanted to make the game potentially playable by a single person, so we eventually decided on a very clear-cut mathematical solution:
Spaces were represented by squares. With each step a player took, he or she would mark that square with a number corresponding to the number of turns. For example, the first step would be "1," the next "2," and so on until they escaped through the door on the bottom floor or the window on the top floor. These numbers would then stay on the board as the player navigated the same terrain with other characters. A character could not occupy the same square as another if their numbers were the same, because that signified that they were in the same place at the same time.
Also, falling rubble and spreading fires were designated with numbers as well. For example, a GM would watch the player's progress, and when he had taken his 8th step (when he wrote the number 8 on a square) the GM would declare, "rubble falls on the 8th turn in these squares--" and then mark those squares with an 8, showing that from the 8th turn onwards, that square is blocked by rubble. Fire behaved similarly in that it spread from a single square every few turns. The turn numbers for fire are roman numerals, to distinguish them from other numbers.
Our playtests revealed that this was a quite intuitive way of showing when and where certain events occurred. Players could easily see which options were or were not viable and plan in advance. Even so, the game was still challenging enough to play multiple times. Subtle changes to the layout, or the distribution of rubble and fire, created an entirely new experience.
The end result was not as atmospheric as the game described in the gameplay transcript, but it did accurately translate the core mechanic in an intelligible way.
We were next tasked with a much more straightforward concept - abstract the game of "tag" into a realtime multiplayer game. This proposal, though simple, was actually quite tricky. After all, tag already IS a realtime multiplayer game. How, then, could we condense the typical tag arena -- a yard or playground -- into a game board, keeping the feelings of frantic terror and exhilaration that make tag fun?
We were also required to incorporate an "infection" element into the gameplay, but this didn't concern us as much as the aforementioned issues.
First we began brainstorming mechanics that could be used for the game. Our usual arsenal of dice, poker chips, building blocks, and grids turned out to be ineffectual. We seemed to fall too easily into the rut of making a turn-based, grid-based game. Such a game wouldn't have the appeal of tag.
Tag should be a game that players can leap into impetuously and finish just as quickly. As a team, we were fairly comfortable designing intricately balanced rule systems for our games, but making an elegant one-note design was more challenging.
After we spent a while getting nowhere, we finally decided to just try going for it. We grabbed markers, pens, and a big sheet of paper with the premise that we would all draw continuous lines -- no lifting the drawing implement -- and simply play "tag" on a field of paper. "Tagging" meant catching up to the front of someone's line -- tagging their implement with yours. Even though the game went by very quickly, we immediately perceived that we'd captured the crazy fun of tag on a small scale. Plus, we were left with an interesting record of how the game had progressed.
The one issue was that we were constantly elbowing each other while playing. Looking around for a larger surface, we went immediately to GAMBIT's big frosted-glass dry erase walls. It didn't take us long to realize that we could improve even further on the game by having the antagonist / "it" stand on one side of the glass, while the rest of the players stood on the other.
The lines that "it" drew were clearly visible from the other side, and even became more ominous and terrifying for their disembodiment. When tagged, a player would go join the antagonist on the other side of the wall, creating an effective feeling of isolation for the remaining players while also conveying the concept of "infection."
Our playtests were quite successful, but the game was still over very quickly. We decided to handicap everyone by making them use dry-erase markers with two more markers capped onto the end.
The players must hold the base marker but draw with the topmost one. If he or she drew too quickly, the markers would break off and they'd have to reassemble them. "It" could still tag them by racing to where their line had abruptly "cut off" and scrawling over the end.
We also upped the ante by using post-it notes as obstacles. This again served to extend game time a bit, but in general the game was still over within a few minutes. We decided that this was acceptable, and that the feel of tag had been accurately captured.
Killer 7 (Gamecube, 2005, 10-15 hrs) - A stellar mind-fuck exploration/shooter game, and in my opinion the best work of self-described "punk" Japanese game developer Suda51 (at least of what's been released Stateside). The set-up involves a group of professional assassins--the Killer 7--who all inhabit the body of a wheelchair-bound old man and can only "come out" when in proximity to a functioning television set. The player must make use of their various abilities to take down "Heaven's Smile", a group of invisible, shape-shifting, and apparently skinless suicide bombers who laugh as they explode. While not technically "horror" Killer 7 manages to be scary in ways few horror games are, and the way it weaves (or rather smashes) together science-fiction, occult fantasy, and political intrigue is genuinely surreal. Unfairly criticized as a mere "rail shooter" by its critics, it actually has a nicely designed combat system that recalls some of the best aspects or Resident Evil 4 and Dead Aim. Its spacial navigation system is especially innovative in how it removes virtually all redundancy from the survival horror exploration/puzzle framework, streamlining it into a smooth, slick experience. Suda's signature ultra-high-contrast cel-shaded visuals give the entire game an appropriate neo-noir look. In the name of Harmon. Credits: Goichi Suda (story, writer, director, producer), Shinji Mikami (story, executive producer).
Friday Games: Marleigh's First Person Shooter Rant
Marleigh loves first person shooters. Marleigh is very fussy about her first person shooters. Marleigh is often disappointed with the current state of first person shooters. Why the video game industry has left this genre alone for so long is a mystery to her. Seems like an obvious market niche to be filled.
For this rant, we'll look at two iconic first person shooters--Doom and Duck Hunt--and discuss which of these meet Marleigh's rather exacting standards.
Hint: Marleigh's title at GAMBIT is Lead Interaction Designer.
Michelle Obama's Apps for Healthy Kids competition offers Student Awards
GE Healthymagination is putting forth $20,000 in prize money to recognize student participation in Apps for Healthy Kids, bringing the total prize purse to $60,000. Two GE Healthymagination Student Awards, $10,000 each, will be awarded to the best student-developed submissions: one in the game category and one in the tool category. GE will also provide travel for the winners of the GE Healthymagination Student Awards to a White House event honoring winners in Washington, DC (up to $500 for individuals and up to $1,500 for winning teams). In addition, all contestants will receive some form of acknowledgement thanking them for directing their creativity and innovative spirit to this important cause.
The Apps for Healthy Kids competition is part of First Lady Michelle Obama's Let's Move! initiative aimed at ending childhood obesity within a generation. The purpose of the competition is to challenge software developers, game designers, and students to develop creative, fun, and engaging tools and games that drive kids and their parents to make more nutritious food choices and be more physically active. Submissions are being accepted through June 30, 2010. For more details and the official rules, please visit www.AppsforHealthyKids.com.
Research Video Podcast Episode 3: "How The Zombie Changed Videogames"
In this horrific version of the Research Video Podcast Series, GAMBIT's own Lead Game Designer, Matthew Weise, discusses his paper on "How The Zombie Changed Videogames"
We here at GAMBIT are pleased to announce the release of the Flash implementation of Tipping Point. While the board game has been available for some time now, the Flash version saw several delays, mostly due to a lack of time on the part of myself (something about a thesis needing to be written).
I won't go into too much detail in this post, but Tipping Point is a cooperative, abstract puzzle game designed with four players in mind. In the new release we implemented "hot seat" multiplayer, meaning that the game assumes all four of you are sitting together and playing through the same connection.
However, the game works equally well with fewer players, and even as a solo game it makes for a compelling experience (objectively speaking, of course). Watch this space in the next few days for a more detailed post-mortem of the design and development process.
Terrascope students present and defend ideas and technologies for reducing atmospheric carbon
Terrascope freshman learning community will be presenting their research on specific ways to reduce the concentrations of carbon and other greenhouse gases in the atmosphere. The Terrascopers have been focusing on this problem all year, and during the spring semester they have worked in teams, under the guidance of MIT faculty members, to develop prototypes, models and examples of real, workable solutions.
I've been advising one group of freshmen on their development of a multiplayer card game, in which each country tries to maximize its own economic growth but all have to work together to prevent the catastrophes that could be brought on by high carbon emissions. Some of the other exhibits at the bazaar include:
A working scale model of a system that would inject carbon dioxide into underground aquifers, sequestering it there rather than in the atmosphere.
Alternatives to traditional concrete building materials, created in a way that would reduce the amount of CO2 normally released into the atmosphere during construction.
A prototype of an electromechanical energy-storage system to be located near offshore wind farms, making it possible to have clean energy onshore when it is needed, not just when the wind is blowing.
A prototype of an interactive, participatory museum exhibit, designed to inform the general public about climate change and ways to prevent it.
Don't miss this showcase of MIT students' ingenuity and creativity! Refreshments will be served!
Over January 2009 I was asked by the lab to pull together a small team to design a board game for Sloan professor Nelson Repenning. The design goal was for the game to demonstrate the pitfalls of "firefighting" in project development. Also known as "crunch time," Repenning et al.'s research shows that when companies divert extra resources to a project that is running behind, other projects suffer and will eventually require crunch time themselves. Although companies that regularly engaged in this process were often proud of their firefighting ability, the overall result was a gradual downward spiral that was difficult to escape without drastic measures. This is of course an extremely high-level summary, but it was this general behavior that we tried to recreate in the game.
The game that resulted was Tipping Point. While I am happy with the overall design, there are a few problems that we are aware of but lacking resources (mostly time) to address.
The board game.
First of all, the game is very abstract, and the link between mechanics and fiction is tenuous. In the game each player "owns" one or more projects, and the players must all work together to finish a set number of projects in order to win. Projects are represented spatially: each exists as a growing cross on a grid. Each turn players grow their own projects one space in each direction. If any project grows to the edge of the board it is game over for everyone. If projects collide they combine into a single project that grows faster and is harder to complete. To combat this players place "concept work" or "production work" tokens on the board, preventing project growth. Once a project cannot grow it is completed.
Projects then can be thought of as becoming larger and more unwieldy over time, so in a sense the game represents time spatially. While that is not unheard of (see analog clocks), the link between stopping growth (what the work tokens do) and getting something done (what they represent) is non-obvious. In playing the game it feels like you are just containing the projects, not actually accomplishing something.
The projects themselves are also somewhat strange. As I said before each player "owns" one or more projects at any given time. Ownership is only used to control project growth: projects grow on their owner's turn. While in testing players tend to prefer finishing their own projects there is no real incentive to do so. In other words there is no competitive element, which at this point is the first thing I would add. If players received a score based on when their own projects were finished it would add an interesting competitive dimension on top of a cooperative design.
Additionally, because of how the work tokens function the best strategy is often to delay finishing projects for several turns. Procrastination is generally not considered good project management, and is at odds with the research the game is supposed to support.
All of these issues are related to the aforementioned weak link between mechanics and fiction. Simply put the game could easily be about anything at all (or just remain totally abstract) and it would play just as well, if not better. While we were certainly thinking of the research during the design, there was a certain amount of shoehorning: the way the tokens function feels right for what we were going for, but the names "production work" and "concept work" are pretty awful and obviously forced. As a result the documentation for the board game is very difficult to follow. Part of that is the terminology but also just a lack of time here as well: the rules could certainly be improved but during the semester resources are scarce. I hope to return to them at some point but right now there is no clear opportunity to do so on the horizon.
(If anyone out there is having trouble understanding the rules please email me at jsbegy-at-mit.edu. I will be happy to answer your questions, and knowing what was problematic will help me fix them in the future.)
At this point I personally find the tension between the play experience and fiction just as, if not more interesting, than actually playing the game. As it stands I think the game feels more like being in school than working for a company, which is a result of the way the difficulty progresses. At the start of the game each player only has one project, so there are four in total. After every other project is completed (after the second, fourth, etc.) another project is added to the mix. By the end of the game there will be seven projects on the board at the same time. This works well in that it motivates a certain behavior, but feels more like being in school: as the semester closes the work load ramps up, just as in the game. During my various stints in corporate America I never had quite that experience. Certainly there were busier times than others, but never the same type of extreme ramp-up (adding projects / final exams) followed by a complete stop (winning the game / end of the semester).
Having said all this, I do think it is an interesting game. It is something more of a puzzle than most board games I am familiar with, and the gameplay creates an interesting group dynamic. Because new projects are placed semi-randomly much of the time playing is spent in discussion and planning as players try to determine who should be doing what and when as players balance between focusing on current projects and preparing for the placement of new ones. Discussion becomes such a focus it caused us to include a "turn token," basically a piece of paper the players pass around so they can remember whose turn it is.
I personally still enjoy playing it and am proud of the game and the team. Reactions around the lab were generally positive as well, which lead to the development of the Flash version over the Spring 2009 semester.
Designed as an exact replica, the Flash version attempts to recreate the four-player experience via hot seat multiplayer. As a result it is simple to play by yourself, but at the cost of the group dynamic. We had initially hoped this version might be a way to play with fixes for some of the problems mentioned above: we had many discussions about including a scoring mechanism and changing the fiction to something else entirely, but with an even smaller team than the board game there simply was not enough time. (If at this point you are wondering why you should take time management advice from people constantly running out of time you are probably not alone.)
As it stands the Flash version is much more abstract, using very iconic graphics designed more with usability in mind. For example, in the board game concept work tokens are pencils and rulers, while in the Flash version they are just black circles. This version has not been playtested outside of GAMBIT's QA department, so what difference these graphics will make is currently unclear. I personally am looking forward to seeing player reactions, as my thesis research concerns abstract games and how they are interpreted.
Despite the game's shortcomings, overall I am happy with the design. While playtesting I never got tired of playing, and would find myself forgetting to look for bugs and instead focusing entirely on my strategy. I hope you find it just as enjoyable.
We're proud to announce our beta release of Monsters in My Backyard! Until June 25, you can download a free version of the game by registering for an account on http://www.mimbgame.com/.
