- Concurrency: tasks (blue stuff) can be run at parallel and a certain point of a task (percentage of completion, distance to end of path, etc) can trigger another parallel task.
- Variables: the usual flow diagrams break down when you have too many things to connect, solution? Use local variables!
- Ordered: the connections have order. This was important lesson learned from countless hours of debugging Crysis flowgraphs.
The arrows at the top of the tasks are execution points. When triggered, the task starting at that location will start executing.
There was also a syntax to define how the next tasks would have been triggered. In the above examples the next task is always triggered when the previous on is finished. I had an idea to also have some kind of notation to require all tasks to be finished before the next one was carried on.
The orange boxes are variables. Grey boxes are functions. Some functions take variables as input (could be stacked ala werkkzeug).
I think that "patrol point is not valid" should have a trigger line coming to it from the same bundle where the patrol point selection and restart is triggered (that eval would be 2 and restart would be 3). The grey text in the patrol box should actually read "Patrol(StartPoint)".
The overall design was much inspired by werkkzeug and PD.
I saw a talk by Dirk (from Werkzeug) at GDC and loved the idea of his blocks. I really like what you've done with them here!
ReplyDeleteThis approach seems to encapsulate many patterns that you need to model behavior blocks (such as assumptions, termination conditions) without trying to handle them all uniformly as nodes in one big sterile behavior tree.
I really like the idea of the stacking, it makes super easy to connect things. Here it is used in two ways, firstly to make those evaluation chains, which run vertically, and also those task combinations which run vertically.
ReplyDeleteThis UI test is from the same era: http://vimeo.com/10461028