Jump to content
  • Advertisement
Sign in to follow this  
warp X

Simple questions

This topic is 4719 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
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

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.


initial x = 0

Game 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.2
Frame: x drawn at 0.3
...
Frame: x drawn at 0.9

Game 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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!