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

游戏新手教程设计应避开的8大误区

发布时间:2011-06-15 21:14:11 Tags:,

作者:Ernest Adams

早期的游戏行业是视频游戏(包括掌机游戏和大型街机游戏)的天下,但这类视频游戏却总让玩家备受折磨,因为这类型游戏并未提供给玩家足够的游戏教程,玩家几乎完全依靠自己的力量去战胜游戏中不断涌现的敌人。玩家失败的时候,也正是这些街机游戏大量吸金之时。

因为电脑游戏难于大型电玩游戏,所以它们经常在游戏开始前提供给玩家一些游戏说明。但是今天,我们已经不能指望还有多少玩家会耐心阅读这种说明,所以便开始采用新手教程向玩家介绍用户界面和游戏玩法,让他们清楚游戏目标或者任务,以及他们能够在游戏中得到何种奖励等。

最近我有幸担任Extra Credits Innovation Awards大赛评审团中的一员,而这也就意味着我必须尝试一些新游戏,而且不得不在很短的时间内快速学会这些游戏。

但是在这个过程中我却遇到了一些带有低劣新手教程的游戏,所以我不得不针对此事提出看法。

虽然新手教程的功能是用来教授玩家玩游戏,但是游戏设计者并不是教师。我们希望游戏中能够充满挑战,所以不希望提供给玩家一个“全盘透露”的新手教程,而是希望玩家能够通过观察并体验游戏过程,学习到更多东西。

Playdom副总裁Raph Koster曾经指出,当玩家在掌握了一种游戏后,他便能够感受到这款游戏设置的乐趣所在,但是这个过程却远远不够。新手教程也不能只是帮助玩家掌握游戏玩法。它还必须让玩家知道他们的游戏任务是什么,他们能从游戏中获得何种奖励等。新手教程的作用是让玩家了解游戏的一些基本要素,为他们在游戏初期提供帮助,而不是引导他们如何过关斩将,直至游戏结束。我发现最近很多游戏的新手教程做得并不得体,以下我将列出新手教程必须避开的8大误区。

game tutorial(from blog.fantage.com)

game tutorial(from blog.fantage.com)

强迫玩家阅读新手教程。玩家在每一次打开游戏时,都必须再次阅读新手教程,不论他是否已经熟悉了游戏流程。如此反复地向玩家解说他已经熟悉的事怎么能不让他们感到厌烦呢?而且这种设置也在无形中浪费着玩家的娱乐时间。

新手教程作为游戏的第一或第二个环节,经常会不可避免地出现于游戏中。而且如果玩家能够自行控制新手教程的播放,关掉或跳过自己已经熟悉的信息提示,那么他们也不会因此感到烦躁了吧。

最简单的解决方法便是把新手教程环节与游戏过程独立开来,并设置成为玩家可以自行选择的环节。对于很多游戏角色而言,包括战士,运动员,驾驶员,甚至是国王和城市规划者等,在开始进行正式的游戏体验前接受新手教程的“培训”是非常重要的。但是如果你实在不想把新手教程从主体游戏中区分开,那么你就必须确保玩家能够按照自己的需求,选择是否阅读该教程,或直接进入游戏环节。

提供过多繁琐信息。一整个屏幕上都是文字介绍,玩家不得不烦躁地点击着鼠标阅读一页又一页教程内容。使用这种仿中世纪的语言(即冗长繁琐的表达)进行描述并不符合时代潮流,更糟的是,玩家并不容易被这种循循劝诱式的独白陈述所收买。例如“The A button swingeth thy sword! Essay it now. Aye, ’tis well done”便是使用中世纪语言叙述的新手教程。

我还发现,这种叙述方式常常使用大标题或者海报标题的字体进行描述,而因此破坏了游戏的整体画面感。

曾经我玩过一款日本游戏,它的新手教程非常长,甚至第一页内容就需要我拉着鼠标阅读10分钟之久。显然,我不可能长时间地记住这么多的内容,常常是玩到游戏最后就忘记了将近一半的教程内容。但是我认为,如果玩家能够边玩游戏边学习,那么他们便能够快速又牢固地掌握游戏玩法了。

除此之外,不要让玩家一直阅读游戏的背景故事。例如在电影《星球大战》中,从“内战时期”到“整个银河恢复自由”这整个背景叙述过程只花费了1分14秒。所以,既然大导演George Lucas(《星球大战》导演)都觉得这个时间绰绰有余了,你又何必执拗于游戏背景的长短呢。比起背景来说,更重要的是让玩家了解游戏接下一步的发展情节。

未能准确描述按钮和菜单项。如果你只是提及某个按钮但却未向玩家详细指明,那么这种新手教程将会让玩家感到厌烦。例如虽然你在新手教程里描述“点击屏幕左上方的Sell按钮”,但是屏幕上方却出现了5个不同的按钮并且没有一个按钮标示着“Sell”字样。同样的,如果你指示玩家选择菜单项,但是玩家却会因为找不到菜单项的位置而无从下手。

比起文本描述,带有标识的按钮更有效率,它不仅能够帮助节省屏幕空间,而且也不需要游戏设计者更多地考虑定位问题。所以游戏设计者必须通过新手教程教会玩家每一个按钮标识的意义和功能等。

当你在描述每一个按钮时,最好能同时在屏幕上突出那个对应的按钮,例如你可以在那个按钮周围添加金色的亮光,让玩家能够一眼分辨出,并因此记住它。

当你在描述菜单项的使用时,最好能把整个过程呈现给玩家,即不要只是说“你可以在定制菜单选项的图形标签中找到它”,而换成“选择帮助>参考>定制菜单>图形标签”。后者的描述能让玩家对此过程一目了然,但是却很少游戏能够按照这一步骤进行描述。

遗漏教程步骤。有些游戏的新手教程常常会在描述过程中遗漏了下一个游戏步骤,使玩家不得不在充斥着陌生的按钮和菜单项中疑惑不已。当玩家因此失去耐心而打算离开游戏时,游戏说明又会突然蹦出屏幕,使玩家对此感到莫名其妙。

比起其它游戏步骤,新手教程的设计应该更为周密,细致。而且如果你的游戏较为不同,或者说主题较为新颖,那么你就更应该考虑如何做才能更加妥当地向玩家介绍游戏。我不反对有限的教程内容,但是如果是那种会卡在解释中途的教程,我就不报任何好感了。所以不论你想要如何表达游戏内容,都必须保持整个教程的周密性。

惩罚缺少经验的玩家。当玩家在新手教程的游戏过程中失利后,便会被退回之前的游戏位置重新开始游戏。这种游戏设置会让玩家感到沮丧。

最让我不能忍受的是,当我在游戏中学习如何跳跃时,经常会因为一些小失误而掉落到之前的位置,且需要我再花费2分钟的时间才能回到现在的游戏点。这种设置在正常的游戏过程中已经很讨厌了,更何况是在新手教程中呢。因为玩家通常都希望能够在自己失利的位置再次开始游戏挑战。

当我在为Innovation Awards活动尝试新游戏时,一款游戏的新手教程让我印象深刻,因为玩家有可能在新手教程里就输掉整个游戏。这款游戏的新手教程并未明确指明玩家的游戏目标,但是我也尽力按照它所指示的进行游戏,可是出乎意料的是,当我走到游戏的最后几个环节时,它却告知我“被淘汰了”。对于在游戏一开始就面临这种打击确实心里会不好受。我认为新手教程应该让玩家轻松完成游戏并带着积极的心态开始完整的游戏体验。如果玩家在新手教程中输掉了比赛,那么也等于这个新手教程失去了玩家。

奉承或批评玩家。当玩家每次完成准确按下一个回车键这种极简单的任务时,便会听到“非常棒”这种过于夸张的表扬,并且玩家每回操作都会听到这种声音。这种激励手段好比是在赞扬一个刚学会扣扣子的四岁小男孩。

另一种情况就是,当玩家在游戏中出错时,还会听到一些“批评”的话语,甚至会出现“你好逊”之类的犀利评价。极少有新手会喜欢因自己的一点小失误而听到这种批评的话语。

无需赘述,新手教程所体现出的情感语调应该是正面且具有鼓励性,而不能带有任何屈尊俯就的意味。虽然在现实生活中,那些有建设性的批评不可或缺,但过度的批评就鲜有人可以接受了。

强迫玩家阅读完所有的教程内容。玩家通常能在阅读部分的新手教程后便掌握了游戏技巧,熟悉了游戏图片,并能够开始进行游戏。但是很多游戏的设置却让玩家不能自如进行选择。因为游戏设计者认为那是他们精心设计的新手教程,不论玩家是否愿意,都应该认认真真地看完所有内容才能开始进行游戏。

如果你的新手教程与游戏过程是相互孤立的,那么玩家便可以随时离开教程页面而进行游戏。但是如果你的新手教程是与游戏进程结合在一起,那么你必须让玩家能够自行选择是否阅读新手教程。

未提供任何新手教程。如果整个游戏既未包含HUD界面,也未提供任何屏幕指示,玩家全凭自己的独创性和直觉进行游戏,那么他们将不可能长时间沉迷于这种类型的游戏。并未提供任何指示而把玩家孤身置于一个完全陌生的游戏世界中,这种游戏怎么能让玩家产生依赖感呢?

我在这次的Innovation Awards大赛中就遇到了一款这种类型的游戏。一开始我对它的UI就不带任何好感。它展示的是3D第一人称游戏画面,但呈现的却是摇摇晃晃的视角,感觉人物角色因极度虚弱而失去方向感。

而且因为这款游戏并未提供任何新手教程,我必须反复摸索它所谓的直觉式用户界面,只为打开游戏中的一扇“门”而花费了5分钟时间。

迄今为止这种人机交互的直觉型用户界面被捧上神坛已有十年之久,但我却不得不直言,这根本行不通。因为除非你正在制作一款电脑教程游戏,否则电脑中的任何输入设备都不可能与游戏所模拟的现实世界的活动作出回应。

追溯到世嘉的Genesis(游戏邦注:家用游戏机)时期,那时我正致力于开发《Madden NFL》,我在游戏中设置了相关的指示,即告诉玩家如何通过使用三个按钮以及方向盘“开始游戏,抱着球前行,将其传给其他接收者,接收者抓到了球,并带着球前进”等功能。因为在Genesis时代并没有足够的游戏空间让我们插入新手教程,所以我们只能通过捆绑销售的游戏指南向玩家传递相关的游戏信息。

任天堂Wii控制器以及今天的Kinect体感周边设备的出现使这个话题重新浮出了水面,同时也有很多玩家希望能够体验《Minority Report》式的操作界面。我想说的是,这些人肯定早已忘记,或根本就不知道为何鼠标会早于触屏设置出现。因为比起鼠标,触屏设备不适于长久使用,它会导致玩家的手臂因为长时间游戏而变得酸痛麻木。就像《Minority Report》所展示的技术一样,这种操作方式虽然看起来很酷,但却不适宜长久使用。

当然了,如果玩家拥有一些较为专业的游戏装备,包括飞行模拟装置的高端操纵杆或者《Donkey Konga》中使用的DK Bongos等,那他们便不再需要新手教程了。但是你却不能指望玩家都能拥有这些设备,除非你的游戏也搭售这些设备,这意味着你还得针对他们的普通控制器另外再设计一个新手教程或操作指南。

简单的来说,你的用户界面必须能够映射整个游戏世界的活动,而且不管通过什么方式或者在什么地方,你都必须让玩家对此界面感到熟悉且充满兴趣。同时你也不能完全按照自己的直觉设计新手教程,因为你在游戏设计过程中已经无数次地经历了游戏体验,对这款游戏可以说是了如指掌了,但是对于玩家来说,他们仍是这款游戏的新手,所以你必须为他们量身定做一个新手教程。

总结

也许一些读者会认为我所陈述的并非是什么建设性的批评意见。虽然我在全文一直阐述不要做什么,什么是禁忌,但是我却还未告诉你什么才是正确的做法,怎样才能创造出最优秀的新手教程。因为游戏类型的多样化,所以我们很难针对它们创造出一些通用准则。例如射击游戏的新手教程与建筑类或管理类游戏的新手教程明显不同。所以我想我能给的最好建议便是,你必须通过一些游戏新手测试你的新手教程(也包括游戏)是否合理,是否有效,且是否能被玩家接受。(本文为游戏邦/gamerboom.com编译,如需转载请联系:游戏邦

The Designer’s Notebook: Eight Ways To Make a Bad Tutorial

by Ernest Adams

[In his latest Designer's Notebook column, veteran Ernest Adams takes a frank and factual look at in-game tutorials, explaining exactly what games do wrong so you can make sure that, when you set out to create your tutorial, you do it right.]

In the early days of the game industry there were video games (console or arcade) and home computer games. Video games threw you into the deep end of the pool: you faced an onslaught of enemies with minimal instruction and you either sank or swam. Mostly you sank, which is how arcade games made their money.

Computer games were more complicated than arcade games, so they gave the players manuals to read before starting to play. These days we don’t expect players to read manuals, so we give them tutorials instead. Tutorials introduce the player to the user interface and the gameplay. They should explain how the player interacts with the game world, what she’s trying to achieve, and (briefly) why.

Recently I had the privilege of serving on the jury for the Extra Credits Innovation Awards, which meant that I had to play — and therefore, learn to play, several games in a hurry.

One or two had tutorial modes so bad that I decided we’d better talk about them. Bad manuals and/or bad tutorials are already Twinkie Denial Conditions, but the Bad Game Designer, No Twinkie column in which I introduced them didn’t go into much detail.

Tutorial modes exist to teach the player, and game designers are not natural teachers. We’re used to creating challenges, not explaining principles. Throughout most of the game, the players are expected to learn things on their own through observation and experimentation.

As Raph Koster has pointed out, much of the fun of gameplay come from learning to master the game, but this process is inefficient. The tutorial shouldn’t be like that. It should tell players what to do and show them what happens when they do it. It should let the players master the basic elements of using the software — guiding them into the shallow end rather than throwing them into the deep end. But as I recently discovered, there are a lot of ways to do it badly. Here are a few.

Force the player to take the tutorial. Whenever the player starts the game over, make him go through the tutorial again. Do this even if he has played it a dozen times before. Bore him with explanations of things he already knows. Irritate him with tiresome trivial challenges. Waste 10 or 20 minutes of his time before he can get to the fun part.

Games often include unavoidable tutorials because the tutorial also constitutes the first level or two of the game. There’s not much harm in this if the player can turn the game’s advice off, or interrupt it. But making the player struggle through a swamp of information he already knows is tedious and annoying.

The simplest way to resolve this is to put the tutorial in its own optional area, separate from the rest of the game. It works for many game roles. Soldiers, athletes, pilots, and for that matter, kings and city planners all go through training phases before they start their real work. If you really want to build your tutorial as part of your main game, make sure the player can turn the teaching elements off and just play straight through.

Square Enix’s Nier

Make the player read a lot. Give the player screen after screen after screen of introductory material to read, with nothing to do but press a button to move from one to the next. Write it in faux-medieval language full of anachronisms, or worse yet, as the monologue of some tiresome mentor character with a lot of irritating verbal mannerisms. (“The A button swingeth thy sword! Essay it now. Aye, ’tis well done.”) Display it all in an ugly typeface that was originally intended for headlines or poster titles, but never for large blocks of text.

I once played a Japanese game whose tutorial mode consisted of ten solid minutes of pressing a button to move to the next screen of text. Of course, by the time I reached the end I had forgotten half of it. Players will remember much more if they learn by doing.

While I’m at it, don’t make the player read huge amounts of back story, either. The opening crawl of the first Star Wars movie takes one minute and 14 seconds, from “It is a period of civil war” until “restore freedom to the galaxy” fades off the screen. If that was enough for George Lucas, it’s enough for you. Let the players learn the rest from context.

Describe buttons and menu items badly. You can make your tutorial mode even more irritating by including references to a button without identifying it clearly. For example, say “Press the Sell button in the upper left of the screen” when there are five different buttons up there and none of them labeled Sell. Similarly, tell them to choose menu item X when no menu item X is visible. Put the actual menu item X down a level or two in the menu tree with no instructions about where to find it.

Buttons with icons on them take up less screen real estate than text does, and they don’t have to be localized as much, so they’re generally a good idea. However, the player needs to learn what the icons mean and what the buttons do, and the tutorial should teach this.

When your text refers to a button, highlight the button on the screen at the same time – put a golden glow around it or something, and make it pulse or flash.

If you refer to something down in the menu tree, be sure to indicate the whole path. Don’t say, “You can find it on the Graphics tab of the customization menu,” say “Select Help > Preferences > Customize and choose the Graphics tab.” This might seem obvious, but you would be surprised how few games do it!

Leave steps out. Get partway through a step-by-step tutorial and then suddenly stop giving the player instructions. Leave her on a game screen full of buttons and menus with no idea what she’s supposed to do next. After she has hesitantly tried something, suddenly start giving instructions again without any reference to what she just did.

Some tutorials need to be more thorough than others. The more unusual your game, or unfamiliar its subject matter, the more you need to explain things. I’m not objecting to limited tutorials here, but to a tutorial that starts out with a detailed explanation and then suddenly disappears. Whatever level of detail you choose, maintain it throughout.

Punish the player’s inexperience. When the player makes a simple mistake, go back a long way and explain everything again in excessive detail — or make the player go back a long way. You can drive his frustration level up by punishing small errors with long delays.

When I’m trying to learn how to jump in a game, one of the things I hate most is falling down a long chasm that takes me two minutes to climb out of before I can try the jump again. This is bad enough in normal gameplay, but it’s inexcusable in a tutorial mode. When a player fails at a jump, or any other physical challenge, she should be able to try it again immediately.

One of the games I played for the Innovation Awards had a tutorial in which you actually lose the game! It wasn’t very clear about what I was trying to achieve, but I tried to do what it told me to, and at the end, it said I had lost. I can hardly think of a more discouraging start to a game. Completing the tutorial should have give the player positive emotional rewards. If the player fails at the tutorial, then clearly the tutorial itself has failed.

Patronize or humiliate your player. Tell the player “Very good!” in an overly chirpy voice when he has successfully managed to find and press the Enter key. Do it every time he does this. Praise him as you would a four-year-old who has just learned to button his own shirt.

Alternatively, humiliate your player when things go wrong. Tell him what a loser he is. New players love being harshly criticized for not knowing the very things that the tutorial is there to teach them.

This doesn’t require much explanation. The emotional tone of a tutorial should be positive and encouraging without being condescending. As in the rest of life, constructive criticism is useful, but abuse is not.

Force the player to complete the whole tutorial. It’s possible that partway through your tutorial, the player will feel that she’s got the picture and is ready to go ahead and start the game. Oh, no. Not a chance. You put a lot of effort into that tutorial and she is going to have to finish it whether she likes it or not. After all, it’s your game, not her game.

If you have a separate tutorial level, let the player quit it and move on. If your tutorial is built into your ordinary level progression, let the player turn off the tutorial elements.

Don’t give them a tutorial at all. Devise what you think is an ingenious and totally intuitive interface, preferably without a HUD or any on-screen indicators that would prevent the players’ complete immersion into your brilliant universe. Make it so transparently obvious that no instruction is needed. Throw them in and wish them luck.

One of the games I had to judge for the Innovation Awards did exactly that. The UI left me nauseated — its 3D first-person view weaved drunkenly around, apparently in an effort to convey the notion that my avatar was feeling sick and disoriented.

It worked; before long, so was I. It also took me five minutes of experimentation with its supposedly intuitive user interface just to figure out how to open a door.

The totally intuitive user interface has been a holy grail of human-computer interaction for decades now. I’ll be blunt: there’s no such thing. Unless you’re making a computer game about using a computer, the machine’s input devices are unlikely to correspond to the real-world activity that the game simulates.

I worked on Madden NFL as far back as the Sega Genesis days, and I can tell you that choosing a play, then snapping the ball, passing it to one of several receivers, catching it, and running with it are not trivial with three buttons and a D-pad. We did it very successfully — but we still had to ship a manual with the game. There wasn’t room for a tutorial in a Genesis cartridge.

The arrival of the Wii controller and more recently the Kinect has moved the issue to the foreground again, and some people are very excited about the possibility of Minority Report-style interfaces. These folks have forgotten — or probably never knew — why the computer mouse was invented in the first place. Touch screens are tiring to use for long periods, because you have to hold your arm up all the time. Waving your arms around, as in Minority Report, is even more tiring. It might look very swishy and cool, but you can’t do it for hours on end.

Players don’t need a tutorial as much if they have specialized gear, of course — a high-end joystick for flight simulators (but they’ll still have to press a key on the keyboard to lower the landing gear), or the DK Bongos for playing Donkey Konga. But you can’t count on the player owning these devices unless you ship them with the game, and that means he still needs a tutorial or a manual for his ordinary controller.

Put simply, your user interface must map the machine’s controls to game-world activities, and somehow, somewhere, you’re going to have to explain that mapping. And your interface almost certainly isn’t as intuitive as you think it is. You’ve been playing your own game for months or years, so it’s second nature to you, but your players are new to it. They need a tutorial. Really.

Conclusion

Some of you might have noticed that this isn’t very constructive criticism. I have identified a number of things not to do, but I haven’t told you how to create a good tutorial. That’s because it’s hard to create general rules for a medium as diverse as ours is. A tutorial for a shooter game will necessarily be very different for one

from a construction and management simulation. The best positive advice I can offer that covers all the cases is, be sure you try out your tutorial on complete novices — and your game too, for that matter.(source:gamasutra


上一篇:

下一篇: