视保屏厂家
免费服务热线

Free service

hotline

010-00000000
视保屏厂家
热门搜索:
技术资讯
当前位置:首页 > 技术资讯

解析游戏迭代开发的概念及工作流程

发布时间:2020-02-11 06:17:07 阅读: 来源:视保屏厂家

在过去几年里,我至少看过3个让人印象深刻的迭代过程解释,并且大多数都太过复杂而难以落实行动。直到我阅读了Jesse Schell对于该过程的描述,我才开始相信自己最终能够理解它,不过当我真正尝试着将其应用到项目中时,我却觉得这并不适合自己。我尝试着在不同媒体中进行设计,但出于各种原因,我并不能将平常的设计观点带到长期游戏项目上。

当我越深入探索这一问题时,我越发意识到自己对于这一过程理解的浅薄。我学习了许多有关这一过程的表面细节,使用方法以及为何它能发挥作用等。但是我却并不能真正理解为何这一过程是基于这种方法进行设计,或者我们该如何在某些环节出现问题时纠正它。

我最终尝试着设计了一个适合自己的全新开发过程而回答了这些问题。我尝试着创造新方法,所以我并不惊讶自己能够到达理想中的迭代开发过程。而在这个过程中,我也终于搞清楚为什么这一过程是有效的。所以我决定将这一实践当成本篇文章的前提,而结果便是专注于设计(而非使用方法)去教授开发过程的指南。换句话说,这是关于我在开始这一项目前所阅读的指南般的内容。

iterative-process(from spiffygoats)

介绍开发过程

我认为关于开发过程的大多数讨论似乎都被定职位一种业务或科学观点,即让人们感到困惑不已。而我反倒对这一话题的实践性更感兴趣,并且我想侧重于你是如何将这一知识与自己的工作整合在一起。

如果你不知道如何观察自己的工作流程的话,你便很难去思考开发过程。当你能够更清楚自己是如何实践以及如何解决问题,你便可以在实践过程中完善效率与效能了。更重要的是,你可以开始学习如何使用全新工作流程,并学习如何使用新工具。

你应该很熟悉这一工作流程或过程,因为这是大多数人在第一次尝试创造游戏时所面对的“默认”过程:

1.决定你想要做什么(设计),

2.明确如何做(计划),

3.实践并完成(执行)。

许多业余游戏项目经常会出错的一环在于,人们总是希望自己的付出能够具有成效,所以他们会飞速完成前两个步骤而尽可能快速进入执行阶段,可能对于他们来说这才是“真正的”工作。但是这一常见的问题只会让开发者感到分心,因为在一开始你可能根本就不会使用到这一过程。这一特殊过程便是“瀑布模式”,这在软件工程世界中非常有名。

尽管这看起来是一种直观的执行计划,但是“瀑布模式”似乎并不能有效支持大型项目。大型项目总是要求更多设计和计划,而这些过程将阻碍真正的设计工作。你可以在执行后再完善设计过程,而当你预先设计了所有内容后,你便需要创造出上百种有关怎样的设置可行的假设。当你开始进行假设时,你便不能再设计游戏了,你只能对此进行幻想。

有些人通过在最后添加一些额外的步骤(注:从而挪出一些时间去修改执行阶段中所遗留下来的问题)而修改瀑布模式。但这么做却是徒劳,因为它根本不可能解决这一设计过程中的内在结构问题。为了真正解决这一问题,我们需要设计出全新的过程。

设计过程

糟糕的工作流程有可能无形地摧毁一个项目。而设计这些过程的前景也实在让人堪忧。幸运的是,我们只对这一讨论的实践面感兴趣,所以我们无需过多担忧在描述过程中所体现的精确性。这也是为何我们的“瀑布模式”过程描述与你在维基百科上找到的内容不一致的原因。

如果我们将设计一个全新过程,我们就需要先明确该过程需要具有怎样的核心特征。首先我们需要解决“瀑布模式”所具有的最大缺陷,并鼓励人们采取有帮助的设计视角。接下来我们必须根据开发游戏所需要的时间和资源而确保该过程是现实的。最后,这一新过程必须能够与“瀑布模式”的直觉性和吸引力相抗衡,否则它便会因为拥有过多需要遵循的规则而让你迷失自我。

“瀑布模式”之所以如此吸引人是因为其整个过程可以概括为一个简单的步骤:

1.在最终完成前一直致力于其中。

尽管这一模式非常模糊,但这却是人们在选择“瀑布模式”时所经历的思维过程。你可以将这一描述当成剩下过程所围绕的“主题”,因为过程的每一部分都是直接源自这一基本计划。

该主题的简单性是推动这一过程无形化的主要原因。我们之所以希望工作流程是无形的是因为,如果不这么做,它就会变成工作中的一个组成部分。就像面对一个精心设计的用户界面,如果我们能够使用一个简单的开发过程,那便无需多花时间进行思考了。如果你之前曾经面临过较复杂的过程,你便会知道即使在非常时期也很难回到简单的过程中了。这是我在实习过程中频繁遇到的情况,尽管我对自己遵循的过程充满信心。

所以现在我们知道需要围绕一个简单且直接的主题去设计全新过程。因为主题可能与我们的目标相关,所以在接下来的内容中我将侧重对于典型设计师工作流程的理解。

迭代循环

当你致力于任何以设计为导向的专业中,不管是视觉图像,音乐,电影,写作等等,你都会发现这一工作流程通常会简化成两个简单的步骤:

1.执行你的理念,

2.评估你的理念,然后回到步骤1中。

这两个步骤的过程便是迭代循环(注:不能与“迭代开发过程”相混淆,后者是针对于软件开发)。对于任何特定项目,设计师在创造出最后作品前都需要多次经历这种循环。每一次循环都称为一种迭代,而当你完成更多迭代时,最终作品将会越完善。

这与我们在学校中学习写散文时,老师会要求我们多打几份草稿再开始写文章是一个道理。在这个阶段你已经学会如何写文章了(第1步),但是你还必须学会找出文章中的缺陷(第2步),并想出如何修改这些缺陷(回到第1步)。

但是我们并不一定总是要遵循着这一迭代过程。举个例子来说吧,如果你正在写一篇散文,你可能只需要阅读自己写下的一个段落,然后只需要移动其中的几行内容。每次当你执行这样的动态编辑后,你只需要完成另一个迭代便可,而这通常不会超过1分钟。

直到你精通了第2个步骤(注:即掌握了客观评估并批评自己的设计的能力)后,你才能真正的像一名设计师那样思考。大多数充满抱负的设计师似乎更希望在创造游戏后再做出所有创造性决定,所以他们的工作往往充满不确定性与各种假设,就像是他们都认为所有人在最后都会喜欢上自己的游戏。但是较为严格的设计师便会更加谨慎。因为他们有寻找自己创作缺陷的习惯,所以他们会花很多时间去思考最终作品会出现什么差错,从而让自己可以在问题真正出现前做好应对准备。

这也是为何迭代循环有时候会被描述为降低风险的过程。基于这种描述,之前的两个步骤将出现颠倒:

1.找到设计中的潜在风险(评估),

2.尝试着缓解风险,然后回到步骤1(执行)。

这一描述比之前的描述更加广泛。因为最初的描述将自己局限在游戏中,而最新的描述更明确地考虑到了可能影响游戏的外部元素。

举个例子来说吧,在对于迭代循环的首次描述后,设计师将问如下问题:“这一小小的改变是否会影响游戏感受?”或者“这种程度是否像我所期待的那般有趣?”而基于新描述,现在的设计师也许会问:“玩家是否会觉得这一机制太过困惑?”“我们是否具有合适的技术能够运行这一功能?”,甚至“我们是否能够保证在六个月内发行商并不会遭遇破产的危机?”这些风险都将影响着游戏设计,因为在游戏设计中的任何一个点上你都能够进行创造。

有些人认为这种设计观点太过压抑,因为它意味着你总是着眼于糟糕的一面。但事实上,这种观点所创造的主要情感是客观的,而非悲观。基于同样的方式,科学家将支持大量的怀疑论去更好地理解世界,设计师则必须基于现实,否则他们便不可能真正面对游戏并不有趣的真相。换句话说,比起逃跑,如果你真的在积极寻找的话,你便能够更容易去接受那些让人不快的信息。

迭代游戏开发

如果能将迭代循环无缝地应用于游戏开发中自然再好不过了,但不幸的是我们面前摆着一个巨大的难题。就像我之前所提到的,你只能在执行设计后才能对其进行评估,但是对于那些未能遵循迭代循环的游戏,你便需要投入更多精力去执行它。如果你不够小心的话,你便有可能只是浪费大量的时间和资源去落实一次的迭代——这时候的你就像是在遵循“瀑布模式”似的。

也许唯一的解决方法便是节俭地对待迭代循环的使用。比起理所当然地进行每次迭代,设计师必须尝试着压缩每次迭代的费用并提升其价值。

iterative rapid prototyping(from gamedesignconcepts)

这便推动了快速原型理念的形成。举个例子来说吧,你想知道的便是一个特定的机制系统是否有趣,然后你便可以尽快创造出该系统的粗糙原型。编程是测试设计最缓慢的方法,所以“纸上原型”便成为了设计师创建系统模型的最常见方法。

那些熟悉游戏经典创造方法的读者也许会注意到,这开始有点像是迭代开发过程了。这是否意味着我们已经到达了设计导向型游戏开发工作流程的问题了?到达这一点的方法能够提供一个我们一直在寻找的完美主题,即以单步骤过程呈现出来:

1.遵循通常设计过程,但却不会将迭代当成理所当然的事。

迭代开发过程是否真的这么简单?尽管从表面上看来这是个很大的发现,但是将它带进你的工作流程中才是实现该过程的关键。比起有意识地思考如何才能有效地遵循过程,你应该在自然且直观地遵循过程的同时专注于工作中。

还有很多方法能够将这一主题划分成更具体的步骤系列,你将找到最适合自己的一种方法。但因为我们正在强调迭代的不足,所以我们关于迭代循环的第二种描述是:

1.找到一些最重要的风险并去缓解它们(评估),

2.明确缓解这些风险的最快速方法(计划),

3.落实行动,然后回到步骤1(执行)。

你也许会注意到这就是迭代循环,但在中间带有一个额外的步骤能够提醒我们不要浪费时间。为了确保我们能够按照适当的顺序解决设计问题,第1个步骤得到了修改。举个例子来说,你肯定不希望自己花许多时间为一个功能创造纸上原型,但是最后却发现在下一次迭代中这一功能太不现实而不能有效地在代码中执行。这是一个很容易犯的错,特别是当你因为一些极具吸引力的次优设计问题而分心时。

关于如何有效管理迭代还有许多需要学习的地方,但是最重要的还是你需要确保每个迭代都具有合适的理由。如果你曾经发现自己是因为“应该”这么做而创造原型的,那么这种迭代便具有误导性并会浪费你的时间。所有迭代都必须受到合理的好奇形式的启发,而不是基于过程本身。

深圳代理记账公司

中山代理记账公司排名

广州工商税务变更