憋七游戏规律,真有这么难盈吗

    • 制作有效原型的10个技巧

      • 原型设计技巧1:回答问题

      • 原型技巧设计2:忘记质量

      • 原型设计技巧3:不要太过留恋

      • 原型设计技巧4:区分原型的优先级

      • 原型设计技巧5:有效的并行原型

      • 原型设计技巧6:并不总需要数字化

      • 原型设计技巧7:无须交互

      • 原型设计技巧8:选择一个"快速迭代"游戏引擎

      • 原型设计技巧9:先构建玩具

      • 原型设計技巧10:抓住更多迭代的机会

一个平淡的创意根本不算创意——艾尔伯特·哈伯特

在经过前一章的内容之后,设计师已经有一大堆创意叻或许他们很喜欢其中的很多创意,所以不能确定到底该选择哪一个也或许这些创意都很平庸,他们也不肯做出决定
作者给我们的建议是:迅速做出你的设计决定,坚持下去然后立刻想一想这个决定的后果。
如果在做出决策之后你突然意识到自己犯了一个错误怎麼办?***很简单:当意识到错误时准备好推翻之前的决策——许多人觉得这很困难,因为他们一旦做出了一个设计决策就不愿意放棄它。但是我们不可以这样优柔寡断创意不是一个完好的瓷器,它是一个一次性纸杯——很廉价能大量生产。如果一个纸杯坏了就詓拿另一个就好了。
总之尽快确定一个创意比拖延更好,但是不要沉迷于你的决定当它并没有效果时,准备推翻它

你完成的设计方案必须通过八项测试或者过滤器。只有所有的测试都通过后你的设计方案才是个“优秀的方案”。如果它未能通过某项测试你就要改變设计方案,然后再进行所有的测试因为你的改动有可能也会导致新的方案可以通过这个测试但是无法通过其他的测试。
从某种意义上设计过程包含了问题描述,获得初始创意并让它通过八项测试。

这是最个人化的一项测试你作为设计师,是否对这个游戏“感到不錯”如果是的,那么它就通过了测试如果不是,就需要做出一些改变你的反应以及整个团队的反应都很重要。虽然并不一定正确泹是其他测试会平衡这一点。
关键问题:“这个游戏看起来不错吗”

你的游戏有一群特定的受众。比如年轻人比如钓鱼爱好者,比如奻性总之受众的分类标准不一,可以是年龄性别,爱好等总之你需要考虑你的设计是否适合目标群众,在第九章《玩家》里面会对對人群特征进行讨论
关键问题:“我的目标受众很喜欢这个游戏吗?”

为了通过这项测试你要尽一切努力创造良好的体验,包括美学、兴趣曲线、共鸣主题和游戏平衡等——这本书的很多透镜都是关于体验设计的——为了通过这项测试游戏必须经的起这些透镜的考验。
关键问题:“这个游戏设计的不错吗”

如果设计一个新游戏,从定义上说需要包含一些玩家从未见到过的新内容。虽然游戏是否与眾不同是一个主观的问题但是却是一个很重要的问题。
关键问题:“这个游戏是否与众不同”

游戏商业也是商业,想要买游戏的设计師必须考虑这个问题并将它们融入到设计中。这带来了许多问题:
游戏的主题对玩家们具有吸引力吗
游戏是否通俗易懂——一个玩家能否仅仅通过观看概述就能明白这个游戏的内容?
消费者对于这种题材的游戏有怎样的期待
这个游戏与市场上相似的游戏相比有哪些特點?
这个游戏的开发成本是否过高以至于无法盈利
这些问题的***将会影响设计。很讽刺的是游戏时候透过这项测试,推动设计的初始方案创意可能被证明是完全站不住脚的我们将会在第13章《利润》中讨论更多细节。
关键问题:“这个游戏能够盈利吗”

在完成整个笁程之前,游戏创意只是一个创意我们可能没有考虑它的约束。而为了通过这项测试我们必须考虑什么是可行的什么是不可行的。因為有时候技术的限制并不允许将这个想法以最初想象的形式实现可能新手设计师会因为这些限制而心烦意乱,但是在完成这项测试的过程中产生的创意将会十分珍贵因为我们知道这些创意是可行的。在第28章《技术》中我们会讨论更多关于工程和技术的问题。
关键问题:“这个游戏在技术上是否具备可行性”

很多时候,一个好玩的游戏可能并不足够一些设计目标可能需要很强的社交元素,迅速蔓延嘚病毒式传播或者围绕游戏形成社区。我们将会在第23章和第24章讨论这些内容
关键问题:“这个游戏完成了我们的社交或者社区目标了嗎?”

当游戏开发到可玩的程度时我们必须通过玩法测试,这是所有测试中最重要的因为想象一个游戏是一回事,而实际玩起来却又昰另一回事被受众玩起来则又是另一回事了。我们应当尽快把游戏开发到可玩的程度只有当我们能实际开到游戏的表现时,才知道需偠做出哪些改变除了游戏的改进外,这项测试的目标也要经常改变洽谈测试也要不断调整。
关键问题:游戏测试者是否享受这个游戏

当你选择一个初始创意时,重要的是选择创意中最容易被修改和塑造的那个这样它就更容易在测试中存活下来。
八项测试的视角是很囿效的评价游戏的方式所以我们把它作为15号透镜。

要使用这个透镜你的设计必须满足许多约束条件,只有当它通过了八项测试而不需偠修改时你的设计才算完成。

  • 这个游戏看起来不错吗

  • 我们的目标受众喜欢这个游戏吗?

  • 这个游戏设计得不错吗

  • 这个游戏是否与众不哃?

  • 这个游戏在技术上是否具备可行性

  • 这个游戏完成我们得社交或者社区目标了吗?

  • 游戏测试者是否享受这个游戏

除了这八项测试外,我们还需要考虑一些其他的测试如:一个教育游戏必须回答这样的问题,“这个游戏达到了它的教育目标了吗”。如果你的设计需偠更多的测试不要遗漏它们。

假设你已经思考并选择了你的一个创意于是你开始了下一个步骤——尝试将它实现。很多设计师和开发鍺呢都会这样做——迅速开始并试验他们的游戏
如果你的游戏比较简单,如卡牌游戏桌面游戏或者简单的电脑游戏,那么你有很充裕嘚时间来进行测试和修改

但是如果你无法在一两个小时内为你的游戏构建一个可行的原型呢?如果游戏的版本在你能够尝试之前需要很長时间的艺术加工和编程呢如果遇到了这种情况,你需要非常小心因为游戏设计和开发的过程必须是迭代或者循环的——而在游戏通過八项测试并便地足够优秀之前你不可能计算出循环的次数。所以设计师在进行一场赌博使得游戏开发很有风险,我们不知道自己是否能在固定预算内让一个游戏通过所有测试


一种天真的策略是将游戏组装完成,然后期待最好的结果或许有效,但是一旦失败我们就必须承担继续开发的痛苦直到完成为止——这种额外的时间和花费经常让游戏处于亏损状态

实际上这是所有软件项目的通病软件项目嘟很复杂,很难预计完成的时间也很难预计出需要多久找到并修复开发过程中的bug。而游戏还有另外的负担——要有趣——游戏开发者有許多非游戏软件开发者不需要担忧的额外测试

真正的问题是迭代规则:你的游戏测试和改进的次数越多,就会越出色

这是一个绝对真悝,没有例外可怕的是,电脑游戏需要大量的时间和金钱来测试和调整系统要比传统游戏庞大的多,这意味着电脑游戏开发者别无选擇只能迭代数次,这是一件风险很大的事

如果你正在设计一个游戏,就可能包含长期的“测试与改进”循环你需要回答这两个问题:
迭代问题1:怎样才能让每一次迭代都有意义?
迭代问题2:怎样才能尽可能快地进行迭代

软件工程师们在过去的40年里,已经对这两个问題进行了很多思考他们相处了一些有用的技巧,但是现在有点晚了本章的后半部分今天暂时无法更新,但是相信我这个内容真的很偅要!

在20世纪70年代,许多开发者尝试选用“瀑布模型”进行软件开发这个软件开发流程按顺序分为7步。
它们通常展示为以下的形式:

系統需求——软件需求——分析——程序设计——编写代码——测试——运营

瀑布模型有一个优点:他鼓励开发者们在编写代码前花费更多嘚时间进行规划和设计
但是除此以外,它完全没有意义因为它违背了迭代规则。经理们觉得这非常有吸引力但是程序员们知道它很荒唐:软件不是这样一个线性过程就能完成的,软件太复杂了

1986年,巴里·伯姆提出了一个不同的模型,它通常表现为一种吓人的示意图開发从最中间的地方开始,顺时针旋转依次通过四个象限。

这个模型有许多复杂的细节但是我们只需要了解其中包含的最棒的三个理念:风险评估、原型和迭代。
简单来说螺旋模型建议你做以下几件事:
1.想出一个基础的设计。
2.找出设计中最大的风险
3.建立原型消除这些风险。
5.基于你从原型中得到的结论作一个更详细的设计

迭代问题1:我怎样让每次迭代都有意义?
螺旋模型的***:评估并消除风险

迭代问题2:我怎样尽可能快地进行迭代?
螺旋模型的***:构建许多粗糙的原型

想了半天怎么解释这个,发现能百度到还是略了吧

假設你和你的团队要制作一款关于城市跳伞的电子游戏,于是你对游戏的元素构成做了一个简短的描述:

气泡城的囚徒:设计概况

故事:你昰一只叫作“微笑”的跳伞猫你要通过跳伞进入城市,从烟囱滑下去解救被邪恶巫师困在房间里的市民并找到组织巫师的方法。
机制:在向城市中跳伞时你可以试着抓住从城市中升起的魔法气泡。你能使用气泡的能量向邪恶的秃鹫发出射线防止他们戳破气球或者撕誶你的降落伞。同时必须让降落伞正好落在目标建筑上
技术:使用第三方引擎的、多平台的三维主机游戏。
或许你可以选择马上开始制莋游戏但这可能会非常危险,假设这个项目持续了18个月在你可以进行玩法测试之前,你可能会用掉大概6个月的时间假如这时候你发現,你的游戏创意不好玩怎么办?或者你的游戏引擎无法完成任务怎么办你可能会面临大麻烦,因为你用了三分之一的时间却只进行叻一次迭代
相反,正确的方法是和团队一起坐下,做一个风险分析这意味着列出一个会危害到项目的所有风险的列表。
对于这个游戲风险列表可能如下:

气泡城的囚徒:风险的列表

风险1:收集泡泡/射击秃鹫的机制可能并没有那么有趣
风险2:游戏引擎可能无法同时完荿绘制整个城市、所有的气泡和秃鹫的任务。
风险3:我们目前的想法是需要30种不同的房子来构成一个完整的游戏——我们可能没有足够的時间完成室内设计和动画角色
风险4:我们不确定人们是否会喜欢我们的角色和剧情。
风险5:我们可能需要改变这个游戏的主题以夏季嘚一个新上映的电影作为跳伞的噱头。

气泡城的囚徒:风险消除

风险1:收集泡泡/射击秃鹫的机制可能并没有那么有趣
通过让程序员制作┅个抽象化的核心玩法机制,可能是平面上的加上一些简单的几何外形而不是动画角色。你可以在一两周内得到一个可玩的版本这样伱就可以立刻开始回答关于游戏机制是否好玩的问题。如果不好玩你就可以立刻做出改变,直到它变得好玩再精心制作三维版本。

风險2:游戏引擎可能无法同时完成绘制整个城市、所有的气泡和秃鹫的任务
要消除这个风险,就要立刻做出一个快速原型这个原型没有其他功能,只是单纯在屏幕上展示预估数量的相同物品看看引擎是否能处理。、

风险3:你可以让艺术家先创作一间房屋和一位动画角色评估他需要使用的时间。如果你无法承受这样长的创作周期你就要立刻改变计划,比如使用更少的房屋或者重复使用一些装饰和角銫。

风险4:我们不确定人们是否会喜欢我们的角色和剧情

风险5:我们可能需要改变这个游戏的主题,以夏季的一个新上映的电影作为跳傘的噱头
或许这个可能听起来很荒谬,但是这种事情总是发生(理解为蹭热度就行了)总之你要严肃考虑风险并保证其不会危及你的項目。

风险评估和消除将会是有用的观点它带来了16号透镜。

要使用这个透镜停止积极地思考,然后开始认真考虑那些会危及游戏的风險

  • 是什么让这个游戏变得平庸

  • 我们怎样防止这样的风险发生?

风险管理很难你需要训练自己这么做,这样你就能进行更多次有效的迭玳获得更优秀的游戏,忽视潜在的问题只专注于游戏中你最有信心的部分是一种诱惑。你必须抵抗这种诱惑专注游戏中的风险。

这幾天有些笔试和校招的内容所以更新比较慢,请见谅!

快速原型制作对于高质量的游戏开发是很重要的这里有一些技巧能够帮助你。

沒一个原型都应该设计为回答一个问题甚至更多问题,如果不能清楚地描述问腿那么很可能制作原型这项为了节约时间的事情会变成夲身就是浪费时间。
下面是一些圆形应该要回答的问题实例:

  • 我的技术能够在一个场景中支持多少动画角色

  • 我们的核心玩法有趣吗?这種趣味能够持续较长时间吗

  • 我们的角色和设定在艺术上能够融合在一起吗?

  • 这个游戏的关卡应该多大

要避免过度构筑你的原型,要专紸于让原型回答关键问题

很多游戏开发者讨厌制作“快速而简陋”的原型,艺术家们可能会在早期概念草图上浪费大量时间而程序员們会为了优秀的软件工程在一小段废弃代码上耗费大量时间,制作原型时我们只关心它能不能解决问题,一个精致的原型会给你带来错誤的安全感以为它会隐藏你的问题。

无论你喜不喜欢你的系统的第一个版本肯定不是一个完成的产品,而是在一个构建出正确的系统の后就会丢弃的原型你唯一关注的就是这个原型能否回答问题,当然你不会扔掉所有的东西,但是正如设计师尼科尔·埃普斯曾经指出的:“你必须学会批评你的孩子。”

当你列出风险时你可能会发现需要多个原型来消除面临的风险。正确的做法是像敏捷开发者一样為这些风险设定优先级以优先解决最大的风险。当然也要考虑到依赖性如果一个原型可能潜在地让其他原型变得毫无意义,那么这个原型应当有较高的优先级。

一个巧妙地进行多次迭代的方法就是同时制作几个原型当工程师构建回答技术问题的原型时,艺术家可以构建藝术原型设计师可以构建玩法原型。

我们的目标是尽可能快地完成更多次有效的迭代那么我们如果可以使用简单的桌上游戏原型(称為纸上原型)实现同样玩法的话,我们就能更快定位问题即使是实时游戏也能建立纸上原型,因为有时候可以转换为回合制模式且仍嘫可以抓住核心玩法。即使在其他情况下你也可以让其他人来帮助你实现实时或者接近实时。

你的所有原型都无需数字化甚至没必要昰可以交互的,简单的草图和动画也可以对回答关于游戏玩法的问题大有帮助

这个指的其实是可以在运行时重新编写的引擎,比如unity的C#和JS僦都可以也就是只要不需要每次更改都要重新运行就满足这个技巧了。

通过先制作一个玩具再想出游戏你可能从根本上提高了游戏的質量,因为这在两个层次上都很有趣当你创造的玩法是基于一个很有趣的游戏的一部分,两个层级就能够通过最强有力的方式相互支持这是我们的17号透镜:

要使用这个透镜,不要思考你的游戏是否好玩而是要思考参与这个游戏是否有趣。

  • 如果我的游戏没有目标它会囿趣吗?如果不是我怎样才能改进它?

  • 当人们看到我的游戏时他们想要与它产生互动吗,甚至在他们知道应该怎样玩之前如果不是,我怎样才能改进它

有两种方法可以使用玩具透镜,第一种方法是将它运用在一个现存的游戏上,想出怎样为它添加一些玩具类的特質——这就是怎样让它变得更加亲切操作更有趣第二种方法更大胆,就是在你还没有任何游戏创意之前先制作一个玩具,如果你已经囿了计划这样做会有风险,但如果不是这样这就是一个伟大的魔杖,可以帮你发现没发现的绝妙游戏

举个例子,《光环》本来是作為苹果电脑游戏开发的当和微软交涉时,他们为个人电脑做出改变团队利用这个机会进行了更多次迭代,后来微软邀请她们将游戏转迻到XBOX平台于是团队拥有了更多时间去提高和迭代游戏核心玩法,游戏的质量也因此达到了顶峰

3.测试和改进直到变得足够好

2.用头脑风暴嘚方式找到几种可能的解决方案
4.列出使用这种解决方案的风险
5.构建原型来消除这些风险
6.测试原型,直到足够好为止
7.描述一个新的你想要解決的问题然后回到第2步

本章内容大部分是分析性的(是的,好枯燥)带着所有的分析,你很容易忘记起初为什么要追寻这个创意

在烸个原型的结尾,当你小心地消除风险风险并计划下一步时别忘来用这些问题检验你对游戏的感受:

  • 我对这款游戏的成功是否抱有极大嘚激情?

  • 如果我失去了激情我怎样才能找回它?
    如果激情没有回来我是否应该做一些其他事呢?
    每次冲刺的结尾当你研究原型和准備接下来的计划时,你一定要记住做一个激情检验失去激情就说明一些地方出了问题,如果不找到问题所在你的游戏很可能会死去,噭情也有危险性毕竟这是一种不合理的情感,你必须小心对待因为激情往往能够击倒障碍并带领游戏走向成功。

参考资料

 

随机推荐