I guess the reason why you were choosing this architecture was to keep the computation costs and computation effort low on the server, allowing it to be lightweight. (Another advantage of this approach is that the usually low upstream of the clients are relieved by a server acting as a broadcasting intermediator.) Of course the downfall is that it now depends on the clients performance. There is no way around this connection.

So you have to decide on what to prioritize:

• Better network performance of the hosting client.
• Better performance of the game on the hosting client.

If you have slow handheld devices which should act as clients you might prefer the first solution, using a strong, scalable server that hosts EVERY game/room. If you always have strong clients with a good connection you might keep your infrastructure low in cost by choosing the second.

Another solution would be to do peer-to-peer communication using the server only for initialization of a game, eg. register as hosting client. Thereby you are able to lower the impact on the bandwidth of server and you don't have to limit the games be playable because of a limited bandwidth: The clients do the work.

I would stick with your approach but with a dynamic part. Since every client can start a game/room in your approach it has the ability to run as hosting client. So why not let the clients provide information about their current performance (FPS/CPU/RAM/Bandwidth/Latency) on which the current host decides if another client is a better host. If this is the case the game migrates from the bad to the new, better host.

What you get is:

• Low impact of running games on the server in aspects of network, CPU and RAM.
• Always get the best host for every game, even if my client accidentally starts an antivirus scan or my damned brother a download of pr0n.
• Low performance handheld devices profit from strong game partners.

As far as I know Awesomenauts uses such dynamic host approach in a peer-to-peer network.

I guess the reason why you were choosing this architecture was to keep the computation costs and computation effort low on the server, allowing it to be lightweight. (Another advantage of this approach is that the usually low upstream of the clients are relieved by a server acting as a broadcasting intermediator.) Of course the downfall is that it now depends on the clients performance. There is no way around this connection.

So you have to decide on what to prioritize:

• Better network performance of the hosting client.
• Better performance of the game on the hosting client.

If you have slow handheld devices which should act as clients you might prefer the first solution, using a strong, scalable server that hosts EVERY game/room. If you always have strong clients with a good connection you might keep your infrastructure low in cost by choosing the second.

Another solution would be to do peer-to-peer communication using the server only for initialization of a game, eg. register as hosting client. Thereby you are able to lower the impact on the bandwidth of the server and you don't have to limit the number of games because of a limited bandwidth: The clients do the work.

I would stick with your approach but with a dynamic part. Since every client can start a game/room in your approach it has the ability to run as hosting client. So why not let the clients provide information about their current performance (FPS/CPU/RAM/Bandwidth/Latency) on which the current host decides if another client is a better host. If this is the case the game migrates from the bad to the new, better host.

What you get is:

• Low impact of running games on the server in aspects of network, CPU and RAM.
• Much simpler and better scalable server implementation.
• Always get the best host for every game session, even if my client accidentally starts an antivirus scan or my damned brother a download of pr0n in the middle of the game.
• Low performance handheld devices profit from strong game partners.

As far as I know Awesomenauts uses such dynamic host approach in a peer-to-peer network.

I guess the reason why you were choosing this architecture was to keep the computation costs and computation effort low on the server, allowing it to be lightweight. Another advantage of this approach is that the (usually) low upstream of the clients are relieved by a server acting as a broadcasting intermediator. Of course the downfall is that it now depends on the clients performance. There is now way around this.

So you have to decide on what to prioritize:

• Better network performance of the hosting client.
• Better performance of the game on the hosting client.

If you have slow handheld devices which should act as clients you might prefer the first solution, using a strong, scalable server that hosts EVERY game/room. If you always have strong clients with a good connection you might keep your infrastructure low in cost by choosing the second.

Another solution would be to do peer-to-peer communication using the server only for initialization of a game, eg. register as hosting client. Thereby you are able to lower the impact on the bandwidth of server and you don't have to limit the games be playable because of a limited bandwidth: The clients do the work.

I would stick with your approach but with a dynamic part. Since every client can start a game/room in your approach it has the ability to run as hosting client. So why not let the clients provide information about their current performance (FPS/CPU/RAM/Bandwidth/Latency) on which the current host decides if another client is a better host. If this is the case the game migrates from the bad to the new, better host.

What you get is:

• Low impact of running games on the server in aspect of network, CPU and RAM.
• Always get the best host for every game, even if my client accidentally starts an antivirus scan or my damned brother a download of pr0n.
• Low performance handheld devices profit from strong game partners.

As far as I know Awesomenauts uses such dynamic host approach in a peer-to-peer network.

I guess the reason why you were choosing this architecture was to keep the computation costs and computation effort low on the server, allowing it to be lightweight. (Another advantage of this approach is that the usually low upstream of the clients are relieved by a server acting as a broadcasting intermediator.) Of course the downfall is that it now depends on the clients performance. There is no way around this connection.

So you have to decide on what to prioritize:

• Better network performance of the hosting client.
• Better performance of the game on the hosting client.

If you have slow handheld devices which should act as clients you might prefer the first solution, using a strong, scalable server that hosts EVERY game/room. If you always have strong clients with a good connection you might keep your infrastructure low in cost by choosing the second.

Another solution would be to do peer-to-peer communication using the server only for initialization of a game, eg. register as hosting client. Thereby you are able to lower the impact on the bandwidth of server and you don't have to limit the games be playable because of a limited bandwidth: The clients do the work.

I would stick with your approach but with a dynamic part. Since every client can start a game/room in your approach it has the ability to run as hosting client. So why not let the clients provide information about their current performance (FPS/CPU/RAM/Bandwidth/Latency) on which the current host decides if another client is a better host. If this is the case the game migrates from the bad to the new, better host.

What you get is:

• Low impact of running games on the server in aspects of network, CPU and RAM.
• Always get the best host for every game, even if my client accidentally starts an antivirus scan or my damned brother a download of pr0n.
• Low performance handheld devices profit from strong game partners.

As far as I know Awesomenauts uses such dynamic host approach in a peer-to-peer network.