Re: Breaking matchmaking deadlocks

Personally, I've used the IP address of the nodes as the tie breaker. It's
guaranteed unique, and it's guaranteed consistent, assuming that each box
tells the other box what IP address *it* sees (so that you don't use the
local, inside-NAT interface address).

Somewhat related: for Xbox Live Indie Games, you don't have access to
Live!(tm) Leaderboards(tm), so I have written a component that emulates it
using a gossip protocol over random matchmaking, similar to that Halo
approach. In this particular case, I first try to find a suitable match
using matchmaking and attempting to join, and if that doesn't work, create a
session. This ends up creating the right number of sessions vs players, as
long as you have a reasonable new player join/leave rate, and it's really
simple and robust. The data flowing over the connection is highscores,
rather than gameplay controls, but the mechanism really is the same.

There's one corner case, that I presume is what you're trying to avoid by
both hunting and hosting at the same time: If there are only two players in
the world, and they both try to start a game at almost exactly the same
time, they'll both end up creating sessions and not talking to each other.
However, in practice, this isn't a big deal -- the only thing I do to
mitigate this is to make the amount of time I try hosting a session before
going back to searching be random. That way, one of the two in that bad
example would end up joining the session of the other. More realistically,
if you have any real amount of users, there will be enough churn that
everybody will be paired up in the appropriate host/player ratio.

Sincerely,

jw

--
Americans might object: there is no way we would sacrifice our living
standards for the benefit of people in the rest of the world. Nevertheless,
whether we get there willingly or not, we shall soon have lower consumption
rates, because our present rates are unsustainable.



On Fri, Jul 9, 2010 at 12:38 AM, James Robertson <[email protected]> wrote:

> Yes, pretty much any meaningless number can be used.  The reason I
> suggested using a timestamp is so that the player who started attempting to
> connect first would be the one more likely to succeed.  Which isn't a huge
> deal in the grand scheme of things, but does appeal to my own personal (and
> slightly warped) sense of order.
>
>

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com