Original Chinese version: 2011 Fall.
Translate to English version: 2012 Spring.
- Before the content, and a brief introduction to game production.
- The tools we can use.
- Software planing.
- Human resources and requirements are changing.
Before the content, and a brief introduction to game production.
This article is about the management of a game software project. It's a combination of personal experience in my previous projects and a course of PMP at DCI( http://www.dci.org.tw/ ).
I was a game programmer at IGS( http://www.igs.com.tw/ ) in Taiwan before 2012' May, the lead programmer of my team. ( My next job will be at a new software company. ) Therefore, this article is base on the knowledge of a software member.
In brief, as long as the member number of a game team grows more than 3, this team will need a somehow management. A good management will collect information of our game production, keep consistancy between our thoughts(or goals) and actions, and reduce the unknowns and the time of re-work by all causes.
In conclusion, I found two common managemnet problems that often occur among game teams.
1. Before we promote project managers ( or we may call them producers / directors in different companies. ), the company usually doesn't evaluate their skills in management. We promote them because their seniority, their high technology skills, or maybe good relationship with others. These three features are certainly important to be a manager, however a good relationship doesn't mean this person can carry our project on schedule, and cannot guarantee to choose the correct pathes at tough choices, which are good for the team and the project.
2. Because we lack for management skill training, the scale of our teams can't expand. Therefore, we split the human resources of entire company to multiple teams according to the management ability of those project managers. However, the senior management seems not know how to deal with the cooperation and association between these multiple teams, and it results in letting them compete with each other, fight for resources, like different companies.
If we don't view these two problems seriously, It has a large chance to become somehow like a black hole: comsuming the output of teams, creating conflicts, losing good workers or their enthusiasm, no more growing of this team.
I will start with a brief introduction of game production in case the readers are new challangers of this industry. If you are well experienced, please feel free to skip to the next section.
Like all other types of projects, a game software production usually includes several steps:
- What (game) do we want to make?
- What (task) should be done in order to complete it?
- Who should be charged with those tasks, and when?
- To excute those tasks till the end.
The period of these steps varies from weeks to months, depending on what kind of product we want.
We will setup some milestones for our product, and usually there will be at least a milestone called prototype, to make sure that the ideas we discuss at meeting room are actually entertainable.
But what should our prototype be like? If we just put and move pictures and some symbols on the table, does it really prove the ideas? Who will and have the right to decide that this project is worth continuing or the prototype is bad like trash?
- From the view point of the boss or market team members, this prototype maybe like trash, because it's completely beyond market standard. They may view it from the standard of mature products on the sheves.
- From the view point of testers or potential players, it's confusing, because it needs lots of explanations and imagination for the meaning of each symbol to make testers understand how this game works and I'm sure it's not exciting comparing with the other products on showcase. Meanwhile, we certainly will not let a player decide our future.
- If we only review the opinions of our team members, it loses the meaning of evaluation or examination.
How completeness should the prototype be in order to prove this idea works?
What should we do next, if the prototype is failed?
These are management, and the answers of those tough choices differ among all kind of teams in all kinds of situations.