Realtime Database
Guild Chat Technical Production using Asana with Firebase Realtime Database
Benjamin Button Edition, Part 3
Technical production in video games is largely about managing workflows, lassoing partner buy-in, and aligning project plans with product goals. We’ve told this story backwards in our first two posts where Alex Harbi stretched Firebase Realtime Database for our guild chat and Osman Kaan Demiroz connected the backend to Firebase’s plugin for Unity so that our players can communicate with each other in their Squads.
In this third and final part I want to take us back to the very beginning and shine some light on how our production processes and organizational workflow helped carry this idea from design to development to functionality by utilizing Asana’s Premium tier features.
To set the stage, I will start by explaining how we set up our Asana projects and the key points of our workflow within these projects.
Agile Work Methods: Kanban And Scrum Refresher
If you’ve ever looked into game development, you’ve probably heard of Agile work methods, which also lie in the heart of our production processes. At a first glance, our two main Asana projects, ART and DEV look like Kanban boards. To achieve this, we use the Board view in Asana and Sections to create necessary columns to organize tasks, or as we call them ‘tickets’. Each of our projects have four main active columns in line with the Kanban method: Backlog, Tickets In Progress, Ready For Review and Completed. Tickets start their life in the Backlog, get moved to Tickets In Progress when the assignee starts working on them based on priority, then to Ready For Review when the task is done and is waiting for testing or approval before getting marked as complete and moved to the Completed section.
This in itself is a very simple yet effective method for tracking ticket progress and priorities, however, as we are always racing towards deadlines for new releases, an added layer of complexity and depth is needed. We achieve this by combining Scrum Sprints with our Kanban set up. Sprints, for us, refer to two week periods where specific tasks are scheduled to get done. This is where Asana’s Premium features, especially the timeline view, becomes very valuable. We use the timeline view to schedule out our sprints for each project.
Timelines, Custom Fields, And Stakeholders
We set tasks as two week long tasks to have a better visual representation of them. Our deadlines like Submission Date are always marked as milestones, another feature Asana Premium makes available for us. With this skeleton set up, it is very easy for us to move in the tasks of individual team members and schedule them in while keeping an eye on the sprints and milestones. Moreover, the timeline pulls information directly from tickets themselves. In other words, as long as a ticket has start and end dates (and is pinned on a project of course), it automatically populates the timeline. Such functionality allows us to move and edit individual tickets easily without the need for manual changes on the timeline. Consequently, timeline functions as a dynamic planning tool as well as a great alternative to a Gantt Chart and it does not intrude in our board view and flow. Although, it took the use of some other Premium features, such as custom fields, to get the timeline to function this way within our workflow.
Most of our engineering tickets first get added to the Backlog and as they move through columns, they switch assignees from Engineers to QA or to Production for review and completion. Similarly most art tickets start with the Artists, go through Engineering, QA and Production for implementation and review before getting completed. In such a dynamic workflow it is key to keep track of original stakeholders of these tickets, and custom fields are very helpful in doing so. One of our custom fields is called “Stakeholder” and is universal across our projects. With this field we are able to tag tickets with the team member that originally worked on them. Even if the ticket changes assignees and moves from department to department we can still keep track of who originally worked on it.
Seeing the Stakeholders makes it easier for Production to schedule tickets for certain team members and to move those tickets back to the stakeholders at the time of completion for record keeping. The stakeholder field also benefits the QA team as they know who to direct their questions to regarding test items in tickets even if there are many collaborators, previous assignees, on one ticket. In addition, custom fields can be set up with custom colors and these colors show up in the timeline which makes it much more comprehensible and visually pleasing. I should add, our team members were very excited to pick their colors and have them show on their tickets.
Technical Production And Dependencies
Now that I’ve covered some of the basics of our workflow and Asana Premium set up, I want to take a closer look at Squad Chat specifically. Squad Chat was created as a part of Squad System which at the time was a brand new feature. With any new feature in our game, the first step was Design to create a GDD detailing the functionality of the new feature.
Based on the GDD design provided, Squad System 1.0 Epic was created with the sub-Epic Squad Chat System. The Squad Chat System Epic contained the sub-tasks our engineers have worked on.
These tickets were scheduled out using timelines and connected to each other through Dependencies. For example, the Server set up of Firebase Nodes is dependent on the Client Hook Up of Firebase Plugin to Unity being completed, and the UI implementation is dependent on the base of the Chat System and UI Art assets being completed. Dependencies are not only useful for production planning but also for development. Our team members can easily see if the pre-requirements for their own task are completed and who needs to work on them. This fosters visibility on each member’s tasks and potential blockers.
Skinning Cats
These are only some of our production processes and workflows. Over the course of many projects we have realized that there is no one way of doing this kind of game production; we’ve only adopted the practices that fit our needs best. That being said, technology is always changing and it is the nature of our field to always adapt to those changes and strive for improving our practices. Simply put, agile work methods require agile workflows and these workflows are what enables us to put out complex features with efficiency. What are some of your workflows that enable you to put complex features out? We would love to hear about your best practices in the comments section and open up the discussion to our readers.
We hope that you have enjoyed our three part series and hope to see you in the next one!
