从零开始独立游戏开发学习笔记（三十五）--游戏设计学习笔记 ...

xiaozongpeng · 发表于 2022-5-17 20:56

很久没有走这条路了，设计虽然学起来不难（实际使用之前），但是东西还蛮多的。
1. 游戏通过迭代提高

1.1 决策

很多时候，我们需要对创意进行判断和取舍。我们可能拥有一大堆的创意，但是其实并不太能确定到底哪个创意好。
（在 Unity 官方的 Creative Core 教程中其实有一节专门讲到决策行为，关于这个教程我有专门写的文章。但是我并没有把决策行为写到文章里，因为我觉得官方教程给的建议没什么用。）
而游戏设计艺术里给的建议则是我认为比较有价值的：

直接用，直接去实现。当做的时候再去决策，发现不好的时候就去放弃。

我认为这个方法比起官方教程的有道理的地方在于：

在实际上手之前，所有的猜测都是没有具体细节，也没有环境的猜想。只有实际上手后才能有更多的视角。如果更近一步，实现出来后，到时候理解肯定也会更深入。那时才是最了解这个决策的优缺点的时候。
很自然就能想到，在毫无细节的时候，也就是刚开始的时候，几乎就不可能有真正好的一个理解，除非以前做过有经验。

当然这个建议并不好做，涉及到一些困难，比如说时间问题，以及人一般也不太愿意推翻自己做的决定。但是如果能够克服这些困难或者做一些妥协，是比较有好处的。
1.2 八项测试

最终的设计方案出来后，需要接受以下 8 项测试。如果有一项没通过，打回重来，并且还要再测一次。因为打回重来的时候，可能改好了一个，同时却改坏了另一个。
（当然，不用那么严格，尤其是独立开发者，如果测试和自己想表达的东西冲突的时候，还是遵循自己的想法，尽量满足即可）
1.2.1 测试 1：自己满足即可

第一个测试很简单，你自己自身。或者团队成员（如果有的话），对这个设计的直觉上的满意。
直觉不一定对，但是缺点会被其他测试弥补。因此还是要选择自己很满意的设计来。
Q：这个游戏看起来不错嘛吗？
1.2.2 测试 2：目标受众

你的设计是否符合目标受众的要求。具体内容会在后面讲到。
Q：我们的目标受众喜欢这个游戏吗？
1.2.3 测试 3：体验设计的如何

前面几章一直在讲如何提高游戏体验。这个测试就是看这些技巧应用的如何。
Q：这个游戏经过精心设计吗？
1.2.4 测试 4：创新

很好理解，是否有玩家之前没见过的内容。
Q：这个游戏是否与众不同？
1.2.5 测试 5：商业和市场

考虑到商业的话，会有非常多的考量因素，毕竟商业是非常难的事情。具体细节会在之后讲到。（不过要相当相当后了，书里是第 32 章讲商业，现在这里才到第 8 章）
Q：这个游戏能盈利吗？
1.2.6 测试 6：工程

不是所有的创意都能实现的。你的创意很牛逼，你想做一个水系魔法师主角，几百万个水滴由玩家随意操控。但你的程序员今天还在问你什么叫做 deep copy。
Q：这个游戏在技术上是否可实现？
1.2.7 测试 7：社交/社区

游戏好玩是一部分。但是还有一部分是在社交和社区上的。游戏是否能在玩家间迅速蔓延？是否有一个繁荣的社区？这些也会在之后讲到（也是非常后） Q：这个游戏达到了我们的社交/社区目标了吗？
1.2.8 测试 8：玩法测试

这个最重要的当然不能缺。游戏做出来后，赶紧去玩，有能力就去测试。找出实际游玩的体验，对反馈进行改进。后面也会详细讲该内容。（非常后）
设计过程中也许会有改变测试，而不是设计的情况。比如说有时候测试之后发现虽然预期目标人群的年轻男性完全不喜欢这游戏，却对年长女性特别有吸引力。那之后测试的时候完全可以直接就把目标人群给改了。
1.3 15 号透镜：八项测试

就是刚刚提到的 8 个测试。
1.4 迭代规则

前面已经提到过，快速迭代的方法有一个致命缺陷。那就是很多时候，并没有那么多时间，有时候开发一个特性就可能花一两个月了。这个时候说抛弃掉再是下一个，确实有点伤。
一般来说，这和游戏类型相关。一些比较简单的类型，如卡牌等。开发时间较短，可以在比较短的时间内快速的迭代多次。
但如果你恰好就是那很难迭代，一次开发就要很久的类型的话。那就需要仔细地安排进度了，很多时候，设计和开发交替迭代循环。这个方式，当然，是没有完美的可能性的。对于这种情况，就是在玩一个固定预算固定时间内，尽量优化进度和设计，让游戏尽量完美的赌博。
所以很多时候，做游戏并不是达到完美，而是一个迭代游戏。在有限的时间和预算内，尽量多的测试和该进。

迭代规则：你测试和改进的越多，游戏就会越出色。

迭代需要问自己这里两个问题：

Q1：怎样才能让每次迭代都有意义？
Q2：怎样才能尽可能快地进行迭代？

想要回答这两个问题，我们需要参考的是软件工程的经验，因为两者很相似。
1.5 软件工程的历史

最开始，软件工程师们开发没有什么规则，就只是只在最开始尽可能的预测，然后开发。这通常会有巨大的问题。
1.5.1 瀑布模型

因此后来为了统一规则，出现了瀑布式流程，但是规则是统一了，瀑布流程却是一个完全没法迭代的规则。只是把整个软件开发流程固定为：系统需求->软件需求->分析->程序设计->编写代码->测试->运营。

可以看出模块化的很好，但是没有看到迭代的存在。事实上提出这个瀑布理念的人在论文里其实一直在强调迭代很好，瀑布流程应该加上迭代的能力。但是目前大多数瀑布流程在教学上都是以线性流程的方式出现的。

1.5.2 巴里·伯姆的螺旋模型

后来，1986 年，巴里·伯姆提出了螺旋模型，如下图：

螺旋模型比较复杂，从中间开始，顺时针向外旋转。
模型包含许多的细节，不过我们不需要了解。只需要关注其中最重要的三个点：风险评估，原型和迭代。

可以简单总结一下螺旋模型建议我们做的事情：

想出一个基础的设计。
找出设计中最大的风险。
建立原型来消除这个风险。
测试在这个原型。
基于从原型中得到的结论，改进得到更详细的设计。
回到第二步

重复这个循环知道系统完成。这个模型很好地解决了之前提出的两个问题：

Q1：怎样才能让每次迭代都有意义？ A1：评估并消除风险。
Q2：怎样才能尽可能快地进行迭代？ A2：构建多个粗糙的原型。

后人在螺旋模型的基础上做了许多改进，而其中最成功的方式则是赫赫有名的敏捷开发。
1.5.3 敏捷开发（agile）

或多或少，大家都听说过这个名词。无论是从老板的画饼中，项目负责人口中，或者一些项目管理软件的官网第一页介绍中，都会出现这个名词。
AGI 我们都知道，空轨的人物属性都是用英文头 3 个字母表示，小时候比较难理解的就是 SPD 和 AGI 不知道什么意思。敏捷开发这个词听起来很不像人话，也不太符合中文语法习惯，但想表达的其实就是快速开发的含义。
1.5.3.1 敏捷宣言

在 2001 年，一群软件工程师在一个叫做雪鸟的滑雪圣地，提出了《敏捷宣言》。继承了巴里·伯姆的思想，尝试提出伟大软件背后的价值观和准则。宣言分为宣言本身，以及 12 条准则。
宣言本身如下：

个体和互动 胜过流程和工具
可用的软件 胜过详尽的文档
客户合作 胜过合同谈判
响应变化 胜过遵循计划

即是说，尽管右项有其价值，但我们更重视左项。
十二条准则如下:

我们最重要的目标，是通过今早并持续不断地交付有价值的软件使客户满意。
欣然面对需求的变化，即使在开发后期也一样。敏捷开发利用变化，为客户赢得竞争优势。
经常交付可工作的软件，相隔几个星期或一两个月，通常周期较短。
业务人员和开发人员必须相互合作，每一天都要。
激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
不论团队内外，传递信息效果最好，效率最高的方式是面对面交谈。
可工作的软件是进度的首要度量标准。
敏捷过程倡导可持续开发。责任人，开发人员，客户要能够共同维持其稳定的步调。
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
以简洁为本，极力减少不必要的工作量。
最好的架构，需求和设计来自自我组织的团队。
团队定期反思如何能够提高成效，以此调整自身的举止表现。

当然，敏捷开发还包含相当多的细节。这里不作深入讲述。并且敏捷开发还有很多延伸版本。敏捷开发对电子游戏有很大帮助，相当多的电子游戏声称采用了某个版本的敏捷开发。
这里有几个不同版本的敏捷开发都会涉及到的核心元素：

灵活的目标：（说实话原文没看懂，感觉前后自相矛盾，甚至不太像人话）这里直接摘抄原话：“敏捷哲学的核心观点是，我们无法精确得知计划所需时间。通过围绕一组更加灵活的目标制定计划而不是忍受对计划作出改变，要有计划地改变计划。在开发过程中，团队能够迅速适应新的创意和信息。”
优先级列表：每次想到一个新的特性，就加入列表。然后每次迭代的时候，进行优先度分级，先完成高优先度的，再完成后面的。这个方法基于一个假设：永远不可能完成所有的特性。但能够完成重要的特性。
冲刺：敏捷开发会定一系列的小冲刺目标，一般是几个星期完成某一目标，且需要在最后完成一个坚实的成果。冲刺背后的思想是 DDL 很有用。
争分夺秒的会议：相对于那种每周一次超长的会议。敏捷开发更多是每天进行一次超短的会议，甚至可以站着开会，每个人只解释三件事“昨天做了啥？今天准备干啥？现在遇到了什么问题？”在会议结束的时候，当面去找那些有问题的成员去解决问题。
演示日：每个冲刺阶段的最后，大家聚在一起面对面地观察和测试工作成果。然后在这个基础上，大家一起进行风险分析，以及下一冲刺阶段的目标。
回顾：每个冲刺阶段的最后，还会有一个回顾会议。和演示日不一样，这个会议不讨论产品，而是工作流程。团队成员每个人都有机会在此讨论什么流程是正确和错误的，怎样在下一冲刺阶段调整这个流程。

用这种视角来看疫情期间影响的无数项目，就可以给出一个全新的观点。

这些受到疫情影响的项目，很有可能就是因为敏捷开发受到限制的原因。敏捷开发极度强调面对面交谈，快速的会议。但是疫情使得面对面不可能，同时远程会议也相当累人，由于缺少眼神和面部众多细节，获取信息也少。

1.5 风险评估和原型设计

记住一点，敏捷开发不是一个既定的固定流程，所有项目直接按着来就行。敏捷开发只是一种思想，每个项目的敏捷开发的流程都不一样。而这些不同流程的设计，核心就是风险评估和原型设计。
不跟你废话，直接上案例：气泡城的囚徒
假设你的团队决定做一个关于城市跳伞的电子游戏。并且已经对游戏元素进行了一个简短的描述：
元素

还记得游戏构成基本元素吗？是这四个：剧情，机制，艺术，技术。

剧情：你是一只会跳伞的猫，名字叫“微笑”。气泡城的居民都被一个邪恶的巫师困在房间里。你需要通过跳伞潜入城市，滑下烟囱，拯救市民，并找到阻止巫师的方法。
机制：在向城市跳伞的时候，你可以试着抓住从城市中升起的魔法气泡。使用魔法气泡的能量向邪恶的秃鹫发出射线，防止它们戳破气泡或者撕碎你的降落伞。同时你必须控制降落伞到城市中的几个目标建筑之上。
艺术：卡通风格的外观和游戏体验。
技术：使用第三方引擎的，多平台的 3D 主机游戏。

很好，现在一个美术普通，无聊，手感稀烂，Steam 评论好评如潮，销量 1000 份的每天都可以看到的 3D 运动游戏跃然纸上。（不是）
现在你有了这些元素，你可以开始制作游戏了。
第一个方法是，现在立刻开始制作。写代码，设计关卡，角色动画，直到做完，然后看一下做出的成品咋样。

但是这有巨大问题。假设这个项目持续 18 个月，你花了 6 个月做了第一版，开始测试。然后发现，玩法不好玩，咋办？或者做到第 5 个月发现，引擎做不成这个特性，咋办？花了 1/3 的时间，却只完成了一次迭代，这就是问题。

第二个方法，也是正确的方法。是和团队一起做一个风险分析，把所有可能会危害到项目的风险列成一个列表。对于刚刚这个游戏，你可以列出以下风险列表：
风险列表

收集泡泡/射击秃鹫的机制可能并不有趣。
游戏引擎可能无法绘制整个城市，秃鹫，以及其气泡。
我们目前的想法是有 30 种不同的房子。但我们可能没时间画那么多，包括设计和动画。
我们不确定人们是否会喜欢我得角色和动画。
今年夏天有一部关于跳伞的电影会上映，发行商可能会要求我们以此作为主题。

假如只考虑这些风险，我们该怎么做呢？为了实现风险消除，我们就需要做原型开发了：

对于第一个风险。我们可以以一种非常简单的方式将其实现，用一些简单的几何形状来代替。然后快速开发原型，试玩，判断是否有趣。不停迭代直到其变得好玩。也许你会觉得，做了这么多原型，写了这么多代码，这些代码可能之后永远都用不上，很浪费。但是其带来的迭代时间上的节省，以及游戏质量的提高，是比较合理的。
对于风险 2，解决方式就是在屏幕上展示预估的数量的相同物品，看引擎是否能够承受。这个原型不测试玩法，只专门用来测试性能。
风险 3 的话，就是让艺术家先画一个房子，计算出单个的时间，然后评估整体的时间。如果发现无法介绍，那就需要对设计进行相应的变化。
第 4 个风险，往往不是游戏原型。而是一个艺术原型，让画师绘制作品，或者渲染出 3 位建模。曝光在媒体，最好是目标人群前。观察其是否喜爱。整理出喜欢和讨厌的原因。对角色和动画进行改动。
风险 5 听起来很怪，但却是经常发生的。这种情况一个原型可能就没用了。你可以在制作游戏的时候让其变得容易修改成电影化的样子。或者制作两个游戏的计划，等等各种有的没的可能性。

1.5.1 16 号透镜：风险消除

具体细节都是上面讲的内容了。
问自己这几个问题：

有哪些可能的风险？
我们怎样防止这种风险发生？

面对风险是一件比较难的事情，因为很多时候人不想面对这些问题。这是一种诱惑，只专注于自己自信的事情（就像我迟迟不学美术和音乐一样）。必须抵抗住这种诱惑，来解决这些风险。
1.5.2 制作原型的 10 个秘诀

技巧 1：回答一个问题

每个原型必须得回答一个或者多个问题。不然原型就是在浪费时间。
这个原型是用来测试玩法的？还是性能的？还是角色设计？等等。
避免过度构建原型，别做着做着开始打磨原型了。原型只专注于解决问题。
技巧 2：忘记质量

不要把原型做的太精致。这不只是浪费时间的问题。甚至，一个在别的方面做的太精致的游戏。可能会让人忽视掉它的问题。
比如说你做一个玩法测试，然后你玩法本身其实不行，但是你美术和音乐和剧情做的太好了。测试者都玩哭了，根本无视掉玩法怎么样了，玩完告诉你这游戏太棒了。你就会得到错误的情报，你的玩法并没有实际上得到验证。
技巧 3：不要太过留恋

没什么好说的。字面意思。不要觉得抛弃掉原型是浪费。
技巧 4：设定原型的优先级

就像在敏捷开发里提到的一样，给原型设定好优先级。优先完成高优先级的原型。
在评判优先级的时候，需要考虑到依赖性。比如一个原型的成功与否关系到别的原型有没有意义，那这个原型无疑是非常高优先级的。
技巧 5：有效的并行原型

因为原型专注的问题比较少，因此对于团队来说，完全可以多个原型并行进行。技术构建玩法原型，美术构建艺术原型，等等
技巧 6：并不一定要数字化

就像之前提到的，原型不一定是程序，也可能是画，3D 建模，一个发布到社交网站上的 gif 图。
有些时候，甚至可以是一个纸上的原型。比如数值，规则之类的。当然，前提是你觉得在纸上做这些比用电脑制作花费时间短。
技巧 7：无需交互

原型并不一定能够交互。可能就只是展示一些片段。还是那句话，注重要解决的问题，其他的打磨都是没有必要的。
技巧 8：选一款能快速迭代的引擎

反正最后都是要抛弃的。并不是说你用 Unity 制作游戏，原型也一定要用 Unity 来做。市面上有很多专门为原型制作而产生的工具。用那些工具能更快的出效果，也许自定义度不够，但那没关系，原型里不需要用即可。
比如说像是 Unreal 其实就可以用蓝图来做原型设计。真实开发再写 C++。
技巧 9：先构建玩具

玩具和游戏的区别在于，玩具本身就很好玩。
棒球游戏中，球是玩具，整个过程是游戏。一个能跳的水管工是玩具，《超级马里奥》才是游戏。
当然不是说主角才是玩具，比如说《GTA》的设计时，玩具是那个城市，这个城市栩栩如生，已经很好玩了。然后我们再添加主角进去和进行互动，等等细节。
《见证者》中，蝌蚪文就是玩具，剩下的就是等游戏自己把自己做出来了。
当玩具和游戏都有趣了，就会拥有两个层级上的好玩。蔚蓝的人物手感已经就很好玩了，光是在一个地方跳来跳去就已经足够有趣，后面就只是扩展了。
17 号透镜：玩具

问自己这几个问题：

如果我的游戏没有目标，那它还好玩吗？如果不是，怎么改进？
人们看到我的游戏，能否在不清楚玩法之前，就已经想跟它互动了？

这个透镜有两种使用方式：

第一种是在一个游戏已经开发好的时候，使用该透镜，让其具有玩具的特质。
第二种是在游戏开发之前，先做一个玩具出来，再围绕着它做成游戏。

技巧 10：抓住迭代的机会

像有些时候，比如说移植到新的平台的时候。可以把这当做一次迭代的机会，再次提高游戏的质量。
1.6 一些工业预算法则

工业上，开发游戏有着各种各样上的限制，尤其是预算和时间。作者自己总结了两个工业上，避免预算不够的法则：
1.6.1 计划性削减预算法则

计划游戏的时候。确保当你的 50% 的预算被削减了，依然能做出一个可玩的版本，即使放弃了一些别的特性。这个法则要求你的核心系统不要过于复杂。
1.6.2 50% 法则

所有的核心玩法应该在前半段时间里完成。即用一半的时间让游戏变得可玩，用剩下一半时间让游戏变得更好。
1.7 你的秘密燃料

1.7.1 18 号透镜：激情

一直带着之前的分析来思考游戏，会很容易忘记初心。每次完成一个原型并消除风险后，问自己这几个问题：

我对这个游戏的成功还有极大的激情吗？
如果我失去了激情，怎样才能找回它？
如果激情没有回来，我是不是该做些别的？

如果你自己都会游戏失去了激情，也许这个游戏在哪些方面是有问题的。必须找到这个问题所在，否则你的游戏很容易死去。
但同时，激情也可能有危险，因为激情是不合理的，需要小心对待它。
2. 自己的想法

看到这种反自我表达的风险评估，毫无感情的工业法则，以及居然要专门为失去激情做一个透镜，就觉得挺难受的。一个工作居然需要我使用技巧来避免失去激情，还挺难过的。
因此这一部分的内容，我决定选择性参考。不过迭代的思想，风险评估等我觉得还是很有用的。

		自动登录	找回密码
密码			立即注册

从零开始独立游戏开发学习笔记（三十五）--游戏设计学习笔记 ...

本帖子中包含更多资源