Investigating one of my favourite games from 1985

The first computer in our house was a 286 Intel PC. It was more than enough for my father’s PhD word editing needs, and could play a handful of games.

I started playing Spacewar probably around 1991. It was a simple space shooter, but was quite feature rich for its day.

Title screen of SPACEWAR via DOSBox

You can have two robot player, that played in different styles (one more offensive one more defensive). It had both torpedoes as well as phasers, and gravity.

I remember thinking on the 286 that the animations was quite smooth, as CPU bound graphics went back then.

War, in space

Peeking behind the curtain

I thought that using Codex I’d be able to reverse engineer erm, investigate how the application works, and get an idea of the architecture.

I didn’t know about this, but DOSBox comes with a debugger where you can do debugging type things: set breakpoints, set memory values, and poke around.

Also, the US government gave a helping hand in this investigation as well… The NSA publishes a reverse engineering tool called Ghidra, that Codex helped me setup, and run on this ancient exe, to get an idea of how it all fits together.

Highlights of what was found

The game was most likely hand written assembly app that was purpose built for the PCs of the day.

The defensive robot player doesn’t ever fire torpedoes. It aims for incoming torpedoes with its phasers and if the other player is close enough, fires at it as well.

The robot player doesn’t honour the cloak of a player, so always knows where its (freaking cheater).

The game world is wrapped (torpedoes and phasers can shoot over the edge of the world, and then will go to the other edge) but the robot players are not aware of this. (So you can shoot the robot from the edge of the game, and they won’t see it coming)

The stars (512) are always rendered randomly at first startup (menu and gameplay).

The gravity function is linear towards the centre (if enabled) so it isn’t very realistic. (This isn’t a fair criticism, as this wasn’t ever intended to be a space simulation in that regard. It was probably the right tradeoff given the available CPU time for each calculation refresh.)

Full investigation docs can be seen on the github repo.

Wait, what if we just change gravity?

I then thought, what can we change in the game?

If the gravity calculation is “wrong” why can’t we just update it? We have the exe, and a good understanding of how it works. Why can’t we just update it? Just a bit?

The bad news is that the exe has a fixed size in the executable header. The good news is that it is easy to change. The bad news is that we can only change it to a point. Apparently the olden days had weird limits on things that we completely take for granted in the current crazy time of 2026.

Luckily the exe ships with 108 empty bytes inside the exe. I’d guess this was reserved space for future expansion.

That futre has arrived.

So to make the gravity calculation more accurate, we can just overwrite the existing simple linear calculation.

It ended up being a still simplified, but slightly more realistic calculation:

New gravity: Yeah!

Old gravity: boooo!

My approach for the actual edits was to generate a Python script to modify the original executable with the new instructions. After modification Codex and I ran the debugger to verify that the behaviour is as expected.

I’ve only explored two of the edits to the binary, and I must say the results are quite good so far.

The power of the tooling

If I had to do this investigation without Codex I’m pretty sure it would have taken weeks to months. So far it has been about 3 days over two weekends.

The skill that I think is quite important these days is to keep the LLMs focused, and on the rails. If you give them enough constraints and a clear goal, then you can go really fast.

Slow is smooth, smooth is fast

(I was using 5.6 Sol for this work running Codex in VSCode)