Ten Years of Civ II: Why Procedurality is Insufficient yet Critical
The Internet (well, the part of it I care about anyway) practically exploded this morning in response to the 10 year Civ II game.
If you haven't read that article yet please do so now, as I'm going to assume you are familiar with it for the rest of this post.
While I certainly found the story interesting, especially since I've been reading Noah Wardrip-Fruin's excellent book "Expressive Processing," I have been wondering why everyone has found it so compelling. On Twitter Chris Remo called it "breathtaking," and this doesn't seem to be an isolated case of hyperbole.
So what is it about this particular game of Civ II? I think that the answer is pretty straightforward, but is interesting in light of a recent game studies debate.
It seems pretty apparent that we (myself included) find this instance of Civ II compelling because it resonates with our fears regarding our own future. With Stanford biologists recently claiming that the current state of the world is unsustainable, recent economic pressures, climate change and general environmental destruction, in this game we see our potential future. It looks like a real possibility, and it scares us. This fear is amplified by the fact that it comes from a medium so many of us are so attached to, and furthermore, from a simulation that many people don't realize is as ideologically charged as it is. It's a bit like predicting the Super Bowl with the most recent Madden game. As Ian Bogost might say, people reading this story are working through simulation fever, asking themselves what it might mean that Civ II predicted this (feasible?) outcome for us.
What is fascinating to me about the reaction to this game is how it appears in light of recent game studies discourse in the wake of Migel Sicart's fascinating "Against Procedurality." As the argument goes, proceduralists believe that the meaning of a game arises primarily, if not only from, the rules and mechanics driving it. On the proceduralist side, games researcher Mike Treanor has perhaps most openly embraced this viewpoint.
The reaction to the 10-year Civ II game shows one of the major shortcomings of the proceduralist stance: the meanings that people make of games depend heavily on the context in which the games are perceived. I highly doubt anybody would care about the Civ II game if it did not seem so real, so possible, and it only seems this way because of the world we live in and how we understand it. If I played a game of Civ II for ten years and it ended in a utopian paradise, would anyone care?
I don't wish to throw-out procedurality entirely, though. As is often the case, the truth lies in the middle. This instance of Civ II is important to us because the rules of the simulation enabled it to happen AND because of who we are and our experience of the world. It is the sum of what the game is and how it works AND our own selves that make it meaningful. Subtract either and the meanings that so many are finding it, the meanings that make the story compelling, are gone.
Update:
From debates on Twitter I've realized this was not as clear as it should have been. I will blame writing quickly, but own it anyway and leave the original unchanged. My goal with this piece was to be a reminder that meaning construction is a collaborative process.
Many say that the "proceduralist" is a strawman, and they could be right. But I've met people who believe the game is everything, and I've met people who believe the game is nothing and it's all on the user. I don't think either viewpoint is correct, and that most people don't hold such extreme views, but even at the extremes both are valuable.
And I forgot to add in the original that Mike does great work, and I highly recommend it.
As we wrap up development on our Arduino version for the 50th anniversary of Spacewar! at MIT, undergraduate Kaivan Wadia reflects past few weeks in the following blog post.
3 2 1... Blast off!Spacewar! is ready to be played with all the peculiar features of the original game. The last blog post mentioned the clever manner in which the spaceships were drawn. We decided not to use that exact technique but instead use the Gameduino's sprite technology to implement our version. This turned out to be very efficient in terms of management of the game state and had the added bonus of making collision seem easy to implement, even though we did not use the Gameduino's collision detection mechanism in the end. The night sky background was also implemented using the sprite technique, thereby remaining true to the original game, where each star is drawn separately after checking to see whether it is in the viewable region of the screen.
Next, we went on to add the thrust and hyperspace features for the spaceships. Hyperspace required a bit of repeated manipulation to get the counters correct for the time spent in hyperspace and the cool down time between two hyperspace jumps. The thrust for the spaceships was implemented using sine and cosine functions, which also posed a problem considering the limited capabilities of the Arduino microcontroller. Using floating point and long variables was not very efficient, as there was limited RAM on the Arduino, which would be used up quickly if we kept using them.
Once we got the thrust feature working, the next logical feature to tackle was gravity, which posed the same computational problems. One of the main features of Spacewar! is the ever-changing gravity and its sling-shot effect on spaceships under certain circumstances. To implement the change in gravity we first simply divided a constant by the distance between the sun and the spaceship. This gave a very positive result in terms of the effect of gravity but did not produce the sling-shot effect that Spacewar! originally had. We then decided to implement gravity as the ratio between a constant and the square of the distance between the sun and the spaceship. This gave us the desired sling-shot effect. It was then just a matter of adjusting the thrust and gravity constants to make the game interesting and playable. One peculiar result of this implementation of gravity was that when you approached the star at a certain angle and certain speed you could be bounced of in a completely different direction or pass right through the star at a very high speed, which was crazy but fun and true to the original game.
The next task was to get the spaceships to be able to blast torpedoes at each other. This was relatively simpler to implement considering our experiences with the thrust and gravity problems. The amazing feature here was that the torpedo velocity also depended on the velocity of the spaceship. This later caused a problem in collision detection: if you were travelling at a very high velocity, turned around, and fired, you would shoot yourself. This solution to this problem was to store the velocity of the torpedo separately and have the first appearance of the torpedo completely independent of the velocity of the spaceship.
One of the last tasks was the collision detection algorithm. The Gameduino itself has an in-built pixel perfect collision detection mechanism, which seemed the logical choice, but later posed a lot of problems. The problem with the Gameduino's collision algorithm was that it only detected a single collision and could not report multiple collisions for the same sprite. Since we had implemented the stars as sprites it was very tedious to detect whether a spaceship was colliding with a star or something else. In some cases a collision would not be reported at all!
We finally decided to implement the collision algorithm used in the original game. The original algorithm considered imaginary circles around the spaceship and detected whether any object capable of blowing it up was within that circle. This resulted in a slightly mysterious effect where torpedoes could pass through the spaceship occasionally. Sometimes two spaceships could pass through each other at certain angles. A spaceship could also be blown up by a passing torpedo that was not going to hit it, but was simply within the circle. This was faithful to the original PDP-1 game, and thus acceptable for our version. Implementing this algorithm was computationally heavy on the Arduino but did not slow it down. We also got the desired effect we were looking for: torpedoes would occasionally pass through a spaceship.
After collision detection, we were left with the explosion of the spaceships. In the original game the explosion of a spaceship resulted in a large number of dots on the screen at the site of the explosion. We wanted to implement the same but with a Gaussian distribution. On implementing the algorithm to generate random number in a Gaussian distribution the game slowed down dramatically when an explosion took place. Although this did not matter much as the game would be over after the collision, it did not look very good. After manipulating the algorithm to remove square roots and logarithms, we finally reached a point where the explosion looked good and did not affect the game speed drastically.
You'll be able to play our version of Spacewar! on February 8 at the Stata Center.
When we first started looking at the Spacewar! source code, one of the first things we tried to identify were the code segments that handled drawing the game state. Thanks to helpful comments in the source, we were quickly able to find the code that rendered the star field, which was covered in the previous post in this series. We also found a section of code that had the tantalizing comment "outlines of spaceship", followed by the two blocks of numbers that you can see in the image to the right. Working out what these numbers meant was the core challenge in understanding how Spacewar! draws its ships.
At first we thought the numbers might be a bitmap encoding of ship sprites, but drawing out what that might look like gave us nothing recognizable. From reading interviews that discussed the techniques that the Spacewar! programmers used we gleaned that the spaceships were actually drawn with vector graphics methods, so our second guess was that the numbers were encodings of vectors. Frustratingly, the simplest interpretation of taking consecutive pairs of numbers to be the x and y coordinates of a series of vectors that were being drawn one after the other again gave us nothing.
A big clue as to what was going on came from a section of the code that was commented as being the "outline compiler". Tracing through this code revealed that it was writing out machine instructions into an empty block of memory past the end of the main program, some of which were display instructions. Next we discovered a separate code section that seemed to be taking the heading of a ship, computing the sine and cosine of the heading, and storing linear combinations of the results in memory. That same memory was then referenced by the code that was being generated by the outline compiler. This was suspiciously like the kind of computation that would need to be done to multiply vectors by a rotation matrix. We'd found the code for rotating the graphics coordinate system!
We found the next piece of the puzzle by tracing the code in the outline compiler using an excel spreadsheet to keep track of variables as the program executes. It turned out that the memory that stored the outline encodings was being consumed in small chunks, and the number that those chunks encoded was being used to jump the program that many instructions ahead. This meant every octal digit in the outline's encoding was specifying a source code section to execute, and each of these code sections caused new instructions to be written into memory, which in turn would later be executed to display the ship on the screen. What these instructions did was update the drawing location, moving it in one of 5 directions relative to the last point drawn, save the current location, or restore the last saved one. By chaining these instructions together the program would trace out the outline of the ship.
With this discovery we had enough information to try reconstructing the outlines of the ships from the encodings by hand. Anxiously, we started sketching the outline of the first ship and were disappointed mid way through to find that it seemed like it mostly just a straight line and that there weren't enough instructions to possibly encode the whole outline of a ship. After reflecting for a moment though, we realized it makes sense that the needle ship would be mostly straight, so that was actually not a problem, but the final realization that made everything fit together was that only half of each ship's outline was being encoded; the programmers must have reflected them to draw the other halves.
Armed with our decoded spaceship outlines we are now reconstructing Spacewar!'s graphics in GAMBIT's Arduino port of the game. For avid Spacewar! fans, you too can reconstruct your own needle and wedge from the encodings in the picture using this decoding: 1 = down, 2 = right, 3 = down and right, 4 = left, 5 = down and left, 6 = save / restore, and 7 = finish!
Posted by Owen Macindoe on November 17, 2011 3:13 PM
|Permalink
November 3, 2011 12:06 PM
The Night Sky in Spacewar!
When we first started looking at the source code for Spacewar! we were struck by a strange section of code at the end, which was solely made up of repeated instructions along the lines of the code in the image on the right. A little bit of reflection and some background reading lead us to discover that this code was setting up a table of all the coordinates of the stars displayed in Spacewar!'s background. The code for doing this is a program in itself called Expensive Planetarium, written by Peter Samson, which displays a faithful recreation of the night sky as visible from MIT and was originally independent of Spacewar, but was later integrated into it. You can see the section of Expensive Planetarium that sets up the star field data on Wikipedia. Investigating this gives a bit of a taste of what unravelling Spacewar! is like.
Right up the top of the source listing is a comment that tells us Peter R. Samson wrote this for version 2b of Spacewar! The command 6077/ means the code from here down should be placed starting at that address in the PDP-1's memory. Next up is another comment telling us that Peter finished his code on March 13th in 1962 and a directive saying all the numbers from here on down should be interpreted as decimal, rather than the default of octal.
Now comes the definition of mark, which is a macro for converting the star coordinates into a format that makes them easier to process for displaying. Anywhere mark is called, the Macro preprocessor will replace the call inline with the code here, substituting in the arguments for the variables X and Y. Interestingly though, any arithmetic expressions or repeat statements are handled by the preprocessor, rather than being translated into code, so repeat 8, Y=Y+Y will multiply Y by 2^8, which is equivalent to bit-shifting it left by 8 bits, but will do this before run time. Wikipedia's listing actually has an error in the code; 8192-X and Y should be on two separate lines. These two lines are telling the preprocessor that 8192 (which is 2^13!) - X should be written at the current address in memory and Y should be written at the following address. In this way, the long list of mark commands that follows the macro's definition builds up a table of the positions of all the stars in the night sky visible from MIT.
Looking at this big list you might wonder why all the X coordinates are in the strange range of 0 to 8192 yet the Y coordinates can be both positive and negative. Also, why bit-shift the Y coordinates and subtract the X coordinates from 8192? It turns out that to answer that question you have to go beyond the code listing in Wiki and look at the Spacewar! source code itself. For keen PDP-1 hackers who are interested in looking at the source code, the macro in Spacewar! that does this is called dislis. Some reading, tracing code execution with pen and paper, and a bit of intuition revealed that Y is initially in the range -512 to 512 because the display of the PDP-1 had a resolution of 1024 by 1024 with its origin at center of the screen. The reason that it's bit-shifted by 8 before being stored in memory is because the display instruction for the PDP-1 looked in bits 0-9 of its accumulator and IO register for the X and Y coordinates respectively and words on the PDP-1 were 18 bits long, so the bit shift puts the Y value in the correct location for display.
The X coordinates are a bit more involved. Spacewar! keeps track of where the rightmost edge of the screen is in world space and moves it along in the game's main loop, which creates the effect of the star field drifting across the screen. dislis examines each X coordinate to see whether it would be in the viewable region of the sky represented in the screen, and then converts the X coordinate from world space to screen space, bit-shifting it in the process to prepare it for a display instruction. The subtraction and also the ordering of the stars by X coordinate performed when the table of stars is generated lets dislis detect when it has reached a star that is beyond the viewable region displayed on the screen and do an early abort of its scan through the table, saving a few cycles.
Lastly if you look back at the Wiki article you can see that the coordinates are separated out into blocks, which it turns out divide the stars into brightness categories. The PDP-1's display was monochrome, but the brightness of any given point could be controlled programatically, a feature which Spacewar! uses quite a lot.
Now that we've worked out how to interpret this star field data we're using it in the port of Spacewar! that we're working on here at GAMBIT. Our device's screen won't be the same size, but we now that we know how the coordinate system worked in the original it will be easy to convert it to make it work for our display. Our next big challenge is reverse engineering the display code for the spaceships in Spacewar! Our initial investigation has revealed that Spacewar! generates the display code programmatically at runtime, but exactly how is a mystery that we're having fun solving.
Posted by Owen Macindoe on November 3, 2011 12:06 PM
|Permalink
October 31, 2011 11:40 AM
"Robotany" Puts Artificial Intelligence in the Mind of the Beholder
When it comes to directing a video game's characters ("If x happens, do y"), there is only so much current artificial intelligence (A.I.) can do.
And while their skills are specialized and prized, A.I. programmers can devote years to a single game. They have to consider all the events that might occur and map out characters' possible reactions. In a first-person shooter, for example, the A.I.-controlled character needs to know how to collect ammunition, seek his target, get within range to fire, and then escape.
What if making certain kinds of A.I. didn't have to be that laborious? What would happen if an algorithm, extrapolating from a few decisions made by players, could figure things out for itself--and even reuse those lessons from one game to the next?
And what if all this could be done by someone with no A.I. training at all?
Those are questions that our game prototype "Robotany" wants to answer.
Set in a garden, the game features small robot-like creatures that sustain the lives of plants. The player manipulates graphs of the robots' three sensory inputs--three overlapping A.I.'s--and these manipulations teach the A.I.'s how to direct characters in new situations.
"The scheme behind Robotany requires that we ask the user to describe what the A.I. should do in just a few example situations, and our algorithm deduces the rest," said the game's product owner, Andrew Grant. "In essence, when faced with something the user hasn't described, the algorithm finds a similar situation that the user did specify, and goes with that."
The game was developed as part of GAMBIT's eight-week summer program, which brings together young artists, programmers, and project managers from U.S. and Singaporean institutes.
Robotany's team of eleven pushed game research in a unique direction by taking advantage of the human brain's ability to identify patterns.
"If we ask the user about a bunch of random example situations and draw conclusions from that," said Grant, "it turns out that you still need a really long list of example situations. With our approach, we can drastically reduce the number of examples we need to make an interesting A.I., well before you'd traditionally get anything good."
Added game director Jason Begy, "The player can effectively give the characters some instructions and then walk away indefinitely while the game runs."
Other A.I. developers have been enthusiastic about this new approach.
"Robotany represents a great new direction for game A.I.," said Damian Isla, who was the artificial intelligence lead at Bungie Studios, makers of the Halo franchise. "It's one in which the A.I.'s brains are grown organically (with help from the player), rather than painstakingly rebuilt from scratch each time by an expert programmer."
MIT Media Lab researcher and GAMBIT summer program alum Jeff Orkin suggested solving this kind of challenge would be "one of the holy grails of A.I. research." He said the video game industry spends an incredible amount of time and money micromanaging the decisions that characters make. "It would be a boon to the game industry, as long as the system still provided designers with an acceptable degree of control."
Rethinking the visual interface to the AI was a key component for addressing these technological questions. Begy described the need for more effective visual design as "absolutely necessary if the project is to succeed," because A.I.'s can handle countless variables while human players training the A.I. cannot. For similar projects, he would recommend having a skilled user interface staffer on hand and testing interfaces with players as much as possible. "In the final design, we went for many robots, each of which was only paying attention to two variables," said Begy. "This is reflected in the training system in Robotany, which is made up of simple two-dimensional graphs."
The Robotany team, honored as a finalist in the student competition at the upcoming Independent Games Festival, China, was also comprised of producer Shawn Conrad (MIT); artists Hannah Lawler (Rhode Island School of Design), Benjamin Khan (Nanyang Technological University), and Hing Chui (Rhode Island School of Design); quality assurance lead Michelle Teo (Ngee Ann Polytechnic); designer Patrick Rodriguez (MIT), programmers Biju Joseph Jacob (Nanyang Technological University) and Daniel Ho (National University Singapore), and audio designer Ashwin Ashley Menon (Republic Polytechnic).
Additional Information
Singapore-MIT GAMBIT Game Lab (gambit.mit.edu)
The Singapore-MIT GAMBIT Game Lab is a research collaboration between the Massachusetts Institute of Technology and the Interactive Digital Media R&D Programme Office hosted by the Media Development Authority of Singapore. The lab experiments with the theory, aesthetics, culture, craft, legacy, technology and play of games, developing, sharing, and deploying prototypes, findings and best practices to challenge and shape global game research and industry. GAMBIT builds collaborations between Singapore institutions of higher learning and MIT departments to identify and solve research problems using a multi-disciplinary approach that can be applied by Singapore's digital game industry.
Media Development Authority (www.mda.gov.sg)
The Media Development Authority of Singapore promotes the growth of globally competitive film, television, radio, publishing, music, games, animation and interactive digital media industries. It also regulates the media sector to safeguard the interests of consumers, and promotes a connected society.
Digital Archaeology: Investigating the Spacewar! Source
Here at GAMBIT we've been working on a project that aims to replicate the first computer game written at MIT, Spacewar! In the process we've been learning a lot about the way that games were written for the machines in the pioneering days of computing.
Spacewar! is game of space combat created for the DEC PDP-1 by hackers at MIT, including Steve "Slug" Russell, Martin "Shag" Graetz, Wayne Witaenem, Alan Kotok, Dan Edwards, Peter Samson and Graetz. You can play the game running on a Java emulator here. You can also run the game on the Multiple Emulator Super System (MESS) implementation of a PDP-1 by following the instructions here. The Spacewar! source code we've taken as the base version of the game is also available through that site. Our goal, however, is to make a version of the game that runs on an Arduino that we can demonstrate in the foyer of the lab.
As part of this project we're trying to understand what's going on in the PDP-1 source code that the emulators use. This has meant teaching ourselves the PDP-1 assembly language MACRO from old manuals written in 1962. It's been slow going, because a lot of information is either buried in the technical documentation or was just assumed knowledge that has been lost over time. It's also been very rewarding though and creates a feeling of connection to the minds of those hackers back in the 60s.
Looking around on Google it seems there's not that much information on the Spacewar! source code, and in trying to understand it we've come up with a few tips that might help someone else out:
Get the manuals for the PDP-1 and also for MACRO. They're available from the Bitsaver's archive and are very helpful. We have noticed that there seem to be errors in some of the example code in the MACRO manual, which were very confusing for me at first. The later examples, however, seem to be correct and are helpful in introducing some of the key concepts in the Spacewar! source.
Look at the compiled version of source code. There are two listings of the Spacewar! source code. The spacewar.mac file is handy for reading clean code, but the spacewar.lst file contains translations of every instruction into machine code, which is very useful for understanding exactly what's going on with the layout of everything in memory, which in turn is critical for understanding a lot of the low level memory manipulation that the code does.
MACRO inlines all macro definitions. The MACRO equivalent of functions are (somewhat confusingly) called macros. When you look through the .lst file you'll notice that wherever a macro was used in the .mac file MACRO has gone through and expanded it out inline by introducing temporary variables for each of the macro's arguments. This is what all the strange labels starting with "ZZ" are. Once you know this, reading the source code becomes a lot less confusing.
All numbers are in octal by default. This took us a long time to work out, although we should have realized it sooner. Unless the MACRO directive "decimal" has been issued in a macro definition the assembler interprets all numbers as octal. All the machine code and addresses that are in the .lst file are expressed in octal.
There is no stack. For programmers used to working at a C level of abstraction or higher, this was very confusing for us at first. As mentioned above, macros look like function when you write them, but when they are processed by the MACRO compiler they all get inlined. There is no stack pointer. There are no stack frames. Everything is just one big blob of data and instructions mushed together.
Labels are used both for naming variables and controlling flow. This was very hard for us to wrap our heads around at first. As mentioned before, there is no separation in memory between data and instructions. A coder would just have to make sure that they never let the program counter point to a place in memory that contains data rather than an instruction. The Spacewar! coders will commonly use a label to name an address in memory that they want to jump the flow control to and they'll also use a label to refer to a memory location that they are only going to store data in. As far as we can tell there is no naming convention which distinguishes them. Sometimes data can be stored immediately next to instructions in memory. Thankfully, however, the majority of the game object data is stored in a big contiguous block of memory after the instructions, rather than being completely interleaved.
Including the symbol "i" after an instruction makes it indirect. We never found an explicit statement of this, but I inferred it from looking at the opcodes in the .lst file. Indirect instructions take a memory address as an argument which tells them where to find the real argument. This idiom is very commonly used in Spacewar!
Space delimiters mean addition. So for instance "law 1 3 5" is equivalent to "law 9". Plus symbols also mean addition!
Parentheses define constants. MACRO automatically allocates some memory to hold the constant, stores its value there, and then replaces the constant symbols with the memory address of the constant. For instance when MACRO reads the instruction "lac (2000" in the preprocessing phase, it causes some memory to be allocated, say address 027703, and then stores 2000 in that address, replacing the original instruction with "lac 027703". This is all done prior to execution. We found this very confusing at first.
Get used to seeing a lot of "dap". The instruction "dap x" deposits the accumulator contents into the argument portion of the memory address x. This lets you change the argument of the instruction stored at that memory address. One of the most common idioms that the Spacewar! programmers use is to manipulate the flow of the program by writing "jmp .", which is a command that says "jump to this address" (which would result in a tight infinite loop if it were actually execute) and then to use the dap instruction to overwrite the target of the jump from "." to some other address that they load into the accumulator. This makes it hard to look at the code and immediately tell what the flow control is going to look like without tracing the execution, since you need to know what the "." is going to be replaced by when the program is actually running. They use a similar idiom for loading data, for example writing "lac ." which if executed straight up would load the contents of the current address (i.e. the "lac ." instruction itself) into the accumulator, but they then use dap to conditionally change the target from "." to some other location that contains data that they want to operate on.
Think in bits. Spacewar! is written very close to the machine. The programmers have used a frightening array of bitwise manipulation tricks that you don't often see in modern programming. They rotate bits in memory using bit-shifting so that they can store two short numbers in space normally used for one long number. They shift number representations around so that they're in the left or right side of a memory address depending on where a particular instruction call requires that it needs to be, which crops up quite frequently with the display instruction "dpy". They use clever number representations, such as 2's complement, to do fancy arithmetic tricks. They use MACRO to repeatedly double numbers in the preprocessing stage so that they get bit-shifted to the location in memory that they want before execution. They add together the bit codes of instructions to create combined instructions. These tricks are very rarely commented and working out exactly what this "clever" code is doing and why often requires a lot of poking around and reverse engineering.
Use MESS as a debugger to understand what's going on. The MESS PDP-1 emulator maps ctrl + most of your keyboard buttons to the switches on the PDP-1. You can turn on the "single step" and "single inst." switches and then hit ctrl-p, which will cause the PDP-1 to go into debugging mode and let your step through the code line by line by repeatedly pressing ctrl-p. By reading off the "memory address" lights and converting from binary to octal you can look up where the program is up to in the .lst file and follow the program as it's being executed.
Working on Spacewar! is fascinating. The programming style is unlike anything we've ever worked on before and has certainly made us think about low level programming in a whole new way. For anyone who is interested in computing history and low-level programming we strongly recommend checking it out.
Posted by Owen Macindoe on October 21, 2011 1:23 PM
|Permalink
October 17, 2011 12:23 PM
New MIT Game Research Explores Singapore Culture from the Inside Out
With student and faculty exchange programs, research alliances and the development of a brand new university, MIT has a long history of collaboration with the country of Singapore.
One such partnership, the Singapore-MIT GAMBIT Game Lab, considers how that strong relationship has created a unique need: how does someone reflect Singaporean culture to those on this side of the Pacific without resorting to rough, if well-intentioned, stereotypes?
A team in the GAMBIT Game Lab's demanding summer program takes on the challenge with its new title, "Stranded in Singapore", a point-and-click adventure game featuring a player "forced by circumstances to complete tasks for the eccentric Auntie MeeMaggi."
"We wanted to see how a game player's values can be mirrored in another culture," says Dr. Clara Fernández-Vara (SM '04), the game's product owner, who along with game director Richard Eberhardt oversaw the work of ten interns over the eight-week summer program. "Singaporean culture was pretty much ideal in that sense. It's distinctive and it offers the parameters needed to design a game in such a short time. It also facilitated the creation of a story: we could present Singapore almost as a character in itself."
In fact, much of the gameplay features Singapore's famously heterogeneous cuisine.
"Food in Singapore is very modular," says Eberhardt. Culinary components of Chinese, Malay, Indian, and other dishes find themselves mixed and matched in creative ways. Similarly, the quests in "Stranded in Singapore" are modular, obliging players to create new combinations of found objects to make their way through the game.
Such permutating puzzles are central to Fernández-Vara's research. The game is procedurally generated, which means it's dependent on algorithms to create and re-create the story. "You can play it multiple times, solving new puzzles with each play-through," describes Eberhardt, illustrating why such games are appealing for players.
Procedural generation can make a game uniquely hard to design. Where traditional adventure games are mapped out in detail, the puzzles in procedurally-generated games change every time you play, even during development. "Our designers and programmers would make a change to an object in the game, and that change would ripple out," remembers Fernández-Vara. "Adventure games are already challenging to make, but when they can be played in many different ways, dependencies get complicated."
When featuring Singaporean culture, those dependencies can get especially complicated.
"We're dealing with dialects, for example," says Fernández-Vara. "We're dealing with mixed vocabularies -- like 'Singlish'. How do you get a game to work well when the same word can have different meanings for different people, when an ambiguous phrase can change the game's whole direction?"
As an example, Fernández-Vara cites "can can".
"In the game, we have a can as an object. But in Singlish, can can is like saying no problem or can do. These language problems are tough."
"It's curious, though," adds Eberhardt, "our Singaporean students learned new Singlish phrases they never heard before -- from each other and from resources we used for the game, such as local guidebooks."
The game development team, which included several Singaporean tertiary students, found technical and design solutions for designers in the game industry. The researchers caution developers working with permutating content to allocate additional planning time. Misconceptions in the team can cause weeks of development delays for a procedurally-generated game. Fernández-Vara describes the dilemma, "everyone on a team envisions the game a little differently, but you can't have changing content if you don't already have content."
Eberhardt backs up that sentiment with a practical solution. "Working in the same room is really important," whether the team member is a programmer, artist, or audio designer. The team's producer, Nicholas Garza '11, echoes the need for open communication from a cultural standpoint. "Every summer we're suddenly grouped with nine strangers and asked to create something unique and amazing together. Working with familiar mentors lent me some solid footing, but when half your team represents the culture featured in your game, communication is especially important. They are not only your subject matter experts, they also reflect your potential audience."
Fernández-Vara describes her satisfaction from building upon her research from GAMBIT's 2010 award-winning adventure game "Symon". "'Stranded in Singapore' features more complex puzzles and locations. To do that, we had to create a set of tools to facilitate the design of procedurally-generated narrative puzzles." The long-term impact of this research will extend beyond point-and-click adventures. GAMBIT plans to to release a version of these tools for general use to programmers and designers of all sorts of games.
Additional Information
Singapore-MIT GAMBIT Game Lab (gambit.mit.edu)
The Singapore-MIT GAMBIT Game Lab is a research collaboration between the Massachusetts Institute of Technology and the Interactive Digital Media R&D Programme Office hosted by the Media Development Authority of Singapore. The lab experiments with the theory, aesthetics, culture, craft, legacy, technology and play of games, developing, sharing, and deploying prototypes, findings and best practices to challenge and shape global game research and industry. GAMBIT builds collaborations between Singapore institutions of higher learning and MIT departments to identify and solve research problems using a multi-disciplinary approach that can be applied by Singapore's digital game industry.
Media Development Authority (www.mda.gov.sg)
The Media Development Authority of Singapore promotes the growth of globally competitive film, television, radio, publishing, music, games, animation and interactive digital media industries. It also regulates the media sector to safeguard the interests of consumers, and promotes a connected society.
Contact
Andrew Whitacre
Communications Manager
Singapore-MIT GAMBIT Game Lab
Massachusetts Institute of Technology
(617) 324-0490
awhit@mit.edu
Learn about our recent research and game development activities at the GAMBIT Summer Summit GSS 2011 on July 6 at the Massachusetts Institute of Technology
While others are going on vacation the research and game development at the Singapore-MIT GAMBIT Game Lab ramps up. Right now students from Singapore and the US are working with our researchers and development team on novel game concepts, and visiting researchers are wracking their brains on different gaming related topics across a variety of fields. For the first time, we will draw back the curtains in the middle of the summer to provide insights into our current game development and research activities. We invite all interested and curious parties to join us for a day full of games and research.
On July 6 Scot Osterweil from the Education Arcade will open the stage with a keynote "Educational Games: Stop Being Serious". He will be followed by a panel discussion about the games that are currently under development at GAMBIT. There will be scientific talks on AI, educational and theory-based game design, visualization and animation tools, presented by game researchers from the MIT Media Lab, CSAIL, and GAMBIT's Singaporean collaborators. A further highlight is the GAMBIT alumni panel tracing the careers of our former students. To top off the GSS 2011 Jeff Orkin (MIT Media Lab / Cognitive Machines) completes the GAMBIT Summer Summit with his keynote talk "Next Generation A.I. & Gameplay: Big Data, Big Opportunities".
Venue: MIT Campus E51-325, Cambridge, MA (map) Date and Time: July 6 2011 from 9am - 6pm Registration: Free entry (wow); Please register ASAP via email: k_mitgut@mit.edu
09:00 GSS 2011 Opening (Philip Tan, Singapore-MIT GAMBIT Game Lab)
09:15 Keynote: Scot Osterweil (Education Arcade): "Educational Games: Stop Being Serious"
10:15 Singapore-MIT GAMBIT Game Lab Game Projects 2011 Panel:
· Mia Consalvo "The Social Social Game"
· Todd Harper "Gender and sexual identity game project"
· Clara Fernández-Vara "Aunt MeeMaggi's Cleaning School"
· Mark Sullivan "Softbody Physics"
· Matt Weise "Narrative Design"
· Andrew Haydn Grant "Human Trainer AI"
11:15 Break
11:30 Owen Macindoe, Singapore-MIT GAMBIT Game Lab: "Cooperative planning for AI in games"
12:00 Li Zhuoru, National University of Singapore: "Context-sensitive Markov Decision Processes"
12:30 Bai Haoyu, National University of Singapore: "Planning and Decision Making under Uncertainty in Complex Worlds"
13:00 Lunch
13:45 Fredo Durand, MIT / CSAIL: "Volumetric shadows, motion blur and depth of field."
14:15 Nguyen Thi Nhat Anh, Nanyang Technological University: "Interactive multi-view image segmentation"
14:45 Shu Ke, Singapore Management University: "K-Sketch: A simple animation tool using in game design"
15:15 Konstantin Mitgutsch, Singapore-MIT GAMBIT Game Lab: "Afterland Revisited. A theory-based game development research circle"
15:45 Break
16:00 Jason Haas, Education Arcade / MIT Scheller Teacher Education Program :"The More We Know: Inside NBC News' iCue, and Why It Didn't Work"
16:30 Singapore-MIT GAMBIT Game Lab Alumni panel
· Mark Sullivan (Singapore-MIT GAMBIT Game Lab)
· Sharat Bhat (Fire Hose)
· Genevieve Conley (ImaginEngine)
· TBA
17:15 Closing Keynote: Jeff Orkin (MIT Media Lab / Cognitive Machines) "Next Generation A.I. & Gameplay: Big Data, Big Opportunities"
As an aficionado of both dice and semiotics, I was very excited to find Rory's Story Cubes in my FLGS (Friendly Local Game Store) a few weeks ago. This set consists of nine six-sided dice featuring 54 different icons; every side of every die is unique.
Rory's Story Cubes is presented as a storytelling game, and offers a few short ways of using them as such, all of which revolve around rolling the dice, creating a sequence of images, and constructing a story based on that sequence.
When used as a game to tell stories, they are a perfect example of how the syntagmatic dimension functions. In semiotics, this dimension refers to how the relationships between signs affects their meaning. In language this manifests as syntax. Here, the sequence of images as displayed on the cubes is syntagmatic in that the meaning of a given cube in shaping the story is necessarily formed by the adjacent cubes. Placing the bee before the keyhole would be very different than before the open hand. In the first example, the bee would likely be interpreted as passing through the keyhole, where the second example implies that the bee was swatted.
Another example of how the syntagmatic dimension shapes meaning is the Kuleshov Effect, a phenomenon related to montage. Named after Russian filmmaker Lev Kuleshov, the Kuleshov Effect describes how an audience brings their own emotions and backgrounds into play when interpreting a sequence of images. Similarly, the meaning of the cubes is also shaped by the players. It makes just as much sense to interpret the bee-hand combination as meaning that the bee landed on the hand, or stung the hand, and so on.
On a different note, Rory's Story Cubes are also an interesting example of several concepts introduced by Espen Aarseth in Cybertext:
"It is useful to distinguish between strings as they appear to readers and strings as they exist in the text, since these may not always be the same. For want of better terms, I call the former scriptons and the latter textons. [...] In addition to textons and scriptons, a text consists of what I call a traversal function - the mechanism by which scriptons are revealed or generated from textons and presented to the user of the text" (62).
In Rory's Story Cubes, the "textons" include all 54 images, while the "scriptons" are whichever images are currently, for lack of a better term, "active" - that is, being made use of by the user. The traversal function is built into their physical nature as dice: the act of rolling them generates the scriptons.
Of course, Aarseth developed these concepts as a means of analyzing textual artifacts, whose primary function is "to relay verbal information" (ibid.). He further notes that scriptons "are what an 'ideal reader' reads by strictly following the linear structure of the textual output" (ibid.). The scriptons in Rory's Story Cubes, however, are not meant to be "read" in the manner Aarseth describes, but rather are used as tools and prompts for constructing a narrative. This is a key distinction between the Cubes and purely textual machines, and alternative terms to "textons" and "scriptons" are called for, to account for artifacts such as these.
While Rory's Story Cubes are certainly effective illustrations of all of these principles, what I personally find compelling about them is not the meanings that can come out of rolling them, but rather that the near-infinite sum of meanings they might release and enable has been so elegantly constrained by their form. It is the many potential meanings highly compressed in the textons that charm, not the meanings brought out by the scriptons.
The editors at Adventure Classic Gaming invited me to write an article about research in adventure games. This was my opportunity to explain adventure game fans what I do and, more importantly, why they should care too. What I explain in the article, although focused on adventure games, is my understanding of what games research may be (we games researchers are still figuring that out).
An excerpt from he article:
The academic study of videogames has become an interdisciplinary research field. Game studies scholars come from a variety of disciplines, such as education, sociology, game studies, and computer science. The objects of their studies are just as diverse: specific genres (e.g., casual games (1) or role-playing games (2,3)), players, formal aspects of game design, to name but a few. Adventure games are also part of this rich research landscape, and their status in the field of game studies remains to be defined. This article is an introduction to the study of adventure games and how research can inform not only scholars but also game developers and fans of the genre. [...]
There is much that can be learned from adventure games and their long history (by videogame standards). Developed between 1975 and 1976, Adventure (Figure 1), also known as Colossal Cave, is commonly cited as the first adventure game (6). Decades later, adventure games are still released both commercially by development studios and non-commercially by dedicated enthusiasts. Computer technologies have evolved, and adventure games along with them, going from text to mouse input to touch screens. The evolution of the genre has not been linear, but rather has branched into different subtypes of adventure games. This has led to new interactive fiction (also known as text adventure games) being released along new point-and-click adventure games, both by commercial developers and by aficionados of the genre.
Rather than giving them an exercise in which they have to reproduce a specific type of code or a variation, the assignment can pose an open problem: a game for an outdated platform, a new type of dialogue system or a character model with only 150 polygons. Although real-life constraints, such as limiting the file size, may be more resonant with professional practice, inventive limitations encourage students to generate creative problem-solving skills and revise their development methods. Team assignments, particularly if the course has students from different departments (e.g. visual arts and computer science), introduce students to solving problems with people from other disciplines -- another essential soft skill in game development.
Read the article to learn about some of the thinking behind the game studies curriculum at MIT!
The editors at Adventure Classic Gaming invited me to write an article about research in adventure games. This was my opportunity to explain adventure game fans what I do and, more importantly, why they should care too. What I explain in the article, although focused on adventure games, is my understanding of what games research may be (we games researchers are still figuring that out).
An excerpt from he article:
The academic study of videogames has become an interdisciplinary research field. Game studies scholars come from a variety of disciplines, such as education, sociology, game studies, and computer science. The objects of their studies are just as diverse: specific genres (e.g., casual games (1) or role-playing games (2,3)), players, formal aspects of game design, to name but a few. Adventure games are also part of this rich research landscape, and their status in the field of game studies remains to be defined. This article is an introduction to the study of adventure games and how research can inform not only scholars but also game developers and fans of the genre. [...]
There is much that can be learned from adventure games and their long history (by videogame standards). Developed between 1975 and 1976, Adventure (Figure 1), also known as Colossal Cave, is commonly cited as the first adventure game (6). Decades later, adventure games are still released both commercially by development studios and non-commercially by dedicated enthusiasts. Computer technologies have evolved, and adventure games along with them, going from text to mouse input to touch screens. The evolution of the genre has not been linear, but rather has branched into different subtypes of adventure games. This has led to new interactive fiction (also known as text adventure games) being released along new point-and-click adventure games, both by commercial developers and by aficionados of the genre.
The editors at Adventure Classic Gaming invited me to write an article about research in adventure games. This was my opportunity to explain adventure game fans what I do and, more importantly, why they should care too. What I explain in the article, although focused on adventure games, is my understanding of what games research may be (we games researchers are still figuring that out). My own work with Rosemary is one the examples of hands-on research on adventure games.
An excerpt from he article:
The academic study of videogames has become an interdisciplinary research field. Game studies scholars come from a variety of disciplines, such as education, sociology, game studies, and computer science. The objects of their studies are just as diverse: specific genres (e.g., casual games or role-playing games), players, formal aspects of game design, to name but a few. Adventure games are also part of this rich research landscape, and their status in the field of game studies remains to be defined. This article is an introduction to the study of adventure games and how research can inform not only scholars but also game developers and fans of the genre. [...]
There is much that can be learned from adventure games and their long history (by videogame standards). Developed between 1975 and 1976, Adventure, also known as Colossal Cave, is commonly cited as the first adventure game. Decades later, adventure games are still released both commercially by development studios and non-commercially by dedicated enthusiasts. Computer technologies have evolved, and adventure games along with them, going from text to mouse input to touch screens. The evolution of the genre has not been linear, but rather has branched into different subtypes of adventure games. This has led to new interactive fiction (also known as text adventure games) being released along new point-and-click adventure games, both by commercial developers and by aficionados of the genre.
Throughout the spring semester of 2010, GAMBIT's Lead Interaction Designer, Marleigh Norton challenged a group of three MIT UROPs (Nick Ristuccia, Anna Kotova and Michael Lin) with the task of each creating three game prototypes. The game prototypes were to reflect a certain area of cancer research with the final goal of a one of the games be developed for use at the new Koch Institute for Integrative Cancer Research at MIT which is scheduled to be opened in December of 2010. Produced by Generoso Fierro, Edited by Garrett Beazley.
In this episode, Anna Kotova demos the three games she created for the project:
(This post originally appeared on Jason Begy's blog, Game Bitiotics.)
Video games have no magic circle, but board games do.
The difference between these two media is, essentially, one of reaction and proaction. If I may be allowed to indulge in a McLuhan-esque theory for a moment, video games are a reactive medium. As a player, I am continually reacting to the game state as-defined by the computer. The computer communicates the current state to me (the means by which it does so varies considerably from game to game). I then process this information, make a decision, and the feedback loop continues. This is of course the same regardless of the nature or genre of the game: in this sense Farmville, Grand Theft Auto and Quake are all the same thing. In multiplayer games the situation is only slightly different: a varying number of people are affecting the state, but the state is still processed, maintained and communicated by the computer.
Board games, however, are a proactive medium. In these games the state is essentially a mental construct shared amongst the players. Each will have (approximately) the same idea of what the state currently is, and when the state is altered each must update his or her own construct accordingly. The actual bits, cards and so on can be thought of as reminders that communicate the state, used so that we do not have to keep everything in memory. These games are fundamentally proactive: as a player, it is up to me to process and update the game state, in addition to choosing how I will alter it when my chance comes. Without the player's shared understanding of the rules and the state the game breaks down. As such, everyone must actively maintain the information in the system that both defines the state and the rules.
With this in mind, I want to address Huizinga's famed "magic circle." Recent scholarship agrees (seemingly unilaterally) that the magic circle is porous at best. While Huizinga implies that a game is somehow set apart from reality, in practice this is never the case. Anyone who has ever intentionally lost a game, bragged (or annoyed by bragging) about winning, or bet on an outcome knows this firsthand. In short, our real lives permeate the games we play, and they cannot be cleanly separated.
As such, it seems that as a theory the magic circle as-described is incomplete, or even incorrect. However, I propose that we should view the magic circle as the information feedback loop maintained by the players of a board game. The magic circle implies that something special and distinct from ordinary reality is occurring during a game. When we play a board game this is exactly what happens: the objects we play with are imbued with a special significance. Paper money is "worth" something, flat discs can "jump" over each other, placing a token in a certain place earns "points." The meaning and information we attach to these objects belongs to the other half of the information feedback loop, a loop drawn between the players-as-players and players-as-processors. This loop is the magic circle, a circle that transforms random cubes of wood into bits of information that we are then somehow able to act upon in a meaningful way. When the game is over the paper money still has value, but it is of a different type.
Six victory points.
With video games the feedback loop is fundamentally different. We do not need to attach any special meaning to Mario, the computer provides it for us. We see and interact with the objects in a video game without any special manipulation of our own cognitive processes. There is no magic circle here, only reaction to a state that is just partially under our control.
I want to conclude by noting that this is not an attempt at a value judgment that privileges one medium over another, despite whatever connotations "proactive" and "reactive" might have in today's business-jargon-infused world. Rather, I believe that board games and video games have some fundamental differences, and this short piece represents a first stab at delineating them.
In this, the last prototyping session of the semester, the team continued work on the castle-building game that we had begun the week before. By the end of the previous meeting, we had made a good start and we had a fun game. This week was mainly refining, adding new features to make the game more interesting and polishing existing features.
The week before, we had necessarily focused mainly on playability and designing a prototype that would actually be a decent representation of the kind of gameplay we wanted, and we glossed over many of the finer details about the workings of medieval castles. While we incorporated concepts that we had come across in our research, like machicolation, we didn't put too much emphasis on making sure that the way we implemented them was completely historically accurate. So, one of our first tasks this week was to go back to our sources and try to adjust or add to the different elements we had included so that they better reflected the reality of medieval castle building. For example, we had previously made a rule that adding machicolation to the top of a tower extended the range of the archers on top of that tower. However, that was not actually an accurate representation of the effects of machicolation--what it actually does is allow archers to fire nearly straight down on attackers at the base of a tower without exposing themselves to enemy fire, an ability that normal crenellated towers did not afford. We had also fudged a bit in our calculations of damage that attackers could do to the castle--for example, we had included mechanics that permitted attackers to shoot down defenders who were inside towers, but in reality, this would have been impossible, since most towers were equipped with arrow slots that allowed defenders to fire out but stopped outsiders from firing in. This week, we went back to the books to cement our understanding of many of these elements and changed their implementation in the game so that they better reflected reality.
In addition to fixing these inaccuracies, we added or updated a number of elements that players could choose to build. For example, while machicolation was an extremely effective method of wall and tower defense, but sometimes resource availability, time, or knowledge might have prevented its construction. The latest versions of our prototype included other options for tower augmentation, like hoardings, which are a sort of wooden version of machicolation, or crenellations, which are simpler to build but provide slightly less flexibility and protection for defenders.
We also experimented with varying the resources available to the player. In the previous iteration of the prototype, the player had three in-game months to build up their fortress in each building phase, but this was the only limiting factor on what they could build. This week, players were required to keep track of how much lumber and stone they had available, as well. Adding this dimension to the game seemed to give the players more interesting decisions to make during the building phase and was overall successful. We also tried adding water as a resource for the creation of moats, but this didn't actually add anything to the game because no playtesters ever came close to running out of water when they started the round with a reasonable amount. We also tried having food as a resource, so that the player would have to build a fortress capable of repelling attackers before food stores ran out, but this added a dimension to the game that we didn't like--we felt that having to worry about food stores took the focus off the actual castle building.
Sadly, since this was our last week of prototyping, there are a lot of potential improvements and expansions that we didn't have a chance to add. Real-life castles were incredibly complex and although our prototype ended up fairly complicated (at least for a paper prototype), it only explored a tiny number of all the possibilities open to us. There are still a number of ideas we wanted to add but never got around to, like bartisans, turrets that projected from walls and allowed an occupant to rain death down upon enemies from all angles while remaining completely protected, or sally ports, heavily protected doors, just large enough for a mounted knight, that allowed defenders to send out sallies to destroy enemy siege weapons. Additions like sally ports would also give the player the opportunity to do something more in the attack phase. Instead of just passively waiting on the outcome of dice rolls, they would have the chance to decide whether to send out a force to attack a trebuchet and how many men to send. This could also add another angle to resource management, either in the form of a new "knight" resource or by requiring the player to decide how many defenders to take off the tower and hold in reserve at the sally ports.
Another idea we never really got to try involves incorporating the differences in castles in different regions and times. The first medieval fortifications in England and northwestern Europe were relatively simple wooden affairs, usually just a large keep on top of hill surrounded by a fence. As time passed, more innovations and improvements were made to the building process, until eventually castles became massive, near-impenetrable fortresses. For example, when people started making towers from stone, it became possible to build round towers instead of square towers, which were advantageous because they didn't have "dead angles" that couldn't be covered by defender fire and allowed enemy forces to attack the walls. It would have been fun to experiment with setting different rounds of the game in different periods and giving players different levels of technology to how it affected their playing and enjoyment of the game.
And, as always, there are still some issues and problems that we have to work out. The attacking army movement and rules for combat and damage still need some tweaking: obstacles, for example, do far more damage than they probably ought to; the trebuchet is probably more random than it ought to be. Towers also give us a little trouble: should players be able to repair recycle rubble from demolished towers in later rounds? What about the scenario where a player puts hoardings on top of a tower, but then later decides they want to build the tower taller? These are issues it would be interesting to address through further playtesting and revision.
Still, we ended our semester with a game that, while far from perfect, is a lot of fun. Players seemed to enjoy not just the opportunity to juggle resources and play with different castle set-ups, they also got found themselves on the edge of their seats during the attack phases, waiting to see if their constructions would hold. Even the GMs who rolled the dice and calculated the damage done each turn became surprisingly invested in the attack phases and the fates of the two sides, given that they had no decisions to make and no input into how the round played out. One amusing development was the way that the attack phase often seemed to play out as a story, players and GMs exclaiming or groaning as parts of attacking armies accidentally impaled themselves on obstacles or when the trebuchet destroyed a tower. The last playtest worked particularly well in this regard, ending in a nail-biter in which a huge invading army was reduced to its last handful of fighters facing off against a single remaining tower of defenders. It looked like a certain victory for the defenders, protected behind their stone walls, but a lucky hit from the trebuchet at the last possible second brought down the tower and the defenders inside. The attackers "won", since they had destroyed the defending army, but in the end there was only one attacker left. Even a couple weeks after that playtest and the end of our work on the castle-building prototype, we still laugh at the image of that single, solitary viking sitting alone in the keep, maybe hanging out with the cows or other farm animals that were the sole survivors in the castle.
Posted by Alexis Brownell on May 12, 2010 3:54 PM
|Permalink
May 11, 2010 9:00 AM
Spring Prototyping #8
For our next prototyping challenge, Drew and Matt asked us to create a prototype based on an idea, a general list of goals and constraints, and a dramatic "minute of gameplay" that describes, in narrative form, how the gameplay should feel. An excerpt follows --
"I survey the floorplan. There are only 5 people left to rescue. I think I can get one more out the window. I click the old man in the rocking chair and take control. He hobbles to his feet and down the hall... the fire is getting closer, so I push into the old drunk in front of me. Things are tight, but the drunk gets on the ladder just in time... the next person won't be able to make it out this way."
This game, temporarily dubbed "Fire Escape," is obviously intended to be a digital experience. The gist of the gameplay is that the player must evacuate five characters out of a burning building. The player takes control of them one at a time.
However, when he evacuates one person and goes back to get another, he actually takes control of the second character at the same time (in the game's narrative timeline) as the first. The actions of the first character he controlled are now programmed into the game, and the first character will go through these actions automatically, alongside the second character (which is currently being controlled by the player).
The ultimate result would be a synchronous evacuation attempt where all five characters are simultaneously going through the motions that had been individually determined by the player's actions. The challenge comes from issues with characters blocking one another or otherwise preventing each other from escaping.
For example, if the first character bolts right for the elevator, that elevator will not be available to the second character if the second character doesn't arrive at the elevator before (or at the same time as) the first. If the first character is slow and is navigating a narrow hallway, a second, faster character who comes up behind them will be trapped behind.
Orchestrating this mass evacuation is a matter of careful planning and coordination. The player also effectively gains foreknowledge of things that will happen in the building - falling walls, collapsing floors, spreading fires - because after taking control of the first character, the player essentially experiences the entirety of the game's timeline - he just goes on to experience it four further times.
We thought carefully about how best to translate this important and innovative mechanic into a paper prototype. Drew had suggested having the trajectory of a character's egress be represented by a drawn line, with multiple paths being drawn simultaneously to determine if they collided. We decided against this for a couple of reasons - firstly, regulating the path and the speed of drawing would be difficult, and secondly, with five characters, there would be too much drawing for one player. We wanted to make the game potentially playable by a single person, so we eventually decided on a very clear-cut mathematical solution:
Spaces were represented by squares. With each step a player took, he or she would mark that square with a number corresponding to the number of turns. For example, the first step would be "1," the next "2," and so on until they escaped through the door on the bottom floor or the window on the top floor. These numbers would then stay on the board as the player navigated the same terrain with other characters. A character could not occupy the same square as another if their numbers were the same, because that signified that they were in the same place at the same time.
Also, falling rubble and spreading fires were designated with numbers as well. For example, a GM would watch the player's progress, and when he had taken his 8th step (when he wrote the number 8 on a square) the GM would declare, "rubble falls on the 8th turn in these squares--" and then mark those squares with an 8, showing that from the 8th turn onwards, that square is blocked by rubble. Fire behaved similarly in that it spread from a single square every few turns. The turn numbers for fire are roman numerals, to distinguish them from other numbers.
Our playtests revealed that this was a quite intuitive way of showing when and where certain events occurred. Players could easily see which options were or were not viable and plan in advance. Even so, the game was still challenging enough to play multiple times. Subtle changes to the layout, or the distribution of rubble and fire, created an entirely new experience.
The end result was not as atmospheric as the game described in the gameplay transcript, but it did accurately translate the core mechanic in an intelligible way.
We were next tasked with a much more straightforward concept - abstract the game of "tag" into a realtime multiplayer game. This proposal, though simple, was actually quite tricky. After all, tag already IS a realtime multiplayer game. How, then, could we condense the typical tag arena -- a yard or playground -- into a game board, keeping the feelings of frantic terror and exhilaration that make tag fun?
We were also required to incorporate an "infection" element into the gameplay, but this didn't concern us as much as the aforementioned issues.
First we began brainstorming mechanics that could be used for the game. Our usual arsenal of dice, poker chips, building blocks, and grids turned out to be ineffectual. We seemed to fall too easily into the rut of making a turn-based, grid-based game. Such a game wouldn't have the appeal of tag.
Tag should be a game that players can leap into impetuously and finish just as quickly. As a team, we were fairly comfortable designing intricately balanced rule systems for our games, but making an elegant one-note design was more challenging.
After we spent a while getting nowhere, we finally decided to just try going for it. We grabbed markers, pens, and a big sheet of paper with the premise that we would all draw continuous lines -- no lifting the drawing implement -- and simply play "tag" on a field of paper. "Tagging" meant catching up to the front of someone's line -- tagging their implement with yours. Even though the game went by very quickly, we immediately perceived that we'd captured the crazy fun of tag on a small scale. Plus, we were left with an interesting record of how the game had progressed.
The one issue was that we were constantly elbowing each other while playing. Looking around for a larger surface, we went immediately to GAMBIT's big frosted-glass dry erase walls. It didn't take us long to realize that we could improve even further on the game by having the antagonist / "it" stand on one side of the glass, while the rest of the players stood on the other.
The lines that "it" drew were clearly visible from the other side, and even became more ominous and terrifying for their disembodiment. When tagged, a player would go join the antagonist on the other side of the wall, creating an effective feeling of isolation for the remaining players while also conveying the concept of "infection."
Our playtests were quite successful, but the game was still over very quickly. We decided to handicap everyone by making them use dry-erase markers with two more markers capped onto the end.
The players must hold the base marker but draw with the topmost one. If he or she drew too quickly, the markers would break off and they'd have to reassemble them. "It" could still tag them by racing to where their line had abruptly "cut off" and scrawling over the end.
We also upped the ante by using post-it notes as obstacles. This again served to extend game time a bit, but in general the game was still over within a few minutes. We decided that this was acceptable, and that the feel of tag had been accurately captured.
Posted by Sophia Foster-Dimino on May 11, 2010 9:00 AM
|Permalink
May 10, 2010 12:40 PM
Spring Prototyping, #7
This session saw us continuing to refine our prototype from the previous weeks, which involved five monsters that each embodied one of the five senses. Our existing prototype had some interesting ideas, but there were still a number of problems with it that we needed to work out. In trying to address these issues, we ended up in a very different place from where we began.
The Starting Point
As readers of the previous posts may remember, the basic concept of the existing prototype was that the player navigated across the game board while avoiding detection by the five monsters that also inhabited that space. The protagonist was a shape-shifter, and had a long list of attributes that they could choose to take on. Each attribute could be perceived by one of the five senses, so the player could choose, say, a taste-related characteristic like "salty" or "savory," or a touch-related characteristic like "rough" or "cold", and so on. The five monsters also reflected the five-senses theme of the game, and each of them had only one sense with which to experience the world.
The game board was overlaid with a grid that was divided into large sections, and each section had a set of characteristics or attributes associated with it. Any objects in a section were supposed to have those associated attributes, and if the player did not have the correct attribute for a given area--for example, if the player had the "bitter" taste attribute in an area designated as "sweet"--they would be detected if a nearby monster had the appropriate sense. A player could only take on three characteristics at any time, and so had to judge which would be the best to choose. In addition, the player had to think of an object which had the three chosen characteristics in order to be allowed to use those characteristics.
In playtests, people found the idea of the five sense-monsters intriguing, and often had a lot of fun trying to think of objects that had a certain set of traits, but the gameplay itself was just too simple. There was very little strategy required, and it was usually very easy to avoid detection. In the event that a player did mess up and was discovered by the monsters, the effects of being detected seemed unimportant or inconsequential.
Fixing the Problems: A First Attempt
Our first try this week at fixing some of these problems involved a complete overhaul of the gameboard layout. Previously, players had found that the layout didn't give them interesting choices about which paths to take, and that it was too easy to tell which monsters would be coming in range and which traits would be required in upcoming turns. In the previous session, we had tried to deal with these problems by adding walls and obstacles to make the player's path more convoluted, but--possibly because of the small size of the board that we were using--we never succeeded in creating a layout that players found interesting or challenging.
So, in this session, we got rid of the walls, and instead of requiring the player to move from one side of the board to the other, we set up the board so that the player had to visit each of the four corners to activate four "switches" and then return to the center. We also changed the monsters' movement patterns to make them a little less predictable and a little more likely to run into the player or each other. Finally, we added the notion of health/HP to the game, so that the player would lose 1 HP each time they were discovered by a monster.
These changes were somewhat successful: the open layout of the board and, in particular, the increased unpredictability of monster movement made the player more likely to end up taking a path they had not originally planned on. Also, since it was harder for the player to predict which monster(s) they would encounter in the next turns, deciding which traits to adopt on each turn was no longer so straightforward. Unfortunately, the changes also had an unforeseen, game-breaking consequence: by the time the player had hit all the switches, the game had reached a state where the player was completely surrounded by monsters at the end of every turn, and thus unable to take on enough different traits to fool them all (because the player was still limited to three traits). Indeed, this was the first playtest where the player was unable to win.
A Dramatic Change
By this point, we were starting to suspect that the issues caused by the overly-simple layout and the system of choosing traits were inherent in the current set up of the prototype, and were unlikely to be resolved as long as we stuck with the idea of a player and monsters running around an abstract space divided up into arbitrary sections with associated attributes.
Thus, the next iteration of the prototype was a huge departure from previous versions. We replaced our large grid with a mysterious house that the player had to explore; we got rid of the extensive list of attributes for the players to choose from; and the monsters no longer wandered around freely. We also added a bit of backstory to the game, with the hopes of creating a more motivating scenario for the player.
The new version played out as follows: at the beginning of the game, the player was told that a friend was deathly ill, and the only hope of a cure lay in a set of six magical artifacts that could be found in a strange house inhabited by bizarre creatures (the five sense monsters). On every turn, the player drew a card from each of five piles of cards--each pile corresponded to one of the senses, and each card had a trait written on it. These five traits would be the only ones that the player could use on that turn.
After drawing the cards, the player then chose which of six rooms to enter (the house contained a bedroom, a kitchen, a workshop, a menagerie, a greenhouse, and a library) and rolled a die to see if they were successful in making it into that room, instead of moving from space to space as in the previous version. Then, a series of die rolls was used to randomly determine which of the monsters would also enter the room, and the player would have to choose which three traits they wanted to take on. As in previous iterations, the player also had to think of an object that had those traits. If the player was successful in convincing the "monsters" (that is, the GM) that the object they had transformed into belonged in the current room (a frying pan, for example, would make sense in the kitchen, but not in the library), then they successfully obtained the magical artifact hidden in that room. If they were unsuccessful in thinking of an object that belonged in the current room, the monsters discovered them and the player lost HP. The player lost the game if all their health was depleted, and won if they managed to acquire all six magical items.
There were a few glitches in our first playtest--for example, it was unclear how the dice rolls determined which room the player ended up in, and some of the aesthetic elements were a little confusing (like our forgetting to include doors leading into the various rooms of the house, which didn't help the player's confusion about movement). Minor hiccups aside, though, it appeared that the dramatic changes we had made had had the desired effects, as the player seemed to enjoy the challenge and we didn't get any comments about the game being too simple.
The addition of drawing attributes from decks was also a success: not only did it avoid overwhelming the player with a huge list of possibilities (something that multiple players of previous versions had commented on), our playtester liked that it gave him the chance to think of possible objects ahead of time and then make a strategic choice about which room to enter.
This new version was not perfect, of course. One big problem our playtester had was that he was unable to tell what determined whether an object he came up with would be accepted by the GM. He couldn't figure out what, if any, criteria were being used to judge the ideas, and he felt like anything he came up with would be accepted, which eliminated all tension. There was also still one nagging problem from previous versions that we hadn't fixed, namely, the consequences of being discovered. Losing 1 HP was not interesting to the player, particularly in the scenario we had concocted, where (the playtester felt) there were opportunities for more compelling, narrative-based consequences.
An Unexpected Suggestion
Based on the feedback from the first playtest, we made a number of tweaks to our new version of the game. First, we fixed some of the obvious glitches, like putting in doors (we learned a good lesson about how even seemingly inconsequential design decisions can have significant effects on players and player expectations). We also made the player's movement simpler--now they could just choose which room to go to next, instead of having to roll to determine if they made it to their intended destination. However, we did add another hurdle for the player by concealing the names of the rooms at the beginning of the game, so that the player would not know the identity of a room until the first time they entered it. We also tried to simplify the framing fiction of the game.
We also added to the consequences of being discovered, since the first playtester had felt that just losing 1 HP wasn't enough. This time, when the monsters found the player, the player would be tossed from the house and one of the magical artifacts that they had acquired would be taken from them and randomly placed in one of the rooms of the house, requiring the player to do more exploring to find the artifact again.
Finally, we tried to work out a more concrete system for deciding whether to accept or reject a player's choice of object, but this was difficult--indeed, the problem of how to create an objective set of rules to govern this part of the game was something that had worried us from the very beginning. While it was fine to have a human being doing the judging during the paper prototyping phase, we couldn't see how we would adapt that for a digital version of the game.
In an unexpected development, our final playtester came to our rescue by pointing out that the prototype we had would probably work best as a multiplayer or party game. The players themselves could take on the role of the GM or judge, and decide among themselves whether a certain object should be accepted as appropriate for a certain room or not. In addition, competing against other players to be the first to collect six artifacts would add tension and make the game a lot more interesting than just trying to find those artifacts before you lost all your health.
This idea had never crossed our minds during development, but our tester was definitely onto something. It might mean abandoning our original idea of this prototype as a precursor to a digital game, but it would resolve so many of our issues--it would even allow us to get rid of the problematic health mechanic, since the win/loss state would just be whether it was you or one of your opponents who collected the six items first. By the time we finished that last playtest, it was time to go and we didn't have time to work on the multiplayer aspect that day, but it was definitely an intriguing concept and opened up a lot of new avenues for us to explore.
Final Reflections
We made good progress during this session, and although we were by no means finished with the prototype by the end of the day, we had a fun, playable game and a good idea of possible future paths.
In addition, this week's prototyping also brought home a lesson that was probably good for us to learn: sometimes when there's an aspect of a game that's really giving you trouble, the best thing to do may be quite drastic--you may have to just get rid of it. We were attached to the idea of having the player move their token from square to square across the play space, but keeping that mechanic meant that we were unable to get around the problem of overly simple navigation that it caused. However, it turned out that the ability to choose the character's exact path through the space was not as important as we had believed, and getting rid of that aspect improved the game dramatically. Removing the grid system also freed us from the system of associating a specific set of attributes with each section of the board, a system that all our playtesters found too obvious. It took us two weeks and a certain amount of desperation to reach the point where we were mentally able to scrap these broken mechanics, but it ended up being worthwhile.
Posted by Alexis Brownell on May 10, 2010 12:40 PM
|Permalink
April 22, 2010 1:37 AM
Spring Prototyping #6
In our final meeting for the month of March, the prototyping team continued to examine the concept of a game with enemies representing the five senses. Our prototype from the previous week had involved only one enemy and one sense (sight) and was a puzzle that required the player to alter his silhouette with various strange items to disguise himself. This week, we tried adding more enemies (and thus more senses) to the game.
We decided that we wanted to continue with the idea of having an inventory or tool set that the player could use to disguise themselves. This time, though, instead of providing physical items that the player could pick up, we made the protagonist into a shape-shifter, and their inventory was the different characteristics or attributes that they could take on--there were five possible characteristics for each sense, like "triangular" or "square" for sight, "rattly" and "shrill" for hearing, "sticky" or "rough" for touch, and so on. The main idea of the game was that the player has to move across the board while avoiding the five enemies or shape-shifting to disguise themselves from one or more enemies as they moved into range.
Our first iteration divided the game board up into a 4 x 3 grid in which each section of the grid had a set of five characteristics associated with it, one characteristic for each of the five senses. For example, a section might be designated to be "bitter, round, cold, squeaky, and sweet-smelling." Five enemies--each of which had only one sense available to them--moved in set paths about the board, and the player had to try to get from one side of the board to the other without being detected. The player and the enemies moved in turns, and at the end of the player's turn he had to choose three attributes from a list (each attribute had to be from a different sense), and think of an object to shift into that had all the desired attributes (if they were unable to think of an object with the desired attributes, they would have to choose a different set of attributes). For example, if the player's turn ended in the section of the board described above, they might choose to take on the traits "round", "cold", and "sweet-smelling", and declare that they were transforming into key lime pie.
If an enemy ran into the player, the enemy would check to see if the player's current shape matched the section of the board they were in. If the player's shape matched the monster's expectations, then the player would escape detection. However, if the monster detected a trait that didn't fit in the section, or detected no trait all for its particular sense that is, if the player didn't choose a characteristic that corresponded to the monster's sense), the player would be discovered. In the previous example, the player would not be detected by the smelling monster, since they had the "sweet smelling" attribute, but WOULD be detected by the tasting monster, because they don't have the "bitter" attribute. We decided that when the player was detected, they would have to choose one trait from their list to give up forever--that is, for the remainder of the game, they would be unable to transform into an object with that characteristic.
At this stage, the game was still very simple. Our first playtester enjoyed trying to think of objects with the required traits, and found the task both challenging and amusing. However, he felt that having to give up a trait upon discovery didn't seem like enough of a consequence, since it was fairly easy to figure out which traits would be necessary and which could be safely discarded. He also found navigating the board to be too simple, since the obvious strategy was to stick close to the walls to avoid the enemies and there was nothing to prevent the player from doing this.
To address these problems, later versions of the game had more complicated layouts that gave the players more choice or forced the player to backtrack. We also made the grid finer, allowing for more sections with their own distinct sets of associated characteristics, and changed the rules of enemy movement to try to make them less predictable. We hoped that these changes would make navigation less straightforward and would make the choice of which attributes to sacrifice more difficult. Further playtesting revealed that while we were (eventually) somewhat successful in creating a more interesting experience when it came to navigation, players still found it obvious which traits they should give up. In addition, making the enemies' movement patterns clearer meant that it was trivial for the player to decide which three attributes (of the five associated with each section) to take on at every turn, because they could easily predict which enemies would move into range.
On the other hand, all our playtesters liked the overall concept of enemies that represented the five senses, and many of them had a lot of fun trying to come up with objects that would match the set of three traits that they had selected (some of the objects that players came up with were hair gel, ninja stars, rusty drainpipes, and various kinds of pie). The task of future sessions, then, is to build on these aspects that clearly work while we try to solve the problems that our playtesting identified. Clearly we need to make significant changes to what happens after an enemy discovers you, but other possible directions to investigate include: changing the layout so that the player is wandering through rooms of a house rather than simply going from start to finish on a mostly linear path, maybe adding some exploration so that the player only finds out what the required traits of a room are when they enter; revising the shape-shifting system so that instead of giving players a list of characteristics to choose from, we give them a library of objects they can change into, and they have to figure out which ones have the attributes that are needed in a certain area; or adding difficulty to the game by putting in some randomness or adding some real-time sections.
Posted by Alexis Brownell on April 22, 2010 1:37 AM
|Permalink
April 10, 2010 2:20 PM
GAMBIT Spring Prototyping: #5
Following the events of our previous meeting, we decided to branch off in a somewhat different direction. Our black box labyrinth mechanic worked well on its own, but we had reached an impasse as far as incorporating it into a larger system. Matt encouraged us to use the ideas generated in playtesting as a jumping-off point for other game concepts. He also suggested that, as we did with the black box labyrinth prototype, we might consider starting from a fictional premise (like a myth) and try to generate a set of verbs or mechanics that fit with that premise. For this session, we spent a lot of time brainstorming and came up with a wide variety of different games.
We first reexamined the narrative of the labyrinth, turning to the original myth (http://en.wikipedia.org/wiki/Minotaur ) for inspiration. We listed possible protagonists associated with the story, as well as verbs that define them.
When Matt reviewed our concepts, he suggested that we might be adhering a little too strictly to the narrative of the myth. He proposed that we instead isolate narrative elements and turn them into mechanics in an otherwise original game. As an example, he described how a game could be made of the Icarus myth simply by adopting the following rules:
1. Use wax and feathers to make wings.
2. Wings allow one to fly.
3. The sun melts wax.
With a few other elements from the myth, such as negotiating with birds for feathers, one could make an engaging game that is simply evocative of, rather than a didactic retelling of, the Icarus story.
We quickly tried brainstorming with other myths and ideas, and came up with the following premises:
1. A game in which you, an office worker, go to work in the morning only to find that your building has turned into a huge labyrinth. Elements from the myth are incorporated, but the myth is never explicitly stated. Perhaps the line between fantasy and reality is blurred - you fight the Minotaur with a stapler, leave post-its to find your way rather than red string, etc.
2. Related to the labyrinth story, we also thought of a variant in which the Minotaur is the player character. There would perhaps be a first-person running segment in which it was not clear that you were playing the Minotaur until the very end. On a more lighthearted note, there could be a fun mechanic where you capture sacrificed youths and eat them. Since the Minotaur will eat only virgins, the youths will invariably tell the Minotaur that they're not virgins. The goal is to interrogate the youths until you're sure that they're lying, a la Phoenix Wright. The game would involve much bluffing about naughty business.
3. A game in which you wake up in a cot in an abandoned hospital, and must drag your IV drip and heart rate monitor around with you. We were thinking of our black box prototype, and how the feeling of a knotted string running through the player's hand evoked a heartbeat. The goal of the game would be to accomplish a task without exerting or frightening yourself too much, as the player has a finite number of "heartbeats" until they die.
4. We recalled a Pre-Colombian myth about a flea trying to deliver an urgent message. As he travels, he comes across a frog who offers to swallow him and continue running so that the message will arrive faster. The frog then comes across a serpent, et cetera, and so on up the food chain until there are ten animals all stacked inside each other. At the destination, each regurgitates the other until the flea emerges intact with the message. As a game, this could be a sidescrolling race in which the object is to find creatures that are larger and faster than you, and avoid ones that are too slow. Certain creative combos could yield greater success. Getting to the end would be fairly simple, but the challenge would come in replaying the game and trying to beat your top score.
5. The last and most fruitful idea we discussed involved the story of Odysseus in the cave of the violent cyclops: Odysseus, trapped in the cave with his men, manages to blind the cyclops with a sharpened stick, but they still have no means of escape, for the cyclops seals the cave entrance with a huge boulder every night. In the morning, when the cyclops lets his flock of sheep out of the cave, he runs his hands over the backs of the sheep to make sure no men are sneaking past. Odysseus, seeing this, ties his men to the undersides of the sheep, and then grabs onto the belly of the biggest sheep with his bare hands. The cyclops is unable to feel the men, and they escape successfully.
We were interested in a stealth game where the enemy only has one (extremely keen) sense. Most stealth games make use of many senses - sight, predominately, but also hearing (of footsteps, sneezing, etc.) and perhaps smell (in Metal Gear Solid 4, Snake would smell foul if he hid in the trash for too long). But we liked the idea of perhaps isolating these senses so that a player had to think creatively in order to disguise himself. For example, getting past an enemy who relies only on touch may require digging through a pile of textiles or debris in order to come up with an outfit that makes you "feel" like a sheep. You can look as ridiculous as possible, but as long as you feel right, you'll succeed.
We also wanted to make the protagonist small in order to preserve the feeling of the original myth and also to challenge the player to use objects in interesting ways - for example, the protagonist can hide himself under a bowler hat or perhaps use a chopsticks like stilts.
Here is a list of the enemies and their senses:
Eye Man
He has a single all-seeing eye. When dealing with vision, it's easy to fall into the rut of simple disguises. But there are ways to innovate with this enemy. One idea involved sneaking in front of a projector, carrying objects that gave you the shape of something that blends in with whatever is being projected (our idea was that the antagonist might be watching a nature film, and so the player would disguise himself as an animal). So while the unblinking Eye Man is watching the screen, he sees a silhouette that seems to belong to the film he's watching and doesn't bother to turn around. Dealing with silhouettes also pushes the player to think creatively, using objects like canes, fans, and salt shakers to make, say, an elephant silhouette.
Some other ideas include optical illusions, colorblindness, or taking advantage of his lack of depth perception. You may also need to visually mimic the behavior of something you're impersonating.
Ear Man
This guy can only hear. Some possibilities for him include using kazoos or buzzers to imitate creatures. Or, perhaps use recordings to make him think something is happening in his house. Maybe you can also record another creature talking, then play back the phrases generated to have a fake conversation with Ear Man. You'd have to pick which recording to play at every conversational juncture, and if the exchange doesn't make sense, he won't buy it (somewhat like the insult duels in Monkey Island).
Nose Man
Maybe you can wear someone's cologne to impersonate them. Or maybe roll around in pepper so that he sneezes when he smells you. Maybe he has bad allergies, and you can use this to your advantage.
Tongue Man
This was our trickiest challenge, and we're still hesitant to approach the idea of Tongue Man. You may need to impersonate a bowl of soup, so watch him carefully in the kitchen and see which spices he uses. Maybe he'll try to eat you, but if you cover yourself in thai curry or sriracha, he'll spit you out. Or maybe there's an ingredient missing from his kitchen that'll give you a clue to his least favorite tastes.
Hand Man
Hand man is most similar to the cyclops in the Odyssey, since he tries to feel his way around everywhere. It will be important to blend in to your environment using touch. It may be as simple as hiding under something (a sheep) but you may need to cobble together a "sheep-feeling" outfit from a glove and some q-tips. If you need to protect yourself from him, you'd need something spiky or hot. A sticky thing could trap him.
At the end of this meeting, we began developing a paper prototype of the forming-silhouettes/Eye Man scenario, although it's at an early stage and could still use a good deal of polish. In future sessions, we may try adding one or more other enemies to the scenario, with the hope that the interaction between the sets of rules for each of the senses/enemies will create a more compelling game than any single rule set would do.
Posted by Kevin Laughlin on April 10, 2010 2:20 PM
|Permalink
April 8, 2010 11:18 PM
PAX Pox vs. Pipe Cleaners
I have been a part of the PAX Pox team from the beginning. I was there to witness the game in its earliest stages. Back in the day, the game wasn't initially about spreading quirky infectious diseases. At one point it was about stealing access codes from evil GAMBIT scientists bent on taking over the world. At another, it was about stealing ID numbers and taking over territory from other players. Later on, the game abandoned thievery and domination all together and evolved into a competition to build iconic game characters out of LEGOs. Oh, those were the days! Overly complicated, resource-intensive, how-will-we-even-make-this-work-for-500-people, frustrating days...
It took a lot of time and failure to come up with a presumably straightforward game that could attract at least 200 dedicated players. Many of the earlier iterations really could have been developed into interesting party games for maybe 10+ people. However, the complexity of their systems could not be properly explained without at least 3 pages of rules -absolutely unacceptable to use for a game at PAX East, or any convention for that matter. Because these games couldn't be explained in less than 2 minutes and required a lot of materials or GM time, there was no feasible (or cheap) way to scale these for a large convention space without removing major components of the game.
These conclusions drove us to focus on creating a game where simplicity would be absolutely required. From this and other critical ideas, PAX Pox was born! It has one core game mechanic. It can be explained easily without a pamphlet. Most importantly: it's simple! PAX Pox was quite possibly the most straightforward game I've ever helped to develop. We infected over 4000 people and attracted at least 500 infectors. It was beyond satisfying to walk around the expo hall and see badges covered with infection stickers. PAX Pox was a success! This is why I was so surprised to find out that even with all of our hard work developing a simple and interesting game for PAX convention goers there was an even easier alternative: Pipe cleaners.
Yes, pipe cleaners.
PAX East was made of lines - lines to get in the convention center, lines to go to concerts, and lines to get food. The higher ups at PAX East thankfully were aware of this and designed "line games" to keep the crowd entertained during a 2+ hour wait. One of their games turned out not to be a game at all and just involved giving a large group of adults tons of pipe cleaners. I can't express the sheer joy and excitement people showed when they got their hands on a pack of pipe cleaners. Of course, I shouted with glee like a 5 year old girl when I saw Enforcers tossing them into the crowd. People really took to the pipe cleaners and spent time meticulously weaving head gear, making Companion Cubes, or whatever their imagination called for.
At one point, collaboration entered the mix and we started to trade for different colors. Though, the biggest collaborative event had to be joining together to make an extremely long pipe cleaner chain that stretched to the corners of the waiting room. These cheap artifacts from kindergarten were tapping into the creative conscious of a group of adults and giving them an outlet to interact cooperatively with one another. However, no matter how much fun it was at the time, the pipe cleaners didn't have staying power. Many people left behind their creations once it was time to leave or threw them out later. I packed mine away with the thought of playing with them later, but "later" still hasn't come.
I'm bringing up the pipe cleaners because they present an interesting concept when thinking about designing convention games. Compared to PAX Pox, this was the simplest form of play: hand them out and let the players define their own rules or game. No need for GM-player interaction, score tracking, or even explanations. The problem is that a game which tries to follow this is only as fun as the player allows it. Without a clearly defined goal or structure, there is no incentive for the player to continue with the game or even retain interest. This is where PAX Pox succeeds because even though the awards were buttons and stickers, they still provided some kind of attainable goal for the players. The rules created a space for players to explore and test strategies, while the achievements gave them a way to track personal progress. PAX Pox may not have been as simple as a pack of pipe cleaners, but it was able to create dedicated players that were willing to play the game for all three days of PAX East. This is where PAX Pox succeeds as a convention game. This resilience among players, I have now learned, is something that should be considered as equally important as simplicity when designing convention games.
Worst case scenario, GAMBIT could invest in buckets of Play-Doh and hand them out at the next PAX East...
Today's post recaps our experience with PAX Pox, a Big Game designed for GAMBIT's presence at the inaugural PAX East. We cover the three main lessons we can take away from our experience and look at how these apply generally to Big Game design.
Lesson 1: Think Big (Okay, Now Bigger)
Because we're talking specifically about Big Games, small-scale play testing generally won't cut it. While these tests can be useful for detecting major design flaws, they're not going to highlight the more subtle issues that plague Big Games. Mental accounting, while difficult, is the best bet for preventing such issues.
Begin by imagining yourself as a GM on game day. Place yourself under the precise conditions of your game and carefully walk through every detail of each step in the process. Got that? Now, start over from the beginning. This time, imagine each step while facing 20 impatient players. Now imagine 50. What changes in each scenario? How are you going to reach those impatient players? Can you distribute your game materials efficiently? Generating answers to these questions may be difficult, but will force you to confront any imprecise elements of your design.
Lesson 2: Know Your Audience
Our game relied heavily on player-to-player recruitment. Our hope was to utilize this to rapidly spread word of our game. In theory, potential players (we'll call them 'primaries') would approach our booth, become Infectors, and infect 24 carriers. Those 24 potentials (we'll call them 'secondaries') would return to our booth, pick up stickers, and infect 24 more carriers each. While we approached this type of explosive growth, we never quite reached numbers it would predict.
The issue here was not with our design, but rather with a failure to fully catalyze the reaction we had set up. When we were first designing PAX Pox, we focused on the primaries. We designed our achievement structure for them, based on the notion that simply recognizing their task completion would sufficiently motivate these self-selecting players. We neglected to note that secondaries, the key component in our exponential equation, were driven to join through entirely different motivators. Most were persuaded either by the promise of swag or by peer pressure from the primaries. Had we considered this, we would have shifted the focus of our achievements away from intrinsic motivators towards more tangible rewards. We also would have put more energy into convincing the more hesitant secondary players to join.
We might have been able to foresee these issues had we dedicated more time to researching our audience. By surveying the PAX forums, we might have noticed how greatly convention-goers valued booth swag. We also could have taken the opportunity to promote our game and built a stronger initial pool of players.
Lesson 3: Avoid Tunnel Vision
In the weeks preceding the convention, it was hard to imagine we would ever get through three days of PAX Pox. This tunnel vision, created by a desire to just get the darn thing over with, caused us to skim over details not necessary for completing the game. Though it's tempting to prioritize tasks solely based on time restraints, project goals should ultimately factor into how tasks are ranked.
The original goal of PAX Pox was to inform players about GAMBIT. Had we kept this at the center of our design, we might have focused more on the social media elements of our game (twitter and Flickr). These might have encouraged our players to keep learning about GAMBIT even after the game had ended. We also could have devoted more energy to involving journalists in our game. These two initiatives fell by the wayside during PAX as we focused on immediate needs rather than long-term goals.
Where to go from here
Looking to the future of PAX Pox, we find ourselves facing two big questions:
How would the game have been played if we hadn't had booth space?
How would the game have been played at Siggraph instead of PAX? How about GDC China?
Interestingly, both questions help address the issues I've described above. Had we asked the first question during the design phase, we might have focused more attention on streamlining the processes that bogged us down during the game's expansion. The second question reminds us to carefully consider audience. What are the motivations of a Siggraph player versus a PAX player? How would the language barrier of GDC China affect us? All these questions highlight details of our game that could have been improved and yet were difficult to spot during the planning process.
I would encourage anyone designing a big game to generate a list of questions that concentrate on how the game would change under various conditions. If our game is any evidence, there are always opportunities to streamline your design.
Posted by Genevieve Conley on April 7, 2010 6:00 PM
|Permalink
April 5, 2010 4:15 PM
PAX Pox: Lessons in Big Gaming Pt. I
Today's post will take you through the unique challenges and goals we considered while designing PAX Pox. For each, I'll provide a quick summary of why it was important and what kind of impact it had on our final product. We'll go into more detail in our post mortem, but for now we'll try to stick to the big picture. Though the details described herein are fairly specific to our game, the issues addressed by each have the potential to arise in any Big Game setting.
Let's begin by taking a quick peek at the goals that defined PAX Pox. These were established at the onset of our project and shaped the major elements of our design.
Anyone should be able to play
The game should last all three days
The game should appeal to nontraditional gamers (especially journalists)
The game should get people to come to our booth
The game should get people talking about GAMBIT
The game should not have a lose condition
The game cannot disrupt non-players' enjoyment of PAX
While many of these goals were fairly straightforward (we wanted people to come to the booth) they began to set the tone for our game to be all-inclusive and pervasive. They also pushed us to consider a viral-style of game play, an element of our design that would ultimately carry over to our fiction as well.
From here, we began to consider the unique design challenges we would have to consider to produce a Big Game. They are as follows:
Control over game space
Managing GM Load
Technology
Availability of alternative activities
Design time limit
Game scalability
Our game, like any big game, needed to be playable anywhere at any time. However, we had little to no control/ownership over the space outside our 20'x20' booth. Additionally, due to our relatively small team, Game Managers (GMs) needed to be minimally involved in play. These two conditions forced us to continually simplify our model and motivated us to create a game that could spread from player-to-player independently from GMs.
We knew that PAX would offer countless distractions, so players needed to be able drop in and out at will. Due to time constraints and a general lack of availability of Wifi/3G in the expo hall, technology had to be kept to a minimum. These issues compelled us to eschew complex scoring systems in favor of simple, low-tech alternatives. They also kept us from closing off players who might have limited access to technology or other responsibilities to attend to during PAX.
The most important challenge was to create a system that could scale between 10 and 1,000 players. This meant we had to iteratively simplify every aspect of our game from how we explained our game to how we produced our materials. In the end, this forced us to strip any unnecessary or arbitrary components from our game.
These elements were at the forefront of our design for the entirety of the process. However, as with any project, we recognize that there are many things we could have improved. My next post will address the three main lessons we can draw from our experience at PAX and how we might approach these issues in future Big Game design.
Posted by Genevieve Conley on April 5, 2010 4:15 PM
|Permalink
April 1, 2010 11:15 AM
Help out a research project - play Shadow Shoppe!
The faculty over at the National University of Singapore (NUS) have made some modifications to Shadow Shoppe, in which you help a town recover their lost shadows. They've added some new shadows and traits, and now we need lots of people to play their version!
So if you've got a couple of minutes to kill, why not play a Flash game and help out university research?
You may already be familiar with Shadow Shoppe, the game prototype we made last summer. We featured it at Games Convention Asia and some of you may have played it at PAX East. A few months ago, we exchanged code and assets with the researchers at NUS so that they could adapt it for their purposes. They're using the game to collect data on how different people associate character traits with body shapes. By playing the game, you are actually helping researchers better understand cultural differences in character design and visual aesthetics!
This does mean that we're collecting information on your choices during the game, but we're careful to make sure that the data we're collecting doesn't personally identify you in any way. Basically, you'll have to enter your age, your gender, and where you're from before you start the game. That's it, and any other information that we could track (IP address, for instance) isn't recorded in any way.
The labyrinth surrounds you interminably. Your way is unclear, though it is evident that a moment's hesitation will be your end; the labyrinth's monster draws nearer every second. In your arms you cradle your infant child who is recovering from a grave illness. You know you must find the way out.
Playtest 1: Matt
Our day commenced by having Matt play our now physically imagined prototype (designed at the previous week's meeting). Initially, he had virtually no concept of the mechanics, story, or props to be used in the game, other than it was in the survival horror genre. The setup, which was ready before Matt walked through the door, was as such:
A small cardboard box, painted pitch-black, approximately the size of a cinder block, fixed upright on the desk.
Roughly centered on the box's face was a small hole, shaped like an upside-down triangle.
Through the hole passed a length of wine-colored string, about eight inches or so of which lay outside the box, while the rest of the string (about 4 feet long) was hidden inside
A pencil, which rested on the desk inside a small, red rectangle, and a pad of ruled paper
Rules used for the first game (before any sort of feedback) were as follows:
After a brief exposition (see beginning of post) is read to the player, he is given the string to hold in his dominant hand.
A list of words is then given, one at a time, in succession, beginning with the shortest (three letters) and ending with the longest (thirteen letters).
The player is required to write each word, using his non-dominant hand, within a certain time limit (1 second less than the amount of letters in the corresponding word - 8 seconds for a 9-letter word, et cetera).
If the player fails to complete a word, one unit of string is pulled from the box, measured by regularly-spaced knots along the length of the string, and the player must re-write a word of the same length
Every three turns, a die is thrown to determine if the player's "child" sneezes, which will attract the Minotaur to your position (resulting in one unit's worth of string being pulled from the box). The player is asked if he wants to cover the child's mouth to stifle its sneezing.
Victory is attained if the player manages to successfully get to - and write -- the 13-letter word before the string is pulled completely out of the box
For Matt, the two most evocative components to the game were the use of the non-dominant hand and the "oh my God, what's in the box" aesthetic. The weak hand as a mechanic not only provides the challenge, but it evokes in a very elegant way a situation of being helpless and crippled. The black box, with the red string pulled slowly from its depths, provokes a nervous curiosity in the player as he anticipates what might be concealed.
Similarly, the kinds of words we used as obstacles were important to the flavor of the game. The language, either ominous or violent, was a big part of what qualified this prototype as "horror."
Matt succeeded at winning the game, but wanted to know what would have happened had he lost. We pulled all the string out of the box to reveal a rather underwhelming "death tassel" at the end. We had been conflicted about what to put at the end - what physical object could rival the bizarre, paranoid thoughts racing through the player's head as he plays? The imagined threat will always be much stronger than the real one. We wanted to convey "death" or "gore" with something vivid and tactile that would shoot out of the box and into the player's hand as we pulled the string. We also wanted to make it abstract and symbolic, as any literal representation (of the Minotaur, a child, or intestines) might come off as somewhat kitschy. But the result was not compelling.
Before the second playtest, we had a chance to make a couple revisions based on Matt's feedback. He commented that we were operating on a high level of abstraction. Improving the game was largely a matter of solidifying our symbols: Is the tassel at the end of the string the Minotaur? Is it the character's viscera? Is it the child? Is the physical act of writing a metaphor for running, or is it literal, as in an incantation or divination the player must perform to progress?
Playtest 2: Gene
For round two, some dramatic adjustments were made to the game interface. First, we decided concretely that the "death tassel" represented the Minotaur, and the string represented its proximity to the player - if the player botches a word, this is interpreted as stumbling or failing to make the right turn, and the Minotaur catches up a bit.
On a suggestion from Matt, we fashioned a makeshift baby from spare materials. The player could then cradle an actual soft, physical object in the crook of his arm whilst grappling with the writing portion of the game. This led to a more involved version of the sneezing mechanic, in which the player would be prompted to cover the baby's "face" with his writing hand, with the threat of receiving an additional penalty if he failed to do so. This would hopefully make the sneezing mechanic more grounded in the rest of the gameplay.
Gene also enjoyed the mystery of the box and string. He found himself with a strange desire to pull the string, but refrained for the fear of what might be on the other end.
However, the baby was not an entirely successful addition to the game. While Gene found the object endearing in a morbid sort of way, the entire sneezing ordeal did little more than jar the flow of game play. The baby became irritating - not the object of a protective instinct.
Gene was also unclear as to the eventual goal of the game. To him, it seemed that we would eventually be throwing twenty-letter words at him to write in under fifteen seconds. He didn't have a good sense of his own progress, which we felt was essential to feelings of tension as the player nears the end.
Playtest 3: Rik
The third iteration of the game marked a turning point in our procedure. We had made some considerable changes to the rules:
The labyrinth was represented by three stacks of cards, and the player had the option of going left, right, or straight, by choosing the respective deck.
The three decks were assorted into three categories: easy, medium, and difficult (most difficult being the longest words).
Instead of having the string drift off the end of the table after it passes through the player's hand, the player would now be required to wind it around his child's throat with each penalty. Holding both the baby and the string with one arm had been awkward for Gene, so we attempted to combine them in this way.
Amusingly, these additions resulted in a rather awkward playtest. The three decks seemed arbitrary, and Rik quickly found that his decisions had little impact on the outcome of the game.
We had wanted the difficulty of the word given to the player to be randomly determined to reflect running through the labyrinth and picking a path haphazardly, desperately hoping it's the right way. But the element of choice implied that the player should be able to guess properly and be rewarded for doing so, when this was not the case.
Additionally, Rik pointed out that the longer words were not necessarily harder than the short ones - he in fact preferred doing mid-length words of 7 letters or so, because he was more accustomed to them.
By jumbling our cards together, we also lost the feeling of tense progression as the player writes longer and longer words. This progression had also served to give the player an idea of how close he was to the end. In Rik's playthrough, the idea of progress was not as intuitive, and the game seemed meandering.
Finally, the act of wrapping the string around the "baby," while macabre, had the bizarre effect of making it seem like a tendril or tongue. The idea of the string as a measure of physical proximity to the Minotaur was lost.
Playtest 4: Philip
When Philip sat down to play, we had done away with the baby and its sneezing shenanigans (though it was still part of the flavor text) and the "path choice". This was our most simplified version - keeping only what seemed to be the most effective parts.
Philip was the first player to have only a moderate reaction to the box and string: since the game was clearly still a crude prototype, he did not expect the box to harbor anything profoundly menacing.
However, with just the words, box, and string in the equation, smaller elements became more important. The string did feel like a burden, and the knots that slid through the palm of his hand were like time ticking by.
In conclusion, the more we tried to add to the game, the more confusing and awkward it became. The most compelling experience came from the simple symbols of the box and the string and the simple mechanic of struggling to write with the wrong hand. We believe that this mechanic can be incorporated into a larger game, or translated into a digital prototype, but the mechanic itself should be kept pure in order to be most effective.
One final, curious result of game was the sheets written on by the players. Each player developed a strategy to cope with having to write with his weaker hand. Most found that using larger arm muscles to write was quite a good way to do it--Gene at times devoted entire sheets to single words--with varying degrees of success. None of the players reached the level of clarity that they had with their dominant hands, particularly with the longer words. We ended up with a series of quickly scrawled lists of violent words which resembled pages from the diary of a homicidal maniac--an unanticipated but nicely creepy souvenir of our playtests.
Posted by Alexis Brownell on March 24, 2010 5:31 PM
|Permalink
March 16, 2010 6:23 PM
GAMBIT Spring Prototyping: #3
After the WILD success of our Shadow of the Colossus prototypes, Matt asked us to make a paper prototype of a survival horror game. Unlike last time, this would not be an adaptation of a specific, existing digital game but rather completely new that would fit into the survival horror genre. He also asked that we avoid using a standard 52 card deck (presumably because playing cards figured heavily in our Shadow of the Colossus prototypes), and to make use of space and an avatar with core verbs (two things which we had not really included in our previous games).
This struck us as a difficult task, since horror--survival or otherwise--seems to depend so much on instinctive reactions to frightening things that the player sees and hears, and a constant feeling of danger and vulnerability. Paper, Play-Doh, dice, and the other materials available to us aren't really the ideal tools for creating such effects.
Our first task was thus to try to pinpoint the elements that define the genre and that are essential in creating that feeling of horror, and then to figure out how to translate those elements into a form that was compatible with paper prototyping.
In our discussions on this topic, we identified a handful of concepts that we believed to be central to the survival horror genre. One is the idea of rationing: the player doesn't have enough of some vital resource and must plan carefully to conserve it. In many cases, ammunition is this limited resource, but there are other possibilities, including non-physical concepts like an action that one can only perform a set number of times.
We also concluded that combat should be de-emphasized in favor of evasion and avoidance, i.e. sneaking around and running away from antagonists. In the event that combat did play a part in our prototype, we thought that it should be weighted more toward strategy and planning--setting traps, for example.
Finally, we decided that we needed to find a way to include an atmosphere of strangeness and "eeriness" in our survival horror prototype. In our Shadow of the Colossus adaptations, we had focused more on gameplay and mechanics and had downplayed things like atmosphere.
Not only did we want to try a different approach with this new prototype, we also felt that such things were essential to conveying the feel of the genre, and that our prototype would be less effective without an appropriate fiction.
From this starting point, we created two different prototypes. The first grew out of discussion on how to handle space in the game. Early on, we decided that we wanted to avoid standard representations like tokens moving around a grid. We considered ideas like having the player explore a world in which space doesn't behave normally (for example, if the player moved two units to the left and then two to the right, he wouldn't end up in the space he started from), but couldn't figure out a way to effectively represent the warping of space in a prototype.
Eventually, we came up with a game in which the player takes on the role of a person who is hiding in a "panic room" inside his house and has to conceal his presence from an antagonist (controlled by a GM) who is searching the house for him. To do this, he would have to find a way to get rid of clues that show that he is in the house, or prevent the searcher from noticing those clues--for example, he might have to find a way to extinguish a fire burning in a fireplace, or distract the antagonist so that he doesn't notice the fact that the master bedroom is too short by a few feet because of the false wall hiding the panic room.
However, the player has to do all this without leaving the panic room, with only a map of the house and the items in the room to help him. In addition, the player has to keep track of his enemy's movements through the house and time his actions so that they don't attract attention. If the player wants to, say, use the fuse box in the room to cut power to the kitchen where a kettle is heating on the stove, he will have to make sure that his enemy is not anywhere near the kitchen when he does so, using pipes and ducts that conduct sound from different points of the house. Finally, the player can only complete a few actions per turn, and so has to choose carefully which to perform.
We also discussed aesthetic elements that we could add to the game: putting the player alone in a darkened room, with recorded sounds that would play--fire crackling, stairs creaking, footsteps on wood floors--to represent the searcher's movement about the house. These elements, unfortunately, were complex and not feasible for a paper prototype developed in a few hours.
As a result, we could not playtest the game entirely as we imagined it. We were able to play through and try out the puzzle-solving elements (figuring out where the antagonist is and what actions to take to prevent discovery), but we couldn't gather much data about whether our ideas for creating a feeling of horror were effective.
We also tried to take a novel approach to representing space in our second prototype, in which the player is trying to escape from a monster pursuing them through a labyrinth. We decided that it would heighten the feeling of dread if the player was not certain how far away the monster was, but only knew that the monster was getting nearer.
Thus, we came up with a system in which the distance between monster and player is represented by a length of string, most of which is concealed inside a box (so that the player cannot see how much string remains). Every time the monster moves closer to the player, the player pulls a unit of string out of the box, and when the entire string has been pulled out, the monster has caught up to the player and the player loses.
On each turn, the player is given a word that they must write with their left hand (or whichever hand is not dominant) in a certain amount of time--the word is presented as a spell or incantation which will indicate the correct way to go, and writing it successfully represents the player having cast the spell and moved forward.
If the player fails to write the word within the time limit, or writes it illegibly, then they are unable to make progress and the monster moves closer. If the player manages to write enough words (which increase in length as time goes on) before pulling the entire string from the box, then the player has reached the end of the maze (or other goal).
At the same time, the player is told that he is carrying his sick infant child that has a chance of sneezing at every turn--in fact, with each successive turn, the chance that the baby will sneeze increases. If the baby does sneeze (as determined by the roll of a die), the monster moves closer. However, the player has the option of briefly covering the baby's mouth to stifle a sneeze. What the player is not told is that if he does this more than three times over the course of the game, the child suffocates. If this happens, the player is not immediately informed, but the baby ceases to sneeze. Only if the player reaches the end of the maze do they learn that they have inadvertently smothered the baby that they were trying to keep safe.
As with the first prototype, we also tried to include some non-gameplay-based elements that would add to the horror feeling of the game. The words that the player has to write are all of a violent or gruesome nature ("cut", "stab", "eviscerate", etc.); the string that the player pulls starts out white but gets gradually redder as the player pulls it out, and ends in a quantity of red silk (originally we wanted to put something disgusting or frightening at the end of the string, but couldn't figure out how the mechanism that would reveal it would work); even the potential revelation at the end that you've suffocated the infant you carried with you is a fictional element not strictly necessary for gameplay but an addition that hopefully creates a sensation of shock and horror.
Overall, the most difficult part of creating a survival horror prototype may have been the "atmosphere" requirement. It was not terribly hard to put elements of rationing (limiting the number of times you could suppress the baby's sneeze, for example, or the number of actions you could perform in a certain turn) and evasion (escaping the minotaur, concealing your presence from the searcher) in our prototypes. Nor was it hard to test the prototypes to see how those elements worked during actual gameplay.
But making a game where the atmosphere or fiction is important automatically adds a second level of difficulty, because you have to make sure not only that the mechanics you have work and are fun, but that the game is creating the effect that you desire. This was where we ran into trouble with our games--we could playtest the puzzles of the first prototype, or the difficulty level of the word-writing mechanic for the second prototype, but without actually recording spooky sounds or constructing the box with the blood-red string, we couldn't predict how our attempts at unsettling the player would really work.
This may be the biggest advantage that digital games have over our paper prototypes: they can rely on graphics of terrifying zombies, grisly grunge maps, and ominous music to create an emotional effect, but we have to devise with more indirect and unconventional ways of eliciting fear or horror using simpler resources.
On the other hand, forcing us to figure out new ways of inflicting dread in players means that, should we wish to make a survival horror video game, we do have a greater repertoire of techniques at hand -- techniques we might not normally have come up with.
Next post: prototyping and playtesting the handwriting game!
Posted by Sophia Foster-Dimino on March 16, 2010 6:23 PM
|Permalink
March 15, 2010 11:39 PM
GAMBIT Spring Prototyping: #2
Following our previous prototyping endeavor, which involved conveying the feeling of exploring and searching, we decided to try and adapt the combat mechanic in Shadow of the Colossus into the format of a card game.
We kept the game two-player to reflect the conflict between hero and colossus. In addition, we weighted the rules so that the colossus would have more cards but fewer opportunities to use them, and the protagonist would have fewer cards but could cycle through them quickly and play them at a higher rate.
The idea was to establish an even playing field that demanded different tactics from either party: in the digital game, the colossi are strong but ponderous, while the player is comparatively lithe and agile.
In our first iteration, the "hero" was dealt a hand of five cards and a deck of 13, and the colossus began with a hand of ten and a deck of 24. The colossus would put the game into play by placing five different cards in numerical succession (though not necessarily consecutively) on the playing field. Each player would then attempt to complete a straight using the cards on the field in addition to their hands.
For example, if the colossus put down King, Queen, ten, four, two, then the players would simultaneously rush to complete the straight from King to two. The protagonist had the option of playing any card he liked (as long as that card had not already been played), but the colossus could only play cards that directly preceded or followed a card already in play.
In this version of the game, whichever player completed the straight would win all the cards in the straight, and would then shuffle them into his deck. The overall winner would be the first person to acquire all 52 cards in this manner. The cards belonging to a player thus represented a slew of concepts - health (since you would lose cards if you lost a round), elevation (since losing was also a metaphor for falling off a colossus), and advantage (since gaining all the cards would equal a victory).
When Matt played through our game, he questioned the idea of having the cards represent all of these gameplay aspects. By trying to contain so much meaning in the cards, we ended up obscuring some of the concepts that we were trying to illustrate. Clearly having more cards in your deck was better and meant that you were winning (the "advantage" aspect), but the relation to climbing or elevation didn't come across. The cards became a "winningness meter," as Matt termed it: not a reflection of any particular aspect of Shadow of the Colossus, simply a task in which performing well translated into winning.
In the second version of the game, we decided to include a separate "health" mechanic that would be closer to that in the digital version of Shadow of the Colossus. Since the card game phase of battle focused on the climbing mechanic, we developed another phase for the action of actually dealing damage to the opposing player.
The first person to complete the straight would roll a d10 and bet on the outcome. If he rolled higher than the number bet, he would deal damage equal to the bet. But if he rolled lower, he would take damage equal to the bet.
This rule was an attempt to recreate the game experience of taking a risk when stabbing a colossus. In the game, an action button is pressed and held to "charge" strength for your stab. A quick press causes only a very weak attack, but the longer the button is held, the greater the risk of being thrown from the colossus.
We also changed the rules of the card game that represented the climbing phase. In this version, the players battled by playing on different straights: the protagonist would first put down the lowest card in his starting hand and build upwards, and the colossus would put down his highest card and do the opposite.
In addition, play was no longer turn-based: players could put down and draw cards as soon as they saw the opportunity to do so, without waiting for the other player to play. Finally, the acquiring-cards-to-win mechanic was discarded--players no longer had separate decks, but drew from a central draw pile, and the first to complete their straight got a shot at dealing damage to his foe in the die-rolling phase. The loser was the first player to have his health (represented by a stack of poker chips) totally depleted.
An anonymous play-tester was brought in at this point to get a fresh perspective on the game. After a round or so, the tester pointed out that even though a real-time system made the game feel more like a frantic struggle, Shadow of the Colossus also has many aspects that are turn-based. Climbing a colossus often falls into a pattern of struggling up the colossus as fast as you can for a few seconds, then pausing and hanging on for your life while the colossus tries to shake you off. When it's done shaking, you can continue climbing and the process repeats - essentially, you and the colossus take turns. Curiously enough, our game was inadvertently turn-based as both players would politely refrain from taking a card if their opponent was also reaching for the draw pile.
Our solution to this issue was to have the players draw from either of two central draw piles, but discard into their own discard pile. This prevented any lulls in play in which neither player could do anything. Players were also allowed to draw from their opponent's discard pile, motivating each to keep track of his opponent's progress and only discard cards the opponent couldn't use. By forcing players to remain aware of the enemy's behavior, the game felt more like an actual physical struggle.
Matt played through the final iteration of our game and was happy to see that we had made our level of abstraction more concrete and specific. He was also interested in some of the elements that we had eliminated by trying to streamline the game. For example, we lost the clumsiness generated by two players trying to desperately draw cards from the same deck. Having just one deck made the game awkward, but the emotional experience was truer to the spirit of the videogame. Making the card game more urgent also removed any traces of what Matt called the "epic tedium" of scaling a colossus.
Our biggest conflict was between accurately recreating the videogame and making a card game that was upbeat and consistent.
Posted by Sophia Foster-Dimino on March 15, 2010 11:39 PM
|Permalink
March 9, 2010 11:28 AM
GAMBIT Spring Prototyping: #1
The following paragraphs are notes documenting the first meeting of the spring prototyping team at Gambit. We had a working lunch, during which our team leader challenged us to take a preexisting videogame and translate it into a paper prototype. We began by brainstorming some games. Out of the twenty-odd games discussed, we chose Shadow of the Colossus--a game that nearly everyone on the team had played, or at least understood in terms of fundamental mechanics.
The team then generated a list of verbs that were integral to or somehow represented the player's immersion in the experience.
Most of these were directly related to gameplay:
Stabbing, slashing, calling your horse, running, shooting an arrow, swimming, grabbing, climbing, divining the locations of colossi
Other actions were less grounded in the mechanics, and more a part of the unique experience of a given player:
Falling, breathing, stumbling, searching, discovering, escape, yearning for exploration
We narrowed the list down to a smaller, more specific set of verbs:
Search, climb, grab, and fall.
We felt we could use these verbs in a way that conveyed the objective of the game as well as the aesthetic experience of playing it.
With an assortment of game pieces at our disposal (cards, poker chips, dice, go stones, cubes, post-its, graph paper), we first attempted to recreate the experience of traversing a vast terrain. We had the idea to have the player search through a deck of cards to find one that represented a colossus. The cards were then set up as a sort of terrain in which the player would navigate. Cards that were placed face-down were evocative of unexplored areas.
As the player moves a token from card to card, he has the option of searching the stack on which the token sits (limited to one card per turn). In order to prevent the game from simply becoming a pixel hunt, we organized the cards so that the player could intuit where cards of a certain suit and rank could be found. As the player advances, the path before him becomes more evident, but breaking down steps into turns necessitated a more gradual progression.
Among the issues that surfaced during the first trial game, one was the question of adapting the rules to include a second player in order to include the role of an active opposing entity, or instead allowing the inherent rules of playing cards work against the player. We also wanted to extend the theme of "searching" to the combat. In the video game, when a colossus is found, the player must then search for its weak point, and then must in turn search for a tactic to reach it.
We also thought we could convey hopelessness and desperation by forcing the player to use cards of a lower and lower denomination as they lost each round, making their failure eventually inevitable (unless they worked out a secret pattern, or tactic, that would ensure victory). Using lower and lower cards (picked up from lower rows on the board) would also symbolize "falling." Conversely, if the player began to successfully fight the colossus, they would feel "climbing" when the colossus had to use cards closer and closer to themselves.
When Matt played the game, more issues were raised. We wanted to have him play without much instruction, similar to how the game throws the player directly into play. But the rules of the game weren't clear enough from the bare setup, so we had to explain, taking away from the feeling of immersion.
He progressed quickly through the terrain, making us wonder if there wasn't a way to better emulate the feeling of crossing a great expanse. The use of graphics, space, and sound design all contribute to the immense atmosphere of the game, but is there a way to replicate this with a deck of cards and simple gameplay mechanics?
He did identify the pattern in the card layout, allowing him to "divine" his intended destination, and even had an "aha!" moment when he discovered the King of Diamonds (which we had instructed him to find at the beginning). Play was then paused at this point, until further development. Additional ideas we had from this experiment are as follows:
The game contains 16 "boss" battles, and after each battle you are brought back to a central point. Is there a way to represent the cyclical nature of this journey?
Can the variety of 16 different bosses be represented with 16 different kinds of gameplay? That is, one involving cards, another involving poker chips or dice?
Can we reproduce the feeling of the ending, which involves "letting go" of ultimate victory but still embracing a rewarding emotional experience?
Is there a way to involve the horse at all? In the game, the horse is a mode of transportation that you can control, but it sometimes disobeys you. We forgive this disobedience because it's a reflection of its characterization, but how would that translate into gameplay elements?
Posted by Sophia Foster-Dimino on March 9, 2010 11:28 AM
|Permalink
March 1, 2010 4:41 PM
Research Video Podcast Episode 1: DEFINING GAMBIT RESEARCH
Episode 1: DEFINING GAMBIT RESEARCH is a discussion amongst the GAMBIT Staff as to the nature of GAMBIT's particular methodology in regards to video games and the state of game studies as practiced here and elsewhere.
GAMBIT Named 8th Best Game Design Program by The Princeton Review!
The Princeton Review "surveyed 50 collegiate game design programs in order to handpick the best schools you should attend if you're interested in going into game development" (so sayeth GamePro magazine, who published the results), and of these 50 American and Canadian undergraduate programs GAMBIT came in 8th! This is particularly awesome since, as GamePro also notes, "MIT doesn't offer a game-specific degree; it only has degrees in disciplines like computer science and media studies. Through these programs, however, students can access the Singapore-MIT GAMBIT Game Lab to work with other schools in collaboration to create games."
The complete Top 8 list is as follows:
University of Southern California, Interactive Media Division
DigiPen Institute of Technology
Drexel University, RePlay (Digital Media & Computer Science)
Becker College, Game Design and Game Programming
Rensselaer Polytechnic Institute, Games and Simulation Arts and Sciences
The Art Institute of Vancouver, Game Art & Design/Visual & Games Programming
Worcester Polytechnic Institute, Interactive Media and Game Development (IMGD)
Massachusetts Institute of Technology, Singapore-MIT GAMBIT Game Lab
"Our core mission is providing parents and students with good admission advice," says David Soto, director of content development at The Princeton Review. "We're hoping this can add legitimacy to an emerging market."
In all, The Princeton Review surveyed 500 schools before arriving at its top 50 with game design studies.
Programs were evaluated on four main criteria: academics (courses and skills fostered), faculty (especially the percentage who had worked in the industry), infrastructure (technology and game laboratories) and career (internships, job placement). "The schools that scored exceptionally well, the top eight, were really top-notch when it came to all four," he says.
My thesis research has given me the opportunity to think a lot about how game objects - the things we use to play a game, be it board or digital - can be representational. Questions such as "what do they represent," "how do they represent," and "on how many levels do they represent?" are not only fascinating but hint at the larger questions of how games can be expressive.
For now, though, I am just going to present a few of my favorite examples and talk a bit about the many layers on which these objects operate. Click on the pictures to open a larger version in a new window.
(I'm also going to do my best not to mention semiotics and Walter Benjamin, or make this too pedantic.)
To begin, a common example is a rook, from Chess.
This is my favorite example from a standard Chess set. On the surface, the piece seems to represent a castle, or a tower. To a person unfamiliar with Chess, this object is nothing more than a miniature tower. But for someone who knows Chess it is impossible to think about a rook without considering the rules; this miniature tower moves orthogonally between one and eight spaces, and may capture an opposing piece. A more experienced player may find deeper meaning - the rook is more valuable than the pawn. The rook thus has meaning on two levels.
A different example is a Go stone.
Go stones are interesting because unlike the rook they only represent on one level: as Go stones. Taken in isolation, these are just small hard discs, made of plastic, rock, shell, or whatever. An observer unfamiliar with the game may have an aesthetic reaction ("this is a pretty rock") but it is not meaningful in the way the rook is. As with the rook, a player of Go will likely recognize Go stones (especially when in play, as in the example), thus imbuing the stones with meaning.
A more complex example is this Viking set of Settlers of Catan pieces (courtesy a good friend who brought me these from the Netherlands).
These pieces are a replacement for the standard pieces, and operate on a few levels. From left to right, these replace the city, settlement, and boat. The city replacement is modeled on a Nordic stave church, the settlement replacement is a traditional Viking house (identifiable by the gable cross roof), and the boat is based on a Norse merchant ship known as a knarr. These pieces thus represent various bits from Viking and Norse culture, yet at the same time represent the base pieces from Settlers of Catan. This is in addition to the deeper meaning of how these objects function in-game. For someone familiar with these pieces they operate on at least three levels.
The last example is also from a Chess set.
These are the most interesting game bits I've found so far. Here we have collections of letters, which represent sounds, combined in such a way that they represent ideas of objects, which in turn represent specific game bits that also represent real-world objects, but then contain game-specific meaning on top of it all.
This was just a short glimpse at some of the interesting questions that arise when we study game objects, and think about what they represent and how they do so.
Dream logic is a distinct entity from the rational thinking we encounter in everyday life. For our most recent project, the prototyping team explored the prototypical dream experience in order to exploit this unique thinking for a dream-based game.
An important aspect of dream logic is the concept of dualism. Extraordinary tasks are common in the dreamscape and are quite trivial for the dreamer. Trivial tasks, however, can become enormously difficult. When we last left our protagonist, the downtrodden supermarket clerk, his everyday tasks had surged into the realm of impossible. The shopping carts he attempted to herd plagued him with puzzles and the gibberish-speaking customers demanded he sort out their nonsensical purchases.
BACKGROUND:
Now our super(market) hero must restock the abundance of items removed from the shelves. Unfortunately these items don't want to be restocked. To get back at him, they're moving around his back, violating space and time. The goal of the boy (and player) is to determine the method behind the item's madness and to order them according to his manager's instructions.
IMPLEMENTATION:
There were four 'aisles' on which items could appear. Aisles were represented by a card. Items were listed on sticky-notes and posted on the card so that they could be moved easily between aisles. There were four thematic aisles/cards: breakfast, meat, produce, and snacks. These themes were not explicitly explained to the player.
The player was instructed (via writing on the first aisle) that there goal was to arrange items in the first aisle as follows: Cereal, Poptarts, Oatmeal, Cream of Wheat (in that order). The sticky-note items in the aisle did not reflect this order and were as follows: Cereal, Poptarts, Chips, Cream of Wheat.
Players were allowed to 'move' between aisles by requesting to view a different card. They had to first return the current card to the GM before receiving the new aisle. Player's were allowed to 'carry' items between items by removing the sticky note for that item and holding on to it while switching cards. Players were allowed to carry more than one item at a time but were not explicitly told so. Once in a new aisle, players could remove items in exchange for an item they were carrying.
Once players had located the desired item in one of the other aisles, they could return to the first aisle. The desired item could always be located in the aisle of the replacement item. E.g., if Chips replaced Oatmeal, the Oatmeal could be found in the Snack aisle.
Upon returning to the first aisle, players discovered that another item had been replaced (Poptarts -> Rhubarb). To find the target item, the player would need to determine the pattern, i.e., that the target item simply switched places with the distracter item and that these items all belonged to a theme aisle.
REFLECTIONS:
One major flaw in this design was the lack of a win-condition. The designer implemented the ideas with the intention of providing a proof-of-concept, rather than a game. While the idea was well represented, the implementation wasn't fun for the player. Two proposed win conditions included the following:
The player picks up all of the items from the first aisle and carries them with them as they traverse the other aisles so that they cannot switch places with the distracters.
The distracter items switch places with the target items according to some trend/ rule and the player has to figure out this rule.
Furthermore, this prototype did not lend itself well to the idea of including the character's story and motivations into the mechanics. Thus, the idea was placed by the wayside to explore other ideas more characteristic of the true gameplay.
Posted by Genevieve Conley on January 28, 2010 9:00 AM
|Permalink
The first of the five video interviews with Kevin Driscoll.
In it, Kevin explains what his group was trying to do with Picopoke, who plays Picopoke, whether or not Picopoke can actually be considered a game, and why they chose to build it on Facebook. The videos aren't very long (the longest is just over two minutes, the shortest is less than 45 seconds) and they're all very informative, so go check 'em out!
I'd like to extend my warmest gratitude to Kevin for sitting down with me for the interview and for sharing his insight, and to Claxton for all his hard work and much-appreciated assistance! Oh, and Kevin, if you're reading this, appreciate the weather out there in sunny LA. Right now Boston's a big, sloppy, melty mess...
Continuing the recent theme of blog posts about dream logic, I thought I'd discuss the prototype that I came up with for this game.
This prototype was another attempt to explore the strange ways that meanings or properties that are assigned to various objects in dreams, and the way that those meanings affect the dreamworld. For example, if a slug, which is associated with the property of sliminess or slipperiness (as mentioned in a previous blog entry), is put in a grocery cart, it might cause the cart to lose traction and become difficult to control, not because of any physical effect like slug slime ending up on the cart's wheels, but simply because putting a slug in a receptacle extends the property of slipperiness to that receptacle.
In this prototype, the player takes on the role of a stocker in a supermarket where the aisles of the store are unhappy. Each aisle has its own problem or set of problems (for example, one aisle might be feeling lonely, while another aisle might be on fire) which are related to the items found in that aisle or, in some cases, items that should be in an aisle but aren't. The player must figure out how to re-arrange the objects in the aisles so that the problems are resolved. To do this, it is necessary to understand the "logic" that governs how each item affects the aisles. Unfortunately, since this is a dream, the logic is rarely straightforward.
For example, in one iteration, Aisle 3 was crazy because almonds were stored there (why would almonds make an aisle crazy? Because they're nuts! Ha!), and removing the almonds restored the aisle's sanity. In some cases, the aisle's problem was more reasonable (after all, what sense does it make for something like a supermarket aisle to be crazy?) and it was the solution that was dream-logic based: for example, it's conceivable that there could be a fire in a grocery store aisle, but only in a dream would it make sense to put out the fire by opening an umbrella in that aisle and thus causing it to rain.
Originally, this prototype was a little unfocused. In addition to solving the aisles' problems, the first version required the player to be able to push a grocery cart to the end of the aisles to collect some sort of prize there. However, the objects in the aisles also served as obstacles to the cart's progress, so to get to the end of each aisle required a complicated shuffling of objects between aisles that would allow the cart enough room to move around while still keeping the aisles happy. It didn't really work; I think I was trying to add in too many systems at once on the first attempt. It might have had the potential to be an interesting spatial reasoning game, or a more complicated version of that puzzle where a guy has a fox, a goose and a bag of corn on one side of a river but a boat that can only hold one of them besides himself, but in the end, neither of those were actually what the prototype was meant to explore. So, the idea of objects as obstacles was pretty much abandoned after that.
The second version retained the idea of having to push a grocery cart to the end of the aisles, but now the only requirement was that the aisles be happy (I guess an unhappy aisle would refuse to let a grocery cart through? The reasoning behind this was never really fleshed out, which in retrospect probably should have tipped me off to the brokenness of this aspect of the prototype). However, during the play through, it came out that there was really no good reason to have this cart-pushing requirement: there was nothing to explain why exactly the player character wants to push a cart to the end of the aisles. Sure, there's a bar of gold or some other prize there, but that is itself a problem: what are bars of gold doing floating around a grocery store? They were just there to provide the player with a reason to push the cart to the end of the aisle, and that brings us back to the question of why it's necessary to make the character push a cart down the aisle. Maybe in later prototypes, or in the actual dream logic game, some story might be added that explains why pushing a cart down aisles is a good thing to do, but at this point in the process it made more sense just to tell the player that their goal is to make the aisles happy. Happy aisles = happy customers, or something.
So, in the final version of this prototype, there was no mention of carts or obstacles or anything like that, just some unhappy aisles with a handful of items in each. Also, by this point, the aisles' woes, the objects, and their interaction with each other had gotten a little more focused and often more intricate. There wasn't any wordplay in this version, for example, since it had been pointed out that puns don't play a part in many people's dreams, so although the idea of almonds making an aisle "nuts" had a sort of silly logic to it, it wasn't exactly dream logic. One of the more complicated puzzles in this iteration involved an aisle containing, I believe, a top hat, a cactus, and a clock, and that aisle was on fire. To put out the fire, the player not only had to bring over an umbrella from a different aisle to make it start to rain, he/she also had to remove the cactus from the aisle, because cacti are associated with deserts and while the cactus was in that aisle the air would be too dry for sufficient rain to fall.
This was the last version of this prototype that was created, because the semester was ending, but an idea that would be good to explore in the future (suggested by the game's owner) would be to have the objects in the aisles relate somehow to who the character is, and what kind of life he leads outside the dream. For example, one of the objects in the last version was a top hat that could produce rabbits---maybe that item was included because the character is actually an amateur magician. If so, there could also be items like giant playing cards, and puzzles revolving around the suits (maybe one of the puzzles requires a DIAMOND ring?) or conflict among the face cards (is there strife in the Court? Are the king and queen mad at each other?).
Posted by Alexis Brownell on January 27, 2010 9:00 AM
|Permalink
January 26, 2010 9:00 AM
Final Summary of Visual3D
Well, today is my last day so I thought I'd do one final summary of my experiences with Visual3D.
Pros Forums
A few times I asked on the Visual3D forum for solutions to problems I was having with the engine. If someone in the community couldn't solve it (which was usually the case), an actual developer of Visual3D would answer my questions and help me until the problem was solved. This was an amazingly helpful asset.
This may go away once Visual3D gets out of Beta, but by then hopefully the documentation will be better and the community will be larger and more experienced.
Code
One of my favorite things about Visual3D was that a user could choose their level of involvement in the code. A user could probably make an entire game by just using the GUI and scripting language. On the other hand, a user could make a game while only using the GUI to import assets and view their scene. Any combination of the two strategies would work as well, with the user only going into code when they need it.
The flexibility of the system was a major asset to Visual3D and would make it useful to anyone regardless of experience level.
GUI
Visual3D has a really nice GUI interface for making games. Most of the current documentation is related to the GUI, so it seems like the focus of the developers rather than code.
The GUI was really useful for debugging also, since I could click on any object in the scene and view it's attributes as well as change them while the simulation was running.
There is a lot of scripting you can do in the GUI which I didn't get much into (I did more C# code in the background rather than their scripting language), but it seems like this would be really useful for someone without too much programming experience.
Features
Visual3D has a lot of features that make it very powerful. For example, the AI engine is very easy to use and to create behaviors with. Making the enemy follow the avatar took about 2 lines of new code, which was pretty amazing. There is also a way-point system built into the GUI.
Cons Documentation
This was the big one.
Even though I could see all the good things about Visual3D and it had a ton of amazing features, I would keep getting stuck because of a lack of documentation. This wouldn't have been as big of a problem if I had had access to the source code, but since I didn't, I had to base most of my code off their sample demos.
One problem I ran into was trying to turn the model independent of the camera. It turned out that I had to use the Spatial object of the model, and once I knew this, manipulating object's size, position, and orientation was unbelievably easy. However, there was no documentation to point me in the right direction and the sample code didn't highlight this fact.
I wish that there had been some basic tutorials saying how the developers meant for certain tools to be used just to point me in the right direction.
I think that once Visual3D has some basic documentation, it will be an excellent system for anybody to use regardless of experience level.
Uh... Importing Models
This goes in the "uh" category because I'm not sure if the problem was with Visual3D or with my lack of knowledge of Maya. I had a problem importing animations that were attached to the skeleton from Maya to Visual3D. Without animation, Visual3D would not move the models as characters. But again, this was probably my own personal failing at understanding Maya, and it seems like Visual3D doesn't make this process hard.
tldr: I think that once Visual3D has some basic documentation, it will be an excellent system for anybody to use regardless of experience level.
Posted by Caryn Krakauer on January 26, 2010 9:00 AM
|Permalink
January 25, 2010 9:00 AM
Goodbye to U(nity)
I can't believe the semester is over already! And I really can't believe that I have a mostly-working prototype of Abandon in Unity. Here's a screenshot of my version of level 15, "Hopscotch", side by side with the same level in Abandon:
Along the way, I've tried to record some of the day-to-day bugs and challenges of learning to use Unity. Here are some issues I had during the learning process that I may not have specifically mentioned:
There doesn't seem to be any sort of ambient light available. The closest thing to it is a directional light, which shines in only one direction but shines in that direction all over the gamespace. The only other light options are point light and spotlight.
Unity's version of C# seems to have nonstandard capitalization requirements. I found this out when I tried to use Caryn's text reader program and it refused to work until I changed a few capitals. In general, capitalization is very important to the scripting syntax.
The scale of an object given in the inspector view is its local scale--that is, the size of the object relative to its original size. Likewise, if an object is the child of another object, the xyz coordinates given will be its position relative to its parent. This can make it difficult to determine an object's global location or relative size.
Every object in a scene will have a Transform, so a lot of the functions that you might think would belong to the GameObject class, such as IsChildOf, are actually under Transform. I forgot this a lot. Very often Unity would tell me a function I had used didn't exist, and the fix would turn out to be changing gameObject.Function() to gameObject.transform.Function().
The output buffer displays at the bottom of the screen (not the top, as the video tutorials claim), and you have to click on it if you want to view more than one line at a time.
The vector Vector3.forward points along the z axis, but in the default perspective view in the scene view, this is not the direction you are facing. I had some trouble with that when I tried to write keyboard input using the arrow keys and the player seemed to be going in the wrong direction. The game view looks in whichever direction the camera is looking.
If you create a variable in a method and never use it, Unity will send you a warning... but if you create an instance variable and never use it, you will not be reminded to do anything about it.
The main documentation page has links to a number of useful resources, including the Unity script reference, the user manual, and the reference manual--and no, I don't know what the difference is between the last two. I especially recommend watching the video tutorials before getting started, to give yourself some idea of how Unity works and where to begin. They also explain how to navigate the scene view, and some basic concepts like parenting which will be very useful later.
The Unity documentation is generally helpful, but in some respects lacking. It's easy to look up a particular command, but not so easy to find the command that does what you want to do. For reference, here are some especially useful pages from the script reference and the manuals:
Note: Nearly all the sample code in the script reference is in Javascript. I can't vouch for the quality of the Javascript code, but the C# code doesn't always work, when it's present at all.
When all else fails, your best option is to try the Unity forums. I got answers to a lot of my questions that way, and everyone who posted was very friendly and helpful.
Now that I know more about Unity, there are some things I would have done differently when I made the game. For example, if I had known about the CharacterController component sooner, I would have taken some time to learn how to use it, which might have worked better with the physics functions than using a collider.
Posted by Naomi Hinchen on January 25, 2010 9:00 AM
|Permalink
January 24, 2010 9:00 AM
Ideas & Ants
So far this semester, the prototyping team has worked on a game about fate, a zombie game with more-realistic-than-usual NPC behavior, a one-button, purely audio game, a game about words, and a game that uses dream logic---so we've been kept pretty busy over the past couple months. These games have all been the projects of other researchers at the lab, to whom we loaned some of our brainstorming/prototyping power. For the past week or so, we've been trying something different, and working on a game that we came up with entirely on our own, from brainstorming on out.
We've made a few starts on this project at different times in the past--one of the walls in our room is still covered with game ideas from a brainstorming session weeks ago (some highlights: "Black Plague--the game!"; a human-harvesting game, with you as a vampire -- think Harvest Moon plus fangs; "Bacon Games!"; an MIT fighting game), and I know there's at least one GoogleDoc floating around the internet somewhere that has even more brainstorms on it. So we're not short on game ideas, is what I'm saying.
But it's actually been a little difficult to move on to the next steps, partly because we've been busy with other stuff, but possibly also just *because* we had so many ideas. I think each of us has our own set of favorites, without necessarily a lot of overlap between our sets, so we've never been able to settle on a particular idea or set of ideas that we've all wanted to explore further. I know we've sat down multiple times to talk about what kind of game we want to make, and half of us end up talking about bears and the other half talking about a tiny person trapped in a fridge. What eventually ended up happening was much less organized; during a break in between other projects someone said "Let's make a resource management game", someone else said "Yeah!", and the third person present at the time was cool with the idea, and suddenly that was our new project. So maybe that's the best way to do it: rather than generating a bunch of ideas for games and then trying to pick between them, figure out some unifying concept -- theme, mechanic, whatever -- that everyone agrees is interesting, and work from there.
After throwing out a few ideas on what our resource management game could be about, we settled on an idea that had come up in previous brainstorming sessions, of a leaf-cutter ant colony. We latched onto that idea pretty quickly, possibly because an ant colony that gathers leaves lends itself well to resource management: having to gather leaves to nourish the fungus that the colony feeds on (it turns out that's what leaf-cutter ants do with the leaves they cut: they chew it up and use it to cultivate fungus), figuring out whether you should increase the number of soldier ants or harvester ants or fungus-farming ants (real life conveniently provides us with a number of pre-built classes in the form of castes in leaf-cutter ant colonies) and whether you can actually afford such an increase, and so on, provides a wealth of interesting decisions for the player to make.
However, this sounds a lot like a classic RTS mapped onto an anthill, which could be an interesting fictional backdrop but might not provide much innovation in terms of gameplay. So, we've been trying to come up with some ways of adding to this concept. Here are a few we've thought of:
-Scent trails: Give instructions to the colony/ants that aren't explicit -- players draw a path from x to y and ants will bring resources from y to x continuously (assuming here that x is the hill and y is the site of some resource). Players might also sabotage opponents by breaking their trails or re-routing their trails into confusing paths or endless loops.
-Leaf-cutting: Like a kindergartener, the fungus likes its food to be cut into particular shapes, but cutting some shapes of leaves is harder/more dangerous than cutting others; cutting larger leaves is harder. Or possibly you have to cut leaves so that they'll fit down the ant hill tunnels, but not so that leaf transport is inefficient, with each ant carrying a tiny piece of leaf.
-Impostor ants: An impostor has infiltrated the colony and has to simultaneously blend in and bring down the colony/kill the queen; the regular ants have to figure out who the impostor is and stop him/her
We're hoping to have a second well-prototyped game by the end of the semester, similar to the work we did on the cat scaring game earlier in the semester. The process is not easy: an ant colony is a complex system---multiple interacting complex systems, even--so there are a lot of possible paths for us to go down. So far, we've each tried to focus on some aspect that interests us. In my case, I think the scent trails idea is most interesting. It might be getting a little bit away from the resource management idea, or maybe just backgrounding it a bit, but I can see players competing to build trails to strategically important spots, taking turns to place paths or disrupt another player's existing trails. It might be worth investigating a restriction on what players are allowed to see--if you can only see your own scent trails, you'll have to figure out what other players are up to by watching what their ants are doing. Or maybe you can't see their ants until those ants cross your scent trail, since your awareness of the world probably ought to depend on what your ants can see. I'm also intrigued by the concept of having to cut leaves into particular shapes so they'll fit down a tunnel or comply with another type of restriction, which keeps the focus on the resources but adds another dimension to the game and the player's concerns.
Posted by Alexis Brownell on January 24, 2010 9:00 AM
|Permalink
January 23, 2010 9:00 AM
On to AI...
Currently (besides looking very different), the game behaves very much like Abandon besides some small differences. Collisions and enemy wake-ups now work, and enemies will die as well as hurt the player when hit.
The actual attack and damage interactions were very easy to implement, as combat is essentially built into the base Avatar classes.
Another element that was implemented was the dynamic spotlight. When the player is damaged the light changes size in accordance to the player's health. The change in light also affects its sensors size, so a smaller light will have a smaller sensor radius.
The next step is to implement basic AI. All that it will be at first is an enemy heading towards the player's location with no path-finding to avoid walls or other obstacles.
So far I can see two possibilities. I have created a script in the GUI, but I can't seem to figure out how to call it from the C# code and cause an enemy to perform it. The problem with doing it in the GUI is that enemies are created from text files, and are not dragged into the scene by the GUI. So the script would have to be added to the enemy object itself from the GUI. Hopefully this will be relatively straight forward.
The other option is to do it all from the C# code, which seems like a lot more work, but might be the only way to do it in code.
Posted by Caryn Krakauer on January 23, 2010 9:00 AM
|Permalink
January 22, 2010 9:00 AM
Leaf Cutter Ants: The Board Game!
Under-slept, over-exited, and inspired by caffeine, I decided to make a board game based on leaf cutter ants. With a (kinda) twist: one of the players is an impostor! This actually happens in ant colonies, other insects or even other types of ants will live in colonies, mimicking the ant's chemical signature to pass as the local ants, and partaking in destructive behavior.
In a slightly cartoon-ified take on this phenomenon, what might an impostor with the colony's worst interests at heart do? It might set misleading scent trails or erase existing ones. It might take food for itself. It might frolic with parasites and introduce them into the colony. It might dig towards a water source to flood the colony. It might kill ants if there are no witnesses. I might eat more than its fair share. It might be all around unpleasant.
So how to turn this into a board game? I took the model of Shadows over Camelot, a game where the players must compete against the game. This model works well for a game that takes place in an ant colony
Posted by Jeremy Rossmann on January 22, 2010 9:00 AM
|Permalink
January 21, 2010 9:00 AM
Interactions
So, though a hack I managed to get the main character to finally see enemies.
The problem I was having was that when I tried to create the main character in a way that allowed their perception to work, it wouldn't show the model (I have no idea why).
So my workaround was to create an invisible triggered area that had a spotlight in it. The triggered area follows the hero around so that it looks like the hero has perception themselves.
The only problem with this is that the area constantly triggers on the hero (every frame), so I can fix that in two ways.
1) Hope that it doesn't create any lag (which it doesn't right now) and just take care of that case with an if statement.
2) Change it so that the hero is the only thing percepting, so that I can make the hero non-perceptible. I'm not sure however, how this will affect AI. Hopefully AI won't rely on perception of creatures for path-finding and the like.
So, right now my play is to go with 1 until I see any problems. Since it works right now, there's no reason to mess with it as there's not much semester left and there are probably more important things for me to spend my time on.
My next step is to actually make the interactions between the hero and the enemies.
I also looked a little into the AI system and am confused. There seem to be a number of ways to do it, both through the GUI with scripts and code in Visual Studio. The tutorials on the subject seem to be up to date, although I haven't tested them yet so I can't be sure.
Posted by Caryn Krakauer on January 21, 2010 9:00 AM
|Permalink
January 20, 2010 9:00 AM
Run away! The chasers are coming!
I've had some trouble getting the chasers to work with the setup script... but on the plus side, I figured out how to program in some cheat codes. I can now skip to the next level or restart the current one. For testing purposes, of course.
At first I had trouble getting the script to choose a mesh based on the list in the pino file. As a temporary fix I just used one mesh as the default, which led to the player being chased by a horde of tiny bathtubs, but now I think I'm back on track to reproducing the meshes in the original game. I was using Resources.Load to select the correct mesh and load it into the script, but it kept returning Null. The problem, as it turned out, wasn't Unity's fault; some of the meshes had different names than were listed in the pino file, so I was sending Unity on a snipe hunt looking for toilet or robot when the mesh I really wanted was toilet_bowl or robot2.
Now that the script is loading the meshes properly, I don't have to go with the tedious alternative of creating a prefab for every single object. I do, however, have to make sure that the script adds all the necessary components--since I'm not using prefabs, the objects won't come with the script, collider, and tags built right in. This proved to be more of a challenge than I had anticipated. For one thing, it turned out that the Resources folder contained both object files and Maya binaries, and they all had the same names, so half the time I would get the wrong kind of file! I moved all the object files into another folder so Unity wouldn't get confused.
For some reason, even after I fixed all this, the car object was still refusing to use physics functions. When I added rigidbodies, it disappeared entirely--I think it may have fallen through the floor. I'm still not sure what's going on there.
Oh, and in other news, I finally changed the player's collider so she can't climb the walls, but I still had a bug where the player could slip through the walls at some of the corners. I changed the walls from planes to blocks, and somehow she's still getting through. Some of the chasers are also managing to climb the walls and make mischief. At least it got rid of the weird effect where the player's aura would wake up a chaser on the opposite side of a wall.
Posted by Naomi Hinchen on January 20, 2010 9:00 AM
|Permalink
January 10, 2010 8:49 AM
The Etymology of Zork
MIT researcher Nick Montfort is digging into the origins of the word "Zork," the name of the seminal text adventure game that started Infocom and, in turn, the rest of the Boston game industry.
It seems reasonable to pursue this question, and reasonable that there would be some discernable answer. After all, there's a whole official document, RFC 3092, explaining the etymology of "foobar." It could be interesting to know what sort of nonsense word "zork" is, since it's quite a different thing, with very different resonances, to borrow a "nonsense" term from Edward Lear or Lewis Carroll as opposed to Hugo Ball or Tristan Tzara. "Zork," of course, doesn't seem to derive from either humorous English nonsense poetry or Dada; the possibilities for its origins are more complex.
Spoiler alert: Nick doesn't arrive a specific conclusion as to the source of the word "Zork", but his detective work is fascinating to read. His article also links to Peter Samson's 1959 TMRC dictionary, a treasure trove of early hacker slang.
Remember back in the "Instantiating prefabs" entry, when I mentioned that Unity doesn't like casting instances of a prefab (which are of type Object) to GameObject? This has gone from a minor annoyance to an actual problem. A lot of the things I want to do to these objects require GameObject functions.
I did find a way around it, though. For objects like the walls and floor, I don't know how many I'm going to need, so I need to create them from the script. But for objects like the player avatar, since I'm only going to make one, I don't need to know the prefab; all I have to do is create one ahead of time, then move it to the appropriate location using the script. So instead of having a Transform object in the script and setting it to the prefab, the script now has instance variable
public GameObject avatar;
Then I simply created an instance of the avatar in Unity and dragged it from the hierarchy to the inspector. The script will use the same avatar every time it sets up a level.
(Update: Someone on the Unity forums has come up with the answer! Just in time, too, since I can't use this workaround when creating the chasers.)
Posted by Naomi Hinchen on January 5, 2010 5:00 PM
|Permalink
January 5, 2010 10:00 AM
NPC Interactions
Recently, the team finished several prototypes focused on the NPC and player interactions for Matt's zombie game. Our designs examined how various NPCs with distinct character traits could affect a player's actions, as well as transfer information to the player, while trying to accomplish some goal (building barricades, reuniting with your party, etc.). After we presented Matt with our prototypes, he brought up a very interesting idea that I think the team should consider at some point in the future.
What would happen if the player was removed from the equation? How would the NPCs interact with each other?
I have always wondered why more games haven't considered creating NPCs that are more than shopkeepers or useless polygons that take up space in battles. What if they could perform tasks without needed the player to constantly guide them or follow their own goals? Looking at The Sims as an example, non-playable Sims complete their wants and needs without needing to interact with the human player as well as form relationships with other non-playable Sims. It would be interesting to bring that concept into other games where NPC free-will could possibly benefit the player and eliminate the anger (that at least I always feel) towards weak, useless characters.
I believe a problem with many games is that NPCs are almost an after-thought, not givent
Posted by Bianca Farrell on January 5, 2010 10:00 AM
|Permalink
January 4, 2010 5:00 PM
Tile time
Just got over one of the big hurdles: Unity now loads levels from a text file!
To make the code easier to test along the way, I actually wrote the series of functions used by level loading backwards. I started with the code to create a tile, given the locations of the walls... then the function that finds the locations of the walls, given an integer tile code and a char to indicate direction... then the code to parse an input string into an integer and a char... and finally, I adapted Caryn's text file reading function to create a 2D array of input strings. Despite all the testing, no is more surprised than I am that it worked in the end. In the process, I learned a lot of new and annoying things about Unity. Such as that it apparently has its own set of capitalization conventions for C#, which differ from the usual C# syntax.
Here's a simple level I created to test the tiling functions:
Here's a picture of the Abandon level Waterfalls, the first level I tried reading from a text file, loaded into Unity.
After getting to the point where the program could read in a text file, I found out that the code that decided where to put the walls was buggy, so I fixed it and made some other adjustments. Here's the level in Unity after the changes:
And finally, for comparison, here's a partial view of the same level in Abandon:
Posted by Naomi Hinchen on January 4, 2010 5:00 PM
|Permalink
January 4, 2010 3:00 PM
Instantiating prefabs
I'm working on getting Unity to start with an empty screen and build everything from scratch with scripts. I've quickly discovered that it's not possible to build everything from scratch. Prefabs are very helpful (you can see the Unity documentation on creating them here), but it's still necessary to use the inspector to some degree.
For example, I built a prefab of the player. I can notify the script that it needs to create a prefab by including it as an instance variable:
public Transform avatar;
and then creating an instance of it in the code:
Object ob = Instantiate (avatar, new Vector3(0, 0, 0), Quaternion.identity);
(The Vector3 gives the initial location.) However, you may notice that the prefab is never assigned a value. It is necessary to go to the project view and click and drag the appropriate prefab onto the variable name in the Inspector. For this reason, it's important for the instance variable to be made public, because otherwise it will not appear in the Inspector.
The nice thing about this is that the prefab comes with the player's scripts and components already attached. The same goes for other prefab objects in the scene, which means that once I get the script to instantiate all objects, I can immediately start playing, since the keyboard input functions are in the player script.
Important note: When creating an instance of a prefab this way, be very careful about making changes to it in the script! I found out the hard way that if you make changes to avatar instead of ob, the prefab itself changes, which can make wild and wacky things happen if you try to run the script more than once--especially if you want to, say, scale the object. This has become something of a headache, because for some reason Unity makes a fuss about casting ob to a GameObject, which would make it easier to work with.
The Instantiate function is similar to (but not quite the same as) the CreatePrimitive function, which is the equivalent function for creating primitive shapes such as planes and cubes. A big advantage of CreatePrimitive is that the object it returns is already a GameObject, avoiding the casting problem.
Posted by Naomi Hinchen on January 4, 2010 3:00 PM
|Permalink
January 4, 2010 1:00 PM
Unity vs Visual3D (spoiler: Unity wins)
I spent the first half of the semester working on GumBeat so I am a recent addition to the Game Engine Team and have spent the last few weeks getting up to speed on Unity and failing to get anywhere with Visual3D.
Lets get the bad news over with first.
Visual3D is great software if you want to drag-and-drop premade skies and dinosaurs onto a scene. Other than that, I don't think it's worth using. The interface is very unintuitive. You can drag and drop premade primitives (and skies and dinosaurs) into a default scene very easily, but it's unclear where to go from there.
I tried simple things like putting a cube and a spotlight in my scene. The cube was super shiny and the spotlight wouldn't cast shadows. Both of them have oodles of options in a handy panel on the right but when I tried to change the default values for say, the range of the light, it snapped back to the default value. Unless I could figure out how to edit it graphically in the scene view, nothing happened.
The documentation for Visual3D is outdated and spotty. They have an old wiki and a few video tutorials but no obvious API or reference documentation.
In sum
Pros: Dinosaurs, premade 3D environments and some particle systems.
Also you can drag objects connected to the ground and they follow the topography of the surface, which is handy for object placement.
Cons: little useful documentation, unintuitive interface, confusing controls.
Unity was much easier to use. They have extensive reference and scripting documentation (although it is not always quite as useful as it appears) and useful tutorials that walk you through the basics of using Unity and scripting.
Since Naomi had been working on making physics work, I decided to try making physics-less collisions. Using only scripting, I wanted to detect when two objects collided and push one of them back so they were no longer intersecting.
The Unity interface is easy to use, especially after reading the introductory tutorials. You can create primitive objects and drag-and-drop within a menu to set objects as children, add scripts, etc. You can even expose variables in scripts and then assign an object to that variable by dragging in the GUI.
The Unity scripting reference was easy to use and click through, although sometimes it did not give quite as much information as I wanted. I never saw a clear diagram of object hierarchy, which would have been useful, but I figured most of it out in the end.
Unity provides the concept of "triggers", which I used instead of collision detection since turning off physics also turned off collisions. When an object enters a trigger (any object with the trigger attribute enabled) they both call the "onTriggerEnter" function. I used this to detect collisions and did some simple vector math to transform the moving "character" back outside the bounding box.
Unity wasn't all fun and games though, it too has a few annoying quirks. Most obvious was it's arbitrary placement of created objects in the 3D space. Making a cube involved hunting down where Unity had placed it and dragging it back to where it was supposed to be. Also when testing it gives you the option to click "play" to see what your game behaves like. You can change variables and scripts while in this mode, but no changes are saved. Sometimes this is useful for testing purposes, more often it was annoying when changes you thought you made didn't get saved.
in sum
Pros: interface was well explained by tutorials, although not always intuitive. Drag-and-drop controls make scene building and simple scripting easy
Cons: arbitrary placement of new objects, not saving during testing
Posted by emilyp on January 4, 2010 1:00 PM
|Permalink
December 29, 2009 4:44 PM
Flixel experiments - AI and combat
Checking the Flixel web site for new code drops from Saltsman is routine at this point. When committing my code back to Perforce, I've found it easier to separate the "updating my project to the latest version of Flixel" from the "adding new functionality" stage. So first I check out the Flixel directory, then I check out any individual code files that need to be edited to accommodate changes in Flixel, if any. It's a bad idea to commit any code that results in a broken build. It's more time-consuming than simply checking out the entire project, updating Flixel, and checking it all back in, but I'm trying to train myself in good team-coding habits. However, I haven't decided if I should also be checking out the compiled runtime directory when I'm updating Flixel, since every new version of Flixel would necessarily change that too, but Perforce has a habit of yelling at me when I do that.
Any opinions would be welcome!
Bad dudes
The next step in Tim's tutorial is the addition of enemies. This involves creating an "Enemy" class, which is much like the "Player" class, only instead of keyhandling functions, Tim lays out the logic for basic AI. Jump if the Player is higher, turn towards the player ninja, and move. There's a lot of code to limit bunny-hopping: the enemy must be on the ground and two seconds must pass between enemy jumps. So now I have a new enemy sprite, but... where's the code to actually insert them into the level?
There's a step missing from the tutorial, it seems. Re-using some of the code for inserting the player sprite into the sprite layer, a second green ninja successfully appears, following my player ninja like a little puppy dog. At this point, there's no code to handle damage, so we quickly become best friends. My hastily-created level design turns out to be a pretty tricky obstacle course for the enemy, requiring pixel-perfect jumps that the AI wasn't designed to handle. I spend a couple of minutes trying to coax it to higher platforms, impressed how Tim's small set of rules created fairly entertaining enemy behavior.
Shuriken
Satisfied, I move on to adding ninja throwing stars. Time to put the puppy dog to sleep. At the end of every chapter in Tim's tutorial, he displays the entire code listing of all the classes that changed as a secondary check. That's where I actually find his implementation for adding enemies to the sprite layer. Instead of adding a single object, he creates an array for enemies and just pushes one into the array for now. This is a nice, flexible approach, that anticipates hordes of ninja enemies for the future. This bodes well for my player ninja, due to the Law of Inverse Ninjitsu.
Ninja stars are basically a static image, but Tim demonstrates Flixel's ability to rotate sprites here. Tim loads the ninja star image pretty much the same way he loaded previous animated characters into memory, but Saltsman has actually provided an easy way to do it by passing the image reference as a parameter to the sprite constructor. There's something to be said about consistency for readability, but I'm keeping a mental note to try out the constructor parameter in the future, just for kicks.
'Tis but a flesh wound!
Tim also adds code to handle damage here. The ninja stars are capable of altering the health variable of enemy ninja sprites, and the enemy ninjas themselves get to hurt the player ninja by bumping into them. The Player class keeps track of the last time the player ninja received damage with a variable called _hurt_counter, so there's a couple seconds of temporary invulnerability while the player flees to safety. Collisions, however, are handled in the PlayState class (basically the main game loop) so PlayState needs to know _hurt_counter to figure out if it should take damage. Turns out _hurt_counter is private to Player, so I need to change it to public. Just for kicks, I try a different approach, doing the collision test in Player instead of exposing private class variables, and I get the same behavior. For the sake of keeping up with Tim's tutorial, though, I revert back to his version.
The ninja stars also give Tim the opportunity to show off FlxEmitters for particle effects. When the stars hit a surface, they throw out a shower of white sparks. They look good and I notice a slight motion-blur effect on the particles, but that might be due to my LCD screen than in code. No worries, I'll take it! As for the spinny rotation of the ninja stars, that doesn't look too hot due to aliasing from the chunky resolution of the game. I crank up the angular velocity of the ninja stars so they look more deadly, at least. (Re: Storm Shadow in G.I. Joe.)
I've highlighted a couple of quirky observations about Flixel code after the jump. It's easier to use actual class names to make my point, but it's definitely less comfortable to read. I'll try to be less jargony in my next post.
Saltsman's tutorial is more of an intro to Flex Builder IDE than Flixel, but the window-by-window detail is pretty reassuring for a first timer. Now I'm moving on to Seifer Tim's tutorial, which was recently updated to reflect the changes in Flixel 1.47. This tutorial is intended to walk a new Flixel coder through a basic game where you have ninjas throwing stars at each other. The tutorial also has a couple of handy tilemaps and sprite sheets for the new demo characters, simplifying the process of identifying which frames you need to use for running/attacking/dying, and setting up some basic logic for Mario Bros-style inertial physics.
Once bitten, twice shy
A quick check to the github tells me that Flixel was updated again. Seifer Tim's tutorial is already out of date, because Flixel is now at 1.48! Thankfully, the changes are minor, and don't appear to affect Tim's instructions for steps I through IV. I check out my project in Perforce and start to edit my old code.
When it comes to editing the level, however, there's one problem: Tim's tutorial points me at Mappy, which is a Windows-based tile editor. It looks great, but I'm on a Mac! Also, no one seems to have uploaded any examples of what a Flixel map file actually looks like, so I can't even use a text editor to start creating it instead. A quick search through the Flixel forums yields Flan, which is a Flixel-specific, square grid editor. It's more complex than I expected -- Flan has a button for each function, so there are a LOT of buttons, hidden between different screens of options. It employs a Photoshop-like concept of "layers" of tilemaps, based on Flixel's own FlxLayer abstraction. So I create a new layer, try to set it to 40x30 as Tim's tutorial recommends, but the new map size never seems to take. Turns out that there's an "Apply Changes" button at the bottom of the Layer options window, but you've got to resize the window to see it.
Eventually, I figure out how to import Tim's demo tile images, draw out a map, and export it as a CSV. Flan auto-generates a filename and creates a CSV file with the following data:
... etc. This goes on for a while. That's my map! And now you know what a Flixel map looks like.
Retyping Tim's code line by line, I realize that it prescribes a fairly large chunk of coding before I'll be able to compile and see any results. This is a little scary; I like to verify that my code is compiler-clean as often as possible, and generating a class that doesn't get used until I significantly edit another class is like walking blindfolded. However, once I've typed in enough, my little ninja appears on screen! I can even steer him a little before he drops off into nothingness.
Where's the level?
I pull out a line of code from Saltsman's old tutorial to throw the string on screen, and nothing shows up. I try to poke around the code that embeds map.txt in the game, learning a bit about taking a class loaded as an octet-stream and turning it into a string, but something very weird starts to happen with Flex. It begins insisting that I hadn't closed a brace, but I squint and squint and can't find where that missing brace would go. Recopying and pasting Tim's code from the wiki into my project solves that problem. (Shrug)
Now the 1's and 0's are showing up on my screen, and I can turn the text-drawing routine off. The map is still nowhere to be found, and my ninja still falls off the screen. Wondering if my Player class might be at fault, I turn off gravity for a moment. That stops the ninja falling, and now he can jump up. A few jumps and I realize that I was starting the ninja far too low! The map was there all the time, but Tim's code kept spawning the ninja several screenfuls below the map and automatically centering the camera on the ninja instead of the map. Tweaking the spawn point puts the ninja inside the map instead, and it works!
Other than struggling a little bit with Perforce, the rest comes pretty easy. My hastily-drawn map turns out to be quite an obstacle course for Tim's default character-moving routines, which seem a little pokey for a ninja. So I double the acceleration, add a routine so that it quadruples dedeceleration, so the ninja can take off like a Ferrari but pivot on a dime. The map is still a challenge, but not frustratingly so.
Now my ninja has a world to run and jump in, but no way to die. Next step: Enemies.
As a huge fan of Canabalt, the giant "F" that shows up at the beginning of the game repeatedly reminds me about the existence of Adam Saltsman's (a.k.a. "Adam Atomic") Flixel. Flixel is Saltsman's game engine that powers the spritely, blitty, pixelly goodness behind Adam Atomic and Danny B's masterpiece of one-button parkour. I'm using "game engine" loosely; Flixel is better described as a collection of ActionScript 3 classes. However, the combination of all those classes aims to give a game programmer the ability to create 2D games very quickly, with some long-standard features like volume control, framerate meter, and game pausing available by default. It's also optimized for a certain type of 2D game currently popular among the indie game scene... chunky pixels, lots of filmstripped sprites, rectangular collision boxes.
The Flixel download is just a zip file with an MIT license and uncompiled ActionScript 3 files. This suggests that if Saltsman's code does something you need done differently, you really could just go into the source and change it, which is comforting. I'm using Flex 3, Adobe's IDE and compiler for ActionScript projects, although you can apparently use FlashDevelop or mxmlc instead. I'm hoping to move my experiments to an automated build machine in the near future, so finding that the Flixel wiki features well-written tutorials on how to get started on all of these environments is a huge bonus.
One trick is that all the tutorials in the Wiki appear to be written by different people. This means that the tutorials all feature subtly different coding styles. Some aggressively choose to import all of Flixel's classes, fit the Actionscript files into a larger file structure, and override his methods by default. Saltsman's own step-by-step instructions takes a more conservative, change-only-what-needs-changing approach to Flixel, seemingly happy with many of the default behaviors in his base engine. It's nice to have different approaches to the same problem, but it takes a little effort to identify functional differences in the code examples that could produce different behavior, and purely stylistic deviations that work fine either way.
Figuring out how I should organize the Flixel files with respect to my own source files takes me the most time. Every tutorial has a different recommendation... some suggest creating a "com" directory for your source files and Flixel in an "org" directory inside "com". Some prefer to use the Flex Builder default of putting your project and Flixel as equal partners in your Documents folder. Knowing that I'm going to check everything into Perforce as soon as I get a clean build, I want it in my local Perforce workspace directory tree instead. I finally find a solution that I'm happy with: A HelloWorld project directory (created by Flex) next to a flixel directory, which holds the contents of the full Flixel download, complete with license text. (Note: This does create two nested directories called "flixel": e.g. [workspace tree]/flixel/org/flixel/data/FlxAnim.as) This should make it really easy for me to update Flixel when Adam releases new versions.
Two hours in and I'm switching game states, throwing text on the screen to tell me whether it's working. Part of my slow progress is due to the fact that I'm pretty much new to AS3; I had only worked with AS2 in the past, so I'm learning as I go. The Flixel wiki directs me to other sites that provide beginners' introductions to AS3, but I feel relatively confident in my ability to pick it up from the Flixel examples alone. (And what I can't figure out, I can ask Drew!) The other reason for the slowdown is that I'm insisting on typing everything in, without copying-and-pasting code from the tutorials. I feel I might miss a nuance or important step that I may have to repeat in the future.
I'm noticing that many of the Flixel tutorials (I should really just stick to one!) refer to older versions of Flixel. Screenshots of sample output look subtly different from mine, hinting that Flixel is actually a rather mature batch of code. It puts a little speedbump in reusing sample code, but it does boost my confidence in Flixel's robustness. Saltsman has tested, tweaked, and found better ways of doing things since its early days. For the record, I'm using version 1.45.
In fact, some tutorials describe getting the Flixel files by pulling it out of the file hierarchy of mode, the sample Flixel game that showcases many of Flixel's features and Saltsman's monochromatic pixel art stylings. It's a pretty ruthless game... like Bangai-O without the offensive capability. (Hmm, adding self-guided missiles or bouncing projectiles to mode seems like a decent weekend project.)
mode ate up quite a bit of time, though, so I'm wrapping up my initial exploration into Flixel after two hours and checking everything into Perforce. I've succeeded in making a Hello World that kills the player. Now to give the player a chance.
Western Otaku: Games Crossing Cultures by Mia Consalvo
If you missed Mia's fine lecture two weeks ago, the full video of it is now on TechTV. Gene compressed it as an m4v file for iPod and iPhone so you can take it with you!
From Nintendo's first Famicom system, Japanese consoles and videogames have played a central role in the development and expansion of the digital game industry. Players globally have consumed and enjoyed Japanese games for many reasons, and in a variety of contexts. This study examines one particular subset of videogame players, for whom the consumption of Japanese videogames in particular is of great value, in addition to their related activities consuming anime and manga from Japan. Through in-depth interviews with such players, this study investigates how transnational fandom operates in the realm of videogame culture, and how a particular group of videogame players interprets their gameplay experience in terms of a global, if hybrid, industry.
Mia Consalvo is visiting associate professor in the Comparative Media Studies program at MIT. She is the author of Cheating: Gaining Advantage in Videogames and is co-editor of the forthcoming Blackwell Handbook of Internet Studies.
One nice thing about using mostly c# for development is that reading in input files is reeeeeaaally simple. It's just your basic file reader and parser.
Right now my main scene gives my Level_Importer a file name, and Level_Importer returns an ArrayList of the objects in the scene (only walls for right now, I don't think that the levels store enemy information).
So now my characters can run around real levels... if I could only get my main character to move. I'm using my old Lizardman guy right now to move until I can get some help with Maya.
Posted by Caryn Krakauer on December 4, 2009 3:00 PM
|Permalink
December 4, 2009 3:00 PM
Dream Prototype - OCD Shopping Carts
How would a person's profession, interests, and hobbies manifest themselves within dreams? How does this work with dream logic?
This is the idea behind the prototype I'm working on for Clara. I wanted to think of something that a person working at a supermarket could possibly experience that would give them nightmares. How about terrifying shopping carts that act suspiciously similar to the friendly creatures in Alfred Hitchcock's The Birds? The prototype itself is laid out so that the player can see the entire parking lot, free spaces, and obstacles as well as the carts. The core verbs for this will be "run" and "throw" since your only defense against the carts will be taffy (my highly researched guess as to what shopping carts fear).
Initially, I imagined the carts moving similar to birds in real time. Not necessarily in a "v" formation, but in some kind of grouping where the carts can break off and "dive-bomb" the player, all while remaining on the ground. If the cart gets within range, the player will have to retaliate at the proper time or receive damage. To keep the game interesting, the carts would eventually encircle the player and they would have to break through the formation by attacking more than one shopping cart.
However, after thinking about this set-up for a while, I decided to go with something slightly different for the actual prototype. Instead, the shopping carts will only move or change position if the character turns around. I imagined the character having an irresistible urge to look back as they walk. Every time that happens, the carts rearrange themselves so that they are within attacking range of the player. I tested this with Clara in the very early stages of this and many problems were brought up. For one it was too easy to just use the taffy to get rid of the carts. I didn't think of creating grids on the board, so player movement was not clearly defined. Also, the game seemed to deviate from what Clara originally requested. The idea seemed interesting, but execution gets a 3/10.
Now I am back to the drawing board and am trying to a new approach. Clara suggested looking at this through the mind of the character and trying to inject their personality/interests/etc. into the actual game. Maybe the character arranges carts at the supermarket constantly and suffers from OCD as well. How can I communicate that through not just a narrative, but also through the game mechanics? What would be the best way to combine the character's personality, mostly their OCD, with pattern recognition? Hopefully I can find a concrete, interesting way to implement all of this for the next prototype.
Posted by Bianca Farrell on December 4, 2009 3:00 PM
|Permalink
December 4, 2009 9:30 AM
More on Word Puzzles
Earlier this week (or possibly last week, depending on when this post goes up), Genevieve posted a blog entry about creating a word game for the Sophocles team. As she noted in her post, our group of 4 split into two teams of 2 to work on different concepts. I was in the group that did not contain Genevieve, so I thought perhaps I'd write a bit about the idea that our half of the team came up with.
Our prototype, like that of Genevieve's group, required the player to use words to form a bridge in order to cross a gap. It's not a coincidence that both groups prototyped games involving bridges; the idea of building a bridge out of words or parts of words was discussed in the brainstorming that we did before splitting into two groups. However, as with the dog-and-girl prototyping at the beginning of the semester, the two prototypes managed to be quite different while still adhering to the same basic concepts of words and bridges.
The thought process that resulted in our group's game went something like this: "What is unique about words; what are their defining characteristics? ...Well, words are made up of a limited set of smaller individual components (letters), which can be arranged to form larger entities. But the other group is already exploring that aspect of words... But words also have meanings associated with them and enable people to communicate. Could you make a game that explores words and meaning?"
...and I think that's how we ended up with a game where you have to translate a stream of gibberish from a guy standing on the other side of a ravine and wearing a weird hat (he wears a weird hat because we needed a way to differentiate the player from the crazy gibberish-speaker in sketches of possible game layouts, and giving the crazy guy a crazy hat was an easy way to do that).
Specifically, our team created a game where you (or rather, your avatar) and an NPC are standing on opposite sides of a ravine, and he starts telling you a story, sentence by sentence. However, some of the words he chooses to use are unfamiliar, and you must translate them. For example, he might say, "The other day I was walking down the sidewalk and I found a baby bird that had fallen out of its gleeble." In this case, context would hopefully lead the player to conclude that 'gleeble' means 'nest'. Then the man might say, "The gleeble was at the very top of a tall bloggin," and the player would have to deduce that 'bloggin' means tree.
The man would then continue to tell you his story, and every sentence would contain a higher proportion of nonsense words. The trick is that all but one or two of the nonsense words in each sentence would be ones that you'd encountered in previous sentences. So maybe he'd say, "And then a bloggin furpled on my klonker, so now I have to vob in a swippy in the glopp," and the player would remember from previous sentences that bloggin = tree, klonker = house, vob = live, swippy = hole, and glopp = ground, and so would be able to guess that "furpled" means "fell", and what the man is actually saying is "And then a tree fell on my house, so now I have to live in a hole in the ground."
Then, once the man has finished telling you his story and you've learned all his weird words, objects start to appear in the ravine that separates you and the man, and as you speak the words for those objects, the words appear in the air and form a bridge to the other side.
Posted by Alexis Brownell on December 4, 2009 9:30 AM
|Permalink
December 3, 2009 9:30 AM
Dream Sequence, Pt. II
Dream logic is a distinct entity from the rational thinking we encounter in everyday life. For our most recent project, the prototyping team explored the prototypical dream experience in order to exploit this unique thinking for a dream-based game.
When we last left off, I had just introduced our nameless super market clerk, a poor boy stuck in a nightmarish world where customers speak in gibberish and the aisles sob with loneliness. We wanted to be able to implement some of the more abstract concepts into playable mechanics. One of the things we had discussed in length was the role of objects in dreams. Nouns often appear in place of complex ideas. Often, people have reoccurring nightmares about their teeth falling from their face. This is generally interpreted as a manifestation for anxiety or worries in the dreamer's mind.
BACKGROUND
To examine this idea, we came up with a fairly straightforward scenario. The set up: the customers have run into each other, spilling the contents of their bags every which way. You, the clerk, must return the proper items to each customer, but which items belong where? The player is cued to the customer's 'theme' by the objects that are still left in the bag (a horseshoe and a rabbit's foot, for example). Once the player determines the relationship between these items (they represent 'luck'), they can easily identify the final element that lies amongst distracter items on the floor (a four-leaf clover).
Here are some early combinations we proposed:
- Horse Shoe, Rabbit's Foot -> Are Lucky -> 4-Leaf clover
- Slugs, Butter -> Are Slippery -> Soap
- Pita bread, Pants -> Have pockets -> Kangaroo
- Donuts, Swiss Cheese -> Have holes -> A tire
- Balloons, Ice -> Do Float -> A rubber ducky
- Mentos + Coke, Baking Powder + Vinegar -> Do Explode -> Dynamite
- Donuts, Swiss Cheese -> Holy -> A cross
- Honey, Bubble gum -> Stick-y -> A stick
- A Door, A Can -> Things you open -> Your mind
- A Train, An Orchestra -> Things you conduct -> Electricity
It's important to mention a couple of things about the grouping here. I've mapped them here to 'Are', 'Have', 'Do', Wordplay, and Abstract Wordplay. Only the first category is truly representative of dream logic. Here, items are characterized as prototypically lucky or slippery. The second group is classified by properties- kangaroos, pants, and pita all have pockets. The third group is based on word play. Donuts are 'hole-y' and a cross is 'holy'. The final group is based on more abstract wordplay. You can open up a door, a can, or your mind. These groups are purposefully ordered by difficulty-level as prototypical traits are necessarily more readily identifiable than abstract associations.
IMPLEMENTATION
Each item was represented on a game board with two sides: one for items in the bag and one for items on the floor (See Figure 1). Each 'target' item on the floor was mixed in with two 'distracter' items. The player was only given one guess in order to avoid random guessing. Because of my impeccable artistic skills, players were allowed to ask about the identity of the objects. This became important particularly for some ambiguously drawn items. A bag of ice (what I drew) does not necessarily cue 'floating' as well as a single ice cube (what was intended). Figure 1. Implementation of the 'Objects-as-Metaphors' Mechanic. (Top) The player was given a pair of pants and a bag of pita on the left hand side. From this, the player was expected to deduce the relationship of 'has pockets' to items in the bag. The player could then apply this expectation to the right-hand side of the board to pick out the 'has pockets' object, the kangaroo. (Bottom) The player was given a bottle of honey and a piece of bubble gum. The player was expected to deduce a relationship of 'is sticky'. From this, the player could identify the stick as itself 'stick-y'. This argument required the use of word-play, which was not accepted by some players as consistent with dream logic.
RESULTS
Test players performed much better on characterization tasks involving 'is' or 'has' than 'does'. For instance, the 'has pockets' condition was immediately identified by all testers. Neither of the testers were able to identify the ice and balloon as 'do float'. There are a couple of potential reasons for this. I already discussed the first possibility, that I am not much of an artist. This was more or less compensated for by a re-drawing of the ice so that it was not contained in the bag (which confounded the first trial, wherein the player focused on the bag as a container for ice and the balloon as a container for air) and by allowing testers to ask questions. Interestingly, both testers also identified the objects in this trial as belonging to a 'set', wherein one object is similar to the other in some ways, but different in a particular other way and thus the third object should follow this pattern. For instance, one tester identified the balloon as containing a gas, the bag of ice as containing a solid, and guessed the distracter item, vinegar, as the item belonging to the bag because it contained a liquid. This was a valid guess (though not the one we were looking for) and should be considered for future design. This also raised the issue of object selection for the distracters. Our secondary tester grouped the balloon and ice with a top hat, because all three belonged at a party (also a valid conclusion). One tester also rejected the logic behind the word puzzles because he doesn't "dream in homonyms" (again, a valid point).
Regardless of logistical implementation issues, we determined this prototype was not necessarily the direction we wanted to proceed in with the dream-based game. The logic, while intriguing, did not lend itself to a story and did not directly involve the personality of the supermarket clerk. While the use of metaphor was acknowledged as relevant for future prototypes, it was determined that the mechanic could be put to better use in an adventure-game type setting than on its own. Furthermore, it was stressed that we should be taking a deeper look at the goals, desires, and motivations of the individual dreaming the dream, a notion to which this prototype did not lend itself.
Posted by Genevieve Conley on December 3, 2009 9:30 AM
|Permalink
December 2, 2009 3:00 PM
Dream Sequence, Pt. I
Dream logic is a distinct entity from the rational thinking we encounter in everyday life. For our most recent project, the prototyping team has begun exploring the prototypical dream experience in order to exploit this unique thinking for a dream-based game.
A brainstorm session revealed some key highlights about dream thinking:
- Concepts can be at once more clear and more obscure
- Commonplace actions become extraordinarily difficult, while extraordinary actions become trivial
• Riding a horse may be intuitive to the dreamer, though they have never seen one in real life. Brushing one's teeth, however, may become impossible.
- Space and time are easily obscured in dreams
• This was compared to the forest maze found in many RPG's, or the cave maze in Monkey Island, where only one pattern will correspond to a feasible mapping of space
From here, we began to construct individuals who may generate interesting scapes for our dream logic to be applied. A stressed student might dream about a code that comes alive, where literal bugs crawl out of the screen. A shy child might dream about a forest of legs, where the only escape lies in tapping each knee with a lollipop to see through the thicket. A pizza delivery boy/ quarterback might dream of a row of angry houses, each one attempting to gobble him up. Only by throwing the toppings into the house's mouths can the boy hope to survive.
We settled initially on the idea of the supermarket clerk who dreads every day of work. Everyday tasks become impossible for the boy as he moves his way though the aisles. While restocking, the items move around behind his back. Customers speak gibberish and run into each other, scattering their items across the floor. Without a common language, he must decipher the commonalities between the items in the customer's bag and the items on the floor in order to return the items to the proper owners. But in the bags, he finds absurd objects-- 2-day old shrimp, tires, sticks, and turtles. The aisles all whine about their problems. One is lonely, another is on fire. How can he help them? The greeting cards begin to shout at him as he rushes down the aisles. Only if he puts them in order will they cease to chatter. Finally, outside, he believes he's reached an escape. Alas, the shopping carts gather and stare at him, as if a pack of ravenous crows. He must return inside in order to survive.
Stay tuned for part II, where I'll talk about the implementation of some of these ideas into early paper prototypes.
Posted by Genevieve Conley on December 2, 2009 3:00 PM
|Permalink
December 2, 2009 9:00 AM
Maya Issues
Currently I am trying to import the maya assets from Abandon into Visual3D. This doesn't seem to be a complicated process at all, except for the fact that I have no idea what I am doing. Any artist would be able to figure this out, but I'm completely lost trying to navigate around Maya. I think that I need to export the mesh with the animations into Orge format, but I can't seem to get the animations to go with the mesh and skeleton.
I need the animations so that my character will move (it doesn't move without an animation for some reason).
If I got that working, the game would actually look pretty similar to abandon. The only things I would need to add would be enemy behavior (which may be complicated) and a way to import levels with text files (which should be pretty easy). After that, it's just a few tweaks until the level looks pretty close to the original game.
Posted by Caryn Krakauer on December 2, 2009 9:00 AM
|Permalink
December 1, 2009 1:00 PM
Unexpected Difficulties in Design
One of the biggest obstacles we've encountered so far is agreeing on how to spend our time. Level of detail is a big issue. Since we are working for only a short time on a game, we'd like to stay more or less on the 'big picture' level. However, in order to really discuss a game idea, you have to look at some of the details or else you are ignoring what makes the game unique.
At one point, we began making a spreadsheet of all the unique objects in our prototype game. The point was to be able to deduce a general nomenclature or way of speaking about how the objects interacted on the player's goals. This seemed unnecessary in a lot of ways because it meant spending a lot of time sitting around talking about what the cat 'might' do in any given situation. Since we didn't have the cat in front of us, it was rather easy to neglect certain ways in which the cat could interact with the object (it could come from behind, it could approach it diagonally, etc.) Furthermore, when we did identify a tricky situation, our solutions were primarily artificial. They were created in vitro, if you will, away from the living creature. They would not necessarily make sense in game or to the player.
This gave way to an overall sense of urgency just to 'play' and figure out what would happen from there. Play-testing was a great way to identify the gaps in our thinking. From our play-throughs, we were able to better organize our thinking. On the other hand, play-testing meant we were much more likely to get hung up on details. If we wanted to make a functional prototype, we needed to have a very narrowly defined set of rules that were consistent across all play times. This meant sacrificing a good deal of creativity and invention. We had to allocate all of our time during this period to making one singular idea work. Even though we had many different ideas of how to approach the general concept, we were forced to focus on the details of this one idea. This led to a good deal of frustration and perhaps a more narrow mindset then was appropriate for such an early stage of design.
Obviously, this can be somewhat compensated for by splitting the group and working on multiple conceptual ideas at once. However, this does not totally address the issue, since the actual prototyping stage still limits the freedom of the designer. I think the main lesson learned is that there is an overall role for both of these processes (the creative, free-flow, no-limitation of verbal analysis and the more constrained, practical approach of play testing). The important thing for the team will be to balance creativity with practicality. Similarly, we will need to be able to problem solve any major flaws in our design, while avoiding getting too caught up in the details.
Posted by Genevieve Conley on December 1, 2009 1:00 PM
|Permalink
December 1, 2009 9:00 AM
The case of the haunted game model
Even now, when I'm more or less familiar with Unity, I occasionally make dumb little mistakes. For one thing, I keep forgetting that any settings that I change in Play mode will reset themselves when Play mode is turned off. Today, I've been reminded once again to be very careful when selecting a Unity object by clicking on the object directly.
I first discovered the problem when my avatar began bumping up against an invisible object. I thought at first it might be a wall I couldn't see from this angle, since planes in Unity are only visible from one side, but there didn't seem to be a wall anywhere nearby.
I moved the avatar around some more and discovered another spot where it behaved oddly, this time climbing on top of a phantom object. About then, I remembered that there had previously been an object on that spot which the avatar had climbed on top of when I moved it there. Was my scene being haunted by the ghosts of objects past?
A little investigation turned up the problem. Earlier, I had indicated some objects I wanted to move by clicking on them directly, rather than selecting them in the hierarchy. As a result, in each case I had actually moved one of the children of the object, not the object itself. The part I moved contained the mesh renderer and all the visual components, so it looked as if I had moved the whole thing, but I had actually left the collider and all the physics components behind--hence the phantom barrier my avatar had encountered.
Here's a picture of my avatar with the phantom bathtub:
The silver lining is that this incident led me indirectly to the solution to a different problem: it explained why the chasers hadn't been turning black when the script told them to. Because the visual components were in the child object, I should have told the child to turn the object black, rather than adding a renderer to the parent. Now if I can just make that work in a script...
Posted by Naomi Hinchen on December 1, 2009 9:00 AM
|Permalink
November 30, 2009 4:06 AM
A game with one button, no visuals?
Marleigh Norton came to our prototyping group with a daring concept for a game: no visuals, only audio. Only one button. And it's a conversation game. How?
Every time you press the button, you interrupt the person speaking to you with an interjection. The nature of your interjection varies based on when in the sentence you interrupt. Press the button early in a sentence, and you're likely to blurt out a rude interruption. Press it late, and you might say something more thoughtful.
So how to prototype this? We all came up with our own prototype (divide and conquer!). I figured that it would be easiest to have the player be faced with a ranting character. This way, if the player didn't say anything, the character would just keep on talking. Also, rants are filled with short declarations and rhetorical questions, which provide loads of natural interjection points. For my prototype, the player is conversing with a friend whose marriage is breaking down. Depending on how to player chooses to interject, the friend might be comforted, annoyed, or discover that the player is in fact having an affair with his wife.
Crude written prototype of the dialogue game, with cards showing which phrase to proceed to based on when the player interjects
Each line of dialogue has several interjection points. If the player chooses to interject, the interjection corresponding to the next interjection point will be read. This will then lead to a different piece of dialogue being spoken in response. This process repeats until the player has ended the conversation, usually by angering or comforting his friend.
Posted by Jeremy Rossmann on November 30, 2009 4:06 AM
|Permalink
November 23, 2009 9:30 AM
Cat Movement (Scaring Cats)
We had several problems arise while working on our Scaring Cats idea. We tried to begin simply by looking at the movement of the cat through an obstacle course. By then, we had already generated a number of objects that the cat could interact with (a bag would attract the cat and cause the cat to slide across the floor, a hairdryer would scare the cat away, etc.) We wanted to be able to model the cat's interaction with both the objects and the player (a dog who could scare the cat in certain directions) in real time. We attempted to do so by using a grid-based game space and allowing the players to alternate movements (as if in a turn-based game). We were forced to decide how fast the cat and dog could move. The cat, we decided, could move at one of three speeds (1 square/ turn, 2 squares, 3 squares) and the dog could only move at the cat's medium speed at the fastest (2 squares). We set up several play-throughs to test this motion, wherein one team member set up an obstacle course (with the goal that the cat would move from point A to B simply by influence from the objects attractiveness/ repellent power) and the others moved the cat and dog. We quickly discovered that we had not defined the cat's interaction with the objects closely enough. Here's an overview of what we found:
The problem with our current play-testing is that there are too many variables that determine whether the cat interacts with the object:
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'
Posted by Genevieve Conley on November 23, 2009 9:30 AM
|Permalink
November 20, 2009 9:30 AM
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 2: 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.
Posted by Genevieve Conley on November 20, 2009 9:30 AM
|Permalink
November 18, 2009 10:16 AM
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).
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
Final Board
Posted by Genevieve Conley on November 18, 2009 10:16 AM
|Permalink
November 17, 2009 1:50 PM
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).
Posted by Alexis Brownell on November 17, 2009 1:50 PM
|Permalink
November 4, 2009 4:26 PM
Meet the new bug, same as the old bug
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.
Posted by Naomi Hinchen on November 4, 2009 4:26 PM
|Permalink
October 28, 2009 6:18 PM
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!
Solution:
Creating the object:
// These two lines are the ones I used instead of halo = new Halo()
// and halo.Spatial.RelativePosition = new Vector3(-10f, 0f, 20f)
halo = (Halo)SEntitySystem.Create("halo", "Halo", new Vector3(-10f, 0f, 20f));
halo.Enter += new IntersectEventHandler(HaloEnter);
halo.Name = "halo";
this.Spatial.AddChild(halo); // Adds the object to the scene
halo.Enter += new IntersectEventHandler(HaloEnter); // Adds the trigger event
halo.IsFlagActive = true;
halo.IsVisible = true;
The other changes I had to make:
add the line:
this.EntityFlags.Perceptible = true;
to the OnActivated() function of my main character's class.
Also,
right click on the entities folder of the Asset Library in the main architect. The context menu that pops up has "Add Custom Type". Select that and add Halo as a new type.
Posted by Caryn Krakauer on October 28, 2009 6:18 PM
|Permalink
October 28, 2009 5:19 PM
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.
Posted by Naomi Hinchen on October 28, 2009 5:19 PM
|Permalink
October 26, 2009 2:02 PM
Translating NPC Drives to Behaviors (Weise Zombie Project)
Last time I talked about the three basic behaviors any NPC might undertake on its own--seek out resources, find a place to hide, or fight zombies. I also mentioned we had come up with a variety of personal character traits for any NPC that might affect their desire to undertake any of these three actions.
Progressing onward, we wanted to look at how specific situations (like those that could conceivably arise within game-play) might alter these characteristics and, thus, the NPCs behavior.
Let's begin our exploration with a few examples using the basic drives of an NPC, as discussed in the last post.
Lack of resources
In an extreme case, the lack of basic resources will cause an NPC to lose the will to survive (extreme drop in S -> loss of interest in all activities. Similarly, this may cause severe irrationality in the NPC. 'Irrationality' itself is a vague term, so we go further to define what this might mean for an NPC.
An NPC may have greater will to fight (engage danger, D) at the expense of other life or gaining the resources they need
It may be less likely to follow orders, even if it 'likes' or 'trusts' another player
It may lose interest in others and wander on its own or fail to follow the group (G)
Mental/ Physical Ailments
Any physical or mental shock will obviously affect stamina. These afflictions may decrease an NPC's likelihood to join group (may not be 'up for it'). It may increase an NPC's willing to sacrifice itself for the group. Specific ailments (like diabetes) may increase the NPC's demand for resources.
Higher Level Needs
Unsurprisingly, higher level needs (Social, self-actualization, etc) tended to generate more complex behaviors in our own imaginations.
For instance, if an NPC was predisposed to disliking a character of type 'B', the NPC...
Will distrust characters of this type
Is less likely to save type B's from danger
Is not likely to follow type B's
Has a higher likelihood of setting type B's up/ sacrificing them
May lie to type B's
May withhold resources from type B
Similarly, if Sarah loves Joe and Sarah is killed, Joe might
Lose the will to live
Stop all actions
Hate another character for not doing anything
Seek revenge (zombies, character)
Lose trust for another character
Sacrifice himself
Save her at cost of others
Stop Zombie Sarah at all costs
Try to recover Zombie Sarah to rehabilitate her (impossible)
Become obsessed with other distraction (coping mechanism)
Posted by Genevieve Conley on October 26, 2009 2:02 PM
|Permalink
October 26, 2009 1:51 PM
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.
Safety/ Security: Protection in numbers, protection from specific group members (leader), hiding place/ safe house
Social needs: Companionship (See mental health), friends, family (Love), trust, 'Us vs Them' (families, class, race, religion)
We worked backward from Matt's description of the game and our brainstormed character needs to come up with three basic 'behavioral desires': searching for resources (like food and water), seeking shelter (either hiding places or safe houses), or fighting
An NPC will prioritize these behaviors based on a variety of internal characteristics (which can be affected by their temporary emotional state). For example:
Brashness: An NPC has some innate predisposition to engage danger (D)
- A low D means the NPC will avoid fighting at all costs
- A high D means the NPC will actively seek out fighting
Stamina: NPCs have some innate drive
- A high S means the NPC will easily undertake the action they desire most
- A low S means the desire to undertake any behavior falls, leaving the NPC fairly inactive/ unlikely to undertake any behavior
Dependence/ Independence: NPCs have some innate predisposition to group up (G)
- A high G means the NPC will closely follow other NPCs/ the player
- A low G means the NPC will not likely follow other characters and may wander off on its own if already in a group
The player may influence an NPC's goals by 'ordering' them to do one of the three basic behaviors
- The likelihood that an NPC will alter its behavior based on the player's commands depends on some internal characteristic trait 'O'
Together these traits and basic desires govern the more complex behaviors NPCs will undertake throughout the game.
Posted by Genevieve Conley on October 26, 2009 1:51 PM
|Permalink
October 22, 2009 6:11 PM
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.
Posted by Caryn Krakauer on October 22, 2009 6:11 PM
|Permalink
October 21, 2009 1:00 PM
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.
Posted by Jeremy Rossmann on October 21, 2009 1:00 PM
|Permalink
October 21, 2009 12:35 PM
More Zombies
Matt Weise came to our prototyping group asking us to come up with ideas for a game he wants to develop. A game about ...? Zombies of course.
The main idea: you define a set of behaviours for zombies. You define a set of behaviours from humans. You drop humans and zombies in a virtual town. Hopefully interesting and believable interactions emerge between humans and zombies.
Zombies are easy to figure out. Humans, not so much. The zombie setting serves to drastically limit the range of possible human behaviours that we need to consider (no one takes time to work out, play piano, go to the museum, walk in the park, etc... in a zombie apocalypse). What's left are relationships between people (A loves B, so he will do stupid things to try and save B), information about your surroundings(there's a safe house over there? I'm going to tell my friends and we'll go hole up in there!), and information about what you can do (If I put gasoline, bacon grease, and motor oil in this bottle, stick an oily rag in it, call it a molotov cocktail, light it, and chuck it, zombies die? Sweet! I'm going to tell my friends!)
The challenge is defining a manageable set relationships and information that characters can have, and then model the spread of information from human to human and a believable set of behaviors that stem from relationships between humans. We'll see what we come up with.
Posted by Jeremy Rossmann on October 21, 2009 12:35 PM
|Permalink
October 19, 2009 4:06 PM
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);
Posted by Naomi Hinchen on October 19, 2009 4:06 PM
|Permalink
October 14, 2009 6:21 PM
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 zombie infestations rage infections always have to happen in the late 20th early 21st century?
Another idea - you have to fight off progressively more absurd procedurally generated apocalypses. Maybe tower defense style, maybe first person.
First it's rats. Then zombie rats. Then bears. Then zombie rat-bears. Then sharks. Then ninja sharks. Then zombie ninja shark-rats. And eventually unicycle riding zombie ninja bears with marshmallow guns. And so on.
And here's one that's been bothering me. I think it would be cool if there was a game such that for every three levels you played, you created a level, which was then used to populate other player's games with levels. The better you play through levels, the more points you earn to create more elaborate levels. The more you play, the more you get fed more elaborate levels. The concept is fine - but what kind of game fits into that concept? Maybe you have a bank of creatures. They have different costs and the amount of points you have is limited. Any creature you create starts at point A and you have to destroy something at point B. Between A and B there are obstacles that block and harm you. You must create the right types of creatures and guide them to circumvent/destroy these obstacles and eventually destroy point B. But this doesn't give any sort of compelling game to play when you have to create a level. Placing obstacles doesn't leave that much room for creativity. I need to think about this one more...
Posted by Jeremy Rossmann on October 14, 2009 6:21 PM
|Permalink
October 14, 2009 3:06 PM
More on Unity3d
Still wading through the Unity documentation. Today's project: incorporating keyboard input. Finding the relevant pages in the Unity documentation was fairly easy; I searched for "key" and found KeyCode, which led me to the Event class. However, it took a while for me to figure out how to use the Event class because the relevant pages did not provide any sample code. I tried using Event objects in the Update function and kept getting errors. Eventually I figured out that whenever an event occurs, the script runs the OnGUI function, so I had to access the event from there. Example:
// If a keyboard event occurs, print the key pressed
void OnGUI(){
if (Event.current.isKey){
KeyCode k = Event.current.keyCode;
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.
Posted by Naomi Hinchen on October 14, 2009 3:06 PM
|Permalink
October 13, 2009 6:13 PM
Collisions!
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.
Posted by Caryn Krakauer on October 13, 2009 6:13 PM
|Permalink
October 7, 2009 5:28 PM
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:
Documentation
The tutorials and documentation for Visual3d are frustrating and incomplete. There are two situations when trying to use it:
1. A tutorial exists, but it is too old to be useful. Apparently Visual3d just released a new beta making all of their old stuff not very useful. Also, most tutorials that exist are focused around using the GUI rather than the coding behind it.
2. A tutorial will be coming "soon". Usually, these say things like "Coming in September 2008!" or something like that.
Community
The Visual3d community is very good however. I posted a question about terrain and had it answered quickly and well. The person who answered is very involved in Visual3d, so there are some good experts who are willing to help you with even beginner problems.
Some of the help is useless. Someone will ask "is it possible to do this?" and will get the answer "yes" by someone without any instructions or hints or anything. Usually someone else will come by though and give real help.
Good Idea
The best method I've found so far of figuring out what is going on is to look at the provided Tech Demos and see how they coded their scenes. This is the way I figured out how to do most of the things in my code.
What I need to do now:
- Make it so my main character can't run through the box.
- Make it so the character actually turns in the direction of travel rather than strafing.
Posted by Caryn Krakauer on October 7, 2009 5:28 PM
|Permalink
October 7, 2009 2:20 PM
Game engine survey!
The Game Engine Survey is a UROP project to test different game engines and evaluate the pros and cons of each. We will be working with Visual3d, Unity3d, and TorqueX.
I've been playing around with Unity recently. It seems like it has a lot of useful functions, but they're not always easy to find. The website's video tutorials are helpful, but they really just cover the basics, and sometimes leave out useful functions that the makers of the tutorial presumably took for granted. For example, in some of the videos, the scene view shows the environment from the same perspective as the game view--which it would be nice to know how to do, except that the tutorials don't seem to mention it. Also, the script documentation has at least one inaccuracy: they claim that the output from print statements appears at the top of the page, by the play/pause/step buttons, when in fact it appears at the bottom.
The script functionality seems fairly well-documented, once you get around the obstacle of writing in C# when the manual uses JavaScript. I'm still figuring out all the functions, so more on that later.
Posted by Naomi Hinchen on October 7, 2009 2:20 PM
|Permalink
September 8, 2009 9:00 AM
An Interview with Mia Consalvo
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
Spacewar! is game of space combat created for the DEC PDP-1 by hackers at MIT, including Steve "Slug" Russell, Martin "Shag" Graetz, Wayne Witaenem, Alan Kotok, Dan Edwards, Peter Samson and Graetz. You can play the game running on a Java emulator 
-thumb-175x218-1852.jpg)
