Dress Up reports · ^du_report(17) · 2026-10-24 · about Messed Up Dress Up, a game made with M and N · ^ticket(593)

KIDS' CHOICE GAMES PRESENTS

GAME SCRIPTS
PLAYER'S GUIDE

for MESSED UP DRESS UP · the 📜 Scripting panel · first edition

Matthew, 2026-10-24: “explaining the new game script feature, in the spirit of a 1980s or 1990s game manual, with screenshots … we want to show what log events look like, and how to use them to ‘debug’ the game script”; “the report/manual for game scripts should show examples of erroneous scripts, and how to check the errors and fix them”; and “use this report to list the full feature set, to track it”.

1WHAT ARE GAME SCRIPTS?

Some rooms in Messed Up Dress Up have rules. Pull a red lever in the trap room and a pit opens or shuts. Pull a blue lever and a boulder drops into a pit, or is lifted out. Pull the lever in a tree house and its trap door swings. Walk out of a square and the world decides where you arrive.

Every rule is a small program, a game script. The game hands it what it needs to know, the globals (which levers are up, which pits are open, which square of the world the friend is in), and an event (“the left red lever was pulled”). The script answers with commands (“flip the left lever; open pit 0”). The game carries them out, with the sounds and animations you know.

The three languages:

• JS: the game's own JavaScript, shown read-only, exactly as the game runs it.
• Hazel: a language with a type checker that reads your rule as you write it, and still runs a rule with mistakes in it.
• 🍄 Fumola: a language in the style of Motoko, running in the browser as WebAssembly.

2GETTING STARTED

1. Open the side panel and choose the 📜 Scripting tab.
2. At the top, in ⚙️ script editor settings, the all row picks one language for every room: JS Hazel 🍄 Fumola. Each room's own box has the same three chips, to choose room by room.
3. Walk into the trap room and pull a lever. The rule in the language you chose decides what happens.

3THE SCRIPT PANEL

Settings

⛶ Max size and the outline

Every box has a ⛶ max size button. It opens the box across the screen, with an outline on the left: every box, and in each its types (with their kinds and how many cases) and its functions (with their types, as Hazel works them out). Click a line in the outline and the box goes to that definition and selects it. Drag the bar between the two sides to make the outline wider or narrower.

Next to ✖ back to game, the 🎮 show game viewport chip puts the game itself at the top of the outline, so you can play while reading the rules and the log.

Hazel's tiles

Hazel boxes show the rule as Hazel's own tiles, the real Hazel editor, in the page's colours. Type in them and the game uses your change about half a second after you stop. Right-click a name for Goto definition (or press F12): it finds the definition even in another box, in Common, or among the types at the program's start. Prefer plain text? Choose hazel: ✏️ text in the settings.

4A WALK THROUGH THE PIT ROOM

The trap room has two pits and four levers. The two red levers open and shut the pits; which lever works which pit depends on the room's wiring: normal, reversed, or at random. The two blue levers drop a boulder into each pit the lever's side works, or lift the boulders out if one is there.

Here is the red lever's part of the rule, in Hazel:

| Pull(side) =>
  let (was0, was1) = Common.pits_open(g.lever_L, g.lever_R, w) in
  let l = if side == L then !g.lever_L else g.lever_L in
  let r = if side == R then !g.lever_R else g.lever_R in
  let (now0, now1) = Common.pits_open(l, r, w) in
  Flip(side, Common.pit_moves(0, was0, now0, Common.pit_moves(1, was1, now1, Done)))

Read it line by line: which pits are open now; the levers after this pull; which pits are open after it; then the answer, flip the lever that was pulled and move each pit whose state changed. Common.pits_open and Common.pit_moves are helpers in the Common box, shared by every room.

5WHAT A RULE SAYS: THE SHAPE OF Cmd

Every rule is one function, on_event. It takes two things, the globals g and the event e, and gives back one thing, a Cmd: what the rule wants the game to do. It changes nothing itself. It only answers, and the game carries the answer out.

# takes the globals and the event, gives back a Cmd #
let on_event = fun (g, e) : (Globals, Event) -> ...

A list of things to do

A Cmd is a list of commands, one after another. Each command's last part is the rest of the list, and the list ends with Done:

# do nothing #
Done
# flip the left lever #
Flip(L, Done)
# flip it, then open pit 0 #
Flip(L, SetPit(0, true, Done))
# say it, wait half a second, then flip #
Say("Ha!", Wait(500, Flip(L, Done)))

Read it from the outside in: the first command is the outermost one. The game does them in that order, the first command first.

Every command

A room only knows its own commands. Give the trap room a GoSquare and the list stops there: the log line says ⚠️ the room does not know it (chapter 8).

Building one: start with Done, wrap commands around it

Since each command holds the rest, you build a Cmd from the end. Many helpers take the rest as their last argument, called k, and either wrap a command around it or hand it back unchanged. Common.pit_moves is one:

# a pit that changed from was to now: SetPit, else nothing #
let pit_moves = fun (i, was, now, k) : (Int, Bool, Bool, Cmd) ->
  if was == now then k else SetPit(i, now, k)

So the red lever's answer in chapter 4, Flip(side, Common.pit_moves(0, …, Common.pit_moves(1, …, Done))), is a flip followed by zero, one or two SetPits, whichever pits changed. To add a command to any answer, wrap it around the rest: Say("Watch out!", Flip(side, …)).

Your answer in the log

Because a Cmd says what should change, the event log reads it as a change to the globals: each command sets its field, as in the table. That is the first step of “what it changed”, pre event ⟶ post rule. Each change's field of the globals is a coloured chip of its own. The commands with no field of their own in the globals (SetPit, Say, Wait, GoRoom) sit beside the changes, with no field chip: a pit's lid follows its lever, so SetPit only agrees with the Flip that is a real change. Everything else the game does while carrying the event out, which no command asked for, is the second step, post rule ⟶ post event (chapter 6).

6THE EVENT LOG 🪵

Every time the game calls into a script, whichever language answers, the call goes into the event log, newest first, up to the last 100 (or all of them: keep: all). A line says:

• its number and the time, to the millisecond;
• which language answered: JS, Hazel or Fumola;
• the call and its event, as in TrapRoom.on_event(Pull("L"));
• how long it took in all (and how much of it was compiling the program, the first time);
• how much of the globals it changed.

Open a line to see the event, the rule's answer just under it, then, in the box, what changed, and, under one more fold, the globals in full, side by side, with every changed field marked.

Each call keeps three snapshots of the globals: pre event, as the rule gets them; post rule, the same with the rule's answer applied, each command setting its field (chapter 5); post event, once the game has finished carrying the event out. So “what it changed” comes in two steps. pre event ⟶ post rule is what the rule's answer says to change: for the red lever, the lever it flips; for a way out, the square it walks to. post rule ⟶ post event is what the game engine did beyond that, which no command asked for: a placed lever turning over, a boulder lying where it landed, and anything that came out otherwise than the answer said (a walk cut short shows the square changing back). For the game's own JS, which writes the globals itself, the first step is what its handler wrote. A step that changed nothing says so with a small no change chip. Under the two steps, over at says how long after the call the event was over, and time how long the rule and the whole call took. The changes are chips: a field, =, what it was, ⟶, what it is; the newest few are on the line itself too, to skim the log without opening it.

The log of the run behind these pictures:

#6 HAZEL  TrapRoom.on_event(Pull("L")) 11.5 ms · handler: lever_L = false ⟶ true · game (over at 1.4 s): nothing
#5 HAZEL  TrapRoom.on_event(Pull("R")) 9.9 ms · handler: lever_R = false ⟶ true · game (over at 1.4 s): nothing
#4 JS     TrapRoom.on_event(Pull("L")) 5.2 ms · handler: lever_L = true ⟶ false · game (over at 1.4 s): nothing
#3 HAZEL  TrapRoom.on_event(Pull("R")) 10.8 ms · handler: lever_R = false ⟶ true · game (over at 1.4 s): nothing
#2 HAZEL  TrapRoom.on_event(PullBoulder("L")) 18.3 ms · handler: covered[0] = false ⟶ true · game (over at 1.4 s): nothing
#1 HAZEL  TrapRoom.on_event(Pull("L")) 19.1 ms · handler: lever_L = false ⟶ true · game (over at 1.4 s): nothing

7DEBUGGING WITH THE LOG

When a lever does something you didn't expect, work through it like this:

1. Do it once. Pull the lever a single time, so the newest entry is the one you care about.
2. Which language answered? If it says JS where you expected Hazel or Fumola, your rule didn't answer. Look for ⚠️ or ⛔ on the same line (chapter 8).
3. What came in? Open the entry and read the event and the globals before. Was the lever really up? Was the wiring what you thought?
4. What did the rule say? The rule's answer is exactly what it returned: Flip(L, SetPit(0, true, Done)), as data.
5. What changed? If the answer is right but what it changed isn't, the game carried a command out differently than you meant. If the answer itself is wrong, the mistake is in the rule.
6. Compare with JS. Switch that room to JS, pull the lever again, and compare the two entries side by side.

8TROUBLESHOOTING: BROKEN SCRIPTS

Four ways a script goes wrong, what each one looks like, and how to fix it. Every example was broken on purpose, in the run behind this guide.

7.1 A type error (Hazel)

Hazel reads the whole program before anything runs. Change the red lever's answer from Flip(side, …) to Flip(3, …): a lever is a Side (L or R), not a number.

7.2 A hole to fill (Hazel)

Leave part of a rule unwritten, a ? or an if without its else, and Hazel counts it: “1 hole to fill”, or “1 bracket or keyword without its partner”. It appears just like a type error: in the box, in the outline, and in a check entry. The game's JS moves until the rule is finished.

7.3 A command the room doesn't know

Every room carries out only its own commands. The trap room knows Flip, SetPit, DropBoulder and LiftBoulder; it doesn't know GoSquare, which belongs to the world. This rule type-checks, since GoSquare is a real command, but the room can't carry it out:

let on_event = fun (g, e) : (Globals, Event) -> GoSquare(0, 0, N, Flip(L, Done))

7.4 A rule that stops (Fumola)

Some mistakes only show up when the rule runs. In Fumola, reading past the end of a list stops the rule:

public func on_event(g : Common.Globals, e : Common.Event) : Common.Cmd { let z = [1, 2][5];

9WHAT A SCRIPT COSTS 🔬

In the ⚙️ Advanced tab, under 🧪 tests and timing, 🔬 the scripts' cost shows, for every kind of event the scripts answer, how long it takes in each language: the whole event (from the game's call to the last command carried out), and for Hazel and Fumola the rule alone. It also shows each language's set-up time. A frame is 16.7 ms; a rule that takes longer than that can make the game stutter.

10BEHIND THE SCENES: GAME EVENTS

Scripts answer only some of what happens in the game. Every way of moving, every arrow, door, pit and ladder, ends in one place in the game's code, enterScene. It tries a passage, a world way, a rope bridge, a ladder, then asks the scripts (scriptGo), and otherwise takes the door's own destination, fixed when the scene was drawn. Here is every kind of game event, what the game reads to decide what happens next, and whether a script decides it today.

Moving: 4 of 16 kinds go through a script

Doing: 4 of 9 kinds go through a script

11BEHIND THE SCENES: THE GAME'S STATE

The game keeps everything it knows in one object, state: 23 parts, about 82 KB written out as JSON (a long-played save). A script sees a small slice of it, Globals: 17 fields, the slice its room needs, built fresh for each call.

The game's state

The background is the world itself: 1,994 settings in 186 families, most of them per castle room (castleHall 390, castlePit 201, castleCat 192, castleThrone 180, castleRoom 79, castleLever 79, castleBoulder 79, castleBones 78, castleHorse 60, castleOut 39, castleFar 39, castleBack 39, …). world is the map: 31 squares, each with its kind (one of 40), its ways, and its things (of 44 kinds); the castles have 12 kinds of room. The rest is the friend (face, body, clothes, costume), the scripts themselves, and the player's settings.

What a script sees: Globals

12QUICK REFERENCE: EVERY FEATURE

The full feature set of the 📜 Scripting panel, and where each feature stands: 20 done, 7 done but not yet seen by Matthew, 3 on a branch, 3 not yet built. This table is kept up to date as the work goes on.

13ABOUT THIS GUIDE

Every picture is of Messed Up Dress Up 0.0.419, as released, and every quoted entry and message comes from the same run of tools/checks/manual593.mjs (kids-choice-games) on GitHub's computers: branch diag-593, the game at 8aadf44, run 40101004886, dark mode, 1440 × 900. The check sets each scene up, breaks the rules on purpose, and takes the picture; nothing was retouched. drivers/build.py draws this page from data/texts.json and data/features.json.

Related: Hazel reports, where the scripts' speed and the three-way checks are measured; hazelgrove/hazel #2711 (Hazel as a JS library); Adapton/fumola.