Jump to content

  • Log In with Google      Sign In   
  • Create Account


Delay shoot until the bullet arrive to the hit point


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
11 replies to this topic

#1 Medo3337   Members   -  Reputation: 665

Like
0Likes
Like

Posted 10 January 2013 - 07:59 PM

I asked this question (as a reply) before here:

http://www.gamedev.net/topic/636970-shooting-accuracy/

 

But I think this question should be separated since it's not related to the accuracy.

 

 

In real life the bullet will arrive to the target based on the speed and distance.
So, I'm trying to find a way to delay the bullet arrival time for certain amount of time in milliseconds (depends on how far is the target).
 
The following should do the trick but definitely it will not only delay the bullet arrival but it will delay rendering as well:
while(...)
{
    // Delay until the bullet arrive (based on the bullet speed and the distance)
}

// SHOOT
Raycasting(...);
Maybe I can create a thread for shooting and do the above code in that thread then use a callback method to get the shooting result?
 
I need suggestion on what is the best way to do it without affecting the rendering, BTW I'm using a single method that I call for shooting and it should get me the shooting results every time I call it.


Sponsor:

#2 JTippetts   Moderators   -  Reputation: 8353

Like
0Likes
Like

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.

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.

Edited by JTippetts, 10 January 2013 - 08:19 PM.


#3 Medo3337   Members   -  Reputation: 665

Like
0Likes
Like

Posted 10 January 2013 - 11:27 PM

I have been thinking that I could create a timer, but is it better to have the time class work on a separate thread?

 

Also, using a timer class means I will be relaying on callbacks to get the raycasting hit result? Is that right?



#4 Tispe   Members   -  Reputation: 1024

Like
0Likes
Like

Posted 11 January 2013 - 05:45 AM

Here is what you can do.

 

For each frame, you calculate the distance the bullet has traveled ( time * velocity ), then make a new ray at a new origin deeper into the scene for the next frame. If the intersect depth test is farther then the bullet is ( time*velocity ) then the bullet has not yet reached the mesh the ray points through.

 

This will enable you at great distances to have the bullet travel through your scene, on a per frame basis. What you do is that the bullet is streched to be (time*velocity) long in size. And for each frame that bullet is moved one notch ahead, everything intersected in that frame gets hit.



#5 Medo3337   Members   -  Reputation: 665

Like
0Likes
Like

Posted 11 January 2013 - 07:27 AM

Resolved by creating a timer class, I'm wondering if it's a good idea to make the timers class work on a separate thread for better performance.



#6 JTippetts   Moderators   -  Reputation: 8353

Like
1Likes
Like

Posted 11 January 2013 - 10:54 AM

Resolved by creating a timer class, I'm wondering if it's a good idea to make the timers class work on a separate thread for better performance.

Profile first to see if it's a bottleneck. (Note that it almost certainly won't be, unless it's doing something stupid; the computing going on in a timer class will be trivial.) Simply making something multi-threaded isn't necessarily a magic bullet to make things faster. I typically reserve multi-threading (if I even use it; I have yet to make a game intensive enough that it is actually necessary) for heavy tasks: background streaming of data, maybe some AI, things that can largely be done in great chunks in relative isolation, since interleaving of access and communication between threads can complicate the process. Decrementing a few timers and passing on signals just isn't the kind of computing- or memory-access-heavy work that would necessitate multi-threading, in my opinion, making any gains from the effort minimal at best.

In short: don't complicate your code unless you absolutely have to.

#7 ankhd   Members   -  Reputation: 1220

Like
0Likes
Like

Posted 11 January 2013 - 05:03 PM

Why do you need to delay it i don't get it.
Are you talking about how fast it fire. Because a projectile should not be delayed.

#8 Medo3337   Members   -  Reputation: 665

Like
0Likes
Like

Posted 11 January 2013 - 07:08 PM

@ankhd: In real life, a bullet should take time (in milliseconds) to arrive to the target depends on it's speed and how far is the target.



#9 JTippetts   Moderators   -  Reputation: 8353

Like
0Likes
Like

Posted 11 January 2013 - 09:22 PM

@ankhd: In real life, a bullet should take time (in milliseconds) to arrive to the target depends on it's speed and how far is the target.

Of course, you can also simulate that by giving the bullet an appropriate velocity when it is spawned. No need for a timer at all.

#10 Medo3337   Members   -  Reputation: 665

Like
0Likes
Like

Posted 12 January 2013 - 05:06 AM

@JTippetts: I don't get it.

 

If the player is shooting at a distance of 3 miles, of course the bullet should take more time to arrive at 3 miles while less time to arrive at 1 mile.

 

I'm looking for a way to delay the bullet arrival according to the target distance.

 

BTW, It's not a bullet mesh, I'm using raycasting for shooting (so I'm talking about delaying the raycasting).



#11 Madhed   Crossbones+   -  Reputation: 2791

Like
0Likes
Like

Posted 12 January 2013 - 06:43 AM

You have to simulate the actual movement of the bullet, not just delay the raycast.

Then you can raycast in "chunks": Only check the path the bullet has travelled since the last time it has moved.



#12 JTippetts   Moderators   -  Reputation: 8353

Like
0Likes
Like

Posted 12 January 2013 - 08:51 AM

Pretty much what Madhed said.

Basically, once the entity pulls the trigger, he can forget all about what happens next. It really is no concern of the entity what the bullet does. I mean, of course, he cares whether or not he hits something, but once that trigger is pulled there is nothing the entity can do about anything regarding the bullet. So it makes no sense from a realism standpoint to put any sort of delay in the entity itself to handle delaying the bullet.

The bullet should be an entity of its own, governed by physics specific to a bullet entity. Whether or not you actually give it a visual representation in the world is irrelevant (although some bullet types, such as tracers or missiles with a flame trail, really should spawn a visible entity). It can just be a proxy object spawned when the trigger is pulled. This proxy object might set up a timer then go idle until the timer triggers, at which point it performs the raycast and applies the effects of shooting a bullet. Once that is done, the bullet entity self-terminates.

It is a little bit unusual, though, that you are so interested in pursuing realism with this one small aspect of it, while ignoring all the rest of the physics. If a bullet travels at 1000 ft/sec and you are shooting at a guy 30 yards (90 ft) away, and your simulation runs at 1/60 frames per sec, then the delay timer on that bullet fire will be about 5.4 ticks. Not really enough for anyone to notice. But even with the delay, there is a much greater problem with your realism: a raycast doesn't accurately simulate a bullet trajectory. Bullets, even though they travel quickly, are still governed by the law of gravity. Over some distance, the bullet will drop (if fired horizontally) or rise then drop (if fired at an upward angle). At short distances, this ballistic arc is slight and not noticeable, but if using, say, a sniper rifle it becomes significantly more of a factor. Now, you don't really need to mess with it if you don't want; if you want simple aim-and-shoot, without forcing the player to adjust for trajectory, that's fine. But if that is the case, it also seems somewhat silly to account for travel delay, since the player will still have to mentally adjust for movement of the target, so it would make more sense from a realism standpoint to model the trajectory as well.

Maybe this is how modern shooters do it, I really wouldn't know since I don't play them. But it just seems a little odd to me.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS