The stuff no one tells you about game development (Developing 7)

Game development is not only prototyping mechanics, designing levels, and releasing exciting demos. A large amount of the work is dry, practical, and easy to ignore from the outside.

Menus need to exist. Heads-up displays need to update. Save data needs to persist. Options need to sync across scenes. Controllers need to be supported. Progress needs to be tracked. Levels need transitions. None of that is glamorous, but someone has to build it.

For a small puzzle game prototype, this kind of work often arrives after the first playable version proves the core idea. The prototype may function, but it is usually held together by duplicated logic and scene-specific hacks. Turning it into a real game means separating those systems from the individual levels.

A character controller overhaul created several player-facing options: hold-to-aim versus toggle-to-aim, remappable keyboard and controller inputs, magnet color, accessibility symbols, and aiming sensitivity. Those options were easy enough inside a throwaway test level, but a full game needs them to survive across every level.

The solution was an options manager: an invisible object created on the title screen, tagged so it survives level loads, with scripts for tracking settings and saving or loading them from disk. When the title screen is replaced by a level, the manager remains in memory.

That lets any new level ask the options manager questions. The character can ask what aiming mode is active. The magnet can ask what color it should be. A panel can ask whether accessibility symbols should be shown.

The underlying lesson is to decouple meta-level game logic from moment-to-moment level design. In the earliest prototype, every level duplicated saving, loading, progress tracking, transitions, and even the pause menu. That made testing slow, cluttered the hierarchy, and made simple option changes tedious. Central managers make the project easier to reason about.

Once the options manager solved one problem, the same pattern could support the rest of the game. A transition manager can receive a level name, wipe away the current scene, and bring in the next one. A music manager can fade the soundtrack out and in during transitions. A HUD manager can draw tutorial prompts and context-sensitive button icons. A UI manager can own the pause menu and options menu.

These systems are not visually exciting, and their first versions may be ugly. The point is functionality. A rough menu that exists in one central place is already more useful than polished duplicated menus scattered across every level.

The more shared systems move out of individual scenes, the easier the game becomes to test, change, and extend.

The first prototype moved linearly from level one to level two to level three. That structure works for some puzzle games, but it can create a hard wall when a player gets stuck on one puzzle. Many puzzle games are more open: players can skip levels, solve puzzles out of order, and return later.

A non-linear structure needs progress tracking. In this prototype, each level contains a key. A progression manager stores a list of all keys in the game, checks them off when collected, and saves that data. A simple hub contains doors to individual puzzles and a final door that opens only after enough keys have been collected.

That threshold can be changed easily during balancing. If playtesters struggle with one puzzle but breeze through another, the hub and unlock requirements can be adjusted without rebuilding the whole game.

The level order was also made easy to change through file names. A level name such as "01 Lift 02" encodes both the hub it belongs to and the key found inside it. Other systems can read those characters, extract the relevant strings, and decide where the level belongs. Reordering levels becomes as simple as renaming files.

Iteration exposed another problem: building levels was frustrating. Changing one electromagnet might require resizing the area effector, resizing the beam visual, moving the particle system, reducing particle lifetime, changing particle colors, changing the beam color, changing the sprite color, changing layers, changing tags, and updating collider masks.

That is not creative level design. It is repetitive manual bookkeeping. The broader realization is that a commercial engine is a tool for making games in general, but it is not automatically a tool for making one specific game. The developer has to build the project-specific tools that make content creation fast.

For the electromagnet, a simple inspector slider can control height and automatically update every related variable. Buttons can switch the magnet between red and blue or on and off. If a change is a rote sequence of steps, a small script can often turn it into one button press.

The same idea applies elsewhere. A moving box can use editor gizmos to show its path. A dedicated prefab window can let designers drag mechanics into the scene quickly. The goal is to make common work visible, reliable, and repeatable.

Unity Events are powerful for puzzle games because an object can invoke an event and the editor can decide which scene object should respond. A button can trigger an electromagnetic panel, open a door, move a platform, or call almost any function on another object.

The annoyance is selection friction. If every event requires hunting through the hierarchy for the relevant object, wiring puzzles becomes slow. A simple scene-picking tool, similar to an eyedropper, can let the developer click an object directly and assign it to the event. That tiny editor convenience can be used constantly.

Tools like this do not make the game better by themselves. They make building the game faster and less error-prone, which means more time can be spent on puzzle quality instead of repetitive setup.

After building the tools, the obvious test is to make a puzzle. If the process is still annoying, fix the bottleneck and build another puzzle. Then build another. This is how systems work can quietly become content work.

A project can suddenly have shared managers, a hub structure, and several new levels simply because the tools made construction fast enough. That is the real payoff of early systems investment. The work is painful up front, but it can save enormous time and effort during the main stretch of development.

The efficiency is not only about speed. It also makes feedback easier to address. If players complained that the character felt bad, the visual language was inconsistent, the mix between platforming and puzzles was confusing, the puzzles lacked strong "aha" moments, levels were buggy, or the core magnet mechanic did not feel central enough, a cleaner toolchain makes iteration less punishing.

The unglamorous work of game development is easy to underestimate because it rarely looks exciting in isolation. But options, persistence, managers, progression, transitions, HUDs, and editor tools are what let a prototype become a game that can be expanded, tested, and revised.

A good tool or manager does not just solve one current annoyance. It changes how quickly future work can happen. The earlier a project removes repetitive friction, the more room it creates for the work players actually notice.