So, the !join issue is resolved now?

Not really, afaik nothing changed..
we agreed that it would be nice to propose server change instead..

and wolas made the !join patch for SL but it wasnt discussed at the meeting.

Oh noes... the meeting-malaise, it has reached spring.. and not even free donuts.

Next we have a gamedev meeting minutes.. and a mapdev meeting minutes.. all agreeing on stuff, voting who stands behind what demand..

I shall not have a part in this... cause one day, there will be this meeting moments were this topic comes up..
"Games who touch the limits of good taste"

conclusion: Ban them all. Just because something is organized, it doesent have to be good, take the mafia for example. Well, i can understand it for lobbydevs, who have to find a comon protocoll..

well, a patch is written, that is a start right?

Change request -> change proposal + vote -> implementation.

That means a 3 week timespan from presentation to delivery. If it is kept up, changes can be routinely deployed every week.

If the old way was better there wouldn't be any need to try this in the first place.

that indeed was quite stupid, cheese (where you quoted licho). pure trolling.
smoth, wolas patch was written before the meeting, is not related.

maybe we should include autohost devs in the lobby dev meeting too?
i guess it woudl only add bibim, and he might not often have time anyway... so no big deal eitherway. i would say yes to that.

The entirety of the spring dev community, from engine devs to lowly mapmakers needs to enter group therapy.

Hello, my name is Pic.

And im an addict to trolling. I even joined this Theraphy just to get you going.

sorry I didn't make meeting - was driving for 16 hours last weekend and had to sleep. spaced going to the meeting. if we're having another this week, I'll set myself a reminder to be there.

so juggler is about matchmaking?

if we're already implementing new protocol, maybe we could consider the merits of matchmaking systems from commercial games.

matchmaking process:

• client sends command "I want to join these kinds of games (choose from 1v1, 2v2, 4v4, ffa, [anything]), running these mods (choose from BA, ZK, KP, [anything])"
• when enough people match a game filter, given a few (10-15?) second delay to allow time for people to queue for larger games, the server can offer a specific game type to all players "there's a 4v4 BA ready!"
• if all users accept, it moves them into a battle and starts a countdown to start the game
• if not all users accept, the game wouldn't work anyway (whether or not they were forced into the game) - server asks a couple of players if they want to fill the slot. first one to answer gets it.
• game starts, plays, great success

other perks - let people view how many players are currently queued for different kinds of tags (5 players with 4v4+BA, etc), how long it takes on average to wait for a game with a specific tag set, how many players are in currently-running games, how many players are in long-running games (and likely to requeue)

for anyone saying the accept process is unwieldy or takes too long - imo it can still be much faster than waiting for a normal game to start, and it's way better than getting ingame and realizing one of your players is afk

@aegis:
Yes, except I wouldn't give people the ability to decline later. If they chose to play a game type, then they should be put in the room and the game should start.

If you do want to give the ability to people to back out prior to start (which shouldn't be allowed always imo) it should be by them leaving the battleroom, which would then close it as well, and place the other players back in the queue. Although I'm not sure that's really good either, because it allows people to skip hard opponents (often done for elo climbing), but if they take an elo punishment for that it would be ok I guess.

Also, one may want to consider whether entering a custom battleroom would make you automatically leave all queues or not.

if they're abusing it, maybe self-regulate? like leaving a battle could = forced dequeue for a few minutes, or keep track of how many times they've done it...

the reason for accept/decline shortly before the game starts:

maybe they're making a sandwich and won't be around to place or order their units. they didn't know a game was starting yet (especially if they just spent 20 minutes waiting and wandered off), so they don't have the mental priority to stay at their computer.

maybe they changed their mind about playing or about playing that game tag and don't want to be penalized for leaving from inside the game.

if someone *does* deny, the matchmaking process removes them from the queue and slots in the next available player. if someone accepts, you know they're ready to play.


to fix people leaving battles to elo dodge, you don't even need to show them their opponent before the game starts - we could implement a command to toss everyone directly in the game after a countdown.

On second thought I guess that can make sense due to probably very likely long waiting queues, which may well be 5-10mins+ initially if elo level similarity is desired.

Prompting people before the game starts slows down the system for everyone.
If a client joins the matchmaking queue then he should be ready to start immediately. If he wants to make a sandwich, he should leave the queue, finish his sandwich, then join it again.

Just my $.02 ofc, but it's how matchmaking works in most games I've played.

aegis we would be better off if join was implemented. Licho's 90% complete autohost based matchmaking could be completed. A server side matchmaking system would take a lot longer to implement.

don't forget zydox then :)

This.

I'm just a player, not a stakeholder, but frankly I think Licho's system was *almost there*. It was absolutely frustrating often, but losing it has been sad. We got FFA games going! FFA! Do you guys know how hard it is to get people playing FFA?

The !join system is the shortest distance between "idea" and "implementation". If the lobby protocol needs anything more elaborate for matchmaking, it's to have a mapoptions.lua-like system for bots so we can have custom GUIs for bot-commands. That is, a way for a host/bot to send a GUI to a user and the user can reply through that GUI.