Breaking Down Tasks: The Engineer’s Survival Guide
De-stress, deconstruct, and deliver!
Just as writers come up against “writer’s block”, and designers draw blanks dreaming up new ideas for a game, engineers frequently find themselves stuck on a task with no idea how to proceed.
At many points during my 5 years in game development, I’ve felt at a total loss for next steps when presented with a particularly challenging new task. This could be anything from writing a new system or feature to handling a (not-so-simple) bugfix.
So how did I make it through?
0. Pour a drink and relax
Yes, relax. The more overwhelming the task seems, the more relaxed I try to be. A complex task often presents these problems:
- Many dependencies. By doing this, what other parts of the game will it affect? Are there subsystems that I can re-use? (Or any that I need to overhaul?)
- Many edge cases. What if the player encounters a special situation that is completely out of the norm?
- Infinite “normal” cases. Even under normal circumstances, there seem to be too many permutations and combinations of conditions that lead to various intended behaviours.
When looking at design documents and visualising how a new feature will work in the game, these questions and problems start to swirl in my mind, and when I’m in this state there’s no moving forward at all. So… grab that drink and think about something else for a short while.
1. Grab something to write on
The medium might vary from person to person — some people like to type, some like to write. I like both, but I prefer a blank piece of unlined paper as I’m free to draw random things and I’m not forced to write in alignment (not to mention saving my eyes the extra screen fatigue). If writing on a whiteboard or a glass panel works for you, make sure you have one to hand.
2. Write ANYTHING
Write anything related to the task. At this stage, there will usually be a lot going on in my head at once. I try to write down whatever comes to mind — class structures, database schema, even actual code. These are the task’s “puzzle pieces” to be connected later on and which for now help me better define the scope of the task.
3. Flowcharts!
Drawing flowcharts and diagrams helps me capture any edge cases that occur to me on the spot. These don’t have to cover every possible scenario, many of which are likely to change throughout the development process. By having at least some documented visually, I’m nonetheless able to organise my thoughts and not feel so overwhelmed.
When drawing up flowcharts, these are the basic points I like to raise:
- What is the most common entry point? Does this feature trigger when the player reaches a certain level? Or when the player taps a button and enters a specific view? A good example of this consideration is tutorials, which often need to trigger when you hit a certain progression milestone, or upon opening a certain view when exploring the game.
- What is the most basic and necessary flow? After reaching a certain state, what is the most common action players will choose? Upon performing this action, what state will the game enter?
- What are the possible exit points and what effects might these have on other parts of the game?
4. Identify your building blocks
After drawing up the flowchart, your basic building blocks will start to come into focus.
- What are the data structures I need? Should these be scriptable objects? Or could they be network messages sent between the client and server?
- What is the most suitable framework? For Butter Royale, we use the DOTS Framework by Unity when it comes to matches (Check out how we cook butter here) and UnityEngine’s MonoBehaviours to handle UI. The question of the right framework therefore usually needs to account for this split: which part of the feature relates to UI, and which part goes into the match systems?
These building blocks are the elements of the feature that, unless tackled first, mean it cannot be implemented. They are essentially the hurdles that need clearing before the task begins in earnest.
5. The final breakdown
At this stage, it should be relatively easy to set out the individual steps that comprise this complex task. I like to create a Jira sub-task for each step to make it easier to keep track of my progress. It’s around this time that I start to feel at ease in the knowledge I’ve fully outlined what I need to do.
Throughout this process, there will also need to be discussions with various stakeholders, including designers, artists, and other engineers. These are to help address issues like:
- Handling certain edge cases
- Data setup. Designers often have certain variables they want to be able to control, so always clarify with them!
- Intended look and feel
- UI/UX and mockups
After breaking down the task, you’ll be much better placed to update your colleagues on the time needed to implement the feature. If your estimate is way off what was initially agreed, be sure to bring it up to the relevant people!
Conclusion
Don’t be afraid of a feature getting too big or too complex. Communication is key: risks and limitations should be thought through and discussed with the rest of the team. You never know when a seemingly complex problem has a simple and straightforward solution, so keep an open mind. Take things one step at a time, and you’ll eventually be able to ship the new feature you’ve worked on, and be proud of it :)
Designers, be sure to also check out this article if you find yourself stuck at the concept stage! I hope these are able to help you in your game development journey :)
