Unity for Artists

Role: Senior Artist → Creative Director → Art Director | AGS, Intuicode, Everi | Unity Adoption, Technical Art, Training, Workflow Design

Challenge

Getting Unity installed is easy.

Getting studios of artists comfortable working inside Unity is something else.

Artists already have tools they know how to use. Then you hand them a new game engine full of scenes, prefabs, shaders, import settings, animation systems, and esoteric developer-crafted things… and all the while production is expected to keep moving – it’s a lot to take in.

I’ve found myself at that frontier three separate times in my career:

1. At AGS, I learned Unity as a Senior Artist, from sprites to animation systems, as I worked with partners across disciplines to explore and build our first Unity slot game & engine.
2. At Intuicode, I led and partnered across disciplines to help build a Unity slot game engine from the art side, and created training & workflows around what artists actually needed.
3. At Everi, that accumulated knowledge and yet another experience of partnering across disciplines to build a Unity slot game engine became…
   Unity for Artists: Training, documentation, practical exercises, safe learning spaces, shared standards, workshops, communication channels, and Technical Art support designed to help other artists cross the same bridge yet again – but at a much larger scale.

Learning Unity

My first real experience with Unity came when AGS began pushing into Unity development. I volunteered to take the lead on the Art side of our studio’s early effort.

That meant learning how artwork made outside the engine actually behaved once it became part of a running game: importing and configuring assets, working with scenes and prefabs, timeline & animator, and figuring out where the artist’s job ended and the developer’s began.

I worked closely with a developer on this first Unity game project. My approach was one of collaboration and experimentation. There wasn’t a training program yet, but learning was the main goal for my part. The experience left me with the following takeaway:

To get the most out of Unity as artists, and to unburden devs to do other important things, artists need enough technical fluency to control what happens to their work inside Unity.

Building Capability

A few years later, I joined Intuicode as Creative Director. We were a small HHR studio growing quickly, and our games were still primarily built in Flash. It had gotten us surprisingly far, but our ambitions were getting bigger, our competitors were getting better, and the limitations were becoming increasingly obvious.

I pushed for us to move into Unity.

This time I wasn’t just learning Unity for myself. I had a production team that needed to come with me. I worked directly in the project with our developers, editing scenes, prefabs, materials, symbol art, animation presentation and effects while we figured out what an effective slot-game workflow should look like.

That led to some wonderfully nerdy questions & tech adventures:

• Should a reel symbol be a sprite, a plane, a quad, or a render texture?
• How should it animate while spinning on the reels?
• Why does the first frame of every video file in engine flash white the first time it’s played?
• How large do these kinds of textures really need to be?
• How far can we push performance with the new engine on our machines?
• What levers do we have when art starts getting expensive in memory or performance?

The questions were technical, but the reasons for asking them were creative.

One example of an artistic technical challenge at that time was the simple-sounding “reusable light sweep” over game art (This was before Light Cookies). I just wanted to make light pass over a gold coin, making it shine. I worked through possible approaches using masking, lighting, Sprite Masks, Shader Graph, and rendered video, comparing each against clipping, scaling, materials, flexibility, and performance. The final result was custom-built shaders, which I taught myself to make, combined with delicious post-processing bloom.

That little challenge captures a role I increasingly found myself playing –
Development understood the engine. Art understood the visual goal.
I could get far enough into both art & dev to help translate between both sides.

The point wasn’t to become the shader guy. It was to understand the creative intent, test technical options, ask better questions, and help turn the result into something artists could actually use. That same thinking expanded into reusable UI, animation patterns, templates, shared assets, and practical training tasks for the team. I was starting down a path that many proto-Technical Artists go down – follow your own curiousity as you solve problems with technical solutions. Through this project I learned a lot of what would later enable me to not only understand Tech Artists, but to understand their importance enough to advocate for building out their role & fill in their bench within Everi.

Determine what it is you and your team are going to want to do – when folks start dreaming up big ideas, what things can we figure out beforehand so they don’t loose momentum?

That was the beginning of what would later become Unity for Artists.

Teaching & Change Management

Then Intuicode was acquired by Everi – who also just so happened to be building their first Unity engine. Our small team became part of a much larger game organization with multiple studios, central technology groups, different workflows, and many more artists preparing to make the same transition we’d already gone through.

At Intuicode, we had been the little company trying to catch up technologically.
At Everi, we arrived with practical experience doing exactly what the larger organization was preparing to do.

How do we help other artists learn it without everyone rediscovering the same lessons the hard way?

The first part of that answer was to hire Tech Artists. Through my experience with Intuicode, I understood the importance of having people on your team who could bridge the divide between Art & Dev, and act as force multipliers for the whole production team as they entered a new world of Unity. We needed SME’s and fast – although I needed my art team to ramp up into using Unity, it would be a hell of lot easier with some experienced folks to help. We lovingly called them Tech Wizards, as they were apt to have long beards, be a little grumpy at times, have nigh-on-magical powers in Unity, and largely be instrumental to the success of our various adventures. I could swear I heard one say:
“A Tech Artist is never late. Nor is he early. He arrives precisely when the build breaks!”

Make It Safe

One of the first things artists need when learning something new is permission to be bad at it for a while. Production projects are terrible classrooms. Nobody wants to be the person who learns what a prefab does by accidentally checking their experiment back into the live game.

So our training began with a protected practical sandbox. It was a place to work in the nearest context to a live project possible. They could safely experiment, and then when ready, coordinate with a dev or a TA to move it into the game. Keep the tech wizards happy.

I put together a Unity Bootcamp wiki that walked artists through the unglamorous things that often stop adoption before the interesting work even begins: licenses & access, VPN setup, version control, the correct Unity version, workspace setup, middleware, launching the game, etc. These dependencies were deliberately taught in order to reduce errors and smooth the road ahead.

We treated it as an accomplishment for those first waves of artists. You had gotten into the project yourself, set it up correctly, launched it, and now had somewhere safe to experiment.

Give Artists a Path

Once people could get into Unity, the next thing to do was to build a training path.

Thus the bootcamp transmuted into the Unity for Artists Wiki. It grew into a ten-volume learning structure covering setup and foundations through animation, 3D, materials and shaders, Shader Graph, VFX Graph, add-ons, post-processing, troubleshooting, and other practical needs. This wasn’t just regurgitating what was on Unity’s website – this was all bespoke material carefully crafted to our specific needs and internal middleware.

Alongside it was a task-based training program organized into four broad tracks:
Basics | 3D | Animation | Advanced

Artists could begin by loading a working game and importing or updating assets, then progress into scenes, materials, animation, particles, effects, shaders and more advanced systems. Artists could learn now at their pace, and to their desired level of depth. People knew where to begin, what came next, and where to look when they got stuck.

Build the Support System

Documentation alone isn’t enough.
Sometimes it’s far easier to just ask a Friendly Neighborhood Tech Artist, or some other person who already spent a week searching for that one check box that you know is there somewhere.

I created shared communication spaces where artists could bring questions, share useful resources, announce tools, and tag Tech Artists for help.

One piece of advice from my Unity for Artists presentation was: Find a swim buddy.

Learn with somebody. Ask the dumb questions. Share what you figured out.
The larger goal was to keep useful knowledge from disappearing into private conversations:

• Repeated questions became FAQs.
• Good discoveries became training material.
• Useful techniques became workshops.
• Recurring technical problems became candidates for tools, presets, prefabs, shared assets or documented standards.

Technical Art became an increasingly important part of our system as I set them up to be guides and trainers. Not to do things for the artists, but to teach them. If artists need a Tech Artist every time they want to replace an image, adjust a material or try an effect, you’ve simply created a new bottleneck.

Creating more tech-independent artists frees up TA’s to solve the harder technical problems, then help turn those solutions into something reusable by everyone else, such as prefabs, packages, shaders, tools, templates…
Give the TA’s some space, and let them surprise you with technical joys wondrous to behold.

Over time, Unity for Artists became more than a wiki or a curriculum. It became:

• An adoption system
• Training paths
• Bootcamp starter kits
• Practical assignments
• Sandboxes
• Troubleshooting
• Workshops
• Communication channels
• Tech Art support
• Shared standards
• And, most importantly, more people who could teach other people – Scalability

What I learned

Looking back at these arcs of getting teams into Unity, I see software adoption as primarily a change management challenge with a lot of software sitting on top of it.

• People need a reason to change.
• They need a safe place to experiment.
• They need a visible path through the intimidating parts.
• They need documentation written for the person actually doing the work.
• They need access to people who can help.
• And when the same friction keeps showing up, somebody needs to turn that repeated problem into a better system.

Technical fluency isn’t about knowing everything. An artist doesn’t need to understand every system inside Unity. They need enough knowledge to:

• Make better creative decisions.
• Understand what their work is doing in the engine.
• Recognize when something is expensive, fragile or reusable.
• Collaborate intelligently with Developers and Tech Artists.
• Experiment & test before handing an idea off.

Before I was a game artist, I was a teacher. I spent years in China training other teachers, building curriculum, creating practical lesson plans, and helping people become comfortable doing something they had never done before.

Years later, I went from barely knowing After Effects to teaching it. Then Unity. More recently, AI. Apparently I have a type.

I like finding something useful, learning how it works, figuring out how to apply it, and then turning around and helping other people do the same.

At AGS, I learned Unity.
At Intuicode, I helped build the bridge.
At Everi, I helped turn what we’d learned into a road other people could follow.

Learning it. Building it. Teaching it.

I suspect I’ll probably do the same thing with whatever comes next.

Credit / Context

Unity adoption across AGS, Intuicode and Everi was collaborative work involving Artists, Developers, Technical Artists, Production, studio leadership and central technology teams.

My role evolved from hands-on artist learning and implementation, to Creative Director helping lead an art-side engine transition, to Art Director helping build, organize and steward artist training, workflows, documentation, Technical Art practices and broader adoption.

Several training resources and systems shown here were collaborative works. Public-facing examples have been cropped, recreated or sanitized where appropriate.

NEXT CASE STUDY / LINK
use image