I always think that there might be a simpler solution to my current problem. OK guys, here''s how it goes: A RTS game (e.g. Starcraft, Red Alert, etc) will have many of those small units walking around on the map. OK, so now I want to make a game that each human player, will represent ONE unit on the map. That means, you log on to the server, you play as ONE SINGLE unit. If you die, the battle still go on. You gotta join the on-going battle again later. Allright? So that''s simple right? But when I consider the traffic over the server side, there''s this BIG problem: Imagine there are 1000 players log on to play in a game, if there''s a need to synchronize, one player will send out a message package to the server, and the server will in turn forward the messages to all the other players. In the worst case, 1000 players will each send out a package, and the server will receive 1000 message packages from all the players, and if it wants to forward them, that will be 1,000,000 message packages on the server side. Try to consider a package of few bytes, will easily result in few megabytes of data flow on the server''s line!! (Note that this is only for a single message package!!) Oh Gosh!! That''s gonna kill the server!! So my friend, do you have any idea as how to address this serious problem? Thanks a lot for helping me, this little poor guy. haha!!

That won''t be 1.000.000 packets to forward.
It will be 1000 packets forwarded containing information about 1000 players each. All you need is a full player-state update sent to each player every tick. You can apply compression there, and techniques like not sending data about players that are far away from the target player as often as data about closer players.


People might not remember what you said, or what you did, but they will always remember how you made them feel.
~ (V)^|) |<é!t|-| ~

Thanks man, but eventhough I were to send out 1000 message packages at one time, each package will still be 1000 bytes in length. So that don''t reduce much the package size.

Whereas for the "distance" way of handling messages, I think that should work well.

I''m just wonderin'' if there''s any good algo for reducing the package sizes dramatically? Ha

Like MadKeith said - you don''t really need to send all the data that the clients send to the server back out to the other clients.

If every unit sends the server an update then the server can recalculate all positions on the map, the map data can be generated for each client with information about the units nearby consisting (at the very least) of co-ordinates for each unit, compressed and then sent. If there are no units nearby then this data will be virtually nothing.

An entire map descriptor with the co-ordinates of every unit can be sent to each client with information on further away units (again compressed) at a much smaller frequency since this data is not directly relevant to what the client is seeing.

With a very simple system having an average of 30-50 units in the immediate vicinity of every client the data sent out to each client every interval would be 40 sets of co-ordinates and data(say 8 bytes per unit) which would work out at 320 bytes (plus network protocol headers) to each client every interval which could be compressed to as little as 100 bytes, which is not too bad.

-Forxl

If it isn''t too much trouble, you might try some sort of circlular pattern of connections, where each player sends their packet to the next player, where the packet is updated and sent on. If someone joins, they''re added to the ring, and if they quit, the ring just closes on either side of where the player was. This way, there is no central computer being bombarded by packets.
I''m not an expert on the subject, though, so I don''t know exactly how you make this work.

-----------------------------
C++ is great, but when is B-
coming out?

OK, here''s an idea that may or may not work, depending on your network. Have one central computer that receives the updates from each of 1000 computers. So far, 1000 packets. Then, after updating whatever necessary state information, send out a multi-cast packet to the receiving stations (by subnet, or whatever). So, 1000 small packets, 1 larger one of ~1000 x the size, or the equivalent of ~ 2000 small packets (not accounting for ethernet frames; this will help bandwidth on the single larger packet).

If you are sending IP, you can send a single packet to an entire subnet. For example, my computers are all 192.168.1.x, where x is from 1 up, no higher than 254. To send a single packet to all, I set the dest addr as 192.168.1.255.

If you''re sending raw data in ethernet frames, the bcast addr is FF:FF:FF:FF:FF:FF (I think, it might be something kooky like 7F:FF:FF:FF:FF:FF).



David

I don''t know about this, but you could treat the entire game as a series of smaller games - what you do is divide the map into lots of small sections, they would have to overlap and be at least twice the size of a screen-full of data. What then happens is the server tracks the position of each player - but only which sector they are in(Maby as multiple sectors in.), which the player updates for the server only when it changes sector. When a player changes sector, the server supplys it with ip addresses of everybody in that sector, and then all the computers in each sector send there state updates only to the computers that are in there sector.

There are problems though - the clients are then responsible for there player state, this opens the door for cheating and causes problems if resolving a conflict, as neither machine has presidence over the other. And of course, this whole idea relies on players being resonably spread out And each client has to have server style behaviour.

Might work?
-Lethe

Server clusters I say.

Have one main server taking care of clients that join the game.

Then you have one game server for each sector of the map and a client moving around will change the game server it comunicates with. That way you can spread the load onto several game servers. There are ofcourse some problems, like having an area on a client screen that covers several game servers sectors, but I''m sure you can solve it somehow.

Thanks a lot for your help guys!!

Forxl, compression is a good idea, but I think that will take up reasonably big amount of time? Yeah, smaller frequency for those further away units, this can be a good way

ByteBlaster256, your idea is like the peer-to-peer approach, just that the message package is only sent to the next client. But then the latency can be very large, say the message bein'' sent out from the first client, by the time it reaches the last client, it will be out-dated. :p

fugue88, oops!! I don''t have any subnets setup here :p haha.

Lethe, your idea is an interesting one. Yeah, I always afraid of handling difficult stuff like this, many maps together...... but can try it out

goir, multiple game servers? Do you mean physical servers? Ugh, I don''t have that many servers, only one I got :p But if you say "software game server", then the physical server will still have the same amount of work to do