This issue I'm digging a bit into our story system. I’ll try to keep it brief but there’s a lot to unpack.
(For whom we've ever overwhelmed by trying to explain how our story system works, sorry :))
Some time back we started working with Ink, as we fell in love with the flexibility and the possibility to add logic to the story already inside the text editor.
We started by conceiving a system that only is "talking" when the player does a story relevant action and have only choice by action instead of a direct click-a-button-to-choose-option story.
This forced us to bend inky a bit as it is made more for a story that flows forward instead of circling back a lot (as we visit the story beats again and again with our generalized actions). Nevertheless it's a joy to write in and rather quick to expand.
So let's try to unfold this system on a basic level. We probably have to revisit it in an additional update or even longer form thing.
Our system works with actions that the game sends to our narrative tool.
In the screenshot above you can see what actions can be. It is the player:
entering a location
entering the vicinity of an item on the floor
taking damage
The green texts (in the screenshot) also show that we can do a good amount of logic scripting inside the story writing. So we track almost all states inside the story and not in Unity (our game engine).
To organise the actions, we bundle them into quests. Each quests implements only the actions it wants to respond to and also stores the variables necessary, so it’s self-contained.
Here you see how the “Traveler” quest looks like.
On the left are all calls the game sends to the story system.
In the middle is the text editor where we write our stories, complete with the small scripting to handle story branching or conditional things.
ex. we don’t let the traveler NPC talk if you are currently fighting.
On the right you see the live preview, which the Inky Editor provides.
It’s a great tool to finish a quest and test out if all branches work out without the need to open Unity.
Almost all actions have a generic fallback that you can utilise to write a base story that triggers if no active quest is overriding that action. Each quest has a priority value that places it in a hierarchy and only the quests with the highest priority fire (or those with an ∞ priority which some gameplay relevant hooks need).
Explaining the full setup of a quest is a thing for another newsletter and adds a lot of details which maybe not suit the newsletter format.
But all in all, this feels like a unexplored and flexible playing field to implement story.
You can quickly add new reactions to the players in-world gameplay experience.
We are really happy with the direction the work on the new world walls and foliage (as discussed in the last update "Of Grass and Living Things").
Basil is now wrapping up some missing systems, like updating the navigation system for all followers, changing the danger system that spawns enemies encounters now with more editing choice and better progression and I'm working on finalizing the tutorial which doubles now as a story introduction. How are we letting the players into the world of Castle Come?
This is now also the time to "fix" the depth of stories. How many callbacks to earlier situations are we adding, how "flexible" are the stories reacting to your current situation and figuring out the amount of explanation we need to add. What is an interesting system to put the explanation way later in the game and have some players discover it on their own terms.
We've added a signup button for a playtest that comes soon on Steam.
So if you want to play an early version of the game sometime this year, sign up and get a notification when we open up the game for a long weekend to test.
Signup for the playtest
Until next time
Yours dearly
Sam