



Awesome concept art by Kit Seaton

The transition from being a AAA game programmer for a decade to a solo indie game developer in 2020 has been an adventure. Having worked on teams of hundreds, making games for millions of players certainly helped immensely with my work on Kinematic. But not every lesson from my previous experience is useful. I've had to unlearn a lot, and find nuance in other areas.





In this blog post, I'd like to present 3 similarities and 3 differences between my time in AAA and solo indie. Hopefully these could be food for thought for developers on any sized team.





Similarity 1: Iteration is Key





Think of all the things a game programmer could optimize for. They could make the game run fast, or on different hardware. They could build cutting edge AI, physics, networking, rendering, sound, narrative. They could make the engine stable, extensible, moddable.





If anyone ever asks me the most important thing to optimize for, no matter what game you're making, the answer is simple. Optimize for iteration. You win every time a human with a skill looks at the state of the game, makes a change, and observes whether the game is better. Make the code easy to modify, and build times short, so programmers can iterate quickly. Make content hot-reload reliably in a short time so content creators can tweak and tune even the tiniest of values. Optimize launching the game into configurable, useful states. Make debug tools to short-circuit lengthy processes. Build the right tools.





What do I mean, "the right tools"? You're looking to speed up tasks that are high on these axes: frequently executed; easy to mess up; high in steps, but low in required expertise, aka "robotic"; annoying or frustrating; slow.





Indie Difference 1: Teaching/Onboarding Aren't Needed





During my time as a AAA tools programmer , I spent a ton of time thinking about onboarding new users. When several hundred people with wildly divergent skillsets are going to interact with a tool, the User eXperience is extremely important. A powerful, but non-obvious tool that could save a handful of developers dozens of hours is probably less important than a simple improvement that saves every developer ten seconds a day. To be a great tools developer, one needs to deeply understand each discipline that will use the tools, in order to make the right decisions for each of them. Often, I would find myself making something that felt intuitively wrong, because after talking to some e.g. FX artists for a while, I discovered a difference in our mental model of what the tool should do.





When I'm developing by myself, I can rely heavily on my specific expertise, and my intuition. If a complex regex query can get the job done, I don't need a better tool than that, because I love regexes. If only a programmer with 15 years of C++ could use a pixel art tool, that's cool. The only person using it has 15 years of C++ experience.





Similarity 2: Task Tracking Helps





I think of task tracking as some system beyond one's brain and a handful of sticky notes to keep track of what one is going to do. Most commonly, it will be Jira, Trello, Monday, or some other ticket tracking software. The parts I've seen be most helpful across both phases of my career:

Storing a backlog. When you have a great idea, it takes up space in your brain. If you write it down, that helps reduce the noise. If you deeply trust that once it's written down, it will never be forgotten, then you get to completely remove it from your brain, in favor of other new ideas. Then, later you can look over the backlog and be reminded of all your great ideas, and choose the right one to work on now.

Planning a milestone. Working on a coherent chunk of work with a specific timeline and goal is satisfying. It helps make sure all the required pieces are being built. And it makes sure that at the end of the milestone, the team will have something to show for their efforts. It also gives the team a chance to practice estimating, in order to better plan future milestones.

Sense of accomplishment. It's easy to forget what I did yesterday, let alone last week or last month. But making a game can take months or years. That's a long time to maintain motivation. Having a list of accomplishments on whatever timescale I want to look at allows me to top off the tank whenever I'm feeling down, like an impostor, or like nothing is getting done.





Indie Difference 2: Flexibility > Predictability





Imagine I'm building some tech that the designer needs to finish their scripts so the animator can make an animation that the VFX artist will enhance before the sound designer can begin to make SFX. I really need to get that tech done on time, otherwise everyone else will be delayed in a monstrous chain reaction. So on a large team, it's extremely important that my work be predictable, for dependency tracking.





Imagine, instead, that today I can be a programmer, a designer, an animator, an artist, a sound designer, a producer, a QA person, or some combination of the above. Maybe I woke up early, drank my tea as the sun rose, and had a great idea about the color palette of a new area. It doesn't matter if I was planning on doing some bug fixing; I should definitely take my inspiration straight into Aseprite for some pixel art. Or maybe I'm feeling like I haven't gotten anything concrete done this week. It might not be coming up on my schedule, but I could work on porting my engine to Vulkan because I love graphics programming, and I've wanted to learn about Vulkan for years.





Basically, when you're responsible for a ton of jobs with no one waiting on any particular one, it can be very valuable to work on whatever feels right on a given day, rather than rigidly forcing yourself into particular parts of the work. (Obviously this can be taken too far; the game does need to be all done at some point)





Similarity 3: Contagious Tech Debt is Dangerous





I continue to think about Contagion in tech debt as an indie developer. A bad decision made once in a contained location likely has minimal impact. Or if it has a large impact, it will eventually be discovered and easily fixed, since it's contained. A bad decision that spreads through the code, or even worse the data, becomes difficult or impossible to root out. Worse, it can slow iteration to a crawl, as the impact of every change becomes unintuitive and difficult to predict. I think paying attention to the contagion of tech debt is something every technical game developer should be doing, regardless of the size of their team.





Indie Difference 3: I See Contagious Tech Debt





Probably my favorite change in moving from AAA to indie is that I get to see the consequences of my tech decisions firsthand in all circumstances. I don't have to worry about what the data built on top of my new feature will look like in a year when I've forgotten about the feature. I'm the one making the data every day. So if I notice that the data I'm making smells funny, I can immediately stop what I'm doing and fix the structure, before I make things worse.





Conclusion



