作者：Jameson Durall

创立新项目促进我思考了许多提升团队对所构建游戏的热情的方法。过去10年间，我在各种不同的团队类型中工作，看到许多不同的运作方式，成功的程度也是各种各样。就我通常所参与的游戏类型，团队规模达到上百人是常事，仅成员间的交流就存在困难。

处在项目初期的小团队通常会花费时间来思考要围绕哪些功能来构建游戏，游戏续作需要增添哪些新的功能。有些团队利用这个阶段的时间来为游戏做计划，做出某些高层次的决定，这样成员就可以在开始工作后明确目标和方向。

有些团队或许决定利用这段时间来放松下，由此让成员产生大量有关开发各个领域的想法。这意味着需要先让部分人走在前面，但是必须等待团队其他成员赶上，落实先驱者做出的决定。

依我看来，在创建新项目时，游戏开发者通常可以分成两种类型。第一个群体乐于成为决策过程的一部分。如果你在早期就敲定了设计决策，他们会觉得自己的想法无法受到重视，而且很可能无法完全领会已经拍板的设计决策。

另一个群体希望团队能够尽早做出重大决定，这样才可以将自己专业的知识用上，在那些限制条件内开发出最棒的游戏。如果你保持决策的开放性，他们或许会觉得团队缺乏方向，怀疑自己能否在这种缺乏方向的境况中发挥作用。

你要如何包容这两类人群呢？最好是你能在前期获得第一类人，在项目开发后期获得第二类人，但是这仅仅是种理想的情况。那么，我们要用哪些方法让人们真正领会和支持我们做出的决定呢？我希望自己能够给出准确的答案，但是现在还做不到，只能提供些许个人想法：

交流

communication(from gamasutra)

我认为，重点在于保证团队中的每个人都能够马上清楚地明白已经做出和还未做出的决定。尽量给他们提供决策背景，努力让他们理解做出决策的缘由。如果每个团队成员都能够马上获得合适的信息，那么误解就会消除，团队就可以继续向前发展。他们或许并不会对那些已经做出或还未做出的决定感到满意，但是上述做法可以算是引发讨论的良好开端。

有时，你自认为所有人都一致同意某个决策，但是却发现自己无法足够高效地将想法传达给团队成员。这个过程需要大量的工作，往往需要多次尝试，以确保正确的信息能够传达给每个人。设计师通常很重视这个阶段，因为他们不希望将来需要为决策做更多的阐述，甚至希望团队成员去阅读他们所编写的话题相关文件。

信息透明

transparency(from gamasutra)

在开发早期，设计师需要做大量的假设，这些假设往往在游戏开发过程中需要重新评估。构思出游戏想法是件简单的事情，但是要得出恰当的设计决策，就必须找到能够领会游戏愿景的合适成员。

其他人员会认为是设计决策改变了他们的思维方式，不知道要采取何种做法，他们觉得不断变动的目标让自己的工作变得艰难。乐于参与这个过程的团队成员或许会认为，如果他们能够参与前期的决策过程，那么做出的决策或许会更好。于是，设计团队的不满便会迅速出现，而这种相互尊重之感一旦失去便很难重新构建。采取某些步骤来修正之前提到的交流也许会有所帮助，最糟糕的情况是，有人的工作需要返功或者认为自己在团队中完全没有价值了。

你必须尽量保证成员清楚地理解已经做出的决定。你需要记住的是，每个团队成员的时间和观点都是有价值的，即便这些观点可能与你当前目标并不相符。这种理解至少可以保持团队成员间的共鸣，让所有人都能够高效率地合作。

自由沟通

alcohol(from gamasutra)

如果你发现某些团队成员难以接受整个团队正在制作的游戏，那么尝试单独外出与之交流。前往某些与工作不相关的地方，一起喝杯酒或吃个饭，让他们坦诚地说出内心的症结。这种自由的谈话往往可以帮助你更好地了解团队成员。

游戏邦注：本文发稿于2011年8月31日，所涉时间、事件和数据均以此为准。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Opinion: You Can’t Please Everyone… Can You?

Jameson Durall

Starting up a new project has me thinking a lot about ways to improve team buy-in and enthusiasm about the game that we are building. I’ve worked on many different team types over the last decade and have seen many ways to run things… with varying degrees of success. As team sizes are easily in the area of 100+ people on the types of games I generally work on, communication alone becomes difficult.

The small team on the beginning of a project is usually spending their time thinking about what key features they want to build the game around… or what new features to add in the case of a sequel. Some teams use this early time to make the plan for the game and nail down a lot of the top level decisions before everyone else rolls on so people can hit the ground running.

Other teams may decide to use this time to keep things very loose and come up with lots of ideas for ways to go in various areas of the development. This could mean having front-runners in areas of decision as a basis to work forward from, but essentially waiting for a bigger chunk of the team to come on board and help make those decisions final.

There generally, in my opinion, seems to be two types of game developers when it comes to moving onto a new project. The first group really enjoys to be a part of the decision process. If you choose to lock some Design decisions down early, they will feel that it’s too late for their ideas to be heard and they may not feel like they can fully get on board with the decisions that were made.

The other group prefers to have the big decisions made so they can apply their expertise to the situation and make the best game possible within those constraints. If you keep things open, they may feel that the group doesn’t have their heads on straight, what have they been doing all this time, and how can I be effective in this lack of direction?

How do you accommodate both types of people? It would be ideal if we could get the people who want to be involved first and the others much later on… but that kind of thinking is from a dream world. So, what are some potential ways we can get people to buy-in and truly get behind what we are making regardless of what method is being used? I wish I had answers… but I do have a few thoughts:

Communication

I think it’s important to go out of your way to ensure that every person coming onto the team knows exactly what decisions have and have not been made right away. Give them as much context as possible and try to help them understand why. If every team member gets the proper info right away, then any misconceptions can be washed away and a new groundwork can be laid for moving forward. They may not be happy with the decisions made, or not made, but this allows a great starting point for discussions.

Sometimes you’ll think that everyone is on the same page about a decision and find out that you weren’t effective enough in getting the message across. It takes great effort, often multiple tries, to make sure the right info gets to everyone. This step is sometimes deemed important by designers because they don’t feel they have to justify decisions or even expect that team members will read the documents they have created about each topic (they won’t).

Transparency

I think there is often a lack of understanding of what a Design team does and how even our best laid plans early on can go horribly wrong. There are a lot of assumptions that have to be made by designers in the early stages of development and those sometimes have to be re-evaluated as the game evolves or cuts happen. Coming up with ideas is easy…it’s finding the ones that fit in the vision of the game and with your constantly changing time constraints that make them good Design decisions.

Other disciplines often view this as Design changing their minds or not knowing what they are doing and it’s hard for them work toward a moving target. The team members who prefer to be involved may say the decision would have been better if only they would have been included in the first place. This can quickly lead to resentment of the Design Team, and that kind of respect is hard to regain once lost. Taking steps to fix the before mentioned communication will help with this, but nothing sucks more than someone doing work that later needs reworking or deemed unneeded entirely.

You have to do your best to make sure people understand as best as possible what goes into the decisions that are made. Respect goes both ways and you need to keep in mind that every team member’s time and opinions are valuable even if the opinions may not fit with your current goals. This kind of understanding can at the very least get you some empathy and keep the respect levels at a place where everyone can work together effectively.

Alcohol

I’m only partly kidding about this. If you find that some of the team members are having difficulty buying in to the game that everyone is making… try taking the discussion outside. Go somewhere outside of work and have a drink or lunch together and just talk frankly about what frustrations they are having. A very free conversation like this can often help you understand each other better and alcohol can only help with that right?

In the end…this is something I’m thinking a lot about for my project before team members start rolling on in large quantities. I obviously don’t have the answers, but really wanted to use this as a topic for discussion. What ideas do you have for helping with this? (Source: Gamasutra)