作者：Charles Egenbacher

《Voodudes》是一款免费下载的第三人称动作RPG，玩家在其中要扮演Virgil这个巫毒娃娃的角色，必须从恶魔Baron Samedi手中解救出巫毒世界。玩家在这款游戏内的商店中可以配备6项独特的技能，还可以通过在游戏中收拾道具以替换造型及饰品。

这款游戏由15名全职硕士生在柏林艺术大学开发而成，整个项目周期为5个月，每名成员投入时间为20个工作时。作为这个项目的制作人，我将在此阐述我们在这个过程中的得失以及收获的经验。

正确做法：

积极的态度

Zombears像一个大家庭一样聚集到一起。每个人都有良好的性格，极具幽默感，并且都有志于制作一款好游戏。因此，大家的积极性并不成问题，我们也不需要因为一些个人矛盾而让项目搁浅。我们拥有让项目向前发展的充分理由。

因此我们能够在充裕的时间中专心制作一款出色的游戏。虽然游戏已经发布，我们现在仍保持着朋友关系。

项目早期

在预制作阶段，我找到一些教授，请教他们哪些问题是学生团队的最大障碍。他们比较一致的回答是，多数团队很难顺利熬过Alpha阶段。在这个时间段，团队会发现他们无法植入自己所预期的所有功能，因此可能会让大量心血付之东流并导致返功。

在Vertical Slice之前两周，主关卡设计师、游戏设计师和我碰面讨论我们在之前阶段所收到的反馈。我们教授的普遍看法是，这款游戏会变得很累赘，我们应该缩减计划中的关卡数量。

我们权衡了一下这项消减关卡工作的利弊，认为我们应该可以创造8个关卡，但也清楚自己根本无法为所有关卡润色。有些关卡可能比较出众，有些则比较平庸。我们与团队见面并讨论了这些选项后，最终决定削减相应的内容。

我们开始发现仅保留4个关卡确实有助于提升游戏质量，并快速意识到如果我们不听从教授的反馈，可能就会一直遇到许多问题。

Voodudes(from gamasutra)

参加独立游戏节

我们决定向截止日期为10月31日的独立游戏节（IGF）提交这一作品，在这个期限的前一周，我们疯狂赶工，这种加速度促使我们推动项目不断向前，也让我们得以提前进入Alpha阶段。

向IGF提交游戏是一个巨大转变，这完全不同于平常提交作业的感觉，并且极大提升了整个团队的士气。

错误举措：

忽视了模块性

模块性和层次具有其短处。这让所有东西看起来都趋于一致。层次让我们急于赶工而忽略了质量。

我们在开发过程中很早就完成了数个粗略的建筑立面。我们有7个可使用的完整立面。这一情况的美妙之处在于，我们很早就能证实自己易于定位的模块立面系统具有可行性。

不幸的是，我们因为这些资产而创造了庞大的可玩空间，这让美术人员和设计师需投入大量心血向其中填充内容。所幸，在Vertical Slice砍削内容减轻了因此而产生了大量范围问题。我们从中得到的教训就是，不要过早因自己的模块资产而得意忘形。

Voodudes(from gamaustra)

寻找漏洞

由于游戏极为庞大，找到漏洞出处就成了一桩棘手事情。

游戏越是庞大和复杂化，漏洞也会更大更复杂。我们开发了6项可供玩家转变的特殊技能，这些技能为玩家提供了广泛的玩法选择。

音频问题

我们很晚才开始添加音频，但我们很幸运。

虽然我们明白音效在游戏开发过程中的重要性，但音效却并非我们所学课程的重点。我们将其置于项目后期进行考虑。因此，我们并没有游戏清晰明确的游戏音频方向，并且许多早期测试都是在毫无声音和音乐的情况下进行。

我们非常幸运，将这一事项外包给位于达拉斯的音效设计公司。他们提供的声音和音乐效果非常出色，但我们得先在游戏玩法中植入音效的占位符。这便于你在开发游戏过程中迭代和调整音频风格。

所获经验：

尊重他人想法

只要让大家觉得他们有机会发言并参与讨论，他们就会更乐于拍板最终的决定。即使大家最后的结论并不是那么理想，如果你之前很乐于倾听他们的意见，他们也会尊重你的决定。

保持信息透明

团队主导成员之间交流以及理念的透明化有助于让大家提前知道一些潜在的障碍。无论这是团队成员之间的问题，还是理念上的混淆，透明化的交流可让你尽早鉴别并快速解决问题。

聆听他人反馈

认真倾听他人对游戏的反馈，这一点很重要。测试者总会找到你自己永远无法看到的一面，因为你对自己的游戏太熟悉了，所以看不到问题所在。因此要注意倾听玩家看法，你并不需要事事依从玩家的意见，但需要查看反馈结果，并判断如何在维持整体项目愿景的前提下将他人建议植入游戏中。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Postmortem: Zombears’ Voodudes

by Charles Egenbacher

The following blog was, unless otherwise noted, independently written by a member of Gamasutra’s game development community. The thoughts and opinions expressed here are not necessarily those of Gamasutra or its parent company.

Want to write your own blog post on Gamasutra? It’s easy! Click here to get started. Your post could be featured on Gamasutra’s home page, right alongside our award-winning articles and news stories.

Voodudes is a free to download third-person action RPG in which the player takes on the role of Virgil, a voodoo doll who must save the world of voodoo from the evil Baron Samedi.  Voodudes features six unique abilities that can be equipped at an in-game shop.  Players may also equip alternate costumes and accessories by collecting various items throughout the game.

Voodudes was developed in UDK by fifteen full-time Master’s students at the Guildhall at SMU.  The total project length lasted five months, with twenty work hours per team member.  As the Producer on this project, I will outline what went right, what went wrong, and the things we learned.

What Went Well

Positive Attitude

The Zombears fit together like one big family.  Everyone was good-natured, had a great sense humor, and was super dedicated to making an awesome game.  Because of this, motivation wasn’t a concern, nor did we have to stop and deal with any major personality conflicts.  This allowed us to always drive the project forward.

We could focus on making a great game while having a great time.  Although the game has shipped, I’m proud to say that we’re all still friends, and there’s something to be said for that.

Super cuts, super early

During pre-production, I approached several professors asking them which capstone milestone gave student teams the most trouble.  The consensus was that most teams struggled at Alpha.  Around this time, teams realized that they would not be able to implement all of their intended features.  This resulted in tremendous amounts of throwaway work and rework.

Two weeks before Vertical Slice, the Lead Level Designer, the Game Designer, and I met to discuss feedback that we received at our previous milestone.  The general consensus from our professors was that the game was going to be much too large and should reduced our planned number of levels.

We weighed the pros and cons of such a large cut.  We were convinced that we could create all eight levels, though we also knew that there was no way we could polish them all.  Some would look good and some would look mediocre.  We met with the team and discussed these options, and we all decided to make the cut.

Understandably, some people were not thrilled about the cut.  That being said, we started to see the increased quality in our four existing levels, and realized very quickly that if we hadn’t listened to feedback, we would have run into many problems down the road.

IGF

We decided to push for the IGF submission deadline on October 31st.  The week before the deadline was a mad dash to the finish, but this push propelled the project forward and placed us well ahead of our Alpha milestone.

We made the deadline and we were better for it.  Submitting to IGF was a great change of pace from the typical workweek, and ended up being a huge morale booster for the entire team.  As for joining the winner’s circle – you’ll have to keep an eye out for us next time.

What Went Wrong

The Betrayal of Modularity

Modularity and Tiers had their drawbacks.  Everything ended up looking the same.  Tiers made us race through development rather than focus on quality.

We completed several robust building facades very early in the development process.  By proof of tech, we had seven completed facades that were available for use.  The awesome part about this was that we proved very early that our easily-placeable modular façade system would work.

Unfortunately, we got carried away with these assets and created massive play spaces that the artists and designers would have to fill.  Fortunately, the cuts at Vertical slice alleviated the bulk of the scope issues resulting from this.  It’s still a valuable lesson in not getting carried away with your modular assets early in development.

Hard-to-Reach Bugs

Finding the source of the bugs became difficult because the game became so big.

As the game got larger and more complex, the bugs also became larger and more complex.  We developed six unique abilities that the player could change out at checkpoints and an in-game shop.  These abilities provided a wide variety of playstyles for players.  However, the interactions of player abilities, enemy abilities, and boss abilities

Audio – Late to the Party

Sound started very late.  We got lucky.

While we know that sound is a crucial element in game development, sound is not a large focus of the Guildhall’s curriculum.  we prioritized it later in the project.  Consequently, we didn’t have a good idea of the audio direction for the game, and many early playtest sessions were void of many sounds and music.

We were very lucky, and were able to contract with a sound design company in Dallas.  The quality of the sound and music ended up being fantastic, but we should have implemented placeholder sounds by proof of gameplay.  This allows you to iterate on your audio style as you develop the game.

What We Learned

People Deserve to be Heard

As long as people feel that they’ve had a chance to speak and participate in a discussion, they will be more likely to buy-in to the decision in the long run.  Even if an undesirable decision is reached, your team will respect you for listening to them before reaching a verdict.

Be Transparent

Transparent communication amongst team leads and disciplines allows many potential roadblocks to float to the surface.  Whether it be issues between teammates or confusion between disciplines, transparent communication allows you to identify issues early and resolve them quickly.

Listen

The willingness to critically listen to feedback on your game is invaluable.  Playtesters always reveal things about your game that you could never have seen yourself.  You just get too close to the game.  Listen to your players.  You don’t always have to run off and make every change that you hear about in your forums, but it’s important to look at the feedback and examine how you can implement it into your game while maintaining the overall vision.（source：gamasutra）