The following blogpost is a repost from the One Sol Studios development blog.
How many of us game devs find ourselves in this same predicament: you have this general idea of all the things you need to do to create your game, however, by not hammering it down, you will likely leave things off either cuz you forget or it just didn’t occur to you at the time. You’ll remember one thing this week but forget it the next as it’s all in your head and you’re thinking of other things constantly whether they be work related or not. As you trudge through development you constantly run into issues you hadn’t accounted for and suddenly you’re adding hours of development time on top of your original plan. What’s worse, you don’t have a timeframe set up for your goals as you have so many tasks in your head and you’re not sure when you want to, or can finish them. The game is this ambiguous and murky set of things you “gotta do at some point”. It’s like looking out into the desert for miles but at the same time your vision is hazy because of all the rising heat waves. Nothing is clearly defined and you’re not sure what direction to go, which is daunting, oftentimes paralysing, and worst of all, demoralizing.
It’s not easy being a small Independent studio. With limited resources and time, it’s easy to get overwhelmed and demotivated. So, I’d like to share our experience with setting goals and keeping motivated throughout the development life cycle of a small/mid sized mobile game. I’ll talk about some ideas that worked for us and some methods that may be helpful to other dev teams. Much of our advice may seem like common sense or obvious to some and new to others. Keep in mind we’re constantly learning and improving our process as well, so feedback and sharing ideas is appreciated.
We use a method I like to call it “Multi-Level-Tasking” (am I not great at naming things). It involves a series of commonly used organizational methods implemented in combination, helping us prioritize our goals as well as organizing tasks on a micro and macro level. It is also surprisingly effective at providing a clear indication of progress as well as helping keep motivation and enthusiasm levels high.
Phase 1: The Punch-List
After the initial brainstorming and Game Design Document(GDD) phase and before you ever create a single asset or type a single line of code, we create what we like to call a “punch list”, basically a glorified to-do list (punch list sounds more awesome). In this punch list, we break down the game into individual tasks, not too specific but not too broad either. An item like “sound” is not very informative, but on the other extreme “find sound effect for enemy 1, find sound effect for enemy 2, etc” can become very tedious and will bloat your list like… something that bloats really large and fast...a liferaft? My point is, be succinct but don’t go overboard “acquire sound package” and “implement audio functionality” is good enough for now.
The punch list functions as a means to give you and your team an idea of all the tasks that will need to be done in order to create a complete video game, from start screen, to UI, asset creation, etc, everything you’d find mentioned at some point in a GDD. It’s important to note that as you progress with your game's development, tasks will change, new ones will be added and others omitted completely. This list is meant to be in flux, but remember to keep the middle ground between broadness and acuteness and you’ll be good to go.
You’re probably saying to yourself, “duh, that’s obvious guy. Make a list, what a revelation, nub”. However, it’s what we do next with our punch list that is really important. Prioritization! We use three letters 'A', 'B', and 'C': 'A' representing highest priority and must be completed first; 'B', lower priority but still needs attention at some point after 'A'; and 'C', can wait until 'A' and 'B' is done or until this task is upgraded in priority. This scale can be done with colors or numbers, whatever floats your boat. The point is, we go through the list item by item and indicate which items are A’s based on what are first level tasks or things that are necessary to accomplish that pave the way for work on the B’s and the C’s. As you go through the list you may change some priorities here and there and that’s ok, you’ll be constantly upgrading and downgrading tasks throughout the development lifecycle as you complete items and progress in your games development. By prioritizing the hierarchy of tasks to accomplish based on what lays the foundation for later tasks, you’ve narrowed your focus to the essential first-level tasks and your game is now closer to being a reality.
Phase2: Time Management
This might be a tricky one but it really grounds the game development process in reality. Find out how many hours a week you have to work on your game and plot how many hours you know you will dedicate to game development each day. I’ve actually used my smart phone’s stopwatch. No need to exaggerate or inflate the numbers, being honest is important, no one’s judging! You’ll be surprised how many hours you actually do spend working and how many hours you actually don’t work on some days. This is a good eye-opener and you’ll begin to grasp what you are capable of and how to improve or manage your time better. It’s a daunting but powerful experience when you begin to hold yourself accountable with actual numbers of hours and minutes. It also gives you the power to shift and change your schedule more accurately based on your needs outside of work and will enable you to decide what task you can realistically accomplish on a daily basis, which brings us to the next phase of multi-level-tasking.
Phase 3: uhhh… Multi-Level-Tasking
Once you’ve prioritized your list, we can start the Multi-Level-Tasking. This concept builds upon the idea of Micro/Macro-management. Based on our list and how many hours a week we have available, we choose from the highest priority tasks on our list, and set these as our weekly goals, we’ll mix in a B level task or two for good measure. Pro tip, be realistic in the tasks you set for your week, know how many hours you have at your disposal and take into account your team’s pace and experience, this whole thing is to avoid burnout and crunch so having realistic and humane expectations of yourself and/or your team is key.
Once you’ve realistically selected your weekly tasks, we hone in even more by assigning these tasks to specific timeframes within the week in which they will be completed. One task a day, or one task over multiple days, it all depends on the goal and how many hours you have to dedicate to it’s completion. Creating these bite size tasks serves as a daily reminder of whether you’re on task (see what i did there), and whether you’ve over/underestimated yourself or are/aren’t being realistic. By doing this macro to micro level task management, you’ve created a hierarchy of stepping stones leading to a larger goal, when you reach a smaller milestone, you feel motivated and accomplished, and then you have the energy to press onto the next milestone. In this way you clearly see progress being made, and by the end of the week you can see a few items have been stricken from the list, like badges of honor, you’ve achieved a larger milestone.
These victories of varying size are what keep you motivated throughout the game development cycle. This can be done on a monthly, bi monthly, weekly, daily, even hourly basis. It’s a flexible approach that can be adapted to many situations, but a balance needs to be kept between the macro and micro levels (example monthly versus daily goals) in order to really work in providing motivation and organization. You can create as many levels as suits you or your team’s needs.
Often times we don’t meet our small or larger milestones and that’s ok, take the time to evaluate what happened, did you underestimate the task, were there unforeseen circumstances, were you missing something from your initial list or misjudge the priority of tasks. Whatever it is, keep making course corrections and refining your multi-level-tasking plan, this is a natural part of the development cycle.
Phase 1: Write a punch list prioritizing your tasks to successfully develop a complete game.
Phase 2: Realistically measure and allocate time for work while taking note of your capabilities and limitations.
Phase 3: Create several levels of realistic goals based on a monthly, weekly, daily, etc time frame by assigning elements from your punch list to these various levels and time slots you’ve allocated.
These tools help a team stay motivated and on task by breaking down the general problem of “develop this game” into “develop this game: here are the steps.”
Keep in mind, some people or teams won’t need these concepts, some organizational wizard out there probably does this already or some form of it, some people can do this all in their heads I’m sure, while others are more into the free flowing, nothing-etched-in-stone approach. What’s important is doing what works for you or your team without adding more pressure or confusion. We found this approach works for us and keeps us motivated and we hope that other devs or dev teams may find it helpful or insightful as well. We admit that we are constatnly improving and learning as well so our approach may change in the future. But until then, be wary of the no man’s land that is ambiguous tasks and hazy goals.