Time-frame of project: Summer 2012
Project status: complete
Play it here: http://www.openprocessing.org/sketch/66388
Role: Game Designer/Programmer
About: I Created this game for my final project in my Computational Photography class. We were given a lot of freedom to create whatever project we wanted as long as it was related to computational photography (IE doing computational processes to photographs). I wanted to create a game for this project that not only was fun and interesting to play but also revolved around computation photography. This game was the result.
In Red Green Blue, players control blocks that fall to the ground (similar to a puzzle game such as Tetris). The blocks are randomly generated and are either the red, green, or blue component of a base image (there are 3 of these images total). The goal is to clear blocks for as long as possible until you lose, earning a high score (you lose when a block is landed in the top row). Players clear blocks by landing different color components of the same image on top of each other (they will merge together when this happens). When all 3 colors are part of a block, it will be cleared (netting you a point) and all blocks of the same image (regardless of how much color they have) that are touching the fully colored block will also disappear (allowing for some pretty big combos). Additionally, blocks will fall down a row if the block below them was cleared, and merge together if they are the same image but not the same color (allowing for even larger combos). As your score gets higher, the blocks will fall faster and faster.
This was a really fun game for me to make because I had never made a real puzzle game before, but always wanted to. I think the game stands out a lot becuase it isn’t about dropping combinations of blocks like most puzzle games, but about differently colored single blocks. From a design perspective, the most important parts of a game like this are the way blocks are cleared and the way score is kept. The way that blocks are cleared when they touch a complete block is I think a pretty natural way to allow for combos (an important part of puzzle games, as nothing feels better in a puzzle game than clearing an entire screen as a result of a single block being placed perfectly), although had I had more time I would have liked to experimented a bit more with this.
After playing the game for a while I realized that the best strategy is to group all of the blocks of the same image together so that when you can complete the coloration of an image, you can easily clear away all of the blocks on that side of the screen. If I had a 2nd chance at making this game, I would make the grid much larger (from 5×5 to maybe 8×8 or 10×10) and make combos act more like a “web” than just a nearby affect. IE every block of the same image that touches the complete block is “marked”, and then each block that touches a marked block that is also that image will also be marked, etc. Then each marked block is also cleared (very similar to how combos work in the game Lumines).
I did not have much time to focus on scoring in this game, and so it is pretty basic: each block that is cleared nets you a single point, regardless of how many colors are in it. I could have made it so that you get more points per color in a cleared block, but I think it is sort of interesting to think about how useful combos are in keeping you alive vs how useful they are in adding to your score. Generally in puzzle games they are correlated: the more blocks you clear the more points you score. However I thought it’d be pretty interesting if you earned more points for clearing blocks “the hard way”, encouraging the player to play more risky to earn more points. So if I had more time to adjust the scoring in this game, I think I would make combo-cleared blocks give the player less blocks than the fully colored cleared blocks, encouraging players to spread out their pieces if they want to earn a higher score.
Overall this was a pretty fun project for me and I learned a lot about designing for the programmer as well (as I did all the programming myself): It’s important to write out all of the important parts of the game first before going into details, and it’s very helpful to do the stuff you don’t know how to do first, since you don’t know how long it will take to do (whereas it is much easier to guess how long it will take to do stuff that you do know how to do).
The game also really got my thinking about rewarding the player with utilities (clearing blocks) vs rewarding them with abstract rewards (higher score). What is the reason people play games really? Do they just want to get a high score, or do they want to clear blocks, regardless of what sort of abstract reward they get? For me personally, I think the real joy (from puzzle games at least) comes from getting one’s head lost in the mechanics of the game: thinking about how they work together and mastering the system. The real reward for me is clearing the blocks becuase I figure it out, and not necessarily the points that I get for it. Points are great for being a numerical value for the time and energy spent on a game, but they are not the real goal, points (or whatever sort of abstract reward you have, such as character level or rank) are not what drives me to keep on playing. the simple drive to clear blocks (or whatever is your main game mechanic) is the experience that I want to partake in, and is the end to the means itself.