好吧，我知道软件工程是很无趣的。而游戏开发却是令人兴奋的。为什么游戏开发需要看软件工程，总有一些充分的理由。
游戏开发在技术上日益复杂。无论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来改进游戏设计吗？可能不是所有的游戏设计都行。但我肯定它适用于某些游戏设计：比较简单的那种。它仍然是一种理论工具。很适合用来说明《吃豆人》和《防御者》这类简单的老游戏。但是，还是那句话，我所说的只是作为出发点。
via：游戏邦/gamerboom.com
更多阅读：
