Posted December 15, 2024 by MaverickHorn
In this blog, I want to talk about a game system we implemented to better balance the gameplay—and why we ultimately decided to remove it: the heat system.
When Net.Attack() was just a game in my mind and I was experimenting with the first gameplay ideas, one thing quickly became apparent: balancing a game where players can code their own attacks would be incredibly challenging.
One of my first ideas to counteract the potentially overpowered nature of the system was something I called the Heat System. The concept was simple: every coding block would generate "heat" when executed. Heat would naturally reduce over time, but if executions generated too much heat, the player would overheat. An overheat would cancel all active code and freeze execution for five seconds. This forced players to optimize their code to avoid overheating. To balance this, we also included nodes that could reduce heat.
While the idea seemed reasonable at first, it quickly became clear that this system had significant drawbacks.
I realized that I wanted the players' code to work as intended as often as possible. The heat mechanic often got in the way of creating truly great, creative solutions.
A common scenario would go something like this:
This kind of experience was deeply unsatisfying. I wanted players to feel rewarded for their creativity, not punished by an obscure mechanic they didn’t fully understand.
In summary, the heat system did solve the problem it was designed for: it made the game more balanced and limited overpowered growth. But it came at a huge cost:
Ultimately, I decided to remove the heat system. Maybe it will rise again someday, but I honestly don’t think it will. The cost of restricting player creativity was simply too high.
Thank you for reading, and stay tuned for the next chapter in Balancing an Unbalancable Game!