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

> the trick is finding a sane line

between "here's structured switch-case" and "here's Lua".


I would really recommend looking at SimBionic for that. It has a nice, GUI
editor, and a sane integration strategy to integrate into your game. When we
evaluated it, we were looking for a higher-level behavior library (path
planning, etc), so we didn't end up selecting it, but I think it would be a
shoo-in for the kind of scenarios you describe.

And once the designers have a GUI tool to draw their logic in, that can
become both design document and implementation. In the end, it generate data
files, which contains of tables describing DAGs, so it's probably quite
similar to what you're doing :-)

Sincerely,

jw

--
Americans might object: there is no way we would sacrifice our living
standards for the benefit of people in the rest of the world. Nevertheless,
whether we get there willingly or not, we shall soon have lower consumption
rates, because our present rates are unsustainable.



On Tue, Jun 15, 2010 at 4:42 PM, Phill Djonov <[email protected]> wrote:

> On Tue, Jun 15, 2010 at 12:27 PM, Jon Watte <[email protected]> wrote:
> > Do you have a feeling for the overall production cost of the system?
> Perhaps
> > you spent less time on your implementation and maintenance than the cost
> of
> > buying it for your current project? Do you have a GUI editor that the
> > designers can use? Or perhaps the opportunity cost of the implementation
> > actually was higher than the cost of the middleware?
>
> Oh, my current implementation is an outright joke (thus my shock it
> worked well enough to ship). The logic I've been dealing with is, in
> essence, a giant mass of "on event E: if X0, Y0, Z0 do A0, if X0, Y0,
> Z1...Z5 do A1...". You could write it as a table, but given the amount
> of duplication it's *much* more compact as a DAG. The main thing was
> that the damn thing kept changing, and there were piles of "in level 4
> I want the same logic, except subsection S should be different
> thusly", which scared me since I've seen game code that does the same
> thing in other titles turn into a hideous unmaintainable mess as the
> design is iterated.
>
> In code, the whole thing consists of a few thousand lines of Lua table
> definitions and a function that traverses the graph they form based on
> a list of keys (so handling events consists of building that list of
> keys, pulling a leaf from the graph, and acting on the leaf data).
> I've just been maintaining it by hand. Given how little of it there is
> in this project, that was probably a fairly cost-effective way to do
> it. Still, it's worth looking at more of this stuff for the future, so
> thanks, I probably wouldn't have thought of AI middleware or the like
> to deal with what I've been imagining as glorified-but-dumb
> multi-level switch-case statements.
>
> Hrm. I guess, given that the ultimate goal would be a tool/language
> that the designers can use directly - almost in place of, or as a
> figure in, a design document - the trick is finding a sane line
> between "here's structured switch-case" and "here's Lua".
>
> Phill
> _______________________________________________
> Sweng-Gamedev mailing list
> [email protected]
> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
>

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