DunkRatz Design Blog: Path to the Cheese Cannon

Hi, my name is Ozzie Smith and I’m the designer and programmer on DunkRatz, a local multiplayer game for 2-4 players where each player is a rat on a team that fights over a ball of cheese to feed to their team’s giant baby rat to score a point. We started working on the game back in 2017, inspired by all the fun we had playing the resurgence of great local multiplayer indie games like Nidhogg, Towerfall, and Videoball. The core mechanic in DunkRatz is the movement and throwing system, where players can only move around by dashing with the A button, but if they touch something else (like the cheese) they will pick it up and then they have to throw it with the A button before they can dash again.

Early on (well before we established the rat theme for the game and it was just a prototype of blocks throwing a ball around) we really liked the idea of a dynamic goal that could be picked up and moved around just like the ball. It was really fun and gave the game a unique flavor (we quickly escalated the idea to allow players to pick up and throw other players around too). However, this led to a design problem that was harder for us to solve than we first thought: how do we add in another ball of cheese to the arena after a point has been scored?

DunkRatz is a ball-and-goal game, so first we looked to how other games continue play after a goal is scored. In Soccer or Rocket League the action stops and the game is reset: everyone goes back to their starting positions and the ball is moved back to the center of the field. We quickly decided against this as goals could be scored so quickly and so often in DunkRatz that it totally broke the flow of the action. In Basketball the team that was scored on gets to check the ball back in from their side of the court, but that also wouldn’t work with DunkRatz since the dynamic goal locations means no team really has a “side” of the court. And in Videoball (the closest design to our own) the ball is automatically respawned in the center after a few seconds. We decided against that as well: with this mechanic the game just became about crowding the center of the map trying to get the respawning ball as soon as possible (or constantly moving the goals to the center of the map). We needed a new solution.

Iteration 1: The bumper

In the early prototypes I was inspired by the quick, casual “ball respawn mechanic” in foosball where the losing team throws the ball back into the table. So I added a “bumper” in the top middle of the map that needed to be touched by a player to spawn in a new ball. I liked the idea of players being able to decide when the new ball came into play, and I wanted to reward teams working together and so the ball would spawn far enough away from the bumper that player that spawned it wouldn’t be able to immediately grab it.

Iteration 2: Two bumpers

A problem we had with the bumper was that it ultimately wasn’t too different from just spawning the ball in the center automatically, as once players knew what was happening they would still just camp where the ball would spawn. So a second bumper and ball spawn location were added, and now teams couldn’t camp the single ball spawn location.

Iteration 3: Moving spawns

The respawn mechanic was a lot more fun when there were 2 bumpers but we knew it could be improved. We tried making the spawns move back and forth to make it more dynamic. Now timing was required to get a “good” spawn.

Iteration 4: Delayed, invisible spawns

It started to feel like trying to get an instant goal off of a ball spawn was too easy and the best strategy in the game. So we began messing around with some ways to make that a lot harder to do. First thing we tried was to just hide where the ball was going to land, but to show the ball being shot out of the bumper towards the spawn location. This concept eventually evolved into the cheese cannons that are in the final version of the game.

Iteration 5: A longer delay, but anywhere in the arena

While it was sort of fun to guess where the ball would spawn, it ultimately felt too random. So we tried delaying the spawn: after the bumper is the spawn location is marked on the arena but it will take a few seconds to get there. This felt so fair that we even opened up the “spawn location” to the entire map.

Iteration 6: Forcefields

The problem with the last iteration was that it was very hard to get the “timing” to feel right. Since the cheese ball could spawn anywhere we felt like we needed to give players enough time to reposition themselves for it, but sometimes that left too much downtime. In this iteration we added in a forcefield around the spawn once it was selected so that we could make the cheese spawn slightly faster but it felt more fair since no one can “catch” the cheese ball as soon as it spawned.

Iteration 7: The arcs

The forcefield spawns were neat, but we realized that the real problem was just not knowing where the cheese ball would spawn. It also made the bumpers completely useless (we even took them out for a bit), as what’s the point of hitting a bumper that will spawn something totally randomly with no benefit to being the one who spawned it? We went back to 2 bumpers and showing where the ball would spawn, but now they move in arcs.

Final iteration: The cheese cannons

We went back and forth for a bit between keeping the forcefields or not, but eventually decided that they broke the flow a little too much. Our design philosophy that we inevitably went back to again and again was “let them dunk.” The final iteration uses the arcs, but the ball lands with a big explosion that pushes everything back. This lets players still try to catch the ball right when it lands but punishes them for missing their timing. An added benefit of the explosion is that it acts like a big hit in a game of billiards and sorta “breaks up the board” so to speak, and it’s just really fun to see.

Other final adjustments include adding a “cheese timer” that automatically picks one of the 2 cannons at random to fire after 8 seconds if neither cannon is activated by the players. And once we decided to replace the “bumpers” with refrigerators we had a new set of art readability problems as players didn’t understand that they were supposed to hit them. Many art passes gave us the final version where the refrigerator light up and glow just like the special item cabinets in the game. We even added in big GUI pop-ups that say “touch for cheese” with an arrow pointing to the fridges. Admittedly it’s sort of lazy and messy, but nonetheless it’s pretty effective and doesn’t get in the way of the play-area.

Takeaways

Give yourself time to design around unknown unknowns. DunkRatz was made as a part-time side project. We had no deadline, so we had plenty of time to iterate on solutions. But I had no idea we would end up spending â…” of the development time still testing out solutions for such a simple problem. The simple mechanic of having moveable goals completely changed the way that a staple mechanic of the genre worked for the game.

It’s fun to experiment, but new solutions can give you new problems that can distract you from the original problem. Part of what took us so long to figure it out is that we kept trying to fix new problems caused by previous solutions. The forcefields were cool, but we only invented them to try to fix a problem of an imperfect solution. We wanted to use bumpers to keep the pace of the game up and keep the flow going, but instead of focusing on that we kept slowing the game down because we were worried about it being too random or unfair. Once we embraced the “let them dunk” mentality, it became obvious which solutions worked best.

DunkRatz is available for preorder on Steam now, launching on July 19th!