Retrospective
This is intended as a review of concepts, scope, and how the process of making the idea — changed it.
I am writing this several years (and several projects) after the fact, partly because I still have this domain, and partly because I feel a great fondness for this project. Even though I now know it was quite beyond my capacity, and in many ways severely misguided, I learned a lot about games, art, and myself in the process.
Please forgive the long-windedness of this, but anything less, would be insufficient to explain what this project meant for me, or how much work I put into it. I want to explain what I was trying to make, and why it wasn’t possible. If you happen to be in a similar position, I hope this will be useful to you.
The original inspiring concept came from sources like Magnetic Rose, Titan A.E., various books of science-fiction, and one specific episode of Cowboy Bebop. In this episode the protagonists have tracked a criminal mastermind back to a derelict space station. The plot of the episode was incidental. I wanted to see more of the derelict station. It’d been jury-rigged by several generations of people who wanted to escape from the rules of organized society.
It was a mess. Null gravity. Random chunks of ships welded on, over many years. Mazes of pipes and tubes. Cats and dogs, running (floating) wild. Tomato vines growing on the walls of corridors. No organization structure to be seen. I wanted more of that. So I started with the basics. ‘Is there a game in there?’
You can spin that any number of ways. You can make it in as a first-person, third-person, or isometric, and the outcome will be drastically different in each case. Gamedev is incredibly fiddly. What you choose to add, or omit, will dramatically change the player experience.
I didn’t have a budget to speak of, so characters were out of the question — and it was just me working on it, so I wanted something fairly contained, and within my experience as much as possible.
Initially I concepted (pencil sketch, it’s a great way to get an idea out) a small level, intended to be explored in first person, zero-G, with six-degrees-of-freedom. I’d wanted it to be a series of puzzles, where you explore abandoned rooms, and unlocked secrets. Eventually you find out why you are trapped, alone, on a space station. I didn’t have a reason yet, but I was sure I would come up with one in time.
The Hovercraft Game
If you dig deep enough into the history of RO, you’ll find a different game. One I never got around to naming, in which you piloted a hovercraft armed with moddable weapons, and fought robot ships in tunnels.
I’m fairly sure I still have some form of game files on a drive, but I have no idea if it would still run, and I absolutely failed to record gameplay beyond this very early prototype that shows nothing of the art design.
As far as I can tell I worked on this hovercraft game for 2-3 months in early 2017.
Addendum: The project still runs (bless Unreal). I’ve expanded on this in a Special Page dedicated to what that game might have been. You may start to see a pattern here. No one should ever accuse me of dreaming too small.
The only feature that was passed over from this prototype was the basis for the Zero-G flight mechanics.
The First Misstep
In spite of thinking of RO initially in terms of a narrative puzzle game, when I went to start making the game, I slowly began adding survival sim mechanics.
I believe this was accidental, but once I got started the original idea seemed shallow.
At the time, I’d been thinking about how to make a good survival game, and I had a few ideas I wanted to try.
In my mind, I figured it would be easier to make a game this way. It was easy to justify. Reusable content. If the content is reused, I don’t have to make as much, right? Wrong. Things that must be used repeatedly, in combination with all other things, will rapidly become exponentially more complex. A system that works in conjunction with all other systems must be bulletproof, and work in every possible exception.
Now, there were absolutely benefits to reusing a base class for most things. I highly recommend it, in fact. The system was just so massive that anytime I found an outlier it was some absurdly niche thing, and attempting to fix it would inevitably break two other things.
A great deal of mistakes were made because every time I wanted a new feature, a large portion of the existing system would stop working — so I would hack in repairs, to accommodate that new feature.
To a point this will just happen, but it’s supposed to get worked out early on, so that less work has to be redone.
I couldn’t have known this then. When you’re just getting started with a new project and a new tool, you don’t know what you want, what the best way is, or even what you can do. That comes with time. Unfortunately time is expensive.