Daggerfall Mod:DFRemake/Dungeon Building

Basic Information

Dungeons are composed of the following objects:

• 3D Objects (from Arch3d.bsa)
• Dungeon Blocks (RDB files from Blocks.bsa)
• Dungeons (MapDItem files from Maps.bsa)

Objects and other dungeon data can be classified into the following categories:

• Static Objects (walls, rooms, etc...)
• Action Objects (anything that can move including doors, switches, platforms, etc...)
• Flat Objects (i.e. 2D sprites), though these may technically be included with Static Objects
• Actors (any NPC or monster in the dungeon, whether movable or not)
• Lights
• Exit Location(s) (unsure how exits are stored in the original DF data, but likely will need to be seperately stored in DB)
• Items (any item that can be picked up)
• Quest Locations (depending on the quest system design, may be included with items)

Design Notes

• One dungeon can be loaded at a time within DB.
• The current dungeon will stay in memory until the next dungeon is needed. This will let players quickly re-enter a dungeon multiple times without needing to reload the dungeon data.
• The current dungeon will be hidden/disabled when the player is not inside it (there shouldn't be any performance issues doing this though we should check to confirm).
• If system resources (memory) are low, the current dungeon data can be cleared if not being used.
• Arrays of the basic objects (using custom types) will hold the various dungeon data (as listed above).
• Dungeons and dungeon blocks will not be cached but created as needed. Some speed tests need to be done concerning this but it seems not to be worth caching anything larger than 3d objects. Some time can be saved by caching blocks but at a significant expense of memory. There are also potential implementation issues regarding block caching that make it simpler to just not cache them.
• Dungeons and dungeon blocks will be composed of individual objects as opposed to using limbs. Using individual objects makes it easier to iterate through objects, especially for animation purpose. The only real advantage to using limbs is to retain the heirarchal structure of dungeon blocks which is only needed during the dungeon creation.
• Dungeon and block data will be first loaded within the DFELibrary and then passed onto DarkBasic as requested.
• State of action objects will need to be saved/restored between dungeon loads.
• Position of actors will need to be saved/restored between loads.
• Items will need to be saved/restored between loads.
• Player save games will have to include the action/actor/item states. A temporary 'save game' can be used during game play to store dungeon states as needed (if memory allows it could be stored in RAM, but since its only needed when entering a dungeon it may be a waste of resources).
• Creatures will respawn in visited dungeons over time (exact time to be determined).
• The first time a player visits a dungeon all the random monsters/items will be created within in. This is slightly different than DF which created random items the first time you viewed the item 'pile'. This reduces the exploit of saving/reloading to change the random items for an item pile. This does slightly increase the size needed for the dungeon state.
• Dungeons will be accessed by region index (0-60) and dungeon index. Must confirm how doors into dungeons reference the location in the original DF data. It could also be referenced by the location ID instead of index.

ToDo

• How are we doing collision? I tried activating collision with dungeon objects and the camera but it didn't work.
• Must check how many lights are allowed at once (DB documentation says 7 which is far too few).
• How will creature respawn time be set? A global respawn time for all creatures or specific times for different creature types?
• Estimate amount of memory required to save the dungeon state. If the player visits 1000s of dungeons, how big will the save game get?

Rough Timing

The following are some general times to load/create dungeon. Note that times were obtained in a debug/test build and are for rough comparison only.

Test	Time
Complete Dungeon Load, including all objects and images	850 ms
Complete Dungeon Load, reusing objects/images in cache	350 ms
Load all Dungeon Records in a Region	3 ms
Load a Dungeon Block	2 - 3 ms
Create Objects from a Loaded Dungeon Block	20 - 300 ms

It seems the majority of time is spent actually creating the dungeon objects with little time required for low-level loading.