# The Grey Labyrinth is a collection of puzzles, riddles, mind games, paradoxes and other intellectually challenging diversions. Related topics: puzzle games, logic puzzles, lateral thinking puzzles, philosophy, mind benders, brain teasers, word problems, conundrums, 3d puzzles, spatial reasoning, intelligence tests, mathematical diversions, paradoxes, physics problems, reasoning, math, science.

Author Message
Amb
Amb the Hitched.

 Posted: Wed Jul 12, 2006 1:48 am    Post subject: 1 I was curious about the old Tank Wars / Scorched earth type of games. How in the world do they calculate the trajectory of the bullets. Lets say Im a tank and I want to fire a bullet out of my turret at 70 degrees (relative to the ground that im on, assuming flat turf). As the bullet moves through the air it gradually arcs until it hits the ground again. As I change the angle of the bullet the trajectory or curve changes. As I increase or decrease the power of the cannon (say from 0 to 1000) the length of the distance covered by the bullet changes. I guess the trick is that at any point I know where the bullet is [x,y] and I know where the bullet is in relation to the ground below it, I should therefore be able to compute [x2,y2] based on some variable that changes everytime the bullet moves... Any ideas?
wordcross

 Posted: Wed Jul 12, 2006 2:30 am    Post subject: 2 they're probably just plotting your basic projectile equations, adding in whatever other physics they are using, such as windspeed etc. Not really that hard, i should think._________________Has anyone really been far even as decided to use even go want to do look more like?
+1

 Posted: Wed Jul 12, 2006 3:31 am    Post subject: 3 As wx said, I'm sure it's based on the well established math in the field. Do you want the math explained?_________________And he lived happily ever after. Except for the dieing at the end and the heartbreak in between.
Amb*
Guest

 Posted: Wed Jul 12, 2006 4:11 am    Post subject: 4 Pretty much... Although I will work on it myself. I want two parameters at the moment - Angle of launch, and power of launch. Im ignoring wind.
+1

 Posted: Wed Jul 12, 2006 4:15 am    Post subject: 5 Then you can just split it into its vertical and horizontal components using basic trig. Then apply gravity to the vertical. There ya go._________________And he lived happily ever after. Except for the dieing at the end and the heartbreak in between.
Aarondalf*
Guest

 Posted: Wed Jul 12, 2006 11:17 am    Post subject: 6 I'm repeating a lot of what others are saying but... Break up the initial velocity into vertical and horizontal using the angle and the power. Apply an acceleration to the vertical of x units per time unit. Time unit will be related to the refresh rate of the game. Try for more than 30fps. x will be whatever you want, that gives you a satisfying curve. Earth has an acceleration due to gravit of 9.8 ms^-2 for instance. The horizontal will have a constant velocity so you just need to increment that every frame. That should do it... unless you need to work out how to know if the bullet has hit the ground etc...
Amb
Amb the Hitched.

 Posted: Wed Jul 12, 2006 9:05 pm    Post subject: 7 Collision detection is pretty easy. Its been ten years since I did any real maths like trig, and I found it quite hard to even know what to google to get me started. Aarondalf's comments is probably sufficient to get me going....
Jack_Ian
Big Endian

 Posted: Wed Jul 12, 2006 10:59 pm    Post subject: 8
Amb*
Guest

 Posted: Thu Jul 13, 2006 4:50 am    Post subject: 9 Okay Im confusing myself. Lets say I have a tank that fires at 45 degrees on a screen with zero gravity. The progression of the bullet is easy, its [x,y], [x+1,y+1], [x+2,y+2] and so on. A straight line. However there are two elements that will help adjust this. First of all "Power" will be applied to the bullet. I daresay the power will gradually attenuate down to zero. Also gravity which negates the power variable. To start with the bullets 'power' will be more powerful than gravity, so as it continues in its trajectory it will be rising, but as it attenuates away it will start to wane off and then fall, causing the curve. What I am struggling with is the formula to achieve that. X will always increase by 1 at a time (1 pixel probably), where as Y will change according to the variables. WHere I am stuck is how to figure out what to do with power P and gravity G.... [x,y],[x+1, y ??? P ????G]. Now one Idea I had was to calculate the bullet in a perfect gravityless situation. Then just recursively alter the height it loses or gains based on where it would have been in that situation. (Eg after 1 pulse of the game clock, the perfect bullet would be at [2,2], and then [3,3], then [4,4]. With gravity and power of shot worked in, then the bullet distance away from that path Might actually grow every step, removing the need to work out an equation that starts rising, peaks, and then falls!
Amb*
Guest

 Posted: Thu Jul 13, 2006 4:55 am    Post subject: 10 Hmmm okay, I was plugging figures into a spreadsheet to test my theories and graphing them. Released my theories were correct and my graph skills not so good. I was ignoring the correct solution because I screwed the graph up
Amb
Amb the Hitched.

Posted: Fri Jul 14, 2006 6:09 am    Post subject: 11

So what I have so far is:

On click GO...
 Code: LastX := 200;  // START AT PIXEL 200 //    LastY := 200;  // START AT PIXEL 200 //    gravity := -0.02 // Per pixel per second //    TimeValue := -200;    Power := (StrToFloatDef(Edit2.text,0) / 100);    Angle := StrToFloatDef(Edit1.text,0);    // Activate Timer !

On Timer Pulse....
 Code: Inc(TimeValue); // Add 1 to Time Value    // Bullet thrown at 48degrees, initial speed 2 units per second //    NewX := LastX + (Cos(DegToRad(Angle)));    NewY := LastY + (Sin(DegToRad(Angle))) - (TimeValue * gravity);    // Collision logic goes here    ...    LastX := NewX;    LastY := NewY;

So what this does is guesses Time value. If the bullet will be in the air for 400 seconds, then for 200 seconds it will be rising and for 200 seconds falling (ignoring cliff type situations where the bullet can fall below its original height). So I would need to work into the logic a method that figures out how long something should be in the air. And then I have to figure in a power factor. Ie Fired at 200 = 2pxs per second per second type thing

Gee I wish I had a maths background....
+1

 Posted: Fri Jul 14, 2006 6:30 am    Post subject: 12 T is arbitrary. The force is expressed in (some metric)/(some time unit) Gravity is expressed in (some metric)/(some time unit)^2 Time is the indpendent variable. The position, in any coordinate, depends upon T. Unless you have an unsolvable solution, every other variable is dependent upon T. Therefore, you must construct equations that calculate x and y (assuming 2d) based upon T. (hopes that boot straps you enough)_________________And he lived happily ever after. Except for the dieing at the end and the heartbreak in between.
Antrax
ESL Student

Posted: Fri Jul 14, 2006 8:19 am    Post subject: 13

 Quote: Collision detection is pretty easy.
Actually, it's very problematic to do it in a way that's not extremely wasteful on computing resources.
_________________
After years of disappointment with get rich quick schemes, I know I'm gonna get rich with this scheme. And quick!
Amb
Amb the Hitched.

Posted: Fri Jul 14, 2006 9:03 pm    Post subject: 14

 Code: procedure TForm1.Timer1Timer(Sender: TObject); var    InitialVelocity : double;    NewX, NewY: double; begin    Inc(TimeValue);    NewX := LastX + (power * Cos(DegToRad(Angle)));    NewY := LastY - (Sin(DegToRad(Angle)));

Currently time value is not used. What I was doing was starting time value at -200 (Picked at random) and increasing it slowly. When not using time, this produces a perfect straight line at the right angle.

Now the reason I start TimeValue at -200 is so that when I do this....

 Code: procedure TForm1.Timer1Timer(Sender: TObject); var    InitialVelocity : double;    NewX, NewY: double; begin    Inc(TimeValue);    NewX := LastX + (power * Cos(DegToRad(Angle)));    NewY := LastY - (power * Sin(DegToRad(Angle))) - (TimeValue * gravity);

That when time value reaches 0 the effect of the gravity starts to have an effect. But this doesn't work... It seems to throw the parabolas all over the place. I have looked at the links provided but the notation and terminology seems to change at arbitrary points for which I have no idea when some terms seem to change (eg 1/2t*at and suddenly changes to 1/2t*gt in one reference above...)
Amb
Amb the Hitched.

 Posted: Fri Jul 14, 2006 9:07 pm    Post subject: 15 If I could work in some way of having Time start logically at 0 and add something to the equation that would eventually cause the equation making the Y coordinate start reducing then that would be brilliant.
extro...*
Guest

 Posted: Fri Jul 14, 2006 9:21 pm    Post subject: 16 My advice is don't try to go a pixel at a time, or any unit of distance at a time, but go by time units - if you're actually animating this thing. If you go a pixel at a time, then: a) you'll get very choppy motion, as not every pixel distance will take the same time to compute, due to random running of background tasks, and b) you won't get consistent speeds across different machines. Start at T0, then go through a loop. At the start of each loop, check a system clock to see what time it is (T), and compute the x and y (or x and z, as it were) based on T as per the first two equations here: http://scienceworld.wolfram.com/physics/Trajectory.html You'll get motion that appears smooth that way.
Aarondalf*
Guest

 Posted: Sun Jul 16, 2006 3:01 am    Post subject: 17 You are right, you are confusing yourself. And also, you dont need to worry about time. Leave it the f**k alone. Just worry about frames. Everything you do with games should be about frames. Ok, so here it goes. The bullet starts off with 4 variables. Velx, Vely, Posx, Posy. (Velocity and position in two dimentions). You have a constant, which is gravity, and can be any number you want... so long as it makes the game playable or look nice. You have another constant, frames per second. This is where you let the game decided whether or not to update the variables and paint stuff, or whether its just gunna sit and do nothing. The user inputs the power and angle and from this the game computes the inital values for velx, vely. The position of the tank (plus or minus a few pixels) gives you the initial values of posx, posy. Your program then needs to work out if it will update and paint the game (I strongly suggest you use object orientated code and make a master object that does all painting and frame updating of sprites and values BEFORE you start thinking about individual games. Remember, this can be used for every game/program that you make.) In all of your update frames (ie, system time%some value=0) you use velx and vely to update posx and posy. Ie, posx += velx. Posy is a little bit harder because you first have to the following. Vely += grav (where grav is the value of your gravity, usually negative). Now all you do is posy += vely. Now you have your updated values for posx and posy. Your master program will paint that object based on the new location at the next paint frame. You can add extra physics like wind... or even wind resistance. They are not so easy to implement, but wind is pretty much the same as gravity and wind resistance is only a little less trivial. Does that help?
+1

 Posted: Sun Jul 16, 2006 5:30 am    Post subject: 18 Program that for me, so I can see how jerky it is._________________And he lived happily ever after. Except for the dieing at the end and the heartbreak in between.
extro...*
Guest

Posted: Sun Jul 16, 2006 1:42 pm    Post subject: 19

 Aarondalf* wrote: And also, you dont need to worry about time. Leave it the f**k alone. Just worry about frames. Everything you do with games should be about frames.

I'm not sure what you mean here. A frame represents a visual depiction of something at a perticular point in time. When you calculate what the frame looks like (or what things changed in this next frame from the one before it), you need to know what time it should be. Equations that tell you where something is at a given point in time, t, are the least confusing way to work.
wordcross

 Posted: Sun Jul 16, 2006 4:38 pm    Post subject: 20 if you are familiar with the "Infamous Worm Game", I programmed a similar game in java. I used a frame by frame method, and it is very very jerky. On my laptop it hardly runs. Extro's method works much better._________________Has anyone really been far even as decided to use even go want to do look more like?
extro...*
Guest

 Posted: Sun Jul 16, 2006 5:36 pm    Post subject: 21 I'm not saying not to go frame by frame - just that you should check a system clock to determine where in the timeline the next frame actually is, and not assume the frames are equally spaced timewise. If, let's say, you're averaging 30 frames per second, the brain won't notice so much if there are a few gaps of 2/3th, 3/30th, 4/30th of a second between frames if the frames are as they should be at the actual time they are displayed. In other words, suppose we use fn to denote the frame that should be displayed at tn. Further suppose there is a pause during times t3, t4 and t5 (system is busy, or I'm doing some display related complex caluculation). There are two possibilities. In both I display frame f2 during time intervals t2, t3, t4 and t5. Then, at time t6, I can either continue with frames f3, f4, etc, or pick up from frame f6. t0 t1 t2 t3 t4 t5 t6 t7 t8 t9 f0 f1 f2 f2 f2 f2 f6 f7 f8 f9 t0 t1 t2 t3 t4 t5 t6 t7 t8 t9 f0 f1 f2 f2 f2 f2 f3 f4 f5 f6 The brain doesn't notice nearly as much if I pick up with frame f6. And it's just easier to compute where everything should be based on a single changing parameter, t.
Jack_Ian
Big Endian

 Posted: Sun Jul 16, 2006 10:33 pm    Post subject: 22 Delphi Pascal I see. I miss PASCAL. The calculations are not very difficult for the processor to compute, so using the system clock and calculating the change in position for each time-slice should produce very good results. If you need to get a smooth graph and you find that you are looking at straight-line segments (especially for edge-case high velocities), then cubic splines are what you would use to smooth out the results. This should not be necessary for real-time functionality (i.e. game environment), but only if you need to present the results in some smooth way. In real time, you will not notice that the projectile disappears and then reappears in another location. It's just like animation, and you should get enough frames-per-second to fool the brain into thinking it is looking at smooth continuous motion.
Aarondalf*
Guest

 Posted: Wed Jul 26, 2006 9:10 am    Post subject: 23 I don't have time to reply but I must have not explained myself very well since extro is talking about not assuming frames are evenly spaced. And I never said you should assume that. I think the point of what I was trying to say was that you dont need to paint the new frame to the screen just because you updated some variables because yeah that will cause jerkiness. And samadhi, if you still dont understand what I'm saying, yeah... I'll make an example.
Amb*
Guest

 Posted: Wed Jul 26, 2006 11:08 pm    Post subject: 24 I have a very basic working model, but my flatmate has a much more advanced one. Obviously I have left my old school maths days way way behind. (Its ten years since I left school now.... eek) Ill post my code, and see what you think.... but only once I get to my home PC where it resides.
+1

 Posted: Thu Jul 27, 2006 2:32 am    Post subject: 25 aaron: I re-read it, and I see that you don't leave time the f*** alone, so indeed, it won't be jerky._________________And he lived happily ever after. Except for the dieing at the end and the heartbreak in between.
Aarondalf*
Guest

 Posted: Thu Jul 27, 2006 3:54 am    Post subject: 26 Heh, I probably shouldn't have said that. What I meant was that when you are doing such a program you can *really* simplify it by forgetting about using time as a variable to determine where the object is. Acceleration is constant. For velocity you just add the acceleration. And for Displacement you just add the velocity. As for a working program, amb, what i suggest is to paint the data to the screen a certain number of times per second. Updating the data can occur any time inbetween these "frames". You'll find this is a really simple solution. It is very easy to read, program, and understand.... and even though you arent really using the equations of motion (specifically related to projectiles) you'll have the exact same result with less computation. It probably wouldnt matter even if you resolved the equations fully each frame though, so if you are doing this project to understant projection motion better, that might be an idea. Heh, I'm not sure if any of what I just said will help.
math geek*
Guest

Posted: Sat Sep 23, 2006 10:38 am    Post subject: 27

 Amb wrote: If I could work in some way of having Time start logically at 0 and add something to the equation that would eventually cause the equation making the Y coordinate start reducing then that would be brilliant.
Use the 3rd equation from the mathforum link (i used to be a math doctor there ): s = ut + (1/2)at^2. Just remember that u is upwards, and a is downwards, so this should read:
 Code: s = |u|*t - |a|*(t^2)/2.
Also, a is a general variable for acceleration, while g is the specific acceleration due to gravity, so don't give up just because people name things differently... For instance, i learnt this equation in the form of: "x = x0 + v0*t + a*(t^2)/2" - considering that the distance is actually x-x0, it's exactly the same thing...
 Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year by All usersAmbAnonymousAntraxJack_IanSamadhiwordcross Oldest FirstNewest First
 All times are GMT Page 1 of 1

 Jump to: Select a forum Puzzles and Games----------------Grey Labyrinth PuzzlesVisitor Submitted PuzzlesVisitor GamesMafia Games Miscellaneous----------------Off-TopicVisitor Submitted NewsScience, Art, and CulturePoll Tournaments Administration----------------Grey Labyrinth NewsFeature Requests / Site Problems
You cannot post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum