So to be clear, Im new to UE4 (been using it for just over a week)
I’ve put together this blueprint, It is a WIP, im learning as i build so most of it is liable to change. The issue I have is im wary of having this many actions on the “EventTick” Im no programmer but that means that the game will be checking all of these things multiple times every second right? I have no idea how many on ticks a blueprint can have before it is ‘too much’.
This is all within the character blueprint and the number of things that keep being added to the “EventTick” node keeps going up and up.
Is this okay? how much is it okay to have on an EventTick node?
For referance this is for a top down RPG style game and this is all on the player character blueprint. Happy to supply more images if needed.
First off, cause this is really going to bother me, can’t you just just do current health / max health to get the ratio? Is there any need for those extra / 100?
Second, I’m assuming your max energy is 100? Otherwise, shouldn’t your if (CurrentPlayerEnergy >= 100) be if (CurrentPlayerEnergy >= MaxPlayerEnergy)? And you don’t need the first branch either. Instead you can just change it so it’s if (CurrentPlayerEnergy < 100) and plug that directly into a SetCanRegen? And if you’re not using that variable for anything else, you can just plug it directly into the second branch.
Third, I personally wouldn’t put any of this into the tick function. I’d only call the SetCurrentHealthPercentage when you change your health. So you’d have a function called TakeDamage (and Heal) or something and do the set stuff in there. There’s no point in calculating and setting the variable every frame if it’s not changing. And what you’re doing to recover energy, I’d just make another event to do that. Something like IncreaseEnergy. So it would look something like:
And then just call it on BeginPlay. That way every 3 seconds it will check if the CurrentPlayerEnergy is less than 100, and if it is, it will increase it by 1. Btw, I’m not 100% certain that will work as I’m very sleep deprived and wrote the first thing I thought of, but I don’t see anything wrong with it right now.
And now to actually answer your question. That amount of stuff in your tick should be fine. It’s all really simple math, but again, I personally wouldn’t do it like that.
Edit: Oh yeah, and if you don’t know what the ++ next to CurrentPlayerEnergy++ is, it just means CurrentPlayerEnergy = CurrentPlayerEnergy + 1. It’s just a faster way of writing it. I believe there’s a blueprint node for it too, called Increment or something. If you drag off from the variable and just type ++ it should come up.
You generally want to avoid using the delay node in tick if you can, it’s a lazy way to get something to happen every 3 seconds. Consider using Timelines to work with timed events.
But no that code is nothing to worry about on tick, all of that is basic arithmetic, your basic math operations are the cheapest computations there are. But without reading it to the depth of the above poster, it does look like you aren’t simplifying your math equations.
Wow, thats some amazing feedback, thanks so much Ispheria.
Like i said im new to UE4 so even some of the most basic stuff still goes right over my head. I really appreciate you phrasing this so that i can actually understand.
oh and working out the ratio, yer, that was pretty dumb on my part.
Thanks HuntaKiller, really appreciate the help, I havent got round to using Timelines yet, will get to them today too and edit, edit, edit.
Wow, sorry to be rude, but all these “tipps” with delay nodes or timers are just plain wrong and before you guys plan to “educate” UE4 or scripting newcomers next time you should reconsider if your are truly qualified to answer those questions.
If you create a delay node, what really happens behind the scene is that your blueprint checks every frame whether your delay is still valid/running or not. So it does not really save you anything.
Timers don’t save you a lot of performance in your case because it’s more expensive to register a timer than doing your simple math operation every tick.
Some people might tell you something about reducing the tick rate of an actor (so it just ticks every second or fourth frame etc.). In many cases this does not increase your game’s performance because a performance spike is a performance spike, so your game will also stutter and run badly if you have big performance spikes every x frames.
So what can you really do?
Don’t worry. Your simple example is not that hard for the engine to handle every tick. You should take care of your instructions count in the tick function (unfortunately you can’t see the current instructions count in the editor). Keep in mind that For- and ForEachLoops might lead to a very high instructions count, so every time you want to use a Loop in your tick, try to come up with a solution that does not require a check every frame.
Try to make your game logic “as event based as possible”. Take a hitpoint check as an example. You could check the Players hitpoints every tick, but alternatively you could trigger the hitpoint check just when it’s really necessary, e.g. when the player has received a hit by an enemy or if he landed a jump or whatever.
If you do all of this and you still have a bad CPU performance, your last resort is to remake parts of the game logic, that is executed in the blueprint tick function, in C++.
Keep it up, don’t get discouraged and have fun working in Unreal.
Edit: Decided to show you how I would restructure your script example:
You could leave out the “SetPlayerEnergy to 0” if its below 0 entirely, if you would add a “ClampFloat” to the place where you reduce the CurrentPlayerEnergy.
Thanks everyone for the input, Im going to swap a few of these over to using timers rather than ticks purely for functionality sake. Also need to look into how to use the “ClampFloat” which swagentrotz mentioned.
Hey, just wanted to emphasize that generally you should avoid delay and timer nodes as often as you can.
Sort of an advanced tipp if you must have some sort of delay or wait time: Build your own timer by hand. This does not only have the advantage that it’s easier to debug, but it’s also more accurate because the “Delay” node creates something like a copy of your blueprint which gets executed one frame after the original blueprint got executed, so a “Delay” node can mess with your execution order which could lead to behavior that you don’t want. Also, a delay node with an input of 0 waits for exactly one frame.
In the future, when you are more experienced with UE4 and work on a serious project, I would recommend to only use delays and timers when there is absolutely no other way to achieve what you want.
I would definitely prefer just using a SetTimer node here. Makes the graph cleaner and more obvious what’s happening. Readability is more important than performance until you run into performance issues. And if you do, the way you set up a timer is rarely the reason that causes the issue.
That’s actually not what you suggested but I would still prefer a SetTimer node. Not only does one might possibly think he could use the macro for different timers but this does also unnecessarily stretch out the Blueprint tab. If someone finds a bug related to your timer, he does also need to check your macro and CollapsedGraph while with a SetTimer node he directly knows that it works like intended. Don’t implement your own algorithms instead of using existing ones that do the same thing and have proven to work correctly by many others. At least as long as you aren’t sure it’s necessary. And a beginner won’t mostly be able to decide if it’s necessary or not. And that’s what this whole thread is actually about.
What sentence do you mean? The first? Plain wrong? This would mean you prefer a complete game implemented in Assembler running at 500fps over the same game implemented in Blueprints running at 120fps. What if you find a bug? Good luck at debugging.
You don’t get it, but that’s fine I have no interest to beat a dead horse.
A timer makes your gameplay code asynchronous, which is complicated and hard to debug. So no, your arguments about readability and difficulty to debug are not correct, because it’s far worse to debug delays and timers than collapsed graphs or macros.
Also this thread is not about timers, readability or whatever, it was a question about performance in blueprints and a lot of amateurish know-it-alls tried to be smart by suggesting timers and delays, which isn’t only a bad tipp for a beginner but also bad practice in professional game development.
Haven’t ever run into such an issue but I think you’re right about timers regarding debugging. But that doesn’t make my statement that ‘readability is more important than performance until you run into performance issues’ wrong. It’s even a fundamental programming concept and you stated it would be wrong.
Just curious OP, why do you need to know what the health value and if regen is true/false is every tick? Wouldn’t you only want to calculate that when a change has happened?
This demonizing of timers seems a very non-object-oriented way of approaching things. You should trust yourself to write something that runs asynchronously especially in a situation like this. I’ve got some quite complex projects for broadcast systems which I work on and i always see it as a bit of a failure if I’ve got anything running off a tick. Looping timers and timelines are excellent ways to do this kind of thing, you just need to set everything up nicely when you begin play or instantiate something and use validation. Why not set up a 3 second looping timer which is solely responsible for the health - it could trigger events like death or warnings as required and you can forget about it.
Lioki - simple answer is i dont, Im still getting to grips with UE4. Yes i would like to have it tick when a change happens but im still working out how to do that the best way. For now OnTick seems to be the most efficient way of doing it (my time wise not computationally)
So, taken all of your advice on board, Really appreciate everything about the timers but i think until i have the basics down ill just stick with the simplest solutions. Please dont think im disregarding your advice, Its really appreciated and when i get more experianced ill look into it.
This is what the BP is looking like now, There is more on there but i think this is everything which is relevant to the topic at hand.
I fully intend to do something similar with the the “SetPlayerHealth%” and “SetPlayerEnergy%” but until my BP is getting more complex i’m just going to leave it as it is as a stand in.
Well with the tick event you are setting the health and energy every frame, I don’t think that’s required. I’m new to programming as well so don’t shoot me if I am wrong, but you should only need to call to the health/energy variable whenever a change has happened and the game needs to be aware of the change, like taking damage or using energy when holding down the sprint key for example. On event begin play is where you could setup the starting health/energy variable amounts, or in the construction script, and the engine will hold those values without needing to calculate them on tick. Then you can do the calculation you have on tick only when damage is taken or energy is consumed.
If someone with more knowledge than me wants to let me know if this is correct that would be great as I am learning also.
Lokki, It is just a stand in until i get round to actually building a proper interface. Im not up to that stage yet and have other things i want focus on first.
