SYSTEM TUTORIAL · WORLDGEN

Build a Custom Dimension

Create a real generated dimension through DAI's world-data layer, understand the restart boundary, then connect gameplay flow to it.

Intermediate35–60 minRegistry restart required

The Mental Model

DAI friendly world definition
        ↓
Generated server-data pack
        ↓
Minecraft dimension / dimension-type registry data
        ↓
Restarted game loads registry
        ↓
Runtime objectives / portals can target the dimension
Registry boundary. The existing DAI 3.0 documentation states that changing generated dimension or world-preset registry data requires restarting Minecraft. Runtime portal/movement settings are a separate reloadable concern.

1. Prove World Generation First

Before building portals or progression, create the smallest possible world profile. This example is the documented friendly void-world shape:

data/<namespace>/dai_worldgen/*.json
{
  "enabled": true,
  "world_type": {
    "type": "void",
    "biome": "minecraft:the_void",
    "features": false,
    "lakes": false,
    "structures": false
  },
  "spawn": {"x":0,"y":64,"z":0}
}

DAI documents high-level world choices including normal, amplified, large biomes, single biome, debug, flat/superflat, void, water world, fixed-biome noise and configurable noise generation.

2. Give the Dimension Its Own Data

Use data/<namespace>/dai_dimensions/*.json when you want a generated dimension rather than only the experience's primary world preset. DAI's current docs say these definitions may contain generation / world_type and compile real Minecraft dimension data.

Keep the first version boring. Start with a known biome and simple generator. Once the dimension boots reliably, add custom biomes, dimension types, timelines or environment presentation one layer at a time.

3. Optional Supporting Registries

dai_dimension_types

Height, skylight, effects and other native dimension-type fields.

dai_biomes

Friendly/native biome data that compiles into Minecraft world data.

dai_timelines

World/environment timing data documented by DAI's customization layer.

4. Connect Runtime Gameplay

  1. Restart after registry changes.Do not debug teleport logic until the dimension itself exists after a clean restart.
  2. Enter through one controlled path.Use an objective, server function or supported portal flow to transfer the player to the new dimension.
  3. Define a safe destination.Use a known spawn/arrival platform before introducing procedural terrain or moving portals.
  4. Test the return path.A custom dimension is not finished until the player can leave safely after death, reload or progression completion.

5. Grow It Safely

  • Add a custom biome only after the base dimension loads.
  • Add natural structures/features after terrain is stable.
  • Add custom environment/sky presentation after gameplay navigation works.
  • Use the Native Minecraft Bridge when you need registry/server-data formats that do not yet have a dedicated DAI schema.

Reference While You Build