举例分析roguelike游戏的弊病及解决方法
作者:Keith Burgun
在我之前发表的文章《The Cautionary Tale Of 100 Rogues》中,我描述了设计、开发和营销2010年iOS游戏《100 Rogues》背后的整个过程。我和我的团队Dinofarm Games已经开始制作新游戏了。但是从表面上来看,新游戏与《100 Rogues》有诸多相似之处。在本文中,我将解释自己如何及为何重新拿起画板,探究该题材的基本层面。
新游戏称为《Auro》,是款基于回合制和巫术的地下城探索战略游戏。请注意,这款游戏不是角色扮演游戏,也不是roguelike。这很有趣,因为游戏原型事实上就是roguelike类游戏。
尽管如此,正如你即将在文中看到的那样,我的设计过程和哲学去除了许多这些题材中的元素。当我统观整个游戏时,发现所创造之物已经不再属于此类题材。当然,是否属于听凭玩家个人意见,但是从哲学上来说,我觉得我制造出了某些全新的东西。
我是roguelike类型游戏的狂热粉丝,《Dungeon Crawl》和《Shiren the Wanderer》是两款我自始至终都很喜欢的游戏。但是,我也觉得此类题材的游戏存在内在固有的问题。有些人可能会认为问题在于游戏的难度太高。事实上,我觉得这是此类题材所采取的主要的正确做法之一。
这些游戏富有挑战性并且你的选择能够对游戏产生影响(游戏邦注:如果玩家做出错误的选择,将可能产生无法挽救的后果),这正是让这些游戏充满趣味性的原因。我从roguelike类游戏中看到的问题也出现在多数电子游戏中,即:过度复杂、分散的游戏设计和暂时性失效。
过度复杂
在电子游戏出现之前,也存在各种各样的游戏,包括桌游、卡片游戏、纸牌、运动和文字游戏。但是,在电脑普及之前,实践原因导致游戏的简单化,游戏受到媒介物理现实的限制。比如,如果你希望自己的运动方式能够流行,如果这项运动只需要1个球和1个场地,那么几个人便可以应付并将其流行。如果这种运动需要12种不同类型的球,并且有许多达成目标的方式和各种设备,仅凭数人之力便很难解决问题。
但是,电脑游戏完全不存在此等限制,开发商也都对此加以利用。事实上,此类优点也使得开发商不断提升游戏的复杂性,而现在我们完全接纳了“越复杂越有内涵”这种哲学思想。
我觉得这种消极影响已经波及所有的现代电子游戏,连DLC(游戏邦注:即可下载内容)和IAP(应用内置付费功能)也未能幸免。
但是复杂不一定总是能增加内涵。当你在游戏中添加“更多”内容时,你就使游戏平衡的可能性下滑。如果游戏不平衡的话,那么就会出现主导战略,某种武器、单位或者移动会被每个玩家频繁使用。这样,你的游戏复杂性还有什么作用呢?
所有在设计、创造和执行这些功能中投入的精力完全浪费。在这种情况下,你的游戏事实上只包含少数可用的道具。
优秀的游戏通常并不具有大量的内在复杂性,也就是规则和内容的复杂性。优秀游戏的内在复杂性有限,但是游戏本身会产生大量的复杂内容,这些复杂内容是在玩游戏的过程中逐步显现出来的。
以游戏《Go》或《俄罗斯方块》为例,这些游戏的成分都非常简单,但是如果你深入发掘之后就会发现其中的选择大有内涵。这便游戏应当“简单上手,难以精通”的原则的来源(游戏邦注:该原则现已逐渐被开发商忽视)。现在,许多现代电子游戏感觉更像是走马观花地浏览所有的内容并逐一体验,随后便可以去体验下一款游戏了。
最后,我们在向游戏设计添加“更多内容”时也应当格外当心,因为我们添加的内容越多,游戏学起来就越难。这也正是为何玩家会期待游戏的最初部分可以设计成教程的原因所在,对那些不熟悉电子游戏的人来说,如果他们要玩《Ocarina of Time》或《Fable》,那么掌握游戏中的复杂规则将变得尤为艰难。
这种问题已经影响到了roguelike类游戏的设计。《Dungeon Crawl: Stone Soup》的首席设计师承认游戏中含有过多的内容。在《100 Rogues》开发早期,我注意到自己也在不断往游戏中添加过多的内容。我们原本还要增加更多的武器和护甲类型,但是这会带来很大的问题。
分散的游戏设计
roguelike游戏中的第二个问题更加基本化,这意味着尽管你未曾看到问题显现在表面,但是该问题确实对整个游戏造成了伤害。我这里所说的问题就是分散的游戏设计。我认为现代电子游戏学生可能会对这个问题感到困惑,但是就我个人经验而言,游戏中的确存在这个问题,而且所有媒介中的所有部分也都存在。
游戏设计应当有特别的目标,也就是要尝试做成的事情。其原因在于,就最基本的层面而言,游戏是个完成某项特别任务的工具,使用各种样式的紧张感来以正确的方式掌控人类的情绪。优秀的故事由想法控制来推动,优秀的散文由主题来推动,优秀的游戏设计自然是由非常特别的目标玩法体验来推动。
我在本地一所小型艺术学校中教授游戏设计,我教授的首个课题是,我们应当在设计游戏时先提出以下问题:“什么是我们想要的最基本体验?”
记住,这些基本体验应当是某些抽象的东西,比如某种有趣的新空间关系或者资源管理样式等。然后我们要做的就是,尝试找到能够最佳表达体验的核心机制。
所有的可玩性机制应当能够直接提供支持,并且直接同你的核心机制产生联系。随后,最后的步骤应当是选择能够让你的游戏清晰且容易为人所理解的主题。
对于roguelike游戏,它们的设计方法却不是这样的。它们首先确立的是主题,然后是一整套的游戏可玩性机制,这些机制间的联系也不甚清晰。
以《Nethack》为例,其中有战术、探索、资源管理、角色计划以及对所有道具、怪物、武器和护甲的学习。正因为此原因,这些机制都没有在游戏中得到很好的发展,这是种类似瑞士军刀那样多功能的游戏设计。而因为没有专门在哪一项游戏机制做得出色,我们很快就会对游戏感到厌烦,而不像《超级马里奥兄弟》或桌游《Puerto Rico》那样可以长久受到人们的欢迎。
分散的游戏设计也给游戏平衡带来了更多的困难(游戏邦注:因为机制间的关系更不清晰)。最后,混乱的游戏设计文件通常产生的就是劣质的产品。
暂时性失效
游戏就是让玩家做出许多有趣决定的载体,这便是游戏的内涵所在。谜题、玩具或模拟器之类的东西与之相比,没有媒介明确需要充满趣味的决定(游戏邦注:假设玩家需要在这些媒介中做出决定)。但是看看如今的多数现代电子游戏,你会发现在1个小时的游戏时间里,你通常只需要做少数几个有趣的决定。
为进行测试,我让一个好友掌控两个不同的秒表。左边的秒表设定时间为20分钟,且不停止,右边的秒表只是玩家做有趣决定的时候读秒。在多数现代电子游戏(游戏邦注:尤其是单人游戏)中,玩家多数时间体验的都是线性过程、观看过场动画、根据游戏的指示按动“A”键、等待游戏加载或者其他完全不用思考的行为。
在10小时的现代视频游戏时间里,我预测我们花9小时的时间来等待那1小时真正趣味内容的出现。这便是游戏中暂时失效出现的频率。
虽然roguelike游戏在这方面并非表现最差的类型,但是浪费玩家的时间也是这个题材中出现的大问题。《Dungeon Crawl》中有大型迷宫,玩游戏的过程中你需要不断探索才能够前进,每20或30个转弯会看到某些有趣事情发生。我很快意识到,游戏中有“自动探索”热键“o”。按这个键电脑就会以相对有效率的方式来探索地下城。
事实上,我总是会使用o键,因为电脑的自动探索和我能做的一样,而且这比通过数字键区来移动要简单得多。尽管如此,我仍然需要浪费时间来等待获得有趣的事物,等待进入做出决定的时刻。如果你觉得某个游戏机制可以自动完成,那倒不如将其放弃。
我玩过的每款roguelike游戏都有不为玩家所知的怪物。要了解这些怪物的技能,你就需要进行尝试,让它对你发动攻击。这样从本质上来说,可能就要耗费一次游戏机会。如果要更深入地了解怪物,那么就要浪费更多的时间。
《100 Rogues》
我觉得通过上文的叙述,我已经将所有的观点都表达清楚了。开发者应当尊重他们的用户,认识到顾客的时间是宝贵的。事实就是,用户给予你的所有东西都是珍贵的礼物。你应当给予他们的回报就是能够提供趣味互动的游戏。
需要澄清的是,尽管我仍然为《100 Rogues》的面世感到骄傲,但是它犯下了以上全部的罪行。我像多数roguelike游戏开发者那样设计游戏,所以就产生了那些关联性并不是很大的机制(游戏邦注:探索、资源管理、角色计划和战术等)。
而正因为此让游戏显得过于复杂。我们是否需要在《100 Rogues》中加入抛投机制(游戏邦注:即在游戏中将道具作为武器抛投出去的功能)?我之前觉得需要这种设计,因为其他的roguelike游戏中都有这项机制。但是游戏确实需要这项机制吗?是否对核心机制起到支持作用?什么才是核心机制?
现实在于,在制作《100 Rogues》的过程中,我学到了很多东西。在漫长的开发进程进行一半时,我意识到游戏需要个核心机制。但是,当我意识到这点时已经为时过晚了。我们已经在各种功能中投入了太多的时间和精力。
事后对此进行反思,我认为《100 Rogues》是我意图采纳现代电子游戏哲学现状的产物。现在我已经认识到这种做法会产生何种结果,在此期间我也学到了更多的内容,我对此并不满意。所以在我们的下款游戏中,我们会进行更深层次的挖掘,锁定根源以解决这些问题。
《Auro》
在游戏开发正式启动前,我花了将近1年的时间来设计游戏。我在设计之处便知道游戏需要有个核心机制,游戏需要尽量显得简单,游戏需要避免浪费玩家时间。
我将游戏的核心机制定为战术。玩家需要使用特殊的战术技能来对抗怪物的战术技能。
游戏的核心是配置,配置自身、怪物和你的能力。
我想要在这款游戏中尽量减少隐藏复杂数字所起到的作用。
我不希望玩家在玩游戏时需要作复杂的考虑,就像“这个怪物有324点的生命值,他每回合造成的伤害是33点。我有131点的生命值,每回合造成的伤害是42点。我装备有+3的火剑,但是怪物有10%的火抗,而且他还有20点的护甲,我的护甲为32点……”。
这简直会令人发疯!这便是游戏的现状!为何我们要用复杂的数学运算来抽象化游戏玩法呢?
《Auro》中的多数怪物都只有1点的生命值,即便在后期的关卡中。有些怪物可能有2或3点的生命值,但是多数怪物只有1点。在整个游戏过程中,你的攻击伤害也是1点(游戏邦注:这种移除大额生命值的方式会强迫游戏设计师发掘游戏中每个怪物的有趣成分,而不是单纯设计那些有着两倍生命值的精英怪)。
你拥有的许多能力并不能直接造成伤害,它们可能会改变你或怪物的状态、削弱怪物或在非常特别的情况下造成伤害。通常情况下,你需要在战斗过程中使用多种技能来使得受益效果最大化。这种设计再次保持了游戏的复杂性直接体现在屏幕上。
你可以直观地从屏幕上看到最为重要的信息,即怪物与你的相对位置。游戏的要点就在于领会这些信息,并且决定下一步要如何移动、攻击或使用技能。
所有的内在复杂性信息都应当让玩家可以轻易获取。游戏中有内置手册,玩家可以在任何时候查看,其中包含所有怪物、机制和技能的信息。当你进入新阶段时,游戏还会详细地说明将添加哪种怪物以及它的能力和技能。
然后,你可以选择技能(游戏邦注:也就是说,你无需在升级时保留技能点以备不时之需)。你可以在每个关卡中选择一项技能,游戏中没有经验点数!当然,了解怪物并不等同于你知道在所遇到的特别情形中要如何应对这些怪物。
说道技能,游戏的复杂性就在于“训练”系统。每种怪物都有1到2个技能,但是玩家有5个技能树——力量、冰霜、火焰、闪避和防护。每个技能树各自都含有5个技能。每次玩游戏时,玩家都可以自行搭配所有技能,创造出独一无二的角色。所以,你可以看到《Auro》中的确还有角色计划机制,但是你也可以看到这种机制清楚直接地同核心机制——战术联系起来。
我还将装备融入到整个技能系统中。游戏中不再有你能够捡起然后可以毫无干涉地被动防御伤害的“护甲”道具,提供防御的是“防护”技能树上的“强化”技能。但是,这个咒语的使用需要适当的计划。它可以帮助你抵消伤害,但是只持续5个回合,而且在此期间你不能移动。这意味着使用这个技能属于需要进行思考的战术,而不是单纯地让你的角色防御属性+1。
该游戏中的地图完全不遵从roguelike游戏的传统。《Auro》的重点不在于探索,探索不属于核心机制。《Auro》的地图更像是“线路”,随机产生但是几乎完全显性而且比多数地下城地图要短。这样设计的好处就是,游戏不需要小地图,因为智能手机没有足够的屏幕实用面积来安放小地图。
你或许会觉得《Auro》中所有的东西都不是随机的,事实并非如此。地图产生是随机的,道具放置、怪物位置、怪物选择(游戏邦注:每个新关卡都会随机增添新怪物)等完全是随机的。
为确保我们不会浪费玩家的时间,我们也处理了其他问题。线性化的小地图确保整个游戏过程中充斥的都是有趣的选择,但是多数开发者可能很不情愿做的事情就是削减动画。
与即时游戏相比,回合制游戏的动画没有任何可玩性意义。因而许多roguelike游戏(游戏邦注:比如《100 Rogues》和《Shiren the Wanderer》)中的动画完全是累赘。《Auro》中自然也有动画效果,但是数量有限。角色移动简单,咒语也能够很快地产生效果,同时伴随着很棒的动画效果。角色没有移动时也会有些许动作,让游戏显得栩栩如生。
《Auro》有着专注和清晰的设计,同时给玩家留下了足够的自定义空间和技能提升空间。这款游戏能够受到玩家的欢迎还犹未可知,但是我认为自己创造出了身为玩家很想玩的游戏。
总结经验和教训
尽管我经过多次总结才得出了这种游戏设计方法,但是我觉得这与游戏设计的“经典”方法很相似。我希望更多设计各个题材游戏的开发者能够考虑这种方法,提出些最基础的问题。
许多绝妙的现代游戏都已经采用了这种方法。《Spelunky》体现了平台游戏使用随机地图的意义,《Super Smash Bros.》展示了战斗中对角色位置的侧重,《Shadow of the Colossus》简化和削减了游戏中小怪的数量。
我们正处在视频游戏发展史中的不成熟阶段,每种题材都有急需解决的基础性问题。尽管我很喜欢《100 Rogues》,但是制作出那样的游戏根本体现不出游戏设计师的价值。无论《Auro》能否为玩家所接受,我都为这款游戏感到骄傲,因为这才是真正“设计”出来的游戏。
《Auro》的进程
即便游戏已经设计了1年之久,但是真正的创作是从2011年7月开始。我们的计划是花3个月的时间来完成游戏,但是或许真正完工的时间会稍微推迟些。当然,玩法测试是很重要的,所以我们使用Flash来制作游戏原型。我们的程序员对这种语言很精通,所以我们可以很容易地测试不同的想法,找出那些毫无意义的内容。(本文为游戏邦/gamerboom.com编译,如需转载请联系:游戏邦)
Radical Rethink: How 100 Rogues Begat Auro
Keith Burgun
In my previous Gamasutra article, “The Cautionary Tale Of 100 Rogues”, I described the process behind designing, developing and marketing of my 2010 iOS game, 100 Rogues. My team, Dinofarm Games, and I have started working on a new game. While, on its face, it shares many surface-level things in common with 100 Rogues, I’d like to explain how and why I went back to the drawing board and looked at the fundamental aspects of the genre.
The new game in question is called Auro, named after the spoiled prince protagonist. To describe it in a line, it’s a “turn-based, hex-based, dungeon-crawling strategy game”. Note that it’s not a “role playing game”, and it’s not a “roguelike”. Which is funny, because the game’s original working title was actually “THE ROGUELIKE”.
However, as you’ll see, my design process and philosophy stripped away so many elements of these genres that when I stepped back, I realized that what I had on my hands no longer fit that title. Players will decide for themselves, of course, but by sticking to a philosophy, I think I’ve stumbled upon something entirely new.
Not that it really needs to be said, if you’ve played 100 Rogues, but I’m a huge fan of roguelikes; Dungeon Crawl and Shiren the Wanderer are two of my all-time favorite games. However, I also think there are inherent problems with the genre. Some are probably thinking, “Yes — they’re too hard and unforgiving”. Actually, though, I think that’s one of the main things they do right.
The fact that these games are challenging, and your choices actually matter (because if you make a wrong choice, there are consequences that cannot be undone — imagine that!) are exactly what make them fun and interesting. The problems as I see them with roguelikes are issues that face most video games: over-complexity, unfocused game design, and temporal inefficiency.
Over-Complexity
Before video games, there were still games, of course; board games, card games, sports, word games, and little “don’t step on the black tiles!” type-games created by children. However, before computers, games had to be simple for practical reasons — they were limited by the physical realities of the medium. For example, if you want your sport to catch on, it’s very nice if a few friends and I can play with nothing more than a ball and a field. If we need 12 different types of balls, several goal-types, and lots of other equipment, we’re just less likely to go to all of the trouble.
Computer games, however, do not have this limitation at all, and developers really take advantage of it. In fact, such great advantage has been taken of this ability to continually add more complexity to games, that we’re now completely taken in by a sort of “more is more” philosophy.
I think that this negatively affects almost all modern video games, and with DLC and in-app purchases, the problem is certainly not going away (to put it lightly!)
But more is not always more. When adding “more” to a game you decrease the likelihood of being able to balance the game. If the game is not balanced, then a dominant strategy emerges — that one weapon or unit or move that everyone uses over and over. Now where did your complexity go?
All of that effort designing, creating and implementing those features was wasted. Your game now effectively contains only a few usable items.
Great games usually don’t have a ton of inherent complexity — that is, the complexity of the rules and content. Great games have a limited amount of inherent complexity, and a great amount of emergent complexity — the complexity that emerges through play.
For a great example, think of Go or Tetris — the ingredients of the game are super-simple, but when you put them into action, it unfolds into an awesome array of meaningful choices. This is where we get the (now lost?) mantra that games should be “easy to learn, difficult to master”. Many modern video games these days end up feeling more like an asset tour — look through all the assets, use them all once, and then buy the next game.
Finally, we also want to be very careful when adding “more” to our game designs because the more we add, the more difficult our games are to learn. That’s part of why we have this expectation that the first act of our games will be a tutorial — because if anyone uninitiated by video games tries to play Ocarina of Time or Fable, they’ll likely have a hard time picking up all of the complex rules from scratch.
This issue of more being more absolutely affects roguelike design. One could almost say that part of Nethack’s appeal is this novelty idea that the game includes almost everything one could imagine (in fact, I believe it even includes a kitchen sink). Dungeon Crawl: Stone Soup has, even by the admission of the lead designer, too much stuff. Early on in the 100 Rogues’ development, I noticed that I was trying to add too much stuff as well. We had originally intended for many more weapon and armor types to be in the game, but stumbled into problems.
Unfocused Game Design
The second problem with roguelikes is a bit more fundamental. This means that while you don’t see as many resulting surface-level issues, the problems that it does cause are actually more harmful overall. This problem I’m talking about is unfocused game design. Students of the modern era of video games will find this concept truly bewildering, I think, but in my experience it is absolutely true for games and for all arts in all mediums.
A game design should have a specific purpose; one single thing that it is trying to do. The reason is that a game is, at its most basic level, a machine that does a specific task, that manipulates human emotions in just the right way using patterns of tension and release to get a very specific desired effect. Good stories are driven by controlling ideas; good essays are driven by thesis statements; and good game designs are driven by a very specific target gameplay experience.
I teach game design classes at a small local art school, and one of the first things I teach is when designing games, we should first start with the question, “what is the fundamental, essential experience that we want to have?”
Keep in mind, these essential experiences should usually be something abstract — some interesting new spacial relationship, or resource-managing pattern, etc. Then we try to figure out what core mechanism would express that experience best.
All gameplay mechanisms should be in direct support and directly related to your core mechanism. Then, the last step should be to choose a theme that makes your game as clear and easy to understand as possible.
With roguelikes, it’s rather unfortunate that this is not the path their design takes. They start off with the theme and a whole kit of gameplay mechanisms, which relate to each other only in nebulous ways gameplay-wise.
To name a few, Nethack is about tactics, exploration, resource-management, character planning, as well as simply learning what all the items, monsters, weapons, and armor in the game actually do. For this reason, none of those mechanics are particularly well-developed in the game; it’s a Swiss Army Knife game design. And because it doesn’t do any one thing particularly well, we get bored more quickly than we would with a game like Super Mario Brothers (NES) or Puerto Rico (board game), both of which do one thing extremely well.
An unfocused game design is also much harder to balance (since mechanical relationships are far less clear). Finally, a messy game design document usually leads to a lot of…
“Temporal Inefficiency”
Games are about making interesting decisions — this is what defines them. Compare them to something like puzzles or toys or simulators, none of which have the explicit need for decisions (if there are any to be made) to be interesting. But start up most any modern video game, and you’ll find that you’re usually only making interesting decisions a handful of times in an hour of play.
To test this, have a friend manage two separate stop clocks. The one on the left will go, straight, for 20 minutes, while the one on the right will only count the seconds while the player is making an interesting decision. With most modern video games (particularly single-player ones), most of the player’s time will be spent running down a linear corridor, watching a cutscene, pressing “A” because the game told him to press “A”, load-times, grinding for stats, or other no-brainers.
In 10 hours of modern video games, I predict we spend nine hours waiting for the one hour of actual fun. This is the rate of temporal inefficiency for a game, and I find a low one to be disrespectful to the audience.
While roguelikes are far from the worst offenders in this regard, wasting the player’s time is a huge problem for the genre. Dungeon Crawl has huge labyrinths that you have to explore in order to play, with interesting encounters happening once every 20 or 30 turns. I soon realized that there is an “auto-explore” hot-key: “o”. Pressing this button has the computer automatically explore the dungeon in a decently efficient way.
Indeed, I use the o key all the time, because it explores just about as well as I could and it’s much easier than moving around via the numeric keypad. However, it’s still time I have to waste getting to the interesting encounters, waiting for the decision-making sections. If you ever have a gameplay mechanic that’s such a no brainer that it can be automated, it should be cut.
Every roguelike I’ve ever played has had monsters whose abilities are not made clear to the player. To learn what they have to do, you have to pretty much bump into them and let them do it to you once or twice. So, essentially, it may cost you one game in order to learn what a monster even does, wasting your time further.
100 Rogues
I think by now my positions on all of these topics have by now ever-so-subtly leaked out. Developers should respect their audience and recognize that their time is precious. The fact that they’re giving you any of it at all is an amazing gift. Repay them with a slick, well-oiled machine that does nothing but dispense interesting interactions.
To be clear, I’m very proud of 100 Rogues, but it is guilty of all three of the above sins. I approached the game just the same way as most roguelike developers do: “let’s make another roguelike game!” And so it came with the entire kit of not-so-related mechanisms (exploration, resource management, character planning, tactics, etc).
And because of this, it also suffered from some subtle kinds of over-complexity. Did we need throwing (meaning, the ability to throw any item in the game as a weapon) to be part of 100 Rogues? I thought we did because other roguelikes had it. But does it really need to be there? Does it help support the core mechanism? What is the core mechanism?
The truth is that I was learning a ton while I was making 100 Rogues, and about halfway through the (long) process, I realized that we did, in fact, need a core mechanism after all. However, it was too late. We’d already invested too much in various functionalities to cut them out.
In hindsight, I think 100 Rogues was my attempt to take the status-quo modern video game philosophy, and see how good I could make it. Well, now I’ve seen, and the more I learn, the less satisfied I am. So for our next game, we’re looking deeper, and targeting all of these problems at their roots.
Auro
I started designing Auro almost a whole year before the game’s development actually began. I knew early on that there needed to be a core mechanism, that the game needed to be as simple as possible, and that the game needed to not waste any of the player’s time.
I decided that the core mechanism for the game would be tactics. Players would use special tactical skills against the tactical skills of the monsters.
This would make as much of the complexity and interrelationships be right there, on the grid, visually clear and obvious, not hidden away in a series of numeric stats on a menu screen somewhere. The game is about positioning — positioning yourself, positioning the monsters, positioning your abilities.
I wanted to downplay the role of hidden complex numbers as much as possible.
I wanted to avoid things like, “Oh, that demon has 324 hit points, and he deals 33 damage a turn, and I have 131 hit points, and I deal 42 damage per turn, but I’m using a +3 fire sword, but he’s got 10 percent fire resistance, and he also has 20 armor points, and I have 32 armor points, and…”
It’s nuts! This is how our games work! Why would we want to obscure our gameplay with complex mathematics?
Most monsters in Auro, even late-game, have 1 hit point. Some have two, or even three, but generally most have 1. For the entire game, your attacks deal 1 point of damage (no stat-scaling — one great side effect of removing this is that it forces me, as a designer, to come up with an interesting role for every monster in the game — no “demon” and then “super demon” with 2x HP).
Many abilities you have don’t deal damage directly; they either change positioning of yourself or monsters, debuff monsters, or deal damage in very special circumstances. Usually, you’ve got to use more than one ability in concert in an intelligent way to actually maximize the benefit of most skills. This keeps all of the complexity, again, right on the screen.
You can literally see the most important information right on the screen — the positions of the monsters in relation to yourself. The game’s all about taking that information and making decisions about how you’re going to move, attack or use skills.
All inherent complexity information should be made easily available to the player. The game has an in-game manual that can be accessed at any time, that contains information about all monsters, mechanisms and particularly the skills. When you start a new stage, it tells you exactly what monster is being added to the mix, and it tells you what he does.
Then, you choose a skill (meaning that there’s no need to “save a point” when you level up to see what you might need later). That’s right — you choose a skill every level — there are no experience points! Of course, just because you know what a monster can do, doesn’t mean you’ll know how to deal with what he does, in the specific situations you’ll encounter.
Speaking of skills, the bulk of the game’s complexity is in the “Disciplines” system. Each monster type has one or sometimes two skills, but the player has five discipline trees — Power, Ice, Fire, Elude, and Guard. Each of these has about five individual skills in it. The player can mix and match skills to create a unique character each time they play. So, you can see that Auro does indeed have a character-planning mechanism, but you can hopefully also see how it very clearly and directly relates to the core mechanism — tactics.
I also condensed down equipment into the skills system. Instead of there being an “armor” item you pick up once and then it just passively protects you without you having to think about it, now there is a Fortify skill in the Guard tree. This spell requires planning to deploy, however. It defends you from some damage, but it lasts for five turns, and you cannot move while it’s on. This means that using it is a tactical choice that must be thought about, rather than just a dull +1 to your character’s stats.
Maps don’t follow roguelike convention at all anymore. Auro is not about exploration; exploration has nothing to do with the core mechanism. Auro’s maps are more like “courses”; they’re randomly generated, still, but almost totally linear and shorter than most dungeon maps. This has the added bonus of not needing a mini-map, which smartphone screens simply do not have the real estate for anyway.
You may be thinking that Auro is completely without randomness, but that isn’t the case. The maps are random (if linear), the item placement, monster placement, monster selection (levels will have different monsters in it from one game to the next) and more will definitely be random.
With regards to making sure we aren’t wasting the player’s time, much has already been addressed. Linear, small maps means that from beginning to end, the game is nothing but interesting decisions. But here’s a huge one that most developers probably aren’t willing to even consider: cutting animations.
Developers of turn-based games need to understand that in a turn-based games, animations do not have any gameplay meaning, as they do in real-time games. Therefore, in any roguelikes where there is animation (there aren’t many, 100 Rogues and Shiren the Wanderer come to mind), the player is sitting and watching animations. Auro will still have some animation, but it will be very limited. Characters will slide from tile to tile like game pieces, and spells will happen quickly with nice-looking animated effects. Idle-animations will still be there when you’re not moving, so the game will feel alive.
Auro has a very focused, clean design, that still allows plenty of room for players to experiment and become better at playing the game. Whether or not it resonates with players is yet to be seen, of course, but I can honestly say I’m making exactly the kind of game I would want to play as a player, and what more can we do as game developers to ensure our success than create something we really believe in?
What can you take from this?
Even though I arrived at my approach to game design slowly and through much of my own calculation, I think that it is quite similar to a “classical” method of game design. I hope that more game developers consider this approach for their game, regardless of genre. Ask fundamental questions.
Many of the greatest modern games have done this. Spelunky pondered “maybe it makes more sense for a platformer to have randomized maps”. Super Smash Bros. pondered “maybe fighters should be less about what moves/combos you’re doing, and more about where you are positioned on the screen.” Shadow of the Colossus pondered, “maybe we don’t need to populate our maps with a bunch of small easy-to-kill monsters; instead, you only fight the Colossus”.
We’re in a very early immature stage of the history of video games, and there are fundamental problems with just about every genre that need to be addressed. As much as I like 100 Rogues, making games like that is not the job of game designers. You don’t need a game designer to make another game like 100 Rogues. You need programmers, artists, musicians and all of that, but you don’t need game designers. Regardless of how it’s received, I’m proud of my work for Auro, because it is a game that was truly designed.
A few words on Auro’s progress
Even though the game design started over a year ago, formal production of the game only began in July 2011. Our production schedule aims to complete the game in three months, but it will likely be at least a little longer than that. Playtesting is of paramount importance, of course, and so one thing we’re doing with Auro is starting off with a Flash prototype. Our programmer is most proficient in the language, and it’s easiest to test out different ideas and make sure none of them are absurd nonsense.
Of course, you can keep track of our progress via our official site. We’ll be needing Beta applicants soon! (Source: Gamasutra)