I've been meaning to provide some answer but the
wiki page @Masper linked actually says most of it. It reads like
Saktoth so was probably written ages ago and ported through multiple wikis.
Sprung's link is a pretty good example of the balancing strategy applied to superfluid. I've already written that, so guess I am being asked to go as meta as possible?
For the sake of structure I'll try boiling my answer down to three things:
-
Have principals/axioms/invariants but don't be afraid to reevaluate them.
-
Gather information and be aware of its quality.
-
Everything bottoms out at player experience.
Having a set of principals or invariants for Zero-K helps keep it from being a complete mess. These are things like:
-
"Buff strengths, nerf weaknesses" (Quant's Rule)
-
"Fight the opponent, not the UI"
-
"It doesn't matter who owns what"
-
"Territory is always important"
-
"No special damages"
-
"Remove as little jank as possible"
-
"Sea which was just land v2 would be a waste of space"
Only the first two exist as pithy phrases. The visibility and flexibility of these principals varies. We don't hear about "Territory is always important" because that was solved over a decade ago by overdrive. Similarly, "No special damages" and "It doesn't matter who owns what" are very unlikely to be reevaluated any time soon.
The principals are good for narrowing down answers to problems, or at least pointing towards what to try first. Working within them ensures consistency. Those with more of an invariant flavour, such as "It doesn't matter who owns what" and "Fight the opponent, not the UI", swiftly cull large swathes of design space. This is good because preexisting bits of the design depend on these invariants, so adding on something that violates the invariant would set us up for conflicts within the game later on.
Sometimes a principal is more for navigating design space rather than ruling out large parts, which makes the principal more flexible. Two examples are "Buff strengths, nerf weaknesses" and "Remove as little jank as possible". Sometimes it is time to think beyond such things, or to refine them into something deeper. Their utility is perhaps in delineating two modes of thought: working within the principals to climb towards a local optimum, and stepping outside them to find a new local optimum.
Information is important because you can't navigate design space without having a fairly good idea of your current position. I think games are better off being played by their devs. If a dev is reasonably good at a game, and there are plenty of people at a similar level, then balance arguments can be resolved by a lot of playtesting. This doesn't always work and doesn't really apply to teamgames or FFA. Luckily a bunch of ZK's principals make a lot of 1v1 balancing apply nearly automatically to other game modes, and the remaining lategame things are relatively easy to eyeball. I find
esainane's stats tool pretty useful for 1v1.
You can't see everything first-hand so feedback is a big source of information. I watch a lot of the games that people comment on and see what they're saying. Something to keep in mind is that the following things are not necessarily correlated from person to person:
-
How much feedback they give.
-
How good they are at analysing feedback.
People tend to attach suggestions to their feedback, but feedback can't be 'wrong' on the basis of a bad solution. Feedback and solutions exist independently, and right and wrong don't make any sense for feedback itself since it is always caused by something. To rephrase, if someone says "I feel X because Y" then there is no way for them to be wrong about feeling X, but whether that feeling stems from Y is something to investigate. I'm not sure why this occurs. Perhaps we feel that for a feeling to have weight it needs to be backed up by an identifiable chain of reasoning, as if the existence of the feeling isn't the proof of its own existence. In any case, this poses dangers on two fronts.
-
Implementing people's suggested fixes for their own feedback, as-is, skips important steps of gathering more information, mulling it over, testing, and discussing the underlying issues.
-
Not implementing suggestions or discussing other solutions runs the risk of appearing to dismiss the feedback associated with it.
This is particularly tricky in Zero-K because the line between player and developer is so blurred. Balance threads are often a mix of people wearing designer hats and people wearing player hats. We can't erect the standard commercial game wall between players and devs, keeping the feedback external and discussion internal, because that isn't how ZK works. Players contribute and turn into devs. So we end up with a lot of miscommunication where I try to discuss the feedback without first separating the validity of the feedback and the merit of various solutions. As a player this can look like the feedback itself is being dismissed.
I also try to counteract the squeaky wheel effect (although doing so perfectly is impossible). Basically, it feels to give significantly more weight to feedback from prolific posters compared to people who post a little or not at all. I try avoid thinking I have more information when I am told something I already know, for example
Anarchid saying #sonarlives for the 1000th time. Don't be too concerned though because in all-but the worst cases such repetition is an opportunity for clarification. I'm also aware that people who are happy with the status quo are much less motivated to write about how happy they are on the forums.
If, somehow, absolutely everything is known about a particular piece of feedback, then the remaining tasks are for people in taking on the role of developers. They need to gather more feedback, discuss it, devise solutions, and test them. There is more information to be gained from different people saying the same thing than one person saying it multiple times. I think a lot of miscommunication has arisen from me trying to guide people into these tasks as if they were expressing an interest in development (like I would for someone talking about art or code), while they are more in the player mindset of repeating their feedback to ensure it is heard.
Finally on information, be aware of the momentum of the meta. It can takes ages for the playerbase to notice something and adapt. Don't change things and expect good information to start flowing in immediately, and try to avoid making multiple changes faster than the meta can adapt.
"Everything bottoms out at player experience" is sort of a meta-principal. I only thought about it explicitly in the context of balance from about 2014 onwards. In earlier years I had this idea of balancing towards some theoretical ideal. In this paradigm it isn't worth nudging players out of a bad meta unless it is indicative of a problem at the absolute peak of play, rather than a poor local optimum. After watching subgroups of players get caught in their own private metas, that they were complaining about, I decided to shift more towards making a good meta for existing players.
On resources:
-
As far as I'm aware
[LCC]quantum[0K] devised Quant's Rule.
-
I read Sirlin's book Playing To Win and the blog around it on balancing and designing competitive games some time in the late 2000s. It probably affected me.
-
I don't really follow what other designers are up to in the RTS design space. A lot of it seems like people making RTS because they are cool. There is some good general game design stuff out there nowdays.
