Tuesday, February 18, 2020

The Poor Man's Gameplay Cue in UE4

I have some time this morning to collect my thoughts, so one thing I want to do is share a quick post here about something interesting I encountered a few days ago.

On Feb 13, Epic hosted a Live from HQ stream on Game Jam Tips and Tricks, which you can find archived on YouTube. In this stream, Michael Noland introduced a useful pattern for UE4 Blueprint programming that I had not seen or thought of before. He mentions that it is inspired by the Gameplay Abilities system, which I am sure I have tried to learn more than once, and each time I think, "This is amazing and also way out of scope for my project!" Then, I forget the important details and carry on. The Gameplay Abilities system is still (or again?) something I want to invest some time in understanding, and I'm hoping in part that by recording this smaller version here, I'll give myself and others an anchor to understand the more complex version.

At 54:15, Noland begins an explanation of why Sound Cues are a useful extension of normal Sound classes. I've been a fan of Sound Cues at least since working on Kaiju Kaboom, where I wanted variation on sound effect volume and modulation. He builds on this, starting around 56:26, explaining the value of decoupling game effects ("juice") from the core game rules. In particular, he mentions that certain blueprints will be high-contention, such as pawns, game modes, and player controllers. Separating the game effects from the other rules means that multiple people can be working simultaneously without version control conflicts, since these behaviors are now in different files.

After a few minutes, he ends up with a hierarchy like this (changing his naming scheme slightly to follow the Gamemakin Style that I prefer):

When the BP_StandardGameplayCue is spawned, it plays any sound, particle effect, or camera shake that has been set, checking via validated get. Noland points out that a slightly more robust system would have to account for who instigated the effect so that it could, to cite his example, do something like set that character on fire or give him a halo.

I hope that write-up is useful, if for nothing else than to help me remember this interesting pattern next time I'm working on a collaborative jam project or trying once again to make sense out of Gameplay Abilities. I wonder if I had known this a few weeks ago if I could have unleashed my son a bit more freely to work on visual effects in Disarmed.

No comments:

Post a Comment