Skip to main content
added 557 characters in body
Source Link
Philip
  • 691
  • 5
  • 7

I've made a TCP-networked RTS, in which I passed the commands themselves, rather than the results of the commands. For instance, a player gives a move order. If the move order is valid according to that client, it is sent to the server. The server then sends it back to all clients, who validate and execute it.

So all client machines run the game themselves, the server code accepts messages and sends them back to all clients. If a client gives a move order, it won't start executing it until it is received back from the server.

The server sends a 'tick' number at which to execute the command as well, which is a few ticks ahead of the 'current' tick. This way all commands can be executed at the same 'tick' on all machines.

One benefit this method is that it doesn't depend on any individual client machine to validate the command. If I passed the results of the move, I might be able to hack it to move my units faster. All clients have to execute the same command and if one machine executes it differently, it will be obvious.

Validating the command client-side before sending it to the server isn't necessary, but in theory it saves network traffic. I used the same validation code to tell the UI that the move was possible, so it didn't require writing extra code.

As for what the messages might look like. I wasn't concerned with ultra efficiency as it was my first networked game. I passed commands as strings. The commands would be formatted like this: "<player_id>:<command>:<parameters>"

For a contrived example, a move command might look like this: "3:move:522:100:200". This means Player 3 wants to move unit 522 to (100,200).

The server passes the command on to all clients, including the one who sent it, with a tick number attached like this: "153238:3:move:522:100:200".

Then the clients would all execute this command when tick 153238 is executed.

I've made a TCP-networked RTS, in which I passed the commands themselves, rather than the results of the commands. For instance, a player gives a move order. If the move order is valid according to that client, it is sent to the server. The server then sends it back to all clients, who validate and execute it.

So all client machines run the game themselves, the server code accepts messages and sends them back to all clients. If a client gives a move order, it won't start executing it until it is received back from the server.

The server sends a 'tick' number at which to execute the command as well, which is a few ticks ahead of the 'current' tick. This way all commands can be executed at the same 'tick' on all machines.

One benefit this method is that it doesn't depend on any individual client machine to validate the command. If I passed the results of the move, I might be able to hack it to move my units faster. All clients have to execute the same command and if one machine executes it differently, it will be obvious.

Validating the command client-side before sending it to the server isn't necessary, but in theory it saves network traffic. I used the same validation code to tell the UI that the move was possible, so it didn't require writing extra code.

I've made a TCP-networked RTS, in which I passed the commands themselves, rather than the results of the commands. For instance, a player gives a move order. If the move order is valid according to that client, it is sent to the server. The server then sends it back to all clients, who validate and execute it.

So all client machines run the game themselves, the server code accepts messages and sends them back to all clients. If a client gives a move order, it won't start executing it until it is received back from the server.

The server sends a 'tick' number at which to execute the command as well, which is a few ticks ahead of the 'current' tick. This way all commands can be executed at the same 'tick' on all machines.

One benefit this method is that it doesn't depend on any individual client machine to validate the command. If I passed the results of the move, I might be able to hack it to move my units faster. All clients have to execute the same command and if one machine executes it differently, it will be obvious.

Validating the command client-side before sending it to the server isn't necessary, but in theory it saves network traffic. I used the same validation code to tell the UI that the move was possible, so it didn't require writing extra code.

As for what the messages might look like. I wasn't concerned with ultra efficiency as it was my first networked game. I passed commands as strings. The commands would be formatted like this: "<player_id>:<command>:<parameters>"

For a contrived example, a move command might look like this: "3:move:522:100:200". This means Player 3 wants to move unit 522 to (100,200).

The server passes the command on to all clients, including the one who sent it, with a tick number attached like this: "153238:3:move:522:100:200".

Then the clients would all execute this command when tick 153238 is executed.

added 557 characters in body
Source Link
Philip
  • 691
  • 5
  • 7

I've made a TCP-networked RTS, in which I passed the commands themselves, rather than the results of the commandspassed the commands themselves, rather than the results of the commands. For instance, a player gives a move order. If the move order is valid according to that client, it is sent to the server. The server then sends it back to all clients, who validate and execute it.

So all client machines were runningrun the game themselves, the server code just acceptedaccepts messages and sentsends them back to all clients. If a client gavegives a move order, it wouldn'twon't start executing it until it wasis received back from the server.

The server would sendsends a 'tick' number at which to execute the command as well, which wasis a few ticks ahead of the 'current' tick. This way all commands wouldcan be executed at the same tick'tick' on all machines.

One benefit this method is that it doesn't depend on any individual client machine to validate the command. If I passed the results of the move, I might be able to hack it to move my units faster. All clients have to execute the same command and if one machine executes it differently, it will be obvious.

Validating the command client-side before sending it to the server isn't necessary, but in theory it saves network traffic. I used the same validation code to tell the UI that the move was possible, so it didn't require writing extra code.

I've made a TCP-networked RTS, in which I passed the commands themselves, rather than the results of the commands. For instance, a player gives a move order. If the move order is valid according to that client, it is sent to the server. The server then sends it back to all clients, who validate and execute it.

So all client machines were running the game themselves, the server code just accepted messages and sent them back to all clients. If a client gave a move order, it wouldn't start executing it until it was received back from the server.

The server would send a 'tick' number at which to execute the command as well, which was a few ticks ahead of the 'current' tick. This way all commands would be executed at the same tick on all machines.

I've made a TCP-networked RTS, in which I passed the commands themselves, rather than the results of the commands. For instance, a player gives a move order. If the move order is valid according to that client, it is sent to the server. The server then sends it back to all clients, who validate and execute it.

So all client machines run the game themselves, the server code accepts messages and sends them back to all clients. If a client gives a move order, it won't start executing it until it is received back from the server.

The server sends a 'tick' number at which to execute the command as well, which is a few ticks ahead of the 'current' tick. This way all commands can be executed at the same 'tick' on all machines.

One benefit this method is that it doesn't depend on any individual client machine to validate the command. If I passed the results of the move, I might be able to hack it to move my units faster. All clients have to execute the same command and if one machine executes it differently, it will be obvious.

Validating the command client-side before sending it to the server isn't necessary, but in theory it saves network traffic. I used the same validation code to tell the UI that the move was possible, so it didn't require writing extra code.

Source Link
Philip
  • 691
  • 5
  • 7

I've made a TCP-networked RTS, in which I passed the commands themselves, rather than the results of the commands. For instance, a player gives a move order. If the move order is valid according to that client, it is sent to the server. The server then sends it back to all clients, who validate and execute it.

So all client machines were running the game themselves, the server code just accepted messages and sent them back to all clients. If a client gave a move order, it wouldn't start executing it until it was received back from the server.

The server would send a 'tick' number at which to execute the command as well, which was a few ticks ahead of the 'current' tick. This way all commands would be executed at the same tick on all machines.