Loading...
  OR  Zero-K Name:    Password:   

Only one teams room

8 posts, 349 views
Post comment
Filter:    Player:  
sort
56 days ago
The culture of having only one teams room is problematic. Often, the players who are waiting in the teams room would be enough to start a new game, but they don't do it. They are waiting while they could just start another game. This doesn't happen in most other RTS. Polls suggest that a quarter of the players actually want to have teams as big as possible, so maybe they want to wait (?), but half of the players prefer small teams.

I propose a solution that will hopefully improve things for both: Each waiting player is asked how many players would at least have to join so that they would join a new game, with the possibility to decline the option at all. As many waiting players as possible are then moved to a new teams room such that each one's minimum size requirement is met. Players are considered to be "waiting" if and only if they are in the players section of a room without playing. I can provide some details on an implementation algorithm if desired.
+4 / -0


56 days ago
Make !battle discoverable
+0 / -0
Thread #648 about splitting the large teams room.

Casual matchmaker with some kind of shared chat could theoretically work, but every complexity will be a pretty against learning the system of how to play the game. In fact, just add everything after the comma to whatever your suggestion is and it holds true.

It's highly likely that 28 zero-k players would rather play a 14 v 14 than a 3 v 3 and 11 v 11, or any permutation of that. And if they don't get that sufficiently massive game, they leave the game for the night, which shrinks the pool of players.

Some key identifiable problem is player count and player perception. A solution to our problem needs to successfully shift the perspective of players and work under a highly varied total player count, and it needs to work better than "the one room."

In a sense I envey games like Splatoon/apex legends/Fortnite because at player numbers that they have you can literally just use queues which is a wildly different player perception of how to play the game than our lobbies.
+2 / -0
56 days ago
The more people there are in a team, the less effort they need to put in individually in order to win. They would rather just wait for that opportunity than to play a lobby where they are required to put more effort in.

One possible solution is to get rid of large team rooms and replace them with 2v2/3v3/4v4 rooms. Unless there's enough people playing for two 16v16 lob pots, which there isn't most of the time.
+2 / -0
The big team room provides reliability. If you spectate an ongoing game of 30 players you can be fairly sure that there will be another game to play shortly after it ends. A smaller room is much more fragile. An eight player room might evaporate with only a few players deciding they don't like the map, the teams, or just calling it a night. If there are multiple rooms then people can scout around for the one they might want to play in, delaying or potentially killing rooms further.

These aren't reasons to try to create more than one room. These are difficulties to overcome if any approach is to be successful. Various forms of splitting and asking players whether they want to play a smaller game have been tried. None have worked, although that may be due to implementation details in many cases. A vital metric for these systems is how likely it is that a player will end up in a game that they want to play.
quote:
Each waiting player is asked how many players would at least have to join so that they would join a new game, with the possibility to decline the option at all. As many waiting players as possible are then moved to a new teams room such that each one's minimum size requirement is met. Players are considered to be "waiting" if and only if they are in the players section of a room without playing. I can provide some details on an implementation algorithm if desired.

CHrankAdminDeinFreund tried something similar and it turns out that it doesn't reliably create viable games. People won't know what it does, so enough people will click it then leave the game to teach everyone to never click it.

My current idea is to use the waiting list. If there are, say, 12 people in the waiting list then create a new room with them when the current game starts. This at least means that there is no game to leave and try to join, since it just started. The new game is still riskier though, as playing a subpar game then missing the next large team game is worse than just watching a large game and then playing the next.
+0 / -0
55 days ago
I agree that small rooms fragility is a major challenge to overcome.

quote:
People won't know what it does, so enough people will click it then leave the game to teach everyone to never click it.
Just explain what it does in one clear sentence in the GUI.

quote:
My current idea is to use the waiting list. If there are, say, 12 people in the waiting list then create a new room with them when the current game starts.
That's fine. But if you only check it at game start and only if there are ~12 people in the waiting list, this will nearly never happen. You would have to use a much lower threshold and also check it during games, where the set of waiting players is no longer equivalent to the waiting list.
+0 / -0



55 days ago
quote:
Just explain what it does in one clear sentence in the GUI.

People don't read, and if you make them then they get annoyed and still don't read.

quote:
That's fine. But if you only check it at game start and only if there are ~12 people in the waiting list, this will nearly never happen.

Something happening rarely but working almost always is much better than something happening slightly more often but with a higher chance of failure. We've tried aggressive systems with fairly common failures in the past. Maybe my thresholds are far too high, but I think the broader approach required is that of making something that doesn't fail, and then trying to expand it from there.
+0 / -0

54 days ago
Maybe use a divider to split the rooms in categories 'auto' and 'non-auto'. Then it's more obvious where overflow should go to.

+0 / -0