Hello, I am slightly confused as to where I should put my AI (architecturally). I have a logic/view split where logic is completely seperate from audio/visual/input. They communicate via messages/events. Initially when I was reading about such a split it was a case of making a new "view" for each AI. The AI would see and react to the events and control an entity the same way the player does.

The problem I have is that events aren't really suitable for the task (I could make them more suitable) and that I would have to get alot of data from the logic in order to make the AI function(destroying the split). My events are things like "PlaySound", "UpdateScene?Node, "PlayAnimation" etc and have nothing regarding the entities themself.

MY entities are component based and so adding an AI component would be a logical choice. Any suggestions as to what I should go for (or alternate ideas)? AI as a seperate "view" or AI as a component?

Thanks

How does your view interact with the logic? If the view is issuing update scene and play animation events then you haven't separated view from logic. Your view should be issuing events like move left, and leave the logic to actually kick off the move left, decide what animations should be running(and note it should specify a general walk\run\skip\whatever left animation id. It should be up to the view to figure out what that means in terms of actual display content) etc. if this were the case then issuing an AI walk left event would be simple, just specify who it is for.

AI, as a concept, doesn't fit conveniently into this logic/view (or model/view/controller) scheme. Some AI can be considered integral to the object itself, such as steering behaviours. Other AI can be considered to be a form of input, such as pathfinding or planning. So when you start dividing up a game in this way, you probably have to stop thinking of AI as a component in itself and instead view it as a category of algorithms that might exist in various places in your application.

I would have to get alot of data from the logic in order to make the AI function(destroying the split)

Personally I'm not convinced you can have a very useful 'view' without being able to query the logic/model for a lot of information. A more typical arrangement is to allow the view (and controller, in a model/view/controller app) to query the model for whatever information it needs.

I think a better answer would be possible if we had a better idea of what sort of game you were making. There isn't a one-size-fits-all approach to putting AI into a game and the messaging system you speak of potentially complicates things further.

My view takes input (mouse/keys) and converts them into whatever it needs to (add pitch/yaw, move forward, fire etc) The logic just sends things liek play sound, play animation and its completely up to the view what it does with it.

Right now my view does work ok with no need for querying my logic but your right, I can't see how it will work with AI without being able to request alot of info.

Oh my game, would have been very helpful I agree. Its a pretty simple first person shooter, no particular goal. Its more a little project for me to learn the various things that will go into a tidy project. I will be quite happy to get pathfinding/steering behaviours, pointing and shooting.

Right now I'm thinking it will be alot easier to have entities having an AI type component but I don't want to realise later on that it was a bad idea.

The view/logic split was also there so I could potentially try multiplayer (with a new type of view being a remote one).

My view takes input (mouse/keys) and converts them into whatever it needs to (add pitch/yaw, move forward, fire etc) [...]

Right now my view does work ok with no need for querying my logic but your right, I can't see how it will work with AI without being able to request alot of info.

What you're talking about there is what is normally called the 'controller', and as you've noticed the controller rarely requires much information - it just translates physical input into logical input and passes that to the model.

The problem is with the view proper, eg. rendering (and to a lesser extent, audio, and networking). To be able to present things to the screen the view must have timely information about almost the entire world. It's typically impractical to push this data to it via messages, since it tends to require a large number of messages, some heavyweight, and often forces the game logic to know about view specifics, or to include redundant data into messages in order to accommodate a subset of view functionality. You can get a certain distance with message passing, as you've found so far, but this ends up getting unwieldy before long.

Instead, people tend to do the reverse: the model knows nothing about the view except that it exists, but the view knows all about the model. The view is then able to pull whatever data from the model that it needs in order to render the scene.

Either way, for your FPS system you can go a long way with just embedding the AI into the logic side. It will, however, end up performing a similar role to your 'view' in that it will be sending 'move forward' and 'fire' messages to the logic. So if I was writing a model-view-controller type of FPS game, I would make the AI a type of controller. Later on this might allow you to host AI on a different server to the one hosting your game, should that be of interest (eg. for mass battles).

Thanks for the replies. I do like the idea of a proper model-view-controller as it will make game saving alot easier too. I think I will stick my AI as components (they can directly access other components then, no need for messages) for now. It'll be fairly self contained I hope so I can rip it out in the future if I decide to try the MCV.