At it again

Hello,

It has been a while. I recently found some time to work on this project again. Feel free to play around with what I have so far:

https://s3.amazonaws.com/files.phred.ws/asterax/index.html

Currently you can use the left and right keys to rotate, the up key to thrust and space key to fire. You can type the 'F' key to toggle "full screen". There is no collision detection yet so the ship and its bullets go right through asteroids right now.

Feel free to leave comments detailing any issues you have with this demo.

Platform Change... Again

So here we are starting a new year.  I've switched platforms for what I hope is the last time before I get something out and completed.  Because of the awkwardness of deploying the app with macruby embedded in the app, I have decided to go with an SDL on Objective-C solution.  This seems like a good mix of object-oriented language that still compiles and creates a reasonably sized binary.  I am now further along with this implementation than I have every been with any other.  I have asteroids and a ship the flies around!.  I'll post more on my progress later.

Initial platform: MacRuby

I have made my decision.  The initial platform will be Mac OS X (probably >= 10.6 for now).  I am going to use MacRuby to develop this game.  One of the reasons I want to do this is to be able to create a focused polished game.  Even though I am going to use MacRuby, I would like to develop the game with the idea of porting it to other platforms later.  This will lead me to separate the game logic and the like from the UI and platform details.  If it makes sense, maybe later I could hook into another platform library.

Ruby

Since my last post, I have researched some ruby options.  It looks like MacRuby could be a good solution.  There is a way of compiling the ruby code and creating a stand alone application with it.  Problems with this are the size of the resulting application (> 50Mb) and that it would only work on a mac (and possibly only >= 10.6).  I also found a library/gem for ruby for game development that would allow me to deploy on linux/win/mac called Gosu.   The negative for this option is that I would have to work on different deployment strategies for each platform, but it would be cross platform.  Also, the gosu option would not including compiling of the ruby code.  Another possible solution is RubyGame.

In search of a platform

With this post, I will bring you up to speed.  My current dilemma is deciding what platform to develop the game on.  I have what appear to be conflicting goals for the platform that make it difficult to find one platform that is exactly what I want.  I have worked with SDL on other projects in the past.  I spent some time working with Slick for this project as well.  I even tried Qt.  My most recent foray has been with the HTML5 canvas element.  I have acquired experience and knowledge from working with each of these options, but also I have used up a bit of time with no product to show for it. My next goal on this project is to weigh my options and decide on a platform.

Most of my daily programming is in ruby.  I have spent time working with C/C++, Objective-C, Java, and many others.  One of the deciding factors for me will be what language I will use to program the game.  For my canvas trial, I used JavaScript, for Qt,  C++.  SDL is written in and most native in C but offers many bindings to other languages.  Slick is a library for Java.

I ruled out the HTML5 canvas option for several reasons.  Sound would be a problem and responsiveness was noticeably distracting to me.  I also noticed a occasional but semi-consistent lagging and the smoothness of the graphics rendering.  While it offered many great pro's, I don't believe that that platform is quite far enough along to use at this point for this game.  I will continue to watch this platform with interest.  For the curious, my father pointed me to a really neat project that aims to allow you to build desktop and mobile applications with web technologies and I had hoped to use it to make my game both downloadable and playable on a website.

I also ended up ruling out Qt.  The thing that I liked about Qt is that it had a nice GraphicsView widget that supports a view hierarchy and collision detection as well as the ability to be backed by OpenGL or software rendering depending on if OpenGL is available.  However, the framework must either be bundled or installed by the user and it is quite bulky and I would only be using a small portion of it.  I also had trouble styling the GUI to look like the original Asterax game.

In my next blog entry, I will go over what I see as my remaining available options and weigh them.

Extracting the graphics

The main work that I have done so far that is durable is extracting the graphics from the resource forks of the game files.  This turned out to be more work that I expected.  I wasn't able to find a simple way to save the images in a modern format.  My solution was to use a outdated trial/beta version of Resorcerer that had been carbonized, so it runs on Mac OS X to load the images.  Since it wouldn't allow me to export the images, I took screen shots of strips of the images.  Then I wrote a ruby script to automatically load up the strips and extract the images based on a map of the sizes I fed it.

I now have the graphics extracted into png format so I can move on with development for the most part and save getting the sounds for later.  I have a copy of AudioHijackPro, which I am planning on using to record each sound as I play it in Resorcerer and then cut in up in a audio editing program.

Taking stock of resources

I was thrilled to have permission to port Asterax and sent off an email to Michael.  He responded with official permission to port the game to any modern platforms I wanted.  During the conversation on the phone, he told me that Anne Fullerton, the graphics artist behind the game later became, Anne Hanson (his wife!).  They both are fond of the game and are excited to have it modernized.  He offered to look for The graphics were originally rendered from povray.  Michael offered to look for the source code and povray files but was unable to find them (unsurprising really, considering that it has been more than 14 years since it was published).

So, I need to take stock of my available resources.  He mentioned that, typical of classic mac applications, the sounds and images were stored in the resource forks of the game files and application.  So, I have no source code but I do have sounds and images available.  I also have a couple old macs and the SheepShaver classic mac emulator, which will allow me to play the game for comparison along with taking screen shots and screen caps of game play.