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

制作人总结10大游戏开发经验

作者:David Manuel

去年澳大利亚布里斯本遭遇了30多年来最大的一次洪水灾害。但过去几百年来,这座城市曾遇到过多次类似规模的洪水。

每次洪灾后,政府都会成立委员会探究未来如何降低洪水灾害的破坏性。但多数建议都遭到忽视,大家继续在洪泛区建筑高楼。这种情况似乎也出现在全球众多事件中——无论是洪水、火灾,还是暴乱。成立委员会,提出建议,然后将此搁置一旁,完全忘记这回事,直到类似情况再次出现。

这种情况也出现在电子游戏的制作中。我们通常会花时间撰写事后报告——但这些经验是否有引起大家的注意?最令人沮丧的莫过于看到类似问题反复出现,例如功能累赘、内容粗糙、较低士气、缺乏焦点和方向、团队内部的沟通问题及开发者和发行商间的沟通问题,以及反复出现的糟糕技术问题。

我们,作为一个行业,常常无法基于自己的所学行事。

过去10多年来,我们听到许多有关快速制作的方式及接受变化的重要性,这有其道理。但即便我们采取快速制作方式,类似问题依然还会出现,在某些情况下,还可能进一步恶化。

本文旨在探讨如何在新项目开始时尽量避免这些问题,主要是通过建立稳固基础及提前进行规划。换而言之,就算天气变幻莫测,创建大坝及避免在洪泛区上建造楼房远比坐等下次洪水来袭好得多。

1. 执行之前的建议

不是所有团队都会在项目结束后撰写事后分析,或没有兴趣,或觉得没有意义。但若我们想要从失误中学习,那么我们就得对项目进行事后分析。

这应该是个合理的过程,既要富有策略性,又要在陈述正误及有待提高的方面不遗余力。

撰写出事后调查报告,且受到相关人员的认可后,应该将此呈现给所有工作室成员(游戏邦注:建议通过公司的内部网络),这样我们就能够轻松进行查阅,不会让文件淹没在邮件或存档文件夹中。

着手新项目时,确保执行所有来自事后分析的建议,公司应定期进行查看,以避免建议遭到忽视,反复出现相同错误。

crisis snake from gamasutra.com

crisis snake from gamasutra.com

2. 尽早动手,从小项目着手

影响财政情况的一大因素是开发团队的规模控制,特别是在各项目之间。最常出现的情况是,只有当前项目收尾,下个项目才能启动。遗憾的是,这会带来这样的问题:在设计人员刚刚确立游戏基本要素及总体构思时,有太多人员无事可做。

相反,若能够在制作当前项目期间提前着手下个项目情况就会好很多,挪用约10%左右的骨干成员。

就我个人来说,我会安排下列成员:全职首席设计师负责确立游戏基本构思,进行研究工作及游戏设计;安排时间进度、预算及预期范围的制作人,同时负责和客户传递项目概况;将所有构思具体化的概念美工。通常,他们需要定期和随后将加入团队的核心员工保持联络——例如主程序员和首席美术师。

我们建议工作室通过演示文稿之类的方式告知所有相关工作人员项目工作进度。否则若这些人员被蒙在鼓里,他们会对新项目产生抵触情绪。若工作人员中途被安排进项目中,他们会觉得自己更像是做零工的资源,而不是重要的团队成员。

这里的观念是,当制作人员着手原型设计时,很多基本工作已落实到位。注意——这不会妨碍构思阶段的创意过程迭代、灵活性或持续性。这主要是促进我们把握游戏和模型的着眼点,而不是要让大量开发人员毫无头绪地探索游戏的构思,进而未能腾出足够时间进行调查研究及思考。这一阶段不应向他们呈现大量游戏设计文稿。

3. 在项目一开始就安排核心人员

在新项目初始安排首席设计师和制作人的问题在于,他们多半也同时参与其他制作中或处于后制作阶段的项目。为避免这种问题,我建议在项目中穿插安排首席设计师和制作人——这样项目就能够总是配有首席设计师和制作人,这些人员无需全程参与整个制作过程,即便这是个单一项目的工作室。这样额外开支将颇具成本效益,因为回报要比风险大得多。

若我们吝于利用资源(游戏邦注:尤其是预先需要的资源),那么后果将非常严重。你需要在一开始就判断成员在关键职位的表现如何,因为在后期制作中对他们加以改造的成本非常高,他们的工作很可能需要重做。

确保自己对关键人员持有充足信心。若工作室出现明显的技能匮乏现象,应发动招募活动,腾出充足时间填补职缺,或落实培训项目。

4. 和客户建立联系

无论是公司利益相关者还是发行商或授权者之类的外部客户,同这些团队主要人员碰面了解项目概况,就发展方向达成一致,建立起工作关系非常重要。

这也许有点显而易见,但很多时候这些并未能尽早实现,或者是完全没有落实到位。我们通常会设定严格的时间表,例如定义清楚的Alpha、Beta和Master阶段,但没有在初期阶段确立对应的默认时间表,而是假定这些会自然形成。

有多少次问题的出现都是归根于公司间糟糕的合作关系、起初的误解及模糊不清的制作开端?

我强烈建议主管们初期进行面谈。据我所知,有家工作室不允许自己的制作人员飞去同授权者碰面,这主要由于差旅费预算有限。几千美元的成本很快就会被缩减的项目开发工作(游戏邦注:这些预算动辄上百万美元)盖过。

相比只是通过邮件和电话会议进行沟通,和碰过面的伙伴合作意义截然不同,因为你会对他们、他们的特殊习惯及行事动机有更深入的了解。

确保项目核心制作人员同利益相关者碰面非常重要,而不只是开发工作室的高层人员。工作室应该建立起直接的合作关系,不要基于繁琐的低效指挥系统进行沟通。

5. 阐明各个成员的角色

在团队中,成员清楚把握自己的职责及懂得如何配合团队非常重要。不要认为这是理所当然的事情,因为如果角色定义模糊,成员就无法知晓团队对他们的预期及团队结构的运作模式。我们会遗漏某些工作,其他角色也会遭到不必要的忽视,甚至会出现两人争吵的局面。清楚确定谁负责游戏方向,谁负责游戏评论。

在项目切换的必要变更期里,我们最好咨询团队成员,把握可能出现的机会。若存在职缺,开放这些职位,这样所有人都可以进行申请。

我建议落实全方位的评论,其中用户能够评论自己的伙伴、上司或下属。这是整体把握团队成员和管理人员能力的最佳方式,能够促使大家获得自我提升。

提高透明度及设定清楚结果并不会降低团队的主动性和灵活性。和足球团队一样,大家需要清楚自己的角色及相关预期。自己是需要得分的前锋,还是需要设定目标的中前卫?

当然,工作要求无法囊括大家实际操作的所有工作,大家所做的工作通常都不止如此——中前卫也会帮团队得分,但面向所有群体会带来许多不必要的问题。

这对团队之外的利益关系者(游戏邦注:高级开发管理人员、发行商和授权者等)来说尤其重要。我们可能会在审批过程中牵涉过多人员,这会令我们无法确定谁负责审批,谁负责冲突反馈信息。相反,我们应在初期就角色、反馈过程及周转时间达成一致。

6. 建立及维持长远计划

虽然项目初始存在众多未知因素,但我们需要从一开始就设定长远计划。起初,这通常是包含关键日期的高级计划——例如项目官方开始日期,预先开发日期、制作开始日期及Alpha、Beta和Submission阶段。

这时候,我们需要确定预算、时间表和游戏概要。确定游戏概念后,我们还需要评估更多内容。若日期发生变化,计划也能够进行相应调整。

值得注意的是,长期计划并非用于取悦利益相关者,只有待到制作阶段才会再次查看(此时已经完全过期)的综述。我们完全能够保持灵活性,创建持续更新的长远计划。这对于依赖关系来说非常重要,因为如果我们只基于时间表查看游戏功能,那么关键要素就会受到忽视。

7. 就时间表的定义达成一致

同你的利益关系者就关键时间表的定义达成一致——尤其是文稿、预先开发终止时间、建模及垂直截面等初期内容。如今在设计完成前完成所有这些工作似乎有点奇怪。但若你清楚自己的项目概要、预算、时间标度和整体游戏构思,我们就能够就行高层次的定义。

例如,若游戏从始至终需要18个月的时间,那么你就有5个月的预开发时间。但5个月后客户能够获得什么?是100页的游戏设计文稿?能否通过结合另一呈现艺术风格的灰盒模型证明玩法富有趣味?能否呈现出各方面颇为精致(游戏邦注:包括艺术元素和声音)的游戏垂直截面演示样本?

这里的风险是,团队可能耗费众多时间制作垂直截面,占用主要制作时间,导致项目出现严重延误。客户也许会给予广泛反馈信息,然后团队陷入“演示困境”。

我们最好在前制作阶段就各截面的质量、时间和预算同客户达成一致。这设定合理预期,给我们带来前瞻性。

8. 鼓励进行合作及提出选择性构思

通常,我们最好避免直接投入大量时间和精力开发首先映入我们脑中的构思,而不考虑其他选择方案。这也许是个不错构思,但也许还存在许多更好的选择方案,某个构思的弱点也许被遮掩起来,直到最终才显现出来——直到后制作阶段,此时要改变基本要素就为时过晚。

要在一开始就让团队成员和利益关系者出谋划策。这不是由评委拍板的设计,因为设计职责通常属于首席设计师,他们会过滤这些构思。

这个过程让团队成员能够出谋划策,进行合作。从决策角度看,将利益关系者纳入其中是明智举措,尤其是客户,无论是发行商还是授权者,因为若他们参与至过程中,他们更容易认同某个发展方向。

有时客户会选择不参与这方面的工作——但我建议向他们呈现若干有限选择,而不是单个关于游戏方向的构思。这能够避免客户随后对他们起初不太感兴趣的游戏方向心生厌恶。若他们要求在制作后期做出巨大改变,这就可能带来很多问题。所以我们应该确保他们参与其中,保持活跃性,完全赞同方案。

9. 尊重时间期限

想象自己置身于持续1小时的考试中,需要解答6个问题,每个问题分别占总分的1/6。你多半不会利用头30分钟揣摩第一个问题。但在游戏开发中,我们经常会在预制作阶段投入过多时间,然后推迟截止期限,以应对项目出现的延误情况。有时我们会希望自己能够在后期赶上进度,或者我们不会考虑错过发行日期的财务影响,因为这些过于遥远。

这对同电影发行日期绑定的游戏作品来说非常重要。若内部预开发阶段的截止日期持续因着眼于完善某关卡而受到延误,那么其余关卡的设计工作及游戏完善任务就会被粗糙带过,进而遭受影响。

腾出更多时间并不同等同于获得更高的质量。我们都知道有些作品耗时很久(游戏邦注:多半是由于制作过程受到延误),但最终却因创意和技术方面不尽人意而以失败告终。陷入制作停滞期,持续出现延误,进而导致人员出现较大变动很容易就会削弱团队的士气,导致作品质量急剧下滑。

因此虽然无法总是顺利如期完成工作,但我们需要尽量在此表现得更好。包括进行更好的计划,我们需要确保团队成员充分意识到项目的截止日期。过去,我通常会把截止日期贴在墙上,将完成成果呈现在团队维客上,这样就没有人会说自己不知道Alpha是什么时候。这让大家更好地意识到时间的重要性。

10. 保持果断

我发现影响日程安排(影响邦注:即便是在前制作初期)的另一重要因素是优柔寡断。虽然前制作阶段主要围绕调查研究、构思和选择方案等内容,但时间依然持续流逝,游戏开发需要有所进展。这意味着我们需要及时做出关键决定。有时要让大家共同做出相对直截了当的决定就像遛一群猫。决定可能遭到压制、推迟、委托及遗忘。

但无故拖延决策要比做出糟糕决策影响更糟。这并非鼓励我们匆忙做出决策,而是要查看选择方案,权衡其中利弊,确保自己及时做出决策,然后继续向前迈进。

持续变更决策也是优柔寡断的表现,这会磨损制作团队的士气,同时还会浪费时间。保持灵活性非常重要,但若决策持续出现反复,将会带来反效果。相反,我们最后要能够做出更高层次的决策,以此充当基石。这样当项目出现进展时,相应制作内容就能够在不变更基本要素的前提下出现相应调整,同时我们还能够观察这给工作安排带来的影响。

总结

上述内容显得有些理想化,这在有些项目中可能如此。但根据我个人的经验,若我们积极在项目开始就着眼于更好的理念,那么我们将能够如期在预算范围内基于高质量标准完成游戏作品,甚至将工作室控制范围之外的情况也考虑在内,逆向做出简单决策能够在后期省下众多麻烦。

无论项目采取什么方法,我建议团队要保持一定的灵活性和稳定性。连同依靠迭代制作,我们还需要进行众多的长远规划。制作人可能通过将工作落实到位实现项目的稳定性,同时还可能设定长远规划。但没有关键利益关系者的支持,尤其是高层开发人员、发行商和授权者,这很快就会土崩瓦解。这些构思需要被那些一开始就参与项目的人员所接受。

换而言之,若没有人建造大坝,自己建设洪水防御设施完全无济于事。(本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

A Producer’s 10 Lessons Learned the Hard Way

by David Manuel

[Experienced Sony Computer Entertainment Europe producer David Manuel shares the secrets he's learned from years of seeing developers fail to learn from the mistakes they've made on projects in the past, and offers suggestions on the key learnings to integrate into your production process.]

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


上一篇:

下一篇: