Asp Engineering Retrospective

Asp is mostly finished by now. All that's left is to finish and include the illustrations that form the storyline of the game. Download the current story-less version here.

This game is certainly my most polished and well-built yet, but that isn't to say that I didn't make some big mistakes during the programming process. So here's a retrospective on what went wrong and what went right.

Technical Design

Having already built Squadron, I had a decent idea of how Asp would be structured. One of the first things I did when starting to build the game was draw up a list of all the classes I would need. I tried to make good use of inheritance so that I'd end up with clean and concise code.

I did make a few mistakes in this early process. For example, I hadn't anticipated needing separate classes for player squads and enemy squads; adding these two classes unfortunately involved a lot of copy+pasting. Similarly, I didn't include a PlayerShip or EnemyShip class, so each of the individual ship classes (e.g. pFighterShip) included very similar code. Still, if the only big issue introduced by these mistakes was repetitious code, I can't complain too much.

I also used some tools of Java that I hadn't needed before when I was just slapping code together until something worked. Abstract classes, enums, generics, and other features were extremely useful in architecting the game.

Programming Process

Asp was built in Ubuntu Linux. My tools were gedit and javac. I really should have used a more powerful environment, such as Eclipse, but I was comfortable with formatting my own code, and I generally kept things clean. My only big mistake in writing the code was putting so much in a single main file. The classes were all managable and orderly, but the main loop and initialization code ended up taking almost 2000 lines of code in one file.

I started Asp during a one-week spring break, and I finished the basic systems by the end of that week, i.e. ships were flying around and shooting each other on my commands.

With most games I've stopped there, but I really wanted to make Asp more complete and friendly. In between college classes this past term, I've expanded Asp to include a lot of small polishes (minor ship movements, particle systems, etc.) and a few more important elements (a menu system, a tutorial, a campaign, randomized skirmishes). Adding these elements took a lot of time, to my surprise, but I'm satisfied with the final product.

Hurdles

I occasionally hit a few problems that couldn't be fixed right away. Initial playtesting required that I make some UI changes, and I had some strange issues with loss of color depth in Ubuntu (the latter disappeared with Ubuntu 8.04, after I had given up on it).

By far my most problematic and difficult issue, however, was performance. Even when I commented out all of my main loop code excepting the drawing of my background, the game would crawl at about 20 FPS, barely playable. On my Windows machine, it would sometimes drop to as low as 6 FPS.

I did a lot of research on Java 2D graphics and performance, and I learned quite a lot. I was introduced to VolatileImages, managed images, the limitations and advantages of different Java graphics methods, and more. It's unfortunate, in a way, that I had to learn all of this since Java works so hard to keep the programmer from having to be concerned with it.

After much experimentation and asking for help on the Sun Java forums and Javagaming.org, I was able to get marginally closer to my goal. The problem was certainly that some images weren't being hardware accelerated for some reason. At first I thought that the issue involved some images (like the background) being too large, but other large images, as well as many small images, were still fast.

I continued experimenting until I eventually discovered that, while I had correctly created my images such that they should be accelerated, I had overwritten them when I loaded my images from files. The unaccelerated background images had not been touched since then, so they slowed down the rest of the game. The issue was fixed and the game runs comfortably at over 60 frames per second.

Lessons Learned

Design for your specific game, but also design with flexibility in mind.

Keep code files compartmentalized and of managable size.

Use powerful tools when available and useful.

Fix major issues when they first appear; waiting will just make it harder to deal with them.