MM-MOW

A small job with room for a bigger world

MM-MOW starts with an ordinary action: cutting grass. The design challenge is making that action support satisfying choices about tools, capacity, maintenance, and progression.

The larger concept imagines a shared countryside built around that work. The Unreal Engine vertical slice starts at a smaller, testable scale: one player, a field, equipment, and a Barn service loop. It gives the broader idea a gameplay foundation before adding the demands of an MMO.

Building the reason to return to the field

The loop connects mowing to a series of visible consequences. Cutting grass produces clippings. Clippings can be collected and carried to the Barn hopper for cash. That cash pays for equipment repairs and progression, which sends the player back out to work.

Capacity and condition give the trip a rhythm. Carrying too much slows movement. Machines have their own durability. Bag progression eventually unlocks mower collection, changing how the player handles the material left behind.

The goal is for each system to earn its place in the loop. A bag matters because it changes how long a run can last. A repair station matters because equipment wears down. A payout matters because there is something useful to spend it on.

Tools with different behavior

The tools differ in input and coverage. The scythe uses deliberate taps and a level-dependent number of cuts within its target area. The weed whacker supports held cutting over a small footprint. Push and gas mowers cover larger areas.

Each tool keeps its own condition when the player switches equipment. That became an important implementation detail: switching tools should reveal the state of the selected machine, not refill it or inherit another machine’s wear. The permanent scythe does not consume durability, keeping a basic cutting option available.

Grass is represented as logical cells within chunks, so a mowing action can change a bounded patch of the field. That makes tool coverage explicit and gives progression something concrete to operate on.

Making the loop explain itself

My work on the project combines gameplay design, system decomposition, and hands-on Unreal iteration with AI-assisted C++ development. Small implementation slices let me test the feel of a tool or a service interaction before widening the scope.

Feedback proved to be part of the system design. A failed action needs to communicate its cause; a silent failure leaves the player guessing whether they are too far away, out of capacity, or using worn equipment. Player-facing status popups and a separate developer HUD help distinguish those cases during iteration.

The debugging process also reinforced a practical lesson: successful compilation is only part of validation. Input mappings, placed Blueprint settings, and the actual in-editor play session determine what the player experiences.

Current scope and next steps

The documented slice connects mowing, loose-clipping pickups, hopper payouts, separate tool durability, bag progression, and repair/upgrade stations. The slice focuses on gameplay systems, with a functional interface supporting iteration.

Tool ownership and unlock rules still need work, and most tool upgrades do not yet affect all their intended performance characteristics. Server authority checks and replication foundations exist, but complete multiplayer request handling and multi-client validation remain ahead. Session persistence and the larger shared-world systems are also outside the current slice.

MM-MOW demonstrates how I turn a broad game idea into interacting systems, then use a small playable loop to expose the decisions that matter next.