Backed up from a local Blogger export (114236197490365970/114236197490365970.html) on 2026-01-01.

Bloggers image upload is broken. For now the the images are still hosted at flickr.

Last weekend a few friends got together for a game hack party. Nothing too formal just sitting down and working on some game ideas. The idea was to use scripting languages to build the games. I feel that the success of the projects that we undertook had a lot to do with this choice.

I’ve been pretty addicted to ruby since I picked it up recently and so I was pretty determined to build a game with it.

People started showing up between 2 and 3 and after eating some food and chatting it was time to get down to business. John decided that he wanted to work on the game with me so we started brainstorming. We both are interested in board games, tactical rpgs and sci-fi so it comes as no suprise that we decided to put together a little turn based space game.

John is well versed in the lingo and logistics of interstellar warfare so I let him drive a lot of game design. I focused on asking the correct questions and focusing these ideas into a working game.

Quickly I had drawn a sample game board and some units on the whiteboard.

We drew up some tables for unit strenghts, sketched out the flow of the game, round and turn transitions and talked about how combat would resolve.

At this point John had never written a lick of ruby so I worked with him directly to begin defining the game. Step one was the game model. I coded up the game base classes: Game, Player, Location, Unit, Weapon, Defense, AttackType, DefenseType. Once we got this out of the way John went off and started creating tons of different weapons, ships and defenses. I wrote a game loop driver to test the turn logic and make sure the basic objects were working together then I went off to write all the graphics for the game. It took a few hours to get this stuff pounded out. I basically just created the units out of 2d primitives. I created a selection cursor and enabled the user to select and move units using a simple arrows and spacebar as selector control scheme.

John’s wife Leslie had some dinner waiting for us at their house so we went over there ate and I spent some time writing a zoomer that would interpolate scale and translate of the board to a selected unit. This was supposed to be for the unit information HUD but I ended up scrapping it. It still looked pretty cool though (you can press ‘I’ on a selected unit to zoom in on it). The fact that all the units are vector based and not little sprites makes this look really cool.

After this we quickly got the HUD working showing unit stats: hull strength, movement points, arament and owning player. John and I worked closely on this part of the project quickly iterating features until the game was playable.

At this point we could spawn whatever ship we wanted on our turn and use it to attack the other player. The weapons that John created were great: Tactical Nukes, Microwave Lasers and Auto Cannons.

What went right

1 Using ruby for prototyping This was an awesome language for a project like this. We were able to use very clean object-oriented code to easily visualize the game. The keyboard handler took a hash of key ID to blocks of code which made adding new keyboard logic super simple. Since we weren’t using source control it was great that ruby allows you to write new methods in a seperate file that are added to an existing class. John could iterate on his battle mechanics adding methods to the Unit class while I was cleaning up the Unit movement in game.rb. As an experienced programmer John was able to get productive in ruby under an hour.

2 My graphics extension to ruby ‘RubyCube’ I had spent some time before the party closing the gap in terms of game programming for ruby by writing a very high-level graphics programming extension that hid all the low level details like movement, updating animations, render queue etc. This made it super-simple for me to write all the graphics code in a few hours in ruby.

3 Pair programming John and I worked very closly in this and picked each others code apart. We were able to catch tons of little problems in the game logic just by sitting down for a few minutes and writing code together.

What went wrong

  1. Wasted time on polish like the zoomer I spent an hour working on this code without even ending up using it.

  2. Using a non-compiled language It was often very painful to know if some branch of your code would break because of a mis-named variable or other small error. This made testing each feature interactively and right after it was written very important. However, in a game things get complex quick and as more code started to interect we ran into more and more problems. We probably spent the majority of our time fixing little errors like this in the game logic. It would have been really nice to have a ruby lint type program to find all the little misspellings.

  3. Only working on the game for 12 hours If this was one of the 24-72 hour game competitions we could have gotten a lot more done like this. I think with more time this game could be even more fun.

Conclusion It’s a great feeling to have a finished game up and running in so short a time. Having a game prototype up and running that exercises the milestones of the game design something that I will continue to do in the future, even if the game will be re-implemented in C++. It’s great to have free tools like ruby to do this. I’m looking forward to the next opportunity to do this type of rapid game programming.