It''s an interresting approach, but one question about this: What data do you transfer to the client with the messages? I guess that all world vertices and models are part of the client, and that you transfer positions and special events (ie: movement, death or damage) to the client with the messages. I understand that you don''t want to transfer too much data.
But now, I run into a problem: my terrain class... it contains the vertices of the map, that are used both for rendering and collision detection. Or, a model, also with poly-level collision detection. You require to keep a copy of both on each side, and if my map is even a bit big, you might get quite a problem with the amount of memory you use.
Or am I overreacting here?

I can see how you would use the idea of FPS to scale movement, but this would require a more sophisticated collision system. Instead of moving objects one bounding area at a time and then testing for collisions each frame, you have to map the objects path as a FUNCTION.

Ive read that, and it makes sense. If two objects collide, their functions intersect, right? This would help those instances where objects skip past other objects due to low framerates, because as a function, all of its positions from point a to point b are mathematically defined. However, integrating this kind of system is not easy, and most likely takes up a little more CPU. It will also involve some calculus Im sure.

The server/client method would also probably work great for games. The trade off, like Structural seems to say, would be the necessity of memory duplication. But its almost a traditional tradeoff, memory for speed! The more memory you can ensure as "given" information, like maps, character models, etc etc.. the less the client has to figure out. If I spent enough time implementing this method, it sounds like it could easily be ported into a multiplayer game as well. Good idea.

>> I can see how you would use the idea of FPS to scale movement, but this would require a more sophisticated collision system. Instead of moving objects one bounding area at a time and then testing for collisions each frame, you have to map the objects path as a FUNCTION.<<

Yup! You need to solve things over time, rather than at an instant in time. There are numerous methods to go about simplifying the calculations of things like this.

For example, for collision detection over time you generally re-arrange the data so that you have all of the volume of both objects as one node and all of the motion as the other node(a ray). Then you have a ray-sphere, ray-bbox, etc test instead of two moving spheres over time, two moving boxes over time, etc.

-John