进行原型制作时,我如何能更轻松地探索游戏行为?


49

我自己创建独立游戏,但是一旦我将新开发的游戏开发到可以玩行为的水平时,我通常就精力不足,因此我选择精打细算而不是探索。结果很糟糕。

精炼与探索
(图片来自对讲博客

例如,我发现调整行为(即链接和重新启动C ++应用程序)的迭代周期很长,以至于它们扼杀了所有创造力。我正在建立一个工具来处理这个问题。

还有哪些其他方法可以快速探索游戏行为?我对独立开发人员以及大型公司使用的方法感兴趣。


1
那是一张非常漂亮的照片。这个从哪里来?
极好的

我认为您的工作被正式称为“单元测试”,尤其是如果您想一次调整游戏的一小部分。不幸的是,游戏很难真正进行单元测试,因为很难隔离组件并且很难自动进行测试(以便它可以决定通过/失败)。不过,阅读有关单元测试策略的信息可能会给您有用的想法。
极好的

5
@Superbest:我从内到外都知道单元测试,您无法将行为探索与单元测试进行比较。探索行为时,您需要加载大部分游戏引擎以及相关资产。仅当您知道要去的地方时,才进行单元测试。在这种情况下,没人知道。这就是为什么它是“探索”而不是“提炼”的原因。来自对讲博客的图片。
乔纳斯·比斯特罗姆(JonasByström),2015年

在“调试”模式下进行测试时,可以在暂停代码时更改代码(至少在Visual Studio中)。只要您不需要太多更改(函数标头等),就可以在短时间内将其加载到暂停的游戏中
Tobias B

@TobiasB:不幸的是,实际上我发现这没用。尤其是当您通常将游戏机制散布在脚本,已经实例化的游戏对象,资产等中时。我什至不确定免费的Visual Express是否支持它,实际上已经有14年没有使用它了!:)
乔纳斯·比斯特罗姆(JonasByström),2015年

Answers:


30

正如您已经指出的那样,当您在研究游戏机制时,迭代速度至关重要。从考虑修改到能够通过该修改进行测试之间的时间越长,您的工作效率就越低,而您的注意力也就越分散。结果,您肯定要管理迭代时间。

对我来说,当测试一个简单的更改的时间超过大约五秒钟时,我的工作效率确实开始下降。因此,当您尝试改善游戏的感觉时,您的目标之一就是要弄清楚“我如何进行更改,然后在不到五秒钟的时间内使用该更改进行游戏”。只要您可以将迭代时间保持在该水平左右,那么执行该操作实际上并不重要。

许多大型的现代引擎(Unity,Unreal等)通常通过将其编辑器放入游戏引擎来实现此目的,因此您可以实时进行大多数修改,而无需重新启动游戏。较小的引擎/游戏通常将工作重点放在另一个方向。使游戏如此快速地编译和启动,以至于每次更改都不必重新启动游戏都没关系;在这五秒钟之前,您仍然可以进行测试。

在我当前的项目中,我需要大约十秒钟来进行小的重新编译,链接,启动游戏,然后到达游戏状态(其中大多数是在加载保存的游戏时生成可渲染的世界几何图形)。这太长了。因此,我创建了单独的“测试”游戏模式,可以在不加载所有真实游戏资源的情况下测试游戏的不同部分,因此我可以更快地进出。通常大约需要两到三秒钟。如果我想测试一些UI,则无需加载到真实游戏中就可以做到。如果我想测试渲染,则可以使用另一种模式进行测试,而无需加载整个游戏系统。

我见过其他通过将游戏逻辑放入DLL中并让已经在内存中的游戏可执行文件在游戏运行时重新加载DLL来解决此问题的人,因此您可以重建DLL并仅将其重新加载到已经加载的可执行文件,因此您无需重新加载/重建游戏的美术资产。对我来说,这似乎很疯狂,但是我已经看到了。

比这要简单得多的是在脚本或数据文件中指定游戏行为和/或配置,并提供一种方法使系统可以按需重新加载这些文件,或者只是看着它们进行修改而无需关闭游戏关闭,重新链接,然后重新启动。

有很多方法。选择最适合您的东西。但是,成功完善游戏机制的关键之一是极其快速的迭代。如果您没有,那其他的事情也几乎没关系。


3
您能详细介绍一下“测试”游戏模式吗?每当您要迭代游戏时,是否为每个部分在每个地方创建游戏的一部分?您需要多少时间来设置“切片”?遗漏了什么,如何去做?对于这种类型的事物,您是否具有某种“保存游戏”和“加载游戏”功能,或者说它不太通用?
乔纳斯·比斯特罗姆(JonasByström),2015年

2
@JonasByström我不了解他,但是当我对自己的游戏状态有很好的控制时,我通常可以拥有IF DEBUG直接进入我的“测试”状态(跳过游戏菜单)的替代“调试”版本(通常是文字编译器指令)等),这是我当时正在测试的任何资产的基本内容。因此,我基本上会编译一个备用可执行文件,该可执行文件会自动加载非常精简的级别(要加载的资产较少,每次都不会浪费游戏菜单)。
极好的

@JonasByström我将游戏分为“模式”。它基本上只是一个大型状态机。因此,我通常将具有“标题屏幕”模式,“游戏中”模式,“信用滚动”模式等。它们就像可执行文件中的嵌入式游戏。我的“测试”模式是“ UITest”之类的东西,它将仅加载并绘制一个用户界面,而无需加载任何其他游戏内容。或“ RenderTest”,它将加载并绘制某些特定对象,而不加载其他任何对象。
Trevor Powell 2015年

@JonasByström当我需要创建新的测试模式时,通常需要花费几分钟的时间来编写代码,以设置我要测试的特定事物以及它可能具有的任何依赖关系。或者,我通常可以在几秒钟内适应现有的测试模式(例如,我通常会修改现有的UITest模式以加载不同的UI,而不是创建新的UI)。但是,建立多长时间实际上并不重要。关键是,一旦设置好,我就可以以惊人的速度进行迭代,这使我在迭代期间保持高效。
Trevor Powell

1
@JonasByström同样值得注意的是,“购买更快的计算机”也是“如何减少迭代时间的”完全合法的解决方案。与将您的时间花在实施特殊测试平台上相比,通常这可能是最便宜的解决方案。减少迭代时间是一项投资,您将大量时间/金钱/精力投入到了前期工作中,但这却为您带来了很多好处。
Trevor Powell

20

为使原型更好,请减少测试思路的成本。

我的工作流程已针对小型游戏进行了调整,但我发现这些事情会有所帮助:

  •  我发现对原型友好的技术对使用动态编程语言和框架很有帮助,例如LuaLÖVE适用于2D),JavaScriptLisp / Scheme,使程序执行某项操作所需的按键操作最少,即使这样做也要付出代价。其他的一切。一旦知道了您想要的内容并想要对其进行优化,就可以对其进行优化或移植到其他引擎。
  • 版本控制  将原型保存在受版本控制的存储库中。早期分支,经常分支。这样一来,您就可以轻松进行尝试,而不必担心会丢失或忘记某些东西。(Git具有最便宜的分支模型。)
  • 构建自动化  确保您需要做的很少,才能真正使事情开始运行。我认为,即使必须按一下按钮也太多了:我通常会有Makefile一个make watch目标,该目标inotifywait循环运行,通过自动编译/运行游戏对文件更改做出反应。用解释性或JIT编译的语言,这是即时的。

1
Lua似乎不支持热交换代码。这是否意味着您需要重新启动游戏/原型才能测试更改?
乔纳斯·比斯特罗姆(JonasByström),2015年

6
绝对可能会热交换Lua代码。
乔什

1
@JonasByström可能,但是只有在正确的环境下才可以。如果找不到一个,请编写一个,Lua的源代码是用C编写的,因此它可以移植到任何接受C样式函数调用的地方。将其与OpenGL,SDL 2或其他图形/硬件包装库混合在一起,并构建自己的热交换IDE。
法拉普2015年


2
@JonasByström:...显然除了回到月球。:(
梅森·惠勒

11

作为主要专注于原型制作的开发人员,以下是我的一些经验建议。

  1. 使用允许您快速进行更改的引擎。这包括诸如“不等待编译”,而是“方便调试”,还“在运行时更改的事情”等我个人喜欢Unity3D,但它不是“测试资产的可用性” 最好的工具在那里。最佳工具取决于游戏:例如,虚幻引擎的编译方式比Unity3D慢,但是它可以快速启动多个连接的客户端。对于网络游戏,这通常可以抵消编译成本。还考虑熟悉度。如果您是C ++的专家,那么即使最好的Javascript引擎也做不了什么,反之亦然。不要花时间与陌生的技术作斗争(我的意思是,一定要学习其他语言/框架,但不要与制作重要的原型同时进行)。
  2. 学会毫不留情地废弃现有功能。紧紧抓住已经实现的东西是成功进行原型设计的厌恶之地,但是放手工作却很难。
  3. 如果您不与游戏设计师合作,请在“戴程序员的帽子”和“戴设计师的帽子”之间划清界线。添加一个很酷的新游戏功能似乎很诱人,但是当您处于设计师位置时,要这样做。而是尝试根据自己的情况创建有趣的游戏玩法(最好是多个变体);列出有助于使用的功能,然后实施(某些)功能。
  4. 快速原型制作涉及两个对立面之间的平衡。您想要尽快完成任务,因此编写了错误的代码。但是您想尽可能多地更改内容,因此您必须编写良好的代码!学会平衡两者。抱歉,对于如何实际执行此操作,我想不出任何具体建议,但至少要注意这个问题(-8

查看您的原型需要多少时间。以我的经验,您希望两天之内拥有所有版本的可播放版本-从头开始;并且您想每天测试一两个新功能。如果您没有达到这些目标,请寻找更快的方法。


我认为功能不同于行为探索。我想探索“感觉”。功能对我来说更像是美丽的渲染:不是必需的,也不与游戏的有趣程度相关。Minecraft,Candy Crush,Tetris和类似游戏证明了恕我直言。
乔纳斯·比斯特罗姆(JonasByström),2015年

@JonasByström要说明的是:这里的“功能”是指对游戏玩法进行必要的更改。也就是说,在制作Minecraft原型时,它不是特别漂亮的渲染,而是“添加一种制作块的方法”或“添加攻击并杀死玩家的小怪”之类的东西。
没关系

1
第二点的重要性,即“放手去做”,这一点不能夸大。许多探索阶段之所以失败,是因为没有对需要花2周时间才能实施的失败功能说“不”。
Kostas

关于第4点的注释。我认为关键是要了解快速更改代码所需要的内容。确保公开您知道要调整的值。如果您知道其他代码对游戏玩法的影响不大,请将其掩埋,并在以后需要时公开它们。您必须快速解决这个问题,但是如果您可以尝试从一开始就设计架构,以使“游戏设计”的内容是面向正面的,并且在可能的情况下保持干净,则其余内容可能会很杂乱。
sydan 2015年

1
@sydan不幸的事实是,您对“前置”代码的想法是错误的。我的意思是,它总是表明您虽然不应该更改的东西实际上是非常动态的事情。进行原型制作时,您最好准备好从各个方面进行更改,并迅速进行操作。
没关系

5

可以将游戏开发分为以下四个阶段:

  • 原型制作
  • 游戏玩法改进
  • 发展
  • 性能细化

我认为游戏性探索主要发生在原型开发阶段,以下是我尝试遵循的一些建议:

  • 从纸质原型开始设计。在清楚地知道游戏可能是什么之后,开始对其进行编码,以便您可以真正感受到互动。也许这对3D游戏没有用,但在过去对我个人有很大帮助。

  • 知道您将在完成后扔掉代码的代码。在选择哪种游戏引擎时,这将使您放心。

  • 快速迭代周期很重要(正如其他人之前指出的那样)。根据游戏引擎的功能来快速向您显示编码内容,从而选择游戏引擎。在此阶段,您也不必关心性能或图形保真度。

  • 限制范围。如果实际的游戏方式是2D(通常为策略游戏,JRPG),则以2D原型。在此阶段,您只关心游戏玩法的反馈。

  • 不要浪费时间进行抛光或搜索资产。在纸上涂鸦,拍摄照片,在Photoshop中进行切割,也许对其进行着色,然后将其用作精灵。打开麦克风,说“ pew pew”。将两个立方体和一个球体放在一起,您将拥有一个机器人。始终牢记,探索游戏可能性是您的头等也是唯一的优先事项。

在确定好玩的原型后,开始完善它。我认为没有理由切换技术,除非有游戏元素需要它。

在开发的后期,您将手握精致的原型,同时开发新的,外观更好,听起来更好,感觉更好的游戏。在这里,您必须选择要使用的实际游戏引擎。

最后,利用现有资源并对其进行调整以使用更少的资源。

我上面所描述的大多数知识都是常识,但将其列出来,将整个开发过程分隔开来,有助于我从各个角度着眼。希望对您有帮助。


1
纸皮照片和“皮尤皮”是极好的建议;是的-列表也对我有帮助。“确定您的三大优先事项。丢掉第二和第三。” :)
乔纳斯·比斯特罗姆(JonasByström),2015年

4

我同意Trevor Powell的回答,即迭代的速度对于您保持创造性的情绪而不是仅仅进行抛光至关重要。布雷特·维克托(Bret Victor)的演讲“原则上的发明”对我来说是一个很大的灵感来源。不幸的是,很难在该级别上找到真正的工具。我尝试构建自己的Python开发工具,以便在键入代码时运行Python代码。在Python中称为实时编码


1
我以前看过vid,但是却忘了。嗯 即时互动确实是要争取的东西;我会根据您的建议采取行动。有趣的Live Coding插件不错!
乔纳斯·拜斯特伦(JonasByström)

2

我建立了一个称为Trabant的原型工具,该工具:

  • 是3D和游戏机制的用户(没有用户界面,没有文本,什么也没有);
  • 需要非常少的代码,并没有资产建立一个原型;
  • 使用ASCII艺术代码创建3D模型;
  • 允许亚秒级迭代;
  • 有刚体仿真支持;
  • 适用于Windows,Mac,Linux和iOS;
  • 使用众所周知的通用语言Python;
  • 具有适用于Windows和iOS的IDE。

我在其中构建了30个测试原型以验证以上内容。

正如Trevor Powell 强调的那样,迭代时间必须小于5秒,而我发现小于1s的迭代几乎是其5倍。:)

Anko 提到使用动态语言是个好主意,因此我选择了Python,因为它是使用广泛的语言之一。关于构建自动化,在Trabant中进行测试就像在IDE中按F5一样快(或者在iPad上按F6对其进行测试),并且由于不涉及构建步骤,因此没有比这更即时的了。

扔掉代码是Nevermind的 要点之一。我完全同意,Trabant强制执行。


1

除了非常重要的Trevor Powell的迭代速度外,还有其他一些有用的注意事项:

就像好的代码...

那里有很多中频。

概念越扎实,您就不需要花太多时间。如果您知道自己想做的是什么,那么原型制作就变成了-放置什么以及如何相对于中心支柱(您的主要物件)进行布置。

如果您像许多其他人一样起步-不太确定要做什么,那么您会朝一个方向前进,并以显示的图像的方式进行探索。

如果可以在没有太多深度的情况下模拟正在寻找的东西,则对技术的承诺都是不相关的-在您想要的/可以的任何东西上进行原型设计。

不要浪费一秒钟的资源。从互联网上下载所有内容。是否专有。您希望能在工作中感觉到自己的概念-除非图形是您的主要功能,否则没人会起诉您尝试他人的声音,纹理和其他任何东西,您还没有将其放在商店的货架上。除非您已经获得资金-要说服人们,否则这个概念是值得的,它将使您获得金钱以获得所需的资源。我见过游戏工作室的人们用无权获得的专有游戏的改进版本介绍游戏概念。

就像您正在构建比例模型一样。拥有您想要的微型生活副本真是棒极了。有时,它足以将其从杂志上剪下来,手工制作并将各部分粘合在一起。充满想象力的每个人都不会假设您实际上将使用显示比例模型的纸板来建造摩天大楼。在创意产业中,与具有想象力的人一起工作更可取。如果他们无法克服一些草案问题,看不到整个概念背后的潜力,那么他们很少会欣赏产品。没有升值意味着他们不愿意承诺,那就是下降螺旋。区别在于树立孩子征服世界的态度,而不是说“小小的脏话甚至连鞋子都不能系好,

无论您做什么,都要记住,无论技术或经济潜力如何,仅凭态度就足以彻底摧毁一切。

我曾经使用独家的gif图像制作游戏原型,并为它们提供了一些与javascript有关的功能。它不刺眼,但可以达到显示我想要显示的目的。以后是否专门为Xbox开发它都没关系。

如果您的想法比简单的原型要复杂,那么您将不得不对将要使用的技术进行研究-因为原型将最终被用作脚手架(原因很简单,因为在它,并且不能轻易丢弃)-如果您明显批准了它。


仅当您要构建新东西时才需要原型。缺少工具就像缺少纸和笔不放-确保您可以在沙子上画图,但是效率低下。我构建Trabant的目的是避免去GIF + JS或Scratch
乔纳斯·比斯特罗姆(JonasByström)2016年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.