Sign in to follow this  

Multiplayer TBS - Quitting Game

This topic is 3042 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm working on adapting a simple TBS game to network multiplayer. One of the things I'm grappling with right now is what should happen server-side when a human player quits before the game is over. So far, I've decided that the game should stop entirely. The question is, how soon? Basically I'm wondering if I should wait until all other players have taken their turns before saying "Oops, Player X has quit, so Game Over." Programmatically, this would be the simplest case for me (I can go into detail here if desired). What do you guys think?

Share this post


Link to post
Share on other sites
TBS = what? Turn-based strategy?

What happens when a user quits isn't really networking related, but game implementation related. If the game can't continue when one player quits, why would you allow the other users to take their turn still? They will just end up taking the time and effort for that last turn, just to be told "just kidding, the game actually ended."

I'd personally tell them immediately when a player has left. I'd hate to sit around waiting for everyone to take their turn when the game is already over. Though it'd also be handy if you allowed people to re-join a game after they leave ungracefully (like if their connection drops). In this case, I'd display a message that they left, and a timer stating how long they can wait for the user to come back until the game auto-ends, and finally the ability to vote on if they even want to wait for the user to come back or abort the game.

Share this post


Link to post
Share on other sites
Moderators: Please feel free to move this thread to "Game Programming" if you feel it belongs there instead (given Spodi's comment).

Quote:
Original post by Spodi
TBS = what? Turn-based strategy?


Yes.

Quote:
What happens when a user quits isn't really networking related, but game implementation related. If the game can't continue when one player quits, why would you allow the other users to take their turn still? They will just end up taking the time and effort for that last turn, just to be told "just kidding, the game actually ended."


I agree - that would provide a worse user experience.

Quote:
I'd personally tell them immediately when a player has left. I'd hate to sit around waiting for everyone to take their turn when the game is already over. Though it'd also be handy if you allowed people to re-join a game after they leave ungracefully (like if their connection drops). In this case, I'd display a message that they left, and a timer stating how long they can wait for the user to come back until the game auto-ends, and finally the ability to vote on if they even want to wait for the user to come back or abort the game.


Okay. The issue for me is a bit more programmatic in nature, if only because I'm not sure about the "best" way to do it.

A little more background: This game is being written in Java (*ducks*). Currently it's being written with blocking sockets (*ducks again*). For each turn, each player sends a list of actions to the server. Human players send their lists via the network. Once the server receives a list from each player, it executes all of the actions against the game universe and sends the updated universe back to each player. I'm using Java's object serialization to send the lists of actions and the universes over the network.

One relatively straightforward solution that I see for player-quit events is to send a list containing only a "quit action" to the server. Upon encountering this list, the server would stop waiting for the other players and halt further execution of the game. Another solution is to use the Composite pattern to turn the list of in-game actions into an action itself ("end-of-turn action" or similar). This has the advantage of being able to share the same interface with a single action.

Any other feedback is greatly appreciated. Please feel free to critique any/all parts of what I'm doing. :)

Share this post


Link to post
Share on other sites
You cannot do network programming and assume that everyone will play nice like that. You have to either put networking in a thread, or use select(), or non-blocking sockets, or asynchronous I/O, and react to network events as they happen. I see several problems with your current design:

1) Someone connects to your server using telnet, but then sends nothing, or just sends an infinite stream of spaces. What will happen to the game and the server?

2) Someone disconnects without sending the "end game" packet, so all you get is a "connection closed" from the socket when you try to read it. What will happen to the game and the server?

You should detect people quitting (as opposed to resigning the game) by detecting connection closed. If you want quick close notifications, you should also send keepalive packets every once in a while (say, every 10 seconds). In fact, some home routers will "forget" about connections if there isn't a bit of traffic on them now and then.

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
You cannot do network programming and assume that everyone will play nice like that. You have to either put networking in a thread, or use select(), or non-blocking sockets, or asynchronous I/O, and react to network events as they happen.


Sorry, I wasn't clear enough in my explanation above. Currently I handle each human player in a separate thread on the server side.

Quote:
I see several problems with your current design:

1) Someone connects to your server using telnet, but then sends nothing, or just sends an infinite stream of spaces. What will happen to the game and the server?


What do you mean by "telnet"? My game is not going to use the telnet protocol, if that's what you mean.

Quote:
2) Someone disconnects without sending the "end game" packet, so all you get is a "connection closed" from the socket when you try to read it. What will happen to the game and the server?


Basically a "Player X disconnected" message will be sent to the remaining human players, as opposed to "Player X resigned". Otherwise the handling will be the same.

Quote:
You should detect people quitting (as opposed to resigning the game) by detecting connection closed. If you want quick close notifications, you should also send keepalive packets every once in a while (say, every 10 seconds). In fact, some home routers will "forget" about connections if there isn't a bit of traffic on them now and then.


I agree about detecting connection closed and plan to do so. Thanks for the tip about keepalive packets and home routers -- I'll definitely think some more about this.

Share this post


Link to post
Share on other sites
Quote:
My game is not going to use the telnet protocol, if that's what you mean.


No, but that doesn't prevent someone from typing "telnet yourserver yourport" into a command line, and a TCP connection will be opened to your server. That same someone can then just sit there, and do nothing -- or can send arbitrary data to your server. Like paste the Unabomber manifesto, or send the output of rand(), or something.

Btw: thread-per-client is not generally a great idea. While it's easy to get running initially, it uses too many server resources when the number of clients grows -- and it introduces locking issues you probably don't want to worry about when the number of clients is low.

Share this post


Link to post
Share on other sites

This topic is 3042 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this