SEAR DevBlog, weeks of 9/7 and 9/14: What's in a Reswave? Part 1
I’ve gone back and forth for a long time on how much to use the word “rhythm” when describing SEAR. On the one hand, the term is ubiquitous shorthand and people automatically know what it means. On the other hand, the rhythm genre invokes a certain playstyle that SEAR does not conform to in the most traditional sense, and I don’t want people to come in with bad expectations.
What I’ve realized from talking to gamers who’ve tried or are looking forward to the game, though, is that it doesn’t really matter whether I use the term or not - people are going to use it regardless. So it feels more important to qualify it rather than try to avoid it.
At 2D Con last month I started describing the game as “high-speed racing with a splash of forgiving rhythm mechanics” and that seemed to make sense to people. So in this post I thought it would be good to talk about exactly what that means, but as I got started on it, I realized exactly how much design time has actually gone into getting this right.
As I got started on SEAR last year the only set of mechanics I knew for sure the game would have was the phasing. That’s the piece that lets true racing control and hard musical limits work together, and afford each the full respect it deserves. Beyond that, though, I wasn’t initially sure. Since it was a “music” game, did it make sense to have the player just hold in an accelerator, for example, or should they have to tap a button to the beat in order to maintain acceleration and stop that rhythm when they wanted to let off the gas? In other words, was SEAR going to be a racing game first, or a rhythm game first?
It didn’t take long for me to reach the realization that racing had to be primary between the two. I was playing a racing game (not a rhythm game) when I first had the idea. The feel of racing was the one I was trying to capture first and foremost. And IMO true racing that is synched with music is what hadn’t been done, while rhythm had been explored pretty well. SEAR respects the music, but the whole idea is that you can respect the music without forcing the player to act strictly on beat. So for the most part, the driving should be the driving, and the music should be the music.
But that said, there are definitely moments in any given song where it feels like a rhythm mechanic is appropriate. By far the most obvious of these is a speed boost. In fast-paced EDM a whoosh or doppler cry is a fairly common sound to hear and ever since the first time I heard one while playing a racing game, my car was practically begging for a speed boost off of it. So then the question became, should that be something the player has to opt in to, or should they just automatically get it? There were arguments to be made for both, but I liked the idea that the player might not want every speed boost the song offered them. In a racing game you choose your moments to pop your boosts, and using one at the wrong time can be highly detrimental. This also fit in with the “racing-game-first” approach.
Great. So, it would be an opt in mechanic. But I didn’t want it to feel like a traditional rhythm mechanic. I wanted it to feel more like a broadly-defined optin/optout. In other words, the input window shouldn’t be a typical tenth-or-less-of-a-second, but wide and forgiving, so that the player could stay focused on their race and opting into the music would feel more like throwing in a dance step instead of zeroing in on a metronome. So how to make that work?
Obviously it would involve hitting a button on (or around) the specific beat that synched to the start of the sound effect in the music. But I had to be careful, because it would be very easy from there to say “Oh, and then the closer you are to hitting the button DIRECTLY on the beat, the stronger the effect is.” I’ve had people suggest this multiple times, and while I don’t hate the idea on face, here’s the thing: if the effect is stronger if you hit it right on the beat, you’re essentially right back where you started. For most players who care about their performance, they’re going to feel intense pressure to get that frame-perfect hit, because it means more speed, and in a race speed is invaluable. But that pressure is exactly what we’re trying to avoid here. I wanted these moments to feel like opportunities, not like punishments waiting to happen.
So the requirements were a wide input window and a binary pass/fail assessment. Good enough. But when I coded it, it felt bad. Why? Because you essentially couldn’t catch it on the beat - you had to press the button early.
The thing about a typical rhythm mechanic with a scaling success assessment is that you can miss the input on either side. In other words, you can press it early or you can press it late, and either way the game will say “near-perfect”, “close” or “miss.” In SEAR, we didn’t really have that “after-the-event” moment. The speed boost HAD to land right on the beat, because the resulting speed HAD to match the music. If it started late, it would feel wrong. So in theory, the absolute latest the player could hit the SEAR button was directly on the beat. Even a fraction of a second late was too late.
Obviously, this sucked. It was the opposite of the forgiving input window I wanted - it was right back to frame-perfect inputs, assuming you wanted to press the button on the beat instead of taking advantage of the early input window. And while it’s easy to say on paper “Oh, just press the button a little early and you’ll be fine,” in practice that felt awful. Every muscle in my hands wanted to hit that button on the beat.
This was a really interesting conundrum, because it was a problem of my own devising. A problem unique to SEAR’s approach. We could give players the window, but we couldn’t force them to use it. If they had an ounce of rhythm in their bones, they wouldn’t want to use it! And then our system felt even worse than the most punishing rhythm window.
I think the solution is simple and thorough, but this post is already too long, so I’ll get into that next week.
Update-wise, we’re in the middle of a bunch of longer-term feature implementations, so week-to-week right now there’s not a whole lot of completed features to report, which is part of why I skipped the update last week. The NPC AI rewrite is still underway. The new level loading process is underway. The TTF reswave is finished enough – there’s still one major element I want to add to it, but tbh if it waited until synchronous online multiplayer, that would be okay. We had good progress on setting up our error tracking for the playtest, the leaderboards, and the UI, and we’ve got our first-draft maps of most of the phases for the new level. All of this while two members of the team were out of town traveling and will continue to be for most of the month. So good progress! Just nothing FINISHED finished.
Talk to you next week.
Comments