Hi All,
I have really debated about making this post for awhile, but I think with the recent rework of Dante, combined with the last few balance patches and (really since) the addition of Magpie, Odin, and Lobster I feel like we are entering a slippery slope in terms of making changes to the game, and I feel like there has been a relative lack of transparency regarding real reasons (if they are present) for some of the changes recently and just a general feeling that we are slowly sliding down a hill from what was OG Zero-K into some other game.
This is gonna be a very long read, so strap in and (don't) enjoy the slide.
Timeline So, all of the events we are going to talk about in this thread begin with the addition of Lobster, so here is a brief timeline if you weren't around yet:
-
Lobster gets added. Immediately influences meta in direction of scallop ball/related strategies.
-
Some Lobster nerfs occur.
-
A long time after this, we get Bolas.
-
Lobster is still getting nerfed, Bolas gets nerfed.
-
A long time after this, we get Magpie and Odin.
-
Magpie, Bolas, and Lobster are getting nerfed (still).
(side note; Lobster is 8 years old!)
As we can see from this extremely general timeline, we end up spending years fixing game balance after each new unit is released. Why is that? And why do we have new units in the first place? I suspect it is a result of a few different factors:
- First and foremost, the changing demands of the playerbase
- Second, as a result of poor or non-existent balancing standards
- Third, potentially as a byproducting of adjusting the game when no adjustment was needed, or as a result of developer boredom
I will attempt to go into each one of these in depth below.
Player Demands Without players, there is no reason to develop a game. After all, who will show up to play it? There's no point in developing it with players, but this comes with the added fact that you must balance your game to appeal to players, and what they want out of the game at that point in time. Most of the time when you are trying to balance a game, the players will steer you in a generally correct direction, but what happens when they don't?
Prior to 8 years ago, amph didn't have anything it could really call an artillery unit. And, to be honest, it still really doesn't have one today - instead, it got an pseudo-artillery movement tool which is the Lobster. And, while cool and funky and unique and all that stuff, we need to consider that when players ask for stuff like giving a factory an artillery unit, we should either incorporate it traditionally or not incorporate it at all.
In Zero-K, as most of you probably know, we have a few forms of movement:
-
being picked up and flown
(I won't include djinn here since you have to set it up with ground or air movement)
Essentially, if you want a ground unit to get over somewhere, you gotta either walk it there, or you have to have a air transport fly it over, giving it the chance to be shot at by AA. Zero-K is not a game that encourages neutral skips - if you want to force advantage state, you need to move there to do it. You can move forward with gimmicks, but you'd still be walking, and you'd run the danger of either being decloaked or your shields running out on the approach.
Lobster upon it's release changed up this formula by providing a new form of movement - throwing units at the opponent. This was essentially the instant overhead of Zero-K for awhile and even had tech like space lobster chaining before it got so out of hand it was nerfed back to earth (literally). However, even now, it is still very strong after multiple nerfs, and still makes scallop ball viable, and is used as a support option for a variety of compositions. It could probably be said that this is probably not what a majority of people were expecting when the playerbase was talking about a artillery unit for the amph factory,
In this case, a cool idea due to the desires of the playerbase inspired a unit with such a drastic game warping impact that it still skews balance to this day, and we still have to spend time complaining about it. Prior to recent nerfs it was essentially an unreactable approach option (not considering very specific micro) and absolutely could have been said to be meta breaking. This is exhibit A of why we do not add units to a game we are already trying to balance. Even if we could say that it was trying to even out factory capabilities by adding a artillery unit, it was so far off the beaten path that it is genuinely impossible to see how this could have been expected to not have game warping implications upon release. Ultimately, the game probably would have been easier to balance without its addition, or with a more orthodox unit in its slot.
Poor Balance Standards or Procedures In Zero-K, due to the nature of being balanced by (what are essentially) community members, we lack some of the professional QA and testing procedures and ability that other larger games may get to utilize before making large scale changes. This is somewhat inevitable, as there is no studio behind Zero-K, but in this case it is even more important for us to consider changes and give them a test to be thoroughly tested by the community before making changes that drastically alter the play experience. It is also vital that we provide thorough documentation and data for changes, although in practice until now this has rarely happened (as even antihype is not particularly used for statistical data to back up changes). For this, I would like to present two case studies: The past case of Magpie, and and the current case of Dante.
Magpie is probably one of the most talked about units in the game in recent years. While never actually in a state where it could be considered "good" by many players, it was seen quite often in Teams All Welcome, and this probably contributed to a situation where it seemed like a much larger problem than it actually was. After being endlessly (and I mean endlessly, to the point where it was virtually talked about every day) discussed, the devs decided that the following changes would bring it into line:
-
Cost 220 -> 210
-
Health 900 -> 740
So generally with changes like these that we tend to see in RTS games, and in some games no matter what genre where damage efficiency is related to health, we would expect to see (based on the health decrease) around a 5% reduction in HP, which would bring it down to about 855. However as we can clearly see, the devs for some reason have decided to go with a
18% reduction. So at this point, we have a pretty middling unit receiving a skewed sidegrade. Now, there could have been many reasons for this, but at this point:
-
The official side notes do not publish any real breakpoints in terms of damage to justify the specific HP point that they nerfed magpie to,
-
Multiple people have said when asked about data to back up the nerf that "it was boring/lame, so we nerfed it" without providing further data,
-
and the new design was not released in a snapshot or any other release where it could be tested ahead of time, so apart from internal testing there was no documented data from tests to back it up either.
Taking into account that it wasn't all that useful besides a handful of players managing to find mild success with it in large teams, its pretty baffling that Magpie would receive a nerf of such magnitude when apparently the idea with the nerf was to start guiding the unit towards a redesign. But if a redesign was the original reason for the nerf, why not create and test a redesign in a snapshot first before actually committing to a change? Due to a lack of standards or procedure for balancing, the devs ultimately ended up rushing a change, perhaps in response to community sentiment, that guttered a unit while not redesigning or reworking it in any meaningful way.
Let's take a break here and talk about ways in which we can meaningfully and practically test and measure the effects of changes before they impact the main game across all formats. Ideally, the best way to test changes is laid on top of the base game in isolation. For example, for Magpie if we wanted to test that balance change before fully committing, we could have made a snapshot with
only that change in it, let TAW use it for a month or so, and then look at the data afterwards from that change specifically. This ensures a few things:
-
We can view the change in isolation so there are no other variable changes besides the control (base game)
-
Instead of viewing balance in context of a patch full of changes, this lets us view changes without background noise and measure data so we can get an accurate read on how the unit is doing
Although time consuming, without a dedicated internal testing team this is the best solution for the game so that developers do not commit changes that are too severe and cannot be reverted easily. Additionally, it would also be better if for patch notes or proposed changes that we would do more community polls and publish more data with the notes in relation to breakpoints, other relevant data, and such.
Now for our other case study: Dante.
Dante was recently reworked from being a skirmisher strider with some up close capability into a more tanky brawler with more HP, but lesser range. The change is new enough to where no one can say whether its good or bad yet, but it does seem like the change helps to align the unit in a more riot-esque perspective which is presumably the tag that the unit was originally designed under. The problems in this case arise not from the actual change itself (yet), but the way that the change was formulated and how it shipped.
A lot of people who have played the game recently have probably at some point or another ran into or played
StiofanKingofAwoo 's boatcars mod. It has some interesting ideas, and the balance is somewhat iffy because it decided to tweak the entire game rather than just a new factory, but that is my opinion and not really the point of this document. The current Dante change originated in this mod, and while it did have some minor testing, beyond that there were a multitude of issues concerning its release:
-
The unit's testing base has a rather small amount of total games, and even fewer unique players have played it in order to gather testing data (compared to larger lobbies recently running such as Palladium, TAW, or FFA)
-
The unit was balanced under a modified context that modified large parts of the base game and added a factory, which would invalidate testing data as the control has been modified
-
The unit in of itself potentially didn't need a rework at all as not that many people were complaining about it and this may be an instance of "developer boredom", as discussed in the next section
-
Due to the small game count and low amount of community exposure the change had prior to release it may have surprised a large amount of the playerbase, which could lead to community discontentment
-
There was no published data to back changes up that were made to Dante, which likely points to purely opinionated reasoning being used to justify the change
To be clear - I am not saying that we never need to touch a unit again balance wise, or never rework them, or even never incorporate new content from mods - but we need developers to be more clear about the reasoning and data behind why changes are justified and provide more time and opportunity for community testing for the main game with changes isolated (such as a snapshot for TAW for a given period of time). If we had more clear guidelines and standards regarding such changes I do not think we would have either changed in the first place or would be hearing complaints about units such as Magpie and Dante.
Developer Boredom and Why Sometimes We Just Shouldn't Touch Things There is a phenomenon in game design and development that I personally like to refer to as "Developer Boredom". It is a little generalist, but I think it does a good job at describing a phenomenon regarding balancing that we have began to see a lot lately across multiple genres, and I think that it is especially a product of our current era in gaming (that is to say, games or software as a service (SaaS)).
Developer boredom, shortly put, is when developers of a given game decide amongst themselves that something needs to be changed, but may not have any current strong community sentiment to base a change off of. For example, Lobster in the past has been consistent game warping in ways that are unpopular, so it has always made sense from a developer perspective (for the sake of game health) to focus on fixing Lobsters strength, and the same goes for a lot of units that have been considered either overpowered or popular over the course of the game.
However, we sometimes see some occurrences where developers decide to make a change or add units (such as the
addition of Magpie or Odin or the Dante rework) that do just tend to show up out of the blue and affect game balance but really didn't have any obvious signs on the front end that they were going to happen. Then, we tend to end up in situations where we did not carefully consider the effects of these units on the game, people either love or hate the unit in question, and then when they must be
inevitably changed, reworked, etc. at a later point in time, we end up with people upset. This is not to say that developers can never surprise players with a new unit or something, but in the context of community-ran games like Zero-K where we don't have a dedicated internal balance team of more than maybe just a few core devs, it could be said to be obvious that we should likely prioritize safely adjusting the game with minimal surprises rather than trying to be fancy with cool stuff. For those of you in the FGC - SF3 and SSBU haven't gotten a patch in over 20 years, and they're just all the better for it.
In a world where we can always change something, it may be tempting for all of us to adapt a mindset of "lets just put this out there and fix it later," and it feels like a majority of game developers in the current era have decided to think like this in terms of their patch structure and balancing. However, as a community, I think personally that it is integral to the continued survival of our game to encourage
safety at all costs, rather than attempting to get everything we want. Some of us may have to live with the way the game is for a long time, and maybe that's fine. Looking back at the history of the SpringRTS/Recoil engine and it's games too should give us caution - we are one of the two games ever out of that engine to have major success, and we should be extremely careful not to give ourselves any reasons to lose players at any point. BAR has balancing and development issues galore because of their hurried and messy development - let us learn from them, and not become like them.
I'm sure you are all tired of reading by this point. Congrats for making it to the end! If you have questions or need clarifying examples, please comment below. I will generally not respond to opinionated statements, unless those opinions have some statistical data backing them.
