// caseydunham.net

This past weekend I took part in my first Ludum Dare competition, Ludum Dare #15. Ludum Dare is a community driven contest where a single developer has to create a complete game within 48 hours.  I have watched the prior competitions, but have never really had the time with family and school, so I was a bit surprised to find that last weekend was fairly open. So on Friday afternoon I decided I would take part.

Each Ludum Dare has an associated theme that the game must be created around that is decided on by community vote. The theme is only revealed at the start of the competition and for LD #15, the theme was “Caverns”. I immediately had a few ideas but nothing that seemed too out of the ordinary. Upon deciding to enter the contest, I also made up my mind that regardless of what the theme was, my goal was to complete a game, no matter how simple, within that 48 hour deadline.  I did complete a simple game, but as usual with these types of competitions, didn’t quite turn out as I had hoped. This is an effort by me to talk about some of the things that I feel went right in the development of Coffee Caverns and what could have been done better.

The Good

Probably one of the best choices was to use what I was already familiar with, C++ and SDL in a Windows environment. I know that some people like to experiment with new technologies during these competitions, but I decided to not risk it, my goal was to complete a game. Along these same lines I also decided that whatever I did would be small. I have started and never finished numerous game projects in the past much like every other aspiring game developer and I also know that one of the things that separates aspiring game developers from game developers is that game developers finish things. I had a decent idea of the scope of what I would be able to finish and decided to stick with it.

I didn’t start coding or designing anything until the Saturday morning after the competition started. I checked to see what the theme was going to be and than went to sleep. In the morning I ate breakfast and started a bit of mind mapping while having some coffee. I started thinking about caverns and I kept coming back to danger and falling, falling objects like rocks, and than somewhere in the mind map coffee came up so I ended up mixing coffee with falling rocks. Awesome, sounds a bit weird let’s go with it. It came naturally that this would be an arcade style game and once I decided on it I stuck with it. The total design of the game was probably about an hour and that was with sketching a bit of a development plan as well.

I also liked that I was able to get a couple of sound effects in thanks to the wonderful program Sfxr. I am glad that I got the title screen in without too much trouble as well. It only took a little bit of trouble and was I think worth it. Although next time, I am going to check for a specific key press to transition as opposed to any key, it made taking screen shots of it a bit tricky.

The Bad

I think that my biggest mistake was not getting the prototype up and playable as fast as I wanted to. My intention originally was to use primitives for prototyping and later put in the graphics. By the time I had the framework ready I needed a break from coding and decided that I would play around with Paint.NET a bit to see what I could come up with. I should also mention that other than SDL, I was using no prior written code, writing everything from scratch. In no time I had created a couple of graphics that I thought would work, so I figured I would just drop them in. It wasn’t a huge time waster since I was going to do it anyways and in some ways did work out in the end.

The Ugly

Easily the worst part about the game and what I would argue is the game, is the game play itself. The game is no where near as balanced as I would have liked it to have been, the scoring is very simple, and there is very little feedback to the player. I spent most of Sunday doing game play testing and bug fixing. I had the majority of the code written by Saturday night and it was a good thing too as I had a few things come up Sunday that might have kept me from finishing otherwise.

The little things that I didn’t fix that were pointed out to me in comments on my Ludum Dare blog are in retrospect what could have made the game better. The player sprite being about a pixel off during the animation would have taken me all of about three seconds to fix. I also never got the score out of the title bar like it should have been. This would have been another easy fix that would have added to the polish of the game.

The other thing that people complained a lot about was my use of an installer. I had mixed feelings about it but I know and understand the irritation I am sure it caused others as I started reviewing a few of the other entries. At a certain point I was annoyed that I had to unzip things and will next time not bother with the setup and provide a straight running executable.

Summary

Overall the whole competition was very rewarding and I learned quite a bit as well and would recommend everyone who is interested in game development to take part in these competitions as often as they can. I am definitely going to!

     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!