SEAR DevBlog, week of 11/24: SFX and VFX heading into the holiday

Yeah, this is why I hire artists.

Early post this week as I will be out the rest of this week for the US Thanksgiving holiday. That also means the update will be a bit shorter as there is less "stuff" overall to report.

Our new sound designer got cranking this week and I feel like I am witnessing in realtime what actual MetaSounds are able to do - there was a lot of functionality we were missing there and it'll be great to see what he can do with it. Looking forward to finally diving in on some tonal matching and other cool things where we take into account the song that's playing while playing a sound effect and adjusting accordingly.

That word "accordingly" masks a sizeable design philosophy that has to be ironed out. I had a discussion earlier this year in the community Discord about this, but essentially, this is a game with both asynchronous sounds - primarily triggered directly by player input, but also player agency in general, such as passing another vehicle - as well as synchronous sounds, which are sfx that hinge directly off of an event that happens at a very specific point in the song, typically on a particular beat. We need to thread the needle between sharp, punchy sfx that clearly stand out from the soundscape and more harmonious fx that don't quite integrate with the song per se, but definitely sound more like they could plausibly be a part of the song while still conveying the audible information they're meant to convey.

Threading that needle, figuring out how much to do each type of sound and when, has been an internal point of contention for me for much of this year. But now that the rubber is hitting the road and we're knee-deep in sound design, what we're quickly concluding is that the former effect - sharpy and punchy - is going to be more appropriate for the asynchronous effects, and the latter, harmonious effect is more appropriate for the song-synchronous effects. It will be fun to hear this play out in the soundscape as it develops.

Parallel to this conversation this week has been development on the fancier new Wave Sensor, part of the visual overhaul to make the whole game more visually appealing and make it more capable of producing the types of screen captures that make people click links and start playing videos. It's really exciting to see this stuff start to come together, and the image at the top is of my earliest chicken-scratch in MS Paint of what I thought our first approach could look like. We're iterating on it from there, but it's coming together and will be very cool once it's in.

On top of those discussions I've nearly completed a full redesign of the Player Res Event system in the project. I originally designed this as more logic-driven rather than object-based, and have repeatedly hit milestones where it was clear that an object-based solution would be very helpful, but until now I've been able to adapt the existing system without rewriting it. After waffling on this for the last several months, I've finally decided it's time to bite the bullet and do the rewrite. Walking through the process has been extremely illuminating and identified some desperately needed clarity around PREs and what objects should implement each step of their resolution. Long story short, this rewrite will cut down the number of timelines running at any given time for any given PRE from one-per-participant to just 2, period. So it will be good for performance, and be much more scalable than the previous solution.

Last but not least: by Friday of next week I should know whether or not we landed an Epic Megagrant.

Talk to you then.