One problem with clients is how much resource they have left over after running glitzy graphics and other input/output related tasks.

Many games have a fairly light load for the simulation (mainly just bookkeeping and simple math/logic to resolve interactions, and even the 'AI' is barely much of anything -- though a game with alot of pathfinding can require more than a little)

8-way intercommunication probably wont be too bad N^2 with constant connections (more complex P2P schemes for masive worlds would start having overhead for the connect/disconnect/boundry transition operations/interactions and that bothersome tendency for players to all be in the same place overloading the 'server' running that location)

As AI gets more complex it will start eating alot more CPU/memory resources and probably a broader information window (pulling alot of data constantly between the P2P distributed servers). That is one situation where a tight server cluster has advantages.

They will be having the multi/many core processors available to provide increased CPU capacities, but a small increase in the AI ability uses magnitudes more CPU so I dont much expect more complex AI in the near future. Eventually that CPU requirement may require a 'cloud' of peers to run AI for NPCs effectively acting just like the players client (except without the graphics) running simultaneously.

The network data feed would then only be a linear multiplication of whats currently used (unless the games get alot 'richer' with more detail events, then it will be a multiplier of that)

Would it be correct to determine each client's average ping at the time of game initiation, and the client with the lowest ping will become the server?

And then if that client cannot be punched through, try the next client down on this list..

You're just better of letting players host games on their own. If they are hard to reach, they just wont get anyone connecting.

When you host a game and advertise yourself to the lobby server, the lobby server can detect if your host has good NAT punchthrough capabilities (port is forwarded correctly, ect...), and send a warning message back if not. Then the user can setup his router accordingly.

Ok, thanks for the replies, very helpful.

I have decided now to allow users to host there own servers, only after being screened for NAT punchthrough type from the server to make sure users can connect to them.

But I would also like to let other clients in the lobby see what connection type or speed the host has. Is this possible?

Host connection speed is a bit tricky. You can get the latency between the host and the lobby server easily, but its actual upstream capability is not straight forward.

The XBox has a bandwidth evaluation API, but that's tightly regulated (to avoid D.O.S. attacks and the likes). You usually run it once. The client can also run a NAT check himself, store his NAT performance result, and return the hosting capabilities to the lobby servers as part of the public session parameters. For example, I know that COD4 and Halo 3 will complain if your router is too strict. And clients with strict servers will only be able to join open game sessions (they use three levels, STRICT, MODERATE, and OPEN).

so, both the game hosts and game clients will have a known NAT level, you can basically restrict the games you can join like so

can we join the host session?-----------------------------host           OPEN         MODERATE        STRICTclientOPEN           yes           yes              yesMODERATE       yes           yes              noSTRICT         yes           no               no

Another thing that's often used is QoS queries between a client and a potential game host.

A QoS query is basically the client requesting a packet (like a ping request) from each game hosts directly. That stresses the NAT punch-through and also makes sure a host is actually present and responding. A host may stop responding for example, if he crashed, while he may still be registered on the lobby server.

A QoS request can give a better approximation of the latency between a host and a client, and also, the QoS packet could contain some useful custom information about a game, like the number of players in the game, the game remaining time. Custom stuff that are not vital to the matchmaking but can be useful information for clients.

Take for example Counterstrike:Source.

first, you query the lobby server for a list of games, with a list of filter settings as an argument.

Then The lobby server returns you some games currently running. Some basic information will be returned, such as the game map, the free slots, the player limit, the server name, address, session id, ect...

Then, on the client side, for each games returned by the server, you issue a QoS request to the game hosts, to get some more accurate information (NAT level, return-trip latency, which custom mods are running, list of players in the game with their scores, playing time, and so on).

Theoretically, the lobby server could return only the minimum information required for a client to join a game (host public address, session id and session key). The rest of the parameters can be discovered via a QoS request with the game host (game name, game map, game type, number of players, number of free slots, ect...). That would move some of the load from your lobby server onto the game hosts themselves. Although the savings are pretty minimal, a lobby server will have to deal with thousands of queries so it all adds up.

Thank you very much for your help. I'm going to implement the QoS query to ensure reliability. However, my game specifics don't go any further than number of players and game type, so I'm going to continue querying the lobby server for those values