Long story short, can anyone recommend an article an creating a client/server model (preferably for turn-based games)? I''ve got a game design i''ve been hammering away at for about 6 months. We''ve made some good progress on design, art, backend game mechanics, and the GUI system. Besides AI, the other major game element that isn''t in there yet is multiplayer networking. I''m not worried about the actual mechanics of ports and sockets and things, but how do you set up the client server model? Especially for a turn based game that doesn''t require any live action? What things should each side be responsible for? I''ve looked through the articles section and yes, i''ve googled plenty. I''ve also read through posts and the Enginuity article. Any thoughts? thanks http://www.project-axis.net/

I suggest going with a peer 2 peer system. Turn based games dont have the time constratins for event verification, like RTS or other realtime multiplayer games. So the benifits of a peer 2 peer archicture, really shines for turnbased. Which are, complete state synchronziation and lower bandwith usage.

Bascially for this to work you will have to do some preplanning in terms of game archtecture. Every action which can affect the game simulation, driven by an agent ( a player or AI ) must go through a proxy object.

This proxy object, redirects events to their destinaiton, which can be a network broker object, or a similation object, etc..

Good Luck

-ddn

Actually, I''d agree with the original poster. I think that it is a perfect case for using the client-server model since time is not a constraint the game can focus on server side security by implementing a "request for operation" model, thereby eliminating most potential for cheating through binary hacking on the executable or interrupting the network data flow via a packet sniffer and outbound data replacement.

Here''s what I''d do. I''d make the client simply able to visually represent any data that is sent by the server. The client is also able to send data operation requests to the server. The server never sends anything the client doesn''t need or isn''t authorized to have (like too much map data).

The entire game state is played on the server. The client is simply a display for this data. This puts more resource constraints on the server but also makes it easier for the client to play the game with a crummy computer.

If the client says "Move ship 1 to position X" the server will first send the request through a authentication module which will verify the position of ship 1 and its ability to move to position X given the ships current state. If the server determined that Move ship 1 to position X was beyond the capabilities of this ship it would send back an acknowledgement that says "FAT CHANCE PACKET SNIFFER A-HOLE" or something like that. If the move command was successful the server would ack back to the client and say "move successful, here''s some new info about your new position ship position".

At least this is what I''m doing for my game.

Cheers, and good luck.

RandomTask

yes, I agree RandomTask. Now thinking about it, there are advantages for a server-client model TB game which makes it a better choice overall.

-ddn

thanks for the feedback.

the way i have it in my head is that every player in the game has the full set of data on their computer to work with (not necessarily visible to them though), only one player has an extra little bit on top of it which is the server. The server is the one that will actually crunch the turn when everyone is finished.

i also thought that every action needs to get checked in with the server, then the server routes it back to the other clients to update them as well. When the turn is procesed, the server would go though all the movement steps and combats and whatnot, updating all clients in sync as it goes. By the end of the turn, all clients should have fresh data.

What i don''t want is to have to check every bit of info from the client and get a response from the server before going ahead with it, for speed reasons. if every action needs an accepted / declined response, it seems like it would slow down an awefull bunch. maybe i''m wrong. am i?

any further thoughts?

I would simplify the processes, turn the server into a resource broker, much like how a webserver works. The pages are the various screens of the game. Develope a simplfied markup language whicih interperts a data stream to display data. It doesn''t have to be as robust as html. Something simple which recives data and displays and embedes the event components which the clients use to request changes to the data.

Once thats done, the client becomes a think client, which doesnt have to worry about simulating the game in any way. The server is whole authroative, and all the clients see the same data at any one time.

Well good luck.

-ddn