Alice-Alice

Problem

The original approach kept mass and jump height constant regardless of Alice's size, reasoning that consistent physics would be easier to design puzzles around. In practice, this made scaling feel bland and cosmetic, growing or shrinking changed how Alice looked without meaningfully changing how she played, and it directly limited the kinds of scaling-based platforming puzzles the team could design, since size had no mechanical consequence to build a puzzle around.

Decision

Reverse the original approach entirely, size directly affects both jump height and mass. A larger Alice jumps higher but is heavier (affecting how she interacts with scaled objects, platforms, or physics-based obstacles), while a smaller Alice jumps lower but is lighter. This gives every scaling decision real mechanical weight (literally), turning "should I grow or shrink here" into an actual strategic choice tied to platforming and physics, rather than a cosmetic toggle.

float HeightToVelocity() {
    return Mathf.Sqrt(2 * (1f * Mathf.Abs(transform.localScale.x))
        / Mathf.Abs(Physics2D.gravity.y)) * Mathf.Abs(Physics2D.gravity.y

float scaleMultiplier = Mathf.Abs(transform.localScale.x / playerScale.originalPlayerScale.x);
rb.velocity = new Vector2(horizontal * moveSpeed * scaleMultiplier, rb.velocity.y

Iteration

The team started with the opposite design, deliberately normalized physics regardless of scale, before recognizing it made the core mechanic feel unsatisfying and mechanically inert. Reversing course to let size affect jump height and mass came directly from playtesting revealing how flat the original version felt, and from recognizing it was actively limiting level design options.

Outcome

Scaling became a real platforming decision instead of a visual one, size now determines traversal options (how high you can jump, how you interact with weight-sensitive puzzle elements), which is what let the level design deep dive actually build puzzles around scaling rather than around a fixed, unchanging Alice.

Problem

With a huge combinatorial puzzle space already at stake, players also need a reliable way to know, at a glance, whether a given object can even be scaled. Without a clear visual signal, players would be reduced to guessing or trial-and-error just to find out what's interactive, undermining Discoverable Through Experimentation, since experimentation only works if players know where to actually experiment.

Decision

Every scalable inanimate object carries a heart-symbol tag marking it as scalable, and Alice's targeting raycast changes color, turning blue, when pointed at a valid scalable object, giving the player immediate, unambiguous feedback before committing to an action. Scalable animals (the Cheshire Cat, the flamingo) don't carry this tag; their scalability is instead taught implicitly through level design, early puzzle placement gives players enough context to learn these characters are interactable without an explicit marker.

public void UpdateColor(bool isSelectable) {
    if (isSelectable) SetColor(selectedStartColor, selectedEndColor);
    else SetColor(unselectedStartColor, unselectedEndColor

Iteration

The earliest version had no visual marker on scalable boxes at all, making it genuinely hard to tell what was interactable. The first fix was giving scalable objects contrasting-colored sprites to make them visually pop against the environment, but this proved insufficient once levels grew more complex and visually varied, a color that stood out in one environment blended into another. The team settled on the heart tag plus the color-changing raycast specifically because it's environment-independent, the signal doesn't rely on contrast against a background that keeps changing. The animal side of the problem never needed a dedicated fix, level design alone was enough to teach their interactivity clearly.

Outcome

Object scalability is now communicated reliably regardless of a level's visual theme, closing the exact gap where the original color-contrast approach broke down, while the animals demonstrate that not every interactive element needs an explicit UI marker if the level itself teaches the rule clearly enough.

Problem

Scaling has multiple independent variables, Alice's own size, static object size, moving objects, magnetic pairs, plus separate systems like buttons and hidden interactables. Introducing all of them at once, or in an arbitrary order, risks overwhelming the player and undermining Discoverable Through Experimentation.

Decision

The tutorial level introduces exactly one new concept per beat: first scaling Alice herself, then scaling other objects, then scalable animals, then interacting with buttons. From there, each subsequent area introduces exactly one further building block on top of what's already been taught: Area 1 reinforces the tutorial's basics while introducing that some objects are hidden behind glass and must be discovered as scalable. Area 2 introduces moving scalable objects. Area 3 introduces magnetic object pairs. The final level ties every mechanic together as a cumulative test, requiring the player to combine everything they've learned rather than teaching anything new.

Outcome

Each area has a clear, singular teaching purpose before the final level asks players to synthesize everything, giving the whole game a legible difficulty curve despite the underlying mechanic's combinatorial complexity.

With scaling introducing genuine complexity, the team debated how much guidance players actually needed. There was real concern early on that players might not grasp certain mechanics or puzzle logic without more explicit instruction, text prompts, tooltips, or hand-holding beyond the basics.

The team ultimately chose to trust the player rather than over-explain. Explicit tutorial content was kept confined to a single dedicated area teaching only the most basic controls. Beyond that, every new mechanic is introduced through a deliberately safe environment, low-stakes space where the player can experiment freely and build understanding before any puzzle actually requires them to apply it under pressure. The teaching happens through level layout and sequencing (per the previous Decision), not through UI or text.

Iteration

This came out of genuine internal debate rather than a settled plan from day one, the team weighed adding more explicit guidance against trusting the player, and chose the latter, backing that choice up by carefully engineering safe, low-risk spaces for every new mechanic to make the trust well-founded rather than reckless.

The game teaches almost entirely through space and sequencing rather than instruction, directly proving Discoverable Through Experimentation as a real practiced value rather than just a stated pillar, while the safe-experimentation-zones design pattern kept that trust from becoming a source of player confusion or frustration.