-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The latest pot idea #2803
Comments
This is what the queue room was supposed to be doing.. I remember you were quite militantly against it.. |
Doesn't this create a leaving spiral that kills the room? If people can still host 32 player rooms, won't this make people switch to manual hosting to work around the juggler? |
I recall the queue room being different in subtle but important ways. Guiding the flow of people so that they don't fight against it and break it is most of the difficult problem here. What exactly was the queue room proposal? I recall predicting it encouraging some sort of behaviour that would bring down the system. The specifics of what players see and can do are vital. I don't know if game observing or friending is possible. Perhaps splits could split people by friend group, but that risks creating high elo disparities that kill rooms.
Potentially. It is one of the big risks for the system. Having the other players simply not be in the room by the time players switch back to the lobby seems like it would partially fix this. Having a potential 7v7 in front of them, with no alternative, would also help. The numbers would have to be calibrated to take into account the usual attrition after a large team game. Perhaps splits could only happen at 32 players, or maybe use waiting list to go even higher.
This is a significant unsolved problem. |
Queue room was basically a battle room where all people who want to play teams join. You can still set the map and stuff but when you run start, it will create possibly multiple running spring games based on ELO/counts. Another thing is that on starting the game, people who are in MM waiting for "big teams" are auto joined to the pool of players. When game ends people are still in the same queue room (they never leave the queue room, making it appear huge). |
These are the things I imagined people would do (besides complaining): If game splits into A and B battles and A ends before B, then based on number of non-ingame players they will decide to either:
But regardless of their choice, they will still be in the same queue room, attracting more people and making it possible to change decision at any moment. |
My concern with queue room is people's reaction to the surprise of not being in as large game as they thought they would be. It doesn't take that many people to bandwagon a force exit or ruin a game due to frustrated expectations. The UI would at least have to pre-show what the games would be. It could work but the whole thing hinges on how the UI manages and communicates with players so that they don't break it. There are also issues such as what to do if one game ends just as another starts (not giving people who are sitting out time to spectate), and how to manage votes. The solution to these problems could create such a split room that we may as well have gone with the latest pot idea, with the big difference being whether the rooms are split on game start or game end. |
I think pot has the problem that you dont see that huge clump of people and you cannot talk to them. I think it's important that the clump exist or people will form it naturally elsewhere. Regarding "surprise" - the room could indicate where the line is or there could be final confirm stage which shows your team. You could say no.. if enough people say no game starts without nay-sayers possibly in unified mode. |
I don't think forming the clump elsewhere is likely if there is only one visible game with 10-20 players. Also, if people manage to successfully form it elsewhere, then I wouldn't call that a failure state. I think a final confirmation stage is too vulnerable to people clicking no, or there being too many people unaware that they have to click anything at all. I think it is an inherent problem for any system to rely on any extra decision making or understanding from players. |
Because lot's of these assumptions are about people behavior perhaps the best way is to try to make it flexible and test it.. |
To revisit this, the wait list could be used to make the resulting rooms more viable. For example, the 32-player room could split into two 20 player rooms if there are 40 people playing or waiting to play. I would also change the "upon game end" to "upon game start". As in, if there are 40 people in the room then the start vote causes a split and people end up in 20 player games. The room could even display the games that could be created. |
Sounds pretty much like old style splitter.. the code probably still exists .. unrestrict the room and auto split on 40+ |
A bit of ancient aliens archeology - found old style split. Removed anno domini 2016
|
I suppose I had better write this down to avoid the work of re-deriving it in the future.
The primary goal is to let the pot scale up to allow everyone who wants to play a slot in the game. The mechanics:
Pots sometimes check for merges. This occurs pairwise under certain condition. The conditions are:
Two pots are merged if at least one has fewer than 10 players.
The text was updated successfully, but these errors were encountered: