A Case Study in Building a Codebase - Part 1

One of the first things any programmer worth their weight in code knows is that re-usable code is key when moving from project to project.  Unless you are extremely anal about your code, odds are rewriting similar pieces of it for differing projects will eventually get to you.  In fact, there should be some kind of annoyance in rewriting the same pieces of code over and over, evolution of anything, whether it's the wheel, computers, or even code, is essential.  And, of course, no one likes someone who re-invents the wheel.

The Situation

A few years ago I developed a project that has taken me years to develop, Pong.  Wait, wait!  Don't stop reading just yet!  Just because Pong has taken me years and years doesn't mean I haven't been dilligently working on a solid project.  So why, did Pong take me so long (blogRhymeCount++)?

First let me discuss the design of Pong.  Actually, the name of the project was PongRPG and it was a blend of Pong and RPG elements.  For example, each match the player would play would earn them experience points (XP) based on how well they did.  Every 100xp the player would level up and earn points which they could distribute between different skills such as having a longer paddle or more health (HP).  See, instead of a traditional score counter at the top of the screen, each player had a HP bar and if the ball entered your goal, you lost some of the HP.  Also, at certain levels the player would unlock magic they could put into the ball (such as doubling the amount of damage done on a single score).  Finally, there were different types of 'armor' the player could equip to their paddle to lessen the amount of damage done to them per score.  Needless to say, between the sheer amount of menus, content, and other general gameplay development (not to mention I also created ALL the art assets) it was quite a large project.

Codebase 1 - Prototype

As most beginner developers tend to do, other than the general game design, little thought was put into the code design.  Sure, I knew the ball and paddle could be classes, and I would be using XNA Game Studio so drawing to the screen and everything else was practically done for me already.  It was damn near only a few hours at most from the time the initial Pong idea popped into my head that I had started programming.

After some months of work I finally had a decently working game.  The game included the following:

Man, that game sounds awesome, it probably was perfectly coded and bug free!

Sorry, but no and no.  Forgiving any AI or collision bugs due to my beginner code in both areas, there was plenty more wrong with the game.  At this point, I was so sick of developing it, I released a version on my website and ran into one of the biggest problems of the game.

I utilized a library XNA GS had included that would allow you to see an on-screen prompt, similar to the Xbox OS, so players could enter their save slot name.  Unfortunately, at the time of development/release, this library was not included in the XNA redistributable, meaning to run the game you needed to install the following:

By developers, for developers, am I right?  Absolutely not, this was the first major failure of PongRPG.

Second, after a few months of clearing my head of the project I ran across the XNA Platformer Starter Kit which is pretty much a fully built 2D platformer that showed off some nifty stuff XNA could do.  The one item that caught my eye was the fact that the levels were loaded through a simple text file.  Pretty much, the engine grabbed the text file, parsed out the characters, and matched the character to a map containing that character and the related texture.  Since the text files were loaded at runtime and didn't need to be compiled (like most content in XNA) you could simply update a single character in a text file to change one enemy from a zombie to a monkey.

In contrast, the code for PongRPG was 100% hardcoded to the content in the project.  For example, there was at least 1 line of code for each sprite that specified what textures to use, the sprite position, scale, and rotation.  Each sprite also contained a unique String handle that was assigned here as well.  In later code, when I wanted to move the player, instead of updating the player objects position (like a good programmer), I specifically called each handle and updated it.  This lead to hundreds of lines of extra code that could have been handled by an iterator over objects with sprites loaded at runtime.

PongRPG needed to change; we can rebuild it, we have the technology.

Continued in Part 2...