Portfolio

I’m a programmer, so this is going to be a text-heavy portfolio!

Highlights #

• Founding engineer on several game projects, including Marvel Snap
• Early adopter of AWS Serverless tech, primarily API Gateway, Lambda (running .NET), and Dynamo DB. This served as the substrate for Marvel Snap’s backend services and resulted in a problem-free launch.
• One of the first engineers on Hearthstone, started up our Unity project to get off of a custom engine
• Built the tech to make Hearthstone’s card mechanics, vfx, and audio feel extra crispy. Ask me about crispy!
• Created a UI animation system for World of Warcraft
• Wrote a game engine in C++ and Lua from scratch for Mecha Drop, my self-published, match-3 iOS game
• Maintain several open source Unity packages on my GitHub

My Background #

I began my career in 2004, working for a small company called Swingin Ape Studios on a project called StarCraft: Ghost during (not after!) college. The StarCraft: Ghost project was owned by Blizzard Entertainment, so when Blizzard acquired Swingin Ape, a month before I graduated, I became a Blizzard employee.

Ghost was canceled in 2006. I briefly joined Blizzard’s Web team before joining World of Warcraft as a UI programmer in 2007. After working on the Wrath of the Lich King expansion mainly, I became the main client and gameplay programmer on Hearthstone in 2009 and was there for 7(!) years. After that, I moved to a small incubation team in 2016 and immersed myself in the world of backend infrastructure so I could build out more of a project’s foundations from scratch.

Since 2016, I’ve been a generalist and have often been the first engineer on teams. I tend to be a good fit for bootstrapping large projects since I’m able to stay organized consistently, and can manage complexity as a project evolves dependencies. I’ve done this so often that I made a repo for it.

A lot of my work has been in Unity, starting with Hearthstone. And starting with Marvel Snap in 2018, a lot of my work has been building out modern .NET backends and tooling for games.

Notable Contributions #

After almost 14 years at Blizzard, I left in August of 2018 to become the technical co-founder of Second Dinner. Our first project was Marvel Snap. Since I moved from a big company with a lot of custom tech to a startup, I felt the need to be proactive in learning and keeping our project and IT up to date with modern techniques. I spent a lot of time following tech social media and reading tech blogs, primarily focused on building up backends since I foresaw that as my biggest challenge.

I designed and built a lot of Marvel Snap from the ground up, client and backend. There was a Unity prototype that was already being worked on prior to me joining Second Dinner, and a temp peer-to-peer-esque solution to enable multiplayer testing. But, I’d essentially scrapped the temp solution in order to plan and build the backend from scratch. We needed a high scale authoritative server solution, and I wanted to do it with as small an engineering team as possible. I chose AWS as our IaaS provider since, at the time, I drew inspiration from Supercell, Nike, and Coca Cola. I figured if it worked for their scale, it should work for our scale too! And if it didn’t, we would have a good problem on our hands! I drew particular inspiration from a couple of talks by Nike and GE engineers, whom both independently selected Dynamo as their database of choice. Dynamo DB is quite easy to get stood up, easy to use, and has super high scale out of the box. I also chose AWS Lambda for our compute layer as an early, risky bet because I was very doubled down in my head on aggressively reducing our company’s headcount and operational burden. Lastly, I planned to utilize plain .NET projects for our backend. I wanted a cohesive Developer Experience around C# to reduce the chance of silos firming up (different languages, different dev tools, etc), and I wanted to bypass the traditional game server route where game engine builds are deployed to long running server instances so that I could take advantage of existing investments being made by other companies in high scale web-centric tech. This worked out well in a couple ways. (1) I leveraged the existing workforce that Microsoft was throwing behind C#, ASP, and multi-platform development. (2) .NET on AWS turned out to be better supported in AWS’s FaaS offering than Microsoft’s own Azure FaaS offering!

The unique part that I had to figure out about this combination of tech I selected was how to re-use code between a Unity project and plain C#. I was pretty determined to do that in order for the client to have deep game state knowledge and the opportunity to play offline for as long as possible, like a good mobile app! After much experimentation and a clutch release of Unity 2018.3 with its new UPM package manager, I came up with a recipe that involves packaging C# code in a way that makes .NET projects and Unity happy. This meant that both client and server had full access to the same code for game logic, and utilizing the same json serialization libraries, could both save and load game states to their respective, idiomatic storage locations, in the same format.

This was all a big risk. The reality was that I had no prior experience with the technology nor the techniques I selected, and it all only worked in theory. My plans for this grand foundation all felt so perfect in my head that I refused to let it fail, so I got to work, putting all my theories into practice. I even developed a custom tool and wrote automated infrastructure provisioning using a combination of a custom dotnet CLI, CloudFormation, CodePipeline, and CodeBuild. I ran into a lot of hurdles that I overcame along the way, and I’ll write an extended blog post about all that, one day.

I also wrote the layer of our Unity clients that requested and cached any state received from the backend so that it could pick up where it left off in case of network and app termination disruptions. It’s important to me that an app feels well behaved and well engineered, so that it meets or exceeds audience expectations.

I was no longer at the company by the time Marvel Snap launched, but these techniques led to “an essentially problem-free launch”. I confirmed with several ex-coworkers that were present at launch, that the tech choices I’d made and tech I’d built were unchanged and still powering the game.

This is long enough already, but I also built out our outsource workflow by breaking up our project into more discrete packages so outsourcers could leverage the same Unity resources we were using, I built out our continuous deployment systems including integrating Cloud Content Delivery into our build system. I even built our Google Workspace automation (including SSO support for various SaaS providers). And documented tons of tech and mojo in Confluence.

I also spent a good 80% of my day in the first few months actively sourcing and recruiting as diverse a candidate pool as I could.

TLDR I got a LOT of stuff done.

I joined Hearthstone in the summer of 2009, when it was still known as Project Pegasus, and it was still an online port of the table top WoW Trading Card Game. Well, technically I went to work on Battlenet for 11 months upon joining, but that’s a story for a future blog post.

Hearthstone is famous for being an early Unity adopter, but most people don’t know that we were on a custom engine before that. I was part of the crew that made the decision to move to Unity (primarily, myself and our 3d artist, Zwick) after evaluating many engines. The finalists were Unreal 4, Adobe AIR, and Unity 3. Unity won because it was a joy to use and you could get a lot done fast. It took only 2 weeks to re-implement what took a year in the custom engine. Unreal was much slower to iterate on by comparison, and Apple really hated Flash so we weren’t going to lock ourselves into AIR since mobile was an important target platform.

After making that decision, basically EVERYTHING needed to be built for our game client. So I went about doing that! Our technical UI and game designers handled a lot of tutorial and initial glue code while I built the foundational client systems. That included asset loading, localization, loading screens, scene management, sound management, and a gameplay vfx system.

My primary focus was on gameplay and vfx. I originated the term cripsy to describe really good feeling game vfx, largely inspired by my love of fighting games. I was huge into Marvel vs Capcom 3 at the time, and even competed at Evo a couple times. So I leveraged that to help our artists make the game feel extra crispy. The first few iterations of the attack impact effects looked almost identical to some of the MvC3 visuals before they were iterated on to look how they do today!

One tidbit about localization: I wrote localization systems for both Battle.net and World of Warcraft, and I did it one more time for Hearthstone. On previous projects, my responsibilities were just grammar rules, like pluralization and Russian declensions. This time, they expanded to include client string management, asset swapping, and import/export tooling.

I started on WoW in mid 2007, a few months after ship of the first expansion: The Burning Crusade.

Most of my time on WoW was on its next expansion, the Wrath of the Lich King. In my humble opinion, that was the best expansion! I think a lot of people agree with me! My notable accomplishments were building the calendar UI and building a UI animation system from scratch since, prior to that, UI animations were few, hyper-specialized, and did not have a performant, idiomatic workflow. I built a couple features for Cataclysm (dual class and totem timer UIs) before leaving the team for what would become Hearthstone.

Something I still find funny and endearing is that one of my first features when joining the team, the party Ready Check UI, is still using my programmer art to this day, from what I can tell.

In the fall of 2004, at the beginning of my senior year of college, I got super lucky and landed a job as an intern at Swingin Ape Studios, on their shiny new project, StarCraft: Ghost. Blizzard had handed Ghost off from Nihilistic to Swingin Ape several months prior.

I started off doing editor tools but quickly moved to UI since the project needed a lot more help there, and it was an easier path to get into than the other subdisciplines at the time. There were only 2 UI programmers, including myself, and the game needed tons of UI. We frequently benchmarked ourselves against Halo 2, which was huge at the time, and set the standard for what a polished game product should look and feel like.

Considering most dev studios were using custom engines at the time, UI was a challenge. Ghost was a ton of fun to work on (and play!) and I’m still sad that it got canceled. We really knocked the multiplayer out of the park - we had fun game modes and all 3 races were playable with unique character classes that translated super well from the RTS to a third person action format.

Side Projects #

When I was a UI programmer on WoW back in 2007, I started building out a custom C++ game engine in my spare time, targeting Windows and Nintendo DS. I started wanted to keep my skills sharp outside of UI, not just be a UI programmer indefinitely. I called it Hope Engine because I was thinking “I hope this works.” In 2008, iOS exploded into the tech world, and it was the first time that on-device portable development had a low barrier to entry, so I pivoted to that. I also started a business called Bright and Shiny Games, LLC to make this feel like a real development and publishing outfit.

I released the first version of Mecha Drop in early 2011. I wanted to get something released to exercise my shipping muscles, but that version of the game had no characters, only 1 mode, and barely any art. I spent the next 4-5 years working on a V2 with characters, two modes, special abilities, backgrounds, and generally tons more design and art content. I outsourced and art directed the character, background, and logo art because I can’t draw to save my life. However, I did almost all of the VFX art impementation. I did all of the system and content design too. From that experience, I learned first hand that the hardest problem to solve when building a game from scratch is content creation iteration speed.

It was really difficult making a high quality game while working full time, honestly, and I ultimately decided to prioritize work. This means my engine is still on deprecated frameworks like OpenAL and Open GL ES 1 (fixed function, no shaders). Impressively, Apple has not dropped support for those frameworks yet! I’ll most likely have a fire under me to port the engine to AVFAudio and Metal when Apple decides to drop those frameworks.

I had to push out my long-in-dev V2 update in 2017, mostly since Apple was going to delist it from the app store for inactivity. I hadn’t finished the UI, 1 ability was missing art, and sound fx and music were absent. But the game was far enough along where it looked a lot like the game I had in my mind’s eye, so I put together some basic marketing materials and pushed out what was there. It started as a 99 cent game, but I quickly realized it wasn’t in a state where I felt comfortable charging for it, and I wanted folks to try it when I mentioned it, so it’s free now. I’ll find a way to monetize it when I have more time to focus on it!