iThis's gonna kill the server!!

[Baling]

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!!

[Lost User]

I'm not sure about the answer, since i'm not specialized in that, but i'd like the server to have all positions in memory, clients send their new position if needed (to decrease client upload), and then server sends an update packet (of all changed positions, that is 1000 max here) to all client each frame / tick / second - depends what framerate u need. I mean, do not update all clients when a client moves, just keep the server up to date and make the server tells everything that is needed on a regular time base. Good luck

[David Cunningham]

Well, I think your math is correct... I play EverQuest, and I've noticed that they seem to have a maximum of about 2000 players per server, and use many other techniques to keep the relayed message count down. One technique in particular is to divide the "world" into a number of zones that you move between. When you move from one zone to another, you get sync'd up with the players in that zone. The system still has the ability to send world wide messages, but they are very few in number in comparison to the standard. By using zones, there's ususally groups of 70 to 80 people or less that are hooked together, and so the standard character positioning messages are far, far fewer in number. HTH, David

[Lost User]

> but i'd like the server to have all positions in memory, > clients send their new position if needed Yes, and you need to make sure that the server takes care of colission detection and other stuff like that, so that the Server has the ultimate say on what happened, and when. > One technique in particular is to divide the "world" > into a number of zones that you move between. Yes, but in an RTS game, (a similar idea) you might want to consider only sending updates to players that actually have something around them. For example, if your avatar is standing in the middle of the woods, with no other players in sight, there is no need for you to receive the locations/actions of every other player in the game (that also increases the cheat potential). You only need to know what is going on around you, and certain other items like transmissions from other teammates, "Base under attack", etc. -=- James.