Sending to everybody - problem with things happening at the same time

Started by
6 comments, last by hplus0603 13 years, 3 months ago
Hi
Im new to networking and Im doing a turnbased wargame.
When moving a unit for example, i send command to server and server sends to all clients. This works fine.

But when i need to check something like when assigning an unique ID to each client what is the best way? I cannot do i simple broadcast to all becouse then the first player will be id=1 and the next one also (since it all happens a the same time players cannot see that an ID already has been taken).

Thanks
Erik
Advertisement
One easy way is to have each player submit a token: display name(might cause trouble if two players try to use the same display name), UUID(should be fool proof), something that uniquely identifies them. It doesn't have to be the same every time or anything just enough to hand them an id. Then when you broadcast ids back you attach the token and now everyone knows who's id it is. Another would be don't broadcast ids unicast them.

When moving a unit for example, i send command to server and server sends to all clients. This works fine.


Star topology. Great!


But when i need to check something like when assigning an unique ID to each client what is the best way?


The server should be in charge of assigning IDs. Each client will have a unique source IP:port address. The server can use those to separate the clients.
enum Bool { True, False, FileNotFound };
Ok cool.
But another thing that i wanted to ask what is the most streamlined way of doing it:

When setting up a game for example (lobby), each time a player clicks to change a setting (player setting, click a checkbox to allow random start etc) everyone needs to know what changed right?
But it becomes unpractical to define a network message (and corresponding code to act out the effect) for each little button in the game.

I mean when e.g. someone clicks to toggle (bool setting->randomStart). And i have 20 similar buttons (lets say) just on the lobby-screen. What is the best way of dealing with such network-commands?

Thanks a lot
Erik
I would have one config changed message, it would list the button and the new setting.

But it becomes unpractical to define a network message (and corresponding code to act out the effect) for each little button in the game.


For everything that can change in the game, you need some way of distributing that state. Whether this is through individual message types ("set-background-color <value>") or through addressable properties ("set-property background-color <value>") is really up to you. I tend to prefer the latter option.

When doing this, you'll have to watch out, though -- if two players want to change the same setting at the same time, you have to make sure that everyone (including the players making the attempts) end up knowing what the final property is. The easiest way to do this is to put the property on the server, and the player action just sends a property change request to the server; the server will figure out who wins and send property updates to all players, and the players always listen to the server and show the data provided by the server.

This architecture is one of the ways that network games generally differ from single-player games: GUI -> request -> server -> authoritative data -> update -> clients
Figuring out how to address the different pieces of game state in a way that is consistent, secure, and ideally hides latency, is a very important part of networked game architecture.
enum Bool { True, False, FileNotFound };
But if each client listens to the server and shows that data (you mean each client should not store data like settings?) wouldnt that mean a lot of unnecessary traffic just to constantly check all values? I mean I basically need to check all data every tick then? Server needs to send a lot of settings etc over the network... Isnt it better to have everyone have all data and just send the changes to everyone when they change something?

Thanks for your input guys
Erik

But if each client listens to the server and shows that data (you mean each client should not store data like settings?) wouldnt that mean a lot of unnecessary traffic just to constantly check all values?


The client should store and display the latest data received from the server, and keep displaying that until it hears something new. This means you only send changes from the server.


What's important here is that, when checking a checkbox (say), you will show the checkbox clicking animation, but you won't actually put the checkmark into the checkbox until the server responds with a "property changed' message. The checkbox clicking animation is user input; the checkmark is data display, and they have to be separated, as opposed to a single-player game, where that separation doesn't generally exist.
enum Bool { True, False, FileNotFound };

This topic is closed to new replies.

Advertisement