[quote:18ip3f14]what i'd suggest is something better - way better - behviours and plugins should have event listeners for ticking. once tick happens - each object / each behaviour updates globally, therefore no for loops at all.
this. kinda
Polling every single condition every single tick is always going to be much slower than an event-driven architecture.
Here's a small example:
CONDITION: Compare two Values-> [PlayerSprite.x] Bigger Than [500]
ACTION: ..
By polling, you check every tick if PlayerSprite.x>500. An Event-Driven way to do this would be like that:
Assume BehaviorsTriggeredArray which is always empty at the beginning of every tick.
The game runs and the player moves to the right. Somewhere deep in the engine there's a MoveSprite() function. When MoveSprite is called, it will trigger a MoveSprite event to which all Conditions that depend on Sprite Positions listen to. This is when the condition will check the PlayerSprite.x>500 expression, and if true, it will add a [Behavior#15Triggered] Object to the BehaviorsTriggeredArray.
When the engine needs to update, it goes through the BehaviorsTriggeredArray objects one by one, and acts accordingly.
If our game only had that one condition above, then with the polling method, the engine checks, 'is player X bigger than 500?' every, single time.. Even if the player never moved.. That's a huge overhead that can be avoided. In the event-driven scenario, the engine does absolutely nothing.. Then, when the player starts to move, it will check if it's X is bigger than 500. Which makes much more sense.
My two cents