Good morning! Jeff here, to talk about some design and engineering stuff. If this isn’t your cuppa tea, I apologize. I’ll be sure to at least include some pretty pictures.
It’s hard to write a game engine. I mean, really hard. Head-achingly, brain-twistingly, spirit-crushingly stupidly hard. Modern game engines, even for simple games, require an intimidating amount of engineering. Rustclad is well over one hundred thousand lines of code already. There’s an adage that the average professional developer writes ten lines of code per day. If that applied, then I would have been working on this project every day, with no days off on weekends, since age six.
In light of this, whenever an opportunity comes along to not write something myself, I jump at it. Such was the case when I began working on our Storyteller system. You can think of the Storyteller as the thing that runs the ‘gamey’ bits of the game engine. Game engines have graphics, and sound, and AI, and data management, and a veritable cornucopia of other subsystems – but at the end of the day, there needs to be a, yaknow, game, right? That’s where the Storyteller comes in. It controls everything that happens to you, the player. It controls where you are and where you can go, what you can see and interact with, what you can (and can’t) do, and what happens if you choose to do those things. And it keeps track of where you’ve already been and the events that have already unfolded that have shaped the game world that you’re experiencing.
Now there are a lot of approaches to constructing a Storyteller, or Scripting System, or Game System, or whatever you want to call it. The most powerful method is to just use whatever programming language you wrote the engine in, since your game systems will run fast and have a tight integration with your engine. However, this method can be extremely cumbersome since a lot of extra low-level programming will then need to go into writing your game. A very common alternative that trades a small amount of power for a whole lot of flexibility is to embed a scripting language in your engine. Scripting languages are often easier to use and complex systems can be quicker to write – and you don’t have to recompile your program every time you want to change a little bit of the game logic. I started with this approach by integrating the Lua scripting language into our engine, and building our Storyteller with Lua scripts. However, I quickly found that I wanted something with even more structure, and more ease of use that would allow our game to be built really fast and cleanly without having to manage hundreds, or even thousands of little Lua scripts.
This got me thinking a bit more outside the box, so to speak. Rustclad takes its inspiration from the adventure games of yore, though you’ll find it to be quite a different experience. But in its heart, it’s an adventure game, so I started looking at adventure game builder kits and tools that might be integrated into our engine. I didn’t find much that would work for us, so I broadened my search a bit and looked for text adventure game tools. Yes, that’s right, the stuff that you (or now maybe even your mom or dad) used to play where the entire game experience was a piece of interactive fiction with no fancy graphics or sound. And here I found a thriving community of tools and developers who were keeping the spirit of the old text adventures alive! Bless their hearts.
One such tool that really stood out to me because of its flexibility, ease of use, and active community is a program called ADRIFT, which stands for Adventure Development and Runner, Interactive Fiction Toolkit. It’s pretty clean and user-friendly, but can it be re-purposed for use in a graphics-heavy highly atmospheric 3D interactive world? At first, it sounded almost antithetical to our goals with Rustclad. But then I started really thinking about what we’re trying to create. Rustclad isn’t a twitch game. It’s a game about exploring a beautiful world at whatever pace you want to experience it. It’s less about skill and timing, and more about interacting and storytelling. We’re building something fantastic and we don’t want you to miss a minute of it due to an errant fireball or a stray bullet.
So maybe interactive fiction isn’t such a bad model to emulate. It’s also a heavily atmospheric experience that uses the art of writing to build a rich environment, despite being visually handicapped. And most of the requirements of an interactive fiction experience apply to us as well. ADRIFT makes it pretty easy to set this stuff up, and perhaps most importantly of all, it allows the entire project to be exported to an XML file, which means that it’s super-easy for us to build our stories in ADRIFT and then suck them all up in to Rustclad (insert sucking sound here). ADRIFT also has a pretty robust property system, which lets us mark objects for more sophisticated engine functionality at runtime. For example, a control panel could be labeled as such with a property, and when you as the player interact with the control panel in the game, we can use this property to configure the game’s user interface appropriately so you see a nice clean representation of the control panel. We’re taking some liberties with ADRIFT’s event and conversation systems because we really want these elements of the game to shine, but the tool is flexible enough to allow these ‘functional reinterpretations’ to most of the time be made pretty intuitively.
So let’s get down to it. What does this all mean for our development process? Well, we start by building our ‘story’ in ADRIFT. This has the advantage of letting us build the structure of our world really fast, since it’s entirely decoupled from the complexities of the visual representation at this stage. When we’re done, it looks a little something like this:
We can even perform some light testing in ADRIFT. It comes with a ‘runner’, which will execute your story in text adventure form. Since our game is not a text adventure, we’re taking a lot of liberties with the tool which make this preview mode not super-useful, but it’s still nice for early playtesting.
After that, we can export the story from ADRIFT and bring it in to our own editor. With the push of a button, we can ‘synchronize’ the visual world with the logical world. Our editor will import and create any objects in the story that don’t exist in the game world, and remove any objects that have since been deleted from the story. What remains to be done is to build the visual representation of the world, tweak properties and bring in art, and set up any ‘responders’ to the story which will allow the world to come alive and respond to the player and changes in the story (more on that later). I’ve built my own version of the ADRIFT runner in our engine, which allows the story files to be executed in much the same way as they are in ADRIFT. Here’s the same scene, but in our game. Note that this is an early build, and the visuals and interface will certainly be improved as we get closer to release.
We’ve been really happy with the process so far. It lets us create content fast, which is important for a small team. The time saved on building the structure of our game can instead be spent on polishing it so when this is all done, we can give you something that’s truly amazing. Thanks for reading!