You got me totally wrong. What I tried to explain to you in my message is that what I consider the standard (for Spring, obviously) is what is described in the official Spring lobby protocol description. This document provides the "ready" status flag that is meant to be used by lobby clients to tell if the player is ready or not (cf MYBATTLESTATUS command). It doesn't matter if this is good or not, I'm just saying this is how it is designed in official documentation, how it has been used by all lobby clients in the past, and how it is still used by most lobby clients (including the main official one).Forboding Angel wrote:As battle.net has proven time and time again, a ready button is bad design. Obviously many lobby devs agree.
If you're using springlobby as some sort of metric for what is "standard" then ur doin it rong. I suggest using pretty much just about any commercial RTS game as your metric for what is standard. The obvious being battle.net because obvious reasons.
The reason I am annoyed is that this is such standard behavior that it becomes difficult to explain why it's standard behavior... Suffice it to say that it works well. There is a reason the companies use the method.
As long as this is the standard , I don't see why I would auto-spectate ready players. I could make it possible to prevent auto-start when a player is afk in a future version though.
That being said, I'm not convinced that the removal of the ready button would be a good thing with current Spring lobby architecture:
I never used battle.net, but is it really relevant to compare battle.net with current Spring architecture?
Does battle.net use the same server/autohost system with big rooms of 8v8+ players? (not matchmaking)
Do battle.net games require as much waiting and have as many spectators as Spring games, leading to a high proportion of afk players?