Hi! smd...@student.cs.york.ac.uk wrote: > Hello CEL users, fans and developers. > My name is Sam Devlin and I am one of the GSoC students this year. Some of > you may remember me from the post-application discussion on this list of > potential AI projects. I have specifically been chosen to work on the > Quest refactor and behaviour tree implementation discussed in this thread. > For a more detailed introduction to myself and the project please see my > blog at http://www.crystalspace3d.org/blog/samd > > Before work can begin I need to collate everyones ideas as to what should > be incorporated within the refactor. Below is a list of currently planned > changes: > > > -Remove triggers and rewards from the Quest system and make them standard > property classes available throughout CEL. > > -Standardise the Quest, Trigger and Reward properties so that they can > access constraints, property values and message each other. >
Can you explain this point in more detail? > -Allow for nesting FSMs > > -Filters for Quest message trigger by sender and parameters. > > -Add ability to subscribe to changes in pc properties (Currently only can > only be done for celPcProperties This last point is not directly related to quests, is it? Generally looking very good to me, some additional ideas: - Factor out the sequence system: Similar problem to having sensors and rewards inside quest and not being accessible generally. Note sequences are connected to two different rewards (startsequence and endsequence), but this could be for example factored into one pc with two actions. Also, one trigger is involved to find out when the sequence ended, this leads to the next idea: - Somehow standarize start-finish protocol. Note i'm not very sure how this can be approached, but many actions take some time to end, for quests this usually involves some state waiting for an action to end, and for behaviour trees its just the basic building block (actions taking some time together with serial or parallel containers). In cel we have some cases like sequences ending or starting, or the steering pc's which report finishing when arriving to some destination (or can fail). So, this is currently done in many ways, in the case of sequences its done with explicit callbacks, steering works with an action-message pair to handle start and end, and probably we have some example of message-message too. Also, i'd like to note i'm actually working on cel logic support for crystal architect, and all the basic framework is there to start playing around with editors for logic (cs, gtk, cairo, a node editor library...). It will be easy to implement any given editing component, so feel free to ask anything specific or propose any kind of fancy interface for quests or behaviour trees (all ideas are welcome). (this was a test logic editor done in 3 days in the prototyping phase: http://wiki.kyanite-studios.org/lib/exe/fetch.php?cache=&media=ca:par-ser8.png. a behaviour tree mixed up with some operators-). Pablo ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Cel-main mailing list Cel-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cel-main
