Description:It is safe to say that all gamers are at least nominally familiar with the grandfather of “falling blocks” games: Tetris. Less familiar to many, though, are the myriad spin-offs and adaptations of the concept that popped up after Tetris’ introduction. In Columns, three-block pieces containing a selection of six images drop while the player attempts to connect three similar images in a row, column, or along a diagonal. Hextris replaces Tetris’ traditional block pieces with those constructed from hexagons. Spoofing a third dimension results in Blockout, a sort of top-down Tetris. Tetris Attack expands upon Columns’ idea with picture matching, but moves away from falling blocks in favor of arrangeable, preformed full rows. Lastly, Tetrisphere takes elements from all of the above games combined with a real 3d engine to form a visually- and mentally-stimulating experience. Plenty of other examples exist – spin-offs of spin-offs, modifications to modifications, et cetera – but all Tetris variants share key elements brought to the drawing board by the original, addictive game in 1985. I’d like to take a closer look at my favorite Tetris clone: Puyo Puyo. In this game, colored tuples of blobs (called “puyos”) fall in a Tetris-like manner. Once four blobs connect (in any way), they disappear, causing other blobs to shift. If these shifted puyos cause a connection of four or more puyos, they disappear and the cycle continues. Speedily forming elaborate stepped “chains” of connections is critical to Puyo Puyo because, unlike Tetris, the game is played against an opponent. Based on the strength of your combination, a number of “nuisance blobs” will fall on the opposition. These nuisance blobs are colorless and continue to exist until adjacent colored blocks are “combo’d” away. Large combinations can effectively kill of an opponent by flooding his screen with uncolored blobs. Observe the examples below (embedded YouTube videos):
Many generations of Puyo Puyo have added and subtracted certain elements from the game. For instance, Puyo Pop Fever includes two-, three-, and four-tuple blobs instead of the standard double piece. This game also uses a system where an opponent can prevent nuisance blobs from falling by comboing. The resultant nuisance puyos from his chain or combination fight back the impending doom sent by an opponent. I would like to build our project off this amendment process. In short, I'd like to add game elements to the base Puyo Puyo idea while preserving (and hopefully augmenting) the spunky enjoyment contained in the series. The list below contains a few ideas I've had, but group brainstorming will be necessary to form a final list:
It is important to emphasize the openness of this project to programmers with specific talents. The sound effects in a puzzle game are important in that they add to the general ambience of a certain game -- perhaps a fast-paced game would feature high frequency, high tempo music while a slow, methodical game would sound more bass heavy. A heavy chain would sound stronger and more imposing than a light chain. If one player nears death, his music could change appropriately. If a net coder ends up on the team, we could explore the network elements of the game in depth -- many players, observer inpurt, et cetera. Graphics and artwork folks of all kinds will fit in as well -- the game can try for anything from realistic to cel shading in a 2d or 3d world. Personally, I'd like to play around with nVidia's Cg shaders to see what neat effects can be created. Physics in the base Puyo games is simple, but this game can easily accomodate a more realistic system. Assessment:The main advantage to this proposal is twofold. First, the game's realization is undoubtedly within the scope of a one-semester course. Second, and more importantly, we will be able to play the game starting from a very early stage. Once we have the base game in place (blocks fall, disappear correctly, players win/lose appropriately), different add-ons can be assessed in reality instead of theory. On this same token, this proposed idea lends itself to a group project in that each add-on can be viewed as a module coded by one (or more) programmer, then added on to the base game. This proposal is exciting because it lets everyone on the team combine different elements of what they find to be "cool" into one working game that dabbles in many different areas. It is very modular, and as such is very friendly to team programming. Development Resources:It's probably a good guess that C++ is the language of choice for most game folks in this course. With C++ comes OpenGL or DirectX, along with their many official and unofficial libraries, utility kits, and modifications. If we have any interest in creating our own rendering engine, we can, but the use of a kit like OGRE, Crystal Space, Irrlicht, or even Torque will be considered. I have copies of modeling suites if anyone needs to use them, including 3ds Max R9, Maya 8, Lightwave 7, and a few others. Photoshop / GIMP will probably be used for texturing, along with procedural materials. Goldwave and Fruity Loops are the big sound creation/editing suites that I know of -- any others are welcome! I don't know much about already implemented physics systems, aside from Havok. However, the rights to use that SDK are probably slightly beyond our 498M budget. It'd be really neat to make our physics system, though! Layered Development:
Other Stuff:I consider myself a graphics guy, and as such have done a fair bit of modeling/texturing/some OGL. If we end up not writing our own rendering engine, I think OGRE would be the best choice because it's been around for a while and has an amazingly active user community. Although it is technically only a rendering engine, user-written code exists that deals with keyboard input, sound, and probably physics. |
| <<Back |
