Join us this Friday at 4:00pm where we will be playing a variety of Halloween-themed and related games!
Day of the Tentacle
Castlevania and Dracula X
Zombies Ate My Neighbors
Left 4 Dead
GAMBIT Halloween Party!
Join us this Friday at 4:00pm where we will be playing a variety of Halloween-themed and related games!
Day of the Tentacle
One Happy Kitty
Full Color Pierre and "The Man"
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
Pierre Character Sketch
Team Logo Concepts
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()
halo.Name = "halo";
The other changes I had to make:
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
Stage Background Concepts
Pierre Storyboard Page
Final Cat Sketches
More Kitty Sketches
First Cat Sketches
11/2/09: Purple Blurb presents Mary Flanagan
Critical Play: Radical Game Design
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
About Purple Blurb
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
The Territory is not the Map: Hyper Realism and the New Immersion Paradigm
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)
Character Silhouette Sketch 2
Character Sketch Silhouettes
11/04/09: Eran Egozy presents the Harmonix Story
6.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.
Another Stage Concept
Early Stage Concept
One More Character Sketch
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.
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.
Similarly, if Sarah loves Joe and Sarah is killed, Joe might
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:
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)
Stamina: NPCs have some innate drive
Dependence/ Independence: NPCs have some innate predisposition to group up (G)
The player may influence an NPC's goals by 'ordering' them to do one of the three basic behaviors
Together these traits and basic desires govern the more complex behaviors NPCs will undertake throughout the game.
More Early Character Sketches
Another Early Sketch
Early Character Sketches
New GOTW: Pierre Insanity Inspired
We have a brand spanking new Game of the Week (GOTW) this week, since, yes, it is Monday.
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.
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!
Usability Milestone Screenshot
First Runnable Screenshot
Screenshot from First Playable
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
Rain God Silhouette Sketch
Friday Games at GAMBIT: Procedural Level Generation with Darius Kazemi
This 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:
Main Menu Sketch
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!
See you in a few.
Some More Concept Art
Team Work Photos
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.
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.
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.
Team Blog Post
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.
The Development of Dearth
'Bad AI, BAD!'
The Design of Dearth
Here is a picture of our self motivated and inspired team.
King of Soda, Alec (Lead Programmer)
King of Pop (tribute), Nick (Designer)
Birds of a Different Feather
10/28/09: Clint Hocking speaks at GAMBIT
The Territory is not the Map: Hyper Realism and the New Immersion Paradigm
The 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 firstname.lastname@example.org 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 www.clicknothing.com.
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
Many 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:
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():
A Very Interesting Early Sketch
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
Another Concept Painting
10/30/09: Reminder - Student Explorer Grant
Turn your ideas into a business venture -- Receive up to $50,000 funding
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:
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.
The proposal must be submitted electronically to email@example.com by 30th October, 2009, 5pm, Singapore time.
Grant application form is available at http://web.mit.edu/smart/explorer
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
Early Dearth Sketch
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!
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.
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.
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 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.
Here is an audio outtake from the recording of the narration for the intro cinematic to Shadow Shoppe. Great voice-acting!
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
- Full Throttle
- BRUTAL LEGEND
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 zomb...no, 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
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:
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
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.''
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.
Happy Shadow Box
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.
More stuff soon!
More Fan Art
Menu Screen Concept Art
Shop Keeper Sketches
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
Scrum Board Photos
Shoppe Keeper Color Study
10/19/09: Jeff Norris (NASA) presents at CSAIL
Date correction: 4pm - 5pm, Stata Center, Kiva/Patil 32-G449.
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:
Hard at Work
Some Funny Shadow Shoppe Fan Art
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
Shadow Shoppe Character Sketches
Shadow Shoppe Docs
Here is a game design document from Shadow Shoppe outlining proposed gameplay features:
And here is a look at some departmental file size budgets for the game:
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.
Some Shadow Shoppe Concept Art
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:
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.
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.
What I need to do now:
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.
Okay, here is a bunch of cool stuff for the last post of the week.
First, here is a Storyboard pdf. Storyboard v2.pdf
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
More Waker Concept Art
Some Waker/Woosh Press
Some More Abstract Concept Work From Woosh
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.
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.
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.
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 Clockw0rk.com, 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 sonichurricane.com 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.
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.
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
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.
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.
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.
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.
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
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
Beautiful Prototype Screen
Alternate Waker Main Menu Screens
Orientation Photos: Part Deux
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!
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.
GAMBIT is Three
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
Beautiful Environment Concepts
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
A Few "Bad" Postmortem Slides
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.
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
Poof Team Picture
More Woosh Concept Art
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
Highlights for us included:
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
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
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?
Waker: Preliminary Sketches