Scorched Earth

[KneeGrow]

Im sure most of you have played Scorched Earth (www.scorch2000.com) aka Cannon Wars aka Tank Wars where there are two tanks and you input the angle and the velocity to shoot your bullet at the enemy. The bullet must travel above a huge mountain and hopefully land onto the enemy tank. Also wind carries your bullets depending on its speed.

So in our math class, our teacher is going over this stuff and he said that if we make this game we get a lot of extra credit. Im just wondering how to make that iregular shaped mountain (randomly generated by computer) and to make the bullets blow off part of that mountain? We can do it in any programming language so I guess java would be easier but I'm just wondering how to do this big blob of mountainous stuff.

[Draco]

For a basic starter idea you could use a modification of a sin or cos curve to make the mountain, then when a tank shell hits it it removes a certain sized circle from the mountain.

[KneeGrow]

Well if you remove part of the mountain then the hole is part of empty space that the bullet can travel through. How do i keep track of what part contains mountain, and what part has air?

[Draco]

one way would be to have a 2d bool array with a true being land and false being air. it would be a little blocky but you could use floats or graphical filtering to take out the blockiness.

[KneeGrow]

But then you would only be able to have a small amount of blocks unless u make like a [100][100] array which would be inefficient

[Draco]

if you made your algorithms fast enough, which shouldnt be too hard with the relatively low complexity of what's going to be accomplished you could have the array be the same size as the screen resolution, giving great visual quality and not taking up too much memory.

[VirtualAce]

A really cheesy way to do this is to check where the projectile will be next. If the buffer result of that position is empty then there is no mountain there, else there is.

This is assuming of course that you have enough memory for the buffers.

For the mountains you can create a recursive function that will create a randomly perturbed line. For each recursion you simply reduce the amount of perturbation of the line.

[Jeremy G]

Piecewise Functions are your answer.

http://www.jeremygiberson.com/images...semountain.jpg

In the picture I have drawn a mountain (in black) that is represented by

from -infiity to a; y = 0
from a to b; y = sqrt(1-x^2)
from b to infinity; y = 0

This is your basic starting line for the mountain. Now consider the first projectile with power R, comes hurling towards the mountain and collides with it at some point c. The mountain is now divided into the parts

from -infinity to a
from a to c-r
from c-r to c+r
from c+r to c+r+6
from c+r+6 to b
from b to infinity

Now the +6 from the fourth line comes in to simplify how we destroy the mountain.
In the x domain of the explosion we reset the y-values from the old a through b, to the lower half of the circle. (y=-sqrt(r-x^2)). From c+r to c+r+6 we simply give the slope of the line between those two points. The cushion in this case is only on the right, because it's impacting the left side of the mountain. However, this will need to be caculated for one or both sides of the circle should the area of effect cause some kind of concavity (which we arn't allowing for with this method).

Thats the analysis of the first explosion (in red). The second explosion (in blue) complicates things a little. Primarily because it hit inside the area of the red, but has a power (R) greater then first explosion. That means it has to modify more then one part of the mountain piecewise function. Luckily in this case, the blues effect completly encompasses the red explosion area of effect. So we simply grab the smallest x value in the circle equation, and the largest and reform the mountain piecewise equation with the original + blue. Again, we have the 6 value cushion that we need to calculate for the right side of the circle. The new equation looks like

(Lblue = light blue)
from -infinity to a
from a to blue c-r
from Lblue c-r to Lblue c+r
from Lblue c+r to Lblue c+r+6
from Lblue c+r+6 to b
from b to infinity

In the third explosion we have a similar case to the second, the explosion effects more then one part of the function, but unfortunatly it doesn't encompass all of one or both. After determining the area of effect from the third (green) explosion to being in the blue part to teh blue cushion to the b part, we need to reconstruct these three pieces into new pieces that properly describe line.

A note should be made here, that the y values of a part of the equation are only modified if they are greater than the y value of the lower bound of the explosion line. This explains how we get the nice peak between light blue and green explosion areas. When green crosses into blue, blue values are already lower then the explosion, so no more alteration needs to be computed. The cushion are explained below is caused by the greatest x value of the explosion area's range is lower then range of the next parts lowest range value.

The new equation (BLUE LINE) looks like

The resulting mountain is the following equation:
y = 0; -infin < x <= a
y = sqrt((Mr)-x^2); a < x <= b
y = -sqrt((LBr)-x^2); b < x <= c
y = -sqrt((Gr)-x^2); c < x <= d
y = mx + b; d < x <= e (where m and b are calculated from slope between points d,e)
y = sqrt((Mr)-x^2); e < x <= f
y = 0; f < x <= infin


Now the really tricky part of all this will be coming up with a nice structure (or class) that acts recursivly and can:
-return a collection of parts that contain a domain of x
-reconstruct a collection of parts from domain of x
-contains the equation of a curve/line for each part

So far as collision detection goes for each part it's pretty simple. All you have to do is:
- trace the projectile along its flight path (every frame, or tick what ever) and compare its current x,y value to predicted next x,y value
-send x1 into your class or function to find out the proper equation (part of function) to use for y value, and you get the collision point.
-send x2 into your class or function to find out the proper equation (part of function) to use for y value, and you get the collision point2 in the next frame/tick.
= if y1 < collision point 1 , you impacted this frame
= if y2 <= collision point 2, you WILL impact next frame

This way you can do any kind of processing that needs to be done on and--or before the collision.


Well I hope all this jibber jabber helps you out. Let me know any questions you have and I'll try to answer them.

[Jeremy G]

Well, I spent a good length of time on my post, I was at least hoping for an update or some kind of acknowledgement that a solution had been proposed. Asked questions, been critisized, praised or belittled -- anything would be fine. I'm tired of seeing my name as last poster in a thread for days at a time, and many times having ended the thread all together.


maybe my title should be "Thread killer"

[Draco]

:'( Sometimes that's just how it happens. Often if I dont feel like I have anything else to say in a post I started I won't say anything else, it doesn't mean I didn't use or appreciate the info people gave me. And by the way you're talking you seem to think the help you seem to discount everyone else's help.

[VirtualAce]

People get too personal with this stuff.

Take a chill pill Jeremy.

[KneeGrow]

Sorry Jeremy I read your post but didn't have to time to respond yet. I was discussing the scorched earth topic with my group and then I read your post. And I haven't been working on programs the last few days due to loads of homework. I ll study your method but its hard to understand at first. Thanks for your help, I really appreciate it.

[Jeremy G]

People get too personal with this stuff.

Take a chill pill Jeremy.

read my signature. It's not nonsense. I'm not being serious.

[PJYelton]

Another idea that could possibly work depending on how you plan to write this graphics wise is to simply use the graphics themselves to tell you whether or not you hit mountain. For example, if using WinAPI you could first draw the mountain to the screen using whatever method you choose (recursively is a good way), then don't bother storing the mountain at all. Then after a shot is fired and before you draw it moving to the next pixel, check to see what color that new pixel is by using GetPixel(). If its the color of a mountain or anything else that would stop a bullet, then process a hit. I would think this would be easier to implement, but obviously far less versatile than other methods such as Jeremy's.

[KneeGrow]

PJYelton thanks for the idea. I guess I'd have to learn some API cause Computer Science courses at my school have changed to java. Jeremy's is more math oriented which is probably easier to write across different languages