The math of Tank Wars

[Amb]

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]

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?

[Samadhi]

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*]

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.

[Samadhi]

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*]

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]

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]

http://mathforum.org/library/drmath/view/56288.html
http://www.makingthemodernworld.org/learning_modules/maths/04.TU.02/?section=9

[Amb*]

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*]

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]

So what I have so far is:

On click GO...

[Samadhi]

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]

[Amb]

[Amb]

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...*]

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*]

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?

[Samadhi]

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...*]

[wordcross]

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...*]

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]

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*]

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*]

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.

[Samadhi]

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*]

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*]