Web Demo Test

I’ve uploaded a few simple Unity Web Player demos for my own test purposes. If anyone is interested, you can access them from the URLs below.

Controls are WSAD to move, mouse to look, Shift to toggle run, Space to jump, ESC to uncapture mouse.

If you have trouble launching the web player in Internet Explorer, try Chrome and see if that works.

Exterior (Daggerfall City)
http://www.dfworkshop.net/web_demos/daggerfallcity-test1/daggerfallcity-test1.html

Exterior (Daggerfall City, point filtering)
http://www.dfworkshop.net/web_demos/daggerfallcity-test2/daggerfallcity-test2.html

Dungeon (Privateer’s Hold)
http://www.dfworkshop.net/web_demos/privateers-test1/privateers-test1.html

This is a work-in-progress build, so don’t expect too much awesome just yet. These demos are mainly interesting in that I put them both together from an empty scene and uploaded in less than 10 minutes.

One more thing. I’ve disabled doors in the Privateer’s Hold test, as interacting with moving objects is still being written. You can get to the exit room without riding the throne up. See if you can remember how. ;)

Tools for Unity Roadmap

I’ve been thinking about the release structure leading up to v1.0 of Daggerfall Tools for Unity. Up until now, I’ve been building new features right across the spectrum. I’ll be working on monsters one day, then lighting the next, then improving the editor, then working on action scripts in dungeons, and so on. Each of these pieces must be worked over a few times before I’m happy. However, I’d like to keep the releases coming and can’t let myself become too distracted. I need to step up a little.

I’ve decided there are certain groups of features that work well together, and I’d like to zoom in on these features based on where they fit. There will be a little crossover, as some features like basic monsters are already in.

Here is the release schedule for the next few weeks.

Release1 – This is already out. Has all the fundamentals of importing Daggerfall content into Unity.

Release2 – Includes lighting update, a player controller, enemies import, building interiors, dungeon texture swaps, new editor stuff, and a bunch of small bug fixes and other improvements. Basically everything I’ve been working on up until now. Release2 will be ready in about a week. I’m also working on a Unity Web Player demo to go along with it.

Release3 – Targets dungeons. I will build out action records (e.g. opening doors, clicking levers, moving platforms, etc.), another pass at enemies, improving navmesh support, etc. The goal is to make it possible to fully explore a dungeon. This release will be up in about 2-3 weeks, and will include another Unity Web Player demo.

Release4 – This will be version 1.0. I will concentrate on improving content browsing, fixing bugs, and tightening up code. The only new features will in the editor, everything else is just polish. This will be ready in approximately 4 weeks. No further demos are planned at this stage.

Release5 and Beyond – We now enter post-1.0 updates. What happens here will be determined by my available time and interest shown in the tools. These will typically be small maintenance releases to fix bugs and the like. I will also be chipping away on some more demos and extensions to show off what is possible with Daggerfall Tools for Unity. This will be stuff like simple AI behaviours, adding weapons, adding spells, and using the API. I am also hoping to create a few tutorials to help you get started.

Light Import

I have nearly completed light import options for cities and dungeons. The Inspector panel for lights is below. Here you can choose to animate lights (a basic range flicker like Daggerfall), set a custom tag, and attach a custom script.

lightimportsettings

Part of getting lights working is setting the correct window texture in outdoor locations. The glass area of windows has a reserved index of 255 which needs to be substituted with appropriate daytime or nighttime colours. This is set using the climate panel of the location Inspector. This will also apply a self-illuminated shader to the windows so the right areas glow at night and appear slightly brighter by day. The window options are Day, Night, or Disabled.

windowsettings_night

Just like climate texture swaps and dungeon texture swaps, your window swaps can be set at any time in the editor or by script. You can easily change this while the game is running to simulate the change from night to day. Below is the same scene with day windows (single directional light) and night windows (full point lights).

windows_night

Dungeons & Dragonlings

Besides constructing horrible puns, I’ve been working on adding Daggerfall’s enemies into the toolkit. My first idea was to add something fast, but it turned into one of those rabbit-hole situations.

Sure it would be easy to just add basic monster templates, but wouldn’t it be great to actually import the correct enemies? Not just the fixed monsters like that first rat or imp in Privateer’s Hold, but support proper random encounter tables like those outlined in the Daggerfall Chronicles guide. And it all had to be easy to change once inside Unity, not just static information pulled from Daggerfall’s files.

The first thing I needed to work out was how did Daggerfall know which monster to spawn where? There are basically two kinds of enemy spawns, fixed and random. Both have an editor marker flat (from TEXTURE.199) in RDB blocks, so this was a good place to start. Fortunately, there’s only a few bytes of data in the record defining these flats, and for fixed monsters this was easy to find. The FactionID in flat resource structures also defines a monster (or mobile) ID. Basically, (FactionID & 0xFF) = MobileID. Range 0-42 are monsters like rat, imp, spriggan, etc. Range 128-146 are enemy adventurer types like Mage, Spellsword, etc.

Just to be sure I had this right, I wrote a quick tool to change IDs of every monster in S0000999.RDB (central dungeon block of Privateer’s Hold) then started a new game. As hoped, the first rat (ID=0) was now an Ancient Lich (ID=33), which promptly ate my level one character for breakfast. I tried not to think about all the ancient liches between myself and the dungeon exit.

I then documented everything into a spreadsheet by spawning each ID in turn, checking them in-game. This allowed me to build a starting template for each and every enemy’s texture file (male and female), animations, behaviour, affinity, corpse marker, and so on. The end result is EnemyBasics.cs where mobile enemies are simply defined. There are also new enumerations in DaggerfallUnityEnums.cs for MobileEnemies, MobileStates, MobileBehaviour, and MobileAffinity. This will be my foundation for adding enemy mobiles to the toolkit moving forward. I’m trying to keep everything just simple enough to get the job done. It’s up to you to build on from here.

I have added a new enemy name field to the DaggerfallBillboard editor script when you have a fixed enemy editor marker selected.

NewEnemyNameField

Next, I turned my sights on random encounters. Any Daggerfall nut knows about the various dungeon types (Crypt, Human Stronghold, Vampire Haunt, and so on), and that each dungeon type has a random encounter table described in the Daggerfall Chronicles guide book. I just had to work out which value defined the dungeon type.

Fortunately this was easy to find also. The upper 8 bits of the “Unknown2″ value in a location’s MapTable data actually defines the dungeon type. It follows the same order as listed in the Chronicles, with Crypt=0x0033, Orc Stronghold=0x0133, Human Stronghold=0x0233 and so on. You can just shift right by 8 bits (DungeonType >> 8) to get the index. I’ve added this information back to the API in DFRegion.cs and MapsFile.cs so it’s all read in for you when loading a location. I have also added a field to the DaggerfallLocation editor script to display the dungeon type in your Inspector.

NewDungeonTypeField

 

With that squared away, I created a basic set of random encounter tables, one per dungeon type, matching those described in Daggerfall Chronicles. This can be found in RandomEncounters.cs.

There’s obviously more to this, as the player’s level is also used to determine which monsters spawn from the encounter table, but this should be a good start and easy to build on. Like the enemy mobiles, my goal here is to make something just functional enough for you to build on with Unity. The more independent you are of the game files, the better.

Now that Daggerfall Tools for Unity has a good foundation of enemy definitions and encounter tables, I’ll be adding a foundation mobile type to the toolkit for ready-made enemies. When starting play mode (or instancing a dungeon from code) the editor markers will spawn an appropriate monster in-place. I’m going to help with this by setting up all the initial animation smarts, but it’s up to you to extend with spells, AI behaviours, pathfinding, and so on. The good news is that you can use all the typical Unity features and there’s a ton of great resources for scripting enemies in the Unity tutorials and on the Asset Store.

Time to wrap this post up. I’ll show more of Daggerfall Tools for Unity very soon, once the above data starts becoming visual.

Daggerfall Tools for Unity

The first release of Daggerfall Tools for Unity is now available. The package includes full source for my Daggerfall API and editor scripts for Unity.

You can download from the main download page, or from download links on the right of home page.

There is also a PDF manual available if you would just like to see how the package works.

I will be adding more features to Daggerfall Tools for Unity soon. The next release will focus on lighting and action scripts in dungeons. Enhancements to the editor scripts are also incoming.

Thank you for taking the time to download. Have fun!

Daggerfall Unity – Climate Swaps

I wasn’t happy with needing to set climate properties before importing cities. I remember being able to change climates at run-time in Daggerfall Explorer and decided that’s how things should work in Daggerfall Tools for Unity.

After a solid few hours work, it’s now possible to set your city’s climate directly from the editor and have materials change immediately. No need to rebuild scene, it all happens procedurally like magic.

dfunity-59-1

 

I also completed mesh import options for adding tangents (useful for normal maps) and secondary UVs (handy for light mapping). Everything is starting to feel nice and functional.

Daggerfall Unity – More Progress

Just a quick update today. I’ve been hard at work on Daggerfall Tools for Unity, adding caching, mesh combining, texture atlasing, ground planes, material sharing, and lots of small tweaks to vastly improve load times and reduce draw calls. I’m almost ready for first release build now. I just want to get in climate swaps and kill some bugs. Oh, and I need to write a manual as well.

dfunity-41

dfunity-41-3 dfunity-41-4

 

 

 

Latest source code code is on the SVN now: https://code.google.com/p/daggerfall-unity/

 

Daggerfall Unity – Cities

The code to import cities is now working, and crikey does it need some improvement. Importing a full city into Unity takes around 10 seconds (compared to less than 1 second in Daggerfall Modelling) and results in a massive scene hierarchy requiring over 5000 draw calls per frame! Obviously this won’t be good enough for a final version. I don’t even have ground planes in yet…

dfunity-city1

The good news is this can be easily improved. Daggerfall Modelling made heavy use of caching, batching, mesh combining, and texture atlasing. I can do the same in Unity to bring those numbers right down. However, I will leave in the ability to import fully atomic scenes in case someone wants to see the native layout without regard to performance. Actually, I think even that can be streamlined. Lots of work to do, but I think I’m on track to finish in a few months as planned.

Edit: I implemented basic caching and mesh combining, and performance is great again. Even the fully atomic scenes load in a few seconds and only require a few hundred draw calls in heavy environments. Unity’s dynamic batching is really awesome. This will get even better once I implement atlasing.

One more thing, the source code is now online. I’ll be updating this every day or so. If you’re really keen you can grab the code and copy it into a Unity project to play with. However if you wait a few days, I’ll create a .unitypackage for download with a manual included.

https://code.google.com/p/daggerfall-unity

 

Daggerfall Unity Update

I’ve completed the first pass at porting code over to Unity. I now have textured models, city blocks, dungeon blocks, and flat objects working. I could lay out complete cities and dungeons at this stage, but want to do some code tidy-up first. Overall, I’m very happy with progress considering I only started work on this a few days ago.

There is a lot of Unity-specific work to go. I need to flesh out editor scripts and add options controlling how scene data is spawned. In case you’re wondering, everything is created procedurally from game files directly within the editor with a single click. After that it just works like a normal scene. The same could be done directly from code as well. Check out the new screens below.

dfunity-rdb dfunity-rdb2 dfunity-rmb dfunity-rmb2

 

In the last screenshot, you can see realtime shadows acting on the scene. Even the flats are casting and receiving shadows. This is using a standard cutout shader, which works in both forward & deferred.

Right now the scenes are built very atomically (from very small pieces). This is perfect for seeing how everything is put together and mucking about with the individual pieces. However it won’t be optimal for real-time uses. One of the options I’m planning will combine meshes and textures sensibly to minimise draw calls and state changes.

Check back in a few days for another update. The next update will include the first release for you to play with.

Daggerfall Tools For Unity

Since leaving the Workshop, I’ve been using Unity a good bit for other projects. It occurred to me the other day it should be trivial to drop my Daggerfall library (Daggerfall Connect) into Unity as everything was written in very portable C#. A few hours later, I had Daggerfall models firing up in Unity.

Scourg Barrow exterior in Unity

Scourg Barrow exterior in Unity.

It’s only a small step from here to spawning entire game-ready cities and dungeons in Unity. For the most part, this can be done using layout code I’ve already written for Daggerfall Modelling. I’d just need to refactor for Unity and build some editor scripts to hold it all together.

Based on this, I’ve decided to repackage the useful parts of Daggerfall Connect and Daggerfall Modelling into a small suite of scripts for Unity developers. As usual, this will be free and open source for everyone.

This doesn’t mean I’m returning to the Workshop full-time. I’ll only be allocating a few months of spare time for this project. I just think it would be great to see all the code I’ve written over the years being put to use by someone, and what better way to wrap up my years with Daggerfall than making one final tool available for a game engine anyone can use?

Let me know what you think! Is there something particular you’d like to see in Daggerfall Unity? If you’re a Unity developer and want to contribute, I would be more than happy to share access to the SVN (will be setting this up soon) to people with the right skillset.

DF Modelling – Crash On Startup

Just a quick post for anyone experiencing a crash on startup in Daggerfall Modelling 0.8. To run this application, you will need the following prerequisites installed:

1. Microsoft .NET Framework 2.0
Note: Only required for Windows XP.
http://www.microsoft.com/en-au/download/details.aspx?id=1639

2. Microsoft XNA Framework Redistributable 3.1
Note: This version is always required even if you have a later version of XNA installed.
http://www.microsoft.com/en-au/download/details.aspx?id=15163

I hope that is helpful for anyone trying to use Daggerfall Modelling and have not been able to get started.