Enemy Projectiles

[Vincent]

Hi guys,

I was wondering about the best way to create multiple type of enemy projectiles.  They don't just look different, they act different.  For example, some are affected by gravity, some aren't.  Some will pass through solid tiles, some won't.  Some will be fast, others will be slow.  Some have special properties (can be blocked by attacking it, will pass trough certain type of armor, etc.)  Or course, they won't deal the same amount of damage.  But overall, a lot of behaviors will remain the same (they all move, they all deal damage, they all disappear if they get too far from the main character, etc)

What is the best possible way to realize that?  At first, I thought I would create only one sprite definition with a lot of properties and, depending on the value of the properties, they would behave differently.  But as most of the enemy projectile sprites will be dynamic sprites, I don't think there is currently of way to set these properties when the dynamic sprite is created (for example, lastcreatedsprite.IsAffectedByGravity is not a property defined in the SpriteBase class).

Is there a way to set particular properties of a dynamic sprite when it is created or is it better to create a sprite definition for all types of projectiles and then copy-paste the common rules between these sprite definitions?

Thanks a lot!

[Tanja]

if you want to create so many different types of sprites, i for myself would make a different definition for each sprite. this would make it a lot easier to create, change, test and debug one sprite after another. also, maybe it would be easier to assign the various graphics.
one super sprite with hundreds of graphics and behaviours just sounds very complicated and buggy.
and you would just pass the name of the projectile to be created and it'd be fine.

[durnurd]

I think the simplest solution would be to create a different sprite definition for each, and everything that they do that's similar can be made as a custom code object as a partial class of the SpriteBase class.  If you want to define all the rules in the rule editor, you can then export that to a custom code object (recently added feature!) that will be a partial class of your sprite's class.  If you then just change the class name in that code object to SpriteBase, you can then call that function from any sprite.  So all of your similar handling between projectiles will be in one rule, and all the differences would be what you can worry about on a per-sprite basis.

You may want to leave the general rules in one sprite so if you need to change them, you can edit the rules and re-export it.

[Vincent]

Thanks guys!  These are good ideas.

I've got another question concerning enemy projectiles...  To aim at the main character, I have 2 big counters that keep track of the main character x and y positions.  When a projectile is created, it takes the current values of the counter and store them in it's own properties (to prevent the projectile from changing target in mid-flight).

Now, I've got a target x and y, I've got the projectile x and y current location...  How do I throw it?  Is there a way to throw it at a certain velocity in a direction determined by the two points I have?  I see no such built-in function.  Did someone do something similar?

Thanks again!  You're all very helpful!

[bluemonkmn]

The function that's most similar to what you want is called GetPolarStateByVector.  You can copy that function into your own custom function and, instead of getting the state based on the sprite's current velocity, get it based on the offset between your sprite and the target location.  The key function there is Atan2 which returns an angle (in radians) given x and y coordinates (the y axis is inverted on computers as compared with a conventional rectangular coordinate system used by mathematicians, which is why the y value has a minus in front of it).  If your copied function eliminates all the dx and dy stuff for velocity and simply replaces it with the offset from your sprite to the target coordinate, you should get an angle, which you can stick into that same formula to get a state that the rotating sprite should switch to to point in the right direction.  Then you can use the PolarAccelerate function to set the velocity in that direction.

You probably want to put this in a partial class (possible generated by the method durnurd mentioned above) so that if a new version of sprite.cs comes out, you can safely reset the intrinsic code and not lose your modifications to the sprite class.

[bluemonkmn]

Another option is to use PushTowardSprite or PushTowardCategory to get the sprite moving in the right direction (if you know which sprite you're heading toward), and then use GetPolarStateByVector to make it point in the direction it's moving.  If you don't want the sprite to change direction after it starts out, just be sure that you stop running these rules shortly after the sprite is created by clearing/setting a sprite parameter to track when you've already done what you need to do and don't need to do it again.

[Vincent]

Well, finally I created a modified version of PushTowardSprite called PushTowardCoordinate and it takes a x and a y coordinate.  But it's mostly doing the same thing as PushTowardSprite.  I decided to manage the aspect (rotation of the sprite) myself without using a function (like Get PolarStateByVector) for that.  For the moment at least...

Thanks for your help!

[Vincent]

Just wondering... 

Is there some predefined function to calculate the trajectory of a thrown object that is affected by gravity?  I'm working on a custom solution (target x and y, origin x and y, constant gravity and constant velocity, angle varies) so an enemy can throw an object that flies like a grenade.  But boy, my maths lessons are far behind.   :nerd:

I'm getting somewhere, but I wonder if I didn't overlooked something that could have done the trick.   :suspious:

[bluemonkmn]

There isn't a function that will predict the entire path that an object affected by gravity will take.  It just happens 1 frame at a time by accumulating simple operations like moving according to the current x and y velocity and increasing the y velocity by gravity.  Why would you need to pre-calculate the whole trajectory?

[Vincent]

Ok, here's why I want to precalculate a trajectory. 

I made a function called PushTowardCoordinate which will aim a thrown object toward a coordinate.  In the context of just a big initial push, it works just fine when the projectile isn't affected by gravity: it will fly toward it's target and hit it.  But, if I use this same target when there is gravity affecting the projectile, the projectile will fall under the target.  To make sure the projectile hits the target on course, it must be aimed over the target.  The initial angle is greater because, as it moves toward the target it will lose altitude.

I provided a little graphic to explain this.  (see attachment)
The red dot at the origin of the graphic is where to projectile is launched.
The red dot further in the graphic is the target to hit.
The green line is the trajectory the projectile follows.
The black line is the angle at which the projectile is thrown.  (Will be hidden under the green line if the two are identical.)
The blue dot is the coordinate that the projectile is aimed at. (Will be hidden under the red target dot if the two are identical.)
 
In the graphic without gravity, the target point to reach is the same target point that has to be aimed at.  The trajectory is straight.  The target is also the coordinate where the projectile must be aimed.

In the graphic with gravity, in order to reach the target (red dot) you must aim over it (aim at the blue dot), since it will lose altitude on it's way to the target.  I want to make sure the projectile hits the target, so if I calculate the whole trajectory first, to make sure it will reach the target during it's flight.

I hope it was clear enough.  I'm not familiar with technical and mathematical vocabulary in English. 

[durnurd]

Well, here's my suggestion:

dy has a constant decrease over time (gravity)
dx is constant over time (initial push);

Calculate distance horizontally between origin and destination, divide by dx.  This is the number of frames the projectile needs to travel to reach the destination.
Multiply acceleration due to gravity by this number of frames to find the height the projectile will fall over this distance.
Aim that much higher over the target, and as long as aiming higher doesn't change your dx, the projectile will reach it's destination.

[bluemonkmn]

You might want to also do something to make dx be inversely proportional to dy so that you don't throw something really fast and high just because it's close to you horizontally but not vertically.  (If dx is 4, and the object is 12 pixels away from you horizontally and 150 pixels away from you vertically, you probably don't want it to cover ~50 pixels vertically in the first frame.)  You probably want to start with a normalized vector resulting from PushTowardSprite to get the velocity, then use the resulting dx.  But maybe that's what was planned all along .

Also, I don't think you can just add gravity * frames to find the offset because ... how do I explain this in plain English?  The order of the change is at the wrong level:
1) Position changes over time as a result of velocity
2) Velocity changes over time as a result of acceleration (gravity)
3) Gravity is a constant.

If you try to calculate a new position (at level 1) using only gravity (at level 3) you have skipped level 2.  In order to calculate the proper offset, you need to get the cumulative affect of gravity on the velocity and position.  For example, if gravity is +1 pixel per frame per frame, then after 5 frames, velocity will be 5 and position will be 0 + 1 + 2 + 3 + 4 + 5 = 15.  The formula to calculate the cumulative effect such a variable is (n * n + n) / 2 when the rate of change is 1:
1 + 2 + 3 + ... + (n - 3) + (n - 2) + (n - 1) + n
(cancel out 1 with -1 in "n-1", and 2 with -2 in "n-2" etc)->
0 + 0 + 0 + ... + n + n + n + n
(the number of terms is n, one of them is the one on the end that didn't cancel anything, and half the remaining terms are 0 and the other half are n) ->
(0 * ((n-1)/2)) + (n * ((n-1)/2)) + n
->
n * (n-1)/2 + n
->
(n*n-n)/2 + n
->
(n*n-n)/2 + 2n/2
->
(n*n-n + 2n) / 2
->
(n*n + n) / 2

So for example, if you have 5 frames and gravity is 1, then use the formula:
(5 * 5 + 5) /2 = 15 ... the total offset from gravity after 5 frames is 15
indeed 1 + 2 + 3 + 4 + 5 = 15.

Now the question is, what if gravity is only 0.4?  The number of frames is still n, but the last number is 0.4 * n.

0.4 + 0.8 + 1.2 + ... + (0.4*n - 1.2) + (0.4*n - 0. + (0.4*n - 0.4) + 0.4n
->
0 + 0 + 0 + ... + 0.4*n + 0.4*n + 0.4*n + 0.4*n
->
(0 * (n-1)/2) + (0.4*n * (n-1)/2) + 0.4*n
->
(0.4 * n * (n-1)/2) + 0.4*n
->
(0.4 * n * n- 0.4*n)/2 + 0.4*n
->
(0.4 * n * n- 0.4*n)/2 + (2 * 0.4*n) / 2
->
(0.4 * n * n- 0.4*n + 2 * 0.4 * n) / 2
->
(0.4*n*n + n * (-0.4 + 2 * 0.4)) / 2
->
(0.4*n*n + n * (0.4)) / 2
->
(0.4*n*n + 0.4*n) / 2
->
(0.4)(n*n + n) / 2

So let's see if this works for 3 frames
0.4 *(3*3 + 3) / 2 = 0.4 * 12 / 2 = 4.8 / 2 = 2.4

0,4 + 0.8 + 1.2 = 2.4

Yay!

So the general formula for any gravity g, then, would be this:

g * (n * n + n) / 2

There was probably an easier way to calculate/simplify that process, but... whatever

[Vincent]

Whoa!   

Your way to calculate is much simpler than mine.  I replaced my calculation with yours and it is much faster to calculate.

Thanks a lot guys!!!  The projectiles look great!