From a Prototype to a Product – The Difficult Task of Applying Structure

How do developers tackle tech debt, raise technical standards and implement new features to a live game? Our Client Tech Lead Alexander Häußler walks us through the process of introducing structure to a game that has found success – without alerting millions of players to the ongoing construction work.

Introducing the Live Prototype

A very common situation for a game developer is to join a project while it is already running at full speed and has reached early, if not sustained success. The moments when we’re developing something from the ground up with no live audience are actually very rare. After all, it’s the game’s growth that enables companies to bring in more developers.

When a game is developed it often starts with a simple prototype. Depending on the team composition, it might be that a high technical standard is not possible or requires too much effort. The idea has to be tested quickly and a timely release is what matters most. Making the game future proof and ready for scaling is not needed for the prototype.

When a game then finds success and grows, it is not easy to justify a stop to start rewriting the game with better standards in mind. Alas, the live prototype is born. It is a working version of the game that looks polished, but is held together with quick solutions under the hood. The live prototype works, grows and makes implementing new features possible. There are no immediate blockers. It is a frog in the famous pot of water that is slowly heated up on a stove.

The Benefits of Gradual Transformation

While the water is heating up, the classic concerns arise: Do we have to rewrite the game? How much does that cost? How long can we keep going like this? Often it’s clear that the necessary change should have been done yesterday. The more realistic and relevant question becomes: How can we transform this prototype into something sustainable and maintainable for many years to come?

The transformation has to be gradual: the game has to be playable at all times, and players should not notice the construction work. While this can feel like an overwhelming task, the gradual nature of the transformation can also be a blessing in disguise. We are not forced to make one big-boom change and hope it all works out. Instead, we can slowly test the waters and apply one change after another, gathering data and feedback along the way to guide us. Splitting our work into smaller, isolated projects is a great and sustainable strategy.

A Clear Plan to Identify Dependencies

Before making the first changes, we start off by making a solid plan. We map out the whole project, aiming to identify dependencies between each area and find areas that are separate from each other already. For example, in Merge Mansion we have a user interface system, an audio system, and the rendering of the different locations inside and outside Grandma's Mansion. All of these come with different challenges and problems to solve, but we can approach them individually. How we play a sound effect has nothing to do with how we render a popup for the player. This is of course a simplification, but the idea holds up.

We then categorize the different parts of the project and estimate how easy it is to change them. With this preparation, we gain a better idea of which steps are more crucial than others. This allows us to evaluate each part of the plan in isolation and makes it easier to put concrete steps on a planning calendar.

A Controlled Approach to Managing Warnings

When working on a live game with millions of daily players, stability is a major concern. That’s why we start by validating assets and slowly increase the pressure to reduce warnings. Regardless of this, depending on the extent of the live prototype, a project might face thousands of warnings. This is a challenge, as new warnings can easily get added to the pile without anyone noticing.

One strategy to control the chaos can be to categorize all warnings by type or by location and aim to resolve these by category. The idea here is to create small actionable chunks of work, instead of creating a single massive task that is called "Remove all warnings." Such massive tasks rarely get completed and the sense of progression and success is missing.

By delivering clean-up work in smaller chunks, progress can be seen sooner and parts of the project can reach a higher standard already while other parts remain "dirty."

This relates to the 80/20 rule where doing 80% of a task takes 20% of the effort, and the last 20% takes 80% of the effort. Dividing tasks into smaller areas of work allows for the changes to affect the project sooner, so there is no waiting until 100% of tasks are done.

Keep Calm and Carry on Iterating

It’s clear that applying structure to and elevating the technical standards of a live game is not a quick task: it takes persistence, patience, and the ability to plan and compartmentalize. As the prototype evolves and complexity builds up, slowly apply counter measures and introduce stricter rules over time. Gradually increase the standard and allow some areas to stay behind. Recognize that trade-offs are part of the process, and find ways to work through it in an organized manner.

To come back to our metaphorical frog in the water: don't panic when the water starts to get hot and pop your hand in boiling water to try and save the frog. Maybe it is not possible to turn off the stove or build a proper regulated hot tub for it, but you can add some cold water, throw in some ice cubes, or serve some gelato to help the little guy withstand the heat. If you stay focused and work with an iterative approach, at some point the frog will be out of the heat and instead, sitting back in a comfortably heated hot spring.

Alexander Häußler is the Client Tech Lead for Merge Mansion. With over 17 years of experience as a programmer and lead in the games industry, he brings strong expertise in technology, management and overall game development.