Re: [Cel-main] AI Project For GSoC
Having found a post in the google group about multiple proposals to one organisation being ok, I have submitted my second proposal. I hope this is not too much of a nuisance for the CS team. My final proposal is listed below and I would greatly appreciate any final comments anyone may have. I would also like to take this time to quickly say thank you to everyone who has helped in this discussion and I genuinely hope that this work will be able to begin soon. Kind Regards, Sam. My Project Proposal. The A* algorithm currently used within CEL for pathfinding is, despite being an optimal solution for finding the shortest path, a slow and often unrequried detail in pathfinding within a game environment. When used in a game scenario it can lead to delays in responsiveness due to agents calculating the whole route before moving and inefficiant as by the time the full path is calculated and performed the dynamic nature of the environment often leads to the final segments of the route never being performed. To fix these general faults and to overcome the performance issues of the CEL implementation (recently discussed in the CEL mailing list) I propose to implement a HA* algorithm. For a more detailed explanation of HA* please see This Paper and for a nice overview please see This Description. Also raised during my recent discussion on the CEL mailing list and in this update within the SVN (Revision 3391) it has been noted that the current steering implementation is still a work in progress. Currently not all of the behaviours work correctly, the performance is bad and a more complete implementation of Craig Reynolds' work is desired. To solve this I first intend to work with the current cel-graph implementation to improve the integration between steering and cel-graph. This may also require some work within the body of CS to implement the ability to change colliders for navigation. Once performance is satisfactory I will look to implement the full body of behaviors presented by Craig Reynolds. Finally, deadlines permitting (this may need to become a personal project after GSoC) I would like to look into the code previously worked on for the automatic generation of navigation meshes. This would be a very useful tool when combined with the new improved pathfinding and steering property classes allowing for some very complex, believable and interesting AI agents. Taking into consideration my other commitments during the first week of implementation my proposed timeline of deliverables is: 1. Pathfinding 1. Implement a HA* algorithm more applicable to games than the standard A* solution - June 21st 2. Cel-Graph 1. Improve integration with pathfinding and steering to remove current performance issues - July 8th 3. Steering 1. Implement all Craig Reynolds' example steering behaviors - July 19th 2. Document all behaviors and create example/tutorial programs - July 22nd 4. Automatic Navigation Mesh Generation 1. Collate existing work and document current faults - July 26th 2. Begin development on improving and finalsing navigation mesh generation tool - Remainder of project -- ___ Cel-main mailing list Cel-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cel-main
Re: [Cel-main] AI Project For GSoC
Taking into consideration Jorrit's latest email with regards to submitting proposals, I have submitted my first draft and included it here. If anyone has any further comments please let me know. Also can anyone confirm wether it is ok for me to submit two proposals to CS? As I have currently leaned towards the Quest/BT proposal but would also be happy to work on the A*/Steering proposal. Thank you to everyone for their support in this application and I hope to start work of these topics soon. Regards, Sam. About Me. My name is Sam Devlin, I am a fifth year computer scientist student about to be awarded a first class MEng in Computer Systems in Software Engineering and beginning a PhD in Reinforcement Learning in October. I have a fond interest in game AI and am looking for a project where I can exert a continuous effort in practical AI throughout my time researching theoretical AI. I have no current experience working on open-source projects but am keen to learn about this field hence my application to GSoC. I do however have over a years industry experience working on a range of projects for BAE System's. Development during this time was predominantly with C++ using MSVC++. I have also completed two internships during my undergraduate degree, one of which was within the challenging environment of a major investment bank. The most relevant of which, however, was within the computer science department at the University of York, UK. During this time I worked with a large commercial API to implement modifications, again in C++, to a military simulator. I also gained working experience with Python in the automation of a number of minor tasks. I am familiar with the OpenGL API having worked with it both during a computer graphics module of my course and in the development of a project for BAE Systems. My experience in AI, however, is more substantial, having focussed a large number of my module choices into this area. I have always excelled in these subjects and as a result was selected to perform my final year project within the AI group. This project involved the use of reinforcement learning under partial observability to make agents play the soccer subgame keepaway. The successful results of my research have been submitted to the IAT'09 conference and have helped me land a DTA scholarship for my PhD research. With regards to other summer plans, I have one module that overlaps with the first week of development time and so will be limited slightly by this but will be able to then commit full time to the project throughout the remainder of the project time. I currently have no intention to apply to other projects within the GSoC. Crystal Space Questions. I first heard about Crystal Space around February this year when I began researching projects I would like to be a part of for GSoC. Although I have not yet contributed to the project, I have gained an understanding of the project through lurking on the irc channel and questioning those with experience on the AI systems available within CEL. As previously mentioned, I am keen to begin a working relationship in the community through the GSoC programme. I see this as a great opportunity to become an established part of the active CS development community and begin to work on AI systems that I want to expand, not just during GSoC but, throughout my PhD studies. Over the past couple of months I have successfully set up a working environment for both CS and CEL in MSVC++. I have worked through the user manuals of both and believe I am forming a strong understanding of the CEL architecture within which the majority of my project work will be. Also as required I have checked out the source code from subversion and introduced myself on the CEL mailing list. My Project Proposal. Given the current complications and issues with the Quest system (Highlighted at Quest Improvement Proposals, Quest Editor-See Bottom Of Page and my recent discussions on the CEL mailing list.) A number of ideas have been discussed as beneficial to the project and a refactor suggested that removes triggers and rewards from the Quest system and makes them standard property classes available throughout CEL. In doing this future systems can be designed to take advantage of these powerful tools. An example of this that I propose to implement is behavior trees. Behavior Trees provide similar functionality to FSMs but are considered more intuitive, and make logic more reusable. (For a more detailed argument of Behavior Trees please see: A Behavior Tree Overview) It has also been argued repeatedly that FSMs are becoming obsolete in industry (For example: FSM Age is Over). If you agree or not, it is important that CS/CEL provide tools for all developers. For those wishing to stick with FSMs the refactored Quest system will be available, and for those who have moved on to behavior trees the new implementation will be available. By implementing Behavior Trees and
Re: [Cel-main] AI Project For GSoC
Thank you for the link Pablo, there are some interesting problems in there that I could attempt to fix as part of a refactor of quest. I like your idea of using a behaviour tree implementation as a focus for the project and a reason for the refactor. One question, however, in your other email you mentioned the interpolation system of Quest. What is this? I do not recall mention of this anywhere. And also as you seem familiar with the Quest system could you explain the sequence rewards? It seems to me that they are simply a combination of rewards performed sequentially but from the last reading it seems implied that one can apply several rewards to one trigger and therefore the sequence seems redundant. In light of these suggestions the new proposal for the 2nd project would be: -Quest Refactor ** Freeing the triggers rewards from within Quest so that access to them is available throughout CEL. ** Standardise the Quest, Trigger and Reward properties so that they can access constraints, property values and message each other (Fixing the last three problems on https://b2cs.delcorp.org/dev/wiki/QuestEditorNG) ** Allow for nesting FSMs ** Example Program / Tutorial -Behaviour Tree Implementation ** Implementation ** Documentation ** Example Program / Tutorial As always thank you for your time, Sam. smd...@student.cs.york.ac.uk wrote: To anyone else still reading, could you please post any interest in either of the following projects: 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 They both sound good to me. I do think that the second approach can be put together with the behaviour tree implementation though, as it should be trivial given the quest has been refactored, it would be the proof that it actually works and give focus (but i might be overly optimistic, so feel free to ignore the suggestion :)). With the proposals as they are, i would probably favour 1) by heart, because it would be just so nice to have the steering examples implemented, plus the perfomance issues solved. If the second proposal was to include behaviour trees, and some interesting examples, i would have a much more difficult time choosing though. And as I am trying to expand my knowledge of the existing quest system, could anyone point me in the direction of documentation regarding this that I may have missed. I have already read the CEL User documentation, browsed the source code and the CEL diagram that I found very useful inside the Developers Whiteboard. A document about current quest editor in b2cs, how it relates to traditional fsm and some problems. https://b2cs.delcorp.org/dev/wiki/QuestEditorNG Also, its important to know the message system and component systems where refactored, to merge property classes with behaviours (not sure it is evident), so for example, the red elements in the cel diagram, are basically gone (they are still there for backwards compatibility -there are a lot of legacy behaviours out there-, but no other reason to use them). Greetings Pablo -- ___ Cel-main mailing list Cel-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cel-main -- ___ Cel-main mailing list Cel-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cel-main
Re: [Cel-main] AI Project For GSoC
Yes, I haven't fully read the thread yet but as such that sounds like a useful idea. Greetings, On Tue, Mar 31, 2009 at 1:28 PM, smd...@student.cs.york.ac.uk wrote: Thank you for the explanation Jorrit, I understand the difference now. Do you agree with the ideas on this thread that seperating triggers and rewards from quest so that they could be used by future systems (such as the proposed behaviour tree) is beneficial to the project? Kind Regards, Sam No, a sequence is not a combination of rewards. A sequence represents some kind of animation. One of the rewards that you can have in response to a trigger is to fire off a sequence. Such a sequence can be to open a door. You don't want the door to go open in one frame. You want to open it slowly. For that you use a sequence. The quest system is integrated with this sequence system so that you can also have triggers that fire when a sequence has finished executing. Example: - Initial state: door is closed. Trigger waits for player to click on the door with the mouse. - The player clicks on the door and the trigger fires. There are two rewards that are executed: - The first reward fires off the sequence to animate the opening of the door. - The second reward switches the quest to the state 'opening'. - The state 'opening' has a single trigger. It is a trigger that waits until the door has finished opening (i.e. until the sequence is done). The reward for this trigger is to go to the 'open' state. - The sequence is finished and thus the trigger fires. And so the quest goes into the 'open' state. - In the 'open' state the quest can again listen for the mouse clicks so that the door can close again. This is a basic example. Greetings, On Tue, Mar 31, 2009 at 12:32 PM, smd...@student.cs.york.ac.uk wrote: Thank you for the link Pablo, there are some interesting problems in there that I could attempt to fix as part of a refactor of quest. I like your idea of using a behaviour tree implementation as a focus for the project and a reason for the refactor. One question, however, in your other email you mentioned the interpolation system of Quest. What is this? I do not recall mention of this anywhere. And also as you seem familiar with the Quest system could you explain the sequence rewards? It seems to me that they are simply a combination of rewards performed sequentially but from the last reading it seems implied that one can apply several rewards to one trigger and therefore the sequence seems redundant. In light of these suggestions the new proposal for the 2nd project would be: -Quest Refactor ** Freeing the triggers rewards from within Quest so that access to them is available throughout CEL. ** Standardise the Quest, Trigger and Reward properties so that they can access constraints, property values and message each other (Fixing the last three problems on https://b2cs.delcorp.org/dev/wiki/QuestEditorNG) ** Allow for nesting FSMs ** Example Program / Tutorial -Behaviour Tree Implementation ** Implementation ** Documentation ** Example Program / Tutorial As always thank you for your time, Sam. smd...@student.cs.york.ac.uk wrote: To anyone else still reading, could you please post any interest in either of the following projects: 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 They both sound good to me. I do think that the second approach can be put together with the behaviour tree implementation though, as it should be trivial given the quest has been refactored, it would be the proof that it actually works and give focus (but i might be overly optimistic, so feel free to ignore the suggestion :)). With the proposals as they are, i would probably favour 1) by heart, because it would be just so nice to have the steering examples implemented, plus the perfomance issues solved. If the second proposal was to include behaviour trees, and some interesting examples, i would have a much more difficult time choosing though. And as I am trying to expand my knowledge of the existing quest system, could anyone point me in the direction of documentation regarding this that I may have missed. I have already read the CEL User documentation, browsed the source code and the CEL diagram
Re: [Cel-main] AI Project For GSoC
Thank you for the explanation Jorrit, I understand the difference now. Do you agree with the ideas on this thread that seperating triggers and rewards from quest so that they could be used by future systems (such as the proposed behaviour tree) is beneficial to the project? Kind Regards, Sam No, a sequence is not a combination of rewards. A sequence represents some kind of animation. One of the rewards that you can have in response to a trigger is to fire off a sequence. Such a sequence can be to open a door. You don't want the door to go open in one frame. You want to open it slowly. For that you use a sequence. The quest system is integrated with this sequence system so that you can also have triggers that fire when a sequence has finished executing. Example: - Initial state: door is closed. Trigger waits for player to click on the door with the mouse. - The player clicks on the door and the trigger fires. There are two rewards that are executed: - The first reward fires off the sequence to animate the opening of the door. - The second reward switches the quest to the state 'opening'. - The state 'opening' has a single trigger. It is a trigger that waits until the door has finished opening (i.e. until the sequence is done). The reward for this trigger is to go to the 'open' state. - The sequence is finished and thus the trigger fires. And so the quest goes into the 'open' state. - In the 'open' state the quest can again listen for the mouse clicks so that the door can close again. This is a basic example. Greetings, On Tue, Mar 31, 2009 at 12:32 PM, smd...@student.cs.york.ac.uk wrote: Thank you for the link Pablo, there are some interesting problems in there that I could attempt to fix as part of a refactor of quest. I like your idea of using a behaviour tree implementation as a focus for the project and a reason for the refactor. One question, however, in your other email you mentioned the interpolation system of Quest. What is this? I do not recall mention of this anywhere. And also as you seem familiar with the Quest system could you explain the sequence rewards? It seems to me that they are simply a combination of rewards performed sequentially but from the last reading it seems implied that one can apply several rewards to one trigger and therefore the sequence seems redundant. In light of these suggestions the new proposal for the 2nd project would be: -Quest Refactor ** Freeing the triggers rewards from within Quest so that access to them is available throughout CEL. ** Standardise the Quest, Trigger and Reward properties so that they can access constraints, property values and message each other (Fixing the last three problems on https://b2cs.delcorp.org/dev/wiki/QuestEditorNG) ** Allow for nesting FSMs ** Example Program / Tutorial -Behaviour Tree Implementation ** Implementation ** Documentation ** Example Program / Tutorial As always thank you for your time, Sam. smd...@student.cs.york.ac.uk wrote: To anyone else still reading, could you please post any interest in either of the following projects: 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 They both sound good to me. I do think that the second approach can be put together with the behaviour tree implementation though, as it should be trivial given the quest has been refactored, it would be the proof that it actually works and give focus (but i might be overly optimistic, so feel free to ignore the suggestion :)). With the proposals as they are, i would probably favour 1) by heart, because it would be just so nice to have the steering examples implemented, plus the perfomance issues solved. If the second proposal was to include behaviour trees, and some interesting examples, i would have a much more difficult time choosing though. And as I am trying to expand my knowledge of the existing quest system, could anyone point me in the direction of documentation regarding this that I may have missed. I have already read the CEL User documentation, browsed the source code and the CEL diagram that I found very useful inside the Developers Whiteboard. A document about current quest editor in b2cs, how it relates to traditional fsm and some problems.
Re: [Cel-main] AI Project For GSoC
Hi again everyone, I submitted my application to GSoC, with the first point that Sam mentioned, about building and improving the pathfinding algorithms and steering behaviour. This is not my final application, but I wanted to keep it updated because the deadline is coming, I think I'm going to edit it in order to complete the requirements that you requested and, of course, I want to be sure which of the to proposals that I liked is better. I think that the pathfinding and steering is better to the project, but I want to hear opinions. If you have comments about it or whatever, please let me know. Henry 2009/4/1 Jorrit Tyberghein jorrit.tybergh...@gmail.com Yes, I haven't fully read the thread yet but as such that sounds like a useful idea. Greetings, On Tue, Mar 31, 2009 at 1:28 PM, smd...@student.cs.york.ac.uk wrote: Thank you for the explanation Jorrit, I understand the difference now. Do you agree with the ideas on this thread that seperating triggers and rewards from quest so that they could be used by future systems (such as the proposed behaviour tree) is beneficial to the project? Kind Regards, Sam No, a sequence is not a combination of rewards. A sequence represents some kind of animation. One of the rewards that you can have in response to a trigger is to fire off a sequence. Such a sequence can be to open a door. You don't want the door to go open in one frame. You want to open it slowly. For that you use a sequence. The quest system is integrated with this sequence system so that you can also have triggers that fire when a sequence has finished executing. Example: - Initial state: door is closed. Trigger waits for player to click on the door with the mouse. - The player clicks on the door and the trigger fires. There are two rewards that are executed: - The first reward fires off the sequence to animate the opening of the door. - The second reward switches the quest to the state 'opening'. - The state 'opening' has a single trigger. It is a trigger that waits until the door has finished opening (i.e. until the sequence is done). The reward for this trigger is to go to the 'open' state. - The sequence is finished and thus the trigger fires. And so the quest goes into the 'open' state. - In the 'open' state the quest can again listen for the mouse clicks so that the door can close again. This is a basic example. Greetings, On Tue, Mar 31, 2009 at 12:32 PM, smd...@student.cs.york.ac.uk wrote: Thank you for the link Pablo, there are some interesting problems in there that I could attempt to fix as part of a refactor of quest. I like your idea of using a behaviour tree implementation as a focus for the project and a reason for the refactor. One question, however, in your other email you mentioned the interpolation system of Quest. What is this? I do not recall mention of this anywhere. And also as you seem familiar with the Quest system could you explain the sequence rewards? It seems to me that they are simply a combination of rewards performed sequentially but from the last reading it seems implied that one can apply several rewards to one trigger and therefore the sequence seems redundant. In light of these suggestions the new proposal for the 2nd project would be: -Quest Refactor ** Freeing the triggers rewards from within Quest so that access to them is available throughout CEL. ** Standardise the Quest, Trigger and Reward properties so that they can access constraints, property values and message each other (Fixing the last three problems on https://b2cs.delcorp.org/dev/wiki/QuestEditorNG ) ** Allow for nesting FSMs ** Example Program / Tutorial -Behaviour Tree Implementation ** Implementation ** Documentation ** Example Program / Tutorial As always thank you for your time, Sam. smd...@student.cs.york.ac.uk wrote: To anyone else still reading, could you please post any interest in either of the following projects: 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 They both sound good to me. I do think that the second approach can be put together with the behaviour tree implementation though, as it
Re: [Cel-main] AI Project For GSoC
Hi Again Sam: 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. No worries. We're pretty patient here at CS. :) 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. I understand. I don't have a ton of experience with these files, but I might be able to help you if you have questions on the overall structure of the projects of Crystal Space and CEL. 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? Ah, this is a good question. Basically, what I meant was that our primary objective with the summer of code is to have new features integrated successfully into CS. I didn't mean that we don't like having new libraries incorporated into the codebase, with successful wrappers and such added into CS. I merely meant that pointing out that Library X would work with CS pretty well, and proposing to integrate it into the codebase of Crystal Space probably wouldn't be a good idea for a project for the summer. It's not enough work, probably, and to be honest, I think that it wouldn't be challenging for most students to do this. On the other hand, proposing Library X would take care of problem Y in the Crystal Space problem set, and I propose to add features 1, 2, and 3, possibly 4, in order to better setup Crystal Space for integration with this library would be a better project. Does this make sense? 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 Yes, I think this sounds reasonable. 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 Yes, definitely a good idea. 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. Hm, this one might be a little shaky. The reason I say this is that it would be difficult to adequately propose what you actually wanted to do (within reason) in the code base. You might get into it and find that things are a complete mess, and that a 100% refactor is necessary. In this case, it would be WAY too much work for a summer of code project. On the other hand, you could get into it and find that all that's really required is documentation. In that case, the summer of code becomes a more summer of documentation, which is not appropriate in the eyes of
Re: [Cel-main] AI Project For GSoC
Hi! I'm fully interested on the first point, I posted a thread about AI too, I'm not sure if you read about it, my name is Henry. Anyway, I want to work on it, I think I can improve this implementation and add new features too. I'm going to check this carefully this week. If you have any question or comment please let me know. Henry 2009/3/31 smd...@student.cs.york.ac.uk Thank you Scott that clarifies my queries and I can now appreciate why the vagueness of the 3rd project makes it unnacceptable. My concern now is that I find it hard to choose between the other two projects as I am very keen to pursue both. Is it acceptable to submit two proposals to crystal space? As I am happy to work on whichever is more desired by the CS community. Or should I try to gauge interest on this thread and submit one formal proposal for one of the two projects? To anyone else still reading, could you please post any interest in either of the following projects: 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 And as I am trying to expand my knowledge of the existing quest system, could anyone point me in the direction of documentation regarding this that I may have missed. I have already read the CEL User documentation, browsed the source code and the CEL diagram that I found very useful inside the Developers Whiteboard. Kind Regards, Sam. -- ___ Cel-main mailing list Cel-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cel-main -- ___ Cel-main mailing list Cel-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cel-main
Re: [Cel-main] AI Project For GSoC
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
Re: [Cel-main] AI Project For GSoC
Hi Sam: A couple of thoughts that I have: Neural networks seem to have an existing implementation, albeit I assume it's not where we want it right now. Check out: /cel/trunk/include/propclass/neuralnet.h under the cel trunk. Also, I've looked in the past at the pathfinding implementation, and currently, it's an A* implementation, iirc. I know that a year or so ago, there was a big drive to try and make it faster, because the original implementation was quite slow. However, I don't currently see the same commenting in the source files (check out cel/trunk/plugins/propclass/pathfinder/pathfinderfact.h/.cpp in the repos) as previously. This leads me to believe that the implementation has been cleaned up somewhat. But, anyway, it might be a good place to start if you want to look into the code a little and see what's all there. ~Scott Thus Spoke smd...@student.cs.york.ac.uk: Hello again group, Sorry to double post, but I wanted to make sure it was on here that I am unfortunately going to be away from my computer for just over a week now. This obviously is unfortunate time with the GSoC application period beginning next week, but it could not be avoided. Please can anyone with any further points or queries regarding AI in CEL keep posting, I will be very interested to hear everyone's opinion upon my return and will look to apply everyone's thoughts and wishes in my final application. Kind Regards, Sam, 2009/3/19 smd...@student.cs.york.ac.uk: Hello Group, This is my first post to the group but I have been following the project for the past month or so and have discussed with some of you already the potential for this project. My name is Sam Devlin, and I post in your forum and irc channel as SamD. I would like to undergo a project in AI as part of the Google Summer of Code. I think this is a great opportunity to begin a development role within crystal space. I believe that a basic AI implementation should provide the following: 1.) A* Pathfinding 2.) A Finite State Machine 3.) Steering With these a good AI developer can produce a vast range of behaviours. Please comment if you think anything should be added to this list. As far as I am aware previous projects have looked to implement A*, steering and a navigation mesh. If anyone can provide details on how far these projects went I would be very appreciative as I have been advised this could be a good place to start work. To summarise, my questions are: 1.) What interest does the group have in AI development for CEL? 2.) Does anyone want anything not included in this list? 3.) Can anyone provide information regarding previous CEL AI work? Source code, brief comments and detailed explanations welcome. Thank you for your time. Kind Regards, Sam. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Cel-main mailing list Cel-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cel-main -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Cel-main mailing list Cel-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cel-main -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Cel-main mailing list Cel-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cel-main -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through
Re: [Cel-main] AI Project For GSoC
Hi Sam, Is there anyway to follow, and maybe contribute, in your development? Best regards, Carlos. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Cel-main mailing list Cel-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cel-main
