smd...@student.cs.york.ac.uk wrote: > Hello Again, > I would like to start by apologising for the delay in my response to this > thread, but as previously stated I had a holiday booked which > unfortunately coincided with the GSoC application time frame. I will > attempt now to cover all the issues raised in my absence, and thank you > for your patience in what could be a very long post. > > -- > > Firstly to Pablo, > It is my interpretation that you are suggesting the use of the previously > mentioned paper as inspiration to standardise the method of communication > between FSMs as opposed to the current non-standard Quest methods. > However, the fixing of the current Quest system to apply to these > standards to then be replaced by behaviour trees seems redundant. Would it > not be more beneficial for the project to move on from the complicated FSM > of Quest, to a new implementation of behaviour trees that abides by the > standards for property classes? Or would you, and anyone else reading, > prefer to have a fully functioning, traditional FSM implementation that > meets these standards? >
Well, note the ideas i proposed where basically everything i could think of, doesn't mean i thought how everything would fit, but i do think that behaviour trees and fsm can be orthogonal, not that behaviour trees would replace fsm... although maybe they're just different ways of viewing the same concepts. Other than that, since we already have a form of fsm, it can be beneficial to work in other approaches, but then again, a few things in the fsm are annoying if you start working on other things, since you will be missing some basic pieces of functionality which are now integrated into the quest implementation (like the triggers, interpolation system, the rewards..). Pablo ------------------------------------------------------------------------------ _______________________________________________ Cel-main mailing list Cel-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cel-main
