This is the story of how I spent two years as an indie game dev, which culminated in a game called Atomic Armies. (If you’d like to sample the goods, you can play the single-player demo online.) During those two years I made a couple other games, a ton of mistakes, almost no money, and learned a hell of a lot about game-making, entrepreneurship, and myself. It was the craziest adventure of my life.
As with most tales of first-time entrepreneurship, mine begins with…
I was 26 years old. It was April in 2010. I was in a serious relationship with a girl named Karla (now my wife of 3 years), and I was starting to burn out at the tail-end of a successful visual effects career. My job was to hack together code that generated pretty visual effects, which I would render out and hand off to someone for compositing into TV commercials. This was contract work, and crunch time was common. I would do 60-hour weeks for a few months at a time, take a break for a week or two, and then repeat the cycle.
I loved the work when I first started but after a few years I was bored and exhausted. I wanted to build something new.
At the time, Mafia Wars had just put Zynga on the map, dazzling tech journalists, entrepreneurs, and VCs with the magic of social gaming. “Social” was the buzzword of the day (“mobile” and “local” would usurp the throne later). I decided this was my opportunity to quit my day job and seek out fame, glory, and riches. Because I was on contract, I simply stopped working when my current contract expired. And just like that I was unemployed: the definition of an entrepreneur!
But now what?
How I knew it was time to quitIf you feel like you’re getting less out of your job than you’re putting in, then you should quit. Common wisdom dictates this works especially well when you’re young and have fewer responsibilities, since that’s the best time you can take risks and recover from failure.
In terms of my job, I had become really good at writing one-off programs that generated interesting visual effects, but I had hit a plateau. I wasn’t progressing as a professional.
In terms of risk, I knew that in a couple years I was going to get married, get car loans, have kids, buy a house, and do all of that grown-up stuff. I felt like this was the best time to take a crazy gamble before life caught up with me.
It’s embarrassing to admit how clueless I was. Game dev is two things: make a game and then make money with the game. It’s not complicated, but somehow I managed to do everything but those two things:
When I think back on these mistakes, I like to remind myself that mistakes are learning experiences, and the important thing is to avoid making the same mistake twice. The common thread throughout all of these things was that I was planning for success, with the ironic byproduct of actually delaying any outcome, whether that be success or failure. I should have just focused on building stuff. Fortunately, after a few months of screwing around and wasting my time and money, I learned my lesson. I kept my money in a lockbox and focused on developing my first game.
Oh, how I wish I had cut out all that bullsh*tIf I could do one thing differently, I would have said “no” to more things.
I would have defined an MVP as my goal: some low-hanging fruit. Then I would have plotted out the shortest course to plucking it. I should have set a clear, specific goal of “making a fun single-player game.”
Then I should have asked myself, “What’s stopping me from accomplishing that today?” I would have ended up with a to-do list that would have inevitably to accomplishing my goal. And I bet you the remainder of my Real Legitimate Business™ checking account that creating an LLC and writing a business plan wouldn’t have been on it.
The game takes place after a nuclear war, and civilization has been wiped out. You emerge from your bunker and have to reclaim decimated cities, build your tech tree and army, and work with your friends to battle and defeat other players for resources.
The gameplay idea for Armies was simple: have units fight on a side-scrolling battlefield. You put your units on the left side. The baddies are on the right. The two sides meet in the middle and brawl it out with explosions and machine-guns and missiles and everything! I built this game with Flash (ActionScript 3) and a hand-rolled PHP and MySQL back-end, and put it on Facebook so you could battle with your friends. It was essentially an asynchronous multiplayer version of Colony, a Flash game I admired.
Beating your friends in battle would earn you resources, but the core game loop was a single-player portion that allowed you to attack cities. Conquered cities would earn you a slow, steady stream of resources.
When you launched an attack against a city or friend, you went through a set-up phase where you picked out your units and arranged them into battle formation on a grid. Between battles, you could buy more units with the resources you had earned.
On June 27, 2010, I had my friends beta-test on Facebook. The trolls in the crowd made the best testers. They loved discovering imbalance exploits (there were so many of them), and once they found a good one they would play for hours and harass everyone else. I will name names here: Damien Sutevski, Ben Shea, Ryan Groves. You made life hell for everyone, and for that I will forever be in your debt.
You may have noticed how ugly the art was in Armies. That’s my fault. I spent a LOT of time searching for an artist to help me, to no avail…until…
I hope he doesn’t take that honorific the wrong way. But he really deserves it.
On July 25, 2010, I found an incredible painting of a Marine battling Hydralisks on DeviantArt. It was painted by a guy named Trent Kaniuga, who was working for Blizzard at the time. His work was an injection of adrenaline directly into my eyeballs. I started drafting an email to see if he would like to work with me. I spent a couple hours just writing and re-writing it, trying to get it to a point where I didn’t sound totally stupid.
Then I hit send.
So maybe you’ve already heard pitches like this from other people who were dreamers and had ideas they couldn’t pull off. My only difference from them is that I’m taking Armies to completion and, if all goes well, profitability. So my question for you is: do you want to do a little work on what’s going to be the funnest, most badass, ground-breaking social game yet made? For uh, cheap? I would absolutely love to have your help.
So, if you ARE down to help out, you’d really be the coolest guy I know. Which is quite a laudable distinction and totally worth doing work for next-to-nothing for me. Oh, and besides an insultingly low amount in payment, I can also offer you my help doing the Flash programming of your next portfolio site. And who could say no that…?
Those are some choice snippets from my email. And, what do you know… somehow it worked! Here’s what he wrote back:
At first glance, I can see a great deal of potential in your future as a game dev. You’ve got a great attitude, and are very personable in your communications, as well as passionate about what you are creating. It takes a unique kind of personality to balance the artist, the programmer and the businessman, while also having good social skills.
In my opinion, [Armies] needs a complete visual overhaul. You need a distinct visual style that sets it apart from other games of its type. It needs to have a bit more flare, and polish. To do this, I’d want to have all new character images, and possibly 2-3 frame animations for each plus new background tiles. Menu and interface needs a slick new touch, perhaps with animations as you mouse over them. Also, you’ll need more interesting names for your unit types. You’re going to need a strong logo, and a better title.
This is known as the “sandwich method” of giving feedback. You lead out with a slice-of-something-nice (in this case, his generous compliments). Then you put a thick juicy slab of criticism in the middle, slathered with honesty and sprinkled with suggestions (I had crappy art, and it should be burnt in a pit and redone). And then you top it off with another slice-of-something-nice (or at least neutral) on the end:
I’d be interested in working with you on your next project. Sort of a… testing period. I’d like to put together something quick, and fun. Maybe a puzzle game, or something that can be made within 3 months of our free time. Polish it, test the hell out of it, balance it, and release it.
Remember what I said earlier about cutting out the bullshit? Trent already knew how to do that. As an industry veteran and a life-long creative, he had a ton of experience working on video games and building stuff.
Unfortunately, I didn’t listen to him! I wanted to make a big ol’ honkin’ social game, and make a bajillion dollars! I talked with Trent some more and he agreed to follow my lead and provide the art for Armies at a price point that worked for both of us.
Two weeks after I emailed him, he sent me his first sketch. It was GORGEOUS. No matter how bad the game itself was, at least I knew Armies was going to look beautiful.
How to ask for helpThe hardest part about asking for help is simply doing it. It’s like how 90% of a job is simply showing up. If you want someone’s help, just ask. But ask nicely!
Show respect for the person. Be honest about who you are and what you have (or don’t have) to offer. Show that you respect the person enough research them and familiarize yourself with their background. Point out specific things about them that you admire and value. Be clear in what you’re asking them for and why. Respect their time by spending your time making your email clear, well-structured, as brief as possible, and to the point.
Of course, none of these things guarantee you’ll get the help you’re asking for, but they’ll certainly improve your odds!
For the next three months, I crunched on Armies. I developed the gameplay, polished the UI, added new social game mechanics and other features, and Trent delivered the artwork.
On November 15, 2010, we launched the new, Trent-infused game, which we re-titled as “Atomic Armies”.
Trent got almost all of the things he wanted: a total visual overhaul with a distinct new style, and new character art and better unit names. He also got a better title and logo for the game, though you could debate how much better they are!
(You may have noticed that this game looks different than the first Atomic Armies screenshot I showed you, at the beginning of this story. This is because we actually made two different games but called them both Atomic Armies. This is the first one and arguably the worst of the two. We’ll get to the second one later.)
This first version of Atomic Armies had a bunch of new features:
Players could also store and watch replays of their battles. Each battle was completely deterministic: any battle fought twice with the exact same units and starting positions would unfold in exactly the same way! This meant that all I had to do was store those starting positions in the database (at very little cost and difficulty) to enable this feature.
I also developed a color-customization feature. I had this idea that players would really want to be able to customize their army by selecting a color for it. So I built a system that would accept artwork with two separate layers: a stroke layer and a color layer. It would then apply the player’s color as a hue-shift to the color layer. This did place undue burden on Trent, since the only trick was that I needed vector artwork. This wasn’t so easy to do, but Trent is an awesome dude so he went ahead with it anyway.
Another cool feature I built was an elaborate effects system for unit attacks and abilities. The medtruck unit could emit an undulating heal ray that arced out to heal friendly units. A simple physics sim controlled mortar rounds that were lobbed into the air and then brought down upon the enemy army. There were also sniper rays, machine gun tracer rounds, and laser beams. Check out the gameplay video below to see some of these features in action.
In late December of 2010, I decided to open the game to the public and start driving traffic to it. I created Facebook ads targeting people who played my competitors’ games. (The best ones got a click-through rate of 1.8%; much better than the typical 0.05% CTR for an ad on Facebook — I remember being very proud of this.)
Driving traffic to the game was only one step. I had three critical KPIs: stickiness (a measure of how often players returned to the game), virality (a measure of how many players recruited their friends to play), and monetization. By January of 2011, none of these numbers were very good.
In February of 2011, I realized that I had built some fundamental flaws into my game. The basic problem was that it played more like a casual Flash game than a social game. This is bad news for a game that’s supposed to be leveraging Facebook’s social channels for growth. Without these social mechanics, the game couldn’t sustain a multi-player experience. Not only that, it also didn’t have the content necessary for a good single-player experience.
I took a hard look at the codebase. It was messy. It was scary. Programming was a battle with code-bombs and logic-puzzles left behind by my past self. I doubted I would able to write the code necessary to fix the crippling gameplay problems, and being a one-man game dev team for 6 months had ground my spirit down to a nub.
But even so, I still had some fight left in me. With my back was against the wall, I decided to make a last-ditch effort to save Atomic Armies before declaring it a failure.
I submitted the game to 6waves, a large social and mobile games publisher. If I could get their marketing power behind the game, I could pull more players in and increase revenue. Unfortunately, they saw the same flaws in the game that I did and decided to pass.
“[The review board] liked the art style and audio, but the main challenges were the economy of the game and user retention based on the existing features. More specifically, the feedback was that there's not enough for people to purchase, the game is balanced such that users run out of coins too easily and there aren't enough motivations for users to come back to the game.”
I thought there was a chance I could fix Atomic Armies’s problems if I had more developers, but I needed money to pay them. So I asked Trent for his permission to portray him as our offical Art Director and I put together a pitch deck to shop around with angels like Paige Craig and Tech Coast Angels. While I think I did a good job with the deck, it wasn’t enough to hide the problems with Atomic Armies, and I found no takers.
So I thought, “Well, if nobody wants to invest in us, maybe somebody will buy us?” In March, I went to SF and met with Zynga’s Head of Corporate Development, Terence Fung, to see if Zynga would be interested in purchasing Atomic Armies. While I had a great visit with Terence, it was clear that an acquisition was not a possibility. I remember at one point I just asked him: “For the love of Zeus and all that is holy, what do we need to do to get acquired by Zynga?!” (Re-enactment has been dramatized.) I don’t think he quite knew how to answer that. There was really no compelling reason for anyone to purchase a game like Atomic Armies or a “company” like Elevated Games.
This is what happens when you set the wrong goalsWe were undeniably in a bad spot at this point. But how did we get there?
I could say something about how our funnel was wrong: low replay value leads to low virality leads to no revenue. Or I could say I didn’t understand the acquisition market. Companies don’t buy games, they buy numbers: a run rate or a user base and we had neither.
But I think the root cause goes deeper. It goes all the way back to my earlier point about setting a goal, having a plan, and cutting out the bullsh*t. If I had set my goal as “having a successful social game” then I would have identified a large player base as a requisite. I would’ve known that I had to make the game incredibly viral to get the number of players I needed. That level of virality would have required strong social mechanics. Building these kinds of social mechanics would have required a robust metrics system and a clean, maintainable codebase for fast iteration.
If I had had this plan, I probably would have realized how unattainable my goal was and I would have chosen a simpler goal!
Beyond that, having an executable plan would have kept me focused on the important things, not features that I just thought were cool. I would have been able to track how closely I was following the plan, and I would have been able to anticipate failure early on and make course corrections.
In February of 2011, I had a heart-to-heart with Trent about what was going on (read as: I fessed up to all the things I had done wrong). I was way out of my depth as a game dev. I also felt like I needed him to take more creative control; I just couldn’t do it alone. Out of that conversation about what we had done came some thoughts on what we could do next, and what we could do better. We started looking to the future. We were in full-on creative overdrive, riffing on some exciting new ideas for a new version of Atomic Armies, and I felt energized again!
Trent wanted to take the game in a more story-oriented and visual direction. He whipped up some storyboards to communicate his ideas. They were awesome!
On February 23, 2011, I used his assets to create a rough prototype where you could place bunkers and marines on an isometric surface, and watch them shoot each other. While I was in SF, I demoed this prototype for a room full of programmers at a local meetup, and they loved it! Suddenly, I felt hope.
Then, a game on Facebook caught my eye: Backyard Monsters. This was an isometric war game, in which you built up a base and an army, and used your army to attack your friends’ bases. And it had attracted a devoted following of players who absolutely loved it. I saw possibilities of marrying these gameplay mechanics with Trent’s new creative vision. After talking it over, we decided to go for it.
The more trust you put into a partnership, the more awesomeness comes outIt took time for Trent and I to figure each other out. We needed to learn each others’ strengths and weaknesses, and earn each others’ trust. This meant that I was initially very cautious with Trent, and relucant to give him too much responsibilitiy.
In retrospect, I wish I had shared creative ownership with him sooner. I think creative individuals like me and Trent do their best work when they have creative control. If we had established a work relationship based on shared ownership earlier on, then I think we could have produced better work, more quickly.
A partnership is also about using each others’s strengths to protect against your own weaknesses. In a complementary partnership, you’re less likely to make stupid decisions because you have multiple viewpoints on a situation and you’ll be compelled to compromise with one another. Trusting partners take advantage of that.
I had a dream: Atomic Armies would be Facebook’s StarCraft! We would bring hardcore gaming to the masses! Nobody else was doing anything like this. It was an ambitious goal. We spent eight… friggin’… months rebuilding Atomic Armies as an isometric war game.
So try the single-player demo! It will be the best 5 minutes of your life!!
Oh man. Almost immediately upon starting work on this new version of Atomic Armies, the challenges starting piling up. Here were some of the biggest hurdles we encountered out of the gate:
The first version of Atomic Armies only had unit art. The units only faced in one direction, and there weren’t any animations. But the new isometric version of Atomic Armies would need a ton more art for the units: walking, attacking, and bloodily-explosively-dying animations, and artwork showing each unit facing in 5 different directions. We were also adding building art into the mix, some of which would also need animations. All of this art created an enormous workload for Trent.
All of our animations needed to be stored as spritesheets, so I built a special tool for Trent to use to convert his artwork into game-ready assets. It took a lot of time to write the code for this tool and keep updating it to meet our evolving needs.
I also needed to create new bases for the NPCs in the single-player campaign. I needed to be able to quickly build or tweak a base and then try out an attack in the game to see if it was fun. To do that, I wrote an app called AtomicEditor which would let me import and export bases as CSV files, which I could then test in the game. This was another tool which took time to build and maintain.
We couldn’t build many of the features we wanted without first writing a ton of subsystems to support them. To name a few, we needed an animation system, a tutorial-scripting system, a dialogue-scripting system, and resource-production and resource-management systems. Though I had become a much better programmer since the first version of Atomic Armies, this was still very much a learning experience for me.
The core shift to an isometric game meant that I had to store the location of all renderable game objects in isometric game-space, and then map their coordinates to screen-space when rendering them. Fortunately, As3isolib solved this coordinate-tracking problem for me (and I became friends with its author, Justin Opitz).
However, performance was an issue. Walls were composed of individual blocks, and players would need to build a lot of walls. Rendering each of these blocks as layered sprites slowed performance down to a crawl. I solved this problem by rendering each game object to a single bitmap, and then displaying that bitmap each frame (this process is called blitting).
But then this created a new problem: hit-testing. With mouse events being dispatched from a single bitmap, how could I tell which game object the cursor was currently interacting with? My solution was to blit a uniquely-colored silhouette of each game object to a separate bitmap. To correlate mouse position with a unit, I would determine the color of the pixel that the cursor was over, and then use this unique color to identify the corresponding game object. I created an open source library called Blis (BLitting Isometric System) to handle this logic.
Trent foresaw a lot of these problems, way early in the process. Here’s something he wrote to me on April 22, 2011, when we first started the pivot:
The primary problems that we will face will derive from the complexity of design for a project of this scope. We haven’t even gotten to the part where we are actually making a game yet. AND NOT unreasonably btw… with such limited resources. Building the assets is only a part of the game development process. This is kind of why AA 1 was not so fun. Hardly any time was spent on the design.
Normally, a designer would be steering the boat on what unit types, and building values we should be developing. So we are very much “feeling it out”, hoping that it comes together later. But we kind of have to do it that way since we are only 2 people. This is what I mean when I talk about the scope of the project being too large. This is another reason why I pushed for a simpler project.
Trent was good at pointing out core problems with our goals and suggesting reasonable solutions. I was good at not listening… :P
Instead of trying to solve every problem myself, I took liberal advantage of some of the great third-party tools that were available.
One of the best things to come out of this game-dev odyssey was that I discovered my deep passion for UI and UX development. I spent waaayyy too much time fine-tuning things like visual appearance, transitions, animations, and interactive states to make every little micro-interaction as fun as possible (when I probably should have been refactoring code or improving the game mechanics).
I also worked motion-based cues into aspects of the UI.
On October 18, 2011, eight months of work, we launched the new and improved Atomic Armies! A week later, I made a design doc to capture our vision for the game and outline where we were going to take the game over the course of the next few months.
Seeing the future in clearer detail also made it apparent that we still had a lot of work to do. The game we had launched was only partially complete. We were missing tons of content and features, we hadn’t spent any time developing the game mechanics, let alone the social mechanics, and there were plenty of bugs to fix. But based on how much time it had taken to get this point, and how much farther we needed to go, it seemed like the game was going to demand a lot of time. Possibly more time than either Trent or I had.
Not only did the game still need a lot of work, but I had come to realize the codebase was messy and too unwieldy for me to get work done quickly or easily. I had written myself into a corner: the game was in a playable state, but not an iterable state. I started to re-architect it, but the enormity of the task at hand was daunting. And every day I spent refactoring and re-architecting was a day not spend on adding sorely-needed features.
Ultimately, I had to acknowledge that although we had a fantastic vision for Atomc Armies, it seemed very unlikely that we could deliver on it.
If that wasn’t bad enough, the market we were in was also shrinking. Social games were losing their share of the casual games market to mobile games. Even Zynga was experiencing growth problems due to a failure to shift focus to mobile. I briefly explored converting Atomic Armies into a mobile format but I didn’t have the time, experience, or resources for this.
And the truth was, I was also exhausted.
Life was also starting to get very real for me. I had proposed to Karla over the summer (she said yes, bless her patient, forgiving heart). We had started planning our wedding, and it wasn’t going to be cheap. I had been eating Subway pretty much every day, living like a college student, and my health was suffering, but my savings were still hurting after two years of almost no income. I had to face it: to make the future I wanted for me and Karla a reality, I would need to make money. It didn’t look like Atomic Armies was going to be a cash cow any time soon, and I was burnt out on game-dev.
I needed to take off the entrepreneur hat and get a full-time job. But in what? Games? I took stock of my current situation and realized that I had spent two years learning about things that were now basically worthless:
There was very little demand for the skills and knowledge I had worked so hard for. What was I doing with my life? What the hell was I going to do now? Doubts ate at me. I started sweating when I thought about it too long. The big blank future had me scared sick.
I spent some time interviewing at several social game companies and found them all incredibly depressing. I interviewed at Riot Games and though they were and still are an amazing company, the role was for building UIs in ActionScript 2. ActionScript 2! Thanks, but no thanks. Eventually I decided I didn’t really want to work in games. I needed something new.
I remembered that my favorite part of working on Atomic Armies was crafting the user experience. I loved building things that people could interact with. I wanted to build products. Over the course of the next four years I pursued this calling. It took a lot of hard work, but I gradually built a successful career as a UI engineer and front-end web developer.
Bills got paid, Karla and I got married, Trent attended our wedding, he and I are still friends and collaborate on projects, and now I can look back on this incredible-and-somewhat-nightmarish journey with relief… because everything worked out in the end!
Well, I’ve been trying to point out things I did wrong along the way (and what I could have done differently). But my core lesson is that I learn best from failure.
I think it’s pretty awesome how much Trent and I did. I think Atomic Armies would have genuinely been great. Just look at games like Clash of Clans and Mobile Strike. I believe that if we had had the right resources and a well of experience ot draw upon, we could have done very, very well. Games were definitely ready to get more “hardcore”. But even though I read the market right, I didn’t have the ability to execute on my ideas.
A messy codebase slowed development to a standstill. I was a relatively inexperienced developer when I started working on these games, and I made many common architectural and design mistakes. I didn’t have a good understanding of the Model-View-Controller or Entity-Component-System architectures, and I didn’t understand how to apply SOLID principles to create maintainable code. This resulted in a codebase that scaled very badly. The more code I wrote, the more difficult it became to maintain. Eventually, I couldn’t write any more code.
The visual style was too dependent upon artwork. Trent’s artwork was what basically set Atomic Armies apart. But this was a huge burden to place on a single artist, even someone as badass as Trent. This created a bottle-neck in game development. If we had chosen an art style that was simpler (think: Tetris), we could have spent more time testing the game and developing the gameplay. In other words, instead of making it a better-looking game, we could have made it a better game.
We had too many game mechanics to fine-tune and balance. Atomic Armies had war simulation mechanics, multiplayer mechanics, social mechanics, and virtual economy mechanics. A game with this many complex interacting mechanics is difficult for even large, experienced teams to get right. It was an impossible task for a single inexperienced developer and a single artist.
Set realistic goals. Know your limits. Know where your passions lie. Set conservative goals that keep both in mind.
Have a plan. Form a step-by-step plan that leads to your goal. If you’re deviating from the plan, ask why. If it’s because you’re losing focus, change what you’re doing. If it’s because your goals were wrong, change your goals.
Build a team. Find talented people who want the same goals as you, and trust them. Ask them for help, lean on them for support, and let go of control. You have more to gain than you have to lose.
Most importantly, live a balanced life! Overwork doesn’t work. You’ll burn out and end up losing productivity. Take time to relax, let your mind decompress, and recharge your batteries. Part of this includes finding time to do a body check and make sure you’re on the right track toward reaching your ultimate goals of happiness and success.
I just want to say thank you to my wife, Karla, for all of her support during this entire crazy period. She kept me sane and focused, and I am so grateful to her for not trying to talk me out of going unemployed for two years. Thank you, Trent, though I know you’ve already heard me say it enough. And thank you to all of my friends and Trent’s friends who beta tested our games. Thanks for taking the time to play them and point out all of the bugs and imbalances you found. You know who you are.
And thank you, Reader, for taking the time to read about my crazy quest in game-dev! I hope you enjoyed reading about it as much as I enjoyed writing about it.
— CJ Cenizal, May 10, 2016