I recently finished my MFA in Parsons Design and Technology program. It's like a giant toybox. Love it.
In the summer of 2006, I got a sneak peek at the MFADT program by taking this month-long crash course. Made a lot of crazy stuff, met a ton of great people, and never slept a wink. Good times.
For my final project in Parsons D&T bootcamp, I created a site called fattofatto.org that was designed to promote the sport of bocce in New York City. I have a real love for the game, so this was a fun project, especially making mini-documentaries by interviewing other players and building a game based bocce's basic skills. Fatto!
This is the work that I did in the Parsons Communication Design and Technology Masters program during the autumn of 2006.
Theory with Sven. Really fun, wide range of assignments, and we get to make podcasts and other weird stuff! Check out some of my work so far:
The proprietors present this fine entertainment, being the podcast in which one Mr. Edwards expounds on noise, aural and digital, and how said noise ties together the coin toss, the credit card, and Guantanamo Bay. Humbly presented for your distinguished listening and with due thanks to the members of the freesound project who contributed samples of their efforts for the creation of this auditory presentation under the esteemed Creative Commons Sampling Plus license:
Attachment | Size |
---|---|
podcast1.ogg | 1.4 MB |
The proprietors extend a further invitation to the world of technology as surveyed by one its most humble practitioners as he confounds the assembled with tales of a truly dreary technology that nevertheless possesses the potential to improve the standard of living among this planet's poorest citizens. The producers are indebted once again to the members of the freesound project who contributed samples of their efforts for the creation of this auditory presentation under the esteemed Creative Commons Sampling Plus license:
Attachment | Size |
---|---|
podcast2.ogg | 1.73 MB |
In this class, we studied how people interact with the world around them. And we designed all manner of crazy things.
Our first assignment was to build three boxes with different materials or other properties. I made these three in stackable sizes and varying opacities.
Attachment | Size |
---|---|
dcam0863.jpg | 93.05 KB |
Then we had to make fifty boxes! I used a survey and a genetic algorithm over the course of four generations to determine which boxes came out on top.
Here's an earlier generation of the boxes project for interface class. Most of these were "killed" later by the genetic algorithm I used to generate more boxes.
This is a later generation of boxes. The losers are on the right. My genetic algorithm evaluated each box based on preferences I got from people in surveys. The genome of each box contained its color, size, opacity, and saturation. Clearly, the transparent ones were not the fittest. The red ones were quite successful, though.
Once I was finished with the boxes, the ones that never made the cut were crushed. Think of my foot as the Permian-Triassic extinction event.
This is the python script I used to determine the winners and losers among my box designs. Each box had a genome that encoded its color, saturation, size, and opacity. Boxes with more votes were allowed to mate. The rest were crushed. Circle of life.
Attachment | Size |
---|---|
box_gene.py.txt | 2.12 KB |
LargoCargo was a project that incorporated yet another box form to serve as a product for one of the worlds described in Einstein's Dreams. Ours were surprise boxes that children could collect and then smash in a "yearly" festival. The idea would be to disseminate propaganda among the young so they would never leave their parents in a world where time ran much, much slower than the rest of the world. Wacky stuff.
Above is our "Why/How" diagram that analyzed the situation in this fictional world and which led to our LargoCargo product.
This is a box cover Alan designed. The idea was to create images for kids showing what awaits them in the outside world if they should ever leave their parents. In the "slow" time-dilated world in which they lived, parents never wanted to let their kids go. Read Einstein's Dream, and that will make more sense--we had to design these for a world depicted in that book.
The LargoCargo project was our midterm for Major Studio: Interface. Here is our presentation.
This is a map of my commute. It measures noise, human movement, personal space, speed, and location in the course of my trip from home to Parsons.
There are my condensed observations of the PATH station near where I live. Beware of the hard-ass Port Authority Police Department -- they do NOT like you taking photos of the station. It does help to say you're from the neighborhood, though.
Hsinping Dai and I made a non-verbal dictionary for communicating about a subject in an elevator. That subject? What to do when somebody farts.
Elevator Dictionary 2
Elevator Dictionary 3
Hsinping and I made a visual dictionary for people on an elevator together to communicate with each other, dealing with a very delicate subject. See if you can guess what it is!
Attachment | Size |
---|---|
dictionary03.png | 102.91 KB |
dictionary02.png | 101.54 KB |
dictionary01.png | 212.17 KB |
I've long been an admirer of the Japanese renga, a collaborative poetic form. One of the major drawbacks, however, is trying to remember the rules. Each person participating must write a two- or three-line stanza using a pre-determined subject, usually a season of the year. In an autumn renga, shown here, the first writer begins with a three-line verse about autumn. The next writer completes a two-line verse about the moon, which is usually related to autumn.
The game board above really nicely condenses these rules. Even though this was just a simple assignment, it solved a long-standing problem for me. I'll most likely continue working on this project in the future. If you're curious about the form or this version of it, download the attached SVG below and print it out on nice paper. Included is a layer that holds the colored squares you can use to write the renga verses. I strongly recommend you use a size of paper bigger than 8.5 x 11, and I suggest you open it with the outstanding SVG editor, Inkscape.
For our final project, my group was required to select a location, identify two groups there, and get them to interact in anyway we chose. We picked the deli inside the Journal Square PATH station. It turned out to be an amazingly difficult but rewarding project.
Depicted above is one of our observation sheets. Every 10 minutes, during the course of over 20 hours observing, we noted which patrons sat where, their gender, their approximate age, and their activity at the table. In so doing, we collected a truly huge amount of data that allowed us to make predictions about who would sit where for the longest period and which demographic they would most likely represent.
Our first attempt to intervene in the Deli. Bingo! Like travel bingo, but with deli stuff.
Attached is the raw data from our deli observations. Over 600 entries. Never let it be said we aren't thorough.
Attachment | Size |
---|---|
delistats.xls | 193.5 KB |
"Lot pots." Left on tables in the deli to get people involved in their tables and with each other. Each pot has a set of fortunes that require you to interact with other tables. Weird looking, but fun.
The ultimate in deli interventions--the Restaurant Telegraph! Each half is place on a separate table. The switch lights up the lamp and sets off a sound. Cool, though much more fun in bars than in the Journal Square Deli, as it turned out.
Attached is the SVG file for the labels, in case anyone wants to repeat the experiment.
These are our presentations for the Journal Square deli project. They're huge downloads, but well worth it if you're fascinated by Jersey-City commuter dining. And, be honest, you know you are.
In all seriousness, this was a very challenging project and well worth the considerable effort. We learned a lot and built interesting things. What more could you ask for?
In this class, I learned a hell of a lot about electronics and physical computing. Now I can't stop busting things open to see what I can pull out of them. Keep a close eye on your peripherals when I'm around.
Some work:
For my midterm project, I hacked the sink in our 10th-floor bathroom.
The sink had an IR sensor with an exposed control box. I cracked that open, split off the power and sensor-data lines, and got it trigger a light show under the sink and play a sound sample from a speaker I attached under the porcelain. I left a record button hooked up to it, and, pretty soon, people were recording their own strange sounds and messages that would play every time someone went to wash their hands.
Attachment | Size |
---|---|
audiograffiti.ogg | 1.25 MB |
For our physical computing final, each pair of students had to complete a link in a chain reaction, receiving an input from the previous team and producing an output for the next team.
Here's our AC/DC-playing, silver-painted-goat-skull, black-polycarbonate dragon. Our only design consideration: Make It Metal!
Attachment | Size |
---|---|
dragon.ogg | 1.48 MB |
This is the goat skull that was part of the physical computing final project. Inside its sinuses is a halogen bulb hooked up to a relay. He really lit up the room!
Max/MSP (and it's open-source cousin PureData) are great ways to get multimedia applications up and running in no time. Plus, it's just a really fun class.
The following are the classes and other work I contributed to during the spring semester of 2007.
In this class, we'll be putting together a game from the brainstorming phase right up into a good prototype.
This is the game project I'm working on for the Casual Games class. It is tentatively entitled Phevo.
My project for this semester will be a game that is similar to battleship, but involves biological infection instead of artillery.
In Phevo, you have a board full of creatures, called phevos, that have a simple "genome." This genome expresses itself in the phevo's appearance. For example, phevos may have "genes" that code for the appearance of a red outer shape, and yellow inner shape, and several different geometric possibilities in their appearance.
The board you have is set up next to a board representing you opponents. There will be any where between 16 and 64 square on the board (the exact number will require user testing.)
To begin play, the user selects a phevo to attack the enemy. A regular phevo will be able to attack an enemy phevo with the same genotype. However, by spend more time (or resources, perhaps,) that phevo becomes more generalized. It may lose color or shape. This indicates that the phevo will be able to attack a broader range of targets. For example, a phevo without color may be able to attack phevos with the same shape in any color available. This makes the attack stronger.
Once the attack phevo has reached sufficient strength, the play can release it to attack the enemy. The player will need to balance between launching many quick attacks (very specific, depletes board stock) and slower power attacks (takes considerably more time.) The pace of this will have to be gamed in a prototype.
"Promoting" a phevo to attack leaves an empty space in the board that the player will need to fill. This can either be done by mating phevos or by cloning (I may have cloning be the default behavior, and may let that happen automatically unless the player intervenes otherwise.)
The game ends when the opposing player has had all of his or her phevos destoyed.
Attached is an archive based on a mechanic I have been meddling with for some time now. Requires Python and Pygame.
Attachment | Size |
---|---|
phevo.zip | 198.26 KB |
Today we see the release of phevo-0.0.33, the first alpha release of the game. It features a very basic AI opponent, more extended gameplay over previous versions, a brief set of instructions, and a number of bug fixes.
Phevo has also been set up for distribution at SourceForge.net, the largest open-source development site on the Web. It is through SourceForge that development of Phevo is likely to continue into the future.
Because of the difficulty in developing and testing a game on my own, I have decided to open-source Phevo under the GNU Public License and release it to the public for testing and development. It is my feeling that Phevo will be able to find an audience, attract developers, and improve in quality because of this.
I would like to address these future developments point by point. First off, the audience for open source games is small but growing. There are a number of sites online, such as the Linux Game Tome, the specialize in Linux and OSS games for the community. It has been my experience that open-source users are very willing to try out new games, test them, report on them, give feedback, and even begin to crack them open to see how they work.
This presents me with a two-fold benefit. I develop a following for the game without having to commit financial resources or deal with a publisher. This following becomes my group of alpha testers as development continues. The second benefit is that I begin to attract other developers to the project.
If the proprietary world of software competes for financial resources, the open-source world competes for developer interest and time. I think I can garner enough curiosity about my project to be able to pull in at least one more person, and possibly a range of others who may commit small improvements with graphics, sound, and the like.
In addition to visual improvements, there are a number of game-level tasks that I'd like to see fulfilled in the alpha stage. One, I'd like to be able to get networking up and running so that two people could play the game against each other over the Internet. It would be especially great to get a meta-server running for it. Second, I'd like for there to be a massive code clean up in the graphics engine, which is starting to show serious weaknesses, especially with animation. Fixing this engine would allow for many more possibilities in display and UI innovations. Third, I would love to see subtle improvements in the game play as alpha feedback starts tickling in. The more feedback I get, the more I'd like to incorporate those experiences into better and more intuitive gameplay.
This concludes the pre-alpha development cycle for Phevo. I'd like to thank Peter Lee and the Casual Games class at Parsons for their continued interest, support, and criticism, which has made this odd little genetics simulation into something approaching a playable game. Cheers!
Attached here is the prototype document for the first prototype of "Phevo."
Attachment | Size |
---|---|
prototype_spec.pdf | 149.21 KB |
See the files below for significant builds.
Attachment | Size |
---|---|
phevo-0.0.6.tar.gz | 94.58 KB |
phevo-0.0.12.tar.gz | 578.07 KB |
phevo-0.0.13.tar.gz | 573.72 KB |
phevo-0.0.22.tar.gz | 581.52 KB |
phevo-0.0.27_win.zip | 4.63 MB |
phevo-0.0.31.tar.gz | 860 KB |
phevo-0.0.33.tar.gz | 715.27 KB |
This is my work from the Design and Education course during the spring of 2007.
These are the design challenges I came up with for the Design and Education course. Interesting stuff.
How do you make learning a language/literacy skill playful?
What are people going to learn? And why? What form will it take?
I intend to teach the fundamentals of multimedia programming to interface designers who have not had much exposure to programming. I will use a graphical programming language that guides players to build simple programs from a limited set of programming blocks. By doing this, players will gain an increased proficiency with programming skills and an increased sense of self-efficacy when approaching problems that require coding. It is hoped that this will enable the users to feel that they can pursue more difficult tasks on their own.
The game I will build is called Alien Pet Shop. The player is the chief mechanic of a funky store that sells unusual, customized pets to discerning customers. The mechanic's job is to build and expand the store's ordering system to allow for different kinds of requests. In the process of working on the store's machine, players will be introduced to important programming concepts suchs as variables, control structures, and functions.
Using the store as a metaphor for an interactive process, users will read the kind of inputs given to them by users. At first, the input will be very simple. Customers will ask for a specific type of pet, such as the "rudbud." The player will then set up a "plan" that will allow for a "type" request to come into the system.
After the request is in the system, the real work begins. The player will add a new "action" to the plan. The action will take the input and perform work to try and get the proper outcome.
The player can edit their actions to work with the kinds of requests that come through. For example, if the customer has asked for a "rudbud," then their action will simply be a condition that asks if the type equals "rudbud" and then returns that pet to the output.
As the player completes the simple challenges, different kinds of orders will start to come in. A customer might ask for a "red" pet. The player will then work with that input and return a set of new choices to the customer, based on which pets are red.
A further advancement will be customizable pets. A customer might ask for a "rudbud" with 5 legs instead of 3, which would require the player to set up a loop that can add legs to the pet based on the type and quantity requested.
By setting up increasingly challenging processes to manage the store, the player, as mechanic, will have to write more and more accommodating "code" to make the system work.
As they progress in complexity, they will see their work on the graphical code editor represented as an actual programming language in the code window. By showing the player multiple syntaxs, they will get used to the idea that the work they are doing in the graphical editor relates directly to the code produced in the code window.
A further advancement would encourage the player to start using the code window for complex scripts, and submitting the to the "machine." This would give the user their first taste of writing code, but would still keep the training wheels of the graphical system handy if they get stuck.
Take a look at the gallery.
The purpose of this game is for professional interface designers to gain an increased proficiency with programming skills and an increased sense of self-efficacy when approaching problems that require coding. From this starting point, it is hoped that students will feel they can advance farther in programming than they otherwise thought they could have.
The main movement in the game begins with a new challenge posed by the fictional clients. In the first few runs, the player is assisted by the Master Mechanic. The MM guides the player through the process of selecting inputs from the order, setting up the plan, and, most crucially, "writing" the code. The MM prompts the player through the early challenges and points the player toward the right tools from a limited set that represent actual coding concepts.
Once the plan is complete and the code has been written, the plan is run. The player can see how the code operates with the input as each step is highlighted as it gets executed (see below.) Then a new challenge is initiated. Eventually, the MM takes a long and well-deserved vacation and the player is left to handle the challenge based on what they've learned.
The model for this game is a highly-colorful alien pet shop. The palette for both the game pieces and the rest of the art is a saturated and contrasting, emphasizing fun and the odd funkiness of this futuristic enterprise. The game pieces themselves are large and block-like, and designed to suggest a pairing or an action without much additional prompting.
Taking a look at the attached PDF file (see bottom of this page,) the building of the code becomes apparent. The initial levels are guided by the Master Mechanic and prompts on the menu items, put the pieces themselves fit together consistently through the play of the game. In addition to explicit hints from the MM and implicit hints on the shapes, other elements appear the help guide likely pieces together, so that a user who drags an item around long enough will receive clues as the matching pieces near each other.
By using the simple set of cues, the player begins to see a fully formed program taking shape. This program is represented graphically in the main window, and takes more concrete shape in a side window in actual code that the player can grab, save, and manipulate more expertly as they progress in the game.
In the future, I want to focus on increasing the visual representation of what is happening, particularly in line with the machine/factory metaphor. By showing what actually happens as the pet is selected or constructed, it could reinforce important points along the "plan's" execution path. Increasing this tie to the central metaphor can help visual learners tie down the concepts to their own already sophisticated visual understanding.
Attachment | Size |
---|---|
model.pdf | 1010.04 KB |
Can you adapt an existing game to make it a focused teaching experience?
Children will learn about how animals forms and behaviors adapt them to their environments. Using Apples to Apples as a game, a rotating "judge" player will draw an animal card (just as the judge in A2A draws an adjective card). Other players will have, in their hands, traits of animals like color, climate preferences, mode of transport, diet, etc. Players will submit a trait that they think best matches the animal on the table. The judge will pick the traits he or she best thinks matches (maybe more than one, as opposed to one and only one in A2A). The animal and the traits are written down, possibly on a computer, for later discussion and comparison. As the rounds continue, players are encouraged, either on the worksheet on which the rounds are recorded or on the computer screen, to see which traits animals share in common, and start making inferences about similar creatures.
In addition to the inferences made about animals, each of the animal cards could be marked with brief descriptions that point to likely traits. Similarly, the trait cards could point toward animals that are more likely to possess them. This way, players wouldn't need to depend as much on prior knowledge and would be able to construct new knowledge within the confines of the game itself.
See attached desed2sketches.pdf for idea sketches.
The purpose of this game is to teach elementary school children about animals. Specifically, they will learn about how the animals are adapted to their environments by exploring these animals habitats, traits, and behaviors and finding commonalities with similar creatures.
The game follows the same progression as Apples to Apples, except that the dealer can pick multiple winners per round and the progress of the game is tracked on a worksheet.
Each player starts out with 5 trait cards. The stack of animal cards is picked up by the dealer and the top card is laid face up on the table.
Each player submits a trait they think is most appropriate. The dealer selects as many cards as he or she thinks matches the animal and writes them down on the worksheet.
A variation I want to test is switching trait and animal cards, so that players hold animals and traits appear in the dealer's deck. I also want to game how many cards a dealer can pick (unlimited, limited to 2 or 3, only one) and see how this affects the game flow.
The model for this project is similar in many ways to that of Apples to Apples. For testing purposes, an equal amount of trait and animal cards were prodeuced, making switching the focus of the game (from animal to trait) as simple as switching decks.
Two versions of the worksheet were also produced, each version reflecting a different possible focus on animals or traits.
Attachment | Size |
---|---|
desed2sketches.pdf | 458.1 KB |
desed2structure.pdf | 180.35 KB |
For my game, I originally modified Apples to Apples to work with animals and their behaviors and habitats. The very first play test of this occurred in class, with four of my classmates playing. As much fun as the original game was, though, play was slow and the learning features were a little clunky--recording the animals and their traits clogged up the game play.
The game I came up with after that, based on suggestions from that class, was more like dominoes, specifically the "Mexican Train" variation. The twist I put on it was faithful to my original educational goal of teaching kids about the lives and homes of animals. Each domino had a name and picture of an animal, and a set of four icons that depicted that animal's identity. The icons represented:
Players were asked to match three of the four traits on tiles on the table to a tile in their hands.
The next play test of the game happened in class with Becky, Laura, Albert, and I playing. I held the lead for a brief period, but Becky won in the end. There was a good consensus that the game was fun and playable--despite several players never having played any version of dominoes before, the rules were easy to explain and everyone picked it up very quickly.
I asked the following questions:
I did get a couple of correct responses from the group of players, but not everyone answered correctly or at all. This exposed one flaw in the game play--the animal identification can be missed if not emphasized properly in the play.
The next test I ran at home with just my wife, Kelcey, and me. I was interested in seeing if the game was still playable with only two people, which turned out to be just fine. I also emphasized, before play, that she should pay attention to the animals on the cards, and I made a point of mentioning the animals as I played.
In the end, Kelcey got two of the three questions after a little prompting, but there did still seem to be a weakness in that area. Some of the suggestions that came out of that play test were:
On the positive side, the game got raves for working with categorization tasks and simple playability. Such are the benefits of living with an educational psychologist.
When considering the game as it stands now, the following principles of James Gee come to mind:
I would argue that the Well-Ordered Play and Pleasantly Frustrating qualities are at the fore, mostly because of the greatness of the original game. Next, On-Demand Information is at work here rather nicely, with the dominoes holding compact and easily-readable data for players to use. This quality in turn benefits the Skills as Strategies characteristic by enabling players to easily convert their data into action. Finally come Co-Design and System Thinking, which work in tandem as players experiment with different pairings and branchings during the course of the game.
I think this game has a good amount of potential for playful learning. It may take a few rounds to pick up the lessons, and more could be done to clarify the game pieces and emphasize the animals. On the whole, though, it's a fun variation of a successful game.
Design a lecture or instructional piece for something missing from the MFADT curriculum.
My concept is to create an interactive "cookbook" that will allow Parsons MFADT students to explore, test, and create their own interactive or computational pieces using simple but powerful math fragments. The idea is threefold:
The purpose of the cookbook is to teach DT students about mathematical formulas that can help them achieve desired effects in their interactive and computational work. It should be a persistent and expanding resource for students to use as a reference and repository of collective associations between different math concepts.
The overall structure of the product is very similar to other community content sites, like the Python Cookbook or instructables. That is, there are individual pages that host particular pieces of information, say about the sine wave function or elasticity functions, that are linked together to form a whole corpus and are supplemented with user responses and other data.
More specifically, each page contains an interface that displays the function as line, in most cases, and shows an example, where applicable, of what that function would look like it it were placed in motion.
The page will also contain keywords that link to this page (as well as others), a list of similar pages (derived implicitly by automated analysis of the keyword linkages), a set of saved settings for the student and other users, so people could go back and explore their experiments, and a threaded list of comments, where users can post more about their experiences.
The pages would be linked together via a search page that allows users to search by keyword. The result of this search would be a graphical result page that would visually show the user what the relevant results looked like. The user could than navigate into the individual pages themselves and begin exploring.
Simple pause, play, rewind and fast-forward buttons would aid study of the function as motion.
Below the graphical display are a set of sliders and numerical readouts that would allow the user to modify useful parameters of the function in order to display different results. The function itself is prominently displayed next to the sliders and changes in response to alterations in the numbers. This provides a multiple-syntax approach to the learning--both the graphical and formulaic representations are provided for the student.
To the right are the keywords, similar pages, and saved settings of the user and others.
Notes from the class.
This is my work for the Design and Psychology class in the spring of 2007.
Notes from this class.
Welcome to my Major Studio: Interactive class page. Most of my work, for now, will appear on the blog. All the work I do in the class will appear there, so keep an eye open for the torrent of new stuff that will appear week after week.
My group in studio was assigned to investigate touch interfaces by digging into vibrating motors, timed stimulus, and other odd bits of perception. The results of our work are detailed here.
For our initial assignment, we were tasked to build devices that communicated to the users via their sense of touch.
Today, we will run through the basics of Arduino programming. To follow along, please go to the reference section of the Arduino site and step through the functions as we go.
Also, download the files below. They are the Arduino code examples we'll follow once we start making real circuits.
Attachment | Size |
---|---|
knight_rider_1.zip | 471 bytes |
knight_rider_2.zip | 39.57 KB |
vibrapot.zip | 37.68 KB |
Now we'll run the knight_rider_1 tutorial. Open up the files in the zip archive. All you need for this is to plug in the Arduino to your computer.
Once the board is plugged in, hit reset on the board, then click the Upload to I/O icon on the Arduino interface. Once that's done, click the Serial Monitor icon to see the numbers move up and down. Now you're talking (to the Arduino!)
Now let's put some of this stuff together into a new circuit. You'll need four LEDs, four 220 ohm or 470 ohm resistors, one 1K ohm resistor, a push button, and a bunch of wires.
Hook four wires into the Arduino's digital outputs (check the code to see which ones.) Connect the smaller resistors to each of those wires, then connect an LED to each resistor with its short leg to ground. Be sure to hook up the 5V and GND lines between your Arduino and breadboard.
Connect the 1K resistor to ground (this is a pull down) and to one pole of the switch. Hook that same pole to the input on the arduino. Hook the other pole to the 5V source.
You're all set!
Okay, actually, that's a pot as in potentiometer. Nyuk, nyuk. Anyway, let have some fun here!
Notes from the Major Studio: Interactive class.
Back again and into my thesis year. Lots more to do and not much time to do it. Let 'er rip.
In this course students re-invent Lang’s student newspaper as a web-based community for Lang College. Focusing on questions of how to translate a print-based medium into an interactive community, students consider what additional technological experience needs be added; how an electronic newspaper is read and used; what links to include to other portions of the university, the city, and the world. Working with a Web designer, students build and test a prototype. The course involves learning about how online communities work, and an examination of what the different kinds of online community are. It involves survey Some prior technical knowledge is preferred. This course also satisfies a requirement for Writing. ing Lang students about their online habits and needs.
Co-taught by Karl Mendonca and Mike Edwards.
We discuss some of the history and structure of the Internet, using historyoftheinternet.org as our guide.
Make tech look good.
Game Design 1. Ain't playin'.
"Call of Duty: Vanguard" is a first-person shooter for the Nintendo Wii set in World War II. The game offers several multiplayer options for play in split-screen mode. This review will evaluate one of these options, "King of the Hill."
The formal system of King of the Hill works as follows. The objects in the game are the player avatars, of which there are four, the flag, which is in the center of the digital environment, several types of upgrade guns placed around the map, obstacle objects like barbed wire and walls, and the terrain itself.
The avatars have attributes, such as their chosen weapon, the ammunition in the "clip" of the weapon, the total ammunition available for the weapon, the direction in which the avatar is facing, the height of the avatar, which can be standing, kneeling, or prone, and some measure of how much life the avatar has left. The avatars are also assigned a team attribute ("allies" or "axis"), which determines their costume or "skin" as well as the color of their displayed player name when the avatar is sighted in the reticule of another player. In King of the Hill Mode, the players also have a score attribute, which is a number from zero to less than 20. The number represents the amount of time, in tens of seconds, that the avatar player's team has spent in close proximity to the flag object. If the flag has an attribute, aside from its visual display, it is whether or not a player is near it. This is represented by a sound triggered when a player avatar cross a boundary near the flag.
The most important internal relationships in the game are between the each of the player avatars and between the player avatars and the flag. For players with the same team attribute, their avatars must not cause "injury" to each other by firing their weapons at one another, and they each contribute to the others score while they can maintain a close proximity to the flag. For players with different team attributes, the relationship requires the players to fire their weapons at the opposing avatars for several different reasons. If the player is in the wider area of the game map, firing on the opposing player avatar is intended to prevent the enemy from achieving proximity to the flag. If the enemy is encamped next to the flag, the goal is to "kill" the opposing player and, in so doing, prevent the enemy from gaining any more points. If the player is next to the flag and the enemy is encroaching, the goal is to kill the enemy to prevent them from killing the player so that points can continue to accrue. First team to 20 points wins the game.
The environment of the formal system is the terrain map and the location of the key objects within it. Typically, the flag, as stated above, is placed in a central location, usually surrounded by a few "bulletproof" objects that serve as cover for the defender. The "spawn points" for the players are located near the periphery of the map and usually orient the player toward the center of the map. Typically, the spawn points for each team are located on opposing sides of the map. The effect of this is that, as players run toward the center of the map, where the flag is placed, they do so while facing enemy fire from their direction of travel. In addition, there are walls, rocks, machinery and other hard points that the player may use to avoid detection or injury from opposing fire. There are also holes in the walls, trenches, alleys and other features that allow the player to progress toward the center, around the objects, as well as allowing enemies the opportunity to fire on exposed players. Finally, located in areas not usually in the direct line between spawn points and the flag are upgrade weapons that allow for attacking with greater speed, accuracy, or power (e.g. machine guns or sniper rifles).
Because the game is a realistically rendered first-person shooter, the game environment allows for the player to wander through the map at will. The player may enjoy the scenery, examine architecture, etc. But to be competitive in the game, the player has far fewer options. After spawning, the player may either make a mad dash toward the flag in hopes of occupying it quickly, encamp near the flag to pick off enemy players (possibly while a teammate occupies the flag's scoring area), circle around the flag in order to find and eliminate any defenders (followed by a rush at the undefended flag) or run off track to acquire a more powerful weapon and then proceed with the first three options.
As the game progresses through several rounds of play and the players begin to achieve an expertise at King of the Hill, however, only two of those options become realistic: mad dash to flag and shooting flag defenders point blank. The other options require too much time for the benefit they grant, creating more points for flag-defending enemies. The consequence of this is that, while the game allows for an almost infinite variety of actions in a realistic digital world, the choices that emerge from play are much more constrained.
Consider the anatomy of this choice. The state of the game is laid out on a split-screen view, with multiple viewpoints displayed, indicating position and orientation of all players. Typical of a game like this, players will check the views of opposing players and discover whether the enemy or the teammate has occupied the flag area, showing the player the possibilities for action. The player pressed forward on their controller and advances toward the center where the flag is placed. The avatar moves in the direction in the face of potential enemy fire as well as closing the gap to the goal. The result is that the player either takes fire and dies (indicated by red flashes on the screen) or reaches the flag intact.
Once in the flag area, the players choice is to pick an orientation and hope that the enemy approaches from that angle. Otherwise, the enemy usually gets the drop on the player, kills the player and then occupies the flag area.
The net result of these choices is that play begins to feel very narrow and mechanical after the group of players has achieved a certain level of expertise with the King of the Hill mode and with specific maps within it. Talk among the players begins to shift from commentary within the context of the game ("gotcha, dude!", "argh, I'm wasted!", "help defend the flag!", "he's over there!", etc.) to meta-game critique ("fuck that, I totally shot you first", "if you mess up in the beginning, it's hard to make up the points", "let's try another map"). This breakdown of the lusory attitude is a consequence of the choices in the game being, in effect, far too limited to allow for a meaningful strategy to develop or for creative approaches to be explored. The constant demands of the scoring system create a game in which the player is forced to rush to the center, dislodge the defender, occupy the position, wait to be killed, then start over again. The winner of the match appears to be nothing more than the team lucky enough to spawn close enough to take the first point, which is very discouraging over time.
The process of designing visually.
More to come.