I’ve been pretty busy lately, so there hasn’t been too much actual progress on the game. As such, this update is going to focus on something pretty simple – the game engine I’ve chosen to build Relic Tycoon in.
When you start working on a new game one of the first things you need to decide on is the game engine you’ll use. Do this too early and you might chose an engine that’s doesn’t fit the game, making development more difficult than it needs to be. Do it too late and the ideas you have during planning can easily become unfocused and overreaching. The idea of the game you have in your head won’t take into account the different limitations that different game engines impose, so when you finally come to choose an engine none of them will seem like a good fit, and you’ll probably end up with a heap of cut ideas and wasted time.
Choose an engine at the right time – after the core of the game is nailed down, but before you flesh out your central ideas, and you’re in business. You can choose an engine that’s going to work with your core vision, and you can incorporate the strengths and weaknesses of your chosen engine into every future idea you have.
Obviously, you can trust me on this, based on my extensive experience as a producer at leading AAA game developers the fact that I’ve made two small games in Twine. But this thinking has already helped me out a lot in the past. I chose Twine for my first two games because they were ideas that worked well as simple hyperlink stories, and they didn’t need particularly robust engines propping them up.
There were a couple of things I wanted to do that Twine made annoying or impractical. But while I could have chosen different engines that might have made those features possible, no other engine would have allowed me to make those games as quickly and as easily.
So, surely I’ll be using Twine again for Relic Tycoon? Quick and easy development sounds perfect. Well, no. Twine is great for a certain kind of game (fairly traditional Choose Your Own Adventure-style branching narratives), but unlike End Boss and Character Creator, Relic Tycoon isn’t that kind of game at all. I actually started making a prototype in Twine, to test out some ideas before I chose a final engine, but even then it was fighting against me every step of the way.
I couldn’t think of a good engine to use, so I thought about making the game from scratch. But Relic Tycoon isn’t that complex – surely there must be something that would allow me to make the game without having to invest weeks or months into building the foundations first.
And then I realised that the ideal engine did exist. It’s StoryNexus – the online platform made by my old employer Failbetter. StoryNexus was essentially built to allow people to make Fallen London-style text-based games, and while Relic Tycoon is different from Fallen London in a lot of ways (for example, it’s a bit more mechanics-driven, with the removal or near-removal of grind and repetition), the basic structure is similar. Partly because I’ve been influenced by Fallen London a great deal, and partly because I thinking the structural decisions behind Fallen London are intelligent, with huge applicability for other types of experiences.
I’ve already had to make a couple of compromises, but ultimately it’s been a great choice. Development is already much easier, much faster, and I’m incorporating my knowledge of the strengths and drawbacks of the engine into every idea I have.
The only real problems are ancillary to the game itself. For one, making Relic Tycoon is StoryNexus is not going to help me improve my programming skills, which is something I definitely need to focus on. But right now I want to write and make games, and the only way I can guarantee I’m going to be able to do that is if I sit down and write and make games. I don’t want to spend months struggling to force myself to do something difficult and tedious in my limited free time, when I can spend that free time actually making something interesting.
So I’m going to keep building Relic Tycoon in StoryNexus. It genuinely seems like by far the best choice, and it’s already allowing me to stop spending my time worrying about technical frustrations and start spending more and more of my time writing and designing.