As you gain game development experience, you will inevitable discover the exciting world of custom made tools and editors. Best-case they can be extremely useful but worst-case they are time-sinks and put your team in maintenance hell. In this post, I present questions you should ask yourself before writing a custom tool for your own project.

Preface

Before I get into the actual post, I want to specify:

In this post I use tools and editors synonymously. There are differences but in game development they are often used interchangeably. Examples of other phrases that mean the same in this context are: Wizards, Editor-time code and sometimes Utilities. (Got more? Write me!) While the purpose of this post is to inspire productivity, it is still important to acknowledge chosing to code something for fun or out of curiousity - your goals are yours! This post is not a technical guide to writing a Unity3D CustomEditor , CustomPropertyDrawer , ScriptableWizard or any Unreal Engine 4 equavalents. It is a set of problems to consider before writing a tool. While the context is game development, I think you could draw parallels to other software contexts, e.g. Web. As I develop games professionally, however, I will stick to the gamedev context.

Being smart about assets

As you get game development experience, you will inevitable discover the exciting world of tools or editors. If you haven’t heard of them yet, are scripts that usually[1] won’t be compiled into the game regular players play; they contain custom code, which only the game developers, designers or artists will use.

Examples of these are:

Enhanced 3D level editor, allowing snapping together segments to form full levels.

Graphical conversation designer, granting overview over dense tree-like conversational structures.

Node-based shader creation tools, that make the somewhat mysterious process of shader making easier.

Custom build windows, that set correct values, run supplementary programs and upload your application to a server.

The potential benefits of these are streamlining of asset creation, enhanced manipulation of virtual scenes, and much more.

[1]Note: Some tools and editors are actually built into the game, and the player can use them too! Other tools are included with the game as a separate program, which would make it a modding tool or Software Development Kit (SDK).

Let others be smart first

You can find plenty of these types of extensions in the Unity Asset store, usually under the Editor Extentions/Visual Scripting category or on the Unreal marketplace where the corresponding category is Code Plugins. If you have never used any assets from the Unity Asset Store/Unreal Marketplace - code, art, audio, etc. I would encourage you to give those platforms a look - There are many interesting projects to be found. Remember, that the official game engine websites are not the places to find useful projects; searching repository hosting services such as GitHub or BitBucket or even using a generic search engine like DuckDuckGo.

That being said, I would also advise you to exercise some caution if you intend to use what you find for more than just experimentation. Production-ready projects have (read: should have) specific performance and architecture requirements that, frankly, at lot of what people upload will not meet.

You might know some of the common performance problems: (I’m using Unity API in my examples, as it is what I know best).

Not caching references and instead re-locating them each frame using Unity’s GetComponent<T> or FindObjectOfType<T> or comparable functions.

or or comparable functions. Calculating the same values each frame instead of using more event- or callback-based approaches.

Wrongly organizing UI elements by their proximity instead of their update rate (Each time a UI element changes, the entire Canvas is recreated).

Architectural problems can be everything from being hard to extend with your own code, having complex or ridgid file system structure, having cumbersome dependencies and so on.

You can’t really blame the creators of free assets if their tools aren’t compatible with the newest patches of the relevant game engine; they have already spent hours working on something which won’t pay[2] them. Those who sell their assets, however, should strive to maintain their code, or at least notify potential downloaders of known issues.

I might expand on common performance and architectural pitfalls in another post - let me know if you would be interested!

[2]Note: While a lot of software might be free, consider donating to the authors who make the free software you use the most. A donation could be money for a coffee or beer but it could also be in code; if you find a bug in the source code you use, (if such is provided) consider sending a Pull Request with the fix to the original author. That way, you have fixed not only your own problem but also some other lucky programmers’ problems. If you are employed, remember to check your company’s policy on this type of charity.

Before writing your own tool

It should be obvious that deciding to begin an exciting editor side-project for fun should not require defending; if you are not under pressure to meet a deadline, playing around with code for a tool is as valid as any hobby and you might learn a lot or discover new paths to take with your project.

On the other hand, if your boss or colleagues are expecting you to meet a deadline for another project and you think your tool might add value to it, you should ask yourself a few questions in order to better determine whether your problem is toolworthy (or untoolworthy):

How stable is the game design?

Tools are the most valuable when there is much designed content left to be created. Problematically, almost by definition, the more there is to be created, the earlier in the development process you are and the more will change before the project is complete.

If you start writing your tool early, a dungeon generator for example, you can enjoy designing, developing and testing your game around a lot of procedurally generated content. The downside is a major one however: since the game is far from done, you will likely re-design many aspects of the core game down the road. Bigger changes will inevitably change how your dungeons should be layed out. Say for example, that you decide to inject some giant skeletons into your dungeon - you will have to widen the halls and maybe allow for rooms with more space to the ceiling, so that your giant bone-based warrior doesn’t scrape its cranium against it.

“No worries…” you might say, while pointing out how every one of your dungeon generator’s variables would be customizable. This is a smart move but it won’t solve the core issue. You see, the variables that you have thought to expose are in all likelyhood only those that solve known problems that you have already noticed and to some extend analysed - Adding a “corridor width” variable will solve the known problem but the unknown problem which you have yet to discover will still need to be solved at some point.

These smaller, rapid changes will likely have a disruptive effect on your code architecture.

This is why you should consider making a tool when you have already created some content in a simpler, more manual way. Continuing our dungeon example: try making a couple of dungeons by hand, using standard tools provided by your game engine of choice. Continue developing your gameplay mechanics. As you start to crystalize your idea; finding its proper shape and your dungeons change less radically, then consider which content creation steps you could automate.

You will inevitably endure scrapping code due to shifting design goals but it will be less annoying if you gauge stability of design modules before dedicating a large chunk of time to implementing them; when design shifts radically, you will have less work to leave behind.

How much time will it save?

Be very honest with yourself and any colleagues. For example, making a procedural dungeon generator is a lot of fun and can end up being a very benefitial tool for level generation in a level-heavy dungeon crawler type game. In your excitement, you might start listing the features of your proposed dungeon generator and how many levels it can generate, how it places doors between rooms and how it smartly balances loot and monsters.

You say to yourself: “With this tool, I could generate one-thousand levels in a minute; each play session will be different!”.

At this phase in the project do you really need a one-thousand randomly generated levels though? Or do you need 10 thought-out, extensibly tested, handcrafted levels? If you are in a concept or pre-production phase, chances are that you should be spending your time making those 10 levels awesome; conduct tests with outsiders, tweak your values and re-test.

Really, a cool pipeline tool might first turn really valuable when the project has proven it’s worth as either a minimal viable product or a vertical slice. Then, eventually, it might save you many hours, days - or even weeks! (one can dream!).

Who will maintain it?

If your tool is used frequently, developers, artists or game designers will come to depend on it; set up processes and other tools around it. Depending on its complexity, there will be some number of bugs in the tool. Some fixes will be easy, some will be harder.

As the inception of the tool is still fresh in your memory, the fixes will flow fast and easy. As you shift to work on other components of the game (a new tool maybe?) the tool will still require revisiting from time to time: to fix a quirk, document a side-effect or add a feature that one of your colleagues requested. While you might find it nice to be needed - chances are that you will be sorely needed on newer features and more critical bugs and crashes. Every time you turn around to fortify your tool, the rest of the game project will suffer your absence.

Naturally, you will be the fastest person to fix most issues with your tool. Other developers; your colleagues will have a harder time as they have to first get an overview of your tool’s architecture and then analyse the problem cause. To ease their pain, you could write documentation for your tool, for users and for maintainers (these groups are not always the same - consider a pipeline tool for an artist, which a developer will have to maintain).

This is naturally a time consuming task in itself, and carries with it the added burden of documentation maintenance; each time the architecture changes, the documentation must be updated as well.

Toolworthy?

If you have discussed the above-mentioned problems throughoutly with yourself and your relevant colleagues, you should have a clearer idea of the necessity of a set of editor scripts or a custom tool. Whether you decide to write your own custom tool, find a third-party tool or refrain from adding more tools at this point, I believe your productivity will benefit from a decision based on discussion.

If you do discover the necessity of a tool later on, or conversely regret previously constructing a pipeline around a tool, it is never too late to reconsider the inclusion or exclusion of a particular tool. As long as the choice is made with productivity in mind: what needs to be done now, right now and soon. What a tool can do for you after the next deadline or what it can do for your third DLC (Downloadable Content) down the line is explicitly secondary.

~

Feedback

If you enjoyed this article, as I hope you have or have feedback please write me on Twitter!