• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Medo Mex

Delay shoot until the bullet arrive to the hit point

11 posts in this topic

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

Share this post


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

Share this post


Link to post
Share on other sites

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?

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites

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

0

Share this post


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

Share this post


Link to post
Share on other sites

@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).

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0