DAI ENGINE 4.2

A JSON Game Engine for Minecraft

DAI Engine turns datapacks, resource packs and JSON into a reusable game-development layer. DAI 4.2 adds datapack-driven title launcher takeover through dai_shell_presentations. The JSON-first input, screen, overlay, Creator and persistent-world foundations from 4.1 remain part of the current engine.

DAI 4.2 production standard

Current DAI experiences are designed around a shared production standard proven across Space Between Blocks and the modernized project library: canonical terrain, staged construction, physical-state validation, versioned local repair, explicit multiplayer ownership, server-authoritative gameplay and presentation that mirrors real state.

Build a complete game step by step

Engine, Not One Fixed Game Mode

DAI JSON → friendly reusable abstraction
        ↓
Minecraft / NeoForge native capability when available
        ↓
Generic DAI runtime primitive only when necessary
        ↓
Pack-specific behavior stays in the datapack

The framework is intentionally moving away from reimplementing systems Minecraft already exposes. A pack can be a tiny addon, a content library, a UI layer, an automation system or a complete standalone game.

Global Datapacks: One MAIN + Unlimited Addons

<gameDir>/datapacks/ acts as DAI's global game library. One MAIN experience may own the launched save and presentation while any number of ADDON packs contribute reusable systems.

Global /datapacks/
├─ MyGame.zip                → MAIN
├─ DamageIndicators.zip      → ADDON
├─ ComicEffects.zip          → ADDON
└─ ordinary_pack.zip         → UNMANAGED

Backwards compatible: explicit dai.role metadata is optional. Older packs that never declared a role continue through legacy inference.

4.1 Physical Input & Keybind Conditions

DAI 4.1 turns the physical client input layer into a creator-facing JSON surface. Datapacks can intercept left click before Minecraft resolves a target, react once per gameplay tick, and query registered key mappings without writing pack-specific Java.

player_attack_inputplayer_input_tickkeybind_heldkeybind_pressedkeybind_releasedkeybind_exists

{
  "type": "keybind_pressed",
  "parameter": "examplemod:special_ability",
  "operator": "is_true"
}

Keybind conditions resolve DAI aliases first and then Minecraft's live registered key-mapping list, allowing properly registered NeoForge mod keybinds to participate in datapack control schemes. Unknown mappings fail closed.

Backwards compatible: input_attack_held and input_use_held remain supported, and existing entity-attack/block-break reactions are unchanged.

Directional First-Person Combat

DAI adds the physical client-side piece that datapacks and resource packs cannot provide alone: controlling the first-person hand and held-item transform while selectively intercepting vanilla attack/use presentation. Musashi Story is the reference implementation.

UpUp-RightRightDown-RightDownDown-LeftLeftUp-LeftNeutral ThrustGuard

Hold attack → capture draw-origin camera
Move view   → resolve one of 8 screen-space directions
Release     → slash in that direction
No >=5° movement → forward thrust
Hold use    → half-draw diagonal guard

The engine-side bridge owns physical key transitions and first-person transforms; the experience datapack owns gameplay state, damage and reactions; the companion resource pack owns the weapon models and screen-space slash art.

Scope: the 4.1 implementation currently ships as the Musashi Story reference path for its Katana, Nodachi, Wakizashi and Naginata. Treat it as the foundation for broader creator-facing combat profiles rather than assuming every custom weapon automatically receives directional combat.

Mod-JAR Datapacks + Global Version Sync

DAI no longer treats a standalone ZIP as the only way to distribute DAI-authored data. Installed mod JARs are scanned as DAI content sources early enough for native registry shells, MAIN experiences, title screens and generated world data.

mods/MyGame.jar
└─ data/my_game/
   ├─ dai_experiences/
   ├─ dai_title_screens/
   ├─ dai_items/
   └─ dai_worldgen/
        ↓
DAI early discovery + normal resource reload

For normal global datapacks, <gameDir>/datapacks/ is now the update source. If a save already contains a DAI-managed pack with the same stable identity, DAI installs the current global copy and removes or deselects stale versions.

{
  "pack": { ... },
  "dai": {
    "role": "main",
    "pack_id": "autocraft_mineshaft",
    "version": "0.5.3"
  }
}

Legacy packs still work: when dai.pack_id is absent, DAI can derive identity from authored non-vanilla data namespaces. A _vX.Y.Z filename can supply version ordering when explicit metadata is absent.

Client / Common / Server

Client

Input, camera, menus, title screens, overlays, loading presentation, application branding, recognition and client-facing automation.

↔

Server

Worldgen, persistence, authoritative functions, block/inventory mutation, natural generation/spawning, registry preflight and generated server-data packs.

Common definitions stay side-safe. JSON models, registries and payload records are kept away from physical-client classes so the same content remains usable on integrated and dedicated servers.

4.1 Action + Condition Runtime

DAI 4.1 retains and expands the shared creator runtime: systems that could exist in JSON can now be directly mutated and queried through the shared action/condition vocabulary instead of requiring pack-specific glue.

state_*capability_*reference_*attribute_*native_attribute_*animation_*content_*status_*emit_reaction_event

action JSON
  ↓ conditions (one captured context per group)
DAI_ActionResolver / DAI_ActionQueue
  ↓
registered action handler
  ↓
client runtime OR DAI server-authority mutation

The matching condition providers expose state existence/value, runtime capabilities, reference type/age/distance/aliveness, custom/native attributes and modifiers, animation playing/paused/finished/tick state, and registered/active/held content.

Open Mojang Registry + Data Bridge

DAI 4.1 can compile JSON directly into Minecraft's native registry/data locations instead of creating a parallel DAI engine for every Mojang system.

dialogsenchantmentspaintingssongsinstrumentstradesvariantsworldgen

data/my_pack/dai_registry/example.json
{
  "registry": "damage_type",
  "raw": {
    "message_id": "example",
    "exhaustion": 0.1,
    "scaling": "never"
  }
}

dai_registry targets arbitrary registry paths and dai_data targets arbitrary server-data paths. Dedicated friendly folders also exist for common Mojang registries and native recipes, loot tables, advancements, predicates and item modifiers.

Native Data Components + Runtime Discovery

Registry-backed DAI items can define a components (or explicit native_components) object. DAI resolves the registered Minecraft DataComponentType and decodes the authored JSON with that component's codec.

{
  "registry_backed": true,
  "native_registry": "item",
  "components": {
    "minecraft:max_stack_size": 1,
    "minecraft:enchantment_glint_override": true
  }
}

At runtime DAI also writes config/decisions_and_impulses/capabilities.json containing discovered Minecraft registry keys, built-in Data Components and direct DAI→Mojang bridge folders. Creator tools can inspect the engine instead of hardcoding every future Mojang addition.

Native JSON Entities, AI & Natural Spawning

Carrierless registry-backed DAI entities define their actual dimensions, attributes, behavior sequence and spawn policy. Legacy carrier-backed entities remain supported.

{
  "registry_backed": true,
  "native_registry": "entity",
  "native_attributes": {
    "minecraft:max_health": 30.0,
    "minecraft:movement_speed": 0.28
  },
  "entity": {
    "category": "monster",
    "width": 1.15,
    "height": 1.35,
    "behavior_sequence": "example:hunter_ai",
    "vanilla_ai": false,
    "spawning": {
      "natural": true,
      "dimensions": ["minecraft:overworld"],
      "placement": "on_ground",
      "min_group": 1,
      "max_group": 3,
      "cap_per_player": 6
    }
  }
}

target_playerchase_targetmelee_attackwanderflee_playerentity_has_targetentity_target_distance

Reusable Natural Structures & Features

dai_structures and dai_features can opt into generic natural generation. Placement is deterministic from the world seed and chunk coordinates and supports spacing/separation, frequency, dimension and biome filters, surface/cave/ocean/fixed/random Y placement, rotation, mirroring and persistent placement markers.

Reusable primitive: games no longer need their own tick-loop just to scatter authored structures or features across a world.

Native Biomes, Dimension Types, Timelines & Dimensions

dai_biomes, dai_dimension_types, dai_timelines and dai_dimensions compile into Minecraft-native server data. Advanced authors can use friendly fields, raw/native bases or the open bridge for the underlying Mojang format.

Environment attributes can describe sky/fog/cloud/light/celestial presentation, including cloud height, star brightness, sun/moon angles and other native environment controls. Multi-noise biome sources and custom world presets are supported as part of the generated world-data path.

Complete MAIN Experience Branding

A MAIN experience may provide its own window title, application/taskbar icon, FML early-startup theme, Minecraft resource-reload loading screen, world-generation/terrain-loading presentation and DAI title screen. Assets stay in the companion resource pack.

JVM launch
  ↓ FancyModLoader early theme
DAI / Minecraft resource reload
  ↓ MAIN loading presentation
DAI title / save entry
  ↓
World generation + terrain loading
  ↓ MAIN world_loading presentation
Gameplay

Early-startup timing: normal DAI Java initializes after FML's earliest display. DAI synchronizes the active MAIN theme into config/fml/, so a newly discovered MAIN becomes the early startup theme on the next JVM launch.

Experience Ownership & Player Controls

Experience definitions can own a save, choose/create/load it, select worldgen, run first-join/resume actions, own the grave/backtick UI, define branding and place a creator-authored ceiling over optional automation. The player's own configuration always remains the upper permission boundary.

Managed + Companion Resource-Pack Lifecycle

Official Packs can use stable dai_managed:* repository IDs, while normal ZIPs in /resourcepacks can auto-enable through namespace matching or explicit dai.auto_enable / dai.companion_id. DAI replaces stale versioned filenames while preserving unrelated user-selected packs.

{
  "pack": { "pack_format": 48, "description": "My Experience" },
  "dai": { "auto_enable": true, "companion_id": "my_experience" }
}

Native Runtime Exposure

DAI 4.1's native layer now reaches beyond registry identity: blocks can own physical/light/state behavior, content receives lifecycle callbacks, projectiles run server physics, vehicles consume real movement input, portals/interactives use standalone volumes, particles/effects/potions can register native IDs, and fluids can modify entity physics.

Static vs reloadable: Minecraft registry shells still require a restart when their native structure changes. DAI keeps action/event/runtime behavior hot-reloadable wherever Minecraft permits it.

Native Runtime Guide

4.1 Input, Mouse & Data Screens

Define controls in dai_keybinds, read named or raw key transitions, query mouse state and open complete dai_screens interfaces.

Input / Mouse / Data Screens →

4.1 Persistent Item + Block Data

Mutate persistent item Data Components through registry codecs and give JSON-owned DAI blocks synchronized typed state, ticking callbacks and inventory slots.

Persistent content-state →