苹果手游开发工具:GameplayKit使用指南

【Gamelook专稿，转载请注明出处】

Gamelook报道/在6月9日凌晨举行的WWDC 2015大会上，苹果宣布iOS 9的同时推出了两个非常重要的工具，分别是GameplayKit以及ReplayKit，从该公司的介绍中来看，这两个工具对于iOS手游开发者以及欧美游戏视频相关领域可能会产生比较大的影响。

简单的说，GameplayKit就是一个帮助新手开发者们在OS X和iOS平台创作游戏的基础工具和技术框架，可提供游戏资源、模块、玩法设计以及系统规则方面的内容，并不包括视觉渲染等功能。因此，可能对于有些资深开发者们来说，支持多平台发布、功能更为复杂的游戏研发框架或许会更适合。

而ReplayKit的细节透露较少，在苹果的官网，我们可以看到，玩家们可以通过该功能在游戏中录制、编辑并在线分享游戏，并没有进一步的说明。

以下请看Gamelook整理的苹果官方《GameplayKit 参考和编程指南》（由于篇幅限制，这里仅翻译概念部分，想了解实例请移步苹果官网，还可下载样本游戏代码）：

第一部分：框架参照

提示：这是一个正在研发的API或技术的概要文件，苹果公司提供这些信息主要是为了帮助你通过苹果产品使用这些技术或者编程界面而做好计划，该信息有可能会在未来发生改变，本文当中提到的软件应该以最终发布的操作系统测试和最终文档为准，未来有可能会提供新版本的文档信息。

GameplayKit是一个面向对象的框架（Object-oriented framework），为在OS X和iOS平台打造游戏提供基础工具与技术。GameplayKit包括为设计游戏功能而提供的工具、可重复使用的架构，还包括为创造和提高玩法功能而研发的技术，比如角色移动和敌人的行为设计等等。

初识GameplayKit

GameplayKit框架包含了一些独立的分支系统，覆盖了游戏设计和研发的多个领域。

随机化（Randomization）：使用GKRandom协议、GKRandomSource以及GKRandomDistribution class，而且还有更多独特的subclasses来增加游戏玩法的不确定性，同时不需要以增加BUG调试量为代价。

状态机（State Machines）：使用GKStateMachine和GKState class打造模块化的玩法系统。

Minmax Strategist：GKMinmaxStrategist class为回合制游戏中的敌人提供AI设计，想要使用一个Strategist的话，你需要用GKGameModel协议以及相关协议来描述游戏玩法。

寻路系统（pathfinding）：使用GKGraph和GKGraphNode class以及它们的subclasses来为你的游戏世界导航建模，并且为游戏对象找到可以使用的路线。

代理、目标和行为：GKAgent class提供模拟功能你可以通过GkGoal对象为游戏单位定制化移动行为规则，每一个class都为一个代理自动跟随设计了高等目标。

规则系统：使用GKRuleSystem和GKRule class打造复杂的游戏逻辑，包括模糊推理（fuzzy reasoning）以及应急行为。

第二部分：GameplayKit编程指南

GameplayKit是为iOS和OS X平台做游戏而研发的一系列基础工具和技术，与更高级的SpriteKit以及SceneKit游戏引擎不同的是，GameplayKit并不包含动画和视觉渲染等内容。GameplayKit主要是帮助开发者研发游戏的玩法并设计模块化组件、用最少的努力做出可扩展的游戏架构。

GameplayKit功能

打造、改善和维护一个复杂的游戏需要非常好的游戏设计。GameplayKit提供一个实体组件架构，帮助你设计可以重复使用的玩法代码，并为解决复杂的面向过程的代码提供一个状态机系统（State Machine System）。GameplayKit还包含了一些随机化的工具，可以为很多种玩法提供基本的资源。

创作一款优秀的游戏还需要使用复杂的算法（algorithms）来解决很多常见的游戏玩法问题。通过GameplayKit，你不再需要写自己的算法，而是可以直接使用GameplayKit提供的资源，这样开发者就有更多的时间专注于把玩法做到更加独特。

比如，你可以使用Minmax Strategist功能为回合制游戏打造AI系统、通过寻路功能为游戏角色设计导航路线，为高等级的游戏角色设置自动行走或者使用与代码分离的规则系统并实现模糊逻辑推理（Fuzzy Logic Reasoning）。

由于GameplayKit在iOS和OS X系统中是独立于高级游戏引擎而存在的，因此你可以拿它与任何可以做一个完整游戏的技术进行整合，比如做2D游戏用的SpriteKit、做3D游戏用的SceneKit或者使用Metal/OpenGL ES定制化的第三方游戏引擎。对于画质要求不高的游戏来说，你甚至可以只用GamePlayKit和（iOS里的）UIKit或者（OS X中的）AppKit直接创作游戏。

随机化

游戏中有很多玩法都是基于概率和机会。桌游中玩家用骰子决定移动步数、纸牌游戏有洗牌的玩法、街机游戏的敌对生物会在不可预测的时间出现、RPG游戏里的每一步动作都有成功或者失败的可能、开放世界游戏里的背景角色会自然移动，这里实在有太多太多的例子可以佐证。意想不到的惊喜可以让一款游戏变得更有趣，每一步都有变化的行为可以增加游戏的重复体验价值，模仿自然界系统的元素可以让游戏更加生动真实。

做一款依靠概率因素的游戏，通常需要使用一个虚拟随机数字生成器，或者说是随机资源。然而，并非所有的随机资源都是平等的，如果使用不当就达不到开发者的目的。在一款游戏中打造优秀的虚拟随机行为，你通常需要做到以下特点：

随机性：一个随机数字生成器应该产生不可预测的行为（至少看起来是这样），但是，随机性是怎么衡量的呢？计算机化的虚拟随机数字生成器是基于无序的有穷数列。最终，这个数列终究会发生重复，至于在重复之前可以生成多少随机数字，完全取决于资源使用的算法。更重要的是，当用二进制来看生成数字的时候，有些数字甚至是可以预测的，当然这取决于随机资源的算法。

游戏性能：更为复杂的算法可以产生更多的不可预测性，但代价是更多的处理时间。如果你的游戏为每一帧都使用多个随机数字，并且需要保持60FPS的运行帧率，一个复杂的随机源可能就会让你的游戏变得很慢，在选择随机源的时候，一定要衡量随机性与游戏性能的关系。

决定机制：高质量的游戏都需要测试，但真正的随机性会让你很难创造一个特定的测试环境。一个随机源（Random Source）应该在游戏中为玩家们保留表面上的不可预测性，但同时要允许多次重复之后的特定结果。决定机制随机源对于联网游戏来说是必要的，你需要确保随机游戏玩法对于所有人都是平等的。

独立性：由于随机源是基于一个数列，所以下一个出现的数字一定程度上取决于已经出现过的数字。然而，一款游戏通常包含多个随机元素。比如说，如果一款游戏在玩法和美观方面都加入了随机性，比如竞技游戏中，玩家们的对手往往是随即匹配的，而他们的角色可以在游戏中选择聊天对话，增加游戏的独特性。如果对话系统和已有的功能使用同一个随机器的话，一名老练的玩家或许就可以预测下一个对话框是什么内容。

透明的分配机制：对于很多玩法中的随机化使用来说，数字应该使用统一的分配机制，也就是说，所有人生成一个特定数字的可能性应该是相同的。而对其他用途的游戏来说，这些随机数字应该遵循特定的分配机制，比如说很多游戏都加入了正常的分配机制，随机的样本经常会产生与平均值相近的数字。

GameplayKit包含多个随机化的class，足以满足开发者们的这些目标。

如何在你的游戏中使用随机化功能

GameplayKit中所有的随机化class都是按照GKRandom协议，可以用最少的界面生成随机数字，首先你需要选择一个适合自己游戏任务的随机生成器：

在大多数情况下，你需要一些按照特定范围固定分配的随机数字对于这类任务来说，使用GKRandomDistribution就可以了。如果要定制化随机行为同时保持统一分配，你可以选择不同的GKRandomSource子类为GKRandomDistribution对象提供基本的随机数值。

为定制化随机数字的分配，请使用GK GaussianDistribution或者GKShuffledDistribution class。

如果你不需要特定范围或者分配随机数字，可以直接使用GKRandomSource subclasses。

你还可以直接使用GKRandomSource classes的一种来为一组数列进行随机排序，比如为纸牌洗牌。首先，选择你需要的随机源对象，然后把数列放到随机源当中。这种方法可以返回原数列的数字，不过是乱序排列。

实体和组件（Entities and Components）

和任何的软件一样，设计一款复杂的游戏需要规划一个很好的架构。随着你的游戏变得越来越大、内容越来越丰富，最初做样本游戏Demo时的一些决定可能会成为游戏发展路上的障碍。GameplayKit可以提供一个让你从一开始就可以重复利用的架构，把游戏中不同的方面分隔开来。

在这种架构里，一个实体指的是游戏相关对象的类型总称。实体可以代表对玩法非常重要的对象，比如玩家以及敌人角色；也可以是只存在于游戏中很少和玩家进行互动的对象，比如某个关卡里的动画装饰。实体还可以是创意或者游戏的UI元素，比如决定何处放置地方角色的系统或者管理玩家角色装备的系统等等。

一个实体只有容纳了游戏组件之后才开始起作用，一个组件指的是处理特定而有限方面外观或者行为的对象。由于一个组件的功能范围是有限的，而且不隶属于特定实体，所以你可以在多个实体中重复使用同一个组件。

状态机（State Machines）

几乎在所有的游戏中，玩法相关的逻辑都高度依赖于目前游戏的状态。比如动画代码的改变可能取决于一个玩家的角色目前在行走、跳跃还是站立。敌人的移动代码可能取决于你为其所做的模拟决定，比如是否追逐较弱的玩家或者躲开强大的玩家等等。甚至你的游戏在特定时间运行的帧率代码更新也取决于游戏是在进行、暂停还是在菜单或者过场动画界面。

当你开始研发一款游戏的时候，很容易把所有取决于游戏状态的代码放到同一个地方。不过，随着你的游戏变得越来越复杂，单一的方法已经很难支撑进一步的扩展。

状态机可以帮助你定义不同游戏状态下的规则，这些定义被称为状态机。然后，你就可以把相关的状态和任意代码联系起来，可以在不同游戏状态下切换模式，使用状态机管理代码可以让你更容易给游戏中的复杂行为进行理性面对，状态机可以用于你游戏中的任何一部分。

Minmax Strategist功能

很多游戏在视频游戏（Video Gaming）出现之前就已经非常流行了，尤其是桌游，比如十五子棋、国际象棋、石头剪刀布以及Go等等，从逻辑意义上讲都是游戏。玩家们想要在这些游戏中获胜就需要在每次机会中规划好最佳的行动，考虑到对手的步骤。这类游戏玩起来很带感，不管对手是另外一个人还是电脑玩家。

在GameplayKit中，Strategist就是AI的简单形式，你可以为这类游戏创造电脑对手。使用Minmax策略的游戏使用的GKMinmax class和支持API应该具有以下特点：

顺序性：每个玩家都需要按顺序行动，也就是说，玩家们要轮流体验。

对抗性：一个玩家赢，就必须有其他玩家（们）输，这类游戏的设计理念是，一个玩家的每一步都应该让自己离胜利越来越近，或者让其他玩家们离失败越来越近。

可知性：玩家们可以自信的猜测自己的每一步可以带来什么样的后果，也就是说，玩家们的行动是不取决于机会和概率的。

完美的信息：所有对于游戏结果重要的信息必须始终对所有玩家开放。比如，国际象棋的输赢基于双方在棋盘上的位置，不过大多数玩家在大多数情况下都可以看到这些位置。如果有人在过程中藏了棋子的话，那么就不是完美的信息了，因为一个玩家的行动出现了未知因素。

寻路系统（Pathfinding）

在很多游戏中，导航都是非常重要的概念，一些回合制游戏要求玩家们选择通往目标的路径，很多动作和冒险游戏把角色放到一些迷宫当中，玩家们必须揭开谜题才能实现玩法目标，敌方角色必须按照既定方式给玩家带来挑战。决定如何设置游戏迷宫、或者其他导航方面的过程就是寻路。GameplayKit为你的游戏提供一系列的地图以及寻路工具，你可以用来移动角色或者其他的游戏组件。

使用GameplayKit寻路工具需要把游戏中的导航区域描述为一张图表，上面有不同的位置或者节点一个组件从一个位置到另一个位置的移动路径是不同的。由于大多数的2D游戏都比较适合，所以为这些游戏做寻路系统是非常容易的。

代理、目标和行为（Agents, Goals, and Behaviors）

在很多种游戏中，游戏组件的实时移动都具有一定程度的自动化。比如玩家可以在一个游戏中拖动角色去特定区域，然后角色会自动行走并达到该地点。敌方角色可能会在图中攻击，计划打断玩家的行动。同盟玩家可以通过消息告诉玩家，保持平行的距离。在所有的情况下，每一个组件的移动都可能具有现实制，所以游戏角色依然可以实时移动和变换方向

GameplayKit中的代理系统可以提供有效的自动移动方式，一个代理意味着游戏中的组件会按照时机的特点进行2D空间移动，比如尺寸、位置以及速率，当然也包括速率改变时候的阻力。一个组件的移动取决于其行动目标。

目标就是可以长期影响代理移动行为的目标。

行为和带动一个游戏组件移动的一个或者多个目标有关，比如，一个目标可能包含直接移动到一个点，路上避免所有障碍。当你把行为中的多个目标综合起来之后，就可以为每一个带来相关影响的目标分配权重。

规则系统（Rule Systems）

一些游戏包含非常复杂的规则，比如回合制RPG战斗游戏可能会规定对方角色抵达相同区域之后的反应，比如谁先手？是否可以相互攻击？如果角色试图攻击或者与另一个角色互动的时候会发生什么等规则。

有些最有趣的游戏包括突发的行为，简单个体之间的互动可以为整个系统带来乐趣。

在GameplayKit当中，规则系统解决了这些问题。通过游戏逻辑数据的对比，规则系统可以帮助你把游戏分解为功能性、可重复使用性、以及可扩展组件，简单的规则也可以到来复杂的行为。

GameplayKit包含两个主要的规则系统打造class，分别是代表永恒状态下的特定决定规则GKRule，以及决定一些特定方面状态数据的规则GKRuleSystem。