32-player TAW is not good for Zero-K

It is probably objectively win-chance-increasing in many large teams games (maybe even 22p, but much more in 32p) for several players (and not just the inept) to reclaim their own factory and assist teammates' construction, and not really doing anything interesting unless they get gifted units from allies.

That feels pretty lame to me, and its lameness has kept it from being very popular outside of stuff like Paladin rush. But ideally games are constructed in such a way that the optimal strategies are not lame.

The cons?
+ Most of the units the game is designed around are obsolete damn near the moment they hit the field
+ Players are stuck with an income that is not sufficient for most strategies
+ The above two points interact - most units small enough to make are not good in big teams, so players are encouraged to passively wait while building something that might be useful
+ Individual player impact is small and this makes playing unsatisfying
+ It's hard to have impact, but it's easy to be impacted upon by multiple players, encouraging passivity at the back while others get wrecked to facilitate your passive teching/ecoing. Perverse incentives.
+ This also makes most strategic decisions kind of arbitrary. Your opponent is always doing rock, paper, and scissors. So is your team. How do you make strategic decisions in this environment?
+ The feedback for learning is terrible, resulting in players learning bad habits and remaining bad players.
+ The space isn't actually that safe for newbies, because your performance is lost in the noise but you have many more people looking for someone to blame.
+ Somehow the room cap coalesces into one room culture, which effectively caps the active multi playerbase to the size of one room.

Big teams is an RTS without strategy. It's competitive without personal success or failure. It's a sandbox that limits viable choices.

Despite all this, the only issue being addressed is the last one. At 32 player room cap, we seem to land at an unfortunate number of players defined by how many people are willing to wait outside the room to play, which isn't enough to seed a second room. If we lower the room cap, the number of people who show up and are waiting MAY hit a threshold that it currently doesn't, allowing for a second room to be seeded and increasing the total effective cap on players. Room player cap is therefore something that may be able to be tuned to socially engineer a more accessible play environment.

If this is the case, ZK may overcome one of its hurdles to playerbase growth. The reasoning above is my own, don't assume I speak for the mods.

OMG, SnuggleBass, can I give you an award or something? You basically said it all.

quote: That day I suspect a lot of misconceptions about how unviable early units are would be shattered.

I doubt it. Circuit, even on Brutal, is pretty hopeless against a porc fortress. I expect the average All Welcome team would beat its numerical equivalent in Brutals pretty easily.

quote: I doubt it. Circuit, even on Brutal, is pretty hopeless against a porc fortress. I expect the average All Welcome team would beat its numerical equivalent in Brutals pretty easily.

That's true, but then you can point out that AI took 2/3 of the map (or more) and the players only survived by stacking aegis and managing to put a cerb up.

If only one player was with the AI, they could just go straight to impalers and take out whatever porc the players get before a cerb is finished.

If there was a will, this could be fixed by reducing the starting metal storage.

Not as easily done but still possible would be to scale the starting metal storage with the number of players. The more players, the less you start with.

And then, if you must, apply a small metal multiplier. The start is slower, but the ramp up is faster.

Demistrider rush is only possible because enough players, each with 500, pool into one project. Cut the inital metal and it's not viable anymore.

Honestly, an alternate !split command could easily solve issues with seeding a second team game in a 26/22 TAW#1 situation. Currently the !split command rips the room in half without the consent of many of it's players. This leads to general unhappiness, as well as one of the matches usually dying soon after.

Another option is to create an alternate !split command, that when activated brings up a vote. Perhaps it could say something to the tune of "Would you like to start a second game?" Any prospective players interesting in starting a new teams room could vote yes, those who want to stay vote no. At conclusion of the vote, all players who voted yes are transported to TAW #2 or next open TAW lobby, and those who vote no remain in the original lobby. Now you have a way for players to easily coordinate a transfer to another lobby, while allowing players who vote no to avoid the split and keep playing games in the current large-ish lobby.

If this vote is effective enough at seeding new pots, then perhaps the TAW room can return to 32 players again. For that to work though, split should probably be a mandatory first vote after map finishes with 10-14+ players total in the lobby. Then after conclusion of the split vote, the map change poll would appear as usual.

Not sure if you missed this, but just in case, you can see some analysis after one week at : https://zero-k.info/Forum/Post/271738#271738

I would hope that we would get some similar update in the near future.

We are now at 11 days of the 22 player limit experiment. It looks promising, however player data is too noisy to tell if there would be a long term effect. I am confident at this point in continuing the experiment because the data seems to indicate that the effect has not been negative. We may have had an anomalously good past week of games, or there could be something to some combination of the smaller room sizes and waiting list change. One surprise is that additional rooms are being seeded without the !split command.

In terms of player feedback, the positive feedback seems to outweigh the negative. Some people say they much prefer the 8v8 to 11v11 sized games, others say that they only way to play 16v16. I am going to side with whichever option seems the best for long term growth. I like how, so far, the teams hosts have been running for a larger proportion of each day. This seems important for attracting players. Although I would not rule out running 32 player games on particular days.

Here is some data.



The above is a timeline of the last month. You'll have to click on it to view a a larger version. It shows the player counts in teams battles that ran in the past month. The battles are stacked so that the total players ingame can be read off the graph. The dotted line is the total spectators across all battles. For example, the peak on Monday the 14th corresponds to B2219014 18 on Fields_Of_Isis, B2219005 14 on Tabula-v6.1 and B2219004 6 on Altair_Crossing_V4.



The numbers do not correspond perfectly because the screenshot shows the players in the room while the graph shows players in game. There is another technicality in that the graph is grouped by 10-minute period, which is necessary to avoid spikes from the ~5 minutes downtime between games. The peak is capturing B2219013 20 on Tau12, which started after the Tabula game.



The top of the timeline graph has a summary for each day. The main number is player minutes i.e. the total time spent in team games by players each day. This is calculated directly from game durations, so the 10-minute period of the graph has no impact. The things I noted last time are holding steady.

• There seem to be more player minutes, on average, since the start of the experiment.
• There are more games overall.
• There are about as many games with at least 16 players.

Eyeballing the last month is a decent sanity check, but it is tricky to draw anything concrete from it. Really, it is difficult to say anything definitive only 11 days into the experiment. But that hasn't stopped me from making more graphs.



The graph above compares the last 11 days (in red) to every other day this year (in green). The box plots are the median and 25th and 75th percentiles. All it really says is that the two weeks prior to the experiment were not abnormally bad. The results so far are an improvement, on average, on the first six months of the year.



Here is an increasingly complicated way to validate the eyeballing of the timeline. This graph shows how much of each day was spent above a set of player count thresholds (8, 16, 22 and 32). This uses the 10-minute batching, so is prone to a bit of weirdness, but it should average out. It doesn't say a whole lot, and mostly just supports the idea that the player distribution spread out across the day, and possibly flattened a little. Although at this level of disaggregation, many of the data points are well within the old distribution.



Finally, this graph is a companion to the one above. It shows the uptime of games of particular sizes during the day, rather than the total playerbase. To see what is going on, note that the red dots in the "size ≥ 32" categories are all sitting at zero. The graph supports conclusions such as "it wasn't harder to find 8v8s during the past 11 days". The baseline data is also quite interesting, as it quantifies what we would be giving up with a smaller room size limit. The uptime of games with at least 22 players ("huge" games) is only around 3-4 hours per day, over the week. It also says that 32 player games were only particularly common on Friday, Saturday and Sunday.



In terms of player numbers, the experiment is the last dot on the weekly players graph. This graph shows the daily number of players that played any online game, averaged over the week. It is too bumpy to say much, especially short term, which is why I am resorting to collecting team game frequency and size data. The hope is that having more games for more of the day is good, and will lead to more players.

quote: The only number to answer the test is whether more people play when the 22 room or 32 room is full. Should look at same days the year before and month before. When the 22 room isn't full, then the test really is not running. Find the times when the 22 room is full and compare to that same time the year or month before. If when the 22 room is full there are more people playing (PvP or PvE) than that same time the year and month before, then the room limit probably helped. The difficulty is isolating for only times when the 22 room is full.

QuietMute this is the right kind of idea, but as you can see above it is a lot more complicated. Player numbers bounce around in a way that isn't consistent year to year. I am also not sure about limiting ourselves to models in which the room limit only matters when there are more players than the limit. Eyeballing the timeline graph above, you'll probably find that there are more player minutes above the 22 player threshold per-experiment than post-experiment. But is that all that matters? The "at least N players" graph says that, so far, more time is spent at or above 22 players post-experiment.

That said, I'm inclined to agree that Monday the 21st isn't that relevant to the experiment. This day failed to have a game larger than 8v8. It probably would have gone like this either way. But I keep in mind that people may or may not have shown up to play because of the changed room limit.

quote: If there is less than 16 players in a TAW match I exit and go play BAR, so I feel like you are not correct in assuming large matches are "bad for Zero-K".

Hellaciouss then perhaps you'll support a 22 player room limit, if the early results hold up. Because there are consistently more games of 16 players or larger.

quote: Thank you, GoogleFrog, for creating those updates. When this discussion started you made clear that you expect support in many aspects of changes are done. Yet you are who provides thoughtful and data-based analysis. I don't think I could do this due to not having access to the data, but even if I could, I'm very thankful that you still do that for the good of the community.

Thanks madez. I should point out though that everyone has access to the data. I'm not even doing the sophisticated scraping that allows for the 1v1 stats tool or the team game analyser. I just went to the replays page, held Page Down until I hit the start of the year, and copied the page into a text file.