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

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

September 2009 is the previous archive.

November 2009 is the next archive.

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

GAMBIT Halloween Party!

luigis-mansion.jpgJoin us this Friday at 4:00pm where we will be playing a variety of Halloween-themed and related games!

Day of the Tentacle
Luigi's Mansion
Castlevania and Dracula X
Zombies Ate My Neighbors
Halloween Harry
Left 4 Dead

One Happy Kitty

Now here's one happy kitty...


Thanks for reading everybody! See you next Monday with an all new Game of the Week!

Full Color Pierre and "The Man"

Here is a full color version of Pierre with "The Man."


More coming right up!

A Thorough GDD

Here is the GDD for Pierre: Insanity Inspired. The team did a good job of keeping a fairly updated and thorough game design document for reference.


Come back for more!

Pierre and the Man

Here is a sketch of Pierre and the mysterious "Man" who yells at you.


More coming right up.

Pierre Character Sketch

Here is another sketch of Pierre in action, jumping!


More coming up!

Team Logo Concepts

Here are some variations on the Rundown team logo!


See you tomorrow!

Perception = true

So development with Visual3D is actually going relatively smoothly now (sort of).

I was having a problem with creating the halo object for the game. I was trying to create an object that would trigger an event whenever the player walked over it (ie intersected with its bounding box). I was creating an object like normal: create it, set it's position, add it to the scene. This however, was not working.

I posted to the forum and a Visual3D developer helped me out! It turns out that I was creating the object incorrectly (my original was was technically correct, but a bug in Visual3D was causing the problem). The new way also involved adding my object to the assets library of the main Visual3D architect program.

The other problem was discovered by Drew who suggested looking for some sort of flag that would tell it what entities to "percept". It turns out that buried in the object was an item called EntityFlags.perception which when set to true, allowed the objects to be percepted. I set this to true and followed the advice of the developer and it works!


Creating the object:

// These two lines are the ones I used instead of halo = new Halo()
// and halo.Spatial.RelativePosition = new Vector3(-10f, 0f, 20f)
halo = (Halo)SEntitySystem.Create("halo", "Halo", new Vector3(-10f, 0f, 20f));
halo.Enter += new IntersectEventHandler(HaloEnter);

halo.Name = "halo";
this.Spatial.AddChild(halo); // Adds the object to the scene
halo.Enter += new IntersectEventHandler(HaloEnter); // Adds the trigger event
halo.IsFlagActive = true;
halo.IsVisible = true;

The other changes I had to make:
add the line:
this.EntityFlags.Perceptible = true;
to the OnActivated() function of my main character's class.

right click on the entities folder of the Asset Library in the main architect. The context menu that pops up has "Add Custom Type". Select that and add Halo as a new type.

Triggers and colliders

I've been trying to import the Abandon meshes into Unity, but it appears I need a new version of Maya installed, so while I'm waiting I've been fiddling with the Chaser script, which makes random objects chase the player through the maze.

When I first implemented the chasers, I simply had them chase the player when the player bumped into them. I had to add a coroutine to make them wait first, or they would simply have stuck to the player immediately, but this was just a temporary fix; the goal was to have the chasers follow the player when the player got near them, rather than actually touched them. This is when I began to have trouble with triggers and colliders.

A Collider component attached to an object uses Unity's physics functions to detect when the object has hit another object and react accordingly. Each Collider has a boolean variable called isTrigger, which designates it as a trigger. An object has separate functions for what to do if it hits a collider and what to do if it hits a trigger. The problem is that when a collider is designated as a trigger, it no longer seems to perform the usual collider function of making sure the object bumps into other objects instead of ghosting through them. I've tried attaching two colliders to an object and making only one a trigger, but this gets complicated very quickly and I'm not sure it really works.

Part of the problem was that I had already designated the halo as a trigger, so I had to make a distinction between the player triggering the halo and triggering a chaser. I tried making the player the trigger, which failed because I still needed it to have collider functionality. This is the point at which I tried giving the avatar two colliders, which caused the problems noted above.

At last I got it to work by making the chaser a trigger and telling the player to send the chaser a signal to chase it when it hit the trigger. Then I went back to the original Abandon game for reference and realized that the range at which the player triggered a chaser was going to have to be variable, making it necessary for the player to be the trigger after all.

To avoid the double-collider problem, I took advantage of another change I would have to make to match the original version: attaching the point light to the player rather than the halo. While it's possible to attach a light component to an object,m which was what I had done with the halo, in this case I found it more convenient to create a point light and make it a child of the player. I then made the point light the trigger, which also allowed me to simultaneously adjust the light level and the trigger range, just as the original game did. The biggest problem after that was figuring out how to adjust the collider radius of the trigger from a script, since only some types of colliders (such as SphereCollider and CapsuleCollider) have a radius at all. I made it work by casting the collider type:

((SphereCollider)collider).radius = light.range;

Also, this is a relatively minor hassle, but it's worth knowing: while two colliders bumping into each other causes both to call OnCollisionEnter, if a collider bumps into a trigger, the other object (not the trigger) is the one that calls OnTriggerEnter.

Concept Menu Page

Here is a concept menu page featuring our intrepid hero Pierre!


See you in a little bit!

Stage Background Concepts

Here is some beautiful concept work of backgrounds for stages.


More coming right up.

Pierre Storyboard Page

Here is a more refined, color page from an early Pierre storyboard.


More coming up soon.

Final Cat Sketches

Here is a final set of cat sketches. After playing the game, you can see which of the sketches the team liked best!


More coming up soon!

More Kitty Sketches

Here are some more preliminary sketches of Pierre the Cat!

Pierre_Sketch_03.jpg Pierre_Sketch_04.jpg

See some more content soon!

First Cat Sketches

Here are some of the first sketches for Pierre as a cat.

Pierre_Sketch_01.jpg Pierre_Sketch_02.jpg

More coming up!

11/2/09: Purple Blurb presents Mary Flanagan

Critical Play: Radical Game Design
6pm, Monday 11/2/09
MIT room 14E-310

Disembodied headMary Flanagan is the author of Critical Play: Radical Game Design (MIT Press, 2009), creator of [giantJoystick], and author of [theHouse] (among other digital writing works).

For many players, games are entertainment, diversion, relaxation, fantasy. But what if certain games were something more than this, providing not only outlets for entertainment but a means for creative expression, instruments for conceptual thinking, or tools for social change? In Critical Play, artist and game designer Mary Flanagan examines alternative games--games that challenge the accepted norms embedded within the gaming industry--and argues that games designed by artists and activists are reshaping everyday game culture.

Flanagan provides a lively historical context for critical play through twentieth-century art movements, connecting subversive game design to subversive art: her examples of "playing house" include Dadaist puppet shows and The Sims; her discussion of language play includes puns, palindromes, Yoko Ono's Instruction Paintings, and Jenny Holzer's messages in LED. Flanagan also looks at artists' alternative computer-based games, examining projects from Persuasive Games and Gonazalo Frasca and other games created through the use of interventionist strategies in the design process. And she explores games for change, considering the way activist concerns--among them Darfur, worldwide poverty, and AIDS--can be incorporated into game design.

Arguing that this kind of conscious practice--which now constitutes the avant-garde of the computer game medium--can inspire new working methods for designers, Flanagan offers a model for designing that will encourage the subversion of popular gaming tropes through new styles of game making, and proposes a theory of alternate game design that focuses on the reworking of contemporary popular game practices.

About the Author
Mary Flanagan, artist and game designer, is Founder and Director of Tiltfactor Laboratory and Sherman Fairchild Distinguished Professor of Digital Humanities at Dartmouth College. She is the coeditor (with Austin Booth) of Reload: Rethinking Women + Cyberculture (2002) and re:skin (2002), both published by the MIT Press.

About Purple Blurb
Purple Blurb offers readings and presentations on digital writing by practitioners of digital writing. All events are at MIT in room 14E-310, Mondays at 6pm. All events are free and open to the public. The Purple Blurb series is supported by the Angus N. MacDonald fund and Writing and Humanistic Studies.

The Walls

Thank goodness for cork-board walls.

Scrumboard1.jpg Scrumboard2.jpg

More coming soon!

QA Survey

Here is a survey developed by our QA lead for one of our playtests. If you would like, you can print it out, take the survey at home, and join in the fun!


Stay tuned for more stuff!

Location confirmed: Clint Hocking at GAMBIT

Clint_Hocking.jpgThe Territory is not the Map: Hyper Realism and the New Immersion Paradigm
Wednesday October 28, 2009
4-5 PM | Singapore-MIT GAMBIT Game Lab

Clint Hocking, Creative Director at Ubisoft Montreal, will be speaking at the Singapore-MIT GAMBIT Game Lab this afternoon at 4pm. The lab is on the third floor of 5 Cambridge Center. (Google Map)

Features List

Here is an early feature list for the game. You can see on the chart that we used a system of S,M,L, and XL to attempt to scope a specific feature.


Come back after lunch for more!

Character Silhouette Sketch 2

Here is another set of silhouettes for the "new" Pierre character.


See you soon.

Character Sketch Silhouettes

Here are a set of character silhouettes for trying to find a new character. When the team abandoned the Mother Earth idea, they were looking for some new inspiration for a main protagonist.


Come back later today for more exclusive goodness.

11/04/09: Eran Egozy presents the Harmonix Story

eran.png6.078 (The Founder's Journey) presents a special presentation by Eran Egozy, the co-founder of Harmonix Music Systems. Eran will be speaking at the Singapore-MIT GAMBIT Game Lab on Wednesday, November 4, 2009, from 3:30pm to 5pm.

Eran will talk about how Harmonix got started, what he and Alex Rigopulos did at the MIT Media Lab that sparked the big idea for Harmonix, and describe the long road leading up to Guitar Hero and Rock Band. He will also discuss what they learned about making their products appeal to mass market through their early games, and how they use consumer feedback to develop their products. He will conclude with a overview of the brands of Rock Band and The Beatles and their influence on the Harmonix brand. (Check out this New York Times article for background information on The Beatles: Rock Band.)

Eran is an accomplished musician who brings extensive technical and musical expertise to the Harmonix management team. He earned his B.S. and M.S. degrees in Electrical Engineering from the Massachusetts Institute of Technology. He then conducted research on combining music and technology at the MIT Media Lab; which led to his co-founding Harmonix with Alex Rigopulos. Eran now manages the company's engineering staff, directs intellectual property development, contributes to game design, and helps drive corporate strategy. As a musician he's performed frequently in MIT's Balinese Gamelan, Chamber Music Society, and Symphony Orchestra, and currently spends much of his spare time playing clarinet in Boston's Radius Ensemble and other local classical music groups. He also mentors local entrepreneurs by giving talks and working with organizations such as TechStars, The MIT Enterprise Forum, and the MIT 100K competition. In 2008, Eran and Alex Rigopulos were named in Time Magazine's list of the one hundred most influential people in the world.

6.078 The Founder's Journey is a class about finding and activating your entrepreneurial energy. What road are you embarking upon in starting a company, and what obstacles threaten your success? What else and who else will you need? If you want to start a company, 6.078 will give you the chance to live the steps to bring that passion to fruition, with substantial exposure to mentors and leaders from the business community. You'll learn by doing. We'll have guest speakers who have travelled this path, successfully and unsuccessfully. Although we will cover the basics of new venture creation, this is not a class about how to write a business plan. Rather it's about grasping the essence of the journey you're about to undertake. This class will guide you to rigorously think about the challenges you'll face in building a business. It will teach you to appreciate and nurture the intangibles that make the entrepreneur special. Even if you're not ready for a startup, this class will provide an exploration of leadership, innovation, and creativity as seen through the lens of a startup founder. We'll gain a broader insight into turning any novel vision into action.

World Sketches

Here are some sketches for "The World" according to original game design ideas for Pierre:


See you all tomorrow morning!

Original Storyboard

Here is an original storyboard from when the game was about pollution and the earth:


More coming up soon!

Falling Stuff

At one point the team was brainstorming objects that could fall from the sky to threaten the protagonist. Here are some sketches.


Come back soon!

Mother Earth

At one point Pierre was going to be about Mother Earth defending herself from trash and pollution. The team worked on a few personifications of Mother Earth in illustration form. Here is one of those:


See you soon.

Another Stage Concept

Here is a very beautiful early concept for a game stage.


See you in about an hour

Early Stage Concept

Here is a piece of concept art for an game stage early in the design, shortly after the team decided to use a circular platform for the game.


Please come back today for some more Pierre content!

One More Character Sketch

Hey y'all, here is one more character sketch from the early pre-production phase of Pierre. At this point we had a hunch we were making some kind of a platformer, but we didn't have a clear game design yet:


See you folks tomorrow!

Translating NPC Drives to Behaviors (Weise Zombie Project)

Last time I talked about the three basic behaviors any NPC might undertake on its own--seek out resources, find a place to hide, or fight zombies. I also mentioned we had come up with a variety of personal character traits for any NPC that might affect their desire to undertake any of these three actions.

Progressing onward, we wanted to look at how specific situations (like those that could conceivably arise within game-play) might alter these characteristics and, thus, the NPCs behavior.

Let's begin our exploration with a few examples using the basic drives of an NPC, as discussed in the last post.

Lack of resources

In an extreme case, the lack of basic resources will cause an NPC to lose the will to survive (extreme drop in S -> loss of interest in all activities. Similarly, this may cause severe irrationality in the NPC. 'Irrationality' itself is a vague term, so we go further to define what this might mean for an NPC.

  • An NPC may have greater will to fight (engage danger, D) at the expense of other life or gaining the resources they need
  • It may be less likely to follow orders, even if it 'likes' or 'trusts' another player
  • It may lose interest in others and wander on its own or fail to follow the group (G)
Mental/ Physical Ailments

Any physical or mental shock will obviously affect stamina. These afflictions may decrease an NPC's likelihood to join group (may not be 'up for it'). It may increase an NPC's willing to sacrifice itself for the group. Specific ailments (like diabetes) may increase the NPC's demand for resources.

Higher Level Needs

Unsurprisingly, higher level needs (Social, self-actualization, etc) tended to generate more complex behaviors in our own imaginations.
For instance, if an NPC was predisposed to disliking a character of type 'B', the NPC...

  • Will distrust characters of this type

  • Is less likely to save type B's from danger

  • Is not likely to follow type B's

  • Has a higher likelihood of setting type B's up/ sacrificing them

  • May lie to type B's

  • May withhold resources from type B

Similarly, if Sarah loves Joe and Sarah is killed, Joe might

  • Lose the will to live

  • Stop all actions

  • Hate another character for not doing anything

  • Seek revenge (zombies, character)

  • Lose trust for another character

  • Sacrifice himself

  • Save her at cost of others

  • Stop Zombie Sarah at all costs

  • Try to recover Zombie Sarah to rehabilitate her (impossible)

  • Become obsessed with other distraction (coping mechanism)

Assigning Drives to NPCs (Weise Zombie Project)

After getting a basic rundown of Matt's game idea, our group began to attack the problem of how to assign complex behavioral drives to non-player characters (NPCs). We began by looking at at Maslow's hierarchy of needs:

Maslow's Needs.png

From here, we came up with a variety of character needs, which could conceivably drive behavior.

Physiological/ Basic Needs: Food, water, shelter, clothes, health (mind + body), reproduction (sex), sleep

Safety/ Security: Protection in numbers, protection from specific group members (leader), hiding place/ safe house

Social needs: Companionship (See mental health), friends, family (Love), trust, 'Us vs Them' (families, class, race, religion)

We worked backward from Matt's description of the game and our brainstormed character needs to come up with three basic 'behavioral desires': searching for resources (like food and water), seeking shelter (either hiding places or safe houses), or fighting


An NPC will prioritize these behaviors based on a variety of internal characteristics (which can be affected by their temporary emotional state). For example:

Brashness: An NPC has some innate predisposition to engage danger (D)
- A low D means the NPC will avoid fighting at all costs
- A high D means the NPC will actively seek out fighting

Stamina: NPCs have some innate drive
- A high S means the NPC will easily undertake the action they desire most
- A low S means the desire to undertake any behavior falls, leaving the NPC fairly inactive/ unlikely to undertake any behavior

Dependence/ Independence: NPCs have some innate predisposition to group up (G)
- A high G means the NPC will closely follow other NPCs/ the player
- A low G means the NPC will not likely follow other characters and may wander off on its own if already in a group

The player may influence an NPC's goals by 'ordering' them to do one of the three basic behaviors
- The likelihood that an NPC will alter its behavior based on the player's commands depends on some internal characteristic trait 'O'

Together these traits and basic desires govern the more complex behaviors NPCs will undertake throughout the game.

Chaos Sketch

Early on the team liked the idea of having a game with a chaotic and crazy feel. This sketch shows some early playing around with this notion:


See you very soon!

More Early Character Sketches

Here are some more sketches for game characters from early in production:


Come back soon for some more exclusive content!

Another Early Sketch

The Pierre team spent a lot of time working with concept art trying to lock down a style for the game.

Here is another early character sketch showing two styles that were looked at by the team:


Come back soon for more!

Early Character Sketches

Before Pierre was a cat, he was something else completely. Here are two early character sketches for the game:

PII_Character_Sketch_1.jpg PII_Character_Sketch_2.jpg

See you soon!

New GOTW: Pierre Insanity Inspired

We have a brand spanking new Game of the Week (GOTW) this week, since, yes, it is Monday.

CUTSCENE 4 small.jpg
Pierre: Insanity Inspired

Start off your week right by having some stranger you don't know heckle you while you play a game, that may or may not make you feel psychotic.

Head over here to check it out, and head over here to watch the video podcast triumphantly kicking off this weeks content!

Game of the Week - Pierre: Insanity Inspired

Final Dearth Concept Painting

Here is a final, beautiful piece of art from Dearth! It is from very early in production, but it is fun to imagine what other directions the game could have gone in. Such creative teams!


If you have not played Dearth yet, go do so now! Check it out, it is lots of fun!
See you next week for an all new GOTW!

Usability Milestone Screenshot

Here is a "usability" milestone screenshot with some elementary UI elements, and a slightly more refined art style.


See you soon.

First Runnable Screenshot

Here is a screenshot from the first "runnable" prototype for Dearth. It is interesting to see what ideas remain consistent across iterations, and also how much work goes into each milestone delivery.


See you after lunch!

Screenshot from First Playable

Here is a screenshot from the first playable version of Dearth, only a few weeks into the development cycle.


Please do come back soon.

Moving is crazy.

So, we finally got movement to work correctly in Visual3D! It involved a lot of banging my head against the keyboard, but eventually we found the solution.

The movement I had implemented previously didn't support diagonal movement (which was bad).

The main problem that I was running up against was that the game maps the WASD keys to moving forward, left, backward, and right automatically. There is no way to stop this (that I've found), and no way to override this. I think it's hidden in their source code somewhere (which we don't have access to). But basically this meant that when trying to intercept the call I was having trouble.

The solution ended up being pretty simple actually. In some commented out code of theirs (tons of code in Visual3D's examples is commented out, I don't know why), we found a reference to TransformSpace.World which was being used in an acceleration object.

Acceleration objects are applied to an actor and that makes them move. Pretty simple. The problem I was having is that once I rotated an actor, the accelerations were using their own frame of reference and therefore going in strange directions. In addition, I wasn't sure how to figure out if the actor was already moving, so I was trying to use a system of getting key inputs and keeping a keyboard map in memory.

The solution was actually to, first of all, tell the accelerations to work in the World.Transform basis. The second part was to calculate the direction from the actor's PhysicsBody object, which stored the current LinearVelocity of the actor. Using this, I was able to make some spiffy quaternions and rotate the actor in the correct direction.

So, the moving works. However, it is very strange that the source code is mapping WASD to directions, and I can't do anything about it. When trying to implement my own KeyMaps, it seemed to work differently than their own. It would be nice to know how keyboard input really works in Visual3D.

Another Set of Sketches

Here is another interesting set of sketches from Dearth.


See you folks tomorrow!

Rain God Silhouette Sketch

Here is a sketch of various rain god silhouettes.


One more for today, coming soon!

Friday Games at GAMBIT: Procedural Level Generation with Darius Kazemi

Darius.jpgThis Friday, Darius Kazemi from Orbus Gameworks and Boston Post Mortem will present a talk on the procedural content algorithms of Derek Yu's Spelunky, and we'll play some other games with procedural level generation (that are not roguelikes!) such as:

Dwarf Fortress
Infinite Mario
Strange Adventure in Infinite Space
Left For Dead
The TIGSource Procedural Generation Competition
Yoda Stories

Main Menu Sketch

Here is a layout sketch for the main menu.


Please come back soon to see some more Dearth material!

Art Style Guide

This is very interesting. Before you is an art style guide for Dearth. You may find it surprising that a team with an 8 week development cycle would take the time to create an art style guide, but in our experience, taking the time to be clear and to create useful documentation to help the team communicate is always a good idea!

Art Style Guide_Team 6.pdf

See you in a few.


Here is a fun one to start your morning.

This file was described as "Left Hand Scribbles." Interesting idea to see what your off hand might give you!


More coming up soon!

Some More Concept Art

This is an interesting mood that shows the game with the final characters depicted.


See you folks tomorrow!

Team Work Photos

Here are a couple of photos of the team workspace.

Photo_1.jpg Photo_2.jpg

More later today!

More on the zombie game we brainstormed

We (or at least, I) liked the idea of having zombie infestations across multiple eras. Here's a game that would take advantage of that setting. You control a zombie horde. Your means of controlling them is represented by an arrow that you may move around the edge of the screen and orient as you'd like. When you click, you unleash a stream of zombies upon the gamespace in the center of the screen. Somewhere in this gamespace there is a historical figure that you must try to zombify. Around him are buildings, people, obstacles, etc, that all influence the movement of your zombie horde. You must, almost in puzzle game fashion, figure out a way to overcome these obstacles to get to the person you want to zombify. Here's a quick mockup. Gray dots are zombies, purple squares seem to scare them away, X is their target.

Zombie Mockup.JPG

This type of game may also lend itself well to the "play three games, design one" idea (see post about unicycle bears and zombie sharks). Each successive era would have a toolset of buildings and obstacles that provide more and more of a challenge (Angry cavemen < angry French peasants < angry man behind MG42 < Predator missiles, hut < mansion < palace < white house < army complex of the future). You would design levels with a drag and drop interface, with an allowance of a certain number of items. As you played further and/or as your levels were played and provided a challenge, you unlocked more eras and therefore could design more and more complicated/challenging levels.

More Zombies

Matt Weise came to our prototyping group asking us to come up with ideas for a game he wants to develop. A game about ...? Zombies of course.

The main idea: you define a set of behaviours for zombies. You define a set of behaviours from humans. You drop humans and zombies in a virtual town. Hopefully interesting and believable interactions emerge between humans and zombies.

Zombies are easy to figure out. Humans, not so much. The zombie setting serves to drastically limit the range of possible human behaviours that we need to consider (no one takes time to work out, play piano, go to the museum, walk in the park, etc... in a zombie apocalypse). What's left are relationships between people (A loves B, so he will do stupid things to try and save B), information about your surroundings(there's a safe house over there? I'm going to tell my friends and we'll go hole up in there!), and information about what you can do (If I put gasoline, bacon grease, and motor oil in this bottle, stick an oily rag in it, call it a molotov cocktail, light it, and chuck it, zombies die? Sweet! I'm going to tell my friends!)

The challenge is defining a manageable set relationships and information that characters can have, and then model the spread of information from human to human and a believable set of behaviors that stem from relationships between humans. We'll see what we come up with.

GUI Sketch

UI is sometimes taken for granted. More specifically, the hard work it takes to design good looking, coherent, and functional GUI.

Here is a sketch for some of Dearth's GUI elements.


See you in a little bit!

Team Blog Post

Introducing: Dearth!

Water is disappearing from the land of Dearth, and no one has the answers why. The only clue is the sightings of strange creatures, roaming through the stricken fields and forests. In desperation the people turn to Dearth's two greatest shamans, who must jointly confront the beasts and solve the crisis of the land.

What? Can't find a friend? Play with the AI sidekick!

Dearth is an action-puzzle game designed for two players. But you're not out of luck if you can't find someone to play with you. There is the single player mode, where the second player is replaced by an experimental AI developed by our product owners, Tomas Lozano-Perez, Leslie P. Kaelbling and Lee Wee Sun. Or if you prefer a challenge, you can attempt to play Two-As-One and control both players at once in two player mode (Current High score: Alec Thomson, Level s 1 through 20, 12 minutes 30 seconds).

The Development of Dearth
All things considered, Dearth was technically challenging to develop. We found that using in-house libraries isn't always the best solution. Pixel Perfect collision detection is not always perfect for the job. There was also the issue with AI files being huge (many megabytes) but that was resolved (they are now each less than a megabyte).

'Bad AI, BAD!'
The greatest hurdle to make the game address our research was getting the AI, which was made for a turn based game, to operate in a real time environment. At the beginning of the game, the AI would run into walls, get the human player or, worse, not move at all.
Which is why we were stunned to find that we were no longer able to get the AI killed at the end of the project, even while intentionally trying, on some levels.

The Design of Dearth
We had to make sure Dearth was a simple enough game to learn to play, yet complex enough to hold their attention after they had figured out our mechanics. Our levels individually aren't long and we wanted to give replay value to our players through smash combos and achievements.

I think our game art speaks for itself. I personally find it to be gorgeous.


Here is a picture of our self motivated and inspired team.
Back left: Andrew (GAMBIT embedded staff), Tomas and Wee Sun (product owners), Victoria (artist), Mushfique (programmer), Nick (designer).
Middle row from left: Alec (lead programmer), Pin Xun (producer), Leslie (product owner), Jeffrey (the one who breaks all things).
Front row: Benjamin Chua (programmer), Benjamin Chee (artist), Aaron Chong (audio).


King of Soda, Alec (Lead Programmer)


King of Pop (tribute), Nick (Designer)

Bug Study

Here is a bug study sketch from Dearth!


Come back soon.

Birds of a Different Feather

Here is a piece of concept art with two vastly different ideas in it.

On the left, some kind of alien and a gooball of some sort.
On the right, companions in love.
Two very interesting ideas for a game with an AI sidekick!


See you folks tomorrow!

Exploding Gooball

Here is concept art of an exploding gooball. Gross. You can see how this plays out in the final version of the game.


More stuff coming up soon.

10/28/09: Clint Hocking speaks at GAMBIT

The Territory is not the Map: Hyper Realism and the New Immersion Paradigm
Wednesday October 28, 2009
4-5 PM | Singapore-MIT GAMBIT Game Lab

Clint_Hocking.jpgThe games of today unsurprisingly strive to mimic the linear, authored structures of previous generations of media largely because gamers and game developers have grown up in a world where those media are culturally dominant. That is changing. As our media become more richly interactive and as our experience of the world becomes increasingly fragmented and parallelized, a new media culture is disintegrating the old. Games of the future will reflect this cultural shift by themselves becoming more fragmentary, more parallelized, and less focused on rich simulation and traditional notions of immersion.

This talk examines the potential long-term future of gaming by looking at the accelerating convergence between rising technologies and competing media from the internet, games, music and narrative media to augmented reality and the prominence of portable wireless devices.

This talk is free to the the MIT community and the public. If you are planning on attending, please email so we can ensure enough seating for everybody. The location of the talk may change; please check updates on the GAMBIT blog.

Clint Hocking has been working at Ubisoft Montreal since July of 2001, when he began his career in the game industry as a Level Designer on the original SPLINTER CELL. During development he also took on the roles of Game Designer and Scriptwriter. Splinter Cell was nominated for seven Game Developer's Choice Awards (including nominations for Excellence in Level Design, Game Design and Scriptwriting). Along with writer JT Petty, Clint was honored for his writing work on the title with the first-ever Game Developer's Choice Award for Excellence in Scriptwriting.

Clint continued to develop the Splinter Cell franchise as Lead Level Designer, Scriptwriter, and Creative Director on SPLINTER CELL: CHAOS THEORY - the highest rated Splinter Cell to date with an aggregate review score of 94%. Clint next took on the role of Creative Director on FAR CRY 2, a controversial title that took players into the 'Heart of Darkness' of a fully realized African state torn apart by civil war. Both innovative and acclaimed, Far Cry 2 was another hit for Ubisoft.

In addition to working as a game developer, Clint is also active in the game development community, and is a vocal proponent of games as an emerging medium and art form. Clint is on the Advisory Board of the Montreal IGDA Chapter, and is a frequent speaker at the Game Developers Conference and other conferences around the world. He maintains a blog at

Clint Hocking sits on the advisory board of the Singapore-MIT GAMBIT Game Lab.

10/29/09: Richard Rouse III - "Cinematic Games"

Thursday October 29, 2009
5-7 PM | MIT Room 4-231

Richard_Rouse.jpgMany people talk about "cinematic" games, but what does this really mean? Over their century of existence, films have been using a range of techniques to create specific emotional responses in their audience. Instead of simply using more cut-scenes, better script writers, or making more heavily scripted game experiences, game designers can look to film techniques as an inspiration for new techniques that accentuate what games do well. This lecture will present film clips from a number of classic movies, analyze how they work from a cinematic standpoint, and then suggest ways these techniques can be used in gameplay to create even more stimulating experiences for gamers, including examples from games that have successfully bridged the gap.

Richard Rouse III is a game designer and writer, best known for The Suffering horror games and his book Game Design: Theory & Practice. He is currently the Lead Single Player Designer on the story-driven FPS Homefront at Kaos Studios in New York City.

The CMS colloquium series is intended to provide an intimate and informal exchange between a visiting speaker and CMS faculty, students, visiting scholars and friends. Each week during the term, we host a figure from academia, industry, or the art world to speak about their work and its relation to our studies. These sessions are free, open to the public, and serve as an excellent introduction to our program.

We also record these and broadcast them to the world-at-large via our Podcast. You can also download the individual files by clicking the links from each entry.

More fun with Unity: parenting and refining keyboard input

The walls finally work! For a while I could make the player stay upright and have it walk through walls, or I could have it bounce off the walls, but I couldn't make it just stop. However, it turns out that increasing the drag coefficient keeps the avatar from skidding away from the wall, and increasing the avatar's mass keeps it from flying off into space when it hits another object.

I also made some progress on parenting. In Unity, one object can be set as the "parent" of another, meaning that moving the parent object will move all the children as well. In Abandon, the player has to find and pick up a halo before exiting the level. I had already learned how to make one object the parent of another from the video tutorials, but I couldn't figure out how to do it from a script.

It turns out that you're not supposed to directly make one object the parent of another; you're supposed to make the transform of one object the parent of the transform of the other object. So the code looks something like this:

Transform t = other.transform;
t.parent = transform;

Along the way, I found another useful function: OnTriggerEnter. If I check isTrigger in the collider for the halo, then when another object collides with it, both of them will run the OnTriggerEnter function (if they have one). This saved me the bother of having to write a script to figure out if the player and halo are in the same position; Unity does it for me.

It does seem like pretty much every function I want to use is already built into Unity somewhere. The hard part is finding out how to do it! Which brings me back to keyboard input.

In my last entry, I discussed using events and the OnGUI function to process keyboard input. That was fine as far as it went, but when I read Caryn's last entry, in which she mentioned that her avatar couldn't move diagonally, I realized that I had the same problem. Since the only way I knew how to handle keyboard input was with OnGUI, and OnGUI runs when an event occurs (such as a key press), the program could only deal with one key at a time. First I tried to rectify this by storing a "move" vector as an instance variable, adjusting it according to keyboard input, and running the actual movement in the Update function, but that didn't help. Then I tried handling KeyUp and KeyDown events separately, but it didn't work because holding down a key creates a series of KeyDown events, so the avatar moved faster and faster but didn't stop because there were so many more KeyDowns than KeyUps.

I keep having the same recurring problems with the Unity documentation: it's hard to find the function you want, when you do find it it's not always clear how to use it, and while there are a few cross-references on each page, most pages don't link to all the other pages that it would be useful to know existed. It's the third issue that came into play here: if the documentation had more cross-references, it wouldn't have taken me nearly so long to find Unity's other methods of handling keyboard input. The Input class's function GetKey(KeyCode key), for example, returns a boolean stating whether the specified key is being pressed right now. Once I knew it existed, I used GetKey to check the arrow keys and made the Update function create a new movement vector every frame, based on which key(s) were pressed. Not only did it work for both straight and diagonal movement, the motion was smoother than before. Here's the final code from Update():

Vector3 move =;
if (Input.GetKey(KeyCode.UpArrow))
     move = move+Vector3.forward;
if (Input.GetKey(KeyCode.DownArrow))
     move = move-Vector3.forward;
if (Input.GetKey(KeyCode.RightArrow))
     move = move+Vector3.right;
if (Input.GetKey(KeyCode.LeftArrow))
     move = move-Vector3.right;

A Very Interesting Early Sketch

Here is an interesting early sketch from one of the artists on Dearth. It shows that they were looking in a lot of different directions for an overarching game narrative.


See you in a about an hour!

Another Sketch

Here is another early sketch with some interesting ideas.


See you soon.

Dearth GDD

Here is a GDD for Dearth. It is nice to see how detailed of a document the team maintained given only an 8 week development cycle.


More later today.

More Concept Paintings

Here is another great concept painting from early ideas for Dearth:


Come back soon to see more.

Another Concept Painting

Here is another beautiful concept painting:


Love the balloons! More later today...

10/30/09: Reminder - Student Explorer Grant

Turn your ideas into a business venture -- Receive up to $50,000 funding
Presented by the SMART Innovation Centre

Do you have an exciting game or web application? Do you want to be an entrepreneur? The Explorer Grant will assist individual students or groups of students explore further development and commercialization of innovative games and web applications originated by them. The Explorer Grant will provide up to $50,000 in funding to develop commercial prototypes, evaluate go-to-market strategies so that your game or web application can be licensed to an existing company or form the basis of a start-up company.

The Explorer Grant recipients will also be provided with business expertise, guidance on intellectual property, and networking opportunities with the Singapore and international venture capital community.

US teams may receive up to US$50,000, Singapore teams may receive up to S$50,000.


Full time undergraduate or graduate students at:

  • Massachusetts Institute of Technology
  • Nanyang Technological University
  • National University of Singapore
  • Singapore Management University
  • Nanyang Polytechnic
  • Ngee Ann Polytechnic
  • Republic Polytechnic
  • Singapore Polytechnic
  • Temasek Polytechnic
  • Other Singapore institutes and recent graduates can be considered

You must identify a faculty member at your institute to act as a Faculty Mentor.

You can work in student teams or individuals. If working as a team, a team leader must be identified. Teams from multiple institutes/universities can be formed.

Submission Process

The proposal must be submitted electronically to by 30th October, 2009, 5pm, Singapore time.

Grant application form is available at

Important Dates

  • 14 September 2009: Grant submission opens
  • 30 October 2009: Grant closes, 5pm (Singapore time)
  • 30 January 2010: Award Grant

For inquiries about the grant program, contact Howard Califano at or visit our website at for more information.

Game of the Week - Dearth

This week's Game of the Week is Dearth. Click the banner up top, or click here to check out great behind-the-scenes art and documentation from the game, including a new video podcast featuring our Technical Director Andrew Grant!

Early Concept Art

Here is a beautiful piece of concept art from early in the design process:


More great stuff in about an hour.

Early Dearth Sketch

Here is an early sketch for Dearth:


More coming up soon.

Game of the Week - Dearth

Here is the video podcast interview with Andrew Grant, Gambit's Technical Director and the embedded staff member for Dearth:

More great Dearth stuff coming up soon.

Shadow Shoppe - Postmortem

Hello and welcome to the Shadow Shoppe!

Shadow Shoppe is a game created to research on how people associate different types of traits to body shapes.

A major mishap has occurred in a small town: the people of that town, including the player, have somehow lost their shadows. The player is 'assigned' to be the shadow maker's assistant to help create and return the shadows to the townspeople.

We encountered many different challenges in the making of this game. At the beginning of the project, we had no idea how we were supposed to create a game that collected data like a survey and yet was fun and entertaining for players. One of the greatest problems we faced was the lack of a right answer for our ideas: we did not want a game that would force players to think and answer in a certain way and we understood the importance of gathering accurate data.

Initially, we wanted a multiplayer game that friends could play together but due to time constraints, we had to rule it out.

In the end, the idea we liked and adhered to for Shadow Shoppe was to judge players based on their own decisions.

Art and Audio
We understood, based on our research question, that in order to gather information on the shapes of bodies alone we would have to present them as perfect silhouettes. The solution we arrived at was the idea of shadows, and from that point we tailored a fictional world around that idea, with the intention that it would engage the player visually and conceptually.

The process of finding an art style for the project was a matter of assessing our own strengths, styles, and desires, as well as drawing on inspiration from a variety of sources. Our artists set out to establish the mysterious, Victorian-era fairy-tale feeling by drawing on ideas from movies like Howl's Moving Castle, Kiki's Delivery Service, The Triplets of Belleville, and the Nintendo DS game Professor Layton and the Curious Village. Though it was important to us that the game feel wholly it's own. In the end, it was vitally important that the art and story elements of the game come together to draw the player in to the world of Shadow Shoppe. It was clear that a large amount of our game's strength and interest originated from the pure concept itself, and so it was important to do our part to live up to the interest and mystery of that first sentence: "Once upon a time, the people of a small town lost their shadows..."

Furthermore, the art style greatly influenced the music. It was our aim to evoke mixed feelings of mystery and playfulness to some extent through our game's music. The theme of Shadow Shoppe is rather specific, therefore choosing the proper genre of music for the game was very important. Our sound engineer drew inspiration from composers like, Joe Hisaishi, Michael Giacchino, Django Reinhardt, Dean Martin, Klezmatics, Nicolo Paganini and a couple more. The music also had to draw the player's attention and feeling to the concept of the game.

Final Outtakes

Here are some final audio outtakes from Shadow Shoppe. More failure communication.

This is the last post for this week. We hope you enjoyed looking at the behind-the-scenes content from Shadow Shoppe. If you haven't done so already, please go play the game, and we'll see you bright and early Monday, with a new video podcast, for a brand spanking new, fancy, shiny, Game of the Week!

More Audio Outtakes

Here is some more audio from the recording of the failure communication in the game. We had a good time recording this stuff...

Please come back for more soon.

Audio Outtakes

Here is an audio outtake from the recording of the narration for the intro cinematic to Shadow Shoppe. Great voice-acting!

More soon.


Here is a sketch of some bottles for character traits. I think it is interesting how the bottles themselves sort of "embody" the characteristic!


Come back soon for more!


Visual3D's community is awesome. This is mainly due to the fact that there are people involved with the development of Visual3D on the forum actually answering questions. I asked a pretty simple question, and a mod offered to forward it to a developer. A little while later, they answered my question perfectly.

This degree of help may stop when Visual3D gets out of beta, but by then hopefully there will be more documentation as well as more high level users on the forum besides the developers.

So now my person moves (almost) the way I want them to. The only bug is tha I can't seem to figure out how to make them go diagonally... I might have to send the keyboard input to the avatar directly, instead of through the system they have set up for handling avatar movement. Hopefully though, I can find something that can handle keyup events.

Friday Games 10/16 -- Tim Schafer ROCKS!

This week's Friday Games celebrates the ROCKTOBER release of Brutal Legend, the heavy metal game by those twin GODS of ROCK: Tim Schafer and Jack Black!

To celebrate, we're going to take a look back at Schafer's work, beginning with
his days at Lucasarts up through the founding of his own company, Double Fine.
You will be ROCKED by:

- Full Throttle
- Grim Fandango
- Psychonauts
- Host Master and the Conquest of Humor

and finally...


P.S. You must be metal to attend. For help on how to be metal, follow this link.

Unicycle riding ninja bears fighting zombie sharks with marshmallow guns

That sounds like a great idea!

After we decided to give traumatizing cats a break, we're back to brainstorming game ideas. The title is the one-too-many-th idea that came out of our last brainstorming session. Though I do think with a heavy dose of faux-serious humour, it could be quite a good game.

Here's my favorite idea from our current session: You're a rage-infected human. You infect another person. And another. Soon, you're controlling a little band of, rage-infected humans. You run through the city, enlarging your horde. Now there's two places this can go. Either this is a Katamari Damacy type game and the camera pans further and further out until you're controlling an enraged mass that overtakes cities, then countries, and then the entire world (and then aliens show up and you infect them too and then you go planet to planet infecting the entire galaxy (or maybe that's too much)).

Or, each level is set in a different era, and your goal is to amass enough infected to make it through the defenses surrounding a certain historical figure you would like to zombify. Imagine running through a revolutionary France inspired level (Zombie Marie Antoinette), a civil war era level (Zombie Lincoln), or an ancient Egypt level (Zombie King Tut... wait...) Who says that zombie infestations rage infections always have to happen in the late 20th early 21st century?

Another idea - you have to fight off progressively more absurd procedurally generated apocalypses. Maybe tower defense style, maybe first person.

First it's rats. Then zombie rats. Then bears. Then zombie rat-bears. Then sharks. Then ninja sharks. Then zombie ninja shark-rats. And eventually unicycle riding zombie ninja bears with marshmallow guns. And so on.

And here's one that's been bothering me. I think it would be cool if there was a game such that for every three levels you played, you created a level, which was then used to populate other player's games with levels. The better you play through levels, the more points you earn to create more elaborate levels. The more you play, the more you get fed more elaborate levels. The concept is fine - but what kind of game fits into that concept? Maybe you have a bank of creatures. They have different costs and the amount of points you have is limited. Any creature you create starts at point A and you have to destroy something at point B. Between A and B there are obstacles that block and harm you. You must create the right types of creatures and guide them to circumvent/destroy these obstacles and eventually destroy point B. But this doesn't give any sort of compelling game to play when you have to create a level. Placing obstacles doesn't leave that much room for creativity. I need to think about this one more...

More on Unity3d

Still wading through the Unity documentation. Today's project: incorporating keyboard input. Finding the relevant pages in the Unity documentation was fairly easy; I searched for "key" and found KeyCode, which led me to the Event class. However, it took a while for me to figure out how to use the Event class because the relevant pages did not provide any sample code. I tried using Event objects in the Update function and kept getting errors. Eventually I figured out that whenever an event occurs, the script runs the OnGUI function, so I had to access the event from there. Example:

// If a keyboard event occurs, print the key pressed
void OnGUI(){
        if (Event.current.isKey){
                KeyCode k = Event.current.keyCode;

Once I had keyboard input up and running, I wrote a simple program to move the avatar using the arrow keys. So far, so good. The next step was restricting the avatar's movement. For the Abandon game, the player needs to stay within the bounds of the maze, so I set up a few test walls:


Unity has a lot of physics functions built in. Most objects automatically have a Collider component, so all I had to do was add a Rigidbody component to the avatar to make it unable to walk through walls. Unfortunately, in this case the physics functions were a little too accurate for my purposes; when the avatar hit a wall, it bounced off the wall and fell over. Next step: figuring out how to make it stay upright.

Some More Interesting Photos

Here are some more interesting photos from the team room. When working on a game about archetypal silhouettes, it is naturally important to start by looking at silhouettes.

Team_5.jpg Team_6.jpg Team_7.jpg

More coming up soon.

Down Time

Here are some team photos from "down time." Everybody needs to relax sometime...

Down-Time_1.jpg Down-Time_2.jpg Down-Time_3.jpg

See you tomorrow for some more.

Daily Stand-Up Meeting

Here is a video of a stand-up meeting from near the end of the production cycle. Though it is a little tough to hear, I think it shows nicely how our "scrum-like process" works with our different teams.

See you soon for some more.

Boston Globe: How Video Games are Good for the Brain

Emily Anthes writes in the Boston Globe:

"Video games are hard,'' said Eric Klopfer, the director of MIT's Education Arcade, which studies and develops educational video games. "People don't like to play easy games, and games have figured out a way to encourage players to persist at solving challenging problems.''

"Until now, people have been asking can you learn anything from games?'' MIT's Klopfer said. "That's a less interesting question than what aspects of games are important for fostering learning.''

Klopfer is currently conducting research to determine how important narrative is in an educational physics game: Do students learn more with a more narrative game?

Play Waker and Woosh, the latest pair of educational games GAMBIT developed for the Education Arcade!


I finally got box collisions to work, it turns out I was missing the line "PhysicsSettings.SetPhysical(true)" which actually turned on the collision physics for the walls... I found it by digging through their examples of working vehicles and avatars. I really wish they would have some documentation... or commenting.

There are almost no comments for their methods with hidden source codes. This makes it hard to figure out what I'm supposed to be doing with them.

Another One

I'm telling you, they were everywhere. All smiling, and making that "Yipee" sound. Gave me the willies.


I promise the next post won't be another smiling cardboard box.

Happy Shadow Box

Here is a happy shadow box. For about 4 weeks our office was filled with the little critters.


Kwaheri ya kuonana.

Focus Testing Results

Here are anonymous numerical results from a Shadow Shoppe survey from a mid-project focus test. I think from looking at it you can see what some of the early concerns were for the developers.

Focus Testing Results.pdf

More stuff soon!

More Fan Art

Here is some more fan art of Shadow Shoppe's dashing protagonist.


Catch you on the flip-side.

Menu Screen Concept Art

Here is some concept art for the Main Menu screen. You can see the obvious seeds of the animated final version in this work:


One more for today, coming right up!

Shop Keeper Sketches

Here are sketches of the Shoppe Keeper:


Please come back soon.

MIT's Undergraduate Research Opportunities Program Celebrates its 40th Anniversary

The MIT UROP program celebrates its 40th anniversary this month on October 29th! What's a UROP you ask? It's more than just another MIT acronym. It stands for Undergraduate Research Opportunities Program. The program is designed to provide undergraduates the opportunity to contribute to vital and cutting-edge research during their studies at MIT as research assistants, via direct funding from the UROP office, sponsored funding from MIT departments, labs, and centers, or for credit. Amazingly, many students supplement their already large course load with hours working on research with MIT faculty and research staff.

The Singapore-MIT GAMBIT Game Lab has hired all of its MIT (plus 1 Wellesley and 1 Harvard) student game developers through MIT's UROP program. Since the lab began developing game prototypes in 2007, we have employed 46 undergraduate students each semester, IAP period, and summer (many of whom multiple times) to work on our games and research projects. In the lab today, 23 MIT undergrads are working on projects as UROPs (yes, acronyms at MIT can apply to people too!). Many of these students are new this semester and do not yet have a development credit to their name; this will change come December when we publish their work from the Fall. Some of the students graduating in 2010 will have worked with us through all four years of their undergraduate career!

I would like to express my thanks to both the MIT UROP Office for their work with providing research opportunities to MIT undergraduates and the 46 undergraduates who have worked with us these past three years. These students have been the heart and soul of the US Lab - serving as a valuable constant (of quality, of morale) as the lab transitions each year from Fall to IAP to Spring to the Summer program and to the next year.

Information about applying for a UROP with us and a list of our past and current UROPs are after the break!

Shadowbox Logo Concepts

Here are some concepts for the Shadowbox team logo:


Come back for more!

Scrum Board Photos

Here is a scrum board. Scrummy, ain't it?

Scrum1.JPG Scrum2.JPG Scrum3.JPG

So long, fare thee well.
Pip! Pip! Cheerio!
We'll be back soon!

Shoppe Keeper Color Study

Here is a color study for the Shop Keeper (Shadow Maker).


More stuff soon.

10/19/09: Jeff Norris (NASA) presents at CSAIL

Date correction: 4pm - 5pm, Stata Center, Kiva/Patil 32-G449.
Refreshments at 3:45pm in 32-G449.
Hosted by Daniela Rus from MIT CSAIL.

What do driving robots have in common with Pac-Man? How can we explore space with a video game? Many video games are marvelous achievements in human-computer interaction that enable untrained players to use sophisticated controllers to take control of complex systems. This talk explores the surprising similarities between video games and mission control software and the inspiration that can be found in their juxtaposition.

Dr. Jeff Norris is the supervisor of the Planning Software Systems Group. His group develops operations systems for a variety of space missions including the Phoenix Mars Scout, Cassini Saturn Orbiter, Mars Reconnaissance Orbiter, and the Spirit and Opportunity Mars Exploration Rovers -- for which his team was co-winner of the 2004 NASA Software of the Year Award. He is currently leading the development of the uplink system for the 2009 Mars Science Laboratory Rover mission and operations software development within NASA's multi-center lunar Human Robotic Systems technology development project. Jeff founded the JPL OPS Lab, an advanced agile development facility for the design, development, and deployment of mission operations software and human-robot interaction technologies. Jeff helped operate the Spirit and Opportunity Mars rovers as a Tactical Activity Planner during the prime mission. He received Bachelor's and Masters degrees in Computer Science from MIT and a Ph.D. in Computer Science from the University of Southern California.

For more information please contact: Rebecca Yadegar, (617) 253-5817.

Game of the Week: Shadow Shoppe

Our Game of the Week series continues with a look at Shadow Shoppe, our survey-in-a-game featuring character silhouettes and the personalities we associate with them. We'll have more concept art, design documents, and more behind-the-scenes stuff uploaded to the Game of the Week section every few hours.

Also check out our YouTube Channel for video podcasts from GAMBIT staff!

Shadow Shoppe Podcast

Jason Beene talking about the making of Shadow Shoppe:

Team Photo

Here is a team photo, including adorable boxes:


More for you tomorrow. See you then.

Hard at Work

Here is the team hard at work:

Team_1.jpg Team_2.jpg Team_3.jpg

More coming at ya round the corner!

Some Funny Shadow Shoppe Fan Art

Here is some Shadow Shoppe fan art another artist made in appreciation of the game. Pretty hilarious.


More good stuff in about an hour and a half!

Shadow Shoppe High Level GDD

Here is a high level GDD for Shadow Shoppe that outlines the proposed innovation and potential risks with the project.


Come back soon!

Shadow Shoppe Game Logo Designs

Here are some designs for the Shadow Shoppe game logo:


Check back soon for some more exclusive content!

Shadow Shoppe Character Sketches

Here are some character sketches from Shadow Shoppe:

Character_Sketch_1.jpg Character_Sketch_2.jpg

More stuff in about an hour.

More Sketches

Here are some more sketches from Shadow Shoppe


See you tomorrow.

Shadow Shoppe Docs

Here is a game design document from Shadow Shoppe outlining proposed gameplay features:

Gameplay Features.pdf

And here is a look at some departmental file size budgets for the game:

Game File Size Budget.pdf

Not the flashiest stuff, but all a part of the process. Come back in a little bit for some more.

Friday Games at GAMBIT: Four Player Madness!

Two's company, three's a crowd, and four is madness! (So is Sparta, I hear). We'll be playing a variety of the best fast-moving four-player crowd-pleasers.

Selections include:

  • Goldeneye

  • Power Stone 2

  • Mario Kart 64

  • Smash Brothers Brawl

  • Castle Crashers

  • Bit.Trip Beat

  • Bomberman Live

  • Dr Mario Online Rx

Come join the fun Friday from 4:00pm until 6:00pm at GAMBIT. We can be found on the 3rd floor of building NE25 (aka 5 Cambridge Center).

Beautiful Sketches

Here are some more sketches for Shadow Shoppe:

Sketch_1.jpg Sketch_2.jpg

See you soon!

Silhoutte Study

Shadow Shoppe is about silhouettes. Here is an interesting early silhouette study for the game:


More content, coming right up!

Some Shadow Shoppe Concept Art

Here are some pieces of concept art for the Shadow Maker's Shadow Shoppe:

SS_Concept_1.jpg SS_Concept_2.jpg SS_Concept_3.jpg

More Shadow Shoppe stuff in about an hour!

Visual3d, part 1

I've spent the last few days trying to beat Visual3d into submission, and so far I have a "lizardman" representing the main character, an infinite plane, a box, and a car. The controls are working pretty much the same as in Abandon (I think...). Pretty sweet, I know.

Here is what I have discovered so far:

The tutorials and documentation for Visual3d are frustrating and incomplete. There are two situations when trying to use it:

1. A tutorial exists, but it is too old to be useful. Apparently Visual3d just released a new beta making all of their old stuff not very useful. Also, most tutorials that exist are focused around using the GUI rather than the coding behind it.

2. A tutorial will be coming "soon". Usually, these say things like "Coming in September 2008!" or something like that.

The Visual3d community is very good however. I posted a question about terrain and had it answered quickly and well. The person who answered is very involved in Visual3d, so there are some good experts who are willing to help you with even beginner problems.

Some of the help is useless. Someone will ask "is it possible to do this?" and will get the answer "yes" by someone without any instructions or hints or anything. Usually someone else will come by though and give real help.

Good Idea
The best method I've found so far of figuring out what is going on is to look at the provided Tech Demos and see how they coded their scenes. This is the way I figured out how to do most of the things in my code.

What I need to do now:
- Make it so my main character can't run through the box.
- Make it so the character actually turns in the direction of travel rather than strafing.

Game engine survey!

The Game Engine Survey is a UROP project to test different game engines and evaluate the pros and cons of each. We will be working with Visual3d, Unity3d, and TorqueX.

I've been playing around with Unity recently. It seems like it has a lot of useful functions, but they're not always easy to find. The website's video tutorials are helpful, but they really just cover the basics, and sometimes leave out useful functions that the makers of the tutorial presumably took for granted. For example, in some of the videos, the scene view shows the environment from the same perspective as the game view--which it would be nice to know how to do, except that the tutorials don't seem to mention it. Also, the script documentation has at least one inaccuracy: they claim that the output from print statements appears at the top of the page, by the play/pause/step buttons, when in fact it appears at the bottom.

The script functionality seems fairly well-documented, once you get around the obstacle of writing in C# when the manual uses JavaScript. I'm still figuring out all the functions, so more on that later.

Concept Art-splosion

Okay, here is a bunch of cool stuff for the last post of the week.

First, here is a Storyboard pdf. Storyboard v2.pdf

Here is a Character study:

Here is a Woosh concept environment with influence from Mononoke.

And finally here is an absolutely gorgeous environment sketch.

Thanks for reading this week, and see you next Monday, bright and early for a new GAME OF THE WEEK!

Hard at Work/Scrum Board

Here they are, Poof, hard at work.


And here is a trampled Scrum Board.


One more this week, for Waker and Woosh.

More Waker Concept Art

Here are some more environment concepts for Waker.


A few more for this week!

Some Waker/Woosh Press

A nice article was written about Waker in Lianghe Zaobao, a Sinpapore newspaper. Chuang Xuejin, Waker's producer, wrote a translation and kindly photoshopped it into the original image! Too funny.

Here are the two versions:

Lianhe Zaobao_5Sep09_Pg11.jpg Thumbnail image for Lianhe Zaobao_5Sep09_Pg11 ENGLISH.jpg

More stuff coming right up.
Some More Abstract Concept Work From Woosh

This is some beautiful stuff. I swear, you could frame it, hang it on your wall, and nobody would suspect that it is concept art from a video game!


GAMBIT, where fine art and games violently collide.
Come back for more.

Waker Woosh Postmortem

Here is a postmortem by Sara Verrilli about the challenges and successes of the "embedded staff" role in our project workflow:


Every summer, GAMBIT runs an eight week game development program for undergraduate students, primarily from Singaporean universities and polytechnics. This year about fifty interns joined us, forty of them from Singapore and the rest from local colleges and universities in the Boston area. This was the third summer for GAMBIT's program, but it changes a bit each year, and 2009 was no exception. For the first time, each team had its own audio designer, rather than sharing the efforts of a three person audio team. Secondly, three of the teams had a grad student from our CMS program join them. And, finally, each of the teams was given an embedded staff member from the GAMBIT staff.

What exactly is an "embedded staff member?" Well, according to our summer planning paperwork, the embedded staff member serves as a team mentor, role model for the producer, overall team advisor, and the primary channel of feedback and criticism from the GAMBIT staff and product owners to the team. The embedded staff's job (or ES, as GAMBIT abbreviated the title) is explicitly not to run the team, provide game design, or make decisions for the team. Unless, of course, one of those things became Necessary, and what conditions constituted Necessary were heavily theorized but never actually specified. And so, with a clear mandate but fuzzy responsibilities, the summer began.
My team was Team 5 - Poof Productions. Their research goal: provide two versions of the same educational game, one with a strong narrative and one without. The product owner (the client for whom the team created the games) also required a fun educational game, one where the player would willingly play the game regardless of its educational impact. Waker and Woosh are Team 5's answer to this task.

What went right?

• Once the prototyping and initial game concept session started rolling, I got out of the way. I wanted to join in - playing around with new game ideas is fun. However, I didn't want to overshadow the team's ideas with my own; this was their game. Instead, I listened in on their prototypes, and tried to use my comments and questions to keep the team on track for their project goals. For example, how do you use a rhythm game to express displacement, velocity and acceleration? Graphically? When they couldn't answer that question, it was time to try an alternate approach.

• Demonstrating the development processes GAMBIT expected the team to use - and then giving the team time to use them, mis-use them, and finally get them working, in their own unique style. GAMBIT required the teams to use several agile development principles borrowed from Scrum - among them, the idea of a product owner, a task board, and daily stand ups. However, with only eight weeks of development and a group of inexperienced developers, GAMBIT also provided a schedule of development goals. So we were using elements of agile production on a waterfall schedule. I built the Scrum task board for them, and helped them define their tasks for the first milestone; I led the first couple of daily stand ups. By the middle of the program, it felt like the task board was useless, as team members frequently announced they'd worked on something completely different, and the task board stood unedited for days until the producer prompted the team to sort and re-arrange. Finally, for the last sprint, something clicked. The team members understood what needed to happen, divvied up the remaining tasks, prioritized them, and tasks flew across the board. I could actually tell where the team was on the project by looking at the board, and then looking at the game, as opposed to talking to each of the team members. It was also during those two weeks that the game really came together, as a good looking, fun to play game.

• Being there to channel the product owner, on the research goals and the specific tasks the product owner asked us to work on. Our product owner was very busy this summer, and while he met with us at the end of every milestone to review the game and give us feedback, he wasn't there for the day to day decisions. All too often, the team would be staring at two seemingly gargantuan tasks, both Necessary to the Well Being of the Project, and clearly both desired by our product owner. By checking our notes, and making sure that the producer and I got clearly prioritized requests during the review meetings, I was able to remind the team which task to tackle first - even if that meant the other task fell off the table, and rolled away. I was also able to reassure them that, yes, the team wasn't going to get everything done it had hoped for, and that was okay also. What we needed to do, instead, was insure that we got the most important tasks completed, and that those completed features worked together to make a good game. During any development period, especially a short one, there is only so much work that can get done. Experienced teams regularly over estimate their ability to accomplish tasks; inexperienced teams are even worse at it. Keeping priorities clear - and, more importantly, the product owner/client's priorities clear - means that at least the tasks that get dropped are the least important ones.

What could I have done better?

• Scoping the project - keeping it a manageable size. Before the students arrived, I knew what our research proposal was, and what our product owner wanted from the team. I was worried about the density of initial design challenges - three concept graphs, two alternate games, and a high quality narrative, but the team had an extra artist and a grad student to play utility infielder, so it seemed achievable. Then the product owner - after the team decided on a platform style game - asked for procedural levels. At the same time, thea bstract version of the game went from 'no story and no story specific art' to a version with a unique set of art and audio assets, including its own avatar. Alarm bells went off in my head, but the team wanted to do it all, so I let them try. I should have stepped up and said no procedural levels, and greatly minimized the abstract version's unique assets. Instead, we ended up chasing a procedural levels solution for about two weeks, while the artists did another round of concepting for abstract assets. Reality did set in, and the only remaining sign of procedural levels is the random placement of obstacles in medium and hard levels. The acceleration levels were also cut, because we just couldn't figure out how to accelerate the player on our small screen.

• Art asset scheduling - I waited too long to talk to the artists about getting art into game. The team of three artists developed elaborate plans for the visual look of the game... and then they kept developing them. With two full games to provide assets for, the team didn't have time to dally - but they did. They generated a set of placeholder assets for the game, so level creation and testing could go on, and then stalled on delivering production assets. Five weeks into the project, with three weeks to go and only one or two production assets in the game, the producer and I revised the art asset list, lined up estimates, and started counting hours. The artists, confronted with their list of desired assets and a very short time frame, buckled down and assets finally appeared. While we had three artists - generous for a summer project! - one of the artists ended up devoted almost entirely to Woosh, and another spent hours converting art from bitmap to vector to go into game. Final art didn't come into the game until the week before ship, and we were still adding new assets during gold certification. Because of that, there are several elements, especially in the story version, Waker, that are less polished than they could be. The team used polish time for final asset creation, rather than polish, and it shows in the level art, the game menus, avatar animations, and the player controls.

• For the narrative version, failing to get a better connection between the story and the game mechanics. The team came up with a compelling gameplay mechanic, and then a rich story. Bringing the two together, however, fell by the wayside as the artists worked on creating art to bring the world to life, the designers made levels, and the programmers and QA struggled to get everything working. When the story was first presented to the team, I was worried about the story's ability to be expressed in the gameplay, and I asked the team to get a better connection between the two. They never got around to it, and in the end we cobbled the story together with the help of a writer, working the story to match the elements that were in game. It worked, but the team had time, and the ability to do a better job. I should have pressured them to connect the game mechanics and fiction, and offered then better support in doing so. I made one or two suggestions, but didn't want to force my ideas on the team; I still wouldn't want to. I should have made them show me how their gameplay and their story interconnected much earlier in the project, when it was still possible to alter story, gameplay, and assets.

My goal for the summer was twofold: one, make sure our client, the product owner, got a successful, useful project. (He did: he told us so!) Secondly, I wanted everyone on the team to learn as much as possible about working on a team, especially when working with people whose skills are different from their own. I wanted them to learn how to make a game by stretching their own skills, and if possible, learn from their teammates about the other disciplines on the team. Finally, I wanted them to make mistakes and recognize them, recover from them, and gain the confidence to make yet more mistakes, and find solutions to them as well. In the end I tried to serve the team as the voice of experience, demonstrating successful techniques, giving advice when asked (and, sometimes, before being asked) and warning them about potential complications they might not expect. What I really didn't want to do was stop them from making the mistakes they would learn from - and therefore learning from them. We - as a team - certainly made lots of mistakes, but the games - Waker and Woosh - speak for themselves. Overall, I think that by serving as ES I helped the students learn; I certainly learned more about how to teach, and next summer I intend to do a better job.

Check back today for more content on Waker and Woosh

An Interview with Maj

Today I'm happy to bring you the second in what is apparently now a series of interviews with prolific combo video makers (be sure to check out the first interview, with James "jchensor" Chen). Maj is the man behind Sonic Hurricane, a fascinating blog and excellent resource for all things Street Fighter.

In this excellent interview, Maj delves into the history of combo videos, his creative priorities, ethical considerations, and hints at the rhetorical power of this unique form.

Begy: How did you get started?

Maj: I liked combo videos from the instant I became aware of their existence and got a chance to watch one. However, the very first thing I read on SRK was the Domination 101 article series by s-kill, who explained that combo video people are "often weaker on certain fundamentals" and "focus on showboating," becoming "that much less centered on the bottom line." Which, in all honesty, is true. So even though people like jchensor and NKI were my heroes for showing us how cool these games can really be, I believed Seth's argument that everything is secondary to becoming unbeatable.

By the time CvS2 came around, I already knew almost everyone in the SoCal community. Out of the blue, tragic (who i didn't really know that well) invited me to his place to help him work on an early CvS2 video. Until I saw him capture a combo with my own eyes, it never occurred to me that making combo videos was something that humans could do. Yeah I don't know, I must have thought it was a super power or something. But suddenly it all made sense and seemed completely feasible.

Not long after that, I started recording clips on VHS tape so I could drive over to MrWizard's house and ask him to capture them for me, since I couldn't afford a capture card myself. Even then, my intention was never to become a combo video maker, because I was still way more interested in progressing through the ranks of the tournament scene.

My first video was a CvS2 Chun Li Strategy Guide posted on the now-defunct, and my second video was a CvS2 Randomness compilation which contained a few combos but was mainly an attempt to get more people to give CvS2 a chance. MvC2 was the big game at the time, and CvS2 seemed rather dry in comparison, so I did what I could to change that perception. It wasn't until my third video that I tried my hand at combos, focusing on Guile because I'd basically become known as SHGL's resident Guile player at that point. Plus he was a perfect fit for the kinds of combo ideas that interested me the most in CvS2.

Eventually the website hosting these files died so I built as a home for my various fighting game projects. When SHGL closed, no arcade was able to replace it in my mind, so I started focusing more on combo videos and less on tournament competition.

Maj's SF ? Guile Exhibition, shown at EVO 2007

What are your primary considerations?

As long as the content is good, everything else takes care of itself. I don't try to force videos from scratch. Finding enough free time is too difficult anyway. Then it's a hassle dealing with technology, especially if the concept calls for multiple games on multiple consoles running at different resolutions and frame rates. None of us get paid for this and somehow everything always takes longer than expected.

If a really good idea hits me, it'll motivate me to put in the effort to perfect each clip and jump through all the hoops necessary to finish the project. Otherwise I'll just test the concept for an hour, post the results on a major forum, and forget about it.

There's a Mitch Hedberg joke about this: "Sometimes in the middle of the night, I think of something that's funny, then I go get a pen and I write it down. Or if the pen's too far away, I have to convince myself that what I thought of ain't funny." Except with combo videos, the pen is always too far away.

How much do you think about things like editing and music?

Until recently, editing was my absolute last concern - always an afterthought. There's no substitute for quality of content in a combo video and it's very easy to make good content unwatchable by over-editing. Lately I've been trying to find ways to make the overall presentation a little more pleasant, but I've only made two videos where I'd call the
editing important. Even then it was less important than the content. Don't get me wrong, I enjoy watching videos where high quality editing takes center stage but it's just not me to try that sort of thing. I'd rather focus on combo originality and keep the editing out of the way.

Music is a big deal to me so I spend a lot of time thinking about it. However it's usually the last thing I add on. Some people choose a soundtrack first then structure their entire video around it, which I admire because syncing clips to rhythms always has an impact. I don't do it because it's too much editing work and because you have to sacrifice a certain degree of clarity to make everything fit. So I always work on the video first and then look for a suitable track, which sometimes takes days. Finding music that compliments video game sound effects can be tricky.

Who are you making the videos for?

It varies a lot. Sometimes I'll make a video to demonstrate a single discovery, basically for anyone who cares. I've made a couple of strategy videos to highlight under-appreciated characters or play styles, intended for the entire fighting game community.

However, whenever I try really hard to make an exceptional combo video,it's with a relatively tiny audience in mind. My primary goals are to impress the best combo video makers in the world and to create something entertaining for my close friends. I figure the best way to show my appreciation for these people is to put together something that'll make them go "Wow."

That said, I've always admired the fighting game community for too many reasons to list. So it feels good to contribute something cool that I think everyone will enjoy.

Is there anything you think combo videos should always do? Or never do?

As long as everyone's honest, everything's fair game. Problems generally arise when someone lies about how they recorded a combo or where they got an idea.

Even extreme cases of combos created with cheat codes or cheat devices are okay as long as the video maker includes a straightforward warning or a disclaimer. Most people won't care about that video or won't be impressed, but it won't cause any actual drama either.

Now if the author tries to pass them off as legit gameplay, everything changes. We know these games well enough to tell when something is awry. Once enough of us start comparing notes, that author quickly finds himself in an indefensible position. The community can take of itself, but it'd be nice if we never had to deal with these temporary annoyances caused by shortsighted dishonesty.

Are there any combo video authors, or videos in particular, that you are particularly fond of or inspired by?

Far too many to name, so I'll just go with jchensor and NKI. They were two of the most respected combo video authors in the scene when I first started making videos. Both of them have produced several combovids that I'd consider classics to this day. Most importantly, they're just really cool people. I think our whole scene would have turned out differently if those two guys hadn't been as welcoming and as open as they've been to everyone who approached them with a question.

NKI Vol X: Super Turbo Shenanigans

I know of similar communities where everyone's at odds with one another. Sometimes that culture can be traced back to one influential figure who happened to be a conceited jerk.

In terms of favorite videos, it's hard to say because the cutting edge is always moving. For starters anything by TZW, Skill Smith, Sai-Rec, Tosaka, 538/kysg, zerokoubou, or T-7 is simply amazing. Each of those guys chose one or two games to absolutely shred apart and then disappeared. Even today it's almost impossible to find SSF2T combos that
can top VHS tapes TZW recorded over ten years ago.

TZW - Chapter 2 - Ken

Honestly though, I admire anyone who's down go through the trouble of recording and editing any video that shows me something I've never seen before. Even if it's one extra hit at the end of an established combo or one tiny element of style, it's enough to make me smile.

Thanks to Maj for his time and patience in putting up with me and this project. For an even more detailed look at his creative process please check out Sonic Hurricane, particularly the media section. Once again please blame any typos or misspellings on me. - Jason Begy

Woosh Ball Concept Sheet

Here is a concept sheet of different designs for the abstract Woosh ball.


See you tomorrow.

Beautiful Prototype Screen

Here is a beautiful main menu screen from one of the early versions of Waker:


Come back soon.

Alternate Waker Main Menu Screens

Here are some alternate main menu screens for Waker:

Main-Screen-1.jpg Main-Screen-3.jpg Main-Screen-4.jpg

More neat stuff, all day! Coming your way. Say hey!

Orientation Photos: Part Deux

Here is the second group of photos. Game franchise revealed after the pictures...

5-3.jpg 5-4.jpg 5-5.jpg 5-6.jpg

That's right! It's FROGGER!

More awesome stuff, coming right up.

Orientation Photos

As an orientation exercise, we had the teams go off with a still camera to make a live action storyboard recreation of any popular video game franchise. Here is the Poof teams offering.

I will post the photos in two installments, revealing the intended game franchise in the second post. See if you can guess which one they chose!

5-0.jpg 5-01.jpg 5-02.jpg 5-2.jpg 5-1.jpg

Come back soon!

This is the Game of The Week

We have made some games for you!


GAMBIT is kicking off our Game of the Week extravaganza today, highlighting Waker and Woosh this week.

We are offering behind the scenes content from the making of all of our summer prototypes, highlighting each game one week at a time. There will be tons of great concept art, design documents, commentaries, videos... tons of stuff. You can see it all here. Or just click on the awesome banner on our home page.

Check back often as we will be posting new stuff just about every hour.
Oh, and of course go play the games if you haven't already!


Welcome to the Game of the Week series at our blog. We are going to kick things off this week with Waker and Woosh. Enjoy this video introduction to the two games.

Come back in a about an hour for some more great content!

GAMBIT is Three

Happy Birthday to you
Happy Birthday to you
SMIGL.jpgHappy Birthday dear GAMBIT
Happy Birthday to yoooooooooou!

The Singapore-MIT GAMBIT Game Lab was started exactly three years ago. There wasn't really a "lab" in 2006, let alone the two R&D facilities at MIT and Singapore that we work in today. Just a tentative written agreement, a couple of lengthy papers justifying a need for a "Singapore-MIT International Game Lab" (the picture shows what Geoff thought of that name when it was announced... hence, our current acronym!), and a couple of plane tickets to Boston.

This is for everyone who has ever come through GAMBIT: in the Singapore lab, twelve timezones away in the MIT lab, representing at Indiecade, leading our research, studying for degrees, funding the program, or working in game/media companies all around the world. From the bottom of my heart, thank you for all the awesomeness... it wouldn't have happened without you.

Some Poof Team Photos

Here are some photos of the Poof team in action.

Poof_Team_01.jpg Poof_Team_02.jpg Poof_Team_03.jpg

Poof_Team_04.jpg Poof_Team_05.jpg Poof_Team_06.jpg

Don't they look like they are having so much fun?

More exclusive stuff tomorrow. Have a great night!

Beautiful Environment Concepts

These are some beautiful concept pieces for environments in Waker.


One more for today in about an hour. See you then.

This is Hilarious

I have not actually seen him protecting the lab, then again, he is a master of stealth.

Come back soon or we will karate chop you.

Waker Environment Concept Art

Here are some Environment sketches for Waker. You can see the experimentation in style and location in these designs.


Come back soon.

A Few "Bad" Postmortem Slides

On the other side of the coin, here are some slides of challenges the Poof team faced during their production cycle.



See you folks tomorrow for more...

Platforming and Politics in Shadow Complex

I finally finished Shadow Complex, getting 100% of the map and items. I enjoyed it a fair amount, though it does get samey after a while. The game is, in the end, more similar to Metroid than I first thought. While it begins like Out of This World or Flashback in terms of exploration and combat, it steadily becomes more like Metroid as your character becomes powered-up with various sci-fi gadgets. Running on water, triple-jumping--you name it. By the end you're zipping around the 'shadow complex' like a super-bouncy rubber ball, spraying bullets in all directions and punching people into oblivion with your bionic fist. Environments blur past. And although the gun-based combat is still at its core very un-Metroid-like, the super-powered-ness of your character eventually causes it to blur past as well.

The way Shadow Complex gradually morphs from a tentative, tactical exploration game to a run-and-gun shooter is interesting, though it betrays the fact that its visuals are not ideally designed for either style. As I mentioned in my previous blog post Shadow Complex's environments seem mostly designed to be taken in slowly, with lots of localized detail. Yet as the game gets faster the carefully nuanced nature of each screen becomes easily ignored, causing most environments to leave the same gray/brown impression. I had to constantly check my map in Shadow Complex, since often that was the only way to tell where the hell I was.

I never had this problem in Metroid, which always manage to separate each chunk of the game world with nicely distinct visual styles. Shadow Complex's more "realistic" visual aesthetic may look cool and more 'next-gen' than the 2D games that inspired it, but the net result is geographic distinction eventually stretches into incoherent mush. This is something nearly every other Metroid-inspired game does better than Shadow Complex. All the recent 2D Castlevanias, for example, have very clear environmental differences between map sectors. Leave it to the Japanese, I guess, to understand the value of iconic visual design and how it supports gameplay as a user feedback system. This is something that our Western obsessions with poly-counts and dynamic lighting get in the way of frequently, and it's one of the main things that, I think, separates Shadow Complex culturally from other Metroid-clones.

As for the story, I have to admit I was somewhat disappointed that the right-wing ideology I was bracing myself for didn't come off as strongly as I'd hoped. The only real evidence of it is fairly subtle, based on a few lines of dialogue you overhear at one point. It is between two enemy soldiers talking about "The Restoration", which is what they call their secret plan to take over America. The first step apparently involves "liberating" San Fransisco and New York, which one soldier says makes sense because those are two big cities "with governments that will want to hop on board as soon as we surface". The soldier goes on to explain how the rest of the country will probably have to be conquered by force, but that they first want to be seen as liberators and win some popular support. While most reviewers of Shadow Complex seem to have either missed or ignored this small detail (most people seem to think that The Restoration wants to nuke San Fran, for some reason) I took it to mean pretty obviously that The Restoration is some group of left-wing extremists, for whom the full cooperation of left-wing American cities (such as San Fran) is a foregone conclusion.

Unfortunately, none of these hinted-at politics fully surface in the end. Instead the game retreats to a highly generic characterization of its villains which feels more like a grab-bag of rotten politics both the (American) Left and Right can agree on... rather than anything which could coherently be called a political point of view. At the end, when the main bad guy gives his Big Speech, he rattles off a bunch of hogwash about America falling from grace and that it will be a great country again, thanks to The Restoration. He makes several references to imperial Rome and says America will be a great empire after they take over, sounding--and looking, thanks to the black uniform and red armband--more like a Nazi than anything else.

My first impulse is that referencing Nazism so heavily represents a retreat from any anit-liberal stance the game might have... though considering how both the Left and Right in the United States have appropriated Nazism to attack the other side, my assumption may be misplaced. Shadow Complex could easily represent for conservative players a typical right-wing fantasy scenario: the heroic fighting off of a left-wing conspiracy to take over the country in which the Left, finally, shows their true totalitarian colors. There is certainly nothing in the game to contradict this.

Hold on...

I just read the Boston Phoenix review of Shadow Complex, and listen to this...

There's not much to say about the paper-thin plot, but I should mention that Shadow Complex takes place in the world of Orson Scott Card's Empire series of books, a bizarre critique of the dangers of liberal political thought. Its antagonists are part of a left-wing organization called the Progressive Restoration whose aim is to overthrow the government and, it would seem, institute a policy of mandatory gay marriage and strict recycling laws.

Well well. Hardly politically neutral, is it? I'm quite disappointed, actually, that Shadow Complex couldn't have been more out-of-the-closet, so to speak, in terms of its right-wing ideology, even if it is merely inherited from Card's books. I think I would have been tickled to death by playing an unabashed right-wing Metroid-clone. That, at least, would have been less boring.

What bothers me more than anything is the seeming inability of commercial video games to address any political controversy head-on, to be upfront about advocating any political point of view. I mean, why not come right out admit what The Restoration stands for? Why tip-toe around what the book doesn't? Are they worried about alienating liberal gamers? They didn't alienate me. I still played it. I got 100% items, for godsake, and I had a ball killing endless streams of lefty no-gooders. Hell, if Shadow Complex taught me anything it's that the Left have some seriously cool robots, and that socialism is, apparently, functional enough to fund a terrifyingly advanced techno-army.

Even the most rampant homophobe would have to admit that shit is pretty badass.

A Few "Good" Postmortem Slides

Each team presented a postmortem at the end of the summer project. Poof created a powerpoint presentation.

Here are two slides of positives from the development experience:



One more for today, coming up in about an hour, so just keep your browser open and hit refresh every now and then.

Poof Team Picture

Here's a team picture:


Love the pink feather hat for the scrum-master/producer.
See you soon.

More Woosh Concept Art

Here is some more Woosh concept art from early in development.


Please come back soon.

Some thoughts from a Product Owner

Waker and Woosh had research provided by MIT's Education Arcade. The product owner's for the game were Scot Osterweil, Lan Xuan Le, Eric Klopfer, and Tim Marsh. Here is what Tim had to say after seeing the final version of the game:

Waker is a puzzle-based game wrapped in a narrative about a child's broken dream. Gameplay is thought-provoking, stimulating and fun but also creates a pleasant level of frustration that encourages the player - from beginner to experienced gamer - to continue playing to figure out how to build pathways and journey through levels of the dream world. Waker's artwork and music are equally compelling. The beautifully graded color and the simple, almost minimalist and somewhat stylized abstract background artwork is pleasing to the eye and peaceful to look at, and instead of competing for your attention, complements features and mechanics associated with gameplay and narrative. The subtle and uplifting music is reminiscent of contemporary art house film scores with repeating loops and rhythms creating another dimension that helps keep you in the game. In summary, the blend of the gameplay, artwork and music is a winning formula that draws the player in and encourages them to continue to play. But the ingenious twist is that Waker is a game for learning - to help learn about velocity and acceleration associated with topics in physics. The beauty of this game is that you wouldn't know it was a game for learning unless someone told you.

See you in a few.

Rock, Paper, Shotgun, Waker, Woosh


Rock, Paper, Shotgun wrote a while back a nice little article about Waker and Woosh.

Highlights for us included:

Well, the initial thought was "Surely they've screwed up the experiment by announcing the experiment". Since this isn't blind - each of the games feature the explaination of the concept beneath - you're approaching the games thinking about what's there or not. The responses are going to have that in mind. In fact, this sort of thing is much more the approach someone making games-for-arts-sake would take. Except GAMBIT aren't those sort of people.

Abstract isn't that abstract. The ability for us to force our lives - our narratives - into inanimate objects, especially when we're in control, is an interesting facet about humanity (Cross-ref: The Companion Cube - though that has a lot of narativist tricks forced on it to tart it up).
In other words, as an experiment, conceptually flawed. As a game, both are pretty sweet.

It is a great article, followed by a nice (and funny) comment conversation.

Can't say we agree with everything, all the same, we are really excited that people are talking about these games.

Check it out. Then come back for more GOTW stuff tomorrow.

Early Character Sketch

Here is an early character sketch from Waker/Woosh. I think if you look at the character on the bottom right, you can see the beginnings of the posture for the current in-game avatar.

Come back soon, see more stuff.


More Crayon

I'm pretty sure this guy did not make it into Waker or Woosh.


Y'all come back now, hear?

Someone Else's Thoughts

Mike Darga wrote a fantastic blog post about Waker, and we were very excited for his feedback and that he took the time to analyze our game.

We asked if Mike would be interested in writing a little paragraph about Waker for our "Game of the Week" spectacular and this is what he offered:

Game developers are constantly trying to convince ourselves that game design is an art, and so far this has done nothing but waste a lot of time and energy. It's refreshing to see a group of people treat game design as a science, and evaluating their games in such an objective manner. I hope Waker/Woosh inspire more people to analyze games, which will help us to better define which elements are and aren't important, successful, and fun.

Thanks for the words Mike, and please everyone hop over to his blog, Mike Darga's Game Design Blog, to read some more interesting stuff.

Also, check back soon for more awesomeness.

Woosh Concept Art

How do you design a completely abstract game artistically?

Well, for starters, here is a sheet of concept art from Woosh .


See you in a bit!

Waker Woosh GDD

Here is a game design document (GDD) for Waker and Woosh.

It is interesting to read through the document in between play sessions to see how it compares and contrasts to the final playable prototype.

Click the link to download the full .pdf.

Have you been checking in regularly to see all the exciting content?
Yeah, you should think about that.


Locomotion Sketch

Here is a little sketch of some early plans for locomotion and graphing.

Note the crayon. Good game designs should start with at least a little crayon.

Click the thumbnail for a larger version, and of course, check back soon for more exclusive content.


Waker: Preliminary Sketches

Well, lets get the ball rolling (har-de-har-har) on this "Game of the Week" exclusive content.

First up here is a sheet of preliminary sketches from the concepting phase of Waker and Woosh. Click the thumbnail for a larger image.

Check back soon for more!


right edge