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? -- To Scott, Thank you for taking the time to direct me to specific files. I have not yet looked into these since my initial review of the code, but I have set aside some time tomorrow morning to look into them in more detail, it is getting late now and I am very tired from the journey home so it would be unproductive to focus my attention there now at this time. However, I have a small initial query in reference to your post here and elsewhere in the mailing lists. You suggested to Henry Daniel that the GSoC is more geared toward implementing new features, rather than simply adding support for additional ready-to-use libraries.and as you and the others have identified there does already exist implementations of A*, steering, neural networks and FSMs. However, it seems from the conversations here that there are complaints with some of these features and so my query is would the projects suggested involving improving current implementations be less appropriate for a GSoC project than say a proposal to implement a brand new behaviour tree plugin? Specifically, I am currently thinking that the following current grouping of ideas could each constitute a full GSoC project. 1.) Pathfinding And Steering -Move the current A* implementation to a HPA* implementation to improve performance -Fully implementing the steering examples from Craig Reynolds work -Improving the interaction between steering and nav-meshes to provide usable performance 2.) Refactoring Quest -Standardise the quest system to fit the current standards for property classes. -Allow for nesting FSMs, direct linking of CEL properties to Quest properties -Freeing the triggers from within Quest so that access to them is available throughout CEL where they may find other uses in future expanisions (I.e Behaviour Trees.) -Explore the potential of inspiration from the UML techniques highlighted by Pablo 3.) AI Code Review A more general project inspired by Pablo's comments and the apparent lack of cohesion between and knowledge of AI systems within CEL. It has recently been raised by Piotr Obrzut that there is a need for a unified tool chain for AI, physics and animation but for this to be possible each subcomponent must be complete first. That does not appear to be the current state of affairs, and so as I see my commitment to AI within CEL as a long term project perhaps the use of GSoC time would be best spent collating the current systems implemented, adapting them to the standard property classes, ensuring there correct inter-system functionality through standard CEL mechanisms (messages, actions and properties) and then documenting the collation with interesting examples that could serve as tutorials to expand the communities knowledge of the tools available. Could you, please, let me know if these are inappropriate due to their focus on existing technologies within CEL and whether you think they are large enough or interesting enough to the community to be pursued as a GSoC project. If they are too focussed on existing technologies then my first choice proposal for a new plug-in would be to work on a behaviour tree implementation provided the community would desire such functionality. -- And finally, to Carlos, This thread currently is my development of ideas for a GSoC proposal. If I am accepted, I will ensure regular contact with the community to make sure the ideas developed are those desired and the tools made available are understood and well received. I'm glad you are interested in this work though, so please take any time you can to input your own ideas or criticisms or the ideas in this thread. -- In closing, if anyone has any pointers, criticisms or desires please drop them onto this thread as I only want to learn about the current AI state of CEL and the potential development and uses of AI the community wishes to see. Thank you for your time, Sam. ------------------------------------------------------------------------------ _______________________________________________ Cel-main mailing list Cel-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cel-main
