G'day! I'm an Indie developer, lone-wolf style! I'm a Christian, I'm Australian, and for some reason I live in Canada. KarBOOM is my debut title, coming out for Windows, Mac & Linux this Tuesday!

Report RSS Online... ouch...

Posted by on

Wow. Okay. Online is still coming to KarBOOM, of course. But what an effort it's turning out to be! After a ridiculous amount of work since the last update, the current state of KarBOOM Online (not publicly released yet) has a serverlist system that makes it pretty easy for people who want to start a new game to get their session listed online and pretty easy for people who want to join a game to find one. Joining a session puts one car into the level that is controlled with the first keyboard controls.

And that's it, for now.

I still have to implement mixed offline-online play, password protection, player accounts, scoring, rounds, mutators, player disconnection, menus, wannabe-hosts who need to set up port-forwarding and whatever else is going to come up! There's still so much to do! But I really want to get a solid and fun KarBOOM Online publicly available by Christmas!

The dead-reckoning system I've just finished is pretty solid. Dead-reckoning refers to position-prediction techniques to cover up the effects of lag. Obviously, to prevent cheating all game logic is performed on the server, with clients simply sending their input. Their's a different function governing the motion of cars depending on whether that computer is the server or a client. The server's car function is easy -- it's actually the same function I've been using all this time for offline play, with a fourth input type: online packet (the first three being keyboard, gamepad, and bot-logic). Also, a few lines of code are added sending each car's state to all the clients at regular intervals. And that's all it needs to be a find-and-dandy server.

The clients are a bit tricker.

I originally copy-pasted the function I use for replay-cars and modified it from there, with cars interpolating their positions based on states coming in from the server rather than saved game-states. This proved much less effective in this situation, however, since the more I smoothed out their motion, the more lag was exaggerated. To be more clear: I could either have sudden jumps to each new position as soon as it arrived to reduce lag as much as possible -- but that was ugly and unplayable -- or I could smoothly interpolate between the previous position and the latest position, but that just meant by the time the car reached the last-received state it was already well out of date.

What I've done now is much better: player states are now sent even less regularly from the server, but player input is sent from the server to the clients quite regularly. Player input packets are much smaller than player states, and they assist in predicting appropriate motion for each car, so all-in-all this reduces network traffic. Now, each car displayed on the client contains two states: one that you can see, and one that is updated as regularly and quickly as possible by the server as before (with no smoothing). Each frame, player input as received from the server (or, if the car is controlled by this client, straight from the player his/herself), and appropriate physics calculations are performed on both states. That is, the visible car is moved forward according to its acceleration, direction and player input; and the latest player state received from the server is moved forward according to its own acceleration, direction and player input.

What we end up with is two new states:

  1. the best possible prediction of the state this car is currently in on the server;
  2. and the most suitable state for the car to visibly be in based on the last state the player saw and all current input.

The final state the player sees is an interpolation between those two states. This new state is used as the visible state for the next frame, while the modified server-state is used as the server-state for the next frame unless a new state is received over the network. It requires some fine-tuning -- if the interpolation factor is too high we get sudden jolts again between states; if the interpolation factor is too low then the visible state will get further and further out of sync with the server's state. But it appears to be working well!
I can't wait to see how well it works with people on opposite sides of the world playing with and against each other!

Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: