Timeline for Behaviour Trees with irregular updates
Current License: CC BY-SA 3.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 6, 2013 at 14:34 | history | edited | Engineer | CC BY-SA 3.0 |
added 21 characters in body
|
| Nov 6, 2013 at 14:32 | comment | added | Engineer | Yes, pretty much. This is required in order to run everything in phases during the loop: if the action-applying phase takes place first (for all entities -- as it should be) then AI processing phase takes place second (for all entities), you need to store those interrim results so that second phase can access them. Storing each result on the entity it applies to is the most logical approach, yes. | |
| Nov 6, 2013 at 14:24 | comment | added | Robominister | If my tree selects the 'eat the sandwich' action, once the sandwich is eaten that action should return 'success' I've seen BT implementations where the leaf node calls BehaviourEatSandwhich.update() and directly gets its return value (ie every frame). If the behaviour is on a queue, then presumably I need to store its return state on the entity (in its blackboard memory?), so on the next tree tick, that node can look up the last return state of that behaviour | |
| Nov 6, 2013 at 14:19 | history | edited | Engineer | CC BY-SA 3.0 |
added 160 characters in body
|
| Nov 6, 2013 at 14:13 | history | edited | Engineer | CC BY-SA 3.0 |
added 160 characters in body
|
| Nov 6, 2013 at 14:10 | comment | added | Robominister | Yes, that's it. | |
| Nov 6, 2013 at 14:08 | comment | added | Engineer | OK, so it will check every frame to see if it has zero frames remaining before it must act, then once it hits zero, it acts, and resets its wait counter? That would be the right approach, yes. | |
| Nov 6, 2013 at 14:07 | history | edited | Engineer | CC BY-SA 3.0 |
added 160 characters in body
|
| Nov 6, 2013 at 14:06 | comment | added | Robominister | Ah ok! Timeout was a very bad choice of words. No, this would be within the main game loop (a given tree could specify how many frames to wait before updating, eg every 10 frames for a complex tree). | |
| Nov 6, 2013 at 14:01 | history | edited | Engineer | CC BY-SA 3.0 |
added 160 characters in body
|
| Nov 6, 2013 at 13:58 | comment | added | Engineer | If your gameloop is in fact running off one of those mechanisms, OTOH, you may be fine, but that may depends then very much on the order in which the event handlers are called by your 'setTimeOut' (or whatever the name may be). This is why Unity, for instance, has script execution ordering -- to ensure that the various elements of your game logic are running in the correct order, on every single game loop tick. | |
| Nov 6, 2013 at 13:55 | comment | added | Engineer | "I'm interested in behaviour trees that aren't iterated every game tick (but on a set time out, eg every 100ms)." <-- at some level, this is using a loop function of its own. Languages like JS, Java, C# implement these kinds of timer as polling mechanisms (loops) under the hood. The problem is that these loops are discrete from your own game loop, so you will have synchronisation problems if you use them for anything other than rendering logic. When it comes to physics, AI, etc. all timing must be integrated with your own game loop. Let me know if this still isn't clear. | |
| Nov 6, 2013 at 13:51 | comment | added | Robominister | Regarding checking vs not checking, you've slightly lost me, as I'm not clear on what you think I don't want to check (or where the idea of events has come into this). It's entirely possible I phrased my question inadequately. The imAs a behaviour tree | |
| Nov 6, 2013 at 13:44 | history | edited | Engineer | CC BY-SA 3.0 |
added 379 characters in body
|
| Nov 6, 2013 at 13:39 | history | answered | Engineer | CC BY-SA 3.0 |