Now you need to pick the kind of interface you're going to use. I assume you'd be using network connections since that is the general idea brought to mind when someone mentions multiplayer.
For that kind of thing, the most general next step is to determine the type of protocol the game uses to communicate between it's various parts. For example, one version of the game is generally the "host" and the others conected to it are "clients." They swap messages between themselves to comunicate different aspects of game play, even if all clients actually do the work of rendering the game images. This means that each player who is assigned to the host receives a "player number" or "Player name" that precedes each message, so that the Host version can tell who did what.
Second, the kind of message sent should also be worked out, for example player "jack" moves forward and sends the message "gameid: jack: up" for pressing the up arrow of forward on the joystick. The Host recieves this message, checks that the game id number is it's own, checks that jack is a player in this game, then extracts the command of up to move jack forward. For most cases, paticularly if you're going to allow dial up connections toplay, these messages should be short and to the point, possibly even a number. Then, when a command message is recieved by the host it sends out a message to all connections to say "jack has moved up" one slot or whatever, so that everyone has their game data updated properly.
in a round robin game, each message received can be selected from a specific player, so that the players take turns before the game continues. In a live action, you'd probably allow message to be received in any order, but would "pick out" those for your game and the host's selected listed of players as above.
So that is the next bit it; decide what these messages are, what they contain, what order they are in, if there is any time lag adjustment needed for fast connections versus dial-up, and what the general messages to all clients should look like.
And when you're done with that, then you need to build the join game section, the leave game, the test for games in progress, and the code that any Host sends to indicate that player slots are available. When that is done, you should also include a regular check for players whose connections may be lost, so that the game doesn't "hang" in the event.
Are you starting to get an idea of what it's all about now?
S.
Any truly great code should be indisguishable from magic.
