General Thoughts
Making this game was certainly more difficult than I expected. Coding by itself was actually the easiest task thanks to XNA, but undoubtedly the greatest challenge was to iterate over the core mechanic until the game felt solid and fun to play. As I said in an old blog post, my objective with this project and the class in general was to create an original game concept. I wanted to experiment with something new. I especially wanted to make a game that was unlike anything I played before –and I played a lot of games in my life! My excessive ambition though was also the greatest source of trouble for this project. My original game idea was approved by Aaron and David, but I really had not figured out my core mechanic fully then and given the experimental nature of my proposal, I had to develop several prototypes before I managed to flesh out the details of gameplay. After all, a lot of game ideas go through this kind of gestation period. A good example is the Winterbottom game that was presented by our guest speaker Matt Korba. He told us that he and his partners had to try many prototypes before they figured out what they wanted to do.
Whatever the case, this project was definitely a learning experience for me. In fact, despite my numerous endeavors in game development, I never focused this much on gameplay, being always very busy dealing with crazy engineering problems. It was an opportunity for me to better appreciate the aesthetics of game design, which is one thing I never really contemplated before. After all, I am an engineer and my perspective on gaming is naturally very different to that of a game designer. On the one hand, we engineers like well-defined specifications, a principled approach to problem-solving, and don’t rely too much on trial and error when possible. On the other hand, game design is something far less tangible than the usual quantifiable notions that are common in engineering. It is therefore really hard to validate a core mechanic without actually trying it out through a prototype. In a nutshell my experience with this class boils down to a lot of prototyping and iterating over gameplay ideas.
Successes
Yes, there was a time during the quarter that I felt very frustrated and I kind of lost my motivation, but in the end I managed to pull off a game that I am really happy with. I performed a lot of play-tests before I could fix my originally broken core mechanic. However, in the last few runs the response of the play testers was very positive. I spend a lot of time to polish the game play and to make it very balanced. The action of each pill in the game and all other game variables are a result of a lot of tweaking and they incorporate much of the input that I got from play testers.
The final critique by Aaron focused mostly on the interface, title screen, and a few annoying bugs. These were actually easy problems to fix, and I addressed all them in the new updated version that posted on the blog. With the updated version the game also feels very polished and complete.
Last but not least, after my artistic marathon in the end, I managed to make the game also look really good.
Failures
I may sound repetitive at this point, but while talking about failures I would like to say again that for quite some time this quarter I thought that my game was a complete failure. The initial design was not well-thought out, my first prototype sucked and it was plagued with a ton of physics-related bugs. Yet I persisted and I decided that rather that pursuing a game concept from scratch, I should get inspiration from some existing ones. I pondered over many games and the ones that seemed to agree most with my original idea were Gorillas, Lemmings, Troddlers, and especially Worms. If you played these games, you can tell that my game has several things in common with these games, but still I do not feel that I betrayed my initial goal to make an original game. I simply made my approach more focused by reinterpreting successful features of these games.
While I am fairly happy with my game and also Aaron agreed that the improvement of my game from the first prototype was huge, there still are some problems.
* The frogs are animated through the physics engine now and they can perform very acrobatic motions, which is good. Moreover, by using a physics engine, I could avoid hand animating the frogs. Nevertheless, the frogs are very inexpressive and they lack good cartoony animations like in the Worms’ game. This detracts substantially from the kind of humor that I wanted to achieve.
* Speaking of physics engine, Aaron told me several times that the physics engine does not seem particularly useful for my game. He is right in that physics doesn’t play any important role in my core mechanic, but I still believe that some physics based animations to spice up the punch of fire balls and explosions is pretty cool. The version that I showed in class for the final critique had some outstanding physics-related problems –namely the foot sliding problem and some weird dynamics for the pills. I addressed both issues in the final update that I posted.
* The two masters and the frogs are pretty much clones of each other and that feels fairly wrong as several people pointed out.
* I should mention that there are still a few inevitable bugs that are lying around, and the AI of the frogs makes them act weird sometimes. However, I fixed all serious bugs in the last update and currently there aren’t any known bugs that can stop gameplay.
* One thing that is really missing is a menu system. Making a menu system by itself is an extremely easy task, but what I lacked are meaningful options to put in the menus. Of course I could fill the menus with options for adding variety to the game, such as several difficulty levels and game types, but that is somewhat time-consuming and it needs to be play-tested first, so I decided to leave the menu system out.
* Probably the main problem with my game is that is not entirely immediate and it takes some time for a new player to understand how the game works. I tried to compensate that by adding a “how to play” screen that pretty much spells out game rules, but that is just a quick fix. What I really need is a tutorial.
Art
Since I am not really an artist, this game was also a remarkable artistic challenge for me. In fact, this is not a game that I can make look nice with some cool tech like Geometry Wars. This game actually requires a lot of good drawing and art design. For those who remember the original graphics, it looked really bad and I had a fairly short time to fix that ugliness. I ended up spending two full days before the deadline working on the art. I tried all kinds of concepts ranging from real pictures processed in Photoshop to traditional hand drawing, but I wasn’t really happy with any of that! Art styles that were too colorful or realistic made the game look very discombobulated and didn’t quite agree with the humor in the game. Then the right inspiration came almost suddenly while I was fixing a bug. I did not set a variable right and the background did not show at all; I looked at the game then and I realized that what I needed was a very bland cartoony art style. So I created a very simple background with a sky gradient and a colorful ground with polka dots and it fit perfectly. Then I modified the frogs and the masters to follow the same artistic direction and voila the game looked really good and fit perfectly my game.
Coding
I’ve been writing code for many years now, and making this game was fairly straightforward from the development side. To make things even easier XNA is an absolutely terrific framework that makes game development a snap. Probably the greatest source of problems for me was the Farseer physics engine. The engine itself is very good and well-designed, but I had a lot of trouble with collision detection, since I wanted to thrust my frogs around at high speeds. This is a classical problem with physics-based animation and I couldn’t expect better from Farseer.
Future Work and Final Thoughts
Despite all the tribulation, I am very happy with the game that I made and I am definitely willing to continue working on it in the future. Honestly, my game is not as revolutionary as I envisioned, but perhaps with some extra polish I may try to submit it to the indie game festival and see what happens. A more realistic goal for now is to get my game ready for the Creator’s Club in October.
As I did many times in my career I am strongly tempted to do a substantial rewrite of the code, as I feel that my prototype has a several engineering flaws. Anyway, that is expected from a prototype. In fact, engineers do a lot of prototyping too. Actually being a researcher myself, I write code prototypes very often. However, among software engineers a prototype is almost always meant to be thrown away. In fact, a prototype can never match the intrinsic quality of a good software product and in most cases the easiest thing to it to rewrite the application from scratch. However, the rewrite is going to incorporate all the insight and the successes of your prototype, so it can be developed very quickly. The advantages of good code quality are enormous and it is definitely something I need, especially if I want to release my game to the public. Furthermore, since I now have a solid core mechanics that works, I can focus my rewrite to address all the technical aspects of my game that I did not have time to develop fully.
Whether or not I am going to rewrite the code, there are a number of improvements I’d like to make for my game. Here is a list of ideas:
* Add game modes that restrict the kind of pills that you can use.
* While not strictly necessary, add a menu system since it appears to be a feature people expect.
* Make the AI of frogs more elaborate and add more pill types.
* Similarly to Worms, have items and bonuses fall off the sky to add some extra randomness and variety to the game.
* There are situations in which both players may get away always using the same pills repeatedly. I should add some gameplay elements to avoid this.
* Add shaders to make explosions and other effects more impressive.
* Make the arena larger and add a camera system to scroll and zoom in.
* Add a replay feature.
* Add animations to the sprites and make the physics-based components of the animation more elaborate.