图例：一个多人解谜类游戏的设计架构

2015-08-21

本帖最后由 小篱 于 2015-8-21 13:52 编辑


GameRes游资网授权发布 文 / 吴睿

如何在网络游戏中设计一个需要多人合作来解谜的游戏？

首先是解谜游戏的基本模型构成。


上图Part1表示的是一个基础顺序型解谜游戏的基本构成，一个基本的解谜游戏由以下几点构成：

Puzzle。组成游戏的单个谜题，在这里我们定义每个谜题仅由一人参与解题。

Step。解完一个谜题后开启下一个谜题的资格，我们称之为Step。如图所示，解完Puzzle1，就进入Step2开始解Puzzle2。

上图Part2表示的是每一个Step内Puzzle间的关系。

1.Not，这个用得很少，因为玩家一开始就处于Step完成状态可以直接进入Step2，通常与以下两个关系联合使用。

2.And，两个Puzzle必须均解出才能Step+1，通常用于并行的解谜操作。

3.Or，两个Puzzle只需要有一个解出就可以Step+1，通常用于让Player自行选择哪个谜题进行解题，比较灵活，但是也会有一些劣势，Player无需获得所有Puzzle中提供的Info就可以进行下一个Step，如果这个过程是不可逆的，那么如果我上一个Step有设置Info用于解决这一个Step的Puzzle而Player没有遇到，最终会导致卡死的情况发生。（Player没有获得到应得的Info，无法做出正确的Action，Info与Action将于下文介绍。）


上图表述的是一个Puzzle内拥有的元素,一个Puzzle内拥有若干个行动（Action）和信息（Info）。

Action，Player对谜题做出的有效行为，比如正确的输入密码，按照要求找回了美眉的指定内衣等等，做出正确的行为则Action值为True，错误则为False。

Info，能够指导玩家进行正确有效行为的信息，比如密码暗示，内衣位置。

请注意，Action和Info之间并没有强制的关系，全部由设计者自行考虑内容的实现。Action之间是拥有基本的与或非逻辑关系的。判断一个Puzzle是否解出，等价于判断所有Action之间逻辑运算后返回的逻辑是否为True。

以上就是一个基本的顺序型解谜游戏的模型，大部分解谜游戏都是如此，是不是看起来很像写代码？

下面我们来谈谈如何设计多人解谜类游戏，我们先不考虑Puzzle内部的设计。

由于在一开始我们已经定义了一个Puzzle只能由一个Player解出，那么在一个Step中，可能存在多个Puzzles需要Players解决，那么我们很容易的认为一个萝卜一个坑，每个Player对应的解决一个Puzzle。同时解决完，进入下个Step，事实上，你无法控制Player的行为，“同时”这个条件需要的代价太大，你需要耗时耗力监测Players是否同时，如果不同时需要进行回滚操作等等。

那么我们考虑异步情况。

能否设定一个机制，每一个Step仅允许通过一人（或者少于整个Player总数的人数），同时在下一个Step中设置上一个Step的准入资格。比如说Step1中的Puzzle1解决了以后，Player1进入Step2，Player1在Step2中解决Puzzle2，使得Player2能进入Step2。

举个说人话的例子，小明站到了一个重力感应机关上面，一个机关门打开，小明一旦离开机关，机关门关闭。这时候见义勇为的小刚让小明站到了重力感应机关上面，然后义无反顾的进入了机关门，在机关门后面的密室里找到了根擎天柱顶住了机关门，小明顺势就这么进入了机关门。

当然这种例子会有一个问题，如果打死了只有小明一个人怎么办？在网络游戏中一定一定不要设计一些必须多少多少人才能通关的关卡，血泪教训，因为你无法知道服务器最终能有几个人，你必须保证就算服务器只剩1个人，这个人也能体验到大部分的游戏内容。

那么我们就可以设置一些or关系的Puzzle来给孤单的小明一点曙光，具体过程不赘述了。

注：

关于Puzzle内的Info与Action，一个Puzzle内提供的Info不一定只用于本Puzzle，也可以提供到八竿子打不着的Puzzle内，不过有得游戏大部分Info都是Player的阅历提供的，有时候设计者根本没想过在游戏内提供，突出一个丧心病狂。

参与评论