Squadron Scramble Redux

I’ll apologize to Brandon first for writing this because I am sure when he reads this blog post he will roll his eyes or puke at the thought of me brining this up.

My junior CSU670 “Software Development” class with Matthias Felleisen at Northeastern will forever be one of the most tortuous ordeals I will have ever lived though – but also probably the most rewarding. To this day, I still wake up from nightmares of me sitting at one of the Solaris boxes in the CCIS computer labs talking with other classmates and they ask me what other classes I am taking that semester; lo and behold I can’t even remember one of the 3 or 4 other classes I am supposed to be taking that semester, all I can think about is Software Dev and that I LIVE in this computer lab!

After passing the class from hell, a few of my friends and I made a pact of sorts that we would (one day) continue on with our code from the class and improve on it, because it really was probably one of the largest projects we had ever worked on.

If you have never heard of Squadron Scramble, no worries, I don’t think anyone in the class had ever heard of the game either. It’s a rummy style game but you use aircraft cards with aircrafts from World War II (oh, so appropriate since our professor is German.) Our class rules were modified from the original game, but the basic premise is that you collect three of an aircraft type and can use that to “shoot down” other aircraft trios with a few other wild cards thrown in for good measure.

We were required to pick a programming language and work in pairs and practice paired programming. I had mixed results in past course with paired programming but in this course it was absolutely critical that you have a well functioning team to carry out each week’s assignments, otherwise you would be behind for next week’s tasks because every week built on the weeks before it.

The tasks finally built up to us creating our own game server and administration as well as clients to connect to our server and other student team’s servers. We also had to create dumb artificial intelligence and come up with “player” strategies to try and beat each other with our “players.” And this was all using ugly XML syntax and we were only allowed to use the aging and severely out-dated Solaris machines. We also had to come up with a GUI interface, and did I mention that yes, it all had to work on the grossly out-dated Solaris machines?! That means using Tcl/Tk instead of all the new flashy goodness of anything else developed within the last decade.

With that said and done, my buddy, Ventz, asked me earlier this week if I had time to develop a Ruby client and server and bring the project back to life. My one request was that instead of XML we use JSON instead to make our lives easier. He was going to take a stab at re-writing a Perl version of the code and hopefully get a few other ex-CSU670ers to chip in a Java version and whatever other version they’d want to contribute. My first task is probably to write out a proper spec and improve upon on some of the universally despised guidelines in Matthias’ original spec.

If you’re interested in seeing the final code I wrote in the class, hop on over to my Subversion repository: http://svn.rachelober.com/csu670/ I think this is pretty much the final version of the code that I submitted in the class. I’m almost certain this will not run on anything unless you can get your hands on one of CCIS’ old Solaris servers (which have since been “taken out back” and summarily assassinated,) but I’ll add a disclaimer anyway that the code is provided “as-is” and under no warranty. If it screws up something on your system when you try to run it, sucks for you!

Maybe one day we’ll get some kind of game server to run and we can all play some crappy aircraft card game over the internet.