Balancing an Unbalancable Game - Part 2

Feeling the Heat

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.

The Origins of 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.

How It Worked

Below is an example of the system in action. You can see the red numbers representing the heat generated by a node upon execution, and blue numbers showing the cooling effect (heat reduction).

While the idea seemed reasonable at first, it quickly became clear that this system had significant drawbacks.

The Problems

1. Difficulty Understanding the System Many players struggled to understand how the heat system worked. For instance, some assumed that if the numbers in their code resulted in a positive heat balance, they wouldn't overheat. However, that wasn't how it worked. Since each node’s execution generated heat, nodes that were executed multiple times in a single tick could easily generate more heat than expected. Explaining this mechanic proved challenging, especially for new players.
2. The System Killed Creative Growth The heat system was designed to counteract exponential execution growth, but this also meant it heavily discouraged players from writing code that could escalate exponentially. As I mentioned in Part 1, that exponential growth is one of the most enjoyable aspects of the game.

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 Frustrating Player Experience

A common scenario would go something like this:

• A player has an exciting idea: "I’ll connect these nodes, add a loop, and watch this escalate quickly!"
• The result: "Oh no, I overheated."

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.

The Decision to Let It Go

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:

• It was difficult for beginners to understand.
• It often blocked players from executing their plans in frustrating and confusing ways.

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!