I am adding a link here to Heart Racer, the midterm project I did with Amira, since we put up a joint post for it under her name – http://makingtoys.net/2012/04/05/heart-racer-the-game/
Here is a video of the project -
On Thursday, April 29th, Jordan Mechner gave a talk at the NYU Game Center that spanned his entire career. Mechner released his first hit game, Karateka, while he was an undergraduate student at Yale. He started his most famous piece, Prince of Persia, before he finished school. He later led the creation of The Last Express. He was also a writer and designer on Prince of Persia: Sands of Time. Finally, he wrote the script for the Disney-Buckheimer blockbuster movie based on his Prince of Persia series. Below are a few tidbits from Mechner’s talk:
My final paper can be found here – http://dl.dropbox.com/u/10445954/SuperFlyPaper.pdf
Video of the game in action can be seen here (warning: the uncompressed video is 312 MB): http://dl.dropbox.com/u/10445954/SuperFlyVideo.avi
Jetpackers is a collaborative action game about navigating spaces. Set in a side-scroller environment, Jetpackers asks two players to help each other move through dangerous levels by using their jetpacks as well as by shooting each other. Getting shot by a friend gives you a boost, allowing you to reach zones that were previously unreachable. While Jetpackers is about cooperation, it’s also about precise movement. Analyzing it from a game designer’s point of view, it’s about creating very tight, balanced controls. It’s about pursing a mechanically-sound movement structure where the player feels like her actions affect the game exactly as they should. It’s about making the player feel like she is not fighting against the movement of her character, but using it as a tool to fight against the environment.
***
Five Questions I Would Ask The Perfect Guest Critic
1. How do you feel about the character movement physics? Would you change the jetpack thrust and gravity physics? Would you change the horizontal movement physics?
2. What would you do about player “death?” When the player hits an enemy or a spike, what do you think should happen to her? Should there be check points? Should the player be sent back to the last platform where she stood? If I do the latter, how do I deal with the player being hit by an enemy when she’s standing on a platform?
3. How would you deal with the problem that both players can time their shots perfectly so they go up forever? Should a player who just got hit with a boost shot not be able to take another shot for X frames?
4. While I have many ideas for how to turn this into a single-player game, I would love to hear more ideas.
5. Are there any tips on platformer programming, especially when it comes to cheap collision detection and dealing with things like moving platforms and scrolling?
***
An exploration, interactive software piece about planting and growing trees, flowers, and maybe even animals. This piece would feel like a game in that the user controls a character that moves around a world, but it wouldn’t have the implicit goals of a game.
I came into this project quite unsure about what to do. When Amira and I teamed up, she already has a core idea – a game in which your heart rate affects the color of boxes. It was an interesting concept and I was eager to be part of it, but I was worried that I wouldn’t be able to add much to her idea.
I hadn’t worked with someone else on a game idea in a while, so it was interesting to see how our back and forth helped further develop her strong concept. We quickly started thinking about how to get the game away from the screen, paper prototyping a handheld device that would serve the same role as the screen-based game, but in a portable format. We also added cards that the player would draw, guiding her by providing the colors she would like to match. The main drawback is that the computer no longer checks the outcome of the game, but this is not necessarily a problem. Checking the outcome of your own game is an integral part of board and card games, so our goal here is to make this feel more like a digital version of a board game than a handheld version of a videogames.
Programming the initial prototype has been more straight forward than we expected. We had some problems in the beginning, but once things got going we were able to create an implementation prototype that satisfies our needs. The implementation prototype is screen-based, but it works well.
The memory game is a small box that uses three buttons, three LEDs, and a speaker to test the user’s memory. Each turn the user sees a pattern of lights (and sounds) showing the order in which she should click the buttons. Once the pattern finishes, the user must click the buttons in the correct order. If she does, she gets a longer pattern. The pattern gets longer and longer until the user can no longer keep up with it. If she enters an incorrect pattern, all the lights tun on and she must restart.
An emotional box.
1. While I was aware of this, it’s easy to forget how much of the time you spend on a physical computing project comes down to debugging. Unlike software debugging, where 99.9% of the time the problem is with your code, in physical computing you have to worry about two different problem areas: software and hardware. This can make debugging a bit fun (it takes you away from the screen), but it can also make debugging super frustrating when things go wrong.
2. Working with 3 LEDs of different colors in a clear box lined with paper, I expected the LEDs to simply blend together to make new colors. It turns out that diffusing LED light is not as simple as I expected. Whenever I managed to diffuse the light more thoroughly, it became almost invisible. I had to settle for a not-quite-diffused light.
3. I’m still making simple mistakes that I did not expect to make. For example, I put both legs of an LED as well as the ground wire on the same line, so the electricity was just skipping the LED and going straight to the ground wire. That slowed me down for a few minutes.
ramiroc1 is discussing. 
The hardest part of this exercise was trying to come up with enough ideas that I might actually want to implement. The ideas I came up with often seemed too far-fetched at first, but then they would then slowly get molded into ideas that I either liked or at least found interested/funny enough to want to create. The easiest part, as I just mentioned, was finishing up the ideas.
My two favorite concepts are the minimalist baseball game and the cold war installation game. They are both projects that I could see myself creating; projects that I think I actually believe I have the expertise to do well.
My least favorite concepts are the Needy Buddy and the fridge scale. They are both semi-jokish concepts that I don’t know if I could create very well.