Ultima Stones | Ultima IV Home | Development | File Details
CGA | CON | DNG | EGA | MAP | SAV | TLK | ULT

*.DNG File Specification

    These eight files define the dungeons. They could be described by a single simple data type but for the exception of the file defining the Abyss. The seven other files have a size of 4608 (0x1200) bytes while ABYSS.DNG has 16896 (0x4200) bytes.

    One file with the DNG extension does not fit this spec, CAMP.DNG. This file is actually a CON file for camping and camp combat in the dungeons.

    The first 512 bytes detail the eight levels of the dungeon. The 64 bytes at the start make up an 8x8 map of the first level. The arrangement inside each 64 byte block is right to left, then top to bottom for a north oriented map. The second 64 apply to the second level and so on. The maps roll over on the edges as the world map does making for apparently infinite levels as well as irregularly shaped maps. The tile key and a schematic of the level arragement in dump format follows:

Floor Arrangement Schematic:

The remaining portion of the file defines the rooms. The format is similar to the CON files. The detail header space contains more data making for a section size of 256 bytes per room. The seven dungeons with smaller file sizes hold 16 room blocks. The Abyss file holds 48. The following is the detail of the rooms:

Triggers

    The first four groups of four bytes are trigger blocks. The first byte is the trigger tile type. The second is the trigger switch coordinates and bytes 3 and 4 are two pair of trigger tile coordinates. In the three coordinate bytes, the high nybble is X and the low nybble is Y. The operation of the trigger is the rule: 'if any party character steps on the tile at the trigger switch coordinates, the trigger tile is written over both of the two trigger tile coordinates.' A single trigger can only change two tiles. However, as many as eight tile swaps can be triggered at once if several switches are set to the same coordinates. If the trigger is 'inactive' (not to be used), all of its bytes are zero. If the trigger acts on only one tile, the other is set to zero. The upper-left-most tile, coordinates 0 by 0, is inherently unused and blocked from contact by solid, opaque tiles. This allows all unused pointers and coordinates to be set to a null (zero). All unused, undirected information acts 'behind the scenes' there.

Hostiles

    The monsters in the dungeon rooms are not random as they are on the surface. To that end, not only are the monster positions recorded in the room header; so are the tiles representing the monsters. Each tile recorded is the first in each NPC's animation.Sixteen monsters's tiles are followed by an array of their X coordinates and an array of their Y coordinates. Monsters can be placed anywhere including several on the same tile stacked up on top of each other, and behind solid objects (its not an issue for ghosts or wisps after all. There may also be less than 16 total hostiles, or even none. Any unused slots in the monster list have the tile and both coordinates set to zero, as is done to 'inactive' triggers. According to original implementation, the empty monster slots come first in the lists.

Party

    Another thing that makes the rooms in dungeons different from conflict scenes is that direction has importance. It is possible to enter from any side so melee positions are set up in four groups coming from each cardinal direction. In the file is the same data layout of the CON files duplicated four times over. In party order, eight X coordinates and eight Y coordinates place the party for entering from the north or the top of the map. Then, follows the left entry, or entering from the east. Next is the bottom entry (from the south) and finally the left entrance (west). If entry from a certain side is not intended, all coordinates are set to null for that side. It is possible and has been implemented that the party may be stacked up on top of each other as hostiles can be. This is seen in cases of triggered exits and due to lack of space.

Map

    The last important data in the file is the map. As are all of the small maps, the data is left to right, top to bottom. The extents of the map are 11 tiles in both directions, like CON files for fitting the overhead veiw window.

Pad Space

    Typically: (00 00 00 00 00 00 00). Modifying this section has caused no noticed, noticable, or apparently relevant changes in operation or gameplay. This space seems common to several files in content. This is most likely junk data from the original creation of the file that fills the space to round out the block size at an even 256 (0x100) bytes.