3DO Development Repo

This is an old revision of the document!

---

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.

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.