作者：Svyatoslav Torick

简短的介绍：自从2008年以来，我曾在各种不同规模的团队（从3人到30人都有）担任游戏设计师，并且本文中的所有内容都是我所经历过的。

游戏设计师总是非常忙。他们必须创造某些很酷的内容，确保玩家始终留在游戏中，尝试着避免玩家感到无聊，同时还需要避免呈现过多的信息。游戏设计师是唯一一个完全控制游戏体验的人，所以为了创造无缝的印象，他们必须做出让步与牺牲。在本文中，我想要向你们呈现游戏设计师所经历的噩梦般的5大工作问题。

Game Designer(from keywin)

1.一切能够创造的内容已经被创造出来了

这里存在一个悖论：电子游戏产业已经有40多岁了，但却仍然是一个动态且高技术的行业。每一天有无数游戏出现在各个平台上，如果你突然想出一个很棒的理念，请先尝试着去搜索看看。最有可能的情况是，你的想法已经在某一时刻某一地点被带到某一款游戏中。以下是另一个悖论：在电子游戏产业中，你最狂热的幻想其实是一文不值的。所以你该做什么呢？

我们从书上学到的是不能偷窃，但在游戏开发中，不借鉴一个优秀理念是很困难的事，或者说证明那是你自己的想法而不是你从参考截图上所看到的是非常困难的。很快地游戏设计师便开始冒险，他们必须思考的第一件事是“他们在哪里执行了这一内容？”如此思考并没有什么好可耻的：程序员会使用别人所编写的程序库，所以游戏设计师也可以从100万款游戏中汲取灵感。

顺便说一下的是，这也是我为何认为对于游戏设计师来说，纯粹的游戏体验比使用模型软件的注册证书重要得多。请果断地去搜索你的记忆库，但同时还要牢记：在哪里以及如何找到你的理念与去执行你的发现是完全不同的。

2.外表vs功能

让我们假设你正在创造一个带有按键的经典用户界面。你拥有一些带有同样布局的不同屏幕：共有4个按键，它们被设置在较低处，它们具有同样的规格，并且同等重要。为什么要这么做？因为这是最流行的风格，你的GUI专家建议你创造具有同等重要按键的屏幕。所有的一切都进展顺利，直至有一天你意识到你所创造的下一个屏幕多出了2个功能。这时候你可以添加另外一个不如其它按键重要的按键，但这么做却不具有说服力。

这是一个经典的游戏设计师矛盾：你可以做一些让视觉效果更佳整洁的事，但通过添加不必要的按键将破坏“一致”体验，或者将不利于整体的理念呈现。

通常情况下，解决方法是介于两者之间。有时候你必须创造全新的屏幕类型（游戏邦注：带有4个按键的“标准”屏幕，带有3个按键的“弹出式”屏幕或者带有2个按键的“认证”屏幕等等），有时候你可以将按键调整为当前功能所要求的规格。

这里并不存在任何先发制人的措施。计划一款优秀的游戏并不是假设编写A到Z的所有内容以及可能出现的任何问题。这是一个迭代过程—-这并不是一个图文并茂的短语，但对于游戏设计师来说却是十字架般的存在。

3.未知结局

开发团队越大，游戏设计师便越不清楚项目结构对于与程序员交流，写下不只代表游戏设计师的目的，同时也能符合程序员能力的文件的重要性。甚至最全面的设计文件也不是结果—-在某一时刻程序员将会找到设计师去询问各种问题。

你必须注意：如果程序员阅读了文件但却并未搞清楚细节，那么他将会“按照原来的样子”进行编程，你最终只会得到基于最简单方式所完成的功能，你有可能不能在未来对此作出任何调整。

同时，游戏设计师没有理由创造过分详细的文件。当功能最终获得开发机遇时，有些算法可能早已过时了。有些文件部分将根据另一个团队成员的要求而进行改写。甚至是游戏设计师自身也有可能想要重新编写某些内容。所以这里的要点在于—-先勾勒出主要算法和细节，并由每个参与者进行讨论和审核。

我们看待游戏设计师的努力并不是通过算法本身，而是经由用户体验，程序员也可以自己想出解决方法。我们需要好好想想；评估其对于用户流的价值；站在玩家的角度进行思考确保这一解决方法不会破坏平衡并且不会阻碍未来的发展。这一问题的一部分内容是程序员已经向游戏设计师下了通令，要求他们必须尽可能低做出决定。

你并不能真正预见所有的这些障碍，不管大小。一方面，你不能丝毫不差地编写文件（这是一个迭代过程！），而另一方面，你不能在短短的几分钟内贯穿所有文件内容而解决一个问题。所以准备好让步吧。你始终需要这么做的。

4.来不及发行

对于游戏设计师来说最可怕的噩梦便是被迫去更新并升级所有内容，包括那些已经非常完美的内容。一开始，我们便扼杀了完美主义者。尽管花了许多时间于文件中，但我们却在最后一刻被非常重要的“启蒙运动”所镇压了。你可以找到任何科学解释去解释为何这是源自你的思想的影子，但这却不能带来任何帮助—-你必须使用它做些事，并且是现在马上立刻。

这里的让步是关于完善那些即使没有程序员和美术师你也能够做到的内容。换句话说，当游戏设计师所拥有的工具越少，他们便越不可能完成这一任务。除此之外，最棒的想法通常不只是改变变量去平衡公式或添加新的实体到数据库中这么简单。

开发悖论在于游戏设计师可以设定任何复杂性和长度的任务，而项目管理者将把它添加到日程表上，但即使你允许做出一两次改变并在之后执行，你也会听到许多批评，如“你应该事先进行计划”。这都是取决于不同团队，但是你应该随时准备好抑制自己自发的欲望。

5.你是唯一的救世主

有时候会发生这种情况：出于财政，人道主义或法律原因，你不得不马上重新创造某一功能。没有多余时间进行解释，你应该马上打开电脑并思考如何进行转变。明天就是截止期限了。如果你能够将某些内容保留下来的话便算是非常好运了。

暂时先把玩笑搁于一旁。重新创造功能要从归档最初的文件（无需重新阅读或从中保存任何内容）开始。这听起来很苛刻，但这真的能够帮助游戏设计师压制自己的脾气并成为自己工作的重要元素。这份工作只是关于编写文本，填表格并绘制草稿。同样地，我们是全身心投入其中。

这便是为何重新创造或削减功能应该是从一开始就需要考虑到的事。这将帮助你不用去思考如何拯救花了许多时间所创造的最喜欢或最费劲的功能。这是许多顾问所使用的原理—-“像对待新机遇那样去考虑拒绝，失败与错误”。不要害怕，请直接打开一张白纸并开始工作吧。

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

Five nightmares of a modern Game Designer

by Svyatoslav Torick

Short introduction: I’ve been a Game Designer in various sized teams (from 3 to 30) since 2008 and everything written here I’ve experienced a lot.

A Game Designer has their hands full all the time. They have to create something cool, keep the player in the flow, trying to prevent boredom while fending off too much information. The Game Designer is the only person who is utterly and completely in charge of the game experience, so to make the impressions seamless and thorough they have to meet compromises and make sacrifices. In this article, I want to show you five working issues that Game Designers (well, me) experience like a nightmare in a B-movie.

1. Everything that can be invented has been invented

Here is a paradox: the videogame industry is more than 40 years old but still considered a dynamic and hi-tech trade. Every day hundreds of games release on platforms and if you suddenly become enlightened with a great idea, try searching the archives. Most likely, your thought has already been developed into a game – somewhere, sometime. And here’s another paradox: in the videogame industry your wildest fantasies are not worth a dime. So what is to be done?

The books tell us that stealing is wrong, but in terms of game development, NOT taking a good concept is quite difficult – or, rather, proving that it was your idea and not something you noticed on reference screenshots. As soon as the Game Designer stands up for a task, the first thing he has to think over is “where did they implement this thing already?” There is nothing to be ashamed of in such way of thinking: programmers use libraries that were written by someone else, so Game Designers have about a million games full of wisdom and experience.

By the way, that is why I think that sheer game experience is more important for Game Designer than a certificate of enrollment in using mockup software. Do not hesitate to search your memory vaults but note this: it is not as important to where and how you found your idea as it is to implement your findings.

2. Beauty vs Function

Let’s say you are developing a classy user interface with buttons. You have different screens of the same layout: there are four buttons, they are placed in the lower part, they are of the same size and they are equally important. Why do this? Because it’s stylish and your GUI specialist recommends you building the screen with the equally important buttons since you adopted unification. Everything went well for a significant number of screens until one day you realize that the next screen you are working only has two more functions. You can add another one that is of less importance in comparison to the other buttons, but that’s just lame.

This is a classic Game Designer conflict: you can either do something that is visually neat, but demolish the “unification” experience by adding unnecessary buttons, or dismiss the whole concept and place as much functions as you need for this screen.

Generally, the solution is somewhere in between. Sometimes you have to invent new screen types (“standard” with four buttons, “pop-up” with three, “confirmation” with two etc), sometimes you adjust buttons size to whatever current functionality requests.

There are no preemptive measures that could be taken. Planning a good game does not assume writing everything A to Z and questions of that kind will rise here and there. The process is iterative – it’s not a pictorial phrase, but a savior cross for Game Designer, a cross he has to bear.

3. Loose ends

The bigger the development team, the less chance that a Game Designer knows the project architecture good enough to speak with programmers on their language and write documentation not only for Game Designer’s intentions, but also for programmer’s capabilities. Even the most thorough design document will not be final – one moment programmer will come to designer and start asking questions.

By the way, take a note: if programmer reads documentation and does not come to clarify details after that he will code it “as is” and you will definitely get the feature done in the simplest way and most probably won’t be able to make any adjustments to it in future.

At the same time, a Game Designer has no point in doing an excessively detailed documentation. Some algorithms might become obsolete by the time that functionality finally gets the development opportunity. Some part of the documentation will be reworked upon at another team members’ request. Even the Game Designer himself might feel the urge to rewrite here and there. So the main point is – picture key algorithms first and the details – discussed and approved by every participant – will follow.

A reflection of this problem is the counter-offer. Seeing Game Designer’s efforts of creating not the algorithm by itself, but a definite user experience, the programmer can come up with his solution. But beware of Greeks bearing the gifts! Think it over; estimate its value for the Flow; get in your player’s shoes and make sure this solution does not break the balance and holds no barrier to future development. Part of this problem is that the programmer already threw the ball to Game Designer forcing him to make decision as soon as possible.

You can’t really foresee all these obstacles, both small and big. On one hand, you won’t be able to write the documentation to a dot (the process is iterative!), but on the other hand – you will never solve a question that crosses out the whole documentation in several minutes. Just be ready to compromise. Always.

4. Late for release

The clingiest nightmare of Game Designer is the urge to update and upgrade everything, including those that already work perfectly. From the very start, we are killing bores and perfectionists. In spite of endless hours spent on documentations, very important enlightenments (no kidding) strike us in the last moment. You can find whatever scientific explanation there is to explain why it comes from the shadow of your mind so untimely, but it doesn’t help – you’ve got to do something with it, and do it NOW.

A compromise here is to improve something that you can without distracting the programmers and artists. Alas, the less tools a Game Designer has, the less probability of completion this mission has. Besides, the great thought usually takes more than changing variables in balancing a formula or adding new entities to the database.

The development paradox is that a Game Designer can set a task of any complexity and longevity and project manager will add it to the schedule, but even if you allow for a change or two and come up with them later, you will hear many bad words and something like “you had to plan it ahead”. Well, it depends upon the team, of course, but be ready to inhibit your spontaneous desires at any time.

5. You are the only savior

Sometimes it happens otherwise: for financial, humanitarian or legal reasons you have to remake this feature right here, right now. No time to explain, get to your computer and think on how to convert platforming action with ponies to air simulator with the Great War planes. Deadline is yesterday. And consider yourself lucky if you’ll be able to retain winged pony to model physics of flight.

Jokes aside. Feature reworking starts with archiving of the original documentation without trying to reread or save a thing from it. It sounds harsh, but it really helps Game Designer to school his temper and become critical quotient to his work. This job is just about writing texts, filling table cells and drawing sketches. Also, we put our souls in it.

That is why reworking or cutting features should be considered a work from scratch. It helps not to think about saving favorite or hard-earned features that took some serious time to work on in the past. This is a philosophy of the same level that various couches and advisors use – “consider denials, failures and errors as new opportunities”. Do not fear – open a blank sheet and start working.(source:gamasutra)