Localizing Strings in Daggerfall Unity – Part 6

Series
Localizing Strings in Daggerfall Unity – Part 1
Localizing Strings in Daggerfall Unity – Part 2
Localizing Strings in Daggerfall Unity – Part 3
Localizing Strings in Daggerfall Unity – Part 4
Localizing Strings in Daggerfall Unity – Part 5
Localizing Strings in Daggerfall Unity – Part 6

Custom Fonts

Note: Before progressing to this tutorial, please update source project to Daggerfall Unity 0.11.3 or later. This version has fixes required to complete this part in series.

In Part 3 of this series, we noted the Korean (ko) locale would print out question mark characters (?? ???) instead of proper glyphs.

This happens because Daggerfall Unity does not yet have an appropriate font asset to render these characters. The default fonts have a full complement of Latin characters but non-Latin languages require a new font to display their unique alphabet.

This tutorial will demonstrate how to add a custom Korean font with a Hangul alphabet to Daggerfall Unity, but the same process can be used to add Cyrillic fonts, Kanji fonts, or even just a custom default font.

The font we’ll be using is Noto Serif KR from Google Fonts. Click Download family on that page to download the font used in this tutorial, or substitute with another TTF/OTF font for your language.

Once downloaded, unzip the whole font family and locate NotoSerifKR-Regular.otf. This is the specific font we’ll be using. To start with, we’ll add this font to our Unity project.

  1. In Project view, navigate to our DemoTranslationMod/Resources folder.
  2. Drag and drop the NotoSerifKR-Regular.otf font into this folder with other resources. Unity will import this like below.

Create TextMeshPro Font

Daggerfall Unity uses TextMeshPro (TMP) fonts. Before we can see this font in game, we need to create a TMP font asset.

  1. Click Window menu > TextMeshPro > Font Asset Creator
  2. Set NotoSerifKR-Regular in Source Font File by clicking the circle selector on right-hand side then selecting font

Now we need to determine which character codes our TMP font will support. This will vary based on many factors unique to the target language, but the core concept is that we want to inform Font Asset Creator which character codes from your alphabet to compile into your TMP font. Any characters not added to TMP font asset will continue to display as question marks in game.

There are multiple ways to describe which characters to use. You can select from a basic list of settings, use decimal/hex ranges, import from another TMP font, import from a file, etc. Whatever method you use, keep track of the settings so you can add to it later if any characters are found missing.

In this example, we’re going to use a subset of Hangul alphabet by directly entering the characters required. It’s better to start with a subset of characters for the region/dialect you’re targeting rather than just trying to include everything. Some languages have thousands of characters which can result in an unusable TMP atlas without enough fidelity.

  1. In Font Asset Creator, drop down Character Set selector and choose Custom Characters
  2. Copy and paste the following custom characters into the Custom Character List text box. Note the very first character is a space character.
 ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz가개갸거게겨고괴괘교구귀궤규그긔기나내냐너네녀노뇌놰뇨누뉘눼뉴느늬니다대댜더데뎌도되돼됴두뒤뒈류드듸디라래랴러레려로뢰뢔료루뤼뤠류르릐리마매먀머메며모뫼뫠묘무뮈뭬뮤므믜미바배뱌버베벼보뵈봬뵤부뷔붸뷰브븨비사새샤서세셔소쇠쇄쇼수쉬쉐슈브븨비아애야어에여오외왜요우위웨유으의이자재쟈저제져조죄좨죠주쥐줴쥬즈즤지차채챠처체쳐초최쵀쵸추취췌츄츠츼치카캐캬커케켜코쾨쾌쿄쿠퀴퀘큐크킈키타태탸터테텨토퇴퇘툐투튀퉤튜트틔티파패퍄퍼페펴포푀퐤표푸퓌풰퓨프픠피하해햐허헤혀호회홰효후휘훼휴흐희히역을선택십시1234567890‘?’“!”(%)[#]{@}/&\<-+÷×=>®©$€£¥¢:;,.*…

The above characters are enough for this tutorial, but will need to be expanded for full language support. This is how it looks in Font Asset Creator. We’re also adding the basic English alphabet to have a well-rounded font that can still display any untranslated English text.

Click Generate Font Atlas to render all the specified characters into a TMP atlas. Once you’ve created the atlas, you’ll see all the characters packed like below. Click for full size.

TextMeshPro renders glyphs using signed distance fields (SDF). How this works is outside the scope of this tutorial, but to summarise it’s a way of representing fonts using mathematical values that can maintain smooth shapes at any resolution.

In the output field, take note of the Missing characters, Excluded characters, and “characters missing from font file”. This will display any character codes you requested but could not be found in the provided TTF/OTF font. If your source font is missing any important characters, then it’s necessary to locate another TTF/OTF font containing those characters.

Depending on your font requirements, you might want to increase Atlas Resolution, e.g. to 4096×4096 or higher to support more characters with good fidelity. You can also adjust packing method, sample size, etc. for your specific font needs.

For this tutorial, the atlas generated above is good enough. Click the Save button and save your new TMP font to DemoTranslationMod/Resources. We’ll use the default name in a moment, please don’t change it. This creates a new TMP font asset like below with the name “NotoSerifKR-Regular SDF”.

This new SDF asset contains the atlas and other information required to render the TMP font in Daggerfall Unity. You can come back and recreate the font later with different properties or more characters if needed.

Associate Font With Locale

There’s one more step before can see this font in game. We need to associate our custom font with the correct locale so that Daggerfall Unity knows to use it. This is done using the StartupScript.cs code we created previously.

Open StartupScript.cs in your code editor and replace the entire contents with below. Don’t forget to save your changes!

using UnityEngine;
using UnityEngine.Localization;
using UnityEngine.Localization.Settings;
using DaggerfallWorkshop.Game;
using DaggerfallWorkshop.Game.Utility.ModSupport;
using DaggerfallWorkshop.Game.UserInterface;

namespace DemoTranslationMod
{
    public class StartupScript : MonoBehaviour
    {
        // Define the names of translated string table collections
        const string runtimeInternalStrings = "Demo_Strings";
        const string runtimeRSCStrings = "Demo_RSC";

        public static Mod mod;

        [Invoke(StateManager.StateTypes.Start, 0)]
        public static void Init(InitParams initParams)
        {
            mod = initParams.Mod;
            var go = new GameObject(mod.Title);
            go.AddComponent<StartupScript>();
        }

        private void Awake()
        {
            // Set TextManager properties to use translated string table collections
            TextManager.Instance.RuntimeInternalStrings = runtimeInternalStrings;
            TextManager.Instance.RuntimeRSCStrings = runtimeRSCStrings;

            // Load KO font
            DaggerfallFont font_ko = new DaggerfallFont(DaggerfallFont.FontName.FONT0003);
            font_ko.LoadSDFFontAsset("NotoSerifKR-Regular SDF");

            // Assign KO font
            Locale ko = LocalizationSettings.AvailableLocales.GetLocale("ko");
            if (ko)
            {
                TextManager.Instance.RegisterLocalizedFont(ko, DaggerfallFont.FontName.FONT0003, font_ko);
            }

            Debug.Log("StartScript has completed.");
        }
    }
}

Let’s take a look at what changed. To start with, we added some new using statements. These import some extra functionality to the script.

using UnityEngine.Localization;
using UnityEngine.Localization.Settings;
using DaggerfallWorkshop.Game.UserInterface;

Then we added the following code to associate our custom font with the KO locale to Daggerfall’s FONT003. This is the default font used in most parts of the game.

// Load KO font
DaggerfallFont font_ko = new DaggerfallFont(DaggerfallFont.FontName.FONT0003);
font_ko.LoadSDFFontAsset("NotoSerifKR-Regular SDF");

// Assign KO font
Locale ko = LocalizationSettings.AvailableLocales.GetLocale("ko");
if (ko)
{
    TextManager.Instance.RegisterLocalizedFont(ko, DaggerfallFont.FontName.FONT0003, font_ko);
}

First, we create a custom DaggerfallFont called font_ko. By default we’re loading FONT003, but we’ll replace this in a moment with our custom font.

Second, we tell font_ko to load our custom font asset using LoadSDFFontAsset(). Any font created using the TextMeshPro Font Asset Creator should load OK. Reminder: you need to be on Daggerfall Unity 0.11.3 or later.

Finally, we try to get the “ko” locale and only continue if this locale is found. If the locale is found, we associate our custom DaggerfallFont with the “ko” locale using RegisterLocalizedFont().

When this code executes at startup, Daggerfall Unity now knows it should use a different font when rendering FONT003 within the Korean (ko) locale. You can associate the same SDF font with FONT001, FONT002, etc. but you might want to use different styles of typefaces to better match the desired look and feel in your translation.

Make sure your changes are saved, then we can try this font in game.

  1. Click Play to start the game and click through to title menu.
  2. Use the locale drop-down to select Korean (ko) in Game view.
  3. Click Start New Game in title menu. If everything works as expected, our custom font will be selected and used with our translated text example.

Click Play again to stop game.

To summarise, creating a custom font requires the following steps:

  1. Locate appropriate TTF/OTF source fonts for your language. These fonts must contain all the alphabet characters you need for your translation.
  2. Import the TTF/OTF font into Unity project.
  3. Use the Font Asset Creator to generate a custom TMP font asset with the required characters and resolution.
  4. Associate new font with your custom locale and related Daggerfall font in startup C# script.

You might need to recreate font several times when creating your translation mod, either to add new characters, change resolution, or just finetune the look and feel. If you change the asset name, don’t forget to update this in your startup script.

Now that we have a custom font, we can move on to packaging our localisation to standalone files. This will be covered in Localizing Strings in Daggerfall Unity – Part 7.

Daggerfall Unity Beta 0.11.0 – Milestone Accomplished

The first official beta release for Daggerfall Unity is now ready to download from Live Builds page. This is only a small update over 0.10.28 release, which was a “pre-beta” test just to make sure there were no showstopping bugs before Beta proper. If you haven’t already, please read that article for more information about recent builds.

So yeah – beta. The game is feature complete and working well. If you’ve been waiting to play Daggerfall with smooth controls, quality of life improvements, and epic mod support, there has never been a better time than now. We still have some quirks and bugs that need to be fixed, but after 18 months of intensive fixes and improvements during alpha, this game is in pretty good shape. The feedback loop of near-monthly releases to community with rapid fixes over several years has proven to be a good formula for this kind of game. This will continue right through to 1.0 and beyond to make the best version of Daggerfall possible. Only the frequency and magnitude of updates will slow down as there’s not much left on the plate beyond fixing bugs and gradually expanding mod support.

If this is your first time here – welcome! You might also be wondering what Daggerfall Unity is, how it came to be, and who were the people involved? So rather than just info-dump the small number of changes in this release (scroll to the end for that), I thought it might be a good time to take a look back at the journey leading up to this point. We only get to reach beta once, so pull up a chair and settle in for the ultra-condensed version. I won’t bore you with the full history, you can check out the About page and this tweetstorm for more about me and this whole journey.

 

The Early Days 1996-2003

My name is Gavin “Interkarma” Clayton and Daggerfall Workshop is my site. After buying Daggerfall in 1996, I fell in love with the game. So much so that by 2000/2001, I began writing tools to view textures and 3D models from the game, including small chunks of locations called “blocks”. This culminated in a program called Daggerfall Explorer written for Windows 95, which incredibly still works today. Daggerfall Explorer was written in C++ and used a custom 3D engine on top of DirectX 8.1 which I called the Alchemy Engine. Sweet name, right?

 

Notable other people around this time were Dave Humphrey who founded the UESP, and Donald Tipton who made several excellent tools. There were many others hacking away at the game data formats back then, and my early efforts build directly on the knowledge they shared. Not everything was well understood, however. Some real basics like how UV coordinates were stored and several other file formats were still a complete mystery. These would continue to be understood as the years rolled by thanks to a sharing and wonderful community.

I continued to build more tools for Daggerfall such as Daggerfall Cartographer (view full cities), Daggerfall Imaging (view and export textures), and Daggerfall Jukebox (play and export music). Late in this tool-building stage, around 2003, I actually attempted a Daggerfall remake that didn’t get off the ground. I didn’t have the experience and the necessary social framework for this kind of project simply didn’t exist, so this attempt failed rather quickly. It was a good learning experience, but my interest faded for a while after that.

 

More Tools 2009-2012

In 2009, I got back to work building more Daggerfall tools. This time around, I constructed a C# library called Daggerfall Connect to read the game data formats and update with some of the new understanding of file formats that had emerged through the intervening years. This culminated in Daggerfall Imaging 2 and Daggerfall Modelling, both evolutions of my previous tools. By this point, it was possible to explore entire cities and dungeons, and even export models to COLLADA format.

 

A code library written in C# turned out to be a great decision. This library was very fast and portable between engines – even operating systems. Without realising it, I was laying the foundation of would eventually become Daggerfall Unity.

 

Daggerfall Tools for Unity 2014

Looking around for something to do while learning the Unity engine in 2014, my wife suggested doing something Daggerfall related. Start with something familiar to learn something new. After a few hours of tinkering, I found my old C# Daggerfall Connect library would plug directly into Unity, and I had the foundation of what became Daggerfall Tools for Unity.

 

In a couple of months, I had the whole world working with basic exploration and combat, and it was obvious we had something special on our hands. It wasn’t a full remake just yet, but even at this early stage a few contributors had appeared like Lypyl and Nystul, helping to expand the tools and show just how easy it was to create cool Daggerfall stuff. Remixing and rebuilding Daggerfall had never been more open and easy to all-comers.

 

Daggerfall Unity 2015-Present

By mid-2015, the number of voices asking for a true remake became overwhelming. I drafted a Mission Statement and a Roadmap that would define the next several years of my life, and the lives of many others. By November 2015, the first test build of Daggerfall Unity was released with Character Creation and most of the game’s framework in place. It was pretty raw and I still had no idea how to do a lot of stuff, but the bones were solid and the heart was beating strongly.

This is where other serious contributors started appearing and helping to build the game. After Lypyl and Nystul came TheLacus, InconsolableCellist, Allofich, Hazelnut, Numidium, Meteoric Dragon, Pango, Jay_H, Ferital, JorisVanEijden, and jefetienne. These were the contributors who made frequent and substantial contributions to the game and it’s underlying code.

It’s simply not possible to cover everyone’s work over the last several years in full detail, but I’ll try to cover the highlights. Read back through the update archive on this site for the full history or review our GitHub Contributors page to see just how much work has gone into this game. I’ll keep expanding this list out as the right words come to me. If anyone feels left out here, it’s not intentional. There are just too many people involved and so many years of work to think of everything. If I’ve missed something you’re proud of, please contact me and I’ll add it below.

Lypyl was the very first contributor and champion of Daggerfall Tools for Unity. He reverse engineered and implemented pretty much all remaining dungeon action records, and did some truly wild and wonderful things with DFTFU. He created the Enhanced Sky mod and architected the foundations of the mod system we still use today.

Nystul implemented the Automap and Talk UIs, and some amazing early mods like Distant Terrain and Realtime Reflections. Nystul was also involved in several other systems critical to the game’s early development.

TheLacus is most known for dialling the mod system up to 11 and building on top of Lypyl’s early foundations. TheLacus also documented the Daggerfall Unity API and mod systems in great detail, and created excellent tools around mod and quest authoring. Without this important work, the mod scene would be much smaller than it is today.

Allofich famously excavated the guts of classic Daggerfall to help DFU stay true to classic’s formulas and behaviours. Allofich also implemented advanced enemy AI and much more. His insights into Daggerfall’s inner workings advanced our knowledge well beyond the Chronicles and UESP alone. The game we have today would be far more divergent without him.

Ferital also reverse engineered several vital systems from classic and helped them reach parity in DFU. The talk and reputation systems particularly were refined extensively by Ferital. He’s also known for fixing many texture issues and other small gripes with classic game data so that DFU can be a better experience. On a personal note, Ferital was one of the first to encourage and support my exploring tools back in the early 2000s.

Hazelnut burst onto the scene with horse riding and went on to implement guild services, taverns, potion maker, and much, much more. Hazelnut is also a powerful force in the modding community, building support and helping others come to grips with the mod system. His mods are legendary, including Archaeologists, Roleplay & Realism (with Ralzar in parts), Basic Roads, and more. He is not only one of the most prolific contributors to Daggerfall Unity, he has been a true friend and supported me privately through some of the darker months. There’s no way to accurately capture just how important Hazelnut is to this project.

Meteoric Dragon built Advanced Climbing and other movement & camera systems. He also helped refine systems like underwater swimming, climbing out of water, and smoothly mantling onto a surface. If you walk, run, jump, swim, climb, or fly in Daggerfall Unity then you’ve experienced Meteoric Dragon’s work. He also added some work to the effect system and a few other subsystems beyond movement.

Jay_H was our resident quest ninja, building hundreds of new quests for Quest Pack 1 while performing deep fixes and improvements to the classic quests. Jay_H was also a positive force in the community helping others come to grips with the quest system and always ready with kindness for others. He helped moderate the forums and keep our little corner of the web a nice place to visit.

JorisVanEijden expanded our knowledge of the quest system, helping it to reach closer parity with classic. He also refined many subsystems and expanded on areas where my work could be considered “placeholder” at best. Joris was another one who patiently supported me when I struggled to understand something fully. The game is better in several places thanks to his help.

Jefetienne constructed the controller input system while overhauling and improving many part of input and related UIs. He is also known for opening some parts of the core game up to mod system, and helping to find and fix several bugs. He also created the screenshot feature and advanced keybinds UI.

Numidium is best known for custom class creator, class questionnaire, and many fixes and improvements across the core game. Numidium also implemented several artifacts for the effect system and bug fixes in other parts of the game.

Pango is another prolific core contributor to Daggerfall Unity. He worked hard through every system of the game, fixing bugs and improving as he went. I’ve watched him support people on several platforms in multiple languages. There just aren’t enough words for how important Pango was to this whole process. There was no job too big or too small for him to take on. He filled in the blanks where my own knowledge was lacking, and remained patient with me when I lacked understanding. Daggerfall Unity would be half the game it is today without his patient and clever hands on the wheel alongside us.

On the modding side, there are also many notable figures who deserve a mention.

King of Worms created the amazing D.R.E.A.M. mod which enhances almost every part of Daggerfall Unity from the textures to the music, to little touches like night and day dungeon exits. His work became so familiar that to many people it’s simply impossible to play Daggerfall Unity without his mods installed.

AlexanderSig crafted the sublime handpainted 3D models to uplift the base assets and even replace many 2D objects with true 3D objects. His work is also closely associated with Daggerfall Unity.

Uncanny_Valley is behind Taverns Redone, Mountains & Hills, and more.

Ralzar has created almost a dozen fantastic mods like Climates & Calories, Torch Taker, Realistic Wagon, Unlevelled Loot, and more. He has also been active helping users across the forums and on reddit.

Kamer is the mastermind behind the fiendish Warm Ashes quest mods pack, adding dangerous encounters around dungeons, wilderness encounters, sieges, and more. He has also created visual mods adding Rocks and Windmills, and expanded on town populations in Villager Immersion Overhaul.

There are so many others who made important contributions helping Daggerfall Unity become what it is today. Head over to the Credits topic on forums to see a complete list. In total, more than 45 people helped to make Daggerfall Unity. That’s just on the development side, it doesn’t count the modders and scores of community members reporting bugs over the years. Something that started as a small solo project quickly exploded into one of the most comprehensive and successful fan recreations of a classic game to date. Even if you hold no love for this project, it’s hard to deny just how hard everyone worked, how much love was involved, and how successful the project model proved to be.

 

Plea for a Future

Daggerfall Unity is made by the Daggerfall community out of love and love alone. This project has never been and will never be monetised. This site has no advertisements and no donation button. I didn’t create a Patreon for the whole of Daggerfall Unity’s development. Every time someone offered to contribute money to me or the project, I politely refused. At every turn, I tried to send a clear message this project is not about making money from Bethesda’s intellectual property. Even the name Daggerfall Unity is more a play on words – it references the engine used but is really a testament to the open development process. Daggerfall Community Edition would have been just as good a name.

Furthermore, you must own a copy of Daggerfall for the asset files essential to make Daggerfall Unity work. It’s a drop-in engine replacement over the original game, not a standalone product. Thankfully, Daggerfall itself has been freely available from Bethesda themselves and many other places online for several years. This means DFU is really a free upgrade to a free game, made by the community for the community.

For all these years, Bethesda has quietly tolerated our tiny presence working in their shadow to rebuild and reimagine their greatest early game. They could have squashed this project at any time, but mercifully chose to let it thrive as an offshoot to the wider Elder Scrolls modding scene. For that, I want to say thankyou. From the bottom of my heart – thank you. This game means the world to me and many thousands of other people. I’ve been contacted by people who said this game played a part in helping them out of depression and reconnecting with friends, that it made their lives better. I believe these heartfelt words and it brings me joy to know all these years of work have brought other people some happiness.

With that, I want to make a simple plea. Please let Daggerfall Unity continue to thrive in the hands of the community who created it. As ownership of The Elder Scrolls passes to Microsoft and into new hands, please let this project continue to be everything it can be. This is something special and virtually unique. A functioning and complete fan recreation that survived not only its own development but the potential of being shut down at any time. It’s a strange and beautiful thing that has no real right to exist, and yet here it is. Please let it continue to be.

 

Conclusion

That’s all from me for now. Daggerfall Unity is feature complete and can only get better from here. The beta builds are ready for download and Nexus has well over a hundred Daggerfall Unity mods all ready for your enjoyment. Go play and be happy, then send us some feedback. We made it so far thanks to positivity and encouragement from others, and I’m confident that will continue into the future as we approach 1.0. Even as our many developers come and go, the project itself lives on with its singular spirit of collaboration.

As promised, there are a few changes in the 0.11.0 release. Here’s a quick list for anyone wanting the patch notes for this version.

  • Alternate Music setting to play FM versions of songs (Numidium)
  • Allow custom Renderer for ObjectPositioner (TheLacus)
  • Improve indoor guard spawns to use farthest entrance (Numidium)
  • Harden SettingsManager against bad values read to reduce most cases of broken settings.ini causing a black screen (Interkarma)
  • Flag emission for special case windows 036_2, 151_3, 154_3, 351_3 (Interkarma)
  • Fix desert Mages Guild window emission (Interkarma)

Identifying Buildings And NPCs

In my last post, I talked about the “Place” quest resource and merging map-level data down to block-level. The next step from here is to propagate this information to scene-level where the player ultimately lives. I decided to tackle this along with a start on Daggerfall’s interaction modes, i.e. Steal, Grab, Info, Talk which are by default bound to keys F1-F4. What I’m most interested in here is the ability to perform an info click directly on a building to discover its name.

First step was to quickly implement the mode switch itself. Key-kinds were already in place inside the InputManager class, all I needed were a few more lines of code to track which mode player was in and a new HUD label to present switch to user. After several minutes it was possible to flip between the 4 interaction modes.

 

Next, I needed a way of detecting when player clicks on a building. I already track player clicks in PlayerActivate class, and can detect clicks on static scenery and doors, but not on the building model itself. I go to work looking for an efficient way to manage this. Each Daggerfall model contains a radius value stating the overall size from its centre point. This seemed like a good place to start, so I overlay the radius as a sphere collider on test buildings.

 

Keep in mind that I’m not storing individual building models at scene level, the entire block of buildings above is combined into one large model. This is more efficient for rendering and results in fewer draw calls to the graphics card. So I don’t know which building player has clicked on – I just know they’ve clicked a combined block model and I need to resolve that back to a specific building. The sphere colliders would do the job, but they unfortunately suffer from a lot of overlap. Depending on where player is standing and where they clicked on the building, it’s possible for that target point to be inside two or three different building spheres. There are ways of handling this of course, but I decided to go with box colliders instead that will tightly wrap Daggerfall’s little box houses.

Before I can implement boxes, I had to go right back to the procedural mesh builders that extract data from ARCH3D.BSA (Daggerfall’s 3D model archive). During the vertex conversion process, I added some tracking for minimum and maximum vertex positions from origin to get the overall size of models in X, Y, Z space. Because the models are being constructed procedurally, and I have to process that information anyway, this step adds almost no overhead to the job of loading models at runtime. I now have what I need to construct a tight bounding box around any model effectively for free.

Then I just had to pass that information to scene builders. The end result looks like this.

 

Every building now has a nice crisp bounding box trigger collider. While this is great to visualise the bounds, I’m not happy with adding so many GameObjects to scene. A large city like Daggerfall will add around 800+ new collider GameObjects. If a few large cities are in the world at once, then it’s very possible that 2000-3000 colliders would be added to scene, the majority of which will never be used. Not ideal from an optimisation point of view.

To work around this, I used the same solution I came up with for doors. I store the box information for every building on the block GameObject itself using component DaggerfallStaticBuildings. This is just a small amount of raw data stored on each block. When the player clicks on a block in scene level, a single box trigger is instantiated and tested for each of the buildings in that block, usually no more than 5-14 buildings. The world-space point of impact for hit ray is tested against known buildings in that block (and only those buildings). If a hit point intersects with a known building trigger in world space, then everything we need to know about that building from scene layout time is returned to PlayerActivate.

The end result is zero new collider objects in the scene and only a small amount of overhead for storing building data and testing hits, which happens only when the player clicks on a city block. The net result has practically no performance impact and still fits nicely hand in glove with Unity’s physics setup. With all of that in place, player can finally make info clicks on buildings in scene.

While I was working on this, I decided to add shop quality text. When the player enters a shop in Daggerfall, the overall quality level is presented to player as a popup. Each shop has a quality value between 1 and 20 with a total of 5 different quality popups. I’ve long assumed it was just qualityValue/4 to get the popup, but testing proved otherwise. Daggerfall weights the quality text a bit more in the mid-range that the extreme low or high ends. After checking shops in Daggerfall city and Gothway Garden, I think I have the weightings worked out. Anyway, It’s something that can be easily tweaked later if needed. Now when player enters a shop, the quality text will popup like in classic.

 

Because the popup actually prevents player from entering building until they click a second time, I added a quick INI option to present quality text to HUD instead, with a configurable delay. With this option configured in INI (ShopQualityPresentation=1), you can enter every building with a single click and watch the quality text scroll off HUD. You can also set ShopQualityPresentation=2 just to turn off quality text completely.

 

While I was on a roll with the whole info setup, I made a start on identifying static NPCs. These are the flat people standing around inside buildings and interior environments like Daggerfall Castle. This will be critical to dialogue as part of questing system eventually, so might as well break some ground for later. The first part of this was simple, just detecting when player clicks on an NPC.

 

Yep, that’s an NPC alright. Exactly how an NPC is detected had to evolve a little over the process of getting this initial text in place. I previously did this by detecting if the billboard had a faction and a gender – something I assumed only NPC billboards would have. This turned out not to be the case and there are plenty of factionless NPCs standing around. Also, the NPCs in building interiors had a different metadata setup to NPCs in dungeons. Just like Daggerfall to use two different data structures for effectively similar things. I ultimately determined NPC status by the texture archive flat belonged to. There are a small range of NPC-specific texture archives and this served better than faction to determine if player has clicked an NPC or not. In the process of doing all this, I actually gained some better understanding of a particular bitfield and found a new gender bit assigned to NPC records.

Before I can identify an NPC properly, I need to use their faction information. An NPC with faction type=4 is an individual NPC which means their name comes directly from faction data. Other NPCs just get a random name generated based on their gender. So before diving any farther down this rabbit hole, I have to implement factions for the player.

I had written faction file reader around a year ago, but this just reads the initial database from FACTION.TXT in game data. In Daggerfall, this initial faction data is assigned to player character at time of creation and persists with player all through their adventuring career. Every interaction can raise or lower their standing with a particular group. To start tracking faction data properly, and to make this information available to NPC info clicks, I added the PersistentFactionData class to player entity. This class represents the player’s current standing with all factions and provides basic lookup functionality. This has already been wired up to save/load system, so when you save a game in future builds, your faction data will be saved as well. This is also an important milestone for the questing system.

With faction data on the player, we can identify individual NPCs like King Gothryd and Queen Aubk-i.

 

But it means that group-based NPCs don’t resolve properly by faction alone.

 

These NPCs need to have a random name based on gender. Thankfully I’ve already written the random name generators, as these were required for building names and elsewhere. The only thing I’m missing is the correct seed value to generate the exact NPC name that Daggerfall uses. For anyone unfamiliar with random generators, the same seed value will always output the same result. Unfortunately, I wasn’t able to find the seed value Daggerfall was using to name NPCs. You’d think this would be obvious like it was for buildings, but sadly not. I decided that one random name is probably as good as any other for these non-essential NPCs and just used their record offset as a seed value. This means they will always have the same persistent name generated each time, it just won’t be the same name as in classic. If the correct seed value is ever located, I can just feed this into the generator instead and the correct name will pop out. Until then, it probably doesn’t really matter. Say hello to random NPC Alabyval Coppersmith.

 

At the end of this little coding adventure, all of the following has fallen into place:

  • Change activation mode between Steal, Grab, Info, Talk.
  • Identify buildings and static NPCs.
  • Shop quality text is now displayed when entering a shop.
  • Faction data now exists on player entity and persists with your save games.
  • The foundation for checking NPCs in scene are ready for “Person” quest resource.
  • The raw data needed for “Place” quest resource now in scene.

With all that done, I can go back to working on “Place” resource and “pc at” condition for quest system. You can see what a rabbit-hole this whole quest setup is. It touches on so many different parts of gameplay that sometimes I need to go in a different direction for a while before I can loop back and progress on what I’m trying to build. But it all adds up, and every tiny step brings us closer to real gameplay.

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

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.

Tutorial – Getting Started

The latest version of Daggerfall Tools for Unity is now available. You can either clone the full project from GitHub or download the standalone asset package from the Daggerfall Tools for Unity project page.

This version of DFTFU might need to be updated a few times as tutorials are rolled out. The current version is 1.6.1, please grab later version if available.

I have also posted the updated Getting Started tutorial to the DFTFU Tutorials page. Image link below will take you straight to tutorial.

GettingStartedTutorialImage

Click image to open tutorial

Upcoming Release 0.3

The 0.3 point release is coming together and should be available sometime late in July. Here’s a quick summary of upcoming features.

 

Modding Support

Lypyl’s mod framework is undoubtedly the star of 0.3. You can read his post about it and check out a few work-in-progress tutorials on the forums. While still early days, I couldn’t be happier with this feature and the potential it brings to Daggerfall Unity.

  • Mods can be created using Unity Personal (free version) and Daggerfall Tools for Unity.
  • Completed mods are packaged to a standalone .dfmod file (asset bundle) for distribution.
  • Integrated mod loader at startup with ability to change load order.
  • Fully integrated run-time C# compiler.
  • Total access to inner workings of Daggerfall Unity.
  • Catch events, display UI windows, spawn world objects, drive game logic.

The mod system is already powerful enough to handle the current round of mods, which will eventually be migrated into .dfmod format. As mod creators grow in experience and the underlying code is expanded to provide more options almost anything will be possible down the road.

 

Treasure & Loot

Random treasure piles and corpse markers will now be lootable, providing gold and new items to you during testing.

  • Player will now find gold and items in random treasure piles and on the bodies of slain foes.
  • Generated items will not have magical powers until the spells & effects features are live.
  • It will be possible to drop items to the ground, but like Daggerfall dropped items will disappear when you leave the area. Non-volatile player storage will be implemented much later as part of housing.

As shops are not implemented yet, I’m going to ignore weight limits on the player and the wagon so you can carry as much as you want. Proper encumbrance tracking will be added in the future after shops come online.

 

New UI Windows

A few UI windows are in the works for 0.3, although not all of them will be ready for initial release. They will come online over the 0.3 cycle.

  • Control mapping UI.
  • Rest UI.
  • Save/Load UI.

As part of updating save/load UI, the way games are saved will be expanded during 0.3 to accommodate the growing amount of data needed to support saving game state.

 

Standalone Builds

From 0.3, I’m going to provide a standalone build of Daggerfall Unity with game files bundled. This will be in addition to the smaller builds where you must provide your own game files. This change is to help users who just wish to quickly try out Daggerfall Unity or have trouble installing a compatible version for any reason.

  • Standalone builds will be substantially larger and updated less often than the trimmed-down test builds.
  • Test builds will be smaller and require you to provide your own set of compatible game files. This is still the best download for dedicated testers.

 

Bug Fixes & Small Improvements

Last but by no means least will be the usual round of small fixes and improvements to features already added. There’s also a bit going on behind the scenes to support future systems like spells & effects, NPCs, factions, shops, and questing. These additions will be slowly rolled out as more features come online post 0.3.

For more frequent micro updates and news, follow me on Twitter @gav_clayton.