[Tutor] how to select a player to play first on a multiplayer game which runs on IRC

[Dave Angel]

On 04/19/2012 06:54 AM, Surya K wrote:
> I am writing tic tac toe game which runs on IRC (i am using freenode now).
> Each player will be a channel member. So, players send private messages between each other to play game. This sounds fine but I need the below things to get done, but I don't know how to do them..
> How my game works:
> Each player will have my program (tictactoe.exe).
> So, each player has to enter a unique Nick Name for them and a their's friend's nick name to play :
> ## Now, I want to know whether the player is on the channel or not. for that I need a list of nick's on the channel. How to get them?
I can't help there.

> The biggest problem is here:
> ## How to select a player to play first... ??? How do I get this done?
>
>

In a peer-to-peer connection, there are a number of situations where you
have to break symmetry.  This is one of them, though not the first. 
Since you don't have a 3rd party arbiter, the two endpoints have to
agree between themselves which of them is to be the arbiter when both
sides need to agree on something.  Once you've chosen the arbiter, then
each decision is made by asking the arbiter.

Start by choosing a large "random" number (or guid) at each end.  Each
sends his own guid along with the two nick-names to propose the new
game.  One of the guids will be larger, and that machine is the arbiter.

The first conflict to be resolved this way is not who goes first, but
how you make sure you only have one game between any two endpoints. 
What happens if more than two players are present, and what happens if
more than one of them picks the same nickname?  Are you going to permit
one of the players to play against two others at the same time, and how
will you keep the games straight?  You need a connection token for each
running game, and that's probably the first time you need an arbiter.

The second case is choosing who goes first.  The arbiter probably
chooses that randomly, and notifies the other player.  The third case is
how to handle miscommunication.  Messages can be lost between the end
points, and you may have to reconstruct the state, so both ends get back
in synch.  Fourth is how to quit.  If one player quits, the other might
not get notified correctly, so you have to keep the connection token for
a while, to aid cleanup.



-- 

DaveA