Simple questions
Author
Hi! I'm a starting game programmer just wondering about the following things:
Which should be handled first, input or AI? Why?
And
which should be handled first, movement or collision detection? Why?
Quote:Which should be handled first, input or AI? Why?
Hmmm... well... many times both are being called so many times per second that order doesn't really matter. You might even program these two to be asynchronous which means that they run at the same time (dual proc machines of course...)
Quote:Which should be handled first, movement or collision detection? Why?
I'd do collision detection first otherwise you might end up with seeing some going partially through a wall and then bounce back. On the other hand: you might implement a virtual move (not displaying yet) and just before you display check collisions. this might seem right but you have to take into account the speed of movement. Imagine a very fast car that moves 10 meters per frame (very fast) collision detection of just the two positions is not enough: in between these positions a wall could be present so you'd have to check more.
Wow, some questions for a starting programmer...
Cheers
Input/AI - Doesn't matter.
Movement/Collision detection - Movement first (to modify the position based on the input), then collision detection (to correct the position if there is a collision), then rendering (so as not to render from an invalid position).
Movement/Collision detection - Movement first (to modify the position based on the input), then collision detection (to correct the position if there is a collision), then rendering (so as not to render from an invalid position).
Just to expand a little more on the AI/Input side of things I thought you might like to have a reason why it doesn't really matter which goes first.
To make things simple, consider a game of Pong. You have two paddles and a ball, nothing really complex. Now, for a first example you could have two human players controlling a single paddle each. You take the input from each, update the game logic and then render to the screen - lather, rinse and repeat.
Now if you have one paddle controlled by a human player and one controlled by AI... the AI is very similar to a source of input - you just don't have to poll the keyboard/mouse/whatever to get the instructions from it. So as far as your movement/collision/rendering system is concerned, AI and Input are the same thing so it doesn't matter which order you handle them in.
Hope that clears it up for you a bit. [smile]
To make things simple, consider a game of Pong. You have two paddles and a ball, nothing really complex. Now, for a first example you could have two human players controlling a single paddle each. You take the input from each, update the game logic and then render to the screen - lather, rinse and repeat.
Now if you have one paddle controlled by a human player and one controlled by AI... the AI is very similar to a source of input - you just don't have to poll the keyboard/mouse/whatever to get the instructions from it. So as far as your movement/collision/rendering system is concerned, AI and Input are the same thing so it doesn't matter which order you handle them in.
Hope that clears it up for you a bit. [smile]
Quote:Original post by Fruny
Movement/Collision detection - Movement first (to modify the position based on the input), then collision detection (to correct the position if there is a collision), then rendering (so as not to render from an invalid position).
That's what I was gonna say.
I might run my AI first followed by input just to arbitrarily pick one. :) I can see advantages/disadvantages either way.
There are actually cases where it's good to do collision detection BEFORE movement. If on the 'game tick', you update the state, and up until the NEXT game tick, you interpolate, it makes more sense to collision detect first. Simple 1-D example:
example (pretend there's a wall or something at x = 1):
Note: Here, 'x' is some position on some virtual game map, NOT pixel position.
So in the previous example, there's a wall at x = 1... x starts at 0, and is seen to advance towards the wall, and explodes when it hits the wall, which is exactly what we want. I can't really imagine doing this kind of interpolation any other way, cause then you're trying to predict user input.
That being said, if your coordinate system is basically based on the pixels and that's that (no tiles or anything), then in most cases, it's better to have collision detection after. And in BOTH cases, it definitely comes after the 'user input' that caused it to collide (duh).
The point I'm getting at is that you shouldn't just assume there are rules for how to do everything. Consider the problem on a case by case basis, and use rules of thumb as a heuristic.
example (pretend there's a wall or something at x = 1):
Note: Here, 'x' is some position on some virtual game map, NOT pixel position.
initial x = 0Game tick: check collision for x = 0... we're good! x = 1 (so the official state is 1... but your guy is still displayed as being at 0)Frame: x drawn at 0.2Frame: x drawn at 0.3...Frame: x drawn at 0.9Game tick: check collision for x = 1... BOOM!So in the previous example, there's a wall at x = 1... x starts at 0, and is seen to advance towards the wall, and explodes when it hits the wall, which is exactly what we want. I can't really imagine doing this kind of interpolation any other way, cause then you're trying to predict user input.
That being said, if your coordinate system is basically based on the pixels and that's that (no tiles or anything), then in most cases, it's better to have collision detection after. And in BOTH cases, it definitely comes after the 'user input' that caused it to collide (duh).
The point I'm getting at is that you shouldn't just assume there are rules for how to do everything. Consider the problem on a case by case basis, and use rules of thumb as a heuristic.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
