Sign in to follow this  

is my Input State Sincronization structure good?

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

What hplus meant was like give the player a trigger so they know something is happening. Best example is in Warcraft 3. You select a unit and tell it to move. You hear the unit say something instantly. Albeit a fighting game is different.

The server doesn't freeze. It goes on it's way updating at 10 frames per second or something. When a player sends input to punch it gets buffered (one way to handle it) until the next server update. If player sends input at time 0 it takes 100 ms to reach the server lets say, and it just gets put in the buffer right after an update (update is every 100 ms) then it gets processed 100 ms later at time 200 ms and that data is sent to both players taking 100 ms. This means that with a 100 ms update the worst case delay the player could see is 300 ms.

If the gameplay is slow enough no one will notice. Also extrapolating the action on the client by a little will make it unnoticeable. If your game is fairly deterministic no one will be the wiser.

Quote:
Original post by becoolnike
If i play an animation when the client recieves an input, i think the game on the other side (server) will go out of sinc.
The idea is that the client knows it's going out of sync in order to trick the player to believing it's in perfect synchronization.

Share this post


Link to post
Share on other sites
I think i got it. I see the trick is to trick the client player. This kind of system works well in a fps or rpg games,because they are not based on finite-state-machine method, but in a fighing game like street fighter the actions or events are inside of states, and the game is based on finite state machoine. I can't figured out yet a way to trick the client player when a state is getting Sincronized.

Ok, this is my scenario of my fighting game.

----------------
-Standing State- ( infinite anim )
----------------
.
.
. --------------
........-> -Punch state-- (20 ticks long)
--------------
The server is running at 60 fps.
At the beginning the Server and the nods(clients) are sincronized at the standing state, But one nod(client,p2) receieves input from its player for making a punch. the client sends the inputto the server. The client generates, and play a small tricking anim while weating for a the real state ... and so on...




My question what kind of anim i can make the client player to play while wearing for the punch state. IF the punch Animation is 20 ticks long, should i play it a partial of it then when the punch state data has arrived, i play the rest?

Share this post


Link to post
Share on other sites
It can still work with a FSM. The trick is to have two "punch" animations; one that takes X milliseconds, and one that takes X+200 milliseconds. When the client receives the "punch" command, start playing the long animation, and enqueue a state machine change request for 200 milliseconds into the future. When the state machine change happens, 200 milliseconds later (which will give it time to go to the other machine), you play the faster animation on the other machine.

This will work as long as RTT is < 200 milliseconds. You can keep time moving forward on the local client as long as it's getting commands for times at least 1 millisecond in the future. Whenever the client hasn't gotten the commands for time T, it cannot advance local time beyond T+200 milliseconds.

Share this post


Link to post
Share on other sites
Thank you fo your help hplus. I will use the best method but hardest to implement. A Lag conpensation system. When the client recieves the input, he will process part of the game state, and when the state game arrives the client will check and correct any error. This method includes another subsystem like error checking, but this will fine well.


Thank you for the ideas.

Share this post


Link to post
Share on other sites

This topic is 3590 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this