Is there a better way to handle this

Is there a better way to handle that situation.

I want to apply a Slow Debuff (via Blueprintinterface) where only the strongest Slow actually slows me down. In this Setup I made it so the Duration and Strenght of the Slow gets stored in two seperate Arrays and everytime a Slow gets applyed, it subbtracts the ellapsed time from the Timer from all Durations and restart the Timer witch the smallest remaining duration.

When the Timer is done it looks for the Index of the smallest duration and removes both the debuff itself and the duration with the same index, makes the same subtraction mentioned above and if one of the duration has a time left of below 0.1 sec it gets removed as well (because of the Timer not being that precise).

It seems to work but i wanted to know if theres a more elegant way to the sollution.

The Movementspeed gets calculated Everytime the Timer gets set

1 Like

Since this is working, the real question here is - are you planning on having more buffs / debuffs affecting the player? And, most importantly, do you want to pull off that spaghetti again?

edit: I meant no offence, this is actually pretty neat for what it does.

Well im planning on adding more Debuffs and wanted to know if there is a easier/more efficient way of doing this.

When this way of handling (De)buffs is good i have no problem pulling of that Spaghetti (maybe by making it a Macro) again.

Edit: I don’t like having many floats what is the main point of me asking.

Well im planning on adding more
Debuffs and wanted to know if there is
a easier/more efficient way of doing

There is. Consider the following and see if it’s applicable to how you need your systems to work.

Actor Component - can be created in the Content Browser, it’s a piece of reusable functionality that can be added / removed from actors, during run-time too - that’s what we’re doing here. The general idea is:

  • design an actor component that acts as a buff / debuff for each effect that you need (inheritance works here, too, btw)
  • each component encapsulates the necessary functionality
  • when the player interacts with the world, a component is spawned and added to the player character
  • while active, the component affects the player
  • when the component’s effect has expired, it destroys itself automatically

Here’s an example, it’s a bit simplified and there’s plenty of room for improvement.

The component itself:

It has 2 exposed variables, Duration - how long the effect lasts and Magnitude - how strong the effect is. When spawned (on the player), it looks at its owner and directly modifies Player’s walk speed by Magnitude. It then starts an internal timer, waits for Duration, restores the speed and destroys itself.

This is, obviously, imperfect and just demonstrates the idea. Ideally, you’d have an interface in the base class here that tells the player to accumulate the Magnitude. And the player would interpret that. The Actor Component should just increase / decrease a SlowDownEffect float variable.

Here is how the player acts on it:

And I’ve placed a trap in the world:

The trap is an actor that spawns the effect on the player when they walk into it. The component can be given to the player in any other way you need, of course.

The first traps slow down by 300 for 5s, so hitting 2 in a row, stops you in place:

Image from Gyazo

Do note that this method does not limit you to granting the effect to the player only. The component can be given to any entity in the world that shares the interface. It does not use arrays or indexing (although nothing stops you from keeping the spawned actor components in an array). You can also make the components responsible for creating the appropriate widget visualising the effect since it’s the component that runs the timer.

This method is very modular, infinitely scalable, easy to maintain but requires a bit extra upfront work. It also allows you to dramatically declutter player character by keeping the stuff it does not need to really worry about in the components.