Moving Fast And Breaking Things - Issue #6

With every new side-project come new challenges, but also new learnings that have the potential to expand your mind in unobvious ways.

As a means of inspiration, I wanted to talk about one project in particular that I’m working on and some of the technical struggles that are not apparent from the outside (and that I didn’t consider going into it).

Thamira: The Sorceress is a mobile game we’ve developed with my friend for over a year. I jumped into game development without previous knowledge of most concepts around it (and I still struggle with quaternions). There is a major mental switch coming from writing code for apps and websites. From mainly writing code that runs every couple of seconds to writing code that has to run at least 24 times per second at any given time (or ideally 60 times per second).

That means that even physics in the game has to be calculated at a given rate. If your player has a fast computer, you will calculate the physics of all objects in your game 60 times every second. But if the player has an old phone, this can drop heavily. That means the physics and game logic may be calculated less frequently depending on the device the simulation is running on. This can lead to some fascinating issues.

Let’s consider a bullet (or any different projectile) that moves at a certain speed. We want the bullet to always move at the same speed regardless of whether the player has a powerful computer or a cheap phone. So we’ll calculate the distance the bullet travels by using the speed of the bullet and the time that passes between frames (time between the two calculations of physics in the game).

On lower-end devices that cannot make calculations as quickly, the physics calculation may happen, e.g., ten times per second. Therefore, the bullet would move by six times larger distance per frame than on a device that can do 60 physics calculations per second. This is an issue because it can mean the bullet might skip the collider of another object like a wall or an enemy and fly through as the bullet will never actually touch the wall in this particular simulation.

To fix an issue like this, we might need to calculate the bullet’s trajectory independently of the actual bullet (and this is called raycasting). When the bullet is fired, we calculate what and where it’s going to hit. The bullet itself would then be only for visual effect, but it won’t impact the actual gameplay or physics.

Though, this solution only works when the bullet moves really fast. If there’s a slower projectile, we might need to move over to some more complex method, e.g., raycasting from the bullet to projected distance between frames to predict whether the bullet will hit something on the next frame. And in multiplayer, this problem gets even more complex by the orders of magnitude.

If you know games like Cyperpunk 2077, you might’ve heard about a lot of bugs. One of them occurred when you drove very fast and crashed into something. After the collision, you might’ve gotten stuck in the object. And while I’m not 100% sure, it’s likely because of this frame rate issue. And that’d also explain why the PC version didn’t have as many bugs as the consoles version, since these titles generally run slower on consoles (And almost no bugs on Stadia, since that runs on powerful remote servers).

This is one of the issues that I had fun dealing with. At first, I was surprised something like this isn’t handled on the game engine, but game engines like Unity or Unreal are supposed to be very flexible, and therefore you have to often rely on learning these concepts on your own. And different solutions work for different scenarios.

But after many iterations and solved issues like the one above, we have an alpha version of the game that works and that you can try right now on iOS and Android!

The next step is to implement multiplayer for it so you can challenge your friends and have tournaments. As I mentioned before, doing multiplayer comes with even greater challenges. In the example of the bullet, another factor for the physics calculation would then be the network delay between the connected devices. This, again, has a plethora of different solutions. But that’s the fun of game and simulation development.

I hope you got to learn something with all this. Have a wonderful Sunday!