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
