3DO Development Repo

The unofficial 3DO Deathkeep files format specifications by Versus (vas.1987), 2024 (version 1.0)

Note:
All data is BIG ENDIAN.
Directions for stairs and ramps means that named direction must have considered from lower to upper part of the structure. i.e. North direction for the ramp means that I’m sliding from the top towards South.
Directions for the monsters means that monster is faced towards the named direction.

I made an app, which reads all game data needed for 3D model export and for some level edit. You can edit every cube, but you can’t extend or shrink the palette. You can extract level to wavefront *.obj format. You can edit a gap between cubes before exporting (for some 3rd app needs). You can also test your suggestions by editing cube’s properties and test it later in the game. First select the target cube, edit its value and click this button “edit”. Then just save a new file or overwrite the an existing one.

---

Level editor with source : https://github.com/Versusvs/3DO-Deathkeep-level-editor

Contents

Overview

Introduction

Level voxel files (\data2\levels\*)

Level data files (\data2\levels\*data)

Global data files (\data2\DK Data*)

Savefile structure

OVERVIEW. This description covers almost all game data files, which contains level geometry, level textures, inventory items and monsters. Movies, sounds, music and separate cel files are excluded from documenting. I also tried to investigate savefile data structure.

INTRODUCTION.
3DO and PC port have identical levels, but level files have different format.
Both 3DO and PC levels consist of voxels. Every voxel is a 3D cube which may contain different combinations of level elements. It may contain ramp or stair only or teleport or level exit. Every level must fit in parallelogram with dimensions 64 by 32 by 8. Where 8 is height and as we could say the number of Floors. We have 16384 voxels in total! Pretty much, isn’t it?
3DO levels consist of two files. First one contains voxel table, Second contains textures, animation data, teleports and other logic, items and monsters.

A) LEVEL VOXEL FILES (\data2\levels\*)

Each level voxel file is 131 072 bytes. Each voxel in 3DO version is encoded by 8 bytes. So, there are 16 384 voxels. If voxel has 0xFF value, it’s blank for the game engine. Every variation from it means that voxel is used by the game. It can be just walls, ceiling and floor with textures, it can be ramp or stairs, item or monster can be placed in. Blank voxels may be located inside large halls, in the center of the room, if the room is big enough.
First voxel in file has position in 0,0,0 (X, Y, Z). Second voxel has position 0,0,1 (X, Y, Z). It means that second voxel is located directly above the first one. First 8 voxels are located one above another. Voxel number 9 is located near to first column in the width direction on the coordinates: 0,1,0 (X, Y, Z).

Voxel file structure

Each voxel is encoded by 8 bytes and they are numbered from 0 to 7.

Voxel structure

A.1)

Byte #0. It contains data about ramps, steps and stairs. Various values can encode all directions of the ramp or stair. Both ramps and stairs can be 2 types. The first type encodes a ramps or stair in lower half of the cube height. The second type encodes the ramp or stair in upper half of the cube height to the top of the cube. Values in range 0x80 – 0x9A are for game inner logic (teleports, elevators, monster and fireballs triggers, etc.).

This byte also encodes a steps, if I may say so. This steps have a various elevation from the floor ground and have flat surface. Using different values, you may do a fine tuning for your level design.

I found some values which affects a level in a weird way and not actually present in the game. May be there are more, I didn’t test others.

All known values of Byte #0 are in the table below.

A.2)

Byte #1. Contains data about cube’s inner brightness, light flickering, and partially doors logic. To ensure the Door is working properly it’s animation must be set in blocks 1-3 (see chapter B).
Bit #1 indicates that this cube has a door, Bit #3 indicates that door is closed or not (requires key). Bits must be set in both cubes (both door sides). Bit #1 == 1 means door presence in the cube. Bit #3 == 1 means that door requires a key. Setting these bits to make a door is necessary but not enough. Most common situation is when door may be opened from both sides. In this case two cubes which have the door, must have Bit #1 bit enabled. I can make a one-way path using a closed door bit (Bit #3) from one side only. So, this area may be accessed but there is no way back without a key.
Byte #1, bits #0-3:
Bit #1 = 1 means that a door is present
Bit #3 = 1 means that a door is locked
You can play with first 4 bits of Byte #1:
0x2 – door present
0xA – door present and locked
0 – door doesn’t exist

Bits #4-7 within Byte #1 describes cube’s inner brightness or light flickering.

A.3)

Byte #2. First palette byte. (See chapter B, LEVEL DATA FILES). This byte is used as a first palette ID part for the walls, ceiling, floors and the textures. This byte must be considered with Byte #3.

A.4)
Byte #3. First 4 bits are always zero. The next 4 bits are used as a second palette ID part for the walls, ceiling, floors and the textures like Byte #2. Textures encodes inner surfaces of the scenery cube and cube’s collisions. This byte must be considered with Byte #3.
Bytes #2, #3 together represents palette ID in *data file. (See chapter B, LEVEL DATA FILES).
Example:
Byte #2 = 0xF4.
Byte #3 = 0xA.
Palette number = 0xF4A.

A.5)
Byte #4. This byte isn’t used by the game and always equals zero.

A.6)
Byte #5. This byte adds additional data for character’s items from Byte #7 (0x50-0xC3). Helms, Armor, Weapons can gain additional specs, i.e. Helm +2, Long sword +1, where +2 and +1 are additional specs. Possible values: 0 to 0x7F.

A.7)
Byte #6. This byte isn’t used by the game and always equals zero.

A.8)
Byte #7. This byte contains data about all items placed on the level. Health potions, weapons, food, amulets, decor and so on. It also encodes an enemy placement with chosen enemy direction. Item may be placed in the level, but some items are visible to Mage, but not visible for Dwarf or Half-Elf FighterMage.

B) LEVEL DATA FILES (\data2\levels\*data)

Data file structure:

B.1) CCB textures
All wall floor and ceiling textures are here. Every texture entry has the following structure:

Texture prefix.
Texture prefix 0x10 indicates default texture for using by game engine. So, for each inner side of the cube only one texture may be assigned by palette (see chapter B.4). If cube geometry is more complex than a simple cube, (cube with ramp, stairs, steps, etc.) this default texture ID will be used for “secondary” surfaces. If voxel data (Byte #0) indicates that cube has a stair, step, etc., this default texture will be assigned to vertical stair polygons. It also applicable for complex cube’s geometry (Byte # 0 is set to: 0x1-0x7F).
Texture prefix may be set to 1 or 2. When I swapped this prefixes, these floor and ceiling textures swapped to in the game. Texture prefix also may be set to 0x20, but I didn’t investigate it yet.
Texture prefix 0x20 marks textures, which are used for hidden doors in the walls.

Texture ID.
Unique texture IDs are assigned to each texture in the CCB textures section. Voxel’s textures are coded in the palette (see chapter B.4).
Texture ID is coded by first 5 bits. Next bits are used for texture rotation of texture mirroring.
For wall textures: Bit #7 = 1 – texture is flipped relative to vertical axis.
For ceiling and floor textures: Bits #6 and #7 codes texture rotation. There are 4 possible cases:

Custom collision.
Base cube’s collision is set by palette (see chapter B.4). But in some cases like stairs, ramps, doors or windows must have a more complex collision. It means that only selected cube’s wall zones must be transparent for any kind of object or the actors. Custom wall collision is encoded by 8 bytes. Each bit in 8×8 grid encodes the collision in the cell. Note that all frame in opening door animation has a corresponding custom collision. There is one exclusion in this bit cell rule, when bit pattern doesn’t work as shown in the game. It’s just an opening in the wall (level 1), but bit mask looks weird… (see pattern 8). Some patterns are shown below.

Pattern 1. Ramp, low ( 0xFF 0x3F 0x0F 0x3 0 0 0 0).

Pattern 2. Ramp, high ( 0xFF 0xFF 0xFF 0xFF 0x3F 0x0F 0x3 0).

Pattern 3. Round hole in the center ( 0xFF 0xFF 0xFF 0xE7 0xE7 0xFF 0xFF 0xFF ).

Pattern 4. Opening door, frame 1 ( 0xE7 0xE7 0xE7 0xE7 0xE7 0xE7 0xFF 0xFF ).

Pattern 5. Opening door, frame 2 ( 0xC3 0xC3 0xC3 0xC3 0xC3 0xE7 0xFF 0xFF ).

Pattern 6. Opening door, frame 3 ( 0x81 0x81 0x81 0x81 0x81 0xC3 0xFF 0xFF ).

Pattern 7. Corner ( 0x80 0xC0 0xE0 0xF0 0xF8 0xFC 0xFE 0xFF ).

Pattern 8. Opening frame (0 0 0x78 0 0xF0 0xE8 0 0xB4 ).

All patterns used in the game see table below.

B.2) Block 1
Block 1 has constant size of 0x300 and consist of 3 equal parts. Part 1 (size = 0x100) is for backgrounds, Part 2 is for wall animation offsets, Part 3 is for repeated animation? (torches, reflections on the walls). Wall texture ID is linked to the Part 1(2, 3) offsets. If offset = 0, wall texture has no texture ID override or animation.
Block 1 has the following structure:

1) Game engine looks to Part 1 offset = Texture ID. Value at this offset = texture ID override. It means that this new texture will draw instead of previous one.

2) Game engine looks to Part 2 offset = Texture ID. Value at this offset = Block 2 offset. Part 2 is for single use animation (like doors).

3) Game engine looks to Part 3 offset = Texture ID. Value at this offset = Block 2 offset. Part 3 is for repeated animations (like torches reflections).

B.3) Block 2
Block 2 describes animation sequences texture IDs. Offsets values from Part 2 and 3 from Block 1 points to animation sequence beginning in this block. Block structure is the follows:

If there are no animations on the level, Block 2 structure is the follows:

B.4) Block 3
Block 3 is the Palette. Palette consist of 16-byte entries and each stores all texture IDs for each side of the cube, base collisions, additional collisions, floor damage flags, resting zone flags, low friction flags and textures for vertical stair’s polygons. Numeration begins from 0. Two Bytes #2, #3 (see chapter A.3, A.4) combined gives the palette #.
Block 3 structure is the follows:

16-bytes entries have the following structure:

Byte #12 structure

Byte #16 collisions structure

B.5) Level entry and exit coordinates
8 bytes encoding level start and exit positions. Structure is the follows:

Level exit coordinates may be 0 when Monster is triggering exit? Rotation values range:
0 = West dir, 0x40 = South dir, 0x80 = East dir, 0xC0 = North dir. Interpolation may be applied.

B.6) Block 4
Block 4 stores offsets for teleports, elevators, collapsing floors and other such data type. These offsets are linked with Block 5 (see chapter B.7). Note that Byte #0 and Byte #7 (see chapter A) must be set to their corresponding values together. Block 4 starts with it’s size (4 bytes) and always equal 0x6C without this 4 bytes. All offsets in the table below starts after the block’s size. I.e. if Byte #7 and Byte #0 (see chapter A) are set, and value on offset in Block 4 is not 0, all data is located in Block 5 (see chapter B.7). Note that offset value for standart teleport in Block 4 is always 0, but teleport data may be in Block 5 (see chapter B.7).

B.7) Block 5
Block 5 contains all special events logic (teleports, elevators, wall and ceiling triggers, etc.). All data in this block is linked with Block 4 offsets (see chapter B.6). If there are no data for block 5 (block is missing), Block 5 is 4 bytes length and = 4. In order to be working, Byte #0 and Byte #7 must be set (see chapter A).

If dependent cube is an another trigger, this new trigger will be activated instead of the first triggering cube (non-teleport related).

C) ANIMBACK
These objects appear in the cube then value on corresponding offsets in Block 1 (see chapter B.2) is not zero. ANIMBACK are usually animated objects which have no collision and may resides always near walls (torches, flames, huge challises etc…) and in the cube’s center (sparkles, hanging objects, candelabras, etc…). May be only two different ANIMBACK object types per level. Some these objects may be observed in 3D in game. These objects may be attached to the top or to the bottom of the cube.
I didn’t dive deeply into the investigation for this type of objects, because it wasn’t necessary for building a 3D model, which was my primary objective. Object’s structure is fairly investigated, but the base is clear.

D) ANIMENEMIES
This objects placed in level are monsters. Enemy placement encoded in Byte #7 (see chapter A.8). May be three of monster types per level maximum. I also didn’t investigate this objects deeply. Object’s structure is shown below.

E) ANIMOBJ
This objects are for level decoration (stalactites, stalagmites, standalone columns, tables, fountains, graves, hanging skeletons, gargoyles, debris, etc…). Object placement encoded in Byte #7 (see chapter A.8). May be four of these object types per level maximum. Object may be observed as 3D in the game. No deep investigation also, sorry.

F) OBJECTS
These objects are unique items which could be found on a level (Keys, Ancestral Artefacts, Feast, etc…). Object placement encoded in Byte #7 (see chapter A.8). May be three or four of these object types per level maximum. In some levels 4th object exist in level file, but kind of ‘blank’. Object may be observed as plain texture in the game. No deep investigation also, sorry.

G) END OF FILE
End of the file mark (-1) is located after objects block (see chapter F). After this mark level name follows.

H) GLOBAL DATA FILES (\data2\DK Data*)
This three files contains all item textures (also small item textures in inventory), explosions animations, weapons animations, inventory backgrounds and huge amount of unknown data.
File structure is the follows.

I) SAVEFILE STRUCTURE
Savefile size is 356 bytes. I tried a lot of tests and now I know some bytes are used for. Some bytes have secondary meaning, may be character dependent. I made a table with all investigated data. Each cell is a byte. Number of columns and rows are equal to HEX-editor in GameGuru.

Bytes for pells for Fighter/Mage occupies these bytes: Armor, Burning hands, Magic missile Melf's Acid arrow, Improved identify, Ray of enfeeblement Fireball, Fly, Lightning bolt Fear, Ice storm, Stoneskin
Cone of cold, Feeblemind, Hold monster Death fog, Disintegrate, True Seeing Acid storm Abi-Dolzin's Horrid Wilting Meteor Swarm

Artefacts byte and its possible values with marked artefacts colors avalable in inventory: