Questing Part 2 – Compiling
Posted on
November 2, 2016 by
Interkarma
In the
first part of this series, I discussed how I’ll be using source files output by Tipton’s Template v1.11 for quests in Daggerfall Unity. If you’d like to check these out in full, the quest source files are already on GitHub. Follow
this link to view them (ignore the .meta files).
Some interesting quest files to investigate are:
- _BRISIEN.txt – This is the quest that launches when player starts in Privateer’s Hold. It sets the whole story arc in motion and starts timers for delivering letters that prompt player to visit Lady Brisienna. Failing to visit Lady B in time is ultimately a failure condition of main quest.
- S0000999.txt – Starts when you leave Privateer’s Hold. Delivers letters from Prince Lhotun and Morgiah and sets key global variables.
- S0000977.txt – Also starts when leaving Privateer’s Hold. Sets up regular ghost and wraith spawns in Daggerfall and plays the VENGEANCE! sound.
- TUTOR.txt – Is the tutorial quest started when selecting Yes to the prompt at start of game.
As another interesting tidbit, longtime players may have noticed the initial journal entry that begins with…
"I am on a mission from the emperor to investigate
the shade of King Lysandus. His spirit has been
haunting the city of Daggerfall. The emperor
himself has charged me with the duty of laying
his ghost to rest."
…will stick around in your log forever. Even after you’ve completed the game, this first journal entry will remain. As part of researching the quest system a while back, I looked into why this was happening and found the above journal entry is added twice and removed only once. The below image sums it up visually. You may have already seen this when I posted it to Twitter back in September.
So the quest system in Daggerfall is quite powerful. It’s responsible for adding and removing journal text, starting timers, delivering letters, spawning enemies, playing sounds, setting global variables, moving NPCs, and a slew of other functions. At first blush it can appear a lot like a full programming language, but it’s only superficially so. The structure is actually more like a complex INI file, or even a kind of markup file. Everything is neatly categorized into its own section and execution flow generally only happens in a few different ways. Most commonly are at startup, when a timer ends, and due to a variable or condition changing state.
Thus despite the initial similarity to a programming language, the quest source is really just a collection of defined objects with some very basic scripting functions. Most of these functions revolve around spawning something, starting something, playing something, or changing something. Complex enough to get the job done, but don’t feel like you need to be a programming expert to create new quests in the future. Using Tipton’s Template v1.11, you could even start creating quests in classic Daggerfall now and later port them into Daggerfall Unity.
Likewise, the job of compiling the quest source back into Daggerfall Unity is not that difficult. It’s going to have some challenges, but nothing on the scale of building a real compiler, something I thought I’d be facing at the outset. The problem is largely just splitting source file up into correct parts and handing that source off to classes designed to support that part. For example, messages will go to a Message class, timers will go to a Timer class, etc. When serializing live quests as part of save games, the QuestMachine will save/load JSON state for each live quest along with the global variables for the current game.
To help Daggerfall Unity re-compile Template’s source output, I’m going to make some minor changes to the expected source files. I’m trying to keep these changes to an absolute minimum.
First change is for the quest header to be uncommented in source file. For example, _BRISIEN has the following header. The dash ‘-‘ prefix starts a comment.
-- StartsBy: letter
-- Questee: anyone
-- Repute: 0
-- QuestId: 0
This reason this can be commented out is that Template is designed to re-compile quests back into the original QBN/QRC format. When commented out, Template will just use the information already in the quest QBN data. However, Daggerfall Unity relies entirely on the quest source and will need the above uncommented to:
StartsBy: letter
Questee: anyone
Repute: 0
QuestId: 0
This way the information can be parsed back into the quest data at compile time.
The second change is that I would like an explicit startup task, rather than an implicit startup after the QBN object definitions (like Person, Clock, etc.). Currently the startup task looks like this:
-- Quest start-up:
log 1010 step 0
pc at PiratesHold set _exitstarter_
say 1025
I would like to change this to:
startup:
log 1010 step 0
pc at PiratesHold set _exitstarter_
say 1025
This makes the startup task an explicit task object to be executed when quest begins. This is already the current behaviour, but I think this change makes the task clearer to identify for both quest creators (even without a comment) and for my compiler. I could definitely get away without this change, but I prefer the explicitness to the current setup.
And of course, the above is subject to change as the quest system matures. If I learned anything from rolling out items, the feature will probably look different again by the time it’s mostly complete. Daggerfall Unity is not just a game remake, it’s an ongoing research project into the guts of Daggerfall. That adds a few twists outside of normal gamedev process, and I just need to roll with it.
One of the upcoming features not shown yet is the quest debugger currently in development. Hopefully, I will have something to show on this by part 3. The quest debugger will be used to manually start new quests, terminate and restart executing quests, and inspect state of global variables and quest objects. It’s a big UI that will continue to grow as development progresses. Should turn out to be quite useful though.
For more frequent updates on Daggerfall Unity, follow me on Twitter
@gav_clayton.
