作者：Josh Samuels

在为期3年半的开发进程后，我们向苹果App Store提交了首款作品《Arrival：Village Kasike》。打从一开始，我便兴趣于采用敏捷方法。我已经着手完成大量网站项目，并发现匹配我思考与管理项目的方式。我无法忍受阅读或论述长篇大论，反之，我常常会通过小规模的代码检验来发现可行创意。

虽然我强烈拥护敏捷方法，但在《Arrival：Village Kasike》开发过程中却仍然没少吃苦头。

Arrival Village Kasike(from gamesbrief)

从困难入手

从2009年中期，我们开始尝试开发游戏创意（游戏邦注：其主要内容与欧洲人入侵前的加勒比人有关）。在2009年GDC大会上，我们会见了一群有趣团队，且十分看好第三方支持技术的发展前景，而后滋生出进军游戏领域的想法。

我们决定组建自己的团队，立马投入开发领域。我们挖掘到大量人才，但由于资金不足，人员流动率颇高；于是我们重点找寻需要创建作品集的学生。在团队壮大后，我们则尽力为那些新成员找到任务。

我们都清楚需要什么，因此只创建简短文档，主要是任务列表。而当时的美工团队还未形成概念艺术，我们也无法优先考虑此事项。在历经漫长的不断试验与失败后，终于我们明确了理想的美术风格。随后的游戏设计与编程也遵照这种模式。我们并未试验游戏机制；而是由设计师确定，然后经工程师构造。

在美工团队忙于创建游戏资源时，我们则试图组建一个可以加速游戏引擎开发的小型工程团队。尽管进展缓慢，但我们从来没有提前测试某些创意在此核心游戏机制上的可行性。

我们本可以利用概念艺术统一绘画风格。然而情况正好相反，美工们在得到正确外观与效果之前，需大量修改作品。通过试验证明游戏机制的可行性避免了我们在之后否决整个已成型系统。如果不是这样，我们就会盲目行动，直到某个性能或美术片段接近成型。由于人员流动率颇高，我们不得不耗费大量时间招聘新成员来加速进程，而且还需追踪未对职位请求回复的人员。

成功标准

在开发后期，我们主要遵循一些敏捷原则。我们会在获得核心功能后测试游戏。在首次回合中，我们随意观察好友的游戏过程，结果显示他在玩了几分钟后便感到厌倦。因为游戏内容不够玩法，而且也没有设置玩法指南。因此，我们决定为此增添新玩法与更多教程。我们并不是一味增加新玩法，而是通过小试验不断探索玩法理念。团队中的两名程序员负责试验不同创意（即农场与钓鱼）。我们还创建它们的迭代过程，从中发现可行创意。而这些小游戏也展示出玩法的运作模式以及完成它们所需的精力。

接下来的测试则显示，即使设置了教程，玩家们仍不理解游戏玩法。因此，我们将其分割成几道关卡，并在各个关卡开头处添加完整的教程。我们还利用迭代过程创建出更清晰的教程，然后通过游戏测试检验它们的可行性。在历经几轮迭代后，测试者终于可以完成整个游戏进程。这是个重大进展，然而此时大部分村庄已陷入饥荒状态；为此，我们更改变量，调整整体系统，最后，他们不仅完成游戏，而且无法停止！

在这过程中，我仍清晰记得一个特殊经历。当时的我为了保证测试过程能持续1小时左右，已加班数天，相当疲惫。我有点担心测试者不知道农场小游戏的获胜秘诀，但情况却完全相反，她似乎没有受到任何影响，仍继续沉浸其中。3个小时后，我告知她已抵达最后关卡，之后将会进入无尽模式。她点点头，继续投入其中。又过了20分钟，我提示可以随时停下来，测试已经结束。我花了不少力气才让她停止游戏。她看了看时间，一脸惊讶地说：“我怎么觉得只玩了1个小时啊！”这时我知道我们成功了。我们获得了用户认可，不久以后，我们向苹果商店提交了这款作品。

之后，我们在添加全新小游戏，修改游戏流程与调整平衡上均采用这种迭代进程。

要点

以下有助于《Arrival：Village Kasike》开发的关键方面：

迭代

迭代模式适合各种游戏题材，且发挥着关键作用。它也许是发挥敏捷性的最重要元素，总之，编程与资源创建总是在迭代周期中完成。

确定机制

我们应围绕证明可行的核心机制开发游戏。选择出有趣创意与题材，而后基于此运行。我们需耗费大量时间塑造出匹配游戏创意的机制。

计划

人们总误认为敏捷原则中并未涵盖计划。当然多种方式均可实现计划制定，而这是必要部分。

项目管理

合理管理项目需耗费大量精力。即使采用敏捷方法也无法改变。我们应准备好投入必要时间，忍受杂乱无章！尤其当时间有限，你不得不一心投入开发进程时，要管理好项目颇具难度。从长远来看，匆忙进行将浪费更多时间。

测试

测试主要针对游戏漏洞、品质、平衡、趣味、流程以及其它重要部分。测试通常伴随开发进程进行，而不是在最后阶段。提早修复漏洞能够防止对项目稳定性与品质造成影响。

收获

在严格的有效期限内，与波动率高的团队成员合作实则增加了结构性开发难度。我曾被推向许多开发方向，因此总让我在计划与组织方面措手不及。

我十分高兴自己挖掘到一组精英人才，我们一同度过重重困难，最终完成了《Arrival：Village Kasike》这款作品。我认为我们已从自己的错误中有所认识，下次将做得更好。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Going agile, and stumbling on the way

by Josh Samuels

Let’s go agile! All the cool companies do it!

After 3½ years in development, we submitted our first game, Arrival: Village Kasike, to Apple’s App Store for iPhone, iPad, and iPod Touch. From the start, I was interested in taking an agile approach. I’ve completed many web projects and found it matches the way I think and manage projects. I have little patience with reading or writing long documents but find playing with ideas in small code experiments holds my interest while I work through the details.

Although I am a fan of how productive an agile approach can be, I still struggled with following this pattern for the development of Arrival: Village Kasike.

Doing things the hard way

We started in mid-2009 with some game ideas about the people of the Caribbean prior to
European settlements. We met with some interested parties at the GDC in 2009 and, excited with the prospect of third-party backing, came up with a concept.

We decided to get a jump on development and sought out team members. Next we found many people but had no money, which made retention difficult; we focused on finding students needing to build up a portfolio. As our team grew, we did our best to immediately find tasks for new members.

We had a general sense of what would be needed and created minimal documentation, mostly to-do lists. For the art team we did not have concept art nor did we make this a priority. Through a long process of trial and error, we were eventually able to define the desired art style. We followed the same pattern with game design and programming. We did not experiment with game mechanics; they were defined by a designer and then built by an engineer.

While the art team was busy building assets, we were trying to get a small engineering team up to speed with our game engine. Progress was slow and we never prioritized small playtests to try our ideas for core game mechanics.

We should have used concept art to document a consistent style for the art team. Instead artists needed to submit many revisions of their work until they got the correct look and feel. Proving which game mechanics work through experimentation would have prevented us from building out systems later discarded. With neither, we were flying blind until a feature or art piece was close to completed. With high turnover, we spent a large amount of time getting new team members up to speed and chasing down people who didn’t respond to status requests.

Are we there yet?

We did follow some agile principles late in development. Once we had the core functionality in place, we conducted play tests. Our first session, which was informally watching a friend play, showed that he got bored after a few minutes. He didn’t have much to do or anything guiding him to do it. This test session led us to add new gameplay and more tutorials. Rather than diving in and adding some new gameplay, we started by exploring our gameplay ideas with small experiments. Two programmers each tried a different idea, farming and fishing. We built a few iterations of these ideas and used this process to pick which would make it in the final game. Minimal versions of these mini games demonstrated how the gameplay would work and how much effort would be needed to complete each one.

Our next testing sessions showed that people didn’t understand how to play, regardless of
the tutorials we put in place. We broke up our game into levels and added integrated tutorials during the early levels. We used an iterative process to build clearer tutorials and check these against our playtesters. After a few rounds of iteration, our playtesters were able to play to the end of the game. This was a big step forward, but most villages were starving by the end. We followed the same process to balance Arrival: Village Kasike’s difficulty and flow; we changed our variables and tweaked overall systems until play testers not only finished the game, but didn’t want to stop playing!

There was one particular session which stands out in my memory. I was tired, having been working late on the game, and was hoping the test session would last for about an hour. I was a bit concerned that the tester didn’t understand how to succeed in our farming mini-game but that didn’t seem to bother her, she kept wanting to play. After about 3 hours of playing I pointed out that she had reached the last level of the game and from there on out it was open-ended. She nodded and kept playing. Another 20 minutes passed and I mentioned that she could stop whenever she wanted, the test was done. It took a little more encouragement but I finally got her to stop playing. She looked at the time and was shocked. “But it felt like I was only playing for an hour!” This is when I knew we nailed it. This was confirmed in additional test sessions and soon after we submitted Arrival: Village Kasike to Apple.

In the end, we followed an iterative process to add new mini games, refine our game flow, and tune the balance.

What worked

Here are key areas that would have helped during development of Arrival: Village Kasike:

Iteration

A version of iteration exists for every discipline and is essential. Iteration is probably the biggest factor in making agile work, programming and asset creation is done in short, iterative cycles.

Clearly defined mechanics

Start development with core mechanics you have tested. Then build a game around that. We picked an interesting idea and a game genre and ran with it. It took a very long time for us to mold our mechanics to the game idea and it should have been the other way around.

Planning

It is a misconception that agile does not involve planning. Planning certainly can be approached in a number of ways, but is still required.

Project management

Managing a project properly takes work. Agile does not change that. Be prepared to put in the necessary time or embrace chaos! Management is especially hard when you are tempted to dive into development due to a tight timeline. Rushing the process will waste far more time in the long run than is saved initially.

Testing

Test for defects, quality, balance, fun, game flow, and anything else you consider important. Test regularly throughout the development process, not at the end. Fix defects early rather than allowing them to linger and degrade the project’s stability and quality.

There’s always next time…

Working under a tight deadline with regularly fluctuating team members made using a structured development process very difficult. I was pulled in many directions which added to my reluctance to take the time needed to plan and organize on a regular basis.

I am grateful that we found a group of dedicated and talented people who stuck around through all of our missteps to finish Arrival: Village Kasike. I like to think we learned from our mistakes and will do much better next time.(source:gamesbrief)