[Released] Missile Behaviours

Store Link
Demo

Update 1.3 out now!

Spoiler: Changelog

- Added new action script, which creates random movement for a missile.
- Added new demo scene to showcase that behaviour.

Update 1.2.1 (hotfix) out now!
Note: The fuel feature in 1.2 is currently broken. Until the hotifx is online please refer to this post for a fix.

Update 1.2 out now!

Spoiler: Changelog

- Now compatible with Unity 4.6 & 5.0
- Reworked lots of things:
- Every class now has tooltips.
- Completely redone demo scene.
- Every action script is now also a trigger.
- Redone ReadMe.
- The Explode action script now has a variable to introduce a delay to the destruction of the gameobject.
- Added more comments to some scripts.
- Added the new SpawnSwarm action script.
- When triggered this script will spawn a number of prefabs around the missile in a radial pattern.
- Added five new prefabs which all use the new SpawnSwarm script to show you how it works.

Update 1.1 out now!

Spoiler: Changelog

- Added fuel feature
- Added the new SearchForNewTarget action script.
- This script is a trigger and an action at the same time.
- When triggered it will search for a new target within a certain range.
- If it can not find a target it will fire an event itself, which you can use the same way as any other trigger script.

Missile Behaviours is a little package that does what the name implies. Currently its main focus is the guidance of missiles, but it already includes some other goodies. The current features include:

- Proportional Navigation based guidance, which creates an intercept course which allows it to hit even dodging targets with ease. It includes the normal algorithm and the augmented version.

- A second guidance script which uses the more common approach of simply rotating the missile towards a target. Since this approach has a fairly bad hit rate for moving (let alone dodging) targets the script also comes with an option for an expertimental improvement to this approach.

- The scripts are build in a modular way which allows you to swap out any part with your own implementation if you wish to do so. This is however a little experimental and will be improved with growing feedback.

- Additionally this package comes with an event based trigger & action system. A 'trigger' is any script which waits for a certain condition and fires an event once that condition is met. An action script can then pickup any number of these events and react to it. This allows you to, for example, trigger an explosion when the missle collides with the target, comes too close to something or loses its target. Among plenty of other things.

The goal of this package is to provide you with everything you'd ever need for your missile based destruction fantasies. My hope is that the feedback of you guys will give me plenty of new features to add over time.

Finally, some eye candy (if you want to call it that) from the current demo scenes.
http://gfycat.com/VerifiableSingleKitfox (V.1.3)
http://gfycat.com/OilyWeeHeron (V.1.2)
http://gfycat.com/DemandingBetterGiantschnauzer (V.1.0)
http://gfycat.com/UnsungPresentEasteuropeanshepherd (V.1.0)

http://i.imgur.com/nys5Kv5.png
http://i.imgur.com/qF2qRzp.png

So please, feel free to already throw any ideas my way which I can add to my todo-list or just wait for it to hit the store to see it for yourself

 

Looks legit! Needed something like this about a year ago and mocked up my own Proportional Navigation. Wish I had a better solution back then. Might be picking this up, looks great!

 

Glad you like it

 

Bookmarked. Thanks.

 

Package is now released in the store, you can find it here.

 

Could this work in 4.6?
I would love to see a little more noise on the missile travel path. Puffy smoke. An store product had some short of crazines value in a missile demo that looked very nicely.

 

I'm currently working on the first update. I'll make sure to include a version for 4.6.

What exactly do you mean by "more noise"? Make it wobble more perhaps?

 

Yes, wobble was the word.

for propper testing please build an exe and upload to mega.

 

Unfortunately converting it to 4.6 is a lot harder than expected, because basically everything breaks. However it's mostly limited to the demo scene, the scripts itself should work. But before I can upload a package for 4.6 I'll have a lot of fixing to do so that'll take a while.

As for the wobble, I'll see what I can do. Might be a lot trickier than it sounds but I'm sure it can be done, I'll look into it.
I'll also look into uploading a demo once all this version shenanigans are worked out.

Sorry for the delay, I didn't expect so many things to break with 4.6.

 

Ok no problem then. May be I'm the only potential customer working on 4.6 so unless there is a public don´t focus too much on it if it takes so much time. But htanks for trying.

 

There might actually be quite a few people still on 4.6. Guess we'll find out when the new statistics come out. 5.0 did change a lot of things from shaders to code. And I believe the missing shaders are what's breaking everything. Maybe there is a way to import 5.0 shaders into 4.6 so that stuff doesn't break. Then it might be far easier to maintain both versions. If however everything breaks again with each update then maintaining both versions might become too much. I don't know. Again, I'll look into it but I can't promise anything since I'm not 100% certain on what's actually broken and what isn't yet.

I'd be very interested to hear from other people if maintaining a package for 4.6 or even lower is a good idea or not. Because as far as I'm aware even the Unity guys themselves are moving away from versions <5, no? And one can certainly see their reasons for that.

 

Version 1.1 uploading right now.

- Added a basic, optional fuel system. Once the fuel runs out, the missile will no longer accelerate.
- Added a new action script which will search for a new target when triggered. It will also fire an event itself, if it can't find a new target. This can, for example, be used to self destruct if there are no more targets in range.
- Improved some minor things.

Now, as for 4.6 support. If everything goes well this will be in the next version. Even though everything breaks when importing from 5.2 to 4.6, it's possible that this doesn't happen when importing from 4.6 to 5.2 (other than some code errors). If this theory turns out to be correct I'll redo the whole demo scene in 4.6 and work with that in the future. Again, I can't promise anything but this seems to be the most promising approach right now.

 

Version 1.1 now live.

Still working on the whole 4.6 thing. It's probably going to take a little longer still. Since I have to remake the whole thing for 4.6 anyway, I decided to tighten up the whole package a bit. Essentially I'll go over every single script again and tie up some loose ends. Additionally version 1.2 will contain at least one new script, possibly more if some cool new ideas find their way into my brain

 

Version 1.2 now pending review.

- The asset now comes in 3 different packages in these versions: 4.6, 5.0, 5.2.
- Reworked demo scene.
- Fixed several minor issues.
- Cleaned up a lot of code.
- Added tooltips to pretty much everything.
- Added 8 new missile prefabs, 5 of which are launchable and 3 of which are spawned another way.
- Added a new swarm launcher script which those 5 new prefabs use.
- Reworked the trigger & action system a bit. Now every action also fires an event once its condition is met.
- Removed some unnessecary ressources & scripts.
- Reduced filesize to nearly 10% of the orignal size. Though to be honest I have no idea why the first version were so huge in the first place

And now I present to you, the pinacle of missile based destruction:

The Swarm!

 

Nice! Cant wait to test the player

 

Finally figured out how to get a demo up on dropbox (I hope...).

You can now play the demo scene in your browser, here. (Hopefully...)
This demo is from the new version (1.2) which should be going live in a few days, given how long it has been in review already.

Unfortunately while working on that I discovered two fairly annoying bugs in version 1.2. I'll post how to fix them here as soon as that version is up. Since there seems to be no way to upload a hotfix I'm afraid the official bug fix will take another few weeks to get through review. Sorry about that :/

 

Does the missile just explode as soon as it launches in v1.2, any chance of a fix?

 

Since you said v1.2 I assume you are talking about the demo? In that scene most missiles are setup in such a way that they explode if they can not find a target. That's the most likely explanation, because targets just spawn every few seconds. So either wait a few seconds before you spawn one, or spawn a target manually by pressing the return key.

 

yes sorry, forgot to mention the demo.. got sidetracked. Im using Unity 5.2.0f3, there are targets, the missiles just explode before they take off. All I can think of is that it doesnt work with 5.2.0f3

 

Well... that's odd. I just imported the package from the store to make sure I have exactly the same version as you do. Turns out that's a backup version... must've somehow uploaded the wrong version. My bad :/

The good news is, it's the most recent backup so hopefully there aren't any other hidden bugs flying around.
To fix this open the SpawnEnemiesAndMissiles.cs and remove the lines 56-60. Which are conveniently tagged with "TODO: Remove." being a test version and all. That reminds me, I also found out that there is still another scene in that package called "TestScene" which you can safely remove.

Sorry again, no idea how or why it uploaded that version. Must've opened the wrong project or something :/

Edit: It's actually kinda weird that that version even got through review, now that I think about it :x

 

no worries, thought I was having an off day Thanks for sorting it out.. worth uploading a new version even if you make some changes. Is there an option to launch a missile up into the sky for a set height before changing the trajectory/rotation of the missile before heading for the target?

 

No there isn't currently. However the guidance scripts have an option to delay the guidance for a certain amount of time. You can't directly set a height with it but if you really need to you could just meassure how long a missile takes to reach that height and use that as a delay.

 

thanks, sounds good.

 

Awesome pack, modified it to my needs but has saved me lots of time and money Keep up the good work.

 

Glad you like it
Of course everyone has to modify it a bit in the end, there is no way to make it 100% generic. Though I think the system it currently uses allows for a broad range of uses. At least I hope so.


Also, I finally found the time to make this overdue post. Version 1.2 is now online.
As I already mentioned a few days ago, there are unfortunately some bugs in that version which I missed. A hotfix is already pending review, but by the time that's through it's not so hot anymore...

In the meantime, here is how to fix them:

1. Open MissileController.cs and locate the 'IsAccelerating' property, which is line 202-211.

2. Replace the whole property with this code:

Spoiler: Code

Code (CSharp):

1.         public bool IsAccelerating
2.         {
3.             get
4.             {
5.                 // If the throttle is zero or the delay isn't over yet the missile will not accelerate.
6.                 if (throttle != 0 && elapsedTime > delay)
7.                 {
8.                     // Find out wether or not the missile uses the fuel feature.
9.                     if (FuelConsumption > 0)
10.                     {
11.                         // If the missiles uses the fuel feature we still need to make sure that it has fuel
12.                         if (fuelRemaining > 0)
13.                             return true;
14.                         else
15.                             return false;
16.                     }
17.                     else
18.                         return true;
19.                 }
20.                 else
21.                     return false;
22.             }
23.         }

If you are wondering why that code looks so funny, it's because it's just a quick fix. I'm sure there is a way to make it look less chaotic

3. Locate the fuel check in the same file, which is line 274-281.
4. Replace the whole if statement with this code:

Spoiler: Code

Code (CSharp):

1.             if (fuelConsumption > 0)
2.             {
3.                 if (fuelRemaining > 0)
4.                 {
5.                     rb.AddForce(transform.forward * force * throttle, ForceMode.Acceleration);
6.                     fuelRemaining -= fuelConsumption * throttle * Time.fixedDeltaTime;
7.                 }
8.             }

And that's it. The property is not too important, it currently only affects the smoke trails in the demo scene. However the fuel check breaks the fuel feature completely, so you should probably replace that. Or just wait for the update to hit the store, if you don't use the fuel feature.

Lastly, when you are importing the new version the demo scene will not work exactly like the demo does. All swarm missiles will behave weirdly, because missiles collide with other missiles by default. All missile prefabs are on their own layer, which is linked to User Layer 8. In an empty scene this layer will still exist, but will not have a name. In order to turn off collision between missiles you'll have to give it a name. Then you can go to the physics option and turn of the collision between missiles. Then the demo scene should work just like the demo. Unfortunately I'm not aware of any good way to avoid this problem.

 

Great, thanks for the update. I added in a specific target on each silo, so its destination will be predefined or set dynamically, rather than use the random script, in my game the missiles are more ballistic, so I modified it for those needs. Works great though.

 

@Trigal, Does your script apply proper physics forces to a rigidbody, or is it kinematic only?

 

look nice, what about the performance? can i trigger 1000 missile without impacting too much the fps? are you planning to make more different type of missile behavior, i was thinking about be able to expose the speed ,randomization, angle, time of destruction, doing some crazy zigzag before starting to find his target etc.

 

Yea, those script are just meant for the demo. You'll usually want to hit a specific target, not what ever target you can find. So it makes sense to customize that. I'm always trying to make it as generic as possible. But at some point you just have to accept that you can't make it plug and play for every possible situation. Oh, while we are at that, the missile controller script in the new version also has a target property now. So you can set it in the inspector or just watch what target is selected there.

Yes it uses regular rigidbodies. That's to say it uses forces to accelerate but the rotation is done manually. In that way, it doesn't work like in real life. It just simulates the needed rotation, it doesn't use some sort of aerodynamic simulation or anything crazy like that.

I haven't spent all that much time optimizing yet and I have not done any performance tests. However the algorithm only uses basic operations, that is multiplication, addition and substraction. Not even divisions, which are slightly more expensive. Therefor it should be possible to have a lot of missiles at the same time. You are more likely to run into performance issues from other sources, which are not directly related to my scripts. For example, monobehaviours have a certain amount of overhead themselves so any 1000 monobehaviours will have an impact on performance. Also, I'm currently not pooling the missiles because it's hard to do that in a good and generic way. In short, the scripts themselves are not particularly expensive, it's likely that any performance loss will come from your usual Unity related sources. Like having 1000 models in the scene for example.

As for more behaviours, the package is build with an event system. You can have an action script, which does something, like explode or search for a target. Then you can have any number of trigger scripts which wait for a certain condition to be met and can then trigger those action scripts. This way you can control all sorts of things about the missile without the need to change the main scripts. For example, if you want the missile to explode after a certain amount of time or once it looses its target, you simply attach the relevant trigger scripts to the missile and link them to the action that should happen, in this case the explode action. This is how all the prefabs in the demo are done. They all use a maximum of 3 action scripts, but a bunch of trigger scripts to give them their unique behaviour.

For the other things you mentioned. Speed is simply a function of the missiles force and its drag. The missile controller script has a property which will tell you what the maximum speed of the missile is (approximately). Randomazation has been mentioned a few times now, but I'm still not entirely sure what you guys mean by that exactly. It would be nice if you could explain that a little further. Same for 'angle', I'm not sure what you mean by that. And I think the zigzag thing you described might be closely related to randomization, so I'd imagine once that is done a zigzag course would work by default

 

@Trigal - It would be great if this could work in a multiplayer environment. Any plans of adding support for this?

 

Oh boy. I don't know, wouldn't even know where to begin
Though I'm not entirely sure why it wouldn't work right now? Haven't really worked much with multiplayer yet, so I might be missing something, but can't you just synchronize the transforms and be done with it?

 

yeah, it may work no problem with photon, generally its the physics side that is a problem.. delay, lag and such like. I'm no way ready for multiplayer yet, still working on single player, but then the fun begins on trying to make it all work multiplayer.

 

As I said, I'm afraid I can't really help you there. I'm also not really clear on what I could add to the package that would make it more multiplayer friendly. But let me know what that could be, once you figured it out

 

I dont see why this could not be multiplayered. You've two options. sync the missile transform and smooth it by lerping plus some prediciton based on speed etc or spawn the missile in every client via RPC with the same target for all clients. I would go for second.

 

Good news, the Unity team was pretty quick this time. The hotfix (v1.2.1) is out already

 

wow that s a pretty damn good explanation , anyway i own that asset and i m already quite happy with it, it s really neat and fit my need , i mean by different behavior something similar to an asset i already own that i find quite nice in term of visual like the pic above

some random rotations befor getting to the target


and zigzag like a random sharp angle befor going to target.
thanks for the asset really usefull for me.

 

I'm always a litte concerned about features like that to be honest. Because, yea okay it looks cool, but it'll either be extra unnecessary computation if you don't want it and at least one more variable if you do. It doesn't look like much, but even that one boolean adds up when you create lots of missiles. And of course the inspector window gets a little cramped. Which, as you may have noticed, is a problem I'm already struggling with because the action & trigger system uses so many different scripts. Which is also the reason why I think a solution that involves yet another script is a little annoying.

However, since this random zizag thing has been talked about a few times now, I'll add it. Can't promise when though, don't have a solid idea on how to do it yet and I'm more busy than usual recently.

And by the way, I still don't have a much better understanding of how it works in that other asset
Turns out a picture doesn't really capture 3D movement all that well

 

Thanks to toto2003 Missile Behaviours will soon get a new action script: Dispersion.
This script, when attached to a missile, will rotate said missile on its forward axis, by a random amount.
Once that's done it will rotate the missile by a random amount each frame on its up axis to create the illusion of random movement. This should, in theory, also allow the little zigzag movements that people asked for. That is, if the scripts runs while a guidance script is also running. However you can also use this script first and activate the guidance later, which will look something like this. (Sorry for the lowish quality, somehow my OBS has reset its settings -_-)

I've also made a new quick demo scene to showcase the whole thing. It's not all that pretty, but it should be enough to give you an idea of how it works. The package with the version number 1.3 will be uploaded later today, once all the polishing is done. As usual it should arrive in about 1-2 weeks, depending on how busy the asset store team is.

Edit: Version 1.3 now pending review.

 

Version 1.3 is now available.

 

hello trigal,
i got a question about the missile demo02, is it possible to have multiple targets in the scene without having all the spawning missiles going to one specific target ?
cheers

 

Sure it's possible, it just wasn't made with that in mind. It's just a quick demo to show off the new 'spreading' behaviour.

You could simply change the FireDreadnought script to allow multiple targets like so:

Code (CSharp):

1. public class FireDreadnought : MonoBehaviour
2. {
3.     public GameObject missilePrefab;
4.     public List<Transform> silos;
5.     public List<Transform> targets;
6.  
7.     void Update ()
8.     {
9.         if (Input.GetKeyDown(KeyCode.Space))
10.         {
11.             foreach (var item in silos)
12.             {
13.                 GameObject missile = Instantiate(missilePrefab, item.transform.position, item.transform.rotation) as GameObject;
14.                 Transform target = targets[Random.Range(0, targets.Count - 1)];
15.                 missile.GetComponent<MissileController>().Target = target;
16.             }
17.         }
18.     }
19. }

Then just add some targets via the inspector and you are good to go. Of course that's still only a demo script, in an actual game you'd probably want something more advanced than that.

 

awesome , work like a charm, i think for for a future update it will be more handy to have an automatic target like the tail chase missile so i would just need to put all my target on a specific layer instead of drag and dropping them into the inspector .thanks for the support.

 

Well, what's stopping you? You can change the dreadnaught missile to work the same way. Or you could have the dreadnought fire any other prefab, including one that'll search for its own target. Just make sure to disable these lines in the FireDreadnought script:

Code (CSharp):

1.                 Transform target = targets[Random.Range(0, targets.Count - 1)];
2.                 missile.GetComponent<MissileController>().Target = target;

That way it will just spawn the missiles and nothing else, they'll then be able to look for their own targets.

 

has this had any performance tests on mobile as i am interested in using this if it is optimized for android

 

This is mostly CPU calculations and mobile devices usually have plenty of CPU power. When doing anything on mobile its most often the graphics that slow things down, mostly by having too many draw calls. So eventhough I haven't specifically tested it on mobile, I don't see why you couldn't have a few dozen to hundreds of missiles in a scene. The most expensive thing on mobile will be the actual rendering of the missiles, their behaviours aren't that expensive to compute. But I won't lie, the proportional navigation algorithm certainly is a lot more expensive to compute than a simple LookAt function. However, modern CPUs are pretty damn strong so I wouldn't worry too much about it, even on mobile.

As long as you keep an eye on instantiation cost and your draw calls you should be fine.

If you still aren't sure just tell me a bit about what kind of usage scenario you are looking for (that is how many missiles and how fast you'd want to spawn them) and I could test it on a fairly old phone tomorrow. But again, I don't see any real problems with it.

 

can the missile prefabs be pooled instead of instantiating them when needed? as this would save cpu on mobile, i would probably need max 25 - 30 missiles at a time, can you test the demo on your mobile device and give us a report on how it runs with basic missile and the proportional nav algorithm say launching 25 missiles

 

You can certainly pool them since there is no fixed way of spawning them. There are a few demo scripts that spawn the missiles for you which simply instanciate them, without pooling. That's by design though. I thought about all sorts of ways to implement a "one fits all" type of script for spawning but in the end I decided that would just end in chaos. After all, instantiating something isn't all that hard and pooling might not even be necessary if you don't need a hundred missiles or something. But if you already have some sort of generic pooling system in place I don't see why it would be a problem to throw the missiles in there, they aren't really special objects in any way.

As for testing it, I just started up Unity (5.3.1f1) and got some really strange errors I've never seen before (something like "IsFinite(outDistanceForSort"), what ever that means). Never tested it in this version though. In other words, I will have to figure out what that's about before I can actually build it. I'll report back once I've figured out what's going on.

Edit: Looks like it's not a problem with any of the scripts. It's the exhaust particle system of all things. Literally no idea what's going on with it though. However, simply deleting the exhaust child seems to solve the problem.

Edit2: Turns out I'm an idiot an didn't save the java sdk and the android sdk. So... downloading those now, sorry for the delay.

 

Did you know Unity 5.3.1f1 has bugs related to particle effects? At least some of it is supposed to be fixed in the p1 patch, so you can try that if you wish.

 

Well, I do know now
It's not really surprising me though, for every single one of the cool new things in Unity 5 there are about a dozen broken things. Though it's good to hear that it's being patched. It's also good to hear that my package isn't broken after all

Edit: Okay, I have tested the Dreadnought scene on a Galaxy S3 mini, which is not exactly the most powerful phone out there. In the scene I spawned 26 Pro-Nav missiles every second with a life time of 10 seconds. So there are at most 260 missiles in the scene at any time.

Keep in mind that I didn't do any kind of optimization, be it draw call reduction, pooling or anything else. I just modified the desktop scene a tiny bit so the missiles would auto-spawn. That's all I did.

When looking directly at those up to 260 missiles the fps wasn't great. About 10-20 fps. However, when I looked away it ran perfectly fine. So as expected it's not all that heavy on the CPU but the phones graphics isn't happy about it. However, I did have the trail renderers still enabled, so that might have been a bad idea...

In short, even 260 missiles with 26 missiles spawning at a single frame, without pooling or any optimization, was no problem even for that old CPU. It only began running badly when the graphics mattered. And I really have no control over that anyway, that'll come down to your models and materials. You'll probably not be so reckless and use 3 different materials for the missiles after all. Or as many vertices as my primitive only approach does

 

thanks for testing on mobile, sounds like it is running decent on mobile, at mo i am using 5.1.2f1 so will have no errors, will be purchasing

thanks