Choosing network arch. for a game with 32+ players

[moogie]

I am currently thinking about cloning (and extending) "Anaconda" which is a in-game of Time Splitters 2 for the Game cube. It is basically a snake game.

It is to be network multiplayer, i will be using java3d and will be able to have more than one player per computer.

One of my main desired features is to allow many concurrent players. e.g. 32+

I am a little unsure as to what networking strategy i should aim to use.... Currently i can think of two strategies:

1. Asynchronous.

Allowing each client to potentially send information any time and the ability to queue up some information.

2. Discrete time steps.

Meaning a server waits for a specified time collecting any information recieved from the clients and then updating the world and sending back information to the clients. If a client does not manage to send any information to the server in the specified time step, the information is ignored by the server.

I believe the second method will be easier to implement however it does mean the clients with high latency will be severely penalized...

The Asynchonous method will could allow users of realatively high latency to play however i will need to handle the bunching of information messages that could occur.


I was going to use a UDP boardcast for the communication between the clients thinking that this should reduce the network traffic, however it is come to my attention that such broadcasts are not propergated though the internet. Meaning that i will have to use many UDP 'connections' Does anyone have any idea at the performance issues realated with many udp connections?

Another potential problem is the fact that each computer may have 1-4 players at the actual terminal. I was hoping to make each game instance running on the computer to be independant however this may cause problems when finding games to connect to. What methodology should i use to resolve this?

Cheers

N Klaebe

[kevglass]

Snake is going to be really difficult in terms of networking, even the smallest lag will make it unplaybale.

Infact, the infamous UDP vs TCP debate in this forum actually started around this area.

Kev

[moogie]

Yeah, i understand that. however i will be probably sacrficing game speed and increasing tail size growth to compensate.

At the moment i am thinking for aiming for a 100-150ms input refresh rate. And thus network message rate.

The game update rate will be independant to the input refresh rate. Thus hiding the poor responce to a degree.

Games published by our own members! Check 'em out!

[Herkules]

snake as a turn-based game ..... nice idea

[moogie]

lol, it wont be that bad.... i hope!

To keep things simple i will probably limit the game to a LAN environment to begin with and usd UDP multicast.

Once i have the game working for the LAN i will go about changing the networking to allow online play.