Where to Hook an AI Manager into the Engine?

#1 Are you doing this in script or C++?

#2 I'm also implementing basic AI into my game - but not using an AI manager. However hopefully the solution I picked will be of some insight to you.

I wanted to update my AI every tick (like you said) but I do so for each object independently in code. To update any game object on every tick you're probably looking at deriving GameBase or any of its subclasses. GameBase introduces the processTick method which is called every 32 ms (the server tick rate).
I'm personally deriving from Shapebase (because my AI will have models) and making a generic AI class. The generic AI class calls a "think" method in script at every tick and it has various helper functions for AI. The derived classes have specific stuff relating to their model, animations. The script will have quite a bit of the AI scripted in (using the helper functions). But this is all for basic AI. I'm not sure how well this approach would work with genetic algorithms or neural networks.

I'm pretty sure (AFAIK) that you could probably manage your AI using a SimGroup in script? Having a bunch of instances inside your game added to a SimGroup? I think this is the approach I'm going to take - we'll see when I get there.

- Eric

#3 @ J. - I'm doing it in C++, but there will also be hooks for manipulation through script.

@ Eric - That sounds really interesting. The reason that I thought about using the AI manager is because some of the AI stuff I have seen on the forums has had very poor performance when you scale up the number of AI entities. The idea for the manager was that I could call it and then use it to manage which AI was allowed to "think" each tick. This way I could keep a st amount of processing time sepnt on AI no matter the amout of entities. Have you thought about this issue? If so how are you going to avoid performance loss?

Also, are you overridding the AIPlayer class or are you going to build your own AI class from Shapebase?

#4 An AI Manager would be very efficient... a single (even if a bit more complex) think process running vs. a bunch of think processes (that increase significantly as you add bots).

I'm beginning to develop the same type of system, though I think I will base it purely in scripts probably using schedules.

an interesting note: TGE 1.4 in the CVS has a GuiTickCtrl

#5 To follow up on Matt's comment about GuiTickControl, 1.4 RCA (release candidate alpha) also has a new "iTickable" object implementation that basically allows you to have any object from SimObject on down receive ticks from the simulation. This means that you can inherit from the highest level that makes sense for your AIManager, and still have a tickable capability. Can be quite useful when you want to be ticked, but don't want the rest of the heavy implementation that comes along at that inheritance level.

I also wanted to point out that a single AIManager does not necessarily guarantee an increased performance as you scale up the number of bots--in fact, implemented poorly, it can cause dramatically worse performance...by it's very nature, the simulation is already looping over every object in the game (in the process of sending ticks, as well as for other reasons such as networking), and if your AIManager implementation simply loops over all your AI-controllable objects and offers them some execution cycles, then you aren't gaining any benefit.

Now, if you have a scheduling system (I'm talking process scheduling of some form/design, not simply using the schedule command) that does have optimization algorithms built into it, then yes, it can be more performant, but it's not a trivial implementation.

#6 @ Brandon - Yeah, I have thought about the performance issue. If your implimenting simple AI - I don't think the AI is going to be your performance bottleneck. I just ran my app with some dead simple AI where all the bots were following me, and every bot was thinking on the server tick rate. At around 10 or so bots performance started to notably drag on this p 1.6ghz - but it only lagged when they were all in view. They are always "think"ing when I'm not looking at them - in fact if I turned around and waited for them to catch up - it would start to lag as soon as they landed on top of me (they were in view).
If worse comes to worse and my AI is taking up a lot of resources I could also just divy up with which object will "think" on which tick. I would probably make a static variable (or two) of some sort that in the contructor specifies at what count each object should "think" at. So if I wanted to divide my thinking into 4 seperate ticks I would get bots that would have a "think" reaction time of 128 instead of 32 - still fast enough for me ;). Not only that but it would reduce the amount of thinking by 1/4. The only downside is that every bot thinks on a seperate 32 ms tick so if you really need synchronization it may not be the best option (maybe a better system of dividing "think ticks"). For now the AI is fine as it is and it's not dragging performance. So even if I really need an AI manager of some type, I think I could manage with the solution I stated above.
Also for my AI class I'm derving from Shapebase - not AIPlayer. I don't want all the stuff the comes with inheriting from the player class. There's far too much stuff specific to the player that I don't want in my bots (necessarily). So from ShapeBase it is. I use the Player class to learn from (how to implement) my object. Besides - if I'm correct, I've already found in the Player class 2 methods never used, and 1 member never used - I don't want to inherit that ;).

And from what Matt and Stephen said...
The whole "iTickable" thing sounds really interesting - but for my AI objects, inheriting Shapebase includes stuff on dts models I don't want to have to worry about for now. Inheriting from ShapeBase seems like the way for me to go personally ;).

#7 That's interesting Stephen. The idea that I had for the AI manager was to provide a behavioral and path-finding planner that could run for each AI. This planner would be housed in the AI manager and decide which AI was allowed to plan, or re-plan, on each tick. That way you could share the AI "thinking time" between all the AI over a series of ticks, instead of each AI thinking on every tick. From a Torque standpoint do you think that this is the right way to go, or should I implement a lightweight planner into each AI?

My understanding is that the current AI implementation in aiPlayer uses call backs to make "decisions" and otherwise simply updates it's position and such with each tick. Is this incorrect?

Thanks for the info..

#8 @ Eric - That sounds good, I'll have to take a look at Shapbase for my bots too. Something else you might want to think about if you hit performance issues is to let the AI "think" faster the closer they are to the player. So AIs within 100 ft ,or whatever, think ever tick and then the further out you go the less often they think. This would require a different implementation that took position to the player into account but it would let you keep the AI the player sees "smart" and then you can spread out the "thinking" for the other AIs as you need to.

#9 Just my 2 cents :

I've already played a little bit with AIManager. Actually, there is NOTHING special about it. AIManager is only the name of a ScriptObject, that is the most primitive class you might create ( thru script ) on your game from which several derive.

By creating just one AImanager you divide your game in two turns, one for the player, and other for all your bots. I'm not sure that is a good approach. Actually I had problems using this on my game. Bots disapeared, they didn't reach their destination, etc. I couldn't actually track those bugs, but they dissappeared once I made a think method for each bot and scheduled them independently.