So, alot of talk about an AI API or OpenAI has been done here at the forums, and mostly these threads end up in a list of features that this API should have. -Pathfinding -ANNs ect... But everybody that have tried to implement Pathfinding know that you have to form your system to fit your existing world! Infact, this fitting is so major, that when the PF is removed from your system, its almost useless, except from the algorithms that you anyway can find on any PF tutorial page. What i want to talk about is what kind of an enviroment could be usefull for an AI programmer? DEBUGING: One major problem with making AIs is the debuging. Emergent behaviour is pretty hard to test, since special cases (witch there are millions off) can emerge unwanted behavior. Of cource you can use different regular debuging features, but when it comes to AI, it would be great with a specialized monitoring system, witch supports all conds of features: Recording, playback, monitoring and so on... Wouldnt it be great to look inside a Finite State Machine whiel it was running? SIMULATION: Say we have a Finite State Machine, wouldnt it be great to set this up with a GUI? Add states, constrains, and all other stuff, and then test it in realtime? I think it would be great to be able to tweek a FSM while the game was running. (This could also be done in our debug/monitoring window, that we run from the game in develop.) INTERFACE: How are you going to plug System A with Game B? This adds to the pathfinder problem I talked about earlier. Would it be nice to have a sort of Virtual Machine run inside our game, where we could plug and play in a restricted way (maybe like LUA makes it possible to use C++ functions from inside the language)? We could also make a type of compiler that generated the actual code. Im thinking here that you should add your algos with a High level language, and then the system does the job of fitting this into your premade structures and worlds. In my opinion its much easier to talk features if you have something like this in place. Adding pathfinding isnt any easy, but if we have this frame enviroment, maybe it could be possible? This leads to a different way of thinking then in OpenGL: insted_of: aiFindPath(↦,&pos,&goal,&constrains) you get something like: aiLoadObjectType(&object_type,"gridmap.aio") aiRegisterObject(&object,&object_type) Our system can now adapt to the object type, and maybe later compile to code into high speed performance. What do you think?

Like u say PF is extremely project specific, how ever this is NOT TRUE to a minor extent.

I will never in anyones world attempt my own pathfinding code, i tried once, and it was succesfull in finding a path how ever it simle took the first path it could fine..no logic in it..

So i downloaded a A* generic code which uses tempelates, now yes i have had to edit some code but its all the same basic code.

How ever more advanced stuff begs 2 be used which will be hard!

I think OpenAI will fail due 2 one fact... AI is not an absolute thing(in a game), its more like a thought, a set of interacting things closely related to the game.

OpenAL works because sound has a definite definition.
-----------------------------------------------------------
All in all id use OpenAI just for the pathfinding if its relatively faster than anything else i have, i myself would prefer it to be in a dll file and in the first format mention : aiFindPath(↦,&pos,&goal,&constrains)

-------------
Oh and please dont forget some things have multiple goals or distance oriented goals.. IE attack unit at posR, means the unit must move till he is in range to posR so thus goal = posR-+Radius

Or other stuff where the unit looks for minerals, or a unit to support, or even higher ground.

Not to mention, Bot AI in rts games use alot of Terrain Assesment