作者：Sergey Mohov

游戏设计通常被人们认为是游戏开发过程中一种基于想法驱动的领域，许多人通常易于陷入考虑纯创意的问题，而忽略其技术要求。虽然拥有想法很好也很有用，但要记住人人都有想法，想法本身并无价值，关键在于执行。编写概念文件或推销游戏理念看起来像是一项令人兴历的任务，但它却只是游戏设计师完成一个项目时诸多工作中的一小部分。

在此我不打算深入探讨更多关于想法、概念、团队头脑风暴和创新的更多细节，因为这是一个足以另起一文的广泛话题。我将讨论的是游戏设计的技术层面，不同情况下可运用的多种生产技巧，帮助设计师以更节省的精力和更高的准确性解决复杂的问题。真正的游戏设计始于团队（即使团队只有一名成员）在某个概念上达成一致之后，但我还是觉得我们没有触及制作技巧的层面。

如果你和我一样，经常搜索游戏设计秘方，意见和事后析误等内容，可能就会很熟悉Jesse Schell、Brenda Romero、Ian Schreiber以及Daniel Cook等人的著作。在此，我将与大家分享我过去几年搜集到的一些方法，并将其编撰为我所谓的抽象级别（Levels of Abstracton，简称LOA）这个统一方法。

简单地说，LOA就是一个允许游戏设计师最管用的方法运用其分析技能的框架。抽象对正确了解和平衡游戏系统来说至关重要，不同的情况对抽象程度的需求也不尽相同。游戏设计师选择LOA这种在任何情况下都最适用的方法，可以确保其工作效率。例如，有时候描述一个机制的最佳方法是绘制一个简单的草图，并与重要的团队人员交流，在某些情况下则可以是制作一个电子表格，一个记事备忘录，一个流程图甚至是编程代码都有可能成为最佳交流媒介。

适用于任何情况的LOA会根据团队、预算、制作时间表、开发阶段、游戏类型及其他多种因素的不同而有所不同。每个LOA都是一个让游戏设计师更好地形式化和传达游戏系统的工具，因此要对它们加以更多控制。在此我将讨论我在制作不同独立及合作项目时遇到的5种LOA。这里有必要指出同个项目甚至是同个机制也可结合使用多个LOA。欢迎各位提出自己的见解。

第1级：经验主义

这是一个不言自明的抽象等级。它很可能是说明一个游戏机制时的最普遍情况，通常用于游戏设计文件、网站和团队成员交流间的介绍环节。例如：

角色如何没有接触主人，就无法做任何事情，甚至是寸步难行。当一个敌人接近角色时，玩家可以摁下动作按钮，这会让角色接触敌人，并让玩家获得敌人所具有的新威力。

此类说明一般会伴随简单的插图，说明游戏机制的运行原理，以令描述更清晰准确。这些图片通常不甚清晰，看起来像是一些简单的游戏场景外加一些额外图像以便进行说明。

Empirical(from gamasutra)

LOA1并不包含任何可运用于需要编写下来的情况的公式或数值，通常是因为游戏设计师想记住一些事情以便过后回顾，或者在没有技术信息需求时以简单文字解释一个机制。

如果LOA1是作为解释游戏机制的唯一方式，那就要由程序员来定义该机制的实际运行方式，找到正确的公式和游戏设计师之后将回顾的虚拟数值。这种方式通常需要迭代，但对于身兼数职，可以控制游戏多个层面的小型团队来说，这却不失为一个好方法。但在中大型团队中，这却可能成为一个问题，因为它需要大量的迭代时间。

第2级：原理图

这个抽象级别更进一步，以图表或表格形式表现游戏机制或玩法元素。因此，抽象级别更高，玩法描述也更正式。通常可以看到第二种LOA与第一种合并使用，作为形式化系统的一种方法。有些机制和游戏情境也更适合使用第二种LOA来表现，根本就不需要LOA1。

Schematic(from gamasutra)

这是一个无需制作任何3D模型，在局部（任务）或全面（游戏世界）水平上表现关卡设计的普通方法。它也常用于无需更改基础公式，使用数值平衡技能和动作的情况。

如果你想展示或者对比（用经验主义方法）需要很长时间才能解释或编写清楚的大型数据阵列，使用LOA2就不失为一个好方法。与LOA1一样，LOA2并不需要使用设计师制作的公式直接控制游戏机制。但是，你却可以使用现成的公式来表现数据和运算。

第3级：数学

它运用数值的方法类似于LOA2，但除了游戏设计师创造自己的公式来表现游戏机制之外，制作抽象级别甚至还高于前者，这可以让设计师获得更高级的控制和更好的视野。

DifficultyOfTransition = NumberOfTagsPerCondition / (N * NumberOfConditionsPerTransition * NumberOfWordsPerTag);

这种抽象等级要求在执行之前进行大量测试，这可能是在纸上，或者使用允许修改公式和不同数值的游戏机制数字原型。这一方法的优势在于游戏设计师能够通过以这种方法描述机制来达到自己所需的结果，而劣势就在于，它在程序员开始编写机制之前，可能需要多花点时间测试原型。

总体来说，当数学问题很关键时，LOA3方法就很理想：各种类型的逻辑谜题，角色扮演元素，以及那些无需大规模调整玩法，可以在纸上创造原型的游戏。这对于跳跃、移动和一切与重力、加速和其他传统物理变量有关的事物来说极具杀伤力。

第4级：算法

这个LOA4要考虑到那些在它之前的方法。游戏设计师要以流程图、伪代码或者以带有详细指示的动作序列形式写下游戏机制。

Algorithmic(from gamasutra)

由于数据表现的属性，我们很难使用这个LOA来平衡事物，但它却是检查游戏机制是否可行的好方法，并且可以确保事物以正确顺序运行。在复杂游戏系统中若不及早进行检查，这后就可能酿成大错，会让开发者花费更多时间进行修复。

LOA4可以指出特定值和公式——但这一切完全取决于设计师。设计师应该考虑使用LOA4的理由。如果其目标是在纸上测试整个在执行之后的运行方式，那么最好使用真正的公式和变量。这样，在这种情况下，自动有限状态机工具（例如Unity的Playmaker）就可以派上用场了。另一方面，如果LOA4是用于确定特定机制背后的逻辑是否可行，以及减轻错误操作顺序的风险，那就可以在无需深入每个状态细节的情况下，使用一个简单的流程图或一个算法顺序。

以我的经验来看，小型和大型项目都可以使用LOA4，但设计师应该谨慎使用这一方法，因为编写复杂系统的一个算法通常需要大量时间。

第5级：编程代码

绕过LOA4直接编写一个机制（或者部分机制）代码是个好主意，因为生产复杂系统的正式算法结构可能需要大量时间，未必需要由最终结果的实用性来验证。在有问题的算法包含大量小或者很容易用代码来表示的简单操作，这可占用较少空间，投入的精力也不大，也不需要太多调试。下图显示有些时间一行代码可以代替大量有限状态机操作。

programming code(from gamasutra)

在编写非常特殊或非常孤立的机制时，这是一个很好的方法，除非游戏设计师要自己编写游戏代码，此时以代码编写一切内容就是唯一的选择了。否则，从机制形式化以及对执行成员解释其原理的角度来看，这都是一个值得考虑的方法。也就是说，如果你认为直接编写机制是最简便渠道，那你就应该考虑这一方法。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Levels of Abstraction in Game Design

by Sergey Mohov

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.

The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

This article was originally posted in my personal blog.

Game design is often perceived as an idea-driven discipline in game development, and many people tend to fall into the trap of thinking about it in terms of pure creativity, neglecting the technical aspect. While having ideas is nice and useful, it is important to remember that everyone has them, and that an idea per se does not have any value. What counts is the implementation, and while writing a concept document or pitching a game may seem like an exciting task, it constitutes a relatively small fraction of the actual work a game designer has to do on any given project.

I am not going to go into more detail about ideas, concepts, team brainstorming and creativity, as this is a broad subject that deserves a separate post. What I would like to talk about here is the technical aspect of game design, various production techniques that can be applied in different situations and help the designer solve complex problems with less effort and more precision. The real game design work begins after the team (even if it is a team of one) has agreed on the concept, and yet I feel like we are barely scratching the surface of production techniques.

If you are anything like me, you are in constant search for game design cookbooks, opinion pieces and postmortems, and are probably familiar with the brilliant work of Jesse Schell, Brenda Romero (Brathwaite), Ian Schreiber, Daniel Cook and others. I am not going to try and rethink game design as such in a short blog article. In fact, everything that I am going to say is compatible with and relies upon these groundbreaking works from before. What I would like to do here is share some of the thoughts on the subject of methodology that I accumulated over the last few years, compiling them in a unified theory that I like to call Levels of Abstraction (LOA).

Perhaps the best analogy for LOA is a YouTube video that me and my teammates used to watch daily while working on Paradis Perdus. It’s a half-mocking that-part-of-the-internet kind of thing which demonstrates the “cuil theory” through text pieces that become more and more abstract as the number of “cuils” (or levels of abstraction from reality) increases.

In simple terms, LOA is a framework that allows the game designer to apply their analytical skills in the most useful way possible. Abstraction is important to understand and balance the game system correctly, and different situations demand different levels of it. The game designer chooses the LOA which is most suitable for them at any given moment, thus ensuring the effectiveness of their work. For example, sometimes the best way to describe a mechanic is drawing a simple sketch and talking to the concerned team members, while in other cases a spreadsheet, a text memo, a flowchart or even programming code will be the best medium.

Suitable LOA for any given situation can vary based on the team, budget, production timeline, development phase, game type and dozens of other factors. Each LOA is a tool that lets the game designer formalize and communicate a game system better, thus giving them more control over it. All and all, I am going to discuss five LOA that I have most often encountered myself while working on various solo and collaborative projects. It is also important to note that multiple LOA can (and should) be combined within the same project and often even the same mechanic.

Discussion is highly encouraged, and, if you have something to contribute to the list or have something to say about one of the LOA, don’t hesitate to drop me a line or leave a comment. This post is reference material, so I am fully prepared to update and improve it if need be.

Level 1: Empirical

This is the level of abstraction that manifests itself as a an explanation in plain words. It is probably the most common way of explaining a game mechanic, often used in introductory sections of game design documents, on websites and in communication between team members.

The character cannot do anything if she does not infect a host, even move. When one of the enemies is close enough to the character, the player can press the action button, which will make the character infect the enemy and give the player some new powers based on the things the enemy can do.

Often this kind of explanation is accompanied by a simple illustration that shows how the game mechanic works, making the description clearer. These images are rarely very detailed and usually look like simple mock-ups of the game scene with some additional graphics for explanation.

A mockup for Ricky, one of the first games I worked on.

LOA1 does not include any formulas or values and can be applied in situations where something has to be written down, usually because the game designer wants to remember something and come back to it later or to explain a mechanic in simple terms when no technical information is needed.

If LOA1 is used as the only way of explaining a game mechanic, it is the programmers who define how the mechanic actually works, finding the correct formulas and dummy values that the game designer comes back to later. This method of work often demands reiteration, but can be a good idea in case of small teams (including teams of one) with team members wearing different hats and having significant control over multiple aspects of the game. In a medium to big team, however, this may become a problem, due to the time it takes to reiterate.

Level 2: Schematic

This level of abstraction goes further and represents a game mechanic or a gameplay element in form of a graph or table. Thus, the level of abstraction is higher, and the gameplay is described more formally. It is common to see the second LOA in combination with the first one as a way of formalizing the system. Some mechanics and game situations are also better represented using the second
LOA and don’t need LOA1 at all.

Table with AI mental states, player inputs and AI outputs. Unannounced project.

This is a common way of representing level design on a local (mission) or global (world) level without doing any 3D modeling. It is also often used for balancing skills and actions using numeric values without changing the underlying formula.

It is generally a good idea to use LOA2 if you want to show and/or compare large arrays of data that would take too long to explain or write down empirically. Like LOA1, LOA2 does not allow for direct control of game mechanics using designer-made formulas. However, it may use the existing formulas for data representation and calculations.

Level 3: Maths

This is similar to LOA2 in that numeric values are being used, but apart from that the designer creates their own formulas to represent game mechanics, making the level of abstraction even higher than before, which gives them a higher level of control and a better perspective.

DifficultyOfTransition = NumberOfTagsPerCondition / (N * NumberOfConditionsPerTransition * NumberOfWordsPerTag);

This level of abstraction is something that demands extensive testing before being implemented: either on paper or using a digital prototype of the mechanic that allows to modify the formula and different variables on the fly. The advantage of this method is that the game designer can achieve exactly the result they want by describing the mechanic in this way, allowing for more fine tuning and precise balancing. The downside, however, is that it may take some time before the programmer will start actually coding the mechanic, since the prototype must be tested before the implementation of the mechanic begins.

In general, LOA3 is good when maths matters: all kinds of logic puzzles, role-playing elements, and in general games that can be easily prototyped on paper without significant changes in their gameplay. It is probably an overkill for things like jumping, movement and everything else involving velocities, accelerations and other conventional physics variables.

Level 4: Algorithmic

The fourth LOA takes into account the ones that come before it. The game designer formalizes the game mechanic writing it down in form of a flowchart, pseudocode or simply as a sequence of actions with precise instructions.

Part of an AI algorithm.

It is hard to use this LOA for balancing things because of the nature of data representation, however, it is good for checking if the logic of the game mechanic works and making sure that things happen in a correct order. If this is not checked early in a complex game system, things can go very wrong later, and it will cost much more to repair them when they do.

LOA4 can point to specific values and formulas or not—this is entirely up the the designer. One should take into account the reason for using LOA4. If the goal is to test the whole mechanic on paper exactly the way it is going to work once implemented, then it is generally a good idea to use the real formulas and variables. In this case, automated finite state machine tools such as Playmaker for Unity may help. On the other hand, if LOA4 is used to determine whether the logic behind a specific mechanic works and to mitigate the risk of a wrong order of actions, a simple flowchart or an algorithm sequence can be used without getting too deep into the specifics of each state.

In my experience, both small and big projects can benefit from LOA4, but the designer should use it with caution, because it generally takes a long time to formally write down an algorithm for a complex system.

Level 5: Programming Code

It is often a good idea to write a mechanic (or a part of a mechanic) down in code directly, bypassing LOA4, because producing formalized algorithm structures for complex systems may take a significant amount of time, not necessarily justified by the usefulness of the final result. This is usually the case when the algorithm in question includes a lot of of small and/or simple actions which could easily be represented in code, taking up less space and demanding less effort and debugging. The image below shows that sometimes one line of code can replace a whole bunch of finite state machine actions.

Sometimes one line of code can replace a whole bunch of finite state machine actions.

It is generally a good idea to write down either very specific or very isolated mechanics this way, unless the game designer codes the game on their own, in which case writing everything in code is the only option anyway. Otherwise, the utility of this approach should be considered in terms of the formalization of the mechanic and its explanation to people who are going to implement it, so programmers. That is to say that you should consider it if you think that it is the easiest way to write a mechanic down.（source：gamasutra）