GAMBIT http://gambit.mit.edu/updates/ Singapore-MIT GAMBIT Game Lab en Copyright 2009 Mon, 23 Nov 2009 09:30:38 -0500 http://www.sixapart.com/movabletype/ http://blogs.law.harvard.edu/tech/rss Cat Movement (Scaring Cats) 1. Each object has a different radius of interaction AND 2. The nature of this radius depends on the direction from which the cat approaches the object AND 3. The nature of this radius depends on the speed that the cat approaches at If the interaction occurs at all (unclear) it is then difficult to determine HOW the cat interacts with the object:
1. Does the cat interact at all? 2. Which is the resultant cat vector direction (can depend on speed, entrance angle)? 3. What is the resultant cat magnitude?
Example: So this means that our bag (which is only accessible from the 'front' and has a radius of the spaces located at (-1,1) (0,1) (1,1) ) has 6 directions from which it can be uniquely approached . [E.g. if that cat approaches from <0 1> it will always enter the bag, but if it comes from <0 -1> it will never enter the bag]. Notice how difficult already it is to describe interactions when the cat is not approaching from one of the 8 primary directions. For instance if the cat is traveling from (1,2) to (1,1) to (1,0), this is completely unique from a diagonal approach and yet had not been included in our original analysis. The cat can also be traveling at one of three speeds, each of which may have a unique effect on the interaction. E.g. If the cat is to the North East of the box and traveling Westward (different spatial thinking then we were using before, but necessary to describe the movement) then it will enter at (0,1) if traveling at speed 1, (-1,1) if traveling at speed 2, and not at all if traveling speed three. So three speeds, six directions... that means there are 18 unique interactions that must be defined for each object. That's too many for a naive user to be able to just 'pick up on' while trying out the game. If this seems confusing, that's because it is. Solutions:
- Should we simplify objects down to basic properties? Similar to the excel sheet we were working on--need simpler objects with less unique properties. - Should we scrap this idea and move to sinks and sources? May be even harder to model. - Should we eliminate the ability to move diagonally? - Should we reduce the number of speeds? - Should we alter our thinking here--should the cat interact with the SPACES around an object the same way every time (regardless of the direction it entered the space) and maybe only vary based on speed.
o There are a lot of problems with thinking in 'vectors'
]]> http://gambit.mit.edu/updates/2009/11/cat_movement_scaring_cats.php http://gambit.mit.edu/updates/2009/11/cat_movement_scaring_cats.php Research Prototyping Scaring Cats UROP Mon, 23 Nov 2009 09:30:38 -0500 Zombie Prototype v2 (Weise Zombie Project) Our primary goal with these prototypes was to explore the role of communication and information exchange within the game, particularly in terms of how this mechanism could be used to influence NPC characters. We wanted to examine a) how a player could obtain information regarding NPC's goals/ character/ desires, b) how a player could use this information to influence the NPCs to accomplish a common goal, and, to a lesser extent, c) how selective or lacking information would affect the scenario's outcome. Play testers (naive group members) were informed that their goal was to elicit the information from NPCs necessary to obtain a given objective. Version e: Save Drew, Save the World We approached this prototype by beginning with the scenario and working backwards to the characters. The scene was set with two houses. DREW was visible to the player and was in the YELLOW HOUSE. The player could also see DORIS and MATT who were hidden behind a ROCK. There was also a RED HOUSE to the north. The goal of the scenario was to rescue DREW. DREW was stuck inside a house that was BARRICADED to keep out zombies (this was a point of contention at one point, see notes). The ability to take down BARRIERS was not available to all characters. The player was told that he/she was a good fighter and would win 5/6 times. CHARACTERS: DREW
- Loyal o High follow orders - Afraid o Low fighting - Weak o 2/6 chance of winning fight
MATT:
- Trusts Doris o High group with DORIS o Follows DORRIS' orders - Knows were PHILLIP is - Normal fighter o Kills 3/6 zombies
DORIS:
- Badass o Kills 5/6 zombies - Independent o Will not follow orders that put her at risk
PHILLIP:
- Friends with DREW o High will to group with DREW - Knows how to build BARRIERS
We designed the level with the intention that the player would approach the YELLOW house to save DREW. Upon reaching the YELLOW HOUSE the player learned that DREW did not know how to take down BARRIERs and was trapped. The player could choose to fight the zombies at this point, seek out the NPCs, or visit the RED HOUSE. If the player approached the RED HOUSE, they would see a barricaded house and would not be able to enter. The player had to talk to MATT and DORIS to see PHILLIP. Upon talking to MATT and DORIS, the player would learn about the NPC's inner states. If the player asked them to join his/her party, DORIS would decline, explaining that she would not join the player if there was not a benefit to her/ MATT. The player could either demonstrate his/her benefit by killing the zombies or by furthering the conversation. If the player inquired whether MATT or DORIS knew how to take down barriers, MATT would respond that he could not, and if he could, he would save PHILLIP, who was in the RED HOUSE. The player could offer to save PHILLIP. Still, DORIS and MATT would not leave the ROCK unless sufficient danger was removed. Once the zombies were killed, DORIS and MATT joined the player's party and proceeded to the RED HOUSE. At the RED HOUSE, the player, MATT, and DORIS could together generate enough volume to alert PHILLIP to their presence. From here, PHILLIP dismantled the BARRIERS and would talk to the player's party. The player needed to convince PHILLIP to join his/her party. PHILLIP could be convinced if he was told the player wanted to rescue DREW as PHILLIP was friends with DREW. The player's party could proceed to the YELLOW HOUSE where they would rescue DREW. PHILLIP could take apart the BARIERS but DREW would not come out if there were zombies. The player could choose either to kill the remaining zombies or try to convince DREW to follow his/her lead. If the player ordered DREW to follow, DREW would follow, providing the player did not get too close to zombies. NOTES: - The dice rolling mechanism for fighting zombie's didn't work out so well, due to the still relatively high probability of death
• The randomization of the fighting was included for two reasons-- primarily to simplify the scenario, and secondarily to provide the player with a good reason *not* to engage the zombies. We wanted to include a sense of risk to knocking out zombies. •This was not fully accomplished by the dice, as there was no real penalty in losing (play began over again). •Perhaps a better way to model would include the use of a limited resource for fighting, so players must carefully choose which zombies to engage. This may also represent the players 'willingness to fight' as explained in previous posts.
- We needed to explain why DREW couldn't undo the barricades. The best explanation was, perhaps, because DREW entered the building with someone else who had been bitten. The person barricaded the room and then died. This was still a stretch.
• When using a GM to manage paper prototype playtests, this person must know the game *very well*. This is a problem we have encountered several times. A GM must be able to produce conversation on the fly and be able to explain why the set-up is the way it is. They must have a very clear understanding of the rules, and know how and when to answer questions. This is critical to a quality playthrough of the prototype.
]]> http://gambit.mit.edu/updates/2009/11/zombie_prototype_v2_weise_zomb.php http://gambit.mit.edu/updates/2009/11/zombie_prototype_v2_weise_zomb.php Research Prototyping UROP Weise Zombies Fri, 20 Nov 2009 09:30:18 -0500 Games at GAMBIT 11/20: Ode to Treasure This week's Games At GAMBIT will feature a selection of games from Japanese developer Treasure, perhaps best known for _Gunstar Heroes_ and _Ikaruga_. The games this week are lesser-known but all excellent in their own right, including: * Radiant Silvergun * Guardian Heroes * Silhouette Mirage * Sin & Punishment * Mischief Makers * Astro Boy Games will run from 4:00pm to 6:00pm in NE25. http://gambit.mit.edu/updates/2009/11/games_at_gambit_1120_ode_to_tr.php http://gambit.mit.edu/updates/2009/11/games_at_gambit_1120_ode_to_tr.php Events Wed, 18 Nov 2009 12:14:13 -0500 Word Puzzle 101 Background After some good, hard thinking, the Sophocles group approached our prototyping team to come up with some quick and dirty paper prototypes for one of three minigames. They had already decided they wanted to focus on three areas--a game about violence, a game about escape, and a game about words. We were asked to focus on the game about words, inspired by the riddle of the sphinx in Sophocles' Oedipus Rex. Design An initial brainstorm gave way to two groups of thought. As such, we decided to break up the task and work in groups of two. Our group focused specifically on the idea of words building a bridge or tower from the player to a desired object. Since words are built with units, we gathered that each unit could become a building block in the tower. A structure could be built using these blocks by overlapping matching units in words. This could be achieved either with morphemes (the smallest meaningful units of a word) or with individual letters. The unit-stacking portion could either be open-ended or restricted based on our design. In an easier to design, more restricted model, players would be given a scaffold of 'blanks' within which they could place letters/ morphemes. This may only have one solution depending on the design. Given that there were only one solution, players would be given cues as to which letters would overlap (see figure). Word_Puzzle.jpg A more open-ended design would ideally allow players to build up as they go, with only limited constraints. This could be accomplished with a drag-and-drop interface using 'unit blocks' of 2-3 letters. Players could build vertically or horizontally such that the final result may look like a crossword. To ramp up difficulty, certain restraints could be built into the building landscape (e.g. a long word might span through the middle of the screen so that the player has to match the letters to build through it). We built a quick prototype of the first version as described above. Some letters were filled in to ease the process for the player. This may or may not have significantly changed gameplay, which would need to be considered before taking this concept further. The initial board and final result are shown below. Initial Board Word_Puzzle_partial.jpg Final Board Word_Puzzle_Final.jpg ]]> http://gambit.mit.edu/updates/2009/11/word_puzzle_101.php http://gambit.mit.edu/updates/2009/11/word_puzzle_101.php Research Prototyping UROP Wed, 18 Nov 2009 10:16:33 -0500 11/21/09: Tech Model Railroad Club Open House The Tech Model Railroad Club was one of several organizations responsible for creating the first videogame at MIT, SpaceWar! If you're curious what they're up to these days, check out their upcoming open house. The Fall 2009 Open House of the Tech Model Railroad Club of MIT will take place Saturday, November 21, in room N52-118 on the MIT campus (on the first floor of the MIT museum building, 265 Massachusetts Avenue, Cambridge). The club will be open for two sessions, from 2-5 and 7-10 pm. This event is open to everyone, and admission is free.]]> http://gambit.mit.edu/updates/2009/11/112109_tech_model_railroad_clu.php http://gambit.mit.edu/updates/2009/11/112109_tech_model_railroad_clu.php Events Wed, 18 Nov 2009 08:00:00 -0500 Round 1 The first task of the semester for the Fast Prototyping Team was to come up with ideas for a game about a girl and her dog. One of the more intriguing concepts from our initial brainstorming session involved having the player control a blind girl who depends on her guide dog to get around (rejected idea: Blind Girl Frogger). But how do you prototype a game where your protagonist is blind when all of your playtesters can see? Our first challenge! In the end, we went with the somewhat obvious solution of simply requiring playtesters to close their eyes or look away from the game boards that we created. We also set up the boards to conceal certain information from the "dog" (who was allowed to see the board), since a dog would have a much more limited understanding of the world than a human would. Unfortunately, when your playtesters and your designers are the same people, any steps you take to hide information about the game world will end up being useless when you actually play the game. So, in order to keep some playtesters in the dark without making any designers sit in a corner and twiddle their thumbs, we broke into two groups that would each come up with their own version of the prototype. There weren't a lot of constraints---specifically, the game had to have two players, with one player taking on the role of the dog and the other that of a blind person, and the person had to rely on the dog to find her way around an unfamiliar space. The first group drew out a set of corridors and required the player and her dog--represented by a couple of little plastic cubes--to navigate from one end to the other. The "human" was not allowed to look at the board, so it was up to the dog to tell her which directions they could go and if something was blocking their way. The corridors were marked with things like "Danger!" and "?", representing (unsurprisingly) danger and unfamiliar objects, respectively, but no further details were included. This was to model the fact that the dog might not be able to identify a particular object (for example, a dog probably doesn't know what a mop is--he just sees it as a non-threatening object) and also to preserve the interspecies communication barrier--even if the dog can see something dangerous coming up, he can't tell his person exactly what it is (spike pit? large carnivorous plant?), only that it should be avoided. It was up to the person to investigate and overcome the obstacles using her other senses ("I listen for any strange noises") and her ability to pick up and identify, and in some cases use, strange objects. And just to make it more difficult, parts of the board were covered up and were only revealed when the human and dog arrived at a point where the dog would be able to see more of the map. The second group envisioned their playing area as a large, cave-like space for the human and dog to explore. In this version, the object was to find an unspecified widget (again represented by a little plastic cube) located at one end of the cave and put it into a widget-shaped impression on an altar in another part of the cave, all the while avoiding dead ends and traps. The walls of the cave and its passages were constructed out of Play-Doh, and the human player had to keep her eyes closed and "navigate" using her finger to feel out the paths formed by those walls. The dog had the ability to move freely over the entire map, regardless of the human's position, and could tell the human which way she should go next or which areas were dangerous and should be avoided. In addition, the dog was able to pick up and carry objects in its mouth if the human ordered it to do so. When the two groups re-joined to play the prototypes, we were surprised that they had turned out to be so different from each other. We had talked about the problem extensively prior to splitting up, and I think we felt that we were all pretty much on the same page. I was in the first group, and I don't think we even considered the idea of 3-D features that allowed the player to physically feel her way around the game world. I was particularly interested to see that the second group had not included a representation of the dog or the human in the world. The human's position was marked by the location of her finger, and since the dog was allowed to run all over the map--in essence, he could move to any location at any time he wanted, with no restrictions--there was no real need for him to have a token on the board. In that prototype, the dog was actually more of an all-seeing advisor than an in-world guide. In general, the dog behavior in the two prototypes was very different--the dog in the first prototype could do about three things (warn of danger, warn of an obstacle, and indicate available directions for travel), but the dog in the second was much, much more capable (more of a guide chimp, perhaps). Splitting into two teams like this may have its disadvantages, but we usually find that it's valuable to do so because we get to experience different takes on a game that we might not have encountered if we'd stayed in our group of 4. The technique is also applicable to pretty much any of the kinds of games that we've been asked to consider this semester, from word games to zombie apocalypses (note: this applies only to game design. Technique may not be valid in the case of actual zombie apocalypse). http://gambit.mit.edu/updates/2009/11/round_1.php http://gambit.mit.edu/updates/2009/11/round_1.php Research Prototyping UROP Tue, 17 Nov 2009 13:50:50 -0500 Open Focus Testing: Thursday, November 19th, 5 - 7 PM Focus Testing: November, 19th, 2009! Games! Opinions! Munchies! When: November 19th, 5 PM to 7 PM Where: The Singapore-MIT GAMBIT Game Lab, 5 Cambridge Center, 3rd Floor (aka MIT NE25, 3rd Floor) (Please introduce yourselves as visitors to GAMBIT in the lobby when you arrive.) On Thursday, the 19th, please come visit the GAMBIT Lab to play and give us your opinions on two of the games we've been working on this Fall, Abandon and Pierre! These two games were initially developed over the summer. Abandon is a whole new game, with nearly 50 new levels, many new features and exciting new gameplay. Pierre has added new levels, new art, and new sounds, and the gameplay has been improved and updated. We are excited to see people playing our games, and we look forward to hearing your opinions about them. We take our focus testing seriously - come on in, and let us know how our games are playing, so we can keep improving them! ]]> http://gambit.mit.edu/updates/2009/11/open_focus_testing_thursday_no.php http://gambit.mit.edu/updates/2009/11/open_focus_testing_thursday_no.php Events Mon, 16 Nov 2009 16:25:03 -0500 Video Game Orchestra Presents ~Awakening~ december.jpgThe Video Game Orchestra (VGO) will hit the Berklee Performance Center (BPC) stage again on December 5th, 2009 at 7:30 pm, nine months after its previous premium sold out success at the venue. Nearly a hundred musicians will be presenting new arrangements of the classic such as Super Mario and Final Fantasy, as well as music from newer games such as God of War, Silent Hill, and Metal Gear Solid. Featured guests include Wataru Hokoyama, an accomplished film/video game composer. His score for the SONY Playstation3 game "Afrika" has won him both critical acclaims and industry awards. He will be guest conducting an orchestral suite of Afrika. "This concert ~Awakening~ is going to feature the full VGO, as it is waking up from a long 9 months of sleep," said Shota Nakama, the founder and director of VGO. "We will be representing diverse styles of music and our renowned symphonic rock style with even better, impressive performance quality. We will surprise you." The concert is $10 for students or 18 under, and $15 for the general public ($5+ on the day of). Purchase can be made at either Ticketmaster or Berklee Performance Center, located at 136 Massachusetts Avenue, Boston. (visit berkleebpc.com or call 617-747-2261 for more information.) A pioneer in raising awareness of video game music repertoire, VGO makes its tribute by performing non-stop at different venues and video game related events. The show this early May in front of about 5000 people earned VGO praise for its outstanding performance and contribution to the video game industry. As what Boston Local media described, VGO "is the new sound for the new generation." About the VGO VGO is a contemporary orchestra that performs orchestral arrangements of video game music. Founded in May 2008, VGO is the first and only student-run orchestra that showcase these interactive media compositions. It comprises of a 45-piece symphony, a 40-piece choir, and a 5-piece rock band. The regional and international award-winning musicians come from over 20 countries. This multi-cultural diversity contributes to the source of VGO's unique signature. Contact info Shota Nakama Creator/Artistic Director/Arranger 253-468-8196 shotanakama@gmail.com Po-Ya Chang Production Manager poya.chang@gmail.com]]> http://gambit.mit.edu/updates/2009/11/video_game_orchestra_presents.php http://gambit.mit.edu/updates/2009/11/video_game_orchestra_presents.php Events Mon, 16 Nov 2009 13:37:28 -0500 That Was the Game of the Week! Game of the Week. We certainly hope that is was informative, or interesting, or insightful, or intriguing, or any other nice adjective that starts with the letter "I". If you have any questions about our games, about our lab, or about anything we do really, please don't hesitate to contact us. We want to thank you for reading, and we want to encourage you to check back to our website often! Finally, we will leave you with this great poster. This is a game I would love to see! Cheers! AllStarFIghter.jpg]]> http://gambit.mit.edu/updates/2009/11/that_was_the_game_of_the_week.php http://gambit.mit.edu/updates/2009/11/that_was_the_game_of_the_week.php GotW Fri, 13 Nov 2009 17:00:26 -0500 Some Concept Team Logos CB_Logo_Concepts.jpg One last one for all y'all!]]> http://gambit.mit.edu/updates/2009/11/some_concept_team_logos.php http://gambit.mit.edu/updates/2009/11/some_concept_team_logos.php GotW Fri, 13 Nov 2009 16:30:03 -0500 The Many Kirbies of GAMBIT Camaquen artists! Kirbies.jpg Come right back, ya hear!]]> http://gambit.mit.edu/updates/2009/11/the_many_kirbies_of_gambit.php http://gambit.mit.edu/updates/2009/11/the_many_kirbies_of_gambit.php GotW Fri, 13 Nov 2009 15:00:00 -0500 The Truth about Game Development Slave_Driver.jpg More coming up around the bend.]]> http://gambit.mit.edu/updates/2009/11/the_truth_about_game_developme.php http://gambit.mit.edu/updates/2009/11/the_truth_about_game_developme.php GotW Fri, 13 Nov 2009 13:30:11 -0500 Friday Games at GAMBIT: Extreme Sports Edition tony-hawks-project-8-20060929023835228_640w.jpgToday, Games at GAMBIT is getting Xtreme. We'll be playing a batch of Extreme Sports games (loosely defined). Join us at GAMBIT from 4:00 - 6:00. Bring your own Mountain Dew. Game selections include:
  • Tony Hawk Underground
  • Skate
  • Wave Race
  • SSX 3
  • Jet Set Radio Future
  • Downhill Domination
  • Fight Night 3
  • Super Mario Strikers
]]> http://gambit.mit.edu/updates/2009/11/friday_games_at_gambit_extreme.php http://gambit.mit.edu/updates/2009/11/friday_games_at_gambit_extreme.php Events Fri, 13 Nov 2009 13:06:03 -0500 Nice Hat Nice_Hat.jpg More coming right up!]]> http://gambit.mit.edu/updates/2009/11/nice_hat.php http://gambit.mit.edu/updates/2009/11/nice_hat.php GotW Fri, 13 Nov 2009 11:30:30 -0500 Camaquen Dev Team Blog Camaquen, a colorful reflection on different ways for games to treat conversation as a game mechanic. We on Team ChatterBoxers are very proud of our work and hope that you find something worth listening to in it. Please run here and give it a shot! We'd like to talk a little bit about the experience of making this game, and provide some food for thought. We'll address something that went very right for us, but also a pitfall or two that we learned about. First, a positive experience for us: our team had a number of people familiar with multiple disciplines. Our artists were capable of adapting to multiple styles and techniques, our producer had a substantial amount of coding experience, our writer was also a designer, and our QA had a surprising knowledge of animation techniques. Because of this, we weren't locked into tunnel vision about the demands of our individual tasks. It's important for teams, especially small ones, to be able to meet at the edges and understand, if not the details about each others' tasks, at least the constraints that everyone else is working under. Not only does it help you make placeholder assets or help come up with good solutions to shared problems, but it also pays off when one person has to hand off work to another person. Everyone's job on a game team is really interconnected, and knowing that changing one line of text here will mean an art asset over there has to be redone helps evaluate priorities and keep bugs free. camaquen_2.jpg
Being close keeps team members in contact and helps join the pieces together.
Of course, knowing other jobs and thinking about consequences doesn't take the place of good communications skills and procedures -- if you are willing to let tasks bleed across roles like this, it's even more important that we keep track of exactly's what being done and when. We made good use of task tracking software and daily reports in our SCRUM meetings to let each other know what was implemented when, and what pieces other team members needed to take care of. Because of this, people knew when they were being depended on, and our team ended up with a remarkably fast turn-around on most of our tasks. This in turn let us make lots of small adjustments very quickly, which helped a lot in tuning our interface and conversational models, which were key to the research goals of the project. camaquen_3.jpg
Disagreements happen, but are less disastrous when the team communicates often.
On behalf of Team ChatterBoxers, I'd like to say thank you to the Singapore-MIT GAMBIT Game Lab staff and administration, to all of our co-workers who provided feedback, and most of all, to the players. Thanks and please enjoy Camaquen! camaquen_4.jpg
Concept artwork from one of our artists, Fabiola Garza
]]> http://gambit.mit.edu/updates/2009/11/camaquen_dev_team_blog.php http://gambit.mit.edu/updates/2009/11/camaquen_dev_team_blog.php GotW Fri, 13 Nov 2009 09:26:37 -0500