Jump to content

  • Log In with Google      Sign In   
  • Create Account

#ActualJTippetts

Posted 10 January 2013 - 08:19 PM

What is the backbone of your game? What is the structure? This is purely a game logic issue and should have no effect on threading, rendering, etc. as long as you have a clear idea of your game structure.

In my personal frameworks, I implement this sort of thing using some sort of timer class. Say your trajectory and ballistics calculations indicate that the optimal time to fire will be 2 seconds in the future, given the target's current velocity. That means the entity doing the firing needs to go into a suspended state. Of course, all the other entities shouldn't be suspended just because one is. So what I typically do is register a Timer with my central control mechanism for 2 seconds, and set up the entity to listen for the event that gets triggered when the timer expires. Each time through the main loop, all existing timers are decremented by the time step, and any that go below 0 are caused to transmit their signals and removed from the list. Considering that the backbone of my game is a message pump, it is easy enough for an expiring Timer to transmit a message through the pump targeted at the entity that wants to listen for it.

Note also that your entity logic should be intelligently structured so that the entity doesn't become locked in his waiting state. Say the target switches direction, requiring new calculations and a new timer. You need to be able to cancel the old timer and instantiate a new one. Or say, while your entity is waiting to fire another opponent ambushes it from another direction. The entity needs to be able to react appropriately to this new change in priorities, canceling the timer on his optimal shot and entering a defensive state. So the suspend state shouldn't be anything so crude as a busy-waiting while loop or thread, but instead just an AI state dependent upon the appropriate set of control and environmental factors.

Edit: Reading your post a second time, it seems that making the shot isn't the question, but waiting for the shot to arrive is. But, again, what I said applies: this is a timing issue (possibly even a collision one) rather than a threading or busy-wait issue. When the bullet arrives at its target (or collides with anything at all) it will transmit a signal through the central event system to the affected object.

#1JTippetts

Posted 10 January 2013 - 08:17 PM

What is the backbone of your game? What is the structure? This is purely a game logic issue and should have no effect on threading, rendering, etc. as long as you have a clear idea of your game structure.

In my personal frameworks, I implement this sort of thing using some sort of timer class. Say your trajectory and ballistics calculations indicate that the optimal time to fire will be 2 seconds in the future, given the target's current velocity. That means the entity doing the firing needs to go into a suspended state. Of course, all the other entities shouldn't be suspended just because one is. So what I typically do is register a Timer with my central control mechanism for 2 seconds, and set up the entity to listen for the event that gets triggered when the timer expires. Each time through the main loop, all existing timers are decremented by the time step, and any that go below 0 are caused to transmit their signals and removed from the list. Considering that the backbone of my game is a message pump, it is easy enough for an expiring Timer to transmit a message through the pump targeted at the entity that wants to listen for it.

Note also that your entity logic should be intelligently structured so that the entity doesn't become locked in his waiting state. Say the target switches direction, requiring new calculations and a new timer. You need to be able to cancel the old timer and instantiate a new one. Or say, while your entity is waiting to fire another opponent ambushes it from another direction. The entity needs to be able to react appropriately to this new change in priorities, canceling the timer on his optimal shot and entering a defensive state. So the suspend state shouldn't be anything so crude as a busy-waiting while loop or thread, but instead just an AI state dependent upon the appropriate set of control and environmental factors.

PARTNERS