作者：Soren Johnson

对于《龙腾世纪传奇》这款游戏，我们的主要目标是创造一款“面向所有玩家的社交游戏。”这一社交RPG将传统游戏的有趣决策与难度的权衡以及社交游戏世界中的创造性结合在一起。实际上，游戏主要分为两部分——类似于日本RPG（如《最终幻想》）的回合制战术战斗系统，以及受到《FrontierVille》等Facebook游戏启发的约定式城堡建造游戏。

怎样做才是正确的

1.核心设计循环

我们设计了 特定的核心游戏循环去匹配Facebook模式，即玩家在一整天时间里多次进入游戏中进行短暂的游戏体验。角色的核心状态（生命值和魔法值）并不能像在其 它RPG游戏中那样再生。（生命值只能在战争以外的情况下以及实时状态中获得再生——每小时补充1颗心）。因此，如果玩家想要在战斗间恢复他们的 生命值和魔法值，他们就需要依赖于消费道具——生命值和魔法值药剂，治疗包，以及魔法药膏。

Dragon Age Legends(from media-freaks)

这些消费品是推动玩家在战斗中前进的能量。《龙腾世纪传奇》与传统RPG不同之处就在于，玩家在这里既可以控制消费品的供给，也能够根据约定好的时间在城堡中进行创造（举个例子来说吧，城堡中的药剂师便能够在30分钟内创造2个生命值药剂）。如果玩家一开始便用尽了某一道具，他便可以花费额外的时间在城堡里重新创造这一供给。

游戏的两部分内容（即城堡和战斗）创造了一种自给自足的经济循环。玩家可以将自己从战斗或任务中获得的金币用于扩展城堡并升级房间。相应地，城堡能够创造药剂，药膏和炸弹帮助玩家抵御难度不断提升的怪物。

因此，战斗和城堡是相辅相成的，推动着玩家继续战斗并建造城堡。这一循环也让玩家团队更加明确游戏的核心理念，从将基于回合制的RPG的有意义的决策与持久且吸引人的城堡建造有效结合在一起。该系统非常适合Facebook，即玩家可以随时进入游戏中参与战斗或只是创造一些药剂。

2.有意义的社交吸引

我们也希望游戏中带有一些有意义的社交吸引元素——从而让游戏有理由出现在Facebook上，而不只是停留于网页中（游戏邦注：就像这款游戏的前任《龙腾世纪旅程》那样）。简单地说，朋友的加入总是能让一款游戏变得更有趣。

此外，我们并不清楚有多少Facebook游戏执行过社交功能，即推动着玩家去支付“友谊税”，如邀请10个好友能够帮助自己完成建造。这些功能能帮助社交游戏呈现病毒式扩展，但是却带有人为性，甚至会被说是对于玩家社交关系圈的滥用。

相反地，朋友应该成为核心游戏玩法的一部分，如此玩家便会自然而然地邀请好友加入。一款派对类RPG便意味着玩家每次需要在浏览器上玩几分钟游戏，而我们能够使用一种新格式去处理这一问题，即异步MMO。尽管玩家创造了一个角色，他们也可以请求好友的角色在战斗中提供异步帮助。

这一功能的细节将创造出一些有趣的社交动态内容。慕名前来的英雄将获得金币作为奖励，而英雄的拥有者将在下次进入游戏时获得。玩家将召集更高级别且拥有更好装备的英雄，所以这些英雄的拥有者便有足够的理由去提高自己角色的能力，从而赚取更多好友的金币。

该系统引起了玩家有关好友应该如何发展自己的英雄，以及一个好友是否正在互惠地使用其他好友的角色的有趣讨论。换句话说，玩家间的社交互动变得更有意义了。作为一种附带利益，因为在《传说》中玩家需要经由好友的角色而不断接触到整个技能树，所以这款游戏才有效地区别于其它RPG。

3.真正的封闭测试

在过去几年里，“测试”这一词已经失去了某些意义，即几乎所有网页游戏都是处于永久性测试状态。举个例子来说吧，《FarmVille》便在2011年4月才删除了测试标签，即在游戏最初发行22个月后，其日活跃用户也从2010年3月的顶峰值8300万掉落到今天的4300万。

许多Facebook游戏都是面向公众进行迭代开发，即始于带有许多任务功能的最小初始版本。这一方法也具有许多好处，即开发团队可以立刻获得哪些方法有效以及哪些无效的反馈信息——这是对于传统游戏开发的一大改善。但是持续的公共开发过程还有一些弊端，如早期的设计决策可能会一直保持不变，从而让当前的社区感到沮丧。

当我们从2011年1月（游戏的发行是在3月中旬）开始面向公众进行封闭测试时，我们采取了一种不同的方法。就像传统MMO那样，我们鼓励玩家去注册在线测试，然后定期发送一些关键信息去提升玩家基础，并吸引了超过5万名玩家的参与。

在这过程中，我们每两周会清空数据库，一方面是为了减少引擎开销，一方面则能帮助我们基于漏斗形玩家情况而专注于早期游戏。因为我们的玩家理解他们的角色和城堡并不是永久的，所以我们能够进行实验并快速做出改变，而这也是公开测试不能做到的。

就像在封闭测试期间，我们添加了严格的库存限制，删除了总是会造成致命一击的道具，拉低了阶层曲线，重新创造了前五张地图，并多次改写技能系统。尽管这些改变并不普及，但是因为所谓的缺少持久性，各种消极影响也因此而减少了。

实际上，在封闭测试期间我们甚至开始对付费货币（Crowns）收钱，主要是为了确保系统的有效运行。让人惊讶的是，玩家便开始花费大量金钱，甚至是知道他们的角色很快就会被消除掉的前提下。在每次数据库清空后，我们总是会快速创造一个系统去返回玩家消费的所有Crowns，从而让他们更加相信自己的购买决定。这是值得我们付出努力的改变，就像我们之前为了盈利策略而获得的无价信息一样。

怎样做是错误的

1.客户端/服务器同步

我们将项目开发的前几个月投入于快速创建战斗系统的原型中，因为我们是重新使用EA2D之前基于Flash的RPG游戏《龙腾世纪旅程》的代码，图像和动画，所以速度便快多了。而这种应急开发引出了一些重要的创造性，如基于图标且具有易用性的生命值/魔法值系统，以及用于消费的额外战斗步骤。

但是《旅程》是较为简单的游戏，即完全运行于玩家浏览器中，不像《传奇》，要求一个主从架构。在创建原型时，我们为了开发速度而忽视了这一不同，从而需要我们为长远的发展付出一定代价。因为担心玩家作弊，我们不能只是让客户端去处理战斗，并且因为延迟问题，我们也不能让服务器去处理它。因此，战斗计算需要与服务器和客户端并行，即意味着我们必须确保两组算法是相同的。

当是时候打开服务器进行实时测试时，客户端将保持与服务器的不同步，因为我们找不到真正的方法去保证算式的一致性。有段时间，我们考虑了一些技术性解决方法，即让我们能够基于一种语言（能够运行于不同平台上）去编写代码，包含Google Web Toolkit，haXe以及在服务器上运行JavaScript。

最后，我们使用的是简单但却让人不快的解决方法，即使用手动蛮力确保能够基于Java和ActionScript同样编写每个战斗功能。这一过程花费了我们的首席游戏玩法程序员数个月的时间，而在这期间我们不得不暂停设计和测试工作，因为战斗系统将不再发挥功效。这一“丑陋的”解决方法在我们的日程表上留下了一大漏洞，就像缺少设计或测试所造成的结果那样。

2.脆弱的任务系统

在网页上开发游戏的一大优势便是它们可以不断更新—-必要的话，甚至可以一天多次。漏洞总是能够得到快速修复，没有人会站在开发者和玩家间监视着，从而减慢了内容的传输速度。但即使是快节奏也有它的弊端，其中一大弊端便是在每次更新后保持游戏状态中无数角色数据永久不变。

不幸的是，我们的任务系统通常都会稍稍下降，更重要的是许多玩家在游戏更新后会进入休息状态。但是问题就在于系统不能做到优雅地衰退。如果玩家处在一个更新期间出现改变，重新命名，甚至是被删除的特定事件中，他便可能没办法完成自己现在的任务。

这一问题与地图和任务设计的严格的线性关系是相混合的。地图通常都是一个线性系列节点，即与线性组合任务（游戏邦注：玩家只能基于特定顺序通过）相匹配。如果这些节点或任务基于某种方式得到修改，那么处于中间状态的玩家便会很容易便跌下任务链条，而没有复原的可能。他们可能会忽视其它任务直接穿越剩下的游戏内容。

随着这些问题的出现，我们的工程师便开始完善数据库，寻找基于休息任务状态的角色，然后手动修复数据。最后，我们创造了一种工具去辅助这一劳动密集型过程，并在代码中创造了一些保护措施能够自动解救被困住的角色（如果可能的话）。尽管如此，我们却浪费了项目主要阶段的大量工程时间。在此我们获得的主要教训便是在改变不可避免地出现时，最好能够想办法设计出足够灵活且能优雅地衰退的游戏内容和系统。

3.害怕社交

我们的目标便是为玩家创造社交游戏，许多玩家对于典型的Facebook游戏所使用的各种战术都带着保守的态度，如向好友发送请求和告示而将其带到游戏中等等。我们尽最大的努力创造了一款吸引人的RPG，并只添加尊重玩家的社会资本的社交功能。

因此，尽管我们创造了自认为有趣，且符合网页同步模式的硬核MMO，但是我们的游戏仍然缺少大多数社交游戏中的病毒式循环。尽管《传奇》吸引了许多渴望新功能和更多内容的忠实用户，但是我们的病毒性元素却仍很少；我们的玩家既不会邀请好友进入游戏，也不会说服离开的资深玩家重返游戏。

我们团队中的大多数人，包括所有设计师，之前都未曾创造过社交游戏，这便意味着我们并不熟悉社交吸引力和Facebook所提供的病毒性功能。我们在发行时未能呈现标准功能列表便意味着我们不清楚社交游戏受欢迎的主要元素：

*使用Facebook的告示/任务渠道

*奖励点击了其他玩家推广墙内容的玩家

*提供合作任务或让玩家有理由邀请好友的帮忙

*让玩家之间相互赠送礼物（甚至是真正的战利品，就像在大多数MMO中那样）

*给予回到游戏中的玩家每日奖励

此外，我们也缺少许多社交游戏开发者常使用的许多工具，如A/B测试，以及为游戏定制的指标指示器等。相反地，我们只能依赖于自己的直觉和来自社区的反馈，这便意味着我们不能证实为什么一些基本数值（如DAU，MAU，K元素等等）会上升或下降。最终，我们便很难创造出一款能够利用平台优势的游戏。

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

Dragon Age Legends Post-Mortem

by Soren Johnson

Our primary goal with Dragon Age Legends was to create a “social game for gamers.” This social RPG combined the interesting decisions and difficult trade-offs found in traditional games with the innovations of the social game world. In fact, the game is split into two halves – a turn-based tactical combat system similar to Japanese RPGs like Final Fantasy and a persistent, appointment-based castle-building game inspired by asynchronous Facebook games like FrontierVille.

What Went Right

1. Core Design Loop

We designed our core game loop specifically to match the Facebook format, with players jumping into the game for short play sessions throughout the day. The character’s core stats (health and mana) do not regenerate naturally as they do in most RPGs. (Health does replenish but only outside of combat and only in real-time – one heart per hour.) Thus, if players want to restore their health and mana between battles, they need to rely heavily on their consumable items – health and mana potions, injury kits, and mana salves.

These consumables are the fuel that powers players though combat. What makes Legends unique compared with traditional RPGs is that the player is actually in control of the supply of consumables as the player can create them in the castle with timed appointments. (For example, the castle’s apothecary can create two health potions in 30 minutes.) If a player begins running low on a certain item, she can always invest extra time at the castle to rebuild her supply.

The two halves of the game – the castle and the combat – create a self-sustaining economic loop. Gold earned from fighting battles and completing quests can be invested in expanding the castle and upgrading its rooms. Accordingly, the castle creates the potions, salves, and bombs that the player needs to defeat the increasingly difficult monsters encountered over the course of the game.

Hence, the combat and the castle provide context for each other, motivating the player to keep fighting and to keep building. This loop gave the team a clear central vision for the game, to pair the meaningful decisions of a turn-based RPG with the compelling persistence of a castle-building game. The system proved a good fit for Facebook, in which players might dip in at any time to fight a couple battles or just to craft a few more potions.

2. Meaningful Social Hook

We also wanted our game to have a meaningful social hook – a reason to be on Facebook instead of just being on the Web, like the game’s predecessor, Dragon Age Journeys. Simply put, friends should make the game more fun.

Further, we were not impressed with how many Facebook games implemented social features, often forcing players to pay a “friend tax” by, for example, asking 10 friends to help finish a building. These features help social games spread virally, but they often feel artificial and even abusive of the player’s social network.

Instead, friends should be a part of the core gameplay, so that players will naturally want to invite their friends to join. As a party-based RPG meant to be played a few minutes at a time in a browser, we had an opportunity to address this problem with a new format – the asynchronous MMO. Although players develop a single character, they recruit their friends’ characters asynchronously to help complete the party in combat.

The details of this feature led to some interesting social dynamics. A recruited hero receives a gold bonus that the hero’s owner can pick up the next time he logs on. As players tend to recruit higher-level and better-equipped heroes, their owners have a strong incentive to keep improving their characters, so that they will earn more friend gold.

Recruited heroes enter a rest state after each use, from a few hours to most of a day, depending on how much damage they withstand in combat. Thus, deciding which friend to use and for.which battle is a strategic choice as one’s most powerful friends can only be used a few times each day. In other words, friends become an important, but limited, resource.

This system led to much interesting discussion between our players about how friends should develop their heroes and even whether one friend was using another friend’s character reciprocally enough. In other words, the social interactions between players had become meaningful. As a nice side benefit, Legends differentiated itself from other RPGs because players were regularly exposed to the entire skill tree via their friends’ characters.

3. An Actual Closed Beta

The term “Beta” has lost some meaning over the years as almost every Web-based game exists in a state of perpetual Beta. FarmVille, for example, didn’t remove the Beta tag until April of 2011, 22 months after the initial release and well after falling from its peak of 83 million monthly active users in March 2010 to today’s 43 million.

Many Facebook games are developed iteratively in public, starting from a minimal initial version with many missing features. This approach has many benefits as teams get immediate feedback about what is working and what isn’t – a big improvement from the multi-year silos of traditional game development. However, there are disadvantages to a continuous public development process; early design decisions can become permanent as backing away from them might upset the current community.

We took a different approach as we started our public development with a Closed Beta from January 2011 to our release in mid-March. Just like a traditional MMO, we encouraged players to sign-up for the Beta online and then periodically sent out keys to grow our player base, letting in over 50,000 players.

During this period, we conducted a database wipe every two weeks, both for the sake of lowering our engineering overhead as well as helping to focus attention on the early game by funneling players through it repeatedly. Because our players understood that their characters and castles were not permanent, we were able to experiment and make rapid changes in ways not possible during an Open Beta.

For example, during the Closed Beta, we added a strict inventory cap, removed Always Critical Hit items, slowed the leveling curve, rebuilt the first five maps, and reworked the skills system multiple times. Although these changes were not always popular, any negative impact was lessened by the known lack of persistence.

In fact, we even began charging real money for our premium currency (Crowns) during the Closed Beta, mostly to make sure the system worked. Surprisingly, players began spending large sums of money, even with the knowledge that their characters would soon be erased. We quickly developed a system to return all spent Crowns to players after each database wipe to give spenders more confidence in their purchases. This simple change was worth the effort as the information we gained was invaluable to our monetization strategy.

What Went Wrong

1. Client/Server Synchronization

We devoted the first few months of the project to rapidly prototyping the combat system. which went quickly because we reused code, art, and animation from EA2D’s previous Flash-based RPG, Dragon Age Journeys. This period of quick-and-dirty development led to important innovations, such as the accessible, icon-based health/mana system and the extra combat step for consumable use.

However, Journeys is a more straightforward game that runs entirely in the player’s browser, unlike Legends, which requires a client-server architecture. When building the prototype, we ignored this difference for the sake of development speed, which cost us in the long run. Because of concerns over player cheating, we couldn’t just allow the client to handle the combat, and because of lag issues, we couldn’t let the server handle it. Thus, the combat calculations needed to run in parallel on both the server and the client, which meant we had to ensure that the two sets of algorithms were identical.

When the time came to turn on the servers for real testing, the client kept falling out of sync with the server because we had no real solution for guaranteeing the calculations would be in lockstep. For a time, we considered some technical solutions that would allow us to write the code in one language which could be run (or recompiled to run) in both places, possibilities which included the Google Web Toolkit, the haXe language, and running Javascript on the server.

In the end, we adopted the simple, but painful, solution of using manual brute force to ensure that every combat function was written identically in both Java and ActionScript. This process cost months of time for our lead gameplay programmer, during which time design and testing was essentially paused because the combat system no longer worked. This ugly solution blew a gaping hole in our schedule as little design or testing could be done.

2. Brittle Quest System

One big advantage of developing games on the Web is that they can be constantly updated – multiple times a day, if necessary. Bugs get fixed faster, and no gatekeeper stands between the developer and the player, slowing down the delivery of content. This rapid pace, however, does have its downsides, one of which is the challenge of keeping the persistent data of hundreds of thousands of characters in a playable state after every update.

Unfortunately, our quest system commonly dropped a small, but significant, number of players into a broken state after game updates. The problem was that the system did not fail gracefully. If a player was in the middle of a certain event that got changed, renamed, or even removed during an update, she may suddenly have no way to finish her current quest.

This problem was compounded by the strict linearity of the map and quest design. Maps were often a linear series of nodes that were paired with a linear set of quests that a player could only progress through in a certain, set order. If these nodes or quests were modified in any way, then players in an intermediate state could easily fall off the quest chain, with no hope of recovery. They might play through the rest of the game without ever seeing another quest!

As these issues began appearing, our engineers scoured the database, looking for characters with broken quest states, and then manually repaired the data. Eventually, we developed a tool to assist with this labor-intensive process as well as safeguards within the code to automatically fix stuck characters, if possible. Nonetheless, we lost significant engineering time during a key part of the project. The lesson learned is to design game content and systems that are flexible enough to fail gracefully when change inevitably occurs.

3. A Fear of Social

Our goal was to make a social game for gamers, many of whom express grave reservations about the tactics used by typical Facebook games to spread virally, by spamming friends with requests and notifications to pull them into the game. We put our greatest effort into making an engaging RPG and only developed social features that treated our players’ social capital with respect.

Thus, although we developed what we believed to be a fun, core MMO that fit the asynchronous format of the Web, our game was light on the viral loops found in most social games. Although Legends attracted a committed audience eager for new features and more content, our viral factor was very low; our players were neither inviting their friends into the game nor convincing lapsed veterans to return.

The majority of our team, including all of our designers, had never made a social game before, which meant that we were simply not familiar enough with the social hooks and viral features Facebook provided us. The list of standard features that we did not have at launch speaks to our naivety about what makes social games work and spread:

No use of Facebook’s notification/request channel

No rewards for clicking on another player’s wall posts

No collaborative tasks or reasons to ask friends for help

No gifting between players (even of actual loot items, as is common in MMOs)

No daily bonus for returning to the game

Further, we lacked many of the tools common to social game developers, such as A/B testing and a metrics viewer customized for our game. Instead, we had to rely on our own intuition and feedback drifting in from our community, which meant that we were never quite sure why our basic numbers (DAUs, MAUs, ARPU, K-factor, etc.) were either going up or going down. Ultimately, we were not developing a game that played to the strengths of its platform.(source:gamasutra)