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

开发者在游戏设计过程中需重视风险管理

发布时间:2011-09-01 22:11:19 Tags:,,,

作者:Danc

游戏开发者大会真的很棒。但是不幸的是,我真的不擅长逐字逐句地记笔记。当我开始动笔时,我的整个脑子里充斥的都是一些关于原型设计,工具和生产风险等有趣的谈话内容,因此便形成了一篇很长的随笔,而本文只是其中之一。

风险管理

很多游戏项目都要涉及风险管理。游戏制作是一个复杂的过程,其中还包括你要判断玩家的喜好,技术的使用,新型交互性和市场动态的变化等因素。开发一款单人游戏将面临一场很大的风险,因为这种游戏的失败几率远远大于其成功的几率。一个小小的错误便会让整个开发团队面临巨大的财政危机,甚至遭到游戏发行商要求改组的致命打击。

这是当代游戏开发中最需要考虑的问题。以下我粗略地列举了几种风险类别,同时也有缓解这些风险的一些技巧。

财政风险

需求风险

执行风险

财政风险:最致命的问题

managing-risk(from aj-solutions.org)

managing-risk(from aj-solutions.org)

所有的产品开发过程都包括游戏制作,并最后为玩家呈现有价值的游戏。作为回报,玩家将会为你的游戏付费。如果你在这个过程中获得了利益,你将可以继续开发更多游戏。但是如果你因此遭受了损失,那么你将停止生产该游戏而利用剩下有限的资源制作其它有利可图的游戏。因为在经济学里不容许任何浪费资源的行为。

财政风险便是指那些会让你亏钱的任何可能事件。同时这一风险也潜在地影响着其它风险的发生。不管怎样,一味想着“赚钱”并不能帮助我们优化生产过程。我们同样需要考虑“我们制作的是什么游戏”以及“我们要如何做才能做好它”。

需求风险:我们制作的到底是什么?

需求风险是关于我们提供的游戏是否能够满足用户的需求。这一风险可细分为三大类别。可以说,任何一种需求风险都有可能为游戏带来不可估量的财政风险:

设计风险:缺乏明确有效的目标客户定位

范围风险:做的太少或者做得太多。做的太少会引起设计风险,而做得太多也会造成执行风险和财政风险。

市场风险:市场的变化将改变你的价值定为。而这也将成为影响你游戏的外部因素。

在上述三种风险中,设计风险是最基本的风险,并与其它两大风险一起制约着你的游戏发展。为了缓解这种需求风险,你需要有一个明确的产品定位,而这种定位将在外部因素影响你的目标市场时发生相应改变。

执行风险:我们要如何做?

一旦你清楚了自己需要做什么,你就可以开始执行你的计划了。这时候你还需要考虑4大附加险:

人员风险:你选择了一些态度不端正或缺乏责任心的人员去执行任务。同时这里也存在一种创造性风险,这意味着作为一名创造者,你无法成功创造出一款优秀的产品并以之为傲。创造性风险常常与财政风险相冲突。

技术风险:你所依赖着的技术失去了成效。常见的技术风险包括游戏引擎的渲染、路径查找等。在游戏中,当出现了新的游戏机制时,便很有可能导致这种风险的产生。当我们在与现实中的玩家进行交流时,一个小小的游戏机制变化都有可能招致惊人的结果。就像对游戏角色的跳跃距离做出了一个不适当的调整,会因此破坏了剩下游戏的所有乐趣。

计划风险:延迟游戏的发行时间而因此错失有利的市场环境。游戏存在于市场循环中,每款游戏都有自己的“保质期”,一旦你没有把握好机会,将大大提高已经确立风格的项目的市场风险。

质量风险:游戏出现错误。一款游戏即使解决了所有问题,但是仍存在着一些漏洞和缺陷。

缓解风险:一个很难解决的问题

你会因为这些难以解决的风险而喘不来气。在Douglas Adams所著的《Dirk Gently’s Holistic Detective Agency》一书中有一个很棒的章节,讲述的是主人公努力将卡在楼梯里的沙发搬到自己的公寓里。作者用电脑创造出一种3D模式以指出如何才能将沙发从楼梯里拉出来,但是最后却没能成功。而Dirk Gently这个横向思维的男孩快速地解决了这一问题。他只要简单地拆除一面墙即可。但是不幸的是,沙发问题解决了,他的整个房子却被破坏了。真见鬼!

而在现代游戏的开发过程中经常会出现类似的境况。就像我们在为我们的游戏选择适当的功能时会遇到的一些基本问题。按照工程学的方法我们需要添加更多的游戏功能。桥梁设计师会将其称为过度工程学,这是一种需要经受住时间考验的技巧。按照这种方法,你的游戏能够满足所有人的需要,因为它已经包含有足够多的功能了。

游戏开发过程中也存在一种副效应。在增加范围时,你需要同时满足人员,技术,时间和质量等因素的要求。而这些因素都不是位于同一水平线上:

当你为团队招揽了越来越多人员时,你将发现团队中的交流过程会发生巨大的变化。一个只有2名成员的团队可以同时坐在一个房间里商讨问题,但是一个拥有20名成员的团队却需要有一个领导来主持大局。更别说一个200多人的团队将会浪费成员们大量的个人时间而用于维持团队凝聚力和团体内部沟通。每一个阶段都是不同的,都需要融入一些文化观点以更好地解决问题。

当游戏功能变得越来越多且越来越丰富时,你将同时需要更多新的技术为辅助。新的游戏机制将可能改变游戏系统,并会对玩家的游戏体验造成影响。每一个新的游戏功能都有可能破坏整个游戏的价值。

越多功能就要求投入越多的时间,而越多的不确定性将严重影响预期的时间安排。这些不确定因素都是由技术风险和人员风险引起。

当你在解决单一风险时,你将会不时地遇到一些烦人的二次风险,而这些风险也将会给你的整款游戏带来致命的打击。

复杂过程的范围

这些高风险,且相互联系的系统最后将会得到合理的解决。事实上,人们已经发现很多传统意义上的解决方法都是适得其反的。当人们执拗地去解决那些位于同一层面上的问题时,将会发现那些不在同一层面的风险会突乎其然地出现,并打乱你的所有安排。

首先你需要意识到产品的制作过程分为不同类型,而每一个类型都需要用运用不同的治理技术。以下的图解是摘自Scrum方法论(游戏邦注:Scrum是一种迭代式增量软件开发过程,通常用于敏捷软件开发。Scrum在英语的意思是橄榄球里的争球)用于描绘需求和执行风险中的不确定性而引起的不同过程。

Scrum Complexity(lostgarden)

Scrum Complexity(lostgarden)

简单的过程:如果你明确了需求和执行风险,那么游戏中的风险就能用一些相对简单的过程来解决了。一份简单明了的清单便是诀窍。即一个工人在同一流水线上重复着同样的工作便可以称得上是简单的任务。

复杂的过程:如果需求和执行风险失去了控制,那么你照样可以按照你自己的清单完成游戏。为了完成任务,你应该增加一些相应的规则和必要的步骤。建造桥梁就是一个复杂任务的典例。

复合的过程:有些游戏虽然明确了需求和执行风险,但是仍存在很多不确定因素,这将导致这些游戏陷入困境。在这种情况下,如果能及时反馈相关信息并作出及时处理,那么再大的风险和不确定性也能得以解决。软件开发便是复合型任务的一个案例。

混乱的进程:当需求和执行风险等不确定性因素变得非常明显时,游戏很有可能陷进一种噪杂无章的混乱状态。而这时如果想取得成功还真的需要一些运气出现了。

游戏开发着实是件有趣的事,因为这一过程中所包含的所有因素都贯穿于整个复杂范围的各个区域。

简单:创造2D图像

复杂:创造3D角色模型

复合:编程

混乱:创造新的游戏机制

游戏邦注:原文发表于2006年4月2日,所涉事件和数据以当时为准。(本文为游戏邦/gamerboom.com编译,如需转载请联系:游戏邦

Managing game design risk: Part I

GDC was wonderful. Unfortunately, I’m the sort of person who is absolutely miserable at copying notes in any literal way. As soon as I started writing, I became distracted by a thread connecting several intriguing talks on prototyping, tools and production risk. The result was a very long essay. This is the first part.

Managing Risk

Much of game production is about managing risk. We partake in a highly complex process that juggles people, technology, new forms of interactivity and rapidly changing market dynamics. Developing a single game is a high stakes effort in which the likelihood of failure is dramatically greater than that of success. One false move and the development team can face financial ruin or heavy restructuring at the request of their publisher.

It is a fascinating optimization problem that drives many of the practices in modern game development. Here are some rough notes describing different forms of risk as well as my initial thoughts on techniques for mitigating certain types of risk.

Financial Risk

Requirements Risk

Execution Risk

Financial Risk: The big daddy

All product development consists of the act of producing and delivering something of value to customers. In return, the customers give you money. If this process produces profit, then you can develop more products. If it produces a loss, you are heavily encouraged to stop making such products and do something more profitable with your limited resources. Economics abhors waste.

The likelihood that you will lose money is financial risk. It is the invisible hand that makes all other forms of risk meaningful. However, simply looking at ‘making money’ does not tell us enough to optimize our processes. We also need to look at what we make and how we make it.

Requirements Risk: What the heck are we making?

Requirements Risk is all about making the right product for our customer. It is split into three interrelated categories. Naturally, any one of these risks can increase the project’s overall financial risk.

Design risk: Risk of not including the right features that create a potent value proposition for your target audience.

Scope risk: Risk of not doing enough or doing too much. If you don’t do enough, you increase Design Risk. If you do too much, you increase execution and financial risks.

Market Risk: Risk that there will be changes in the market place that invalidate your value proposition. Market risk is external to your project.

Of these three, design risk is the most fundamental with the other two acting as constraints. In order to mitigate requirements risk, you must choose the minimal right features for your product. This correct set of features changes over time as external events influence your target market.

Execution Risks: How do we make this?

Once you understand ‘what’ you need to do, you need to execute on your plan. At this point, four additional risks raise their ugly heads.

People Risk: Risk that you do not have the right people with the right motivation and methods of work to execute. A subset of this is creative risk, in which you fail to create a product that you, as a creator, takes pride in. Often creative risk can be in conflict with the constraints of financial risk.

Technical Risk: Risk that major technology that you rely upon will fail. The obvious aspects of technical risk are things like rendering engines, path finding, etc. In games, technical risk also fluctuates wildly with the addition of new game mechanics. Since we are dealing with psychological interactions with real customers, minor game mechanic changes have surprising results. Even the act of adusting a character’s jumping distance may not ‘work’ since it can destroy the fun factor for the rest of the game.

Schedule Risk: Risk of delaying the product and missing a competitive window in the market place. Games are products with a shelf life and strong market cycles. When you miss your dates, you dramatically increase Market Risk for certain types of established genres.

Quality risk: Risk of errors. A product that solves all other factors, but includes bugs and other malfunctions.

Mitigating risk: A difficult problem to solve

You end up with a web of constraints with no easy solutions. There is a wonderful section of Douglas Adams book “Dirk Gently’s Holistic Detective Agency” in which the lead character manages to get his sofa stuck in the stairway going up to his flat. He creates a 3D computer model of the situation to figure out how to get it unstuck, but can’t manage it. Dirk Gently, the world’s lateral thinking poster boy, solves the problem in seconds. All he has to do is remove one of the walls. Unfortunately, the solution to moving the couch would destroy the entire house. Woops.

Modern game development often finds itself in a similar situation. Let’s take the fundamental problem of choosing the right features for our product. An obvious engineering path is to add more features. Bridge builders might call this over engineering, a time tested technique. That way, you’ll ensure that you make a product that solves everyone’s needs since it contain more than enough features.

In game development, the secondary effects kick in. By increasing your scope, you increase the need for people, technology, time and quality. None of these scale linearly.

When you add more people to a team the communication processes within a team change dramatically. A 2 person team can sit in a room together and talk through problems. A 20 person team needs defined managers and process. A 200 person team often spends the majority of each individual’s time simply maintaining group cohesion and intergroup communication. Each stage is distinct and requires major cultural shifts to succeed.

As features increase in number and diversity, the need for new technology development increases. As game mechanics are added, the very nature of the system and its effect on the customer fluctuates radically. Each new feature has a very real chance of destroying the value of the entire product.

More features require more planning time and uncertainties can result in large schedule fluctuations. These are compounded by technology and people risks.

When you optimize for a single risk factor, you’ll often have unpleasant secondary risks that bring down the whole system.

The spectrum of process complexity

These high risk, heavily interconnected systems finally are getting their due. Building games is not like engineering bridges. In fact, folks have started to notice that many traditional project management are counter productive. When someone attempts to scale the project by turning one of the dials, the non-linear risk increases in unpredictable ways and the product fails.

The first step is to realize that there are different types of production processes and each one requires radically different management techniques. Here’s a diagram from the Scrum methodology that describes how uncertainty in both requirements and execution creates multiple classes of processes.

Simple Processes: When both requirements and execution are quite certain, then the projects can be managed with relatively simple processes. Often a simple checklist does the trick. The repetative steps that a single worker performs on an assembly line is a good example of a simple task.

Complicated: When the requirements and execution get out of hand slightly, you end up with a project that can still be completed with your typical check list. However, you need to increase the number of rule and steps necessary to accomplish the task. Bridge building is a good example of a complicated task.

Complex: Many projects fall into the dangerous middle ground where requirements and execution is somewhat defined, but rife with multiple layers of uncertainty. In these situations, high feedback, agile processes let team steer their way towards ago despite high risk and uncertainty. Software development is a good example of a complex task.

Chaotic Processes: When both requirements and execution uncertainty is very high, projects tend to devolve into unmanageable chaos. Success arises as often from luck as it does from any real process.

Game development is intriguing because it contains elements spread across all areas of the process complexity spectrum.

Simple: Creating 2D art

Complicated: Creating 3D character models:

Complex: Writing Code

Chaotic: Creating new game mechanics

If you end up focusing on a shoehorning all elements of gameplay into a single process, you are bound to leave gaps in your competitive strategy. With that thought in mind, I’ll be posting a couple more essays shortly that use this conceptual framework to examine two common risk mitigation strategies.

Data driven development: Reducing risk by simplifying the process of game development. This technique focuses on reducing overall execution risk.

Prototype driven development: Reducing risk by embracing change and finding the fun earlier. This technique focuses on reducing overall design risk.(source:lostgarden


上一篇:

下一篇: