I have this simple cardgame which supports internet play over a bnet like client/server architecture. For possible exploits, I should probably have the clients ask the server for a new card, but I'm a little unsure how I should do it while keeping possible lag in mind.. Step 1: Give server DrawCard request. Step 2: Play animation while waiting for server response. if(response) Step 3: Show card with ID equal to what server drew. else MessageBox.Show("Waiting for server..."); During step two, should I test for lag? IE, server hasn't responded before animation is moving to its end, pop up a messagebox showing something like "Waiting for server..."? At the moment, I do not have any method to test for continueous connection, but I'm going to implement a countdown for each connection at the serverside, where clients have to respond before 0 or get disconnected.

In a turn-based game (I think that's the case) lag shouldn't be a big deal. Playing a fixed length animation wouldn't be good... some looping animation would be fine and normal. Like an animation of a spinning card perhaps.

Looping animation, that's clever. :)

How often do you think the server should poll for client response before it is marked as dead? 8 seconds sounds reasonable to me when taking into accounts of client lag spikes..

Edit: by client lag spikes, I mean stuff like the client ISP might have some issues for a couple of seconds, or anything like that. I'm not really sure how often issues like this happen, but disconnecting a client would IMO be a little harsh if it's only for a few seconds..

On the online poker games I play, you get maybe 15-20s. That would seem reasonable, if you also want people to have time to think!

You could give people more time to think than it's required to disconnect them by having the client send a message saying it is still connected.

Actually, I think I would have the server do a RequestClientResponse to each client every x seconds (or even these requests over a fixed time interval in order to avoid hickups), and have the client respond to the request in background - no matter what state the client is in, as long as it's connected. If they don't answer within the timeframe set by the server, they get disconnected (or the game is halted, while clients get a "Waiting for user %user%" message. Clients may then disconnect that user, and game is continued as before.

In other words, I think I'll let my users have infinite time to think. If it becomes a problem that people exploit and ruin games for others by purpose, I'll probably set a time limit per user turn and use that as the actual connection test, as you proposed, Dooogh.

I understand that my approach might seem a little naive, but this card game isn't supposed to be anything real, it's just a simple game to experiment with internet play so I can integrate it into a RTS at a later stage! It's actually just a multiplayer tweaked version of Blackjack. ;)

Thanks for the answers, both of you!

Edit: You know what, scratch that. There's no good reason not to go for fixed turn length and then disconnect or let the other clients disconnect a player who haven't given any response within the timeframe of his turn. I was thinking of trying out the above so I would have a firm idea for my RTS, but it's not very complex, and it would be kind of stupid to use such an approach in a turn based game. If this was a real (fun!) card game, I would probably give the players the ability to pause and unpause. (Friendly game, bathroom breaks etc).

[Edited by - Nunyah on August 4, 2008 8:11:32 AM]