🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
This's gonna kill the server!!
Author
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!!
Only send updates to the player about other players that are visible to him. You can either break the map up into small grids and only send the grids surrounding the player, or actually test each unit to see if it''s visible from the player''s current position. Of course, testing 1000 units, 1000 times every update will also kill your server, so I suggest the segmented map method. =)
And know you know why there are no games in which 1000 people play together.
In EQ there''s ~150 people in a zone, tops. And the game slows to a drawl if more than ~30 players are on the screen.
Also, it should become 1000 msg in, 1000 msg out. Clump the data together & resend in bigger packets (a little less overhead that way).
I don''t think there''s a machine out there that could display 1000 players at the same time either. unless it''s 2d, then maybe...
In EQ there''s ~150 people in a zone, tops. And the game slows to a drawl if more than ~30 players are on the screen.
Also, it should become 1000 msg in, 1000 msg out. Clump the data together & resend in bigger packets (a little less overhead that way).
I don''t think there''s a machine out there that could display 1000 players at the same time either. unless it''s 2d, then maybe...
Author
Hahahaha ...... allright, thanks guys, thanks a lot.
JonStelly, yours is the most suggested way of solving this problem, so that should be a good way
Magmai Kai Holmlor, yeah, why don''t I reduce the number of players to smaller numbers? That will certainly help
Hmmm ...... must give it a try, anyway it''s just a concept now, so still not too late
JonStelly, yours is the most suggested way of solving this problem, so that should be a good way
Magmai Kai Holmlor, yeah, why don''t I reduce the number of players to smaller numbers? That will certainly help
Hmmm ...... must give it a try, anyway it''s just a concept now, so still not too late
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
