Abstract
Problem: How did a team of ~12 people build Arcanum's massive game world in the late 1990s with severe RAM constraints?
Approach: Tim Cain explains two key systems: a prototype-based object model that minimized memory usage through inheritance and bitfield deltas, and a rectangle-based structure editor that let artists rapidly build buildings, dungeons, and caves.
Findings: The prototype system meant hundreds of identical objects (e.g. knives) stored only their unique differences (location, current HP, parent), with everything else inherited from a shared prototype. The structure system used a top-down rectangle-drawing approach where walls, corners, doors, and windows were automatically generated along perimeters — then artists switched to isometric view to place props. Both systems dramatically reduced memory footprint and accelerated content creation.
Key insight: In memory-constrained environments, it's better to define a field on every prototype and never override it than to not have the field and need it later — the bitfield delta approach makes unused fields essentially free.
Source
Arcanum Prototypes & Structures — Tim Cain's YouTube channel.
The Object System
Everything visible on Arcanum's game scene that wasn't a background tile was an object. There were 18 object types organized into logical categories:
- Critters: PCs and NPCs
- Items: weapons, ammo, armor, gold, food, scrolls, keys, key rings, written objects, generics
- Mobiles: projectiles, containers, critters, and items — anything whose location could change during gameplay
- Consumables: food and scrolls — objects that disappear when used
All objects had shared fields (art ID, location, hit points, AC) plus category-specific fields. Every object got hit points and AC "just in case" — for example, to support explosives destroying scenery or spells targeting containers. As Tim explains, the prototype system made it better to include fields speculatively than to add them later.
How Prototypes Worked
Every object in the world pointed to a prototype. A knife prototype, for instance, stored the art ID, damage range (e.g. 1–6), damage type, weight, cost, and all other base values.
When you found a knife in the game, the actual object just said "I'm this prototype" and then stored only the fields that differed from the prototype. The mechanism:
- A bitfield on each object indicated which prototype fields were overridden
- If a bit was 0 → use the prototype's value
- If a bit was 1 → the override value was stored in the object, in order of the set bits
What Got Overridden
- Always stored: Location (always unique per instance)
- Frequently stored: Current hit points (starts inherited at full health, overridden on first damage)
- Stored as deltas: Inventory for containers/creatures, charges for magic items
A hundred knives in the game might each store only three fields: location, current HP, and parent. Everything else came from the shared prototype.
Benefits
- Tiny RAM footprint — critical in the late 90s
- Small save games — only deltas were persisted
- Sector-based loading — objects loaded when the player entered or approached a sector, and loaded fast because they were tiny
Mark Harrison did the majority of the heavy lifting on this object system. Tim acknowledges that modders later found the prototype-object interrelation frustrating to work with, but it was essential for a small team shipping a huge game.
The Structure System
Buildings, dungeons, and caves used a dedicated structure editor rather than being placed as normal objects.
How It Worked
Each structure had a floor-wall-ceiling grouping — artists selected a floor type, a wall set (with subtypes for corners, window segments, etc.), and optionally a ceiling (dungeons/caves had no ceiling so you could see inside).
The workflow:
- Switch to top-down view — same tile grid, but viewed from above instead of isometric
- Draw rectangles — each rectangle becomes a room; the editor automatically generates outer walls along the perimeter
- Merge rectangles — drawing an intersecting rectangle removes interior walls at the overlap and generates a new combined perimeter
- Switch to isometric view — click on walls to place doors and windows; windows auto-bracket with closing segments on either side; doors supported single and double widths
- Place props — tables, chairs, bookcases — all just prototype-backed objects needing only a location
Dungeons
Dungeons worked identically: fill the background with solid rock, then draw rectangles for hallways and rooms. The editor handled wall generation and connectivity. Switch to isometric, add doors, place props. One artist could build an entire dungeon level quickly.
Bonus Features
- Footstep sounds derived from floor texture (wood, stone, metal) — the game knew when you entered a structure and what floor you were on
- Lighting switched automatically from outdoor to indoor when entering a structure, using whatever lights were placed inside
Why It Mattered
Both systems were designed for the same two constraints: minimize memory and maximize productivity for a tiny team. With roughly a dozen people building Arcanum's enormous world — its cities, dungeons, ruins, and wilderness — these tools were the difference between shipping and not shipping. The prototype system kept RAM and save files small; the structure system let one person rapidly produce complete levels.