Is there a less resource intensive way to do projectile tracking?

grimtooth

Regarding something like cannon aiming, the first thing that comes to mind to display aim for the player is to simply have the cannon constantly shoot physics-less small projectiles (white dots for instance, and only during "aim mode") that destroy themselves upon collision or upon leaving the screen X-width.

This seemed like the fairly obvious solution and came to mind very quickly... followed by "gosh that's a lot of actor spawning and destroying, it could be pretty resource intensive.

Second solution to come to mind then is not to have a constant spawn / destroy, but rather just spawn a series of actors once that destroy themselves upon firing... their positions could be calculated by a simple polynomial, but my brain runs into a problem here as well as a functional change.

Functional change = you can no longer have the aim line stop at solid objects. (not really a big deal)
Problem= What exactly does "Velocity" mean in gamesalad. The aim line function would be a plot of X,Y vs. Time so I have to ask.. in gamesalad does a Linear X Velocity of 300 = 300 px / sec? Testing makes it look like that is the case but confirmation would be good.

EDIT: After thinking I guess the time definition really doesn't matter as long as the Accelerate -Y (gravity) and Move (Vector) are in the same Units.

http://cookbook.gamesalad.com/definitions doesn't really mention anything about this.

So if anyone has any pointers or thoughts about a less resource intensive method of creating an "Aim Line" I would absolutely love to hear them!

Grim

The_Gamesalad_Guru

What makes you suspect your current ideas are resource intensive? Have you done any testing? Don't jump to any conclusions until you test out a few ideas. I'm prototyping a physics game that @RP and I are in the early stages and I don't see any real processor hogs yet. Don't listen to a lot of the misinformation around here. Always test it out for yourself. When I work on physics games I always build a raw prototype using just plain old actors.

grimtooth

Thanks for the advice Bacon I've probably just read too many threads about performance issues with large complicated scenes... I'm sure it's a lot like when people start to study medicine and disease states they invariably get a mild case of hypochondria hehe

The_Gamesalad_Guru

Yep. There is just too much speculation sometimes around here and not enough fact. I always test out stuff.. After you've been around here for a while you start to know who really knows their stuff and one can trust their assumptions as they have tested it out and know how to code.

grimtooth

So it turns out "Time" may matter after all lol

In playing with the cannon physics tutorial I created the Aim Line but it has to move faster than the cannonball or it will just be way too slow to be usable. At first I just quadrupled the shoot speed of the cannonball and then quadrupled the "Gravity" (accelerate @ 270 relative to scene) but that didn't match up to the cannonball flight.

I tried to set a max speed and then have the gravity acceleration very very high so that it would reach max velocity right out of the cannon, but that didn't work very well because you want the aim line projectiles moving forward faster than they are falling most of the time.

In order to reach a good fit with the 4x speed I had to go to 16x "Gravity" and honestly that would probably work just fine for any game, but unfortunately the fact that it works isn't really good enough for me because if possible I'd like to know WHY.

With that being said, does anyone know the definition of accelerate or velocity in gamesalad? I said earlier that I thought Velocity may be defined in px/sec, and that seems pretty straightforward. Accelerate could be one of a few things but i would GUESS that it means velocity=initial velocity + (Accelerate * self.time).

http://en.wikipedia.org/wiki/Equations_of_motion


Theorycrafting it out would say that the cannonball with 300 speed(X) and 100 gravity(Y) would fall "r" pixels in the time it takes to travel 600 pixels along the X axis

t=600/300 = 2 seconds
u= initial velocity = 0
v= final velocity = 100(2) = 200
r= y.movement = vt - (at^2/2) = 400-(100*2^2/2) = 200

compared to my aim line with speed 1200(X) and gravity(1600)
t=600/1200 = 0.5 seconds
u=0
v= 1600(0.5) = 800
r= 400-(1600*0.5^2/2) = 200 (yay)

I know it looks solved, but it really still is a question "Is this right?"
Confirm or deny, GO!

Grim

grimtooth

Link to the modified demo

http://yadi.sk/d/9BHrSmwV5enAE

The_Gamesalad_Guru

Did you add any drag to the ball? Drag will affect the flight time. Also, when I recently did some tests on gravity in relation to a ball falling from point a to point b I found that gravity over 700 didn't produce the measured results I expected. I had to almost double the change in gravity by 2 to keep the measured results in line. From say 100 to 700 the results moved in expected time differentials but after 700 it didn't.

grimtooth

I didn't add any drag to the aim line projectile, I can't look at the cannonball right now because I'm just on my phone. The only discrepancy I could see is explainable by the actor "handle" being the bottom left corner.

Anyways, once again bacon you come through... I don't need a confirm or deny, I can track self.time vs x and confirm for myself duh! Then I can stop thinking about this and move on to the next puzzle!

Grim

dudemangames

Not sure if you found a solution yet, but tshirtbooth has a tutorial for a cannon aim system. Hope this helps. Here's the link.

grimtooth

@dudmangames thank you for the video, Its not really what I was after in the beginning but it is actually something I will probably end up using in the project!

Anyways if anyone cares here is an X,T plot of "Move 100" and "Accelerate 50", I just used a timer "Every 0.5 seconds" so the points are 0.5 sec apart



Move almost perfectly aligns to X=100T (so it is almost certainly defined in pixels per second).

Accelerate almost perfectly aligns to X=50t^2/2 which would read out on display as:
6.25, 25, 56.25, 100, 156.25, 225, 306.25, 400
so Accelerate is almost certainly defined in pixels per second per second)

I hereby declare "The case of the curios newbie math nerd" closed.

@FryingBaconStudios Thanks for playing along!

Grim