Reply To: [Feedback] Our AppleArcade Game

[Driiade]

Hey !

1. it will not work as explicated in my other thread. There are situations where the callback is not yet added, and you will miss the message. I strongly suggest a pool of incoming message, and check in this pool if the message was sent between 2 graph update. Care you can’t throw the pool after Graph update, because intern message will be directly throw and so not available for next update.
You need 2 buffer, 1 buffer for last sent messages, 1 for current available messages, each time you send a message, you add them to the last sent message. Before updating a graph, you need to swap buffer from last sent message to current available messages. It’s a bit a mess, but it ‘s  what we found to be order independant.

And if you want all graph to be order independant, you need to do the swap right before ALL graph update (so MonoManager can do that.. I suppose ^^).

3. Dirty blackboard in scene don’t have newly added variables. Causing a lot of problem. Same things if you delete variables, reorganize or whatever. There are all strange and non intuitive behaviour (some times, all variable values are shift from variables). What I personaly expect: each blackboard variables have an ID (like a script have), reorganizing the blackboard doesn’t dirty those variables, adding a value doesn’t dirty other variables, deleting is the same… What we had to do to support level designer to override/modify value, is to have a script which can override a blackboard value on Awake. Dirtying the script doesn’t matter for Unity.

4. Yes I used it with the pooling system (best of 2 worlds). And hacked NestedFSM to get from pool. But to be sure NestedFSM / SubBT are working with pooling, I hacked all of them to retrieve Graph from the pool.

5. Yes there is that option. And in fact we would have to create our own FSMOwner. But Graph still had reference to runtime, when it really don’t have to (I cut all dependency between Graph and Runtime).

8. Yes this is a touchy point. To secure execution order, what I believe is the best is to have this sort of architecture :

-All entering Action during this update are executed
-All updating Action during this update are executed

– All exiting Action during this update are executed

A bit like Unity does with Awake/Start/Update during a frame.

Instead of :
-For every graph update -> execute OnEnter/OnUpdate/OnExit

Maybe this point is difficult to have because BT are not the same as FSM and so we can’t do this.

10. Some of us want to have this on a server without Unity. But yes throw this point, it’s not really a blocking point.

12. Yes for the first point. For BT, we can have parallel sub graph And parallel ActionTask, like FSM. In fact, all graph have to be defined with some parallel Node, and parallel Graph running with them. It’s a good principle when working with this sub graph pattern.

I added other points in the first message(^^)