Insight VR

About 12 years ago I had a CS assignment to write an asteroids game called Blaster over the course of a week using OpenGL.  Technically we were using Brian Paul‘s Mesa3D library on Macs that didn’t have any hardware graphics acceleration.  The assignment only had a few requirements, such as 3D asteroids that broke into smaller asteroids when you shot them and other simple asteroids gameplay features that you would expect.  Most implementations were pretty vanilla, as time constraints and performance problems limited what could be done.  Each time the class was taught somebody would go overboard and make a fancy version of the game that performed well, had some particle effects, and perhaps an enemy ship and then give it a name such as Super Blaster.

I started working on my 3D asteroid code first.  While we could simply use a GLUT primitive for the asteroids and get full credit I thought it would be fun to try to write a 3D fractal routine for the asteroids.  That went quicker than I had thought it would and soon I had some very dangerous looking asteroids floating around the screen.  It seemed a pity to shoot them in a 2D plane.

I had recently picked up a freebie Rubik’s cube at a job fair.  Some company whose logo has long ago faded from my cube was claiming that they were only going to hire geniuses and were using a 3x3x3 cube to symbolize that.  I was wondering how to make a compelling 3D asteroids game and staring at the cube when I had a realization:  a 3D implementation would be fundamentally different from a 2D one in how you handle the edges of the world.  In traditional asteroids you can fly to the edge of the screen and you’d pop out on the opposite site.  In 3D with a first person view you still needed to have some sort of world boundary or you’d need a limitless number of asteroids to fill the area.  In order to get the same wrapping effect in 3D I imagined that the world was the Rubik’s cube and my ship was always in the center of it.  If I moved forward in reality all of the asteroids would be moved backwards.  If an asteroid left the bounds of the cube it would “wrap” to the other side.

I coded this up pretty quick and began to play with it.  Then I had another realization:  It takes a lot of asteroids to fill a 3D space.

In a 2D asteroids game if you’ve got ten asteroids on the screen, that is a lot to have going on.  In 3D asteroids if you have 10 asteroids in the world you’re luck if you ever see one, and hitting one doesn’t happen by accident much.  So I increased the number of asteroids a great deal (around 100) and then things began to look like something.  But then I faced another problem.  Shooting 100 asteroids isn’t fun, it is work.  Finishing a level would take forever and would definitely not be fun.  Clearly I needed an objective other than clearing the world of asteroids.  So I put in some enemy ships and gave them some simple AI.  The objective became to shoot the enemy ships while dodging the now plentiful asteroids, which you could shoot if you wanted to.

I wrote this on a 16MHz Mac Performa using software rendering.  Moving all the objects around didn’t create a performance problem, but making the screen very large did.  But it ran fast enough to be playable in a 320×200 window on my Performa and luckily it was graded on a 300 MHz machine that could run it fullscreen at 640×480.

I got a good grade and one of the TA’s even got me into the SGI lab and we did a quick port to an SGI machine.  By quick port I mean about 30 minutes to get the input stuff moved over.  Other than that it just ran, and ran quickly at high resolution.

A few years later I had a ThinkPad for work which had a mediocre graphics chip in it, but that was better than nothing, right?  I ported the game to Windows and suddenly it flew.  I had to implement some timing routines to slow it down to 60 fps.

Here’s a screenshot of it running on Windows:

As you can see I’ve changed the original ship design for reasons that should be fairly obvious.  For those that can tolerate the ugliness of an old Angelfire page you can find a working download of the Windows port and complete source code here.  About that same time I did a quick port to Linux as well.

Now here we are 12 years later and I have more computer in my pocket than I had on my desktop in college.  The iPhone has more powerful processor, more RAM, more storage, and a decent graphics chip.  Once I got a dev kit I began porting the game.  It took about a day to get a stripped down version of it working on the iPhone.  So my college project began its journey from Blaster to being Battle for Vesta.  The main change was the move from display lists to vertex arrays for OpenGL ES.  That didn’t mean that I had something I could put on the App Store, but it meant that rather than starting from scratch I had a core engine around which I could build a game worth putting into the App Store.  One thing worth noting is that the bulk of the code is still C++.  I have yet to learn Objective C and really didn’t have any need to do so for this project.

Several weeks ago I ported the iPhone version over to Python.  This involved a lot of searching and replacing to remove the C++ syntatic sugar but didn’t require an substantial changes to the OpenGL code.  That effort took about 8 hours and allowed me to quickly experiment with different collision detection optimizations in Python, which was much easier than doing the same experiments in C++.  I’ll admit to having become a Python bigot and that my C++ skills are not what they once were.  Having a Python port also allows me to use my strange pySight and wiiMote stuff that runs in Python to control the game.  That version runs on Mac, Linux and (I assume) Windows.

Now imagine if instead of OpenGL (ok, Mesa3D) we had used some early version of Direct3D for my graphics class.  Not only would everything I wrote have been deprecated five times over by now and what platforms would it run on?

There really is something to be said for open standards and libraries built on those standards.  While there isn’t enormous value in an ultraportable 3D asteroids game the same principles apply elsewhere.  If you are writing something that is going to have a useful life beyond a couple of years you should consider carefully the core technologies that you use to build it.  Don’t be distracted by buzzwords and whatever the most recent flash in the pan is.  Even if what you are working on seems like a throwaway code, writing it for portability can allow for opportunities that wouldn’t otherwise be available.

For the curious here’s what it looked like on the iPhone at version 1.0. Now it has some textures to liven things up. [EDIT:] I’ve lowered the price today to $0.99 in case anybody wants to try it out on a whim.