作者：Shay Pierce

近期我撰写系列博文，主题是自己刚刚设计完成并提交至App Store的iOS益智游戏《Connectrode》。现在，我觉得应该从项目中解脱出来，通过编撰其他感兴趣的内容在博客中放松自己。先在此提醒大家注意，文章表达游戏设计和编程中抽象想法的言辞相当随意，我并未将这些想法以最容易理解的形式来阐述，此文的主要目的在于将脑中的想法转移到纸上。

在我的职业生涯中，主要担任各种形式的“游戏可玩性程序员”。其中大部分时间我都在自行设计和执行游戏，这两个方面我都很喜欢。亲自编写代码的游戏设计师并不多，做游戏设计工作的可玩性程序员同样也不是很多。我觉得身兼两职赋予了自己独特的视角，让我构想出新风格的游戏引擎，使游戏制作甚至可以脱离可玩性程序员，直接由设计师来落实想法。

game-design-pic(from mrcasas.blogspot.com)

首次萌生这种想法是在设计卡片游戏和桌游原型之时，我发觉这纯粹是种游戏设计而已。尽管与电子游戏相比，能够用于设计桌游的工具极为有限，但这种局限性让你在核心游戏设计方面眼界更宽。在那段时间里，我认为游戏在结构上只包含3个部分：

1、名词：游戏系统元素及其相关变量。示例：玩家，角色，NPC，道具；地图，世界，地点，瓦片，卡片，XP，HP。

2、动词：游戏中代理人（游戏邦注：玩家或玩家扮演的角色）能做出的动作。示例：攻击，跳跃，移动，贿赂，玩卡片，抛骰子。

3、规则：规定现存名词的性质并营造名词间的关系和互动，规定在何时及何种背景下能做出的动词。示例：在每回合开始时抽取一张卡片，当一个单位攻击另一个单位时，所造成的伤害等于攻击者的基本伤害值；当马里奥在空中时，重力产生的下落加速度为每毫秒1像素。

每款游戏都有此三种元素，但我认为标准结构游戏只含有这三个元素。事实上，我推测所有系统都可以分解成这三个元素，我即将提出的新“引擎”或许将成为开发任意形式游戏乃至任意形式软件的新方法。但在本文中，我将着重阐述自己最熟悉的领域——游戏。

如果这些是所有游戏的结构，那么合理的游戏引擎应该首先专注于将这三样东西模型化，使它们的创建和修改尽量简单易懂。有些游戏引擎似乎能实现上述目标，但看起来都未触及问题的核心。

说到底，我觉得根源在于当前编程范例都没有提供合适的语言来表达这些结构。对“名词”元素而言，此类评述可能并不恰当。顾名思义，面向对象编程擅于呈现各式对象（游戏邦注：即三元素中的“名词”）及其间可能存在的关系，将重复性代码或无用工作降到最少。但是在任何我所知晓的编程语言中，动词和规则都很难清晰地得到表达。尤其是规则（游戏邦注：作者认为规则是游戏设计中较为重要且时常改变的元素），我觉得很难通过现有编程或引擎范例来呈现。

假设我在开发平台游戏，想要添加“跳到敌人头上可以踩死它”这个规则，但随后还要添加例外规则“跳到豪猪头上会导致角色死亡”。在当前面向对象编程范例中，我可能通过以下两个步骤来表达此规则：1、为“Enemy”类添加“jumpedOnBy()”功能，body为“die()”；2、在“Porcupine”类中用杀死玩家的body来覆盖这个功能。事实上，我可能不会一成不变地采用这种方法，但上述构思已然很接近自己的做法。

我想说的是，使用面向对象编程的习惯导致自己本能地将此规则表达为名词的性质或行为。我觉得这是个不好的习惯，每个规则都应该以对象呈现。从概念上来说，规则实际上应该“控制”名词并可以进行修改。但是，当前典型的规则呈现方式完全无法做到这一点。这些规则反而是添加到代码的各个位置中。在可玩性代码中，很少看到某项规则精确地在代码中某处表现出来。换句话说，“游戏规则”和“代码群”间很少存在对应关系。

现在想想这个过程，我认为这种编码方法暗示范例需要有所改变，即名词无需有它们自己的行为。在游戏《大富翁》中，桌上的棋子自身没有任何行为，它的作用只是能够位于棋盘不同位置上。将棋子移动是动词（游戏邦注：“移动”动词由玩家执行），限制和定义移动的是规则（游戏邦注：规则约定玩家在执行“移动”动词前必须掷骰子，根据点数来移动棋子）。

如果我们相信代码结构与真正呈现出的概念对象结构的匹配能够使代码简洁且更具持续性，那么就应该改变可玩性代码的范例，使名词自身不具行为，让规则和动词成为一阶对象。而且，应该将此扩展为规则完全由数据驱动并完全由设计师使用引擎工具来定义。我心中理想的游戏引擎是：

1、可玩性设计师可以在游戏引擎中添加规则，利用简单易懂但功能健全的引擎来表达规则。这些规则也能定义名词和动词。

2、随后，设计师可以马上在这些准确定义游戏的规则下体验游戏。他们会发现规则在哪些地方无法营造出想得到的行为，随即进行修改然后再次运行游戏。

3、也就是说，在此工作流程中没有可玩性程序员。看起来就像是游戏设计师坐下来设计桌游，体验游戏并反复修改规则。不同之处在于，现在游戏可以自动执行所有规则，这使得设计师能够制作出复杂得多的游戏。所有电子游戏均是如此。

当然，以上看法是理想情况，现在我们应该怎么做呢？我举了“跳到豪猪头上”规则这个反例，也阐述了不能采用的呈现方法。或许有人会问，能否举例说明我们应该怎么做？

我觉得自己恐怕还做不到，此刻该想法依然仅存在于脑中，而且我认为提供不完整的答案帮不了任何人。但这是我已经想了很久的东西，也愿意投入更多时间来进行研究。搜索“规则基础编程”得出的结果让人倍受鼓舞，因为现在已有大量沿着这些路线发展的编程框架知识，但我对这些内容的探索还不够充分，无法断定它们是否真正能用于我在本文中提到的东西。

以抽象实体呈现规则是个难题，因为人类对“规则”并没有清晰的看法。我不知道是否存在某种可用来表达任何“规则”的语言，或许唯一能实现此等目标的就是人类语言。但也可能不像所说的那么难，我们只需坐下来思索如何以明确的形式来表达这种抽象想法而已。或许某些人已经在这个方向上有了重大突破，抑或已经以此为基础构建出完整的引擎，只是我不知道罢了。

我最大的希望是，此博文能够引发人们更多地思考和讨论这个话题，提出我们可以实现的想法。希望有人能够提供已经以此方式呈现可玩性代码的范例，或者至少在此方向上有所突破的内容！（本文为游戏邦/gamerboom.com编译，如需转载请联系：游戏邦）

Towards a Rule-Based Game Engine

Shay Pierce

I’ll be doing a series of blogs posts shortly about the iOS puzzle game I just designed (“Connectrode”) and submitted to the App Store this morning. For now I thought I would “detox” from that project, and ease myself back into blogging, by writing about something else that interests me. Warning, this is a fairly off-the-cuff attempt to express some very abstract ideas about both game design and programming – I haven’t necessarily polished these ideas into the most comprehensible form… I’m mostly just writing this to get the ideas out of my head and onto “paper.”

I’ve been a “Gameplay Programmer” in one form or another for most of my career. A lot of this has taken the form of my designing games myself, and then proceeding to implement them myself – a process which I love both sides of. Not very many game designers actually do the coding themselves; and not many gameplay programmers do a great deal of game design. I feel like it’s given me a unique perspective, and in particular it’s led me to conceive of a new type of game engine – one that would minimize the need for even having a gameplay programmer, and put the implementation directly into the hands of the designer.

The idea started to come to me as I worked on card game and board game design prototypes – this, I realized, was a very pure form of game design. Though “table game” design gives you a limited set of tools compared to those you have on electronic games, it can really open your eyes as to what the core of game design really is. I’ve believed for some time that, structurally, a game is comprised of only 3 things:

Nouns – Elements of your game system, and variables related to them. Example: Players, avatars, NPCs, items, a map, a world, locations, tiles, cards, XP, HP.

Verbs – The actions that agents (players or player stand-ins) in your game can enact; the “things you can do.” Example: Attack, jump, move, bribe, play card, roll dice.

Rules – Rules, which limit the nature of the existence of the nouns and create relationships and interactions between them; and which limit which verbs can be enacted when and in what context. Example: “draw a card at the start of every turn”; “when a unit attacks another unit, it does damage equal to the attacker’s base damage value”; “when Mario is not on the ground, gravity pulls him down at a rate of acceleration of 1 pixel per millisecond”.

Every game has these three elements, and I think that games (in terms of a formal structure) are solely comprised of these three elements. (In fact I theorize that all systems can be defined by these three elements, and that the “engine” I’m about to propose might be a new approach to developing not just any type of game, but any type of software. But for now I’m sticking with the domain I understand best: games).

Given that this is the structure of any game, shouldn’t a proper game engine be focused on, first and foremost, modeling these three things, and making the creation and modification of them as straightforward as possible? A few game engines seem to do this, but in very specific ways which don’t seem to get to the heart of the matter.

What this comes down to is that I feel that current programming paradigms do not provide an appropriate language for expressing these structures. This may not be true for the “nouns” element – Object-Oriented programming, as its name implies, is very good at representing different types of objects (“nouns”) and the relationships they may have between each other, with minimal duplicated code or wasted work. But both verbs and rules are hard to express clearly in any programming language I know. In particular I think that rules (which I see as the more important and often-changed element of game design) can often be difficult to represent in existing programming/engine paradigms.

Let’s say I’m developing a platformer and I want to add rules that say “when you jump on any enemy’s head, it dies”, but then add an exception that says “when you jump on a porcupine’s head, it survives and YOU die”. In current Object-Oriented programming paradigms, I’m probably going to express this by 1) adding a “jumpedOnBy()” function to the Enemy class with a body of “die();” … and 2) overriding that function on the Porcupine enemy class with a body that says to kill the player instead. (This is not exactly how I would actually implement this but it’s close enough for the point I’m making.)

The point is that the habits of Object-Oriented programming lead me to instinctively express this rule as properties or behaviors of the nouns. I think this habit is inappropriate: each rule should be represented as an object in its own right; and conceptually the rule should in fact be an element that “controls” the nouns and can modify them. But our current typical representation of rules doesn’t do this at all. Instead they find themselves poked and prodded into various places in code. It’s rare, in gameplay code, to find a rule that is even concisely expressed in exactly one place in code – in other words, it’s rare to find a 1-to-1 relationship between “a game rule” and “a chunk of code.”

As I think this through now, I think that perhaps the biggest, paradigm-shifting implication of coding this way would be that nouns do not have behavior of their own. In a game of Monopoly, the Thimble on the board has no behavior of its own; it just has the capacity to rest on different locations on the board. It is verbs that put the thimble into motion (a player initiates a “move” verb), and it is rules that restrict and define that motion (a rule states that the player performing a move verb must roll the dice and move the thimble that many game spaces in the forward direction).

If we believe that our code will be cleaner and more maintainable if it structure matches the structure of the conceptual objects that we’re actually representing, then we should move gameplay code to a paradigm in which Nouns have no behavior of their own; and push to make Rules and Verbs first-order objects. Furthermore, this should be extended to the point that Rules are entirely data-driven, and can be defined entirely by designers using engine tools. My ideal game engine looks like this:

The Gameplay Designer can add Rules into the game engine using a straightforward but robust engine for expressing those rules. (They also define Nouns, and have some capacity to define Verbs.)

They can then immediately play the game with these rules being applied by the game exactly as defined. They see where the rules fail to create the behavior that they want, and can easily modify those rules and run the game again.

That’s it. There is no Gameplay Programmer in this workflow. It’s kind of like the Game Designer is sitting down and defining a board game design, playing it and iterating on the rules… except that this game happens to automate all the enforcement of the rules, allowing them to make much more complex games. Because that’s all that video games are.

All right, this is a grand high-level vision of intentions, but how exactly do we go about it? I gave a counter-example with the “jumping on the porcupine head” rule and how we shouldn’t be representing that; but where’s my example of exactly how we should?

I’m afraid I haven’t gotten that far; I only have the glimmer of an idea at this point, and I feel like throwing out my half-baked answers wouldn’t help anyone. But, it’s something I’ve thought a lot about and would like to spend more time researching. Googling for “Rules-Based Programming” has been encouraging, as it turns out that there’s a substantial amount of existing knowledge for programming frameworks that work along these lines; but I haven’t yet explored them thoroughly enough to determine whether they truly apply what I’m trying to get at here.

The “hard problem” here is representing rules as abstract entities. The fact is that a “rule” is something that we as humans have a very loosely-defined idea of. I don’t know if there’s a single language that can be used to express any and all possible “rules”; perhaps the only language that can actually do that is human language itself. But perhaps it’s not as hard as all that, and we need to simply sit down and take this abstract ideal and determine what concrete form it could take. Or perhaps someone out there has already made significant strides in this direction, or an entire engine based around this, of which I’m unaware.

My main hope is that this blog will spark more thought and discussion on the topic; lay out a (very vague and high-level) ideal we can work towards; and hopefully that someone will even point out to me a paradigm that already represents gameplay code in this way, or at least is a step in this direction! (Source: Gamasutra)