Has anyone had any experience using a flow graph based AI specification? Like so:

http://seithcg.com/wordpress/?page_id=1605

How does it compare with Behavior Trees? Any non-obvious (or obvious) pros or cons? Or just apples and oranges?

From the looks of the samples i have seen it sort of looks like a behavior tree (ish) style of specification, but with parameter fields (such as target, speed, etc.) coming from source nodes and other activation semantics, also the samples i have seen are missing things like fallbacks and concurrency that I get with my BT implementation, but it doesn't seem like a big jump to add these.

It may be how i have been writing my example BTs or the nodes I have implemented (probably is), but users attempting to create new trees are having a hard time expressing what they want, without my help.

I also have a visual tree editor similar to Braniac Designer, and have your usual nodes: Leaves: Condition, Wait, Action,TreeCall; Branches: Selector, Sequence, Parallel, ActiveSelector, SwitchSelector, WeightedRandomSelector; Decorators: Always, Negate, Loop, Monitor, ConditionDec, Limit, Periodic, Toggle, etc

Maybe the problem is too many node types, not enough higher level node types, Actions that are to granular or not granular enough?

I often puzzle at how to express a particular behavior in the system, keep thinking to myself "oh if only I had this imperative like ability from Lua", but I manage. But I am a developer (who wrote the system), and the users are maybe very junior developers or not developers at all.

I am also starting to really appreciate the benefits I am getting from my BT implementation like simulated concurrency, latent functions, subgraph aborts, etc. that would be REALLY hard via imperative scripting (i've been there done that).

What i have is working, but i am ending up building too many of the trees or aiding in creating them too often. Trying to reduce this.

I have also been looking into adding utility based selectors into the mix, but so far, it has been a bit of a can of worms, extremely useful!, but trying to formulate appropriate factors, considerations, and picking proper response curves is an art unto itself. Don't think i will ever get a user to comprehend building those (planned to hide utility methods in trees they can just call through the TreeCall leaf, in things like the perception system, or in custom actions like findBestEnemyTarget).

I wonder if a flow graph representation might be more intuitive? I often have to keep reminding my users priority order priority order...
They keep missing or miss understanding how the BT activation flow works.

Maybe a mix of flow graphs and strict BTs (like Crysis)?

I'm asking for the impossible, i know. User level intuitiveness, yet powerful expression, but just trying to inch over.

Any thoughts?

BTW, my previous system was visual HFSM based, and in that the users were TRULY were lost, BTs are going over relatively better.

P.S. maybe i should be looking into some automatic BT (partial) construction through combinations of higher level rules (e.g. ogres hate grues, ogre like spiders, when raining get nervous, not these rules per say, but the concept), or partial planning?

What i mean by flowgraph AI, is the declaritive flow of action activation with minimal or no imperative like side effects. Kind of what a BT does, a flexable rule set (plan) to determine what actions get activated when.

From my experience, one's users (game designers) are more comfortable with flowgraphs, rather than fully-fledged BTs that offer the full spectrum of what can be done with such a system. Most of the time, our designers were using sequence-like nodes in their flowgraphs, and also parallels, though they were not called "parallels", but were rather wrapped by a "synchronization". Also, nodes couldn't fail - just execute and then finish, which simplified their way of thinking. To be able to do branching, a named flag could be set by one node, and be queried by another condition-like node, which had 2 outputs (condition being true or false) that linked to the further nodes. So, things were simplified for the sake of usability by having every node implicitly act as a sequence as well as a parallel without a BT-like fallback mechanism.

So, the flowgraphs were like a Windows OS (get simple things done quickly on a higher level), whereas the BT was more like a Unix-like OS (combine small low-level tools to build really powerful things).

--

Shadax

So would you recommend maybe hiding a BT system beneath the visual guise of a flowgraph for the game designers to use, but still letting an experienced designer to build trees directly? Does that even make sense?

I have no experience in wrapping a BT by a higher-level GUI (had to build my BTs in XML by hand, and the flowgraph thingy was based on a totally different technology that existed already), but it sounds like something that has been done by other gaming companies - Alex had often mentioned the possibility to expose certain nodes to the game-designer differently than what's going on under the hood.