Strategy Pattern - Composition over Inheritance

The strategy pattern is a subtle pattern. It’s all about minimizing the duplication of code and decoupling classes. As an added bonus, the strategy pattern can also allow behaviors or algorithms to swapped at runtime without any messy switch statements or long chains of if statements. In the end it doesn’t have a super flashy or exciting outcome. It’s just good coding practice.

With some aspects of the pattern it’s easy to think, “Yeah, but this other way works…” But! The pattern is solid and avoids lots of little issues that can pop up later down the road when your project gets bigger.

Before we jump into the pattern lets first look at the problem it solves.

Inheritance Is Not Always Awesome

Let’s imagine you’re making a game based around weapons, or at least has a lot of them in your game. It would seem reasonable to create a “Weapon Base” class that other weapons can inherit from. This base class can contain basic stats and functions that can be used or overridden by sub-classes.

For example, we may have a DoDamage function that gets called every time a weapon is used. The function might simply reduce the health of the player’s target.

This is all reasonable.

Going a step further, let's imagine that we want to create 3 fire-based weapons that will all inherit from the WeaponBase and on top of reducing the targets health will also do some actions specifically for fire damage.

I now have 3 new classes that all have duplicated code. The DoDamage function has the same code from the base class, plus fire damage specific parts.  Updating the fire behavior means opening and changing the code in all the every fire weapon class in your project. This isn’t horrible with 3 weapons, but imagine having 20 or 50 or 100 weapons. Yeah, that’s not going to work.

I could also call base.DoDamage, but then all my weapons would be dependent on the base class DoDamage function, which is definitely NOT AWESOME.  If the base class function changes, all the inheriting classes change too and that’s not good. That’s not a solid foundation to build on. That’s a way to break your game in a hurry. This coupling between classes is what we want to reduce!

Now you might now argue that you could create a “Fire Weapon” class that inherits from the weapon base class and that all fire weapons inherit from… Which may work, but it is starting to get messy. Imagine now that you want to add ice or poision damage? You’d have to create Ice Weapon and Poison Weapon classes that those new weapons have to inherit from.

Okay, push comes to shove this might still be okay… Ugly, but okay, if the project stays small.

What if you now have a weapon that will do both fire and poison damage? Which class does it inherit from? Fire or Poison? Or do you make a combo class to inherit from? NO! Please don’t.

The strategy pattern can help solve these problems…

Strategy Pattern

The strategy pattern is all about encapsulating or wrapping up a behavior or algorithm in it’s own class. It’s also very closely related to the concept or belief that composition is better than inheritance! The exact details of how we do this are less important than the overall pattern so let’s start with a simple and common way to implement this pattern.

First, we create an interface called “IDoDamage” (you can argue all you want about using “I” to name an interface - I don’t care). This interface will have one function called “DoDamage.”

At this point, you might be thinking, “Okay, we’ll just implement the interface in all our weapons.” And that would be understandable, but it would be a mistake to do that as that would cause lots of duplicate code and not really buy us much in return from just good old inheritance.

Instead, we are going to create an instance variable of this interface in the Weapon_Base class. This class will also have a function that calls the DoDamage function on the IDoDamage variable.

Why? Good question. This is the crux of the whole pattern.

We can create classes that implement the IDoDamage interface. Each of these classes will have a different damage behavior. This will encapsulate the damage behavior AND make it so that we can change behavior at runtime by a simple assignment - no ugly switch statement or crazy chain of if statements needed.

For example, we can create a “FireDamage” class. This can do all the basic damage bits and most importantly it can then do any fire specific bits - maybe there are events that play sound effects or trigger specific lighting effects.

Then!

We create a new class for each weapon that inherits from Weapon_Base. Rather than hiding variables or overriding functions we use a constructor to set basic variable values AND to set the damageType variable.

While we now have a poop ton of classes, which could be a criticism of the pattern, we have very little duplicated code, and if we need to change the fire damage behavior, it only needs to be changed in one place in our project.

There is a neatness, a tidiness, a cleanliness that just feels good with this implementation. All we are doing is using a constructor to set up the weapon. The entirety of the damage algorithm or behavior is fully encapsulated in another class. While we are still using inheritance, we have decoupled much of our code, and much of the messiness of inheritance isn’t present in our solution.

Adding More Behaviors

The strategy pattern also works if you want to create other types of damage, such as IceDamage. To implement this style of attack, we need to create new IceDamage and IceSword classes.

Going Abstract

You could go either further and create generic weapons that have their damage and damage type set by a constructor. This could allow generic classes for each weapon type with all the data PLUS the behaviors injected into it.

Changing Behaviors

And I think the real cherry on top is that with the strategy pattern is that it allows easy changing of behaviors at runtime. Sure, you could do that with some if or switch statements. But those tend to be ugly. They break. They’re generally a brittle approach to programming and we can do better.

We can add a function to Weapon_Base to allow the damageType variable to be set. This would have the effect of changing behaviors. Something the code on the right.

Yes, I realize I made the variables public, but I don’t like changing values in classes from outside the class without using a function. If this was my project, I’d probably use private variables or maybe a public getter. 

With this functionality, a click of a button or the invoking of an event can change the weapon's damage type and thus much of it’s behavior.

If that’s not useful. I’m not sure what is.

Combining Behaviors

What if you really want that fire poison sword? Maybe your game is based around combining behaviors or abilities? Then what?

Make a list of IDoDamage values. The code can then iterate through the list and called DoDamage on each item in the list?

I’ll be honest I haven’t tried this but it seems solid and pretty useful.

Other Thoughts

The choice to use an interface in the strategy pattern is not the only choice. You may want to use an abstract class instead so that you can define variables. Personally I like the cleanliness of the interface and then simply injecting any needed data.

I also thought to use scriptable objects. And while I think that would work, I think it’s stretching SOs to a place they don’t fit particularly well. Writing the classes and then creating assets seemed like too many steps and I was struggling to find a situation where that would truly be better. But maybe I’m wrong?

I also wrestled with making the base class a MonoBehaviour or not. For simplicity I kept it as a MonoBehaviour so I could easily attach it to a button (for the video). I think that choice really depends on the use, but my gut say most the time I’d want it to NOT be a MonoBehaviour.

The State Pattern

Whoa. It’s been nearly a year since I’ve made a post. I’ve been busy. A lot has happened, but that’s a topic for another post.

So I’m going to try something new, well a few things. But the first thing I’m going to try is writing a blog post for my next video. I figure taking the time to explain the video in writing will help me cement the ideas and provide one more resource for you all. There are many people who’d prefer to read than to watch a video. So maybe it’s a win-win? We’ll see.

But enough of that. Let’s get onto the second new thing.

That’s is exploring programming patterns. It’s something I’ve wanted to do because I want to learn more about programming patterns. Plus Bolt 2 will eventually (!!) get released and when it does many of the basic programming patterns will be far easier to implement AND folks developing with Bolt can benefit from implementing them.

Since Bolt 2 is now fully in hiding under the protection of Unity (who knows when the alpha will make it out to the public again) the upcoming video will be entirely C# based.

I should also give credit where it’s due. I’m no genius - that should be clear if you’ve read more than a few paragraphs of my writing. Much of what I know or think I know about programming patters comes from the book “Game Programming Patterns” by Robert Nystrom. It’s well worth a look if you are unfamiliar with the topic of programming patterns..

The State Pattern

“Allow an object to alter its behavior when its internal state changes. The object will appear to change its state.”

Like any other pattern the State pattern has its limitations, but also like any other pattern when used correctly it can help to detangle code which can make debugging code or adding features easier and much less frustrating. And that’s a win no matter how you look at it.

You may have heard the term “Finite State Machine” or “FSM” thrown around. Both of these terms refer to the same thing which is an implementation of the state pattern. The Unity asset Playmaker is based on the uses of FSMs and Bolt has the ability to create them with “State Macros.”

To help illustrate the state pattern, I’ve created a simple Unity project. There is a NPC played by a capsule and it’s goal is to wander around the maze and collect the yellow cubes. When it sees a red sphere (critter) it will chase it and attack it. Nothing too fancy.

So with that in mind, how would you program this behavior? Take a minute and think it through. No cheating!

Just about ready to go up on steam! ;)

This actually doesn’t look too bade with the use of functions… but will get out of control in a hurry.

I know when I first got started with C# and Unity, I would have done it with an if statement or two (or seven). And that works. It really does. Until you need to add another behavior. Or another game mechanic gets layered in. And we all know it won’t end there. The layers will continue to get added until the code breaks, bugs appear or the project gets forgotten because it was getting too hard to work with.

Simple FSM = Enum + Switch

So let’s look at the simple FSM. I still remember learning about this and was utterly confused by how to implement it but at the same time amazed at what it did to my code once I finally got it working. At that time I hadn’t really learned to use functions well so I had 100’s of lines in my update function. Needless to say it was nearly impossible to debug and when I discovered FSMs it was a major break through!

Simple FSM using an ENum and a Switch

In the case I described above the NPC behavior can be broken down into 3 different states or 3 different smaller behaviors. I thought of these as wander, collect and attack. A custom enum can then be created with these three values.

With the enum created a switch statement can be placed in the update function. For each case we can call the relevant function for that behavior. But we still need a way to change or switch (get it!) the state. For the most part this can still be done with basic if statements.

And now this may sound like we’ve back pedaled to our original solution and just made things more complex.

But!

There is a major advantage here!

When we started, inside the update function we had to have a way to determine which state we were in - picking from ALL the possible states. Imagine how complicated that would be if there were 5, 6 or maybe even 10 different states. Yuck! Nothing clean about that.

With this method we only have to decide IF we need to change states GIVEN that we are already in a particular state. This greatly simplifies the decision making albeit at the cost of a few extra lines of code.

In a FSM it’s common that a given state can only transition to a limited number of other states. For example in my case maybe I don’t want the NPC to stop collecting if it sees a red sphere and it should only attack a sphere if it’s wandering around with no cubes in sight. If that’s the case the “state pattern” may actually reduce the amount of code needed as well as serving to untangle the code.

This implementation of the state pattern can be used for all kinds of different behaviors. It could be used to control animations, background music, or which UI elements are being displayed. 

As an aside, in my personal project, I use a vaguely similar approach that makes use of a static enum and events for game modes so that various managers and UI elements can act or react based on the state of the game. The clarity of being in exactly one state has greatly simplified my code and made it far less error prone.

So this is all well and good, but you may be able to see the end result of this approach is still messy if the number of states starts to get large.

A Step Further => More Abstract + More Manageable

Having all the states switching inside the Update function can quickly get unmanagable and if nothing else is pretty hard to look at.

So let’s go one step further. This step adds another layer or two of abstraction to the system, still has some downsides but does clean up our code and will make larger FSMs easier to manage.

This step will place each state in its own (mostly) self contained class. The state will be in control of itself and will determine when to make a transition as well as determine which state to transition to.

Step 1 is to create a new interface. In my case I’ll call the interface INPCState. The interface will have just one function that will take in all the NPC data and will return a value of the type INPCState. This returned state will be the state for the next frame as the “Do Action” function will be called by the base class of the NPC which in turn will run the behavior for a given state.

The Wander State with all the functions included

Step 2 is to create a new class for each state of the FSM and that state needs to implement the interface INPCState. Each of these classes should also contain any functions or logic needed for that state. In my case I have choosen to leave all the variables on the NPC base class. This keeps each state class tidy, but does mean that the state class will be changing values on the NPC base class which is usually something I like to avoid - you win some and you lose some.

Inside each state’s “Do Action” function we need to call the relevant functions AND we need to decide which state to use for the next frame. You can see the full code to the left, but for now let’s jump back to the NPC base class which will help make sense of the return values.

Step 3 is to refactor the NPC base class. Here we need a new variable of the type INPCState that will hold a reference to the current state. We also need instances of each state - it would be possible to make this work with static classes and using an abstract class rather than an interface, but if you know what that means you can probably implement it yourself.

The simplified NPC Base Class

In the OnEnable function I’ve set the current state to the wander state to ensure that the current state variable is never null.

Then the real magic happens in the Update function. Here we have just one line! So awesome. Here we call the “do action” function on the current state and then set the current state to the value returned from that state.

That makes total sense, I swear it does, but it’s abstract.

Give a mintue to let it sink in.

This is so clean.

Step 4 is to add conditionals to the state classes to determine which state to be in for the next frame. Notice that we have passed in a reference to the NPC base class into the “Do Action” function and from there we can get a reference to the instances of the state classes.

Pro’s

The base class is exceptionally clean. You can now see how the class appears to change it’s state (behavior). Effectively the entire Update function changes depending on the current state and what in that state’s “Do Action” function. That’s cool.

If we want to add an additional state we simply create a new class, add an instance to the NPC base class and finally add conditions to allow a transition to the new state from other states.

As long as the number of states stays fairly small 5 or maybe 10 this is a pretty manageable solution.

Con’s

It’s hard to maintain if the system truly gets complex. In this case most sophicated structures such as behavior trees might be needed.

All the variables in the NPC base class are public. Which is a bit messy and not super awesome. This could be partially solved by creating a data container that itself is private in the NPC base class but has public variables… This passes the buck a bit, but would prevent those variable from being changed by classes without access to the data container. A generic data container would also potentially open the doors a bit wider for reuse of the states by other NPC types - so worth thinking about.

As mentioned before, the states are changing values of variables on the NPC base class. Not ideal and something I usually go out of my way to avoid if possible.

Easy UI Styles for Unity

So like many of us when in the middle of the project it’s easy to get distracted and start building tools that probably take longer to create than the time the saved by the tool. And what do you know, a few years back I created Easy UI Styles…

I was finding it hard to iterate on my UI designs. I’d change a color here and it would look better, but then I’d need to change it 7 other places and then it was a tad or dark. Or a tad to light. Oh and then I wanted the font a bit smaller.

Ugh.

So Easy UI Styles let me define a style in a custom editor and then apply it object by object in the scene.

A little while back I started switching my project from UGUI text to Text Mesh Pro (holy crap it looks better) and Easy UI Styles didn’t support it. So down the rabbit hole I went! Several hours later the asset now supports 99% of the setting for Easy UI Styles - seemly there are 2 settings that can’t be set by an external script.

While I was at it I created a new video for the asset as well as a cut down free version of the asset. You can get the “Lite” version on the asset store once it’s accepted or until then you can download it here. The full paid version is free for my Patrons (wink wink).

Programming Challenges

Without doubt and maybe not for the better my focus has shifted from working on my game every night to trying to edit a video. Work on the game continues just slower than before… My fledgling YouTube channel continues to grow albeit at a limited pace. I’ve seemly snatched the “Bolt” niche on YouTube for the time being, but that’s a limited population and is likely to stay that way.

It’s time for something new.

With one part “hey this is cool” and one part “maybe this will expand my audience” I’ve launched Programming Challenges that can be completed in any programming environment or language used in Unity. This is something that I did with my students this year to help get over the significant learning curve of Bolt - and by most accounts it really helped. So why not bring it to a larger audience? If nothing else maybe it’ll help me refine my the challenges for my students.

The goal is to give short programming challenges that can be done in an evening or certainly without a huge time commitment over a weekend. The target audience is beginner to intermediate programmers and likely folks who are picking up Unity as a hobby and want to learn more.

But isn’t that what game jams are for?

For sure! But a lot of us can’t devote huge hours to a game jam on any sort of regular basis. And for those at the beginning of their game development journey creating an entire game (even in a month) can be intimidating.

Now I’m quite sure that there will never be the “perfect” challenge. Some will find a challenge far too hard or so easy that it’s not worth the time to fire up Unity. All the same this seems like a niche that is unfilled on the greater interwebs and continues the larger goal of giving back to the community that I learned from.

With that said, this last weekend, I launched the first challenge. The challenge is to create a dynamic grid of objects. It’s not a game and its not intended to be, but the programming used to “solve” this challenge is something that could easily be used in a game.

I’d love to hear feedback on the idea or this particular challenge. If you’ve got a suggestion for a challenge I want to hear that too.

Resources: Processing, Consumption and Inventory

As a solo developer (of an admittedly over scoped game) relying on outside assets is a key to building a game "quickly" and efficiently. I'm not the type of person to subscribe to the idea that I need to build everything from scratch. I have no desire to build my own game engine, but I do understand why folks often prefer to roll their own solution.

I've become very skeptical of assets that run with the game. I have learned that editor tools are more reliable and don't come with performance downsides that many runtime assets do. I've tried using several assets that are overly bloated or have turned out to have poor performance. My snow shader and graphing tool came out of such experiences. It's a tricky to find the balance between using pre-made tools and rolling your own. There are pro's and con's both ways.

Game #2 will allow players to collect and use items - this will in fact be a key mechanic. This means that I need some kind of inventory solution. I did a little research on how to do the basics, but decided to also look at solutions on the Unity Asset Store. If nothing else the Asset Store can be a good source of ideas. 

As a Unity Plus subscriber I get discounts on a handful of assets. One of those assets is Inventory Pro. So I figured it was worth a look since I was shopping for a inventory solution and the reviews were nearly flawless. 

I watched the tutorials and did as much research as I could. While not "cheap" it's an asset that would take me several days if not weeks to reproduce even in the most basic of forms. Plus it has a level of polish that would take even more work on my part.  So why not give it a shot?

I made the purchase and spent some time playing around. My first impression was positive. It has a nice and easy to use editor. Out of the box it handles person inventory, vendors, looting, banks, a skill bar and two styles of crafting. It comes with a pretty decent default look too (but, I suspect almost any developer will want to modify it). What's not to like about it?

View fullsize

Inventory Pro Editor - Item Editor

Inventory Pro also plays nice with several other popular third party add-ons. This includes Playmaker for those who don't want to dink around in C#. 

It also has custom functions for Behavior Designer which is a major plus in my book as I intend to use Behavior Designer as my AI engine. 

If you are intending on building game with a fairly typical or standard use of inventory then Inventory Pro should be on your short list of assets to check out. However, if your design has some non-standard uses you should keep reading. 

The Other Side of the Coin

As I continued to explore and think more about the custom needs my game was going to have I was becoming discouraged. The code base is all open source, which is greatly appreciated, but it feels like a mess of inherited classes and prefabs. Ugh. The documentation is decent, but doesn't do a great job of describing how to truly customize the tools. The learning curve is moderately steep.

The odd blog post by the developer were very helpful and cut hours out of my work. The needed info is out there, but it can be a little hard to find. 

When trying to setup a scene you can't simply drag and drop UI prefabs in the scene. They don't easily slide into a scene because there are too many connections that need to be made. Too many prefabs that need to be dropped into the inspector or combination of components that are required. It's certainly possible, but it's not easy.  Adding the UI to a scene is best done by copying from a demo scene and then turning off the parts you don't need - a custom editor to add the parts you want and get them all connected correctly would be a major plus and make the product that much more user friendly. 

There is a cost to using someone else's code base... That shouldn't be a real surprise. I got frustrated enough with Inventory Pro that I spent a few hours working to roll my own custom inventory code. It was all going well until I began to write a custom editor to create content. I went running back to Inventory Pro and I'm very glad I did.

Custom Windows

View fullsize

I mentioned a chicken, so why not include a image of my chicken?

For Game #2 I need some custom windows for resource consumers and resource processors. A resource consumer could be something such as a steam engine from my previous post that may take in wood or coal and produce a more usable form of energy.  While resource processors may be something such as a windmill that will process corn into corn meal that can be used to feed your chickens, i.e. turn items into other items.

Each of these custom windows is easy enough to create from a purely UI perspective, but coding them took a bit more especially as I was to digging through someone else's code. 

A resource consumer is very similar to a vendor in that individual objects in a scene will have there own collection that is loaded into a common UI. The main differences being that the resource consumer needs to do something with the items even when the player is not currently using that object, i.e. a steam engine should continue to burn coal and produce energy when the player is busy elsewhere and I don't want to be selling coal to a steam engine...

View fullsize

A snippet of the some of the custom code - All in all there's several hundred lines in the new classes some is copied other bits are mine

Rather than inherit from the vendor classes, which would bring functionality I didn't want, I chose to essentially copy the vendor scripts (ItemCollection and Trigger) and modify the scripts once I had basic functionality working.  The result was a custom trigger script, custom UI window (damned ugly at the moment), a custom collection script that controls what is shown in the UI as well as a base class resource consumer that is designed to be extended for a variety of resource consumer objects (steam engine, chicken feeder, etc). 

View fullsize

I promise it won't be this ugly in a final build

The resource processor is a bit different. At its core resource processing is very similar to crafting. Items go in and products come out - all following a blueprint. Given that Inventory Pro has a built in crafting system it seemed worth the time to fight through the code to create a custom "crafting" window that would meet my design needs. 

The idea here is a that a player (or NPC) drops off some items to be processed and it gets turned into a different item that can later be collected. This means that the UI needs to have an input and a output collection/inventory. It's also required that each individual scene object has it's own input and output collections to that get loaded to the UI when the player interacts with the object. A final two requirements is that the resource processor continues to work when the UI is closed and that the products get assigned to the correct scene object when the processing is done so the product doesn't get lost and the player can collect it later.

View fullsize

A snippet of the Custom Trigger

This last requirement was the biggest hurdles and required about an hour of hunting through code to follow the flow of the information. Inventory Pro has a "craft info" class that contains all the basic information which gets passed through about 8 different methods before an new inventory object is actually created.

I almost lost it at this point. Lots of deep breaths needed. 

To get it all working required an addition to the CraftInfo class to track what object had ordered the product to be created. This allows a finished product to look up where it was supposed to go and assign it to the appropriate collection. 

Custom Inventory Items

View fullsize

Default Item Types - Plus 3 of My own

While I found the process of adding custom windows and functionality challenging and frustrating, adding custom inventory item types was easy and almost fun. Out of the box Inventory Pro comes with several default item types, but anything beyond the typical RPG will likely require custom item types.

Different types have different properties (oh, shocking). These properties are not particularly well documented or at least I haven't found the documentation. Thankfully most are self explanatory. 

Game #2 is not the typical RPG with the collection, crafting or upgrading of gear playing a central role. Rather most inventory will have some use in creating something in the world. This might be a shovel that is used to prepare the ground to plant a crop or coal that will be used by a steam engine to power an industrial building. Inventory Pro's items all inherit from a parent class that calls a Use() function. This function can easily be overridden to perform any actions needed. The Use() function is called when the player uses the object. Which can be done from inside the inventory or from the skill bar.

View fullsize

A sample custom USE() function for a tool item type.

The Use() function returns an integer that indicates whether the object can be used.

In the case shown using the tool will call an outside public function that toggles a mode of the game (i.e. use a shovel and you can dig to plant seeds). 

The inventory item can also have public variables that will be displayed in the Inventory Pro editor. For example the Tool Type enum can be set for each inventory item of this type inside the editor which makes for easy and organized content creation. 

The ease of creating custom inventory items was a stark contrast to making custom windows and triggers. Why can't the rest be this easy?

The Final Verdict - Inventory Pro

Inventory Pro caused me a good amount frustration, plenty of swearing but also gave me a much more functional inventory system than I could have created on my own.

If you are looking to build a game with non-standard use of inventory and aren't comfortable with C# then you should probably look else where or be willing to hire a programmer to code up some custom solutions. 

But if you don't need custom functionality or if you are comfortable with C# and reading someone else's code then Inventory Pro can solve your inventory needs far quicker than you'll be able to roll your own solution. Mucking around with the custom windows wasn't particularly fun, but the end product was worth the time and money.

Click to Color

I was needing something simple to work on (the day job has turned my brain to mush) so I spent a few hours last week polishing a tool that I've used in the production of Fracture the Flag. The tool allows the creation and editing of color palettes within Unity.

Low poly scene and the 

Click To Color

interface

The use of color palettes along with flat shaded low poly assets allows a significant reduction in the number of materials being used in a scene or project. This can also reduce draw calls and improve performance.

Due to the flat shading models can be unwrapped and the UV's can be stacked. This allows the texture size to be very small - in theory as small as one pixel per color used in the project! This means that by using a 32 by 32 pixel texture a project can have up to 1024 colors contained in a 4 kb file! Ideal for mobile uses or simply keeping a desktop build size down to something reasonable.

Unwrapped model in Blender

The editing of these textures within Unity also allows the artist or developer to quickly adjust colors of models in a scene while lighting and image effects are shown in real time. This speeds up development time as there is less back and forth between Unity and a photo editing program.

Click To Color will be available on the Unity Asset Store:  https://www.assetstore.unity3d.com/#!/content/72930

All the features of Click to Color can be seen in the video below.

A potential work flow using Unity and Blender is shown in the second video.

Unity Object Swapper

A while back I found myself looking at a Unity scene with several hundred trees that each needed to be updated and the connection to the prefab had somehow broken... Rather than spent hours replacing each one I spent almost as much time writing an editor extension to do the same thing.

I'd forgotten about the tool, until a student of mine ended up in a similar position. Which made me revisit the tool a do just a bit of fine tuning.

Screenshot of the editor window

It's a pretty simple script, but handy all the same. If I find the time I might add it to the Unity Asset Store as a free asset. Until then, assuming this looks like useful, you can download it from this link (box). There's no documentation, but it should be pretty self explanatory- the search is case sensitive.