The following is part of an ongoing series of basic tutorials for gameplay scripters.
Event driven systems vs polling
Simply this is the difference between code that checks or ‘polls’ every frame to see if a condition has been met, and code that is called only once, when a condition triggers a function to be executed.
Let’s look at an example of a damage system.
We run a check, every single frame to see if any bullet’s position overlaps with the player, and if it does we subtract some health.
The function used to subtract health is only ever called when the bullet has hit the player. When the bullet hits them, a check is run to see if the target has health (so for example, is not a wall) and if it does, we call the relevant damage function.
Where possible event driven systems are far better because they reduce function calls drastically, and are far neater. If you find your script has to be called every frame, consider instead how you can change your code to be triggered on an event.
One thing to remember is that even things that seem like they should be checked every frame can often be event driven.
Take the example of a trigger box. You would think as it needs to check for the player consistently, it should be polling the world for them constantly. However, if you think about it, triggers only really need to query for collision on everything that’s moved significantly. If the player is still, it may be that it is unnecessary to check them. A player only trigger can therefore be tied to the players