Hello and welcome to my last dev blog for this project. It’s been ten weeks since we started this project and now we’re in our last week working on it.

So last time I wrote that I would do my best to bring you a preview of client side prediction for this blog. Well it seems I was a bit too ambitious as there were a lot more to do than just start doing it.

What I did wrong

I would not be able to rely on blueprints when developing the prediction and there was the biggest problem. I was not knowledgeable enough in using C++ with blueprints in Unreal Engine, and as such I would have to learn it under the project. If I had started working with C++ at the start of this project, then it wouldn’t have been a big problem.

For the past ten weeks I’ve learned a lot of developing a game with Unreal Engine, and I think I’ve contributed my share on the project. But I wish that I could’ve done much more on the time I was given.

I had planned to show you much more than the progression of the lobby on my dev blogs. I wanted to make my own client-side prediction, as well as a small anti-cheat system. For those of you who are interested in how it would work in the game we have now, I will tell you how I envisioned it.

Client side prediction

As for the explanation of how client-side prediction works, I wrote about that in my previous blog.

Say that we have two players on a server one which is me. To get the other player to move smoothly I would have to predict where the player is going based on what input I was last given. I would store the other player’s input from the last two times I received them, so I would make two classes called: LastInput() and SecondLastInput().

Both classes would store the same types of information, only slightly different from one another. They would include a position, amount of force, the direction of force and a timer float. LastInput() would get overridden for every new input, and SecondLastInput() would copy LastInput() before it’s overridden.

With this I would be able to predict where the other players is going based on the members of LastInput(). I can then also calculate the players acceleration, if there is one and then stop accelerating when the maximum allowed speed is reached.

This would be considered a very simple client-side prediction. Because when experiencing longer intervals between inputs from the server, other players would end up walking in a straight line until next received input. Which is fine for a ten week project in my opinion.

How I would do my the client-side prediction also leads me to how the server would handle cheaters trying to speed-hack or just teleporting around.

Server anti-cheat system

The server could also predict where clients should be, However this would only be a local and much weaker kind of predicting. Because the server should tell clients where they are based on where it thinks they are, rather it should only tell them if it thinks they are farther away than possible.

So the server would do the same as I wrote in the client-side prediction section, with a bit more added to it. If the server can calculate acceleration and current force then it can also calculate the amount speed a player can have for every tick. This hinders players from increasing their acceleration speed.

If a player excels the max speed then I would either set their speed to the max speed, or kick them from the game (I would probably kick them since cheating is a sin).

Using this calculation I can also tell, based on their speed, acceleration and elapsed time between each input, how far it’s possible to be from their last known position. Hence making it harder to cheat.

I wish I could implement these functionalities before the end of the project but hey, it’s normal to be overly ambitious when developing a game and it’s normal not being able to finish everything one would like to implement.

It’s been a fun project and I’m glad to have been a part of it. Thank you for reading about the development of Project Sky Conquerors,

/Kevin