Projectile System information

OK guys, I was wondering if I could make a projectile system. However I am newb in this area and I make no idea what such a system would take nor need. I also make no idea what it is supposed to do besides moving projectiles. I believe I can make something great, something good, but I need a point to start.

You can help by telling your opinion:
What are the problems of such systems?
What are they supposed to offer besides moving missiles?
What option would you like to see?

What kind of coders do you want the system to cater to?

How much kinematics you know to offer something good and solid?

My problem(s) regarding this kind of thing are:
a. Mathematics know-how
b. Algebra
c. Trigonometry
d. Geometry

Note: These are my personal problems.

I'm also guessing that warcraft's engine, with regards to it's performance, can't accommodate multiple instances of objects, alongside it's mathematical operations, moving at a single time-frame, since it's (game engine?) operation is limited to a certain extent.

Anything a user of the system might want.

Projectiles/Objects WILL be limited proportional to the computing power of a user's computer.

In my opinion, a projectile system alone would just burden a map, there are more disadvantages than advantages. Projectiles would resemble a realistic flightpath but at the price of having only a small amount of them populating the map. A physics system is a much better thing to incorporate into a map, rather than a projectile system that only handles movement and a very basic collision detection, that is if it was feasible.

This "system" is for vJass coders. It is supposed to be something CMS might use.
Now, the reason why I wonder about this system is because I didn't found one I like.
xecollider is rather limited and doesn't allow for certain types of missiles.
After seeing a diablo3 movie, where the caster actually stops the missiles in time or reflects them, I started to wonder why no one had done that before when it can be done.
Now, I can make this thing efficient by using TimedLoop per example, but I don't see how a Physics system is related to a projectile one. They take care of different things.

As for the limit of missiles, it would be something like 8190 if I am not mistaken, which is perfectly feasible, even if 1 units shoots 2 missiles, you are never going to have 4095 units in one map at one time.

The system would be CMS in most cases. I intend to add some more features like collision detection but the user will always define what happens to the missile.
As for geometry, this system would make a pair with my 2D3S system, thus allows for users to make any geomtric shapes he wants.
I am currently asking for reviews on some scripts of 2d3s.

As for kinematics, I just don't see a use for them, which is why I am asking for an opinion, I don't know what a projectile system is supposed to do xD

Wrong..? They both simulate physical objects. The difference is, a "physics system" is meant for a lot more than projectiles.

The problem isn't the limit of struct size. The problem is the amount of missiles you can simulate before the game lags to hell. Of course, you can simulate a lot more than most people would think without lagging the game... But to do that, you need to really understand how to write heavily optimal, but still maintainable and readable (v)JASS code.

Collision detection is the only real reason I haven't written and release a physics system. It's not easy to do deterministic collision detection for a high yield of objects in an optimized fashion. You have to do culling well, otherwise you end up calculating a lot of useless garbage. You also need a high understanding of the math involved to apply it in (v)JASS.

Also, would you consider doing collision detection between different missiles? Or just between missiles and units? (Therein lies what really separates a projectile simulation system from a full blown physics simulation system...)

Well I thought that detecting collisions was easy, In fact I detect collisions in one of my spells by picking all units around the missile every X seconds. If I find any unit, then I blow up the missile. Because I have in mind using TimedLoop, I would only need 1 timer for all 8190 missiles in game, so I believe this would be quite optimal.

As for the collision, It would probably be both. I mean, I can store structs into Table, and then I pick all struct of type myMissile and check if they re hitting something or not. This way I can make missiles do whatever I want, like change their direction or speed in runtime, like in the movie from diablo 3.

I've used phönix fire as collision detection without any animation used or detection triggers.

However this only works for 2D projectile systems. The problem with phönix fire is that it only covers 2 dimension and kills units no matter their height, which eliminates the 3rd dimension.



You can choose making a simple 2D projectile engine which look well in flat maps like the one I'm using in Naval Battle, or make a more awesome 3D projectile system which looks more realistic but requires more scripting, like in Supreme Commander map for wc3. I'm not sure what you want.

Well, my system will be mostly an interface. It should allow both so I am going for 3D.
I was thinking on something like this:


Then the system would obey this interface:


A missile would be something like:

Truth is that I already did most of the job here:
http://www.wc3c.net/showthread.php?t=107101

Which is why I am considering this expansion.
I have already seen a ProjectileSystem in the script section that handles no physics, I am aiming for something similar but yet with more features.

So now imagine I want to make the TimeSlow diablo 3 spell, which slows or stops all missiles that enter an area.
It would be something like:

When the spell end, we return the original speed to the missiles, if they are still alive.

This has what is called the arrow-through-paper problem.

Lets say that X represents the radius a missile needs to be in to kill a unit, O represents a missiles position before, and G represents its position after a single iteration of the system: (= represents empty space)

O======XXXXXXXXXXXXXXXXXX=======G

if a missile travels fast enough, and the search radius is small enough, the missile will skip right past the unit, like in the above diagram, even though it's flight path was right through it.

Also, that doesn't account for z-height. Of course, you can check Z height when you find a unit to collide with using that method, but it still suffers the problem I just described.

You wouldn't use TimedLoop. You'd build a list of missile instances which actively need to be simulated in a global array, and iterate over them from a normal JASS timer. You don't need a timer system for that.

If your missiles are travelling along a fixed path, you've created the worst projectile system ever...

What about bouncing off of terrain? Destructables? Buildings? how will that be handled?

Well, it kinda makes sense, if the missile is too small should it hit anything ?
Though it is a problem I didn't know about.
Is there a practical solution for it ?


As for 3D collision, CMS already has a way to detected it (thanks to chobibo) , with a few changed I would make that able to work.


As for terrain and destructables and such ... well, I don't know any projectile system that handles them. What usually happens (I usually see) is that the missiles ignore terrain and die when they collide with a tree or a building (which kinda makes sense) or that they simply pass through the building like Hammer Bold or any other projectile the game uses.
And no, they don't follow a fixed path, every iteration I calculate the position of the target and change the missile to move towards it. Ofc this only works when the spell has a fixed target that you want to hit. If it is a spell like shockwave then I don't know how to fix the arrow problem you pointed.
I think xecollider has something similar to the arrow problem, but I don't know, so I will check it.

Your global array is neat ... but I want to make this modular xD
I mean, if I don't use stuff made by the community, someone will sooner or later accuse me of having NIH syndrome. Besides, using things made by other people kinda eases my life =P

What do you think of my idea of "use" of the system?

So, things a system should have:
- Not have the arrow problem
- what I am supposed to do when hitting building, trees?
- how should it behave with terrain?

Sorry, I have more questions than answers...

Projectile systems are pretty fun to make. I had a really cool projectile system script somewhere, but I never finished it, because I was too lazy to code a good homing thingy for it, because rotating vectors was harder than I thought and sometimes I kinda hate math.


If you are doing some GroupEnumProjectilesInRange function, you should just make all missile dummies to be same unit-type and owned by Player 13, so you can just easily group them by using GroupEnumUnitsOfPlayer, since it picks locusted units too. Projectile struct can be attached to dummy with UnitUserData. It should not conflict with any unit indexing, since those systems usually dont index dummies anyways. Same unit type for all projectiles makes filtering easy.


That arrow problem could probably be solved by picking units in larger area, and doing some vector math filttering to find out how close they actually are the line projectile is travelling. ( Of course this makes it slower and is not easy at all I can imagine )

For hitting buildings and trees, you should probably just have some method in your interface for that, so people can make different projectile types to behave differently when they hit those. Same thing with when they hit terrain.

I see your point Vikuna. Truth is that what I have in mind will not use many math, but basic math. As for your suggestion, I don't know if it is better than using xefx. I don't know how to use UnitUserData though I believe Table may be a good solution as well.
To solve the arrow problem thing I don't know a solution yet, but I think using vectors is just complicating to much. There must be a solution ...

I decided to have a look on a projectile system made in the scripts section ... I was disappointed... the projectiles ignore trees and pathing ...

As for terrain ... how do I make my projectile follow the terrain Z ?

True z height equals to GetLocationZ in dummys position + dummys fly height.

UnitUserData is simple, just check those 2 native functions from functions list. They are used to set/get integers to/from some unit. ( integers, for example your projectile struct instances )

You will never solve the arrow-through-paper problem using "basic math", as you must do collision detection via complex math. (You must get the closest unit which will intersect the path of the projectile within the current frame. Unless of course projectiles have volume, in which case things are even more complex.)

Also, learn and use vector math. Vector math is actually really nice and simple, because the application of it is so simple that the complex theory behind it can somewhat be ignored. You'll never simulate a decent amount of projectiles with any kind of sanity using pure trigonometry.