>> -Standardise the Quest, Trigger and Reward properties so that they can >> access constraints, property values and message each other. >> > > Can you explain this point in more detail?
This was intended to satisfy the last 3 suggestions on https://b2cs.delcorp.org/dev/wiki/QuestEditorNG. Specifically "Sequence constraints ¶ One problem with current sequences is they don't allow contraining of parameters, so, for example, if a state allows to rotate a robot arm a certain amount of degrees by clicking some key, it's not easy to make the rotation stop at a certain angle. Constrains could be implemented in sequences themselves, as an additional object, or not allowed at this level of abstraction. Using values from properties inside rewards/triggers ¶ It's needed to use real time values inside rewards or triggers, to be able to specify varying parameters (like the position for an object). This is not possible right now. It could be implemented in the quest property class, by specifying synced parameters, but needs some change also in the quest manager for this to work, as now the quest parameters are specified at quest creation, and not updated afterwards. Forwarding of parameters from triggers to rewards ¶ Rewards often need to use parameters coming from trigger, like message parameters, property values... also possibly with some arithmetic operation. This is now wip in cel trunk, but the arithmetic operations are not considered, and also the concept is somewhat problematic when trigger logical operations are being used. " >> -Add ability to subscribe to changes in pc properties (Currently only >> can >> only be done for celPcProperties > > This last point is not directly related to quests, is it? Correct, I had overlooked this. I pulled it out from a page that I had incorrectly archived as Quest improvements and was general suggestions for CEL. I will step back from this one. As the ideas you present below seem both more interesting and relevant to the project. > Generally looking very good to me, some additional ideas: > > - Factor out the sequence system: > Similar problem to having sensors and rewards inside quest and not > being accessible generally. Note sequences are connected to two > different rewards (startsequence and endsequence), but this could be > for example factored into one pc with two actions. Also, one trigger is > involved to find out when the sequence ended, this leads to the next idea: > - Somehow standarize start-finish protocol. Note i'm not very sure how > this can be approached, but many actions take some time to end, for > quests this usually involves some state waiting for an action to end, > and for behaviour trees its just the basic building block (actions > taking some time together with serial or parallel containers). In cel we > have some cases like sequences ending or starting, or the steering pc's > which report finishing when arriving to some destination (or can fail). > So, this is currently done in many ways, in the case of sequences its > done with explicit callbacks, steering works with an action-message pair > to handle start and end, and probably we have some example of > message-message too. Ok, so if I understand correctly you would like sequences removed and instead implemented through one pc with two actions with one trigger for detecting the end of the sequence that will be represented by the (to be implemented) standard finish protocol. Have I got the point? > Also, i'd like to note i'm actually working on cel logic support for > crystal architect, and all the basic framework is there to start playing > around with editors for logic (cs, gtk, cairo, a node editor > library...). It will be easy to implement any given editing component, > so feel free to ask anything specific or propose any kind of fancy > interface for quests or behaviour trees (all ideas are welcome). (this > was a test logic editor done in 3 days in the prototyping phase: > http://wiki.kyanite-studios.org/lib/exe/fetch.php?cache=&media=ca:par-ser8.png. > a behaviour tree mixed up with some operators-). That would be a very useful tool to link with this work. At this time I have no suggestions specifically for the behaviour tree as I have not considered the implementation in detail yet, but once the Quest refactor is formally defined perhaps we could work on a way to integrate the new method with your work. Kind Regards, Sam ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Cel-main mailing list Cel-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cel-main
