Sometimes programming feels a lot like playing Whack-A-Mole. You get one bug sorted out, then another one rears its head, and then another, and then somehow fixing that one brings the first one back again. And it brings a friend.
Now that we have Maya installed, I wanted to start incorporating the original Abandon models into the Unity version of the game. First I found out, much to my annoyance, that I couldn't just change the mesh on the model player I had been using, because the Maya models had multiple meshes. (Say that three times fast.) So I had to create a new object for the new Maya model... and suddenly all those problems I had with the physics functions, where I couldn't get the avatar to stop bouncing off of things, came back to haunt me, and the previous fixes (increasing the rigidbody's mass and drag) proved ineffective. Plus, despite gravity being turned on, under certain circumstances the avatar will end up hovering in midair:
On the plus side, now that I've got the hang of adding meshes, I can start to put in the shapes for the household objects, too. So currently the avatar is getting chased around the screen by a bathtub.
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.
More fun with Unity: parenting and refining keyboard input
The walls finally work! For a while I could make the player stay upright and have it walk through walls, or I could have it bounce off the walls, but I couldn't make it just stop. However, it turns out that increasing the drag coefficient keeps the avatar from skidding away from the wall, and increasing the avatar's mass keeps it from flying off into space when it hits another object.
I also made some progress on parenting. In Unity, one object can be set as the "parent" of another, meaning that moving the parent object will move all the children as well. In Abandon, the player has to find and pick up a halo before exiting the level. I had already learned how to make one object the parent of another from the video tutorials, but I couldn't figure out how to do it from a script.
It turns out that you're not supposed to directly make one object the parent of another; you're supposed to make the transform of one object the parent of the transform of the other object. So the code looks something like this:
Transform t = other.transform;
t.parent = transform;
Along the way, I found another useful function: OnTriggerEnter. If I check isTrigger in the collider for the halo, then when another object collides with it, both of them will run the OnTriggerEnter function (if they have one). This saved me the bother of having to write a script to figure out if the player and halo are in the same position; Unity does it for me.
It does seem like pretty much every function I want to use is already built into Unity somewhere. The hard part is finding out how to do it! Which brings me back to keyboard input.
In my last entry, I discussed using events and the OnGUI function to process keyboard input. That was fine as far as it went, but when I read Caryn's last entry, in which she mentioned that her avatar couldn't move diagonally, I realized that I had the same problem. Since the only way I knew how to handle keyboard input was with OnGUI, and OnGUI runs when an event occurs (such as a key press), the program could only deal with one key at a time. First I tried to rectify this by storing a "move" vector as an instance variable, adjusting it according to keyboard input, and running the actual movement in the Update function, but that didn't help. Then I tried handling KeyUp and KeyDown events separately, but it didn't work because holding down a key creates a series of KeyDown events, so the avatar moved faster and faster but didn't stop because there were so many more KeyDowns than KeyUps.
I keep having the same recurring problems with the Unity documentation: it's hard to find the function you want, when you do find it it's not always clear how to use it, and while there are a few cross-references on each page, most pages don't link to all the other pages that it would be useful to know existed. It's the third issue that came into play here: if the documentation had more cross-references, it wouldn't have taken me nearly so long to find Unity's other methods of handling keyboard input. The Input class's function GetKey(KeyCode key), for example, returns a boolean stating whether the specified key is being pressed right now. Once I knew it existed, I used GetKey to check the arrow keys and made the Update function create a new movement vector every frame, based on which key(s) were pressed. Not only did it work for both straight and diagonal movement, the motion was smoother than before. Here's the final code from Update():
Vector3 move = Vector3.zero;
if (Input.GetKey(KeyCode.UpArrow))
move = move+Vector3.forward;
if (Input.GetKey(KeyCode.DownArrow))
move = move-Vector3.forward;
if (Input.GetKey(KeyCode.RightArrow))
move = move+Vector3.right;
if (Input.GetKey(KeyCode.LeftArrow))
move = move-Vector3.right;
move.Normalize();
transform.Translate(move*Time.deltaTime*speed);
Still wading through the Unity documentation. Today's project: incorporating keyboard input. Finding the relevant pages in the Unity documentation was fairly easy; I searched for "key" and found KeyCode, which led me to the Event class. However, it took a while for me to figure out how to use the Event class because the relevant pages did not provide any sample code. I tried using Event objects in the Update function and kept getting errors. Eventually I figured out that whenever an event occurs, the script runs the OnGUI function, so I had to access the event from there. Example:
// If a keyboard event occurs, print the key pressed
void OnGUI(){
if (Event.current.isKey){
KeyCode k = Event.current.keyCode;
print(k);
}
}
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.
The Game Engine Survey is a UROP project to test different game engines and evaluate the pros and cons of each. We will be working with Visual3d, Unity3d, and TorqueX.
I've been playing around with Unity recently. It seems like it has a lot of useful functions, but they're not always easy to find. The website's video tutorials are helpful, but they really just cover the basics, and sometimes leave out useful functions that the makers of the tutorial presumably took for granted. For example, in some of the videos, the scene view shows the environment from the same perspective as the game view--which it would be nice to know how to do, except that the tutorials don't seem to mention it. Also, the script documentation has at least one inaccuracy: they claim that the output from print statements appears at the top of the page, by the play/pause/step buttons, when in fact it appears at the bottom.
The script functionality seems fairly well-documented, once you get around the obstacle of writing in C# when the manual uses JavaScript. I'm still figuring out all the functions, so more on that later.
I recently had the pleasure of sitting down with Dr. Mia Consalvo, who is rejoining the GAMBIT US lab as a visiting associate professor this year, for an hour and chatting about her research interests. The resulting transcript has been published in the Fall 2009 issue of In Medias Res, the Comparative Media Studies newsletter.
Here are the first few paragraphs as a preview:
Geoffrey Long: First of all, welcome! Where are you coming from?
Mia Consalvo: I'm coming from Davis Square, but I most recently come from Ohio University's School of Media Arts and Studies. I'm an associate professor there, and I teach classes in new media, media criticism and analysis, and videogame studies. I wrote a book with MIT Press in 2007 about cheating in videogames, and right now I have two big projects going. One is on the role of Japan in the formation of the game industry and its status now, and the other relates to casual games and casual game players and casual game player culture and those kinds of things.
GL: What stage are you in with these projects?
MC: I've written a few smaller pieces that have been articles or chapters for other things that are eventually going to be collected into a book. One of the pieces, which I wrote when I was here at MIT last summer as a visiting scholar, was on the business aspect of Japanese videogame industries and how they're trying to push more for globalization.
Interestingly, even though Nintendo kind of resurrected the videogame industry in the 1980s after it went bust, and most Western kids grew up playing Nintendo, once Western companies got back up and going there was a decline in sales of Japanese games, so that now Japanese games aren't quite as dominant in the West. In Japan, it's still almost completely Japanese games on the top sellers list, but in North America and Europe it's much more split, and you see Japanese companies trying to figure out how to get that global dominance back. They have plans for different kinds of localization, transnational products, those kinds of things.
GL: When you're talking about the East and the West, you're not talking about just Japan and the United States. What is the game sale breakdown like in the rest of the world?
MC: There are three major game markets that companies look at: North America, Europe (and mostly that's Western Europe) and Japan. Korea has its own special thing with online games, but otherwise they're kind of too small. North American bestseller lists are clearly mixed as to what games are made where, and Europe is the same. There are few local European products that wouldn't sell somewhere else, like football games, and the Germans prefer PC games over console games, particularly strategy games.
In Japan, there's been this dominance of Japanese companies. When I was there in 2005 for a few months, it took me a while to realize, looking at the bestseller lists, "Wait a minute, there are no Western games here!" There were a few, like Halo and The Sims, but it was almost completely dominated by Japanese game developers. Now, because of the downturn in the economy and the declining birth rate in Japan, they've seen some declines in their sales, and Japanese companies are more motivated to look globally for other markets.
The complete article can be read online on the CMS site. Alternatively, the full Fall 2009 issue of In Medias Res can be downloaded as a 1.4 MB PDF for on-screen reading or as a 42 MB PDF for high-quality printing. Check it out!
Faculty and post-doc researchers from Singapore and MIT are invited to submit proposals for consideration to the Singapore-MIT GAMBIT Game Lab. Funding is available for projects to be run between September 2010 to September 2011, inclusive.
Researchers participating in GAMBIT-funded projects will be expected to encapsulate and present their work within an academic context, such as presenting at conferences or publishing in respected journals, websites, or magazines. Research projects must also include an applied component to be used in game development during the GAMBIT summer program in 2010 or 2011. Proposal requirements are explained in greater detail in Join Game.
PDF submissions for research collaborations seeking funding through the Singapore-MIT GAMBIT Game Lab must be sent to gambit-proposal@mit.edu by 30 November 2009 for consideration by the Projects Steering Committee. Proposal submitters may be contacted after the deadline for revision requests and clarifications. Approved projects will be announced in February 2010 to begin funded research in Fall 2010 at the latest. Approved projects may be able to get an early start by nominating a Singaporean researcher to participate in the GAMBIT Summer Game Development Program in 2010, allowing collaborators to meet regularly at MIT for the summer.
Being a games scholar is being a pioneer in undiscovered countries. It's exciting and adventurous, but it's also difficult and painful. Maybe it feels more of a pain because I'm in the middle of re-writing my dissertation, getting it ready for my committee to review before the defense.
At times, I miss Literature, I miss Film Studies, I miss my Shakespeare. They are established fields, and coming up with a significant contribution is really hard. But they have a set of established materials and tools. Research is like furnishing your house, and studying Literature is like going to IKEA--you go and select your pieces, and put them together following the instructions. In Game Studies, we have to come up with our own design, go to the forest, cut down our trees, make our boards, and assemble them. Thank goodness we can borrow the saws, hammers and nails of other academic fields, from Media Studies to Computer Science, although it is becoming evident that we need to make our own tools as well. We can also take some boards from IKEA and build something completely different. We shouldn't abuse it, however, or else we won't be using the materials that are inherent to our field. So far, the contributions of IKEA to game studies have been rather strange.
This metaphor is the result of having re-written my introduction and the methods section of my dissertation, and still not being happy with it. I find myself talking about foundational concepts that are still debated and in flux. How are games a type of performance? What do narratives have to do with games? What is a gameworld? What is a simulation? All I want to do is get around to talk about adventure games, which is the bloody topic of my thesis!
Don't get me wrong--it is because I like challenges that I'm in this field. The moment a theory or an idea clicks and makes sense is wonderful, precisely because one has to go through all these pangs. Perhaps I just want to figure too much out; I want the answer to life, the universe and everything, while I should just write "42" and talk about Monkey Island to get it over with. Or perhaps I'm just pissed off because I'm missing out on a gorgeous summer and working on my dissertation on a Saturday night.
Last week, Jesper Juul and I attended the Foundations of Digital Games conference. This is a conference on a Disney Cruise ship. Yes, you heard me right, on a Disney Cruise ship. It's not a bad idea if you think about it. Why network in a bar when you can network on the beach? And as the attendees kept pointing out, we're all trapped on the same boat. Plenty of time to ask your questions, right?
Yes and no, as it turns out. Cruise ships are HUGE. Thank goodness Jesper and I were in rooms next to each other or we may not have seen each other for the entire trip. Also, Internet and cell phone usage was very expensive, making meeting up with people rather cumbersome. Twitter was non-existent, and just walking around and finding other attendees wasn't as easy as one would hope. Still, dinner turned out to be a good time to network. There were FDG tables set aside, so you could walk in and be seated next to other attendees. I was also assigned a roommate, Amber Settle, a computer science professor from DePaul. Excellent person. Well worth sharing a drink and conversation with.
In terms of presentations, I found them very hit and miss. The diversity of the conference meant that there were often slots that had nothing of personal research interest to me, and what few there were seemed to conflict with each other. Not that I minded, after all the jacuzzi beckoned, but it did make me feel slightly guilty in terms of going on company time. There were a few gems, though.
Christina Strong from UC Santa Cruz discussed her work on conversation tools for game writers. Since I've been working on conversation games recently, this was particularly germane. Her particular work was creating a tool for Telltale Games to allow NPCs to make small talk. Writers would write phrases and comments for the characters to say, tagging with keywords as needed. The tool then used ConceptNet (go MIT!) to create more connections, so conversations would spring up based around related topics. For example, a conversation that started out about chili could then lead to Mexican food which could then lead to Mexico which could then lead to the beach and so on and so forth. The conversations would evolve over time. Cool stuff. Sadly, she implemented her system for Telltale's internal writing tool, so the rest of us can't see it, but neat ideas all the same. Also, I couldn't find a current website for Christina, but here's her old Georgia Tech webpage.
Damián Isla, a new addition to the Boston games community though not to the games industry in general, gave a surprisingly accessible talk about artificial intelligence tools. I very much liked his comparison between AI and method acting, suggesting that a good tool might follow the format of a theatrical rehearsal. The AI is the actor and the designer is the director. The AI has an initial set of instructions in terms of character and motivations, then does the best it can. The designer can then stop a scene at any time and correct behavior, which is then incorporated into the AI's character.
Shannon Duvall from Elon University had an intriguing poster about creating a games class that actually contained a video game style economy. Coins were earned by students who could then use them to buy extra credit, more time for an assignment, or other perks. They also could barter with each other, which she said was the more common, so less experienced students could purchase time from senior students to help them. I found this part very intriguing. It seems it creates a situation where students can specialize and market their skills to other teams. Also students would more commonly float between teams, spreading knowledge and expertise. I didn't get a chance to speak with Shannon so never heard the punch line of whether it worked or not, but I'm psyched that experiments like this are being done.
And finally, I'd be remiss if I didn't mention my own presentation, Easy to Use and Incredibly Difficult: On the Mythical Border between Interface and Gameplay, co-authored with Jesper Juul. The gist is that there's an instinct that good games have simple user interfaces but difficult gameplay. We argue that this idea doesn't always hold, both because it's hard to find a clear line between interface and gameplay and because good games can also have difficulty in the interface. The presentation went well, if I do say so myself, and we got lots of compliments after it. Some asked me if we were going to keep going with the idea, but it's such a simple idea, I'm not sure what more there is to say.
So, was I glad I went? Yes. I got to meet some cool people and had a lovely time away from the office. Will I go next year? Not sure. We'll see if I get a paper in.
Radiant Silvergun was one of the last games released for Sega's ill-fated Saturn. The game is a vertically scrolling shooter (or "shmup") and is considered one of, if not the, best games in the genre ever made. Its high acclaim combined with a limited, Japan-only release has made the game exceedingly rare, with copies on eBay going for upwards of $300 USD. Reasons for its status vary: the graphics, gameplay and soundtrack are all extremely impressive even eleven years after it was released.
"Be Attitude For Gains" is one of the more famous bits of Engrish in the game, displayed with advice for defeating each boss or miniboss.
What often goes overlooked, and what makes Radiant Silvergun special, is the parallel between the narrative and how the game is played (this post assumes familiarity with the plot and basic mechanics, check Wikipedia and the full plot translation at Silver Translations to get caught up). Just as the story is about an endless cycle, the gameplay encourages the player to enact out a similar cycle through several mechanisms.
The first is genre convention: shmups are typically designed to be played through over and over again, with the assumption that the player will be continually trying to improve his or her score. As a result the games are usually quite short; Radiant Silvergun can be finished in around ninety minutes.
The second is the leveling system: using a weapon to earn points causes it to gain levels, increasing the damage it inflicts. When the player runs out of lives or finishes the game they have the option to save their game, which in actuality only saves the weapon level. A new game can then be started from the save file, so the player begins the game with stronger weapons. This encourages continually using the same save file: playing the game, saving, starting over from that point, and so on. Each time the player does this the game gets slightly easier because the player's weapons are more powerful.
Next there is the chain system: every enemy ship is colored red, blue, or yellow. For every three ships destroyed of the same color the player earns bonus points. The bonus awarded increases with the number of chains, which in turn levels the weapons faster. This encourages the player to practice levels in order to learn how to chain most effectively, leading to more replays. There is also the "secret" chain, earned by destroying one red, one blue, then one yellow, and then continued by destroying groups of three yellows. This type of chain earns many more points than regular chains but is much harder to accomplish.
Finally there are two types of hidden bonuses spread throughout the game: Merry the dog and "weapon" bonuses. Merry is located in various points throughout the entire game, and can only be found by using the lock-on homing weapon. The weapon will target Merry, revealing him or her and awarding bonus points; there is no other way to find Merry. The "weapon" bonuses are also spread throughout the game; by using the correct weapon at the right time the player is awarded a "weapon" bonus. Both of these bonus types are left to the player to discover.
Normally we might say that all of these mechanics are included to increase replay value. On one level this is true of Radiant Silvergun, but there is an ulterior motive: by playing the game over and over again the player is enacting out the same type of cyclical existence presented in the narrative. Doris Rusch calls this "fictional alignment": the player experiences the endless, unbreakable cycle just as the characters do (from personal correspondence / forthcoming research).
It is this alignment that makes Radiant Silvergun so brilliant. By designing to maximize replay value, Treasure has created a game where the player wants the cycle to continue, further emphasizing the inevitably of the outcome. This is a spin on the classic adage of creative writing: show, don't tell. When the player realizes the parallel it is all the more powerful an experience because he or she was implicated in it from the beginning.
Shmups and similar arcade-style games are often derided for their emphasis on memorization and repetition, and have largely gone out of style. Radiant Silvergun shows how even an outdated form can create a compelling gameplay experience, suggesting that such an achievement might be possible for other classic game designs.
Today we are announcing the release of a new game for download: Sc-rum'pet: The Om-Nom Adventures. Sc-rum'pet is a one-button game in which the player guides a space alien named Sc-rum'pet through various challenges in a quest to earn his wings (because, ya know, aliens need their wings).
The core concept for Sc-rum'pet is quite simple. Sc-rum'pet travels through space based on magnetism, being either attracted to or repelled from objects based on polarity. The player controls polarity with a single button, and must switch polarity at the right moments to guide Sc-rum'pet through a level. That's about all there is to it.
There are 21 levels in Sc-rum'pet: The Om-Nom Adventures. It was developed all in-house by GAMBIT students over the past two semesters. Please download the game or play it in your browser and let us know what you think!
Last week, I went to the CHI conference, which is pronounced "kye" and stands for Human-Computer Interaction. Yeah, I know it doesn't match exactly, but how would you pronounce "HCI" anyway?
The field of HCI is the convergence of psychology, computer science, and design. Use psychology to understand the people. Use computer science to understand the computers. Use design to make it all work together. Lather, rinse, repeat, and voila! You have a well-designed system.
HCI techniques can be used for any system involving people and technology which includes... well, pretty much everything I can think of. It's a really broad field. That being said, I was pleased to see that CHI had some offerings specific to video games.
Gaming Picks
Wii All Play: The Console Game as a Computational Meeting Place
Amy Voida and Saul Greenberg
I first met Amy Voida at Georgia Tech when I was a Master's student and she was a teaching assistant. She wasn't into games research then and I'm psyched to see she's joined the cult. Our field could use more smart people like her.
The crux of the paper is a study she did on people who play console games together in the same room. For these people, it turned out the goal was not to save the princess or win the race, but rather to spend meaningful time with friends and family. As she points out, it's not "What makes video games fun?" but rather "Who makes video games fun?" Games that accommodate a diverse set of people with varying experience, preferences, and enthusiasm were key to a good gaming experience.
Designing Digital Games for Rural Children: A Study of Traditional Village Games in India
Matthew Kim, Akhil Mathur, Anuj Kumar, and John Canny
The goal? Create educational video games for children in rural India. The result? Crash and burn. The games were too Western. An adaptation of Frogger, for example, was the most easily accessible in terms of goals--crossing roads safely is a common occurrence in India. The idea of moving sideways to fit though gaps, though, was confusing. Who crosses a street like that in real life?
In order to make video games more accessible to the children, the researchers began studying the games children were already playing. Physical games, board games, whatever. They came up with a named set of structure elements, similar to the games ontology projects that pop up every once in a while in video game circles. By creating educational computer games that use the same elements as the games the children were already playing, they were able to create new games that the children could more easily identify with.
This sort of design philosophy is one of my favorites, to study the users and find their needs and interests, and then let the system flow from that. Pretty common in non-entertainment applications. Cool to see it being applied to game design.
Design Influence on Social Play in Distributed Exertion Games
Florian 'Floyd' Mueller, Martin R. Gibbs, and Frank Vetere
Ping pong for three players sounds weird enough. Ping pong for three players in different rooms seems even weirder. Strangely, it works better than one would think. Floyd Mueller presented an evaluation of his game Table Tennis for Three.
The thing that struck me about his talk--besides how hard it would be to market commercially--was how a lot of the joy of the game came from the people themselves. Much like with Amy Voida's study, people were bonding over this game. It allowed and encouraged chatting, showing off, cheating, and adapting the game in unexpected ways. For example, one trio had two novice ping pong players and one expert. They agreed the novices were allowed to use their hands while the expert could only use the paddle.
In video games, so much is artificial. So often you can't do anything except what the designers thought of ahead of time and the programmers coded in. It was nice to see a game that wasn't afraid to let the players just relax and play. So maybe using your hands isn't what the designers intended. So what? They're still having fun with the technology and each other. This kind of flexibility only added to the enjoyment of the game.
Non-Gaming Picks
Like I said, HCI is a broad field. Believe it or not, there's some awesome stuff going on in the world that doesn't relate to video games.
Designing for Global Impact
Jan Chipchase
Jan Chipchase's talk mostly seemed to be an hour long presentation of highlights from his blog. If that sounds boring, I assure you it isn't. He travels the world, studying the quirkiness of humanity and takes some pretty good pictures to boot.
Resilience Through Technology Adoption: Merging the Old and the New in Iraq
Gloria Mark, Ban Al-Ani, and Bryan Semaan
Picture this: the power's out, it's crazy hot out, and the generator can either power the air conditioner or the computer and router. What kind of person picks the computer? You're probably imagining a technogeek, but a modern Iraqi might pick that too.
Wow, this study was both awesome and gut-wrenching. These researchers conducted phone interviews on how technology is being used by civilians in Iraq to get by during war time. Information like what religious sect controls which streets today can be the difference between life and death. Unsurprising how some Iraqis went from low- or no-tech to high-tech in such a short time.
Mobile Technologies for the World's Children
Alison Druin (moderator), David Cavallo, Christopher Fabian, Ben Bederson, Glenda Revelle, Yvonne Rogers, and Jim Grey
And just so we don't end on a downer, the panel on mobile technology for kids brought together a super cool group of people from organizations like UNICEF, Sesame Workshop, Leapfrog, and OLPC. Special shout out to the International Children's Digital Library, which is a free online source of children's books from all over the world. I already downloaded their iPhone app, which sadly only has a few books, but not bad for the price of free.
Back in January I posted about how GAMBIT alum Skeel Lee Keng Siang's "Introduction to Soft Body Physics" won the Ziggyware Fall 2008 XNA Article contest, but apparently the accolades for Skeel's work don't stop there! The piece was also entered into the Intel Havok Physics contest, where it won two more prizes:
Community Voting Prize in Jan 2009 for the highest voted tutorial in that month
Jumping is a mechanic so pervasive that we rarely stop to think about it. It has gone from the defining trait of a genre (platformers) to being included in all manner of action games, adventure games, and first-person shooters. As a means of traversing space it is nearly universal in video games, but in every day life it is nearly absent. How often does an average adult actually jump over something? Adult jumping is limited to hopping over puddles, which is a far cry from leaping over pits and on to platforms suspended in midair. How has this mechanic become so ubiquitous in video games?
One potential answer lies with imitation. While they were not the first video games where you jump over enemies and onto platforms (an honor which may fall to Donkey Kong), the Super Mario Brothers games on the NES were hugely successful. This success spawned a wealth of imitators, leading to countless games where jumping over things was the primary means of interaction. That the Sega Genesis came with Sonic and the SNES with Super Mario World only further ingrained platforming in the gaming consciousness. While the success of these games may help explain the ubiquity of jumping today, there is the still question of how the mechanic came to be in the first place.
Because early video games were two-dimensional, they were limited in choice of perspective. For the most part they had to be a top-down view, as in Adventure:
Or a side view, as in Pitfall:
Top-down games had odd perspective issues in that characters were typically drawn as seen from the side, not from above, as in Dark Chambers:
In a side view perspective game featuring a human avatar, you run into the problem of movement. In shooters like Defender the ship can simply fly in all four directions, because (in theory) that's how spaceships move. But a person is bound by gravity, and simply walking back-and-forth along the ground is not terribly interesting. Burgertime solves this by having multiple platforms connected by ladders: if an enemy is approaching, you can spray them with your pepper, or try to out maneuver them by moving to a different platform. The pepper only sprays directly in front of you; doing nothing but would get old fast. The fun of the game comes from the multi-layered levels. On the other hand, in games like Donkey Kong and Pitfall jumping is the main method of avoiding hostile entities. In other words, jumping provides another way for a gravity-bound person to move vertically, hence making use of the limited 2D space. Of course in the real world we avoid things like rogue barrels and hostile mushrooms by simply walking around them, so jumping in a 2D game might also be thought of as an abstraction of depth.
Burgertime
Of course all of this is highly circumstantial and somewhat arbitrary. Besides, board games with jumping long predate video games and have developed all over the world. In his fascinating book The Oxford History of Board Games, author David Parlett devotes an entire chapter to games where one piece captures another by jumping over it (the following information is taken from Parlett's book). According to Parlett, the earliest game known with this mechanic is Alquerque: the game is described in a manuscript written in 1283, and may be the game called Qirkat mentioned in Kitab-al Aghani, an Arabic book of songs and poetry probably written before the author died in 976. Alquerque is largely accepted as the predecessor of what is called Checkers in the United States, and Draughts (or a variation thereof) in Europe. However, similar games have been found all over the world. Games such as Konane (Hawaii), Siga (Egpyt), Dablot Prejjesne (Sweden), Tobi-Shogi (Japan), Kolowis Awithlaknannai (Mexico), and Koruböddo and Lorkaböd (Somalia) all feature jumping capture.
The long popularity and widespread use of jumping indicates that the mechanic itself has some sort of intrinsic appeal. People tend to have positive associations with height, a topic explored by Lakoff and Johnson in Metaphors We Live By. Lakoff and Johnson refer to such associations as "Orientational Metaphors." For example, in Christianity Heaven is described as somehow "above" the Earth (as in the geocentric model of the universe that long dominated European thought). Our language expresses the same idea, with phrases such as "jumping up and down," "on cloud nine," "free as a bird" or simply "things are looking up." The opposite is true: Hell is underneath the Earth, we feel "down in the dumps" or "under the weather." (There are of course a few exceptions, such as "I'm down with X" or "high on Y," though whether these are positive or negative phrases depends on who you ask.) This psychology is not limited to humans: many dog behavior experts say that when your dog jumps on you she is being dominant, trying to put you in a submissive position within the pack. In season two, episode three of The Dog Whisperer ("Buddy the Animal Killer"), Cesar Milan recommends stepping over your dog to assert your position as pack leader. In his words, "over means dominant."
When a game piece jumps over another, it is in a superior position than its Earthly (boardly?) victim. The act of jumping your piece over your opponent's has an intrinsic satisfaction regardless of the in-game effect; this simple pleasure is extremely evident when watching beginners play Street Fighter. They jump frequently, almost constantly, relishing the motion: kicking your opponent is less satisfying than leaping into the air and then kicking him. That jumping leaves you extremely vulnerable is fairly obvious yet totally ignored. In his new book Game Feel, Steve Swink presents a picture of Super Mario Brothers tracing Mario's movements: his jumping creates a curved, arcing line. For Swink the shape of Mario's jumps have an intrinsic aesthetic quality: "Whether it's the motion of the avatar itself, animation that's layered on top of it or both, curved, arcing motions are more appealing" (306).
There is more to jumping than psychology and aesthetics, however. In many games jumping is fun because of the associated risk. In a Mario game a mistimed jump will send you into a pit or cause you to collide with the enemy you intended to stomp on. In the old Sonic games your speed increased that risk, as a single jump could carry you through several screens worth of space, leaving you unable to tell where and on what you will land. This may be the reason the new Street Fighter player jumps so insistently: they are playing to have fun, not to win. Jumping can mean power not just over an opponent but over the environment itself: would Master Chief seem so powerful if he could not jump over a small rock or fence? The ability to jump in a first-person shooter gives the player more control over the environment, which makes the game feel less linear: jumping out of a window is more satisfying than backtracking to look for stairs. Jumping was frequently used in later 2D beat-em-ups to create the illusion of 3D space. In these games the player primarily moves in four directions: left and right, towards the player and away. Jumping adds height, so the player now feels like they are playing in three dimensions, as in Battletoads. The same could be said of first-person shooters: without the ability to jump you feel stuck to the ground, as though you are a 2D entity in a 3D space.
That jumping has been a part of games for so long indicates that it appeals to players on a very basic level. When studying video games it can be easy to forget that games have thousands of years of history behind them, and that is a long time for a mechanic to remain fun. Jumping's prevalence also suggests a strategy for inspiration: do other common themes in language, myth and psychology exist? And if so, can they be adapted into a game?
GAMBIT is proud to introduce our first new game of 2009, now freely available for downloading: Tipping Point!
Tipping Point is unique among our games for several reasons. First, this game has our lowest set of system requirements so far: paper, a color printer, scissors and tape. (Or glue. We're not picky.) Although we frequently develop paper prototypes for our video games as they're being developed, Tipping Point is the first board game that we've made publicly available.
Second, this game represents our first (but definitely not our last) collaboration with the MIT Sloan School of Management. Tipping Point was developed over the MIT Independent Activities Period in January by Sara Verrilli (Product Owner, Documentation), Jason Begy (Production, Design, Documentation), Dustin Katzin (Design), Mike Rapa (Design, Art) and Jennifer Swann (Design) based on a challenge posed to us by our friends over at Sloan: how do you make a board game that represents the dynamics of project management?
The result is a cooperative puzzle game for up to four players. Players assume the roles of Project Managers, and must work together to complete projects before they go too far past their deadline. The game is won by completing a set number of projects without letting any project fail.
The game is designed to be both a fun game and a useful training tool, teaching players how to manage multiple projects while emphasizing the importance of long-term planning. Projects are completed through a mix of Concept and Production work. "Concept Work" represents the planning and research done in the early phases of a project, while "Production Work" represents implementing the project, such as building a product. Each turn the players decide which project to work on and which type of work to be done. There must be a balance between Concept work and Production work: Production work is more useful in the short term, but Concept work is more useful in the long term.
Over the course of the game players can see how their previous choices affect the current state of the game, which helps them understand the benefits of long-term planning. Concept work done on early projects will have a positive impact on later projects, making them easier to manage. Production work makes it easier to finish a project immediately, but players who spend too much time on Production work will soon find their later projects uncontrollable.
Tipping Point also demonstrates the problem of letting projects continue for too long. If they are not completed early on, projects will begin to negatively impact each other, creating a downward spiral that is difficult to reverse. The "Tipping Point" is the start of this spiral. If they want to succeed the players must work together to prevent the game from reaching this point.
The game is an engaging puzzle that requires players to think long-term and work together. If anyone's project fails, everyone loses: players win or lose as a team, and many decisions in the game must be made by consensus. As the game progresses the number of simultaneous projects increases, forcing players to think strategically about when to complete and when to begin new projects. A hasty decision can quickly change several small projects into an enormous, convoluted amalgamation that is almost impossible to manage.
While fun on its own, Tipping Point is an excellent team builder and project management training tool. It is highly recommended for any organization where teamwork and long-term planning are core values.
In early January, experiencing the kind of doldrums that readers of an academic blog about video game
research are no doubt quite familiar with, I picked up a little expansion to that one game. It took me a while to hit the new level cap of 80. After a few lucky runs, I was in a pretty good spot, and felt up to tackling some of of the end-game content. Poking around a friendly chat channel for a group, I signed up to run a dungeon I’d been through once before, only to be told I was undergeared and unknown, and was bounced from the group. A week later, I managed to connive my way back into the group to tackle a set of the toughest dungeons in the game. By the end of our run, I had managed to upgrade almost all of my equipment, including snagging some of the best gear available for Shamans who specialize in Restoration. This should make my life easier: I’ve got status, I can clear the hardest stuff in the game, right?
Research Proposal Deadline Extended to Dec 31, 2008
Faculty and post-doc researchers from Singapore and MIT are invited to submit proposals to GAMBIT for collaborative projects starting in Fall 2009. In previous funding cycles, proposals were due at the end of September and investigators received responses at the beginning of the following year. To reduce the wait between submission, approval, and funding, note that the deadline this year has been moved to December 31, 2008.
Before the deadline arrives, interested researchers are encouraged to email gambit-exec AT mit DOT edu for inquiries, support in finding collaborators, and feedback on draft proposals. More information on the proposal format and requirements can be found on the Research Proposals page.
GumBeat is the latest of the games created for the 2008 GAMBIT Summer program that is now available for download. Team PanopXis really brought it home with this one (of course, I'm a bit biased: I was one of the product owners for this team, alongside Matthew Weise). So now, please...
Take on the role of a young woman exploring her personal boundaries... no, that's not it.
Challenge a corrupt government bent on security at all costs... nah, still not quite right.
Blow big bubbles to persuade your peers that fun and joy needn't be opposed to civic order... yes!
Master our mastication-engine and gleefully guide a cohort of cavorting citizens past the police in order to persuade city hall to relax its War on Snacks in GumBeat!
It's been a busy week for GAMBIT – in addition to our preparations for this summer's wave of students, we've also been getting a lot of buzz in the press about one of last year's games, AudiOdyssey. The game has already gotten some good press from WIRED, CNN, the Game Career Guide and Gamasutra, but now we're also getting attention from CNET, Wii Fanboy and a whole host of others. Definitely not a bad way to start the summer!
There is one thing we'd like to clarify, though. Although AudiOdyssey was developed to use the Wii controllers, it is not a game for the Wii – it's a game developed in Flash to run on PCs. It would definitely be cool to have the game show up on the Wii at some point, but the AudiOdyssey folks are currently focusing their attention on new projects. Watch this space for possible announcements about said projects later this year!
Other places talking up AudiOdyssey around teh Intarwebs include:
GAMBIT Highlights a Year of Development & Research: Wiip
This is part three of a multi-part series reflecting back on the games developed during the first year of the Singapore-MIT GAMBIT Game Lab, a five-year research initiative created to address important challenges faced by the global digital game research community and industry. Last time, we looked at AudiOdyssey, a rhythm game designed to be playable by the sighted and the blind. Today we focus on Wiip, one of many games developed during the summer internship program.
Wiip was one of six games developed at GAMBIT this past summer. As you might have guessed from its name, the game uses the Wii remote as its main controller. The Wiimote, as it is commonly called, was chosen as the controller to give players a greater sense of immersion and agency in the game.
When playing Wiip, the player steps into the role of Mustachio, a circus ringmaster whose animals have gotten out of control. As the cute creatures run and bounce towards the screen, it is the player's job to stop the creatures before they attack. Fortunately for Mustachio, it only takes a simple crack of his bullwhip to tame the animals. Players can also utilize the whip crack, which triggers the combo system that has the potential to tame all the oncoming animals on the screen at once. But what does any of this have to do with research-oriented game design?
Press play for a video walkthrough of the game.
Alex Mitchell, Wiip's Product Owner, set out to explore the spectrum between abstraction and expression in game design, while creating a new vocabulary for interactivity in the process. This research goal was a driving force in the adoption of the Wiimote to play the game. The Wiimote makes use of multiple accelerometers to measure the movement and tilt of the controller. This technology allows the player to manipulate the Wimote like a real whip, creating a greater sense of immersion when playing the game. Although the game is meant to be played using the Wiimote, Wiip can also be played with a computer keyboard.
Wiip was conceptualized as a way to investigate controller expression, therefore choosing the correct control scheme was an integral part of the game design process. Trey Reyher, Wiip's Quality Assurance Lead, had this to say about the process:
"It was fascinating to see how testers responded to the controller. Those who were unfamiliar with the Wii remote played a bit timidly at first, whereas those who had used a bullwhip before could be seen gesticulating wildly in front of the computer screen. Eventually both groups tended toward a happy medium which allowed them optimal control with a minimum of exhaustion.
"We also encountered an unexpected difference in the play style of female versus male players. When female testers played Wiip, their movements tended to be more graceful and fluid than their male counterparts. This resulted in few of their motions exceeding the game's force threshold, which detects when a player's movement is significant enough to be interpreted as a swing of the whip. This was a challenging aspect to tune, since the threshold needs to be sensitive enough to correctly detect a swing without generating false positives as the player adjusted the direction of the Wii remote to target specific lanes. A compromise was reached after extensive focus testing of female players.
"Since we were targeting a broad audience, I tried to find as many testers as I could from the MIT community and beyond. Perhaps the best feedback I got was at a local ice cream parlor, where I was showing the game to some friends and observing their patterns of play. As they were playing, the employees of the store jumped over the counter and asked to play Wiip. They picked it up quickly, and seemed to greatly enjoy the game. In fact, one of them asked me, 'Did you just buy this next door?' I was confused until I recalled that the ice cream parlor was next to a game specialty retailer, and replied, 'No, we made this game.'"
More games in the Wiip universe are currently in development at the Singapore branch of the GAMBIT Lab.
Wiip was created by Alex Mitchell, Teo Chor Guan, Joshua Wong, Zhou Xuanming, Edmund Teo, Jonathan Johnson, Desmond Wong, Tio Lok Ling, Trey Reyher, contains original music by Guo Yuan, sound effects by "Fezz" Hoo Shu Yi, and voices by Matt Weise. Wiip can be downloaded here.
Posted by Mandi Holmes on May 23, 2008 9:00 AM
|Permalink
May 21, 2008 9:00 AM
GAMBIT Highlights a Year of Development & Research: AudiOdyssey
This is part two of a multi-part series reflecting back on the games developed during the first year of the Singapore-MIT GAMBIT Game Lab, a five-year research initiative created to address important challenges faced by the global digital game research community and industry. Today we focus on AudiOdyssey, one of many games developed during the summer internship program.
AudiOdyssey is a rhythm video game which stars Vinyl Scorcher, a DJ in a nightclub trying to get people to dance. By matching various rhythmic sequences, Vinyl adds different tracks to a song to get club goers moving. However, if the party gets too crazy, there's a chance Vinyl's table might get bumped, causing him to lose tracks and forcing him to resynch his music. A single-player PC game, the user can control the game either with the keyboard or with the Nintendo Wiimote.
So, what's the research the game is based on? Well, AudiOdyssey is a fun game designed for everyone to enjoy, regardless of their level of sight. What does that mean? A blind individual can play AudiOdyssey just as well as a sighted person, and vice versa; furthermore, if we accomplished our research goal, both groups should enjoy the game with a similar challenge level. This was the original goal of the project – to create a game that both the sighted and non-sighted could play together and share a common gaming experience.
Press play for a video walkthrough of the game.
The game serves as the research for Eitan Glinert's Master's thesis, and Eitan is currently conducting game testing here at MIT to determine how effective it was in achieving its goals (if you are in the Boston area and want to help out with testing, drop him a line at glinert [at] mit [dot] edu.) This coming summer, a spiritual sequel to the game will expand on what was learned in the first version and improve on the weak areas. Most notably, the new game will likely have an online multiplayer element, so that people in remote locations with varying levels of eyesight will be able to play the game together.
AudiOdyssey was created by Eitan Glinert, Lonce Wyse, Dominic Chai, Bruce Chia, Paviter Singh, Mark Sullivan, Edwin Toh, Jim Willburger, Yeo Jingying, and contains original music by Guo Yuan. AudiOdyssey can be downloaded here.
Posted by Mandi Holmes on May 21, 2008 9:00 AM
|Permalink
May 19, 2008 9:00 AM
GAMBIT Highlights a Year of Development & Research: Elementalyst
Summer is fast approaching at the GAMBIT MIT-Singapore Game Lab. In a little under two months the second class of GAMBIT summer interns will descend upon Boston to work with MIT faculty, students and staff in pushing the limits of video game research.
Expectations are high. A number of the games developed during GAMBIT's inaugural year have been extremely well received: Backflow was a 2008 Independent Games Festival finalist in two categories (Best Mobile Game and Innovation in Mobile Game Design) and AudiOdyssey was recently chosen to be featured as a postmortem at Gamasutra. The GAMBIT Singapore Lab is currently putting the finishing touches on Backflow and Wiip for their June 2008 release, and AudiOdyssey will undergo a major redesign this summer to prepare it for publication.
The past year has been a whirlwind of Scrum meetings, game development, testing and of course playing as many games as we can (we like to call it "research"). To help us remember it all, over the next few weeks we'll be highlighting some of the games developed at GAMBIT. Today we'll be looking at Elementalyst.
Elementalyst is a single player casual game modeled after games such as Lumines and Puzzle Fighter. Players build chains of each element while awaiting the arrival of the catalyst block. When the catalyst finally appears it induces a series of chain reactions between the three elements and helps clear the screen. The player's goal is to build larger and larger chains for more combos and more points.
As GAMBIT's first game development team, the main goal of the project was to expose students and staff to the process of game development in early 2007. Students were responsible for evaluating various software packages – including GIMP, an open-source graphics editor similar to Photoshop, and Microsoft's XNA – as well as test drive the Scrum Software Development Methodology, which has now been adopted by all of GAMBIT.
Working on Elementalyst has even persuaded some students to pursue game development as a career. "I love seeing all the different aspects that go into making a game and working alongside other students to produce something great," said Elementalyst programmer Jim Wilberger. "I could definitely see myself doing this for many years to come."
Despite the trials and tribulations of designing a video game for the first time, the majority of students on the Elementalyst team returned to GAMBIT over the summer or during the fall and spring terms. It just goes to show that we here at GAMBIT just can't get enough when it comes to games.
Elementalyst was created by Mark Grimm, Sharat Bhat, Jonathan Johnson, Jim Wilberger, Jamie Jones, Chris Casiano, Ben Decker, and contains original music by Jeremy Flores. Elementalyst can be downloaded here.
Posted by Mandi Holmes on May 19, 2008 9:00 AM
|Permalink
