MetalSucker's lobby simplification thread

[MetalSucker]

I decided not to clutter the forum with random ideas.

I don't know if this has been previously discussed, accepted or rejected so feel free to point me in the right direction if there's previous work / conversation regarding this or tell me to gtfo if you don't like/want it.

tl;dr version: make a very simple GUI with a big button that just automagically finds a 1v1 game and starts it with minimal player effort and in the shortest time possible. All advanced options and what is currently considered a lobby should be hidden from the player - unless of course he wants to see it.

---- warning: long post ----

I'm not asking anyone to do it, I will attempt to do this myself.

I believe I can implement a lot of this without any lobby protocol modifications, basically by ripping apart springlobby (because multi-platform + seems fast + I understand most of the code I've looked at).

I will ignore single player/tutorial missions for now because that's a whole different topic and the content just isn't there yet, but multiplayer works - and it rocks hard.

What I would like to achieve is not really a lobby. I would call it a multiplayer auto-game finder and launcher, maybe a "non-expert mode" based on already existing lobby protocol libraries. In the end it should not block any other fully featured lobbies by functioning as intended, and this way to do things could become a part of them.

What I want to do for now is a big "Find 1v1 game now" button, with the rest of the UI showing just the following:
- how many people are online (using this lobby/launcher or whatever you want to call it)
- how many games are in progress -> a list of progress games that can be spectated

The Launcher would be restricted to one game. The way I'm imagining it, this is a tool that can be used by people who distribute their games, a tool that would make it dead easy for their players to start an online game. Of course the whole restriction is basically a string in a config file, a simple filter - but invisible to the end user.

If people want to see other spring games there are a few options - banners advertising them (yes, banner rotation within the launcher) or simply going to 'expert mode' or launching a fully fledged lobby, also packed with the distribution.

Distribution = this launcher + at least a lobby + engine version required + game + maps, etc., a package that has all content needed, with minimal/no other downloads required for that specific game



I will only address the "Find 1v1 game now" button since I believe this is essential. Yes, there could also be "2v2", "3v3" etc buttons, but all in due time.

A basic, naive usability metric is "how many clicks/actions do I need to do before I can actually play the game". Another metric would be "how long do I have to wait before the game starts".

While the second metric pretty much depends on download times and/or packing launcher + game + assets + maps together, the first one requires a bit of tinkering to get right.



The Launcher would need to know the following things:
-game name & version (for filtering)
-engine version needed (this should already be downloaded with the distribution)
-list of 1v1 playable maps - something like 5-10 decent maps will do for now.

Upon launching and logging in, the launcher should see if there are games with newer game/engine versions and simply nag the player to update. Since the available list of "accepted" 1v1 maps should be defined launcher side, there should be a mechanism to update that too.

Playing any game and even logging in using this launcher should be impossible unless all elements are up-to-date (to the versions the game creator decided they should be). A lot of this can depend on already implemented update mechanisms. An alternative way to do it is point the player to an archive/torrent with a full distribution available for download, with all the updated elements inside.

If login is successful and everything has the right versions the launcher grabs the battle list and looks for a battle with the following characteristics:

-not already running
-exactly one player inside not spectating
-expected spring engine version, game version, already have map downloaded and map in "accepted" 1v1 list for launcher
-game description contains the following;
SpecialString_1v1_%random_string%

where SpecialString would be something along the lines of "autofinder" or some unique prefix that players using regular lobbies would not normally use when creating custom games. This prefix could be used as a filter for hiding such games in regular lobbies.

%random_string% is needed and should be long enough to accommodate any surges in player/running game numbers.


Should no such game be found, the following should happen:
-the Launcher starts a game with said game description
-a random map is chosen out of the "approved" 1v1 maps list for the auto launcher (to be determined what maps)
-player joins a team automagically
-the player is told to wait until somebody comes in.


Should such a game already exist, the Launcher would attempt and re-attempt to join the oldest one for a number of times (or a random one?!) then move to the next one. A reporting mechanism for "stuck" games would be nice.


There is no chat, no re-defining map start positions (since there's an "approved" 1v1 maps list, those should have excellent starting positions built in), there's no !map (random).

Anyone wanting those features can use a fully featured lobby.

The second there are two people in such a game, they are each sent to opposing teams and then auto !start.


Of course there could be such thing as "average wait time for 1v1 game.." but those are final touches.

Yes I do want to hear from you. Feel free to be fully honest, I'm not easily insulted and the only thing I want is for people to play spring games. This is about making it dead easy for them.




Multiple edits: making things clearer.

[smoth]

How will you handle the rapid system where games are downloaded to the player's machine. It would be good to have some way of showing progress and letting the player know how much longer they have. Ideally auto starting the dl once they start the lobby.

also a point of interest. Spring versions are stored in their own directory, each having their own copy of unitsync. If the installer is self contained(portable spring) the maps will not be visible to all engines and the directory with that engine version will have to have a sybolic link to the games and maps dir or whatever the 'nix version has. some of the games are still running really old builds of spring. Is the multi version support a non-issue for this "basic" lobby?

[MetalSucker]

It's mostly a non issue because such things are handled by fully fledged lobbies. This is a tool that can be re-configured in the context of each game before distributing to the gamers. It's not a multi-game multi-engine tool - but it will probably benefit from already existing download systems for updates and such.

However it does not in any way prevent the user from using a fully fledged lobby or knowing about other games, in fact I believe that should be encouraged.

This is a sort of 'less is more' kind of approach. And I know the value of a tool that does just one simple thing but does it really really well. Baby steps, but it's a start.

[smoth]

sounds pretty cool, will you put the source up on git?

[MetalSucker]

Yes, but it's not written yet and I'm looking to get as much feedback as possible from people making the games / running the servers before going ahead and doing it, because spawning games like this could potentially affect them.

Regarding the update, I think there should be a separate executable that handles full update for that particular game, with pretty progress bars. This is better since there could be cases of reverting to an older version or whatnot, but I'd rather focus on the actual "matchmaking protocol" for now, since the update mechanism that is already in place looks functional to me.

[smoth]

It's all good man, I am just trying to ask questions as I come up with them. I hope I can be helpful with my random queries

[gajop]

Regarding the matchmaker, as that's the key concept:
1. Lobby protocol modifications (or addition of new servers or bots) are required for it to function correctly. You need at least one matchmaker entity (most likely a bot or the lobby server itself) to queue in. The matchmaker should then inform you (the player) when a game is ready which would likely transfer everyone to a battleroom and immediately start.
2. Regarding the actual matchmaking details, I think you haven't spent enough time thinking about this. You haven't considered the following:
1) different queue types (not just match sizes, e.g. 1v1, 2v2, ... , but also "normal/casual", "ranked", "sillymaps", etc.)
2) queuing with friend(s)
3) ELO/Trueskill balancing of matches
4) player readiness confirmation

And I repeat, there's no reason to hack the current battleroom system with "SpecialString" stuff. If matchmaking is to be added, it should be done decently, otherwise you are just doomed to experience the same fate ZK's juggler did.

[MetalSucker]

1) no, the player just spawns a game if none is found, based on a game title format, I have detailed this. No protocol modifications needed.

2) I have considered them and have specifically said I don't care about them RIGHT NOW

take evo for example - there aren't enough people for 1v1 and you're talking 2v2. All in due time.

This isn't a generic fix all, it's a start.

Player readiness confirmation for 1v1 = when both of them are in the battle room, no need for it.

Everyone seems to be building lobbies with the sole purpose of implementing every feature out there, this is the opposite, implementing features in a way that gets new people playing as easily as possible.

[gajop]

Yes, you have detailed something that's nearly in every way inferior to ZK's juggler (a system that has existed for years), and that has showed that treating battlerooms as a matchmaker is a really bad idea. All this leads to a fat client, something we don't need.
The only 'simplification' present here is laziness to do something about the lobby protocol/matchmaking bots - the part that actually needs changes most of all.

[MetalSucker]

It's supposed to be inferior to pretty much any lobby, it's supposed to have less features, it's supposed to hide functionality.

I have not been aware of ZK's juggler and I will look at what went wrong with that.

A fat client might be exactly what's needed for end users.

[Licho]

Work on matchmaker is already in progress. We will make it work without needing to change lobbies at all.

You simply join "queue" battle room and when game starts it starts "outside" the queue room automatically. It can all be achieved without touching lobbies or protocol.
It will simply count all people in the queue room with map as "in queue", when enough people are in it will force move them to newly created room and insta start that.
Game room will create start script regardless of who are in it/teams in it, so even if you see 11 in team 1 and 2 in team 2 in lobby, in reality game will start with correct clan/elo balanced teams.

We plan to add 1v1 queue (with max elo difference about 200), 2v2 queue, 3v3-6v6 and 5v5-10v10.

Code will be part of autohost system so it can support any mods/games/engines.

If you want to help - #zkdev.

[Licho]

Btw. ZK also has a working matchmaker independent of lobby rooms - planetwars matchmaker where you join by attacking/defending planets. But that is built completely independent of lobby protocol (does not have any "queue room") and supports only ZK planetwars games.

Planetwars matchmaker, unlike juggler, worked great and got good feedback so some of its features will be used in the incoming queue room system.

[Jools]

I think doing a less cluttered lobby is fine and people may want that. But I don't think anyone wants the game to start automatically, without pressing ready etc. That's invasion of user's privacy. People may be doing other stuff in the meanwhile, don't autolaunch stuff for them.

[BaNa]

The planetwars thing was awesome in concept and in the flesh as well, sadly for me the game (ZK) became increasingly incomprehensible with updates.

I totally agree with the need for a simple matchmaking / lobby client, my game-using patterns have gotten to the point where I never click browse servers in the games I play (tf2 and ql), i just click "play game" with the mode I want selected. When I tried to return to spring after a while, the tedium involved with lobbies and battle rooms and waiting and all that made me drop it very soon. I know part of that is the nature of fps vs rts strategy games, but a large part is that the current systems in spring (besides ZK) are not really designed to facilitate a better player experience.

[Jools]

Compare spring lobbies to warzone or phoenix worx. They work basically the same way.

[Silentwings]

Work on matchmaker is already in progress... Code will be part of autohost system so it can support any mods/games/engines.

@Licho: I think it would be great to have a matchmaking system with a "queue" battleroom, but I would want to specify what types of games it could spawn (and ofc which rapid tags & maps were used, else incompatibilities & other chaos etc etc).

For example, for BA, it would be great to have it used tor 1v1s, 2v2s, maybe even 3-4s. But we wouldn't allow it to be used for anything larger, since experience has shown that large games need more careful infrastructure (admins, modoptions, voting, etc) or they become open to abuse by a minority - and on our SPADS hosts over the last couple of years we already have developed a very effective and well maintained infrastructure for this.

Another example; for BA Chickens there are several difficulty settings, presets & luaAIs involved so I would imagine specialized hosts would always be needed there.

I imagine the other sets of game devs would feel the same way, although since (imo) the BA/BAR hosts are the most developed/complicated set of non-Springie-Nightwatch architecture, we have probably evolved more specific needs than most.

(Sorry that this is not the topic of the thread! Imo split out matchmaking discussion.)

[Jools]

I imagine other game devs would feel the same way, although since (imo) the BA/BAR hosts are the most developed/complicated set of non-Springie-Nightwatch architecture, we have probably evolved more specific needs than most.

Again an arrogant and blatant lie.

gajop: User was warned for this post. Don't resort to personal insults.

[Licho]

Each queue has its own settings - you get what you see in queue room.. If you join 1v1 queue it wont ever start 2v2 game..

Map normally cycles there after each battle starts, but to give people time to load the map it stays same while people wait in queue.

When someone new joins the queue and there is enough for a game, start is scheduled in 1 minute, if someone else joins it can increase to up to 3:00.

So by purpose the queue can contain more people than needed for the game. When there is more people, it will start several games at once, splitting people by skill and clans.

[MetalSucker]

Whether chatroom based or otherwise...

I believe players should not be allowed to enter the queue (or even log in) if they don't have all the content downloaded beforehand, joining a queue just to have other people waiting for you to download is wrong.

Similarly, there were a few people complaining on steam that when they got Evo, it was 'just a downloader', not a full game.

I understand that a lot of work has gone into Zero-K, but Spring is not just Zero-K and there are a whole lot of assumptions there about large numbers of players available and about how a game should be started based on clans, etc. - those are elements that may not be found in all games, so there needs to be a common baseline to which game specific conditions, filters... can be applied. I don't want to do something ZK specific. If anything, it might start out as Evo specific (since it doesn't use all the bells and whistles for making a game) and go from there with a template.

Thanks for the feedback, I will attempt to create a very simple chatroom based 1v1 queue (with no content downloading permitted), since I understand people actually want the 'find match' thing but the host spawning could be problematic.

[MetalSucker]

Alice, Bob and Charlie are using the Launcher. It means they are full updated, have all the maps needed and upon login they are automatically joining channel MMLauncher, this is invisible to the gamer.

Neither of them are playing or looking for 1v1 games, but they are logged in.

Diane logs in using the same process and auto joins the channel. Since she wants to play she presses the big magical 'find 1v1 match' button.

In response, the launcher generates %uniqueid% and sends this to the channel:

Diane: want 1v1 %uniqueid% (+ whatever parameters, To Be Determined)

Since neither Alice, Bob nor Charlie have pressed the magical button, their Launchers are not in 'listening mode'.

Since Diane has pressed it and got no reply of any kind in the first 1-2 seconds, her Launcher is now 'listening', waiting for someone else to come and play.

If a number of seconds pass and nothing happens, no game is found, Diane's launcher complains in the channel:

Diane: stillwant 1v1 %uniqueid%


What this would do is signal the 'non listening' launchers, from Alice, Bob and Charlie that they should potentially do a non-intrusive notification of the player that there's a possibility for them to join a match right now should they decide to do so. This would be along the lines of "hey player, there's someone who wants to play 1v1 right this moment, click me to take you to the game!", but in a manner that would not upset them if they were in another window or working at that moment.

Charlie is probably watching his favorite TV series and doesn't notice anything.

Both Alice and Bob see the message on they Launcher windows and say 'oh cool, I wanna play!' and click the notification - surprisingly almost at the same time, just to make things more complicated.

Diane's launcher receives two private messages:

Alice: wanttoo 1v1 %uniqueid%
Bob: wanttoo 1v1 %uniqueid%

Don't panic!

Diane's Launcher puts out a big confirmation window:

Match has been found, accept challenge?
Yes / No

Upon clicking Yes, private messages are sent to both Alice and Bob confirming the 1v1 %uniqueid%

They both launch a similar confirmation window (not sure this is needed, since they just confirmed they wanna play by clicking the non-intrusive notification) and upon pressing YES, they each send their confirmation messages to Diane, although she just considers the first one, from Alice since she simply clicked the button faster and thus the confirmation message was sent first.

Bob is sent a "denied" message from Diane. The user interface informs him that although the current match has already started between other players, he's still able to find a match if he waits for a new player. Upon confirmation he sends a "want 1v1 %other_uniqueid%" to the channel, essentially starting where Diane was when she joined the channel.

Upon mutual confirmation between Diane and Alice, Diane sends host connection details, possibly even a password. Their launchers both leave listening mode. Diane sends "found 1v1 %uniqueid%" to the channel.



Now I'll go back for a bit where Alice, Bob and Charlie were not listening, and assume neither of them saw the notification from "stillwant" or cared enough to click it.

Enter Edward, who has just joined the channel after Diane's "want/stillwant" notification. He thus has no way of knowing that someone already wants to play, thus issues a:

Edward: want 1v1 %ed_uniqueid% (+whatever parameters)

Diane has not until this time found a game, and neither Alice, Bob and Charlie have bothered to play with her, but her Launcher is in "listening mode". While disregarding her original %uniqueid%, she replies in a private message to Edward:

Diane: wanttoo 1v1 %ed_uniqueid%

Same notification confirmation scheme follows.

Diane sends a message to the channel, broadcasting the cancellation of her original unique id:

Diane: cancel %uniqueid%

This tells the non-listening non-intrusive launcher notifications to take this into account.

Timeouts need to be determined.