* 首先，这是我的定义。当然这也是IGDA Education SIG所采用的定义。
区分不同游戏也非常重要。以《Three to Fifteen》为例，你们大多没有听过或玩过这款游戏。其规则非常简单：
现在你就心中有数。这就是一字棋游戏。那么一字棋和《Three to Fifteen》是大同小异，还是存在差异？（游戏邦注：这取决于你的定义）。
谈论游戏一个最常见的方式是用其他游戏形容它们。“这就像《侠盗猎车手》混合《模拟人生》和《魔兽世界》。”但这存在两大局限性，首先，若没有体验《魔兽世界》，我就 无法明白你的意思；这要求我得同时玩过这两款游戏。其次，更重要的是，这不适合游戏类型不同的情况。你如何基于其他游戏谈论《Katamari Damacy》？
* 游戏要有“目标和工具”：目标、结果和系列实现规则。（David Parlett）
* 游戏是包含玩家决策的活动，是在“有限环境”中寻找目标。（Clark C. Abt）
* 游戏包含六大属性：“自由”（体验具有选择性而非义务性），“单独”（事先设定于某空间和时间中），具有不确定的结果，“非创造性”（不会创造商品和财富），受规则 限制，“虚构”（游戏不是现实生活，而是共享的独立“现实”）。（Roger Callois）
* 游戏是“自愿付出完成不必要的障碍。”这是最受大家认可的定义。这个定义听起来有些不同，但包含很多先前定义的概念：自发性，存在目标和规则。“不必要障碍”说明规 则故意拖延效率——例如，若一字棋的目标是横向、纵向及对角方向收集3个符号，最简单的方式就是在首回合在同一行中写下3个符号，同时让对手无法接触到纸张。但你并没有 这么做，因为游戏有自己的规则，这些规则是游戏体验的来源。（Bernard Suits）
* 游戏有4个属性。它们是“封闭而形式的机制”；包含互动；包含冲突；提供安全性，至少相比其所代表的实际内容（例如，真正的美国足球与以美国足球为蓝本的游戏）。 （Chris Crawford）
* 游戏是“玩家进行系列决策，通过游戏符合合理管理资源，从而实现目标的艺术形式。”这个定义包含许多前面没有的内容：游戏属于艺术，涉及决策和资源管理，游戏有“符 号”。此外，也涉及有常见的目标概念。（Greg Costikyan）
* 游戏是“玩家参与规则定义的虚拟冲突，进而产生量化结果的机制”（这里的“量化”是指存在“输赢”概念）。这个定义来自Katie Salen和Eric Zimmerman创作的《Rules of Play》一书中。书中还罗列上述系列定义。
* 游戏就有自发性。若你处在枪口下，被迫参与所谓的游戏活动，有人会认为这对你来说便不再是游戏（试着想想：若你认同这点，那么有些玩家自发参与，而其他玩家被迫参与 的活动则既是游戏，又不是游戏，这取决于你所处的立场）。
* 益智游戏，如数字游戏《数独》、《魔术方块》或逻辑游戏。这些是否属于游戏？在Salen & Zimmerman看来，它们是游戏的一种，游戏包含系列正确答案。而Costikyan则认为 ，它们不属于游戏，虽然它们可以融入游戏中。
* 《Choose your own adventure》系列书籍。这些通常不被视作游戏；你在“阅读”书籍，而不是“体验”书籍。但这几乎满足所有游戏定义的标准。更令人迷惑的是，若在其中 某本书中添加某页包含数值的“人物统计表”，随机决定在某些页面中融入“技能检测”，将其称作“冒险模块”而非“Choose your own adventure”，我们发现这就变成游戏！
* 故事。游戏是否属于故事？一方面，多数游戏都呈线性发展，而游戏则更具动态。另一方面，多数游戏都蕴含某些故事或叙述内容；如今甚至还有投身数百万美元视频游戏项目 的专业故事作家。除此之外，玩家还可以讲述自己游戏体验的故事。记住故事和游戏概念具有紧密关联。
我们要制作的是所谓的瞄准终点的棋盘游戏。你可能玩过很多这类游戏；游戏目标是将自己的符号代表从棋盘某处移到另一处。常见例子包括《Candyland》、《Chutes & Ladders 》和巴棋戏。这些是最简单的游戏类型。
现在你已把握所有游戏要素，虽然这里还缺少某个常见要素：冲突。若能影响对手，或帮助他们，或伤害他们，游戏会更加有趣。想想玩家同对手的互动方式。当玩家与对手同处 一个空格时，会出现什么情况？是否存在某些空格能让你影响游戏，如让他们前进或后退？轮到玩家时，他们是否能够通过其他方式移动对手（如掷出某数）？应融入至少一个能 够让玩家修改对手身份的渠道。
“设计”这个单词将会频繁出现在这篇文章中，但是很不幸的是，在各类型文章中，这个词的使用实在太过于泛滥，所以我想在此详细解释我所说的“设计”到底指什么。就像在 《Challenges》中，游戏设计便是单纯指代游戏规则和内容的创造。其中并不包含编程，艺术，动画，市场营销或者其它游戏制作所要求的任务。所有的这些任务集中在一起被称 为“游戏开发”，而游戏设计只是游戏开发中的一个部分。
就像我们所提到的《Challenges》，它的游戏设计便体现了各种任务，包括系统设计，关卡设计，内容设计，用户界面设计，建造世界以及故事编写等。你可以花10周的时间去学 习这些任务的相关课程，但我们的这系列课程将不会囊括游戏设计中的所有范围。我们将会略提到用户界面，故事编写以及相关内容，但本课程的主要焦点还是系统设计（有时候 我们也称之为“核心系统设计”）。
游戏设计师是教育者。在阅读了《Theory of Fun》之后，我们会发现娱乐和教育是紧密联系着的，游戏之所以有趣是因为其中蕴含了一些新的学习技巧。
但是否游戏设计师的定位就只有这些？或者什么都不是？这是一个值得讨论的话题，但是我认为，游戏设计者虽然拥有各个领域的多种因素，但是却仍然伫立在一个属于自己的领 域中。而且这也是一个非常广阔的领域。当游戏设计领域进一步发展，我们也许在将来的某一天能够看到，那些专攻于“游戏设计”的设计者们将被会被细分到更多更加专业的领 域，就像“科学”领域的学生也有自己的专攻学科（游戏邦注：如化学，生物，物理等）。
有时候，有些人认为如果能够选择回到之前的步骤去修正一些内容是个不错的主意，而这也是我们后来所说的迭代式方法。而如果是瀑布模式，我们便只能沿着设计游戏，执行设 计，并确保设计可行这一直线路而行动了。但是你也可以在后来添加一个额外的步骤去评估你的游戏。玩游戏并判断它是否有趣或者哪里需要做出调整。随后做出决定：你是否完 成了任务，还是你应该回到之前的设计步骤进行一些完善？如果你认为游戏足够优秀了，那么你便完成了所有工作。但是如果你认为游戏尚待调整，那么你就需要回到之前的设计 步骤，找到问题所在，并针对性地进行修改，然后再次评估游戏。反复进行这一过程直到游戏真正得以完善。
也许有些人喜欢制造桌面游戏，所以并不关心电子游戏的制作。但是对于那些热爱电子游戏制作的人来说，便会好奇为何我们在这个课程里花了这么多时间都在阐述如何制作桌面 游戏和纸牌游戏。而现在你们应该知道答案了吧：因为对于纸牌游戏和桌面游戏来说，迭代的方法更加快速且便宜。就像我们曾在之前的课程提到的：你可以花15分钟制作一款桌 面游戏。游戏编程需要很长时间。所以你需要尽可能地先在纸上绘出游戏原型，因为15分钟的纸上原型绘制以及1个小时的游戏测试，都可能帮助你节省数个月的编程工作。
这也是我们的课程为何侧重于非数字游戏，特别是桌面游戏和纸牌游戏的另一大原因。这是一个关于系统设计的课程，也就是关于创造游戏规则的课程。桌面游戏的规则总是很直 白。虽然其中也包含了一些实质性元素，但是说实在的，玩家的游戏体验几乎完全依靠于游戏规则和玩家交互性。如果游戏规则没有说服力，那么游戏也就不会有趣，所以我们在 制作游戏的过程中应该更加关注于游戏规则和玩家体验间的联系。
在角色扮演游戏中，游戏规则和玩家体验也是个让人苦恼的组合。你们中有许多人也许对角色扮演游戏设计感兴趣，所以你们可能会对游戏规则和玩家体验感到陌生。但是不管怎 样，你都需要牢记，角色扮演游戏是故事的集合体（并且由一大规则系统去限制游戏界限）。同样地，再优秀的系统也会因为玩家拙劣的讲故事能力和游戏技巧而黯然失色，而再 糟糕的系统也可以因为玩家的高超技术而生辉。如此，我们选择，或者只是在最初阶段，避开这些游戏类型。
在你退出游戏后，至少针对游戏做出一个改变。你可以改变游戏运转规则，或者为玩家添加一个新的互动方式。你还可以改变纸牌的移动空间等等。不论你是出于何种原因做了何 种改变，你都必须在改变后再次尝试游戏。记下变化。关于你所做的改变是否对游戏有帮助。你是否可以根据这次的改变而设想下一次的改变？如果游戏因为改变而变得更加糟糕 ，你是否会将规则恢复到之前的样子，还是按照其它方式再次进行调整？
我们将在后面的课程中进一步阐述游戏测试过程中的细节问题。而现在，我只是希望所有人都能够克服一种恐惧，即“如果我尝试自己制造的游戏结果会怎样？会不会很失望？” 我猜测你根据课程一所设计游戏失败几率非常高（我们怎么可能只花15分钟而制造出一款类似于《战争机器》的游戏？）。但这并不表明你就是一个“糟糕的设计师”，只能说明 如果你能够投入更多时间，并反复进行迭代，那么你一定能够制造出一款非常优秀的游戏。
《Challenges for Game Designers》第二章节（Atoms）。这部分内容可以作为下周我们将分析的“游戏”概念的过渡点。
Doug Church的《Formal Abstract Design Tools》。这篇文章是基于Costikyan的《I Have No Words》，而提供一些有用的道具帮助我们分析并设计游戏。文章里提到了许多关于 电子游戏的例子，请试想一下这些概念是否也适用于其它类型的游戏。
本文要涉及到的读物是Doug Church的《Formal Abstract Design Tools》。我想提些有关这篇文章的东西。首先，他提到了游戏中的三个层面值得在设计中考虑：
3、故事指的是游戏的叙事线路。应当注意的是，游戏可能包含两个不同类型的故事：内在故事（游戏邦注：由设计师创造）和表面故事（游戏邦注：由玩家创造）。比如，当你告 诉好友近期玩的某款游戏以及在玩游戏过程中经历的事情：“我控制了整个非洲，但是还是无法将蓝方赶出扎伊尔。”，这时发生的便是表面故事。内在故事便是我们通常认为的 游戏的“叙事”，比如“你扮演着某个勇敢的骑士，在邪恶巫师的城堡中探险。”。Doug的观点是，内在故事与意图和结果相对立，也就是说，游戏的内在故事越强，玩家对游戏 结果的影响就越小。当Costikyan表示游戏并非故事时，我认为Doug更好地阐述了Costikyan的看法。
这里我将距离说明为何玩家意图和可察觉后果很重要。考虑以下情况：你正在玩一款第一人称射击游戏。你走向一面墙，上面有个开关。你拨弄开关。什么都没有发生。但是，事 实上发生了某些事情，但是游戏没有给你提供任何发生某些事情的迹象。或许是关卡中某个地方的一扇门开启。或许你只是将大量的怪物释放到这片区域中，只要你离开目前所处 的房间就会碰上它们。或许有一系列的开关，它们必须形成某种开启和关闭组合（游戏邦注：或者他们需要以正确的顺序来触发）才能够打开过关的路径。但是所有这些你都无从 知晓，因而你会产生挫败感，现在你必须彻底搜索已经到过的所有地方，只是为了看看拨动开关是否产生了某种效果。
如果快速浏览下我之前列举的那些定义，就可分离出可能适用于游戏每个定义的特性。我们可以在其中看到某些不断出现的要旨：游戏有规则、冲突、目标、决策和不确定的结果 。游戏是活动，它们是人为的、安全的和外在的普通生活，它们是义务无偿的，它们包含伪装、呈现和模拟元素，它们的效率很低，它们是艺术，它们是封闭式的系统。花点时间 想想，还有许多所有游戏共有的东西。这为我们认识各游戏机制提供了出发点。
1、单人（1个玩家 VS 游戏系统）。范例包括纸牌游戏《Klondike》（游戏邦注：有时就称为“单人纸牌游戏”）和电子游戏《扫雷》。
2、单对单（1个玩家 VS 1个玩家）。象棋和《Go》是典型的范例。
3、PVE（多个玩家 VS 游戏系统）。这种形式在《魔兽世界》等MMO游戏中很常见。也有些纯合作桌游，比如Knizia的《指环王》、《魔镇惊魂》和《瘟疫危机》。
4、单对多（1个玩家 VS 多个玩家）。桌游《苏格兰场》便是此类结果的绝佳例证，单个玩家需要对付整个侦探团队。
5、自由混战（1个玩家 VS 1个玩家 VS 1个玩家VS…）。这可能是多人游戏采用的最普遍的玩家结果，到处都可以看到，从《大富翁》之类的桌游到多数第一人称射击电子游戏中 的“多人死亡竞赛”。
6、独立个人对系统（1个玩家 VS 一系列其他玩家）。赌场游戏《黑杰克》便是例证，游戏中的“庄家”是个单独的玩家，对阵许多其他的玩家，但是他所对阵的玩家之间互不干 涉且毫无联系。
7、团队竞赛（多个玩家 VS 多个玩家 VS 多个玩家 VS…）。这也是中常见的结构，使用于多数团队运动、桥牌和《黑桃王》等纸牌游戏、第一人称射击游戏中“夺取旗帜”模式 等基于团队的在线游戏和许多其他游戏。
8、捕食者和猎物循环。玩家围成一个真实或虚拟的圈。每个人的目标都是攻击左边的玩家，防御来自右边玩家的攻击。游戏《暗杀》和卡片交易游戏《Vampire: the Eternal Struggle》使用的都是这种结构。
让我们再进一步挖掘。Salen和Zimmerman的《Rules of Play》将规则分为三种类型，包括操作规则、建构规则和暗示规则（游戏邦注：这些并非行业内的标准属于，因而在这里概 念比术语更加重要）。为阐述其中的概念，我们以《Tic-Tac-Toe》的规则为例：
这些便是《Rules of Play》中所谓的“操作规则”。思考片刻，这些是游戏中仅有的规则吗？
乍看之下，似乎便是如此。但是假如我认识到自己即将失败，拒绝在自己的回合中展开行动，那又如何呢？规则中并没有明确的时间限制，所以我可以无限期地拖延以避免失败， 此举并没有违反游戏的“规则”。但是，在现实的游戏中，会暗中规定合理的时间限制。这并非游戏的正式规则（即操作规则），但是仍属于《Rules of Play》中所述“暗示规则 ”的部分。这里的要点在于，玩家在玩游戏时会达成某些不成文的社交契约，这些内容尽管并未特别说明，但仍然可以为玩家双方所理解。
即便是游戏中的正是规则也包含两个层面。3X3棋盘和“X”及“O”标志是这款游戏的特别之处，但是你可以将它们抛弃。可以将棋盘重新构建成1到9的范围，将空间连线转变成其 他的数学特性，你就可以获得《Three-to-Fifteen》。尽管《Tic-Tac-Toe》和《Three-to-Fifteen》有着不同的操作方式和外观，但是潜在的抽象规则是相同的。当我们提及“规 则”时通常不会考虑到这些抽象术语，但是它们确实存在于游戏的外表之下。《Rules of Play》将这些称为“建构规则”。
“操作规则”和“建构规则”间的差异可以帮助我们理解为何某款游戏与其他游戏相比会显得有趣。经典街机游戏《Gauntlet》的游戏玩法同第一人称射击游戏《毁灭战士》极为 相像，最大的差异就在于镜头位置的不同。对于那些玩现代桌游的人来说，《波多黎各》和《银河竞逐》也极为相似。这种相似度可能不会立即显现出来，因为游戏的外观看上去 有很大差别，你需要考虑到游戏状况和规则才能够发现其中的相似之处。
许多第一人称射击游戏包含有一个规则，那就是当玩家被杀死之后，他们会在特定的已知地点重生。其他的玩家可以站在那个地点附近杀死任何重生的玩家，他们根本没有做出反 应的机会。这便是所谓的“复活杀戮”，为众多玩家所诟病。复活杀戮是否属于游戏的一部分（因为这并没有触犯规则）？这是种优秀的战略还是作弊行为？这取决于你问的人， 因为它属于游戏中的“暗示规则”。当两个玩家在不同的暗示规则下操作时，你会最终发现某个玩家控告另一个玩家作弊，而另一个玩家会狡辩称他们并没有触犯游戏规则，妨碍 他们取得胜利的努力是不合理的行为。这里的经验就是，游戏设计师精确定义尽可能多的此类规则很重要，以避免游戏过程中的规则争辩。
4、其他变体。对于基于回合的游戏而言，玩家要以何种顺序来轮流行动呢？以顺时针方向轮流采取行动是普遍的做法。以顺时针顺序随后跳过首个采取行动的玩家以减少先手优势 也是在许多现代桌游中采用的改良方法。我也见过某些随机决定回合顺序的游戏，或者玩家支付其他游戏中的资源来获得先手或最后行动的特权，或者根据玩家的地位来决定回合 顺序（游戏邦注：比如目前胜利的玩家最先或最后行动）。
第二个原因是，精心选择的主题能够让游戏学习和玩起来更加容易，因为规则更易于理解。象棋中棋子的移动规则与主题毫无相关，因而学习象棋的玩家必须死记这些规则。相比 之下，桌游《波多黎各》中的角色与他们的游戏功能都存在联系：建筑工人可以帮助你建造建筑物，市长可以招募新定居者等。游戏中多数的行动都很容易记住，因为它们同游戏 的主题存在某些联系。
你或许需要做某些研究才能够完成设计项目（游戏邦注：即便只是搜索维基百科来寻求灵感）。这是典型的游戏设计。许多人将游戏设计师想象成那种整天只是坐在桌旁思考的人 ，最后忽然站起来然后大吼：“我想到了某个绝妙的游戏想法！有忍者、激光恶化太空！程序员和美工们，马上行动将游戏构建起来！我会接着坐在这里构思另一个绝妙想法，同 时还能够得到之前5个创意的版税。”但这与现实相差甚远。许多设计需要涉及到细节，不仅要定义规则，还要进行研究确保规则适合参数和项目。
记住，想法并不享有版权，它们不能被注册成商标，不能秘密交易，也很难申请成专利。你无法以某种方法来保护它们，你不应当在这方面费尽心机，你应当做的是尝试构思出新 想法，开始就优秀的想法展开工作。不要因为在此课程中看到的内容而焦虑不安，“Ian说我应当将自己的作品提交到论坛上，但是我想到了某个很棒的想法，不希望它被他人窃取 。”这种想法是毫无必要的。在游戏中，想法是种很普遍的东西，与执行想法的价值相比，想法本身根本毫无价值，你应当努力将想法开发成某些真正能让你赚到钱的东西。但是 最为重要的是，我们的行业很紧密且极具协作性。你会发现人们在GDC上分享他们的想法，各工作室之间会协作开发项目，或者使用来自某款游戏的灵感来提升另一款游戏的质量。 不要为此而争斗。这就是事态的运转方式，以宽广的胸怀包容这一切，你会获得更多的好处。
现在你不妨思考一下电子游戏中所谓的“开放世界”是什么。玩家的一般反应就是，游戏充许你做任何事，给予玩家完全的自由，这也是乐趣所在。然而，严格地说，游戏并没有 给予玩家彻底的自由。玩家实际上受到储多约束：玩家的移动必然遵循一定的方式，能与玩家发生互动的必然有确定的对象，自行移动对象必然受某种计算机算法控制。玩家有多 种选择和相对开放的目标，但可以肯定的是，确实存在许多让玩家产生“无拘无束、随心所欲”这种错觉的限制条件。
我提这个的另一个原因是，你的生命当中很少有不受来自他人的限制的时候（特别是“独立”游戏开发者和业余设计师），如果你的工作起步有困难，出路之一就是给自己添加一 些限制条件。比如，给自己一个时间限制（游戏邦注：例如“Game Jam”大赛一般要求参与者在24小时或48小时内制作一款游戏）；选择一个自己有兴趣的题材作为游戏的主题； 挑选一个你喜欢的核心机制进行开发。这完全是随意的，但如果你不知道你的游戏该往哪个方向走，坚持下去，选择一个额外的限制条件让自己前进。（重复再重复，之后你总是 能够排除那些武断的限制条件，如果你发现所选的条件阻碍了游戏设计的话。）
纠错法。批判地看待你的游戏。你可能有一本笔记本记录了其他设计师（包括我）多年的心得体会，但你也需要写一本自己东西（无论你是不是要拿去出版，总之记下先）。当你 发现有些东西不太管用，并且你认为你可以识别其根源，那么就把引发问题的原因当作设计法则（或至少是指导）记录下来。如果你不知道根源，也还是记下来吧，定期地看看， 没准就让你找到答案了。
玩游戏法。玩很多游戏！不过，要带着研究的目的玩游戏，而不要像普通玩家那样，为了娱乐而玩游戏。另外，批判地玩游戏。问自己该游戏的设计做了什么选择，为什么，是否 有效。尝试你不喜欢或从来没玩过的游戏类型，找出其他人觉得好玩的原因。再者，已经发布的游戏指南也值得一读，那些基本上就是一份完备的设计文件了，所有游戏机制的细 节一目了然！
不能应对以敏捷或时间为基础的系统……虽然我们知道有许多以敏捷为基础的非数字化的游戏。想一想《街霸》系列电子游戏和James Ernest的实时卡片战争游戏《Brawl》之间的 相似和差异。有些能在纸上模拟得很好，有些就不同了。
极端复杂的算法要在纸上完成就太沉闷了，那种系统还是丢给Excel这种软件去制作“原型”吧。如果复杂的系统是游戏的必须及核心部分，这意味着“电脑玩得比玩家还开心”（ 引用Sid Meier之语），也许有必要对游戏进行简化处理了。
工艺品店和玩具店，无论是零售店还是网店，都可以给游戏设计师带来不错的灵感谢。我曾发现大量没上漆色的木质小方块（真是极佳的标记物和自定义骰子）和木质盘（质感好 ，比硬币大）。有次，我找到一套木质小方片，大约有1英寸，还有一些木质胡萝卜；我不知道我拿这些东西做什么，但总有一天会派上用场吧。我还发现有店面出售木质小人和各 种尺寸的铺砖。这些东西可能一时半会儿用不上，但项目开发到后期，肯定会有用。
游戏过程：轮到顺序的玩家叫一个方格的坐标（如B5或H10）。如果该坐标上没有任何敌方的潜艇占领，那么敌方玩家就说“没中”；否则，就说“命中”。另外，如果该方格被“ 命中”且该方格上的潜艇的所有“舱位”（即潜艇的方格长）都被击中，则该潜艇“沉没”，敌方玩家必须告诉对方哪只潜艇“沉没”。无论是否命中，叫方格的顺序轮给另一方 。
如果你确实去模拟这个游戏了，你会马上发玩有问题。比如，我没有定义什么叫“可以看到”，所以没有办法判定一枪打出去，到底是打中没中。你必须自己明确地定义这一点（ 可能是直线正对的玩家为“可见”，或者在一定的范围以内等等）。你可能也注意到了，游戏的深度不够，没有重刷、能量源、弹药、命值补给、特殊武器等。这个游戏也不支持 “占山为王”之类的模式。以上所提到的东西都可以添加进去，只是再费几分钟的事。
这种原型有什么用呢？你可以用来测试提交上来的关卡设计方案，这样就可以在入进关卡编辑工具的执行以前就知道可行不可行了。如果你增加怪物和组队模式进去，再设计一个 限制弹药和命值的机制，你可以用怪物的数量来平衡弹药及命值，从而获得一个比较可观的游戏挑战。如果你增加了具有不同射程、杀伤力和命中率的武器种类，那么在给定的地 图上，你可以好好琢磨该使用哪款武器。将游戏改成电子版后，你还是必须重新审视这些设定，因为从一种媒体转换到另一种媒体上，转换率未必是100%……但毕竟开头做好了， 再理解游戏的机制及其作用方式就不难了。
制作游戏面板的方法有很多，但这里有三条普遍的原则：将面板细分成方形网格。方格更容易操作，也更为玩家所熟悉，这样休闲玩家也容易上手。对于包含许多障碍物和移动挑 战的网格，方格更容易表示“此路不通”：不可通过的方格迫使玩家改变自己原来的路线而走其他路线。方格的缺点在于，对角线移动成问题：对角线移动是算作一格还是两格？ 一格的话感觉太少了，两格的话感觉太多了。（对角线距离的真实数值是“根号2”，或约等于1.4……不过，计算这个显然没什么实在意义。）
将面板细分成六边形网格。六边形具有一些理想的数学功能，因为3个六边形的距离是固定的，无论你往哪个方向走——不会遇到方形网格的“对角线移动”问题。六边形网格的缺 点在于，玩家更容易躲开障碍物，所以移动受限的情况也少了很多。这到底好不好，得看游戏的属性。另外，六边形相当令人讨厌，很可能不会吸引那些没有经验的玩家。在空地上模拟，不要用游戏面板。每个回合，游戏物品的移动距离都用卷尺测量出固定的某某厘米。这样就更流畅更精确了，不过，六边形地图的某些缺点还是存在，并且很难说 玩的过程中玩家会不会一不小心就撞上桌子或把游戏物品给挪动了一点。
为什么不一次性把所有东西加进去？因为你加进去的所有新东西都可能存在问题。如果你只增加了一个，一旦在测试中发现不对劲，你马上就知道问题出在哪里，因为你只改变过 一个东西。如果你一次就添加了十条规则，一旦出了错，要区分出哪条规则（或哪几条规则组合后）不适用就相当困难了。这跟编程序类似：如果你只写了一小块语句，然后进行 单元测试，很容易就知道漏洞所在，而如果你写了一万条语句才测试，出了问题的话……
是啊，确实是件沉闷的事。你必须测试，然后改变一条规则，然后再测试，再改变另一条规则，如此反复数十次（甚至上百次）。第一次测试很有趣，但你很快就会对一切都感到 厌烦。这是设计过程的一部分。有时候，游戏设计就是件苦差事，没什么乐趣可言。如果你想成为专业的设计师，你必需接受现实。记住专业设计师的目标：制作有趣的游戏，如 果游戏没意思，你就鼓起动力去改变和测试，直到达到你的目标。
Level 1: Overview / What is a Game?
By Ian Schreiber
Welcome to Game Design Concepts! I am Ian Schreiber, and I will be your guide through this whole experiment. I’ve heard a lot of excitement throughout all of the registration process these last few months, and be assured that I am just as excited (and intimidated) at this whole process as anyone else. So let me say that I appreciate your time, and will do my best to make the time you spend on this worthwhile.
Before we begin, I’d like to get a few quick administrative things out of the way:
* Registration. As I’m writing this, there is a large backlog of registrations sent in at the last minute. So, if you sent an email and have not yet received a reply, check your inbox in the next day or two. If you still haven’t received a response by Wednesday, it means I did not receive your email and you should find your previous one and forward it.
* On that subject, keep in mind there are over a thousand people actively participating here. I value all of your feedback and contributions, but if you send an email directly to me, understand that I may receive a lot and it may take some time to get back to you.
* I’ve set up two resources for this course, a wiki and a blog.
* The wiki is at http://gamedesignconcepts.pbworks.comand is intended for two things: as a resource for group collaboration (for those of you who are taking this course with friends), and as an area for people to post translations of this blog into other languages (as some of you have offered). If you think of other uses, feel free! Right now it is a closed wiki and requires an email address and password. If you registered, expect to receive an email in the next few days giving you login information.
* The discussion board is at http://gamedesignconcepts.aceboard.com and is the primary place for interactive discussion. I’ve created separate discussion areas by interest group (such as: an area for college students, another for professional educators, another for professional video game designers, and so on). I will create forums by geographic region soon, to allow you to find others in your area and arrange to meet in person, if you’d like. This is also where you’ll be able to post the work you do for this course, and give and receive peer review (these will become available as they are assigned). Lastly, there is a forum at the top called Meta Discussion, which is discussion for the course itself — what is working and what is not, in terms of using blog, wiki, forum and so on in order to communicate. You will have to create an account and then wait for the moderator to add you. This process may take a couple of days, so please be patient.
* If you twitter, use the tag #GDCU for any course-related tweets.
* If you have something to say about the course content itself, feel free to leave it as a comment here on this blog.
And with all of that out of the way, let’s talk about game design!
Most fields of study have been around for thousands of years. Game design has been studied for not much more than ten. We do not have a vast body of work to draw upon, compared to those in most other arts and sciences.
On the other hand, we are lucky. Within the past few years, we have finally reached what I see as a critical mass of conceptual writing, formal analysis, and theoretical and practical understanding to be able to fill a college curriculum… or at least, in this case, a ten-week course.
Okay, that isn’t entirely fair. There is actually a huge body of material in the field of game design, and many books (with more being released at an alarming rate). But the vast majority of it is either useless, or it is such dense reading that no one in the field bothers to read it. The readings we’ll have in this course are those that have, for whatever reason, pervaded the industry; many professional designers are already familiar with them.
This course will be divided, roughly, into two parts. The first half of the course will focus on the theories and concepts of game design. We will learn what a game is, how to break the concept of a game down into its component parts, and what makes one game better or worse than another. In the second half of the course, the main focus is the practical aspect of how to create a good game out of nothing, and the processes that are involved in creating your own games. Throughout all of the course, there will be a number of opportunities to make your own games (all non-digital, no computer programming required), so that you can see how the theory actually works in practice.
What is a game?
Those of you who have read a little into the Challenges text may think this is obvious. My preferred definition is a play activity with rules that involves conflict. But the question “what is a game?” is ctually more complicated than that:
* For one thing, that’s my definition. Sure, it was adopted by the IGDA Education SIG (mostly because no one argued with me about it). There are many other definitions that disagree with mine. Many of those other definitions were proposed by people with more game design experience than me. So, you can’t take this definition (or anything else) for granted, just because Ian Says So.
* For another, that definition tells us nothing about how to design games, so we’ll be talking about what a game is in terms of its component parts: rules, resources, actions, story, and so on. I call these things “formal elements” of games, for reasons that will be discussed later.
Also, it’s important to make distinctions between different games. Consider the game of Three to Fifteen. Most of you have probably never heard of or played this game. It has a very simple set of rules:
* Players: 2
* Objective: to collect a set of exactly three numbers that add up to 15.
* Setup: start by writing the numbers 1 through 9 on a sheet of paper. Choose a player to go first.
* Progression of Play: on your turn, choose a number that has not been chosen by either player. You now control that number. Cross it off the list of numbers, and write the number on your side of the paper to show that it is now yours.
* Resolution: if either player collects a set of exactly three numbers that add up to exactly 15, the game ends, and that player wins. If all nine numbers are collected and neither player has won, the game is a draw.
Go ahead and play this game, either against yourself or against another player. Do you recognize it now?
The numbers 1 through 9 can be arranged in a 3×3 grid known as a “magic square” where every row, column and diagonal adds up to exactly 15:
Now you may recognize it. It is the game of Tic-Tac-Toe (or Noughts and Crosses or several other names, depending on where you live). So, is Tic-Tac-Toe the same game as Three-to-Fifteen, or are they different games? (The answer is, it depends on what you mean… which is why it is important to define what a “game” is!)
Working towards a Critical Vocabulary
When I say “vocabulary” what I mean is, a set of words that allows us to talk about games. The word “critical” in this case does not mean that we are being critical (i.e. finding fault with a game), but rather that we are able to analyze games critically (as in, being able to analyze them carefully by considering all of their parts and how they fit together, and looking at both the good and the bad).
Vocabulary might not be as fascinating as that game you want to design with robot laser ninjas, but it is important, because it gives us the means to talk about games. Otherwise we’ll be stuck gesturing and grunting, and it becomes very hard to learn anything if we can’t communicate.
One of the most common ways to talk about games is to describe them in terms of other games. “It’s like Grand Theft Auto meets The Sims meets World of Warcraft.” But this has two limitations. First, if I haven’t played World of Warcraft, then I won’t know what you mean; it requires us to both have played the same games. Second, and more importantly, it does not cover the case of a game that is very different. How would you describe Katamari Damacy in terms of other games?
Another option, often chosen by those who write textbooks on game design, is to invent terminology as needed and then use it consistently within the text. I could do this, and we could at least communicate with each other about fundamental game design concepts. The problem here is what happens after this course is over; the jargon from this course would become useless when you were talking to anyone else. I cannot force or mandate that the game industry adopt my
One might wonder, if having the words to discuss games is such an important thing, why hasn’t it been done already? Why hasn’t the game industry settled on a list of terms? The answer is that it is doing so, but it is a slow process. We’ll see plenty of this emerging in the readings, and it is a theme we will return to many times during the first half of this course.
Games and Play
There are many kinds of play: tossing a ball around, playing make-believe, and of course games. So, you can think of games as one type of play.
Games are made of many parts, including the rules, story, physical components, and so on. Play is just one aspect of games. Therefore, you can also think of play as one part of games.How can two things both be a subset the other? It seems like a paradox, and it’s something you are welcome to think about on your own. For our purposes, it doesn’t matter — the point here is that games and play are concepts that are related.
So, what is a game, anyway?
You might have noticed I never answered the earlier question of what a game is. This is because the concept is very difficult to define, at least in a way that doesn’t either leave things out that are obviously games (so the definition is too narrow), or accept things that are clearly not games (making the definition too broad)… or sometimes both.
Here are some definitions from various sources:
* A game has “ends and means”: an objective, an outcome, and a set of rules to get there. (David Parlett)
* A game is an activity involving player decisions, seeking objectives within a “limiting context” [i.e. rules]. (Clark C. Abt)
* A game has six properties: it is “free” (playing is optional and not obligatory), “separate” (fixed in space and time, in advance), has an uncertain outcome, is “unproductive” (in the sense of creating neither goods nor wealth — note that wagering transferswealth between players but does not create it), is governed by rules, and is “make believe” (accompanied by an awareness that the game is not Real Life, but is some kind of shared separate “reality ”). (Roger Callois)
* A game is a “voluntary effort to overcome unnecessary obstacles.” This is a favorite among my classroom students. It sounds a bit different, but includes a lot of concepts of former definitions: it is voluntary, it has goals and rules. The bit about “unnecessary obstacles” implies an inefficiency caused by the rules on purpose — for example, if the object of Tic Tac Toe is to get three symbols across, down or diagonally, the easiest way to do that is to simply write three symbols in a row on your first turn while keeping the paper away from your opponent. But you don’t do that, because the rules get in the way… and it is from those rules that the play emerges. (Bernard Suits)
* Games have four properties. They are a “closed, formal system” (this is a fancy way of saying that they have rules; “formal” in this case means that it can be defined, not that it involves wearing a suit and tie); they involve interaction; they involve conflict; and they offer safety… at least compared to what they represent (for example, American Football is certainly not what one would call perfectly safe — injuries are common — but as a game it is an abstract representation of warfare, and it is certainly more safe than being a soldier in the middle of combat). (Chris Crawford)
* Games are a “form of art in which the participants, termed Players, make decisions in order to manage resources through game tokens in the pursuit of a goal.” This definition includes a number of concepts not seen in earlier definitions: games are art, they involve decisions and resource management, and they have “tokens” (objects within the game). There is also the familiar concept of goals. (Greg Costikyan)
* Games are a “system in which players engage in an artificial conflict, defined by rules, that results in a quantifiable outcome” (“quantifiable” here just means, for example, that there is a concept of “winning” and “losing”). This definition is from the book Rules of Playby Katie Salen and Eric Zimmerman. That book also lists the other definitions given above, and I thank the authors for putting them all in one place for easy reference.
By examining these definitions, we now have a starting point for discussing games. Some of the elements mentioned that seem to be common to many (if not all) games include:
* Games are an activity.
* Games have rules.
* Games have conflict.
* Games have goals.
* Games involve decision making.
* Games are artificial, they are safe, and they are outside ordinary life. This is sometimes referred to as the players stepping into the “Magic Circle” or sharing a “lusory attitude”.
* Games involve no material gain on the part of the players.
* Games are voluntary. If you are held at gunpoint and forced into an activity that would normally be considered a game, some would say that it is no longer a game for you. (Something to think about: if you accept this, then an activity that is voluntary for some players and compulsory for others may or may not be a game… depending on whose point of view you are looking at.)
* Games have an uncertain outcome.
* Games are a representation or simulation of something real, but they are themselves make believe.
* Games are inefficient. The rules impose obstacles that prevent the player from reaching their goal through the most efficient means.
* Games have systems. Usually, it is a closed system, meaning that resources and information do not flow between the game and the outside world.* Games are a form of art.
Weaknesses of Definitions
Which of the earlier definitions is correct?
None of them are perfect. If you try to come up with your own definition, it will likely be imperfect as well. Here are a few common edge cases that commonly cause problems with definitions:
* Puzzles, such as crossword puzzles, Sudoku, Rubik’s Cube, or logic puzzles. Are these games? It depends on the definition. Salen & Zimmerman say they are a subset of games where there is a set of correct answers. Costikyan says they are not games, although they may be contained within a game.
* Role-playing games, such as Dungeons & Dragons. They have the word “game” right in the title, yet they are often not considered games (for example, because they often have no final outcome or resolution, no winning or losing).
* Choose-your-own-adventure books. These are not generally thought of as games; you say you are “reading” a book, not “playing” it. And yet, it fits most of the criteria for most definitions of a game. To make things even more confusing, if you take one of these books, add a tear-out “character sheet” with some numeric stats, include “skill checks” on some pages where you roll a die against a stat, and call it an “adventure module” instead of a “choose- your-own-adventure book,” we would now call it a game!
* Stories. Are games stories? On the one hand, most stories are linear, while games tend to be more dynamic. On the other hand, most games have some kind of story or narrative in them; we even have professional story writers that work on multi-million-dollar video game projects. And even beyond that, a player cantell a story about their game experience (“let me tell you about this Chess game I played last night, it was awesome”). For now, keep in mind that the concepts of story and game are related in many ways, and we’ll explore this more thoroughly later in the course.
Let’s Make a Game
You might be wondering how all of this is going to help you make games. It isn’t, directly… but we need to at least take some steps towards a shared vocabulary so that we can talk about games in a meaningful way.
Here’s a thing about games. I hear a lot from students that they’re afraid they won’t be able to make a game. They don’t have the creativity, or the skills, or whatever. This is nonsense, and it is time to get that out of our systems now.
If you have never made a game before, it is time to get over your fear. You are going to make a game now. Take out a pencil and paper (or load up a drawing program like Microsoft Paint). This will take all of 15 minutes and it will be fun and painless, I promise.
I mean it, get ready. Okay?
We are going to make what is referred to as a race-to-the-end board game. You have probably played a lot of these; the object is to get your token from one area of a game board to another. Common examples include Candyland, Chutes & Ladders, and Parcheesi. They are the easiest kind of game to design, and you’re going to make one now.
First, draw some kind of path. It can be straight or curved. All it takes is drawing a line. Now divide the path into spaces. You have now completed the first step out of four. See how easy this is?
Second, come up with a theme or objective. The players need to get from one end of the path to the other; why? You are either running towards something or running away from something. What are the players represented as in the game? What is their goal? In the design of many games, it is often helpful to start by asking what the objective is, and a lot of rules will fall into place just from that. You should be able to come up with something (even if it is extremely silly) in just a few minutes. You’re now half way done!
Third, you need a set of rules to allow the players to travel from space to space. How do you move? The simplest way, which you’re probably familiar with, is to roll a die on your turn and move that many spaces forward. You also need to decide exactly how the game ends: do you have to land on the final space by exact count, or does the game end as soon as a player reaches or passes it?
You now have something that has all the elements of a game, although it is missing one element common to many games: conflict. Games tend to be more interesting if you can affect your opponents, either by helping them or harming them. Think of ways to interact with your opponents. Does something happen when you land on the same space as them? Are there spaces you land on that let you do things to your opponents, such as move them forward or back? Can you
move your opponents through other means on your turn (such as if you roll a certain result on the die)? Add at least one way to modify the standing of your opponents when it is your turn.
Congratulations! You have now made a game. It may not be a particularly good game (as that is something we will cover later in this course), but it is a functional game that can be played, and you made it in just a few minutes, with no tools other than a simple pencil and paper.
Credit for developing this exercise goes to my friend and co-author, Brenda Brathwaite, who noticed that there is this invisible barrier between a lot of people and game design, and created this as a way to get her students over their initial fear that they might not be able to design anything.
If you take away nothing else from this little activity, realize that you can have a playable game in minutes. It does not take programming skill. It does not require a great deal of creativity. It does not require lots of money, resources, or special materials. It does not take months or years of time. Making a good game may require some or all of these things, but the process of just starting out with a simple idea is something that can be done in a very short period of time with nothing more than a few slips of paper.
Remember this as we move forward in this course. When we talk about iteration and rapid prototyping, many people are afraid to commit to a design, to actually build their idea. They are afraid it will take too long, or that the idea will not turn out to be as good as it seems in their head. Part of the process involves killing weak ideas and making them stronger, by actually making and playing your game. The faster you can have something up and running, and the more times that you can play it, the better a game you can make. If it takes you more than a few minutes to make your first prototype of a new idea, it is taking too long.
Some classes assign “homework problems.” I’m not sure what is less fun: the concept of work at home, or having problems. So, I call everything a “homeplay” because I want these to be fun and interesting.
Before this Thursday, read the following:
* Challenges for Game Designers, Chapter 1 (Basics). This is just a short introduction to the text.
* I Have No Words and I Must Design, by Greg Costikyan. To me (and I’m sure others will disagree), this essay is the turning point when game design started to become its own field of study. Since it all started here, for me at least, I think it only fitting to introduce it at the start of this course. (There is a newer version here[PDF] if you are interested, but I prefer the original for its historical importance.)
* Understanding Games 1, Understanding Games 2, Understanding Games 3, Understanding Games 4. These are not readings, but playings. They are a series of short Flash games that attempt to explain some basic concepts of games in the form of a game. The name is a reference to Understanding Comics, a comic book that explains about comic books. Each one takes about five minutes.
Last time we asked the question: what is a game? Today, we look into a related question: what, exactly, is game design? Last time, we made a simple game. This time, we will look into the process of how games are made in general. While it is possible to make a race-to-the-end board game in 15 minutes, you will need to take a little longer if you are looking to make the next Settlers of Catan or World of Warcraft.
Some administrative things that have come up since Monday:
? First, I would like to apologize to those who are registered for the misbehavior of the wiki. It was sending out hourly announcements of updates… and there were a lot of updates! I have attempted to turn off these updates, so you should hopefully not receive any more “wiki-spam” but if you do, you can shut it off manually by going to your own settings and changing notifications to “Never.”
? As of 5am GMT this morning, the discussion forums are set up and operational. I look forward to seeing some really great discussion. There were quite a few spambots that tried to register, so I had to check every forum account against course registrations. If you got an email that your account was rejected, it just means I was unable to match it up to a course registration; please try again. If you have not yet created a forum account, you can make it easiest
for me by using the same email on the forums that you used to register for this course… and if you’re unwilling to do that, at least put some kind of identifying information in there (like your name and location) so I can find you in the list. Thank you.
? Lastly, to those of you who sent in a registration email after the course started (that is, if your email was timestamped after Monday, noon GMT), I apologize for not being able to add you after the fact. Registration emails have taken a lot of my time prior to the start of the course, and if I accept late registrations I will not have the time to do other things for the course. Whether you are registered or not, this blog is free and open to the public (as is the Twitter feed), and I hope you do still follow along and get a lot out of the experience.
We will use the word “design” a lot in this course, and unfortunately it is a term that is a bit overused, so I will clarify what I mean here. As it says in Challenges, game design is the creation of the rules and content of a game. It does not involve programming, art or animation, or marketing, or any of the other myriad tasks required to make a game. All of these tasks collectively can be called “game development” and game design is one part of development.
Unfortunately, I have seen the term “design” used (particularly in some college curricula) to refer to all aspects of development. When used in the video game industry (or the board game industry), “game design” has a very specific meaning, and that is the meaning that we will use for this course.
Multiple Types of Game Design
As mentioned in Challenges, there are many tasks associated with game design: system design, level design, content design, user interface design, world building, and story writing You could fill several 10-week courses with any one of these, so this summer course will not be a full treatment of the entire range of game design. We will touch lightly on UI, story writing and content when relevant, but the majority of this course focuses on system design (also sometimes called “systems design” or “core systems design”).
System design is about defining the basic rules of the game. What are the pieces? What can you control? What actions can you take on your turn (if there are “turns” at all)? What happens when you take each action, and how does it affect the game state? In general, system design is the creation of three things:
? Rules for setup. How does the game begin?
? Rules for progression of play. Once the game begins, what can the players do, and what happens when they do things?
? Rules for resolution. What, if anything, causes the game to end? If the game has an outcome (such as winning or losing), how is that outcome determined?
If you look back at Three-to-Fifteen from Monday, you’ll notice those very simple rules contain all of these parts. The creation of those rules is system design, and that is what we will be spending most of our time with over this summer.
What is a Game Designer?
As you may have noticed, game design is an incredibly broad field. Those of us who are professional designers sometimes have trouble explaining what we do to our families and friends. Part of the reason for this is that we do so many things. Here are some analogies I’ve seen when trying to explain what it is like to be a game designer:
? Game designers are artists. The term “art” is just as difficult to define as the word “game”… but if games can be a form of art (as we saw in Costikyan’s definition, at least), then designers would be artists.
? Game designers are architects. Architects do not build physical structures; they create blueprints. Video game designers also create “blueprints” which are referred to as “design docs.” Board game designers create “blueprints” as well — in the form of prototypes — which are then mass-produced by publishers.
? Game designers are party hosts. As designers, we invite players into our space and try our best to show them a good time.
? Game designers are research scientists. As I will touch on later today, we create games in a manner that is very close to the scientific method.
? Game designers are gods. We create worlds, and we create the physical rules that govern those worlds.
? Game designers are lawyers. We create a set of rules that others must follow.
? Game designers are educators. As we will see later when we start reading Theory of Fun, entertainment and education are strongly linked, and games are (at least sometimes) fun because they involve learning new skills.
If game design is all these things, where would it fit in a college curriculum? It could be justified in the school of education, or art, or architecture, or theology, or recreation management, or law, or engineering, or applied sciences, or half a dozen other things.
Is a game designer all of these things? None of them? It is open for discussion, but I think that game design has elements of many other fields, but it is still its own field. And you can see just how broad the field is! As the field of game design advances, we may see a day where game designers are so specialized that “game design” will be like the field of “science” — students will need to pick a specialty (Chemistry, Biology, Physics, etc.) rather than just “majoring in Science.”
Speaking of Science…
How is a game designed? There are many methods.
Historically, the first design methodology was known as the waterfall method: first you design the entire game on paper, then you implement it (using programming in a video game, or creating the board and pieces for a non-digital game), then you test it to make sure the rules work properly, add some graphical polish to make it look nice, and then you ship it.
Waterfall is so named because, like water in a waterfall, you can only move in one direction. If you’re busy making the final art for the game and it occurs to you that one of the rules needs to change, too bad — the methodology does not include a way to go back to the design step once you are done.
At some point, someone figured out that it might be a good idea to at least have the option of going back and fixing things in earlier steps, and created what is sometimes known as the iterative approach. As with waterfall, you first design the game, then implement it, and then make sure it works. But after this you add an extra step of evaluating the game. Play it, decide what is good and what needs to change. And then, make a decision: are you done, or should you go back to the design step and make some changes? If you decide the game is good enough, then that is that. But if you identify some changes, you now go back to the design step, find ways to address the identified problems, implement those changes, and then evaluate again. Continue doing this until the game is ready.
If this sounds familiar, it is because this is more or less the Scientific Method:
1. Make an observation. (“My experience in playing/making games has shown me that certain types of mechanics are fun.”)
2. Make a hypothesis. (“I think that this particular set of rules I am writing will make a fun game.”)
3. Create an experiment to prove or disprove the hypothesis. (“Let’s organize a playtest of this game and see if it is fun or not.”)
4. Perform the experiment. (“Let’s play!”)
5. Interpret the results of the experiment, forming a new set of observations. Go back to the first step.
With non-digital (card and board) games, this process works fine, because it can be done quickly. With video games, there is still one problem:
implementation (i.e. programming and debugging) is expensive and takes a long time. If it takes 18 months to code the game the first time and you only have two years, you will not get a lot of time to playtest and modify the game.
In general, the more times you iterate, the better your final game will be.
Therefore, any game design process should involve iterating (that is, going through an entire cycle of designing, implementing and evaluating) as much as possible, and anything you can do that lets you iterate faster will usually lead to a better game in the end. Because of this, video game designers will often prototype on paper first, and then only get the programmers involved when they are confident that the core rules are fun. We call this rapid prototyping.
Iteration and Risk
Games have many kinds of risk associated with them. There is design risk, the risk that the game will not be fun and people won’t like it. There is implementation risk, the possibility that the development team will not be able to build the game at all, even if the rules are solid. There is market risk, the chance that the game will be wonderful and no one will buy it anyway. And so on.The purpose of iteration is to lower design risk. The more times you iterate, the more you can be certain that the rules of your game are effective.
This all comes down to one important point: the greater the design risk of your game (that is, if your rules are untested and unproven), the more you need iteration. An iterative method is not as critical for games where the mechanics are largely lifted from another successful game; sequels and expansion sets to popular games are examples of situations where a Waterfall approach may work fine.
That said, most game designers have aspirations of making games that are new, creative, and innovative.
Why This Course is Non-Digital…
Some of you would rather make board games anyway, so you don’t care how video games are made. But for those of you who would love to make video games, you may have wondered why we will be spending so mch time making board and card games in this course. Now you know: it is because iteration is faster and cheaper with cardboard. Remember from Monday: you can make a board game in 15 minutes. Coding that game will take significantly longer. When possible,
prototype on paper first, because a 15-minute paper prototype and an hour-long playtest session can save you months of programming work.
Later in this course, we will discuss in detail methods of paper prototyping, both for traditional board games and also for various types of video games.
There is another reason why we will concentrate primarily on non-digital games this summer, particularly board and card games. This is a course in systems design, that is, creating the rules of the game. In board games, the rules are laid bare. There may be some physical components, sure, but the play experience is almost entirely determined by the rules and the player interactions. If the rules are not compelling, the game will not be fun, so working in this medium makes a clear connection between the rules and the player experience.
This is not as true in video games. Many video games have impressive technology (such as realistic physics engines) and graphics and sound, which can obscure the fact that the gameplay is stale. Video games also take much longer to make (due to programming and art/audio asset creation), making them an impractical choice for a ten-week course.
The connection between rules and player experience is also muddied in tabletop role-playing games. I realize that many of you have expressed an interest primarily in RPG design, so this may seem strange to you. However, keep in mind that an RPG is essentially a collaborative story-telling exercise (with a rules system in place to set boundaries for what can and can’t happen). As such, a wonderful system can be ruined by players who have poor story-telling and improv skills, and a weak system can be salvaged by skillful players. As such, we will stay away from these game genres, at least in the early stages.
Trying it out
Take that 15-minute game you made last time, and play it, if you haven’t already. As you are playing, ask yourself: is this more fun or less fun than playing your favorite published games? Why? What could you change about your game to make it better? You do not have to play the game to completion, but only for as long as it takes you to get the overall feeling of what it is like to play.Then, after playing once, make at least one change. Maybe you’ll change the rules for movement, or add a new way for players to interact. Maybe you’ll change some of the spaces on the board.
Whatever you do, for whatever reason, make a change and then play again. Note the differences. Has the change made the game better, or worse? Has this one change made you think of additional changes you could make? If the game got worse, would you just change the rule back, or would you change it again in a different way?
We will be looking at the playtest process in detail later in this course. For now, I just want everyone to get over that fear: “what if I play my game and it sucks?” With the game you designed on Monday, the odds are very high that your game does suck (seriously, did you expect to make the next Gears of War in 15 minutes?). This does not make you a “bad designer” by any means — but it should make it clear that the more time you put into a game and the more iterations you make, the better it gets.
The one big takeaway from today is that the more you iterate on a game, the better it becomes. Great designers do not design great games. They usually design really bad games, and then they iterate on them until the games become great.
This has two corollaries:
? You want to have a playable prototype of your game as early in development as possible. The faster you can playtest your ideas, the more time you have to make changes.
? Given equal amounts of time, a shorter, simpler game will give a better experience than a longer, complicated game. A game that takes ten hours to play to completion will give you fewer iterations than a game that can be played in five minutes. When we start on the Design Project later in this course, keep this in mind.
Before next Monday, read the following. I will be referencing these in Monday’s content when we talk about the formal elements of games:
? Challenges for Game Designers, Chapter 2 (Atoms). This will act as a bridge between last Monday when we talked about a critical vocabulary, and next Monday when we will start breaking down the concept of a “game” into its component parts.
? Formal Abstract Design Tools, by Doug Church. This article builds on Costikyan’s I Have No Words, offering some additional tools by which we can analyze and design games. While he does use many examples from video games, think about how the core concepts in the article can apply to other kinds of games as well.
Today marks the last day that we continue in building a critical vocabulary from which to discuss games; this Thursday we will dive right in to the game design process. Today I want the last pieces to fall into place: we need a way to dissect and analyze a game by discussing its component parts and how they all fit together. This can be useful when discussing other people’s games (it would be nice if, for example, more professional game reviews could do this properly), but it is also useful in designing our own games. After all, how can you design a game if you don’t know how all the different parts fit together?
As usual, there are a few things I’d like to announce and clarify:
I’m happy to announce that the course wiki is now open to the public (read-only access). This wiki is pretty much entirely run by the participants who registered for this course. Among other things, the blog posts here have already been translated into five different languages. I am impressed and humbled at the level of participation going on there, and encourage casual viewers to stop by and check it out.
I noticed some confusion on this so I would like to clarify: for readings in the Challenges text, you do not have to actually do all of the challenges at the end of the chapter. You certainly can if you want, but most chapters have five long challenges and ten short ones, and I would call that an extreme workload for a class of this pace. Repeat, you do not have to do all of the challenges (except where expressly noted on this blog).
A note on the reading for today
One of the readings for today was Doug Church’s Formal Abstract Design Tools. I want to mention a few things about this. First, he mentions three aspects of games that are worth putting in our design toolbox:
Player intention is defined as the ability of the player to devise and carry out their own plans and goals. We will come back to this later on in this course, but for now just realize that it can be important in many games to allow the player to form a plan of action.
Perceivable consequence is defined in the reading as a clear reaction of the game to the player’s actions. Clarity is important here: if the game reacts but you don’t know how the game state has changed, then you may have difficulty linking your actions to the consequences of those actions. I’ll point out that “perceivable consequence” is known by a more common name: feedback.
Story is the narrative thread of the game. Note that a game can contain two different types of story: the “embedded” story (created by the designer) and the “emergent” story (created by players). Emergent story happens, for example, when you tell your friends about a recent game you played and what happened to you during the play: “I had taken over all of Africa, but I just couldn’t keep the Blue player out of Zaire.” Embedded story is what we normally think of as the “narrative” of the game: “You are playing a brave knight venturing into the castle of an evil wizard.” Doug’s point is that embedded story competes with intention and consequence — that is, the more the game is “on rails”, the less the player can affect the outcome. When Costikyan said in “I Have No Words” that games are not stories, Doug provides what I think is a better way of saying what Costikyan meant.
Here is an example of why player intention and perceivable consequence are important. Consider this situation: you are playing a first-person shooter game. You walk up to a wall that has a switch on it. You flip the switch. Nothing happens. Well, actually something did happen, but the game gives you no indication of what happened. Maybe a door somewhere else in the level opened. Maybe you just unleashed a bunch of monsters into the area, and you’ll run into them as soon as you exit the current room. Maybe there are a series of switches, and they all have to be in exactly the right pattern of on and off (or they have to be triggered in the right order) in order to open up the path to the level exit. But you have no way of knowing, and so you feel frustrated that you must now do a thorough search of everywhere you’ve already been… just to see if the switch did anything.
How could you fix this? Add better feedback. One way would be to provide a map to the player, and show them a location on the map when the switch was pulled. Or, show a brief cut scene that shows a door opening somewhere. I’m sure you can think of other methods as well.
On another subject, Doug also included an interesting note at the end of the article about how he values beta testing, and half of his readers found the first two pages slow, so start at page 3 if you’re in that half. This would be an example of iteration in the design of this essay, of exactly the sort we talked about.
Now, I’m sure this note was partly in jest, but let’s take it at face value. There’s a slight problem with this fix: you don’t see the note until you’ve already read all of the way through the article, and it’s too late to do anything about it. If Doug were to iterate on his design a second time, what would you suggest he do? (I’ve heard many suggestions from my students in the past.)
Qualities of Games
It was rightly pointed out in the comments of this blog that on the first day of this course, I contradicted myself: I insisted that a critical vocabulary was important, and then I went on to say that completely defining the word “game” is impossible. Let’s reconcile this apparent paradox.
Take a quick look at the definitions listed on the first day. Separate out all of the qualities listed from each definition that may apply to games. We see some recurring themes: games have rules, conflict, goals, decision-making, and an uncertain outcome. Games are activities, they are artificial / safe / outside ordinary life, they are voluntary, they contain elements of make-believe / representation / simulation, they are inefficient, they are art, and they are closed systems. Think for a moment about what other things are common to all (or most) games. This provides a starting point for us to identify
individual game elements.I refer to these as “formal elements” again, not because they have anything to do with wearing a suit and tie, but because they are “formal” in the mathematical and scientific sense: something that can be explicitly defined. Challenges refers to them as “atoms” — in the sense that these are the smallest parts of a game that can be isolated and studied individually.
What are atomic elements of games?
This depends on who you ask. I have seen several schemes of classification. Like the definition of “game,” none is perfect, but by looking at all of them we can see some emerging themes that can shed light on the kinds of things that we need to create as game designers if we are to make games.
What follows are some parts of games, and some of the things designers may consider when looking at these atoms.
How many players does the game support? Must it be an exact number (4 players only), or a variable number (2 to 5 players)? Can players enter or leave during play? How does this affect play?
What is the relationship between players: are there teams, or individuals? Can teams be uneven? Here are some example player structures; this is by no means a complete list:
Solitaire (1 player vs. the game system). Examples include the card game Klondike (sometimes just called “Solitaire”) and the video game Minesweeper.
Head-to-head (1 player vs. 1 player). Chess and Go are classic examples.
“PvE” (multiple players vs. the game system). This is common in MMOs like World of Warcraft. Some purely-cooperative board games exist too, such as Knizia ’s Lord of the Rings, Arkham Horror, and Pandemic.
One-against-many (1 player vs. multiple players). The board game Scotland Yard is a great example of this; it pits a single player as Mr. X against a team of detectives.
Free-for-all (1 player vs. 1 player vs. 1 player vs. …). Perhaps the most common player structure for multi-player games, this can be found everywhere, from board games like Monopoly to “multiplayer deathmatch” play in most first-person shooter video games.
Separate individuals against the system (1 player vs. a series of other players). The casino game Blackjack is an example, where the “House” is playing as a single player against several other players, but those other players are not affecting each other much and do not really help or hinder or play against each other.
Team competition (multiple players vs. multiple players [vs. multiple players...]). This is also a common structure, finding its way into most team sports, card games like Bridge and Spades, team-based online games like “Capture the Flag” modes from first-person shooters, and numerous other games.
Predator-Prey. Players form a (real or virtual) circle. Everyone’s goal is to attack the player on their left, and defend themselves from the player on their right. The college game Assassination and the trading-card game Vampire: the Eternal Struggle both use this structure.
Five-pointed Star. I first saw this in a five-player Magic: the Gathering variant. The goal is to eliminate both of the players who are not on either side of you.
What is the object of the game? What are the players trying to do? This is often one of the first things you can ask yourself when designing a game, if you’ re stuck and don’t know where to begin. Once you know the objective, many of the other formal elements will seem to define themselves for you. Some common objectives (again, this is not a complete list):
Capture/destroy. Eliminate all of your opponent’s pieces from the game. Chess and Stratego are some well-known examples where you must eliminate the opposing forces to win.
Territorial control. The focus is not necessarily on destroying the opponent, but on controlling certain areas of the board. RISK and Diplomacy are examples.
Collection. The card game Rummy and its variants involve collecting sets of cards to win. Bohnanza involves collecting sets of beans. Many platformer video games (such as the Spyro series) included levels where you had to collect a certain number of objects scattered throughout the level.
Solve. The board game Clue (or Cluedo, depending on where you live) is an example of a game where the objective is to solve a puzzle. Lesser-known (but more interesting) examples are Castle of Magic and Sleuth.
Chase/race/escape. Generally, anything where you are running towards or away from something; the playground game Tag and the video game Super Mario Bros. are examples.
Spatial alignment. A number of games involve positioning of elements as an objective, including the non-digital games Tic-Tac-Toe and Pente and the video game Tetris.
Build. The opposite of “destroy” — your goal is to advance your character(s) or build your resources to a certain point. The Sims has strong elements of this; the board game Settlers of Catan is an example also.
Negation of another goal. Some games end when one player performs an act that is forbiden by the rules, and that player loses. Examples are the physical dexterity games Twister and Jenga.
As mentioned last week, there are three categories of rules: setup (things you do once at the beginning of the game), progression of play (what happens during the game), and resolution (what conditions cause the game to end, and how is an outcome determined based on the game state).
Some rules are automatic: they are triggered at a certain point in the game without player choices or interaction (“Draw a card at the start of your turn” or “The bonus timer decreases by 100 points every second”). Other rules define the choices or actions that the players can take in the game, and the effects of those actions on the game state.
Let’s dig deeper. Salen & Zimmerman’s Rules of Play classifies three types of rules, which they call operational, constituative, and implied (these are not standard terms in the industry, so the concepts are more important than the terminology in this case). To illustrate, let’s consider the rules of Tic-Tac- Toe:
Setup: Draw a 3×3 grid. Choose a player to go first as X. Their opponent is designated O.
Progression of play: On your turn, mark an empty square with your symbol. Play then passes to your opponent.
Resolution: If you get 3 of your symbol in a row (orthogonally or diagonally), you win. If the board is filled and there is no winner, it is a draw.
These are what Rules of Play calls the “operational” rules. Think for a moment: are these the only rules of the game?
At first glance, it seems so. But what if I’m losing and simply refuse to take another turn? The rules do not explicitly give a time limit, so I could “stall” indefinitely to avoid losing and still be operating within the “rules” as they are typically stated. However, in actual play, a reasonable time limit is implied. This is not part of the formal (operational) rules of the game, but it is still part of what Rules of Play calls the “implied” rules. The point here is that there is some kind of unwritten social contract that players make when playing a game, and these are understood even when not stated.
Even within the formal rules there are two layers. The 3×3 board and “X” and “O” symbols are specific to the “flavor” of this game, but you could strip them away. By reframing the squares as the numbers 1 through 9 and turning spatial alignment into a mathematical property, you can get Three-to- Fifteen. While Tic-Tac-Toe and Three-to-Fifteen have different implementations and appearances, the underlying abstract rules are the same. We do not normally think in these abstract terms when we think of “rules” but they are still there, under the surface. Rules of Play calls these “constituative” rules.
Is it useful to make the distinction between these three types of rules? I think it is important to be aware of them for two reasons:
The distinction between “operational” and “constituative” rules helps us understand why one game is fun in relation to other games. The classic arcade game Gauntlet has highly similar gameplay to the first-person shooter DOOM; the largest difference is the position of the camera. For those of you who play modern board games, a similar statement is that Puerto Rico is highly similar to Race for the Galaxy. The similarity may not be immediately apparent because the games look so different on the surface, unless you are thinking in terms of game states and rules.
Many first-person shooters contain a rule where, when a player is killed, they re-appear (“respawn”) in a specific known location. Another player can stand near that location and kill anyone that respawns before they have a chance to react. This is known as “spawn-camping” and can be rather annoying to someone on the receiving end of it. Is spawn-camping part of the game (since it is allowed by the rules)? Is it good strategy, or is it cheating? This depends on whoyou ask, as it is part of the “implied” rules of the game. When two players are operating under different implied rules, you will entually get one player accusing the other of cheating (or just “being cheap”) while the other player will get defensive and say that they’re playing by the rules, and there’s no reason for them to handicap themselves when they are playing to win. The lesson here is that it is important for the game designer to define as many of these rules as possible, to avoid rules arguments during play.
Resources and resource management
“Resources” is a broad category, and I use it to mean everything that is under control of a single player. Obviously this includes explicit resources (Wood and Wheat in Settlers of Catan, health and mana and currency in World of Warcraft), but this can also include other things under player control:
Territory in RISK
Number of questions remaining in Twenty Questions
Objects that can be picked up in video games (weapons, powerups)
Time (either game time, or real time, or both)
Known information (as the suspects that you have eliminated in Clue)
What kinds of resources do the players control? How are these resources manipulated during play? This is something the game designer must define explicitly.
Some “resource-like” things are not owned by a single player, but are still part of the game: unowned properties in Monopoly, the common cards in Texas Hold ‘Em. Everything in the game together, including the current player resources and everything else that makes up a snapshot of the game at a single point in time is called the game state.
In board games, explicitly defining the game state is not always necessary, but it is sometimes useful to think about. After all, what are rules, but the means by which the game is transformed from one game state to another?
In video games, someone must define the game state, because it includes all of the data that the computer must keep track of. Normally this task falls to a programmer, but if the game designer can explicitly define the entire game state it can greatly aid in the understanding of the game by the programming team.
How much of the game state is visible to each player? Changing the amount of information available to players has a drastic effect on the game, even if all other formal elements are the same. Some examples of information structures in games:
A few games offer total information, where all players see the complete game state at all times. Chess and Go are classic board game examples.
Games can include some information that is private to each individual. Think of Poker and other card games where each player has a hand of cards that only they can see.
One player can have their own privileged information, while other players do not. This is common in one-against-many player structures, like Scotland Yard.The game itself can contain information that is hidden from all players. Games like Clue and Sleuth actually have the victory condition that a player discover this hidden information.
These can be combined. Many “real-time strategy” computer games use what is called “fog of war” where certain sections of the map are concealed to any player that does not have a unit in sight range. Some information is therefore hidden from all players. Beyond that, players cannot see each other’s screens, so each player is unaware of what information is and isn’t available to their opponents.
In what order do players take their actions? How does play flow from one action to another? Games can work differently depending on the turn structure that is used:
Some games are purely turn-based: at any given time it is a single player’s “turn” on which they may take action. When they are done, it becomes someone else’s turn. Most classic board games and turn-based strategy games work this way.
Other games are turn-based, but with simultaneous play (everyone takes their turn at the same time, often by writing down their actions or playing an action card face-down and then simultaneously revealing). The board game Diplomacy works like this. There is also an interesting Chess variant where players write down their turns simultaneously and then resolve (two pieces entering the same square on the same turn are both captured) that adds tension to the game.
Still other games are real-time, where actions are taken as fast as players can take them. Most action-oriented video games fall into this category, but even some non-digital games (such as the card games Spit or Speed) work this way.
There are additional variations. For a turn-based game, what order do players take their turns? Taking turns in clockwise order is common. Taking turns in clockwise order and then skipping the first player (to reduce the first-player advantage) is a modification found in many modern board games. I’ve also seen games where turn order is randomized for each round of turns, or where players pay other resources in the game for the privilege of going first (or last), or
where turn order is determined by player standing (player who is currently winning goes first or last).
Turn-based games can be further modified by the addition of an explicit time limit, or other form of time pressure.
This is an often-neglected but highly important aspect of games to consider. How do players interact with one another? How can they influence one another? Here are some examples of player interactions:
Direct conflict (“I attack you”)
Negotiation (“If you support me to enter the Black Sea, I’ll help you get into Cairo next turn”)
Trading (“I’ll give you a Wood in exchange for your Wheat”)
Information sharing (“I looked at that tile last turn and I’m telling you, if you enter it a trap will go off”)
Theme (or narrative, backstory, or setting)
These terms do have distinct meanings for people who are professional story writers, but for our purposes they are used interchangeably to mean the parts of the game that do not directly affect gameplay at all.
If it doesn’t matter in terms of gameplay, why bother with this at all? There are two main reasons. First, the setting provides an emotional connection to the game. I find it hard to really care about the pawns on my chessboard the way I care about my Dungeons & Dragons character. And while this doesn’t necessarily make one game “better” than another, it does make it easier for a player to become emotionally invested in the game.
The other reason is that a well-chosen theme can make a game easier to learn and easier to play, because the rules make sense. The piece movement rules in Chess have no relation to the theme and must therefore be memorized by someone learning the game. By contrast, the roles in the board game Puerto Rico have some relation to their game function: the builder lets you build buildings, the mayor recruits new colonists, the captain ships goods off to the Old World, and so on. It is easy to remember what most actions do in the game, because they have some relation to the theme of the game.
Games as Systems
I’d like to call two things about these formal elements to your attention.
First, if you change even one formal element, it can make for a very different game. Each formal element of a game contributes in a deep way to the player experience. When designing a game, give thought to each of these elements, and make sure that each is a deliberate choice.
Second, note that these elements are interrelated, and changing one can affect others. Rules govern changes in Game State. Information can sometimes become a Resource. Sequencing can lead to different kinds of Player Interaction. Changing the number of Players can affect what kinds of Objectives can be defined.
And so on.
Because of the interrelated nature of these parts, you can frame any game as a system. (One dictionary definition of the word “system” is: a combination of things or parts that form a complex whole.)
In fact, a single game can contain several systems. World of Warcraft has a combat system, a quest system, a guild system, a chat system, and so on…
Another property of systems is that it is hard to fully understand or predict them just by defining them; you gain a far deeper understanding by seeing the system in action. Consider the physical system of projectile motion. I can give you a mathematical equation to define the path of a ball being thrown, and you could even predict its behavior… but the whole thing makes a lot more sense if you see someone actually throwing a ball.
Games are like this, too. You can read the rules and define all the formal elements of a game, but to truly understand a game you need to play it. This is why most people do not immediately see the parallel between Tic-Tac-Toe and Three-to-Fifteen until they have played them.
Critical Analysis of Games
What is a critical analysis, and why do we care?
Critical analysis is not just a game review. We are not concerned with how many out of five stars, or any numbers from 0 to 10, or whether or not a game is “fun” (whatever that means), or aiding in the consumer decision of whether or not to buy a game.
Critical analysis does not just mean a list of things that are wrong with the game. The word “critical” in this context does not mean “fault-finding” but rather a thorough and unbiased look at the game.
Critical analysis is useful when discussing or comparing games. You can say “I like the card game Bang! because it’s fun” but that does not help us as designers to learn why it is fun. We must look at the parts of games and how they interact in order to understand how each part relates to the play experience.
Critical analysis is also useful when examining our own works in progress. For a game that you’re working on, how do you know what to add or remove to make it better?
There are many ways to critically analyze a game, but I offer a three-step process:
Describe the game’s formal elements. Do not interpret at this point, simply state what is there.
Describe the results of the formal elements when put in motion. How do the different elements interact? What is the play of the game like? Is it effective?
Try to understand why the designer chose those elements and not others. Why this particular player structure, and why that set of resources? What would have happened if the designer had chosen differently?
Some questions to ask yourself during a critical analysis at various stages:
What challenges do the players face? What actions can players take to overcome those challenges?
How do players affect each other?
Is the game perceived by the players as fair? (Note that it may or may not actually be fair. Perception and reality often differ.)
Is the game replayable? Are there multiple paths to victory, varied start positions, or optional rules that cause the experience to be different each time?
What is the game’s intended audience? Is the game appropriate for that audience?
What is the “core” of the game — the one thing you do over and over that represents the main “fun” part?
We covered a lot of content today. The main takeaways I offer:
Games are systems.
Understanding a game is much easier if you have played it.
Analyzing a game requires looking at all of the game’s working parts, and figuring out how they fit together and how a play experience arises from them.
Designing a game requires the creation of all of the game’s parts. If you haven’t defined the formal elements of your game in some way, then you don’t really have a game… you just have the seed of an idea. This is fine, but to make it into a game you must actually design it.
It was brought to my attention that I have been using the word “homeplay” to refer to the reading, and that reading is not play no matter how I dress it up. This criticism is valid; normally in my classroom courses I use “homeplay” to refer to actual game design assignments and not readings, and I mixed the terms up here. I will make an attempt to avoid this confusion in the future, because I believe that trying to treat learning as an inherently Not-Fun activity (as evidenced by the need to use fancy fun-sounding words to describe it) is damaging to our collective long-term well being. As we will see when we get into flow theory, the reality is actually the opposite.
With that said, here is an activity that I hope you will find fun. It is based off of Challenge 2-5 in the Challenges text, with some minor changes just to keep you on your toes.
Here’s how it works. First, choose your difficulty level based on your previous experience with game design. Skiiers may find this familiar:
Here is your challenge:
Most war-themed games have an objective of either territorial control or capture/destroy (as described earlier). For this challenge, you’ll be pushing beyond these traditional boundaries. You should design a non-digital game that includes the following:
The theme must relate to World War I. The primary objective of players cannot be territorial control, or capture/destroy.
You cannot use territorial control or capture/destroy as game dynamics. That is, your game is not allowed to contain the concepts of territory or death in any form.
As above, and the players may not engage in direct conflict, only indirect.
I have created three new areas on the forums (one for each difficulty level). Post your game rules in the appropriate forum by Thursday, July 9, noon GMT. You are encouraged to post earlier if possible.
Then, after you have posted, read at least two other posts from your difficulty level and offer a constructive analysis and critique. If you are at blue- square or black-diamond difficulty, also read at least two other posts from the difficulty level immediately below yours and offer the benefit of your experience to those who you could mentor. Try to choose posts that have no responses already, so that everyone can get at least some feedback. Also complete this by Thursday, noon GMT.
A note about research…
Note that you may have to do some actual research to complete this project (even if only looking to Wikipedia for inspiration). This is typical of much game design in the field. Many laypersons imagine game designers as these people that just sit and think at their desk all day, then eventually stand up and proclaim, “I have this Great Idea for a game! Ninjas… and lasers… in space! Go forth and build it, my army of programmer and art lackeys. I shall sit here now until I come up with another Great Idea, while collecting royalties from my last five ideas.” This is not even close to reality. A great deal of design is the details: defining the rules, certainly, but also doing research to make sure that the rules fit the constraints and are appropriate for the project.
A note about IP law…
At this point, some of you may be thinking that by posting your game to the forum, you run the risk that someone will Steal Your Great Idea. How can you protect yourself from the threat of someone taking your basic idea, turning it into a working, sellable game, and leaving you with nothing?
One of the participants of this course, Dan Rosenthal, has kindly written an article that details the basics of IP (intellectual property) law as it pertains to games. The article admits to being US-centric, but the core idea (which is worth repeating here) should be sound no matter where you are:
Remember, ideas are not copyrightable, they’re not trademarkable, not trade secretable, and both difficult and prohibitively expensive to patent. You can’t protect them anyway, and you shouldn’t try — instead you should try to come up with new ones, and start working on the good ones. Don’t freak out when you see things like Game Jams, or this course and think “Ian says I should post my work to the discussion forum, but I came up with a Great Idea(tm) and I
don’t want other people to steal it.” Ideas are commonplace in games, and the value of your idea is nothing compared to the value of the implementation of that idea, your expertise and hard work in developing it into something that’s going to make you real money. But most importantly, our industry is very lateral, very tight-knit, very collaborative. You’ll find people sharing their ideas at GDC, doing collaborative projects between studios, or using inspiration from one game’s mechanics to improve another. Don’t fight it. That’s the way things work, and by embracing that open atmosphere, you’ll be far better off
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.
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 ofessionals), 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.)
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 withmost 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.
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 riting 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
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:
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 prototpe 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
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 mos 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 isadvantages 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!
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.