游戏邦在:
杂志专栏:
gamerboom.com订阅到鲜果订阅到抓虾google reader订阅到有道订阅到QQ邮箱订阅到帮看

游戏设计课程之初步设计及制作原型(4)

发布时间:2011-11-06 01:30:09 Tags:,,,

作者:Ian Schreiber

我们在设计游戏时,很大一分部工作,把一大堆元素捆在一起,一款游戏就出炉了。用这种方法制作出来的游戏如果成功了,也只能说是瞎猫碰上死耗子。

那么对于风险比较高的大项目怎么办?为了做出一款好游戏,有没有什么步骤可走?当然有,就是重复地经历一系列的设计、测试、评估,但是我不想在这里剖析每一个重复的步骤。如何提出初步设计?测试的最有效方法是什么?游戏评估评的是什么以及怎么知道要修改什么?请各位读者继续往下看,答案自然提晓。

在本文,我们要学习的就是:初步设计。(请点击此处阅读本系列第1第2第3、第5第6、第7、第8第9、第10第11第12第13、第14、第15、第16、第17第18课程内容

game prototyping(from guardian.co.uk)

game prototyping(from guardian.co.uk)

限制条件

很多时候,我们会发现天马行空地想像一番之后,设计游戏时却无从下手。这时候,添加一些限制条件也许会让难题不那么棘手。这好像跟我们的解题思维背道而驰了——原来的问题都解决不了了,再加限制条件不是雪上加霜?道路已经够曲折了,还添堵?未必,至少设计游戏时不总是这样。

为了便于理解,我们可以把游戏设计当作一个在游戏中依次叠加限制条件的过程。你每增加一条新的规则、定义一种新资源,对玩家来说都是增加了一个限制条件。在游戏设计的开头,你什么规则也没有,而玩家什么都能做;到了结尾,各种各样的限制条件根据“有趣”的方式来定义玩家的体验。

现在你不妨思考一下电子游戏中所谓的“开放世界”是什么。玩家的一般反应就是,游戏充许你做任何事,给予玩家完全的自由,这也是乐趣所在。然而,严格地说,游戏并没有给予玩家彻底的自由。玩家实际上受到储多约束:玩家的移动必然遵循一定的方式,能与玩家发生互动的必然有确定的对象,自行移动对象必然受某种计算机算法控制。玩家有多种选择和相对开放的目标,但可以肯定的是,确实存在许多让玩家产生“无拘无束、随心所欲”这种错觉的限制条件。

如果你认同这种解释——游戏设计就是创造限制条件,那么你可以看看外界施加的限制条件是否可以辅助初步设计。通过添加限制条件,要做的设计工作就没那么多了。这就解释了我刚才提出来的悖论。

限制条件还可以为你的创意提供依附点。如果我只想着做游戏而不考虑限制条件,那么许多人都会傻坐着像只无头苍蝇,不知所往。而通过添加限制条件(如“第一次世界大战”),这个问题就不再是“要做什么”了,而是“根据这个主题我能做什么”。后者显然比前者更容易回答。

事实上,现实的设计大多数与限制条件有关:比如,发行商要求游戏采用某个原创主题或设某种类型或在某个时间/预算内完成。我提这个的原因之一是,要提醒你这些限制条件虽然看起来很可笑(“我得以‘我的小马’概念为基础做一款DS游戏?”),但实际上限制条件常常能让设计师的日子好过得多。

我提这个的另一个原因是,你的生命当中很少有不受来自他人的限制的时候(特别是“独立”游戏开发者和业余设计师),如果你的工作起步有困难,出路之一就是给自己添加一些限制条件。比如,给自己一个时间限制(游戏邦注:例如“Game Jam”大赛一般要求参与者在24小时或48小时内制作一款游戏);选择一个自己有兴趣的题材作为游戏的主题;挑选一个你喜欢的核心机制进行开发。这完全是随意的,但如果你不知道你的游戏该往哪个方向走,坚持下去,选择一个额外的限制条件让自己前进。(重复再重复,之后你总是能够排除那些武断的限制条件,如果你发现所选的条件阻碍了游戏设计的话。)

创意生成

设计的第一步,你必须想出一个基本的游戏创意。不一定要完全成形的,但至少要有一个基本的概念。以下我无顺序地列举了几种创意生成的方式:

体验法。你想让玩家有什么感觉?你想让玩家有什么反应?游戏体验应该是怎么样的?从玩家体验的角度出发,构想一套能达到期望美学的规则。想一想你自己玩游戏时的最好体验,即什么游戏规则能带来那种体验?

规则法(系统法)。从你在日常生活中观察到的规则或系统出发,特别是那些需要人们做出有趣的决定的。观察你周围的世界,思考一下什么系统能做成好游戏?

改良法。从现存的、确定的设计出发,然后将其调整提升(“模仿-加工-生成”)。这种方法常用于制作游戏续篇。什么游戏你认为有潜力,但价值还没完全发挥出来,你要怎么改良它?

技术法。从技术,如新游戏引擎(电子游戏)或特别的游戏部件(如角色可旋转的基部)出发,将其运用于你自己的游戏中。你生活的地方有什么东西还没出现在游戏中,但可以添加到游戏中?

拾遗法。从其他资源中搜集材料,如其他游戏还没用上的艺术作品或游戏机制。利用这些设计一款游戏。你有没有美术文件夹或者早期游戏设计时用到但最终没有做出成品的材料?大众化的作品,比如文艺复兴时期的作品怎么样?围绕这些材料你怎么设计游戏?

剧情法。从游戏的剧情出发,然后找到匹配的规则,做成一款剧情导向型的游戏。什么类型的故事适合做成游戏?

市场研究法。从市场研究出发:你可能知道某类人群还没被开发,可以针对这类人群设计游戏;或者你只知道当前某个主题很热门,且某段时间内不会有太多的游戏出来填补市场,这就是个时机。你怎么把这个信息转化为可玩的游戏?

将以上方法组合使用。比如,从核心美学和剧情出发,你可以制作出一款兼顾剧情和玩法的综合型游戏。

当你想到新的游戏创意时,你的起点是什么?

其他创意生成的方法

如果你遇到了设计瓶颈,你可以找到许多应对的策略,以下列举了一些:

收集法。将你的所有关于游戏、机制、剧情等等想法收集成册。时不时的浏览一下,看看有没有什么“老菜”可以拿出来“新炒”。每当你想到暂时用不上的创意,就把它记录下来。

随意思物法。随便想到什么东西,想方设法把它安到游戏中去。

温故知新法。从更深的层面上去研究当前的游戏,你可能就会想到新的点子了。

基础法。思考游戏中的正规元素。比如,玩家的目标是什么?规则?资源?等等。注意,为了创造游戏,无论怎样都要明确定义这些东西,所以集中注意力思考这些东西,你可能会发现新的问题。

brainstorm(from blog.lib.umn.edu)

brainstorm(from blog.lib.umn.edu)

头脑风暴法。你可以一个人做,也可以和一帮人一起做。有些人非常信奉这个方法,有些人却很质疑其产生的结果。我能说的就是,结果是不可测的,但这确实是种研究与开发的方式。

纠错法。批判地看待你的游戏。你可能有一本笔记本记录了其他设计师(包括我)多年的心得体会,但你也需要写一本自己东西(无论你是不是要拿去出版,总之记下先)。当你发现有些东西不太管用,并且你认为你可以识别其根源,那么就把引发问题的原因当作设计法则(或至少是指导)记录下来。如果你不知道根源,也还是记下来吧,定期地看看,没准就让你找到答案了。

玩游戏法。玩很多游戏!不过,要带着研究的目的玩游戏,而不要像普通玩家那样,为了娱乐而玩游戏。另外,批判地玩游戏。问自己该游戏的设计做了什么选择,为什么,是否有效。尝试你不喜欢或从来没玩过的游戏类型,找出其他人觉得好玩的原因。再者,已经发布的游戏指南也值得一读,那些基本上就是一份完备的设计文件了,所有游戏机制的细节一目了然!

最后,勤加练习,熟能生巧。在自己的项目中好好干。你制作的游戏越多,你就越会制作……其他艺术也是如此。

原型制作

记住,你的想法重复构想得越多次,最终的游戏就越好。一旦你有了基本想法,下一步就是尽快将其转化为尽可能廉价的可玩模型。这么做可以为测试和返工节省下大量时间。

对于存在高设计风险的部分,重做是最关键的环节。“模仿-加工-生成”类的游戏大多是从已经存在了的游戏中的玩法提炼出来的,所以快速原型就不是那么重要了。这不意味着“克隆”来的游戏就不必重做了,而是你应该有选择性地把创意过的部分拿出来重做。为了应对当下的挑战,牢记于心吧。

原型制作的“法则”

请记住制作原型的目的是最大化迭代循环次数。推论:尽量减少每次重做所需的时间。现在,考虑一下各个重复循环一般包含的四个步骤:设计、原型、测试和评估。这四个步骤,哪一步能节省时间?

设计游戏的规则时,如果不折中你的目标,确实省不下时间,因为匆匆忙忙是出不了好创意的。

通过制定高效的时间表和设计测试(游戏邦注:即在最短的时间内给出最多的信息)可以减少花在游戏测试上的时间。但仍然有一个固有的限制,在某个时间点上,你就是得花这么多时间来测试游戏,不能再仓促了。评估倒是用不了太久,你只是根据测试结果,简单地回答是否来决定游戏好不好。所以也不可能从中挤出什么时间了。

所以,节省时间的重任就落到原型制作这个步骤上了。

当你制作可玩的原型时,请记住以下几点:

能快则快。怎么快怎么来。只要省钱省事,丑点没关系。

删繁就简。只做评估游戏必须具备的部分。如果你打算测试新的战斗系统,那么你不需要制作出整个探测系统。如果你在制作卡片游戏,徒手在卡片上完成就好,没必要输入到PPT上、打印在硬纸片上然后手把手地剪下来。精工细活另安排时间去做,游戏设计的早期阶段就没必要在这上面耗了。

容易调整。你做测试时,会发现不少问题,所以你得保证原型容易调整。

以上原则把设计师推向了一个不可避免的方向……

纸上原型

你可以叫这个东西“纸张”、“纸板”或“非数码”或“模拟”等等,随便你怎么称呼,反正就是要有一个有实物的、摆到桌面上、不用电脑(或至少不需要代码)也能玩的游戏。编程很好很强大,但与纸上原型相比,太慢太贵。纸上原型具有以下优点:

划算。大多数系统只要一支笔加几张纸就能完成了,当然,后面我会告诉你该花的钱花到什么地方去了。

省时。你不需要在编程、布局或美术设计上浪费时间。只要在碎纸片上写个把字就够了。

容易修改。不喜欢某个数字?擦了另写一个。

丢掉不心疼。结果你的想法用不了?好吧,浪费了半小时。了不起,就像画打草稿:如果第一次画的不太好,浪费掉的只是那几秒钟,涂掉重来。

普适性。纸上原型基本上可以模拟所有系统,甚至是那些我们一般认为与只针对电子游戏的系统。

通过制作一些可玩的原型,你必须切实地设计出系统。你不能只是想“这个游戏包含50张不确定的卡片”。你必须像个游戏设计师那样真正地去设计游戏!

纸上原型的缺陷

纸上原型存在一些你必须意识到的缺陷:

不能应对以敏捷或时间为基础的系统……虽然我们知道有许多以敏捷为基础的非数字化的游戏。想一想《街霸》系列电子游戏和James Ernest的实时卡片战争游戏《Brawl》之间的相似和差异。有些能在纸上模拟得很好,有些就不同了。

street-fighter-4(from yuwings.org)

street-fighter-4(from yuwings.org)

有些信息对玩家隐藏,但仍需要记录在案,如在RTS游戏中非常流行的“战争之雾”机制。另外,注意,这个有时候也是能解决的——经典儿童《战舰》游戏也有仿“战争之雾”机制的,桌面游戏《Clue》也有信息对所有玩家隐藏。

极端复杂的算法要在纸上完成就太沉闷了,那种系统还是丢给Excel这种软件去制作“原型”吧。如果复杂的系统是游戏的必须及核心部分,这意味着“电脑玩得比玩家还开心”(引用Sid Meier之语),也许有必要对游戏进行简化处理了。

“华而不实”等高质量的美术和动画显然不能靠简笔画和手写卡就给原型化。而且,这些也不是游戏机制的一部分。发果你的游戏更依赖视觉效果而不是系统,这意味着你不是一个合格的系统设计师。

纸上原型不适用于测试电子游戏的UI。计算机UI是动态的,但纸是静态的。你可以从纸上草稿看出一点视觉设计的意思,但要知道电脑上的实际效果如何,你需要制作数字化原型。

如你所见,纸上原型的优势是很普遍的,而其缺点却是特定的,所以每个设计师都应该掌握纸上原型的技巧,无论他们是制作电子游戏还是桌面游戏。

非数码设计师的原型工具

以下是我个人觉得很有用的原型制作材料。当然其他设计师可能也有自己最喜欢的材料,所以不可避免有人会对我的清单有异议。

各个品种的纸:白纸、线条纸和网格纸。这些特别适合一般的笔记和速成游戏面板或其他表面。

彩色画笔和铅笔。显然你需要一些能涂写的东西。颜色可以很好地区分各个游戏元素,或注释游戏组件。

索引卡片(3*5)。这些用来制作卡片,很适合混合。你可以把卡片对半开也可以三等分,做成不同大小的卡片。你也可以只是在卡片上写下想法,然后贴到墙上,便于你边看边整理思路。这些纸片通用又便宜。

剪刀和胶带。这些是用来剪东西和粘东西的,对设计师的重要性,好比WD-40润滑油和管道胶带对水管工的重要性。

曲别针和/或长尾夹。这些可以把相关的材料固定在一起。例如,如果你做了好几份卡片,用这些曲别针或长尾夹就可以把相关的纸片夹在一起,不会和不同类的混起来(更惨的是和不同的原型卡片混起来)。

不同颜色的玻璃珠。这些可以作标志物、计数器和游戏部件。

各种类型的骰子(4、6、8、12和20边的)。各个型号的都准备几个,颜色要不同。这些用来产生独立随机数。注意,骰子也可以当作游戏的部件,比如代表“石头”,数字是几就代表有多少值——如6面骰子代表一个有6点攻击力的战士。

一小袋不值钱的硬币(请原谅我不知道其他国家的硬币面值是多少)。硬币可以作标记,可以产生随机变量,因为有两面,所以可以代表两种状态(游戏邦注:如各代表两个控制硬币的玩家)。另外,硬币比骰子和玻璃珠更好堆放。

便利贴(from 3lian)

便利贴(from 3lian)

有色便利贴(小圆不干胶贴)。你可以把这些贴在石头、骰子或硬币作标记、装饰。你可以在上面记录必要的信息。

一本专门用来记录原型和测试的笔记本。这个东西要保存好,切不可丢失!

以上物品哪里找?这个要看你住在什么地方。除了骰子、玻璃珠和硬币,大多数东西可在办公用品店里找到。找硬币,请往银行走;骰子,一般的玩具店或漫画书店有售或网上购买;玻璃珠,玩具店里可能有卖,不过通常是当作装饰品或工艺品。很多游戏套装里有玻璃珠,如果你能找到一款带玻璃珠的游戏,那就便宜了。

工艺品店和玩具店,无论是零售店还是网店,都可以给游戏设计师带来不错的灵感谢。我曾发现大量没上漆色的木质小方块(真是极佳的标记物和自定义骰子)和木质盘(质感好,比硬币大)。有次,我找到一套木质小方片,大约有1英寸,还有一些木质胡萝卜;我不知道我拿这些东西做什么,但总有一天会派上用场吧。我还发现有店面出售木质小人和各种尺寸的铺砖。这些东西可能一时半会儿用不上,但项目开发到后期,肯定会有用。

你的第一个纸上原型

以下是一款经典儿童战争游戏的规则:

玩家:2

目标:先于对方打沉对方舰队的5艘潜艇。

设置:双方玩家各有一个10*10的网格面板,各行标有从1到10的数字,名列标有A到J的字母。玩家各有5艘潜艇:2个方格长的一艘,3个方格长的二艘,4个方格长的一艘,5个方格长的一艘。玩家将自己的潜艇暗藏在自己的网格下,各艘潜艇可上下左右移动。一名玩家先移动。

游戏过程:轮到顺序的玩家叫一个方格的坐标(如B5或H10)。如果该坐标上没有任何敌方的潜艇占领,那么敌方玩家就说“没中”;否则,就说“命中”。另外,如果该方格被“命中”且该方格上的潜艇的所有“舱位”(即潜艇的方格长)都被击中,则该潜艇“沉没”,敌方玩家必须告诉对方哪只潜艇“沉没”。无论是否命中,叫方格的顺序轮给另一方。

结果:当一名玩家击沉对方的所有潜艇,即获胜。玩具店一般有卖这个游戏套装,里面配有带塑料钉子的游戏面板。有些比较贵的电子版可以发出声音,但需要装电池。我觉得你应该可以在5分钟内就完成该游戏的纸上原型。

只要在纸上画一个10*10的网格两张(一张记录你的潜艇分布情况,另一张记录攻击结果),就可以开始玩这个游戏了,体验与“现实”版相差无几。

现在,我们来干点脑力活:将这场“海战”当成游戏进行严格地分析。这个游戏的设计缺陷是什么?如何改进游戏规则?然后再想想:如何改良你的纸上原型,用来测试新游戏规则?这个是很琐碎的事。以下是我个人提出来的改进方案:

如果潜艇未被攻击,那么玩家可以移动自己的潜艇。(修改原型:玩家可以把网格上原来的潜艇擦掉重画到其他位。)

允许玩家在自己的回合中不发动“攻击”,而是使用“声纳扫描”:可以叫任何一块3*3大小的区域,玩家说出该区域有潜艇占领的方格数字(0~9)。(这个地方就没什么好调整的,直接按新规则玩就是了。)

如果玩家在这个回合中“命中”,则回合不变,仍然由该玩家“叫号”。(还是没有调整的必要,直接按新规则玩。)

采用不同形状的潜艇:除了直线形的,还可以有T形、方形等,就像俄罗斯方块一样。(调整原型,只需要把潜艇画成不同的形状即可。)

给双方玩家一个攻击的有效区域,如在炮弹在某个3*3的区域内可以获击所有敌方潜艇。玩家可以在自己的回合内使用,以代替普通攻击,但整个游戏玩家只能使用一次。(不修改原型,按新规则玩。)

缩小游戏面板,把10*10的方格改成6*6的。(再画两个网格。)

如你所见,修改纸上模型真是又快又简单,想怎么改就怎么改。不要害怕你的想法“不靠谱”,不靠谱就不靠谱吧。即使是有经验的设计师第一次设计出来的东西也会“很糟”。但是,除非你开始制作,则否永远也出不了好游戏。纸上原型就是一个理想的开端。

即时系统的原型制作

像《战舰》这种回合制的游戏,非数码的原型基本上够用了。那么如果是FPS类的电子游戏,如《光晕》,怎么办呢?纸上原型有办法模拟那种基本上围绕着即时射击的游戏吗?答案是,完全可以。以下是揭示:

一个桌面游戏的“回合”相当于即时游戏中一定量的时间(如3秒)。

对于需要准确计时的躲避和命中系统,玩家成功与否取决于当前的难度和玩家的技能。这可以用随机死亡率来模拟。注意,即使电子游戏的系统不全是随机的,但从敌方玩家的角度看,也等同于随机了:如果我向你开枪,无论你能不能躲开,我都无法掌控。

许多即时游戏使用的是3D地图,不能细分成一块一块的“空间”。不过这不妨碍你用桌面游戏的方式模拟。

例如,考虑以下原则:

玩家:2~6,自由参与

目标:命中敌方

设置:玩家从游戏面板上的某一个设计好的起点开始。面板被划分为六边形。各名玩家正对着六个方向中的一边。各名玩家均持有以下卡片:移动、转向、移动/转向、开枪。

游戏过程:每一回合,所有玩家选择一张自己的卡片,写有动作的那一面朝下。所有玩家同时揭开卡片。首先,选择“移动”的玩家可向任意方向移动2格,但不可以转向且必须继续面朝一开始所选择的方向。然后,选择“移动/转向”的玩家可以移动1格,并顺/逆时针转向60度。最后,选择“开枪‘的玩家可以立刻杀死他们可以“看到”的敌方玩家。被杀死的玩家将淘汰出局。一个回合后,玩家再次从四张卡片中选择下一步行动的卡片。

结果:坚持到最后的玩家得胜。如果在同一回合中,二名或以上的玩家同时杀死对方,则游戏为平局。

现在我们加入新的规则:你只需随便地画一个六边形地图,添加几个六边形代表障碍物,玩家不可走过也不可射穿。

如果你确实去模拟这个游戏了,你会马上发玩有问题。比如,我没有定义什么叫“可以看到”,所以没有办法判定一枪打出去,到底是打中没中。你必须自己明确地定义这一点(可能是直线正对的玩家为“可见”,或者在一定的范围以内等等)。你可能也注意到了,游戏的深度不够,没有重刷、能量源、弹药、命值补给、特殊武器等。这个游戏也不支持“占山为王”之类的模式。以上所提到的东西都可以添加进去,只是再费几分钟的事。

这种原型有什么用呢?你可以用来测试提交上来的关卡设计方案,这样就可以在入进关卡编辑工具的执行以前就知道可行不可行了。如果你增加怪物和组队模式进去,再设计一个限制弹药和命值的机制,你可以用怪物的数量来平衡弹药及命值,从而获得一个比较可观的游戏挑战。如果你增加了具有不同射程、杀伤力和命中率的武器种类,那么在给定的地图上,你可以好好琢磨该使用哪款武器。将游戏改成电子版后,你还是必须重新审视这些设定,因为从一种媒体转换到另一种媒体上,转换率未必是100%……但毕竟开头做好了,再理解游戏的机制及其作用方式就不难了。

即使这个电子版游戏不太成功,至少你和朋友还能在这个游戏上找点乐子。

我举这个例子是希望大家明白,大多数的电子游戏至少有那么几个部分是可以在纸上完成原型制作的。当然,不通过数字渠道发行的游戏也可以这么模拟。有些出自桌面RPG和LARP游戏的系统在开发早期也可以用这种方式模拟。

关于网格

制作游戏面板的方法有很多,但这里有三条普遍的原则:将面板细分成方形网格。方格更容易操作,也更为玩家所熟悉,这样休闲玩家也容易上手。对于包含许多障碍物和移动挑战的网格,方格更容易表示“此路不通”:不可通过的方格迫使玩家改变自己原来的路线而走其他路线。方格的缺点在于,对角线移动成问题:对角线移动是算作一格还是两格?一格的话感觉太少了,两格的话感觉太多了。(对角线距离的真实数值是“根号2”,或约等于1.4……不过,计算这个显然没什么实在意义。)

将面板细分成六边形网格。六边形具有一些理想的数学功能,因为3个六边形的距离是固定的,无论你往哪个方向走——不会遇到方形网格的“对角线移动”问题。六边形网格的缺点在于,玩家更容易躲开障碍物,所以移动受限的情况也少了很多。这到底好不好,得看游戏的属性。另外,六边形相当令人讨厌,很可能不会吸引那些没有经验的玩家。

在空地上模拟,不要用游戏面板。每个回合,游戏物品的移动距离都用卷尺测量出固定的某某厘米。这样就更流畅更精确了,不过,六边形地图的某些缺点还是存在,并且很难说玩的过程中玩家会不会一不小心就撞上桌子或把游戏物品给挪动了一点。

增加功能还是保持简单?

正如前面所述,我们的FPS游戏原型还需要其他功能特点,如生命值和弹药。为什么不直接从这些已经想到的额外系统开始,而是从简单的核心系统开始?我们首先从简单的核心规则开始,然后再慢慢增加规则,而不是一次性完成整个游戏的设计,这么做有以下几个原因:

如果基本的核心规则不管用,添加额外的规则也保证核心规则生效。首先要把基本的规则做好了,才能添加复杂的东西。

如果你在不牢靠的基础上构建额外的规则,真正潜在的问题反而模糊了!有些东西看起来错了,但如果游戏中的其他系统、资源和对象太多了,你遇到的问题是因为核心机制出错,还是某种资源不平衡,或是地图的设计有误,还是其他什么问题,真的很难断定了。

在游戏的早期阶段,能简单就简单。当你想添加任何规则、机制、物品或资源时,你得问自己:确实有必要现在就加吗?此时,让你的懒惰掩盖你的创意吧。要在设计中加点什么太容易了,但要拿掉什么东西却未必,所以只要游戏能玩,尽可能少增加其他东西。

如果你觉得选择起来有困难,那么就写一份你希望运用于游戏的想法清单,然后根据没有此物游戏是否可运作为标准,尽可能地划掉清单上的想法,直到你完全没办法再划为止。

你还可以找那些跟你在个人事务或情绪上没有利害关系的设计师作评判,让他们说说你的哪个想法是垃圾。更甚,你可以跟你的同事交换自己的原型,你看我的,我看你的!

更进一步

一旦你完成了可运作的核心玩法,那么你就可以往其中添加新的功能特征了。此时,你会禁不住想把最初想到的所有东西一股脑地全丢进去。忍住啊,别冲动。你每增加一个功能特征,就要测试一次,直到确定新功能特征是有效的,或者发现新功能特征无效该丢弃。

为什么不一次性把所有东西加进去?因为你加进去的所有新东西都可能存在问题。如果你只增加了一个,一旦在测试中发现不对劲,你马上就知道问题出在哪里,因为你只改变过一个东西。如果你一次就添加了十条规则,一旦出了错,要区分出哪条规则(或哪几条规则组合后)不适用就相当困难了。这跟编程序类似:如果你只写了一小块语句,然后进行单元测试,很容易就知道漏洞所在,而如果你写了一万条语句才测试,出了问题的话……

是啊,确实是件沉闷的事。你必须测试,然后改变一条规则,然后再测试,再改变另一条规则,如此反复数十次(甚至上百次)。第一次测试很有趣,但你很快就会对一切都感到厌烦。这是设计过程的一部分。有时候,游戏设计就是件苦差事,没什么乐趣可言。如果你想成为专业的设计师,你必需接受现实。记住专业设计师的目标:制作有趣的游戏,如果游戏没意思,你就鼓起动力去改变和测试,直到达到你的目标。

要制作真正的游戏了,物质原型做完后的下一步就是制作文档。这些文档不必厚成500页的《游戏设计圣经》,只要记录你在反复设计、测试的过程中确定下来的规则和积累下来的测试注意事项就够了。然后在开始项目以前,把这些文档格式化成其他人能读能理解的材料。同时,如果之后你忘了曾做过什么,这些材料也将成为有价值的参考资料——有时候,你不得不把一个创意暂时放到一边,个把月后你回头再考虑这个创意,我敢说你肯定已经忘记所有那些曾经刻骨铭心的细节,所以,制作记录文档非常有必要。(本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

Level 4: The Early Stages of the Design Process

We have already made some games in this course, so we have already been through the creation process on a small scale. But our method of design, for the most part, has been ad-hoc: here are a bunch of elements, just throw them together and call it a game. The results of this type of design can be expected to be hit-and-miss.

What about for larger projects where the stakes are higher? Is there a process that can be followed that will lead to better games? There is the iterative process, to be sure, but we have not gone into detail on any of the iterative steps (design, playtesting, evaluation). How exactly do you come up with an initial design? What is the most effective way to playtest? When evaluating a game, what do you look for, and how do you know what to change? These are the things we will be concerned with throughout the rest of this course.

Today, we examine the first step of the iterative process: initial design.

Course Announcements

Just a couple of comments based on feedback received from the first forum challenge:

When the assignment is to design a game, I am looking for something that is in a state where you could print out the rules, create the components, and play. Some people posted, say, a card game and just handwaved over this: “The deck contains 50 cards, here are a couple of samples but I haven’t designed the others yet.” This is not a complete design. I encourage you to make complete designs, when you are designing a game and not just a concept. It is these details that are the essence of design.

If there is confusion over what I am asking for, as I’m sure will happen just about every time, do feel free to ask for clarifications in the blog comments. However, I also encourage you to make your own interpretations to the best of your ability. In classroom courses (and usually in the Real World) you can ask for immediate clarification if a constraint is unclear; but in this course, since we go so quickly, there is not always time to post a comment, wait for me to respond, and then read the comment. Be creative but fair in your interpretations.

A Note on Constraints

An interesting thing happened for this Monday’s challenge: more people attempted the Black Diamond (highest difficulty) than those who did all of the other difficulties combined. By contrast, when signing up, only about a tenth of the participants identified themselves as experienced game designers. What is going on here?
Part of it may be pride. Even though people will admit a total lack of experience to me in private email, broadcasting it on forums is another thing entirely. Part of it may be the thrill of the challenge. People want to know just how far they can push themselves.

However, part of it may be that adding constraints makes a challenge easier. This sounds unintuitive; after all, isn’t a new constraint just one more thing you can’t do? With more roadblocks, shouldn’t a task be harder? Not always, in the case of game design.

To understand this, we can look at the process of game design as a successive layering of constraints on a game. Every new rule you add, every resource you define, is just one more constraint on the players. At the start of the design process you may have nothing, and the players could do anything at all; by the end, the player experience is sharply defined and heavily constrained in a way that is fun. (We will address what “fun” actually is, later in the course.)

To put this in perspective, consider the so-called genre of “open world” video games (popularized by Grand Theft Auto). The typical player reaction is that these games let you do anything, they give complete freedom to the player, and that is why they are fun. However, a critical look at the games shows that they do not give complete freedom. The games actually constrain the player in many ways: there are only certain ways a player can move, a defined set of objects they can interact with, and the autonomous computer-controlled agents that wander around are governed by specific algorithms. The player has many decisions and a relatively open set of goals, to be sure, but there are a great deal of constraints that lead to this illusion of “being able to do anything.”

If you accept this explanation, that design is the creation of constraints, then you can see that constraints imposed from outside can be thought of as providing some of the initial design. By adding constraints, there is less design work to be done. Thus explains the paradox.

Constraints can also provide a useful anchor for your ideas. If I just say “go make a game” with no constraints, many people would just sit there like a deer in headlights, wondering where to begin. By adding a constraint (such as “World War I”), the question is no longer “where do I start” but rather, “what do I do with this.” And that is a much easier question to answer.

Most of the challenges in this course will involve constraints. In fact, most design in the Real World happens within constraints: a publisher asking for a game that uses a certain IP or within a certain genre or within a given time and budget, for example. One of the reasons I mention this, then, is to remind you that these constraints may sometimes seem ridiculous (“do I really have to come up with a concept for a My Little Pony game for DS?”) but that in fact they can often make a designer’s life much, much easier.

There is one other reason I mention constraints. For those rare times in your life when there are truly no constraints imposed on you by others (this is more common with “indie” development and hobbyist designers than with professionals), if you have trouble getting started, one way is to generate some constraints for yourself. Give yourself a time limit (“Game Jam” events typically challenge people to make a game in as little as 24 or 48 hours). Choose a subject matter that interests you and use it for the theme. Select a core mechanic that you’d like to explore. It can be completely arbitrary, but if you are stuck and don’t know what direction to take your game, go ahead and just choose an extra constraint to get yourself moving. (With iteration, you can always remove that arbitrary constraint later if you find it’s holding back your design.)

Generating Ideas

The first thing that happens in a design is that you must come up with the basic core of an idea. This isn’t necessarily fully-formed, but just a basic concept. There are many different starting points for a game’s design. Here are some examples, in no particular order:

Start with the core “aesthetics” — what do you want the player to feel? How do you want them to react? What should the play experience be like? Then work backwards from the player experience to figure out a set of rules that will achieve the desired aesthetic. Think about the best experience you’ve ever had while playing a game; what game rules led to that experience?

Start with a rule or system that you observe in everyday life, particularly one that requires people to make interesting decisions. Look at the world around you; what systems do you see that would make good games?

Start with an existing, proven design, then make modifications to improve on it (the “clone-and-tweak” method). This often happens when making sequels and ports of existing games. Think of a game that you thought had potential, but didn’t quite take the experience as far as they could; how would you make it better?

Start with technology, such as a new game engine (for video games) or a special kind of game piece (like a rotateable base for miniature figures). Find a way to make use of it in a game. What kinds of items do you have lying around your living space that have never been used in a board game before, but that would make great game “bits”?

Start with materials from other sources, such as existing art or game mechanics that didn’t make it in to other projects. Design a game to make use of them. Do you have an art portfolio, or earlier game designs that you didn’t turn into finished products? What about public domain works, such as Renaissance art? How could you design a game around these?

Start with a narrative and then design game rules to fit, making a story-driven game. What kinds of stories work well in games?

Start with market research: perhaps you know that a certain demographic is underserved, and want to design a game specifically for them. Or maybe you just know that a certain genre is “hot” right now, and that there are no major games of that type coming out in a certain range of dates, so there is an opportunity. How do you turn this knowledge into a playable game?

Combinations of several of these. For example, starting with core aesthetics and narrative at the same time, you can make a game where the story and gameplay are highly integrated.

When you think of new ideas for games, what kinds of ideas do you have? What are your starting points? What does this say about you as a designer, and the kinds of games you are likely to make?

Other Methods of Idea Generation

If you are stuck with “designer’s block” (the game design equivalent of “writer’s block”) there are a number of strategies you’ll see mentioned in various places. Here are a few:

Keep a permanent collection of all of your ideas for games, mechanics, stories, and everything else. Look back through it from time to time to see if there’s anything from years ago that you can use. Add to it whenever an idea occurs to you that you can’t use immediately, but that you want to return to later.

Think of something random. Try to find a way to integrate it into your game.

Do some research. Learn about some aspect of the game in more depth, and you will likely find new ideas.

Go back to the basic. Think of the formal elements of your game. What are the player goals? Rules? Resources? And so on. Note that you’ll need to define these anyway in order to have a game, so by focusing on these one at a time it may give you new questions to answer.

Formalized brainstorming, either alone or in a group. Some people swear by this method, while others say the results are questionable. The best I can say is that the results are highly unpredictable… as is the case with most R&D.

Think critically about games. You may have my textbook on game design that contains some of what Brenda and I have learned over the years, but you should write your own book over the course of your lifetime (whether you publish it or not, at least keep it for yourself). When you discover something that does or doesn’t work in a game and you think you can identify the root cause as a “law” (or at least a guideline) of game design that is broadly applicable, write it down! If you don’t know why, write that down too, and come back to it periodically until you find the answer.

Play lots of games! But… play as a designer and not just a player. Don’t just play for enjoyment. Instead, play critically. Ask yourself what choices were made by the designer of the game, and why you think those choices were made, and whether or not they work. Play games in genres that you don’t like or have never tried, and try to figure out why other people find them fun. Also, published hint guides can be useful to read — they are basically glorified design documents that detail all of the systems of a game!

And lastly, practice. Work on your own projects. The more you make games, the better you get at making them… just like any other art form.

Prototyping

Remember, the more times you can iterate on your idea, the better the final game will be. Once you have a basic idea, the next step is to get it in playable form as quickly and cheaply as possible. That will leave you with as much time as possible to playtest and iterate.

As mentioned last time, iteration is the most critical for those parts of your game that have high design risk. For “clone-and-tweak” games where you are mostly lifting gameplay from an existing game, rapid prototyping is less important. This does not mean that “clone” games do not benefit from iteration, but simply that you should use it selectively in those areas where you are innovating. Keep this in mind for today’s challenge.

“Laws” of Prototyping

Remember that the entire purpose of prototyping is to maximize the number of iterative cycles. Corollary: do everything you can to reduce the time required in each iteration. Now, consider that each iterative cycle consists generally of four steps: design, prototyping, playtesting, and evaluation. Of these steps, where can you save time?

You can’t really reduce the time it takes to design the rules of the game, without compromising your goals. You can’t rush creativity.

You can reduce time spent in playtesting by being efficient about scheduling and designing playtests to give maximum information for minimum play time… but there is a natural limit to this, and beyond a certain point you can’t rush through playing the game.

Evaluation doesn’t take very long; you’re making a simple yes/no decision of whether the game is “done” or “good enough” based on playtest results. There is little to be gained by rushing through this further.

So, that leaves reducing the time it takes to create a prototype.

Some things to keep in mind when building a playable prototype:

Build it as fast as possible. Cut corners. Make it as ugly and cheap as you can get away with.

Minimize what you need to build. Only do what is absolutely necessary to evaluate your game. If you’re trying to test out a new combat system, you do not need to build the entire exploration system. If you’re making a card game, hand writing on index cards is faster to make than typing everything into Powerpoint, printing on heavy card stock, and cutting it all out manually. There is a time and place for making nice-looking components, and the early stages of game design is not that time or that place.

Make your prototype easy to change. You will find problems in playtesting, so make it easy to adjust on the fly.

All of these guidelines push designers towards one inevitable direction…

Prototyping in Paper

You can call it “paper” or “cardboard” or “non-digital” or “analog” or any number of things, but the idea is to have a physical, tabletop game that is playable without computers (or at least, without requiring programming code). Programming is wonderful and powerful but it is also slow and expensive in comparison to paper prototypes. Here are some advantages of paper prototyping:

It is cheap. Most systems can be prototyped with little more than a pencil and some paper, although I will give suggestions for other components for those of you that have some money to spend.

It’s fast. You don’t have to mess around with programming, or layouts, or artwork. Just write a few words on a scrap of paper.

It’s easy to change. Don’t like one of your numbers? Erase it and write in a new one.

There is no guilt about throwing it away. You came up with an idea that didn’t work? Oh well, you lost a whole half hour. Big deal. It’s like making stick-figure drawings: if your first attempt at drawing a stick figure doesn’t work, it only took you a few seconds, so just cross it out and try again.

Paper can be used to model most gameplay systems. Yes, even most of the ones we normally associate with being specific to video games.

By making something playable, you are forced to actually design the systems. No more handwaving of “this game will have 50 undefined cards”. You have to actually do your job as the game designer, and design the game!

Limitations of Paper

Paper prototypes do have some limitations that you should be aware of:

They cannot always handle “twitch” (dexterity or timing based) mechanics… although be aware that there are many dexterity-based non-digital games. Consider the similarities and differences between the Street Fighter series of video games, and James Ernest’s real-time card battle game Brawl. Some things carry over well… others, not so much.

Information that is hidden to both players but that still requires bookkeeping, such as the “Fog of War” mechanics prevalent in Real-Time Strategy video games. Again, note that this can sometimes be worked around — the classic children’s game Battleship has “fog-of-war-like” mechanics, and the board game Clue has information hidden from all players.

Extremely complex calculations are tedious on paper, and the systems that use them may be better suited to “prototyping” in a spreadsheet program like Excel. However, if the complex systems are a necessary and core part of the game, it may be a sign that “the computer is having more fun than the player” (to quote Sid Meier), and that perhaps some simplification would make the game more accessible.

“Eye candy” such as high-quality art and animation is obviously not prototyped easily with stick-figure drawings and handwritten cards. Then again, these are not part of the game mechanics. If your game relies on visuals rather than systems, that is a sign that you are not doing a strong enough job as the systems designer.

Paper prototypes are not very well suited for testing the user interface (UI) of a video game. Computer UIs are dynamic, but paper is static. You can get an idea of the visual layout with some paper sketches, but to know how it will actually be used on a computer, you’d need a digital prototype.

As you can see, the advantages of paper prototyping are very general and the limitations are specific, so the ability to prototype in paper is an important skill for any game designer to develop, whether they work in video games or board games or anything in between.

The Non-Digital Designer’s Prototyping Kit

What follows is a list of materials that I have personally found useful when prototyping. Other designers may have their favorite materials, so I look forward to seeing the discussion that will inevitably be generated by this list:

Paper, of several varieties: blank, lined, and graph. These are useful for general note-taking, and for the fast construction of makeshift game boards and other surfaces.

Colored pens and pencils. Obviously you need something to write with. Colors give an easy way to differentiate between game elements, or to annotate your game components.

Index cards (3″x5″). These make it easy to make cards. They shuffle reasonably well. You can cut them in halves or thirds for different card sizes. You can also just write ideas down on these and tape them on the wall, making it easy to arrange your thoughts visually. These are versatile and cheap.

Scissors and tape. For breaking things apart and sticking them together, respectively. These are to game design what WD-40 and duct tape are to handymen, for the same reasons.

Paper clips and/or binder clips. This lets you store related materials in one place. For example, if you create several “decks” of index cards, this lets you hold them together so they don’t get mixed up with each other (or worse, mixed up with cards from other prototypes).

Glass beads (sometimes called “Pente stones”) in different colors. These make great markers, counters, and playing pieces.

Dice, of varying types (4, 6, 8, 10, 12 and 20 sided). Several of each type, in different colors. These provide independent random variables (as opposed to the dependent randomness of card draws). For more information on the uses of dice and cards, see Chapter 5 in the Challenges text. Note that dice can also make decent playing pieces that can simultaneously “store” a single number on them — for example, a six-sided die could represent a warrior with up to 6 hit points.

A small bag of low-value coins (pennies in the United States, and I admit ignorance to how other countries handle coin-based currency). Coins make good markers, they can be flipped for a random variable, they have two sides so they can represent either of two states (such as which of two players currently controls them), and they can be stacked more easily than dice or glass beads.

Colored sticky-dots (small round adhesive labels). You can put them on stones, dice or pennies to mark them, differentiate them, or customize them. You can write on the dots to provide additional information if needed.

A paper notebook that is kept with your prototypes and used exclusively for taking notes in playtests. This is not something you want to accidentally lose track of!
Where do you find these things? It depends where you live. Most, you can get at an office supply store (Staples, Office Depot and Office Max are the big stores near where I live; you may have others), except for dice, glass beads, and coins. The coins, you can get at a bank (in the United States, you can get a hundred pennies for only one dollar — a bargain by any standard for quality game components  ). Dice are generally found in hobby-game stores or comic-book shops, or purchased online. Glass beads can be found in a variety of places. Hobby-game stores have them. Pet stores that sell fish equipment may sell them as aquarium stones. Art/craft hobby stores may sell them as glass beads for jewelry and craft projects. They also come as components with many games (notably Pente), if you can find a game with glass beads for cheap.

Craft and hobby stores, both the retail chains and online (Michael’s is the big chain store in my area), can offer great inspiration for game designers. I’ve found large quantities of unpainted and colored wooden cubes (great as resource markers and also as custom dice) and wooden discs (they feel better and are larger than pennies). Once, I found a set of flat painted wooden cut-outs, maybe an inch square, of bunnies and another set of carrots; I don’t know what I’ll ultimately do with them, but there is a game that will be made with them some day. Craftparts has wooden people-shaped pawns and square tiles in various sizes. These kinds of quality components may not be immediately suitable for quick-and-dirty paper prototypes, but they can certainly come into use as your project becomes more developed.

Your First Paper Prototype

Here are the rules for the classic children’s game Battleship:

Players: 2

Objective: sink all five ships in your opponent’s fleet before they do the same to you.

Setup: Each player has a 10×10 grid of squares, with the rows labeled with numbers 1 through 10 and the columns labeled with letters A through J. Each player has five ships: one ship that is 2 squares long, two ships that are each 3 squares long, one ship that is 4 squares long and one ship that is 5 squares long. Each player secretly places their ships on their own grid, in such a way that each ship is oriented sideways or up-and-down (not diagonally) and that ships do not overlap. A player is chosen to go first.

Progression of play: On a player’s turn, they call out a single square by its coordinates (such as “B-5″ or “H-10″). If the named square is not occupied by any of the opponent’s ships, the opponent says “Miss”. If the square is occupied, the opponent says “Hit”. Additionally, if the square was a “hit” and the ship that was hit has had all of its sections hit, the ship is considered “sunk” and the opponent must tell you which ship was sunk. No matter what the result, after the action is resolved, play passes to the opponent.

Resolution: When one player sinks all five ships of the opponent’s fleet, that player is the winner.

Normally, this game is available in toy stores. It comes on a plastic board with plastic pegs. Some fancy electronic versions require batteries and have sound. But I bet if you think about it, you could prototype this game in paper in less than five minutes. How would you do this?

If you couldn’t guess, all you’d have to do is draw two 10×10 grids on a sheet of paper for each of the two players (one to keep track of your fleet, and one to track the results of your shots against the opponent). This is all you need to play, and it gives pretty much the same experience as the “real” version!

Now, try this thought experiment: critically analyze Battleship as a game. What are the weaknesses of its design? How would you modify the rules of the game to make it better? If you are taking this course in a group, discuss this with your colleagues. Then, consider: how would you modify your paper prototype to test out your new rules in a playtest to see if they work? Usually, this is trivial to do. Here are some examples from the times when I’ve taught this course in a classroom:

Allow players to move their own ships if they haven’t yet been hit. (To modify the prototype: just allow players to erase and re-draw their ships.)

Allow players to use a “sonar sweep” instead of firing a shot on their turn: they name any 3×3 square area on the board, and the opponent says the number of squares in that area (from 0 to 9) that are occupied by ships. (No modifications necessary, just play with this as a new rule.)

Let players take another turn immediately if they score a “hit”. (Again, no modifications necessary, just play with this new rule.)

Use differently-shaped ships: instead of lines, have a T-shaped or square-shaped ship, like Tetris pieces. (To modify the prototype, just draw the ships in different shapes.)
Give each player one area-effect bomb that hits everything in an entire 3×3 square area. They can use it on their turn instead of taking a normal shot, but only once per game per player. (Again, just play with the modified rules.)

Shorten the game by playing on a 6×6 grid instead of 10×10. (Just draw the grid differently on paper.)

As you can see, modifying the rules to a paper prototype is very fast and easy, and you could go through many iterations in a short period of time. Don’t be afraid that your idea will be “bad”! Of course it will be bad. Even experienced designers create “bad” games in their first iteration. But you will never turn it into a good game unless you start somewhere. A paper prototype is very often the ideal starting point.

Prototyping Realtime Systems

For a turn-based game like Battleship, a non-digital prototype is easy enough to put together. What if you wanted to prototype a First-Person Shooter video game like Halo? Is there any possible way to do that on paper, when most of the game is running around and shooting things in real time? The answer is yes, absolutely. Here are some hints:

One “turn” of a board game is equivalent to some amount of time (say, 3 seconds) of real-time

play

For “twitch” mechanics like dodging and accuracy that require accurate timing, either a player succeeds or fails at these based on how difficult they are and how skilled the player is. This can be modeled with a random die roll. Note that even though the video game’s system is not random at all, it may as well be random from the opponent’s perspective: if I shoot at you and you either do or do not successfully dodge, I have no control over that.

Many real-time games take place on an open 3D map that is not subdivided into “spaces”. This does not prevent you from making a game board that has spaces anyway.

For example, consider these rules:

Players: 2 to 6, free-for-all

Objective: shoot your opponents

Setup: Players start at designated starting locations on the board. The board is subdivided into hexagons (“hexes”). Each player is facing in one of the six directions leading away from their space towards another hex. Each player takes a set of the following cards: Move, Turn, Move/Turn, Fire.

Progression of Play: Each turn, all players select one of their cards and play face-down. Cards are revealed simultaneously. First, any players who selected Move get to move up to 2 spaces away in any direction(s), but they cannot turn and must continue to face the same direction they started the turn facing. Next, any players who selected Move/Turn may move up to 1 space and also change their facing by a single hex (60 degrees) in either the clockwise or counterclockwise direction. Next, any players who selected Turn can change their facing to any direction they want. Finally, any player who chose Fire immediately hits and kills any opponent(s) that they can see. Any player who is killed is eliminated from the game. After the turn, players collect the card they played. They may play this card or another one on the next turn.

Resolution: When one player is left standing, that player wins. If two or more players shoot and kill each other on the same turn simultaneously, the game is a draw.
Then you just draw up a quick hex map, maybe fill in a few hexes to represent obstacles that players cannot walk or shoot through, and play. Try it out!

And if you do try it out, you’ll immediately notice the game needs some iteration. For example, I didn’t define what a player “can see” so there is no way from the rules above to tell if a shot hits or not. You will have to define this more explicitly on your own (maybe it means in a straight line, or maybe within a certain range, or maybe something else). You may also notice that the game is not very deep; there are no respawns, power-ups, ammo, health packs, special weapons, or anything else. The game does not immediately support common variants like Capture-the-Flag or King-of-the-Hill. All of these things could be added, however, in just a few minutes.

What would this kind of prototype be useful for? You could use it to playtest a proposed level layout, before implementing it in the game’s level editing tools. If you add enemy monsters and play as a cooperative team, and you add limited ammunition and health as new mechanics, you could balance the number of monsters versus the amount of ammo and health on a level to get a pretty decent first stab at a level that would provide a desired level of challenge. If you add different weapon types with varying range, damage and accuracy, you could get a pretty good idea of which weapons would be the most powerful on a given map. You would still need to revisit these things if you turn it into a digital game, because things do not transition 100% perfectly from one medium to another… but you will have a better starting point, and a better understanding of the game’s mechanics and how they are likely to interact.

And maybe even if the digital game fails, you’ll still at least have a fun little tabletop game to play with your friends.

I hope this example serves to show you that most video games can have at least some of their elements prototyped in paper. And naturally, games that are meant to be released in non-digital form can be prototyped that way as well. Even some systems from tabletop RPGs and LARPs can be prototyped in this way, in their early stages.

A Short Note about Grids

There are many ways to make a game board, but here are three common ways to get you started:

Subdivide into a grid of squares. Square grids are easy to navigate and are familiar to most players, so they will not intimidate casual players as much as some other methods. For grids that include lots of obstacles and movement challenges, grids are ideal because it is easy to block off a path: a single impassable square forces you to go quite a bit out of your way to get to the other side. The drawback of squares is that you inevitably run into a problem with diagonal movement: does it count as one space or two in order to move diagonally? One space feels too fast; two spaces feels too slow. (The actual value is the square root of 2, or about 1.4 spaces… but if you’re dealing with whole-number values this obviously does not work.)

Subdivide into a grid of hexes. Hexes have some nice mathematical properties to them, in that something that is 3 hexes away is always that many hexes, no matter which of several paths you take; this gets around the “how fast to move along a diagonal” problem of square grids. On the down side, hex boards make it much easier to move around obstacles, so movement is a lot less constrained. This may be desireable or not, depending on the nature of your game. Also, hexes are quite “geeky” and are likely to put off players who are not that experienced with this style of play.

Open area, no board. Use a tape measure instead, and move your pieces a certain number of inches (or centimetres, or what have you) per turn. This gives the most fluid and precise movement, although it has many of the same disadvantages as hex maps, and is also vulnerable to someone accidentally bumping the table and sending pieces slightly off of where they were.

Adding Features versus Keeping It Simple

As mentioned earlier, our First-Person Shooter prototype is just begging for extra features, such as health and ammo. Why not start with all of these extra systems already in place, as opposed to starting with just the simple core system? There are a few reasons to start with a simple, core rule set and then add on one rule at a time, instead of trying to design the entire game in one big effort:

If the basic, core rules don’t work, then adding extra rules on top of it will generally not make it work. Get the basics working first, before you start adding complexity.

In fact, if you build extra rules on an unstable foundation, the real underlying problems in your design could be obscured! Something might seem wrong, but if there are a lot of systems and resources and game objects it can be hard to tell if you’re experiencing a problem with the core mechanics, or the balance of a particular resource, or the design of the map, or something else.

Early on in a design process, it’s generally better to keep things as simple as possible. For every rule or mechanic or object or resource that you want to include, ask yourself: is this really necessary right now? At this point, let your laziness override your creativity. It is far easier to add something to your design than to take it away, so add the minimum possible to have a working, playable game.

If you have trouble with this, try writing down a list of all of the ideas you have that you want to include in the game, and then cross off as many as you can. Ask if whatever items are left on your list would make a complete, playable game. If so, try to cross off more, until you absolutely can’t anymore.

It may also help to run your idea by another designer who is not personally and emotionally attached to your pet idea. Invite them to be merciless in deciding which of your rules can be trashed. For the purposes of this course, you can offer a trade with any colleagues in your area: you look at my prototype, I’ll look at yours!

Moving Forward

Once you have the core gameplay, and it works, then you can add new features. The temptation at this point is to add everything you originally thought of. Resist this temptation. Instead, add one new feature, and playtest again until the new feature works, or you have decided that it doesn’t work and it needs to be abandoned.

Why not add everything at once? Because every new thing you add may have some problems with it. If you only add one new rule and a critical game system becomes broken in playtesting, you know exactly where the problem is, because you only changed one thing. If you add ten new rules and something breaks, it’s harder to isolate which rule (or combination of rules) caused the problem. Incidentally, this part is similar to programming: if you write code in small chunks and then unit test, it’s easier to find bugs than if you write ten thousand lines of code between tests.

Yes, this is tedious. You have to playtest, then change one rule, then playtest again, then change another rule, and keep doing this dozens (or even hundreds) of times. The first few playtests are fun, but you will quickly become sick of the whole business. This is part of the process of design. Sometimes, game design is hard work that is not particularly fun. This is something you need to accept if you have aspirations to become a professional designer. Just remember that the purpose of this is to make a game that is fun, and if it’s not there yet, that should be your incentive to change something and playtest again until you reach your goal.

In making an actual game, the next step after the physical prototype (once you’re happy with it) is to document it. These documents do not have to be 500-page Game Design Bibles. They can be small sets of rules and design and playtest notes that you’ve accumulated as you went through the iterative process, but formatted into something that is readable and understandable by someone who has not seen the project before. This documentation will be valuable reference material for later, if you ever forget what you were doing. Sometimes you have to put an idea to the side for a few months and return to it later, and I guarantee you will forget all of those details that used to seem second-nature to you when you were fiddling with the rules early on.(source:gamedesignconcepts


上一篇:

下一篇: