A personal design reflection outlining the philosophies and decision-making frameworks I developed while balancing Apeiron over the course of 35 patches. This serves as a record of my thought process for addressing player feedback, systemic balance, and design trade-offs. Each bullet represents a major lesson learned through experience.

• Clear alignment and communication between player base and game developers is key

  • Players need to be communicated to, so they understand, as clearly as we can explain, our decision making process

  • Having support from players on dev decisions, and people in the community supporting / genuinely understanding the dev perspective is invaluable

• That said, listening to players is important to understand the meta and sentiment, BUT:

  • Be weary of vocal minorities - make sure people are and feel heard, but take what they say with caution as they do not represent the majority of the player base

  • Keep in mind that players perspectives are most often shrouded in bias (intentionally or not)

  • Players often (not always) verbalize what they want for themselves, rather than what is best for the ecosystem - this leads to opinions and suggestions that disregard other major repercussions

• Timing of balance changes is important

  • This is specifically important in the context of competitive games, and games where money is involved (rewards on the leaderboard)

  • Make changes understanding the full ramifications of those changes

    1. Example: A skill is identified as unhealthy and unbalanced mid-season - the skill leads to a very frustrating player loop, with little (perceived) room for counterplay.

       1. What I chose to do was to nerf the skill’s duration, and also rework(arguably buff) counterplay options. I felt like this was the right decision, and all aspects of my understanding at the time stood by it, but I soon realized that making this balance change mid-season heavily impacted those players who depended on the skill.

       2. It’s easy to just say “Skill issue”, or “The skill was never balanced to start”, but the truth is that people invested time and money into learning how to optimize the skill. All of this with the goal of learning rewards at the end of the leaderboard. Now, the time and money they put in were gone to waste. This is a case where better QA was necessary to identify this skill as problematic early on. But nevertheless, those changes shouldn’t have been made in the on-season. They needed to happen after the season ended.

  • Changes should be avoided during major competitive aspects of the leaderboard/ladder, unless completely necessary to avoid impacting player ROI (return on investment, fiscal but also time)

• Understand root problems, and always aim to tackle them

  • What prompted this skill needing to be rebalanced

  • Are emotions at play? e.g. did you just lose a game to this skill

  • What part specifically about the skill feels like it needs to be rebalanced

  • How do the data points align with concerns

  • How is the general player sentiment about the skill

  • Is there a large dissonance between data points, and player sentiment?

• Focus on iteration

  • Being stuck on original design / intention makes iteration very difficult, and at the end of the day, player perception is king

  • Adaptive mindset in this ever-changing space is of the utmost importance

• Alignment across the balance team

  • Ensure that everyone relevant is on the same page, and that there is thorough discussion where necessary

• Play and understand the game you are balancing

  • This sounds incredibly obvious, but it needs to be said. Blind balancing without hands-on experience is never good, and it should be reserved for internal playtest balancing, if ever

• Goal: Make a fun game

  • Is enjoyment heavily gated?

  • Why do those who enjoy the game, enjoy the game?

  • Capitalize where possible

  • Is the target player base being satiated

  • Are personal biases overwhelming the ability to create a fun and enjoyable experience

• NOBODY is objectively correct in game design

  • There are many ways to get to an end result - there is often not one correct answer

  • Understand the various perspectives, and the problem that is trying to be solved, then compare and communicate

  • Keep things professional, and understand where others perspectives come from always

• Understand technical capabilities, and what balance changes are within the realm of feasibility

  • Be cautious of going down balance changes that are not feasible

  • Understand that it is often easier to build brand new ideas rather than build off of what currently exists

• Band-Aid solutions are meant to be step one, not the final step

  • Just because a problem has been fixed with a Band-Aid solution doesn’t mean it’s the final step, in fact, it should just be one step towards fixing the problem

• Argue with yourself on every change you are proposing

  • Put yourself in the position of the person you are trying to pitch this to (If you have enough exposure to that person to understand their thought process)

  • Ask yourself what they (and other individuals) would argue against the change you are pitching, and think it through thoroughly

• Shooting for “perfectly balanced data” is not the goal

  • Doing so will often lead to changes driven purely by numbers, when there are too many other factors in place not being accounted for

  • Player perception for balance is often first - a skill may have a 45% win rate, but seem OP to some players- dig in and understand why that’s the case, and why the skill’s win rate does not align with player perception - and is it an issue that needs to be solved