Level Designer.

My approach to creating levels

I started in a greybox, experimenting with the mechanics until I found an interaction worth building a level around. Then I designed the path into it: the buildup that puts the player in the right situation, so the level is a full experience and not just the gimmick. If a level didn't work at this stage, I asked a colleague for a different perspective, and if that didn't solve it, I parked the problem and came back when the right idea showed up. Once a level held up, I playtested it: watching what the player noticed first and whether their first thought matched what I wanted them to think in that situation.

Puree, fries, wedges

The game is built in sections of nine levels, and each section introduces one new animal. Every level in that section has to use it, so my work was finding enough interactions to keep one mechanic interesting nine times in a row: reusing gimmicks the player already knows in new roles, and raising the difficulty by combining more mechanics as the section goes on. Later in the game those animals come back and interact with each other, which keeps opening new combinations.

Aiming a shot. The goal is always to use as few shots and droplets as possible.

Two of my levels using a double corner into the end hole, each with different animals interacting.

Who needs a tutorial?

I had one hard rule: the player proves they understand a mechanic before any level builds on it. Whenever a level asks for a trick, the player has already done that trick in a simpler situation, so nobody fails because they were never taught. On top of that, I never used the same setup twice, so familiar pieces keep showing up in unfamiliar ways across all levels.

The same level rebuilt with different pieces. The core of the gameplay stays the same, so the player understands it right away because it feels familiar.

My design approach

When designing a level on paper, I worked from four angles:

1. Combinations of mechanics I hadn't used yet.
2. New ways to reuse existing gimmicks.
3. Level ideas suggested by colleagues, polished to make their ideas shine.
4. New ways for the player to interact with a mechanic, and how to teach them.

Production planning

I started with little more than a theme and a genre. I designed how the setting works, built the gameplay loop around escalating waves, picked the asset packs that fit the tone, and wrote down exactly what we needed from each person on the team.

Creating a vertical slice

I scoped the game as a minimal viable version plus a stretch list: every asset, animation and sound effect needed for the minimal game was written down first, and the extras queued behind them. That gave us the final look of the game early, with time left to polish, instead of missing assets at the deadline. The maps show how it worked: the minimal version had one map we would recolor if time ran out; we stayed on schedule, so the game shipped with four distinct maps. The trade-off was real: some complexity I wanted never made it in, and I cut it consciously to protect the ship date.

Two runs: carving through early waves, and holding out at level 69, surrounded on all sides.

My approach for balancing

I balanced the game by playing it and by watching others play. I tracked what level players reached at each minute of a run and tuned the difficulty curve around that. Weapons that underperformed got buffed, dominant ones got pulled back, and waves that shut down one playstyle were adjusted until every build stayed viable. Survivorlikes are my genre and this game was my idea, so it was much easier for me to understand what it needed to feel like in such a short time.

The progression I balanced: level-up choices during a run, and permanent upgrades between runs.

My role on the project

I had full creative freedom over the levels and everything inside them, and it was on me to keep them within scope. I designed and built all 15 missions without extending development time, on a five-person team that shipped the game in a year and a half. I worked closely with our programmer and the art team, and I kept the design documentation up to date so it always matched the actual state of the game. Anyone who needed to work around a mission could understand exactly how it plays from the docs alone, without playing it and without asking me. That transparency saved the team real time.

Mission variety

My goal was to give every room of the house its own mission. Players fly through some rooms more than once, but the core of a mission is always fresh in a new room. I also kept the missions diverse while reusing the same mechanics: the bombing mechanic, for example, returns as delivering construction materials for a road renovation.

Left: the road renovation mission, dropping the right construction materials for the workers. Right: an escape from a wall of cardboard boxes flooding the corridor.

My pipeline when creating missions

Every mission started as a flowchart: what happens after what. I expanded each step until I could see it working, both mechanically and in the player's logic. Planning this way caught problems before they cost anything: when a step made sense gameplay-wise but wasn't what a player would logically do in that situation, the flowchart exposed it before I built anything. From there I built the mission in Unity on our programmer's custom mission scripts, balanced it and polished it.

"So the pink square is the axe, and the blue one is the wood"

Every minigame reached me as a paper design and a minimal 2D prototype, often literally two squares interacting. I turned that into a 3D level that looks good, fits the game's theme, and stays easy to follow with four players on screen. My readability bar was simple: the game has to be understandable from a single screenshot. Part of the audience was children, so anything that needed explaining was too complex. The wood-chopping minigame below shows the full journey.

01 / My first blockout

I started by replacing the chopped square with a log and the axe square with an axe to make the chopping readable, set up four arenas, one per player, and dropped in rough background trees to mark where the forest would go.

02 / My scene, before art polish

After experimenting, I merged the four arenas into one shared campfire scene with players side by side, and reworked the camera. I wanted players to see each other while playing, which made the game easier to follow and more fun.

03 / Final shipped version

The finished scene after art polish, with my final camera adjustments so it reads better.

A repeatable pipeline

Almost every minigame followed the same flow: a short description from the designer, a 2D prototype from the programmer, then my pass. I replaced the prototype shapes with real objects, built the scene and its setting, set up the camera, and kept iterating on the layout until the minigame played well and read clearly. When the first idea didn't hold up, I experimented until it did, like merging the four chopping arenas into one shared scene.

Creating the tiles

The game runs on tiles with different functions: regular road, bridges, and special shapes that change the gameplay. Whatever their function, all of them have to fit each other. My rules were simple: one shared ground texture across all tiles, variety placed inside a tile rather than on its edges, and the left side of each tile composed differently from the right. With that, a bridge tile connects to a regular tile as naturally as to another bridge, assets stay evenly spread, and no clumps form.

Two of the environments I assembled: a seaside town and a desert highway.

First time with sound design

This was my first time owning sound design. I selected the effects, adjusted them until they sounded consistent with each other and with the game's tone, and put them into the game.

The synergy core

Every card has a faction, a class and a damage type. Fielding enough cards of one faction activates a synergy that buffs the whole team, and enemies carry resistances, so damage types have to match too. The player's real task sits on top of all three layers at once: assembling the strongest possible team from what the run offers, and pushing further with it.

Left: the fight phase against a boss. Right: the preparation phase, where you assemble the team around synergies.

Designed around the preparation phase

I focused the game on the preparation phase, the way Backpack Battles does: the player has unlimited time to think. The depth comes from activating many synergies at once and matching exactly what the situation needs, but the system stays simple enough that beginner players read it quickly.

Balancing against the broken build

My hardest problem was boss scaling in the early game. When a player discovered something overpowered, they could push very far without ever changing their team; when a player missed the mechanics, they hit a wall. I solved it inside the enemies: their abilities now counter specific playstyles, so even a very strong build loses to some encounters and has to adapt.

Sisyphus

The game is mechanically complete and fully playable. Right now I'm polishing the parts I'm not naturally strongest at: graphics, animations, sound effects and quality of life. I run playtest sessions a few times a week, about an hour per player. I watch, take notes, and fix everything that isn't perfectly smooth, even when nobody complains about it: button positions, filter and panel placement, card layout. When I run out of improvements, I bring in a new tester and the cycle repeats.

Why I build my own level editors

Instead of writing levels as text, I built an editor for each game that runs in the browser. I draw a level with the mouse, the editor uses the game's own code, and the open game reloads by itself when I save. That way I see problems while I build, instead of play-testing every idea by hand.

Cog and Balls editor

The editor has 12 tools: three wheels, start, goal, spikes, gates, lava, switch, off cogs, portals and an eraser. A live preview next to the grid lets me play the level as I build it. Every level is checked automatically in the background:

• Solvable with only the moves a real player can make, with the shortest solution written out turn by turn.
• No dead ends: no position the player can reach makes the level impossible.
• Needs more than one wheel, and a warning when most cogs do nothing.
• A difficulty score, so I can order the levels from easy to hard.

A generator invents extra levels and keeps only the fair ones, and a pacing check makes sure a hard level is followed by an easy one. I pick and order the final levels myself.

The Cog and Balls editor: level 109 open, every check passed, and the live preview on the right.

Lootseum editor

Here I draw walls and floors, the start, three gems, hiding spots, guard patrol routes, lasers, wall panels, cameras, and 68 kinds of furniture and wall decorations. One key tests the level inside the editor. A live list of problems catches mistakes while I build: a missing start, guard waypoints inside walls, lasers that pass through walls, or lasers with no panel to switch them off. Saving keeps the last 30 backups.

The Lootseum editor: the Paris level with guard routes, lasers and furniture.

Small games I made

Borzoi Adventures: a platformer with 20+ levels

Voxel Panic: a Doom-style FPS

Aero Cosmos: flying a plane through space, collecting orbs and dodging floating rocks

Operation Hostage Rescue: a Hotline Miami style top-down shooter

Astro Rangers: a robot fighting through spaceship rooms full of evil robots

Pirate Havoc: a shooting-range style FPS, traveling between pirate fights

Robo Hop: a 2.5D platformer with 12 levels

Code Blue: a top-down shooter set in a hospital

A track game where you ride everyday objects, 12 levels

A 2D top-down racing game, 12 tracks based on real circuits

A tile-built minigolf with 50 levels

A motocross racing game with tracks inspired by real ones

A 3D top-down racing game, this time with monster trucks

A top-down alien shooter with different weapons, 12 levels

A 2D racing game where bike flips score points

Game jam: Say My Name

A 24-hour jam game made by a team of four: you slay demons by speaking their names into the microphone. I did the game design and the level design. It was also my first close look at a professional AI-assisted coding pipeline, watching our programmers work with Claude Code, and I've been using that approach in my own projects since.

You travel through the level, encounter demons like this one, and defeat them by speaking their names out loud.

Game jam: Call Me Maybe

A point-and-click dating sim made in 48 hours by a team of three: impress Sabina, the bartender, by clicking the right things during dialogue. I wrote the script and the dialogues, designed the game, and designed how the interactive moments work.

Sabina behind the bar, and one of the click-to-fill dialogue interactions.