OSG supports billboards, so that's 90% of the rendering sorted immediately. The biggest issue I can think of, though, is that loads of Daggerfall is procedurally generated, so that would need reverse-engineering, and so would the mechanics, and I imagine that that's most of the work in a total engine replacement already.

OSG supports billboards, so that's 90% of the rendering sorted immediately. The biggest issue I can think of, though, is that loads of Daggerfall is procedurally generated, so that would need reverse-engineering, and so would the mechanics, and I imagine that that's most of the work in a total engine replacement already.

I've been in contact with Interkarma about sharing resources and we've gotten on pretty well, between his effort into DF Unity and what we have from daggerxl, we have a lot of resources available to us since both projects are MIT which have no issues with becoming GPLv3. (Note: xlengine might have GPL related code anyway, we're looking into that now)

There have been talks (years ago) on here about proceduraly generated dungeons. I have a bit of experience with that already, should be fun when we get to that point. I'm kinda interested how some things 'translate', such as quests. We'd likely have to massage a lot data-structures into OpenMW/Morrowind equivalents.

While reverse engineering would usually be most of the work, DFUnity already has a great deal of the system hashed out, and feels mostly the same as vanilla. However, the one place that DFUnity fails, is the physics system. I'm actually not sure if Interkarma just has the current physics system as a placeholder, or if he plans to make it true to the original, but movement is not anywhere near what the vanilla game was like. Movement just isn't tight enough, making my usual hit-dodge play-style completely and utterly useless. The physics system is a bit "normal", but it nerfs the way I play so badly that it can hardly be considered a QoL improvement.

Daggerfall does use a lot of procedural generation, but how much varies between elements in the game.

I don't know where it was said, but I remember someone saying that while procedural generation was used to create the dungeons of Daggerfall, it was based on some sort of "template" that is the same for everyone. Sort of like how the same seed in Minecraft will give every person the same exact procedurally generated world.

Then there are things like towns and wilderness. A town's placement is always the same, and some dungeons were hand crafted by the bethesda devs. While most every town will be different each time you play, there may be elements within that game that are always the same, such as Castle Daggerfall, which will always be in the NW of the City of Daggerfall. In the wilderness, tree placement and terrain leveling is random, though trees and terrain are dependent on region. I'm not sure if enemies encountered in the wild differ depending on region.

If done right, this could become the best option for people to play Daggerfall on modern systems, without closed dependencies like Unity. I have a lot of reason to believe this is the best option, even as a side project.

I don't know where it was said, but I remember someone saying that while procedural generation was used to create the dungeons of Daggerfall, it was based on some sort of "template" that is the same for everyone.

Procedural generation isn't necessarily the same as random generation (although a lot of people seem to think it is). If you can't be bothered handcrafting a zillion mountains for a flight simulator, it can be a lot easier to procedurally generate them and tweak anything that comes out weird, and it can make the game data a lot smaller if you're only storing a seed and some modifications instead of a fully detailed version of everything.

Incidentally, Daggerfall's dungeons are not procedurally generated at run-time. They were generated during development, and the results saved to the game data. Some of them (the MQ-related ones) were then tweaked by hand. Every town, city, and dungeon has the same location and the same layout for everyone everytime.

Certain elements (like texture selection, enemy encounters, or loot) can change at runtime, but the layout and spawn point placements are static. Outdoor areas have more procedural generation going on, though using the game data to seed various parameters (terrain bumpyness, flora, weather). Quests were also templated, with locations, items, rewards, and the template itself being selected to fit various parameters (your level, current region, quest giver's faction), along with an optional time limit that's calculated based on your current location and the selected target location (and consider that some quests have multiple randomized target locations).

Given the size of Daggerfall's map, and the differences in mechanics, I really don't think OpenMW is a good starting point for a Daggerfall engine (or even a Daggerfall-style game). Consider the changes from Morrowind to Oblivion, then realize Daggerfall to Morrowind was a much bigger change. Daggerfall was designed to reuse map data wherever it could to reduce the amount of disk space, whereas Morrowind is less stringent on space saving.

That was really my only concern... that terrain is more streaming with Daggerfall than with Morrowind, the map is huge so it would have to auto-generated into something OpenMW can use on-the-fly and not just read from esm/esp/addon.