This is the second part of my overview of some (but not all) of my older prototypes. Part one can be found here. So lets move on, the prototypes in this part represent a departure from bad HTML and flash, towards actual programming in C# and JAVA.
5) Three cauldrons: first steps into XNA and C#, a twist on card battle games where your "cards" are created by combining color coded mana resources. (Here starts my ongoing obsession with color coding).
 |
| Placeholder graphics, oh so ugly. |
Code: this was my first attempt at something resembling a game engine. XNA provided the game loop and low level graphics. Here finally I had separate update (logic) and render (graphics) calls each frame. The game logic was now organized in classes; input was aggregated and polled by the engine for the player. A drag and drop interface system was created utilizing interfaces and abstract classes. Card details were loaded from an external XML file. Code wise this was a huge leap forward from previous games.
Graphics: sprite sheets created using either Gimp or Photoshop (can't remember which to be honest).
Game idea and design: a two player game. Each player had 3 mana fields, a tower, and six battle fields.
Each turn the players mana fields would produce specific color coded mana resources (a red field generates red mana, blue for blue etc.). The player then placed 3 mana orbs into one of three cauldrons, the choice of cauldron and mana types would determine the spell (card) the player received. The player could then save the spell in a bottle (limited to 15 bottles) or cast the spell. Casting the spell would be like playing a card in a card game. It could place a monster or trap on the battle field, it could change the mana field types, and it could harm the other player’s tower and more. The players’ battle fields were connected and monsters placed on them would fight each other, with the winner damaging the loser’s tower. Once a tower is destroyed the player who owns it would lose. Somewhat inspired by Arcomage, which you should totally play. The thought was that exploring and learning what combinations produce what spells would be fun.
The good: data oriented approach to spell details, robust and modular drag and drop system. Actual thought put into the design of the software aspects of the game.
The bad: core mechanic was too cumbersome. Exploring spell recipes was fun but too slow and tedious. Grinding through the lower level spells at the game's beginning was really boring.
Status: abandoned a bit after the prototype stage. When abandoned it contained about 20 spells and a system for adding and changing spells on the fly for testing. A complete drag and drop based interface, and the core mechanic fully implemented.
What I've learned: some color theory (used in the mixing of the mana colors). The value of thinking through the design of the code (this was before I learned about class diagrams). Keeping up the motivation is hard and requires a conscious effort. It’s hard to judge a game about exploration and discovery when you know everything, external feedback and fresh testers are required. Over complication is bad.
6) Color walkers: I've mentioned color walkers before. It was the first prototype I made for the game programming course I took as part of my CS degree. It was a color based puzzle game with platformer elements, created using XNA.
 |
| Winner of the girlfriends' favorite prototype award. |
Code: this game boasted a simple tile based engine with three controllable characters, the basic engine was written in two days (experience counts). The color related aspect of the game was also rather simple to code, putting to use what I've learned about color combinations from the previous game.
Graphics: this was a rapid prototype limited to circles and squares.
Game idea and design: the player controls three characters, one red, one green and one blue. the position of each character on the screen determines the color of the screens background (so if red is all the way to the right and green and blue are all the way to the left, the screen would be fully red).
The characters move and jump platformer style. Platforms are color coded. And when a platform is the same color as the background, it blends into it and can be passed through. Allowing characters to proceed. The goal was to move all characters all the way to the right.
The good: one of my cooler concepts. Reviews (both in the course and from friends) were really good. Implementation was simple and straightforward.
The bad: designing the one and only level took about a week. Once that level was completed, there was not much more to be done with the mechanic. Basically it was a great prototype that will never be a game.
Status: deferred. It is not fully abandoned as I hope to one day find a way to incorporate it into another game or find a way to expand on its concept. But for now no development is done on it.
What I've learned: rapid prototyping is a lot of fun and really puts the mechanic forward. Even a great prototype can be a long term failure.
7) Operation BOOM! This was the final project for the game programming course. It was a group effort. It has a devblog of its own so I will not repeat the details provided there.
 |
| Boom! |
Status: completed.
What I've learned: working in a team is exactly nothing like working alone. For better and for worse. It is extremely important to work with people that you can trust, and can hold their own. Luckily I worked with three great friends. And more importantly, we managed to remain friends despite the project.
8) Pachinguys: First android game. Currently in active development. This devblog is devoted to it, read it!
That's it for this nostalgia / memory dump post. Next time I'll be back to rambling about Pachinguys, promise.
