top of page
  • Writer's pictureDoğa

Delegate Based Animation Callback System

Updated: Feb 1, 2023

Introduction


That's a system that I've designed to reduce overhead on adding new weapon types into one of my pet projects. It's based on a single super lightweight header file, which is called WeaponEvent:


As you can see from the contents of the header, it's providing us a struct with well defined event types, like "End", "Begin", "Process", "Trigger" etc. Those events require them to be bound by a lambda function, and get called inside timeline of the animations with anim notifies. For example, if we want to define a weapon fire event, we should create an event struct, bind required logic inside related events with lambda functions, and then call them inside our weapon fire animation with anim notifies. In that case, our "Begin" event should set a boolean named "bIsFiring" to true, "Process" event should fire the bullet and apply damage if any hit happens, and lastly "End" event should set "bIsFiring" to false back, to let other modules know if we're currently firing or not.


Animation notifies are handled with two different classes, as shown below:



As seen in the code blocks, notify state class defines when an weapon event begins & ends. Notify class can be any kind of event type, and it's mostly implemented for more specific needs, for example, you can trigger the Process event in bounds of notify state in an animation timeline. For a fire animation, the timeline looks like this:


In this sample animation, we run the weapon fire logic just when the "Fire: Process" notify is fired, and the only job of this notify is retrieving defined fire event from currently equipped weapon, and calling its "Process" callback function. On final state of the project, whole list of weapon animations are marked with those animation notifies, and works flawlessly without any performance drawback. It's also possible to make events blocking, which means during an event, another event cannot be started, which reduces complexity of weapon source code a lot, because of non-existing if/else checks for each event type.

Lastly, I'm also attaching a sample source code for binding weapon fire event. As you can see, I've bound required weapon logic for each event type, and registered the event struct for the weapon instance.



In this sample animation, we run the weapon fire logic just when the "Fire: Process" notify is fired, and the only job of this notify is retrieving defined fire event from currently equipped weapon, and calling its "Process" callback function. On final state of the project, whole list of weapon animations are marked with those animation notifies, and works flawlessly without any performance drawback. It's also possible to make events blocking, which means during an event, another event cannot be started, which reduces complexity of weapon source code a lot, because of non-existing if/else checks for each event type.

Lastly, I'm also attaching a sample source code for binding weapon fire event. As you can see, I've bound required weapon logic for each event type, and registered the event struct for the weapon instance.


195 views0 comments
bottom of page