For my final game project I really wanted to make one of these kinds of games. With the limit on the project being that it must be multiplayer, I decided that a racing game would be appropriate. While playing with the idea of a racing platform game, I had a difficult time thinking of what to do to balance the game by giving challenges to the players.

At first I thought of making some sort of system of rewards or powers that the player can accumulate and transfer to the next race. This however, made the games powers too easy to abuse by simply stockpiling powers. I then settled on all the powers being limited use, but that can make the race more difficult for other players. I did this by giving boxes for the player to pickup. These boxes give the player a power that that player can use against other players. These powers target specific players, such as the player in the position above you, below you, the player in 1st place, or all other players. These powers, when used, randomly select an effect, with chances weighed depending on players’ positions. For example the player in last place gets better powers and the player in first gets worse.

These powers are crucial to a challenging race. They can obscure players’ vision, movement, and distort players’ controls. Without this added element, races would be dry and boring. These however are what add the competitive element necessary for a meaningful game.

Coding the game took a lot of time and research. There has been a lot written about making games which use a tile based map system such as mine, but unfortunately, most of them (the good ones anyway) are all written for flash. I had to spend a lot of time getting my system working correctly, and I ended up having to remove some elements of the game that I would have liked to keep in (such as sloped tiles). In the end, the system came out rather robust and well suited to my game, however it is not without some bugs (graphical) and could use optimization.

The art for the game I think might have taken just as long, if not longer. I hadn’t done any sort of pixel art until the last project for this class, and it’s really strange to get used to. It becomes about implying details and getting every pixel in just the right place. I really enjoyed doing the art for this game, especially the caketown logo and the level cakes, but it really took a long time. Overall I’m happy with it though. The music also took awhile, but I’m happy with how that came out too. I think I might have spent a whole day on the caketown song, but I like how it turned out.

The biggest challenges in this project I think were creating the tiling engine and the art assets. Both were incredibly time consuming, but I feel like I learned a lot while doing them, especially the engine. The art was really enjoyable, but ate up a lot of time.

I think what turned out best was the tiling engine and the art. I spent the most time on them but they are what I am most happy with. Also the option in the options menu, go try it, it gives everything a dreamy quality.

What did not turn out the way I wanted it to, or I didn’t have enough time for, was the powerups system, sloped tiles, character options and more levels. I felt like I had to cut a lot from my game that I wanted to put in, and given more time I would have been able to put in a lot more (and I will with the summer).

In the end, I’m happy with how my game turned out. I feel like right now it’s a skeleton of what it could be, and will be. It only has one level at the moment, but everything is there. At this point it’s a matter of using the tools i’ve made for this game and just creating more content. I need to look into optimizing a little bit more (the game got a little slower after adding in all the music and post processing).

Oh and I think for the next project I do I want to work with someone else. I had way too much work for this class this quarter.

Download

The first prototypes were built in 2D to keep the gameplay and graphics simple and easy to iterate on quickly.  Using power of the Vector2D class in xna I got a nice natural tank motion out of LERPing the tank direction with the joystick input.  I soon had a working prototype with multiple tanks and projectile capabilities. Because I had a larger vision for the future, I kept everything modular so i could easily swap values in and out. But mostly, I kept stuff variable so I could make the switch to 3D.

3D Was my biggest challenge and most time consuming aspect of my project and where I ran into the most problems.  It took several tries to get the models oriented correctly. Because My game was using 2D information for collisions and movement I was forced to orient along the XY plane. Because of this I ended up using negative Z up for my models when building them in Maya.  Which was kind of confusing when moving around the camera in Maya.  It took me a week or so to figure out how to add textures to my models in game as well, which was not helped by the fact that I have never really learned UV unwrapping.  But I was able to teach myself what I needed to know and move on. 

My next Big problem came when I wanted to add particle effects, I found that they were batch controlled and texture values for any sprite could over ride info for the others.  Thus I limited myself to two textures for my effects and created variance by adjusting tint and opacity.  In the end I was able to create some nice soft particle effects that really added to the explosions and feel of the game. 

I’d like to say I did everything in this game myself, but I Have to give props to my good buddy, Rick Gilliland.  He came to me one day after dinner and said “I wanna add Depth map Shadows to your game.” How could I refuse such a generous offer, so we struggled to figure out the math and four hours later we had some sexy depth map shadows in game. Thanks Rick you’re the best.

After that most of my time was consumed with modeling the area for my tank battle.  It took many days, but came out looking pretty fantastic. I slapped in some royalty free music from http://freeplaymusic.com/ which helped players get pumped for the action and made the game experience more entertaining.  I was lucky to find some hilariously awful elevator music which I placed in my pause menu to make interruptions in the game very comical.  A few menus later I had a polished game which is quite fun to play.

An all round success, I was very pleased with my work.  I’ve had lots of fun dominating my teacher and friends in my own game, and they didn’t mind losing to much because they enjoyed the experience so much. 

Why Was my game only the Seventh best tank game ever? Well because of the limited time I was only able to build one level to play on, I had two other awesomely epic levels planned out that I didn’t get around to making.  I also didn’t have time to give the players the ability to choose from multiple vehicles with different strengths and weaknesses, but that would have required quite a bit of balancing and was simply not practical for a class project like this.  There was nothing really wrong with my game, Just some places where I could have gone farther to make it even more awesome. 

It was nice to work by myself and have full creative control on my project, but It would have been nice to work in a group and be able to collaborate and make something even larger, while being able to focus more closely on one aspect of the games design.  But I know I’ll be forced to do that once i enter the industry so I guess I’ll just be thankful for the opportunity to wear every hat on the design team.

What went well:

For the most part, delegating work had a good turn out. We could each stick with one aspect of game development rather than deciding back and forth about whether or not it was a good time to work on gameplay or improve the visuals or sound if we had worked on our own games independently. The AI ended up working as it should and didn’t need to rely on tweaking character statistics in a menu screen which is something that can make many people lose interest right away. The fighting system turned out balanced by the end. No attack turned out to be the best or the worst one, it was more dependent on the situation the player was currently in. It was also really satisfying to see two players’ AI characters battle after being trained because then it becomes more about who the best teacher was rather than who the best player is. I’m pretty happy with how the visuals turned out even though it took forever to make all of it. I think it turned out to be about 180 texture files I had to add to the game. Even so, it ended up looking pretty close to how I imagined it.

What went wrong:

I would have liked the game to go farther, but due to time constraints we had to settle for less. Of course, there’s always the possibility to go further with it after this quarter. Mainly, I was hoping for power-ups or other variations to how two players battle since it would give the players more strategical options. Also, I had underestimated how long it was going to take to do a lot of the art which resulted in many late nights of drawing in Flash and last minute graphics bugs, but overall the essential bits of art for the game got in.

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. 

What went right –

Graphics – I felt I was able to express the feel of the game I was going for through the graphics. They seemed to work very well at conveying the aesthetic.

 Controls – My aim was to keep the controls as concise as possibly so a player could pick up the controls and immediately know how to play. I feel I was successful at doing that.

Menus - I really like how the menus turned out. I feel they not only helped provide a cohesive flow to the game, but also looked very professional.

What went wrong –

Concept – the concept underwent a lot of changes throughout the process. While this can be a good thing, it ended up costing me a lot of time and therefore I was unable to take the project as far as I had hoped. I wanted to add projectiles and powerups but due to my ever changing concept I was unable to devote the time to do so.

Collisions – I was unable to get the collisions working as fluidly as I had hoped. They seem to work correct in the 3D world, however I had issues getting the 2D rotation planes to properly collide with the circles I used for the pawns. Given the chance to do it over, I probably would’ve used farseer.

Sound – The sounds I used I was not very happy with. I am not very good at making sound and I could not find any that met exactly what I was looking for. This led me to be somewhat unhappy with the sound I ended up with.

I wish i could go into more detail here, unfortunately, not having had the benefit of a critique, i can only base this report on my own experiences. I hope, with input from friends, to be able to further improve my game over the course of the summer, and hopefully release it for the creators club launch in october.

Here’s a detailed list of the changes in the new release

* The font in the think bubbles is bigger and more readable

* The think bubble persists longer and it can be recalled by pressing the X button

* Now you select a pill by using the D-Pad. Now you can also move horizontally as well as vertically in the grid

* Updated the title image to reflect the new control scheme

* Added a different tune for the title screen

* When the game is over you go back to the title screen now. Before a new game started immediately

* The position of the frog is now reset when you start a new match

* The pill panel now slides away when it is not needed

* Fixed the foot sliding problem

* Changed the sensitivity of aiming

* Now the game is fully resolution independent

* A fixed problem with the physics of a pill when it was thrown

* Added an additional intro screen with “How to Play” instructions

* Now the selected pill is magnified

Source code available at http://www.cs.ucla.edu/~billyh/AIFighterCode.zip

To play you need a PC, the XNA framework that you can download here

No longer needs Xbox controllers!

Major Changes from the last version
I enabled the keyboard so that users without XBox controllers could play. Many people outside the class asked for this. Additionally, I fixed the crash bugs that occurred in the demo last Thursday. I also fixed some of the font bugs that were visible in the demo.

What worked on this Project?

I really enjoyed working with an artist rather than working by myself, and I feel our game was much better for it. One decision we made early on in the game-creation process was to use source control, and that clearly paid huge dividends, as it was easy to pass work between the two of us, easy for me to develop on multiple machines, and easy to merge our work. We used free project hosting on google-code (with Turtle-Subversion as our source-control client), and I would highly recommend this for anyone starting up a project with more than one person. Even with one person, it forces you to check your checkins and it’s a great way to back up your work.

As far as the game itself, I’m very proud of how it turned out. Most people, on hearing the game pitch, didn’t feel like we would make a fun game or thought that our AI couldn’t be implemented in the short time frame we had, but everything worked very well. There was enough time at the end of the project to add additional modes like AI vs. AI, player vs. player, or single player training AI. Most people that played the game enjoyed it a great deal and got very competitive. I’m convinced that our project was one of the most ambitious and novel games in the class and for the most part we pulled it off well.

What could have gone better?

There were a couple of problems we had working as a team. One of them was that it was difficult pulling everything together for demos or deadlines. For example, my partner checked in art at 6:15am on the final day, but he was unable to test the code changes he made to get the art to work because he only had one controller. Later that day I attempted to fix the two player bugs that had been introduced, but I missed one that occurred in our final demo (in certain types of two player game, we would crash if player 1 won). This was frustrating because I had spent a long time bug searching, but immediately before class I was still trying to integrate artwork rather than bug hunting. I recommend to any team that you get everything checked in a day before the deadline so that you can spend time integrating and looking for bugs in the integrated version.

I’m not convinced the “teacher” mode is the best design element for this game. Some users had trouble using it to train their AIs. On the other hand, I’m not sure what could replace it. There haven’t been many other games like this (Black and White had creature training, and Virtua Fighter 4 had some combat training), so we were in new design space where there weren’t established guidelines.

What about the Future? What’s next?

I would like to get this game running on the XBox in time for the release of free Xbox games. I’ve fixed the problems that I know about, but I need an XBox360 to test it. There’s two things that would make a huge improvement to our game (for both Xbox and for PC); networking and proper save/load. Our current save/load has a number of “slots” or specific files where it saves AI. There should be a way to easily get this to work on the Xbox and (if on a PC) to open a normal “save file to disk” window like a normal windows application, but I haven’t been able to find it. Ideally the game could be networked as well, so one could fight other players on the internet (or XBox Live), as well as downloading/uploading cool AIs that players have created, but I haven’t been able to find good examples of this. These are problems that the Xbox/XNA community has to solve, as I have no desire to write my own networking or save/load GUI software (besides the game dependent parts).

Besides releasing the game on the Xbox360, I might submit it to something like the independent games festival or GDC. With just one programmer (me) and one artist (Erik), its not a incredibly developed game, but I feel like there’s an interest in AI for video games that goes beyond state machines.

The idea for Psychic Construction Company came from the basic premise “Use farseer to do something”.   I like physics based games, such as Crayon Physics, and I feel that the genre hasn’t been fully explored yet.  I thought about real-world physics based games, and the most prominent are things like Jenga, where you stack or unstack blocks, with balance and a steady hand determining who wins or loses.  This led to the idea of a block stacking game.  I wanted the block control to be a little imperfect, so that the player would have the risk fo knocking down their own structure if they weren’t careful; I came up with the idea of psychic characters as a way of explaining this.

What went right

• Development order

I had a very specific development order planned from the beginning, and I think it worked very well: first get single player gameplay working, including physics and controls.  Then get multiplayer up, then do graphics and sound last.  Having singleplayer up early gave me a lot of time to test and change the physics and the control system, which were the two most important parts of making the game feel right.  Doing graphics late saved me from making graphics for things I didn’t need, such as different characters for the different player roles (which I ended up scrapping), different block tile sets for different block types (which I ended up scrapping), etc.  I also felt that testing singleplayer early and finding that people enjoyed it was very helpful for my morale when I learned that multiplayer had problems and needed overhauling.   Instead of being lost as to how to fix it, I knew what kind of core gameplay I wanted and worked towards getting the players doing that again.

• Art + Sound

I’m pretty happy with the art style I ended up developing for PCC.  I knew I wanted things to be cartoony, and I planned from the start to have bobble-headed characters with giant brains.  But the cityscape background, the brick textures for the blocks, and animated hands for the characters were all developed after the initial design.

• Level Design and Level Editor

My initial plan was to just have players race to build a taller tower, but the idea of having multiple levels came up pretty quickly.  I wanted to make the levels very simple.  The controls for the game were already getting fairly complicated, and I didn’t want to add more complexity through level design.  I also wanted to leave a lot of room for players to solve levels in a lot of different ways, so I rejected any designs that I thought were too restrictive.  The + and - goal system allowed a reasonable number of different levels and challenges and made building strategies almost completely open ended.  In my playtests I saw very different solutions to some of the levels, so I consider my design successful.

I wanted to make levels easy to change, so I wrote a ‘level editor’ which takes images and parses them into PCC levels.  The upper left pixel in the image represents the size of the blocks, and then there are pixel colors for green goals, red goals, base platforms, and swinging base platforms.  The difficult part is combining adjacent pixels with the ‘base platform’ color into a single object.  I tuned the level designs very frequently over the course of the project, and with the level parser all I had to do was open up some images in photoshop; it saved a lot of time.

• Hacks

I did a number of things somewhat inelegantly to save time; some of these were good ideas and some of them were terrible ideas.  One that worked really well was the hand animation.  Hands have two modes: swing, in which they are a constant distance away from the shoulder and the arms rotate from one angle to another, and slide, in which the hands are up by the head and slide towards a goal point without any regard for how far away from the shoulder they are.  I initially wanted a ‘real’ animation system where I could draw points at the elbows and everything would look realistic, but to save time I did it in this simplified way and it wound up looking pretty good.

What didn’t go so well

• Farseer

The most frustrating part of the project by far was dealing with Farseer bugs.  Complex 2D physics was absolutely necessary to make my game work, and Farseer was pretty much the only option when I started development.  A full C# version of box2d is being written right now, but it is not yet available for public use.  So I don’t actually regret using farseer, because I didn’t really have another option.   But I do feel that it has a ton of shortcomings, including:

Sliding: blocks constantly slid apart in the initial versions of PCC, regardless of how stable they looked or how strong the friction was.  I eventually added a manual workaround for this, in which I check a box’s position before and after each physics update, and if it moved a tiny amount I ignore the motion.

Setting things static: here’s an odd bug that came up when I was making the ‘freeze’ ability.  If you have a static object (the level base) with two things sitting on it (such as a block and the character), and you set one thing (the block) to be static, then farseer flings the other thing into space.  Sometimes it just crashes intstead.  The fix for this was to set a custom collision handler for the frozen block which ignored collisions with other static objects.

Intersection: this is a bug that still exists, although I made it harder to achieve.  Create a stack of about 10 4×1 blocks, then grab the top block and pull straight down.  Somewhere in the stack, two blocks will slide into each other.  I made this difficult to cause by carefully controlling how hard you can pull a held block, but it’s still doable.  I have no idea what causes this problem.

• Energy System

I didn’t realize just how complicated the gameplay in PCC is until I was writing the ‘how to play’ section.  Which is a lesson in itself, but anyway: most of the complication comes from the energy system.  I introduced energy when I put in block freezing, because I wanted greater control over how often the player could use that ability.  Attacking also had an energy cost, and I added one for block creation to tie the game together better.  Having written up instructions for the game, it seems that energy takes too much of the player’s attention for something that was intended as an unobtrusive pacing mechanism.  The player has to charge his energy, there’s no way to know how much energy something takes aside from trying to do it and seeing if you succeed, and the charge rate mechanics are confusing.  I do plan to keep workin on the game, and the next version should remove the energy system and replace it with a timer for certain actions (like the one currently used for freezing blocks).

• Hacks

Earlier I described the hand animation system as a successful hack which saved a lot of time by dropping realism.  One hack that I’m not happy with is the faked camera system.  Instead of writing real viewport code, the camera change that occurs when a player attacks is done with a translate and a whole bunch of different cases in the draw code.  Aside from making the code hard to read, this also makes it really difficult to change anything in this section, such as adding an animation for moving to the other player’s screen instead of just appearing there.  Writing a real viewport system would have taken a lot longer, but it would have made this part of the game much easier to change.

Conclusion

I think I succeeded in most of my goals.  I made a game which uses physics, which is fun to play, and which has a lot of room for variation between how different players play.  Although there are some things that need to be streamlined, I think that PCC is close to being ready to go on the XNA community games site.   Between PCC and my breakout game, I think it’s clear that my biggest problem when it comes to game design is making things too complex when a simpler design would play faster and be more fun.

(Meaningful change:  Level/Player Select)

The plan for Tanx has always been to create a fast paced kinetic game that is easy to pick up.  I have a great fondness for physics and find that simple physical interactions can be incredibly pleasing.  There is a subtle joy in being able to knock something around.  In my opinion, there is an even greater joy in knocking your friend around.  The goal was to make a game that players could intuit naturally based on prior knowledge of physics, but that a thinking player could excel based on knowledge and manipulation of the physics system.

Generally, I spend a longer than average time in pre-production, trying to set up systems that allow for easy expansion.  I think as a result of this, I have created several socketable components that I can (and am currently) using in other projects, but the overall pace of the project suffered.

Right

• The physical interaction went well.  The kinetic feel of the game is about exactly what I was hoping for.
• The systems I put in place, and the little helper classes I developed, such as the Quaternal Smoother, and the Particle Manager have been useful in several different applications now.
• XML levels/Projectiles/Weapons allow for fairly quick editing of content.

Wrong

• I didn’t go all-the-way on the XML serialization, and some things still need to be referenced in the game code, making it not truly expandable through content.
• No Level editor means that levels are fairly mathematical.
• The slow-start lead to a less-polished game than would have been ideal

In retrospect, some choices I made to do things “correctly” may have taken longer than just getting them done.  In the context of a deadline, the result is a less finished product than could have otherwise been achieved.  As a base for future projects, however, I feel like this game has been a very worthwhile effort.

I knew from the beginning that I wanted this interaction to be at the core of my game. At stage one, I decided that I wanted to make a learning game that, although geared toward kids, would also be entertaining for adults. My goal was to give players the ability to directly affect the progress of their opponents, so I knew early that there would be power ups and that both/all players would share one screen. Adding and subtracting seemed like an obvious choice for a children’s game and frogs just seemed to fit the game best.

What went right…

Simpicity: I knew from past game class experiences that I wanted to start simple. In the past I have set my eyes on a goal way too big for the scope of less than ten weeks and ended up with a pretty unfinished game. So, this time around I started with a simple game that I knew I could code, even if it was in a completely new language…This was the smartest thing I did all quarter. Instead of getting bogged down in details like concentric circles, like last quarter, I was able to set simple goals for myself and see my intended final product by the end of the quarter.

Early prototyping: The simplicity of my original idea allowed me to have a finished prototype early. This made it possible to see what would be fun about my game early on and use that knowledge in the rest of development. Early prototyping also gave me the chance to add extras like animations, menus and sounds.

Playtesting: This was not something I had really done before and it proved to be invaluable in my design process. My playtesters brought up new ideas about power ups and ways to make the gameplay more fun as well as pointing out some bugs and less interesting points in the game, which I was later able to avoid.

What went wrong…

Learning a new language on the fly: Okay, so in the end it wasn’t that bad, but the development could have taken a quarter of the time if I had created the game in a more familiar language, say Processing. I am glad I stuck it out because of XNA’s connection with Xbox Live and the new features Microsoft is providing, but it definitely created some kinks along the road.

Flying solo: I generally prefer to do everything myself, as I have been screwed over a few too many times by flaky partners. I am also very picky and like to do things my own way, so I opted to work on this project alone. I wish I had taken the opportunity to partner up with a CS kid or one of our more tech-savvy designers. This would have allowed me to spend less time debugging and learning XNA basics and more time designing the game play and creating artwork. I am glad I put myself in a position where I was forced to learn at least the basics of coding in C#, but I think the project could have benefited from a more well-rounded team.

In the next few months, I am going to continue working on the project, playtesting and making the game as fun as possible. Then you’ll see it on Xbox  in the fall!