Get Games Done

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. From past experiences, I have learned that the single most important factor to get games 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. The odds of succeeding are also generally tied with the ability to deliver these increments at more or less regular intervals. There are many reasons why a developer that sets out with the best of intentions will end up being unable to deliver functionality over time, and these reasons will end up killing the project. Rather than discussing the symptoms here, I'll explain my way of overcoming them.

Implementing a Development Routine (5,1,1 Routine)

To establish sustainable development over long stretches of time, a developer needs to have a Routine. This mental construct will initially be forced, and eventually become a habit, so that the majority of threats endangering the project will be met with fierce and effortless resistance. Different developers will prefer different routines, of course, so bear in mind this works for me and may not work for you. However, the idea of a Routine remains universal. I call mine the "5,1,1 Routine"... I accidentally created the 5,1,1 Routine during one of my hobby projects, and decided to stick with this method as it allowed me to meet three very important objectives:

1. Remain motivated with the project by working on fun features most of the time.
2. Deliver shippable increments of functionality regularly (sustained velocity).
3. Perform a constant health check of my code with limited effort.

What is the 5,1,1 Routine?

The 5,1,1 Routine is a representation of the workload in a given week in regards to three axis.

5 Dev Days... (I deliver a new feature or improvement) 1 Refactor Day... (I cleanup and optimize the code) 1 Rest Day... (I don't look at the project)

What are Dev Days?

This methodology assumes that my codebase is healthy enough to allow me to develop new aspects of the game five days per week, which is what will keep me motivated to continue my work on the project. During these five days, I will develop new features with the quickest possible route in mind, regardless of how "unclean" it will look. The reason for this is twofold:

a - We're developing an entertainment product (game), and fun is hard to catch. Rarely will the first implementation feel right, therefore it's better to be able to try several messy ways in a single day than to try a single clean way. b - These dev days are meant to keep my motivation high. The fun comes from seeing new things working in my game, not from clean code. The more new stuff I get to try, the more excited I get about the project as a whole. I don't feel wrong because I know that 90% of the things I'll try will end up being discarded, thus won't harm my codebase much at the end of the day.

Usually, I'll want to deliver something new EVERY day. To achieve this, I like to keep the JIT / DWYN attitude.

JIT (Just-In-Time): While generally employed to relate to inventory, one can correlate this with information flow in regards to decision-making. Essentially, postpone any technical decision until later. Code your new feature quickly and don't have any foresight about how it can be reused (you can always use your refactor days for that anyway). Do what you need (Lean): A good way to prevent over-engineering, this tells you to code exactly what you need and nothing more. When you refactor later or need to build a more complex mechanic that leverages the same logic, you can always revisit, but assuming that you will and over-engineering will result in tremendous amounts of time loss.

What is a Refactor Day?

If you've been developing for a while, chances are you've quit on many projects solely because they reached a point where it would take too long to implement any new idea. This can be explained as technical debt. Though I spend five days per week adding stuff without caring much about how clean the code is, I discipline myself into adding an extra day per week where I am not allowed to develop anything new, and rather, I seek only to clean up my codebase, refactor, etc. In other words, I deal with my technical debt. Note that I use the term discipline to represent that I not only force myself to refactor but that I allow refactoring a very specific amount of time. This allows me to ensure I do enough refactoring so that I can maintain my development velocity, but not too much refactoring, which would pointlessly halt development altogether. This is used as a means to prevent me from falling into either the prototyping mood (which can never amount to shipped large scope projects) or the coder's mood (where the technological thrill outweighs the goal of delivering a game). In the methodology known as Test-Driven Development (TDD), the goal is to reach a functional state as quickly as possible and then refactor. This is usually done within a few minutes. In 5,1,1, this Routine is stretched across a development cycle of a week. The other advantage of having a sixth day dedicated to refactoring is to keep a general understanding of the project. Since I spend five days looking at the new code, I don't want to lose sight of what the rest of the code base looks like, and how I can find ways to optimize/refactor. It also ensures that I'm still familiar with the codebase when I get back to development on the next Dev day the week after. I used to be the kind of developer that tried to get things done through weekend development sprees believing that having longer stretches of time would be more beneficial as my concentration would be easier to muster. It turns out that the amount of concentration required to undergo these sprees is largely due to forgetting a lot about the codebase in-between sprees. As a result, I find a lot more value in spacing that development time across a week and retain a constant understanding of the codebase. For more information on refactoring (and clean code), see

">this video. I went to college with this guy, and he's grown into a very successful indie, so I was amazed to watch this video after completing this article.

What if 5,1,1 breaks?

It's entirely possible that the 5,1,1 will break, and though this is not desirable per se, it exposes any threat so that it becomes actionable. Determining that the 5,1,1 is broken is fairly simple and can be answered with a very simple question:

Did I deliver an increment of functionality on each dev day?

The key to 5,1,1 is to understand why the method broke, and how to fix it. One of the most common reasons for the cycle to break will be that a specific class, function or segment of code is currently in a state that makes it impossible to deliver new increments of functionality on each dev day. This could be due to code readability, unnecessary complexity resulting from multiple iterations, or any other logical issue that could be dealt with on a refactor day. When this occurs, I willingly choose to sacrifice one of my dev days and turn it in an extra refactor day (turning that specific week in a 4,2,1), knowing there's a very specific goal to be attained in order to restore my cycle. I generally refrain from using the 7th day (rest day). The rest day should, most of the time, be sacred. It is a day that keeps everything in equilibrium and allows for this routine to last. No matter how asocial one might be, there's always a time when other things need to get done, and having a routine that leaves room for this is essential. It's also a good way to stay clear from burn-outs.

Ways to make refactoring fun

Some developers refactor too much and over-engineer. If you are one such developer, I recommend reading this article. For the more gameplay-oriented programmers, however, refactoring is often perceived as a pain, a necessary evil, and is often cause for grief. We've already addressed a way to build up momentum and motivation by having five dev days, but unless you come to your refactoring day with a plan in mind, you're still likely to loathe it. There are various ways you can approach this, but the important thing here is to prioritize the work that makes the most sense all the while keeping your sanity above ground. My personal approach is to come with a specific goal in mind. It could be that I have identified throughout the week a very painful bit of code that I need to deal with recurrently that could be refactored into something more intuitive and easier to use. It could also be that I happen to think that I've broken enough encapsulation rules to try and fix this before it becomes spaghetti code. The key here is that your recent development cycle is still fresh in memory, so you know where you've struggled, and what you have stained with poor (new) code. Whatever the problem you may have identified, make sure that it will reduce your development time for new features. That way, you won't feel like you're shooting in the dark. Also, make sure to vary your method and focus from week to week to keep things interesting. It's a good way to make sure it does not feel redundant over longer stretches of time.

Ways to make each dev day more efficient

Here is a short list of tools and techniques that can help you stay focused and gain velocity. These are software that I have used in various projects. Please note that while I suggest specific software for each category, it may not be the most suitable for you, but it doesn't hurt to know where to start looking. Source Control (SVN / GIT / Perforce) I'm always surprised by developers (generally "lone" wolves) that don't use source versioning. These allow you to do many things at once with relatively little effort:

• Share your source code with somebody and allow more than one person to work on the project at once. Though you may not plan on having anybody else contributing to the project at this stage, it's not a given that it will never happen.
• Prevent data loss when your development setup unmistakenly breaks. A simple checkout will restore your project a few minutes away from where you were at.
• Help you establish a "system." By establishing the rules of "when to commit," you have a more healthy relationship with your development cycle.

Also, when looking for free hosting for source versioning, I recommend: Assembla. Task / Bug Tracking (Trello, Assembla) As an indie, it's easy to fall prey to the misconception that it's possible for one person to "know-it-all" because of the scope of the project. Even if it were accurate, it would take such a toll on a person's memory that the impact in everyday life is not desirable. Rather, the use of tools that allow you to track tasks and ideas is preferable. I use Trello for my projects. The key here is that a simple tool allows you to do more. Trello has the advantage of being flexible (create your own workflow/categories, the ability to add checklists, etc.). Furthermore, it works on mobile, making it also good at taking notes in the context of a project (rather than in a standalone app). What I like about Trello is that it allows you to create one item (say, a feature) and break it down in many sub-checklists. This way, you can contain within a single feature the necessary logical components, the assets you might need and other requirements, the polish ideas you have along with any bug or optimization requirements you might have. Thus, your Trello board can be a collection of high-level features that display something along the lines of "Feature name - 10/93 items". Continuous Integration (Jenkins) A bit more recent perhaps than other items listed here, the concept of continuous integration is really something to delve into. It allows you to minimize the amount of time lost "building" the project and makes it simple to screen a build whenever you want. By default, it will build a version after every commit you make. Versioning might prove catastrophic at first, but you'll get the hang of it. I'll admit that I've never looked at alternatives to Jenkins. The gain I've experienced when first using Jenkins was so great that I did not bother to compare, but there may be better ways to do this out there.

How to get Games Done

You may follow all of the above and still not get games done. That's because while you may understand how to "get there," it's possible that you have no idea where "there" actually is. Say you want to go to Newark's airport, and I tell you it's somewhere along the New Jersey Turnpike, it's quite possible you'll end up god-knows-where along the turnpike because you have no idea what an airport looks like (arguably they've done a pretty good job at putting signs up, and well, there are planes, but without prior knowledge about what planes are it won't help you much). Making games is no exception. If you know your way around development tools and have a development cycle, it's possible you'll miss out on completing a project, despite being highly motivated. If this is your case, here are a few things to bear in mind as you define your overall development "strategy" (something you should think about before starting, and iterate on as time passes by).

Have a clear idea of what you want to demonstrate

What you should have at this stage is a "game vision." In simple terms, you should be able to describe the end-user experience before the software is built, knowing that some things will need to shift along the way. You should not know everything in finer d?tails, but you need to have this sort of high-level interpretation of how it will all come together. A good way to confirm that you have a clear idea of what you want to demonstrate is to try to explain your game to a friend using as few words as possible, and yet hype them. If your friend starts saying "oh and you should do this and that..." you should probably ignore the specifics, but you'll at least know you've come up with an idea that is fertile ground. Your job then will only be to squeeze out the fun where it really is and exploit the fun-vein to a maximum.

How to scope & iterate (MVP)

As a game developer and designer, your role is initially to demonstrate fun gameplay. The core of your job should be to build a skeleton of the game you want to build, by focusing on its most important aspects (what makes it unique, fun, etc.). If you're not going for original gameplay, and rather focus on execution, then there should be fewer unknowns in regards to what's fun early on, but timing will still be critical. Don't assume that just because you are doing a final fantasy rip off, the same pace should be used in exploration and combat just because it worked for these games. The next logical step is to build an MVP: Minimum-Viable Product. In essence, the MVP represents the minimum your game can ever be. It's a condensed game that contains very few mechanics. However, each mechanic will be brought to complete fruition. The process to get there is to build the skeleton first. Prog-art, your prototype, check what works, what doesn't. Then iterate until this part makes sense. Then, proceed to the next core gameplay mechanic. Once each CORE gameplay mechanic feels right, hone them. Develop each of these mechanics until you feel like your game is a polished gem, with much untapped potential. Play this build over and over again and ask for feedback. THIS is your MVP. If anything happens tomorrow, you'll have at least achieved that (the minimum your game can ever be to deserve to be called a game). Instead of being a shady prototype halfway through completion of the next uber MMORPG, you'll have achieved a shippable game that may just lack depth. Why is this critical? Because from now on, you can release this game anytime you want, and you know the quality you are delivering. In fact, you knew the quality you were delivering every step of the way, never worried about whether other mechanics would feel right or not. Knowing that you can release anytime alleviates the pressure of the unfinished project and helps you keep a high motivation. It's much easier to think in terms of polishing a final product than to get everything missing for release. While you may spend the same amount of time on the game, you've had a lot more control on overall quality, always working on that which has more value and always judging of new feature's value based on their coherence with what is established. This is a mindset that takes some getting used to, but over time, it's something I've grown incapable to avoid based on the sheer benefits of this approach. The drawback to this approach is feature-creep. Having an MVP in hand puts you in a state of mind where you need to consider the features you feel you need to add to complete the greater experience. The problem is that you might get excited about way more features than the game would normally support. There's no real rule to determine when you've entered the feature-creep lane, but if you find yourself months beyond your MVP and still have a lengthy list of things you'd like to add, consider releasing first and adding whatever you need based on user reviews instead. If the game allows it, consider metric-driven development if at all relevant.

Set Deadlines

Let's face it, there are many reasons not to set deadlines. This is likely a hobby project, and the truth is that you might enjoy the indefinite nature of it. I won't argue here as I have plenty of side projects of my own that don't have a set deadline. The key difference is that I did not choose to make these a priority and I did not determine I wanted to get them Done. The premise of this article is that you want to get this game done. If this specific project does not fit this criterion, you are more than welcome resuming work on it without actually applying any system or deadline. Just know that it is likely to fail/fall in an indefinite hiatus at some point. There's nothing wrong with that. As a matter of fact, it's better to toy with many ideas at once and choose to only pursue the most fun. Once you've browsed over your projects and have identified the one you really want to complete, then it's time to trade the safety you had knowing there were no "rules" for a system and actual deadlines. Deadlines shouldn't be daunting. You are not liable for a contract here as you would in the corporate world. Rather, think of deadlines as goals, ways to keep a macro idea of where you are headed. I personally like to think of my own deadlines as extremely lax and vague, but they allow me to place tangible milestones in time and give me an idea of the commitment I need to put towards achieving what I want. For example, your first milestone could be just a prototype, and it may take as many milestones as you want just to get to the MVP. Don't try to be too micro. However, you're only likely to make your milestone definition irrelevant as time passes by. Also, don't put an exact date on a milestone. Depending on the scope, a specific week or month may be enough. I personally use quarters of a year and calendar events as references ("I'll get this done before Christmas, and this somewhere in Q1 2014). You don't have to stick to your milestones if the circumstances change (if a core gameplay element isn't as fun as it should and you've chosen to take the time to fix it or find alternatives) but you should always have a broad plan of where you are headed days, weeks, months from now (task tracking helps, especially in the form of notes for "later"). The mere effort to project your project in time is what matters, not the end result. Pat yourself on the back if you meet a deadline, don't focus on the deadlines you miss and simply keep in check the reasons why you have failed. Are you overthinking things? Are you still working on the MVP? It's possible that you'll find out you've been feature-creeping. If you are, learn to let go, push these ideas through Trello instead, and focus on what needs to be done first. Perhaps you'll discover your game vision has grown blurry? Take a pause, reassess what you think the game should be, how it should feel, then resume work. It's pointless to work on fun bits of the game if they can't become part of the greater whole and feel coherent with the experience.

Random Thoughts & Rants

Here's a short list of practices you might want to set up. These are mostly aimed at team work environments (2+ people). Weekly Reviews One good practice is to do weekly team review. If you can afford it (even over Skype), this is extremely helpful in setting everybody's expectations straight and keeping the vision clear. It's also a good opportunity to discuss potential features, solutions to some problems, and more importantly, evaluate the level of fun resulting from the current implementation. If using the 5,1,1, you can probably do these every other Rest day. Internal Playtesting If you're working on something on your end while others work on something else, it's always good to send them something partial as you are progressing with minimal information. If possible, seeing them manipulating it is ideal, but comments can also work. It will give you an idea how intuitive what you're doing is and will grant you impressively useful feedbacks. The often forgotten effect of doing this is keeping the motivation across the team. This article does not discuss teamwork much, but it is critical to leverage each other's motivation to keep the boat afloat in larger teams (or risk chain reaction of demotivation). Experiencing what others are doing and receiving a stream of comments on what you are doing keeps the dialogue open. You need to use each other's mind as much as possible to make this the best game it can be. External Playtesting Often discarded... sadly. You need to get out there and let people play your build. Ideally, you want to see them in action (moreso than team members). Be aware of who these players are compared to your target audience (this will let you know which part of the notes you are taking will be truly relevant). There are various ways to do this which doesn't fit within the scope of this article, however. I recommend reading further on the subject of defining your target audience through the big five. Leadership (who owns what) As the team becomes larger, it's important for roles to be clear. By "who owns what," I'm not referring to the final product and legal ownership of the end-result. Rather, I'm discussing about who should have final say on what matters. The best approach I've used this far is to allow everyone to pitch into everything, but give the final say to the one most proficient with that discipline. For example, I do some programming on my projects, but it's not uncommon for my partner to have superior programming skills, and I tend to grant him the final say in everything technical. Likewise, I tend to have a clearer vision of the end product (especially when I'm responsible for initially creating the high-level concept) and like to keep final say in design matters, but not all. To keep other team members motivated on the team, I also break down the design into various features/components. For example, if making a tactical game, though the game may be my original idea, I may end up being teamed with a Tactics Ogre // Final Fantasy Tactics freak. Why not share design ownership? There may be reasons not to share this ownership, though. The important part is to make sure that ownership is clear for everyone to avoid people feeling like they are in control until denied later. Confusion on who owns what can be a real team killer as it turns out, and it's better to gauge team member's assumptions early on (and tell them outright where they might not have authority) than to lead them on until you need to squash their dreams by imposing your vision.

***

If you do all of the above, you may not make a great game, but you'll at least complete it, knowing that you've completed something that is as good as you could make it. The difference if you lose hope is that you'll have something to show for instead of nothing. Putting that "decent project that could've been so much more" on your website might draw people to you, either in the form of potential players, or collaborators. Never under-estimate the value of completed projects when gauging for partners. It gives people faith in your ability to get things done, and with the number of indie developers lurking about, this is key to forming bigger teams or relationships. What you'll learn from this experience will also help you on the next project, and the next... until ultimately you release games in the state you want them to be. It can take 4-5+ projects before you get there, but hopefully, this method will make the journey less painful, and leave you with tangible proofs of your efforts. If you have your own system, let me know! I'm always curious about how other minds work, and how people manage to motivate themselves. Though my system allows me to complete games, it's not perfect, and I'm always looking for ways to further improve it. Cheers, - M

Article Update Log

28 Jan 2014: Created Draft, modified templating from the original file. 2 July 2015: Updated broken link.