The Krilling team is back at work from a short break. I didn’t have a lot of things to do this week, my portion of things is complete, so I ended up taking various miscellaneous tasks from our other team members. These were mostly simple and short changes. The first thing I did was just move a couple of objects to different locations in the scene. After that, our sound designer wanted a way to play a sound when the guests pulled out a chair to sit in. For that, I just went to the portion of the code where the chairs are pulled out and added a sound to play using some systems already set up by our sound programmer. To avoid forcing our sound designer to go around and manually add in the sound to various chairs around the scene I just decided to take a shortcut and put the reference to the sound in the sound queue file itself. It’s not the greatest practice, but we are nearing the end, and it makes life easier for our sound designer. The last thing I did was look at the rolling cart object and stop it from crashing into seemingly invisible things stopping it from moving. This was mostly areas of the floor that were slightly higher than others. To fix this I removed the colliders from the various floor objects and consolidated them all into 1 large collider. This doesn’t fix everything as there is still the issue of going up the stairs. The cart can go up the stairs, but there is a bounce-back functionality that was made to push the cart back when it runs into something. This meant that it would never make it up the stairs since it just kept bouncing off of it. To fix this I simply added a tag to all the floor objects including the stairs and when checking collision for the bounce back I check if that tag is present and if it is I ignore the collision.

That is all on The Krilling but now that I have had time after returning from GDC, I figured it would be a good time to talk more about this side project of mine.

First off, I wanted to discuss different ways of doing movement systems. In my time I have experimented with 3 main ways of doing movement, and I want to discuss the pros and cons of them. The main 3 ways I have found are Rigidbodies using forces, Rigidbodies using velocity, and kinematic bodies with your own physics. These increase in complexity but decrease in limitations.

Rigid bodies with forces can give you a pretty good and easy simulation of physics. If the movement system is fairly unimportant then this can be a good route since it is very fast to implement and get decent results. The problem is when trying to fine-tune it to the experience you want or are creating unorthodox movement systems it takes a lot of work to create the functionality you want. For instance, the dash functionality was discussed in my last post. I needed this shortcut of subtracting the opposite velocity to make sure the dash was always relatively the same speed and not run into the issue of the dash just canceling out momentum and going nowhere.

Rigidbodies with velocity give you a lot more control over how the character is moving, but at the same time can take more work. Before, to dash, I needed to just add an impulse force and call it a day. Now with velocity, I get to set the velocity directly, but that velocity should last for a short time, meaning I will need to keep setting the velocity for the duration of the dash. Now I need to set up some form of timer to set the velocity correctly while dashing. This is fairly simple but is an example of how a previously simple task can become a bit more complicated. This system also has its fair share of limitations. Since Rigidbodies are tied into the physics systems it can be difficult to control them in ways that don’t use physics, for instance changing the position of a Rigidbody can create odd behavior with it often teleporting back to where it was before.

Working with your own physics removes these limitations, but obviously comes with a fair amount of overhead. At the very least Godot contains move_and_slide and move_and_collide functions that allow you to move your player and have it interact with collision still. This simplifies things a lot and then we just take the same approach we had with a Rigidbody with velocity, but we have more control over the complete state of our player.

Here is an example of how I am doing the movement in this way.

Moving on to a new topic, input buffering. The main way of achieving input buffering is to start a timer when the button is pressed and for the duration of that timer, the button counts as pressed. I moved all of my input functionality into its own class, and it takes care of all of the input buffering. However, there is one issue with this way of doing input buffering. If you are using manual timers by subtracting the delta of each frame, then your input buffering can become inconsistent. For instance, if you have a delta of .02 for each frame, and you set the amount of input delay to .05, then when subtracting the delta, it won’t be until .06 seconds later that the buffer is actually revoked. This doesn’t make a massive difference, but it does make the amount of time a buffer lasts mildly related to the frame rate. To solve this, I decided to work inside of the physics update. Instead of having timers that represent real-time seconds, I have timers that represent a number of physics frames, meaning that each physics update 1 is subtracted from the timers. Since physics update is locked to a specific frame rate it allows us to get consistent and predictable timer durations.

Next is a quality-of-life feature that can go unnoticed, freeze frames. Since the dash uses the direction of the wasd characters the player must make sure to press the correct keys before dashing. This can often lead to players dashing in the wrong direction because they pressed dash and then moved their fingers to a different wasd direction right after. A subtle way to solve this is to add freeze frames. Freezing the game when the dash button is pressed gives the player a small window to adjust the direction they are inputting after pressing dash. This is a massive improvement to how a game feels to control. Yes, it is possible for a player to input a dash in the direction they want to go, then unintentionally change the direction within the freeze frames, causing this same misdashing phenomenon. However, this problem is far less common, as a player is more likely to hold the direction for a couple of frames after pressing dash.

The last thing I want to talk about is an experiment I did with portals. At the base level, I created these portals by having colliders with scripts on them that when overlapping with a player “teleports” the player to the other one, more on that later. To start with when the player is suddenly moved to the other one then obviously they will overlap with the new one. To avoid this sending the player back and forth over and over I start a short cooldown when teleporting. The cooldown isn’t long but it gives enough time for the player to move out of the portal without getting sent back. Now for the actual teleporting we need to both move the player to the new location and also transform the players velocity into the new direction. Moving the player is as simple as updating its position. To transform the velocity we can reuse our functionality from the grappling hook with our inverse_transform_velocity and transform_velocity functions. First, we use inverse transform to transform the player's velocity to be in relation to the local space of the teleporter we entered, then we can use transform velocity using the exit teleporter to convert it back into global space. You can think of it as figuring out the player's velocity relative to the portal, then mapping that relative velocity onto the other portal and extrapolating that out to the global space. One last important note is that before transforming the velocity back we need to invert the x velocity since the player is going to be exiting the portal rather than entering it.

That is going to be all for this week. There is still a lot more on this project to share, so stay tuned for the coming weeks when I might find time to continue with updates.