| 1 |
[q]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...[/q]
|
1 |
[q]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...[/q]
|
| 2 |
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.
|
2 |
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.
|
| 3 |
\n
|
3 |
\n
|
| 4 |
[q]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.[/q]
|
4 |
[q]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.[/q]
|
| 5 |
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.
|
5 |
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.
|
| 6 |
\n
|
6 |
\n
|
| 7 |
[q]You mean the ones who want to start a small game get frustrated? As much as they are in the current situation?[/q]
|
7 |
[q]You mean the ones who want to start a small game get frustrated? As much as they are in the current situation?[/q]
|
| 8 |
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.
|
8 |
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.
|
| 9 |
\n
|
9 |
\n
|
| 10 |
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.
|
10 |
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.
|
| 11 |
* Make 10 identical "special" big teams rooms, indexed by some number in their name.
|
11 |
* Make 10 identical "special" big teams rooms, indexed by some number in their name.
|
| 12 |
* 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.
|
12 |
* 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.
|
| 13 |
* The system initialises with the first room visible, and the others hidden.
|
13 |
* The system initialises with the first room visible, and the others hidden.
|
| 14 |
* When a room starts, another room (perhaps the lowest hidden one) becomes visible.
|
14 |
* When a room starts, another room (perhaps the lowest hidden one) becomes visible.
|
| 15 |
* Additionally, when a room starts, everyone in the waiting list is sent to the newly visible room, rather than loading into the game.
|
15 |
* Additionally, when a room starts, everyone in the waiting list is sent to the newly visible room, rather than loading into the game.
|
| 16 |
* When a room ends, everyone in the room is sent to the visible room, and the room that ended is hidden.
|
16 |
* When a room ends, everyone in the room is sent to the visible room, and the room that ended is hidden.
|
| 17 |
* Clicking on a running special room rejoins the game without entering the room (like MM rooms).
|
17 |
* Clicking on a running special room rejoins the game without entering the room (like MM rooms).
|
| 18 |
\n
|
18 |
\n
|
| 19 |
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.
|
19 |
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.
|
| 20 |
* 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.
|
20 |
* 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.
|
| 21 |
* 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.
|
21 |
* 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.
|
| 22 |
* 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.
|
22 |
* 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.
|
| 23 |
* 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.
|
23 |
* 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.
|
| 24 |
* 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.
|
24 |
* 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.
|
| 25 |
\n
|
25 |
\n
|
| 26 |
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?
|
26 |
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?
|
| 27 |
* Make 10 identical "special" big teams rooms, indexed by some number in their name.
|
27 |
* Make 10 identical "special" big teams rooms, indexed by some number in their name.
|
| 28 |
* 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.
|
28 |
* 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.
|
| 29 |
* The system initialises with the first room visible, and the others hidden.
|
29 |
* The system initialises with the first room visible, and the others hidden.
|
| 30 |
* When a room starts and there are no visible-non running rooms, a hidden room becomes visible.
|
30 |
* When a room starts and there are no visible-non running rooms, a hidden room becomes visible.
|
| 31 |
* Additionally, when a room starts, everyone in the waiting list is sent to the non-running visible room with the most players.
|
31 |
* Additionally, when a room starts, everyone in the waiting list is sent to the non-running visible room with the most players.
|
| 32 |
* [i]Any time[/i] 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 [i]top[/i] 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.
|
32 |
* [i]Any time[/i] 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 [i]top[/i] 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.
|
| 33 |
\n
|
33 |
\n
|
| 34 |
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.
|
34 |
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.
|
| 35 |
* 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).
|
35 |
* 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).
|
| 36 |
* Battle rooms have a new moderator-only settable integer parameter 'spawnmergethreshold', used by selfspawning rooms.
|
36 |
* Battle rooms have a new moderator-only settable integer parameter 'spawnmergethreshold', used by selfspawning rooms.
|
| 37 |
*
All
instances
of
"room"
below
refer
to
a
battle
room
with
selfspawning
set
to
a
particular
identifier,
such
as
'bigteams'
|
37 |
*
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.
|
| 38 |
* When a room starts, if there are no non-running rooms, a new room with identical settings is created.
|
38 |
* When a room starts, if there are no non-running rooms, a new room with identical settings is created.
|
| 39 |
* 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.
|
39 |
* 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.
|
| 40 |
* [i]Any time[/i] 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.
|
40 |
* [i]Any time[/i] 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.
|
| 41 |
\n
|
41 |
\n
|
Vote to split Teams - All Welcome into 2 smaller teams rooms?