3 replies to this topic

[NDarkTeng]

My Game Software Management Experience

Author: NDark
Original Chinese version: 2011 Fall.
Translate to English version: 2012 Spring.

Outline

• 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.

[NDarkTeng]

My Game Software Management Experience

Author: NDark
Original Chinese version: 2011 Fall.
Translate to English version: 2012 Spring.

The tools we can use.

In the section I will quickly introduce the tools which help our development.

From the easy one to complex, there are three kinds of tools:

• Version control.
• Bug tracking.
• Prject management.

Most software teams I know have used version control already, and completely understood the importance of it. Even those teams have only one programmer, I will still recommend them using version control immediately.

Version control helps controlling the progress of our product each day, even each section in a day. It forces developpers commit(upload) their work results to a server, which is open and accessable easily to all team members, this benefits the company and the team definitely. And it also helps improving quality of source code amd resources.

What kind of version control we should use? It totally depends on the style, the habit, and the scale of teams.

• If we are new to version control and we develop on windows platform, choosing Subversion and TortoiseSVN will save a lot of time. Use it right now. Once our team gets used to this kind of development method. We can easyly change to other tools, they basically are all the same.
• If our team members are seperated between different working places, or they have lots of bussiness trips, we will need those solutions without server.
• If the number of files under version control is large quantity, some old version of Subversion may have performance issue, choose the new one.

There is an issue we should discuss here.
That is, should we put the outputs of designers and artists under version control?
The media (ex. textures and script files) using by our running product should be included, of course.
But how about designing documents, intermedia of script (ex.excel), source media of artists(ex.psd), or even our concept art? I will recommend try putting them under version control, no matter they are under the same repository(server) or different ones.

However, this kind of file accessing method is somehow unfamiliar by the designers and artists. Sometimes it needs political force to enter, to explain to our team members that this kind of method is not making trouble intentionally. This method helps the team to manage their files when the scale of our team grows up, it helps each one to view the progress of all other members very fast and directly, and it reduces the conflicts between both contents and individuals when members modify the same document ( or file ) at the same period of time occasionally.






In second part, I briefly discuss about bug tracking.
I believe we all know what are bugs. This system, in the literal meaning, is used for tracking those bugs.
Therefore, I will talk about it in the reverse side.
That is, if we don't use a system to tracking bugs, what will happens?

• When a bug is reported by someone, and we don't record it in any form ( that means this bug is reported orally only ). Sooner or later, this bug will be ignored, or be forgotten.
• Someone does report it and record it in some form ( no matter documents or files ), but this bug is not assigned to anyone. That means no one is trying to handle it, or find out what's going on.
• It is reported, and someone process this bug, however there is no feedback of the result of that bug. In order to understand the status of each bug, we have to spend time in questioning our workers in detail whenever it needs.
• That means the senior management (including project managers) can not abstract the whole picture of the stability of entire project, espcieally via a simple representation and without interrupting our workers.

Third part of them is the kind of tools for project management, like documentation and task management.

Without this kind of tools, we still can make good game products. Designers write documents everday, artists create 3D models and pictures everday, and programmers add source code of each component everyday. Each task will be assigned after communications, conversations, or meetings. Each task will be tracked by our project manager, lead programmer, lead artist, lead designner, and even the excutors themselves. We will use real papers, e-mails, tips, and even just orally orders to note and assign each task.

The tools for project management, like bug tracking, only change the form of assigning tasks to a web interface that can be access by each member in the team. These tasks will have titles, descriptions of spec., excutors, start time and end time, statuses and completeness.

If your team is small enough that the members can sit shoulder by shoulder, I believe you will feel the oral conversation is the most effective tool. However, when our team grows, we will start needing some kind of interface more than words and human brains, it benefits us like bug tracking system.










The final part of tools I want to mention is that "these tools are only tools". We design, solve problems, and complete our jobs. These works are done by persons, our excellent colleagues. The value of above tools only emphasize the ability of us, and we shall not expect them as magical mechanism.

[NDarkTeng]

My Game Software Management Experience

Author: NDark
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.

[NDarkTeng]

My Game Software Management Experience

Author: NDark
Original Chinese version: 2011 Fall.
Translate to English version: 2012 Spring.

Human resources and requirements are changing.


We have already had the documents and a plan. Will there be a happy ending?

The progress will not go smoothly, the tasks will delay, and the human resources will be idle or will leave at some time.

What should we do, when the schedule is delayed, and the next task shall start?

The advantage of assigning all tasks at the beginning is able to estimate the whole period of time. However, when we estimate or predict something, it means there will be inaccuracy or errors.

If the excutor knows the starting time of his next job, he will be rushed to be "on schedule", or will pretend that the working task is completed. If we test inattentively, and let the working task pass, we will pay it back in the future. If we verify it seriously, the next job and the whole schedule of course will be delayed.

Shall we flog our workers?

We must understand the future is un-certained and every project is a new challange waiting for explore. If we know exactly the whole period of time, that is not a project, it's just like something we have done before.


Being different from assigning the excutors in the first, I try another way dynamically. The estimation is for whole schedule roughly, when the next job is about to start, the true excutor is assigned. This kind of method results in dynamic or floating period of total time of course, but as my experience, the excutor can actually do their job with good quallity when no other thing is chasing him. In this case, the management bravely keep un-mature workers and tasks at the same place.

And of course, the next job will "always" be taken by any idle member "in time". Who takes the most jobs is the one with high productivity.




Back to the game product, its requirements somehow change faster than other kind of products. There are many reasons for changing.

• We change, because the idea is not fun after the prototype.
• We change, because our technology level cannot support our idea.
• We change, because the schedule is too long beyond our budget.
• We change, because the boss don't like the color of background.
• We change, because we complete the project too fast and still have lots of time.
• We change, even because we spend on the project too long, the market changes.

The bible of design pattern loudly tells us "requirements are always changing."

Even Workers with fully enthusiasm will wait and see if the requirements do not move anymore. Because if the requirements keep changing, the tasks will not be finished obviously. Even we complete them as fast as we can, the new tasks will keep popping.

This is not a good thing to mangement. However, as my observation, they are not this kind of workers at the start, this environment effects them.

From the viewpoint of result, the changing of requirements will have these type:

• Totally different requirements, completely re-work the features. This kind of changing will need analysing again, estimating again, and implementing again. From the bright side, this kind of changing usually will have a new schedule.
• Reduce the requirements, this kind of changing is friendly to excutors. If we did plan in detail, we can skim some parts to achieve the goal.
• The type of requirement propagates, a animation of waving a knife is not enough, now we have to add sparks, add the shadow of blade, the background scene changed to the moon, and back to earth after this animation. This kind of changing is annoyed, because it happens gradually. And this kind of changing will ruin the architecture of system designed originally. It sometime is a nightmare to those workers.

I can understand the necessity of changing of requirements, however in my oberservation, the management often ignores that the schedule shall be changed at the same time. We know that the schedule changing means that the budget changes too. No one want to take the responsibility. Obviously over-time work usually is the first strategy been used. If no miracle happens, we can show mercy later.

This kind of thing hurts the team, not only we ignore the risks and possiblity that we can't make it in time, but we ignore the reacting ability to possible danger. We ignore the mayday signal send by person with vision, we hurt the trust between our team members.

When the schedule is not possible to excute, the solutions are obvious:

• Increasing time.
• Reducing requirement.
• Looking for more hands.

The sequence is in the order of quantiy that they help.
Try deciding a reasonable schdule to the whole team, do not be chased by our schdule.



The procedure of requirement changing shall include these steps:

• With somehow certain reason, we change the requirements.
• We discuss how it will be.
• We analyse and estimate the new schedule, if that is not acceptable, back to step 2.
• Replace or insert to the schedule.
• Modify the documents.
• The tasks are excuted by programmers, artists, or designers.

As my experience, there will be a disaster without completing this procedure,

For example, with only step 1 and 6, the boss shows up, he convinces artist changing the model he doesn't like. I am sure the model will be replaced at the day after tomorrow.

Without step 5, someone will implement the old document, and the quality assurance may be produced by this old document after failing in test.

Without step 3 and 4, just change whenever we want, extra works in old schedule, over-time works there should be, bad ending.

Each modification will take some time, even just a small hour. Those "one hour" will finally accumurate to huge thing we can not ignore.

I humbly think that the best time we should insert the tasks of requirement changing is "after this milestone". We shall let the excutors rush in current goal without hesitation. Start new specification at next version, that will minimize the damage to our team.




At the end of this article, I cite the ancient wisdom of the Confucius
"The most important is trust, the second is living(of members), and keep the weapons(our products) at the last."