作者：Emanuel Montero

好吧，我知道软件工程是很无趣的。而游戏开发却是令人兴奋的。为什么游戏开发需要看软件工程，总有一些充分的理由。

游戏开发在技术上日益复杂。无论SDK和游戏引擎将变得多么强大，无论一个项目能动员多少人资源，游戏开发的进度仍然很慢。游戏开发的成本一直很高。为了做出更好的游戏，我们必须改进软件开发过程。

在软件工程中，一个标准的软件生命周期包括提出需求、设计、执行、验证和维护。在游戏开发周期中，构想（提出需求）和设计是由游戏设计师负责的。程序员和美工按照具体的游戏设计说明来执行。程序员手动将游戏设计说明转译成源代码，而源代码将在目设备（如PC、游戏机和手机等）上编辑和执行。美工制作游戏所需的美术资源。游戏可执行后就要进行验证测试。问题就是在这个阶段中发现的。游戏设计并不更改高层次的说明部分。相反地，只更改低层次的执行源代码部分。在软件工程中，这种错误一般被称作“程序员的捷径”。维护程度不高不仅使设计说明完全废弃失效，而且使维护本身变成一项更容易出错、成本更高的任务。这时，我们就走上了一条危险的道路，迷失了唯一的地图。我们可能会因此毁掉整个软件。

programmer(from drimmit.com)

程序员的揵径可能会产生其他游戏开发说明上的问题。我们都知道迭代游戏设计可以产生更好的游戏：通过增加游戏玩法改良的次数来找到乐趣要素。但我们怎么可能迭代越来越复杂的源代码？毕竟它已经一团糟了。我们必须在设计层次上调整游戏玩法，然后再将游戏设计说明转译成源代码。但我们不能再那么做。将游戏设计概念手动地转译成游戏执行概念是非常耗成本的。程序员必须腾时间再做一次，我肯定他们不会乐意的。

如果有一种游戏设计编辑器能自动地将游戏设计高级概念转译成代码，就像源代码编辑器自动地将源代码转译成二进制，那该多好啊！我们不能像忘记二记制一样忘记源代码。但在此之前，我们需要一种用于游戏设计的准确说明语言。

我们如何将游戏说明做得准确？

一般的解决办法是，写成自然语言。当然，我们可以将游戏描述在纸上。但自然语言是很模糊的，不适合将交互系统准确地表达出来。所以用自然语言描述游戏设计将会很糟糕。

在软件工程中，有一种叫作指定域语言（DSL）的东西。DSL是一种适用于描述准确域任务的语言。所以我们可以将DSL用于游戏开发。更准确地说，我们必须将DSL用于游戏开发。

我不打算说得太详细，但我们将DSL用于游戏设计时将遇到两个大问题：

第一个问题是电子游戏设计的抽象度。有些人不在具体的技术执行范围内就无法想象电子游戏。我更倾向于将电子游戏当作一种高层次的技术抽象，独立于执行和目标设备。为了不谈Atari游戏机，我们必须借助高级DSL来谈论《吃豆人》这款游戏。在软件工程中这叫作平台独立模式（PIM）。不要担心设备的具体细节，我们将在更低的抽象度上用平台指定模式（PSM）来处理。所以我们可以将《吃豆人》指定为高级PIM，将其转译为适用于许多目标设备的PSM。

第二个问题与游戏类型有关。有些人偏好类型指定的DSL，因为它的游戏设计概念表达更具体，可以轻易地将所有类型常表现出来。例如，一个RPG DSL应该提供的概念包括龙验值、命值、武器、魔法等。当类型容量太大，还有存在亚类型或类型常规随着类型演变而变化时，问题就产生了。这时的DSL就变得不充分、不实用了。这就是我不喜欢类型指定DSL的原因。类型独立的DSL可以泛化这些游戏设计概念，以适用于所有电子游戏。

但什么是技术独立和类型独立的游戏设计概念？

根据Crawford提出的交互循环，那正是我最初的建议。我们可以从不同的方面或兴趣点来看待游戏。游戏玩法、图形用户界面（GUI）和控制是所有游戏都应该具备的三大方面。

在探讨游戏玩法时，我们可以规定有多少名游戏与游戏产生互动。我们还可以将存在于虚拟游戏系统的游戏实体归类。游戏实体可以分成由玩家操作的对象（即玩家角色）或由游戏AI控制的非玩家角色（即NPC），还有一类不表现任何智力行为的对角叫作消极游戏实体。这些概念准确地规定了游戏玩法规则。以后有时间我将另外讨论游戏规则定义这个主题。

先说GUI。游戏是由画面组成的。不要将画面看作等级或阶段，而是图形信息布局。各个画面都代表了不同的游戏实体或游戏信息（展示实体，如图象、进度条、数字和文本）。所有画面都可以是静止的，或呈水平滚动、垂直滚动或双向滚动。

再说控制。玩家使用控制器如键盘、鼠标、控制杆或手柄来操作。各种控制器都由不同的控制元素组成，如按键、触发器或手柄，它们分别向游戏系统发送0、1和2。更准确地说，玩家与控制元素的互动是为了执行玩家角色的活动。控制元素互动可能是按下或松开一个按键、将触发器设为高于或低于某个阀值或将手柄转向某个方向。

那就是用于游戏设计的高级类型独立的DSL。我知道这显而易见，但非常实用。我们可能用这三个简单的方面指定游戏设计。当然我们还可以增加其他方面：音频、剧情、AI或关卡设计。以上所说的只是作为一个出发点。

《吃豆人》是一款单人游戏。游戏中有一名玩家角色（吃豆人）和许多NPC（鬼）。还有一些消极游戏实体，如大理石和能量球。《吃豆人》的GUI有单个静态画面，所有游戏实体都用图像展示在上面。另外，玩家角色的得分是由数字表示的，而图标进度条则表示玩家角色的命值。玩家使用操作杆或键盘上的四个键移动吃豆人。

DSL的第一个优势是准确。因为不存在含糊不清的描述，所以所有人都能理解这种说明。甚至编辑器也能理解。

另一个优势是，DSL容易制成图表。各个实体概念可以表现为图象，使整个游戏设计说明相当直观和容易理解。这样我们就有了一份表现准确清析的说明。

好吧，我的DSL很不错。但是，实用吗？游戏设计师真的可以用这种DSL来改进游戏设计吗？可能不是所有的游戏设计都行。但我肯定它适用于某些游戏设计：比较简单的那种。它仍然是一种理论工具。很适合用来说明《吃豆人》和《防御者》这类简单的老游戏。但是，还是那句话，我所说的只是作为出发点。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Software Engineering Is Boring

by Emanuel Montero

Yeah, I know software engineering is boring. On the other hand, game development is exciting. But there’re some good reasons why game development needs to look a bit at software engineering.

Game development is growing every day even more technologically complex. No matter how good SDKs and middleware (i.e., game engines) may become. No matter how many people we put into a single project. Game development productivity is very low. Games are long to develop and cost a lot of money. We need to improve our software development process in order to focus on our unique characteristic: building better games.

In software engineering, a typical software life cycle includes requirements, design, implementation, verification and maintenance. In the game development life cycle, ideation (requirements) and design are performed by game designers. With a concrete game design specification, programmers and artists step in for implementation. Programmers manually translate the game design specification into source code that can be compiled and executed in the target technology (i.e. PC, console, mobile, etc). Artists create the art assets used by the game. Once the game is implemented, it’s playtested for verification. And here comes the BIG mistake. Game design refinements are not updated in the high level game design specification. Instead, they’re updated directly in the low level implementation source code. In software engineering, this mistake is commonly known as the programmer’s shortcut. A low level maintenance not only makes the design documentation completely obsolete and useless. It makes maintenance an extremely error-prone and expensive task. We are lost in a dangerous journey and we’ve lost our only map. Chances are we won’t make it alive.

And there are some other game development specific problems derived from the programmer’s shortcut. We all know that iterative game design means better games: finding the fun factor through incremental gameplay refinements. But how can we iterate over an increasingly complex source code? It’s a growing mess. We need to make gameplay readjustments at design level and then, re-translate the game design specification into code. But we can’t do that again. The manual transformation from game design concepts to game implementation concepts is very expensive. It took the programmers some precious time to do it once, and I’m sure they’re not willing to do it again.

Wouldn’t be great to have a game design compiler that automatically translates game design high level concepts into code, just like a source code compiler automatically translates source code into binaries? We can just forget about source code as much as we have forgotten about binaries. But before that, we need a precise specification language for game design.

How can we precisely specify games?

The traditional solution is to use written natural language. Of course, we can fill pages describing how our game will be. But natural language is vague and imprecise. And specially describing interactive systems, it grows short of expressiveness. So it’s a very bad specification language for game design.

In software engineering, there’s a thing called Domain-Specific Languages (DSL). ADSL is a language designed to be useful for a specific domain task. So we need a DSL for game development. More accurately, we need a DSL for game design.

I’m not going into details, but there’re two major issues when we’re dealing with a DSL for game design:

The first issue is about videogame design abstraction level. Some people can’t think of a videogame outside a concrete technology implementation. I prefer to think about a videogames at a high level of technological abstraction, with independence of their implementation and target technology details. So we need a high level DSL for game design in order to talk about Pac-Man without going into Atari memory slots. In software engineering this is called a Platform-Independent Model (PIM). Don’t worry about technology specific details, we will address them with a Platform-Specific Model (PSM), at a lower level of abstraction. So we can specify Pac-Man as a high level PIM and translate it into many PSMs for many target technologies.

The second issue is about game genres. Some people prefer a genre-specific DSL that expresses game design concepts in such a concrete way that all genre conventions are easily represented. For instance,a RPG DSL should provide concepts such as experience points, health, weapons, spells, etc. The problem arises when the genre is so vast that different sub-genres coexist or when the genre is evolving and genre conventions change. The DSL becomes incomplete or obsolete. That’s why I don’t like genre-specific DSLs. A genre-independent DSL will provide those game design concepts that are generic to all videogames.

But what are these technology-independent and genre-independent game design concepts, anyway?

That’s my initial proposal, based on Crawford’s interactivity cycle. Games can be seen from multiple perspectives or views of interest. Gameplay, Graphical User Interface (GUI) and control are the three main perspectives that all games should have.

Talking about gameplay we can specify how many players interact with the game. We can also specify different game entities that exist inside the fictional game system. A game entity can be controlled by a player (being a player character) or by the AI of the game (being a non-playercharacter). There’re also passive game entities which show no intelligent behavior. Gameplay rules are precisely defined using these concepts. I’ll talk about game rule definition some other day. It’s a topic on its own.

Talking about GUI, a game is composed of screens. Don’t think on screens as levels or stages but as graphical information layouts. Each screen represents different game entities or game information using display primitives such as images, progress bars, numbers and text. All screens can be static or have horizontal scroll, vertical scroll or bidirectional scroll.

Talking about control, each player uses a controller such as a keyboard, mouse, joystick or gamepad. Each controller is formed by different control elements such as buttons, triggers or joysticks that respectively send 0-dimesional, 1-dimensional and 2-dimensional information to the game system. More accurately, each player interacts with a control element in order to perform a player character’s action. Control element interactions may be pushing or releasing a button, holding a trigger above or under acertain threshold or moving a joystick in a certain direction.

And that’s a high-level genre-independent DSL for game design. I know it’s fairly obvious, but it works pretty well. We can specifyany game using these three simple perspectives. Of course there are other perspectives we can add: audio, story, AI or level design. But that’s just a starting point.

Pac-Man is a game played by 1 player. It features a single player character (Pac-Man) and many NPCs (the ghosts). There are some passive game entities such as the marbles and the power pills. Pac-man GUI has a single static screen where all game entities are displayed by images. Additionally, the player character score is displayed in numbers and the player character lives are displayed with an icon progress bar. The player uses a joystick or a keyboard with 4 buttons to move Pac-Man.

The first advantage of DSLs is that they’re precise. There’s no ambiguity, so anyone can understand what the specification means. Even a compiler can understand what it means.

Another advantage is that DSLs are easily diagrammed. Each primitive concept has a visual representation, making the whole game design specification pretty intuitive and easy to understand. So we have a precise specification with a clear and concise representation.

OK. My DSL is cool. But, is it useful? Can game designers really use this DSL in order to express their game designs? Probably not ALL their game designs. But I’m sure it’s useful form SOME game designs: the simpler ones. It’s still an academic tool. It works well on Pac-Man and Defender and lots of simple old games. But again, that’s only a starting point. （source：gamasutra）