I see the value in this but doesnt that put alot of load on the server?
When you remove the graphics processing, the load is less than you might think, but yes, servers are supposed to handle appreciable amounts of data processing.
So 3d mesh collisions are handled server side? I can understand not being able to trust the client with saying what direction it was facing cause then you end up with CS snap shooting shenannigans, but this seems a little odd to be completely server side. Could you elaborate on the physics portion of this?
Broad-phase collision detection (the first part of a 2-stage broad and narrow phase system) reduces the number of calculated collisions to those with a high chance of occurring in this time frame. This can be made further efficient by only calculating physics near any player presence, or using a cheaper collision model (like simpler forms vs high-poly collision meshes). Expensive collision hulls are only used on high-performance systems, or in games like fighters where there are only a handful of ptentially colliding meshes in the entire scene.
Also, physics calculations can be done much less frequently (like on the order of 6-10 times per second, as a guess number) and still produce fully acceptable reactions as they can do interpolated time steps internally. This reduces processing requirements a lot compared to the 60 fps people want for believable graphics rendering.
As a side note once i get a firm understanding of all of this i plan to post a conceptual template of where each piece of behavior takes place and the general structure/routine of these engines.
I'm willing to bet it already exists somewhere. If it helps your learning process, go for it, but otherwise I'd save yourself some time and just make your game
Edited by BCullis, 27 May 2012 - 05:17 PM.