My Journey as Tech Lead : Standardizing Project Structure and Versioning (Part 4)
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)
There are 6 phase of Software Development Life Cycle : Planning, Analysis, Design, Implementation, Testing & Integration, and Maintenance.
Planning, Analysis, and Design took place outside of the software repository. The challenge for these phase is how to communicate the information clearly. This is solved by having a good documentation.
Implementation, Testing & Integration, and Maintenance took place inside the software repository. The challenge for these phase is how to synchronize each team member work. This is solved by having a good Project Standardization.
Project Standardization main purpose is to help synchronize each team member work into an impactful and valuable software.
A good project standardization is those that can satisfy project needs. Therefore, we have to make sure our project standardization satisfy team needs.
Our goal is to create casual mobile game, allow every team member to work independently and have their work easily integrated into the game.
When creating project standardization, my general thought process is as follow :
- Find a best practice or industry standard practice for that problem
- Identify any requirement that is not fulfilled by those best practice
- Modify it a little bit to fulfill team needs
Folder Structure
The crucial part of synchronizing work is making sure that the work can be distributed to its assignee and can be integrated when it is done.
It answer the biggest question of distributing and integrating work.
How can I find the file for this part ?
Where should I put this part ?
We can answer this by defining a rule on how we organize things. A common way to organize files is by using folder.
In Game Development, there are 3 type of files
- Resources : External files that is used in game, such as Image, Animation, Audio, etc. This is created by Visual Art team.
- Database : Source of data such as Level Data, Game Config, etc. This is created by Game Design team.
- Script : Code implementation of the game, created by Programmer team.
For Resources and Database the rule are simple because they are an independent file. We can use a root folder for that resource type, and adding sub-folder for its module.
Foldering Format : {resource type}/{module name}/{file name}
Example : image/tutorial/tutorial_button.png
Code Structure
For Script, the rules are more complex, because the script is both a file and a logic that connected with one another. A common practice for organizing script is by using namespace. Namespace works like a folder, but in logical sense rather than physical sense.
A common practice for organizing code is by following Separation of Concern Principle. Basically this means we need to separate code based on its functionality.
There are 2 kind of separation that we can do, separation by scope or separation by type. Separation by scope is when we separate code by which feature it is responsible to, such as tutorial, gameplay, shop, etc. While separation of type is when we separate code by its component type, such as data model, logic, visual. A common practice for separation of type is using Model-View-Controller pattern.
Another best practice for organizing code is by using Single Responsibility Principle. This means that every part of code must only have one and only one responsibility. This means that we can use both separation type to make our script file have clear responsibility.
For example :
TutorialModel have tutorial scope and data model type
InputView have input scope and view type.
This makes every class name to be self-categorize and self-explanatory. After that, we can use both folder structure and namespace structure to make it obvious where it should be put on.
Code Structure Format
Folder Path : {root folder}/{scope name}/{component type}/{class name}
Namespace : {game name}.{scope name}.{component type}.{class name}Example :
Class name : TutorialModel
Folder Path : Script/Tutorial/Model/TutorialModel.cs
Namespace : Game.Tutorial.Model.TutorialModel
Another advantage of this structure is that it makes distribution of task more obvious and make each scope to be more modular.
Environment Setting & Build Mode
Our goal is to release a mobile game integrated with Advertisement, Analytics, and Notification system. Therefore we need to test and verify that the system has been integrated properly. But we also want to make sure that our the data sent during tested is separated from data from real user.
The best practice for this is to create different Environment Setting for different purpose. A common implementation is to split into 3 environment setting as follow :
Environment Mode : Development - Staging - Production
Development : Used during development, for developer
Staging : Used during testing, for tester
Production : Used when the game is released, for real user
The setup above works well if we are creating a server-based cloud service. In our case however, our game is client-based instead of server-based. We are using other people cloud service instead of providing one.
Furthermore, because we have limited team member and timeline, we choose to go server-less architecture. This means that we does not create any server-based functionality, and instead rely on third-party service to provide it for us.
Because of that, we only need 2 environment mode, one for development and one for production
Environment Mode : Sandbox— Production
Sandbox : Server target for development
Production : Server target for real user
Both server target need to be tested and verified. A common approach to test and verify it is by creating a debugging tool that can bypass game flow and go directly into certain part of the game. This debugging tools should only be available during development and testing, and should be removed when the game is released.
When testing production mode, we need to prevent the game to send analytic data, so they does not contaminate data from real user.
Because of that, we need to define build mode as follow :
Build Mode
Development : use sandbox server, used for development.
Both debugging tool and analytic is enabled.Release Test : use production server, used for testing production server. Debugging tool is enabled, but analytic is disabled.
Release : Use production server, used for real user.
Analytic is enabled but debugging tool is disabled
Versioning
Game development is a continuous iteration process. We add a little bit improvement here and there everyday. Versioning help us to keep track of what improvement we had done.
A common practice for versioning is using Semantic Versioning. We interpret semantic versioning for Mobile Game Versioning as follow :
Version Format : X.Y.Z
X : Major version, when we make big changes in gameplay, mechanic, or visual
Y : Minor version, when we improve feature or adding small feature
Z : Patch version , when we resolve severe technical issues in previous version
From player perspective, a game version is changed whenever there is new update for the game. For player, this versioning is enough.
From developer perspective however, this versioning is not enough. This is because every game update will go through several iteration. This means that the developer need to build the game several times for the same feature before the feature is considered finished.
In my opinion, the purpose of versioning is to prevent confusion from developer. That means we need to add a new identifier for build number. So the developer can identify changes during iteration.
Additionally, we have defined different build mode for development, testing, and release. We give each build mode a numeric code. 0 for development, 1 for release, and 2 for release test.
With that in mind, we modify the semantic versioning as follow
Version Format : X.Y.Z.A.B
X : Major version
Y : Minor version
Z : Patch version
A : Build sequence number
B : Build mode numeric code
In the next part, I will explain standardization for workflow between programmer, artist, and game designer.
You can read the next part here :
My Journey as Tech Lead : Standardizing Project Workflow (Part 5)
