Hi,

Sending/Receiving data is an operation that takes place per player rather than per machine. What strategy do you advise in case there are several players on each end?

For example, say 4 players on 2 consoles (A and B on one end, C and D on the other end). Their positions need to be kept in sync.

On, say, first console, it's easy to loop on local players (A and B) to collect their position, but who would you send that data to? C or D only? Both of them? Will the framework optimize the bandwidth usage in this case? How would you handle the duplicated data on the receiving end?

Your help will be appreciated,
Thanks!

I just keep a list of the unique NetworkMachines, and send data to the 0th NetworkGamer on that NetworkMachine.

I'm certainly no network-gaming expert, but it seems odd that the API was designed with 'gamer' as the main abstraction for sending data instead of 'machine'.

it seems odd that the API was designed with 'gamer' as the main abstraction for sending data instead of 'machine'.

That makes it much easier to support various networking scenarios in a single-straightforward way; you can write your code once and then not worry about where and how players connect. It does, however, possibly increase network traffic.

Dark Saber:

Hi,

Sending/Receiving data is an operation that takes place per player rather than per machine. What strategy do you advise in case there are several players on each end?

For example, say 4 players on 2 consoles (A and B on one end, C and D on the other end). Their positions need to be kept in sync.

On, say, first console, it's easy to loop on local players (A and B) to collect their position, but who would you send that data to? C or D only? Both of them? Will the framework optimize the bandwidth usage in this case? How would you handle the duplicated data on the receiving end?

Your help will be appreciated,
Thanks!

It's entirely up to you.  Notice that there is are broadcast and a target-specific overloads.  If you broadcast a players status, it'll go to everyone in the session, but it'll only go over the wire once per machine.  So from a bandwidth perspective, it doesn't matter.  This allows each client to go through their player and broadcast general status, and then separately process that status to update the game (the local player updates essentially looping back to the same client).

Int32:

Dark Saber:

Hi,

Sending/Receiving data is an operation that takes place per player rather than per machine. What strategy do you advise in case there are several players on each end?

For example, say 4 players on 2 consoles (A and B on one end, C and D on the other end). Their positions need to be kept in sync.

On, say, first console, it's easy to loop on local players (A and B) to collect their position, but who would you send that data to? C or D only? Both of them? Will the framework optimize the bandwidth usage in this case? How would you handle the duplicated data on the receiving end?

Your help will be appreciated,
Thanks!

It's entirely up to you.  Notice that there is are broadcast and a target-specific overloads.  If you broadcast a players status, it'll go to everyone in the session, but it'll only go over the wire once per machine.  So from a bandwidth perspective, it doesn't matter.  This allows each client to go through their player and broadcast general status, and then separately process that status to update the game (the local player updates essentially looping back to the same client).

Wow, this is great! The only thing that we still have to think about then, in a peer-to-peer setup, is to not predict the same remote player more than once (since all local players receive the status update)..