作者：Martin Annander

在我曾参与创造的每一款游戏中，不管大小，它们在方向，概念，关注点，计划，职责分工（或者同时包含了所有这些元素）等方面都带有基本的缺陷。

我曾在书中看到过一些借口。“一直都是这样的。”“上一次更糟糕。”“你是否真正想过别人能够做得更好？”“是发行商让我们这么做的！”

更别提任何愚蠢的励志演讲。“你应该为能够只做游戏感到幸运。”“下一个项目的话……”“想想版税吧！”“再坚持下它就要完成了！”

但最终这只会让我越来越厌倦这个产业。我已经准备好做一些不那么随意的事了。我本来可以离开产业并永不回头，但多亏了朋友的建议，我又一头扎进了相同的产业中并拓宽了自己的坐标。

几年后，我获得了一个机遇，即在瑞典创建一家全新的开发工作室并专注于创造教育类游戏。在2014年下半年我成为了Calm Island的游戏产品总监。

我不知道该做什么。

前两周我一直在听取一些已建立起的团队的看法，希望能够明确他们真正需要的方向。正是那时候我领悟到了：比起该做的事，我有更多不该做的事。我看到许多不该做的事反复出现着，并且在发现游戏学校未能帮助人们准备好迎接真正的实践生活时感到非常难过。但说实话，我并不能从自己的经历中找到许多该做的事。也就是说我需要从头再来。

所以我决定先从不该做的事开始。以下是我认为9大不该做的事。

don-t(from dreamstime)

1.不该滥用敏捷机制

有人曾基于更多方式跟我解释过敏捷项目管理。在我所参与的项目中总是会聘请昂贵的顾问并购买更加昂贵的软件，之后在这一新软件中也会出现同样的坍塌过程。并不会出现什么变化。如果你不能完成改变，你便不应该在一开始去尝试它们。纠正错误并不是那么简单的事，这需要你做出牺牲与决定。

2.不该太过依赖于头衔

在我所参与的一些项目中，有些人总是通过不断为别人创造更多工作而提升自己的位置。或者有些人会把自己的头衔当成魔杖，甚至忽略各种常识。而这通常都是以牺牲项目质量为代价。游戏开发通常都包含许多人，所以民主真的非常重要。

3.不该创造怪罪文化

当你停止讨论到底是谁做了什么并开始讨论问题本质时，你便等于开始寻找解决方法。在一家会将罪责归咎于个人的公司中，所有成员都会害怕自己变成那个可怜的人，并为了避免这种情况的发生而学会怪罪别人。不管是谁犯了错都不重要，因为问题的出现往往是伴随着实际原因。讨论问题将让人们在解决问题方面更具有创造性，而讨论是谁犯了错则只会让大家闭上嘴。

4.不该只做一些分内的事

我认识一些并未真正使用游戏引擎去测试自己作品的专家们。人们将其称为“test_3”或“test 3”。更糟糕的是，我还认识一些明知道这是错误的，但却并不在意也从未对那些忽视了这些所谓“小事”的人做出反应。这一切都是因为他们认为这并不属于自己的工作范畴。为什么美术师应该担心“test 3”会破坏文件系统？为什么程序员需要担心新着色器的纹理太暗？即使专业不同，但所有人其实都是朝着同一个目标前进。你应该跳脱个人任务并努力做一些对项目有帮助的事。不要一心只想藏在你的部门中。

5.不该宽恕精英主义

所谓的精英主义比之前提到的头衔问题更加深入。寻找原因的过程很重要，例如检查所完成的工作的系统，这一过程是一视同仁的，并不能为任何人开绿灯，特别是不会以头衔，公司历史或人际关系为基础。如果你过度依赖于精英主义或带有偏袒心理，你便很容易忘掉那些最重要的事，如此职业发展或项目决策制定也会偏离正确的轨道。你应该给予人们真正符合他们的正面或负面评价，不应该应人而异。

6.不该过度开会

在我的记忆中大多数会议都是没有实质性的。不管我们谈论的是玩家是否理解游戏的某些部分或者理念是否合理，从来都不存在任何相关会议计划表或相关数据，这一切只是我们单纯的猜测。没有参数，没有测试，没有项目相关指南，什么都没有。有的只是“我不认为任何人都能够做到这点，”或者“我昨晚玩的其它游戏也是基于这种方式。”这对于整个产品而言是无依据的参数。我自己曾这么做过，但是今天我要做出改变。任何声明都不应该是基于假设，除非你们开的是关于头脑风暴的会议。如果你真正想要讨论某些事，你就应该先把事实搞清楚。不要误解创造性过程。只有先明确这一过程你才能够真正发挥创造性。当出现一些你并不是很了解的事情时，请一定要大胆地承认。

7.不该惩罚团队

这是一个硬道理：如果遭遇发行失败的话，那绝对不是团队的错误。而是管理者的错误。强迫人们不断加班，取消假期或威胁员工都不是有效的做法。这只会打压员工们的士气并导致团队对管理者的反抗，员工们将会把找工作或完善自己的简历作为日常工作的一部分。不管是对于产品还是对于团队来说这都不是一件好事。管理者必须努力保护团队并关心团队，这是他们坐在那个位置上需要担负起的责任。如果你不能有效做到这点，员工们便会觉得自己不能完成你的要求或者他们也不会再把你当成管理者也不会再尊重你了。

8.不该进行功能蔓延（游戏邦注：指在发展过程中产品或设计的需求增加大大超过他们原来预期的趋势，导致其功能不是原本计划的并且要承担产品质量或生产进度的风险）

当你在往杯子里倒水时，你总是知道该倒多少水。然而在生产中的一个大问题是，我们总是会遇到功能蔓延或其它类型的要求。对方通常会以一种恐慌的心理说着：“现在就做！”他们同时也会带着一种轻视的态度，并且这些人往往都未曾参与过制作。他们只会觉得“这有什么难的！”但事实上他们却正在往杯子里倒过量的水。这时候你需要明确自己的执行过程，然后确保是否真的基于这种方式在行动。使用适当的截止日期并始终遵循着它。如果你认为内容够了，那么便不存在“多一个纹理”的空间了。你应该始终遵循着计划行事，即使这可能会在短期内造成不利的结果。

9.不该依赖于迭代

游戏开发中最大的浪费便是反复做着同样的工作。这是在任何人明确应该做什么事之前致力于某些事的结果，并且这通常会将一个糟糕的过程隐藏于游戏开发阶段之后，“这就是一个迭代过程。”在我所参与的任何项目中从未有过任何适当的试验性生产，创建原型与概念化过程。它们都只是直接跳到制作过程并且直到首次发行前5分钟才会停下来。同一个关卡可能会经历上百次的重整。通常情况下这只会加重员工们的工作负担，因为这一切都是在办公室内部进行的—-这并不能满足真正的需求。你应该仔细且清楚地定义产品。并在你觉得合适的时候进行创造。

（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转发，如需转载请联系：游戏邦）

Game Studio Don’ts

by Martin Annander

Every title I worked on, no matter how large or small, had fundamental flaws in direction, conceptualisation, focus, planning, distribution of responsibilities, or even all of them at once.

I’ve heard every defensive excuse in the book. “It’s always been like this.” — “It was worse last time.” — “Do you really think someone else does it better?” — “The publisher made us do it!”

Not to mention every ham-fisted motivational speech ever attempted. “You should feel lucky to work in games at all.” — “Next project…” — “Think of the royalties!” — “Just one more crunch and it’s done!”

But in the end, it ultimately made me fed up with the industry. I was ready for something not quite as arbitrary. I could have left the industry and never looked back, but thanks to a friend’s recommendation I moved on inside the same industry instead and widened my frame of reference a bit.

A couple of years later, I stumbled onto the opportunity to start a new development studio making educational games in Sweden. I was signed on as Game Product Director for Calm Island in the second half of 2014.

I had no idea what to do.

I spent the first two weeks listening to the already established team, hoping to figure out what kind of direction they really needed. That’s when it hit me: I had way more don’ts than dos with me. I could see many of the don’ts repeated, and it hurt me to see that game schools didn’t do a better job of preparing people for real-life production work. But frankly, I couldn’t think of many dos at all from my own experiences. I’d have to start from a clean slate.

So I started with the don’ts. The nine biggest don’ts are what I’m sharing here.

1. Don’t Misuse Agile

People have explained agile project management to me in more ways than there have been people talking. Titles this, terms that. But what always happened where I worked was that an expensive consultant was hired and a more expensive software acquired, followed by the very same broken processes used in this new software. Nothing ever changed. It just had user stories added, and maybe some post-its on a wall somewhere. If you don’t go through with your changes, you shouldn’t try them to begin with. Fixing what’s wrong takes more than words – it takes sacrifice and determination.

2. Don’t Rely on Titles

Some projects I worked on had people who constantly motivated their positions simply by generating more work for others. Often outside of schedule. Or people waved their titles like magic wands that would supposedly grant them immunity even from common sense. Not to mention the trash-talking and name-calling that could come with the titles, as people turned the office into a political playground in the name of various power-grabs. Almost always at the cost of the project’s quality. Game development normally involves too many people to be a democracy, but titles for the sake of titles will never solve problems, and they won’t grant unconditional respect to unproven, unknown or even unpopular individuals.

3. Don’t Build Blame Culture

When you stop discussing who did what and start discussing the problems, you can also start finding solutions. In a company where blame gets pinned on individuals, everyone becomes deadly afraid of becoming that guy, and will start going to great lengths to put blame on others so they avoid becoming that guy. In the end, it’s irrelevant who it was that did something, since problems usually come up for structural or practical reasons. Discussing problems will let people be creative with solutions – discussing whose fault something is will shut everyone up.

4. Don’t Departmentalize Focus

I’ve known specialists who didn’t ever start the game engine to test their work. People who named files “test_3” or even “test 3.” Worse than that, I’ve known people who knew that this was wrong, and simply didn’t care, never reflected that others would care or even willingly ignored that such “small things” are actually important. All because they considered it to be outside the scope of what they were hired to do. Why should an artist care that “test 3” breaks the file system? Why should a programmer care that the textures are too dark with the new shaders? Everyone has to work towards the same goals even if their specialisations are different. Look beyond the singular task on your screen and do what’s good for the project. Don’t hide in your department.

5. Don’t Condone Elitism

Elitism goes much deeper than titles (mentioned earlier). The reason process is important, for example a system for reviewing what gets done, is that the process should be exactly the same for everyone and never give a free pass to anyone – especially not based on title, company history or personal relations. If you rely too much on elitism or favoritism, you easily forget what’s most important, and career development or project decision-making starts becoming a struggle to have lunch with the right person rather than doing a good job. Give people the good and bad criticism they need and deserve, no matter who they are.

6. Don’t Overdo Meetings

Most meetings I can remember had very little substance. Whether we talked about if players would understand a certain segment of a game or if an idea was good or bad, there was never any meeting schedule or relevant data, just pure assumption. No metrics, no testing, no project-specific guidelines, nothing. Just vague arguments like “I don’t think anyone will get this,” or “this other game I played last night does it this way.” Empty arguments with no concern for the whole of the product. I’ve argued like this myself, but these days I try not to. No statement should ever be based on supposition, unless the meeting is a freeform brainstorming session. If you care to argue for something, get your facts straight. Don’t confuse creative process for a situation where anything goes. Define the process, then get creative. Admit it when there’s something you don’t actually know.

7. Don’t Punish the Team

This is a hard truth: it’s never the team’s fault if a release fails. It’s the manager’s. Forcing people to crunch endlessly, cancelling holidays or threatening people’s jobs is simply not the way to go. It will crush morale and will create a situation where it’s the team against the management or where people make it part of their daily routine to search for new jobs or polish their portfolios. This is terrible both for the product and for the team overall. A manager has to protect the team and care for the team to bring out its best, and this is a constant process that starts with taking responsibility. People have to feel like they couldn’t do your job, or they won’t respect you as their manager.

8. Don’t Do Feature Creep

If you fill a glass, you know that you can’t pour more water. Yet, one of the biggest issues in production in every place I’ve been has been feature creep and other kinds of spot requests. They’re often more or less panicked, “do this NOW!” They’re also often formulated in a trivialising manner, and from people outside the affected field of work. “That can’t be too hard – it’s just X.” But what they all ultimately do is that they pour more water. This is another situation handled best by process – define how you do things, then make sure to do it that way. Use proper deadlines and follow them. If you say content stop, then there’s no room for “just one texture.” Be consistent, be fair and follow the plan even when it hurts in the short-term.

9. Don’t Rely on Iteration

One of the biggest wastes in game development is to do the same work multiple times. It’s often an outcome of working on something before anyone even knows what that something is supposed to be, and it often hides bad process behind the game development adage, “it’s an iterative process.” There has never been proper preproduction, prototyping or conceptualisation phases on any project I’ve worked on. It just jumped straight into production and didn’t stop until five minutes after the first release candidate. The same level would be rebuilt a hundred times, inside the game, rather than getting reworked on a whiteboard or low-LOD where it takes hours to make important decisions and not weeks or months. Often, this was just to keep people busy because they happened to be at the office – not to meet actual needs. Define the product carefully and tangibly. Build it only when you know what to build.

End Rant

I haven’t seen attack ships on fire or c-beams glitter, but I have seen things in game development that have shown me over and over that there’s a very long way left to go. But these don’ts are just the beginning. Now comes the hard search for the dos!(source:gamasutra)