Generate
Roll a whole cave system from intent — chambers, connections, dressing — then refine it with the Sculpt verbs. It writes the same recipe; Undo brings back whatever was there before.
Tip: the Cutaway slider up top shows the whole layout like a map. Every roll is different — click again until one speaks to you, then sculpt it.
Sculpt
Shape the space. Every change rewrites the environment's recipe and the engine regenerates the cave — what you see is exactly what the game will generate.
Shape
Structure verbs
Blobs and carves are entries in the recipe — rerolling or resizing the cave keeps them. Click one above to move and resize it.
Tunnels
Sketch a gallery
Draw a stroke — it becomes a flat-floored gallery melted into the cave (top-down view; the cave center is the middle of the pad).
Materials
What the cave is made of. Choices apply to the whole cave today; painting regions comes later.
Editing the live cave needs the engine — the Forge is the cave-authoring surface. Connect the engine and the wall / ore / floor / growth controls appear here.
Texture library
Every PBR material the engine ships (albedo + normal + roughness). Click one to inspect it on the cube — drag the cube to turn it.
Paint regions — floor vs. ceiling vs. veins: different materials for different parts of the cave, each region part of the recipe.
Surface brushes — paint a zone by stroke; the stroke becomes a region shape, so it regenerates with the cave.
Material editing — author new block materials (textures, properties) without leaving the tool.
Assets
Structures from the game's blueprint library, placed on your cave floors by rules — count per blueprint, random floor points, random facing. Placement is part of the recipe: it rerolls, undoes, and saves like everything else.
In this cave
Imported assets
Everything you've generated or imported. Blueprints place via + Place; model blocks appear in the scatter/hangings palettes. 🗑 deletes the files permanently; ☁ publishes to the cloud library.
Creatures (rigged)
The game's rigged GLB entities — click one to view it on the stage with its animations playing. Pick an animation from the row that appears.
Blueprint library
Generate with Meshy
Describe it; Meshy makes the mesh (1–4 minutes, uses your Meshy credits), then it lands below ready to voxelize.
Import mesh → blueprint
Pick a GLB (AI-generated or downloaded), choose resolution and material — it's voxelized in the browser and saved as a real blueprint, instantly placeable and previewed on the render stage.
Creatures & rigged assets — GLB models with bones and animations (the vendor asset lane), placed and configured here.
Combat
The combat parameter sheet: a stat-balancing and meta bench first — the game director: "testing meta and stat balancing" — difficulty an illustrative second. One entity's stats, stagger rules and health model beside live math over its real attack timelines. Every knob is a test bench — edits stay in this page's memory and recompute the numbers on the right; 📌 pin as baseline turns every recompute into a delta against a frozen config; ⬇ download hands you the edited JSON to walk through engine review. Saving into the game is an engine/review act — deliberately not a button here tonight.
Quick loop: pick a combatant → adjust essentials → → read the tiles. Everything else is optional depth.
ℹ About this simulation
Why it exists. To make tuning claims testable and comparable. The goal, per the game director: "testing meta and stat balancing," not absolute difficulty — comparisons stay meaningful where absolute numbers inherit model assumptions (📌 pin as baseline is that idea as a button). Difficulty here is declared as target outcomes — clear rates, median clear times — and every number recomputes from the same inputs, so a balance discussion argues over one shared, reproducible basis instead of two gut feelings. It is a model, not the game: once the game reports real players, telemetry is meant to correct it — until then this is the best available stand-in.
How it works. Inputs are engine-true: the entity's own stats JSON and its tick-exact attack timelines (30 ticks/s), with the damage, Defense, regen and stagger formulas cited line-by-line from engine source in this page's code. Bouts are event-driven and emit event logs — the fight report, the 3D battle replay and the duel all share that one format, so anything simulated can be replayed and inspected. A population run simulates 1,000 skill-stratified players per tier in roughly 80ms, seeded and bit-reproducible: same inputs, same histogram, every run. The difficulty solver works backwards — you declare the target outcomes, it searches the multipliers.
The two models. Simple (the default, and the only balance-bearing one) is the director's spreadsheet made executable: the player attacks for an editable uptime share of the bout and eats a flat editable share of enemy hit windows — engine-true damage including Defense, no psychology. Behavioral is an experimental lens, not for balance claims: reaction-time distributions drawn against each attack's real telegraph, plus learning, tilt and greed — and it can adopt YOUR measured reactions from the duel.
What it is not. Per the game director's rulings — "we cannot simulate it all, only approach it":
- It does not simulate movement, spacing, terrain, co-op coordination, multiple enemies, or AI positioning.
- Dodging and interrupts are not simulated in the balance-bearing model (director ruling).
- The interrupt/Sturdiness system is moving to a Poise mechanic (WIP) — the stagger math here reflects the current build only.
- AI attack selection is uniform over the entity's hitbox timelines — not the real brain's weighting.
- Melee weapon wear is assumed at 1 per swing — not wired in the current build.
- Telemetry reporting exists as a design and is deliberately parked until combat is mechanically complete.
Combatant
Filesystem truth via serve-studio (/entitylist) — combatants first (docs carrying Stats / Combatant / EntityHealth), everything else under the divider. Hosted with no serve-studio (2026-07-17), the Keep catalog's entity-definition rows are the fallback shelf — sign in via the profile chip.
essentials — full detail in the groups below
Stats & behavior
Every leaf of Stats, Combatant, EntityHealth and VisionDetection. Edits recompute all math live; an accent label means the field differs from disk. Arrays/objects edit as JSON. Shipped Defense values are all 0 today — the engine's defense curve (real, cited in source) only bites once you raise it.
Opponent dummy
The other side of every number on the right. Player weapon truth lives in item definitions (held-item hand stats), so the dummy is configurable, not fake-authoritative — set it to the loadout you're balancing against.
Simulations
Deterministic by construction: the randomness is mulberry32 seeded 1337 — same inputs, same histogram, every run.
Player model
Two bout engines can drive the population numbers, the tier solver and the gauntlet. Simple (default) is the balance-bearing model — Floris spreadsheet semantics: the player attacks for an editable share of the bout (the rest is repositioning/healing, not a reaction draw), eats a flat editable share of enemy hit windows, and Defense stays the engine formula. Dodging, staggers and interrupts are deliberately not simulated here. Behavioral keeps the two-sided reaction sim as an opt-in experimental lens — not for balance claims. The duel and battle replay are feel/demo tools and ignore this switch.
Skill percentile enters the simple model only as modest uptime/dps scaling (uptime ×0.90–1.10, damage ×0.85–1.15, swing rate ×0.90–1.10) — population percentiles still exist, but they measure output, not reads.
Behavioral assumptions (read only while Behavioral is selected): every behavioral constant lives in the one table below, each row labeled with its source — literature rows are shapes borrowed from published human-performance data and are built to be replaced by telemetry one row at a time once the game reports real players; modeling rows are harness mechanics. Entity attacks are drawn uniformly from its hitbox timelines and replayed by their real tick data — AI weighting is deliberately not modeled (that holds for both engines).
Difficulty tiers
Secondary by design — the game director: difficulty has "so many unknowns" (co-op, terrain, multiple enemies); tiers here are illustrative envelopes, not shipping difficulty. Editable targets per tier. The solver searches entityHealth× and entityDamage× inside the envelope — coarse 9×9 log-spaced grid, one half-step local refinement, each cell scored by a 300-player population sim, winner verified at N=1000. Clear rate is measured over the whole population; median clear time over the tier's reference skill band (±10 percentiles). These two multipliers are the subset this bench can ground: the game's difficulty design is broader (spawn rates, hazards, sanity, ability cooldowns); a cooldown× axis is a possible future addition to the solver.
Battle replay
A sampled bout from the population sim, performed on the stage: the entity's real rig plays its real attack timelines (animation + sound + hitbox volumes) as the log's clock passes each event. The challenger is a deliberate abstraction — outcomes are visualized, movement is not simulated.
⚔ Fight it yourself
A timing duel over the real attack data — spacing and movement are not simulated. The creature draws uniformly from its real hitbox timelines and performs them for real; your inputs are judged on the clock against each window's true telegraph. Every duel lands in the run picker above and banks your reaction times for the behavioral model.
Attacks
Every timeline of this entity holding a Hitbox clip. Damage = AttackDamage × clip DamageMultiplier through the engine's defense curve vs the dummy; stagger = the engine's power>sturdiness gate — the current build's rule (the Sturdiness/interrupt system is slated to become a Poise mechanic, WIP). Recomputed on every edit.
Headline numbers
Fight report
Tune against a simulated population today — pin a baseline to measure changes as deltas; flip the toggle the day telemetry lands — same charts, same targets, zero rework.
Timelines
The choreography rung: where animation, sound, damage windows, particles and camera shake meet on one clock. This is a read-only viewer (v0) over the engine's own timeline files — the multi-track editor is the next build. Timelines are game files; editing them stays server-authoritative territory, decided with the engine team.
Library
Every environment is a folder of game content — what you save IS the shipping format, byte for byte. New environments are born dev-only, invisible to the real game until published.
Environments
Create
Checkpoint
Edits autosave continuously (nothing is ever lost). The checkpoint is your explicit safety line: Save moves it here, Revert returns to it.
Content browser
The whole game lives here: every shipped asset and every creator publish, versioned and hash-verified in the cloud catalog. Search is instant; click any card for its story — versions, files, provenance. Descriptions and tags are editable on your own content (machines wrote the first draft).
checking…
Dashboard
The four question families (doc 11): activity & adoption, content production, AI usage, health & friction — SQL views over telemetry, visible to reviewer/manager roles.
connect & sign in to load…
Help
How this tool thinks.
The document
You are editing a recipe, not blocks. The recipe lives in the environment's own game files; the engine regenerates the cave from it after every change. That's why Reroll is safe (new randomness, same design), why nothing you do can drift from what ships, and why every edit is undoable.
The render window
Drag to orbit · shift+drag or middle-drag to pan · wheel to zoom · Home to reframe on the cave (also resets pan). The game window only renders; all editing happens here.
Preview scale
Work at 64 for ~1-second feedback while sculpting; switch to 192 to see full preview quality. The recipe is identical at every scale.
Diagnostics
About
The Foundry — where raw assets are cast into game-ready stock for Everdeep: materials, meshes, rigged creatures and animations, refined here, shaped in the Forge, stored in the Keep.
Standing on the engine
The tool is built on the Everdeep engine's data architecture. Worldgen is shape-in, voxels-out: environments are small Lua recipes over an SDF/CSG shape language, and the engine turns them into worlds. Blocks, materials, particles, creatures and whole mods are data, not code — JSON and GLB files the engine picks up by convention. That degree of data abstraction is rare; it is what made a live, web-based creation studio feasible in days rather than months, and it is the work of the Sun Fox engine team.
Found along the way
Building against the real engine surfaced items now documented for the engine team: speed polish (the editor's bake loop went from minutes to ~1 second — parallel chunk sweep, release-build bake, fast chunk discard, stripped editor boot) and bugs (ambience-zone fog values never reaching the shader, a dead sky-color field, the chunk vertex format's tiling limit, a disposal-docs mismatch). All are recorded as decision records with measurements.
How it works
Editing operates on a document — never voxels, never raw files. Every slider, verb and placement is a small change to a compact recipe; the engine rewrites the environment's Lua parameters from it and regenerates the cave in about a second at working resolution. The game window is the truth renderer: what appears on screen is the real pipeline, not a preview approximation. Every operation is undoable and reroll-safe, and output is saved as ordinary game content in the Contentstudio mod — never in core assets. Imported meshes (including AI-generated ones) become real blueprints, model blocks with their own materials and effects, or rigged, animated creatures.
Who it's for
Today: vendors, network partners and contractors — the L1 studio tier with the full toolbox. The same protocol powers the in-game god mode (L2) and marketplace (L3) prototypes — see the god-mode prototype for the player-facing face of these features, live on the same engine.
The layer ladder
A game is layers, and in Everdeep every layer is data: space (environments) → matter (materials, blocks, props) → inhabitants (creatures, animations) → choreography (timelines — where animation, sound, damage and effects meet) → and above them the arc: the beats, gates and goals that give a player a reason to go anywhere. Space, matter and inhabitants are working today. Choreography has its first foothold: the Timelines viewer renders the engine's timeline system (thirteen verbs of JSON) as live multi-track choreography. The arc layer is not represented in the tool today. The entire shipped game — 3,000+ assets, every kind — already lives versioned and hash-verified in the studio's catalog.
Engine and platform
The platform joins two directions of architecture. From the engine side: content-as-data, the shape language, sandboxed Lua and the timeline system — capabilities built by the engine team from what the game needed. From the platform side: identity, provenance and the separations of concerns that keep the game pure. The two meet at the document layer — engine files on one side, the catalog on the other, with this studio as the interface between them. The ✦ sparks throughout the tool capture observations at that boundary; each one is recorded to the platform.
How this was built
The studio was built by one architect working with an AI. Every feature passed through a mandate written before code, design laws that were never bent (never touch core; the engine owns truth; content immutable), and decision records for every engine finding. Several capabilities were deliberately not built, or were built and switched off, pending review by the right owner. Distribution follows the same policy: the tool is not handed out on its own — access comes with the working discipline around it.
Design intent
Everything in the studio is held to the game director's three F's — fun, frictionless, flexible — with the JSON and the Lua tucked behind approachable controls. The aim goes one step further: for a cave, a creature or a beat of choreography, success is measured by how it feels, and the tool is built so that reaching that feel is fast rather than laborious. Authoring lives here, apart from playing, which keeps the game pure and gives content-making a dedicated home. The studio's direction is set by the game director's vision; its output scales with how much of that vision flows in.
The architecture — who owns what
The separation of concerns this studio is built on: the engine owns semantics — what content means, how it bakes, renders and plays; sealed and authoritative. The tool owns ergonomics — how humans make content: iteration speed, undo, sketch pads, AI assists. The database owns truth and history — what exists, whose it is, which version, what's approved. And the game only ever consumes — content arrives validated and versioned; the runtime never hosts authoring. In-game tools are useful bootstraps, but authoring inside the runtime tangles editor concerns with server authority; keeping authoring here keeps the game pure and the server's word final. One protocol, many clients — the game stays the game.
The backend around it
Identity and accounts, an asset catalog with immutable versions and audited moderation, cloud storage, per-asset review threads (status, comments, roles) and a recorded event log — all live today. Login-gated distribution is built and install-tested but deliberately switched off: the package contains the unreleased game, so turning that tap on is Sun Fox's call, not this tool's.
Design laws
Fast first, quality on demand — draft resolution lands in a second; raise it when the shape is right. Document-centric — edits target a recipe and the engine owns the truth; nothing made here can drift from what ships. Content immutable, metadata mutable — versions and hashes are forever; descriptions and tags are living. Background work must be frame-budgeted — a warm-up that steals frames is a bug.
Where Everdeep goes next is game direction; this studio's job is to make that direction cheap to execute. Proposals travel through the ✦ notes on each page.