Arcanum's Procedural Terrain Generation

Abstract

Problem: How did Troika Games fit an enormous open world into late-1990s hardware with severe memory constraints?

Approach: Tim Cain walks through Arcanum's layered procedural terrain system — from individual tiles up to the world map — explaining how deterministic seeding, delta-based storage, and transition rules enabled a 128-square-mile explorable world.

Findings: By procedurally generating sectors from a seeded RNG and storing only human-made edits as deltas, Arcanum achieved massive world sizes with minimal storage. The same system extended to player actions (dropping items), prototypes, and could have supported player-built structures.

Key insight: Treating hand-edited content as deltas on top of deterministic procedural generation is an elegant compression strategy that scales to arbitrarily large worlds — Arcanum's engine theoretically supported maps up to 4.2 million miles per side.

Source: https://www.youtube.com/watch?v=BbI7hFoT6TQ

1. Tiles: The Foundation

An Arcanum tile is a diamond shape, 80×40 pixels, representing roughly 5 feet of ground. There are approximately 1,000 tiles per mile.

Tiles connect at their four corner points, and each corner enforces transition rules — only certain terrain types can be adjacent. The terrain types included deep water, shallow water, coastal, sand, scrub, grass, light forest, deep forest, rocky, hilly, and mountain.

If you dropped deep water onto a grass map, the system would automatically create the transition chain: deep water → shallow water → coast → sand → grass. This was all enforced by the corner-based transition rules.

1.1. Tile Properties

Tiles controlled more than visuals:

  • Movement — walkable, blocked, flyable, sinkable (drawn knee-deep), or icy (slip and fall)
  • Sound — six footstep types: dirt, sand, snow, stone, water, and wood (covering both outdoor terrain and indoor structures)
  • Horizontal flipping — some tiles could be mirrored to double variety while halving storage. Artists worked hard to ensure flipped tiles still connected correctly.

2. Sectors: The Middle Layer

A sector is a 64×64 tile grid (5,120×2,560 pixels, roughly 320×200 feet). Each sector is uniquely numbered by its XY position on the world map — this unique number is critical to the entire system.

At the map level, sectors are painted with one of up to 32 base terrain types (simplified categories like grass, forest, mountain, water). These base terrains determined both procedural generation behavior and world-map movement — water and mountains were marked impassable for overland travel.

3. Procedural Generation via Deterministic Seeding

When a sector needed to be displayed, the engine would:

  1. Look up the sector's base terrain type
  2. Seed a random number generator with the sector's unique number
  3. Run terrain-specific algorithms to place props — trees, boulders, flowers, plants

Because the seed was deterministic, the same sector always generated identically on any machine, whether loaded for the first time or the hundredth. No pre-generated data needed to be stored.

4. Delta Storage: Only Save the Differences

When a designer edited a procedurally generated sector in the world editor, the system stored only the deltas — additions, removals, and changes relative to the generated baseline. If you made three edits to a sector, only three deltas were saved.

To load an edited sector: generate it procedurally from its seed, then apply the delta list. This was extraordinarily memory-efficient.

4.1. Multi-User Editing at Troika

The world editor supported concurrent editing through file-based locking. When someone edited a sector, a file named after the sector number was created in a shared network directory. File creation is atomic at the OS level — if two people tried to lock the same sector simultaneously, one would succeed and the other would get "file already exists." Edits were saved, verified, then the lock file was removed.

4.2. Deltas Beyond Editing

The delta system extended elegantly into gameplay:

  • Dropped items — a sword dropped by the player became a delta referencing the item's prototype ID and position
  • Prototype system — items stored only their differences from a prototype. A magic fire sword might only store changed art ID, damage range, and damage type. Weapon degradation stored current HP as a delta while max HP lived in the prototype
  • Structures — buildings were stored as deltas on sectors

4.3. Unrealized Plans

Troika had designs for even more ambitious delta-based features:

  • Player-built structures — would have been stored as sector deltas (Fallout 4 later did something similar)
  • Terrain-altering spells — temporarily or permanently changing terrain types via deltas

5. Facades

Facades were pre-rendered tile arrangements laid down in a fixed order, used for large unique objects like certain buildings and the crashed blimp. Unlike regular tiles, facades ignored transition rules — surrounding tiles simply didn't try to transition into them. Facade tiles were automatically marked as blocked.

6. World Map Scale

The Arcanum world map was 2,000×2,000 sectors, mostly filling that central continent. That translates to roughly 128 miles per side — enormous for a late-1990s game you could freely walk across.

The engine's theoretical maximum was 67,108,864 sectors squared (the unsigned 32-bit integer limit), yielding 4.2 billion tiles or about 4.2 million miles per side. The world editor shipped with the game could theoretically create maps that large.

7. Maps: Indoor/Outdoor and Audio

Each map declared itself as indoor or outdoor, affecting:

  • Lighting — outdoor maps got day/night cycles
  • Audio — ambient sounds could vary by time of day
  • Structures — entering a building on an outdoor map overrode it to indoor

8. References