// caseydunham.net

     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!