Please enjoy this "behind the scenes" content from the development process of our summer prototypes. For eight weeks teams of students worked together to develop these games from scratch with only some research guidelines as a starting point. We hope that by exposing our process to the public we can encourage innovation in game development and game studies for industry and academia alike. Take a look at the developer interviews, concept art, sound, design documentation, essays, commentaries, and all other content we will make available in this series. But most importantly please take a chance to go play the games. We have made them, for you.

March 30, 2012 9:05 AM

GOTW: Squeezicks More Concept Art

Hello everyone and welcome to our last day of Game of the Week for Squeezicks. We've got even more concept art from the development of the game for you to check out!

Thanks so much for stopping by to check out the Game of the Week. You stay classy, planet earth.

Welcome back to the Game of the Week! Today we have some concept art fromt he early stages of development of Squeezicks. The project was one of two 3D games we produced last summer, along with Snowfield, and making a 3D game with a short development cycle introduces unique challenges to the team. I think you can see some of the early ideas for the game being worked out in these pieces.

Welcome back to the GOTW, featuring Eksa. Today we are sharing various design documents used in the creation of the game. First we have shots of an art asset list to give you a sense for how much art creation is involved in making a game like Eksa:

Next we want to show you some more concept art work from the game development:

We hope you enjoyed this behind the scenes look at Eksa. Come back on Monday for another Game of the Week

Hi everyone, and happy Wednesday! Today we will be sharing some concept art from the development of Eksa. The team had a unique challenge with Eksa to design a Facebook game that could appeal to a broad audience, and I think you can see in the concept art how they tested out many different ideas before arriving at their final style.

Welcome back to the Game of the Week series here at GAMBIT. Today with our last post for Stranded in Singapore we're going to show you some design documentation that will hopefully give you some insight into the character of the team behind the game.

Hello everyone, and welcome back! Today we have some concept art from various stages of development for Stranded in Singapore. These are posted in order by milestones (internal deadlines) so you can really see how the game progressed over the summer!

We'll be back on Friday with more from Stranded in Singapore. See you then.

Hi friends of GAMBIT! We're back with another game of the week this Monday, and today we begin our coverage of Stranded in Singapore.

Stranded in Singapore is a classic point and click adventure game built on research developed by Clara Fernández-Vara on procedurally generated puzzles. It is a great, and hilarious game, and if you haven't played it yet head on over to our games page and try it out. In the mean time, here is a video with Clara and Rik talking about the project!

Hey Everyone! Finishing up this week of coverage of The Snowfield we're going to share with you a special music video made by the members of the team, and featuring some special guests. We hope you enjoy it as much as we did!

Well hello everybody, we're back with another Game of the Week, and this week we are taking an in depth look at our IGF nominated The Snowfield. We're staring things off with another great video, this time featuring an interview with Matthew Weise, and Jason Beene.

To close out our week of Robotany coverage, we're going to share some thoughts written by one of the programmers of the game, Daniel Ho. I think it is important to let the words of the developers of the game, our interns, be read to paint a clearer portrait of our processes here at the lab in the summer, and to get a more focused understanding of the dynamics of a specific team.

Working on a 2D game in Unity has lots of decision to make, especially so in the area of coding and software development. The whole procedure is kind of like a hack around of the whole Unity engine. We used an unorthodox technique recommended by our Technical Director in the end! We basically play with a 3D world with billboards of characters on a usual 3d world flat terrain. It worked pretty well for most parts of it except that we have some weird Z sorting problem that Bruce(SG Game Lab Programmer) couldn't understand what is going on. However, for the most part, it was quite a good technique as we don't really have to care about depth sorting if we had to use other softwares.

I get to use Sprite Manager 2 and EZ GUI for the graphics. We ran into quite a few problems due to it being a community written library. The initializations of sprites are problematic. It work at times, and doesn't work at times due to the functions running concurrently or not the order we thought it would be.

UI implementation was a breeze with EZ GUI. Although we did some parts of hard coding to speed things up, most of the implementations for EZ GUI seems working as expected. However, as thing happens when some functions can flip in the order they are called. Eg. Update vs OnMouseDown.

Working with Biju is really fun! We get to analyze algorithms and design patterns that actually help me get a deeper understanding of what are the better practices to follow for game programming. Having 2 programmers out of a development team of 9 is really taxing on us. However, I think we communicated really well and manage to work at an extremely efficient rate. 10 over classes in 3 weeks!!!

I really enjoyed working in the team, as well as in GAMBIT. The environment is not stressful, and there is a lot of learning opportunities. We can have fun during work and there was always some laughter going on. This kind of environment really pushed me to do my best without the unneeded stress I get from rushing assignments in school! Awesome!

Thanks for checking in this week, and come back on Monday for another Game of the Week!

Welcome back everyone. In this post we are highlighting a large collection of Robotany concept art. The nature theme persisted throughout development, but I think you can see some very interesting early ideas in these pieces.

Well, that's all for today. See you all on Friday with a final installment of Robotany features!

We're going to star this final post of the A Closed World coverage with some screenshots of early versions of the game. I think looking through them you can see some of the path that was taken to get to the final version.

Next are some images of maps that were designed for the game. I think this shows how the world developed over the weeks working on the game.

Finally, I'd like to finish this little retrospective of A Closed World with some reflections written by the team's game designer. See you on Monday with our next Game of the Week!

Welcome back to part two of our first week of coverage of last Summer's prototypes. We are continuing our look at A Closed World with some images from our early development stages creating paper prototypes before starting work on a digital game. I think these images nicely illustrate how creative our teams can get in developing playable paper prototypes to iron out ideas and to troubleshoot difficult design challenges before even a single line of code is written.

Next are some concept art pieces done from early in development. We emphasize extensive concept work for our artists, audio designers and for our game designers. It is valuable to experiment and explore before settling on artistic directions.
That's it for today. We'll be back on Friday morning with more stuff from development of A Closed World so check back in then!

Well hello everyone! We're back with another Game of the Week series showcasing our summer prototypes from 2011. For those of you new to this series, we spend an entire week posting behind the scenes looks at how our games are produced. We have video interviews, concept art, design documents, blog posts and myriad other artifacts from our production process.

This year we'll be posting three items a week, on Monday, Wednesday and Friday mornings. The posts will be chock full of unique and interesting insights, so be sure to check in and see what we've posted.

This week we are starting with A Closed World! If you haven't played the game yet, head on over here and check it out. Then, come back and watch this video with Todd Harper, the Product Owner, and yours truly.

Just uploaded for your viewing pleasure is trailer promoting the 2012 edition of Game Of The Week! Beginning February 20th, 2012...On the Monday of each week, a new video exploring the origins and processes of developing each Summer 2011 game project will be posted. GAMBIT Audio Director Abe Stein will post blogs during the week, featuring concept art, design documents, and analysis of the highlighted game will be offered for your viewing pleasure! Video Produced by Generoso Fierro, edited by James Barrile, music by Abe Stein. Check out the series beginning February 20th, 2012 at http://gambit.mit.edu/gotw

With all the beautiful sketches and concept art we show with the Game of the Week, I wanted to take a moment to show you another side of the game development process, the organization and planning done by producers and designers. Here are some shots of the product backlog for Improviso at an early stage of development. Product backlogs are how you keep track of features that you want to implement in the game, and they really help in maintaining appropriate scope for the development cycle of a project. These documents are always changing and adapting to the newest state of the game, but they help provide a roadmap for what developers can expect.

The fiction used in Improviso was important to creating an atmosphere for players to feel comfortable engaging one another. A big part of that is the "alien" character that you find in the game. Here are some alien sketches:

I also promised you a surprise yesterday. I am excited to announce that you can now go download and PLAY Improviso right from this website. Click here to get your acting on. See you tomorrow.

Improviso was unique this last summer in that it was the only game we were developing that was using full 3D art. This presented some new challenges to the art team in how to create a style that would be flexible enough to fit the fiction of improvisation and would still be engaging to the player. Check out some of the concept work done early on below:

Hey everyone! Halfway through the development of Seer and Yet One Word the artists decided to change the art style of the game to the paper cutout theme you see in the final version of the games. Here are some screenshots from early builds that we showed at a large open playtest halfway through the summer program:

One slightly different thing about The Sophocles Project games was that there were three artists on the team. This was done to ensure there were no jams in the art pipeline since the team was going to be making two games in one summer.

What is really great is that I think you can see the styles and ideas of all three artists in the final games. Check out a few pieces of concept art below, and see if you can find traces of ideas that made it into the final game!

It is always useful to look back at early screenshots of first prototypes of games. I think looking at these screens you can see that even in the first digital prototypes of the games some of the core mechanics of the games are being worked out. Check them out:

Greetings from GDC! Sorry we are a little late today with our post for this week's GOTW video, I hope you are still with us. This week we are actually highlighting two games, Seer and Yet One Word from the ongoing Sophocles Project. Check out the video describing the origins of the project:

For our final installation for Afterland we are showing some of the concept art developed early in the process. Balancing a game between conventional design choices and unexpected consequences can be very difficult, and I think you can see some of the ideas being worked out in these concept pieces.

See you next week, from San Francisco and GDC, with a brand new Game of The Week!

Here is a blog post written by one of the Afterland programmers, and current MIT and GAMBIT grad student, Mark Sullivan!

Here at GAMBIT, the members of a team each have a certain role. It might be one in production, quality assurance, game design, sound, art, or programming. The function of a programmer is one of a facilitator. The ideas and creations of all these disciplines are synthesized into a game by its coding team.

The programming team for Afterland consisted of three members. I, Mark Sullivan III, am a recent MIT graduate and GAMBIT veteran. Su Qin is a Computer Science student who has just graduated from Nanyang Technological University, Singapore. Last but not least, Melvyn Qwek who is doing his final year Nanyang Polytechnic, Singapore with a specialization in Games Programming.

While we all had prior experience developing games, none of us had done so in Flash before. The mood, however, was definitely one of excitement, and not intimidation. We were all very excited to learn the skills needed to develop for this very portable and accessible platform. Early on, at the recommendation of GAMBIT's technical director Andrew Grant, we decided to use Flixel as our game engine. We did not regret our decision; Flixel does a great job at establishing the basic game framework so that it's very easy to get a simple game up and running very fast. The tools Flixel provided were sufficient to accomplish nearly everything we wanted, and it was easy to patch in the things it did not.

For the first stretch of the project, we did not code at all. Our research objective specified a lofty concept, so the whole team participated in brainstorming before a more concrete specification of the game could be created. While a lot of the design was iterated upon and modified after this point, we had a starting point and could begin implementation. We implemented much of the framework which persisted for the duration of the project. We created a basic platformer with collection elements, and after that the game charged full speed ahead.

At this point, we were able to come up with a reasonable partitioning for the workload, one which persisted the entire summer. I was responsible for the game world - integrating designer levels and the art for the levels - as well as the collision detection and audio. Melvyn was charged with the user interface and heads up display, as well as the item collection. Su Qin took care of the player and non-player-character movement and behavior. While there was certainly some gray area and this was not a strict partitioning, we were able to develop in parallel quite well with this system, and the workload was evenly balanced among us.

One unintended feature of this partitioning was that it matched the artists' partitioning. Yoshi did the level art, Sophia did the character art, and Kelvin did the user interface. This ended up working quite well for us, each having a primary contact on the other discipline's team. There are several things we learned to fear from the art team, however. A high pitched voice accompanying flattering words without a doubt signaled the onset of some absurd feature request. "You're the best programmer ever! I'm sure it would be no trouble for you to..." A particular favorite was "Wow, what a great job on the ending scene! Although...wouldn't it be great if there was confetti as well?" That one lead to our game being stuck at 1 fps for a while. Or the completely urgent "NO! What happened? The items in the house are off by a couple pixels!" I can't pretend I can tell the difference, but perhaps that's why I'm not an artist. In any case, the bantering between the teams was done in good spirit.

The design pipeline was pretty smooth. We kept an up to date backlog with the features we planned to implement, so it was always easy to tell what the plan was. Additionally, we found Flan, a level editor designed for use with Flixel. While the editor was restrictive at times, and closed source so we couldn't modify it, it provided a lot of functionality which we would not have been able to match on a timeline like ours. It allowed our designer, Aaron, to create and test levels on his own, though we wound up fitting in things like the parallaxing backgrounds in code.

Sound integration also went pretty well. There were plenty of iterations on the way sound worked which required programmer intervention, such as certain crossfades and other transitions, but the sound designer, Iqbal, was given access to our sound manager, so that he could swap assets and adjust volume levels on his own. Due to some file size problems, we unfortunately cut a lot of audio in the end, but I feel we managed to tie together what we had quite well.

While most things worked out quite well, there was one thing in particular we could have done better. Our file size is much larger than it needs to be. A lot of the art is in bitmap when it could have been done with vector. This is not the fault of the artists, just a lack of foresight on all of our parts. We managed to save about 6 megabytes converting many of the parallaxing backgrounds to vector art (with blur - we cached them at runtime to prevent a huge performance hit). We could have avoided the need to redo some of the artwork had we anticipated this.

In the end, all of the parts converged to the whole, and we wound up with, what I believe, is a great game which accomplishes the research objective. If you haven't tried it, play it now!

Hello all. Here are some storyboard sketches for the cutscene to Afterland. Sketching out cutscenes is really important to making sure that they communicate the story clearly to the player. Check these out:

Hey everyone. Today we are sharing screenshots from the first playable digital prototype of Afterland. I think you can see from these shots the drastic change that the art style of the game underwent during the process. At the same time you can see how the core gameplay existed early on. Check these out:

Pouring over materials from from the development of Elude I ran into some interesting things I'd like to share.

First here are a couple of images depicting how the artists layered their game visually. This shows some of the thinking that goes into designing a game visually:

Next I'd like to show you some concept art for "inspiration objects" in the game. These objects, which became birds in the final build, are important to the metaphor driving the games design and you can see from the sketches a lot of thought was put into how these objects should look.

Hope you've enjoyed the Elude content this week. See you on Monday with a new Game of the Week!

Good morning everyone. Here are some more pieces of concept art from Elude. The development team had some great artists, and I think it is nice to look back at how the style for the game grew out of early sketches.

Hey everyone. Here is some concept art from Elude. One of the really nice things about Elude is the coherence of the art style. All the elements really contribute to the feel of the game. This was not arrived at by accident. The team spent lots of time testing out concepts and iterating on the ideas. As you may have noticed by now, at GAMBIT we really emphasize iterative design!

Welcome back, and happy Valentine's Day! This week, we will be highlighting Elude, a game about clinical depression. Check out this video below, and if you haven't yet, play the game here at the GAMBIT website!

To close out the Poikilia week we're gonna post some pictures of the Chroma Studios team during the summer. I think these give you a good sense for how our lab is set up and a little bit of a feeling for how our summer program operates!
Thanks for checking out our Poikilia coverage. Come back next week for some more GOTW!

An essential component of the research behind Poikilia is examining the effect of structured narrative on the ability of players to decode and unpack the meaning behind a game. In the instance of Poikilia, storyboard cutscenes are used for telling the story behind the game. Below are some of the concept boards for the narrative scenes:

Welcome back folks! Today we're gonna show you some early character sketches from the development of Poikilia. Because narrative and fiction are a large part of the research behind Poikilia, tremendous thought and iteration was put into how characters would be depicted in the game to supports a fully fleshed out narrative and the absence of one. Check out the sketches below.

Check back tomorrow for some more Poikilia behind the scenes features!

An often overlooked important part of the development process is paper prototyping. At GAMBIT, before a single line of code is written, teams will build physical prototypes of various ideas to quickly and simply test out mechanics and systems. Paper prototypes help to mitigate some of the risk during later stages of the development process because ideas have already been tested and, in most instances, tweaked. Here are some shots of physical prototypes for Poikilia:

What is not shown in these shots is that most of these prototypes were played with flashlights and colored gels of the kind used in theater productions. With that in mind, I think you can see how these maps relate to the final mechanics of the game. If you haven't played Poikilia yet, what are you waiting for?

Hey everybody, hope you had a great weekend. Welcome back to our Game of The Week series here at GAMBIT. This week we will be highlighting Poikilia, a difficult to pronounce game about color theory! Check out this short form documentary video about the game featuring our very own Sergeant@Arms Marleigh Norton!

Hey folks! To close out this week of Symon coverage we're posting a whole bunch of images and pics from the development weeks last summer. We've got character sketches, background sketches, screenshot concepts, and even pics from the team room of the intrepid developers! Check it out:

So that wraps up our GOTW coverage of Symon. If you haven't played it yet, definitely check it out and give it a try. Also, come back next week for some more Game of The Week behind the scenes features!

Here are some sketches and a spreadsheet from the design process of Symon. While the premise and play of Symon is fairly straightforward, the complex design involved in creating a procedural point-and-click adventure game was anything but simple.

While these sketches do not demonstrate the depth of the game's design, they do show how complicated the process can be when trying to innovate on an established genre, even in small form. I think in looking at the early flowcharts and some of the early object relationships you can get a sense for the hard work the team did over the summer.

Hello again folks! Here are some character sketches for both the main character of the game and for some of the NPC you encounter. What I like about this set of design sketches from the early production stage is seeing how a character design might be iterated on. Seeing alternate versions of characters shows some of what the designers worked through on their way to finalizing the game.

Here are some early sketches from one of the first milestones in the development for Symon. There is some interesting stuff in there, and I think you can see that, even early on, the developers of the game had some pretty clear ideas for how it could look and play.

I especially like the notes written on the first sketch. It nicely illustrates the dynamic nature of game design. Nothing comes out right immediately, there is always some difficult questioning and plenty of trial and error.

Thanks for reading. Please come back tomorrow for some more exclusive behind the scenes materials from the development of Symon.

Well folks, that wraps up this summer edition of Game of the Week. We certainly hope that is was informative, or interesting, or insightful, or intriguing, or any other nice adjective that starts with the letter "I".

If you have any questions about our games, about our lab, or about anything we do really, please don't hesitate to contact us. We want to thank you for reading, and we want to encourage you to check back to our website often!

Finally, we will leave you with this great poster. This is a game I would love to see!
Cheers!

Hello and welcome to the release of Camaquen, a colorful reflection on different ways for games to treat conversation as a game mechanic. We on Team ChatterBoxers are very proud of our work and hope that you find something worth listening to in it. Please run here and give it a shot!

We'd like to talk a little bit about the experience of making this game, and provide some food for thought. We'll address something that went very right for us, but also a pitfall or two that we learned about.

First, a positive experience for us: our team had a number of people familiar with multiple disciplines. Our artists were capable of adapting to multiple styles and techniques, our producer had a substantial amount of coding experience, our writer was also a designer, and our QA had a surprising knowledge of animation techniques. Because of this, we weren't locked into tunnel vision about the demands of our individual tasks. It's important for teams, especially small ones, to be able to meet at the edges and understand, if not the details about each others' tasks, at least the constraints that everyone else is working under. Not only does it help you make placeholder assets or help come up with good solutions to shared problems, but it also pays off when one person has to hand off work to another person. Everyone's job on a game team is really interconnected, and knowing that changing one line of text here will mean an art asset over there has to be redone helps evaluate priorities and keep bugs free.

Being close keeps team members in contact and helps join the pieces together.

Of course, knowing other jobs and thinking about consequences doesn't take the place of good communications skills and procedures -- if you are willing to let tasks bleed across roles like this, it's even more important that we keep track of exactly's what being done and when. We made good use of task tracking software and daily reports in our SCRUM meetings to let each other know what was implemented when, and what pieces other team members needed to take care of. Because of this, people knew when they were being depended on, and our team ended up with a remarkably fast turn-around on most of our tasks. This in turn let us make lots of small adjustments very quickly, which helped a lot in tuning our interface and conversational models, which were key to the research goals of the project.

Disagreements happen, but are less disastrous when the team communicates often.

On behalf of Team ChatterBoxers, I'd like to say thank you to the Singapore-MIT GAMBIT Game Lab staff and administration, to all of our co-workers who provided feedback, and most of all, to the players. Thanks and please enjoy Camaquen!

Here is a piece of music written for Camaquen that did not make it into the game. Hans Zimmer's scores for The Lion King movie and musical (namely "Shadowland" from the musical) were definitely an inspiration, and this piece actually fell a little too heavy on the side of dramatic flare to make the final cut for the game.

Here is the text of a document from the beginning of the summer titled "Research Goals." It is interesting to see where the teams often start with these projects.

July 8, 2009

Overall Research Question: What different interaction techniques are there for conversation in games besides dialogue trees?

This game fits in to Marleigh Norton's greater research into games based on conversations. This game will be one of a series which will hopefully illustrate a set of techniques game developers can use to represent conversation in games.

This specific game will look at the interplay of emotional state and conversation.

Rules to get there:
• The emotional states of the brothers will be represented by some sort of dynamic, interactive system.
• The system should reflect the personality types of the brothers.
• One brother's emotional state should be able to affect the other.
• Players should be able to make predictions on how the system works based on their personal experiences with communication. This doesn't mean all their predictions should always be correct, but most players who put in concerted effort should be able to figure it out eventually.

Other considerations:
• As an additional goal, we will not be using a branching structure in which the word choice changes based on player input. In particular, we're trying to get around the assumption that the writer needs to write several versions of the story to make the conversation seem different and responsive to player input. Still allowed are multiple endings, including ending the game early. Also, the underlying logic of the game can have a branching structure as long as it does not result in the writer having to write unique text for each branch.

Here is an interesting early character design I just stumbled upon. It breaks the "rough" chronological order of these postings, but it was too great to ignore. Without further ado, I introduce, Disgruntled Flamethrower Man.

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:

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!

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 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!

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.

Challenges
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.

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.

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.

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.

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.

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.