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 > >>>> 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 > >>> > >> > >> > >> > >> -- > >> Project Manager of Crystal Space (http://www.crystalspace3d.org) > >> and CEL (http://cel.crystalspace3d.org) > >> Support Crystal Space. Donate at > >> https://sourceforge.net/donate/index.php?group_id=649 > >> Personal page: http://users.telenet.be/jorritTyberghein/ > >> > >> > ------------------------------------------------------------------------------ > >> _______________________________________________ > >> 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 > > > > > > -- > Project Manager of Crystal Space (http://www.crystalspace3d.org) > and CEL (http://cel.crystalspace3d.org) > Support Crystal Space. Donate at > https://sourceforge.net/donate/index.php?group_id=649 > Personal page: http://users.telenet.be/jorritTyberghein/ > > > ------------------------------------------------------------------------------ > _______________________________________________ > 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
