Back in 2014, I wrote an article for Gamedev.net. In the subsequent weeks, it boomed (retranslated in Russian, Chinese, etc.), as it appears I had laid my finger on one of the most prevalent questions among hobbyists: how does one go about Getting Games Done?
The disclaimer notice of the article was “This article is aimed at hobbyists/indie developers with limited spare time to dedicate to their projects. It seeks to help them increase their motivation (and finish their projects) all the while improving their working environment setup and productivity.“
Today, I’d like to revisit the same topic, from the vantage point of someone that has turned said hobby into a full-time gig and expanded it into a full-fledged, successful startup. Many of the things I said at the time still hold true today, but it warrants exploring the question under a different angle, especially in light of the outcome.
Do I want to get this game done?
The first question to address is this: Do I want to get this game done?
However silly that may sound, I feel a lot of developers (myself included) often overlook this very important first step which, if left unchecked, will lead to frustration and confusion down the line. Let’s face it, there are numerous reasons why you may prefer not to get a game done. Perhaps you enjoy the indefinite and iterative nature of it, perhaps it is more of an intellectual pursuit, etc. All of these reasons and more are reason enough not to get a game done. If it is your case, I would only recommend that you come to terms with this reality, and that you enjoy the journey for what it is: you may learn, and enjoy yourself, but the game is unlikely to ever get done, and there’s actually nothing wrong with that. The sooner you know, the sooner you’ll feel at peace.
Understandably, the rest of this article is aimed specifically at projects you’ve decided you wanted to get done. Either because that’s where you are in your life, or because the concept simply feels like it needs to be executed. Regardless of your reasons, the project became far more pragmatic, and requires a much different mindset…
On the importance of having a system
Once a developer has decided that they want a project done, the logical next step is to adapt to a new system that will facilitate that goal. There are various schools of thoughts on which particular model to adopt, but I believe that the need for such a structure itself is universal. In addition, before venturing into the need for a team or funding, one needs to optimize that which they do control, and facilitating development into a routine is probably one of the best low cost / high reward strategies to implement.
The following are merely notes extracted from my own system, which allowed me to proceed. I don’t necessarily believe this will work for everyone, as each person’s reality is fundamentally different, but it is a good starting point to exemplify the need for such a system.
The first thing I noticed when I started becoming more serious about my work is that I happened to implement, by accident, a routine that felt natural. I humbly called this routine the “5,1,1” routine in the past, and while it certainly worked for a time, I’ve since changed, simply because my situation has evolved. But to this day, I still value how the “5,1,1” led me to where I am, and believe it a good starting point.
To better understand the routine itself, it makes sense to understand my situation at the time: I had a day job (as most probably do when starting on such a journey), and lots of responsibilities (kids, etc.) that left me with very limited time. As such, I needed a model that allowed me to channel most of my spare time into this project.
Before delving into what the 5,1,1 routine actually is, let me lay down the practical objectives that I was pursuing with said routine:
1. Remain motivated with the project by working on fun features most of the time
Up to that point, most of my non-professional projects had been hobby projects that simply wouldn’t get done, and I correctly identified that something eventually affected my motivation mid-project, causing the inevitable end.
2. Deliver shippable increments of functionality regularly (sustained velocity)
I hypothesized, in part correctly, that one of the reasons for my own personal projects graveyard was the inability to produce noticeable results over time and needed a model that would prevent this from happening so that later stages of development would not lead to cancellation
3. Perform a constant health check of my code with limited effort
I also made the partly-correct assumption that technical debt was one of the reasons why some of these projects would not be completed. For those unfamiliar, the concept of technical debt can best be summarized as the increased amount of time necessary to add features to a project that are due to the accumulation of bad code and limited solution architectures. In essence, the more you ‘prototype’ the more you dig yourself into a hole for late-stage development (though prototyping may be desirable).
The 5,1,1 routine explained
The premise of the 5,1,1 routine is that the single most important factor to getting a game done lies with the ability of the developer to deliver increments of functionality at a steady pace. Essentially, a project will only get done if an external eye to the project sees consistent progress throughout longer periods of time.
…constant progress trumps crunches.
That is to say that constant progress trumps crunches. Long before getting games done, I was prone to be a ‘crunch’-oriented developer, sacrificing a weekend here and there to try and get some momentum behind an idea. There are various reasons why this was suboptimal, and why changing to a constant albeit slow grind was more desirable. I’m certainly not disputing the value of the development ‘spree’ (as can be evidenced in gamejams, notably, where ‘flow’ is prevalent) but it is a different tool for a different purpose.
So what’s this cryptic 5,1,1 routine? It is essentially a representation of the workflow over the course of a week through 3 separate axes. On any given week, the 5,1,1 routine assumes the following:
- There will be 5 Dev Days
- There will be 1 Refactor Day
- There will be 1 Rest Day
This must feel unnaturally strict, and you’d be correct in assuming that, at first, it is a challenging routine to put in place, but over time, it feels more and more natural and shows its true value. But before we assume, let’s make sure we know what these days are. The names, I hope, are a bit self-explanatory, but it may be worth breaking it down a bit more clearly:
Dev Days
Pursued objective: “Working on fun features most of the time” & “sustained velocity”
Dev days are fun, dev days feel like they’re the only days you’d need! Dev days are those where you can develop new features, which can be highly rewarding and motivating. In fact, Dev days can be poison as, on their own, dev days are not enough to make a game. Real dev days generate unclean code, prototypes, messy naming conventions, etc. The intent is to generate fast progress, validate news ideas, implement rough new features. 90% of the work you do might end up discarded at later stages, but it allows you to test many different outcomes and iterate very fast. I find that the JIT (just-in-time) and DWYN (do-what-you-need) are good mindsets to keep it lean. Dev days are not about architecturing, they’re about testing. They’re probably what brought you to make games in the first place, and a primary source of motivation.
Refactor Days
Pursued objective: “Sustained velocity” & “Perform constant health check of my code”
Refactor days are days you’d prefer exist in some remote abstract time. You’ve always got plans for refactor days, but you’re pushing that further along as you create technical debt. The lack of refactor days is typically what kills projects altogether, at least in my experience. I’ve also seen pipelines that I’d qualify of ‘engineering powertrips’ where the entire schedule was comprised exclusively of refactor days which is not desirable either. Refactor days are painful, require you to work hard for no tangible progress with the game. But refactor days are magical, as over time, they allow you to proceed with your development unimpeded. Without refactor days, dev days become less and less productive over time, whereas refactor days, if used at regular intervals, prevent this. This is absolutely key to getting games done. The amount of refactor days compared to the dev days insures the project does not fall into ‘neverending prototype’ mode nor ‘overengineering’ mode.
The secret underlying value of the refactor day is that it allows one to keep a thorough understanding of the codebase over the weekends so that the next dev day isn’t just about trying to remember.
Rest Days
Pursued objective: “Remain motivated”
We’re in for the long haul, and it is easy to fall prey to your early motivation to get things done. However, as time progresses, if your routine does not include some forced rest, you’ll slowly feel trapped and you’ll end up creating that space for yourself regardless. Whether you’re a social person and need to see friends, or just want to binge some random show off of Netflix, recognizing how much ‘rest’ you need is key to establishing the right routine so that it endures. To continue with the Netflix example, if you’re a bit older, you might remember watching tv series before Netflix, and how much more rewarding it was to have to wait for the next episode? On rest days, one should not even open the project, and if possible, avoid even mentioning it.
What if the 5,1,1 routine breaks?
The 5,1,1 routine does feel like it is bound to break. For example, one can’t possibly expect to deliver new functionality on every dev day, or to limit refactoring to just a single day per week. When the 5,1,1 breaks (it assuredly will), the upside is that you’re getting key information. Without a system, this information would remain hidden, and the use of a routine makes that information jump at you and prompts a decision, and this is, perhaps, the most important element. It’s fine that the routine breaks if it allows you to keep going and get your game done. The outcome certainly matters more than the means of transportation afterall.
The best way to determine whether the 5,1,1 routine breaks is to ask this simple question:
Did I deliver an increment of functionality on every dev day?
If the answer is ‘no’, then something is off.
Understanding why the routine has broken is paramount. Most likely, it will be possible to trace back this shortcoming with the state of a particular class, manager or other segment of code. Under normal circumstances, a refactor day could’ve been applied towards fixing this problem, but it could either be that (a) there’s too much technical debt throughout the entire project, or (b) that this particular refactor is sufficiently large that it would exceed the scope of a single refactor day. In either case, the fix is simple: make a 4,2,1!
That’s it.
Either your project is far enough along that you’re now into production (as opposed to pre-production) and that it’s going to be this way from here on out (4,2,1) or you’re just making a tactical adjustment on that week (and will resume the 5,1,1 afterwards).
Sacrificing a dev days for an extra refactor day is not a sign of weakness or failure, it is a sign of understanding where you are with the production, and what’s good for your game. The first time you make that decision, you might feel bad about it, like the project is slowly drifting, but chances are that, the following week, you’ll see the value of sticking to your routine and start to realize how that routine is, ultimately, a fierce ally.
By the end of the project, you might be having 2,4,1 weeks, and that’s fine, at least by that time you’ll see the end and understand why the last 20% really does take 80% of the time because you’ll have already invested in that last 20% as you went along.
Note that I purposefully said 4,2,1 and not 5,2,0. The rest day is sacred. It might feel intuitive as you read it, but I can’t possibly stress enough the importance of the rest day. No matter how anti-social you might be, there are always things that need doing, and your brain simply needs rest.
Ways to make refactoring days fun
Some developers thrive in the abstract, if you’re one of those, then mustering up the motivation to soldier through refactoring days shouldn’t be a challenge (quite the contrary), but for most of us, I feel it takes a bit of getting used to in order to find motivation in the darkest of places. Truth be told, in the 5,1,1 routine, a refactor day is more or less the equivalent of cleaning up the house after you’ve left your food on the table the entire week. It’s not fun, but it is what allows you to tackle the next Monday and jump straight into things. It’s the same as reading through emails on Sunday evenings to rush through everything that needs to be done the morning after.
My stance on refactoring is that it really starts making sense once you figure out what you’re going to do ahead of time. Taking notes about the technical debt you’re accumulating throughout the week, and on the typical points of pressure in your architecture can help you set goals. And these micro-goals are an absolute must.
If you come in your refactor day with no plan, start poking left and right, and fix all of these ‘TODOS’, you’ll feel you’re wandering aimlessly against an ocean of things that are inherently wrong without fully understanding why you’re doing it, and what value it has. If, however, you’ve noticed lag in a particular level and know you want to be over 60 FPS consistently across your game, then a refactor day becomes a great tool to take some time apart, turn off most of your creative brain, and focus on nailing down a particular problem: open up the console, the profiling tools, find out what’s wrong, and fix it until it’s fixed, one problem at a time.
It is important to prioritize (you could fix bugs forever, but fixing only the ones that are the most important at this very moment are going to help you DWYN!) The truth is that, if you’re paying attention as you develop new features, you know where you’ve been doing spaghetti code, and the classes you’d rather not open up. The point is not to fix all of it, but that which you end up depending on the most. Time to break a huge purposeless class in multiple ones? Sounds like a fair goal for a refactor day!
The most important part, perhaps, is to make sure that the refactor operations you’re about to undertake either (a) help you alleviate your technical debt to make the most out of your next dev days, or (b) are absolutely necessary for your project (such as trying to meet certain measurable benchmarks).
The key is to start when your memory is still fresh, so, preferably, your refactor day should immediately follow your dev days. You will still know where you’ve struggled, making it all the easier to address the problem. Also, make sure you vary your method and focus every week so as to avoid redundancy and insure you remain motivated in the project.
As you venture deeper into your project, you might find yourself at odds with the 5,1,1 mentality, and that’s perfectly fine. You’ve implemented a model, found whether it works for you, and have your own theories on how to perfect it in your favor. Do it. Just make sure you accumulate enough data beforehand to make sure you’re not changing model on a whim!
Ways to make dev days more efficient
I’m going to assume you’re a first-time developer. If not, don’t take offense at my suggestions. The following is a list of simple tools anybody can use to increase efficiency and avoid loss of direction.
- Source Control / Versioning (SVN, Git, Perforce)
Source control is surprisingly helpful as, for a lone wolf, it will immediately take care of three important things:- Share your source code with others (in case your team grows – the dream!).
- Prevent data loss when your development ultimately breaks (rollback!) or your HDD dies (I lost a few before learning myself).
- Establish a system: you need to think of rules of when to commit, which helps you develop a more healthy relationship with your development cycle.
- Task tracking
At first, you’ll probably be under the impression you ‘know-it-all’ when it comes to your project, and while your instinct to steer away from a GDD may be justified, I can’t stress enough the importance of using software to act as an extension of your brain and help you keep track of everything you’re not immediately doing. From ideas on what you might want to implement all the way to practical bugs you’ve left behind for later, a good task tracking software allows you to keep the information organized for later. You’ll need to groom that backlog once in a while, but it is much better than a .doc file with your disorganized ideas. Give it a shot!- I personally recommend Trello which, while not perfect, is free and covers most needs right off the bat so long as you have an idea of where you’re headed. What’s more, it can easily be configured so whether you want to take a look at your project from a workflow standpoint (backlog, in progress, to review, done) or as a series of components, it’s all possible here.
- If you’re integrating in a tools suite (assembla, etc.) my stance is that it is best to use fewer tools even if they’re less efficient than to try and use the best of every subset of tools. For example, Assembla has some basic task tracking solution, it’s not as good as Trello, but if that’s also your code repository I’d probably recommend using Assembla for everything.
Still not getting games done?
Up to this point, I’ve gone into how to get your game done, but it could very well be that your challenge is not the how, but rather the what. While the process (how) is relatively straightforward so long as you find your own routine and tools, the what is far harder to grasp, and requires more insight into your primary purpose.
About the Author
With over a decade of professional experience in the industry, and 100+ projects under his belt, Michel Mony founded Cathar Games in 2017, turning his lifelong passion for games into a full-fledged startup. Cathar works on both ambitious projects, and indie co-productions, providing services to aspiring indies on the side to give them a fair chance in this rapidly-changing industry.
Linkedin contact: https://www.linkedin.com/in/michelmony/
Business inquiries: http://www.cathargames.com/