Jump to content
  • Advertisement
Bronovitch

Game Server Open World, Authoritative server, state synchronisation

Recommended Posts

Hi everyone,

I'am student developper, and i have big interest to video game, i have all the competences to create a solo game but now i would like to growth and jump into multiplayer, i know it exist a lot of framework for gameserver but i want to create my own server, i have all technical competencies C, C++, c#, node and i can easily learn other langage, i am here to asking your help,

i search a lot about game server i found some really usefull article talked about authoritative server, state interpolation, state synchronisation and so on, but i didn't found a concret simple example so if some of you found usefull ressource, can you share with me please?

 

for example, how can i synchronize my received state from 2 client about the same entity? (for example taking ARK, when to player hitting the same rock to gather stone)

what is the fomat of the packet sending from the server to the client

how can i ensure the packet order in the right way?

how to format my packet from client to server

 

i think some example could help me a lot

 

thx to all ( sorry for my bad english )

Share this post


Link to post
Share on other sites
Advertisement

The English is good enough, so don't worry!

The case of "tie breaking" requires game design more than it requires network packet design. The case of two players hitting the same rock sounds similar to the case of two players trying to collect the same health pack in a first-person shooter.

The way that case is solved is by structuring the player interaction in two phases; one phase is the "preview" phase, visible only to the acting player, and the other is the "result" phase, visible to everyone. So, for example, the "preview" phase of picking up a health pack might be playing a short sound of an injection gun or something. As soon as the player gets to the health pack, play this sound, and send a "I got to the health pack" request to the server. Then, when the server determines that the request succeeded, it sends back "so-and-so picked up the health pack" which causes a particle glow to play around the winning player and causes the sound effect to trigger if it hasn't already played. Also, when receiving this message, each game client knows to update the health of player so-and-so.

So, if you and I are both racing for the health pack, both of us will play the capture sound, and then one of us will be "winner" (normal result) whereas the other will be "loser" (and will see the effect of the other player picking up the health pack.) Each viewer will hear the pickup sound, and will see the player that won actually get the particle effect. For the "losing" player, the way to rationalize this is that the sound effect was actually played by the other player picking up the pack.

There are some important design considerations here:

- the preview effect is somewhat small and not too noticeable, and works well in all three cases of "winning," "losing," and "seeing someone else do it."

- the state on the client doesn't actually change (other than noting that the health pack sound effect already triggered) as part of the request

- the server chooses to only act on requests that are correct, and doesn't need to send any updated about "negative" requests (it's great when you can design it like this, but some cases may require a negative message.)

- the state on the client (and on all clients) are updated as part of the server update

Together, they make for a robust system that solves tie-breaking on the server with minimal player confusion.

 

Share this post


Link to post
Share on other sites

Hi,

 

Okay i have better understanding of the logic i have to use thx !

i think i need to do more research about networking, some aspect are very dark for me at this moment, i wil open new thread if i have more question :)

 

thx again for your help !

Share this post


Link to post
Share on other sites

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

  • Advertisement
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!