// caseydunham.net

For the past two months I have been happily playing the Beta version of QuakeLive, Id Software’s newest release in the Quake universe, which is moving to an open beta this Tuesday . I have been a big fan of the Quake series since Quake I and have been having a lot of fun playing the current incarnation in the Quake universe. QuakeLive is free to play and only requires that a browser plugin be installed. The game is run from within the plugin and requires you to log into the quakelive site. All of your statistics are tracked automatically and are used to determine what tier you are placed on. I don’t know all of the particulars of the skill matching system as it has been slightly adjusted over the last couple of months but for the most part it has been matching me against opponents who are about my skill level.

I would encourage everyone to head on over to http://www.quakelive.com on Tuesday to register and begin playing.

     I just finished packaging my remake of Tetris, aptly called Orb Drop which you can find here and I wanted to touch on a few things that I thought went well in the development (more like redevelopment) of this game, as well as a few things that I thought could have been done better or done differently. I have had this code lying around for quite some time so it went through many changes from a simple prototype to what I am presenting here.

The Good

     The first thing that comes to mind is getting Visual Studio setup to work with my directory structure and to place files in the places that I wanted them. Getting source control involved, via svn, right from the beginning was also a good idea. Knowing that I could refactor quite a bit of code and if I didn’t like it or if I broke it, could revert back to a working copy was definitely worth having it. It is also just a good idea in general especially when working across multiple computers.
     Using SDL was a big plus. I don’t know why I would use anything else for developing cross platform games. While I didn’t get a build for anything but Windows, it shouldn’t be that difficult to get it built on Linux or even OSX.

The Bad

     While I said that I thought it was a good idea to spend some time setting up Visual Studio, in the end I just don’t think it was worth all of the effort. I spent the better part of an afternoon getting the macros correct and making sure that both the Release and Debug builds were both setup correctly. In part this was because the directory structure I wanted was going to support building on Windows, Linux and OSX. However, I never got around to fully working out some issues in the Linux build setup and never even got to touch the OSX setup at all. This is a case where I didn’t really apply an iterative process to the build system like I tried to the actual coding.
     I also think it would have been better if I just used a cross platform compiler right from the beginning, like Code::Blocks. I am going to look into using this more for future projects.
     Not building this for Linux was a big black eye as well. I may come back in a few days and try and work out a few of the problems, but I don’t know if I will spend the time. All the code should be cross platform it is just a matter of setting up the build environment and getting an executable.

The Ugly

     I am not too fond of the code. There are a few places where some decent design is showing through but it is marred by horrible choices in other parts. I refactored here and there during development, but there are still a lot of parts where I feel like I could have done better. There are also a couple of bugs that are in there due in part to not redoing portions of the code where it needed it.
     Not documenting. I am currently looking into Doxygen and playing around with it. I didn’t document the code at all because I thought what would be the point since a lot of it would most likely change and I didn’t want to update documentation whenever I made a change. I should have found an equilibrium between keeping the code documented at a high level (relationship of classes etc..) and making it maintainable. This is definitely going to be a first step in my next project.
     My last big gripe involving this project was handling images and sound. First there is no sound. That was just laziness on my part as I was kind of getting sick of this project. The images are all handled in the most naive way being stored as single files. It increased the overall file size of the final compressed deliverable and is just not a good way at handling these things. It also made loading the images awkward and error prone. These issues are all being addressed in my next project.

Summary

     As I said, this project didn’t turn out as well as I wanted but I also can’t just keep pecking away at it, I just don’t have the time. I learned that the last 10% is really the hard part. Getting a project polished enough to even resemble a complete game is hard. It is made easier if a bit of time is spent up front on defining what will constitute a finished game and plan for some of these things from the beginning. If I had spent another afternoon on the state system, a few of the problems in architecture I came across, would have been easier to take care of. I also had a few ideas that I wanted to implement to make it less of straight remake, but again, I was using some code that I had written over a couple of years ago and getting the changes incorporated would have been a big task, I should have just started over from scratch.
     Overall the most important thing is that I learned something from this endeavor. I have since been working on another project where I have or am currently fixing these issues that I came across in developing Orb Drop.

Please stay tuned and I hope you enjoy this!

As mentioned in my previous post, I was attempting to work out a couple of issues in the design of Orb Drop. I was having problems incorporating the state system into the current framework of the game in a way that I was pleased with. I pulled a lot of the code out and began experimenting with it trying out a few ideas. I am going to continue the development of this framework while finishing Orb Drop and another smaller game. I have found that working on the reusable components while creating small game prototypes or demos is a great help as it makes it easier to see where you need abstractions and how your components are actually coming together.

As far as Orb Drop goes, I don’t think I am going to refactor any more of it, instead just fixing a couple of bugs and packaging it up. I would like to move on from this and work on my other projects. I will of course put the source code up for it as well, but like I said previously I am not too happy with it. However, I learned a decent amount from working on this game which I think is the most important thing.