How-do-you-do Champions of Battlerite!

My name is Daniel "Prog" Fahlström and I am one of the programmers (Editor's Note: aka "One of the lead devs") here at Stunlock Studios. I've been working hither since January 2013. Some of you might know me from the Bloodline Champions days as I was an active customs fellow member and moderator back then. During the evolution of Battlerite, I've been working in multiple areas such every bit the gameplay backend, UI and localization.

In this blog I will briefly explain how the Champion movement works in Battlerite (without being too technical) and what requirements and challenges nosotros've had with the solution we utilise.

Requirements and Challenges

Responsive

All movement in Battlerite has to feel responsive, as you are in direct command of the graphic symbol. Visual delays to inputs has to be avoided for full immersion and to keep the gameplay fluid and on betoken. This is something we recall we have achieved with our electric current solution. The movement in Battlerite feels very responsive and will practise and so regardless of what your latency might be.

Anti-Cheat

As Battlerite is a competitive game, nosotros put a lot of effort into making sure players are unable to cheat. Due to this, the server is the authority of the actions the thespian performs, meaning all the deportment (Move, Ability Cast, Projectile Collisions etc.) are fully controlled by the server.

The solution therefore requires the server to verify all the deportment sent from a local client (i.e the Battlerite game running on your figurer). The server so makes sure the actions are valid, and volition but send valid positions to all the other clients.

Latency

A challenge that is unavoidable when making an online game is of class latency. It is a mutual rage-cistron in multiple games, especially those relying on responsive inputs and reactions.
Latency causes all actions from a local client to be delayed for all other clients, unless information technology is predicted or simulated. Since latency cannot be avoided, a phrase that is used among the states is "You don't remove the latency, you but determine where to hide it".

In a perfect world all players would have less than 50ms latency to our servers, but every bit that is not the case, a requirement we have is that the solution should piece of work with upwardly to 150ms latency.

Hither is a visual example how the responsiveness would look with and without our solution with a high latency. The green line represents which direction the input is pressed on the customer. Apparently the delayed visual feedback of the input makes the game a lot more sluggish for the player.

Inspiration

Since the motion in Battlerite is based on WASD motility, like to how it works with most FPS games, we took inspiration from the very solid solutions used in Quake and whatever of Valve's Source games. We've adapted their solutions to ameliorate work for Battlerite, but the core of the solution remains the aforementioned.

A big departure betwixt the above mentioned FPS games and Battlerite is that Battlerite uses slower projectiles instead of instant line shots. This means that whenever latency causes visually invalid spell collisions (you getting hitting when information technology looks like a projectile misses) information technology is much more noticeable. The fact that Battlerite is a game with a summit-down photographic camera view further enhances this.

If y'all're interested in reading more than most the solutions nosotros've been inspired by, I've listed some manufactures at the bottom of this blog.

So how does it piece of work?

The simplest style of explaining how the movement system works is to recollect of it like this; The client simulates its movement visually, and sends all false motion commands to the server. This means the client is constantly visually showing the position information technology believes is the current position for the role player. Since the client and the server run the same calculations, a mismatch rarely occurs. If it does, the client volition change the simulation then it matches the expected position on the server.

Here is another visual representation with and without our solution when running with very high latency. This time with some circles showing the position for the client and server. The cherry-red circumvolve represents what position the player has on the server. The greenish circle represents the position on the local client, with the green line representing customer'south input direction.

The green circle is always ahead when we're simulating the move commands on the customer, instantly responding to the input. The server position even so is delayed due to the latency.

Issues

Now, this solution (or any other solution) is non completely perfect since latency volition e'er still be a factor. And also, as mentioned before, collision errors will be a lot easier to spot in a superlative-downwards perspective with projectiles.

Here is an example of a visual fault at a very loftier latency. The scarlet circle that is shown is the position of Shifu when a collision is detected. Even though it looks wrong on the client, information technology is the correct result on the server.

This is something we know players occasionally refer to as "invalid hitboxes", but in bodily fact, a lot of the times it is an result with the latency to the server.

To conclude, issues like these are unavoidable. We desire to allow the client to simulate the motility, withal still permit the server have dominance over the positions. We are aware this is something that has been frustrating for Battlerite players, and nosotros're constantly looking at different ways of solving these issues in society to strive for the best experience possible for all players.

Thank you for reading!
/ @ProgrammerarN

Technical Manufactures

Hither is some of the articles we've used as a inspiration for the network model nosotros use for dissimilar areas of the gameplay in Battlerite.

http://fabiensanglard.net/quake3/network.php
http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking

https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization