DAI 4.1 runtime expansion: creators can now use the same shared JSON action/condition model for named state and capabilities, runtime references, custom/native attributes, animation state, registered content, reaction events and server-authoritative entity status.

Page 1 · Overview

Design With DAI 4.1

DAI Engine 4.1 is a JSON-driven Minecraft game framework aimed at game and modpack makers: compose client/server gameplay, native custom entities, one main experience and optional addon packs, with an engine-side client render bridge available where datapacks/resource packs cannot control Minecraft alone.

The DAI Mental Model

Player / Minecraft Client
        ↓
Recognition + Conditions
        ↓
Menus / Decisions / Reactions / Customization
        ↓
Objectives + Sequences
        ↓
Client Actions ─────── Server Actions
        ↓                    ↓
Input / UI / Camera     World / Inventory / Functions
        └────────── Minecraft State ──────────┘

DAI is the engine; your pack is the game. Use the visual Creator when a first-class editor exists, and use Universal Files when you need a DAI or Minecraft data type that does not yet have a dedicated form.

Start With Ownership

Client behavior

Input, look, navigation, menus, recognition and overlays belong to the physical client.

Server behavior

Persistent world changes, privileged functions, inventory grants and worldgen belong to server authority.

Shared definitions

Data schemas describe what should happen without forcing a physical side to load the other's classes.

What You Can Build

Complete Games

Custom title screens, owned saves, world bootstrap, progression, custom entities, UI and server-authoritative rules.

Addon Modules

Damage indicators, effects, quests, UI layers, utility systems and other reusable features that can stack onto a main game.

Native Content

Registry-backed identities and carrierless DAI mobs with JSON-defined hitboxes, attributes and behavior sequences.

Think in Roles + Deliverables

Main Datapack

The one game-owning experience: title, save, worldgen, progression and creator control policy.

Addon Datapacks

Zero or more optional DAI modules layered beside the main experience. Addons do not compete for game ownership.

Resource Packs

Textures, models, sounds, sprites and UI presentation, installed client-wide or through DAI management.

Recommended Build Order

Define the player-visible goal.
Decide which state is client-observed and which changes require server authority.
Create small objectives and verify each one.
Add conditions and recognition instead of hardcoding assumptions.
Wrap behavior in menus/reactions/experience startup.
Add presentation assets after logic is reliable.
Validate, export, test a clean world and test resume/reload behavior.

The DAI Engine Rule

1. Minecraft already has it?  → expose / compile it
2. NeoForge has a clean hook? → bridge it
3. DAI needs a primitive?      → implement it once, generically
4. One game's special rule?    → keep it in that game's datapack

This is why the current 4.1 runtime uses the open Mojang bridge, native Data Components and generated native world data instead of creating another parallel content system for every new Mojang registry.

What 4.1 Changes

Directional physical combat

The Musashi reference implementation can own first-person hand/weapon motion, resolve eight camera-driven slash directions, use a neutral thrust and enter a half-draw guard.

Selective vanilla interception

Custom experience weapons can suppress the conflicting vanilla attack/use presentation without globally replacing normal Minecraft controls.

Runtime foundations remain

Mod-JAR DAI data, global pack version sync, native content/world bridges, addon stacking and companion resource lifecycle continue into 4.1.

DAI is still data-first. Use Java hooks only for physical client behavior Minecraft does not expose to data/resource packs; keep the game's rules in the experience whenever possible.