When to use physics

I try to create a MMORPG and am thinking about how to solve some physic related issues:

Of course I need some kind of gravity to keep things on the ground and simulate falling at a natural speed (i.e. accelerated at g and de-accelerated by aerodynamic resistance). I think that should be feasible without a complete physics engine by simplifying the effect. In an MMORPG nobody will measure the time and distance and calculate :slight_smile:

On the other hand I'd like to have horse and ox carts for which force and spring simulation would be quite handy. There might also be a need for ballistic calculations.

I have used other game engines and at least one caused some problems where I would have loved to switch off physics completely. One such problem was the permanent dynamics that made corpses slide down a hill and made it hard to stop when walking down into a valley.



What's your suggestion? Should I go for a physics engine or better try to keep things simple and calculate the simulations only where needed? In the end physics would only play a small helping role. The main issue in such a game is not physics.

I read something a while ago, and the general idea was that in game design you want to fake it when you can.  Save yourself coding time and client/server resources if there is no actual benefit to doing something the 'right' way.



That said, the two issues in my mind are:

  1. Fairly accurate jump trajectories
  2. Making sure the player doesn't cheat (extra movement, extra fast movement, or teleporting from area to area)



    Unless your MMO is set up to have complicated physics interactions like HL2, the player movement is pretty much the only real time physics - the rest can be easily scripted.  Even then, it is basically just jumping, so you need speed and trajectory calculations.  It gets a bit more complicated when you add in items such as chairs, but it is still doable.



    My decision, considering the limited amount of physics actually required, was to put this functionality on the server.  I have the client send a signal to initiate a jump or movement (including rotation, etc) - and then the server does calculations and tells the client how far to move, and how long to take doing that. 



    I'm not sure that this is the best way to do it, but it was the only way I could think of to adequately bounds check the player's movement and prevent cheating.  (If you let them calculate movement on client side then your server side bounds checks have to be fairly accurate anyway - you don't want someone floating around just high enough that no one else can attack them, for example)



    Disclaimer:  I haven't load tested this scheme - theoretically it should work fine, but there's always a small chance it will fail miserably! :slight_smile:
unfair said:

My decision, considering the limited amount of physics actually required, was to put this functionality on the server.  I have the client send a signal to initiate a jump or movement (including rotation, etc) - and then the server does calculations and tells the client how far to move, and how long to take doing that. 


This approach is not really that scalable... The client needs to feel completely responsive to user input. An alternative approach, (which is presumably what most games do) is to have calculations about positions/speeds be calculated by both the server and the client. The client sends the jumping action request to the server, and starts its animation, doing all the calculations on its own. Periodic updates are sent to the server with the position.

The server receives the request for a jump, and calculates where it will land and when. If the client sends an update that violates this estimate outside of reasonable boundaries, then the server sends a veto and rejects the user update.

I think you're talking more about responsiveness/latency than scalability…



And yes, I didn't go too in depth with my description, but the client does start moving without waiting for the server response, and then compensates accordingly if necessary.  My point was just that the client is never giving the server calculations, merely directions.  This mitigates the cheating aspect of movement.

Scalability is also a problem with serverside physics rendering:

Just imagine the load you are putting on the server for calculating all the physics. Load that normally the client takes to calculate the limited amount of physics related to the player.

I don't even want to think about the server array you would need to calculate the physic for a worls that is populated by thousands of players.

That might be the case if you were doing complete world physics calculations server side, for example trying to run what could be compared to thousands of HL2 clients on one server.  However, if you read my posts it's pretty clear that what I'm suggesting is very very limited calculations. 



You already have to do sanity checks on the player's location fairly frequently - using a few physics calculations instead shouldn't add much in the way of extra overhead.



I'm still waiting for someone to make a better/different suggestion :stuck_out_tongue: