Re: Decision Graphs (or whatever they're called)

On Fri, Jun 11, 2010 at 2:44 PM, Tom Plunket <[email protected]> wrote:
> It sounds a lot like state machines to me.  This is basically how it's
> done at my employer; designers have tools to construct logic and the
> leaves are "doer" nodes which are bound to code. (Specifically, it's
> like an enum and the tool gives a droplist of all of the
> possibilities.)

I hadn't actually thought of it as a state machine. At least not in
the usual "state X + event A = transition to state Y and side-effect
Z", as I'm not actually storing any state. It's more about authoring a
single complex function without getting bogged down in the complexity
of it. The way it all works, you could easily bake it into a flat
table of updates keyed by all possible permutations of the input
values, though a DAG is *vastly* more compact and maintainable (at
least in my case).

On reflection, I guess you could think of it as an odd sort of
degenerate state machine. I guess I should read up on how people
typically deal with big state machines and see how much of it
applies...

> Writing a robust tool requires not allowing invalid data (e.g. each
> branch must eventually lead to an action node, even if that action is
> "do nothing," but the experience seems to be that a visual tool for
> the designers and the requirement that logic stay compartmentalized
> means this is possibly the single most robust system+data in the
> engine.

Yeah. I've been thinking about this sort of thing a lot. The main
point where I'm trying to come up with something elegant is building a
good way to "inherit" logic and reuse it. What I've been doing so far
is loading up the "parent" graph and authoring the "inherited" graph
as, basically, a diff on top of that. Keeping those coherent when the
base changes is tricky, but it's been a powerful enough technique that
I think it's worthwhile spending some time to make it work well.

> I'm a huge fan of "scripting" languages personally, but the lack of
> one hasn't made any task impossible. "Visual scripting" is sometimes
> more tedious ("if only I could increment a counter!"), but it has been
> demostrably more robust.

It's also easier to write tools to validate or transform the damn
things since you can make stronger assumptions about their structures
than you can an arbitrary AST. Mind you, I've not really explored that
(haven't had to, yet) but I think it's definitely worth thinking
about...

On Sat, Jun 12, 2010 at 4:01 AM, Javier Arevalo <[email protected]> wrote:
> Drop by http://aigamedev.com/ and you'll find tons of information on
> decision and behaviour trees, very relevant to what you're doing.

Thanks! That's a lot to chew through, but so far very interesting.
Hopefully I find some time to *really* dive into it soon.

Cheers!
Phill
_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com