I have a game where the player is operating a vehicle. Whenever the vehicle is moving, it’s ‘energy’ slowly goes down. When the vehicle stops, the ‘energy’ begins to recharge. I am currently doing this with Event Ticks. On it’s own, I assume this is a good way to do this. However, the vehicle also has different ‘systems’ such as ‘sensors’, ‘weapons’, etc. that all drain the energy as well. So, if the vehicle is moving, has sensors on, and is using it’s weapons, the energy will drop at the most rapid pace.
My issue is that when I have all these systems effecting the energy using Event Ticks, my framerate is dropping significantly. Is there a more efficient or better way to achieve this same functionality? Any help would be greatly appreciated. Thank you!
Using tick isnt the nost efficient way of making it but it shouldnt xrop down performance by more than 0.0001% unless u made something bad so that the “code” gets executed houndrets of thousands times every tick. So the problem is in graphic(prob particle emmiters) or u f*ed smthing in bp. If you colud send screanshots of bp. To check if the tick is the problem here just plug out execution out of tick and do same thing which makes your fps drop down.
You can:
Reorganise all weapons, sensors, etc., blueprint if whey are long chains at the moment. For example: if you have some energy bar (aka fuel) you dont need to execute all that blueprint nodes chain which set energy value, read/set some bools, cast something to widgets, etc. So, if you energy bar are using some float+float mechanics (for automaticly restoring power) dont execute all that blueprint chain if energy allready 100% cause you really dont need to set “Enegry at 100 percent” every tick if player event doesnt move.
If player not in the car - dont execute **Event Tick **at all. If energy of, for example, weapon are full - dont execute **Event Tick **until player dont press MLB for shooting.
Also:
You can use **Retriggerable delay **as infinite loop which will “tick” each 5,20,50,n milliseconds whatewer you needed, which will cost less than Event tick. Retrig. Delay chains are also can be easilly closed, so whey will not executed at all until whey triggered again.
One problem with **Retriggerable delay **chains - thay are pretty messy to work with when you retrig it again by themselves
It would be helpful to see how your blueprint is set up at the moment. It seems strange that the event tick would effect your framerate so much.
Just to clarify, are you adding your widgets to viewport at Begin Play or Every Tick? I made a silly mistake with this before, and this small error can cause huge framerate drops.
Dependant on how your nodes are rigged at the moment, definitely look at implementing the points which Alexander.L made.
If you are doing multiple actions i.e. moving & shooting, dont run both set of nodes.
If you can upload a blueprint screen shot, I can take a look and see if it can be improved at all.
That’s an interesting topic going on, as I currently are struggling with similar problems. My approach might be a possible solution to your issue as well, although I have run into some issues, that might need to be discussed…:
Within my project (see signature) I have many AI driven cars, so I wanted to optimize the performance of the code.
The vehicles drive along preset splines and depending to their relative position to the spline forces and torques are used to keep the vehicles on track. I thought that probably all these checks don’t have to be done on each tick so I have the “AI Driving code” in a separate function. Now, onBeginPlay I have a timer set with this AIDrivingFunction, which loops every e.g. 0.1 s. So, every 100 ms the code will be executed, checking the vehicle’s location, calculating forces and torque and eventually applying everything.
I thought that is a smart idea to optimize the code, plus in that way it is tuneable, i.e., I can play with the timer-frequency in order to have the function being executed more or less frequently.
However, something does not seem to work properly… May it be the case that the time that I set in the timer is not super reliable? I did not have the time to track if the timer is actually fired precisely every 100 ms. I guess not, which would make kind of sense, taking into account frame times of 20 - 30 ms. I probably have to measure the actual time delays and take it into account when calculating the required forces/torques (more force at higher time intervals and vice versa)…
Have a Timer that controls the delay, that way you can pause this Timer and also restart it at the times that it should be doing so. Set Timer Event/Function Name and have it do the timing for you. That is how I do the regenerative health and mana situations on my characters, they set up timers on their Begin Play that begin to work as soon as there is a change in the HP or Mana, the timer is then stopped or paused when they take damage or the statistic is full or attack or such.
I believe it to be a more effective solution than using Ticks, which I have also done in the past. Tick won’t tax your system that much, however my Tick and your Tick are two different things. Time is time.
I’ve been using a timeline for my recharges. It only plays when needed (if the variable is less than max and you are stopped). Do timelines bog things down too much?.
I do not recommend using event tick unless it is absolutely essential for the function. Tick fires every frame, and it sounds like you have multiple functions running off ticks to update something that the user will never need to be that precise in timing. Multiple functions using tick events can VERY quickly add up and reduce performance.
My recommendation would be to use delay loops with gates or bools to update your “charge” status. For example, you could use a delay to check every .5 second and update the charge status, this would fire every half second, rather than 30-60 times a second, and the user is unlikely to need to have the charge status updated more often than that.
