Game Design Tips #13 – [Unity] ScriptableObjects and Custom Project Gizmos

It’s been a while since my last Game Design Tip, but I’m back and ready to show off some cool things I started using very recently. Ever wanted to save data as an asset in Unity? Turns out, there’s a dead easy way to do that. I’d heard of ScriptableObjects before, but not used them; they’re a godsend for any task where you just care about keeping hold of static data for something – weapons, enemies, item drops, you name it.

I’ll take an example I was working on the other day. I have a load of guns that the player may own, each with their own cooldown rates, damage, clip size and whatnot. My strategy at the time would have been to create a MonoBehaviour script that holds a bunch of public variables, stick that script on a bunch of GameObjects and tweak their variables individually, then save them all as prefabs. Upon needing to read the data, I’d instantiate one of those objects (or have them all instantiated at level start), then read off all the variables. In doing so, I’d waste a bunch of memory loading up GameObjects whose sole purpose was to hold data, clogging up the RAM with redundant data and making the garbage collector mad.


That was dumb.

Instead, I should have used ScriptableObjects, something Unity provides for this exact purpose. Instead of extending MonoBehaviour, we’re first of all going to extend ScriptableObject. That’s going to tell Unity that this script is special, just like every one of my readers. That’s my flattery quota for the day met!


You’ll also notice we gave the entire class the [Serializable] attribute. This is provided by the System namespace (hence, that’s included on line 2) and tells Unity we’ll want it to do stuff to it to make it visible in the Inspector. In reality, it’s a lot more complex than that, but we don’t care for now, do we? We just want our data saved. Oh, and I’ve stuck this class in the WeaponClasses namespace for the hell of it, but you can ignore that if you so wish. In my example, WeaponType is just an enum to deduce which class the weapon falls under.

Now that we’ve gone about making our data serializable, we need a way to make these new Weapon objects. There’s probably many ways to do this, but I’ve used a bit of Editor scripting to get the job done. It might look a bit alien at first, but it’ll all start to come together soon.


This is a brand-new script which doesn’t extend Monobehaviour, ScriptableObject etc. It just needs to import UnityEngine and UnityEditor, and the script must be placed under Assets/Editor. We use the [MenuItem] attribute to add a lovely menu entry for making new weapons – now, we’ll be able to click ‘Assets’ on the toolbar, hover over ‘Create’ and find ‘Weapon’ listed underneath all the usual entries. Clicking this places a brand-spanking-new Weapon under the path defined in the script (line 14) and focuses Unity on the new Weapon in the Project Window (lines 16 and 17). Just a word of warning – it’ll replace anything called NewWeapon.asset in that directory, so I’d rename it straight away! Now you’ll have an awesome new Weapon instance you can reference in your scripts without having to attach it to some empty GameObject.


Not a typo, just a really fun thing for gunning people down.

I did a little more processing with mine using an additional, more complex Editor script to hide certain variables based on the type of weapon, but this is basically what you get when you click on one of your Weapon instances in the Project window. We’re done with ScriptableObjects now, but let’s go one step further and make a cool gizmo for our Weapons.

Weapon icon

This is the icon I’ll be using. It’s dead easy to tell Unity to use this for our Weapons; just save this under the exact name “Weapon icon.png” or “Weapon icon.tif” – only .png and .tif files are allowed. The syntax is [Class Name] [single space] [the word “icon”] [.png/.tif]. Super simple stuff!


Now we have pretty-looking icons for our Weapons and a clean way to save data for each Weapon. Unfortunately, it doesn’t make them look different in the Inspector, but at least they have an icon in the Project view that makes them easier to find. I hope this has been helpful, and I’ll be back soon with more tips.