This post is a part of Game-A-Week 2023, and was released alongside Game-A-Week 14: Shmup Demo. Play it here.

 Designing video games is, in addition to many things, a test in decision making.

There are the obvious decisions- how many shots can a certain enemy take? Does the player slow down when firing? How much currency does an enemy drop when killed? These are what the player is conscious of.

But what I spend more time thinking about are the seemingly insignificant decisions- how is damage tracked if an enemy is hit twice in a frame? How much slower is a player while firing, and how quickly or smoothly does the speed wind down? At what velocity does currency drop from enemies?

Thinking through each of these questions, and testing various possibilities can eat up a lot of time. Oftentimes the question has been solved, but oftentimes the solution has it's own issues, or doesn't fit your desired game-feel.

For example, I tried an experiment in this game I had never seen done before: while a player is shooting, they cannot change the direction they are facing. The player still can move left or right, but they must keep shooting in the same direction until the shoot button is released.

Space shooters where the player cannot turn often feel very restrictive, while games where the player can turn remove the player's ability to shoot backwards. I hope my experiment provides a happy middleground (without needing an extra button to lock facing).

This has some technical limitations. The player is restricted to a shooting cooldown of 170ms, so they can shoot about 6 times a second. The player can flip while the shoot button is not pressed with no restrictions, but the cooldown timer is unaffected. This means that if a player shoots left, flips right, and presses the shoot button, there will be a delay in the shot being fired. 170ms is not a lot of time, and most players won't consciously notice it, but these are the kinds of quirks that create game-feel.

During early tests, if the player flipped, then tapped the shoot button within those 170ms, no shot would fire. To fix this, I created an input buffer- a common technique which stores an input for a limited time to perform the related action when it becomes possible.

But how long do you buffer the input for? I set it at 170ms to match (170ms has become my default for "long enough to make a difference, but not long enough to be a noticeable span of time"), but games often buffer different inputs for different amounts of time, some buffering an input for several seconds.

All of this is to say that there really is no limit to how precisely you can tune the most minute action in a game. Input buffering provides a great depth of options for improving game-feel and it is only one of many tools at a game dev's toolbelt.

What about you?

Do you have any resources for fine-tuning mechanics? Other interesting tools or tricks?

What span of time do you feel is "long enough to make a difference, but not long enough to be a noticeable span of time"? I wonder if we perceive time differently.

If you played Game-A-Week 14, how did it feel?

Thank you for reading and I will be back next week!

- Ciaran