   Server-side World Geometry
  Hi,I'm developing a small 3d online RPG (think diablo style, but hopefully a bit more immersive).  Development thus far has been going very smoothly, but now I'm struggling with world/zone management on the server.I want to avoid full-blown collision detection on the server - maybe even allow the client to be authoritative (at least for now).  I'm not particularly worried about the security implications for this project as it's more of a stepping-stone project into something more ambitious (perhaps an MMO).That said, I don't want to take too many design "shortcuts", so I'm interested in hearing solutions that also apply to larger scale projects, such as MMOs, with more complex environments and significantly more entities.Anyway, my question is the following.  Suppose I design an indoor environment (dungeon, etc) in my modeling program of choice.  The resulting model defines my world geometry for that zone.  This is fine for the client, but how does the server manage the zone?  Is it common for the server to actually load all the world geometry?My first thought was that I surely wouldn't need to do this if collision detection is primarily (or completely) handled client-side, but how else will AI entities know to move/path properly?  I've read that server-side collision detection for massive worlds is usually limited to a basic, "blocky", representation of the world.  How is this generally achieved?  A separate, low-poly version of the same model, or something generated algorithmically?Perhaps this approach is all wrong?  Should my indoor maps all be tile-based so that the server can hold a simpler representation?  This seems limiting.Anyway, sorry for the long-winded question.  Any thoughts would be appreciated.I doubt any of this is relevant, but here is what I'm working with:Language: C++ (both client and server)Graphics: Irrlicht EngineNetwork: ENetOther: OpenThreads   
Quote:Is it common for the server to actually load all the world geometry?The server needs to load all data it needs to enforce the rules it needs to enforce.Generally, you have three kinds of data coming in from clients:1) Data that can be forwarded without verification ("full trust" data -- say, chat text, perhaps).2) Data that the server needs to verify; either by applying rules, or re-running simulations, or whatever.3) Data that the client is sending in an attempt to cheat.You need to tell the three kinds apart, and deal with them appropriately. Typically, your data schema will tell the server (and clients) whether a given packet is of type 1) or type 2); and you may even be able to easily switch data between the two kinds with some minor changes to your schema. Type 3 will be detected either when the data doesn't physically match the intended structure (corrupt packets), or when, in case 2), the simulation does not match the data.If you want to put position into category 1, then that's fine -- just treat it more like you treat text chat, and less like you treat, say, quest completion, or player trade. In a well designed system (without shortcuts), different kinds of data get subjected to different validation and forwarding rules, and you simply classify "position data" appropriately as per your needs.Now, as for AI, yes, the AI may need geometry. Or it may need pre-calculated nav meshes. Or it may need a pre-calculated route network. Whatever it needs, must be loaded on the machine(s) that actually run the AI code. In the simplest case, the data is the actual collision data, and the machine is the single-zone server machine.You can also consider letting the clients drive the AI (scary!) or putting AI in a separate process (scales better) if you want.