My Journey as Tech Lead : Standardizing Project Workflow (Part 5)

image credit to berwickpartners.com

This article is part of my series “My Journey as Tech Lead” where I share my experience as Tech Lead on creating technical foundation for my team. What kind of challenge I have to solve and my thought process to solve them.

You can follow this series from the start by going into the link below.
My Journey as Tech Lead (Part 1)

Collaboration is a key to building a great product. One of a way to ensure the team can collaborate effectively is by standardizing the workflow.

Our development team consist of :

1. Programmer (technical)
2. Game Artist (visual art)
3. Game Designer (design)
4. Quality Assurance (tester)

All team communicate with each other, with programmer team at the center of it. Because programmer is the one who stitch together all aspect of the game, they are the one that suffers the risk of bottleneck process.

My responsibility is to define a good workflow between programmer team and other team, so it does not create bottleneck for programmer team.

My though process for standardizing workflow is as follow :

1. Identify what information is needed by both team.
2. Identify what task can be delegated to non-programmer team.
3. Design a system that can support that delegation process.

Git Usage Workflow

The first step to ensure that everyone can collaborate effectively is to make sure that everyone can work independently. This can be achieved by enforcing everyone to use Version Control Tool.

Thankfully, Agate has standardized the use of version control in the form of Gitlab Server. We use Gitlab both for version control and project management tool.

What I need to do is standardizing the usage of git in the form of branching name. This is also have been standardized in Agate.

The branch standardization is as follow :

branch naming format for our game

Asset Import Workflow

Importing an asset into the game seems like a simple task to do. In reality, it can be a little more complicated. It has to do with the process of Sprite Packing.

Sprite Packing is a process of packing multiple individual sprite images into one large sprite atlas. The purpose of this process is to reduce rendering process by allowing multiple different sprite to be drawn in one render call.

example of a sprite atlas in our game Juragan Kost

Because our game will mainly using 2D sprite, sprite packing process is highly significant in improving game performance.

We are using Unity Engine for development. In Unity, a sprite asset is identified by reference, commonly known as guid (game object unique identifier). The problem is, when multiple sprite is packed into a sprite atlas, it will recreate new guid and thus all reference to its will be lost.

Fortunately, this problem can be easily solved by using Texture Packer plugin. The plugin prevent Unity to recreate all reference as long as the sprite inside the atlas does not change its name.

Because of this, we need to define naming convention for sprite image and sprite atlas. Additionally, we need to address how we should pack the sprite images. So we create a naming convention that can solve both problem by having atlas name as its prefix for every sprite image in that atlas. That way, we can quickly identify where we should pack a sprite based on its prefix.

The name convention is as follow :

Asset naming format : {atlas name}_{image name}
Example : MainMenu_PlayButton.png

Therefore, the workflow is as follow :

1. Artist and Programmer team discuss to define sprite atlas list (based on scene appearance)
2. Artist and Programmer team define which sprite image will be included in that sprite atlas
3. Artist team name all sprite image with sprite atlas name as its prefix
4. Artist team pack all sprite image with the same prefix into sprite atlas
5. Artist team put all individual sprite image into asset bank for archive purpose
6. Artist team put sprite atlas into game repository in asset branch
7. Artist team push the changes and create merge request
8. Programmer team merge changed asset into develop branch

Database Export Workflow

When people say database, they usually refer to two different thing : Game Data or Player Data.

Game Data is basically a lookup table of values for each game element. For example : a list of all available map in the game.

Player Data is a snapshot of player progression of the game. For example : player current level, player current gold, etc.

In more complex game, both of these data is stored in game server. However, because we are using server-less architecture, we store both data in client device instead.

In our game, Game Data is basically a read-only database. Game designer should be the one who are responsible for managing Game Data.

So, we need to find a way to allow game designer to modify data with ease. Since our game data is not very complex, we can use a simple text based database instead of using database program (such as SQLite).

We decided to use JSON format for our database format because it is :

1. Versatile : object structure can be changed easily
2. Easy to Parse : can be parsed directly into the game object
3. Human Readable : human can understand what it means

However, JSON format is not intuitive and not easy to maintain for non-technical person. Therefore, we use Excel file to help our Game Designer to modify the data, and create a way to export the Excel directly into JSON file, to be used in the game.

For better usability, we design the Excel file so each sheet name will be exported into a JSON file name. That way we can manage multiple json file in one excel file. Additionally, we provide 2 excel export format : Object Database and Attribute Dictionary.

Object Database is a format that contain a list of object with similar attribute. When parsed, Object Database format will result in a list of object.

example of Object Database format

CharData class structure

Attrribute Dictionary is a format that contain a mapping of attribute into its value. When parsed, Attribute Dictionary format will result in a single object.

example of Attribute Dictionary format

PlayerData class structure

The resulting JSON file can then be parsed easily into game object with a single line of code :

code to load json file into game object

The workflow is as follow :

1. Game Designer and Programmer team discuss the structure of object
2. Programmer team write a class code structure and code to load json into game object.
3. Programmer team create an Excel file that match structure in code
4. Game Designer team modify excel data and then use our tool to export the excel into JSON file
5. Game Designer team then push the changes for both Excel file and JSON file and create merge request
6. Programmer team merge the request into develop branch

Debugging Workflow

During development, we need to test and verify that the feature is working properly. Sometimes, that feature is inly available after player progressed further in the game. Because of that, we need to create a way to allow game tester to progress into later stage without actually playing the game. In short, we need to create a cheat tool to allow game tester to test our game efficiently.

In server based game, this is usually done by allowing the game tester to modify player data directly in server database. However, because we use server-less architecture, we store player progression data in client device instead of storing it in server. This means we need a client based cheat tools.

Additionally, we need a way to inspect object state during runtime. For that, we created a highly customizable runtime debug panel.

appearance of our debug panel

We can add a functionality for the debug panel by writing one line of code

one line code to add functionality to debug panel

For checking runtime error, we use Touch Console Pro, as it has good usability and can send the log error as email. For more complete error log, we use Android Logcat.

The workflow is as follow :

1. Programmer and Tester team discuss what functionality is needed to be added to debug panel
2. Tester team can request more functionality as the development goes
3. Programmer team implement cheat mechanism and add the shortcut into debug panel
4. Programmer team can use debug panel to test feature in Unity Editor.
5. Tester team can use debug panel to test feature in Device
6. When an error occured, Tester team can send the error log to developer

In the next part, I will explain about the process of creating module integrator. Stay tuned !

You can read the next part here :
My Journey as Tech Lead : Creating Module Integrator (Part 6)