thanks for the tips jobem
yeah we have already started tinkering with aquaserver so that messages are only sent to groups of users, so that you at least only have to deal with messages relevant to your own game! hooray for open-source
the approach we are currently leaning towards is to classify all events as
- critical: meaning that the event cannot be executed until all the clients have received and acknowledged the event
- non-critical: the event can be executed immediately but notification still has to be sent to all clients, ack is not required
- local: the event does not have to be communicated to the other clients
so a critical event would be something like attacking another player's units, they have to have ~not~ moved their units since you sent the attack order, otherwise your attack message has to be rolled back.
a non-critical event would be the completion of a new unit. eventually they need to know about it but it is not time-critical for the other clients to know
and a local event would be choosing to build a new unit... the other players don't need to know about it until it is complete
critical events therefore are the only ones that we need to care about latency for. and hopefully there won't be THAT many of them. (even a person clicking and dragging at a huge rate might generate one of these only once every 5 seconds or something). it depends a lot on how we design the gameplay too as to how often they occur.
our current idea for approaching the critical events is that they'll have to be acknowledged by each player before they are executed by any player, including the originator. to handle this we were thinking that when a player generates the event, it is shown as a ghost and some sort of message pops up 'mobilizing forces' or whatever while the message is sent and acked. once it has been acked by all the players then it can be executed... and if it's rejected then it gets cancelled. this allows us to (fairly) gracefully back out because nothing has actually been executed yet. and the player can be informed that 'communication lines were down, order cancelled' or something. and hopefully the delay would never be more than a couple of seconds...
this is where we could modify the server as well, it could handle the final ack of critical events, not sending it until an ack is received from all players, and cancelling it if one player rejects the event. this avoids the problem that would occur in pure flash of a massive cascade of rejection messages that would have to be sent to all the players.
thoughts anyone?
