Cede Dev Log 1: Server Auth Movement

I’ve decided to start a new sandbox project for me to build on, try new things and see what I can learn. There are going to be a lot of technical challenges for me to work through that is beyond the scope of what I’ve done up to this point.

 

The first challenge is server authenticated movement. If you’re unfamiliar with the concept the simple explanation is that all your input is sent to the server, processed, and applied to your character. The results are then synced back to the character on your local machine. Normally this would feel terrible for games like an FPS because there would be a very noticeable delay before you see visible results from your input. That’s why we take it one step further with another concept called client-side prediction, and this is where things get a little more complicated.

 

Why am I writing this post?

  • I would like a link I can send to people when trying to describe what it is.
  • I’m going to detail the progress of my new sandbox project.

 

Let’s continue with some more detailed explanations.

 

1. Client connects to a game server. (What happens when a user joins an online game)

The server tells all the clients connected to it to instantiate the character. There are 3 different “perspectives” of this character.

1. Owner. The character the server instantiates. The server has full control over this character. In a server auth game this is the only version of the character that matters. It’s position, rotation, health, ammo count..etc are the actual values, regardless of what either the user’s client says, or what other clients say.

2. Controller. As far as the user can tell this is their character, but it isn’t really. It’s just a local representation of the actual character. If the user tries to cheat and tell the character to teleport somewhere it will only affect this local character and neither the server nor other users will be affected. If the user wants to effect the actual character they have to ask politely by sending the server predefined inputs like “walk forward”.

3. Proxy. This is the copy of the character that other users will see. They have neither ownership nor control over this character. All changes to the owner, the server’s copy of the character, will be synced over and applied to it.

 

2. User input. (What happens when the user presses W) 

Every server tick the user input gets polled and wrapped up into a command that is sent to the server. The server takes a look a look at the input and applies it to it’s copy of the character. In this case the input was ‘W’ and the character moved forward. The results of the input are written down and sent back to the client. The client then resets it’s version of the character state to the results it just received. Normally server auth games will take this a step further with client-side predictions but I’ll save that for another post.

Leave a Reply

Your email address will not be published. Required fields are marked *