As I’ve written about extensively for the last few months, I’m currently in the process of creating a tool to go on the Unity Asset Store. Every tool carries within it a set of standards and expectations. Sure, everyone knows what hammers are and what they’re meant to be used for – but a specific hammer, its size and shape and heft, change this meaning and purpose slightly. Even within the subset of hammers meant to drive nails – which is, on reflection, a fairly narrow category of hammer – each has different sizes and shapes, suitable for hammering different sorts of nails even as they remain broadly similar. Each tool carries an implication of purpose that shapes the result of whatever it’s used for, in addition to whatever the properties are that actually make it useful.
As the saying goes, when all you have is a hammer every problem looks like a nail – even though a hammer can be used for many purposes, the form of the hammer communicates that it is meant to be used on nails. This is also true of digital tools – each 3D modeling tool may serve much the same purpose as another, as may each paint program, as may each digital audio workstation. These all might have exactly the same capabilities as their peers – yet also each have a distinct emphasis and style, and each communicates certain expectations of how they ought to be used, which shapes the output users will generate using them.
A common example of this dynamic might be the hard division between the perception of what a game made in the Unreal Engine looks like vs what a game made in Unity looks like: While these engines have, broadly speaking, similar capabilities, the set of default tools and materials and lighting models are significantly different. These different aspects make certain types and approaches to development more (or less) approachable and appealing, thus shaping in aggregate that sorts of games most likely to be developed using them.
This isn’t really noteworthy viewed from the outside – every artist learns that different tools can serve different styles, even as they appear to do more-or-less the same thing in more-or-less the same way. Where this can get a bit strange to think about, though, is when you’re in the position I am now: When you’re building a tool, you are also potentially constraining the possibilities of all art that might one day be made using that tool. My instinct is to keep expanding the tool’s capabilities further and further, to make it able to do anything that one could conceivably require of it, and this is a dangerous instinct for several reasons. First, as I’ve discovered the hard way over the past few months, this can lead to A Lot Of Work: Each new idea for what a tool might do leads to, not only figuring out how it might do that, but the cleanest way to expose that capability to a prospective user, and how to efficiently implement these behaviors internally. Second, if you create a tool that can do anything, it is crucially similar to having no tool at all – there are few obstacles to creativity so formidable as the infinite possibility space of the blank page. Ideally, a tool will be easy to use in simple, obvious, clear-cut ways, but also afford experienced users the ability to quickly and intuitively experiment and iterate on an idea. This is, anyway, the philosophy I’ve pursued in developing my current project.
Creating a tool like this is similar to creating a game – not just an art, but a second-order art, a meta-art, creating an experience for those creating experiences and trying to guide the generated output somewhere interesting and, hopefully, useful. There is a responsibility for the artist, to keep the impact you can have on the world in mind – and, likewise, for those of us who build tools for artists, that weight exists at one layer of remove, to mind the impact we might have on our artists.