Jump to content
  • Advertisement
Sign in to follow this  
BrickedKeyboard

Evaluate my Proposed Networking solution for a vehicle simulator

This topic is 915 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Game Environment : Large, traversable vehicles similar to Space Engineers.

Networking Solution :  

 

For Vehicles : Vehicles are under direct on-server computer control.  Players can adjust settings on the vehicle but ultimately fine control is from the computer.  Players can update vehicle state controls.  On their client, instantly when a button is pressed, the state controls update to indicate the new state.  A small window of time exists where a player can "undo" a command and the command will "undo" if the message reaches the server in time.  As commands reach the server, the server incorporates these new command states into it's simulation of vehicle dynamics.  Then, the server sends back new update messages - basically a big message using TCP/IP that contains all of the new states for the game world in the future.  Server always runs about 0.5 seconds in the future.

 

Clients are always interpolating the game world knowing what the future state will be.  It's interpolation from a known past state, to a known future state.  The idea is to make all movements always correct, down to the millimeter - the client does physics integration per frame, while the server uses a different timestep period, and the client applies a correction factor per frame so that the end result always ends up in the given future state.  

 

For direct client movement, P2P and PeertoServer UDP frames.  Every time a client performs a movement or use or tool switch command, etc, it sends via UDP to both all peers who are close enough to see the client and to the server any actions taken.  Clients then use future state prediction for player models and player shovable small objects only.  (future state prediction being inaccurate) .  (like many other games, every time the player performs an action, their client UDP spams both other clients and the game server with a UDP message every 20ms or so.  The message spam continues until an ACK for that particular UDP message arrives.  The server then UDP spams all clients who need to be "relayed" this message - so at all times the UDP link is being used between between both clients and between client and server so that there is the least possible latency between 1 client performing an action and another client knowing about it.  If a client has other clients blocked via firewall, the 100% packet loss in the link eventually causes a client to stop wasting bandwidth sending to clients who are not receiving.  Similarly, since firewalls can block UDP from the server, the TCP update frames also contain the same embedded data so that the data gets there eventually) 

 

A consequence of this is that the player's model cannot ever block a moving object in game.  If a player is caught between, say, an elevator descending and the floor, the player must be crushed even if they are wearing indestructible armor.  All world objects are unstoppable as far as the player's model is concerned.

To use TCP and UDP simultaneously like this I'll need a more clever throttling mechanism so TCP send rate is governed by UDP packet loss.  

 

For larger environments and for handling of clients with limited bandwidth, there will also need to be a subscription system, where clients can subscribe to network events, limiting their subscriptions to stay within their network bandwidth availability, but that isn't needed to get a basic version of the game working.

Edited by BrickedKeyboard

Share this post


Link to post
Share on other sites
Advertisement
You don't want to make client movement exact "to the millimeter" -- you want to make it exact, period.
I suggest you use the lockstep deterministic simulation model. The gameplay you describe seems like a perfect match for this!
The "1,500 archers on a 28,8 kpbs modem" article about Age of Empires networking describes this very well.
I think the link in the FAQ still works, or you can Google it.

Share this post


Link to post
Share on other sites

You don't want to make client movement exact "to the millimeter" -- you want to make it exact, period.
I suggest you use the lockstep deterministic simulation model. The gameplay you describe seems like a perfect match for this!
The "1,500 archers on a 28,8 kpbs modem" article about Age of Empires networking describes this very well.
I think the link in the FAQ still works, or you can Google it.

I've read that article.  By "to the millimeter" I'm implicitly referring to precision issues.

 

My plan is that the only client side physics is between player models/small objects and the environment.  All large vehicles would be server side physics.  Instead of simulating in lockstep, only the server does the heavy lifting, and it informs the clients of (1) end position (start being implicit) (2) net forces at start and endpoint (3) intermediate collisions

By making the server the arbiter, bugs like false collisions don't happen.  Any collision a client renders is real.  Errors in client interpolation would lead to clipping, however.  This also means I don't have to reduce performance with the kinds of tweaks needed to make floating point math work the same on a variety of CPUs - only the server does the calculations.  It means that clients do not need to be aware of all the same information the server is aware of.  It means that the resynchronizing is easier - the minimum information a client needs to be aware of are essentially the fine environmental details near the client and any "local" forces.  (if a client is onboard a spinning space station, it only needs to know there is a velocity dependent acceleration vector (coriolis force) and a constant acceleration vector (centrifugal force))

It frees up CPU and memory on the client, making it easier to port to consoles.

Share this post


Link to post
Share on other sites


I suggest you use the lockstep deterministic simulation model. The gameplay you describe seems like a perfect match for this!

 

Seconded. As long as you're putting in a reasonable number of players per server (Or creating a very robust re-sync/ authoritative lockstep (So the game can run faster than the slowest client), a P2P lockstep sounds pretty much an exact perfect fit.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!