作者：Tony

游戏设计原则总是在不断发生改变。更确切地说应该是，这个世界对于游戏设计师的期望一直在发生改变。如今的游戏已经是无处不在了，游戏产业已经发展成为拥有数十亿美元资产的大产业，分布不再是一种准入壁垒，而工具的存在不只是为了帮助独立设计师更有激情地创造游戏，同时也将为他们带来更多利益。随着媒体的发展，独立群体与AAA级工作室之间的鸿沟也变得越来越大。比起之前，如今已经很少有工作室愿意去迎合主机市场了，而其他人所面对的巨大机遇则是在一个高度竞争的环境下越战越猛，并快速改变游戏市场。我们总是会投入大量时间和精力于游戏中，但是最终所获得的回报却不一定成正比。

不管是出于游戏设计还是利润，这都是每一位认真的游戏设计师寻求成功的内在目的。为了继续致力于自己所喜欢的事，我们不仅需要实事求是，培养商业头脑，同时还必须具有创造性并努力工作。当然了，还有许多方法能够帮助我们取得这些成功，我们只需要选择合适的方法并避开错误方法便有可能创造出一款真正成功的游戏。

游戏设计的黄金法则便是，如果游戏本身具有超高质量，那么即使商业计划中存在缺陷也不会影响其最终的成功。但是这样的游戏却少之又少，尽管我们都希望能够创造出这么一款游戏。而我并不会在本文中阐述这种特殊游戏设计的相关指南。相反地，本篇文章将帮助你提升游戏成功的机会，不管是理念还是最后的发行。我将着眼于各种内容，包括代码编写和商业实践，尝试着解释一些最常见也是最重要的问题，并将开发者引向最赚钱的道路上。我将通过研究和例子去支持所有的内容，但是因为游戏产业一直处于转变期，所以研究结果可能永远都达不到与时俱进。但是我仍希望开发者们可以耐心听取这些建议。

理念

天才不过是有更大的耐性。——George-Louis Leclerc（1803）

塑造理念—-原型

在设计世界中，不管是设计游戏，建筑还是汽车，理念都是无价值的。它们很普通，很廉价，并且只是想象力的一部分。世界上的任何人都具有想象力，而你的并不会多特别。就像我就设想过上百首协奏曲，构思过上千幅画以及上万种情节，但却仅限于想象这一表达形式。如果你希望通过想象力去掳获别人的心，那就必须想办法去改变它——你必须赋予理念一种形式，而在游戏设计的例子中便是，创建原型。

原型是一种敏捷开发方式，你可以在此测试理念，并明确这一理念是否能够创造出一款有趣的游戏。许多致力于2D开发的设计师都会告诉你，如果你不能让理念发挥功效并最终创造出乐趣的话，那最好直接将其抛弃。如果未拥有编程背景（就像我开始创造第一款游戏前），我会建议你多给自己一定时间，并仍遵循基本规则。创建原型便意味着将一些粗糙的骰子投入屏幕，执行一些基本的控制和简单的游戏循环，并检查是否存在发展前途。如果没有便意味着你的理念是无效的，所以请直接前往下一个理念。如果你能在一个非常混乱的原型中看到一丝希望，那就果敢地创造一个新原型并再次进行测试。

如果你说，我知道自己的理念是有效的，所以我并不需要创建原型。

请你终止这种想法。要知道做出任何判断前都需要找出证据，而如果真的存在证据的话，那只能说那并不是你的理念。如果你偷取了现有的游戏设计，那倒也没关系，因为我们的产业便是建立在这一基础上。但是如果你所持有的是一个全新理念，你便不可能知晓它是否有效，除非你能够进行测试。有时候游戏设计是关于情感和信念，但通常情况下它是经过不断的试验过程所发展起来，对此我可以保证两种结果中的一种，即要么开发过程永远都不会结束，要么最终产品将不值得你做出任何投入。

优先考虑游戏玩法

在创建原型的过程中，你必须竭尽全力地突出游戏玩法。这是从较小的独立游戏向《马里奥》那样的平台游戏过度的建议。如果你的理念是关于叙述，关卡进程或者任何静态内容的话，你便为自己铺好了走向失败的道路。但是如果你的理念是关于游戏玩法，你就需要想办法去赋予它乐趣，并在之后添加能够完善游戏玩法的静态内容—-绝不能让静态内容阻碍了游戏玩法的发展。

想想你之前所拥有的所有游戏（不管是卖掉的，删掉的还是忘掉的）。将这些游戏与你摆放在架子上或储存于硬盘中多年的游戏对比。你所扔掉的一次性游戏体验与长期摆在架子上的无限体验相比最大的差别便是后者拥有新鲜的游戏玩法。

忽视静态内容

静态内容在原型上无任何立足之地，并且在其它地方也没有多大价值。也许我的这一观点会让许多人感到沮丧，但是这却能够帮助你创造出真正成功的游戏。围绕静态内容（如故事）设计游戏等于往自己手上带上手铐。静态内容将禁锢设计决策，并阻碍你创造出更棒的理念。无数的游戏变成了它的牺牲品—-玩家将不得不为了完成故事而继续游戏，或攻克最后关卡，而不是因为对游戏玩法感兴趣而玩游戏。

而能够替代静态内容的便是动态内容。从程序上来看，动态内容是游戏所生成的内容，而不是预先设置在关卡或故事中。静态平台游戏和动态平台游戏的区别便是非常显著的例子。《马里奥》拥有静态关卡以及最小动态内容（关卡将基于玩家所选择的道路发生细微的改变）。所以当玩家记住关卡时，游戏便不再具有任何挑战意义。而《都市大逃亡》则是一款完全动态的平台游戏，确保玩家每次游戏都能随机面对不同挑战。可以说这两款游戏都非常出色，但是作为一名独立游戏设计师，我们必须权衡创造多个静态关卡与一个静态内容的成本和利益。

当你每次尝试着想保护静态内容时，任何可能通向成功的大门都会在你面前关闭。越早在游戏中包含静态内容，你的开发便会面临越多限制因素。

旁白：授权的诅咒

来自其它媒体（游戏邦注：如电影或玩具）的授权正荼毒着游戏设计，你应该想办法避开它们。甚至大多数非常神奇且有所准备的授权也不能帮助我们创造出真正优秀的游戏。授权总是将内容看的比游戏玩法重要，即使事实并非如此。基于授权创造游戏就像在绘制风景时，前景已经用蜡笔先上完色了。你的工作就变成是尽可能去利用这种授权，而基于这种任务也没人会谴责你的失败。

让我列举一个案例研究，即想象你的角色正在一个到处都是水的环境中奔跑着。为了突出角色的武器，你需要选取与背景相对立的颜色。而最佳设计选择便是闪闪发光的黄金武器—-不过如果你所创造的是《加勒比海盗》这一类游戏，并且主角使用的专门设计的铁剑的话便除外。这是唯一能够妥协的选择，但其实还有更多选择。包括战斗的数量，背景的多样性，可游戏角色的范围，不能进行互动的故事，以及音乐等等。

而反面论据便在于，优秀的作品总是源自更多限制，许多艺术家的成绩便能够证实这一点。授权也能创造出优秀的游戏（游戏邦注：例如《蝙蝠侠》和《星球大战》），但前提是它们必须是拥有大量惊人选择的授权内容。《蝙蝠侠》便受到了许多艺术家的各种诠释，而观众们也都做好了接受新设计和新方向的准备。《星球大战》拥有宇宙规模的主题，所以不再受限于现有的叙述。但是对于开发者而言，限制因素总是比机遇多得多。如果他们能够站起来迎接所有挑战，他们便有可能获得更多力量，但是比起作为成功的秘诀，这更像是造成灾难的元素。

进程，障碍和资源

所有游戏，从象棋到最近的《光晕》巨作，都是以不同形式去传达这三大游戏机制。这是所有游戏设计的基础，并且我们必须在创建原型的同时明确平衡点。

进程是关于发展与升级。对于大多数游戏而言，最简单的例子便是分数，但它也能进一步延伸到升级，角色能力的增强以及故事的发展。

障碍会阻碍进程，是我们必须克服的一大元素。它不一定像杀死敌人那样具有破坏性—-反倒是它像任务那样具有转变性。但是当障碍发挥作用时，它便会阻碍进程的发展。

资源便是你提供给玩家去对付障碍的工具，并且偶尔可以用在进程中。资源可以像跳跃或奔跑那样无限，也可以像升级或生命值那样有限。同样地，它们也可以像板位或玩家的创造性那样变得更加抽象。

我们应该尽早且频繁地着眼于这三大元素的平衡。带有许多障碍但却少量进程的游戏只会折腾玩家。而带有过多资源的游戏则会变得更加复杂，因为游戏中并未拥有足够的障碍能让玩家使用这些资源。如果进程是恒定的，那么游戏将会变得很无聊并不断反复。

我们必须明确进程，障碍和资源这三大元素，如此才能更好地规划如何通过游戏去赚钱。

认准销售机遇

假设你采取了一种微交易模式，你便需要设置一些能够在游戏中销售的内容。在此你将把游戏分解为进程，障碍和资源三大元素。

一般说来，销售障碍不仅不好赚取，还很费工。像额外的关卡或更多故事等内容将与额外的进程奖励相匹配，从而克服障碍。

单独销售进程虽然能够赚钱，但却会惹恼用户。出售进程的最常见方法便是黑市交易（例如购买储存文件和在线角色），但是你的核心玩家并不会支持这一点。

而资源销售不仅是赚钱的方法，同时也是玩家能够接受的游戏盈利方式。在创建原型的过程中，你必须牢记，优秀的游戏设计有可能导致你不能销售任何资源。如果游戏中拥有无限的资源，即不存在玩家补充或提升的空间，如此你只能转向障碍及进程奖励的销售，但是这却是更加艰难的业务模式。并不是说这是一种糟糕的业务模式，但是你所作出的选择却逐渐偏离了原型阶段。

最重要的是必须具有创造性。资源需要包含任何能够帮助玩家升级或提升能量的内容—-游戏中任何能够翻倍的可变或恒定内容都可能带来巨大的收入。如果你能够找到合适的内容（或者在之后选择更多内容），你便可以开始进行开发了。

开发

如果一个人完全不玩游戏的话，他的工作将变得非常无聊。—-Simone de Beauvoir（1966）

成功的架构

作为一名程序员，不管眼前摆着的是怎样的编程环境或任务，你都能使用并学习前人所创造的一些内容。而你的第一项工作便是去寻找这些内容。不管你选择了何种开发内容，何种语言，总是能够找到包含简单动画工具，像素位块传送引擎，大规模物理模拟器以及3D模型等等。如果你选择自己创造，请先为此找出一个适当的理由。开发者们总是会沉迷于创建完美的游戏引擎代码，就好似在应对一篇学术论文那般。但是要知道，你的同行们已经创造了许多非常优秀的代码，你就不要再浪费时间了。

当然了，你也必须有效地编写代码。对于整体的游戏编程来说，所有的对象编程原则都很重要，但同时这也是一种模块化原则，即将受益于快速且灵活的设计。创造测试案例，换入并换出，改变所有相关内容，扭转它们，并继续开发。如果你的代码能够更好地处理简单的类别或变量呼唤所引起的游戏玩法改变，那么你便能在开发过程中找到更多选择。

旁白：受变量驱动的开发

我支持在所谓的“受变量驱动的开发”中设置文件。在一个或一小组类别中，我设置了关于各种内容的常数列。这些内容包括特效相机，纵横比，玩家高度，基本速度，每一波的敌人数，每发炮弹的破坏力，每个敌人的生命值，每次杀人所包含的奖励等等。当我在创造这些常数时，它们通常也会复合其它常数。而当我创造个体类别时，我必须确保自己引用的是这些常数而非内部数字—-所以当我想要加速整体的模拟时，我便可以将一个常数从50改为100，而游戏将自动管理所有改变。

基于这种方法进行开发还有其它优势，就是你可以在测试过程中设置一个活动的面板去调整各种变量，而无需每次进行重新编辑。如果我将升级数翻倍但却将玩家的时间缩半，那么游戏是否会变得更有趣？

在运行过程中调整变量的面板便意味着对广泛的设计决策做出实时反馈。但是我们几乎不可能拥有足够的成本去测试不同的场景。

游戏测试

邀请陌生人在每个开发阶段去测试你的游戏。也许他们会问各种愚蠢的问题并做出愚蠢的评价，但是他们却经常能够提供给你自己在测试中所发现的内容，并且这也是你在开发过程中未曾注意到的。

这是我想要再次强调的一大重要过程。

你没有第三只眼睛去发现游戏中最显著的问题。如果你能够拥有更多只眼睛，你便能找到更多游戏问题。所以你最好走出工作室，让别人为你提供反馈。你最好能够尽早且更加频繁地明确问题所在。

确保简单性

在开发过程中，简单性便是你的好朋友：

游戏越简单的话，你便能够越轻松地改变那些失灵的内容。但是当游戏变得更加笨拙时，你便会更不愿意做出这些改变了。

发行一款简单的游戏是测试市场的最佳方法。你必须考虑种种可能性，因为即使你做出了最佳尝试，但是游戏也有可能遭遇失败。创造符合你的想法的最简单的游戏能够帮助你面向市场测试核心设计及其不可预知的力量。你也可以创造系列游戏。而简单的设计能够更有效地体现出乐趣。你必须确保游戏和原型一样有趣—-太大的偏离只会遭遇失败。试着忽略一些临界的游戏玩法，并在开发过程中努力探寻更多乐趣。这是帮助我们基于无损失条件而尝试游戏的简单方法—-如果游戏真的有趣的话，我们便能够考虑最终作品了。

对于游戏的一些深层次元素而言，复杂的系统也非常重要，但是我们必须在整合所有内容之前花时间去精通相关组件（并切除那些不需要的内容）。

敞开大门

在开发过程中的某些时间，你必须开始做出一些明确的决策。这一点非常重要，但是在核心开发过程中，我们却总是未能做到这一点。所有的决策都必须具有延展性和可逆性。最简单的方法便是将游戏图像和声音留在最后时刻。当你决定游戏可以更快速地前进时，如果玩家精灵变得三倍大，你便可以使用提升精灵。而事先设计游戏图像则意味着你将更难做出这些改变。

对于开发者来说，更复杂的工作便是抵制静态内容的诱惑。创造这些挑战关卡以及编写史诗般故事对我们来说只是一种强制性的任务，但是每一块静态内容却会禁锢潜在设计选择的多样性。也许这看起来并不是什么大问题，但是当我们开始为了最后发行而优化游戏时便会发现，玩家因为缺少双重跳机制而郁闷不已，而你投入了如此多时间所创造的关卡最终只能面临死亡。

神奇的解决方法

将你自己与游戏敞开的最终方法便是添加尽可能多的动态内容。我们可以在开发循环中不花多少成本去改变程序生成内容。此外，你可以添加新的游戏机制，重新平衡资源，并改变自己的想法（游戏邦注：如此你便可以无需花费太多时间而测试理念了）。

在游戏中添加动态内容不仅能帮你打开大门，同时也能让你设置更多开发选择，而如果你添加的是静态内容，那么这些选择便会被扼杀掉。

静态内容具有边界限制，即要求你必须在其中进行设计；一旦超越了边界你便需要重新创造内容。而动态内容则会根据你的开发去改变边界。这是将内容添加到一款游戏中与在一些重复的内容中创造游戏的区别。

旁白：如何像任天堂那样进行开发

我并不是说静态内容（游戏邦注：像关卡，故事，叙述，树的解锁，角色进程等）不是游戏设计师工具中的优秀工具。作为游戏设计师，我们所尊敬的许多游戏都能够将内容与游戏玩法巧妙地融合在一起。但是如果你想提高成功的几率，你就必须向任天堂学习而不是微软。

可以说，任天堂是地球上最成功的娱乐公司，而他们的成功并不是源自内容。他们的游戏图像都很简单，角色总是能够反复使用，故事很少，并且同一关卡总是会反复出现。而最不成功的游戏（如《Fire Emblem》）则是拥有高端的图像，复杂的故事以及严格的线性进程。但是不管怎样，游戏玩法始终是任天堂旗下游戏最重视的元素。

而微软则同时呈现出吸引人的游戏玩法以及复杂的内容—-华丽的图像，诱人的故事情节，自然的线性进程以及定义明确的角色。但是比起任天堂，他们在每款游戏中投入得更多但是得到的回报却更少。

对于这两种策略都存在发展空间。但是对于任何人来说创造全新游戏玩法才是最有效的商业模式。在现有的游戏玩法中使用新内容适合那些拥有强大市场营销能力的大公司。对于像Capcom或艺电等公司来说，即使80%的游戏失败了，其它20%的游戏也能帮他们赚回损失。但是如果一款独立游戏失败了，那就没有任何备份计划了。为了提升成功几率，你最好遵循受游戏玩法驱动的开发而不是受内容驱动的开发。市场中还存在着更大的空间，让你能够以更低的成本而获得更大的成功。

开发你的社区

你的不同商业计划都需要依赖于一个健全的社区。围绕着游戏创建一个社区就像在提炼金子似得。优秀的游戏也将鼓动其自身社区的兴趣，但还有很多方法能够帮助你做到这一点：

我的名字是什么？高分板总是看起来非常空白，除非你能够在数字旁添加一些名字。创造一个名字并不是件易事，并要求更多胁迫。但是让玩家知道还有谁在那里（有多少人等等）将能更好地发展游戏社区。

我是谁？如果你的玩家在游戏中不能传达任何身份，他们便没有理由向其他人介绍自己。而注释，角色以及个人的小小空间都将促进个性化的发展，并鼓励玩家向其他人呈现自己的表现。

你是谁？如果你的玩家没有办法将自己的想法传达给游戏中的其他人，他们便只能看到自己的社区。他们不会愿意加入自己不知道的社区。将不同玩家阻隔开来会把社区扼杀于摇篮之中。

为何我是重要的？让你的玩家不只能够维护自己的身份，同时也会在乎社区对自己的看法。等级，头衔，名字旁边的星星，衣物等等都能够定义并区分不同玩家，并带给他们一种存在感和归属感。

为什么我会出现在这里？尽管你的游戏很出色，但它也不是这个世界上的唯一事物。如果你不能清楚地给予玩家游戏交待，他们将永远只能与别人讨论游戏相关内容。虽然这对于你的自尊是好事，但是却不利于游戏社区的发展，并且最终将导致社区停滞不前而最终衰败。

意义是什么？在社区中给予跳跃行动相关奖励是个好主意。持续提供给社区玩家奖励是件好事，并能够保持整个社区充满活力。

游戏是否处在一个我已身处其中的社区？利用现有的社区（就像Facebook）将让你无需为创建自己的社区劳神，并且能让你更专注于核心游戏设计中。

尽管你付出了巨大的努力，但是你的社区却可能从未出现起色。与创建游戏社区一样重要的是，你同样也需要确保它对于游戏体验并不是必然的存在，否则你的游戏便会因为没有社区而遭遇巨大的损失。考虑到离线社区和在线社区的结合，你的用户可以无需同时在线便能够感受到彼此的陪伴。

幂次定律

还有许多选择能够帮助游戏设计师更好地赚钱，我的建议是同时选择多种方法（要知道，宁可事先谨慎有余，不要事后追悔莫及）。但是现在关于独立游戏开发的最成功模式便是基于免费模式，并通过之后出售额外内容而赚取利益。这种方法之所以大受欢迎是因为开发者所获得的大多数收益是来自少数用户。而在统计和业务中，这便是所谓的幂次定律（免费游戏便是基于该定律）。即你的成功完全是围绕着自己能否说服顶级粉丝去购买你所提供的内容。但这里也存在一个问题，即人们总是很难去评估价值。

价值对于你而言，也就是所有这些内容的创造与你所投入的时间的正比。额外的内容总是非常宝贵。衣物便是额外内容的缩影，所以它们也拥有一定的价值。升级从字面上看只是一个简单数字的翻倍，所以对于你而言它拥有最低的价值。

但是玩家对于价值的看法却正好与你相反。那些能够带来翻倍效果的内容更能推动他们花钱，但是你花了1000多个小时而创造的额外内容在他们眼里却不一定值钱。

不仅如此，我们人类对于价值的判断是基于主观标准。对于你而言，创造三顶帽子需要花费等量的时间，但是它们却拥有不同的价值，并且玩家也会基于不同的标准去评定它们的价值。最有趣的情况便是，本来一顶10美元的帽子对于玩家来说可能太贵了，但是当你添加了一顶100美元的帽子时，之前的10美元便会显得异常合理了。添加了一顶1000美元的帽子后，100美元的帽子也将变得非常合理，而10美元的帽子则立刻变得非常便宜。

这便是所谓的幂次定律。大多数用户不会为游戏花钱。如果他们真的掏钱了，那也只是购买那顶10美元的帽子，并只会带来你的总收益的20%。但是那些购买了100美元，甚至是1000美元帽子的玩家却占据着你的收益的总数。所以请善待这些玩家。

卖什么（以及不卖什么）

开发者经常会犯的一个错便是关于内容的销售，即包括地图，关卡编辑器，更多故事，更多关卡以及更多角色等。根据我所遇到过的情况，可以说这是最不成功的游戏盈利方法。用户们总是会谨慎地对待额外内容的购买。有些人虽然觉得自己有权利享有这些内容，但却极度厌烦游戏催促他们进行购买。而有些人则始终满足于你所提供的免费内容。你可以通过销售内容而赚钱—-但是你却需要花费很多精力去创造内容，所以通过这种方法所获得的回报是最少的。如果将这种内容提供当成是业务模式而非选择的话，这便是你所做出的最糟糕的选择。

而销售衣物品则能够帮助你提高盈利。这是一种除了美感外，在游戏内部并不存在多少价值的物品。但是这也是一种让玩家付钱较不唐突的方法—-付钱的话你便能够获得一顶帽子。并且从开发角度来看，这也是一种很好执行的方法—-比在故事中添加一个新的章节或设计一个新角色简单多了。

而游戏中最赚钱的方法要数升级道具了，例如更强大的道具，更厉害的铠甲或者能够帮助玩家减少刷任务的道具。当你致力于创造这些道具时需要牢记，大多数讲英语的用户都很蔑视那些花钱而得来的竞争优势。所以你需要想出既能提供升级道具，同时也能确保公平竞争的方法（或至少在表面看来是如此）。如增加经验值，让玩家花钱购买能够在游戏中打开的内容，或将这种优势与分数隔离开来。如果你能够在不惹怒任何玩家的前提下提供付费升级道具，你的盈利额便会出现显著提升。

忽视游戏内部货币（即用于购买其它内部的道具），分类武器和升级道具的组合（因为它们指的是相同的东西），你便会发现升级道具和衣物品总是比其它模式更赚钱。

优化

即使走完了95%的旅程，你也仍只到达半路。——日本谚语

优化的定义：

优化是一种较为模糊的术语，即关于游戏开发的最后“5%”的旅程。这也是糟糕游戏与优秀游戏的区别。优化是关于巩固代码，完善资产，并调整游戏玩法。如果你是一名带有自己架构的规矩开发者，你便会觉得优化也是快乐的。

聪明的你会暂且将一些显著的漏洞和已知问题搁在一边，而开始检查内存管理（如果你已经忽视了它的话）。Flash开发者通常都具有垃圾收集器，能够自动删除内存中一些无用的对象—-但是附加于一个废弃对象的单一引用将继续留在内存中。而关于优化就无需过于学术化了—-如果面向的是底端设备，那就请停止优化。因为游戏玩法会遭受到你的系统局限性的束缚。

资产堆积：

着眼于所有资产，包括音乐，音效，菜单，图像，动画等等，并留意任何有可能阻碍游戏体验的内容，即使只是微小因素。你希望游戏是一个统一整体，如果出现了那些不合适的内容，请果断改变它或删除它。投入大量的时间和金钱去创造大规模的介绍动画并不是一个好主意。我知道，要你删掉一些出色的内容非常困难，但是如果它们对游戏整体不能做出任何贡献，你就不要再犹豫了。

左图是早前的《蒸汽战鹰》的图像风格，右图则是最终敲定的方案。我们可以发现最终结果并未与任何图像资产捆绑在一起。

这是我们作为未具有更高功能的人类所倾向的结果。我们拥有非常可怕的价值观，总是会将过去的成本去现在的价值整合在一起。这也是我们为何会为一辆坏掉的车不断花钱的原因—-人们总是会想，既然已经投入了1万每样去修理它了，那么再投入1千美元也总比浪费掉之前所投入的钱好吧。你自己是否会支持或忽视你所判断的任何资产的“价值”。除非它能够帮助你的游戏，否则便没有存在的意义。

旁白：掀桌

Shigeru Miyamoto与我们分享了任天堂开发团队的各种故事。他表示已经很习惯“掀桌”了，特别是在花费了几个小时进行评估后告诉开发团队抛弃之前所投入的大量工作。在团队成员心理，这些工作的价值是是由数个月的开发时间和好几千美元的开发成本所衡量的。但是Miyamoto认为，如果他所看到的是没有任何作用的内容，那么这只会对游戏造成伤害，并且毫无价值。而拥有识别这些问题的能力并命令团队抛弃它们的权威便创造出了Miyamoto的传奇。这是值得开发者们珩磨的技能。

调整阶段

当你将弹药减少到只剩一颗子弹时，游戏会出现何种变化？没有了升级道具游戏会变得更有趣吗？如果你能够有效地完成开发过程，那么做出这些设计改变便不是什么难事。但是这时候，你将不再是设计改变的最佳判断者。游戏对你的吸引力将从获得用户转向争取成功。为了明确创造出优秀游戏的细节，你需要依赖于一些诚实的玩家进行追踪。

反馈就是上帝

我只是想说：获得新鲜的玩家反馈在游戏设计中是非常重要的一点。你拥有30秒钟的时间能够从玩家身上获得有关游戏的反馈（这也是为什么你总是需要一些新鲜的测试者）。根据Malcolm Gladwell，人们的第一印象，也就是眨眼反应通常都只是若干秒钟的功夫。所以如果只需要花费几秒钟便能够获得玩家的游戏总结，并花几秒钟让他们将其转化为文字，那么你便能在极短的时间内获得来自玩家的诚实反馈。但是这些反馈却不一定有用，它们也许只能告诉你一些已知的信息，，例如玩家只是因为你不能有效识别相关元素而讨厌游戏理念，或者他们不能直接传达自己对于游戏的看法，又或者是你的测试者对于自己的反馈并不诚实。所以你必须谨慎地埋伏在这危险的区域中，想办法获得最有效的反馈，如果说这是游戏设计中最重要的环节，你又该如何执行呢？多年来，许多开发者所给出的答案都只是投入更多金钱或资源，但是今天，我们将推荐一种更廉价且更精确的工具，也就是分析。

使用有意义的分析

你可以使用许多工具去进行分析，包括为自己定制一个解决方案，或者使用像Playtomic（游戏邦注：游戏数据分析公司）所提供的信息。但是不管你的选择是什么，你都需要一种快速且可行的方法去收集并了解玩家数据。包括他们玩了多久的游戏，什么时候选择放弃，他们是否会关掉音乐，他们在游戏中死了多少次，他们会盯着启动屏幕多久，他们是否会离开游戏一段时间，是否会选择再次回归，他们是否会给自己取名，是否会遇到任何错误等等。但是因为最初几秒在玩家的思维中都较为格式化，所以你需要确保分析数据是前载型。对于玩家所走出的每一步（从点击开始按键到介绍的结束），你都要设置分析点。也许这听起来太过夸张，但是如果能在用户按压第一个按键前发现时间比例的失衡，你便有可能找出之前未曾发现的主要设计问题。

从图中我们可以发现第一个目标（观看开始视频）与下一个目标（完成教程）之间具有较大的落差。

你可以通过分析图表获得大量信息，但同时你也必须想办法在各种随机去问玩家一些简单的反馈问题。让他们基于游戏体验为游戏评分便是一个很好的开始—-只要你拥有一些数据能够进行对比便可。只玩了2分钟游戏的玩家给出较低的评分而玩了5分钟游戏的玩家给出较高评分便意味着前2分钟的游戏设计有问题。你可以基于自己的创造性去解决问题，或者请求玩家的帮助。评论框与分析相配合总是能够起到非常棒的效果。如果有越多用户帮你测试游戏，那么评论就需要保持越短，而你更需要以理智的心态做出判断。明确地问自己，是十几条清晰的评论更有帮助，还是由无数贡献所构成的完整文子云更有效。不同的游戏以及测试的不同阶段可能需要不同的方法。而你需要做的便是确保测试的顺畅，敏捷且即时。

同时我们也需要记得你所感兴趣的统计不一定是你需要用于设计中的统计。《荒野大镖客》的创造者Rockstar拥有许多有关玩家杀死更多乌鸦，而不是其它生物的统计，并且比起其它游戏活动，他们更频繁地参加乌鸦射击活动。虽然这一统计非常有趣，但却对游戏设计没有任何意义。乌鸦是否会因为它们是射击挑战而被选中？因为它们的数量足够多？它们足够有价值？还是足够惹人烦？因为它们是诱饵？因为它们并不会反击？还是因为这只是一种设计缺陷，即在任何低于42清晰度的电视上，乌鸦将变得最清楚而其它动物只会融入背景中？因为找不到任何方法去分隔并评估你所收集到的数据，所以你所做出的设计决策可能完全区别于那些数据想要传达的问题。

为什么会有一个蹲伏按键？

游戏中一大华丽的创造性（或者是在整理的界面设计中）便在于许多游戏设计行动不再要求一大把按键了。与上下文相关的行动按键将拯救之前复杂的设计，即让玩家能够只按压一个按键便可以完成更多控制。

而设计世界，不管是苹果还是任天堂都开始限制给予玩家的控制。他们通过减少功能和能力去交换简单性，但同时在其它按键中仍保持着基于上下文的方法。苹果甚至将其压缩到只剩一个手指滑动控制。而主机制造商们也将控制减少到只需用户轻敲指关节便可。基于这些超级简单的行动，整个世界变得更加开放了。

而这种变化对于游戏来说意味着什么？这意味着你的用户不只是期待，甚至会要求界面至少需要具备活跃的互动功能。当玩家跑向一个混凝土石柱寻求庇护时，他们不再想要按压一个额外的按键而做出蹲伏动作，他们希望游戏能够理解自己与环境的互动。这是一种自动反馈。着眼于你的界面，按键，命令和功能，如果有哪一项具备自动性，请好好利用它，因为你将能够因此挽留住更多用户。《都市大逃亡》便是一款不存在任何按键去控制移动的平台游戏。阻碍游戏乐趣的主要元素已经被删除了，所以便成就了这么一个成功的设计选择。

此后，你所面对的便只剩下那些有助于设计的功能。现在你的任务便是进一步简化它们。是否能将这些功能结合在一起？它们能否作为子功能而去执行更普通的命令？最大胆的是，它们能否被忽略？最简单的界面应该是更加自动化的，不需要添加多余内容去告诉玩家该怎么做。而你接下来需要考虑的便是如何教授玩家玩游戏。

教程

如果你与我一样是是玩着主机游戏和PC游戏长大的，你便会发现许多游戏总是使用一些极端糟糕的方法去教授玩家如何游戏。因为开发者认为，既然玩家已经花钱购买了游戏，他们便会愿意花时间去学习如何游戏。在免费游戏市场中更是如此。如今开发者所呈献给玩家的游戏总是包含着游戏内部教程以及反复的学习强化内容。

如果你想要创造出最合适的教程，你就必须考虑到以下三点内容：

玩家进入游戏时至少需要掌握何种内容？游戏的核心行动是什么？你能够直接引导玩家的绝对最小值是什么？玩家可以凭自己的力量发现什么？

如何让玩家基于自己的节奏进行学习？如何确保指令简短而清晰，并保证所有人都能够理解？如何确保玩家在前进前能够吸取适当的经验教训？

如何将教程无缝地整合到游戏中？能否将与游戏中相同的语言和角色作为教具？能否将游戏中的氛围（如紧迫感）呈现在学习环境中，或者需要以某种方法进行改变？

关于教授一些简单的内容并不存在什么简单的方法—-你必须假设自己同时面对着领悟能力较差的人与领悟能力极强的人。幸运的是已经出现了一些经过验证的好方法了：

演示版本（如《吃豆人》，《Joust》，《明星大斗乱》）：无需互动而将游戏的主要理念呈献给玩家。这种方法比指示页面实用多了，因为它带有视觉强化效果，但也仍具有一定的缺陷。不过对于那些街机类游戏而言就已经足够了。

路标（如《战神》和《侠盗猎车手》系列）：当玩家需要知道自己该做什么时，你的游戏将通过文本，路标，屏幕提示以及“暗示”等功能告诉他们。这是一种持续的上下文教学，即将把复杂的行动分解成一系列学习点。这适合于那些基于玩家与环境间复杂互动的游戏。

沙盒（如《超级马里奥64》，《塞尔达传说》系列以及《时空幻境》）：当你的玩家是从一个安全的区域开始游戏，并面对着各种控制时，这便是最佳方法。玩家将沿着你所提供的路径走向更危险的区域。这将确保玩家不会过于疑惑—-因为当他们第一次遭遇问题时，他们便已经知道如何应对它了。这种方法适用于探索类游戏和基于物理原理的游戏。

零关卡（如《《皮克敏星球历险》，《蒸汽战鹰》）：这是一种安全关卡，即不包含任何失败选择，只是关于前进与学习。最棒的零关卡便是完全由玩家口述完成的，即他们的学习曲线是由自己所陈述的而非游戏。需要注意的是，我们必须在第一个关卡中尽快完成这一任务；因为如果花费的时间过长，你便会发现它的作用逐渐减弱了。这一方法适合那些通过特定机制的策略执行体现出策略，而非通过大量命令和功能的游戏。

Sensei（如《模拟城市》，任天堂的“Super Guide”功能）：Sensei是一种允许你犯错误，并且会在之后告诉你如何纠正错误的向导。如果玩家愿意从自身错误中吸取教训，那便比预先的教程更有效，并且能够帮助他们更好地克服挫折。这种方法适合有关长期发展的游戏以及带有许多独特障碍的游戏。

选择一种最适合自己的方法，并将其整合到游戏中，让玩家能够按照自己的基调进行学习。首先你必须清楚，你是在呈献给玩家该做什么，而不是告诉他们。比起直接告诉，引导玩家走向问题的解决方法总是更有效。这与“按压空格键跳跃”和“按压空格键”的区别一样简单。

《时空幻境》便有效地呈献给玩家教程而不是直接告诉他们该怎么做。游戏中设置了各种视觉线索，但却不包含游戏指令。

毕竟，如果你不能有效地传达给玩家你需要他们做的事，那就说明游戏设计存在问题。假设你创造了一款太过复杂的游戏，而现在你需要做出选择，即要么推出一款濒临死亡的游戏，要么删除那些你所自豪但却会迷惑玩家的机制。

你是否会向玩家收钱？

我发现许多贱卖自己作品并因此影响了利润的开发者们都走进了一个误区：他们不知道如何向玩家要钱。他们将自己所提供的内容隐藏在主屏幕的一个小角落里，甚至是在次菜单中，而让玩家在游戏中游走了几个小时还是未能找到任何购买选择。从市场营销角度来看的话，这便是彻底的失败。

关于最后优化阶段的一大组成部门便是确保你所提供的游戏道具和内容能够反复赚钱，并且是容易理解且吸引人的。想办法改掉广告是烦人的这一想法。只有当它破坏了游戏体验时才会让人感到厌烦—-所以请果断将其有效地整合到游戏中，保证没有人会感到抱怨。

重复提供内容能够确保玩家始终都能在关卡与关卡间购买自己想要的内容。这不一定总是在向玩家要钱，而是在提供更多能让他们进行互动的内容。将你的免费内容（或者游戏内部货币）与付费内容一起呈献给玩家，如此他们便会更加适应这些内容。而如果你养成了隐藏内容的习惯，那么当玩家看到这些内容时便会感到厌烦。定期向玩家推销你的商品更能引诱他们去掏腰包。

比起隐晦的内容，容易理解的内容往往更具有吸引力（这也是为何销售帽子总是比销售关卡更成功）。当玩家在游戏中表示想要获得更多信息时，你就必须确保他们能够随时获得这些信息，并能够轻易理解这些信息。切忌撒谎或夸张化，不要留下任何惊喜。“还有更多”的表达只适用于你已经明确跟他们说明这一所谓的“更多”是什么。如果你所扮演的更像是推销员而不是信息来源，这将大大破坏你所传递的信息。

诱导玩家去购买你的商品就像是一种艺术。显然，定价非常重要，特别是当玩家所面对的是“散装”交易时。但是除了定价结构，最吸引人的还是你所提供给玩家的信息。如果你呈现出了易懂的内容，那就已经成功一半了。但是因为你能够呈现的总是多于你所阐述的，所以就让玩家开始游戏吧。如果玩家所购买的并不能直接延伸自己当前的体验（例如对现有机制的升级），那就让他们将其当成一种试验或演示进行尝试。让玩家观看付费体验的演示版本——如果这能够吸引他们的注意，那定也能够引诱他们花钱。

但是我们仍需要清楚，在所有的这些过程中反馈仍然是最关键的——定期邀请新用户去测试新内容将帮助你获得更多有关发展方向的重要信息。而当这些用户对你的游戏充满信心时，你也会是如此。

发行

我的剧本本身非常成功，但是在吸引观众上却遭遇了失败。—–Ashleigh Brilliant（1984）

第一个平台

关于发行你需要做出的第一个决定（在开发过程中所做的）便是目标平台。这一特别的理念总是处在不断的变化中：基于Flash而开发并作为SWF格式进行分布的游戏能够进入谷歌的App Store中，但不同的开发者都在争论着到底哪个“平台”才是最佳目标。不管怎样，你都必须确保玩家能够接触到游戏，而你的心中应该也浮现出一些对象了，例如：

Facebook：该平台对游戏设定了相关政策，但是该政策却有利也有弊。它拥有完美的分布，惊人的流量以及能够用于访问社区的各种强大工具。但不可否认的是它也具有各种缺点，如充斥着上百万美元的竞争，并且平台规则太过束缚。

苹果产品：作为应用经销商，苹果具有让人称羡的优势，能够为用户提供大量的应用。苹果制定了严格的开发者协议，并会向开发者抽成30%，并且其平台上最畅销应用也能一直占据着畅销之位，即排行榜顶端上的位置很少发生改变。这是一个具有巨大竞争性的市场，每一款游戏都担负着巨大的资金投入，但也仍为新投机者留下一定的空间。不过我们也不能高估他们的用户，因为尽管苹果拥有巨大的应用业务，但是覆盖面却始终不及Facebook。

其它手机：没有一款手机设备的市场营销能力可以胜过苹果，但是Android市场正在迅速发展着。我们同样也需要记得那些市场处于供不应求的状态：用户可以在其它手机市场中找到未能在苹果商店中获得的需求。（例如Spryfox的Kindle游戏）

基于浏览器（Flash）：Flash游戏拥有一个巨大的市场，但同时也具有资深的盈利问题。虽然这种情况在最近发生了改变，但仍有许多Flash门户一直在抵触开发者通过募资和广告之外的方法赚钱。许多成功的商店都是源于开发者在Flash世界的试水并通过募资而筹钱，然后发行游戏更新版本赚取利益（通过续集内容的应用内部购买或微交易模式）。尽管一直涌现出各种竞争者，但是Flash市场每一年都能赚取巨大的利益。

基于浏览器（其它插件）：Unity是Flash的绝佳替代品，但是我们却很难找到足够的记录去证明它是开发者的最佳业务模式。虽然其它插件都是不可小觑的黑马，但是它们能够带来成功的几率却仍很低。

基于浏览器（没有插件）：还有很多人在谈论有关HTML5等脚本语言能够替代Flash在网页上创造游戏内容，但是除非我们能够找到一个面向无数网站进行分布的简单方法（Flash便可以），否则它们将仍只是传说。对于那些并不要求广泛分布的浏览器游戏来说这便是一种好方法，特别是当谷歌最近在努力做到让浏览器能够访问其平台上的所有应用，而Abode的演示程序甚至能将整个Flash文件转变成HTML5。

三大巨头：曾经开发者们认为面向索尼，任天堂和微软发行游戏是在做白日梦，除非你拥有强大的后台和足够的金钱。而现在这种情况发生了改变，并且这三大平台上的许多独立游戏也开始转向其它平台，并拓展自己的市场。甚至这三大巨头有可能沦落为游戏所选择的最后一个发行平台。

Steam：Valve的Steam服务拥有较小的用户基础（相对于Flash或Facebook），但是因为Steam能够很好地控制他们的内容，所以其用户基础都能在此看到非常出色的内容，并愿意投入大量的金钱。虽然这是面向Steam发行游戏的粗糙过程，但是一旦你进入了该平台，你就无需再担心收入问题了。所以说这是一个值得尝试，但却不适合做长远计划的平台。

台式机：虽然《我的世界》已经向我们证明了这不是一种被废弃的理念，但是在充满盗版，黑客以及通用平台被荒废的时代里，PC也成为了最难瞄准的平台，特别是当谷歌于2011年强行进入操作系统市场时。尽管如此，这仍是一个存在着巨大机遇的供不应求市场。

这既不是一个综合列表，也不是对某一平台的宣传。到底选择哪个平台是基于你作为开发者的优势以及目标用户群体而言。就像单人游戏并不可能在Facebook上取得巨大的发展。需要一个小时游戏时间的游戏则通常选择面向iPhone发行。带有持续教程的游戏不可能在浏览器上取得成功（因为玩家投向该平台的注意力都很短暂）。你应该明确每个市场的优势和劣势，并将其与你游戏的独立机遇进行比较。

完成的错觉

如果你有在关注设计和艺术世界的动态，你便会注意到很多人在谈论“完成”作品的贬值。如今的博物馆陈列出了更多互动式作品，艺术家们也一直在琢磨新方法去呈现出作品的活跃性，而观众也能通过这种创造性过程进一步投入其中。反映社会作为一个群体的广告也向我们呈现出了更多过程而不再只有作品。可以说，如今的我们对于文化的延展性及其永无止尽的混合内容更感兴趣。

而这种情况会带给游戏何种影响呢？简单地说，即使你认为完成了游戏，但是你的游戏却未曾真正“完成了”。就像软件公司和开发商们都坚持发行的是完整且无漏洞的作品，但是他们很快就会发现自己需要或想要推出一些更新内容。

对此我们需要考虑到3大事项：更新能力，调整能力以及知晓何时和需要更新内容的能力。

更新：更新游戏的能力既有可能帮助你在推广游戏所做出的各项决策，但也有可能将其彻底摧毁。如果你不受任何人的控制，那么更新游戏就如加载一份文件那么简单。但是如果你受到那些帮助游戏推广的人和组织的控制，你就需要先明确一份合理且公平的更新协议。

调整：面向用户调整游戏应该是轻松的，且不需要完整的更新。你可以通过将游戏中某些变量的价值储存在游戏的服务器中，从而让自己能够随时进行修改。

何时进行更新和调整：你需要想办法找出用户正在体验的内容，从而让你能够适时且精确地做出调整与修改。你可以通过用户的评价进行修改，但同时你也可以使用分析工具。

分析工具将帮助你划分玩家在游戏中做些什么，他们选择了怎样的武器，他们走了多远，他们死掉的频率是怎样的等等。着眼于分析图表上的数字，你将会清楚地发现问题所在—-如果在第四个关卡期间掉落了很多用户，即平均第四个关卡死掉的用户数最高，你就应该知道要怎么做了。如果用户在购买了升级道具后不再使用，你便能够猜到是道具有问题，而应该对此做出修改。如果你做出了合理的分析，你便能够轻松地解决所有潜在的问题，从而帮助你更有效地调整并更新游戏内容。

定价

如果你所面向的是付费下载市场（就像苹果的应用商店），你就必须在发行前明确游戏的定价。

在发行时做出定价决定其实就是一道非此即彼的命题—-要么为游戏收费，要么免费出售。如果你的整个业务模式是基于事先赚钱的话，那么你就无需纠结了。但是如果你想要通过在游戏中出售商品或衣物而赚钱，那么你的选择便会混乱些。你是否免费出售游戏并希望游戏内部的销售能够弥补收入损失？或者你是否预先收费以避免失败？

我们还有许多需要考虑的变量，而最大的未知变量便是成功。虽然我们找不到准确的答案，但却能够发现正确的方向。让我们再次回到幂次定律。

拉斯维加斯业务模式

内华达始终走在世界业务模式发展的前列。而拉斯维加斯则以少量的客户发展着巨大的业务。可以说，该城市95%的收入是来自5%的客户，也就是狂赌者，大厅承租者以及相关活动组织者，所以它又有和理由去迎合那些只能带来5%收入贡献的上百万旅游者？

主要有两个原因。首先，最底层的消费者都有转变成上层5%贡献者的潜力。其次，如此才能让狂赌者不可自拔—-不是关于金钱，而是关于地位。那些狂赌者需要身边环绕着许多观众，否则精英也会失去光环。所以拉斯维加斯便利用这种方式让他们感受到自己的高高在上—-你花的钱越多，你便享有更多特权，不管是桌上的饮料还是总统套房的舒适享受。所以他们的客户才愿意继续为此花钱。这便是幂次定律的表现。

使用免费模式

免费模式与拉斯维加斯业务模式类似，但却更加强大。首先便是满足用户的需求，提供任何他们想要花钱的内容。让我们假设你创造了一款玩家喜欢的游戏。如果它售价10美元，那么那些真心喜欢游戏的玩家便会购买，但是那些认为它只值5美元的玩家将面临2种选择—-不玩，或者盗取它。如果将价格将至5美元，你仍会遇到相同的问题（也会出现那些认为游戏只值1美元的玩家）。而当你决定免费出售游戏时，你的玩家群体便一下子拓宽了—-不再会有人说其价格不合适了。现在你便拥有连拉斯维加斯都会嫉妒的用户。

当人们拥有了你的游戏后，你需要想办法从那些认为游戏价值1美元的玩家身上赚取这1美元，并从那些认为游戏价值5美元的玩家身上赚取5美元。你还需要采取其它方法从那些超级用户（即非常喜欢游戏并愿意花钱继续玩游戏的玩家）身上赚取10美元或者更多的利益。每一位玩家都是潜在的付费用户。如果你为游戏定制了一个价格（而不是免费），你便等于排除了上千名玩家，当然也包含了付费玩家。他们将永远不会成为做出最大收益贡献的5%玩家。

这么做似乎充满风险。但是如果你和测试用户都对游戏充满信心，你就需要相信当你向玩家要钱时他们会伸手去掏腰包。

调整价格点

当然了，在数字网络发行内容最棒之处便在于，任何决定都不是终点。如果你的发行商伙伴同意的话，你便能够任意改变价格点。你可以基于较高的价格发行游戏，进行市场测试，并相对地降低价格。或者你可以提供一个免费版本，并广泛宣传这是限时优惠，然后在不久后提升价格，并观察玩家的反应。你的决定将对市场造成直接影响，所以无需对此感到担忧。

不过通常情况下开发者并不会常常做出这些改变—-你必须基于微交易商品的价格而对价格点进行持续监控与调整。根据分析，你可以明确最大的买家以及表现较糟糕的群体，并通过调整基准价格去推动游戏内部经济的发展。如果你的商品定价能够越接近用户心中的价值点，你便越能够达到最理想的财务状况。

当然了，你也不要忘记限时优惠和促销的诱惑。你可以定时提供促销商品或特定用户促销，即与玩家的游戏历史和风格整合在一起（或者他们的生日！）。又或者，你也可以提供两种促销模式并对此进行分析，以观察哪一种更具吸引力。

走向多平台

假设你已经取得了一定的成功，你的游戏也足够稳定且具有足够的活力能够转战其它平台。只有在这时候我才会鼓励你去创造新内容：新平台能够提供给你很棒的机遇去推出新功能，新的游戏模式，新动画，新音乐等等。这也能够帮助你提供给社区玩家他们想要的内容，同时推动着他们为游戏再次花钱。不过在新平台上的再发行也具有内在的负面含义，即代表你背离了最初的用户，并且在新平台上也会展现出低人一等的姿态。不过通过添加新内容到再次发行的游戏上，你便能够推翻这些负面假设。而你也只是在尝试之前因为游戏太过膨胀而不得已删掉的一些功能。

如果你能够走到这里，那就恭喜你了，因为你已经设计出一款能够取得成功并带来巨大收益的优秀游戏了。

总结

原型——只有你自己才能证明自己的理念是否可行。所以请尽可能地去实现它。

游戏玩法便是全部——从最初的开发到最后的优化，你必须始终优先考虑游戏玩法。如果你的游戏玩法太过模糊，那就进行修改，直到你最终能够清楚地看到它。

内容上帝——对于独立开发者而言，创造只有一个解决方法的静态谜题无疑是最大的冒险。而创造带有无限解决方法的动态谜题才是通向成功的方法。

反馈也是上帝——如果未能频繁地获取新鲜反馈，你的设计将逐渐退化，并需要做出巨大的改变。频繁地从新测试者身上获取反馈将带给游戏莫大的帮助。

重视幂次定律—–要知道你的绝大多数收益是来自5%的突出用户。所以你需要想办法在游戏中引诱他们花钱。

不管怎么所，本文所给出的也只是建议，而你真正需要做的便是听取这些建议，并根据自己情况进行删减，测试，思考并讨论。

（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Indie Games: Designing to Succeed

Posted on January 19, 2011 by Tony

The discipline of game design is changing. More accurately, what the world has come to expect from game designers is changing. Games are becoming ubiquitous, the industry has grown by billions of dollars, distribution is no longer a barrier to entry, and the tools exist to not only for indie designers to make games with passion, but to make games with profit. As our medium expands, so too do the rifts between the indie crowd and the triple-A studios. Fewer studios cater to the console market than ever before, and the gigantic opportunity that remains for everyone else is fought for by thousands upon thousands of developers and publishers in a highly competitive, rapidly changing marketplace. Stories of success are told loudly enough to drown out the countless failures it takes us as a community to get there. Hours, months, hearts and lives are poured into games, and what they return can be cripplingly low.

It should be the intent of every serious game designer to set out to succeed, in terms of both game design and profitability. To continue working on what we love, we have to be pragmatic and business minded as well as creative and hard-working. There are a wide variety of avenues towards this kind of success, and choosing the right ones while avoiding the wrong ones will help create a game that is designed to succeed.

The golden rule of game design is that if the game itself is of exceptional quality, it will succeed despite any shortcomings in its business plan. Games like this are rare, though we all seem to set out to make one. What follows here is not a recipe or guide to exceptional game design. Instead, this essay is meant as a road map to maximize your chances of your game becoming successful, from conception to release. It looks at everything from coding practices to business practices in an attempt to clarify common and critical mistakes, and point indie developers into a profitable direction. Everything here is backed up with research and examples, but the game industry is in such a state of transition that the research can never be up to date. Take this pile of advice and suggestions with a dose of healthy apprehension.

Conception

Genius is only a greater aptitude for patience. – George-Louis Leclerc, 1803

Give Form to Ideas – Prototype

In the world of design, from games to architecture to cars, ideas are nearly worthless. They are common, they are cheap, and they are part of the imagination. Everyone in the world has an imagination, and yours is no different. I have imagined no less than a hundred concertos, a thousand paintings, and a million plot twists, despite being inept at those forms of expression. For your imagination to capture anyone, it has to evolve – you have to give your idea a form, and in the case of game design, that means making a prototype.

Prototyping is fast, agile development where you can test out your ideas and see if they’d actually make a fun game. Many game designers working in 2-D development will tell you that if you can’t make your idea work and make it fun by the end of a weekend, you should leave it behind. Not having much programming background myself (or any, before I started my first game), I would say you can give yourself a little longer, but the basic rule stands. Prototyping means getting in there, throwing some ugly crap on the screen, implementing some basic controls and a simple game loop, and checking to see if there’s any promise there. If not, your idea didn’t work, so move onto the next one. If there is a glimmer of promise in an otherwise horrible prototype, make a new prototype and repeat.

I Know My Idea Works, so I Don’t Need to Prototype

Stop. The only way you can know something is by proof, and if there’s proof out there, then it isn’t your idea. If you’re cribbing off an existing game design, fine – our industry is built on it. But if it really is a new idea, you cannot know that it works until you test it out. Game design may feel like it’s about emotion and conviction at times, but more often it evolves through a scientific process of trial and error, thesis and antithesis, experimenting and testing your ideas. If you’re not willing to put your own assumptions to the test, then I can guarantee one of two outcomes: either the development will never finish, or the final product won’t be worth the work put into it.

Prioritize Gameplay

This idea is going to come up a lot, and it starts early. During prototyping (and every phase after), make your gameplay shine regardless of any of the surrounding content. This is advice that holds from the tiniest indie game to the next Mario platformer. If your idea is about a narrative, about level progression, or about any sort of static, unchanging content, then you are setting yourself up to fail. But if your idea is about gameplay, and you can make that fun, then adding that static content later will preserve good gameplay – rather than stellar static content obscuring the fact that the gameplay is much less than it could be.

Think of all the games you’ve owned in your lifetime that you sold or traded or deleted or forgot. Compare those games to the ones that have been on your shelf or hard drives for years. The key difference between those one-time game experiences you threw away and the infinite experiences on your shelf is the refreshing gameplay, and little else.

Neglect Static Content

Static content has no place in prototyping, and not a lot of value elsewhere either. That statement is going to upset some people, but it’s critical for setting yourself up for successful game development. Designing a game around something static, like a story, is handcuffing yourself. The static content will force design decisions and prevent you from making better ones. Countless games fall prey to this – where players continue playing in order to finish the story, or conquer the final level, rather than play the game because the gameplay is keeping them interested.

The replacement for static content is dynamic content. Dynamic content is content that is procedurally generated by the game, rather than preset and deployed into levels or narratives. A brilliant example is the difference between a static platformer and a dynamic one. The Mario games have static levels with minimal dynamic content (the level can vary slightly based on the player’s path taken, I suppose). The game ceases to be a challenge once the level is memorized. Meanwhile, Canabalt is an entirely dynamic platformer, using randomization to ensure a challenge on every single play. Both are excellent games, but as indie game designers, we have to weigh the costs and benefits of producing dozens of static levels against making one dynamic one.

At each motion to include static content, possible doors are shut. The earlier the static content is included, the more restrictive development gets.

Aside: The Curse of Franchises

Existing franchises from other media (like film or toys) are poison to game design and you should avoid them wherever you can. Even the most magical and game-ready franchises can rarely be turned into a half-way decent game. Content is vastly prioritized over gameplay, but even if that’s not the case, the content shapes and molds the gameplay in thousands of invisible ways. Working with a franchise is like painting a landscape, but the foreground has already been crayoned in. It becomes your job to make the best of it, a task no one could fault you for failing.

As a quick case study, imagine your character running around in an environment dominated by water. In order to make your character’s weapon pop out, you’ll want to pick a colour that stands out against the background. The best possible design choice for this particular game is a glowing gold weapon – except you’re making a Pirates of the Caribbean game, and your main character wields a very specifically designed iron sword. It’s only one choice to compromise on, but there are always more. The number of fights, the variety of settings, the range of playable characters, the fact that the story can’t be interactive since it’s already been determined, the music, and more.

The counter-argument is that great works can arise from great restrictions, as many artists will attest to. Franchises can produce good games – Batman and Star Wars both come to mind – but they are franchises that tend to have an amazing pool of choices to pull from. Batman has been interpreted by thousands of artists, so audiences are primed to accept new designs and directions without question. Star Wars has a universe-sized mythos and is no longer restricted to existing narratives. But the cards are still stacked against the developers as the restrictions are always going to be more abundant than the opportunities. If they can rise up to meet the challenge, all the power to them, but it’s a recipe for disaster much more often than a recipe for success.

Progress, Obstacles and Resources

All games, from chess to the latest Halo epic, share three primary mechanics in different forms. This is the basis of all game design, and it’s important to identify where your balance lies while prototyping.

Progress is the idea of growth, development, and escalation. For most games, the simplest example of this is a score, but it stretches much further to level progression, character enhancements and an evolving story.

Obstacles are barriers to progress that must be overcome. It doesn’t have to be destructive like killing an enemy – it can be transformative instead, like a quest. But for it to work, it has to stand in the way of progress.

Resources are the tools you give players to use against obstacles, and occasionally spend on progress. They can be infinite like jumping or running, or finite like power-ups or hit points. They can also be much more abstract, like board position or even the player’s own creativity.

It’s important to look carefully at your balance between these three early and often. A game with lots of obstacles for little progress is a grind for players. A game with too many resources can get convoluted if there aren’t matching obstacles to use them with. If progress is constant and eternal, the game becomes boring and repetitive.

But backing away from the game design a little, it’s critical to identify your progress, obstacles and resources so you can think about how this game is going to make money.

Identifying Your Sales Opportunities

Assuming you’re taking a microtransaction business model, you’ll want something to sell in your game. This is where breaking your game into Progress, Obstacles and Resources comes in handy.

As a general rule, selling obstacles isn’t very profitable and it takes a lot of work to create. This extra content, like extra levels or more story, should be paired with additional progress rewards for overcoming the obstacles.

Selling progression alone can be profitable, but it’s nearly impossible to do without angering your users. Where progress is for sale, it’s most commonly sold outside of a game system by a black market – buying save files and online characters, for instance – and your core players won’t stand for it.

Selling resources, on the other hand, is a highly profitable and player-accepted form of monetizing your game. While prototyping, you have to keep this in mind, because a good game design may leave you no options for selling any resources. If there are no limited resources, nothing for the user to replenish or increase, then suddenly you are in the business of selling obstacles and their progress rewards, which is a much tougher business model. It’s not a bad business model, or the worst, but you’re making the conscious choice to leave the prototyping stage with a weakness.

Above all, be creative. Resources include anything that you can enhance or power-up – anything variable or constant in your game that you can double might be a source of tremendous revenue. If you can find something, (or preferably, many things that you can choose from later), then you’re on your way, and can begin development.

Development

Work would be terribly boring if one did not play the game all out, passionately. – Simone de Beauvoir, 1966.

Architecture for Success

As a programmer, no matter the programming environment or tasks in front of you, someone out there has made something for you to use and learn from. Your first job is to go look for it. No matter how you choose to develop, and in what language, there are hundreds of libraries from simple animation helpers to pixel-blitting engines, massive physics simulators to 3-D modelling. If you’re choosing to build it all yourself, make sure you’re doing it for the right reasons. Developers have a habit of getting stuck building the perfect game engine or coding as if it were for a master’s thesis. There’s plenty of great code from your peers out there. Use it.

Of course, you should also code well, and code well the first time. All of the principles of object oriented programming are important to programming games as a whole, but it is the principle of modularity that most benefits quick, agile design. Make test cases, swap them in, swap them out, change everything about them, reverse them, plug them back in and keep developing. The better your code can handle big gameplay changes with simple class or variable swaps, the more options you have open to you in a day of development.

Aside: Variable Driven Development

I’m a huge proponent of setting up my files in what I call “variable driven development”. In one or a small group of classes, I set up lists of constants that have a number for everything. Everything. Camera zoom, aspect ratio, player height, base speed, enemies per wave, damage per cannonball, hit points per enemy, reward per kill – everything. When I create constants, they’re often multiples of other constants. And when I create individual classes, I make sure to reference these constants rather than internal numbers – so when I want to speed up an entire simulation, I can do so by changing one constant from 50 to 100, and the game automatically manages everything a massive gameplay change like that could possibly touch.

The other great thing about developing in this way is that you can set up a live panel to adjust your variables on the fly while play testing, instead of re-compiling every time. Would the game be more fun if I doubled the number of power-ups but halved the player’s timer? Two key strokes and I can find out.

A panel to adjust variables on the fly means instant feedback on a wide variety of design decisions. There’s practically no cost to test different scenarios.

While I’m on the topic – when you’re tweaking your variables to get the right balance, start by either doubling or halving the number in question. Chances are it won’t feel right – but it will feel different enough to let you know if you’re on the right track.

Play-Testing

Get strangers to play test your game at every single stage of development. They will often ask the stupid questions and make stupid comments, while your stock answer will be “I haven’t built that part yet”. But they will also provide you with insights that come from things they find obvious but you can’t see while mired in code.

This is such an important step that I’m going to say that all again.

You cannot see some of the most obvious problems with your game without another set of eyes. The more sets of eyes you have, the more insight you’re going to get into your game. Get out there, and get people to give you feedback. Identify problems early, and identify them often.

Keeping it Simple

Simplicity is your friend while developing:

The simpler your game is, the more likely you are to change something that isn’t working. As it becomes a lumbering behemoth of dependencies and one-off bug-fixes, those changes become a lot less enticing to make.

Releasing a simple game is the best way to test the market. You have to consider the possibility that despite your best attempts, the game may be a flop. Releasing the simplest possible game that still is in line with your vision will test your core design against the market and its unpredictable forces. You can always make a sequel. Always.
Simple designs keep the fun visible. Your game was fun as a prototype – stray too far too fast and you’ll lose it. Try omitting seemingly critical gameplay while developing to keep your mind searching for more fun. It’s a simple matter to try your game without a lose condition (or a win condition) – if it’s more enjoyable, then it’s worth considering for the final product.

Complex systems are still vitally important for some of the deepest aspects of your game, but take the time to master the components (and cut the ones that you find aren’t needed) before stringing everything together.

Leaving Doors Open

At some point in development, you will have to start making design decisions that are set in stone instead of sand. That’s a great place to be – but during core development, you are not at that point. Every decision should be malleable and reversible. The easiest place to do this (for some developers, anyway) is leaving the game art and sound until the last possible moment. Work with stand-in sprites and the like – when you suddenly decide that your game could go a lot faster if your player sprite was three times larger, there’s no harm done. Doing the game art early just means those changes become more painful to make – and you’re less likely to make them.

A lot harder job for developers is resisting the siren call of static content. Building those challenging levels and writing that epic narrative is just so compelling to us. But every piece of static content that gets included locks down a huge variety of potential design choices. It might not seem to be an issue – but when it’s time to start polishing up the game for release and your players get insanely frustrated at the lack of double-jumps, all of the sudden those levels you spent so long on are dead weight.

The Magic Solution

The ultimate way to leave doors open for yourself and your game is having as much of your game as possible be Dynamic Content. Procedurally generated content can be changed late into the development cycle without a significant cost. What’s more, you can add new game mechanics, completely re-balance resources, and generally change your mind (and have the means to test your ideas without losing too much valuable time).

The addition of dynamic content to your game leaves your doors open, allowing you many continuing development options, options that static content kills.

Static content has boundaries that you must design within; wander outside of it, and that content needs to be remade. Dynamic content has changing boundaries that react to your development. It’s the difference between placing content inside a fun game, and making a game inside some repetitive content.

Aside: How to Develop Like Nintendo

I wouldn’t dare argue that static content, like levels, story, narrative, unlock trees, character progression and more are not good tools in a game designers toolbox. Many of the games we as designers look up to are brilliant melds of content and gameplay, seamless and brilliant. But if you are trying to maximize your chance at success, you have to be more like Nintendo and less like Microsoft.

Nintendo is one of the most successful entertainment companies on the planet, and it doesn’t come from content. Their graphics are simple, their characters are re-used over and over again, their stories are rare and their levels are re-visited many times in a game. Their least successful ventures (like Fire Emblem) have high-end graphics, compelling stories and a strict linear progression. But regardless of the game, the gameplay is always given top billing.

Microsoft is capable of taking captivating gameplay and applying amazing content – stunning graphics, compelling story-lines, natural linear progression, and well defined characters. But they spend more and make less than Nintendo per game.

Nintendo has long made their money in innovation rather than perfection. They create markets like the desire for touch screens and motion control, pet simulators and 2-D platformers, then back out of the markets they created (or re-invigorated) when players like Microsoft throw their incredible talent around, offering a more refined, complete experience that relies on new content rather than new gameplay.

There’s room for both strategies and there will be for years to come. But innovating new gameplay is a valid business model for anyone. Applying new content to existing gameplay is a business model best suited to major companies with powerful marketing. For developers like Capcom or EA, if 80% of their games flop, the other 20% will make enough to pay for those failures. If an indie game flops, there is no backup plan. To maximize your chances at success, better to follow a gameplay driven development rather than content driven development. There’s more room in the market, a higher chance of success, and less cost to get there.

Developing Your Community

Depending on your business plan, it may rely on a community. Building one around your game can seem like alchemy. The best games will inspire their own communities, but there are many, many things you can do to help:

What’s My Name? Those high score boards are going to look pretty empty unless you’ve got some names next to the numbers.  Getting a name is a difficult matter and can require a lot of coercing.  But knowing who else is out there – and how many there are – helps the image of a thriving community (even if it’s not there yet).

Who Am I? If your players can’t express any identity in your game, they have no reason to express it to anyone else.  Comments, avatars, their own little room – anything that promotes personalization will encourage players to show their work to other people.

Who Are You? If your players don’t have a means to express themselves to anyone else in-game, then they also don’t have a way to see a community beyond themselves.  And they aren’t going to join a community that they don’t know exists.  Hiding players from each other is a sure way to kill your community before it starts.

Why am I Important? Give your players a way not only to assert their own identity, but what the community should think of them.  Rankings, titles, stars next to their name and wearables will all help define and separate players from each other while also giving them a sense of place and belonging.

Why am I Here? As great as your game is, it’s not the only thing in the world.  If you don’t provide a way for people to get off-topic, they’ll only ever communicate to each other about your game.  Great for your ego, but bad for your community; it will just become stagnant and die.

What’s the Point? Providing a reward for jumping in the community is a good idea.  Continuing to provide rewards for being in the community is a great idea – and keeps everything alive.

Is it in a Community I’m already Part Of? Piggybacking onto an existing community (like Facebook) opens all of these doors and allows for you to worry less about building your community and more about your core game design.

Despite your valiant efforts, your community may never fly. As important as building your community may be, make sure it’s not essential to the game experience, or your game could suffer from a permanent stigma of having no community – which is a self-fulfilling prophecy. Consider a mix of off-line and on-line community, so that your users don’t have to be online at the same time to enjoy each other’s company.

The Power Law

There are many options for game designers to make money, and I’d suggest pursuing a few at once (better safe than sorry). But currently the most successful model for the indie crowd is giving it away, free-to-play, and selling add-ons to your joyous users later. The reason for this is because the vast majority of your revenue is going to come from the vast minority of your users. In statistics and business, this is called the Power Law and free-to-play games depend on it. Your success is going to hinge on your ability to convince your top tier fans that what you’re offering is worth their money. But there’s a problem – humans are horrible judges of value.

Value to you, the builder of all of this content, is proportional to how many hours something takes to build. Extra content is highly valuable. Wearables are a miniature form of extra content, so they have some value. Power-ups are literally doubling a single number, so it has the least value to you.

Your players see value exactly the opposite to you. Doubling a variable is something they’ll spend money on, but your 1000 hour opus of extra content isn’t nearly as valuable.

Not only that, but value is subjective to us humans. To you, building three hats as wearables takes an equal amount of time. But price them differently, and your players will see their values as wildly different. My favourite anecdote is about the $10 hat that is far too expensive for players. Add a $100 hat, and suddenly that $10 hat looks kind of reasonable. Add a $1,000 hat, and the $100 hat looks reasonable – and the $10 hat looks cheap. It’s a steal.

And that’s how the power law, embarrassingly, works. The vast majority of your users will never give you a penny. If they give you any money at all, they will get that $10 hat and will make up maybe 20% of your overall revenue. But the users that buy those $100 and $1,000 hats are the ones that are generating the lion’s share of your income. Make sure to treat them well.

What to Sell (And What Not to Sell)

A small (or in some cases large) mistake that’s been made over and over again is selling content. Maps, level editors, more story, more levels, more characters. Based on all the numbers I’ve seen, this is the least successful way to monetize games. Users are extremely wary about buying additional content. Many feel entitled to it and are enraged at being asked to purchase it. Others are just happy with the content you’ve provided for free. You can make money selling content – but content can be a lot of work to create, and it’s for the least amount of return. Don’t be afraid to offer it as an option – but as a business model, it’s the weakest of your options.

A step up in profitability is selling wearables. These are items with little or no in-game value outside of aesthetics. It’s a non-obtrusive way to ask your players for money – give me some cash, get a hat. It’s also fairly easy to implement from a development perspective – far simpler than adding a chapter on your story or designing a new character.

Note that if everyone can see each other’s wearables, a feeling of superiority is promoted in your game. These big spenders are paying for higher status in your game, and your community will look up to them (or at least the buyers will feel that).

The most profitable category for games in general is power-ups. More powerful weapons, better armor, grind-reducers, and the like. When you’re working on this, keep in mind that most English speaking audiences despise the concept of paying for a competitive advantage. Figure out ways to provide power-ups while keeping the playing field level – or at least the appearance of it. This can include experience boosts, paying for something that can be unlocked in-game, or keeping your scoreboards separated. If you can integrate paid power-ups without angering your players, your sales will show that they appreciate it.

Ignoring in-game currency (which is spent on other categories), and grouping weapons and power-ups together (because they are the same thing), you can see that power-ups and wearables outsell any other model.

Polish

When you have completed 95 percent of your journey, you are only halfway there. – Japanese Proverb.

Polish: A Definition:

Polish is one of those vague, catch-all terms for the final “five percent” of a game’s development. It’s the difference between a bad game and a good game; a good game and a great game. Polish is about tightening the code, improving the assets, and tweaking the gameplay. And if you’ve been a well-behaved developer with your architecture, it should be fun too.

The obvious bug fixes and known problems aside, you’re probably wise to start with a few checks on memory management (if you’ve been neglecting it). Flash developers are blessed with a garbage collector that removes objects from memory automatically – but a single reference attached to a dead object will keep it in memory. (It also won’t eject from memory anything too big – which is exactly the sort of thing it should do to prevent problems). As for optimization, don’t be too academic about it – if it works on a low-end device, then stop optimizing. The only reason to go beyond that would be because the gameplay is suffering from the limitations of your system.

The Asset Pile:

Working through your assets – music, sound effects, menus, graphics, animations and more – keep an eye out for anything that removes you from the experience of your game, even slightly. You want your game to be a unified whole – if something doesn’t fit, change or cut it. Just because a lot of time and money went into that massive intro animation doesn’t mean it’s a good idea. It can be extremely tough to make those cuts to some excellent pieces of work, but if it doesn’t contribute to the game as a whole, you’re better off without it of it.

On the left, the early Steambirds Art style. On the right, the final decision. Nothing was tied to the graphical assets.

This is one of those cases where we as a human beings are better off without our higher functions. We have a terrible, terrible notion of value, assigning past costs to current value. It’s the same reasoning we use when we keep pouring money into a broken car – we’ve already put ten grand into fixing it, so spending another thousand dollars is better than losing the money we’ve already ‘invested’. Do yourself a favour and ignore the ‘value’ of whatever asset it is you’re judging. It is worth absolutely nothing unless it helps your game.

Aside: Upending the Tea Table

There are a variety of stories from Nintendo’s various development teams when Shigeru Miyamoto comes to visit. He has a habit of ‘upending the tea table’, essentially telling development teams to discard massive amounts of work after spending a few hours evaluating it. In their mind, the value of that work could be measured in months of development and thousands of dollars. In Miyamoto’s mind, if what he saw wasn’t working, then it was hurting the game and was worth less than nothing. The ability to identify these problems combined with the authority to throw out the work behind them have made Miyamoto a legend. It is a skill well worth honing.

The Tweak Phase

What changes about your game when you reduce your ammunition to a single bullet? Is it more fun without that power-up you built? If you’ve done a good job in your development, making these sweeping and radical design changes should be easy and prove fascinating. But at this point, you may no longer be the best judge of design changes. What makes your game interesting to you may turn away the audience you need to succeed. To start nailing down the details that will turn your good game into a great one, you need some responsive and honest players to set you on track.

Feedback is King

I’m just going to come out and call it: getting fresh player feedback is the most important step in game design. You have all of about thirty seconds for your player to have a nearly calcified impression of your game (which is why you need your testers to be in constantly fresh supply). The psychology of it suggests an even lower number – that first impression, that Blink reaction that Malcolm Gladwell identified, takes a fraction of a second. So if it takes just a few seconds to get a player’s summation of your game, and a few more seconds for them to put it into words for you, it should only take a minute or so for you to get some honest feedback from someone. But it may not be useful feedback – they may tell you something you already know, they may hate your game concept for reasons you can’t discern, or they may just be unable to communicate what exactly their impression is. Alternatively, your testers may not be honest about their feedback. So you have a minefield to navigate in order to get constant, useful feedback, and that’s only if you have a supply of users at your disposal. But if it’s the most important step in game design, how do you go about doing it well? For years the answer was either to have lots of money or lots of resources. But today, we’ve got a much cheaper and far more accurate tool: analytics.

Supplying Yourself with Meaningful Analytics

There are a number of tools you can use for analytics – everything from making a custom solution for yourself to using something like what Playtomic offers. But no matter what you choose, you need a fast and reliable method for both collecting and making sense of reams of player data. How long they play for, when they quit, if they turn off your music, how many times they die, how long they stare at your launch screen, if they leave it inactive for a while, if they come back, if they name themselves, if they encountered any errors… the list of useful data can go on forever. But since those first few seconds are so formative in the player’s minds, your analytic data should be front-loaded. Every single expected step for your player to take – from clicking on the start button to the end of your introduction – should set off an analytic flag. It may sound like overkill, but finding out that users spend a disproportionate time before their first button press may point you towards a major design problem that you wouldn’t find otherwise.

Here we see that there is a large drop off between the first landmark – watching the opening video – and the next landmark, completing the first step in the tutorial.

You can assume a tremendous amount from looking at the graphs your analytics have provided you with, but you also need a method to ask your players some simple feedback questions at various random points. Asking them to rate the game out of five based on their experience so far is a great start – as long as you have some data to pair it with. Low ratings coming from users who have played for two minutes and high ratings coming from players who’ve played for five minutes points to a design problem that comes in the first two minutes of play. You can either rely on your own ingenuity to solve the problem, or simply ask your players for a little help. A comment box, matched again with your analytics, can be extremely helpful. The more users you have testing out your game, the shorter those comments should be, to keep your sanity in check. Ask yourself what would be more helpful – a dozen articulate comments or an entire word cloud made up of hundreds of contributions. Different games and different stages of testing will call for different approaches. Keep it fluid, keep it agile, and keep it current.

Remember too that statistics that are interesting to you are not necessarily the statistics you should be basing your design on. Rockstar, the makers of Red Dead Redemption, have plenty of statistics showing that players killed crows than any other species in the game, and participated in crow shooting far more often than any other in-game activity. It was interesting, but it showed nothing meaningful to the design. Were crows picked on because they were a challenge to shoot? Because they were plentiful? Valuable? Annoying? Because they were bait? Because they didn’t fight back? Or was it due to a significant design flaw – that at anything less than a 42” HD television, crows are highly visible and all other animals blend into the landscape? With no way to separate and evaluate the numbers you’re collecting, you may make design decisions that are completely contrary to the problem those numbers are trying to reveal to you.

Why is there a Button for Crouching?

One of the gorgeous innovations in gaming – or in interface design as a whole – came with the realization that a dozen in-game actions didn’t require a dozen buttons. Context-sensitive action buttons saved ridiculously complex designs from themselves while providing players with more control then they were ever given before, and all with a single button.

Then the design world, from Apple to Nintendo, started to give their users less control. They dropped functions and abilities in exchange for simplicity, but kept that context-sensitive approach to their remaining buttons. Apple reduced it all to a finger swipe. The console manufacturers reduced it to a flick of the wrist. And with those impossibly simple actions, entire worlds have opened up.

Wii Tennis, the poster-child for simpler controls and reduced functionality. You control a tennis racket but not the feet that get it around the court. It sold in the tens of millions.

What does that mean for your game? It means that your audience is not just expecting but demanding an interface that feels minimal in interaction and robust in function. When they run up to a toppled concrete pillar for cover, they don’t want to press an extra button to crouch behind it – they want their interaction with the environment to be understood by the game. It should be automatic. Look at your interface, the buttons, commands and functions you have. Can any of them be automated? If so, do it, and you’ll immediately retain more users. Canabalt, a platformer, has no button for moving forward. A significant barrier to the enjoyment of the game was removed – that’s a winning design choice.

After that, you’re left with the functions that you consider essential to your design. Now your task is to further simplify it. Can any of them be combined? Can any of them be sub-functions to a more general command? And most daringly, can any of them be omitted? An elegantly simple interface should eventually feel automatic, and not something you have to teach. Which is good, because the next thing you’ve got to worry about is teaching your players how to play.

The Tutorial

If you’re anything like me, you were brought up on console and PC games, which as a whole have horrible methods of teaching you how to play the game. The implication is that because you’ve invested money in the product, you’ll also invest time in learning how to play it. In a free-to-play market, that is no longer the assumption. The working assumption now is that the game has to present itself to the player loaded with in-game learning and repeated reinforcement of that learning.

If you haven’t worked out something brilliant yet, now is the time to nail down teaching your game to your players, and assuming you’re breaking new ground, you have a lot to teach. There are at least three things you need to consider:

What is the minimum the player needs to know to get going? What are the core actions of your game? What is the absolute minimum you have to directly instruct the player on? What can you assume they’ll discover on their own?

How can you let the player learn at their own pace? How do you keep your instruction brief and informative, but still make sure that everyone gets it? How do you make sure the appropriate lesson has been learned before letting your player progress?

How do you integrate it seamlessly into your game? Can you use the same language and characters that you use for the rest of your game as instructional aids? Can you keep the mood of your game (i.e. urgency) present in a learning environment, or will it need to be subverted somehow?

There’s nothing simple about teaching something simple – you have to assume that you’re teaching both idiots and geniuses all at once. Thankfully, there are a few methods that are tried and true:

The Demo (i.e. Pac-Man, Joust, Super Smash Bros): This is where the game’s major concepts are presented to the player without their interaction. It’s better than a page of instructions because it has visual reinforcement – but it’s still lacking. Still, it’s sufficient for a game with arcade-style play.

The Guidepost (i.e. the God of War & Grand Theft Auto series): This is the idea that when the players need to know what to do, your game will tell them, through text, signposts, on-screen prompts, a ‘hint’ feature, or something similar. It’s a kind of ongoing contextual teaching, breaking down highly complicated actions into a series of learning points. Good for games that are built on sophisticated interactions between the player and their environment.

The Sandbox (i.e. Super Mario 64, The Zelda Series, Braid): This is the idea of starting your player inside a safety zone while they fiddle with the controls. Long time gamers will proceed along the path you’ve provided them to more dangerous grounds. Those less video game inclined will fiddle with the controls and concepts you’ve presented to them. This keeps your player from getting over their head – the first time they encounter a problem, they’ll already have an idea of how to handle it. Great for exploratory games and physics based games.

The Level Zero (i.e. Pikmin, Steambirds): This is the safety level, a level with no option of failure, only progress and learning. The best level zeroes are entirely player dictated, where their learning curve is dictated by themselves and not the game. Keep in mind that it should be able to be completed in much less time than the first level; if it’s too long, you may find you’re better off without it. Good for games where the depth comes from the strategic execution of given mechanics, rather than the depth of a hundred commands and features.

The Sensei (i.e. Sim City, Nintendo’s Super Guide feature): The Sensei is the game-long guide that lets you make mistakes and then suggests how to correct them. It assumes that your player’s willingness to learn from their own mistakes is greater than their willingness to be taught up-front, and is more about subduing frustration than anything else. Great for long-form games about growth and games with lots of unique obstacles.

Pick a solution that’s best for your game, integrate it, and let the players get through it at their own pace. Above all, remember that you are showing the player what to do, not telling them. It’s much more psychologically rewarding to be ushered towards the answer to a problem rather than outright told. It’s as simple as the difference between “Press the Space Bar to Jump” and “Press the Space Bar”.

Braid is a perfect example of showing the user instead of telling them. There are visual cues, but no instructions.

After all of that, if you’re having trouble communicating to your users exactly what it is that you want them to do, there may be a design problem. You may have made a game that’s too complex, and now are forced to either release a game that’s dead on arrival, or cut mechanics that you were proud of but that confuse your players.

Are You Asking Your Players for Money?

I have seen countless game developers sell themselves short and cut deeply into their profits with a simple, regrettable, and fixable mistake: they do a bad job of asking for their user’s money. They bury their offers in a corner of the main screen, or even a sub-menu. Worse still, the players can go on for hours without ever seeing any option to buy anything. In marketing terms, that’s a complete failure.

A big part of your polish phase heading into release is making sure that your offers for in-game items and content in exchange for their money is repeated, transparent, and enticing. And get over your fear that advertising is inherently annoying. It’s only annoying when it takes you out of the experience – embed it into your game seamlessly, and no one will complain.

Repetition of your offers is about making sure that the player can always purchase things between levels or between deaths. It’s not about always asking for their money, but rather always offering them more to play with. Put your free (or in-game currency) offers with your paid offers so that your players get used to looking at them. If you make a habit of hiding them, your players will only get annoyed when they see them. Regularly pitching your wares to players will ease them into the idea of buying from you.

Transparent offers are more enticing than mysterious or poorly described offers (which is partially why selling a hat is more successful than selling a level). When your player makes a motion in your game for more information (by clicking or hovering or whatever) then you should make that information readily available and totally transparent. Don’t lie, don’t exaggerate, and don’t leave anything as a surprise. The phrase “… and more!” only works if you actually tell them what the ‘more’ is – leave them hanging, and it’s no longer a transparent deal. You stop sounding like a source of information and more like a salesman, which will aggravate where you meant to inform.

Enticing your players to buy your wares is an art. Obviously, the pricing can be significantly enticing, especially if there are ‘bulk’ deals. But regardless of your pricing structure, the most enticing thing you have to offer them is information. If you’re being transparent, you’re halfway there. But you can show them much more than you can tell them, so let your players play. If what they are buying is not a direct extension of something they’re already experiencing (like a power-up to an existing mechanic), then let them try it as a trial or demo. Let them see a small version of the paid experience in action – if it’s worth their attention, then it will be worth their money too.

Remember that during all of this, feedback is still king – getting new users to try your tweaks and additions on a regular basis will provide you with vital information about the direction you’re headed in. Once those users are confident in your game, then you should be too.

Release

My play was a complete success. The audience was a failure. – Ashleigh Brilliant, 1984.

The First Platform

The first decision you have to make regarding your release (a decision you’ll make during development) is the target platform. This very concept is in flux at the moment: a game developed in Flash and distributed as a SWF can be added to Google’s App Store, but different developers will argue about what exactly the ‘platform’ is in that example. Regardless, your players have to have a way to play your game, and you hopefully have some method in mind, such as…

Facebook: Facebook has set their policy for games based on the policy they’ve pulled out for the behemoths already working in the space, which is at best a mixed blessing. It has flawless distribution, incredible traffic, and a very robust series of tools to access their community. The downsides include some million dollar competition and adhereing to their platform rules. EDIT, January 25, 2010: like these platform rules.

iThings: Apple has an enviable position as the distributor of a massive number of applications to an audience that can’t seem to get enough of them. Apple has a strict developer agreement and takes a 30% cut of your revenue, and the best-selling apps tend to continue to be the best-selling apps, with very little movement at the top. It’s a highly competitive market with the vast majority of the money being spent on very few games, but there’s certainly room for new ventures. Don’t overestimate their audience though – apps are big business, but Apple isn’t nearly as omnipresent as Facebook.

Other Mobiles: No other mobile device has the marketing power that Apple has made for themselves, but the Android market is picking up. Remember too that those markets are under-served: what may go over tepidly on Apple’s store could fill a need in the rest of the mobile market. (i.e. Spryfox’s Kindle games)

Browser-Based (Flash): Flash games are a huge market that traditionally has had problems monetizing itself. That’s changed recently, but some of the major Flash portals are still extremely resistant to developers making any money besides sponsorship and advertising deals. The majority of the success stories have come from developers testing the waters in the Flash world and making their money through sponsorships, then releasing an updated version which seeks to monetize through app purchases or micro-transactions in a sequel. The Flash market makes more money every year though, and despite new competition, hasn’t slowed.

Browser-Based (Other Plugin): Unity is the major alternative to Flash but its track record as a successful business model for developers is slim to none. Other plug-ins are a dark horse market that can definitely be pandered to, but the chances at success are low.

Browser-Based (No Plugin): There’s been a lot of talk about HTML5 and javascript replacing Flash as the primary method to have game-like content on the web, but until there is a method of simple distribution to thousands of sites (as there is for Flash), it’s a fantasy. It’s still a great method for browser-based games that don’t require wide distribution though, especially with Google’s recent push to make the browser the access point for all of their apps, and Abode demoing a program that converts an entire Flash file into HTML5.

The Big Three: Releasing for Sony, Nintendo and Microsoft was once a pipe dream unless you had an established pedigree and a lot of money. That’s changed, but the vast majority of the indie games for all three services started on other platforms and were updated for their markets. It’s becoming more common for one of these to become the last platform a game is released for.

Steam: Valve’s Steam service has a relatively small user base (compared to Flash or Facebook) but because Steam has such control over their content, the user base has come to expect excellence and tends to spend a fair amount of money. It’s a rough process to be approved for release through Steam, but once you’re in, the income is all but guaranteed. It’s worth trying for, but unreliable to plan for.

Desktop Downloadable: Minecraft has proven this is not a dead concept, but between piracy, hacking and a general platform abandonment, the PC is one of the toughest platforms to target, especially with Google muscling into the operating system market in 2011. Still, an under-served market can be a fantastic opportunity.

That is by no means a comprehensive list, nor is it an advertisement for one platform over another. There is no correct platform to choose, because it depends largely on your strengths as a developer, and the audience you’re trying to reach. A fiercely single-player game probably won’t explode on Facebook. A game that is played best in hour-long sessions will be looked over in an iPhone release. A game with an on-going tutorial probably won’t succeed in the a browser-based game where the attention span is fleeting at best. Pick out the advantages and disadvantages of each market and match them up with the unique opportunities in your game.

The Illusion of Completion

If you’ve been listening in on the world of design and art, you’ll notice that there’s talk about the devaluation of the “finished product”. Museums are displaying more interactive works, artists are coming up with new ways for their works to be active and changing even when they are no longer involved, and audiences are more frequently sought for their input in the creative process. Major advertising, which mirrors society as a whole, is increasingly showing us more of the process and less of the product. We are becoming more interested in the malleability of our culture and its never-ending remixes then we are with the finished projects.

What does that have to do with your game? Simple – even if you think you’re finished, your game won’t ever be ‘complete’. Software companies and developers that insist on releasing stable and bug-free products nevertheless suddenly find themselves with a need or a desire to send out an update of some nature.

What that ultimately boils down to is three major considerations: the ability to update, the ability to tweak, and the ability to know when those are needed.

Updating: The ability to update your game for your users is either helped or hindered with every decision you make about distribution. If you are in complete control, then updating your game can be as easy as uploading a single file. If you’ve given control to the people and organizations that are helping your distribution, make sure that they have a painless update protocol in place.

Tweaking: Tweaking your game in response to your users should be painless and shouldn’t even require a full update. Use a method like storing the values of some of the variables in your game on a server, so you can change them at a whim.

When to Update and Tweak: You need a way for you to find out, reliably, what your users are experiencing so you can provide timely and accurate adjustments and fixes. You could pour through comment threads for glimmers of insight, but you’ve already implemented a tool for this: analytics.

Analytics should give you a breakdown of just what your players are doing in your game, from which weapons they choose to how far they get to how often they die. Look at those numbers on a chart, and you’ll find out precisely where your problems are – if there’s a big user drop-off in users during level four, and a corresponding spike in the average number of level four deaths, then there’s absolutely no guess work about what needs to be done. And if after your users buy that power-up they use it and never buy again, then you know that item has a problem that you should fix. If your analytics are well done, then fixing these issues with a crystal clear view of the underlying problem should be a snap, provided you’ve got a tweaking and updating procedure in place that’s easy to rush through.

The blue line shows a drop-off at level 6, where users are essentially rage-quitting. A simple fix brought those numbers up and that blue line up to the target red line. (Those numbers are from Trickochet, image courtesy of Playtomic)

Setting Your Price

If you are releasing to a market that will actually pay for the download of your game (like Apple’s store), then you are forced into a decision at your launch about how much you should charge for your game. Even in the days of shareware prices never went as low as 99 cents, but that’s the new standard price if the game isn’t free.

The pricing decision on release comes down to a simple either / or proposition – either you charge for admission to your game, or you don’t. If your entire business model relies on making money up front, then this is a no-brainer. But if you’re trying to make money in-game from consumables or wearables, then your choice is a lot more muddled. Do you give away your game for free and hope that your in-game sales make up for that lost revenue? Or do you charge up front to help cushion against a failure?

There are a lot of variables to consider, and the biggest unknown variable is success. There is no right answer here, but there is a right direction, and it goes back to the power law.

The Las Vegas Business Model

For years a “free-to-play” business model was counter-intuitive outside of the glittering lights of Las Vegas. Nevada has long been ahead of the curve on this one, with a business model that media around the world is beginning to emulate. Las Vegas does the vast, vast majority of their business with a small minority of their clientele. These are the big rollers, the convention hall renters, and the title fight organizers. These top 5% are responsible for 95% of the Vegas income. So what’s the point of catering to the millions of tourists who only make up 5% of their bottom line?

Two reasons. First, every person in that bottom rung is a potential convert to the to 5% who pay for Vegas for everyone else. The second reason is this: in order for the high rollers to feel like hot shots, it’s not about the money – it’s about the status. You need those throngs of people swarming around, or else the elite suddenly doesn’t feel so elite anymore. And Vegas goes out of their way to make them feel on top – the more you spend, the better the perks, from drinks at the tables to a free stay in the presidential suite and far, far beyond. And their customers keep spending. It’s the power law in full effect.

Making Your Game Free

The free-to-play business model is similar to the Vegas business model, but in many ways more powerful. The first part is meeting your customers expectations on what they are willing to pay. Let’s say you make a game and people like it. At $10, people who really enjoy it will buy it up, but anyone who thinks it’s worth $5 is left with two options – don’t play it, or pirate it. Drop the price to $5, and you have the same problem with people who think it’s only worth $1. Drop the price to free, and suddenly you’ve maximized your audience – no one can claim that the price isn’t right. You now have an audience that Vegas is jealous of.

After people have your game, you need a way to get $1 out of the people who think it’s worth $1. You need another way to get $5 out of the people who think it’s worth $5. And you need yet another way to get $10 or more from those super-customers, the ones who are in love with your game and willing to pay to continue playing. Every playing customer is a potential paying customer. Price your game at anything but free, and you’ve excluded thousands of players – and therefore, paying customers. They will never join your top five percent of users who make up the majority of your bottom line.

This can seem risky and even reckless. But if you and your test-audience have confidence in your game, you should be confident that it will make money provided you ask players for it.

Adjusting Your Price Points

Of course, the great thing about releasing in a digital network is that no decision is ever final. Provided your publishing partners allow it, you are free to change your pricing as often as you want. Launch at a premium price, test the waters, and drop (or even increase) your prices as you see fit. Or better yet, offer a free version and widely advertise that it’s a limited time offer, then jump the price up for a while and see how it goes. You have direct influence over your market – don’t be afraid to use it.

These changes will be fairly few and far between though – the pricing you have to monitor and tweak on an ongoing basis is your prices for microtransaction goods. Using your analytics, identify your big sellers and under-performers, and tweak your baseline prices to encourage a nicely rounded in-game economy. The closer you can align the pricing of your goods with your user’s valuing of those goods, the better off your financial situation is going to be.

And of course, don’t forget the allure of limited time offers and sales. You can either provide regular sales of a random assortment of deals (which will generate timely buzz) or you can provide user-specific sales, tied into their gameplay history and style (or their birthday – get creative!) Better yet, provide both kinds of sales and track the analytics on them to see how your energies are paying off.

Going Multi-Platform

Assuming a certain basic success, your game will be stable and active enough to encourage you to shoot for other platforms. This is the only time I will ever encourage you to create new content: a new platform is an excellent opportunity to launch new features, new game modes, new animations, new music, or pretty much new anything. It’s a fantastic way to give your community the kinds of things they ask for while at the same time making them pay for it all over again. Re-releases on new platforms have inherently bad connotations, including assumptions of greed, that you’ve turned your back on your original fans, and that the port to a new platform will be inferior in some way. By adding new content into your re-release, you can turn all of those assumptions on their heads, and turn bad publicity into good publicity. Everybody wins, and you get to try out a little something you cut from your game months ago because of feature creep.

At this point, congratulations. You’ve designed your game for success, and it’s paid off.

Summary

There are a few takeaways that I think are the most important pieces of game development in the current market:

Prototype – Your idea isn’t proven until you prove it. Get it done before anything else.

Gameplay is All – Gameplay is your top priority from early in development to late into polish. If your gameplay is obscured, start cutting until you can see it again.

Content Kills – Creating a static puzzle with one solution is a needlessly risky path for indie developers. Creating a dynamic puzzle with infinite solutions is a much more viable path to success.

Feedback is King – Without a constant supply of fresh pairs of eyes, your design is slowly going to need major changes to get it back on course, which are admittedly hard to justify. Get feedback, get it often, and get it from new sources to save yourself from yourself.

Mind the Power Law – The bulk of your revenue is going to come from the best five percent of your users. Make sure you have a way in your game for them to give you money, or you’ll never get it.

Above all, the most important takeaway is that this entire essay has been a suggestion. Take it, cut it apart, test it, argue with it, ignore it; as long as you give it some thought. We’re a community of like-minded individuals and peers. Here’s hoping that all of our next games are successes.(source:tonydowney)