作者：Pete Garcin

“有趣”可能是游戏设计演讲中使用次数最多的词。这也是个不明确的主观术语，并没有真正告诉我们某些对游戏体验有意义的东西。

这里我不是想要阐述“有趣”这个词的具体含义，而是想讨论这些不明确的术语如何妨碍我们有效地交流游戏愿景以及在团队中构建对游戏的共同愿景。

诸如“有趣”或“美妙”之类的一般词汇并没有向读者传递有意义的信息，也没有给那些文件内容的执行者指明具体的方向和细节。

在游戏开发中，构成共同愿景很困难，每个模棱两可的词都可能被误解，让人们对方向感到不甚确定。

fun(from thewordthoughtsblog.blogspot.com)

泛词

使用“有趣”这种泛词带来的最大的风险是，给人们对措辞的理解留下了过多的空间。“有趣”有着很广泛的概念，即便是个人，生活中可以归结为“有趣”的经历也是各种各样的。

假设你在谈论的是游戏的控制方式，你需要这种控制比较“有趣”。你究竟要表达的是什么意思？要求呈现出怎样的趣味性？有趣的控制方式是否能为玩家所接受？是否容易学会？是否直观？或者此类控制方式具有挑战性、需要玩家具有一定熟练度？

对不同的玩家和不同的背景而言，以上描述都可以被统称为“有趣”的控制方式。但是如果不使用更具描述性的术语，你根本无法理解对控制方式的具体愿景。所以，你最后获得的东西跟你想要得到的控制方式可能天差地别。

设计文件需要的是具体化，以精确的细节来陈述对控制方式的愿景，而不是使用这些泛词。接下来我们就会看那到，精确的细节并不意味这冗长的内容，而是些更具概括性且更有意义的词语。

“有趣”的判定人

对于泛词而言，主观化又是一大弊病。假设你获得的游戏控制方法可能与你所期待的差不多，但是或许还并不完全符合。

如果开始时你使用的是像“有趣”之类的主观词语，那么就很难将其作为评价度量。

使用精确的术语来描述功能和需求，可以将主观呈现降到最少。

精确

现在，有许多围绕创造性开发的设计和交流并不具有精确性。它们游曳于核心问题周围，但是却无法有效地传达概念。

这并非因为所交流的游戏愿景过于模糊而无法将其表达为具体的词语，而是训练不精，没有认识到编撰和交流通常都是个分解的过程：将事物分解到最为精细的部分，而不是添加更多内容。

当人们被要求澄清某件事情的时候，最初的直觉便是编写更多内容对想法进行“扩展”。但是通常正确的做法是将其削减细化，将事物分解更某些更为简明的东西。

当你在编撰功能、设计以及技术要点等相关文件时，清晰、精确和简洁是帮助你成为更高效的交流者的强大工具，可以帮助分享愿景（游戏邦注：即有效地将你脑中的愿景传达给其他人），帮助减少期望和结果间的分歧。

文件需要独自发挥其作用，当有人阅读文件而作者恰好不在现场，清晰高效的文件表述就会在此时凸显其重要性。

如果我们摒弃“有趣”之类的主观泛词，花些经历构思更加具体的短语，我们就更能够让人们理解我们试图表达的想法。（本文为游戏邦/gamerboom.com编译，如需转载请联系：游戏邦）

Opinion: Is ‘Fun’ Really What We Mean?

Pete Garcin

Fun is probably one of the most (over) used words in game design discourse. It’s also a broad, non-specific, subjective term that actually doesn’t actually tell us anything meaningful about a game experience.

I’m not here to pick on “fun” specifically, but rather to talk about how non-specific language, and overly broad terms actually prevent us from effectively communicating design visions, and from building a shared vision of a game on a team.

Generic words like “fun” or “nice” offer no meaningful information to the reader, and no concrete direction or detail for those who need to act on the contents of a document.

Developing a shared vision for a game is difficult – and every ambiguous word is an opportunity for there to be misinterpretation and uncertainty about direction.

Broad is Bad

One of the biggest dangers in using broad terms like “fun” is that they leave far too much room for interpretation. “Fun” is a pretty wide-ranging concept, and even for a single person there are a wide range of experiences that might be classified as fun.
Let’s say you’re talking about the controls for a game and you describe them as needing to be “fun”. What is it you mean? What does fun represent? Are fun controls accessible? Easy to learn? Obvious? Or are they challenging? Require mastery? Have depth and subtlety?

To different players, and in different contexts, all of the above descriptors might be broadly described as “fun” controls – but without using more descriptive terms, you cannot get at the intended vision for the controls. And so what you get back might be wildly different than what you asked for.

Instead, design documentation calls for specificity – for the vision for the controls to be laid out in precise detail, rather than broad sweeping terms. As we’ll see shortly, precise detail does not mean exhaustive tomes of text, but instead, tightly honed, meaningful phrases.

Who Is The Judge Of “Fun”?

Subjectivity is the other major downfall of overly broad and imprecise language. Let’s say you managed to get controls that were more-or-less what you were after, but that something isn’t quite right.

If at the outset you used terms that were subjective, like “fun”, it is difficult to refer back to those and use them as an evaluation metric. You’re stuck with: “Well, what I actually meant was…” – which isn’t a very effective way to give feedback.

Using precise, non-ambiguous terms to describe features and requests helps minimize the amount of subjectivity present – and as a result, makes discussion about what things need to be, and whether they are at that point easier.

Be Precise

So much design and communication surrounding creative development is sprawling and unfocused. It dances around the core of what it is trying to communicate and fails to convey concepts effectively.

It’s not because the visions being communicated are so nebulous that they can’t be put into words – but more a failure of discipline, to recognize that writing and communication is often an act of reduction: of paring things back to their bare minimum, rather than adding more.

When asked to clarify something, the first instinct is often to write more to “expand” on a thought. Often the right thing to do is to reduce, and distill what is already there to something more concise. In audio, subtractive EQ is the process of removing certain frequencies to accentuate others: you gain clarity and focus by removing information from the signal.

When writing about features, design, or even technical specifications – clarity, precision, and brevity can be powerful tools to helping be more effective communicators, to help build a shared vision (by effectively communicating the vision inside your head to another person!) – and to help reduce ambiguity about expectations and outcomes.

Documentation needs to stand on its own – when someone refers back to it and its author is not around to clarify, having clear, effectively written documents become critical.

If we move away from using overly broad, subjective filler words like “fun”, and take the time to focus and craft our phrases to be precisely what we mean – we’ll actually go a long way towards actually being able to realize the visions that we’re trying to communicate. (Source: Gamasutra)