Jump to content
  • Advertisement
Sign in to follow this  
lemm

Simple Client-Server Question

This topic is 2391 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

Hello,


I am making a multiplayer 2D-platformer arena game for 2-12 people. The previous incarnation that I hacked together used the original doom network code, where every peer acknowledges every other peer's input before the game can advance. It works okay, but this is not really suitable for more than a few players over long distances (using DosBox IPX-tunneling through UDP), so I'd like to use a server-client architecture this time around.


I have read the FAQs, as well as the Unreal and CS network design documents. I understand most of what is said, but I am not exactly sure as to how the server is supposed to process a player's motion if the game timestamp of the player's input it receives is always timestamped with a tic earlier than the game time of the server world. If the server is at tick T, but the input was generated at tick T-x on the client, should the server just process this input for tick T?

Share this post


Link to post
Share on other sites
Advertisement

I have read the FAQs, as well as the Unreal and CS network design documents. I understand most of what is said, but I am not exactly sure as to how the server is supposed to process a player's motion if the game timestamp of the player's input it receives is always timestamped with a tic earlier than the game time of the server world. If the server is at tick T, but the input was generated at tick T-x on the client, should the server just process this input for tick T?


This question comes up every week, and the answer is actually in the documents you've already read (for those particular model).
On a higher level, you can do it that way. Or you can simulate backwards in time. Or you can run the client ahead of server time. In every case, there is a trade-off between the client not having all information, and the client having high command latency.

Share this post


Link to post
Share on other sites
Hello

My idea to solve that:

1-All the players / clients are dumb terminals, so every thing is processed in the server
2-Every player movement /action is sent to the server to be processed, but it is also processed locally so you get an "instant" response to the input in the screen for the player
3-Clients try to predict other players actions and update them so, even if server is lagging we would have an "illusion" that they keep moving
4-Server updates clients with the real data every X ms so they really get synchronized.

Just an idea...

Share this post


Link to post
Share on other sites

On a higher level, you can do it that way. Or you can simulate backwards in time. Or you can run the client ahead of server time. In every case, there is a trade-off between the client not having all information, and the client having high command latency.


What exactly is the trade off when doing backwards simulation? My understanding is that there will be no command latency, and the available information will be at worst as stale as any other model.

Share this post


Link to post
Share on other sites

What exactly is the trade off when doing backwards simulation? My understanding is that there will be no command latency, and the available information will be at worst as stale as any other model.


You can have one of these options:

1) Display everything as you see it from the server: There is high command latency, and the client makes all decisions based on perfect information about the rest of the world.
2) Display client forward simulated, everything else forward extrapolated: There is low command latency, and the client makes decisions based on extrapolated information about the rest of the world.
3) Display client forward simulated, everything else as you see it from the server: There is low command latency, and the client makes decisions based on old information about the rest of the world.

If you do things like gunshot hit resolution server side, you have cases:
1) Everything just works
2) Either make the hit determination on the server based on the extrapolated information the client "ought" to have displayed, or make hit determination based on the actual server state at the time, saying that the extrapolation was usually a good estimate for the client to give commands. (Note: bunny jumping or zigzagging mainly help by make extrapolation a poorer estimate)
3) Make hit determination based on the state the client was displaying other entities at at the time.

Share this post


Link to post
Share on other sites
Backward simulation is not a great idea.. you have to ahave a history of inputs and states to back up to.

Because your game is a platformer it need tight responsive local interaction. you need to implement quake3's netcode or so on that use client side prediction.


The thing about quake3 style netcode is that your client is constantly sending updates of input. The server side version of your character (barring excess packet loss) will recieve your inputs in sequence and execute them properly. If your engine is deterministic with simulation, then both client and server will see similar events unfold.

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!