Tech Art Thoughts: The best solution is no solution

When you're chipping away at your next script, exporter, framework, or just really anything that requires you to do some work, it's tempting to get sucked in and just write code for its own sake.

You can even go as far as finding excuses to build systems simply because you're interested in finding out how they work, almost regardless of whether you can justify their cost. This is often an easy trap to fall into, because often, these systems do carry value in the mid-to-long term.

When it comes to Tech Art, long-term solutions are generally not the thing we work on most. The average lifetime of a given solution Tech Art builds tends to be a subset of the total production time. As project needs change, Tech Art adapts and builds solutions for problems the project encounters, almost always on an as-needed basis.

It can be tempting, then, to chase the next solution as it comes up: artists are having trouble constructing levels quickly? Work on placement tools. Lots of buildings in your game? Make a building generator. Too many unique textures? Time to work on an atlasing solution.

Notice how all of these examples have one thing in common: they assume the answer to the problem is a new piece of tech, or a tool.

This sounds like a daft statement, but not every challenge needs tech art, and not everything that looks like a problem actually is one. In a decent subset of situations, the solution is actually a process change that leads to different outcomes, which then removes the need for a tech solution.

Let's illustrate with the example of the building generator. It's tempting to look at a piece of concept art of a city and immediately leap to the conclusion that the buildings in it absolutely must be procedurally generated. In some cases, this might be right; take Epic Games' recent Matrix city demo for Unreal Engine 5, for example: the goal statement of that entire project was to create a life size city, with literally thousands of unique buildings. Hand authoring this would have taken years, so procedural generation was a given.

However, if you're making a game that funnels a player through or into a tightly controlled environment, like The Last of Us for example, the degree of investment required to build the generator would take about as much time as it would take an artist to just do the work.

This neatly illustrates the most common pitfall when examining fancy tech solutions: chasing the solution instead of pushing back on the problem. This is an easy trap to fall for because it's so tempting: you get to make a new tool, after all!

Instead, when presented with this request for a building generator, think: what is it we're actually trying to do? Examining the problem more closely, you could arrive at a number of potential solutions, of which procedural generation is just one; note how the list below is sorted in order of minimum tech spend.

- Create the buildings manually, but come up with some clever authoring techniques to reuse content, like a library of textures, meshes, etc. The final DCC export is still a fully textured unique static mesh.

- Modularize your buildings. You can do this most simply by modularizing floors, if you only need control over building height. If you need width and length too, you will need to make your modular pieces more granular, though you can still divide it pretty roughly; one corner, one tileable middle piece, a door and a roof. Assembly is preferably done in DCC, rather than engine. This speeds up the process without sacrificing artist control.

- Go fully modular in-engine. Note that this approach can be relatively easily scripted or tooled in things like Unreal Blueprints without needing to bring the heavyweights like Houdini. This approach requires a close collaboration between tech and art, and sacrifices a degree of artist control, though not all of it. The artist can generally make minor edits to the final results, like vertex painting and prop placement.

- Go fully procedural. You will still use modular pieces, but the final output is difficult to control by an artist, and is destructively generated by the algorithm. This is the approach you see in Epic's Matrix demo, and the sheer number of videos they released on the topic of city and building generation illustrates the minimum tech spend on this path. Proceed with caution.

All this is to say that solving a problem in content production can sometimes be as simple as taking a different approach, rather than making tools to support the current path.