如何利⽤结构化思考,去设计游戏系统?

作者:三季⼈ 2021-10-11 25.8k
前言

在游戏设计中,思考方式本身不存在孰优孰劣,但在某些应用场景中,更适合的思考方式能够更容易得出更健壮的结果。

本文无意争论思维方式的好与坏,只是分享一种思考的方式,供设计师们参考。

什么是结构化思考?

我所认为的结构化思考更多是一种将事物本质进行结构分类,以及将各部分结构之间联系梳理清楚的思考方式。

以一个简单例子说明,在一般游戏公司中,

一般会把负责游戏设计的人员称之为“策划”,

负责美术制作称之为“美术”,

负责游戏实现称之为“开发”,

同样的还有运营市场等等······

这种划分方式叫做组织“结构”划分,这其实就是典型的”结构化“分类。

将事物本质按照特定的逻辑关系,分类成不同结构,并且将结构之间的逻辑联系梳理清楚,这就是我所理解的结构化思考。

当然,按照上述例子而言,每个结构之下可以继续进行细分分类,譬如策划可以分为系统、数值等,只要有需要,理论上可以无限拆分。

那么何时为思考完成呢?

因人、因事而异,当设计者认为当前结果已经足够完善即可。

怎么用 —— 以房间系统为实例

回到正题,那么在游戏系统设计中,如何利用结构化思考呢?

我个人而言会从三点去进行:

  • 按照一定逻辑关系拆分结构。
  • 简单将结构联系起来(不需要太精准)。
  • 深入拆解结构之间的数据的输入输出。
  • 基于第三步的结果,进一步优化结构或者生成有必需的分支结构。
  • 重复上述2,3,4步,直至结构以及结构之间的联系是足够精准的。

上面几点有不说人话的嫌疑。

下面以一个简单游戏系统,房间系统为例子,讲述整个过程。

先说房间系统的需求,用相对浅显的语言描述就是,

“房间是为汇集不同玩家成一个个小群体而提供临时场所,它提供的是玩家进入游戏前的过度”。

但实际上,这依旧是一个相对模糊的需求,怎么样的“”不同玩家”?不同玩家是怎么样分类的?需要怎么样的过度?过度是为了什么?

梳理问题,以及解决问题,可能这本身就是设计师的工作。

让我们开始吧。

首先,先分析需求的本质,房间目的是为了分类不同玩家,让符合一定标准的玩家更好地一起进行游戏。

那么,第一步,房间系统的主体结构可以拆分为:


第二步,简单将结构联系起来。


结构相互之间关系为,用户进入到房间,房间将聚集好的用户输入到战斗中,战斗完成后,将结果反馈到用户当中。

这里的结构之间联系肯定是不够周全的,但先从最明显的关系出发。

第三步,深入拆解结构之间联系。

先从用户—>房间开始,用户是以怎么样的方式进入到房间呢?


对于房间来说,用户的进入,可以理解为不同的用户数据输入,这部分数据需要按照一定标准进行分类,目的是把玩家分成不同群体,每个群体即为一个房间。

这里需要一种对用户数据的筛选处理方式,一般情况下有下面三种,

匹配:按照一定规则,将用户特征相符合的玩家聚集在一起;适用大部分公平竞技游戏。

房间号:提供房间号,将输入相同房间号的玩家聚集在一起(好友邀请进入同理);适用于个性化房间,即方便玩家自由组队。

房间列表:玩家建房间,客户端提供可用房间列表,其他玩家进行挑选;适用于有模式或者地图选择的游戏,如CSGO。

一般情况下,如果没有对整体结构有清晰认知,房间系统的设计往往约等于匹配系统设计或者房间列表设计,执着于具体的筛选方式。当然,这部分或许是整个房间系统最重要的部分,但是也只是一部分,一个完整的系统需要完整的闭环。

经过筛选后,符合条件的用户就会变成一个房间,房间需要输出房间数据,而不符合要求的玩家,则需要驳回到用户。

根据上述思路,我们可以得出以下结构:


第四步,在第三步的思考的基础上,实际上需要一分支结构。

思考到这个阶段,很容易就出现了疑惑,单纯把玩家聚集在一起,就足够了吗?

但实际上很多情况下,玩家进入到房间,实际上还有非常多操作需要进行,譬如在MOBA游戏当中选择英雄和技能等。

既然用户有相当大的一部分数据是需要在房间内进行的,因此这部分房间数据实际上需要返回给用户,用户再进入下一个阶段,我称之为用户准备阶段。

用户完成准备阶段后,实际上是将房间内的用户个人数据、房间信息、准备流程数据一起输出到游戏战斗中,战斗模块根据该部分信息生成战斗。

根据上述思路,我们可以得出以下结构:


根据游戏种类的不同,用户在房间内的准备流程各不相同,流程基准是能够产生生成战斗所需的必须数据信息。

第五步,需要从第二步开始,重复2,3,4步,继续深化结构与结构之间的联系。

当房间完成其任务后,自然将其输出的数据,输入到游戏战斗模块当中,去生成战斗。

此时要做的是,深化房间—>战斗的联系。


战斗模块各不相同,实际上只要保证生成战斗的必须数据,房间能够提供即可。

可得出以下结构:


同理,继续深化战斗与用户之间的联系。


当战斗结束后,产生的结果需要给予用户反馈,譬如谁胜利了,拿了多少分等等,这些可能在战斗流程就完成,但也有可能需要在战斗外处理。

除了结果外,战斗还会对现有信息产生一些变更,如用户的个人信息(KDA,胜率,常用枪支角色等等),这些数据,需要用户系统自行进行处理。

可以得出以下结构:


当思考到这一步后,我们继续重复第四步,有可能的分支漏了吗?

一个非常明显的问题,战斗结果的信息需要返回给房间吗?房间部分需要战斗的一些信息吗?


实际上,是需要的。房间在战斗结束后,需不需要根据结果的数据,保留房间还是销毁房间?房间内的角色是否缺失了?房间内的阵营这些信息会影响玩家准备阶段吗,还是直接可以带入到下一盘当中?

显然这些疑问都需要战斗产生的结果信息反馈到房间当中,所以实际的优化结构是:


战斗反馈结果到房间的结构是:


在此为止,整个房间系统就完成自我的系统闭环,可暂时视为已经完成结构化思考。当然,因为是介绍限制,在实际使用中,还可以继续对结构进行深化,直到达到自己认为完善的标准。

在达到自己认为完善的标准后,就可以对结构中每一部分进行深化了,譬如,到底是用匹配规则还是房间列表方式,用户数据有哪些,组成房间后,内部准备流程是怎么样的等等······基于结构进行详细设计的过程,会使整个设计脉络更加清晰。

总结 —— 结构化思考的优缺点

结构化思考并不能直接得出一个完整的系统,可做的是将整个系统骨骼搭建起来,为之后的交互规则、具体机制设计提供支撑。

对于一些十分熟练的设计师,可能稍显浪费时间,但结构化思考是存在一定价值的,下面将会总结一下结构化思考的优缺点。

首先,谈谈优点。

  • 比较易懂,清晰,好用,**起来没烦恼。无论是主策还是实际设计落地的设计师,基于整个结构化进行讨论(**),都会更加有效率。在系统设计前期,讨论太多的交互细节容易扰乱其他人思维,同时,清晰的系统结构确定后,会极大减少返工的可能性,这一点无论是实际设计,还是实际开发中,都很重要。
  • 逻辑点不容易漏。在结构化思考的过程中往往比较容易查漏补缺,就像上述房间系统需求当中,在深化结构与结构之间的联系过程中,往往能够排查出思考过程少了的部分。
  • 扩展性强。当以后有新的需求需要加入时,可以很清楚了解新需求应该加入到哪一部分当中,结构的哪一部分变更了,从而更加直接找出需要变更修改的地方。
  • 系统排错能力强。当实际验收过程中,发现错误时,大部分错误能够根据结构流程,快速找出其导致错误的原因,脑海里会比较清晰了解到底是哪部分结构卡壳了导致现有问题。

当然,这种思维方式肯定存在缺点。

  • 只适合确定性比较强的游戏功能系统,对创造性需求较强的结果效果比较弱。对未见过,认知比较少,或者需要较强创造性的需求时,效果不好,特别是游戏艺术部分,但对一些确定性比较强的部分,譬如好友、公会等系统,结构化思考的优势就会显然易见了。
  • 思考容易受限,特别是在结构化基本成型后。思考的边界往往摆脱不了现有已经成型的结构,这也是为什么结构化思考不太适合艺术创作的原因,突破思考边界的最有效的方式往往是交流。
  • 结构一旦出错,往往都不是什么小事。这个,可能不用多说了。

结论:

我很喜欢埃隆·马斯克所提倡的“第一性原理“思考的法则,我认为结构化思考的本身就是第一性原理思考的延伸。

结构化思考带来的是整个系统的设计支撑,它本身不会直接输出一个完整的结果,如果说游戏开发是基于设计者的设计图,去开发整个系统,那么结构化思考更多是”设计图“本身的“设计”。

如前言所描述的,在游戏设计中,思考方式本身不存在孰优孰劣,但是合适的思考方式,帮助我们更容易的得出更周全的结果。希望这次分享的思维方式能够帮到你,也希望能够交流不一样的思考方式。

我是三季人,欢迎关注游戏设计思维(知乎号、微信号同名)。

笔者是游戏从业者,专注于游戏和游戏设计,欢迎交流互喷,一起共同成长。

一片赤诚之心,致我们热爱的游戏。



相关推荐

最新评论
暂无评论
参与评论

Facebook游戏出海峰会
推广
商务合作 查看更多

编辑推荐 查看更多