A few weeks ago, we mentioned our frustrations with Unity’s editor system while building BurntOut. It’s pretty simple and easy to use if you want to expose a few of an object’s fields to the editor, but if you want to do more with it, it starts to become a pain. We wanted to have the narrative structure of the game all in one easy to edit place in the Unity editor, so we opted for a custom editor window.

Custom Editor Issues

As the window became more and more complex, having to manage all narrative data in the editor, the code for the window quickly became more and more complex. Looking back over it, it had become hard to review and edit in several places, especially for someone who hadn’t written it. We also then came into contact with a new glaring problem: the Unity editor’s default font-size.

Unity’s default font-size is only 11, and Unity’s size 11 is the equivalent of a size 9 in a typical word processor. Unity adds the pixels at the bottom of characters like ‘p’, while most programs omit that from their calculations. This is fine for simple value edits in the inspector, but when managing fields with multiple sentences, this can become quite inconvenient. There are ways to change Unity’s font-size, but much to our dismay, the GUI elements typically wouldn’t scale with them correctly.

Ideally, we wanted an editor window that stores all the narrative data, looks nice, has a changeable font-size, and its code is easy to read and change.

A Custom Editor Class

Since Unity’s system didn’t seem to do what we wanted, implementing it ourselves seemed to be the obvious answer.

Our first solution involved creating a new Editor class that we would use for all our editor calls. The idea was to mirror classes like EditorGUILayout, except actually work.

Unfortunately, we ran into more issues along the way. While that idea largely worked, our new class quickly became huge. To match EditorGUILayout‘s functionality, we had to contain countless methods all in one class.

Things got even more complex when we started working with TextAreas. Because of how Unity handles editor code, the TextAreas were getting a different height every other call, so they wouldn’t display properly. We ended up having to store the last valid height to circumvent this issue, but this value had to be stored outside the method. Having to store the TextArea’s data outside of it was pretty sloppy.

Since we’re using Unity’s ReorderableList, we wanted our methods to work with that. Unfortunately, that wasn’t compatible with how we were drawing elements, and we couldn’t find a good way to switch between the draw methods without our long class becoming a much larger mess.

An Object-Oriented Editor

Reflecting on all the troubles I was having with Unity’s editor, I realized that a large part of my issue with it, especially in regards to my prior solution, was that it wasn’t object-oriented. This isn’t to say object-oriented is the only possible way to approach a GUI, but C# is an object-oriented language, and trying to create an editor GUI without object-oriented programming inevitably caused countless issues.

The solution we were left with was creating an object-oriented wrapper for creating an editor GUI. That took awhile, but the object-oriented editor system is almost in a place where we can feel happy with it!

It can create a bit more code in some places, as the GUI elements must be initialized, given event listeners, and drawn. However, it makes the code so much easier to understand. You can easily look at the drawn part of the code, and the layout the code will take is very apparent. The extra code for initialization allows you to customize how a particular element is drawn, without having to clutter the draw code. You also have the ability to do things whenever a GUI element changes, not just get the new value every draw call.

There’s a little more work to go, but the improvements have been immense. Creating custom editor code now feels the way writing C# code should feel.

You can read more about the BurntOut game at its website and follow along with our development on the blogs.