Hi Again Sam: > Hello Again, > I would like to start by apologising for the delay in my response to this > thread, but as previously stated I had a holiday booked which > unfortunately coincided with the GSoC application time frame. I will > attempt now to cover all the issues raised in my absence, and thank you > for your patience in what could be a very long post. > > No worries. We're pretty patient here at CS. :) > To Scott, > Thank you for taking the time to direct me to specific files. I have not > yet looked into these since my initial review of the code, but I have set > aside some time tomorrow morning to look into them in more detail, it is > getting late now and I am very tired from the journey home so it would be > unproductive to focus my attention there now at this time. > > I understand. I don't have a ton of experience with these files, but I might be able to help you if you have questions on the overall structure of the projects of Crystal Space and CEL. > However, I have a small initial query in reference to your post here and > elsewhere in the mailing lists. You suggested to Henry Daniel that the > GSoC “is more geared toward implementing new features, rather than simply > adding support for additional ready-to-use libraries.”and as you and the > others have identified there does already exist implementations of A*, > steering, neural networks and FSMs. However, it seems from the > conversations here that there are complaints with some of these features > and so my query is would the projects suggested involving improving > current implementations be less appropriate for a GSoC project than say a > proposal to implement a brand new behaviour tree plugin? > Ah, this is a good question. Basically, what I meant was that our primary objective with the summer of code is to have new features integrated successfully into CS. I didn't mean that we don't like having new libraries incorporated into the codebase, with successful wrappers and such added into CS. I merely meant that pointing out that "Library X would work with CS pretty well," and proposing to integrate it into the codebase of Crystal Space probably wouldn't be a good idea for a project for the summer. It's not enough work, probably, and to be honest, I think that it wouldn't be challenging for most students to do this. On the other hand, proposing "Library X would take care of problem Y in the Crystal Space problem set, and I propose to add features 1, 2, and 3, possibly 4, in order to better setup Crystal Space for integration with this library" would be a better project. Does this make sense? > Specifically, I am currently thinking that the following current grouping > of ideas could each constitute a full GSoC project. > > 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 > > Yes, I think this sounds reasonable. > 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 > > Yes, definitely a good idea. > 3.) AI Code Review > A more general project inspired by Pablo's comments and the apparent lack > of cohesion between and knowledge of AI systems within CEL. It has > recently been raised by Piotr Obrzut that there is a need for a unified > tool chain for AI, physics and animation but for this to be possible each > subcomponent must be complete first. That does not appear to be the > current state of affairs, and so as I see my commitment to AI within CEL > as a long term project perhaps the use of GSoC time would be best spent > collating the current systems implemented, adapting them to the standard > property classes, ensuring there correct inter-system functionality > through standard CEL mechanisms (messages, actions and properties) and > then documenting the collation with interesting examples that could serve > as tutorials to expand the communities knowledge of the tools available. > > Hm, this one might be a little shaky. The reason I say this is that it would be difficult to adequately propose what you actually wanted to do (within reason) in the code base. You might get into it and find that things are a complete mess, and that a 100% refactor is necessary. In this case, it would be WAY too much work for a summer of code project. On the other hand, you could get into it and find that all that's really required is documentation. In that case, the summer of code becomes a more "summer of documentation," which is not appropriate in the eyes of the Google administrators. I'm not saying this idea couldn't be acceptable, I'm just saying it would need to be more rigidly defined going into the project (IMHO) than the others.
~Scott ------------------------------------------------------------------------------ _______________________________________________ Cel-main mailing list Cel-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cel-main
