I Wet My Plants

A creative reimagining of Breakout. A kodama — a forest spirit — controls the paddle and directs a ball around the screen. The ball absorbs water from puddles and rain clouds, and when it hits a tree or plant it waters them, turning their mood from angry to happy. Water everything to win.

The engineering problem

Breakout is trivial to build because its blocks have one bit of state: present, or gone. This game breaks that. Every plant is a small state machine with a mood you are improving rather than an obstacle you are destroying, and the ball carries a consumable resource that it spends on contact and refills from the environment.

That sounds like a cosmetic difference and it is not. The moment a block has state, three things follow: something has to own that state, the visual has to stay in step with it without becoming a second source of truth, and the win condition stops being a counter and becomes a query across every entity on the board. Get that modelling wrong at hour six of a jam and you spend hour thirty untangling it.

How I approached it

The water is a clamped float on the ball, not a boolean. That sounds like a detail and it is the whole design: a capacity that fills passing over water and drains into each plant it touches is what makes the board a resource-management problem rather than a sequence of hits. A boolean would have given us a game about touching things in the right order.

The win condition is event-driven, not polled. A manager tracks how many plants are fully watered, and each plant notifies it when its own status changes, rather than something scanning every plant every frame to ask. The plant owns its state and announces changes; the manager owns the count and nothing else.

That is a small decision with a large blast radius. Polling would have worked at this size and quietly stopped scaling, and — more to the point — it would have put knowledge of what "fully watered" means into two places instead of one.

What I'd bring to your project

This is domain modelling, and it is the most transferable thing I do. Fifteen years of designing entities and their relationships in production systems is exactly the skill that decides whether your game's data is a pleasure or a liability in month six, and it is the one self-taught teams have least often had a reason to develop.

If your project has a class that has quietly become the place everything lives, or a manager polling objects that could just tell it, that is the problem I have spent my career on.

Scope & role

Programming and production, on a team of seven. Unity. Submitted to Summer Slow Jams 2018 — one of my first game jams.