作者：Eric Schwarz

距离我开始创造《龙腾世纪：起源》的模组“Thirst”已经过去了一年多的时间。起初我是基于一个非常特别的游戏理念开始创造——在一次短途地牢冒险中，玩家所控制的角色从原来的考古学家转变成一个可怕的恶魔，并不得不吸取别人的灵魂才能获得生存，但这最终却发展成一个更加标准且传统化的电脑角色扮演游戏模式。

“Thirst”并不是我所创造的第一个模组，但是这却是一次非常有帮助的经历，将带我体验到“真正的”游戏开发实践，即推动我学会如何使用C++语言撰写脚本，如何构建一个时间跨度较长的故事结构，如何创造游戏关卡以平衡游戏玩法和现实主义，以及如何在各种变量间处理复杂的互动元素等。

我将在此讨论我所遇到过的一些挑战，以及我是如何克服这些挑战并从中学到何种经验教训。

事先掌握工具的使用方法

“Thirst”之所以花费了我如此长的时间（撇开老旧的系统崩溃导致我不得不重头开始工作不说）是因为我一直在不断摸索着各种工具的使用方法。《龙腾世纪》工具箱是一款非常出色的软件，并基于资源类型而拥有不同编辑器；但是尽管如此，学习如何执行特定的行动，如何更好地编辑游戏文件以创造出非标准结果，如何有效地设置脚本以推翻任何不合理的行为等都需要我投入更长时间才能得以掌握。

toolset(from gamaustra)

（《龙腾世纪》工具箱是一款非常出色的软件，但是我们却必须花费数月时间才能完全掌握其学习曲线和工作流程。）

如此便导致“Thirst”中出现了许多草率的脚本设置。早期，当我在编写任务时，我使用了更多情节变量而不是那些对追踪进度有帮助的内容。举个例子来说吧，玩家所面临的一个任务是必须从一名囚犯那获得相关信息，而反之囚犯也希望因此获得自由。这时候玩家将面临多种选择：贿赂狱卒，撬锁，偷钥匙，杀死门卫等等。而各种独特的选择也需要各种变量，但是除了一些细节的不同，玩家这些行动最终都会促成相同的结果，即玩家能够或者不能释放囚犯。而如果游戏中未设置一个单独的变量去追踪囚犯是否获得自由，之后的脚本内容将会变得更复杂，并且我将不得不费时间核对4至5个变量而不只是1个变量。如果我有足够的远见，也许便能够避开这一问题了。

从玩家的角度进行思考

当我们以创造者角度进行思考时，我们的脑中总是会涌现出许多想法。通常这些想法总是能够推动我们创造出一些特定的场景——如创造出多种结果或任务解决方法，并推动事物的有效互动等（作为玩过多种RPG游戏的我来说这些事真的都不难）。但是当我需要真正去执行这些想法时，我却会发现结果常常不如玩家所愿。

在“Thirst”的一开始，玩家将会遇到一个遭遇抢劫的商队，并在此遇到一个幸存者能够阐述一些背景故事，如此便推动着玩家开始接下来的探索任务。一开始听起来好像很不错，但是当我开始进行游戏测试时，我发现我的一个好友虽然不断地尝试着完成这一模组但是最终却导致了角色的死亡，因为他将自己的角色与另外一个死尸混淆在一起（游戏邦注：尽管这个死尸的位置设置是合理的）。而为了解决这一问题我就需要使用一些特定的技巧，如在死尸周围设置火把，以此照亮该区域并突出死尸，或者当玩家靠近时添加弹出对话框（如“请帮帮我”之类的），但是经历了这次的教训后我却不得不重新思考特定角色的地理位置以及之后的关卡布局等问题。

daorigins(from gamasutra)

（像这样的早期挑战将加强角色开发，以及探索环境和搜索物资等积极行为的价值。）

有些时候这种设置能够带给玩家更多选择。早些时候，我发现建立一系列与玩家维系在一起的游戏玩法非常重要，因为如此玩家便能够很容易知道哪些内容对自己有利而哪些有害。在角色扮演游戏中，特别是当玩家在每个场景拥有多个属性，技能并面对多种结果时，玩家便很容易假设“所有的一切”都是对自己有帮助的——但是事实上，为了保持游戏的有序进行以及故事的顺利发展，设计师总是会在这种可能性中添加种种局限因素。

举个例子来说吧，当玩家遇到受伤的非玩家角色时他将面临5种不同的选择（喂他治疗的植物，给他健康药剂，施以治疗咒语，使用生存技能等。），但是大多数情况下游戏都不可能提供给玩家如此广的选择，不过我还是使用了一些提示帮助玩家做出选择，如“嘿，你可以在对话中使用特定的道具！”或者“你的非战斗技能具有价值！”之后我还面临了一个类似的挑战，即使用各种方式穿越栅栏将能够告知玩家，在游戏中不仅技能很重要，种族和属性也同样重要（游戏邦注：例如拥有较大的力量能够让玩家畅通无阻，而扮演较小的种族，如小矮人或精灵则能让玩家更有效地解决谜题）。

预先透露重要信息

“Thirst”是一个突出强调选择和结果的模组。尽管它不像《阿尔法协议》那样，“任何内容都可以改变”游戏故事，但是其中的一些小细节却也将彼此影响。举个例子来说吧，帮助角色进行早期的支线任务将能够在之后的任务中创造出一个替代选择，让玩家能够绕开其中部分内容。而在另外一个例子中，如果玩家能够打败一个非常强大的敌人，他便能够跳过其中一个主要任务。最明显的可能是，这两种主要的任务线是相互排斥的，并且它们将直接且长期地影响着故事的发展。

然而，关于这种结果的一大问题便是，玩家可能不喜欢这种突如其来的惊喜。我们总是很难定义什么是不受欢迎的内容，例如与其他角色展开战斗的预先行动到底是一种奖励还是惩罚？而明确这一结果又非常重要，因为这将能够确保玩家不会在游戏中觉得自己被欺骗，或者抱怨自己的任何决策都得不到回报。但是这也不是说游戏中不允许坏的结果存在，而是当出现这些不好结果时，游戏必须让玩家能够清楚自己所做的任何行动对于今后挑战将有何影响。

daorigins (from gamaustra)

（游戏可以预先透露一些重要的决策，从而让玩家觉得游戏进程更加自然且富有逻辑。一些较小的游戏可能不会透露这些信息，但是对于玩家预先行动所给予的较小奖励（或惩罚）却也能够加强游戏世界的连贯性。）

而对于两个主要任务线（城镇镜戒系统和黑社会）间的较大选择，我便不能为玩家创造惊讶而已了。相对来说，这是一个重要的决策，游戏玩法和游戏故事的结果将能够影响起整个模组的核心内容。因此我就必须谨慎地传达这一决策，即通过添加对话暗示而帮助一方更好地排除其他对手。当玩家发现他们以前的同盟背叛了自己时，整个游戏世界，故事和游戏玩法将能有序地连接在一起，而不再只是充斥着一些不可预见的结果，而尽管玩家仍然不喜欢这种设置，他们也不再会认为这是一种卑鄙手段了。

当然了，玩家也需要做好迎接那些重大后果的准备。就像之前所提到的游戏玩法间的关系是取决于可行的选择，所以我们必须说明这种关系所围绕的结果。所以我便决定在模组的介绍部分引入一些关系明确且相互依赖的较小结果。例如在早期阶段玩家将在一个小酒馆中遇到一些雇佣兵，而在之后当玩家再次遇到他们时，他们有可能会在玩家执行任务中提供一些有用信息，也有可能会对玩家发动攻击。还有一种结果是玩家帮助商人逃过贸易禁令——如果玩家帮助了这名商人，他不仅能够再次出现在城市中，同时他也将提供给玩家一个新的任务，或者对于玩家另外一个不相干的任务提供相关信息。但是在另外一个早期任务中却存在一个离开腐败的城市官员的选择，这将导致玩家展开暗杀行为，而阻碍了商人的第二次任务行动（也就是之前所提到的）。游戏并未预先透露这些结果，或者这也不是什么重大结果，但是在玩家看来它们却近乎相同，特别是随着故事的发展其重要性不断上升之时。

不要创建你的技术和系统无法支持的游戏玩法

我之所以开始使用《龙腾世纪：起源》模组工具是因为它是我遇到过的少数优秀的RPG工具之一，并且那时候还存在一个充满活力的模组社区（很不幸的是今天已经看不到这样的社区）。我想要创造一个能够提供给玩家各种选择的模组，并带有各种具有引导性的结果——但是当我在创造“thirst”时，《龙腾世纪》的游戏机制和系统的缺陷却暴露无遗。

我所遇到的最大问题之一便是游戏不能有效地执行潜行和偷盗技能。归根结底是因为《龙腾世纪：起源》是一款围绕着地牢爬行和战斗的游戏，而这种偷盗技能很难在此体现出真正价值。尽管我尝试着去创造一些类似于潜行的游戏玩法，并且也让玩家能够在此面对偷钱包，撬锁等机制，但是所有的一切却仍显得不够成熟，因为核心规则本身还未得到合理的完善。而重新塑造游戏角色系统和规则则是我力所能及之外的任务，就其本身而言不仅需要投入大量的时间，进行各种游戏测试，同时我们还需要去平衡创造出全新内容是否真的具有价值性。

daorigins (from gamaustra)

（从根本上来看，《龙腾世纪》是一款围绕着战斗展开的游戏，而我也决定在项目规则集和引擎不断变强的同时往游戏中添加更多战斗内容。）

我正在努力解决的另外一个问题便是处理特定的任务结果。我本来应该在游戏中，甚至在对话中添加更多灵巧性检查或潜行检查而让玩家体会到更多像《颓废年代》中“朝着守卫射箭，在他分心时刺穿他的脸部，”的桥段，但是因为《龙腾世纪：起源》是以完全的3D特写视角呈现出来，所以加上这些桥段则会带给玩家一种笨拙感。老实说，投入大量时间而为玩家呈现出一小段动画序列并不是一种消耗时间的好方法。

甚至当我在游戏中添加了一些桥段，如玩家在对话中偷东西时，玩家甚至未能发现这些内容——尽管游戏机制明显地呈现在那里，但是我却不能清晰地表达出这些额外的桥段。同样的情况也出现在配音过程中。“Thirst”并没有任何配音演员，但是它却拥有《龙腾世纪》般特写对话镜头以及角色动画（尽管这些看起来不是那么协调）。实际上“Thirst”拥有上千条对话线，而如果我亲自为它们进行配音真的很不靠谱，我不仅需要为此增加大量的开发时间，同时还需要处理一个混乱的脚本（我并不是一个出色的对话作者，我也总是需要反复修改各种内容），所以我必须找到足够的配音演员（我不满意那些非专业的演员阵容，但我在此无意冒犯那些给自己的模组作画外音的人）。但是如果我使用早前的2D引擎，或者像《无冬之夜2》中的文本对话，这些问题也就迎刃而解了。

总结

总之，“Thirst”对于我来说是一个巨大的任务，我也很高兴看到自己能够发行其中的某些内容——尽管我还未能完成最终版本的模组设计。在整个开发过程中我真的获得了许多宝贵的经验教训。现在我不仅熟悉了各种工具，掌握了自己的优势和劣势，同时也了解了整个工作流程，所以我们便能够更加有效地完成接下来的工作。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Thirst: Development Lessons Learned

by Eric Schwarz

It’s been well over a year since I started work on my Dragon Age: Origins mod, Thirst.  Starting out as a very, very different concept – a short dungeon adventure where your character, a lone archeologist, is transformed into a demon and has to consume the souls of others to stay alive – and eventually working its way into a more standard but much more extensive traditional CRPG format, it underwent a huge number of changes.

While it still has yet to be completed, I have released a playable demo of the first several hours, and a clear vision of where things are going to go from here.  Thirst is not my first mod experience ever, but it was a huge learning experience that got me into “real” game development practices by forcing me to learn how to script using C++, how to properly structure narrative over a longer period of time, how to better construct levels to balance gameplay and realism, and how to handle complex interactions between many, many variables.

In this article I’ll be discussing a few of the challenges I faced, and how I overcame and learned from them.

Learn the Tools Before-Hand

One of the reasons that Thirst took so long for me to produce, not counting the odd system crash that forced me to restart it from scratch (though few of those original ideas remain in the final mod), was that I was still becoming familiar with the tools for the better part of its development.  The Dragon Age Toolset is a very good piece of software and quite intelligently organized, with different editors based on resource types, but even so, learning how to perform certain actions, do more advanced editing of game files to produce non-standard results, and set up scripts properly to override default behaviour are things that took me a while to come to grips with.

The Dragon Age Toolset is a great piece of software to use, but its learning curve and workflow required months of experience to fully appreciate and learn.

As a result, Thirst has some sloppy scripting in places.  There are a few quests that I wrote early on where I use more plot variables than what are really necessary to track progress.  One quest, for instance, revolves around getting information from a prisoner, who in turn demands freedom.  The player has many options for this – pay a bribe, pick the lock on the cell, steal the key, kill the guards, and more.  Lots of unique options demand lots of variables, but aside from minor details the outcomes are all relatively the same – the player frees the prisoner or doesn’t.  Without a single variable to track whether the prisoner was freed or not, later scripts became overly convoluted as I had to check four or five variables instead of one.  Had I had better foresight, I would have been able to avoid this issue entirely.

Similarly, my workflow in building levels is something I continually improved over the course of the project.  I learned new techniques for visually improving them, such as adding post-processing like bloom and colour grading – but in turn, that also meant I had to go back and tweak dozens of levels’ lighting schemes and layouts to make the new and improved effects work properly.  While not exceptionally time-consuming, it was still several days of work that I could have spent otherwise.  I feel the results were worth it and gave Thirst that “professional” look, but by not knowing how to do things before-hand I had to do more iteration than what was necessary.

Put Yourself in the Player’s Shoes

When sitting in the creator’s chair, oftentimes there are a lot of ideas flying around in my head.  Usually, they’re pretty good and appropriate to a given scenario – for example, creating multiple outcomes or solutions to quests and making things interact properly is something that comes easily to me because I’ve played plenty of other RPGs in my time – but when it comes to actually implementing them, sometimes the end results are different from what players expect.

Sometimes, this can be very simple things.  At the very beginning of Thirst, while exploring a raided caravan, the player comes across a survivor who provides some background exposition, and starts a small quest that gives impetus for the player to explore later down the road.  Sounds good, except when it came time to play-test, a friend of mine who tried the mod out completely missed the character because he mistook him for another dead body, despite being placed right along the critical path.  Solving it was a combination of a few techniques – placing a torch nearby to illuminate the area and highlight it, adding a dialogue pop-up as the player nears (“help me” etc.) – but this lesson made me drastically re-think the placement of certain characters and the layout of later levels.

Early challenges like this one reinforce the value of character development and positive behaviour like exploring the environment and searching for supplies.

Other times, this extends more to options the player has.  Early on, I learned it was important to establish a sort of gameplay contract with the player that expressed what was possible for the player and what wasn’t.  In an RPG, especially one with lots of stats, skills and multiple outcomes for every scenario, it can be easy for the player to assume that “everything” is possible – but of course, very real limitations have to be placed on those possibilities in order to keep the game consistent and the story moving forward.

For example, the encounter with the injured NPC mentioned above has about five different possible options (feed him healing plants, give him a health potion, cast a healing spell, use the Survival skill, etc.) – most situations later in the game don’t have quite that breadth of options, but I included them to establish a few ideas, such as “hey, you can use certain items in dialogue!” or “your non-combat skills have value!”  A similar challenge later on, breaking through some bars using a variety of means, was another gate intended to teach players that not only do skills matter, but things like race and attributes as well (for example, a high Strength allows players to break their way through, and playing a smaller race like dwarf or elf allows the player to bypass the puzzle entirely).

Telegraph Consequences

Thirst is a mod that features heavy emphasis on choice and consequence.  While it’s not quite the multi-faceted, “everything can change” story of a game like Alpha Protocol, many smaller details can influence each other.  For example, helping a character on a side-quest early on may yield an alternate option on a later main quest, allowing the player to bypass a portion of it.  In another instance, a major quest can be entirely skipped if the player is able to defeat a very challenging enemy.  Perhaps most clearly, two of the major quest-lines are mutually exclusive, and have story repercussions both in immediate and long-term ways.

However, one problem with consequence is that players don’t like unwelcome surprises.  Defining exactly what is unwelcome is tricky – for example, is getting into a fight with a character over a prior action a reward, or a punishment?  The context of consequence is very, very important to make sure players don’t feel like they’ve been betrayed by the game, or that their decisions didn’t pay off.  This isn’t to say that bad outcomes aren’t possible or warranted – but when they are, players should be given an understanding that what they do will have some sort of ramification later down the road.

Important decisions are telegraphed in advance so that they feel natural and logical.  Smaller ones have less telegraphing, but serve as minor rewards (or failures) for prior actions that help reinforce the continuity of the game world.

That big choice between the two major quest-lines (City Guard and Criminal Underworld), for instance, is something that I couldn’t just surprise the player with.  It’s a big decision, relatively speaking, and the consequences in both gameplay and story are notable to say the least, shaping the middle portion of the mod.  Therefore, I made sure to properly telegraph the decision by adding dialogue hinting that helping one party would exclude the other.  When players find that their former allies have turned against them, now it makes sense in the context of the world, story and gameplay, rather than coming off as unexpected or arbitrary.  Even if a player feels it’s unwelcome, it doesn’t feel like a cheap shot.

Of course, big consequences also require the player be prepared for them.  Much like the gameplay contract regarding options available, as mentioned above, a contract around consequences must also be established.  As a result, I made sure to include a number of smaller consequences in the introductory stages of the mod that have clear lineage and dependency.  For example, the way the player deals with a couple of mercenaries in a tavern early on has ramifications later on, when the player runs into them and they either provide information during a quest, or attack the player.  Another such consequence involves helping a merchant slip past a trade embargo – if the player assists him, not only will he appear later on in the city, but he’ll offer a new quest and provide information for another unrelated quest.  Yet another early quest has the option of ratting out a corrupt city official, which leads to his assassination, preventing the merchant’s second quest mentioned above.  These outcomes aren’t always stated clearly in advance, and the consequences aren’t necessarily huge, but they are felt and understood all the same, especially as they ramp up in significance over the course of the story.

Don’t Build Gameplay Your Tech and Systems Don’t Support

I started working with the Dragon Age: Origins mod tools because, at the time, it was one of the few good sets of RPG tools I had access to, and because at the time there was a vibrant mod community for it (unfortunately, not so much today).  My intent was always to build a mod where there were lots of options for the player, with plenty of consequences to boot – however, the limitations of the Dragon Age game mechanics and systems also made themselves apparent when creating Thirst.

One of the biggest problems I had was that stealth and thieving skills are not very well implemented.  This mostly comes down to the fact that Dragon Age: Origins is a game largely centered around dungeon crawling and combat, and those thieving skills are just not especially valuable except for a handful of times.  Although I tried to develop some semblance of stealth gameplay, and I included several quests where the player can pick pockets, open locks and so on to succeed, it always felt half-baked because the core rules themselves were under-developed as well.  Re-engineering the game’s character system and rules was something well beyond me, as that in itself would require huge time investments, play-testing, and tons of balancing that would ultimately be better spent on creating new content.

Ultimately, Dragon Age is a game whose mechanics revolve mostly around combat, and I decided to include more combat as the project went on to play to the strengths of the rule set and engine.

Another problem I struggled with was handling certain quest outcomes.  I would have loved to include more dexterity checks in the game, or stealth checks, even in dialogue, for example, to allow for great moments like Age of Decadence’s “throw your crossbow at guard and stab him in the face while he’s distracted”, but because of the fully 3D, close-up perspective Dragon Age: Origins takes, presenting those sorts of moments would have been a matter of hand-animating them.  Frankly, spending hours or even days keyframing out a short cinematic sequence that only as fraction of players would see was not a good way to spend time.

Even when I did include a few moments, like the player stealing items in dialogue, they didn’t really come across that well, because while the mechanics were all there, the presentation I was able to achieve wasn’t up to snuff.  The same also applies to voice acting.  Simply put, Thirst has none, but it does have the Dragon Age-style close-up dialogue cameras and character animations, which is arguably a bit jarring.  The fact is that Thirst has thousands of lines of dialogue, and voicing them myself is a near logistic impossibility that would add immensely to development time, not to mention the issue of dealing with a locked-down script (I’m not an amazing dialogue writer and I usually revise things many times over), finding adequate voice actors (I don’t think I’d be satisfied with the mixed quality a small non-professional cast could provide, no offense to those who are doing voice-over with their own mods), etc.  None of these would be problems if I had gone with an old-school 2D engine, or even with a game like Neverwinter Nights 2, where text-only dialogue is common.

Closing Thoughts

In short, Thirst was a huge undertaking for me and I’m happy that I’ve managed to finally release something, even if it still isn’t the complete version of the mod.  I learned a lot of lessons over the course of its development, and if there’s some consolation in going back to create another 3-5 hours of gameplay and story over the next several months, it’s that, now that I am familiar with the tools and know my strengths, weaknesses and limitations, not to mention a more efficient workflow, I can produce work much more quickly.

I’m not a professional developer, but hopefully my experiences have made for an interesting read, whether you’re an amateur, modder, industry hopeful, pro, or just a fan.  I’d love to hear any similar experiences anyone else has had with their own work, as well.  Thanks for reading!（source：GAMASUTRA）