The Evolution of Sporting Balance: A Journey Towards Mastery

Section I: The Battletest system

I am Breno Azevedo, and I have been professionally engaged in competitive game balancing and design since 2006. This is the first installment of a three-part series on combat-focused game balancing, tracing its development and presenting successful case studies to demonstrate key concepts and solutions.

As revenues from multiplayer gaming continue to surge, recent research reveals that 47% of studios struggle to analyze and respond to the overwhelming volume of player feedback. In mobile games, nearly half of in-app purchases consist of currencies that are deeply embedded in both the in-game economy and core gameplay. This brings up a crucial question: how can developers effectively manage these increasingly complex multiplayer ecosystems to deliver the best possible player experience? Let’s illuminate this topic, often regarded as either esoteric knowledge for the initiated or the result of years of trial-and-error — a phenomenon we have observed even in well-funded triple-A titles.

Prior to 2010, while I was a freelance Game Balance Model designer for EA Los Angeles’ RTS (real-time strategy) games division, I had the opportunity to spearhead balance patch development for several of their most recognizable titles, including Lord of the Rings: Battle for Middle-earth I & II, as well as during the pre-production of Command and Conquer 3 and 4. These were exhilarating times, when I introduced what I called the ‘Battletest system’. The system operates in two phases, focusing first on collecting feedback from controlled tests involving top players across the game’s various factions. Then the balance designer merges statistical analysis with a pragmatic ‘gut feeling’ to swiftly iterate patches and finely tune these intricate games to a satisfying state of perceived balance.

How it all began

I started my work on Battle for Middle-earth (BfME1) patch 1.03 as a collaborator, without guarantees that it would ever see an official release. EA’s stringent review and approval process made patching costly — approximately $50k per patch. Not a trivial investment for a game that had already launched, especially with another title in development, consuming its own resources. There were also concerns within the studio that leaning too heavily on top players’ feedback could lead to a gameplay style that might alienate lower-skilled players, who formed the foundation of the player pyramid. I contended that top players were the ones being observed, setting trends and genuinely enhancing the optimal strategies, which would naturally filter down to the broader player base over time.

On gamereplays.org and other public forums, top players began openly praising and promoting the personal “battletest” modified versions they had been testing in organized sessions, which were later released publicly as mods. To our team’s surprise, EA embraced the project and decided to turn it into an official patch — something unprecedented at that time. After a month of intense back-and-forth with their internal and external QA teams, BfME patch 1.03 was officially released on February 25, 2006, to widespread acclaim. As anticipated, the solutions proposed by the top players throughout the patch’s development took months for the average player to grasp, leading to an unusually protracted period of balance maintenance. And let’s be honest — high-skill players tend to be the most vocal and influential in the community, and for good reason. When they commend a game’s balance, it’s hard to dispute.

The second step is not always simpler

Next came Battle for Middle-earth II (BfME2), which presented a significant design challenge in terms of balance. With its six distinct factions and over 1,600 unique data entries, manually balancing the game was nearly impossible. To stay on schedule and within budget, I developed a truly innovative tool — the Battle Stats Reference (BSR) automated spreadsheet. Keep in mind, this was during a time when Excel was dominant, and there were no cloud-based solutions. Therefore, I taught myself VBA (Visual Basic for Applications) and, in just two months, completed version two of BSR right in time for the actual battletest sessions. While opening the spreadsheet on a modern (2021) version of Excel “kinda works,” some features — like the classic floating control bar — don’t function correctly. However, you can view a screenshot of it in its original iconic form below:

BSR managed the various “ini” data files utilized by EA’s proprietary SAGE engine via separate, cross-referenced sheets. It could seamlessly import and export game data to and from these sheets without disrupting internal data connections. This functionality facilitated rapid comparison and bulk adjustments of game parameters, leading to a tenfold increase in productivity.

Finding efficiency is not very efficient

Merely enhancing and inputting numbers into the game wasn’t sufficient to arrive at an initial raw-balanced version. I required a reliable (guess what?) system. My approach involved conducting a series of synthetic tests with two networked machines, each using different sets of units with roughly the same total cost, pitting them against each other. I also defined a “base” or reference unit for each category, such as the Rohan Rohirrim for cavalry and the Elven Lorien Archer for ranged units. By balancing these key units against each other, I was able to extend the implications to other units within the same category, given they were “internally balanced.” Internal balance occurs among different units within the same class and requires a separate subsequent balancing effort. The primary difficulty lay in crafting an “efficiency” system to distill a unit’s battlefield effectiveness down to a single figure. Not only is there no contemporary method for this rather subjective parameter, but RTS games also include a wide range of classes from swordsmen to pikemen and heroes, each with numerous attributes. Lastly, factors like build time, movement speed, and weapon range all carry different weights for effectiveness, depending on the game’s economy, map scale, and pace. Ultimately, as with most complex systems, the key was to discern