Thrust

Recently I revisited an old BBC Micro game from the mid 1980’s that I used to enjoy playing as a kid, called “Thrust”. It was a fairly addictive game with a simple concept: fly your ship, pick up a ball and with it, exit the planet.

What could be simpler?

Reflections

Being home alone at the time, having not played Thrust since goodness knows when, I registered and reflected on what a nice bit of work this was. What was evident is that Thrust assembled (excuse the pun) a collection of simple concepts, but executed them beautifully. (Those in the know will appreciate only too well that the author, Jeremy C. Smith, later went on – with Peter Irvin – to write the technically astounding “Exile”, again for the BBC Micro.)

Most notable about the game at the time was its application of physics – your ship had mass, the planet had gravity. So as you fly around the landscape you get a feel for a simulated physical environment. But the elegance of this model starts when you pick up the ball, for suddenly your ship and the ball are connected by a fixed rod. And the ball also has mass. And the ball is also subject to gravity. And you have to start manoeuvring your way through the landscape carrying this heavy, connected object. In a screen full of pixels, suddenly these two abstract images feel real…

In a screen full of pixels, suddenly these two abstract images feel real…

So here is a relatively early example of physics simulation in a game and, interestingly, using a software modelling process that still sits at the heart of many a rag-doll physics library. And all done by one person, in a handful of kilobytes, written direct-to-metal on the 6502 processor. Quite simply, the more one considers how this must have been built – especially as one digs more into the game itself – it becomes increasingly clear that this really was an understated and impressive bit of work.

A Prototype

After having played it, I wanted to have a quick try at the maths/physics of the underlying model, just to see if I could appreciate how the central element of the game “stuck together”. Opting for a rapid development pairing of HTML5 and Javascript (and being an expert in neither), I was able to read and write at the pixel level to a canvas that was fixed to the original resolution of the BBC Micro version (320×256), albeit with the luxury of 24-bit colour rather than the 2-bit (4 colour) MODE 1 setup that Thrust was originally written for.

As it turns out, the modelling is actually very straightforward and I was able to get a ship and ball flying around the canvas and connected by a fixed rod in about an hour. The trick, if there is one, is to use the Verlet integration method for modelling the movement of both ship and ball under gravity, with the fixed rod simply constraining their movement. Note that the fixed rod is simulated in Thrust as precisely that – a fixed rod, like a steel bar. (It would of course be possible to extend this concept slightly and have a more elastic/string-like connection between ship and ball by coupling many smaller fixed rods. It is likely that this thought crossed the author’s mind, but likely the technical constraints underlying this precluded further exploration in this area).

Completing

And having got that far, that’s where I had intended to leave it. But for no particular reason, the underlying concepts of the game continued to be interesting, and after three weeks of snatching an hour here, half an hour there, the proof of concept blossomed (very coarsely, and in an uncontrolled manner) into pretty much a full reconstruction of the original. It runs in browsers (your mileage may vary with Microsoft environments, for which I make no apology) and if you want to give it a quick go, it can be found here:

http://www.abbeycatuk.info/thrust/public_html/

(Keys are: A/S to rotate left/right, SHIFT fires your thrusters, ENTER fires a missile, and SPACE activates your shields/tractor beam to pick up the ball).

The source code, crude as it currently is, can be found here and is licensed under MIT conditions:

https://www.github.com/abbeycatuk/thrust

Of course it should be made clear at this point that, for reasons of clarity, this was re-engineered from scratch without looking at the original source code (that much should be obvious just by observing the state of the source). And that there is no intention of this being used in any way for profit. Respective copyrights and so forth remain with the original holders. In short, I’m not looking to get sued on this one.

On Efficiency / Elegance

But this isn’t where the story ends. Because, as mentioned already, the source code produced here is woefully inadequate to what was produced in the original. This, as a matter of fact, is a sterling example of how incredibly wasteful and lazy we are allowed to be with modern systems. At no point was there any concern about dealing with floating-point (or at least fixed-point) values in 8-bit registers. The screen redraw routine is blissfully simple – it just redraws the entire screen every time (whereas the original code had to be very clever to draw precisely what it needs in order to maximise efficiency, something which directly influenced the graphic “style” of the landscape because hardware scrolling was not employed). The “particle” subsystem in the code just adds particles into a boundless Array. There was no requirement to worry about how much memory any of the code was taking up. And so on. And so on.

So to repeat, by comparison to the original, the code I offer here is shockingly poor. Shockingly poor. Do not let this amateur “hack” detract from the elegance of what Jeremy C. Smith put together all those years ago. Perhaps over time I will come back to this – I hope I do – and revisit the underlying technical aspects of it and spend some time re-implementing it with a view to demonstrating how compact and elegant it can be.

But then again, having rebuilt it, I’m still trying to complete level five. So perhaps just one more go, before I open up the source and get to work…