So today is the final day of GSoC 2009 and I have just committed my final major revision of the program. Although this will not be my final contribution to CrystalSpace, I thought it fitting to take the time to summarise the project undergone this summer; both the deliverables achieved and those that were missed.
Dismissed at an early stage due to unforeseen delays, this feature was originally intended but has not been produced. Unfortunately, I can not provide any insight at this time as to how future work could implement this feature.
CEL Expressions in Triggers
Again a personal target that was not reached. The mailing list discussion on this topic faded rapidly and with my faulty system delaying the generation of documentation in the final week, this deliverable was pushed back in favour of the documentation deliverables. Unlike nesting, however, I do have some insights as to how or if this feature should be implemented that I would like to share.
Firstly, my concern comes in that CEL expressions optionally require a parameter block to be parsed. This is readily available in rewards and sequences as when rewards are executed the calling trigger passes a parameter block consisting of the dynamic (@) parameters that specific trigger generates. It was then noted that this could be passed on to sequences when started or finished by the associated reward and therefore CEL expressions have been implemented into sequences (a small compensation for the lack of this feature in triggers.) However, with no data stored in a parameter block inside triggers and certain expressions calling parameter block methods on the optional argument could easily cause runtime errors and, even with these caught and reported, the full functionality of expressions would not be possible.
This opinion though is based on my current understanding of CEL expressions and may be inaccurate. Anyone considering taking up this development issue in future would be wise to consider this but also to read around themselves. Predominately, the following expression tokens need to be considered for their use of the parameter block:
Similarly, the method GetParameter from ParamaterManager that calls for the evaluation of expressions also attempts to get parameters of type dynamic/@ which are only generated inside triggers. Therefore, I think a new method probably should be called to prevent the accidental, attempted use of dynamic parameters inside a trigger.
The remaining list of features not developed were not originally proposed but have been raised in mailing list discussions as being of interest to the community. Anyone keen to take on a quest-related project may want to consider:
- Adding constraints to sequences
- Creating filters for Message Trigger by sender and parameters
- Making quest variables accessible as pc properties
- Standardising the start-finish protocol of sequences
After the sour note of what was not achieved, the following is a brief overview of what I have added to CrystalSpace during GSoC 2009.
Rewards, Triggers, Sequences & Parameters now Quest Independent
One of the largest goals of this project was to factor out Rewards and Triggers from the Quest system where they may be of use to developers in other contexts. This development led to the refactor also of sequences and quest parameters with the creation of cel sequences and the parameter manager. All of these tools can now be created and used without the need to construct a quest.
Added CEL Expression Functionality to Sequences
As discussed in the previous section, CEL expressions can now be passed as parameters to sequences and seqops.
A Brand-New Behaviour Tree Tool for Character Development
Successfully completed in time, CEL now offers the tools needed to create and execute a Behaviour Tree. Serving as a proof of concept for the usefulness of factoring out rewards and triggers from the Quest subsystem, the Behaviour Tree tool is a new AI method quickly gaining popularity in the commercial game development scene to create reactive and complex characters in game environments.
Tutorials on Quests and Behaviour Trees
An original deliverable that, having personally struggled to understand at first the Quest subsystem, is proudly presented to help all new-comers to CEL and this powerful FSM implementation.
It is hoped that the inclusion of such documentation for the Behaviour Tree implementation at the time of its creation will help to introduce existing CEL developers to the new tool, growing the BT user base and resulting in the further development of BT features. Examples of such future BT work could include:
- Crystal Architect integration
Already discussed briefly on the mailing list, this will require the addition of Error handling and (De)Serializing Methods.
The current implementation evaluates the whole tree each frame.
This could be detrimental to a game's performance. Instead a scheduler could dictate how many nodes to expand each frame. A BT scheduler also would allow for the development of more advanced features such as a parallel selector.
- Expansion of the Decorator Plugin
Currently only three decorators have been implemented. These three show the use of a decorator but only begin to implement the functionality. A wide range of possible decorators are possible and will hopefully in time become available in CEL.
A Final Personal Note
To conclude, I would like to thank everyone that has supported or shown interest in this project and a special thanks to Guillaume for being my mentor and helping throughout the programme.
Special mention also to Pablo who has been very vocal in all discussions, without your input a lot of this may not have been achieved. I hope you find my work useful and that we can continue to work on BT integration with Crystal Architect in the near future.
My personal plan, is now to enjoy the next two weeks of my summer and to take a break from my computer (although this will involve at least sometime trying to recover my fallen machine... grumble :( ). I am busy then throughout September with a conference in Milan and moving back to university. However, I will be available at all times by email so will keep track of the mailing list for any quest/bt discussion or anything required of me to successfully finish this programme.
My intention then still remains to continue developing for CS/CEL. My interest for the BT implementation is obvious and I hope to work further on this alongside my PhD that begins in October.
I believe that the project has been a great success, and hope that you all agree likewise. If anyone has any queries or difficulties with what I have produced I will as always remain open to questions and love to help. I hope that this work is found to be useful to the community and that it makes it into a CEL release version soon. :)
Kind Regards, Sam
My post this week is coming noticeably early. Unfortunately this is due to me being able to do little else today. I have been having a few problems over the past fortnight with my machine, but today it decided to finally blue screen and fade away. I am sad to see its demise, but am optomistic about being able to repair it soon.
However, given that we are now in the final week of GSoC I have put that on hold for now and am in the middle of installing/recompiling all the required software/code on an old laptop for me to remain functional. This is not ideal but I almost have a working environment set up again for the final programming tasks and the documentation will be easily producable on this machine.
Although I have lost this day, I am confident that my deadlines will be met for producing the documentation.
With regards to the final programming deliverable of implementing cel expressions in triggers I have had some difficulties but hope the mailing list discussion will overcome these. If anyone reading feels they can help in anyway please contribute to the discussion.
I will not make a further post this week, but I will keep the post on progress below updated.
Kind Regards, Sam
As of 14/08/09
- Parameters, Sequences and all Rewards/Triggers/SeqOps factored out
- Clean redundant code
- Tutorial Program - Partially Complete (appquesttest)
- Update manual pages on quests
- Bug fix factor out of sequences
- Implement cel expressions into sequences and seqops
- Complete questtest
- Write tutorial
- Implement cel expressions into triggers
- Implemented all selectors, decorators and lear nodes
- Basic functioning behaviour tree demonstrated in example program
- Behaviour tree executes inside csDefaultRunLoop
- Complete bttest
- Write tutorial
- Write manual entry
Regrettably Unlikely During GSoC 2009
- Deserialize/Load methods for parsing an XML BT
- Allow for nesting FSMs
- Add constraints to sequences
- Filters for Quest Message Trigger by sender and parameters
- Make quest variables be accessible as pc properties
- Standardise start-finish protocol
I have had a very successful week implementing the Behaviour Tree(BT) I introduced in the design documentation below. I am happy to say that I now have all selectors, decorators and leaf nodes implemented and have a working example of a BT that will form the basis of the tutorial.
The final major obstacle to overcome to reach my originally planned deliverable is to have the BT execute within the default run loop. At this time, the example BT is executed once effectively before the "game" begins. However, I am confident that this issue can be overcome in the few remaining days of coding left.
In addition I am very keen to support the future integration of behaviour trees into the crystal architect editor. I am taking careful consideration of the issues raised both on the mailing list and in irc with regard to this and hope to implement as many of the required methods as I can before the GSoC period ends.
Finally, google has set the suggested pencils down date as next Monday with the remaining week dedicated to documentation. I do not think that the documentation I have left to produce will take me a whole week, however, I do want to ensure that I provide good quality documentation covering all implemented features. Therefore, my plan is to start writing on Monday at which time I hope at the very least the final BT obstacle will be overcome and committed. I aim to complete the documentation by Wednesday/Thursday next week leaving a few days remaining to tackle any left over programming tasks and further develop BT features for CA integration.
As always I will remain available on irc as often as possible and can be contacted via the mailing list. Both discussions of CA integration and BT design are still active on the mailing lists and I appreciate any and all input.
Kind Regards, Sam.
|<< <||Current||> >>|