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

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.)

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.

(The "compartmentalized" requirement comes from logic only being
attachable to objects; afaik there is no global controlling script. It
just so happens that everything that happens depends on local
conditions. Presumably one could create a global script but it would
quickly get unweildy. Therefore it's more prudent just to stick logic
on what it controls instead of trying to drive a bunch of "external"
objects somehow.)

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.

Sorry for the tangent. Phil brings up a definite issue and it can be
tricky to code all gameplay explicitly. Every game I've worked on has
solved it differently (even one in interpreted C, scripting languages
should not have malloc), but going toward a state machine seems to be
the easiest way for me to manage it. Then, anything shared between
states is done so explicitly; there are no accidental function calls
shared, as in Phil's example.

-tom!

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