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
