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
This post has 7 feedbacks awaiting moderation...
Comments are not allowed from anonymous visitors.
|<< <||> >>|