Chucksaw was born out of an idea to make a party game that I could play with my friends. Finding party games that everyone likes is difficult, so I decided to make my own. The initial idea was very different to the final product, though. Originally you had to reflect balls into an opposing player’s goal to score points, but the initial prototype had players trying to reflect a ball to crush the other player. That proved fun enough that I stuck with it (and it was easier to code to support variable amounts of players, haha).

The core mechanics were pretty much made in a couple of days. A player object with a couple states (default, holding saw) was as simple as possible. Saws also have only two states (default, being held). This stayed for a day or two until I decided I wanted to add another move the player could use while playing: the dash. I wanted some extra mobility to dodge saws, but quickly realized it would be fun to also dash into the saw itself, ricocheting it back quickly. Because of how quick it was to execute and always sends the saw at max speed, it became a dominant strategy for my players. Thus, the stunned state was added so that dashing into the saw had some kind of a drawback for the players. In a way, the dash is simply a more high-risk throw.

Even in this unpolished state that had a lot of bugs with edge cases, the game was really fun to play. It had a similar flow to Stick Fight: The Game, which I really enjoyed. The rounds go so fast you don’t even get to think about winning or losing. You don’t have enough time to get salty. Micro breaks between rounds let you rest for just a moment before continuing.

Hardest part of developing the game was definitely handling multiple players joining in and out and keeping track of the game state with multiple players. I don’t tend to make games that really handle a lot of data, so I had to dig a bit deeper on how I wanted to keep track of everything. Eventually I settled on having a few global lists to keep track of scores, alive players and connected controllers. Simple stuff, really, but pretty alien to me nevertheless. In hindsight I could have used existing libraries to keep track of players joining in and out but in my mad dash of prototyping I didn’t even consider it. In the end, it all works and theoretically scales up to infinity with the player amounts.

So, how does the game work? Or, rather, why does it work?

The way I see it, Chucksaw is a mind game in its core. As fast as the game is, the player is always rewarded more for outsmarting the others instead of having godlike reflexes. There’s a couple reasons for why I think this is the case.

Chucksaw utilizes a kind of game design philosophy where there’s inherent risk in taking any action. For everything you do, you also lose something, making you vulnerable. But if you don’t do anything, you are even more vulnerable to being killed by other players, forcing you to take action. All player actions kind of share this invisible “resource”. That resource enables the player to interact with the saw or other players. By spending it (taking an action) the player will have to wait a short while before they can interact with anything again, and that’s really important because it makes every single action twofold.

When taking action, you have to plan how to kill your opponent, but you also have to plan how to survive until you have that resource again. This way players don’t default to trying to employ the most deadly strategies and instead think of their own survival. If my plan goes wrong, how do I make sure I also don’t get dunked on? Points getting rewarded for survival rather than kills accent this philosophy.

I think there’s something fundamentally interesting in that sort of thing. If you throw a saw directly into an opposing player and they foresee it, you will die instantly as they dash into the saw you just threw. This is when Chucksaw becomes a mind game. If you think the other player will think you’ll throw the saw at them, you might opt to ricochet your saw from a wall, making your opponent dash into you fruitlessly. But the other player might anticipate you thinking that and deploy a different plan. This cycle repeats ad infinitum and forms the basic spine of Chucksaw’s gameplay. All this sounds messy when writing it out, so I’d recommend trying the game to see it in action. It required a lot of work to get the game functioning this way, though. There’s a couple very important factors that enable this.

Input leniency to start with is needed for this game to function. Instead of having to catch the saw as it is near you, you can opt to hold the needed button down before the saw is near enough for you to catch. You will remain able to catch the saw for a short while until this time expires and you lose your resource. Again, no need to have great reflexes if you can simply predict when the other is going to throw their saw and just hold the button to prepare for it. By preparing this way, you are banking on the other player to throw it before your resource runs out. The catch is, the throwing player also has their resource. They can’t infinitely hold the saw without throwing, so once again it becomes a battle of wits between the players. Dashing utilizes the same kind of philosophy as you can still hit the saw at the very end of your dash for the same effect as timing it perfectly at the start.

Secondly, these timers until the player loses their resource need to be balanced against each other. It’s incredibly important that all of them are tuned so that the basic flow of the game works. These timers include:

• Time the player can prepare to catch a saw until losing their resource
• Time the player spends in the dashing state before reverting to normal state
• Time the player spends in the stunned state after dashing into a saw
• Time the player can hold the saw before exploding
• Time it takes for the player to regenerate their resource to do these things

Maybe you could make a billion different games out of Chucksaw by simply changing these timers. Each permutation would result in a slightly different feel to the game and I truly don’t know if the values I settled on are the best they could be for the feel I want. But, they’re close enough. These timers are a huge part of the risk you take when taking action in Chucksaw and combined with the speed of the saw when thrown and the way you throw it offer infinite scenarios each time you take any action in the game. Then you take into account the other player and their resource and yeah, I think I’m repeating myself here. Can you tell these posts are written in a flow of mind way?

There’s so much to how Chucksaw works but I feel like the things I’ve talked about here highlight the most important bits. Obviously there are a ton of effects plastered to everything, but I wanted to focus on the nuts and bolts on this one. Maybe I’ll write more in the future, if anyone asks.