Re: Breaking matchmaking deadlocks

You presume correctly - it's that corner case I'm trying to avoid; but as
you describe, having a player host an empty match for a random amount of
time before returning to searching should be enough to ensure it doesn't
become too big an issue.

Of course, we won't really know if we have enough churn to avoid the problem
entirely until we launch... J

On Sat, Jul 17, 2010 at 7:51 AM, Jon Watte <[email protected]> wrote:

>
> 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
>
>

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