Seedship‘s development could be used as a cautionary tale in not letting the scope of a project get too large.
I started working on the first version of what would become Seedship several years ago, as a personal side-project while I was working a day job in the games industry. My original idea was to create a space exploration game, a little like Strange Adventures in Infinite Space, but based on hard science rather than space opera tropes. I started to develop it in Unity, writing the code in C#.
The Unity version got as far as a sort of model solar system, with planets moving in circular orbits, and a spaceship that could fly between them. There were no real graphics: the planets were coloured spheres, and the spaceship was a cube. When you clicked on a planet it brought up a dialog with its details: gravity, temperature, atmospheric composition, and so forth. There was a complicated system of code for generating these planets according to (my layperson’s understanding of) real-world science. I had planned a system of text-based random events for things that could happen when you sent people down to a planet’s surface, but I didn’t get far in implementing it.
My problem was that I was trying to do too many things at once, and learn too many things at once, without a clear enough plan. My core idea was a realistic space-exploration game, but I got so bogged down in the science of generating realistic solar systems that I didn’t pay enough attention to the game design. I was teaching myself all the science I needed, at the same time as learning Unity through trying to create a fairly complex game as my first Unity project. The game was too big and complex and unfocused to be a good first solo project. Which is something that I really ought to have known as a games industry professional, but I think it’s one of those lessons that everyone has to learn for themselves.
I eventually realised my mistake and decided pare the game down, keeping the hard-science solar system generation but giving the game simpler mechanics and a more focused objective. Rather than exploring the universe with the vague goal of collecting data, you were trying to find the best planet to found a colony on. Changing the focus to founding a colony improved things, but I still wasn’t making real progress so I decided to shelve the game and concentrate on other projects.
More recently (mid-November 2016) I began messing around with Twine, and when I became aware of the kind of complex scripting it was capable of, I decided to revisit the colony founding game idea and try to make it again in this new medium. I discarded the Unity version and started from scratch, and this time I decided to ditch the scientific detail and instead define planets in terms of how useful they would be for the colony. So, for example, rather than expressing temperature in degrees Kelvin (which means knowing the luminosity of the star and how for the planet is from the star and the planet’s albedo and how much heat its atmosphere retains…) I just rate it on a scale from “Very cold” to “Very hot”. Which then ties directly in to how easy it is to build a colony there, because you need heated suits on “Very cold” planets, you need to wrap up warm on merely “Cold” ones, and you can walk around in shirtsleeves on “Moderate” ones. I created similar scales for atmosphere, gravity, and so forth, plus a system of “surface features” for extra traits that some planets might have. My goal was to retain a feeling of scientific realism without getting bogged down in detail.
Twine proved to be better suited to the game I wanted to make than Unity had been. There were no more planets moving in pretty orbits, but that had never been a core mechanic of the game anyway; the important information had always been the planet attributes which were displayed as text. Making text-based random encounters in Unity meant making a whole system of dialog boxes, whereas multiple-choice text dialogs is what Twine is for.
Learning from my previous mistakes, I made sure to keep the game simple and focused. That, combined with the ease of use of Twine and the fact that I didn’t need any graphics, meant that I progressed pretty quickly. Right now, after a few months of working on it part-time, I’ve got a working prototype that I just need to refine and add more content to.
I may revisit the idea of a hard-science space exploration game in a future Twine project (I’m thinking of something where you have crew members with different skills who you can send on away missions), but if I do I’ll make sure to keep it focused and not fall down another rabbit hole of scientific realism.
I’m hoping to launch Seedship in late February or early March.