Re: [Algorithms] Ideas for an AI scheme

[Ryan J. <rya...@gm...>]

>
>  To be honest, I hadn't got much further than the design I originally
> suggested (well, I have a few more diagrams this end). By "composite
> behaviour" I guess I effectively meant branch nodes in a behaviour tree. I'd
> realised there were going to be some concurrency issues involved when I got
> round to building the behaviour trees, but I hadn't really come across the
> idea of a concurrent HFSM. I think it possibly sounds a little over my head
> at this point :), but it does seem an interesting approach. Are you thinking
> that a standard HFSM won't be ideal for what I'm trying to do though? I'm
> trying to come up with something I can do in the time really (I'm writing up
> a PhD thesis at the same time and trying to get the game up and running so I
> can use it as a demo for job interviews among other things, although I
> ideally also want it to be quite flexible).
>
> I simple HFSM should be fine. Lots of games have used that approach. It
might have some more code duplication between behaviours, but has the
benefit of being very explicit. Don't overcomplicate things until you find a
need for it.




> Automatically-generated transitions sound interesting - any useful links by
> any chance? (I tried Googling for "fsm automatic transition generation goal
> action" but got a load of stuff on automatic code generation instead
> unfortunately...)
>

What I was refering to was somthing like a mix between a HFSM and the GOAP (
http://web.media.mit.edu/~jorkin/goap.html) stuff from F.E.A.R. It can
maintain the explicit higher level transitions and let the system
automatically figure the rest out. Regardless, a non-concurrent HFSM should
be fine for what you are doing.

 - Ryan