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

列举开发者容易忽略的游戏多人模式问题

发布时间:2012-10-09 16:46:05 Tags:,,,

作者:Robert Dieterich

电子游戏中的多人模式几乎同电子游戏一般年代久远。至少可以追溯至乒乓球的发源时代。作为游戏采用的古老方式,你可能认为,我们至今所遇到的问题均与多人模式运行时发现的问题有关。但是,这种想法是错误的。

从游戏设计的角度上看,我们常会在解决多人模式方面遗漏些许问题,而在实际操作中,这些问题才会突显出来。在大型团队中,后期的发现可能会造成耗费一些不必要的修复时间,因为这些问题一被发现,可能会涉及到负责游戏设计决策的人们,并追溯到功能执行者。

所以,为了将游戏开发中的这类问题扼杀在萌芽阶段,以下简单列举某些我们通常会忽略的多人模式问题。

multiplayer gaming(from sciencedaily.com)

multiplayer gaming(from sciencedaily.com)

游戏中的数据由谁保存?

过去,大多数多人模式并未在数据持久性方面采取任何举措。更别提用户保存数据方面。现在,由于游戏中出现玩家档案及类似元素,玩家更有可能在游戏中保存自己的数据。虽然让玩家保存自己游戏记录的做法颇有意义,然而,当涉及到角色、选项和关卡的解锁时,事情就会陷入混乱状态。玩家可以挑选所有其他玩家解锁的角色吗?还是他们只能在自己解锁的角色中进行挑选呢?游戏的类型不同,这些问题的最佳答案也各式各样,而这些对菜单UI的核心设计具有深远的影响。

在游戏关卡上,我们必须考虑如何处理玩家游戏进程的数据。玩家可以在体验多人模式时解锁某些关卡吗?如果他们因同级别更高的玩家合作,从而可以不按顺序地解锁关卡,那会发生什么?这也是以玩家1为主导的合作类游戏中采用玩家2(宾客对象参与游戏)的原因。虽然玩家2会保存一些统计数据,但是游戏进程的主要数据仍取决于玩家1。

游戏主要以谁的故事为模版?

在包含重要故事元素的游戏中,处理过场动画中的额外玩家是该类游戏所面临的主要问题。因为制作拥有多种角色(或合作角色)的过场动画需耗费巨资,因此过场动画通常只需关注主角(指玩家1),而玩家2的角色只需出现在背景中。游戏中常用的另一种方法即让玩家2操控某个往常由AI控制的角色。这样,“好友”角色可以成为可用的故事情节,同时为玩家2提供他们想要参与体验的平台。

游戏中的菜单由谁决定?

castle-crashers(from nerdgranny.com)

castle-crashers(from nerdgranny.com)

如果玩家和非玩家共同参与游戏的话,《Castle Crashers》并非一款出色的多人游戏。我提及这一想法的主要原因是它的地图菜单。由于基本上任何人都可以同时控制地图,所以我们从未选择自己喜爱的游戏阶段,因为总有人调试自己的控制器。也可能有人懒于移动按钮开关,而有人试图选择游戏阶段。同时,有人总试图弥补流失的输入量,进一步复杂化这种混乱状态。最后,我们不得不呼吁其他人在他们选择游戏阶段时,不要触碰控制器。但最终的结果是:非玩家们会因多度担心而调节控制器,而玩家们有时会试图忽略对方的关卡选择。

表面上,《Castle Crashers》试图让所有参与其中的玩家感受到“公平”,它允许玩家同时控制关卡选择菜单。可惜,这种做法只会导致上述结果。这也是为何大多数战斗游戏会在对抗模式中随机选择由某位玩家挑选竞技背景。你希望玩家为谁是更优秀的战斗者而争辩,而不是为下一阶段该玩什么内容而争执不休。在《Castle Crashers》这种情况中,敲定由谁控制关卡地图等此类明确决策,就有助于缓解大家难以达成共识这种多人游戏体验的问题。

多人模式游戏很棒,坐在沙发上玩的类型尤其如此。但同时它也会产生许多看似微小实则会深深影响游戏核心体验的问题。如果我们有些先见之明,就应该在类似问题发生之前予以解决。对于需耗费大量预算打造的项目,这种先见之明尤为关键。(本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

Player 2, Press Start

by Robert Dieterich

Multiplayer in video games is almost as old as the medium itself. It’s at least as old as Pong, right? As such an old institution in games, you’d think we’d have all the issues related to implementing multiplayer in games figured out by now. Of course, you’d be wrong. Otherwise, I’d have nothing to write about in this article.

In terms of handling multiplayer from a game design perspective, there are several issues that tend to slip through the cracks until they show up during actual implementation. In large teams, the late discovery of these issues can cause disproportionate amounts of time being spent to fix them as they wind their way from the discover’s desk to the people responsible for game design decisions and back to the feature implementor.

So, in an effort to nip that sort of game development waste in the bud, here is a short list of common multiplayer oversights that I’ve seen crop up in the wild.

Whose Save Data is This Anyway?

In the past, most multiplayer modes had very little in the way of persistent data. Let alone data that may be saved per user. Nowadays, with player profiles and the like, it’s quite likely for each player in the game to have their own save data. While it makes sense in terms of having each player save their own play records, things can get messy when we start talking about unlockable characters, options, and levels. Should multiple players be able to select from a union of characters unlocked by all the players? Should players only be able to select characters they themselves have unlocked? The best answers to these questions vary by the kind of game and have significant effects on the core design of menu UI.

In terms of playable levels, one must think about how a player’s progression data is handled. Will a player be able to unlock levels by playing multiplayer? What happens if they unlock levels out-of-order by playing with someone who has progressed further in the game? This is one of the reasons that games with co-op campaigns tend of have player 2 as a sort of guest participant in player 1′s host game (and save data). While player 2 may save some statistical data, the main progress data remains wedded to player 1.

Whose Story is This Anyway?

In games with a significant story element, handling of extra players in cutscenes can be a major issue. Because of the significant costs involved in creating cutscenes that could handle a variable number of stars (or co-stars), it’s common for the cutscenes to simply focus on the main (player 1′s) character while player 2′s character simply shows up in the background (if at all.) Another common approach is to have player 2 take control of a normally AI-controlled character. This allows the “buddy” character to be available story-wise while also providing a vessel for player 2 to participate should they want to play.

Whose Menu is This Anyway?

Castle Crashers is not a good party game. Not if you have a mix of gamers and non-gamers anway. The main reason I say this is because of the map menu. Basically, because everyone could control the map simultaneously, we could never select the stage we wanted because someone was always fiddling with their controller for some reason or another. Someone might be moving the thumbstick idly while someone else is trying to select a stage. In the meantime someone else was always trying to compensate for stray inputs, further complicating the mess. Eventually, one of us had to yell out and tell everyone else to not touch their controllers while they selected a stage. The end result: the non-gamers were too intimidated to touch their controllers while the gamers would occasionally try to override each other’s level decision.

Seemingly in an attempt to be “fair” to all players involved, Castle Crashers allowed them all to control the level select menu simultaneously. Unfortunately, this led to the above result. This is why most fighting games arbitrarily choose one player to pick the arena backgrounds during Versus mode. You want to the players to squabble over who is the better fighter, not over what the next stage should be. In the case of Castle Crashers, some explicit decision as to who would control the level map (essentially, a party leader) would have gone a long way to smooth the multiplayer experience with any disagreements about level choice ultimately being filtered through a human arbiter before being chosen in the game.

Multiplayer gaming is great, especially the local, on-the-couch kind. That being said, it can bring along with it a lot of seemingly minor issues that can deeply affect the core experience of a game. With a little bit of forethought, it’s possible to address these issues before encountering them during implementation. In a project with any sort of significant budget on the line, this sort of forethought is crucial.(source:gamasutra)

 


上一篇:

下一篇: