Automation and procedural

techniques
Speeding up development with robot butlers
Directions
Automation and delegating
more work to the computer
in general can be
interpreted in a few ways,
but mainly, this
presentation will be
covering 3 things
Straight up automation
As in: systems that actively
perform work previously done
manually, by developers
Procedural elements
and systems
Which are not necessarily
eliminating work on some area
altogether, but allow us to
reduce artist workload or
otherwise get more bang for
development hours spent
Interesting workflows
Built around those time-saving
systems
For a start
We hope you'll find the
tricks we'll present here
interesting and
applicable to your own
games.

Let’s begin with a very

short video for a brief
overview of the game
About us
We’re a small indie game
development studio located in
Seattle, WA

TETRAGON WORKS
We’re a small team
But we're building a fairly
ambitious game about
giant robots stomping
through cities.
The game we want needs a lot of content
Just like anyone else, we want to offer
enough value to the players:

● Lots of varied environments

● Big set of character assets
● Large number of levels
● Many scenarios, items, abilities
● Wide tactical options
● Other strategy/RPG goodies
● Modding support
Robot buddies to the rescue
We like to focus on fun, creative parts of
game development - so we found ways to
automate some of the boring parts
Levels first *
The boards on which tactical games
take place. Some stats first:

● Average grid sizes between

50x50 and 100x100 cells with
height of up to 20 cells
● Locations we build can reach
into 10000+ objects

* literally, that was the first system we built

Let's start with a spec
What do we want
from a level system?
Predictable art production
First of all, it would be nice to
have a finite set of possible
shapes for modular assets,
making tileset production
straightforward and fixed in
scope.

No endless possibilities for

new modular pieces, no back-
and-forth with level design
requesting forgotten bits.
Learning from modern terrain systems
Some modern terrain systems do a
lot of stuff right. We want similar
things they accomplish:

● Automated shape generation

or object placement
● Reasonably flat performance
cost per surface area
● Potential for granular LoD
fading and frustum culling
● Granular customization of
points (tilesets, materials)
On top of that
Of course, terrain systems are unfit for
our needs. You can't shape a city with
something like that. We also need:

● To represent varied manmade

locations: cities, factories, roads
● Full destructibility - it's not a
proper game about walking tanks
if you can't level buildings
● Use of traditional modular assets,
no procedural geometry - we want
to leverage modeling skills we
have
Foundation
Voxel grid is a natural
foundation - no better way to
represent a continuous 3D
volume snapped to a grid.
The problem
Except the voxel-based
volumes are usually rendered
with a skin of procedural
geometry, which is not
desirable for us.
The problem
Whether you go with a blocky
aesthetic or a complex smooth
mesh generation, you're
nowhere close to reproducing
architecture, roads and other
manmade objects.
Manually
authored art is
key
But how to use it while
reaping benefits of a
voxel grid?
Now that's a harder problem
But it's already solved in 2d
games, like old Zelda
installments. Let's take a
closer look at 2D tilesets - if
we look at roads, cliff faces,
grass to rock edges and such,
what is the underlying idea?
Tile
What is a tile in a tileset
depicting, for instance, grass,
sand, and transitions between
them? I think it's reasonable
to say that every tile can be
looked at as a set of four
points.
Simple case
In case of simple, fully filled
tiles, all 4 points have the
same value.
Permutations
Given four points and two
possible values a point can
take, we get 2^4, or 16
possible configurations.
Permutations
If we exclude rotations, we
are left with just six
configurations.
Interpretations
Those configuration can be
interpreted in a number of
ways.
Interpretations
Those configuration can be
interpreted in a number of
ways.
Limit
Those configurations only
cover all possible shapes in
2D space, and we want a
system that allows us to
cover all possible shapes
arising in a 3d voxel volume,
though.

So let's look for an

equivalent structure in 3D
space.
Cell
Normally, voxel volumes are
visualized by blobs built
around full points.

But let's shift our attention

away from individual points,
into spaces between them.
Cell

Notice how 8-point groups

form a cube with points in its
corners.

We'll call that group a cell.

Configurations
Since each voxel point can
be either full or empty, there
are many possible
permutations that 8-point
group can assume.
Configurations
We call them configurations.
Making a model covering it
and placing it at a midpoint
on a voxel grid would cover
part of a 3D volume.
Permutations
Since we have eight corners
with two possible values in
each, we have 2^8, or 256
configurations on our hands.
Permutations
That's... not encouraging.
Who the would want to
author 256 unique meshes
per tileset at the very
minimum?
Reducing the number
First of all, there are
configurations that match
rotations of other
configurations. Excluding
those gives us 128
configurations left.

And eliminating horizontally

mirrored matches drops the
number of configurations to
more reasonable number: 53.
Simplifying art production
It's hard to keep track of all
the configurations even after
they are trimmed to 53. So,
let's give an artist a helping
hand:

We automatically generate a
foundation template: a scene
which contains base shapes
of each configuration
Modeling on top
With that foundation, we can
start interpreting the shapes
into natural-looking tilesets -
pieces of hills, buildings,
factories.
A bit of variety
We also author multiple
versions of some
configurations to scroll
through them later: a wall
might have a variant with a
window, fire exit and so on.
Export
At this point we're sweating
about the prospect of
exporting and managing
hundreds of strictly named
block files.
Export
It's a potential production
nightmare where one typo
can cause a long-unnoticed
error in level rendering and
export of each new tileset is
a long, tiresome slog. Let's
avoid it.
To export, simply
save the 3D scene
We automated the rest.
Processing magic
In Unity, custom processing
scripts perform a lot of
operations on the imported
file.
Processing magic
● Split the scene into
blocks
● Figure out which blocks
belong to which
configuration
● Merge and clean up
internal structure of the
meshes
● Collect all materials in
the tileset
Processing magic
● Swap all materials for
ones in reference library
● Bake material IDs to
secondary UV channels of
all meshes
● Generate texture arrays /
property arrays by packing
every input from precursor
materials together (more
on that later)
● Save the blocks and
material assets
Supporting multi-cell models
We want to support big
designs like road turns, hero
facade elements for
buildings, large gates, natural
formations and so on - things
that can't fit into 3x3x3m
bounds we use for cells.

So, a solution for processing

those into same format had
to be implemented.
Multi-block processing
We simply author big models
with edges adhering to the
grid, and export all those
models for a tileset into
another lone file.
Multi-block processing
In Unity, custom processing script
would do the following:

● Cut the big design into standard

single-cell blocks
● Figure out the shape of resulting
level chunk build from newly
separated submeshes
● Generate the metadata for the level
system, allowing insertion of that
multi-block chunk into levels
● Process the single-cell blocks like
normal tileset assets
To sum level asset production up
● Clearly defined scope for
tileset art, fixed set of models
you need to cover all possible
shapes
● Freedom to author varieties
without cluttering the system
● No need to handle export of
hundreds of separate files
● No need to handle any asset
preparation tasks manually
Finally, how
we use the
assets
We don’t place anything
manually. We just fly
around scene view and
click on nice colored
cubes.
Level system updates
configurations
Then, it automatically fills all cells
with meshes, effectively covering
the volume with a skin made from
modular tileset assets

It's an abstraction of what level

designers do when they manually
place similar modular blocks.
I want a building
Which 40 pieces do I have
to place next, and what
position/rotation/scale
should they have?

The system answers that

for you, no need to drag
individual pieces.
The system is tightly
integrated into the editor
We took care to make it feel like a
native Unity tool.
Perks of the system
Going with that approach to
level geometry also gives us
some nice features and
performance benefits.

To touch a few of them...

Cheap rendering
Small set of meshes
instantiated thousands of
times on a strict grid with
fixed scale?

Forget demos with asteroid

fields, this is perfect use case
for GPU instancing right
here.
Instancing
This whole approach is
prohibitively expensive with
traditionally rendered
geometry - think 15+
thousands of draw calls per
level.

Instancing enables us to drop

draw call count into just
hundreds, making it viable.
Damage
Thanks to levels
being built from
thousands of
separate meshes, we
can leverage
instancing-friendly
per-object shader
properties.
Damage
One example of
such properties
would be vectors
with state of the 8
corner points, which
would allow the
surface shader to
tear off parts of the
level.
Better damage
visualization
Instead of sending just empty
states of the volume grid, we
can also send 0-1 integrities 8
corner points. This can allow
us to visualize partial damage
and make the cell destruction
smoothly animated.
Damage edges
Just as it's possible to
skin arbitrary 3D
volume with a finite
number of 8-point
configurations
(shapes), damage
edges on cells can be
filled in the same
way.
Damage edges
All you need is a
small number of
decorative meshes
depicting chunks of
concrete and other
appropriate bits.
Damage edges
With an algorithm
fitting those edges to
various partially
damage block
configurations, we
get better, layered
transitions to
demolished cells
Interiors
Storing damage as
another state of a
voxel grid point has
another benefit - it is
possible to place
interior tileset blocks
to plug any hole
caused by damage
Collisions
Thanks to grid-aligned
level geometry, we can
drive collisions from a
simple pool of box
colliders attached to full
voxel points
One more thing
Speaking of which - what is
the next obvious step when
you have a destructible grid
with proper, grid-aligned
colliders?
Physics-driven
destruction
How about making all
these damaged buildings
fall down?
Physics-driven
destruction
The idea is pretty simple - we
build a graph of filled points
through the volume starting
from the bottom level (using
neighbourhood search), find
remaining full points not
included in resulting graph,
and make those isolated
chunks fall down, inflicting
point damage to voxel grid. To
do: stress analysis to prevent
single-column supports.
Navigation grid
Again, thanks to the shape
of the level being so
ordered, it's incredibly
simple to solve navgrid
generation for pathfinding:

All you need is to find flat

floor configurations, create
a node for each, and link
them to neighbours
Advanced navigation
You can also generate more
elaborate pathfinding grids
with different link types for
jumping, dropping,
climbing and so on:

Simply traverse the grid

starting from flat nodes,
searching for a suitable
chain of configurations
Props
Having a grid of shapes
which can be traversed in
code is also beneficial for
decorating levels with
smaller objects.

We implement a prop system

that detects whether prop is
compatible with it's location,
auto-rotates wall props,
drops props attached to
destroyed cells and so on.
Block shading
Speaking of cheap rendering,
we briefly mentioned
generating texture/property
arrays during tileset
processing stage

All tileset blocks use a single

material with a shader that
works similarly to modern
terrain shaders.
Block shading
The shader picks from an
array of textures and PBR
properties using a material
index (which was baked into
secondary UVs).

This allows artists to author

tileset assets without any care
for atlasing, enabling fast
workflows like strip texturing
from multiple maps.
Block shading
No matter the number of
materials in the source scene
of the tileset, blocks always
cost 1 draw call thanks to
lone array-utilizing material
being used ingame.

Well, actually, we use far less

than 1 draw call per cell -
remember, everything is
instanced too.
Other stuff
Of course, support for per-
block colors and emission
values is in too -
implementing that through
instancing-friendly shader
properties allows us to tweak
individual blocks without
breaking batches up.
Mech assets
Level system isn’t the
only area benefitting from
automation, asset
processing and related
trickery
The core
The heart of any game about mechs
is customization.

We need a deep customization

system, allowing you to tinker with
various bits, swap parts and so on -
and we want to leverage it to
produce varied enemies and offer
interesting progression.
Constraints
Since we're a small team, we want
to produce as much content as
possible with as little work hours as
possible.

To maximize possibilities for

customization with minimum art
cost per permutation, we decided to
go with a single platform.
Platform
The platform, or skeleton, is shared
by every unit existing in the game
right now. It's the underlying body
to which all parts are attached, be it
armor, weapons or even pilot
capsule.
Platform
Since the body had to work with a
huge number of assets, fitting
potential hundreds of different items
like a body, making it had to be a
deliberate, iterative process.
Iterating
Except iterating on a complex
skeleton built from multiple files is
a bit of a pain.

Deciding how joints should look to

interfere with armor as little as
possible, how limbs should be
proportioned to bear different items
equally well - it all involves
reexporting the assets multiple
times, which results in a bottleneck
from manually reassembling the
character hierarchy in Unity.
First thing to
automate
So, first thing we automated was
character hierarchy building itself.

We wrote a script that examined the

description of desired structure (this
joint goes under that joint, etc) and
fetched the meshes from a set of
files to instantly update the playable
character prototype whenever we
changed one of the models it's
composed from.
More requirements
All character meshes had to include
vertex colors baked from special
materials to drive masking of 4 user-
controlled customization zones

They also had to have curvature/AO

maps, AO baked into vertex data,
body piece index baked into one of
secondary UV channels and so on.

We automated all that too.

The workflow
Nobody wants to manually export,
bake and assemble 30 body parts. So,
the workflow allows us to iterate
quickly, and goes like this:
The workflow
● Artist exports just one FBX file
● The scripts find correct sub-
objects in them, merge them, bake
every input required by our
shaders
● Whole hierarchy used for
animation is automatically rebuilt
every time one of sub-objects is
changed
● We immediately hit "Play" and
see it in action to check on, say,
updated leg joint
Animation-unfriendly
bits
Mechs are complex, and some
parts of them are pretty
unfriendly to animation.

All those mechanical joints

rotating on multiple axes in a
strict order to match a certain
3D orientation, pistons pushing
an arm into certain pose and so
on.
Procedural
animation
Some parts of the
hierarchy are animated
with scripts, making
clips lightweight and
allowing us to iterate
on the joint design
without breaking any
animations. Animator
creates a keyframe
with an arm pointing
forward, script figures
out how to do that.
Side benefits to auto-
animated joints
Excluding those exotic bits from
main hierarchy chains also makes it
possible to set up the skeleton
identically to standard biped rig,
reaping the benefits of complex
human-targeted IK, FK, ragdolls
and other interesting systems.
Reducing scope of
artistic work further
With the underlying body and
animations out of the way, we turn
to items themselves.

We need to produce hundreds of

pieces of armor and weapons with
as little effort as possible to
maximize the output of our artist.
Textures
One of the biggest time sinks in 3D
art is texturing.

Unwrapping, wrangling bake files,

using them to author proper input
maps for the PBR shaders and so on
- it's all pretty time consuming.
Customization
concerns
Also, we can't even use traditional
PBR maps because we want every
PBR property to be customizable -
pre-painted smoothness or albedo
maps are useless in this case.

So, we took a bit of a shortcut.

Shortcuts to texturing
Instead of authoring a full set of
PBR maps for every part, we bake
curvature and AO (which can be
thought of as abstract shape
descriptions).

We interpret those inputs directly in

the surface shader to allow full
customization of the material.
Raw automated
bakes drive shading
Essentially, users control the settings
of a tiny Substance Designer-like
system that’s not being driven by
any manually authored maps.

Which means we don't spend a

single second on texturing. Did I
mention that unwrapping is
automated too?
The workflow
So, the workflow for armor pieces
and weapons is simple: 3D artist just
creates basic shapes and marks up
customizable areas with few special
materials, then exports the resulting
untextured bit and gets to work on
the next design.
Well, almost
Except result of that workflow
looks a bit plain - no small details,
just large shapes with neat
shading.

And we can't really just paint

rivets/seams/hatches in the
textures - it's time consuming and
incompatible with automated
system. But we solved it in a
different way.
Details, details,
details
To think of it, most of hardsurface
details are repetitive.

Dozens of seams, rivets, panels,

vents, protrusions, depressions,
hatches, ports and joints are present
in most hardsurface designs.

All those are usually baked to a

unified texture using so-called
“floaters” or modeled right into the
mesh with great effort.
Removing redundant
work
We don't want to paint 27 vents or
76 rivets manually, nor do we want
to bake them using floaters.

Instead, we author every bit of detail

just once, and pack it into a single
atlas.
Decal
workflow
Next, we map that atlas to some quads
or other simple geometry, and start
slapping that detail onto our parts like
stickers.
The crucial bit
But since we can't touch the
underlying surface texture (it's
automated and should contain
only bakes of plain shape), we
leave all detail floating in the part
model.

In the game, the decal shader

selectively overwrites parts of G-
buffer under those floating
decals, smoothly blending the
detail into the underlying surface.
The benefit
The benefits from this are obvious -
for one, we never waste any texture
space for repetitive detail.

Also, if we want to edit some detail

(like shape of a rivet), changes to a
decal atlas immediately influence
the look of every single model in the
project using that detail.

That’s all well and good, but where

is automation in this area?
Automation in decals
Even in that efficient workflow,
there is work worth getting rid of.
For instance, decal shader needs to
know the customization ID of
underlying surface to blend to it's
albedo correctly, and all decal
vertices need AO baked to vertices
to match shadows on underlying
surfaces.

We completely automate that work,

feeding surface mesh and decal
mesh to a script which performs that
work for us.
Damage
We don't author any
"damaged" states for the
armor, even though mech
damage is a very important
part of the game.

You should be able to punch

a hole in the armor or tear
entire arm off the enemy
mech, that's part of the fun
of a game about walking
tanks.
Damage
implementation
Instead of spending time
on special damage assets,
we render it similarly to
buildings, peeling off
layers based on local
damage maps updated on
hits.

Add some fancy FX and

deferred decals, and we're
in a pretty good shape even
without bespoke assets.
Dynamic animations
We also don't author any
flinching/staggering
animations for different hit
directions and intensities.
Instead, we use a ragdoll
system which gracefully
blends in whenever a hit
occurs.

It's also used for similar

needs like weapon recoil
animation.
Saving time
Likewise, some movements
work off an IK rig, removing
the need to animate heads,
arm pose during aiming and
so on.

All this, again, is reducing

the workload of the artists,
allowing them to focus on
more creative tasks.
Weapons
Since we need a lot of them and
would prefer to reduce per-weapon
workload as much as possible, we
use an old trick a-la Borderlands -
modular components.
Weapons
Every new
component
increases the
number of
possible
permutations.
Props
Props are all the small decorative
objects placed on top of main level
geometry - street lights, vehicles,
boxes, vegetation and so on.
Basic requirements
Props need to be:

● Very cheap to render (1

draw call)
● Destructible (from mechs
running through levels,
stray shots, destruction of
level underneath them)
● Customizable (lights,
colors, locations).

But before all that, we have to

get them into the levels.
Prop placement
We wanted to completely avoid the
need to position props manually.

Dragging transforms around is time

consuming, imprecise, and leaves us
with no information about relation
of props to the voxel grid, which is
important for integrating them with
main level destruction.
Done quick
So, our level editing tools treat
props as another way of modifying
grid data.

They can have some small offsets

and independent rotation, but
fundamentally, they "inhabit" the
cells of the level.

This makes placement a one-click

affair and greatly simplifies prop-
related logic like collisions against
mechs.
Collision setup
Speaking of collisions and
destruction in general - we automate
collider setup, detection of renderers
to use in active/destroyed state,
setup for fellable props like trees
and street lights (which involves
setting up force application points,
various physical properties, FX
points) and some other prop
properties.
Processing, rendering
Just like mech parts and level
blocks, props go through a dedicated
3D model processor performing
some time-saving tasks like material
merging, vertex AO bakes and so
on.
Processing, rendering
Rendering works similarly to level
system, with instancing and injected
properties allowing per-prop
customization without breaking
batches.
Special needs
Speaking of reducing artist work
hours per prop: there are few
vegetation-specific areas to it.

While you can't really invent many

novel ways of modeling boxes and
street lights fast, vegetation work
can be significantly simplified
beyond tricks described above.
Vegetation
For one, all vegetation we use is
made in tree creator system that
ships with Unity, which relieves us
from need to model and unwrap all
the repetitive branch and foliage
geometry.
Vegetation
But that's not exactly novel, many
Unity games use it. What's
interesting is optimization of
vegetation produced that way.
Level of detail
Since we're making a strategy game
with relatively low geometry
complexity required from props,
we're mostly concerned with
producing just one LoD level for our
props.

For vegetation, that would be a

billboard - a small piece of
geometry fading in when a tree is
seen from a distance.
Authoring billboards
Usually, LoD billboards are a bit of
a pain - you have to take a shot of a
tree in neutral lighting conditions,
integrate it with normal lighting,
batch them into groups and so on.
Authoring billboards
They rarely look right and do not
blend well with higher LoDs. We
solved that and automated their
production.
Basic automation
First step to optimizing this part of
vegetation production is generating
the billboard texture.

After an artist clicks a button, we set

up a neutral lighting environment,
frame a prop with a camera, switch
on some nice supersampling and
save a shot with alpha, then
downsample and save a texture.
The usual problem
To make the billboard tree look like
a real tree in the distance, it... needs
to write very values very similar to
the original tree into the deferred
buffers.

Same albedo, same normals, same

shadows. Which is a bit hard to
achieve if you're using a cutout of
final buffer capture.
The solution
To solve this, we capture full
content of deferred rendering
buffers, as well as a shot of the final
buffer with special replacement
shaders leaving only the shadow
mapping visible.

From them, we create textures,

when used with a custom shader,
can give us a tree pretty similar to
the real one in terms of it's PBR
output.
Other stuff
Of course, all the small tasks like
setting up a quad mesh, creating a
material, customizing it to match
full tree model values, compositing
textures with appropriate resolution
and channel packing and saving the
result are also automated.

It's a one-click system. LOD1

LOD0

Albedo buffer
Performance
By the way, since we're using
instancing, every single billboard is
rendered with the same material in
just one draw call total.

So, 500 trees of the same type in the

distance past LoD threshold will
require just 1 draw call.
More performance
But wait, there is more. Since
billboards always use the same
mesh, we can generate a per-level
texture array with all billboard
textures and pass a slice index using
an instancing-friendly property to
each billboard.

That way, whole billboard forest

with any number of tree types can
be rendered in... 1 draw call.
Data-driven systems
It might be mundane stuff for some
enterprise developers, but it's a
surprisingly rare and effective approach
in game development
We offload as much as
possible
No point limiting yourself to save games and
setting configs. For us, external files store:

● Items
● Scenarios
● Levels
● Props
● Localization
● Units
● Constants
● Characters
● Even unit behaviors/action types!
How it works
We use a YAML serializer to generate human-
readable configuration files containing as much
data as we can take out from the game.

We load those configs at runtime to drive

aforementioned systems instead of hardcoding
them or using internal assets in the Unity
project.
Benefit A
For one, this makes the game
extremely friendly to modding.
It's very easy to add new
times, change characters and
even implement new unit
abilities with their own data-
driven logic.
Benefit B
This approach also speeds up
iteration during development.
Hot loading data and using
tweakable scalar values to
adjust most of behavior in the
game makes fixing lots of
issues quick and painless.
We sat down
with a playtester once
And rebalanced the game on the spot
as he watched and directed us to
issues standing out to him.

Data-driven systems can be a bit of a

slog to implement, but it pays to go in
that direction.
Spicy hotfixes
Having an ability to fix
issues on the spot without
making a new build is,
well, priceless. Any
developer on a deadline
can probably relate to
that :)
To summarize
Through automation and procedural assistance, we’ve
greatly simplified:

● Level art production

● Level design
● Character art production
● Prop art production
● Balancing the game
● Filling it with items/scenarios/other RPG goodies

That’s not an exhaustive list, we have more systems

(pilots, AI, panoramic art behind the levels and so on),
but it’s probably time to wrap up.
Questions?