Should AI movement/logic happen during input or update?

[kong288]

So for the most part you have 3 parts to a game's main loop, right? One that does input, one that does updates, and one that finally drawls things on the screen.

Can someone outline what should go in where? In input we have things like user input. Update we have collision? And then the draw will basically just draw everything to the screen. What about AI movement (assigning current velocity, giving tasks, etc). and what exactly should happen in the update part? should EVERY object that isn't static (like a wall) have their own update function? if so, what should happen in it? assigning the current rotation/moving?

and where does collision come into this? should you have ONE update loop and make everything run through it one iterator at a time? example:

//input
for(int x; objects; i++)
{

objects[i].update();
collision(objects[i]);


//draw

that seems more efficient than:

//input

objects.update() //runs through EVERY object and calls its update function
collision.update() //runs through EVERY object AGAIN and checks collision
//etc

//draw 

that seems less efficient seeing you're looping through every object more than once.. but it seems like it'd work better. i mean, how is collision going to work if not every object has moved for its current frame?

if anyone can link me any articles that go through this stuff that'd be great as well. thank you for reading.

[Peter87]

There is no single way to do this so I think it's up to you how you want to do it and what suits the game you are making.

The update phase can consist of many different parts. The way I see it the update phase is what updates the state of the game. This means all movement, collision detection, collision response and updates of other things that is part of the game state.

I think the state of the AI is part of the game state so it should be in the update part. I don't think the input phase should actually move anything, not even the user character. It should just register what keys are down so that you can take the correct actions in the update phase.

I don't think you need to be very concerned about the efficiency of the two ways of looping through the elements. Most of the time will be spent inside the update and collision functions anyway. What is most important is that you get the game to behave the way you want (and that the code is easy to work with). If you are doing collision detection against other objects there is a difference between the two methods you describe. Make sure you use the one that give you the result that you want.

[BlatantlyX]

I dont actually know anything about AI or game design, so take this with a grain of salt.

Should AI movement/logic happen during input or update?

Yes.
This depends on what you want the AI to do. I would suspect the common thing to do would be to have AI in update, but i've also seen it happen during player input in some games. You may even choose to have a purely graphical AI, and update it while you are drawing.

should EVERY object that isn't static (like a wall) have their own update function?

This is one technique of doing an AI, and things in general, Unity 3D is a game engine that uses this. There are also many other ways to do AI.

And finally, something fun to read, but I'm sure it will help:
http://alumni.media.mit.edu/~jorkin/gdc2006_orkin_jeff_fear.pdf

[ultifinitus]

Honestly, your AI can go anywhere, but one thing that I've learned in my most recent game is the value of consistency.

For myself, in my game loop, I now have a separate place for my entities to receive input (this is where I put my core AI logic, and where my player object checks for input from the keyboard), one (this can combine with the previous step if you don't want to store events) for my entities to act on input (this means both the player, and AI), then a completely decoupled method to show the entities on screen.

As far as individual objects having an update function... I use a relatively complicated event system, and each object can respond to events that happen (such as player interact, player step into, player collision, mouse click, etc), this was the biggest revolution in my game programming, once I made the objects able to efficiently interact with one another, the actual game development was able to progress farther at a much faster rate.

Now when I say I have a separate place for my entities to receive input, act on input, and display, I'm sure you can see how an event system would easily fulfill the role of sending those messages to the entities.

One other thing that I've learned recently is the value of actual implementation vs the value of abstraction. I love making abstract functions that perform magnificent functions, but at some point for the game to become a game there has to be some very specific code for that game, and for me focusing less on the back end and more on the goal of the game has really helped me shift gears and make better programs in general in addition to games.