For example, I need some variables to be calculated from moment to moment to achieve the effect of resetting a CD, such as the crosshair in this FPS game, the crosshair will expand when the character moves, while the crosshair will shrink when the character does not move, until it returns to the default value. So I set a variable that’s always decreasing to drive the crosshair to shrink, but I put a clamp on it so it doesn’t shrink indefinitely, it goes back to the default value that I want.
At present, I use event tick to execute this descending function, but I find that after using a fixed frame rate and changing the frame rate, the speed of crosstalk recovery changes, so the animation effect I want also changes. Therefore, I am thinking whether this function should be executed with timer?
And the phantom event tick is bound to the rendered frame rate? It doesn’t have any probability like logic frames in it?
I acknowledge that my understanding may be limited, as I am still in the early stages of learning. There are numerous aspects of this field that I have yet to fully grasp. I would therefore greatly appreciate any guidance and advice you could provide.
Yes, you should use a timer for this! Especially since it’s something that starts and stops often, you can tie it to an event and be done instead of bogging down tick.
But yeah, your research is correct that tick will be based on framerate, which is fine for face-value things that the player will have such as “Looking at an object” and such things. Using a timer disconnects it from that.
Though, looking at what you have here with the crosshair I would recommend a timeline and a LERP for your variables, a timer is “Execute after this many seconds” a timeline is “Continuously update until finish”. Hope that helps!
I respectfully disagree with @Mind-Brain on this matter. This doesn’t mean that they are wrong and I am right but hear me out.
It matters little weather a piece of code is executed on a timer or in the tick if it is executed equally often. In your case you are dealing with an UI element which is executed only on the client and you need it updated each frame to have a smooth animation.
In order to avoid the frame-rate dependency you just shrink your crosshair by “shrink rate” multiplied by Delta Seconds from your tick.
Now if we are talking about the actual game mechanic of shot spread you don’t really need any of the intermediate values between the shots. You just need to know the shot spread when fired: spread = max(minSpread, lastShotSpread - timeSinceLastShot * spreadReductionRate). Of course this gets more complex the more dependencies you add.
In short, if I were you, I would make my crosshair size update in the Tick of the UI element (only in the client), and calculate my bullet spread only when I fire (probably only on the server).
This is why I said to use a Timeline instead of either of these, and run a LERP using that (I didn’t say on the update pin though, I should have specified).
Though, after looking at your math here… I disagree with myself. I like this better, it’s elegant and easily wrapped up into a pure function, keeping an actor from needing a Timeline Component added to it.
Sorry. Sometimes I misread “Timer” and “Timeline”… They have so many different things named similarly
You are really onto something, good sir. Timeline will probably work best if you have some complex, non-linear change of the spread - sampling the timeline at different points based on time since the last shot.
Thanks @Mind-Brain, I have a general understanding of it, but I’m curious if the project uses a fixed frame rate and sets the frame rate to 60 frames versus timer, but the time is connected to 1/60, is the performance cost the same for both?
It feels that the use of event tick for time-related parameters will become less rigorous, because the number of frames refreshed per second will execute the event tick many times, and even if the fixed frame rate is used, the player’s computer may not be able to run the fixed frame rate, so the effect will be different
In addition, I found that fighting games usually use the probability of frames to describe the duration of animation, and Street Fighter 6 is 60 frames, but the refresh rate of Street Fighter 6 is another unit, or the Battlefield server is also marked with 60HZ, but obviously my PC rendering of the game screen can be other frame rates, such as higher than 60 frames. So this event tick in Unreal is like binding the execution frame to the rendered frame?
As a novice in Unreal Engine, my understanding of many concepts stems from my prior gaming experience. While this perspective may lack rigor, the exploration process has been both intriguing and enjoyable.
And players will also use frames to discuss moves and animations, perhaps with time to express there will be a lot of decimals, using frames is convenient, or perhaps it is related to the production of the game?
It would cost a very very very very very VERY small amount more to run the Timer, I believe, I haven’t tested it, and that’s based on the idea that you’re doing 1 divided by 60 each time, fixable by replacing it with .16.
Yes, fighting games do, which is why they didn’t release on PC for so long(due to the variable equipment it’s working with). They are tied to framerate, so if the framerate goes down, the game physically slows down- not something you want in an action game or RPG. Basically this comes down to the production design for the game itself- Monster Hunter, Capcom’s OTHER big one, follows the opposite path of frame independence and fluidity, probably because of the PVE nature instead of Street Fighter’s focus on PVP and exactness.
Kind of, yes. It attempts to run tick every frame. It’s for trying to simulate an “All the time”, or “Constant” thing, which can become costly if the thing can run fewer times for the same effect.
Hope that helps!
