Building the Spacecraft I Imagined as a Child
Deck & Conn has probably gone through more iterations than any project I've developed. This is it here, in its first form - a pico-8 prototype of what was then a sort of "Super Star Trek with bells added". From there, it went through three complete re-writes or ports across two more languages, until it ended up as its current C++ iteration with a custom engine.
So, why did it stick with me for so long? Why was I constantly trying to make it or some version of it?
If I broke down what prompted designing most of the games I've made, they mostly come down to one origin story: Games I played when I was young that weren't quite what I wanted them to me. Maybe they weren't bad, per se, but the promise of what they could be wasn't really there. This was more common in decades past, where hardware limitations often meant what you might want to do as a game designer and what you COULD do in a few megabytes or less of memory were light years apart.
Sometimes, it was games I loved as a child, and when I'd go back to them, they just weren't as complex as they were in my memory. EGA Trek was one of those for me, along with other iterations of this game formula. It's still a great little game, and you can see how it directly inspired so much of Deck & Conn. Even the interface has a similar pane-based breakdown, though in Deck & Conn they're more diegetic-looking.
But when you go back to most of these amazing versions of the original mainframe Star Trek game, they retain the simplicity of the original. Not a bad thing, but as a child I made up in my head all the complexities of shipboard life that were going on beneath the EGA exterior, and by the time I had grown older and gotten into aviation, submarine warfare, and read half the Aubrey-Maturin books, I kept seeing a project in my future. I imagine my version having all the things I was a sicko for.
For one thing, startup procedures. The practice of them was never my thing (have you ever looked at a real startup checklist for an aircraft? It's enough to make your eyes glaze over), but to me, if a spacecraft was going to feel real, it'd have a startup checklist. I imagined that before the Enterprise left port in a Star Trek TV show, half the crew were going over the world's most complex startup checklist, for each deck and each division, to get the vessel ready to go. I'd need that, of course, to give it a sense of being tangible.
There's even a digital checklist in-game, based on one I printed out in flyer-form to hand to attendees at a games expo I showed an early build of the game at. It's not a complex one, and once you know the game you'll start your boat in no time at all, but the feeling was important to me.
So what about the rest of the game? Complex systems, etc? What was I going to go?
The trick I used to keep myself on track as a "the original game, but more systemic and complex" was to give myself hard limits. At the start, these were:
1) The core combat should remain the same. Two weapon types (one that uses ammunition and does more damage / has more range, one that takes power, no ammunition, and has limited range) and shields which could be up or down.
2) The core turn-based mechanics should remain the same. Grid-based movement within a sector, and a whole quadrant of sectors to explore.
3) A focus on how much power you did or didn't have - power management was a big thing in all versions of the game.
Whenever I began to flesh out a given system, I'd ask myself the question - is this changing the core gameplay loop and focus? If the answer was no, I would add it to the prototype and see how it plays.
In Deck & Conn, for instance, you not only have magnetic hull plating (shields SST), but CIWTs defence turrets, to provide limited defence against torpedoes. But the core combat mechanics are still there.
Power is still critical, but now it comes from numerous sources and different ship systems can be turned on/off or modified settings-wise. We have an APU now, and a reactor that has to be started and has numerous modes.
Then there's the biggest change: I had my prototype working when I realised that the original 8x8 sectors of 8x8 tiles each was just too small to allow anything like the sort of tactical complexity I wanted. Which isn't to say this is some hugely complex chess-like tactical simulation, but by making my sectors and quadrants larger, it meant you had a bit of time spent finding enemies before engaging them. Just enough to mean your early decision-making mattered as much as your post-contact combat tactics.
