Solo Unity 6 case study · August 2026

Platformer Ultra

A factory platformer built like a factory: generated, connected, and repaired under pressure.

A roughly 48-hour build became a focused exercise in system design. One vertical hall connects movement, production, machine damage, enemy traversal, and escape—then makes the player maintain that whole chain without a weapon.

I directed the design, Unity engineering, visual language, testing, and scope. Codex and Unity MCP accelerated editor tooling and generated assets; I set the constraints, reviewed the output, playtested the result, and replaced what did not read or play clearly.

Enter the factory View GitHub

Platformer Ultra presentation artwork showing the purple Saboteur enemy in the factory beside large orange Corrupt Maintenace lettering — Presentation artwork from the project. The title embedded in the image is an experimental cover treatment; the verified project title is Platformer Ultra.

Role: Solo designer / developer
Constraint: Built around ~48 hours, then polished
Engine: Unity 6.3 · URP · C#
Target run: One hall · roughly 5–10 minutes

Mine · the brief

Restore the line. Reach the portal. Never become the weapon.

The strongest constraint was not time or height. It was making maintenance feel active while withholding direct combat.

A sabotage signal wakes a compact maintenance unit inside an autonomous factory. The factory is one interconnected room, so the final portal remains a visible promise while the player climbs through the systems needed to power it.

Movement and maintenance are the verbs: jump, double-jump, dash, cross conveyors and hover platforms, hold repairs under pressure, build defensive turrets, and keep machines running long enough to produce three portal cores.

Space: One readable vertical hall
Combat: No direct player attack
Goal: Restore production and escape
Scope cut: Breadth in favor of one complete route

Small orange, steel, and cyan maintenance robot standing between two factory service columns — The factory-built maintenance unit uses cyan for player energy and safety orange for service hardware. Its silhouette avoids implying a combat role.

Smelter · the playable loop

Five machines turn platforming into a dependency chain.

Mine → Smelter → Generator → Assembler → Portal is both the production model and the run's dramatic spine.

Visible cargo made the chain legible. Ore leaves the mine, becomes ingots, feeds powered assembly, and ends as portal components the player can see moving through the room.

The loop alternates progress and exposure. Activating a station opens the next route; keeping it alive forces the player back into older spaces while enemies attack the infrastructure below.

Activate

Wake the next machine and expose a new objective.

Connect

Complete the conveyor route and make cargo movement visible.

Produce

Turn ore into ingots, power, components, and portal cores.

Repair / defend

Hold a timed interaction or construct a turret while exposed.

Escape

Install three cores, stabilize the portal, and reach the top deck.

Maintenance creates the danger window

Enemies prefer operational machines and nearby players. Repairs and turret construction lock attention for a moment, so the non-combat protagonist still makes tactical choices about route, timing, and which failure matters first.

Generator · building the factory

The room was authored as a system, not a fragile pile of scene edits.

Reusable endpoints, deterministic builders, and scene-contract tests kept one dense vertical level editable at speed.

I began with a point-to-point conveyor and a movement/interaction test scene, then generated the full factory through editor builders. That made large structural passes repeatable: platforms, machines, routes, navigation surfaces, and objective wiring could be rebuilt together.

The level keeps the portal high and readable, places broad decks between meaningful jumps, and provides recovery routes when a jump fails. Later passes removed a forest of identical posts, introduced gantries and cantilevers, and converted selected decks into stable hover platforms.

Wide view of the complete vertical factory hall with the smelter on the left, stacked production decks on the right, conveyors, gantries, and the portal near the roof — The full hall keeps the active production layer and final portal in the same visual field. Broad decks provide orientation; narrow links carry the platforming risk.

See the destination

The portal anchors the climb before the player can reach it.

Fall forward

Lower decks and recovery paths reduce dead resets without erasing risk.

Generate repeatably

Builders preserve scene contracts while the room changes shape.

A curved conveyor turn carrying the factory route between stacked platforms beside an assembler arm — Reusable conveyor endpoints and turn modules let the production route bend around the platforming layout while cargo remains readable.

Assembler · pressure and visual pivot

Every replacement solved a readability problem.

The rapid build improved through deliberate swaps: navigation, characters, machines, and structure all changed when the first answer fought the game.

Transparent enemy roads made traversal possible but looked arbitrary. I replaced them with deployable enemy-only mechanical ladders and procedural jump links backed by NavMesh. Ground enemies now earn vertical access as production advances; drones retain flight.

Borrowed humanoids also contradicted the factory. They were replaced with project-built geometric characters and procedural animation tied to movement and combat state. The existing drone stayed because its silhouette already belonged in the space.

Target

Machines first

Enemies attack operational infrastructure and switch to nearby players when opportunity changes.

Exposure

Repairs take time

Holding a repair or turret build creates a readable window for interruption.

Escalation

Routes unlock with progress

Ladders, jumps, flying drones, and burst spawning expand pressure as the line comes online.

Factory-built threats

The Saboteur Cutter and Foundry Brute share the same chamfered housings, bearings, pistons, and restrained emissives as the machines around them.

Large purple Foundry Brute enemy with glowing orange vents and heavy mechanical arms standing on a factory deck — The Foundry Brute reads through mass: protected head, pressure core, piston limbs, crusher claw, and pile-driver hammer.

Tall narrow purple Saboteur Cutter enemy with an orange visor and long blade hands beside factory machinery — The Saboteur Cutter uses a narrow, forward-weighted silhouette, one orange eye slit, and asymmetric blade hands for threat before impact.

Machines communicate state before UI does

Mine, Smelter, Generator, Assembler, Crusher, and Portal were centralized and rebuilt with state-driven motion, emissives, particles, and synchronized audio while their gameplay footprints stayed fixed.

Purple smelter in a broken inactive state with its furnace opening dark red — Broken: stopped motion and a cold, damaged presentation signal the repair target.

Purple smelter beginning its repaired startup state with the same fixed gameplay footprint — Restart: synchronized movement and hot light confirm that production has resumed.

Portal · polish and outcome

Polish made the system explain itself.

The final passes focused on communication: what is broken, what matters next, what changed, and why this unit is here.

Contextual tutorials, an objective and broken-machine HUD, pause options, persistent mixer controls, and original mechanical movement/enemy SFX reduced the amount the player had to infer. A dedicated Timeline intro added the sabotage premise with processed robotic voiceover and subtitles.

The project was prepared for a Unity Web build and store presentation. No public itch.io page is verified, so this case study links only to the repository.

State feedback

Motion, particles, emissives, HUD status, and audio agree on machine health.

Player guidance

Tutorial prompts arrive in context instead of front-loading every control.

Audio continuity

Movement, enemies, machines, voice, and persistent mixer settings share one controlled mix.

26—29 / 08 / 2026

A fast build, then focused polish

Repository history runs from August 26–29, 2026, followed by presentation and publishing work. The accurate story is a project shaped around a 48-hour constraint—not a claim that every final feature landed inside that exact window.

Blue industrial drone flying beside a large octagonal portal and its three core sockets on the top factory deck — The retained drone and final portal share the upper deck: ongoing pressure beside the objective that ends the run.

RUN COMPLETE

What the build proved

A short game can still demonstrate systems depth when every mechanic reinforces one route. The useful outcome was not feature volume; it was the ability to replace weak solutions quickly without losing the playable spine.

Generated tooling is valuable when its contracts are explicit and repeatedly tested.
Gameplay readability should decide whether an asset, route, or effect survives—not the time already spent on it.
A hard scope works best when it defines a complete ending, not only a short schedule.

Inspect the repository Return to all projects