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

适时放弃一个项目的事后分析

发布时间:2016-11-10 15:54:08 Tags:,,,,

作者:Javier Ansoleaga

在经过较长时间的沉默后,我们觉得是时候去解释9个月前我们有关《The Swarm》的最后一次公开谈话后发生了什么,并为此写下这篇“事后分析”。

首先,在经过6个月的开发后我们决定放弃我们的上个项目《The Swarm》。因为我们意识到自己已经没有完成这款游戏所需要的资源了。但是在这几个月我们也并没有闲下来。我们一直致力于一个全新项目并且我们也对此充满信心,所以我们迫不及待想和你们分享所有的这一切了。

而以下内容便是我们在这个过程中所经历的一切。

logo_cancelado(from gamsutra)

logo_cancelado(from gamsutra)

设计不稳定性和范围蔓延

我们大约是在一年前开始开发《The Swarm》。在经过3个月的前期制作后,我们想到了一些有趣的想法,于是我们便快马加鞭开始开发。我们最初的计划是1年开发时间。是的,我们知道我们所计划的时间永远都不够长。但毕竟我们是一支尝试着在产业中寻找立足点的小型独立开发团队。所以我们的大多数时间都是在不断尝试与犯错中学习。

早前的原型

在设计方面第一个出现问题的标志是在审批最初原型之后。因为一开始我们基于一些主要机制经历了一个互动过程。我们认为这是一种正常过程,因为我们都知道电子游戏是通过开发而不断发展的。我们将通过不断改变机制和游戏元素而获得更好的效果。而大多数改变都是因为我们认为这是对的执行方式。所以为了获得我们想要的结果我们需要了解游戏的整体状况。

这一过程经历了3,4个月时间,直至我们开始意识到已经离最初游戏概念越来越远了。虽然不是很明显,但是这一期间我们所进行的许多改变让我们很难再去识别最初出现的许多问题。但事实上这并不是因为游戏的改变,因为它的改变是为了变得更好。从整体看来这其实是一款更加连贯的游戏。但是我们却并未意识到真正的问题是伴随着全新系统,功能以及范围的修改而出现的。

总的来说我们的确拥有一款更出色的游戏。这是值得我们骄傲的。这是一款具有创造性且基于强大工作核心的项目。但是它却是需要比我们现在的团队大出2倍的规模且多出2倍的开发时间才能完成的内容。而那时候我们的团队根本负担不起这一切。

这真的让我们非常头疼,但当我们意识到这一点的时候却已经到最后阶段了。

团队分裂

我认为我们并不需要详细讲述从无到有去发展一家独立工作室有多艰难,因为网络上已经充斥着许多这样的文章了。但为了能帮到你们我们想提及我们在这个过程中所遇到的一两个难点。

对于独立开发者来说,一开始所面对的最大困难之一便是在维持整个开发过程的同时维持团队的完整性。(游戏邦注:如果没有专门的HR负责人在寻找全新人才并进行面试,这便会大大浪费开发时间。)

除此之外,对于年轻团队来说缺少财政支持是再正常不过的事了,他们通常都是依靠自己的存款或兼职工作所赚到的钱去支持游戏开发。所以我们有时候只是在依靠热情和动力去留住团队成员。但说实话热情是远远不够的。

我们便因为经济问题或个人原因失去了4名成员中的2名。我们的开发也因此变得更加艰巨。所以那时候我们立即召开了“紧急会议”去决定下一步该怎么做。

幸运的是我们都非常喜爱这家小小的工作室并决定继续去实现我们的目标。于是我们便决定将所有精力放在创建一支全新团队并重新开始。

结论和一些建议

在经历了“重新开始”的过程后,我们并未对放弃《The Swarm》的决定感到后悔。我们认为这是一个正确的选择。而我们也从这一过程中学到了一些宝贵的经验教训,这对我们来说才是真正无价的奖励。

我认为当你意识到某件项目不可能获得成功时,那么比起投入更多时间和精力于一个僵尸项目中,你最好选择放弃。

虽然我们犯了许多错,但是《The Swarm》的开发过程也为我们的全新项目提供了非常有价值的经验教训,并且从长远角度来看这为我们省去了更多麻烦与时间。

以下是能够带给你们帮助的一些建议:

明确你的核心设计原则,在原型中多次尝试测试它们,如果可行的话从一开始便坚持不变。

不要害怕改变设计元素,我们仍然认为改变是贯穿于整个过程。你只需要确保你所作出的每个改变都是基于项目范围内。如果你所作出的改变不能更好完善你的核心设计原则,那么这样的改变便是无意义的。

团队中的人员流动是很正常的,所以你最好确保为此做好提前的计划,尽可能将人员流失对开发的负面影响降至最低。

根据个人经验及浅见,如果你正在创建一支团队并缺少财政支持,那么你最重要的资源便是长期的承诺。所以你最好在寻找团队成员的时候将该承诺突出表现出来。想象你可能会招到一个拥有经验和出色技能的程序员,但如果他最终选择了离开,那么他所拥有的技能和你花费在寻找全新程序员的时间与精力相比就变得没那么重要了。

希望这些建议能够带给那些正要起步的开发者有益的帮助。

本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转发,如需转载请联系:游戏邦

Learning from Failure: Post Mortem of an Unborn

by Javier Ansoleaga

After a long period of silence we have decided it’s time for us to explain what happened since our last public communication regarding The Swarm, 9 months ago, and write a quick “Post Mortem”.

So first of all, TLDR: We’ve decided to cancel our last project, The Swarm, after roughly 6 months in development. Because we realized we didn’t have the resources the game was needing to be completed the way we wanted. Nonetheless we haven’t been idle all these months. We have been working on a new project we are very confident with, and we can’t wait to tell you all about it as soon as possible!

For those who are interested, we would like to tell you what happened along the way.

Design instability and Scope Creep

We started the development of The Swarm about a year ago. After roughly 3 months of pre-production we felt like we had something interesting, so we went full throttle and started development. We did our maths and initially planned for 1 year of development. Yeah, I know, you never plan long enough… Of course, after all, we are a little indie team trying to find our place in this industry. And as so, learning most of the time through trial and error along the way.

Early Prototype Mockup

The first signs of trouble came in the Design side, shortly after approving the initial prototype. Since the beginning we went through an iterative process with some of the main mechanics. We were feeling it was a normal process, because we all know video games evolve through development… It felt natural, we were changing mechanics and aspects of the game for the better. Most of the changes were implemented because we were convinced of them. Knowing the overall picture of the game was needing it in order to be what we wanted it to be.

It went this way for 3-4 months, until we started realizing we were far away from the initial concept for the game. A lot of little, not so evident, changes during an extended period of time made it difficult to spot the problem earlier. Which was not the fact the game changed, because it changed for the better. It was a richer and more coherent game overall. The actual problem was that along with cool new systems and features also the scope was modified, without us realizing. It basically grew out of bounds.

Summarizing, we had a better game overall. One we were really proud of. It was deep, innovative and, finally, with a strong working core. Just it was for a team double our size and doubled development time. None of which the team at that time was able to afford.

This was already causing us some headaches, but the final stroke came just when we realized about this.

Team fragmentation

I think there is no need to go in detail on how difficult or tough is to raise an indie studio from nothing, the internet is filled with plenty of good articles on the topic. But we did hit a bump or two along the road worth mentioning in case our failures help someone.

One of the main difficulties indie devs have while starting out is (from my experience and what some fellow devs have told me here, in Spain) to keep a compromised team during the whole development process. (without a dedicated HR person finding new talent and running interviews it’s quite time consuming and slows down the development).

On top of that it’s not strange for young, new teams to lack financial support, running on personal savings or having a part time job to pay the bills. So we sometimes depend on just pure passion and motivation to keep the team engaged. And sadly, it’s not always enough.

This was part of what happened to us. At some point we lost 2 out of 4 members, sadly due to economical or personal troubles. Which in fact set us back and made an already complicated development seem like an impossible task. Immediately we had a “crisis meeting” to decide what would be our next step.

Luckily we were both still crazy in love with our little studio and determined to accomplish our objective. We wanted to keep on going no matter what. So we decided to put all our efforts on building a new team and starting over. It was going to be new team, new office (or basement, depending on the point of view) and new project anyways.

The Swarm Gameplay Mockup

Conclusion & some tips

After some time of work in the “restart” process we ended up regretting nothing about our decision of canceling The Swarm. We think it was a good one, and today we can proudly say it all went fine for us and we are back in track with new team and new project, it was a throwback at least in timing, that’s true. But we kept all the lessons we learned along the way and that was a priceless reward, we learned a lot!
Looking in retrospective, I think it was a good move because I’m of the opinion that it’s always better to cancel a project when you realize it’s not gonna work, than keep pouring hours and effort into a zombie project, a project you know ahead it’s not going to work as well as you want.

At the end every single mistake we did while developing The Swarm has been a valuable gain developing our new project, saving us lots of headaches and time in the long run.

To summarize some tips in case it helps someone:

Be sure to define your core design principles, test them in a prototype a thousand times and, if they work, stick to them to have a good foundation ground to start from.

Don’t be afraid on changing aspects of the design, we still think it has to evolve along the way. Just be sure every change you do keeps the project between scope. And if the change you’re doing doesn’t help to better define or improve one of your core design principles in some way maybe it’s not worth it.

People comes and goes, try to have a backup plan in case you lose some team members, so you can minimize the negative impact in the development.

From my experience and in my humble opinion, if you’re building a team with a lack of financial support your most important resource is long-term commitment. So be sure you prioritize it above other qualities when looking for candidates. Think about it, you may hire an awesome coder with experience and awesome skills, but in the long run if he goes away that extra skills are worth little compared to the time and effort you’re gonna spend in finding a new candidate.

I hope our failures can help anyone starting out as much as it helped ourselves.
Stay tuned as we’re almost ready to let you know the first details of our new project. And we’re so excited to do so. And so happy with the fact it’s working as we expected and we’re still so confident in it, even more than when we started it 6 months ago

The Evolve Games team.(source:gamasutra)

 


上一篇:

下一篇: