It is unlikely that a well-provisioned server will run out of bandwidth before it runs out of CPU. It's more likely that each client runs out of bandwidth.
When it comes to CPU load, a highly optimized FPS that doesn't allow you to affect the environment (similar to Planetside) may allow you 300-500 players per server CPU. That's making some assumptions on server physics rate, collision complexity, etc. If you allow players to affect the environment, have very complex geometry, a richer movement model, a higher simulation rate, etc, then that number will go down. From what little I've played WoW (a one-month subscription that came with a copy I got), I would say that they do not run the full simulation on the servers.
When I said that client path finding may not be deterministic with the server, I have seen the following cases:
1) bugs, however small, in the code will cause it to diverge
2) differences in CPU implementation (Intel has 80 bit FP registers, AMD has 64) may cause it to diverge
3) unsynchronized data sources, such as geometry caches, random number generators, etc will cause it to diverge
4) differences in object position between client/server will cause it to diverge
4.1) such differences can be caused by dropped packets or lag
5) differences in knowledge about the map may cause it to diverge
5.1) Most MMOs do not send you information about all entities; they only send your client what they think might be "interesting" to you
5.2) starting up a new entity when it becomes "interesting" may have some latency
You _can_ build a system where the simulation is almost always consistent, despite these hazards. It is, however, really hard work, especially for a system like an MMO where entities will come and go. You'd still need occasional corrections for certain cases. It's somewhat easier for a "closed box" system like an RTS, but still not trivial. If I was alone or part of a small team, and just had to get it to work, it's much less work to do it once on the server, and let the clients know. That would save lots of money up front!
MMORPG Client/Server Architecture ? Such as Movement
Quote:Original post by Sirisian
Yeah I'm pretty sure the servers are performing collision and everything for clients.
They really aren't. Both in World of Warcraft and other MMOs like Dark Age of Camelot, there's been several cases of "teleportation hacks". Basically spoofing a packet from the client telling the server "I'm at coordinates X, Y, Z now", which works perfectly (or at least it used to, they could've put in safeguards by now). Google for "wow teleport hack" and you should find plenty of sources :P.
Yes, I've worked on a commercial MMO on my previous job and that's what they did. The client was 100% authoritative on the player position inside a zone. It took 2 years and half for a clever guy to use a program to change his system clock and go to 4x his normal speed. We then had to implement some counter measures but CPU was really tight so it only prevented the most glaring speed hacks.
Tracking down and deleting all of the user accounts and characters for the perpetrators also provided a certain deterrent of course.
I had a co worked who told me they did the same thing for Everquest inside zones and they had the exact same problem with a speed hack after a while. So I'm guessing it's a pretty common solution. Looking back to my very short EQ experience it did look like it was the case.
I remember I had that image in my mind before I worked on a mmo of high security practices, very optimized code etc. How far I was from the truth... And yes hplus is right, CPU was usually the biggest problem, bandwith never got into it.
Tracking down and deleting all of the user accounts and characters for the perpetrators also provided a certain deterrent of course.
I had a co worked who told me they did the same thing for Everquest inside zones and they had the exact same problem with a speed hack after a while. So I'm guessing it's a pretty common solution. Looking back to my very short EQ experience it did look like it was the case.
I remember I had that image in my mind before I worked on a mmo of high security practices, very optimized code etc. How far I was from the truth... And yes hplus is right, CPU was usually the biggest problem, bandwith never got into it.
Getting back to the nitty gritty of this problem (rather than arguing about what games do what), the solution you implement really does depend on the scale of the project.
If you want to do a multiplayer online game that supports a dozen or so players you can get away with the server managing object states (and state dynamics) and clients accepting and propogating inputs and displaying proxies for the objects within the players field of view. This is the Object<->ObjectProxy paradigm; the server stores all game objects and each client maintains a list of proxies for objects satisfying a constraint set for the player (such as distance, visibility, etc). Within this framework you can include techniques for overcoming network limitations (latency, flutter, packet loss), such as client-side state prediction, server-side state rollback, client-client state sharing, etc. You're not restricted to using purely client-server architectures either.
If, however, you want to implement an MMO then you should stick with a pure client-server architecture with the addition of a network database (particularly if you want persistence). Your server is now a front end to the database. Its role is to maintain data and to make sure it is consistent with a basic set of game rules. Clients are responsible for the state of the avatar they are connected to (so a client makes a network connection to an avatar in a character database... you could use an Object<->ObjectProxy scenario here as well) and for maintaining a valid state w.r.t the world geometry during movement (the server would usually check states infrequently to validate what the client is doing). Interactions between avatars are adjudicated by the server when necessary, typically by a specific subsystem designed to manage such interactions (e.g., combat).
There's obviously a lot more to it than the few lines above... indeed whole books have been written on this subject... if you need some citations just holler. 8)
Cheers,
Timkin
If you want to do a multiplayer online game that supports a dozen or so players you can get away with the server managing object states (and state dynamics) and clients accepting and propogating inputs and displaying proxies for the objects within the players field of view. This is the Object<->ObjectProxy paradigm; the server stores all game objects and each client maintains a list of proxies for objects satisfying a constraint set for the player (such as distance, visibility, etc). Within this framework you can include techniques for overcoming network limitations (latency, flutter, packet loss), such as client-side state prediction, server-side state rollback, client-client state sharing, etc. You're not restricted to using purely client-server architectures either.
If, however, you want to implement an MMO then you should stick with a pure client-server architecture with the addition of a network database (particularly if you want persistence). Your server is now a front end to the database. Its role is to maintain data and to make sure it is consistent with a basic set of game rules. Clients are responsible for the state of the avatar they are connected to (so a client makes a network connection to an avatar in a character database... you could use an Object<->ObjectProxy scenario here as well) and for maintaining a valid state w.r.t the world geometry during movement (the server would usually check states infrequently to validate what the client is doing). Interactions between avatars are adjudicated by the server when necessary, typically by a specific subsystem designed to manage such interactions (e.g., combat).
There's obviously a lot more to it than the few lines above... indeed whole books have been written on this subject... if you need some citations just holler. 8)
Cheers,
Timkin
Author
You guys here at gamedev are amazing! I got my answer answered on many levels plus some. Thanks so much.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
