Ahoy ahoy humans! You may recall that last week during our programming stream we were trying out a specific attack behavior for the bullcatcher. The goal was to give players a window of escape just before she pounces, to make the bullcatcher a little more manageable for new players. We’ve done more iteration on that and hopefully can show you the changes on Friday. This Friday’s stream will be Dave doing more art, so aspiring artists stop on by at 2pm PST! You can follow our twitch channel to get notified about when we go live.
Solving Sneaky Design Problems
Some of you asked about some of my other findings during my week of “new player playtesting,” and one of them was a very tricky problem with how players mentally map the buttons and the rotation of the bull. You steer the bull clockwise and counterclockwise using both mouse buttons or either trigger on a controller. Most people learn this fairly well, but we were noticing that the mental mapping would sometimes break down in stressful situations (like when the bullcatcher is on your tail) and specifically after bouncing off a wall many people would turn left when they’d intended to turn right, or vice versa.
To narrow down the problem point and figure out how to solve it, we made a UI widget that explicitly shows which button will turn him which direction wherever he’s orienting. This helped me look at the problem case a little more clearly while watching people play.
As you can see in the images below, the mapping breakdown would happen when people hit a wall at a very severe angle, because when the bull exits the bounce, the left/right button association is the exact opposite of what it was when he entered (notice how the blue and red halves are swapped). When in a high stress moment, it’s easy to see how a player could get confused and hit the wrong button, often turning themselves straight into danger.
One idea we’re trying is shifting when the pause on the bounce happens. Currently you ram into a wall and there’s a beat before you reflect off. We’re going to try shifting the pause to the moment when the bull has already reoriented, so players could use that beat to remap which direction they will turn when they hit a button. Thematically, it’ll be something like the bull rams the wall and then has a moment after he bounces off where he gets to his feet before running again.
Here’s the mouse-drawn designer sketch I used to propose the idea to my team.
Will this solution work? Only playtesting will tell!
Here’s a few questions that were leftover from last Friday’s stream.
Mattdwny: have you considered overlaying dischordant music with the regular music based on stress?
From Alex: Not yet! The sound itself is indicative of stress and it might be a little too much if the sound AND music got stressful. You don’t know until you try, though!
Vx967: Maybe a question for later, but: any chance of integrating an external audio engine, such as FMod or Wwise?
From Alex: I have no plans to yet since the game’s audio needs are pretty simple at the moment. But we may need to sometime! It would just take a bit of work to get it integrated seamlessly.
Omgwtfdenny: How do you balance creative and ambitious ideas with resource restraints? Where do you start cutting down?
We have to be very careful about this since it’s such a small team and since it was important to us to be nimble and get something out into the world (relatively) quickly. I’m constantly weighing ideas against the scope we’re working with, and often I think “what problem is this idea trying to solve? Could we solve the same problem in a different way that is within scope? Is the best way to solve the problem to cut out the thing that is causing it?” It’s never an easy balancing act, but I feel like constraints are what forces us to be our most creative selves, so I welcome them.