The main problem is not so much "big teams vs small teams" but rather "playing vs waiting to play". Additionally, there is the conflict of "changing things vs keeping things as they are". Here's my preferred solution (*) that is more on the side of changing things: You cannot join a room of a running game except as a spectator. There is one designated waiting room for teams that is not running, marked with a colored frame. When a game in the designated room starts, it becomes non-designated, another designated room is started and the players from the waiting list of the old designated room are sent to the new one. When a non-password protected team game ends, its room is dissolved and all its players are sent to the designated waiting room. This means that joining the designated waiting room always gives you the highest chance of joining the next game because the players of all running non-password protected team games will be sent there. Potential additional features: - If you click on a running room, you are presented the following options: spectate, join waiting room, spectate and join waiting room, cancel. - If a player joins a room (manually or automatically), the game start is delayed by few seconds or until that player becomes a spectator or has confirmed that they are ready to play, for example by voting yes on a start vote. - If you are spectating while in another room, you are notified more clearly about start votes in that room. - There is a big button to join the designated waiting room such that you could even join it if new rooms were created at high frequency. - If players enter/leave during an ongoing start vote, the vote threshold changes. My waiting room suggestion is similar to    dyth68's multiroom suggestion. Both are fine imo. The advantage of the multiroom is that it doesn't try to break with the habit of always joining the largest room. The advantage of the waiting room is that the GUI is clearer and it scales better for many rooms.
+2 / -0
|
If you're more on the side of keeping things as they are, there is still my suggestion of being asked to move to a new room with a customizable minimal size requirement. quote:
The defining feature of the game found message box is that it demands an answer and times out in 30 seconds. So I really don't know what you mean by making a message like that, but which doesn't prevent other actions. |
By similar to the matchmaker messagebox, I mean mostly in parts of the graphical design. I hope you can imagine a messagebox that does not prevent you from doing anything else. As I said I can provide some details on an implementation, but the details provided so far should be enough to say in which kind of solution we are interested at all. If one of the suggestions becomes more likely to be accepted, we can go more into detail.
+0 / -0
|
quote:
You cannot join a room of a running game except as a spectator. There is one designated waiting room for teams that is not running, marked with a colored frame. When a game in the designated room starts, it becomes non-designated, another designated room is started and the players from the waiting list of the old designated room are sent to the new one. When a non-password protected team game ends, its room is dissolved and all its players are sent to the designated waiting room. |
Sounds fine except a few important nitpicks which make this fall short as a specification.
-
There is currently no concept of joining a room as a spectator or a player. People just join rooms and can then switch between player or spectator slots freely. So technically your first sentence doesn't really do anything, but it is possibly implying something you'd like to dig into and spell out.
-
All games need to be joinable "as players" (whatever that means) so crashed people can rejoin.
-
"non-password protected team game" is the wrong category if you intend for anyone to be able to host their own team games, which I think we do. It sounds like you want "non-passworded team room set in autohost mode".
-
The system compromises too much of the existing features of being able to predict when the next game will be, who is likely to be in it, and its approximate size.
-
What happens to the spectators when a game in one of these managed rooms ends?
-
Players from the waiting list join the game they were wait for as spectators, so how are they supposed to see what is going on in the new room they were shunted to?
More substantially, it seems like you have effectively added another option that may not be so good when the waiting list is small. Currently the only option for an arriving player is to join the big team room and wait until it game start, and possibly spectate until then. This option still exists, but now there is also the option to join a separate-seeming teams room with a few players in it. Once there, they might try to start the game. This seems problematic if there aren't many players in the room. Each player in this room can be some combination of:
-
Unaware that they are even in the room, or at least that there is activity in it, because they are busy spectating the big team game.
-
Preferring to wait for a spot in the big game rather than start a new one of the current size.
I expect the preference for waiting to increase as the running game comes to an end, and the players from the waiting list have a clear view of this as they are spectating the other game. This becomes a problem in three ways.
-
People who would have been happy to wait for the big game get frustrated at the waiting players not wanting to start a game, so leave.
-
People end playing small games that they don't want or enjoy. Trying to play a game then ending up feeling obliged to play a game you don't want to feels bad. It has costs.
-
People end up loading in to a game they don't want, and were probably not aware of, then leave and go back to waiting for the big game. This wastes everyone's time.
So votes to start "small" games in these spinoff rooms might have to be unanimous, and there would need to be some better relay of room to game chat that can deal with people in different rooms. So it sounds generally ok, but there are some UI issues that need thinking out. I'm being so exact on all this stuff because we have to know exactly what we want to have any chance of implementing it. An exact specification of how the UI solves all these problems will lead to some minimal server-side change required to implement the rest of it in the lobby. Ideally it wouldn't require any server changes at all. This requires knowing all the details of the end goal, then figuring out ways to implement them (eg maybe spawn a bunch of autohosts, given them some standard index name, and make the lobby show/hide them and move people around themselves). quote:
By similar to the matchmaker messagebox, I mean mostly in parts of the graphical design. I hope you can imagine a messagebox that does not prevent you from doing anything else. |
I can imagine such things, but what comes to mind is terrible. Message box popups, blocking or not, are a scant resource due to how annoying and cluttered they can make things. If you're going to start adding regular non-blocking popups, then you probably have to give the lobby a slight redesign to set aside an area for them. This is the primary problem with giving people extra optional queues for them to join, and I'm not currently interested enough in this line of inquiry to do the thinking for you.
+0 / -0
|
quote:
There is currently no concept of joining a room as a spectator or a player. People just join rooms and can then switch between player or spectator slots freely. So technically your first sentence doesn't really do anything, but it is possibly implying something you'd like to dig into and spell out. |
It is strange that the status of whether a player is playing, spectating or waiting can be different between the running game and the game room. It is also strange that a running room can have waiting players at all. This is not the case for many other RTS. There is already the concept of running games created by the matchmaker where you can only join as a spectator (except for rejoining as a player). So it can either be implemented in the way the matchmaker does it or just keep it as a running room where joining players become spectators and cannot switch to players (except if they are actually playing). quote:
All games need to be joinable "as players" (whatever that means) so crashed people can rejoin. |
Yes, fine, allow it only for people who are actually playing. quote:
"non-password protected team game" is the wrong category if you intend for anyone to be able to host their own team games, which I think we do. It sounds like you want "non-passworded team room set in autohost mode". |
Both works. Only including autohosts has the danger that people circumvent the waiting room with a big teams game. Including other public team games still makes it possible to host your own game. You only have to create a new room for a new game (as it is in many other RTS). But it works either way. quote:
The system compromises too much of the existing features of being able to predict when the next game will be, who is likely to be in it, and its approximate size. |
If you are in the waiting room, you see all other people in the waiting room. You can also look at the room list. If the goal is to have multiple games running at the same time, then it is always hard to see all other games. If this is really a concern, then allow for showing the room list on one side and the current room on the other side instead of the main chat. quote:
What happens to the spectators when a game in one of these managed rooms ends? |
They are sent to the waiting room as spectators so that they will join the next game as spectators. quote:
Players from the waiting list join the game they were wait for as spectators, so how are they supposed to see what is going on in the new room they were shunted to? |
They don't join as spectators. They are only sent to the waiting room because they are waiting to play, not to spectate. They can still just leave the waiting room and spectate a running game. quote:
Unaware that they are even in the room, or at least that there is activity in it, because they are busy spectating the big team game. |
They are not unaware because somebody who is sent to the waiting room is never automatically spectating or playing another game. The only thing that somebody sees who is automatically sent to the waiting room is the waiting room. Currently, you can also wait in a room while spectating another game. It would be better if the chat and players of your room were shown to you while you are spectating a different game without having to switch between the two. But this issue exists independently of my suggestion and spectating while waiting has to be dealt with in any kind of solution that allows it. My suggestion would at least make the player aware of the possibility of being in a room and spectating another one without making it the default: quote:
- If you click on a running room, you are presented the following options: spectate, join waiting room, spectate and join waiting room, cancel. |
quote:
Preferring to wait for a spot in the big game rather than start a new one of the current size. |
This is indeed an issue. Those people can just leave the waiting room or spec the waiting room or running game or we can provide an option were they can specify a minimum player number at which they are willing to play while in the waiting room. If enough people join the waiting room, they probably want to play too. If we never send them there, this will never happen. That's the reason for this thread. So it wouldn't be as bad as it is now. quote:
People who would have been happy to wait for the big game get frustrated at the waiting players not wanting to start a game, so leave. |
You mean the ones who want to start a small game get frustrated? As much as they are in the current situation? quote:
People end playing small games that they don't want or enjoy. Trying to play a game then ending up feeling obliged to play a game you don't want to feels bad. It has costs. People end up loading in to a game they don't want, and were probably not aware of, then leave and go back to waiting for the big game. This wastes everyone's time. |
This shouldn't happen because everyone in the waiting room would be notified about a start vote and afkers specced. People who don't want to play should leave that room or spec. For people who only want to play at a minimum size, we can provide an option to specify this size. Even if we don't, they can spec/unspec manually.
+0 / -0
|
quote:
It is strange that the status of whether a player is playing, spectating or waiting can be different between the running game and the game room... |
Sure, but for communication it doesn't matter how strange you think any aspect of games work. If you don't specify a change, then I am going to assume you mean it continues to work as it does now. quote:
Both works. Only including autohosts has the danger that people circumvent the waiting room with a big teams game. Including other public team games still makes it possible to host your own game. You only have to create a new room for a new game (as it is in many other RTS). But it works either way. |
While people hosting the big teams room can cause issues, I wouldn't want to trade it for people being unable to host their own team games. Hosting your own small team game under this system would be essentially impossible because the room would be killed at the end of each game. Anyway, if the system is so bad that people feel the need to host their own big teams, then it's probably not working anyway. quote:
You mean the ones who want to start a small game get frustrated? As much as they are in the current situation? |
No, I mean anyone trying to start the game. Look, and this applies generally to threads like this, I wrote what I wrote. Can we all try a bit harder to avoid twisting everything towards the barrows we push? I just gets annoying to have to write so defensively. Anyway, I don't want an extended quote-and-requote. I want a clarified proposal that hits the issues raised, in one spot rather than spread across replies. So I'll just write out what I think your proposal is, in light of what you've said.
-
Make 10 identical "special" big teams rooms, indexed by some number in their name.
-
The lobby is going to show or hide these rooms based on some rules. The result of the rules is that one and only one non-running room is visible at all times.
-
The system initialises with the first room visible, and the others hidden.
-
When a room starts, another room (perhaps the lowest hidden one) becomes visible.
-
Additionally, when a room starts, everyone in the waiting list is sent to the newly visible room, rather than loading into the game.
-
When a room ends, everyone in the room is sent to the visible room, and the room that ended is hidden.
-
Clicking on a running special room rejoins the game without entering the room (like MM rooms).
This still has a few issues, but I stopped there because so far it all sounds implementable from the lobby. Here are some problems, some of which seem solvable with some infra work, but which would significantly complicate the system.
-
When a room ends there is some grace time where there are no votes, then an automatic 4-way map vote, then a start vote. This seems to keep games flowing pretty well so would be good to retain. Having everyone move to the new visible room doesn't allow this.
-
This could be solved without infra by moving everyone from the visible room to the newly ended room, but then the people who were waiting in the smaller room would be at the end of the waiting list, when those people should be at the front.
-
Say two 32 player games just ended, it seems like the system creates needless screwing around to start the next two games. First everyone votes for a map, then to start, in one room, then the overflow are shunted to a new room, where they probably want to vote for a map again. The first map vote is irrelevant to half the players. So the map of the newly visible room should probably be copied from the room that just started.
-
This system would kill one of two 20 player games if they happen to end at the same time. The rooms would be merged into a 32 player game, with 8 players left over. So it seems like the whole "there is one non-running visible room" idea seems a bit too simplified.
-
I'm not so sure about "Clicking on a running special room rejoins the game without entering the room" as it is a step backwards in UI. Being actually in a running room is the most reliable way to play the next game with that approximate set of players (maybe you friend is in it). If you can't be in the room then you can't automatically play the next game. The waiting room could try to start a new game before the one you want is done, which you don't want, because you care about who you play with. So your best bet is to watch the game you want, then click on it in the lobby once it is over. This seems bad.
So anyway, the above is what you seemed to write. Perhaps write out your own system if I got it wrong, or address the flaws some other way. How about the system below?
-
Make 10 identical "special" big teams rooms, indexed by some number in their name.
-
The lobby is going to show or hide these rooms based on some rules. The result of the rules is that at least one non-running room is visible, and if more than two rooms are visible then they all have players in them.
-
The system initialises with the first room visible, and the others hidden.
-
When a room starts and there are no visible-non running rooms, a hidden room becomes visible.
-
Additionally, when a room starts, everyone in the waiting list is sent to the non-running visible room with the most players.
-
Any time there is a non-running room with fewer than 12 players, and at least one other non-running room, a room merge occurs. This is done by hiding the smallest visible non-running room and sending all of its inhabitants to the next-smallest non-running visible room, inserting players to the top of the waiting list. Triggers for this system are suspended if the smallest room has or had a vote active in the last 10 seconds.
The above seems to necessarily require infrastructure work as it requires a way to put people in rooms at the top of the waiting list. Technically the smallest infra change is to let the lobby say where it wants to go on the list, but letting clients do that seems questionable. So infra would have to handle merging rooms, and once it does that it may as well handle spawning rooms as well. So the revised system could be as follows.
-
Battle rooms have a new moderator-only settable string parameter 'selfspawning'. The string is intended to be a name, so parallel versions of the system could exist (eg one for small teams, one for big).
-
Battle rooms have a new moderator-only settable integer parameter 'spawnmergethreshold', used by selfspawning rooms.
-
All instances of "room" below refer to a battle room with selfspawning set to a fixed identifier, such as 'bigteams'. All the rooms with the same selfspawning identifier form a managed set of rooms.
-
When a room starts, if there are no non-running rooms, a new room with identical settings is created.
-
Additionally, when a room starts, everyone in the waiting list of the room is sent to the non-running room with the most players. Clients that are moved this way are not sent the instruction to join the game that started as a spectator.
-
Any time there is a room with fewer than spawnmergethreshold players, and at least one other non-running room, a merge occurs. This is done by closing the smallest non-running room and sending all of its inhabitants (retaining spectator/player state) to the next-smallest non-running room. The system continues iterating, closing the smallest room, until the conditions for doing so are no longer required. Everyone transferred by this system retains the wait list join time they had in their old room. This system halts if a room that would be closed has an active start vote.
+0 / -0
|
Alongside this there could be some ingame overlay UI that tells players about start votes for non-running rooms they are in, but that seems orthogonal to the rest of this stuff.
+0 / -0
|
I think it is very good that we are now talking about solutions. Sorry that I didn't understand your sentence about players getting frustrated. Your version is fine except for one point: If people can still just join the big running room instead of the waiting room, then how do we make them aware that the waiting room even exists and works as it does? I understand that you want to keep this option for people who actually want to wait. But what about those that just want to play but don't know how the waiting room works? After clicking on a running autohosted team room, maybe show options that include joining this room and joining the waiting room with the text "When this game ends, players in the waiting room will be moved to this room at the top of the waiting list." Otherwise, they will again sit in the big room and wait even if they would be enough to start a new game. quote:
Any time there is a non-running room with fewer than 12 players, and at least one other non-running room, a room merge occurs. This is done by hiding the smallest visible non-running room and sending all of its inhabitants to the next-smallest non-running visible room, inserting players to the top of the waiting list. Triggers for this system are suspended if the smallest room has or had a vote active in the last 10 seconds. |
I guess this only applies to autohosted big team rooms, right? It shouldn't merge small teams or own rooms that have just been joined or opened. For votes in the last 10s, the following should probably not be counted: resign votes, kick votes, exit votes. Also consider the following case: A small and a big team game are running. The big team game ends and few waiting players are inserted at the top of the waiting list. Votes and discussions are going on in the non-running big room. The small team game ends and its players (< 12) are inserted at the TOP of the waiting list because they were the smaller room. So probably the criterion for which room should be inserted at the top shouldn't be its size but whether it just became non-running so that players who waited longer get the higher spots. It would also be possible to not merge rooms if the room that just became non-running is smaller than the waiting room. It is good that your solution already includes the possibility to generalize it to other game modes than teams. I didn't mention it for simplicity, but it is good to have this option.
+0 / -0
|
quote:
Clients that are moved this way are not sent the instruction to join the game that started as a spectator. |
That does not sound particularly nice. Speccing games is a nice activity while waiting. Do you propose this to minimize infra changes? Ideally there would be some way to "ping" players speccing that their room requires attention (for start vote for example) quote:
I understand that you want to keep this option for people who actually want to wait. |
Not sure if that was the idea, just in case I would point out that allowing people to wait on a running game might discourage people to stay in the waiting room, because waiting in the running room will always guarantee you are in the next game. Staying in the waiting room relies on the merge that might sometime not happen (ex: vote or above the threshold but game not starting)
+0 / -0
|
quote:
(personal opinion as user) Using queues is very anti-social. You do not know who else waits. You cannot chat with them. You have no estimation about when next game will start (even very approximate based on history, or on other games happening for that queue). I generally do not use a queue because of the above. |
How about this?
-
do the things I talked in my earlier post (i.e. make the changes that let you queue up to MM in parallel and not be sad). The core change (leave queue when playing in a room, get back when game ends) doesn't require infra changes
-
have a mapping between MM queues and chat channels. This can also be done lobbyside (just hardcode that the channel for 1v1 wide is #mm_1v1_wide or whatever).
-
make it possible to click the MM button to join that chat channel, and have the UI pretend it's not a chat channel but a room. Like this:
[Spoiler]This way you can do all the usual room stuff like talking to people before (and after) a game, see who the other guys are gonna be etc while it still being MM. The MM chatroom fills a very similar role to the extra spawning waiting rooms in the posts above but has the various advantages of MM. It doesn't even preclude having those waiting rooms.
+1 / -0
|
quote:
That does not sound particularly nice. Speccing games is a nice activity while waiting. Do you propose this to minimize infra changes? Ideally there would be some way to "ping" players speccing that their room requires attention (for start vote for example) |
I wrote this because it is    Brackman's solution to people not knowing that the waiting room exists, or more specifically, people being quote:
Unaware that they are even in the room, or at least that there is activity in it, because they are busy spectating the big team game. |
and I haven't seen another one. quote:
Staying in the waiting room relies on the merge that might sometime not happen (ex: vote or above the threshold but game not starting) |
This is certainly a concern, so the system should focus on making sure that people in the waiting room are no worse off than the running room. This means that there has to be quite a high chance of the waiting room generating a game in cases where it isn't merged.
+0 / -0
|
Question: when you mention infra changes, is there any reason why any of the above solutions couldn't be implemented only on lobby side? The lobby can move (automatically) from one room to another and/or any special autohost (if needed) could instruct its clients what to do via special chat messages that are not shown in chat. This would also make testing/deployment easier as you could leave the server alone and use the test version or something, so in case of issues not all server suffers.
+0 / -0
|
I comment on that between proposals. quote:
...
This still has a few issues, but I stopped there because so far it all sounds implementable from the lobby. Here are some problems, some of which seem solvable with some infra work, but which would significantly complicate the system.
...
...
The above seems to necessarily require infrastructure work as it requires a way to put people in rooms at the top of the waiting list. Technically the smallest infra change is to let the lobby say where it wants to go on the list, but letting clients do that seems questionable. So infra would have to handle merging rooms, and once it does that it may as well handle spawning rooms as well. |
Telling the lobby to do things via chat is a bit fragile. People can move between rooms with it, but I wouldn't want to use to reorder the waiting list. And there effectively isn't a way to do things like change maps just by telling lobbies to take actions.
+0 / -0
|
|
|
As much as many people love the game in Room Team Wellcome, this type of game is only a minor variant of the main game ZK, which can only be seen in small rooms with max 5v5. Definitely enter 32 different players in the same room, it creates a confusion of playstyles and ultimately just creates a rush to create zenith or starlight. The important thing is to decide something about it and in any case if you want to entice players to move to other rooms you could: 1. reward with elo given 1 as a value in team max 5v5, while with elo 0.5 in case of victory in team wellcome; 2. or reduce the welcome team to max 16 players; making it more playable
+0 / -0
|
|
|
quote:
1. reward with elo given 1 as a value in team max 5v5, while with elo 0.5 in case of victory in team wellcome; |
The expectation value of elo change must be zero if your rating matches your skill. Multiplying this change by 0.5 or 1 does not incentivize anything. Introducing an additive shift of the change away from zero would mess up the whole system. Ok, yes, this is definitely an improvement. I was happy to see it at the time! I'm looking forward to further improvements to actually solve the problem.
+0 / -0
|
Brackman I didn't mean as calculation method it was just an example: if, for example, at the end of the game in team wellcome I have won 2 % elo points, I am assigned only 1 elo % point (half) while if I win in a small room game I win 2% points and 2 are counted.
+0 / -0
|
If I understand correctly you would like smaller team games to have a larger impact on your ELO than large team games? (my impression is that that is already the case) I also do not think the hypothesis of "entice via ELO gains" holds for most players, and we would not want that to be the case anyhow. There will be many people that want very large team games to troll (or have fun without lots of stress). The issue is we don't have enough players to easily split in such a way that: players that want small games play small games, people that want to troll more get a 10x10 to troll.
+1 / -0
|
By keeping elo change responses in spoilers, I try to prevent the thread from derailing. [Spoiler]First, rewarding small teams players with elo (actually WHR) doesn't necessarily solve the problem of only one room. Even if it did, we wouldn't want to mess up the whole rating system for that. And finally,   manero's elo change would either not even be a reward or mess up the system. In case somebody doesn't know what expectation value of elo change means, it is p*W + (1-p)*L = 0 where p is your win probability, W the elo gain if you win and L the elo gain if you loose with L = W*p/(p-1) < 0. If you multiply W and L by any equal factor, it does not reward you more because on average, you loose as much as you gain. It can worsen predictions and balance a bit though. But if you change W such that p*W + (1-p)*L is no longer zero, the whole rating scale will be massively inflated or deflated such that ratings become entirely meaningless. The other parts of manero's post are a valid attitude but it will be hard to get a consensus on that because a significant minority is against it. There are so good suggestions in this thread that we should discuss in more detail, like variants of room splitting, MM "rooms" and the waiting room.
+1 / -0
|
i mean whats the point? people would then just leave one of the rooms and go back to the one with more players, or people just stop using autohost for large teams and instead use custom lobby that wont get raped by some whiner who wants to play small teams...
+0 / -4
|
