Singapore-MIT GAMBIT Game Lab spacer spacer
CMS MIT
spacer
spacer New Entries Archives Links subheader placeholder
Updates July2009 edging
left edge
About the Archives

This page contains all entries posted to GAMBIT in July 2009. They are listed from oldest to newest.

June 2009 is the previous archive.

August 2009 is the next archive.

Many more can be found on the main index page or by looking through the archives.

pinstripe
Last Chance Open House and Focus Testing: July 30th, 2009!

More Games! More Opinions! More Munchies!

(Well, actually, the same six games that showed at the last open house.. but, now with
two more weeks of work - and they've been very busy weeks!)

When: July 30th, 6 PM to 8 PM
Where: The Singapore-MIT GAMBIT Game Lab, 5 Cambridge Center, 3rd
Floor (aka MIT NE25, 3rd Floor)
(Please introduce yourselves as visitors to GAMBIT in the lobby when you arrive.)

On Thursday, the 30th, please come to our Summer GAMBIT Game Lab Open House, play one or all of six games in development, and give us your opinions! We'll be testing the initial candidates for the release version at the Open House - help us find our ship stopping bugs while the teams still have a chance to fix them!

Feel free to drop by any time between 6:00 and 8:00 to play our games, but arriving earlier will give you the chance to play more games. We do close the lab at 8:00 to let our staff head home after a long day on the job.

One of our games this year is targeted at children aged 12 - 17; we could especially use testers in that age range, if any of you have children and would like to bring them. If you do bring children to test, please contact us before hand, so we can send you a parent/guardian consent form. If you decide to come at the last minute, that's fine too, but before your child plays any games, please contact a member of the GAMBIT staff, so we can give you a consent form to sign.

Please RSVP to gambit-qa(at)mitdotedu, so that we will know how many people are intending to come. We look forward to seeing you!

CarneyVale: Showtime named to the 2009 PAX 10!
PAX 10
GAMBIT's high-flying CarneyVale: Showtime is about to hit a new height: appearing as one of the 10 best games of 2009 at the Penny Arcade Expo!

According to Gamasutra's Leigh Alexander:

Organizers have chosen the 10 best games from over 150 submissions to be showcased at Penny Arcade's PAX consumer event this year, including CarneyVale: Showtime and Osmos.

Now in its second year, the PAX 10 is designed to highlight the efforts of indie game creators working on original, self-funded and self-published, fully playable, non-mod game projects across all platforms.

The developers of the top ten games will be given four exhibitor passes each to the Penny Arcade Expo to be held September 4 to 6, and will showcase the games in a special booth at the show.

The PAX 10 selections are as follows:

CarneyVale: Showtime by the Singapore-MIT GAMBIT Game Lab (Xbox 360)
Closure by Tyler Glaiel and Jon Schubbe (PC)
Fieldrunners by Subatomic Studios (iPhone)
Liight by Studio Walljump (Wii)
Machinarium by Amanita Design (PC)
Osmos by Hemisphere Games (PC)
Puzzle Bloom by Team Shotgun (PC)
Tag: The Power of Paint by Tag Team (PC)
Trino by Trinoteam (Xbox 360)
What is Bothering Carl? by Story Fort (PC)

PAX, organized by popular Penny Arcade comic creators Jerry "Tycho" Holkins and Mike "Gabe" Krahulik, first featured the PAX 10 last year, with finalists whittled down from more than 80 submissions. Last year, Expo attendees chose Twisted Pixel's The Maw as the overall champion.

As longtime fans of Gabe and Tycho, what can we say other than... Woo-hoo!

Summer Program Open House/Focus Test Session: July 16th, 6pm - 8pm

Videogames! Opinions! Food!

When: July 16th, 6 PM to 8 PM
Where: The Singapore-MIT GAMBIT Game Lab, 5 Cambridge Center, 3rd Floor (aka
MIT NE25, 3rd Floor)

On your way in, let the lobby desk attendant know you are attending the GAMBIT Open House.

On Thursday, July 16th, please come to GAMBIT's Summer Program Open House and Focus Testing Session, play one or all of six games in development, and tell us what you think. Our interns have been working hard for the last five weeks, and it's time to get some fresh eyes and fresh opinions on our games. We still have 3 weeks left of our 8 week process, so your opinions and thoughts will make a difference.

If you cannot make this Open House, please consider attending our second (and final) Focus Test session on July 30th, also from 6 - 8 PM.

One of our games this year is targeted at children aged 12 - 17; we especially welcome testers in that age range. (Younger children are also welcome.) If you do bring children to test, please contact us before hand, so that we can send you a parent/guardian consent form. If you decide to come at the last minute, that's fine too, but before your child plays any games, please contact one of the GAMBIT staff and fill out a parental consent form.

Please RSVP to gambit-qa@mit(dot)edu, so that we will know how many people are
intending to come. We don't want to run out of food and drink too early!

Introducing Moki Combat 2.0
Moki Combat v2.0
Prototype
Moki and Rooki are back! Moki Combat 2.0 features a brand new design built around a unique physics engine. It's been a fascinating experience to take the original demo and gradually transform it to the current state. Moki Combat 1.0 was based around arena combat, but as we implemented the new physics we transitioned towards slower almost puzzle-like jousting, switched from arenas to linear levels, and eventually de-emphasized the combat itself. Hopefully I can shed some light on our process and the challenges we encountered along the way.


loadgame_moki_20_03.jpg
More Than Just Ragdoll

The core feature of Moki Combat 2.0 is the physics engine developed by Computer Science graduate student Yeuhi Abe. You may be familiar with "Ragdoll Physics" which is frequently used to simulate falling or unconscious bodies. Instead of being stiffly posed, the limbs of the body move freely. Yeuhi's engine experiments with active control of the character through physical means. This allows a body to support itself and move naturally when force is applied. In other words, rather than having an animation ready for when Moki gets hit by a spear, Moki will procedurally bend and try to right himself in the saddle.

Though it often results in impressively lifelike motions, this model is challenging for several reasons. First, control over the character has to be seriously rethought. Physically simulated characters are restricted to physically plausible motion. As a result, the character will not always respond immediately to user inputs. It's not just a matter of triggering the "Swing Spear Animation." You might notice some of the actions in the game feel a bit sluggish as result. We saw this physical lag as part of the challenge for the player, but some players will likely find it to be frustrating that the character doesn't respond as they might expect.

In order to implement the new physics engine, the physics from the summer had to be pulled completely. Despite parts of the framework remaining, the programmers chose to scrap everything related to physics and basically start from the ground up. For the first few weeks of work on Moki Combat 2.0, there was little more than boxes and balls bouncing around. Yet the framework that resulted was much better than the original. Not being afraid to start over and develop a stronger foundation brought our more complex goals within reach.

The Design Evolution

It was around this time that I joined the team as a designer to better incorporate the new physics into the gameplay. The early prototypes combined the arena combat of Moki 1.0 with object manipulation puzzles. While play-testers enjoyed the look of the game, the actions were too imprecise for most of the object manipulation puzzles. The most consistently praised element was running through a block wall and watching the cubes fall down on top of Moki, pushing him around. I proposed a new jousting mechanic that would show off the natural movement of characters in the engine while adding more precise interactions.

loadgame_moki_20_02.jpg

The zooming, slow-motion joust took many iterations to get right and persisted through all the designs that followed. Yet the challenges surrounding the joust changed a great deal. Given our lack of satisfaction with how the arena combat meshed with the physics, the next idea was to make the game a series of one on one jousting matches. The player would maneuver Moki into position and charge at the enemy. My original designs for the jousting developed into an almost puzzle-like challenge with the player having to observe how the enemy reacted to each blow in order to determine their weak spots. But as we began trying to implement this mechanic, certain challenges arose.

Size Matters Not. Usually.

During the Fall semester, our development team consisted of two programmers (Mark Sullivan III and Igor Kopylov), myself on design, Yeuhi as the product owner, and of course QA testers Jose Soto and Ruben Perez. When implementing new features, we quickly ran into the limitations of having such a small team. In particular, not having an artist meant that we had to make do with existing assets, only tweaking the models' poses slightly. The puzzle-like jousting idea became an impossibility just given the shape and size of Moki and Chawi (the NPC enemy). As we came up with new ideas, we had to find ways to reuse assets in new ways. To create a circular track, a single hut was placed in the center of the arena level and enlarged to fill most of the space.

We lost a coder after Winter Break, but picked up a level designer and 3D artist in Randy O'Connor. Finally we could add new models and levels! His addition to the team came just in time for another major design overhaul. To better emphasize the excitement of jousting and to keep the player always moving, we decided to trade arena combat for gauntlet runs. Dashing through a narrow mountain pass, trying to hit as many targets as possible was an instantly exciting new mode. As soon as we had a minimal demo of this idea, we had our own tournament to see who could score the most points in 2 minutes. We knew we were on to something.

loadgame_moki_20_04.jpg

Yet the limitations of our team size still created a hurdle. Not having the resources to develop our own level editor, Randy and Igor hijacked Maya. Rather than hardcoding all the collision geometry and objects, they created some tools to utilize specially named 3D objects in Maya that would export into the relevant information. A smooth pipeline was created for level design allowing complex levels to become feasible. A difficulty that arose was having to use primitive objects such as cubes, cylinders, and spheres to create free form terrain. Panda3D has limits on stacking material effects so we had to make certain decisions about having shadows, normal maps, or other effects. Despite the limitations, Randy made some great looking levels. A general theme of the development process was finding ways to overcome (or at least work around) our limitations.

As a demonstration of Yeuhi's physics engine, and as a quick, fun, lighthearted experience, we feel that Moki Combat 2.0 certainly succeeded. Throughout the last semester we tossed around various ideas for further small games utilizing these physics controls. Some early prototypes are already underway. Don't expect Moki Combat 2.0 to be the last you've seen of this engine.

Enjoy the game!

Introducing The Bridge
The Bridge
Prototype
Next up in our series of games from the Spring 2009 semester is The Bridge, another arthouse game from Doris C. Rusch, the product owner of last summer's Akrasia. This game, a rumination on loss and mourning, is now available to play. You may want to check it out before reading the following reflection from Doris on the game's creation - there are spoilers ahead! - but definitely do come back and give the following essay a read, to share in Doris' experiences with game design as its own personally reflective, insightful process. -Geoff

The Bridge: Game Design as a Tool for Reflection and Self-Exploration


by Doris C. Rusch

The Bridge is a short, single player Flash game, made during the spring semester of 2009 by a team of students. I was the product owner and lead designer of this project. Although I have my doubts regarding The Bridge's qualities as a game (for which I take full responsibility), I still regard it as one of the most interesting works I've ever done. The focus, however, is on "work" as in "process", not the result. Working on The Bridge showed me what a wonderful tool for self-reflection and insight game design can be. The following is an account of how using the tools of my craft helped me and two of my team members to more clearly map out our emotional landscapes. Feel free to try this at home!

The Bridge screenshot


Guided by Images

Saying I wanted to make a game about "mourning" or the connection between "love" and "fear of loss" would be bullshitting (Def. bullshitting: terminus technicus for making a process appear intentional and focused in hindsight when it actually was not). So, let's just stick to the dirty truth of how it really went.

It started with an image of an empty tire swing that suddenly bubbled to the surface of my subconscious but never quite made it into the more analytical realm of my mind. The image didn't come with an explanation, only with an emotional overtone of loss, frustration and hoping against hope. A bit like a cone without ice cream, a tire-swing is a sad affair when it just hangs there without a child on it. Of course, one can take either image both ways: as a promise for future fun or as the memory of past pleasures. In the moment my mind decided to release the tire swing from its swampy depths, I gravitated towards the darker reading of it. But why a tire swing? Why not a more traditional metaphor for loss, such as a gravestone or a couple dressed in black, huddled together under an umbrella?

How I would love to be able to give a clever and coherent explanation now. But I vowed to adhere to honesty and will thus further refrain from bullshitting. The best I can do is share the stream of associations with you that (to me) accompanied the tire-swing metaphor.

Imagine being the one pushing the swing with the child on it. You push, you watch the swing perform the familiar motion, you wait for it to come back to you, and you push it again. The "here-gone" dichotomy strongly resonated with me. The necessity of letting go of the swing in order for it to fulfill its purpose (i.e. provide a pleasurable experience for the child) and at the same time distancing yourself from the precious freight it carries, experiencing a moment of anticipation (anxiety?) before the swing starts to come back, and the relief upon its safe return. But this relief is not really due to the return of the swing, but to the return of the child on it. In most cases, these two things are coupled. While the cycle of the swing will not be interrupted as long as one keeps pushing (what goes up must come down, right?), it is possible to lose a person forever. Fate is less predictable than physics. If the swing is "gone" it will transform into "here" again. A person, once dead, will remain gone. Child and swing - once fused together - are indeed separate entities; they can part ways. The stubborn mind, however, is reluctant to dissociate the two. The swing has always brought the child back, so maybe pushing an empty swing will magically return what has been lost. But some things cannot be changed, no matter how hard we push...

The Bridge screenshot


The Initial Idea

The interactive piece I initially envisioned (I wasn't even going to call it a game!) was strongly inspired by this crude image of an empty tire-swing and the foggy feelings of loss and mourning I associated with it. The player would enter an empty space with nothing but a swing in it and nothing to do but to push it. Pushing the swing would produce faint laughter and the transparent outline of a child would become visible on the swing. The implied goal would be to push until the child materialized completely. In truth, no such thing would be possible, though. The player would have to realize that all her efforts were for naught, that there was no way of bringing the child to life and that the only way to "win" was to accept that and walk away. In order to make this (emotionally) difficult for the player, every time she stopped pushing, the child would fade again, the laughing would grow faint at first, then maybe turn into whimpering (good audio would be required for this or instead of inducing guilt, the whining would create the wish to quickly leave the wretched child behind).

The Bridge screenshot


Using "The Tools" for Self-Exploration: A Conversation With The Inner Game Designer

When I talked to my friends Jaroslav and Eric about this initial idea - both very game savvy - they saw the potential for an emotionally compelling experience. However, they thought it should be more "gamey". I was reluctant at first. The simple tire-swing sequence felt so right that I wanted to do it exactly as I had described above. And then, they popped the Question (yep, it deserves the capital letter): "But what exactly is this about?" Mourning, clinging, loss, attachment - whatever I said to explain it didn't quite capture it. I couldn't put it in words. Since I'm strongly advocating purposeful design, not knowing my own mind was a problem. How can I purposefully create an experience for someone else if I don't understand my own feelings?

This had to change. I decided to follow my friends' advice and make it more "gamey". Because although the game itself can be ambiguous and allow multiple interpretations, coming up with the rules forces the designer to be precise and concrete. I started to explore what I already had in mind in terms of game elements. Here's a rough transcript of the dialogue I had with what I call my "Inner Game Designer" (IGD):

IGD: What exactly is the GOAL?

Me: To "let go".

IGD: A goal without CONFLICT makes for a lousy game. So what is the conflict? What makes "letting go" difficult?

Me: Attachment makes it difficult.

IGD: What creates attachment?

Me: Hm...love?

IGD: So, the way to overcome attachment is to overcome love?

Me: I don't think so. That would be terrible. Love is important.

IGD: Are you sure it is love, then, that bothers you? Maybe it's fear?

Me: Oh yeah? Well, what do YOU know?

IGD: I'm you, remember?

Me: Attachment and fear. Fear of losing love. You cling because you are afraid...

IGD: What exactly are you afraid of?

Me: Haven't I just said that? Afraid of losing love! Isn't that obvious?

IGD: Aren't you a bit negative?

Me: Don't play the Eliza trick on me!

IGD: All right, I'm sorry - couldn't resist. Seriously now, why would losing love be bad? It sounds like love serves a purpose.

Me: It protects...makes you feel good.

IGD: And since you don't want to lose what makes you feel good, love itself creates fear. It is both the curse and the cure, it seems.

Me: That's right. Fear creates clinging, you want to stay close to the "love object".

IGD: May I point out that you don't seem to have internalized love? It's this outside thing on which you depend. That attitude will always kick you in the butt.

Me: You're my inner game designer, not my freaking therapist.

IGD: Seems like pretty much the same thing to me...

I will spare you the rest of the conversation because it involved giant flying puddings and the monster with 14 toes, neither of which had any relevance to The Bridge. But you can see how the concept had dramatically evolved from the simple initial idea to a system that tackles the mechanisms of a certain kind of love and the problems that come with it. What was still lacking was an idea of how to overcome those problems, to get "unstuck" and break the pattern. Obviously, you had to fight your fears so you weren't dependent on your love object anymore and could love it in a more selfless way. And then what?

It was at the speakers' party at this year's Game Developer's Conference in San Francisco when Trey (the game's producer) and Jamie (code and animation) approached me with the words: "we have been thinking." Sitting in front of cocktails called "The Game Designer" or "Achievement Unlocked", they spoke to me of closeness, emancipation and sacrifice in a serious and insightful way. We pondered how the game could end. We knew the goal, we had grasped the conflict. Now we had entered the final stage of the process: finding a solution. What happened when you killed the monsters that represented your fears? What happened to the girl that represented your love object? What exactly would "letting go" look like? It was Jamie who dumped the solution in my lap: every monster you killed would help form a bridge across the river that divided the playground (the game's main space) from the untended field (representing an unknown future). I loved the symbolism that the road to a better future was paved by one's conquered fears. We further entertained the rather disturbing idea that the girl would sacrifice herself to complete the bridge, that her (self-inflicted) death would produce the last missing piece. We let this sink in. Nah...no good, since it would undermine the emancipation process which depends on taking responsibility for one's actions. So, maybe the player had to kill the girl before the bridge solidified? No, no, no! Not reconcilable with the idea of selfless love! We finally agreed that to win the game, one would have to kill all the monsters in the playground and refrain from "reclaiming" the girl on the tire-swing. The bridge would solidify upon the death of the last monster and one could cross it. Crossing the bridge would "free" the girl (she'd dissolve into a could of particles). This should not mean that one abandoned love itself, but had overcome functionalizing it.

The Bridge screenshot


The True Reward Was The Journey

My team had an equivalent of two 40-hour work weeks to develop this game. This is not a lot of time, but they did an amazing job. Our biggest problem, however, was that the theme was so personal. If a project is too big, you can always scope it down. But if you are very invested in the concept you want to convey, to do it justice and get it right, the problem starts much sooner than scope. It starts with understanding what exactly you want to model.

We tried something big with The Bridge. Too big, maybe, for the given timeframe. I felt bad for a while after our last official work session, because how can you close the book on "love" and walk away feeling like you've accomplished anything? Also, eighty hours of development time do not leave a lot of room for tweaking and polishing and thus many of the ideas in the game are still latent and could be communicated to players more clearly.

But then again, I have learned a lot. The process of designing this game made many things apparent to me, helped me map out some of my emotional landscape. In that regard, The Bridge was a huge success. It confirmed my belief that while making profound games that tackle the human condition is a worthy goal which I will keep pursuing, game design itself can be a wonderful tool for insight that greatly enhances our understanding of ourselves.

right edge