Reversed engineered game Starflight (1986)
github.comOne of my all-time favourite games. A family member had Starflight on Genesis. I still pull it up in an emulator from time to time.
Author here. I’m happy to see one of my projects on Hacker News. This has been a fun one. One evening you just try to disassemble it and wonder where the code is. The following months were a truly satisfying experience, reverse-engineering this diamond.
There is still a functioning Forth interpreter implemented in the game. If they hadn’t removed all the word names, it would have been possible to debug at any time and analyze the program state and call functions live with real Forth code. Some crazy feature at that time.
A fantastic read, and really interesting to see the use of Forth. I remember Forth having a bit of popularity in the 80s. This was such an amazing game, especially in that you felt like the world was huge with the encouragement to just explore.
The other game this reminds me of is a game for the TI99/4a called Tunnels of Doom. It was a cartridge game that also had a floppy or cassette data load. It had a dynamic dungeon creation so every time you played the game you got a new unique experience. That would be an equally challenging one to reverse engineer due to the oddity of the GROM/GPL architecture in the TI99/4a.
Hard to convey how effective Starflight’s game design was within the limits of the day.
The embedding of the story within what was almost entirely free-form exploration & adventure across a huge galaxy was masterful.
You could feel how close the creators were to the edge of what was possible with the save game system: Basically, the disk was a memory image. As you played the game would rewrite itself, so if you got stuck there was no “reset”. The documentation was emphatic: Only play with a copy of the original disk!!
Everyone goes on about Elite, but Elite was just a sandbox… (an amazing sandbox)
This was crazy! World gen is hard. Proc world gen is NP hard. Story driven proc world gen with persistence in 1986 was Kaku level brilliance.
I loved Starlight but I'm not sure it was procedural world generation. I mean there was a map of stars printed with the game so they weren't changing. There was a small bit of variation in terms of what one found on planets and so on...the key was it felt like an open world because it was big enough and there was nothing stopping you from doing what you liked and when (except resources).
yeah but you're dismissing the fact that this was just a pregen table of data back then. They made a map based on that, sure, but from that table came... everything else and you can't store all that data on floppy.
Similar techniques apply today. Pregen like 100,000 stars. Give them names and locations in the galaxy, treat them as your "locations of interest" with a seed. The rest can just be another cloud of particles with no interest and if the player visits, you can RNG whatever based on the seed. No two systems can share a seed. They can, however, share a branch.
It was procedural at least in the sense that you couldn't store the data for all the planets in memory (or even store it on disk) on the 1980s systems it ran on. So you needed a way to generate the data on the fly.
> for this game you can throw the usual tools away...
> The reason is that Starflight was written in Forth
I recently reverse-engineered another game from the 80's, and had a similar issue because it was written with Turbo Pascal.
The different tools didn't like quirks such as data stored inline between the instructions or every library function having a different calling convention.
Turns out the simplest way to handle this was to write my own decompiler, since Turbo Pascal 3 didn't do any optimisations.
This game looked very familiar and after googling around it looks like it is recognized as the progenitor of Starcontrol game.
I find it curious that the game was written in Forth. Certainly a very unusual choice for a commercial game.
This was the era before optimizing compilers.[1] The overwhelming majority of commercial games were shipping hand-coded assembly still. Forth had the advantage of low overhead, no-worse-than-a-compiler speed, and better-than-assembly productivity. It was a small time window, but a good fit in the moment.
[1] Non-trivial optimizations were just starting to show up on big systems, but Microsoft C in 1985 was still a direct translator.
...Forth? Wow. I wonder how much code change was necessary between the various systems. It's hard to imagine a Megadrive Forth compiler, but then again, the game was on several other M68k systems so maybe it wasn't as hard...
It is really, really easy to write a Forth interpreter (You can write a simple one in an afternoon). It's often the first software written for an architecture. The structure of Forth means that the hardware-dependent parts are contained in a small number of words (sort of like functions in other languages but not exactly). Forth can be implemented on tiny microcontrollers; a Megadrive would be luxury.
It's.. not a compiler (besides I had Forth on my C64). Maybe one can call it a translator to ad-hoc bytecode. I also had USCD Pascal on that C64 which translated to bytecode. This was more JVM-like. So nothing hard about it.