Now that buildings and NPCs can be identified in the game world, I can finally start linking together parts of quest system to world. The clearest starting point is quest buildings, as a majority of quests in Daggerfall will send player to a building somewhere in the world.

If you’ve been following my progress on quest system for a while, you already know a lot of technical progress has been made on the back-end. Without forcing you to recap on past articles, here’s a brief summary of quest system in its current state:

Quest scripts are generated by Template v1.11 by Donald Tipton. This has long been the go-to solution for adding new quests to classic Daggerfall. By adopting this scripting format, it becomes possible to compile scripts between both Daggerfall and Daggerfall Unity for testing. And it means anyone with experience writing quests for Daggerfall can already write quests for Daggerfall Unity.

Daggerfall Unity has a JIT quest compiler which builds quest scripts at runtime. This means you can edit, start, and stop quests without once closing the game. This will be even more useful once the Quest Inspector UI is ready.

The QuestMachine execution environment runs compiled quests like small virtual machines inside your game session. It interfaces with the world and does all the necessary housekeeping for running quests.

Quests are made up of resources (Place, Person, Item, etc.) and Actions (perform some task). Some actions are also conditional (do task when condition is true). Almost all of Daggerfall’s high-level gameplay is driven by the quest system. Even some things you might not expect (such as Lysandus screaming VENGEANCE! at night) are accomplished by quests.

When adding building selection to game, one of my first problems was how do I locate the building in whatever town player is in. Daggerfall Unity doesn’t have wandering NPCs to mark buildings on your map quite yet. Not a problem for named buildings like taverns and shops because these are visible on the automap, but what about some random residence in town? How do I get the player there for testing?

The solution I landed on was to add a simple quest compass on the HUD. This will show the direction, name, and distance to target door. Fortunately, I already track building entrances in the world. What’s needed is to build a set of marker positions based on active quests. I start by just adding a test sphere on quest target doors.

That blob above sits perfectly on the door to my quest building. Now I need to show that as text and distance. The HUD text overlay below align with doors in camera space and show distance to multiple targets.

And finally the building name. This marker can direct quest developers straight to all active quest sites in their current location. Of course, anyone will be able to turn this on from the quest inspector UI if they would like a quest compass. I’m almost certainly going to expand this system out for quest items in dungeons and other targets in the future.

I can now enable the quest journal, something Lypyl implemented perfectly some time back. I wire up the keybinds and UI to allow player to open quest journal, and find logged quest information sitting there as expected.

What you can’t easily see above is that some text macro support has been added as well. For example, %pcn resolves to player’s full character name, _buildingSymbol_ expands to building name, __buildingSymbol_ expands to location name, and ____buildingSymbol_ expands to region name. This is all part of the text engine inside Daggerfall I’ve had to reimplement in Daggerfall Unity.

With local building support out of the way, the next step is remote buildings elsewhere in the same region. This involves a bit more work, but in a few hours it’s possible to send player anywhere in the game world.

The final piece is to implement PcAt conditional action, which detects when player has entered target building and does something. In this test quest, I just display a popup and end the quest.

This is an important milestone for questing in Daggerfall Unity. It means a lot of the hard groundwork has been completed and the real work, the stuff visible to the player, can commence. This is a huge relief for me because I can finally show off my progress in a meaningful way with screenshots and videos. As important as all the code back-end is to outcome, its been very difficult to show progress which sometimes makes it feel like nothing is happening.

To celebrate visible progress, here’s the first video of Daggerfall Unity’s fledgling quest system in action.

For more frequent updates on Daggerfall Unity, follow me on Twitter @gav_clayton.