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

开发者需适应并谨慎管理游戏制作风险

发布时间:2013-09-02 10:35:42 Tags:,,,

作者:Florian Schwarzer

恶梦是什么?恶梦就是,你组建了一支优秀的团队,辛苦地工作了两年,发布了一款精良的游戏——最后眼睁睁地看着它失败了。

更可怕的是:我们这个行业每天都在上演这种悲剧。

令人惊讶的是,我们并不太经常讨论这种风险。甚至我们当中那些肩负着“企业责任”的人似乎也在逃避这个话题。我们经常讨论开发过程或领导策略,却极少花时间探讨如何应对开发风险。这通常会让你产生一种错觉:我们在发布游戏方面一直在进步——但事实上,我们在保证产品成功方面却没有什么长进。

是不是因为居于成功游戏的核心的东西与导致其他软件成功或失败的东西完全是不同的?

长久以来,我们的项目管理一直向软件开发行业看齐,我们从中学到的经验已经帮助我们改进制作游戏的方法。但我仍然认为,局限性是存在的;我们所面临的挑战是其他软件开发管理者永远不会遇到的。游戏开发者遇到的第一个挑战是:游戏设计。

小区别

游戏是用来娱乐的。这就把游戏与传统的软件区别开来了,游戏相当于软件的子类别。这也意味着我们承担的风险与电影或小说一样:我们的受众可能根本看不到我们的游戏好在哪里。研究人员称之为“制作风险”。

Illustration(from-develop-online)

Illustration(from-develop-online)

作为管理者,我们通常认为风险就是应该最小化的威胁,或者在更糟的情况下,至少应该缓解。然而,我们也能这样对待这样的风险:玩家感觉不到我们认为有趣的东西到底有趣在哪里吗?

基本上,让某种东西变得有趣的很大一部分在于让受众产生好奇心。众所周知,我们喜欢新事物——几乎所有游戏都努力地为它的玩家提供一定程度的新意。我们研究,我们制作,我们宣传崭新的东西,无论它是实验作品还是老游戏的续作。

豪赌

当然有一个问题:对我来说是原创的东西,可能对你来说是老套的。要在做出来以前预测一款游戏是否达到我们的期望是非常困难的。特别是还要考虑到这么多受众,预测基本上是一件不可能的事。想一想为什么好莱坞电影会走进模式化的怪圈。

显然,这意味着冒太多创作风险是不明智的。毕竟,如果我们发布的产品与以前的产品都大不相同,那么它很可能就迎合不了大多数人的品味,是吧?

确实,但我们的玩家仍然喜欢新玩意。像《传送门》或者《Wii Sports》这类游戏表明,如果你冒险了,并且找到受众,反响是会非常热烈的。创作风险就像搞投机——结果可能好也可能坏。

当然,围绕一个比较保守的概念做出一款好玩的游戏也是有可能的。比如《星际争霸2》,就是一个成功的案例。再以吉他游戏为例,它们的主题太保守了,虽然执行得不错——所以它们的玩家都玩不久。所以,保险也是一种冒险。

说到底,无论你做的游戏是哪种类型、你做得有多好,你仍然是在投骰子。游戏的卖点正是让游戏成功又冒着最大风险的东西。所以,我们在计划时必须认真考虑。

管用吗?

显然,如果我们想帮助游戏设计师处理有风险的设计,我们首先应该评估它们。同样显然的是,最好能尽快把这些设计做出可测试版。

这里有一个好消息,所有与游戏设计有关的部门都有自己的一套快速制作原型和测试想法的办法。因此,制定测试计划似乎是相当容易的事。比如,你可以先测试新设计的纸上草图,再模拟UI,逻辑原型,最后在测试服务器上发布完全版。这种计划很吸引人,因为让团队和投资商都感到稳妥。当然,它是不管用的。

部分原因在于时间。团队总是太专注于详尽的测试,结果却发现没有时间修复错误的地方。

更糟的情况是,玩家测试产生混乱的数据。玩家会提出各种改进建议,不同看法很容易产生分歧,所以解决方案当然也是五花八门。这时,只要主要投资人或主管认可这种不同的意见,那么游戏设计师马上就失去他们自己的概念的控制权。

敏捷开发的局限性

为了解决时间不足的问题,似乎只能把大规模的原型制作活动严密地整合到开发过程中。让我惊讶的是,当我开始做敏捷开发方面的顾问时,有人告诉我,这是一个糟糕的主意。

我们都知道Scrum和极限编程。把待做事项列成一个目录,把最重要的东西放在最上面。这就好像为自己设定了一系列冲刺目标,每到达一个目标,就应该做完一定量的工作。因为追求每一个目标的过程都是一场冲刺赛跑,所以挤出来的时间就会越来越多。

但我们当中许多人都忽略了“传统的”敏捷开发是什么。没有标志性事件,没有审查。做完前面几周后,最重要的东西做出来了。然后,随着冲刺目标,团队会做出更好的东西。

顺着这个逻辑,把冲刺时间用于制作最终可能要丢掉的原型或要重制的东西,简直就是浪费。制定全面计划?那就是我们出错的地方。

对于B2B应用开发,敏捷开发适用于开发确定的东西。然而,确定排在目录最前面的东西对用户来说就是重要的,这是不可能确定的事。这也是游戏开发中不能确定的。

Illustration(from develop-online)

Illustration(from develop-online)

根源

这意味着,我们应该适应游戏设计的创作风险,我们必须根据我们的领域特性安排开发流程。我们不知道我们最中心的特征对玩家来说是否有价值。我们只能希望是。

对我而言,那些特征和它们被实证的程度,应该作为项目的驱动力。从根本上说,这意味着接受它们每一个都可能被多次重制的事实。以我的经验,不要对实现可能性少于60%的特征做计划。

更大的挑战:我们必须接受争论的存在。它有助于迫使游戏设计师在一开始就确定特征。这样当被告之某个特征不可行时,他们就能很快提供提供实现方法。这使设计师具有一定程度的测试自主权,并且为任何讨论设置可行性标准。

最后,我们必须让投资方发挥一定的影响力。为此,在大测试完后制定一个里程碑式的阶段性目标是明智的。这样你就更加了解你的项目进展到什么程度。因此,如果有必要,这时候也是最适合讨论变化的时候——比如增加预算、调整规模或者取消特征等。

变化也是我们不太讨论的另一个话题。但如果我们能严肃地对待制作风险,我们就总会考虑到那一步。在纸上看起来各种牛逼的东西,可能根本实现不了。尽管如此,太过冒险仍然是不可原谅的错误。(本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

Managing risk: The creative gamble

by Florian Schwarzer

Here’s a nightmare: Build the best team you can, work hard for two straight years, release a well-crafted game – and watch it fail in the market.

Here’s the crazy thing: We work in an industry where that nightmare comes true somewhere every day.

Surprisingly, we don’t talk about this very often. Even those of us who carry ‘business responsibility’ over our games seem to avoid the topic. There’s valuable discussion of development processes or leadership strategies, but little time is spent on how to deal with the great volatility of our products. Often, you’ll get the impression that we’re improving at releasing games on time – but not at ensuring their success.

Can it be that this is because what is at the heart of a successful game is radically different from what makes or breaks other software?

For a long time, our project management has looked to IT for its cues, and what we learned from there has enhanced our way of making games. Still, I would argue that there are limits; challenges we have to face that other software managers will never see. Most of them start with two words: game design.

THE SMALL DIFFERENCE

Games try to entertain. This sets us apart from traditional software, like eshops. It also means that we run the same risk as any movie or novel: Our audience might just not find the game appealing. Researchers call this ‘creative risk’.

As managers, we usually think of risks as threats to be minimised, or, in the worst case, mitigated. One has to wonder: Is the same possible for the risk of people not having fun?

Fundamentally, a big part of what makes something entertaining is down to curiosity. We like new things. This will be news to nobody – pretty much every game tries to offer some degree of novelty to its players. We search, we build, we advertise fresh new features, whether in an experimental title, or a sequel.

ON GREAT GAMBLES

There’s a problem, of course: What may seem original to me, can feel trite to you. Even individually, it can be very difficult to predict whether a game will meet our tastes before we try it. For a whole audience, it becomes effectively incalculable. Just consider how often century-old Hollywood gets it wrong.

Intuitively, this means that it’s a bad idea to take a lot of creative risks. After all, if we release a product that’s different from anything that’s come before, there’s a good chance it’ll miss everyone’s tastes, right?

True, but our players still really like new stuff. Games like Portal or Wii Sports show that if you take the risk, and manage to connect to your audience, the reaction can be tremendous. Creative risk is speculative – its outcomes can be negative or positive.

Of course, it is possible to build an entertaining game around a relatively conservative concept. Take StarCraft II, a careful extension of a well proven game. Then again, take the guitar game genre. There, we have a group of very well executed titles that got too conservative – and saw their audience move on. Taking no creative risks is a risk, too.

In the end, no matter what kind of game you build and how well you build it, all you get is a roll of the dice. The game’s USPs, the very things that can make it succeed, will carry the greatest, most central risks. Accordingly, there’s nothing we should take more seriously in our plans.

DOES IT WORK?

Obviously, if we want to help our game designers deal with risky features, we should help evaluate them. Just as obviously, it’s a good idea to make these features testable as quickly as possible.

The good news here is that every discipline involved in the creation of games has found its own ways of quickly prototyping and testing ideas. Based on those, it seems pretty easy to set up whole test plans. Say, you start out by testing a paper draft of a new feature, graduate to UI mock-ups, logic prototypes, and eventually release a fleshed-out version on a beta server. Such plans are hugely attractive. They reassure the team and stakeholders. Also, they don’t work.

Partially, it’s down to time. Way too often does a team invest into elaborate tests, only to discover that there’s no room to fix what is broken.

Things can get even worse, though: User tests, by their very nature, produce messy data. It’s easy to come to rivaling interpretations, and thus solutions. If a major stakeholder subscribes to such a differing view, the game designers may quickly lose control over their own concept.

THE LIMITS OF AGILE

To avoid all this, it seems sensible to integrate large-scale prototyping more tightly into the development process. To my surprise, when I began consulting Agile experts on this, they told me it was a bad idea.

We all know the basic artifacts of Scrum and XP. You’ve got a backlog, with the most important stuff up top. You’ve got a sprint, during which a certain amount of stuff is supposed to get done. You’ve got a working increment, which grows sprint by sprint.

What a lot of us miss is that, as far as ‘traditional’ Agile is concerned, that’s it. No milestones, no gates. After the first few weeks, the most important stuff is in. Then, with every sprint, the team will be able to release something better.

Following that logic, it’s a waste to spend a sprint building a prototype that may get discarded or even lead to a rework of stuff that’s already done. Setting up whole plans full of that? That’s missing the point.

For B2B application development, the environment Agile was built for, that’s true. There, it is possible to ensure that what is at the top of the backlog is also the most valuable for the user. In games dev, that’s the very thing we often can’t be sure about.

THE ROOT CAUSE

What this means is that to accommodate the creative risks of our games, we must tailor our processes in ways unique to our field. We don’t know whether our most central features are valuable to the player. We only hope so.

To me, those features – and the degree to which they are proven – should drive a project. At the root, this means accepting that each of them will be reworked many times. In my experience, one shouldn’t plan with less than 60 per cent of feature-specific contingency here.

More challenging: We have to acknowledge that there will be controversy. Here, it can help to have the game designers prepare while they are defining the features in the first place. Ask them to name ways by which to tell that the feature doesn’t work. It provides the designers with a degree of ownership over the tests, and sets a reliable yardstick for any discussion.

Finally, we have to give our stakeholders a fair chance to take influence. For this, it’s sensible to set milestones after major tests. There, you will have learned something important about your project. Thus, if necessary, it’s the ideal time to discuss changes – whether that means budget extensions, scope adjustments, or the dreaded cancellation.

That’s another thing we don’t talk about. But if we take creative risk seriously, it’s a step we should always consider. It’s always possible that what sounded fun on paper doesn’t really work out. Pressing on nonetheless – now that’s inexcusable.(source:develop-online)


上一篇:

下一篇: