My Game Software Management Experience
Original Chinese version: 2011 Fall.
Translate to English version: 2012 Spring.Software planing.
After the software team ( or programmers ) gets the documents (ex.GDD) by designers, we will start software analysing and planning.
- The analysing is to transform the GDD to another kind of documents (ex.TDD) that can be implemented by programmers.
- The planning is to arrange tasks and human resources in order to implement the system described by the TDD.
In the highest standard, a perfect GDD means it can be transformed to the the same TDD by different programmers.
The same, a perfect TDD means it can be implemented to identity product by different teams.
I haven't seen the perfect document, but it doesn't mean it is not worth to try.
Each time after designer produce GDD, we should examine its realizability.
( We do not examine it is entertainable or not, cause it's the duty of designers to make it fun. )
How detail we should examine?
There are many principles I usually use.
- Mis-spelling and error grammar. We want our game 0 bug, try making it so at the beginning. It's an attitude. Write these documents as an adult, proofread them mutually, we are a team.
- The sentences are too complexed, abstruse, or hard to understand. Try making them simple by using the formmation of bullet points.
- Describing one thing by using different nouns in different parts among document, like "fire" and "flame". They should be the same in case that it will be implemented to different items in the game, and this kind of error usually won't be discovered before the end of the production.
- The branch document being edited from wrong or old version. Start use version control, find out who makes this mistake, and make sure the responsibility of each document.
- Multiple descriptions in multiple parts in one document, and only being modified one place. Use hyperlink to collect these duplicated parts.
- Sperate our chapters and sections by subjects, like characters and monsters, battle gameplay and strategy scenario. Reference them when describing them in irrelevant section.
- On the contrary, the same idea should not be described seperately in different parts.
- Use tables and hyperlink to describe parameters, for example of the speed, the frequency, the size. Let parameters be adjustable at the beginning of our product.
- List priority of each feature. Make our production time be flexible.
After we fully understand the GDD made by our designers, the next job is to write a TDD that will be read and can be implemented by programmers.
As we mention above, the perfect TDD should produce identity product by different teams. That is, this document should write in detail each member and each method ( or interface ) of all components. The outer functionality and inner operation of them, and the last the communication between them.
"If I am able to write precisely so much, why not just implement the code?" I scream in my mind every time. However, the game system sometimes is too large, and we need cooperation of several programmers to complete it. That is why we need to do so to prevent "conflict" and "re-work" in the future.
I have several guidelines in the following.
- Write the name of this component and its brief functionality in the first sentence.
- Describe what is contained, and who owns this component.
- The data structure of it and its members.
- Definition or default parameter.
- Interface of its initialization, its operation, and its finish.
- other constraints, or those un-usual thing, therefore, should be noticed.
After we have a complete document, we shall continue
- Deconstructing our project to tasks.
- Estimating the periods to do those tasks.
- Arranging the human resources.
What should be a task?
"To complete the game." can be a task. Above it, "To sell our game" can also be a task. We usually disassemble the work we should do to a somehow level that an employee can do that task in a period of time. The "a period of time" will depend on with how frequently the managers want to examine the progress of our workers. In my experience, I will set the range from one day to a week. Those tasks over a week, can be possibly disassembled to multiple child tasks.
After that, We will have thousands of tasks and I usually arrange the tasks about quality assurance at this moment. That means a task of "To complete weapon system." will be followed by
- To test if the weapon system is complete. (test by the lead programmer, make sure it truly works at running time)
- To debug the weapon system. ( those in-correct bug based on the features in our document )
- To maintain the weapon system. ( after several weeks, the other system is connected, there will be relative bugs. )
- To verification weapon system. ( by test teams or QA members, they examine the system by each item we have writen in the documents. )
When we develop our product, there will be specified bugs and corresponding tasks like this:
"To solve the problem the weapon is failed when we use button A and B at the same time."
By the way, the tasks of management should be arrange here, those tasks which be done by the project manager, the lead programmer, the lead designer, the lead artist, etc. Those tasks will be labeled like "To discuss and arrange tasks", "To examine the completenss of product", "To complete a slide for demonstration", or "To build and publish the product at milestones". In my opinion, the time I spend in management is about 40%, the rest 60% can truly write source code. And for the higher managers, I guess the ratio of management should be higher, even consumes their overall working hours.
Estimating the periods to do those tasks should be the first and most controversy we will encounter.
Because it is about future, and future is full of uncertaincy. How can we know how long it will take before we actually do the job? It all depends on experience. And because of it, the period of time will differ from viewpoints of different persons. Who or which result should we rely on?
It's not only a technique problem, but a political one. When the schedule explodes, it just happened, no one can press the reset button, reload the level from the last check point.
Estimation have some approaches.
- From the buttom up, ask the possible executor to estimate the period of time of a task and those time will be accumulated to the top ( or the root of the task tree ). The obvious drawback of this method is that the requirements or specification of the task is not clear, and the junior colleaques might not understand it fully. Too long estimation it will be.
- From the top down, the estimation of the senior members should be close to actual value, however, it might not take the ability of excutors into consideration. Too short estimation it might be.
- If we use the longset estimation among all members. The total time will be too long.
- Estimation twice. First from senior members, and when the task is actually assigned the excutor estimates it again. This kind method definitely makes the schedule keep changing or dynamic. However, it is flexible, and representable to possible truth.
Arranging the human resources is assigning the tasks to colleaques, and after this, we can actually find out the final and exact date we will finish this project as long as we don't cheat ourselves in the previous situations.
When assigning tasks, we should notice that
- Who is responsible for what tasks? Does anyone have favor in some tasks? Does someone actually CAN do those tasks?
- There will be successive relation between tasks, it results in that those tasks can not excute at the same time by different excutors.
- How is the cooperation of this team? Can they hand over smoothly the successive tasks like pipeline? If the answer is not, assign the relative tasks to the same person.
When we assign these tasks by the order of importance, we will discover the imbalance. Some personnels will be idle in specified time. Take efforts to adjust them accoring to quantity and importance.
In my opinion, I will assign the tasks of low technology and long working hours to junior members, therefore, they can focus on one thing at the time. Assign myself those tasks which are not urgent, but important. Do not fill all working hours of high technologic members, let them be able to support emergent situations whenever it needed. Pair the members with the man respondible for system core or hold a small technology meeting, let all group members know the deail.
At the end of this section, I want to discuss the milesones.
No matter waterfall or scrum, we will have milesones somehow to examine the progress of our project. The decision of the date is sometimes more important than we think it is. Do not just pick a date like a month before we lanching the project.
"What will this milestone bring us?", we should think from this. A milestone usually means a version that can be played, a version through debugging, a version with fully expectation of our team ( maybe over-time work, LOL ). That is, we can say, the milestone means this product have gone through features completing, testing & debugging, pulishing to some group no matter to public or just group members, celebration ( happy and drunk weekend ), reviewing ( what is wrong of this version ), and starting next version ( call it next sprint if you run scrum. ).
Ignoring or lacking of any step among them will damage the morale of the team, I mean it.
- Going testing when the features havn't be completed.
- Releaing to players before fully testing.
- No appreciation after hard working.
- The development exists potential problems, but no one want to discuss or even solve them.
- No brief break, all we have are uncountable un-finished tasks.
I think the time after important features are completed is the right time for milestone, that's why we do planning, to know at what time we will have it. I experience so many milestone checks that do not have requirements or specification. Because of it, we add some features or tasks just for its demonstrating, and those tasks certainly will be removed after it.
I also experience so many times that the date of demonstration has been set, and the features or functions are discovered "not completed" at the beginning of testing. Therefore, the features will be done in the middle of testing period, or even the day before demonstration. Of course, without fully testing, there shall be bugs.
This kind of things discourage the team, and create large risks.