How would you solve client/server physics for my MMO?

I'm doing some hypothetical brainstorming for future work, and I want to use Unity for my MMO client and SmartFoxServer for the backend.

The biggest problem I see is that, as far as I can tell, I'm probably going to need a custom physics engine so it can run on the authoritative server (Java) and each client (Mono). I know that Mono supports Java, but Unity does not appear to. Please tell me I'm wrong and there is a way to run a Java physics engine (like JBullet) with Unity!

If there is an existing physics engine that I could use without writing a custom one, I would strongly prefer that. From what I have found in my research, there is no physics engine which runs under .NET/Mono and Java. Thus, I think I would need a fully custom engine.

How would you solve this problem with the least amount of effort?

 

One way is to only have physics on the server side. This will seriously simplify your network coding, but might not be what you are after.

Depends on your game really and what you want to use physics for.

 

If you want physics only for effects but not for gameplay, just kick it out from the server end and do it fully on the client.
Especially stuff like particles do not need to be networked.

Basic collision handling can be done through a dedicated client on the server that checks the validity of the data you get from the clients, I tend to call it "collision node" in our design.
The job of that node is to check if people missused bugs or hacked the client to bypass collision checks and/or attack enemies through walls.


MMO networked physics is something that is not possible right now, our internet connections are still significantly too slow to handle that and the amount of server side CPU time you need just for the physics is brutal. Using GPU there is no option as a CUDA GPU takes more power than you have for a dual QuadCore server in whole (normally U1 have 160W and less, thats less than an 8800GTS needs which is the very bottom you would need per zone server)
Once Unity is DX10 and supports CUDA PhysX you could potentially use that for correct client side physics, similar to Crysis that offers multiplayer physics on DX10 (and only there) because it can offload it to client GPU.

 

Cool - I had been just wondering about this issue, and here's the answer, without even asking ;-)

So, you have an optimized C++ server that primarily handles all the networking stuff ("keeping the right clients updated with the right information") but relies on one specific client (that "sits" somewhere near that server) for the physics stuff? If you need to scale that up, you could probably add more such clients (for different areas), right?

I'm wondering if that approach could also be used for other higher-level game logic, like a combat system, for instance; maybe even all of persistence. I'm asking because I really don't like C++ very much, but it seems for supporting "lots'n'lots of players", there's no way around it ... but I'd still want to do as much as possible with Unity ;-)

 

Thats the good thing about the distinct node.
If more power is needed the solution can be scaled independent the rest of the server layout.


There is no reason to switch to C++.
The whole thing actually would even better, if we could use the Unityengine within a mono project so we could create a really optimized node. Right now the whole thing is far from optimal.

But we are also in the early prototype phase only, but if it shows up that there is no usefull way to do it within the closed blackbox design from which even Unity Pro suffers, we will have to evaluate the situation and options.

 

Thanks for the replies, guys!

My needs would be pretty minimal. I basically want some gravity and of course a solid collision system. (Anything else I can get away with like buoyancy or joints is icing on the cake.)

My thinking was that the server would be the authoritative simulation but the client would simulate to smooth it out with some corrections from the server when necessary.

But if I can leave physics out of the client (since I want it as thin as possible anyway), that would be even better. I figured that it would create visual glitches unless the client is doing predictive simulation. I suppose simple motion interpolation could look smooth enough? I'll have to try it out.