The importance of spending less time doing boring things

Hello once again.

As I mentioned in my previous blog entry I have been hard at work improving the tooling of Lords of Illic. Last entry I talked about a testing scene I created that allowed me to quickly set up combats. In that entry I got side tracked by talking about Adobe and architectural changes. Those topics are more specific to Lords of Illic and do fit into a blog entry, but there is a more fundamental element to all of this. Having a testing scene is more than just a “nice to have”. It is a fundamentally important part of keeping your project on track and making efficient progress. 

I like to watch Adam Savage’s Tested (it was incredible to meet him at Supanova last year in his first Australia con, but I digress). One little tidbit I pulled from one livestream video (I originally thought it was from his book but found out it wasn’t when I reread my newly signed copy - the last digression I promise) was that if a tool is inconvenient to get a hold of you will avoid using it. I believe this holds true as much with a hammer as any digital tool.

File management in Unity is bad. By default there isn’t even a way to navigate back. The more files there are to deal with this the worse it is. I bought several effect packs from the asset store when they were on sale, and in total I have imported 133 effects into my project. So if I want to select an effect for a weapon I have 133 choices only distinguishable by name. The cherry on top of this is that any name of decent length is abbreviated. For example if the effect is called pack_number_effectName you have the name cut off (to be fair you can resize the window manually, but that is fiddly). 

Naturally when I was adding these new effects I chose a couple of effects that looked decent and got to something else as quickly as possible. I wasn’t happy with the job I did and I knew the game should have some sound effects along with the effects but it was a pain to work on effects. 

Humans are natural storytellers and our favourite story to tell is the story of us. The story of me being lazy is not a particularly appealing one. So naturally my brain offered another story for me. I didn’t want to work on that part of the game because I was a programmer and it would be “better” and more fun to work on something programming related. Saying it like that might sound strange, but another very human habit is to edit stories in the retelling to make ourselves look better. We don’t like talking about the fuzzy part of ourselves that sometimes makes us try to put the milk in the cupboard and the cereal in the fridge. Whether we like it or not, by taking notice of this fuzziness, accepting it and looking for ways to change things we can improve our habits and our lives. Once we drag our silly fuzzy half-thoughts into the light we see them for what they are. 

Perhaps the punchline of all this, is realising the problem is more often than not the difficult part (in creative pursuits at least). Once I knew why I didn’t want to improve the effects, the solution was simple. Perhaps even a bit boringly simple, I just needed a scene where I could test visual effects. Now Unity does provide you something like this with prefabs, but the prefab view is very abstract. Besides, in my case I paid a small fee to someone on the asset store to handle the prefab making and testing part. What I needed to know is what they look like when a character in my game uses an ability. So I made a script which programmatically filled a menu with each effect in my program and when I clicked the button it played the effect. Simple. Easy. Done. Right? Except…

Wouldn’t it be nice if I could search this list of effects. Well that’s easy right? Okay. Well wouldn’t it also be nice if I could tag effects to make the search better. Okay. But also wouldn’t it be good if I could add these tags while unity was running? “Completing domain” wastes a lot of time after all. Wouldn’t it be… Well you get the picture.

A quick note before we continue. In Lords of Illic I don’t assign scripts to my effect prefabs. There is a very good reason for this. If I adjust a whole lot of effect prefabs and there is an update from the makers of said prefabs I have to update the prefabs and then reapply my changes. Instead I use scriptable objects which contain references to prefabs and whatever overrides I want to apply to said effects. One other advantage is that I have a function on the scriptable object which handles the setup of the effects. That way the end user of the script only has to call one function to start a one shot effect. With that in mind…

Can you edit scriptable objects when the game is running?

The answer is… yes providing that you are running the game from the editor. For my first solution I loaded the “real” scriptable object from disk, but it turns out that is unnecessary. If you drag a scriptable object into a script it is the “real” scriptable object. So you do exactly the same thing as when you write an editor script where you want to edit a scriptable object. The magic “UnityEditor.EditorUtility.SetDirty(scriptableObj)” to mark the scriptable object dirty. Then you save. You need to wrap this code into # if UNITY_EDITOR compile define or your script will cause your project to fail to build - editor utility functions are only part of the editor after all. This is how I do it in my scripts:

// Technically only makes the object saveable
public void SaveAsset()
{
   // Only compile this code if editor
#if UNITY_EDITOR
<span class="Apple-tab-span"></span>  // Make sure you reference the function via UnityEditor.EditorUtility
<span class="Apple-tab-span"></span>  // Even an unused UnityEditor import will stop you compiling
<span class="Apple-tab-span"></span>   UnityEditor.EditorUtility.SetDirty(scriptableObj)
#endif
}

You can also put your script into an assembly definition that is editor only, but there is a catch. You can’t add Editor Only Monobehaviours to objects. There is however a simple workaround. If the assembly definition includes at least one non-editor platform you can add it to a gameObject. So you include one platform you will never build to such as Stadia (which is defunct) and Unity will allow you to add it to your gameObject. I personally prefer compile defines as it means I can have scripts which have extra in editor function and in theory be part of the game. For example if I wanted an effect gallery as a completion bonus. Either way both techniques work equally well for expanding your toolset.

But I wasn’t done there! Now that I could edit the effects scriptables, I wanted to cut out the next annoying step. These effects are on abilities which means to test one I need to know what the effect on the ability is, write it down, search for it, test it and then find a new effect and compare it. Then if you want to change it you have to exit playmode, find the ability and then update the effect. Ugh. But hey if I can edit scriptable objects in playmode… It means I can create a second menu of abilities and play the effects that abilities have! Then I can make a button which sets the next effect. Of course once I made that I also wanted to be able to change other values in the effect scriptable objects and also change the effect which is on the ability buff… If you give a mouse a muffin I guess.

The more I build up these tools, the quicker (and most importantly with less wasted time and effort) I can express my creativity by improving how Lords of Illic looks. But even better than that - these are all nice little self-contained problems to solve. I can scratch my itch to program while also working on effects. Not because I am a programmer and I want to program, but so that I can work on a variety of different things. It is being able to switch between a variety of different tasks which has kept me hooked on working on Lords of Illic all this time after all.

So here is my suggestion. Look for the parts of your game where you have to do a set of tedious steps. Tedious reproducible steps are the strong point of computers. Creativity is the strong point of humans. Solve the interesting problem of automation once so you can spend more of your time doing what you love. And yes I know it feels like you are going slower when you have to stop and make tools, but that is just a trick of perception. A stitch in time saves nine. An editor script in time saves hours of dragging and dropping. So I encourage you to find creative solutions and make everything a bit more fun.

As a bonus here is another useful code snippet.

// If you set this on a button click you have a function that copies the asset name
// Then you just have to paste it into a search bar to find it in the project
private void SetAssetNameToClipBoard()
{
   if (!scriptableObj) 
  {
      return;
  }
#if UNITY_EDITOR
   UnityEditor.EditorGUIUtility.systemCopyBuffer = scriptableObj.name;
#endif
}

Until next time.