My aim with this game was to create a simple platformer with unique and innovative gameplay. That’s why I chose to create “Nuts & Bolty”, a game in which it isn’t power-ups that allow you to overcome obstacles or defeat enemies, but a turret and companion that you can physically place within the world, acting as a spring, weapon or weight to trigger pressure plates.
I also tried to breathe life and personality into the turret so that I could form a personal bond with it and see it as a companion, not just a tool.
The project followed a full industry development pipeline from ideation through vertical slice, with a deliberate focus on player testing at every stage.
As Solo Developer, I owned every aspect of the game:
Development followed a structured three-phase pipeline.
In ideation, I generated concepts using SCAMPER, defined design goals to filter ideas against, evaluated scope, and pitched multiple directions to stakeholders before selecting the strongest.
The prototype phase focused on building all core systems in C#: player movement, turret placement and behavior, enemy interactions, and mechanisms. I built a test level that incorporated every functionality, then ran playtesting rounds to collect feedback. This first level was designed for functionality testing rather than gameplay testing, which meant the feedback I got was useful for systems validation but less useful for pacing and difficulty. (Image 1)
For the vertical slice, I designed puzzle levels from scratch with a clear progression philosophy: each level introduces one new way to use Bolty or increases the complexity of a previous interaction. One level teaches placement. The next teaches bouncing. The next combines them. This gradual introduction meant players could learn by doing, the level design itself is the tutorial.
The companion-as-tool mechanic created more emergent puzzle solutions than I anticipated. Playtesters found approaches I hadn't designed for, which confirmed that the core mechanic had genuine depth rather than being a one-trick gimmick.
Running structured playtesting rounds and documenting feedback formally, especially as a solo developer, kept the project grounded in player experience rather than my own assumptions. The feedback became a decision-making tool I referred back to throughout development.
The prototype level should have been designed for gameplay testing from the start, not just functionality validation. I lost a testing cycle learning that distinction, which cost time in a project with a tight timeline.
I'd invest in a more complete visual language for the puzzle elements earlier. Some playtesters didn't immediately read which objects Bolty could interact with, which is a level design clarity problem that better visual signposting would have solved.
Design documentation, pitch decks, and reference materials from this project.