Dream 1: compact object authoring

Dream is a small declarative language for objects and bounded world activities, with reusable, parameterized components. compileDream(source) returns Object DSL v2 data only after the entire source validates. The scene validator remains the next boundary. No source text, callbacks, imports, JavaScript or shaders execute in the game. JSON v1/v2 remains readable and is the engine's stored format.

The mock world includes seven objects authored in dream-creations.dream. That file is the canonical example library, handmade rather than generated by Muse. Muse authoring success has not been measured. This remains a pre-hackathon, mock-only prototype.

Impact authoring adds intact bouncing bodies, break thresholds and grouped fragments. World interactions covers routes, seats, doors, steam and watercourses.

Start here

dream 1;
material wood = grain #966c48 #b48c60;

component leg(h) {
  part leg box wood at [0,h/2,0] size [4,h,4];
}

object "Small table" {
  body solid radius 26 height 28;
  foundation [58,38] #68765a;
  repeat x 2 {
    repeat z 2 {
      use leg(24) at [x*44-22,0,z*24-12];
    }
  }
  part top box wood at [0,26,0] size [58,4,38];
}

Call compileDream(text) from src/scene/dream.ts. It returns an array of validated objects. A DreamError includes the source line and column, for example Dream 4:2: unknown material 'blue'. Fix the source and compile again. Failure returns no objects, including when an earlier object was valid. Accepted output can be serialized and attached to kind: "custom" objects or the scene's player. Live simulation state stays separate.

Vocabulary

Files start with dream 1;. Statements end in ;; blocks use braces. Comments start with //. Names contain letters, digits and underscores, starting with a letter or underscore. Object names are double-quoted strings.

Shapes: box, sphere, cylinder, cone, pyramid, icosphere, capsule, torus. Dimensions are normalized bounding sizes, not radii. Cylinders, cones and capsules point along Y; a torus hole points along Z. Beams derive center, Y length and rotation from their ends. Rounded corners and capsule tips remain rounded.

Part modifiers follow size, in any order, at most once each:

rotate [xDegrees,yDegrees,zDegrees]
deform (integerSeed, amount)
spin z degreesPerSecond
roll radius
roll z radius
sway (amplitudeDegrees, speed)

roll radius retains the original Y axis; use roll x/y/z radius for other primitive orientations, such as a torus bicycle wheel. Only one motion applies per part. Beams support the same modifiers except rotate, because endpoints determine rotation. The legacy cloth style includes flag wind deformation; use toon or grain for rigid clothing on people. Material style is not a garment simulator.

Coordinates are local XYZ, Y up, in canonical scene units. Angles, phases, trigonometric inputs and spin speeds use degrees. Swing/sway speeds use radians per second in their sine wave, matching the engine. Euler order is XYZ. Parent transforms scale and rotate child offsets. Uniform scale affects dimensions, joint offsets and roll radii; joints never inherit part dimension scaling. Use a surrounding group to scale a jointed component.

Expressions support decimals/scientific notation, names, parentheses, unary +/-, + - * /, and sin(angle)/cos(angle) in degrees. Multiplication/division precede addition/subtraction; binary operators associate left to right. No string expressions, properties, assignment, conditionals or general functions. Variation uses repeat indices, parameters and seeded deformation.

Constants are block-scoped; child blocks may shadow outer constants. Component bodies see their parameters and global constants, independently of caller locals. Globals resolve in declaration order. Components/materials may be declared before or after objects. Repeated parts/joints receive deterministic IDs from expansion order. Editing earlier source may change those local IDs; stable world object IDs still belong to the scene document.

What the examples taught us

These expand into existing v2 primitives. No object-name recipe or renderer branch was needed. Remaining geometry gaps are visible too: the basket has no continuous woven wall, primitive faces do not make a detailed human face, and stacked rocks do not fuse into one sculpted mesh. A later demonstrated need may justify bounded profiles/extrusions, sockets or shaped surfaces, with geometry and validation tests. Avoid a special bread or person engine kind for each new example.

Authoring instructions for Muse

Use this contract, the syntax above and a few canonical examples as a future provider prompt:

Interpret the user's sketch as intent for the whole playable world. For object requests, return only Dream 1 source. Choose silhouettes and proportions first. Define a small palette. Reuse components when structure repeats. Use endpoint beams for connections, and joints where parts must move together. Keep feet and bases at local Y=0. Ground buildings upright with a foundation; use surface grounding only for props that should tilt with terrain. Declare one conservative physical cylinder independently of visual detail. Stay inside every budget. If a sketch needs unsupported geometry or behavior, report that limitation through the world interpretation's unresolved labels; do not invent syntax or code.

compileDreamWorld(source) additionally compiles routes, placements and watercourses. See world interactions and the complete interactive-world.dream mock source. Main racing-road topology, hills and checkpoint rules still use the scene document. Provider integration and a model repair loop remain future work.

Budgets

Source: ≤65,536 UTF-16 characters, ≤12,000 tokens, ≤16 objects, ≤16 nested/expanded blocks, ≤2,048 expanded statements per file, and 0–32 iterations per repeat. Recursive components fail. Numeric results must be finite within ±1,000,000. Parsed expression nesting ≤32; evaluation depth ≤64. Combined uniform scale must be positive and ≤16.

Output budgets stay unchanged: 1–32 parts, ≤12 joints, joint depth ≤4, reach ≤256, bounded dimensions, offsets, bodies, materials, deformation and motions. See v2 for numeric bounds. Empty objects, invalid metadata, unknown commands/names/materials, duplicate definitions, bad hierarchy, imports and executable syntax fail. Scenes still cap live jointed actors at 24 including the player. World source may declare ≤12 routes, ≤64 placements and ≤8 watercourses. A scene accepts ≤24 route actors and ≤16 steam emitters. See the interaction contract for the additional geometry and physical limits.

Compilation happens once at mock-source load, outside the frame loop. Static results retain GPU instancing; props and jointed actors retain existing bounded live paths. Compact source reduces authoring duplication, not expanded geometry cost. Verification reports character counts, not tokenizer savings or AI accuracy.