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

游戏制作人分享做好项目前期管理的10条经验

发布时间:2019-11-29 09:00:02 Tags:,

游戏制作人分享做好项目前期管理的10条经验

原作者:David Manuel 译者:Vivian Xue

去年,在我曾经居住过的澳大利亚布里斯班,发生了30多年来最严重的洪灾。然而过去的几个世纪里,这座城市经历了好几次这样的洪水。

每次洪水过后,委员会都会研究讨论未来减轻洪灾的方法。然而大多数建议都被忽视了,重建工作依旧在洪泛平原上展开。这种现象存在于世界各地的种种事件中——无论是洪水、火灾还是暴乱。我们成立委员会,提出建议,然后搁置它们、遗忘它们直到事件再次发生。

同样的情况发生在电子游戏制作领域。我们经常花时间写反思——但人们真的听取这些教训了吗?功能蔓延、高强度加班、士气低落、缺乏重心和方向、团队内部或开发者与发行商之间的沟通问题、缺乏技术和管理方法,看到这些老问题不断重现令人沮丧。

从整个行业的角度来看,我们往往没能把习得的经验应用到实践中。

过去十多年来,我们听过许多人谈论敏捷开发以及必须拥抱变化,这些都很有道理。然而,即便我们采用敏捷开发,相似的问题还是会发生,甚至在某些情况下加剧了。

本文旨在讨论如何在项目初期最大程度减轻这些问题,主要是通过打牢基础和提前计划实现的。换句话说,即便天气难以预料,修建堤坝和避免在洪泛区上开展重建工作总比坐等下一次洪水来袭明智得多。

1. 确保先前项目的经验得到运用

不是所有团队都会在项目结束后写反思,他们要么对此漠不关心,要么认为这毫无意义。然而,如果我们想从错误中学习,我们必须对所有项目进行事后分析,尤其是那些被取消的项目。

这个过程必须是公正合理的,既要建立在平等友好的基础上,同时必须不留余地、全面深刻地反思什么是对的、什么是错的以及今后如何改进。

相关人员撰写完反思并一致同意通过后,应该把它提供给工作室的全体成员——最好放在公司内部网站上,确保成员们能够轻松找到并查阅它,而不需要在成堆的邮件和折叠文件夹中搜寻。

开始新项目时,确保反思中的相关经验有运用到实践中并定期检查,以避免人们遗忘这些建议,从而导致同样的问题再次发生。

Lineage 2: Revolution(from pocket gamer.biz)

Lineage 2: Revolution(from pocket gamer.biz)

2. 尽早开始准备项目,从小做起

公司财务状况最大的影响因素之一是开发团队规模的管理(成员数量的峰值和谷值),特别是在新旧项目过渡时。通常情况,当前项目结束后,下一个项目似乎才刚刚起步,这导致了许多成员无所事事,因为项目设计者才刚刚开始构建游戏的基础和总体愿景。

更好的做法是提前规划,如果可能的话,在当前项目进行过程中规划下一款游戏,挑选出一个骨干团队(成员数量大概是最终团队数量的10%)进行这件事。

我个人建议该骨干团队的成员组成如下:一名负责规划愿景、研究和设计游戏的全职总设计师;一名负责制定时间表、预算、项目范围、联系客户的制作人;以及一名为游戏最初概念提供可视化参考的概念设计师。当然,他们需要定期联络未来将加入团队的核心员工——例如主程序员和美术主管。

此外,最好通过PPT演讲等形式,向这些未来成员及时介绍新项目的进展。如果成员们一直被蒙在鼓里,他们会对新项目产生憎恶和疏离感。如果人们突然得知自己将被派去做一个进行到中期的项目,他们可能会感觉自己更像一个临时的资源,而不是一名有价值的团队成员。

在团队成员聚在一起为游戏建模之前,应该先做好大量的基础工作。注意——这并不会阻碍概念阶段或之后的迭代、灵活性或创造性。这么做主要是为了让团队有个方向,使他们明白应该把重点放在哪里,从而避免人们在黑暗中摸索寻找创意,浪费了宝贵的研究和思考的时间。在这个阶段应避免使用大量游戏开发文件,以免加重他们的负担。

3. 让关键人物尽早加入团队

让首席设计师和制作人尽早开始新项目的一个问题在于,他们很有可能还在进行手头项目的中后期制作。对此我的建议是让一些首席设计师和制作人投入研发,剩下一些作为帮衬——意味着总有一名首席设计师和制作人没有完全投入研发(处于待命的状态),即便你们的工作室只有一个项目。这样做会产生额外的开销,但这是划算的,因为它带来的回报远远大于风险。

如果为了节省经费而导致人手不足,特别是在前面领头的人,后果将会很严重。如果你无法在一开始确定某人的能力,后期换掉他们将产生更大的费用,因为他们的工作很可能要被推倒重做。

确保你对这些关键人物有充分的信心。如果你发现团队存在明显的技能短板,必要时通过招聘或员工培训补充缺失的岗位。

4. 与客户建立良好关系

无论是公司内部的利益相关者还是外部客户,例如发行商和IP授权方,这些制作团队的领导者应进行面对面交流确保双方理解项目的工作简报(brief),在方向上达成一致,并建立良好的工作关系。

虽然这似乎显而易见,但许多时候人们没能尽早着手去做这件事,甚至忽略了它。我们为游戏开发过程设立了许多里程碑——Alpha、Beta,并且清楚理解它们的定义,然而这件事没有被纳入到任何早期的里程碑中。我们仿佛假定它将会发生。

许多问题产生的根源都可以追溯到合作公司之间糟糕的关系、最初的误解以及模糊的方向。

我强烈建议人们进行这些早期的面对面交谈。据我所知,有一家工作室由于差旅预算方面的限制,无法允许制作人员飞去见授权方,但双方面谈有助于减轻这些预算高达数百万美元的项目的工作负担,它带来的好处足以抵消这几千美元的成本。

相比于仅仅通过邮件和电话会议和对方打交道,如果你能和他们面对面交流——哪怕只有一次——这将对合作产生巨大的影响,因为你能更好地了解对方,他们的习惯和行为逻辑。

应该让100%参与项目的关键人员(尤其是制作人)与利益相关者见面,而不仅仅是工作室的高层。这将促进双方建立直接联系,从而实现更高效的沟通。

5. 明确分工

对于任何团队来说,各个成员们了解自己的责任以及如何融入团队是很重要的。不要把这想得理所当然,如果团队成员的角色是模糊的,人们不清楚公司对他们的期望是什么,也不知道团队结构是怎样运作的。许多事情会因此被忽略,某些岗位的责任会被稀释,甚至引发人们对岗位的争夺。因此必须明确谁负责方向指导,谁负责审查,等等。

在项目交替、不可避免地出现岗位变动时,最好与团队成员共同商议。如果出现了岗位空缺,开放这些岗位,让所有人都可以来应聘。

我强烈推荐采用全方位评估,让人们评价他们的同事和上下级。这是一种全面了解团队成员能力和团队管理的方式,并且有利于自我改进。

明确团队结构并不会降低主动性和灵活性。就像在足球队里,球员们需要清楚自己的角色和随之而来的期望。他们是负责得分的前锋,还是负责创造机会的中场?

当然,岗位说明无法涵盖所有工作责任,人们常常会突破岗位职责的限制——中场球员照样可以得分——但让人们自由选择承担职责会引发很多不必要的问题。

对于团队以外的利益相关者——管理高层、发行商、授权方等,这一点尤为重要。参与审批的人太多是一件危险的事,这会导致签字确认/处理矛盾反馈的责任人不明确。因此,应该一开始就确定分工,反馈流程以及周转时间。

6. 制定并坚持实施一个长期计划

项目刚启动时存在许多未知数,但制定一个长期计划是必要的。在项目初期,长期计划包含了许多关键日期——例如项目正式启动日期,什么时候进入前期开发,什么时候开始制作,Alpha版制作,Beta版制作,什么时候提交项目。

在这个阶段,必须制定预算、时间表和游戏项目的工作简报。游戏概念确立后,我们可以进一步估算其它事物。如果日期发生变动——计划也随之而变。

注意,长期计划不只是为了取悦利益相关者而匆匆制定出来的一个概况,直到项目严重滞后时才被重新审视。保持敏捷开发的同时遵循并实时更新长期计划,这对于保持功能相关性来说尤为重要,因为如果我们仅以不同阶段审视产品功能,可能会遗漏关键方面。

7. 明确里程碑的含义

与所有利益相关者正式确定各个里程碑含义——特别是早期里程碑,例如文件归档、结束前期开发、建模、垂直切片。在游戏设计完成前进行这些可能有些奇怪。但如果你们清楚了解产品的工作简报、预算、所需时间和整体游戏概念,你们完全可以进行更高层次的定义。

举个例子,如果游戏从设计到完成的时间为18个月,那么你们可能有5个月进行前期开发。但5个月后交付到客户手上的具体是什么呢?是100页的设计文档?是证明游戏玩法很有趣的灰盒测试结果,加上一个展示艺术风格的demo?还是一个可试玩的demo,作为游戏(画面和音效)最终打磨完成后的效果参考?

这里我要特别指出一个误区:许多团队会花上数月制作一个精致的demo,占用制作时间,导致进度严重滞后。客户那边往往会给大量修改意见,导致团队深陷修改demo的泥潭。

因此,最好在前期制作开始前,与客户就各个阶段交付成果的质量、时间、预算达成一致,从而树立合理的期望并提供远见。

8. 鼓励合作和替代方案

一般来说,最好不要一股脑地投入到第一个想法中,全然不考虑其它替代方案。它或许是个好主意,但可能存在更好的想法,并且在不权衡其它可能性的情况下,一个想法的缺点可能会被暂时掩盖,直到最终凸显出来——到时游戏早已进入制作阶段,改变基本原则为时已晚。

设计之初,允许任何团队成员和利益相关者贡献自己的想法,但具体的责任和决定权仍然在首席设计师手中,首席设计师应该对这些想法进行筛选。

这个过程将大大提高团队的认可度和参与度。从人际关系策略的角度来看,让利益相关者加入其中是明智的——特别是客户(无论是发行商还是授权方)——因为如果他们参与到这个过程中,他们将更可能同意某个方案。

有时客户可能选择不参与这一层面的工作,但我建议向他们提供一些有限的方案选择,而不是单个关于游戏方向的想法。这是为了避免客户一开始就不太喜欢游戏方向,因而变得冷漠。如果他们在日后制作过程中要求对游戏做重大更改,这可能会导致很多问题。因此,你要确保他们参与其中,兴奋不已并且全身心投入。

9. 尊重并遵守期限

想象你在参加一场1个小时的考试,一共有6道题,每道题的分数占总成绩的六分之一。你不可能把前30分钟全花在解答第一道题上。然而,在游戏开发过程中,有时我们花了很长时间进行前期制作,不停地延后期限。有时我们觉得自己后期可以赶上进度,或者由于交付日期离我们还很远,我们丝毫不考虑滞后带来的财务影响。

这一点对那些和电影同期发行的游戏来说尤为重要。如果为了打磨某个关卡不断延后前期制作,则团队很可能要赶工完成剩下的关卡,导致游戏质量大打折扣。

延长时间不一定能提高质量。我们都听说过一些耗费了大量时间的游戏项目——主要是由于制作延误导致的——最终却一败涂地,因为别的游戏从创意和技术方面超越了它们。游戏开发一再出现延误,伴随人员流动率上升,这会导致团队士气大减和游戏质量严重滑坡。

因此,虽然我们不可能每次都在规定期限内完成任务,我们必须尽最大努力。除了提前做好计划外,另一种方式是确保团队成员清楚了解期限。过去,我曾经将把截止日期张贴在墙上,并在团队的wiki上发布里程碑信息,因此每个人都清楚什么时候该制作Alpha版,等等。这让成员们更好地认识到时间的宝贵。

10. 保持果断

我发现优柔寡断是另一个影响开发进度的因素,甚至是在前期制作开始时。虽然前期制作主要从研究、思考创意和替代方案开始,但时间还是照常流逝,游戏开发必须取得进展。这意味着我们必须及时做出关键决策。有时让人们聚在一起做一个相对简单的决策就像赶一群猫一样难以控制。决策可能被搁置、移交然后被遗忘。

然而,在没有充分理由的前提下推迟决策,可能比做一个坏的决策更糟糕。这不是鼓励人们草率地决策,而是在审视了所有替代方案并权衡利弊后,及时决定并继续前进。

不断改变决策同样是一种优柔寡断的表现,这会损耗员工士气并浪费时间。保持灵活性很重要,但若决策结果一再变动,则适得其反。更好的方法是把一些重大的、高层次的事情定下来,作为日后决策的基石。这样随着游戏开发进行,我们可以对那些尚未成型的事物进行调整同时不改变基本原则,除非我们有令人信服的理由这么做并且审视了它对进度造成的影响。

总结

上面的内容也许看起来很理想化,对某些项目来说确实如此。然而,基于我的个人经验,我相信如果我们在项目启动时,有意识地追求更好的开发理念,这将帮助我们及时完成游戏制作、把成本控制在预算内,并产出高质量的游戏。我见证并参与制作了一些项目——甚至考虑了工作室控制范围之外的情况——通过这些项目发现,我们本可以通过一些早期的简单决策大大减少日后的痛苦。

因此无论人们采取何种方式制作项目,我都会鼓励他们在保持灵活性的同时采取一定的稳定性措施,在迭代的基础上做好长期规划。游戏制作人可以采取适当的策略提高稳定性并做好长期规划——但若得不到利益相关者的支持——尤其是开发人员、发行商和授权方——再努力也是白费。上述理念必须一开始就得到相关人员的认可。

换句话说,若他人毫不在意,试图自己建立防洪系统是没有意义的。

本文由游戏邦编译,转载请注明来源,或咨询微信zhengjintiao

Last year, in Brisbane, Australia, where I used to live, there were the worst floods for over 30 years. And yet over the last few centuries there have been several such floods that have hit the city.

After each flood, there has been a commission to look at ways to mitigate flooding in the future. And yet most of the recommendations are ignored and building continued on the flood plains. This seems to be true with a lot of events around the world — whether it’s floods, fires, or riots. A commission is set up, recommendations are made, and then we shelve it and forget about it until it happens again.

The same thing happens in video game production, too. We often spend time writing up postmortems — but are these lessons heeded? It’s depressing to see the same old issues, such as feature creep, aggressive crunching, low morale, lack of focus and direction, communication issues within the team or/and between developer and publisher, and poor technology and pipelines crop up again and again.

We, as an industry, often fail to act on what we learn.

Over the last decade, we have heard a lot about agile production methodologies and the need to embrace change, which makes sense. However, even when agile is used, similar sorts of problems arise, and in some cases are exacerbated.

The goal of this article is to discuss ways of minimizing these issues at the start of new projects, primarily by creating solid foundations and planning ahead. In other words, even with unpredictable weather, building a dam and avoiding building on flood plains is far cheaper, and better, than waiting for the next flood to hit.

1. Implement Previous Recommendations

Not all teams write up a postmortem at the end of a project, either due to apathy or because they see no point. However, if we are going to even begin to learn from our mistakes, then all projects, especially the ones which were canned, need to have a postmortem.

It also needs to be a fair process which is diplomatic but at the same time doesn’t pull its punches in terms of what went right, what went wrong and what can be improved next time.

Once a postmortem has been written up and agreed by those involved, it needs to be available to all members of the studio — preferably through the company’s intranet, so it can be referenced at any time with ease rather than lost in email or hidden away in archived folders.

When starting a new project, ensure that all relevant recommendations from the postmortem are implemented and checked at regular intervals by the company to avoid these recommendations being forgotten and the same issues constantly recurring.

2. Start Early and Start Small

One of the biggest impacts on finances is managing the peaks and troughs of development team sizes, especially between projects. All too often it appears the next project only really gets going when the current project has ended. Unfortunately, this creates the problem of having too many staff twiddling their thumbs whilst those designing the project are only just beginning to lay down the foundations of the game and its overall vision.

Instead, it would be much better to develop the next game, if possible, well in advance during the current project, with a skeleton crew of staff numbering around 10 percent or so of the eventual team size.

Personally, I would include in that group the following: a full time lead designer to work on the basic vision, research, and game design; a producer to map out the deadlines, the budget, the potential scope, and work closely with the clients on the brief; and a concept artist to visualize initial ideas. Naturally, they would need to regularly liaise with key staff who are due to join the team later — e.g. the lead programmer and lead artist.

It is also advisable to keep everyone who is earmarked to move onto a new project informed of its progress via presentations, etc. Otherwise, if people are kept in the dark, they may feel resentment or detachment towards the new project. If people are simply slapped onto a project mid-development, they may feel more like a jobbing resource than a valued member of the team.

The idea is that when a number of production staff comes across to work on prototyping, a lot of the foundational work is already in place. Note — this does not prevent iteration, flexibility or the continuation of creativity at or beyond the concept stage. It is primarily there to initiate what the game and the prototyping should focus on rather than having too many development staff stumbling in the dark looking for ideas without having the luxury of time to research and to simply think. There shouldn’t be a massive amount of game development documentation awaiting them at this stage.

3. Put Your Key People in From the Start

The problem with having a lead designer and producer starting early on a new project is that there is a high chance they are also working on another project in mid- or postproduction. To get around this, I would advocate staggering lead designers and producers on projects — meaning that there would always be an available lead Designer and producer not in full production, even if it’s a one project studio. The additional expense would be cost effective, because the rewards are so much greater than the risks.

If we skimp on a resource, particularly one that is needed up front, then the impact can be severe. If you are unsure of someone’s ability in a key role at the start, then it will be far more costly to change them later during mid-production, as it is likely their work will be redone.

Make sure you have utmost confidence in those key personnel. If there are any obvious skill shortages, then start the recruitment push with plenty of time to fill the position for when it’s needed, or implement a training program.

4. Establish a Relationship with Your Clients

Whether it’s stakeholders within a company and/or external clients such as publishers and licensors, it’s vital that those leading a production team meet face-to-face and understand the brief, gain agreement on direction, and establish a working relationship.

This may seem obvious, but many times this doesn’t happen early enough, or even at all. We have serious milestones such as Alpha, Beta, and Master with their definitions, and yet there isn’t the equivalent early default milestone which includes this. It’s kind of assumed it will happen.

How many times are issues caused which can be traced back to poor relationships between companies, initial misunderstandings, and fuzzy starts to production?

I strongly advocate these early face-to-face meetings. I know of a studio who wouldn’t allow any of its production staff to fly to meet the licensor because of budgetary travel restrictions. And yet the cost of a few thousand dollars would easily be outweighed by the benefits of saved development work on projects with budgets that run into the millions.

Working with someone you have already met face-to-face — even just once — makes a big difference compared to only dealing with them via email and conference calls, as you have a better understanding of them, their mannerisms, and what makes them tick.

It’s important that it’s the key production staff (particularly the producer) who are working on the project 100 percent meet the stakeholders, and not just those higher up in the development studio. This is so a direct relationship can be formed, and communication is not filtered through a long, inefficient chain of command.

5. Clarify Everyone’s Role

On any team, it is important that the members know their responsibilities and how they fit into the team. Don’t take this for granted, because if a role is vague, then people won’t know what is expected of them, and how the team structure works. Things will get missed, and other roles may be unnecessarily diluted, or even fought over between two people. Identify who’s responsible for the game direction, who’s responsible for line reviews, etc.

During the period of inevitable change that happens when moving from one project to another, it’s best to consult with team members and set up opportunities, as much as can reasonably be expected. If there are any vacancies, have these positions open, so anyone can apply and make their case.

I would also highly recommend implementing 360 degree reviews, where people are able to appraise their peers, those they report to, and those who report to them. This is an excellent way of getting a more rounded picture of the abilities of team members and management, which leads to self-improvement.

Having clarity and structure doesn’t dull initiative and flexibility. Like a football (that is to say, soccer) team, people need to know their role and the expectations that go along with it. Are they a striker and expected to score goals, or a mid-fielder and expected to set up goals?

Of course, a job specification doesn’t capture all the tasks people do, and people will naturally help out above and beyond it — mid-fielders can also score goals — but a free-for-all can cause many unnecessary problems.

This is particularly important for stakeholders outside of the team — senior development management, publishers, licensors, etc. There is a danger of having too many people involved in the approval process, which creates uncertainty about who is responsible for sign off and/or dealing with conflicting feedback. Instead, agree to the roles, the feedback process, and turnaround times at the very start.

6. Create and Maintain a Long-Term Plan

At the beginning of a project there are many unknowns, but right from the start there needs to be a long-term plan. Initially, this will be very high-level with key dates — such as the official start of the project, when pre-dev is due to start, when production begins, Alpha, Beta, and Submission.

At this point, the budget, the milestone dates and the brief for the game need to be established. When the concept of the game has been established, then more things can be estimated. And if dates change — so can the plan.

It is important that a long-term schedule isn’t just an overview knocked up to please the stakeholders and then isn’t looked at again until well into production when it has become woefully out of date. It is possible to be agile and to keep an updated long-term plan running alongside. This is particularly important for dependencies, because if features are only looked at milestone by milestone, then key aspects will be missed.

7. Agree on Milestone Definitions

With your stakeholders, formally agree on key milestone definitions — particularly the early ones such as documentation, end of pre-dev, prototyping, and vertical slice. Now, it might seem a bit odd doing all of this before the design has been finished. But if you know your brief, your budget, your timescale, and overall game idea, then it’s possible to do a high-level definition.

For example, if the game is 18 months from start to master, then you may have five months for pre-development. But what can the client expect after five months? Will it be a 100 page Game Design Document? Will it be proof that the gameplay is fun in a grey box prototype, combined with another demo which shows the art style? Will it provide a playable demo that is a vertical slice of the game to a level of final polish in all areas, including art and audio?

The danger I’m trying to highlight in particular is when a team burns many months creating a polished vertical slice, eating into main production time, and causes severe delays. The client may give extensive feedback, and the team then gets caught in a “demo hell”.

It is better, instead, to agree with the client what is desirable at the start of pre-production in terms of quality, time, and budget for each section, and for all the production. This sets up reasonable expectations and provides foresight.

8. Encourage Collaboration and Alternative Ideas

Generally, it’s best to avoid spending a lot of time and effort developing the first idea that pops into someone’s head without looking at the alternative possibilities. It might be a great idea, but there may be better ideas, and without weighing up the alternative possibilities, the weaknesses of one idea may be brushed under the carpet until they become all too apparent — far into production, when it’s too late to change the fundamentals.

At the start, allow any team members and stakeholders to contribute ideas. This is not design by committee, as the design still squarely falls under the responsibility and authority of the lead designer, who should filter these ideas.

This process allows a great deal of buy-in and collaboration from the team. Politically, it is astute to involve the stakeholders — particularly the client, whether publisher or licensor — because they are more likely to approve a direction if they were involved in this process.

Sometimes a client might choose not be involved at this level — however I would recommend that they are presented with a few limited options rather than just one idea for a game direction. This is to avoid a client later going cold on a game direction that they weren’t too keen with in the first place. If they demand significant changes later in production, this is likely to cause a lot of problems. Instead, make sure they are involved, excited, and fully onboard.

9. Appreciate and Keep To Deadlines

Imagine sitting a one hour exam where there are six questions which are each worth one sixth of your final grade. It is unlikely you’ll spend the first 30 minutes just trying answer the first question. However, in game development, we sometimes spend too long on our preproduction and keep pushing deadlines back to accommodate the slippage. Sometimes we hope we can catch up time later, or we don’t even think about the financial impact of missing the ship date, because it’s so far away.

This is particularly important for games which are tied into movie releases. If an internal pre-dev deadline continually gets pushed back because the focus is on getting one level polished and complete, then it is likely the rest of the subsequent level design for all the other levels and the polish for the rest of the game will be rushed and suffer.

Adding more time doesn’t automatically equate to better quality. We all know of games which have taken an extraordinary amount of time — primarily due to delays in production — only to flop because, creatively and technically, they have been surpassed by other games. Being stuck in production doldrums with constant delays and a likely high turnover of staff is a good way to have morale plummet and quality to nosedive.

So whilst it’s not always possible to meet deadlines, we do need to be better at hitting them. Along with better planning, one way is to make sure the team is fully aware of the deadline dates. In the past, I have stuck up the dates on the wall and the milestone deliverables on the team wiki, so no one could say they didn’t know when Alpha was, etc. It gives everyone a better appreciation of how valuable time is.

10. Be Decisive

Another issue which I find impacts schedules, even at the start of preproduction, is indecision. Whilst pre-dev starts with research, ideas, alternatives etc — the clock is still ticking away at a constant rate and there needs to be progress on the development of the game. This means key decisions need to be made in a timely fashion. Sometimes trying to get people together to make a relatively straightforward decision can be like herding cats. Decisions can be sat on, deferred, delegated, and forgotten.

However deferring a decision for no apparent good reason can be a worse mistake than making a bad decision. This is not encouraging rash decision-making, but rather after investigating the alternatives and weighing up the pros and cons, having the confidence to make a timely decision and move forward.

Constantly changing decisions is also a type of indecision, which wears down the production team’s morale and wastes time. It’s important to be flexible, but when decisions are continually reversed, it is counterproductive. Instead, it’s better to make the big, high-level decisions, and use these as foundation stones. This is so that as the game progresses, things which have yet to be developed can be changed without altering the fundamentals, unless there is compelling reason to do so, and the impact on the schedules have been looked into.

Conclusion

All the above may seem idealistic, and for certain projects these ideas may well be. However, based on my experience, I believe if we make a conscious effort to strive for better ideals at the start of a project, then this will help us get the game done on time, on budget, and to a high quality. I have seen and have been involved with projects — even taking into account circumstances outside the studio’s control — where simple decisions taken upstream could have really minimized a lot of pain later.

So whatever methodology a project chooses to use, I would urge that as well as having flexibility, there needs to be a degree of stability. As well as relying on iteration, there needs to be plenty of long-term planning. A producer can put things in place to aid stability and can organize long-term planning. But without the support of the key stakeholders — especially executives of the developer, the publisher, and the licensor — it can quickly fall apart. These ideas really need to be embraced by all those involved at the beginning.

In other words, there is no point trying to build a flood defense by yourself if no one gives a damn.(source:gamasutra.com

 


上一篇:

下一篇: