Devlog: Balancing Solstride

To understand Game Balancing, we need to first go over some game design basics, such as the core principles of game design and balancing. Game Design is much about the idea of risk and reward, something you can identify in almost any game. Take Space Invaders for example: Steam post image

In Space Invaders you control a space ship and need to defeat the aliens, which approach you systemically. You can hide behind those barracks to hide from the enemies and their attacks , and you are in a “No Risk/No Reward” State. But as soon as you decide to get out of that comfort zone, you enter a “High Risk/ High Reward” Situation, because you can now attack the foes yourself, but are now in a vulnerable state, as you are not shielded anymore. It’s a really simple, yet effective balance of a 50/50 setup, because it rewards you for being courageous to be in a vulnerable state, yet punishes you for coming out of the No Risk Zone at the wrong time.

[carousel]

[/carousel]

You notice, I’m throwing words out like reward and punishment. Each game has to define those terms and qualities for themselves. For Solstride we wanted to have clear trade-offs, interesting decisions and a readable difficulty curve for the player. The core principles that we used as reference are the aforementioned Risk/Reward, a Flow State, Fun over equality and Trade-offs, instead of optimalism. To compare and measure balancing, the game design team set up a structured documentation system to log each run in Solstride with consistent parameters, such as resources, rooms visited, objects, abilities, enemy types and a few more. This approach helps to keep quantitative data and qualitative observations clearly distinct, but connected at the same time.

Steam post imageSteam post image

That way we could identify issues, such as combat encounters being too punishing, enemies being scaled too aggressively compared to player options at that point in time, consumables being OP and so on and so forth. Some systems raised design questions, rather than balance problems, which indicated missing design clarity that would only be addressed by labbing the game the way we did. After we run test-runs, we use all the observations and data to make targeted adjustments and validate them through follow-up runs. That way we can truly test, if our adjustments apply to the game in real-time. We loop this procedure for every run, to see if the game is fun or overwhelming, what type of problems could players encounter to the point that trade-offs aren’t even trade-offs but simply submission. We hope you enjoyed our little excursion to Game Design and we thank you for reading this! A little homework until next time: Where is the risk/reward dilemma in your favorite game? How do you think it’s handled in the game, what would you change?