Honey, I Shrunk Myself

Kenney Jam's theme was Scale, using only Kenney and KayKit asset packs. I built a first-person puzzle game around a single interaction: click an object to scale it up or down, and use that change in size to solve your way through a room. No combat, no inventory, no dialogue tree — just one verb, applied to everything the raycast could hit, built and shipped in a weekend.

A one-verb game lives or dies on whether that verb feels good to use everywhere, not just in the one puzzle it was designed for. Scaling a crate to climb on top of it is obvious. Scaling a crate down so it fits through a gap, or scaling it up so it wedges a door open, only works if the underlying interaction doesn't care what kind of object it's touching. That meant building the scale interaction once, generically, rather than special-casing it per puzzle.

The player moves through a first-person environment solving spatial puzzles by scaling objects up or down and dragging them into position — shrinking something to fit through a gap, growing something to reach a ledge, or repositioning a scaled object to bridge a gap entirely.

• Click-based object scaling via raycast from the player's camera — any object tagged as scalable responds to the same interaction, with no per-object special-casing.
• Raycast-drag repositioning sharing the same input model as scaling, so the player has one consistent way to manipulate anything in the world rather than separate controls per mechanic.
• Puzzle rooms built entirely from Kenney and KayKit asset packs, constraining level design to what those kits actually provided rather than custom art — a real jam constraint, not a self-imposed one.

Both interactions — scale and drag — fire from the same camera raycast, differing only in what they do with the hit result. That shared foundation is what made it possible to build two distinct mechanics inside a single weekend: one raycast, one hit-detection path, two different responses depending on which interaction the player triggered.

PlayerInteraction (MonoBehaviour)
    → fires raycast from camera on interact input
    → on hit: routes to Scale() or Drag() depending on input mode
    → Scale() reads/writes hit object's transform.localScale directly
    → Drag() repositions hit object along the raycast while held

Drag has no bounds clamping. An object being dragged can be pulled straight through walls and geometry, because the drag system repositions along the raycast without checking whether that position is actually valid space. It didn't break the jam build because the puzzle rooms were small and forgiving, but it's a real gap — not a stylistic choice — and it's the first thing on the list before this system gets reused anywhere else.

Scale had no min/max clamp either. Nothing stopped a determined player from scaling an object down to zero or up past the room's geometry. For a weekend jam that's a shrug; for anything built to last, it's an obvious next fix.

Why It Matters

This is the project that proved the core interaction was worth building on. The shared raycast-scale-drag foundation from this weekend became the base I returned to when scoping a local two-player expansion — asymmetric co-op puzzles where one player scales and the other moves faster, sharing a split-screen environment neither can solve alone. The bounds-clamping fix flagged here is a direct prerequisite on that expansion's backlog.