Hi smd...@student.cs.york.ac.uk wrote: > Hello Group, > This is my first post to the group but I have been following the project > for the past month or so and have discussed with some of you already the > potential for this project. > > My name is Sam Devlin, and I post in your forum and irc channel as SamD. I > would like to undergo a project in AI as part of the Google Summer of > Code. I think this is a great opportunity to begin a development role > within crystal space. > > I believe that a basic AI implementation should provide the following: > > 1.) A* Pathfinding > 2.) A Finite State Machine >
Note we also have a (little bit non-standard and limited) finite state machine system called "Quests". > 3.) Steering > > With these a good AI developer can produce a vast range of behaviours. > Please comment if you think anything should be added to this list. > > As far as I am aware previous projects have looked to implement A*, > steering and a navigation mesh. If anyone can provide details on how far > these projects went I would be very appreciative as I have been advised > this could be a good place to start work. > Well, i have experimented with current code in cel, not sure if some gsoc results (like the navigation stuff last year, which if i recall correctly was about generating a navigation mesh from world geometry) are still to be merged in trunk though, but my experience was, the navigation graph system can work together with the steering system, but it's not completely optimal (too many computations for example), and also isn't completely bug free. It also needs some support from cs, so for example a different set of colliders can be set for navigation than for other things, for example, or find some other way to optimize collision detection on cs. Also, b2cs can produce navigation graphs created manually. Also, iirc the navigation graph system can do A* pathfinding, but you can check the code.. As i understood of what we have, pcsteer takes care of steering when going from one place to another, pcpathfinder uses navgraph information to find a good route among two distant points, the navgraph provides the pathfinding functionality. > To summarise, my questions are: > > 1.) What interest does the group have in AI development for CEL? > A lot :) > 2.) Does anyone want anything not included in this list? > Ok, some random ideas, in no special order: 1- neural networks (we do have something, but not sure to what extent it works, nor do i know what nn model it implements). From my pov a good implementation should provide a nice example that works, two nice examples that i dont think can be done easily at the moment are the ones explained in the neat nn papers (classical nn test problems), or the creature evolution papers from karl sims (a little bit academic, but still i'd love to see it running on cs+cel with standard stuff) 2- behaviour tree implementation in the line of the ones proposed on aigamedev.com (its a little bit not standard i think, but looks interesting and the papers there certainly are) 3- Yet another thing i'd like to see, someone reviewing all ai code to adapt it to current standards for property classes (like the more advanced message system), plus quality checking, documenting and creating some useful examples and so on. Make sure all ai subsystems work nicely together via the standard cel mechanisms (messages, actions and properties). 4- examples involving advanced interaction among ai subsystems together or with other subsystems would be specially useful for people (say, crowd simulation on a non trivial surface with non trivial obstacles, or for steering, implementing all the examples from Craig Reynolds together with improving the steering classes so they can actually do it -at the moment our implementation is very simplistic-). 5- Improving the sensor system. At the moment, many systems are trapped inside the quest system (the "triggers"), while they would be generally useful in many situations, or with other guiding ai setup (like the behaviour trees, or straightforward connections to events), also, some sensors which are commonly needed in games are not readily available at the moment. 6- Refactor the quest system, maybe by creating a more straightforward FSM implementation, saner api, allowing nesting of fsm's, better introspection support, direct link of cel properties to quest properties. 7- See how the uml capsule model for real time applications can be applied to cel. 8- Bayesian networks 9- If you can get yourself a copy of "AI for developers", i myself could see a lot of ideas for cel, but i dont have it around right now (i'm not sure but i think on a previous email to this list i said which chapters we had -more or less- already covered in cel). > 3.) Can anyone provide information regarding previous CEL AI work? Source > code, brief comments and detailed explanations welcome. > I don't know all details, but you can check the current quest, navgraph, pathfinder and steering property classes, plus you can check out the cel branches, which is where the gsoc work gets done. About the neural network property class, i think the ecksdee people can provide more information, since they at least tried to use it at some point. There is also something called the "rules" property class, which i think is also ai related, but not sure what it's for exactly and also afaik is not finished. Good luck :) Pablo ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Cel-main mailing list Cel-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cel-main
