Doug Holder gave a talk on his career path and the development of the Unity-based game EXE: Mainframe: art style, level design, VFX, controls and more.
My name is Doug Holder. I’m a Game Designer in Los Angeles, originally from Dallas, TX. I started my games career at Naughty Dog and most recently worked at Infinity Ward and Snapchat. A few games that I’ve worked on include Uncharted 3, The Last of Us, Left Behind (Last of Us DLC), Uncharted 4, and Call Of Duty: Infinite Warfare.
I always knew I wanted to work in the art field and enrolled in the Art Institute of Dallas after high school. At the Art Institute, I shifted focus between animation, character modeling, and concept art until finally landing on compositing and post-production. After graduation, I began working at a local post-production house and was there for about 3 years. Although I enjoyed working there, my ultimate goal was to make it out to California since this is where most studios are located. A studio in Pasadena named SunnyBoy Entertainment basically shifted my entire life in a massively positive direction when they offered me a job to work on the show “1000 Ways To Die” for Spike TV. I was very dedicated to the post-production industry at that time and finally getting to California was a huge part of moving my career forward.
While I was working on the show, a friend of mine told me that Naughty Dog was looking for an FX Artist. I honestly didn’t think I had what it took to work for such a renowned studio, at least, not yet. I loved the Uncharted games and I was a big fan of Naughty Dog. I wanted to work in games but my plan was to try to work my way up to Naughty Dog. I applied anyways and was shocked when they contacted me and asked me to take a VFX test. I took the test, sent it back to them, and got a call for a phone interview the next day. Within a couple weeks, I was sitting at a desk staring at Nathan Drake in the engine. All I kept thinking was “Somehow I’ve tricked my way into this. This cannot be real.” I had to quickly learn to stop seeing my coworkers as the heroes I envisioned them to be and more as my peers. Naughty Dog was and still is a huge part of who I am as a developer. They allowed me to grow over the projects and be able to transition into a Game Design role. I learned about gameplay scripting in the engine and creating shaders for particle effects which led to me taking classes in my free time in programming and maths. That’s pretty much how my entire game development career started.
EXE: Mainframe: the Idea
EXE: Mainframe came about through kind of a little experiment of experiments. Some of the other devs at Naughty Dog and I created a little group called “Lunacy”. The idea was to come together once a month and show each other something we were working on in our free time. My first idea that I ended up putting out for free was a game called ThumbderDome Wrestling. The whole point was to teach myself another code/scripting language through Unity and try to make something as fast as possible. When I finished that idea I started to experiment with other ideas. I’ve always had this itch for 80’s and early 90’s arcade shootem-ups and neon colors. I wanted to make something visually different than what I was doing at work to challenge myself to make something a little more unrealistic and less grounded. EXE: Mainframe was born from my love of arcade games and synthwave music.
Originally I knew that I would be the only person creating the assets for the game so I had to make something that still appealed to me and was within my abilities. I decided to keep the art scope low but I didn’t really have a clear idea in my head of what that was. This whole process was still new to me so I was kind of winging it. I’ve been very fortunate to know some hyper-talented concept artists, one of which is Janice Chu. I really like her art style and she’s also a passionate gamer as well. She took the loose ideas and references I had and created the characters and visual design of the world. The pieces she provided were exciting and guided me all the way to the end. I chose this low-fi 80’s inspired design because the entire look is focused on shapes and bright colors. This felt like a perfect fit for something that moves quickly and would allow the player to see everything happening on screen.
Technical Side of the Game
I chose Unity for this project because I had become very comfortable in the engine and the community around it is very strong. There is a lot of community support and the asset store is incredible. I’m also a fan of writing code by hand so working in C# was a big part of why I chose it. The engine has a pretty small footprint by modern gaming standards and the documentation for Unity is very well kept. The game itself isn’t that technical which I’m sure at a glance isn’t surprising to hear. There are several things I’m technically proud of that didn’t make it into the final build. I used quite a few plugins such as Shader Forge and Pro Builder. It’s very easy to customize your game and mechanics inside Unity.
The original scope of the game was really big. Much bigger than it should have been for just me to accomplish. I played with the idea of one day having funds to build a small team around it and I blocked out several levels in the game. Eventually, I boiled the game down to its core loop and made it an endless survival shootem-up. There is only one arena but I procedurally spawn pillars throughout the arena that can be destroyed dynamically. I don’t instantiate them over and over though so after each wave, I clean them up and respawn them again. The enemies after the first wave are random but the types of enemies that get introduced become more difficult as you move through each wave. The arena also begins spawning random hazards you have to dodge through to avoid getting hit by and the whole things just keep getting harder and harder. A few people have made it very far before dying – farther than I have.
By now you know that I started out as an FX artist so that’s always been my bread and butter. The game is very FX heavy and is a huge part of the games aesthetic. I created over 150+ effects in the game and a lot didn’t make it into the final build for scope reasons.
I approached the FX in the game the same way I approach them for AAA game development. I looked at a lot of inspiration in movies like Tron and 80’s cartoon intros like Thundercats. For the weapon FX, I would just imagine something crazy and then try to make it the way I saw it in my head. I typically start with some simple particle to get the basic movement and feel of the effect, then I start to layer in some secondary emitters to add more interesting movement and aspects. It’s important to make sure that secondary emitters and layers don’t confuse the player as to where the actual damaging part of a projectile is. I used the stock particle system in Unity (Shuriken) to create the effects for the game.
While I’m working on an effect I start to create the materials for that effect. This is where the really interesting work is done because the shaders and materials control so much of the final look and it takes quite a bit of math to come to the look I’m looking for. I don’t like to use very many “flipbooks” for my effects. “Flipbooks” or “sprite sheets” are rendered animations on a single texture that get cycled through over and over. The problem with this method is that it becomes very easy to spot the same animation on multiple particles and the more frames there are in the animation, the less resolution each frame will have because they’re all on the same image.
Instead, I opt for a more procedural approach. I create shaders that rely on a few low res textures to create dynamic UV distortion and this gives me more randomness in each particle. The game engines time clock moves these materials textures around and I can offset each particles reference of the material individually. So each particle will have a different starting time in the textures movement making them appear more random. The drawback to this method is that each particle becomes a little more expensive when they stack on top of each other so to optimize, I just control the counts and keep an eye on the GPU cost for each material.
Most of my effects use the same exact shader but have very different values and textures plugged into them. This is a technique I learned while working at Naughty Dog. I relied heavily on the plugin Shader Forge to craft the majority of my shaders. When it comes to shaders I prefer node-based editors because it’s faster to experiment and shaders for me are not an exact science. You’d be surprised how many great things in games were a complete accident in development.
Helpers from Unity Asset Store
The Asset Store for Unity was a life saver. As I mentioned, I used Shader Forge for my shaders but I also used a few others as well. I used Holo UI Gui for my UI assets, Stylizer for my post effects, InControl for my input management, ProGroups and ProBuilder for in engine asset building, and Fracturing and Destruction from Ultimate Game Tools. InControl was a huge help because Unity doesn’t handle multiple types of controllers very well. I was able to detect and assign the same input values across multiple controllers such as XBOX, PS4, and Keyboard without having to write complicated checks myself. I modeled all of the characters and most of the art myself since it’s all very simple geometric shapes. In the beginning, I was determined to make everything myself but you quickly realize that you have to accept your limitations and take advantage of opportunities to improve your project where you can. I might just be projecting but you have to set aside your ego a bit.
When it came to lighting, I experimented with a few different things. I’ve worked with some amazing lighters and I’m ashamed to say I never learned very much. This is another area where I knew I would be limited in what I could achieve so I chose to use a movie like Tron Legacy to inspire. I lit objects using reflective surfaces and emissive details. Most of the materials in the game have emissive details using masks and the non-emissive areas receive direct and indirect lighting. I think I was able to fake quite a bit which kept the GPU performance higher and I relied very heavily on LUTs (Look Up Tables) to control the final image from a post-processing perspective.
The controls were always an ongoing process, even until the final day before I shipped. Twin stick shooter games and any game using two sticks is always difficult. Any time you introduce another mechanic, you’ll think to yourself “Oh, this should work fine if I put that action on this face button like X or B”. You test it and realize that the player has to take their hand off the right stick to press a face button and then it feels wrong. That “feeling” is what you’re tying to perfect. The controls need to feel intuitive and actions the player uses shouldn’t interfere with the flow of movement or other actions they’re trying to perform.
Before I assign a mechanic to any action on a controller I pretend it’s in there and I instinctively press a button that feels right given the context. For example, the “dodge” ability in the game is mapped to the left trigger button. The left trigger is an analog axis usually reserved for actions that require precision as the trigger is pressed. Here I used it for a binary button like purpose because it needed to be mapped to a button that allowed players to keep moving and shooting while they performed it. Then I have the desperation move “format” which clears all enemies on the screen mapped to the “Y” or “Triangle” button. This locks the player into an animation where they can’t move so taking your hands off a stick has no consequence. Controls in most of the games take place on the shoulder buttons and the triggers to keep the player feeling in control and flowing through enemies. In games where the movement is fast and the actions are happening by the second, you want players to feel like they have almost a John Wick like level of control.
Publishing the Game
The game got stuck in development when I decided I was going to sell it. I had hoped to maybe secure funding to make the game bigger and into the more elaborate story-driven experience of the original scope. Because I was working at other studios during most of its development, I had to make sure I wasn’t in violation of any conflict of interest agreement. I work as a game designer by day so if I wanted to sell the game I needed permission to do so and, in most cases, it’s a hard “no”, which I respect and completely understand.
Activision put in place a very honest and great system that allows employees to present their project to a committee and they then determine if there is any conflict of interest. If a possible conflict of interest is determined then they give you the option to continue working on it but agree to a right of first refusal. The only downside is that you can’t seek outside funding for development. It has to all be on you and your dime.
Once I left Activision I was no longer in any kind of conflict of interest but I was still bound to the original right of first refusal agreement so I sent them the game knowing it had been reduced in scope and they politely passed. I chose to self-publish the game on Steam which was a great learning experience but was also a huge task to undertake. There are so many little legal business things you have to account for and I personally like to make sure I’m doing things by the book. Steam was actually very straightforward and they have a great system in place with Steamworks. They mostly guide you through the entire process and alert you when something isn’t complete before release. I really wish I could have published the game to something like the Nintendo Switch because I think the controls would have worked well on the portable version of that platform but console publishing has a few more ropes to jump than PC.
If you found this article interesting, below we are listing a couple of related Unity Store Assets that may be useful for you.