Project Anatomy
Understand datapacks, resource packs, namespaces, DAI folders, MAIN experiences and ADDONs before authoring content.
What is a DAI project?
A project is not one special “DAI file.” It is a normal Minecraft datapack and, when needed, a normal resource pack containing DAI definitions in known folders. DAI reads those definitions and connects them to engine features.
DAI Engine = runtime/framework Your datapack = rules, state, functions, DAI definitions Your resource pack = textures, models, sounds, sprites, UI art Minecraft = world, entities, inventory, commands, registries
Namespaces: your project's address
A namespace is the first half of an ID. In my_game:hello, my_game is the namespace and hello is the path/ID.
my_game:hello │ └─ resource path / ID └──────── namespace (who owns it)
Use your own stable namespace for original content. minecraft: belongs to vanilla Minecraft. decisions_and_impulses: belongs to DAI.
Minimal datapack anatomy
MyGame/
├─ pack.mcmeta
└─ data/
├─ minecraft/
│ └─ tags/
│ └─ function/
│ ├─ load.json
│ └─ tick.json
└─ my_game/
├─ function/
├─ logics/
├─ reactions/
├─ dai_items/
├─ dai_entities/
├─ dai_experiences/
└─ ...You do not need every folder. Create only the folders your project actually uses.
Minimal resource-pack anatomy
MyGame_Resources/
├─ pack.mcmeta
└─ assets/
└─ my_game/
├─ textures/
├─ models/
├─ sounds/
└─ dai/
└─ models/Gameplay should remain server-authoritative; visuals should represent state rather than secretly define it.
What the common folders mean
| Folder | Purpose |
|---|---|
function/ | Minecraft command scripts (.mcfunction). |
logics/definitions/ | Reusable DAI action/logic definitions. |
reactions/ | Responses to gameplay events. |
dai_items/ | DAI item definitions. |
dai_blocks/ | DAI block definitions. |
dai_entities/ | DAI entity definitions. |
dai_experiences/ | MAIN experience/save ownership and lifecycle. |
dai_worldgen/ | Experience/world construction definitions. |
dai_title_screens/ | Experience title-screen definitions. |
menus/ | DAI menu resources/overrides where documented. |
assets/<namespace>/ | Client presentation in a resource pack. |
MAIN vs ADDON
MAIN
Owns a complete DAI game/experience: save bootstrap, title/presentation, world lifecycle and progression.
ADDON
Adds reusable content or mechanics to a normal world or compatible MAIN without claiming the whole game.
Translate an idea into files
| Player-visible idea | Likely project surfaces |
|---|---|
| “I want a custom sword.” | Item/weapon definition + reaction/function + optional resource model. |
| “I want a quest.” | Objective/logic + conditions + functions/reactions + persistence. |
| “I want a custom mob.” | Entity definition + behavior/attributes + optional render assets. |
| “I want a new complete game.” | MAIN experience + worldgen + progression + recovery + optional companion resource pack. |
| “I want a button to do something.” | Menu definition → action/logic definition → server function/action. |
| “I want custom art only.” | Resource pack; no gameplay authority. |
Checkpoint
You are ready when my_game:hello makes sense as an address and you can explain why gameplay definitions usually live under data/ while textures/models live under assets/.