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.