It Lives!

With some back-end and core actions out of the way, it was incredibly satisfying to watch the quest system spring into life today. The two bootstrap quests are now launched with a new character. They don’t do much more than popup messages right now, but everything starts somewhere.

The work from here is “just” building out all the remaining actions and conditions for quest scripting. I say “just” because it’s still a huge amount of work. But it’s finally starting to feel like I’m getting somewhere!

If this doesn’t look like an awful lot of progress for a few months work, remember it’s a black triangle milestone. This is a pioneer of more interesting stuff to come.

Questing Part 3 – Anatomy of a Task

Example custom quest action created for this post

The quest system back-end is coming along. I’m sad it’s not further along by now, but life has a way of disrupting plans. The important thing is I’m still making progress and have some good stuff to share today.

In this post, I will dissect tasks along with their conditions and actions, which together form the meat of a quest. There’s a great deal of technical content ahead, I want this post to be a kind of primer for contributors to quest system. My apologies to those of you who don’t enjoy code-heavy updates.

Before getting started, please have a quick skim through Donald Tipton’s excellent documentation for his Template v1.11 quest compiler/decompiler. As discussed in Questing Part 1: Source, these source files are also used by Daggerfall Unity’s quest parser so we have common ground with classic. This even allows quest source to be shared back and forth with classic for testing. I’ve actually rolled back some of my ideas from that first post and will use Template source files directly as-is without any changes. This might have to change in time but right now I’m aiming for total parity.

If you’d like to see some real quest source, you’ll find all of Daggerfall’s decompiled quests in the StreamingAssets/Quests directory (link to GitHub, ignore .meta files). But today we’re just zooming in on tasks and actions to see how these are handled by Daggerfall Unity.

 

Tasks

Daggerfall quests have four distinct forms of tasks (so far). All of the examples below are from the quest _BRISIEN.

Standard – This is a basic task which does not start unless explicitly triggered somehow. The task name (e.g. _invitepc_) is also a boolean symbol which can be queried to see if task has been triggered (i.e. is active). The lines under the task header are the conditions and actions making up that task.

_invitepc_ task:
	start timer _remindpc_ 
	give pc _letter1_ notify 1026 
	create npc at _dirtypit_ 
	place npc ladyBrisienna at _dirtypit_ 

Repeating – These tasks execute continuously until the symbol they reference (the boolean state of another task or variable name) is triggered. In below case, the task will persist until _exitstarter_ is triggered. Repeating tasks appear to be triggered automatically at startup.

until _exitstarter_ performed:
	start quest 999 999 
	start quest 977 977 
	start timer _invitepc_ 
	remove log step 0

Variable – A variable is really a kind of task with trigger state only. Trigger state may be set/unset by other tasks.

variable _exitstarter_

Headless – Every quest must have a single headless task. This is the entry point to be executed automatically at quest start-up. Unlike other tasks, a headless task does not have a symbol to query trigger state. It just executes to bootstrap the rest of quest. This is the entry point of _BRISIEN:

--	Quest start-up:
	log 1010 step 0 
	pc at PiratesHold set _exitstarter_ 
	say 1025 

At time of writing, Daggerfall Unity will parse through quest source to instantiate tasks and try to match component actions to a registered template (more on this below).

 

Conditions

Other than being triggered at startup or by other tasks and clock time-outs, a task can have one or more conditions that might cause it to be triggered. For example, if player is in a specific place at a certain time (e.g. Daggerfall at night) then some action can be performed (e.g. play the “vengeance” effect). This makes it possible to chain together tasks which trigger on and off based on the trigger state of other tasks.

I won’t go much into conditions right now as they have not been implemented yet. I’ve just barely stubbed out a bit of starting code that will be replaced later. If you like, you can read more about quest conditions here.

 

Actions

A quest action is a bit of text that does something. This is usually a single thing like playing a sound, displaying a message, or starting another task. Don’t think of actions like a normal programming command though. They aren’t necessarily run and done (although they might be). Try to think of actions as components attached to a task in a similar way that Unity components are attached to a GameObject. This isn’t a perfect analogy, but its a start. Like GameObjects in Unity, tasks can switch on and off and their component actions perform bits of work over time.

Actions are a great way for contributors to help build out the quest system. There are many different kinds of actions, some will be very simple others very complex.

 

Building Actions

So how does an action go from a line of text to actually doing something in the game? The rest of this post will cover the fundamentals and show a real working example of a custom action… in action.

The bones of every action begins with the ActionTemplate class, an abstract implementation of IQuestAction interface. All actions must inherit from ActionTemplate and implement the required parts of IQuestAction. This ensures that every action template has a few key features:

  • Pattern – A regex string used to pair a line of source text with this action. Two actions cannot have the same match pattern.
  • Test – Checks if provided source string matches the regex pattern expected for this action.
  • Create – An action template is special in that it can also factory (i.e. generate) a new instance of itself with default settings. This allows the QuestMachine which hosts active quests to hold a list of self-replicating action templates that can be instantiated as required.
  • GetSaveData – Gets a data packet from action live state. This will be passed on to JSON serialization system when saving a game.
  • ResoreSaveData – Sends a data packet to action from serialized state. This will be used to restore action state when loading a game.
  • Update – Called by the task owning this action. Allows the action to do work every frame as needed.

To show all of this working, I wrote an example called JuggleAction which simulates the player juggling some number of objects with a percent chance to drop one. Click here for the full source code and I’ll break it down below. Let’s start with the pattern:

public override string Pattern
{
    get { return @"juggle (?<numberOfThings>\d+) (?<thingName>\w+) every (?<interval>\d+) seconds drop (?<dropPercent>\d+)%"; }
}

This is just a basic regex match string that looks for a pattern like “juggle 5 apples every 2 seconds drop 40%”. Everything the action needs to execute is contained in the pattern. Sometimes an action might take different forms and the pattern string must cover these variants also.

The parser uses Test to find a registered action template with pattern matching source. When a match is found, the JuggleAction template will factory a new instance of itself with default settings by way of Create.

public override IQuestAction Create(string source, Quest parentQuest)
{
    // Source must match pattern
    Match match = Test(source);
    if (!match.Success)
        return null;

    // Factory new action and set default data as needed
    JuggleAction action = new JuggleAction(parentQuest);
    action.thingName = match.Groups["thingName"].Value;
    action.thingsRemaining = Parser.ParseInt(match.Groups["numberOfThings"].Value);
    action.interval = Parser.ParseInt(match.Groups["interval"].Value);
    action.dropPercent = Parser.ParseInt(match.Groups["dropPercent"].Value);

    return action;
}

You’ll notice the action parameters are exposed directly by the Match class returned by Test. This makes it easy to read out the values involved. At this time, our new action is ready and is added to a collection stored in the Task object. During quest runtime, the task will call Update on each action to do the work required. Here it just counts off time and if still holding any objects, calls the Juggle() method. Note that we’re using Time.realtimeSinceStartup instead of Time.deltaTime. The reason for this is that QuestMachine ticks at a slower rate than Unity (currently 10 times per second). So we need to measure time without using something that only changes frame-to-frame.

public override void Update(Task caller)
{
    // Increment timer
    if (Time.realtimeSinceStartup < nextTick)
        return;

    // Juggle 'em if you got 'em
    if (thingsRemaining > 0)
    {
        Juggle();
    }

    // Update timer
    nextTick = Time.realtimeSinceStartup + interval;
}

Below is the Juggle() method for completeness. It just spits out some notification text to HUD and randomly decrements object count until none are remaining.

private void Juggle()
{
    // Juggle current things
    DaggerfallUI.AddHUDText(string.Format("Juggling {0} {1}...", thingsRemaining, thingName));

    // We might drop something!
    int roll = Random.Range(1, 101);
    if (roll < dropPercent)
    {
        thingsRemaining--;
        DaggerfallUI.AddHUDText("Oops, I dropped one!");
    }

    // Give up if we've dropped everything
    if (thingsRemaining == 0)
    {
        DaggerfallUI.AddHUDText(string.Format("Dropped all the {0}. I give up!", thingName));
        return;
    }
}

I won’t touch on GetSaveData and RestoreSaveData yet as quest state serialization has a ways to go. You can check the full source of JuggleAction linked above for an example implementation.

You might recall I said something about registering new actions with QuestMachine. This might change later, but right now our action class JuggleAction is registered in QuestMachine from RegisterActionTemplates() like below. The template is only being used as a factory so it doesn’t need to pass in an owning quest at construction.

RegisterAction(new JuggleAction(null));

Registering the action template allows the quest machine to find it (using Test) and factory a new instance from the template.

Now that we have an action and registered it to quest machine, we actually need a quest that uses this action for real. I created a cut-down quest just for this example called __DEMO01.

- Minimal example quest used to demonstrate how to script custom actions

Quest: _BASIC01

QRC:

- No text resources

QBN:

- Headless entry point with custom action
juggle 5 apples every 2 seconds drop 40%

All that remains is to instantiate the quest itself. I will add a console command soon for this, but in the meantime I’m calling the following bit of code from StartGameBehaviour.

GameManager.Instance.QuestMachine.InstantiateQuest("__DEMO01");

This loads our custom quest into the quest machine and starts executing supported actions, which right now is just the demo quest and juggle action. When starting a game, this will be the output:

 

Next Steps

For now, I will continue to work on the quest machine, parser, and related frameworks. My immediate next step will be to get the full tutorial quest working along with some foundation conditions and actions, and a few supporting user interfaces (quest log, quest debugger UI).

I would like to invite the more experienced contributors to review the quest source documentation in more detail and see if any actions might fall into their range of interest. I would also love some help with quest resources other than tasks (e.g. Place, Item, Foe, Person, etc.). I’ve stubbed out the Clock resource as a starting point. If there is something you would like to work with, please start a conversation on the forums and let’s see where it takes us.

If you have any questions or would like to dicuss this post in more detail, please don’t hesitate to find me on the forums!

 

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

Back To Work 2017

Hey everyone, belated happy new year for 2017!

I’m back to work after taking a few weeks off. Now things have settled down, I’m also back to working on Daggerfall Unity’s quest system. You can expect a blog post for part 3 of this series soon.

Quests are the beating heart of Daggerfall, everything from the tutorial to vengeance! are powered by quests, and this will be my main focus in 2017 until things are working well enough to move onto spells and effects. With a bit of help from others this will come together at a reasonable speed. Just to manage expectations, you won’t see a fully-formed quest system arise out of nothing – things will continue to be built in small stages. But barring any major setbacks, you should be able to launch quests for testing with the quest debugger by March-ish. I can’t promise every part of quests will operate (in fact, I guarantee it won’t) but it should be enough for testers to sink their teeth into and iterative development will continue from there.

Speaking of help, I’m also looking forward to seeing what contributors and modders do in 2017. I think last quarter saw the most number of new contributors since Daggerfall Unity began in August 2015. This is really exciting for me because it confirms opening source from the beginning was the right choice. There will probably come a point where the project will be taken further by others (and probably faster) than I could take it by myself. If things keep heading the way they did in 2016, this should be a big year for Daggerfall Unity.

 

December 2016 Test Build

Hello everyone! This will be my last post for 2016. It’s been a great year for Daggerfall Unity with solid updates across the board. I was hoping to have basic quest support in by now, but sadly not everything goes to plan. This will return as a priority early in 2017 so watch this space!

One thing that always amazes me is the quality of work this community is willing to put back into Daggerfall Unity. It’s always a pleasure to find a new pull request on git from someone willing to contribute their personal time to make this project even better. So this post is going to focus almost exclusively on contributions from community members. It’s time for kudos and credits all around, and you’ll see very little of me this post.

 

Texture & Mesh Replacement

This feature began with Uncanny_Valley and has lately been updated and maintained by TheLacus. It allows for runtime injection of new textures and meshes into Daggerfall Unity’s scene builders, setting the stage for updated models, higher resolution materials, and improvements to Daggerfall’s vanilla UI. It’s still early days but the potential is incredible. Here’s a few screenshots of new assets by community members.

 

At time of writing, mesh and texture replacements aren’t quite ready for download. But now support for this is baked into the core, you should start seeing community-created packs in the near future. You can read more about mesh and texture replacement in this thread on the forums.

 

Early Bow Combat

New contributor electrorobobody added basic bow combat to the lineup of supported weapon animation. No counting arrows yet, and you’ll need to roll a new character for your free silver bow, but it’s awesome to finally burn down enemies with ranged kiting. Looking forward to bows becoming a strong part of the game in future.

 

Save & Load Weather

Daggerfall Unity added basic weather events a while back, but they would not be saved and loaded with your games. Thanks to midopa, the current state of weather will be saved and loaded. This will only get better once correct weather events are wired up based on climate and season.

 

Enemy Steering

Another epic update by midopa. He added a little steering to enemy AI to prevent enemies from stacking on top of small creatures like rats. As hilarious as this problem could be, it’s good to see a workable solution for this bug. It’s still possible for enemies to slightly stack in edge cases, but the problem is much improved and they will no longer ride around on each other (imagine skeletons surfing rats and rat-rat-rat stacks).

 

Potion Recipes

The perennial InconsolableCellist returned with some amazing updates for us. Credit goes completely to him for working out potion recipe format and integrating with Daggerfall Unity. This also means potion recipes will display properly in inventory, and they’re even usable to see the individual ingredients. This is really important ground-work for a bunch of other things down the line.

 

Books

I wrote the initial book reader UI ages ago, but InconsolableCellist wrapped it up along with random book drops in loot, correct tooltips, and all-round awesomeness. Books currently exhibit the same formatting problems as classic (because it’s the same book data). That’s something yet to be fixed.

 

Exterior Automap

Nystul has done it again with the perfect companion UI to his dungeon and interior automap. Yep, exterior automaps are now a thing! It even supports proper tagging of buildings, zoom, and rotation. As always, I’m completely blown away by how complete this is right from the start. It’s still waiting on full building name integration and building identification in scene, but that will come. For now, all the buildings are tagged by type. Go explore!

 

Spotlight: Allofich

I can’t give Allofich high enough praise. He has worked incredibly hard tuning up different areas of Daggerfall Unity to make it more true to the original. He fixed a wide range of UI problems, identified sound effects, linked sounds to their correct actions, fixed clothing and item problems, and so on. Check out his full list of commits here. It’s hard to show these off properly in screenshot form because the changes are either subtle improvements or related to audio, but below is one of the UIs he has cleaned up. Note the poor texture joins in the “before” image (circled). Huge props to Allofich for his work!

 

Thanks To: AnKor

OK this is embarrassing. I was looking everywhere for the animations used when player was riding horse or cart. These turned out to be in the overlooked CFA image file format. Somehow, I had completely disregarded these files which are a format holdover from Arena. Yep, I’m only human. Fortunately, AnKor pointed this out on the forums and I was able to implement CFA support in no time. Now we have this:


It’s only a short jump from here to having these transport options in the game.

 

Thanks To: Testers

I also want to send out a huge thanks to all the amazing people who tested Daggerfall Unity in 2016 and reported the bugs and problems you found. There are simply too many people to list, but you know who you are. You’re on the forums, and Twitter, and Reddit, and sending me emails. You guys rock!

 

Bugs and Problems

Yep, we got ’em! Any large update like this will bring its fair share of new bugs. If you come across a bug during tests and would like to report it, please lodge this in the Bug Reports forum. Don’t forget to read the Guidelines to help you provide the best information to developers.

Contributors, please keep an eye on the Bug Reports forum for anything that might fall into your wheelhouse.

 

Where To Download?

You can always download the latest version of Daggerfall Unity from the Live Builds page. If this is your first time downloading Daggerfall Unity, welcome! Other information on Live Builds page should also help you get started. If you have any troubles, or just want to discuss updates, please go to the December 2016 Test Builds Updated thread on forums.

 

That’s it for 2016! Thank you everyone for visiting and all your kind words of support. Here’s wishing you all a very Merry Christmas and Happy New Year, and all the best for 2017!

 

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

Questing Part 2 – Compiling

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.

 

questlogmessagestuck

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.

Questing Part 1 – Source

With items and loot more or less finished, it’s time to place my sights on the next big feature group. I had originally planned to work on spells and effects in the 0.4 cycle, but also had quests in mind as an equally important feature. So back in July, I used a Twitter poll to sample what the community wanted priority on. The answer came firmly in preference for quests over spells.

Fast forward a couple months: 0.3 stable is now tagged on Live Builds page and I’ve started work on the quest system in earnest. This post is the first in a series documenting the journey from raw bytes to a working feature.

When adding a big new feature, there’s always a technical planning stage before commencement. I need to understand which of Daggerfall’s binary files are involved in the feature, learn how much is already known about those files (sometimes a lot, sometimes almost nothing), map out the additional details I need to know before I can re-implement that feature, and finally start cutting some code.

Sometimes it takes a few iterations, as writing code to pull apart the binaries is itself a journey where new information is learned. I don’t know what I don’t know, and often that new information results in a new iteration with better understanding. There’s basically a research-implement-compare loop going at all times throughout development of Daggerfall Unity. It can be a bit draining.

Items for example needed considerable research to bridge the gap between “enough knowledge to make an item editor” and “enough knowledge to fully implement items in a new engine”. Believe me, there’s a huge amount of work needed between having a file spec with lots of unknowns and building a completely functional equivalent. Most of my time is spent somewhere in that gap.

So when starting quests, I set out to learn everything I could about the binary formats and the work others had done before me. I was pleasantly surprised to learn:

  • Quests are among the most well-understood formats, thanks to the work of several early Daggerfall hackers (notably Donald Tipton and Dave Humphrey).
  • Tools exist to edit live quests, but more importantly decompile the QRC and QBN files to a human-readable source file (thanks to Template v1.11 by Tipton).
  • Early Daggerfall modders already had a good understanding of creating quests for Daggerfall – there’s an established process.
  • Quest files are one of the few cleanly decoupled things in Daggerfall. Unlike items which have template data hard-coded in the executable, quests are nicely self-contained.

With the above in mind, it was no longer necessary for me write a quest decompiler from scratch, design a new file format, decouple quest data, or chase half a dozen other time sinks. I can almost go directly to implementation. Almost. But first I need quest data in a usable form.

For the first step, I’m using Template v1.11, which you can find on UESP. This tool can decompile all the QRC (quest text) and QBN (quest programming) files to a single easy-to-read text file. So the information goes from raw binary data to the following (snippet from starting quest _BRISIEN).

QBN:
Item _letter1_ letter used 1020
Item _letter2_ letter used 1021
Item stopMainQuest letter used 1022

Person ladyBrisienna face 1 named Lady_Brisienna anyInfo 1012 rumors 1013

Place PiratesHold permanent PirateerHold1
Place _dirtypit_ remote tavern

Clock _invitepc_ 7.00:00 14.00:00
Clock _remindpc_ 30.00:00 0 flag 1 range 0 1
Clock _pcfailed_ 14.00:00 0 flag 1 range 0 1
Clock _oneday_ 1.00:00 0 flag 1 range 0 1
Clock _nowwhat_ 29.09:00 0 flag 1 range 0 1

-- Quest start-up:
 log 1010 step 0 
 pc at PiratesHold set _exitstarter_ 
 say 1025

That can still look a bit daunting if you’re not comfortable with programming concepts, but the source format generated by Template v1.11 is generally very easy to read and understand – more like a complex INI file than a real programming language. It’s so good that I’ve decided to adopt Template’s output as the source data for quests in Daggerfall Unity. You won’t need to recompile quest source back to QBN/QRC, rather you will use the source directly in Daggerfall Unity where it will be compiled at runtime by the quest system.

This means the de facto standard for creating Daggerfall quests will remain essentially the same in Daggerfall Unity (with some minor differences I’ll discuss later). If you’ve ever created a quest for Daggerfall, or even seriously looked into it, then you already have the skills to create quests in Daggerfall Unity. If you’re new to Daggerfall quests then you can learn from existing quests and read Template’s excellent documentation. Just as I don’t need to start from scratch, neither do you.

I will need to change the format slightly for unique needs on my side, but I aim to keep my input format as close as possible to Template’s output format. There’s also the need to emulate support for every single condition and action in Daggerfall Unity to behave similarly to Daggerfall given the same quest source. That will probably be an ongoing process all the way through to 1.0. But we need to start somewhere, and this is a great starting point.

The next article in series will look at parsing quest source files and how quests will be executed inside Daggerfall Unity.

 

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

Tutorial – Cloning from GitHub

If you’re interested in developing mods or contributing to Daggerfall Unity, you’ll first need to clone the project from GitHub. This light tutorial goes through the basic process of cloning Daggerfall Unity using GitHub for Desktop and opening with a fresh Unity install. There are many other ways to clone from git, but this is probably the simplest if you’re new to Unity or open source repositories.

After cloning the project, I go for a quick run through Privateer’s Hold to check everything is working normally.

Standalone Builds Update

After launching Live Builds a week ago, I’ve been very happy with the ability to push out small incremental changes. Besides the streamlined build process and less of a wait time, it also means I’m not overwhelmed with bugs every release. I can now tackle large problems fast and keep track of smaller problems for when I have the time.

This ability to turnaround builds so quickly has lead me to rethink the standalone builds (for now) and continue with the leaner, more agile cloud build process. I will revisit the standalone builds later in Daggerfall Unity’s life cycle. Here’s a summary of how to get Daggerfall Unity moving forwards:

  • GitHub always has the most recent code for developers.
  • The Live Builds page always has the most recent builds, and links for getting Daggerfall.
  • I will start to tag specific live builds as “Stable”. This means that everything implemented so far is generally working as expected.
  • I will restore the Daggerfall Tools for Unity pages as soon as possible, including updated tutorials.

If you were waiting for the convenience of a standalone build, I apologise for changing my plans. Daggerfall Unity is very much a living thing, both in terms of development and community, and can take up a large amount of my personal time. Anything that saves me time I can put back into gameplay, or spend with my family, is extremely valuable to me.

The good news is that pointing Daggerfall Unity to your game files has never been easier. The setup helper introduced with version 0.2 makes it very easy to get up and running, and you only need to download the game files once.

The first 0.3 stable build will be tagged soon. Lootable monsters just went into the latest live build and is with testers now. I only have the Rest and Keybind UIs to go and I’ve hit all the feature milestones planned for this release.

Live Builds Now Available

live-builds-header

Get Up To Date

Live builds based on latest code are now available to testers, as described in this blog post.

Check the forum topic State of 0.3 for information on 0.3 at time of writing.

 

Get The Latest Test Build

You can download latest builds from the all new Live Builds page.

 

Provide Feedback

Use the Bug Reports forum to log bugs. Please read the Bug Report Guidelines topic first.

 

Stable Builds

The latest stable build is still version 0.2.9 from 09-Apr-16. This version will be updated to 0.3.x in a few weeks once the majority of bugs have been found and eliminated.

Quick Update – 1 August

Short Delay

The 0.3 test cycle has been delayed slightly due to changing from Unity 5.3 to Unity 5.4 and less than typical free time on my end. Things are back on track for now and I estimate first 0.3 test build should be ready in approximately 7-10 days. I will update you in the case of any further delays.

 

More Information On Test Builds

I’ve had a few queries via email and Twitter about how test builds will work from 0.3. I’ll try to clarify this now. If you need more details please don’t hesitate to ask.

The short answer is that not much is really changing from your side. If you’ve tested with 0.2 or earlier the process for you is basically the same. The key difference is how builds are generated and how frequently I’m able to put a new build into your hands.

In 0.2 and earlier, I had to manually create a build for each platform, package to a zip file, upload to my host, then configure new download in WordPress and update related pages. This isn’t difficult, but it can be time consuming when rapidly turning over bugs. In many cases a bug could be fixed much faster than I could work through the manual build process. So I tended not to generate new builds until a larger block of work was completed. This ultimately means you had to wait weeks or a even a few months to see fixes.

 

Automatic Cloud Builds

Enter Unity Cloud Build. This service allows me to setup an automated build process for Daggerfall Unity’s target platforms. Cloud build works by periodically checking the git repository for changes and automatically spits out a complete new build for each platform. The download is also hosted by the cloud build servers. All I have to do is share the build and give you a download link. Here’s how it looks from the back-end:

CloudBuild-BackEnd

 

One a build is ready, I can either download a zip to test for myself, or share out a link to the public. The public link is what I’ll give to you, which takes you to a page like below. This is your front-end to the cloud build process.

CloudBuild-FrontEnd

 

To make this process even easier for you, I will setup a permalink page from dfworkshop.net that always points to the latest shared builds. I plan to update this page frequently. If the code on git changes, you’ll have a new test build not long afterwards. More information for this will be available with 0.3.

 

Rolling Builds

This is where things get interesting. Instead of waiting months for next test cycle, testers will now have a direct pipeline to code updates as they are generated. If you’ve ever played an Early Access game on Steam that gives you an “experimental/unstable” option for rapid updates, my rolling test builds are fundamentally the same concept. You will now get to play with new code as it’s being developed.

The main downside to this style of rolling build is that you will be playing with live code. Usually things will work as expected, but sometimes things that were working will break. For example, quicksave was briefly broken while I was overhauling the save interface a few weeks back.

The key is for testers to understand what is a bug and what might just be broken because it’s in the middle of changes.

 

Watching Git

To this end, I highly recommend testers keep an eye on the commits page on git. These commits tell a story of what is being worked on and what has been recently fixed. If you see that I’m working on a big system (like saves or looting), then you can bet something will be broken in that system until work is complete. I try to keep my commits exclusive to a specific update and provide good descriptions. I’ll continue to work on improving the quality of my checkins as time goes on.

 

Providing Feedback

As before, the Daggerfall Workshop Forums are the correct place to log bugs or ask questions about a feature. Specifically the Issues & Support forum. If you aren’t sure if a feature has been implemented yet (e.g. quests), please ask before logging the absence of this feature as a bug. Daggerfall Unity is a live work in progress and some features are much further down the pipeline than others.

At every major milestone, I will post some information on things that need the most attention from testers. For example, the loot and inventory system was the major component of 0.2.

 

Stable Builds

If you don’t feel up to watching git, downloading test builds, testing features, and providing feedback – that’s OK! I will occasionally release a “stable build” at major milestones where everything is more or less running as expected. Not everyone has the time or interest to be a full-on tester, and that’s all good. Just grab the stable builds when they’re available and let people know about Daggerfall Unity.

The first 0.3 stable build will be available a couple of weeks after the first test build. This gives me a chance to nail any show-stopping bugs before putting the stable build into your hands. I’ll post an update on this when available.

 

Conclusion

I hope that clarifies the new build process more thoroughly. In summary:

  • You’ll get new builds almost as quickly as code changes. The latest build might be awesome or it might not even run.
  • I will provide a permalink page on dfworkshop.net that always points to latest several builds.
  • Keep an eye on git commits to see what’s being worked on.
  • Post feedback, bug reports, and questions to the Issues & Support forum.

Thank you for reading. I look forward to you joining me for the next big step in Daggerfall Unity’s development process.

 

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

New Options For Downloading Builds

The 0.3 release should be wrapped up in the next week or so, provided nothing comes up in testing to cause delays. Along with 0.3 there will be more options for downloading builds to better cater to various groups in the community. Read on to see what’s coming up.

 

 

get-play

 

If you just want to take a quick look at Daggerfall Unity, and avoid the hassles of a test setup, then 0.3 might encourage you to try it out.

  • New standalone builds will be made available for each platform (Windows/Mac/Linux).
  • Standalone builds are self contained and do not require you to provide Daggerfall game files.
  • Standalone builds will be updated less frequently but will generally be more stable.

 

 

get-test

 

If you’re an existing tester, or would like to help catch bugs, then I have some good news.

  • Test builds are now automated using Unity Cloud build and will be updated approximately weekly, or daily during heavy development.
  • However, test builds are based on live code and will not be as stable as standalone builds.
  • Test builds are cut-down for smallest download and will require you to provide your own Daggerfall game files (just like previous test builds).

 

 

get-mod

 

The biggest feature in 0.3 is Lypyl’s mod system, which he introduced a few posts back. The mod system allows you create asset bundles containing code, textures, sound, etc. that can change how Daggerfall Unity works.

  • Modders will need a copy of Unity3D 5.3 Personal/Plus/Pro and a copy of game files.
  • Modders are encouraged to clone from git (tutorial coming soon), but just downloading a zip of current project should be adequate.
  • New forum areas will be opened to help modders find each other and collaborate on projects.

 

 

get-contribute

 

If you would like to contribute to Daggerfall Unity, and have a good understanding of both Daggerfall’s inner workings and Unity3D, it will become easier to contribute from 0.3.

  • Full Daggerfall Unity project is now on git. Contributors should create their own fork of project.
  • Contributors will need a copy of Unity3D 5.3 Personal/Plus/Pro and a copy of game files.
  • Contributors will also get new forum areas for discussion.
  • A Trello page is in the works to help contributors find tasks they may be able to help with.

 

That all for now. Hopefully 0.3 will represent a new stage in the development of Daggerfall Unity, with even more options for gamers, testers, modders, and contributors.

 

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