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
