Making a Mod/zh
本章旨在帮助你对起源引擎做出修改，或是制作一个Mod。首先，这里有一些关于开始创建Mod和组建团队的建议。接下来，是一些有关于确定游戏设计相关的提示。最后，是制作Mod最困难的部分，即如何为你的收尾并完成你的Mod。
Contents
开始
让我们从如何组建团队开始。
这部分的规则是保持团队轻量化。管理一个团队的人是一个全职工作，即便是所有员工都在一个工作地点。如果你想组建的团队都在线上工作，你可能除了管理团队外就没有多余时间来亲临制作模组活动了。为团队增加更多的成员并不意味着工作进度就会加快，因为更多的人就需要更多的时间去管理。
军团要塞的核心团队是三人，
反恐精英的核心团队是一人。
当寻找团队成员时，尽量去招募那些不可替代的人。你的第一直觉可能是招募任何能够编程、建模和地图制作等工作的人。但是对于你的第一个版本，你在以下每个领域（编程、音效、建模、地图）的团队都不需要超过一人。甚至你可能都不需要创建新的模型、声音或地图，所以在看到工作示例之前不需要招募任何人。确保他们都完成了他们的工作——一个模型师做了20个模型但都是半成品，你肯定不会接受的。
Mod设计
作为一个Mod的作者，最有用的问题就是“为什么有人会玩我的Mod？”。这是一个很难如实回答的问题，但如果你能很好地回答，你就走在了正确的轨道上。探寻一下同行制作的Mod，以及它们提供的功能，你的Mod是否为玩家提供了一些新的东西？您提供的内容是否足以吸引忙于玩其他模组的玩家？纵使你不能回答这个问题，你仍然可以自行思考你的Mod大概会对游戏有什么帮助。
在可玩性上比拼
你有商业开发者所没有的权利：你不必担心新游戏风格的商业可行性。商业开发者不得不担心吸引零售、收支平衡和其他令人讨厌的事情，这就是为什么大多数游戏都是对已经证明的游戏玩法进行轻微修改的原因。但你不需要担心，你又不是企业，你可以尝试去做可能成为下一个大事件的全新游戏创意。这是你对于商业开发者的优势。专注于这一优势，让您的工作更轻松，不要花时间尝试在商业产品擅长的领域竞争。大多数模组无法在内容级别(地图、模型、声音等)上与商业产品相抗衡。他们有经验丰富的创作团队，但是对于游戏性，你可以拥有不同于他人的奇特想法，所以你可以在游戏性这一方面对峙他们。有一定规模的玩家会选择去玩一个内容很少，但游戏玩法非常有趣的模组。许多人没有意识到的是，军团要塞在首次发布后的一年内几乎没有任何美术方面的变动。
保持热情
你还有相较于商业开发者的另一个优势，你可以既快又频繁的发布。我们用“尽快发布，经常发布”来总结这个模组开发理念。商业开发者工作3-5年来发布他们的游戏，希望能有玩家喜欢这些游戏，但你不一定需要“循规蹈矩”，你可以选择设计完模组，制作到25%，并将其打磨至能玩的状态就发布。立刻获得反馈，然后你就可以逐个添加你所设计的其他部分，同时你可以将玩家的反馈添加到你的第一个版本，并继续在一到两个月内发布。你将始终与玩家保持联系减少你在玩家是否会喜欢的问题上所花的时间。诀窍就是把你的模组分成各个部分，初始版本只要能玩就行，不一定需要心急如焚的添加你原先所构想的每个功能。
需要注意，“尽快发布”并不意味着发布质量差的东西，而是尽量快的发布一些虽然小但是已经经过微小打磨的内容。第一个版本的反恐精英比如今的功能少一半。CS团队发布了一个体量不大但高质量的Mod。在过去的时间里他们一直在定期的添加越来越多的功能，玩家群体也因为他们的“尽快发布”而不断壮大规模。
与众不同并不代表比别人更好
在思考游戏设计时，不要陷入相信“与众不同更好”的陷阱。如果没有任何有趣的方式改动游戏，你都完全没必要重写霰弹枪的源码并还大费周章的去整一个新的猎枪模型。当别人问你，“为什么人们要玩你的Mod？”的时候你回答说，“我的Mod有一个新的作战系统和一个新的运动系统……”这并不是一个好的回答。难道因为你的作战机制和半条命不同？啊对~对~对~。这会让你的mod玩起来更有趣吗？新的移动系统会让游戏更有趣吗？玩家已经习惯了现有的系统，让他们学习另一个系统对他们来说是值得的。所以，在你考虑改变某些东西之前，你得知道你正在让它变得更好，这会让你的mod更有趣。勿惟恐丢掉和半条命有关的东西。
现实的目标
为自己制定切合实际的目标。想一想商业开发者需要多长时间才能制作一个拥有10种武器的FPS射击游戏。如果您的模组将拥有40种武器，那么将非常影响您的进度。这里要记住的是"质量胜于数量"。玩家更愿意拥有10种独特，平衡且用法有趣的武器，而不是40种不平衡的武器，其中还有一些武器仅仅做了略微调整。
不要害怕削减内容和功能。如果模组看起来永远不会完成，或者有些内容你认为不符合模组其余部分的质量，那么就开始剪辑吧，在
半衰期的开发过程中，设计中至少有30%的原始特性被删减，因为很明显它们在我们的时间线中无法实现。或者因为我们认为它们不值得他们花时间开发.正如我们上面所说，“质量胜于数量”。比起 10 个未经测试的地图，玩家更愿意拥有3个非常好的，经过良好游戏测试的地图，这将使您的模组在优质内容方面享有盛誉。不要让别人看到你做的东西很糟糕。
理解游戏引擎
你十分有必要去读一下SDK里面的Source SDK开发文档。这样你就能充分了解到引擎做你想要的功能如何完成效果最好而不是引擎可不可以实现你想要的功能这种没有营养的问题。你可以做一把能够发射50发火箭的P90火箭发射器，但是如果你不懂引擎是怎么工作的，那你可能会因为这把武器把玩家的网络搞得不堪重负。这方面对你mod中的所有人都很重要。如果你的地图制作者不了解引擎，他们将制作一幅巨大的地图而没有考虑到网络资源的占用，那每个玩家都会指责你的mod玩起来太卡了。如果你是程序员那加入半衰期程序员邮件列表是个好主意，你可以在其中与其他许多mod程序员或者Valve员工进行深入交流。邮件列表可以查看很久以前的档案，说不定其中就有你苦苦追寻关于mod开发的解决方案。
完成
很多mod一开始都很强大，产生了很多精彩的内容，但却十分难以成功进入玩家手中。这一部分将帮助你进入发布模式，在这个模式下，你正朝着mod发布之路前进。
我们选择通过五周时间作为正常开发到交付版本的时间预估。通过连续发布模式可以将mod变得更好且发布更频繁。如果你的Mod想法宏大，或者你的团队是国际化的团队，那么可能需要的时间更长，如果可能的话，试着让团队在这段时间内每天化几个小时投入到模组上。如果某些团队成员做不到这点，你最好将他们从发布过程中删除。让他们将自己负责的部分交给其他人完成。即便是发布一个小的作品也是需要实质性承诺才能做到的。
这一节中可能有许多内容看起来让人觉得很生硬与苛刻。很不幸，但是反映了开发一个作品是一个多么困难的过程。这里的建议是对许多产品发布过程中吸取的经验和教训的总结，其中大部分是导致我们发布日期推迟的苦痛经历。当你觉得这里的某些建议是否那么必要时，我们可能因为这个错误而将产品发布日期推迟了数周。
这也是潜在雇主非常关注的事情。看到一个模组制作团队制作了一堆很酷的东西是一回事，而看到他们制作了一堆很酷的东西并且实际发售后有人游玩这是另一回事。如果这些很酷的地图、模型、代码、音效等因为一点小原因而最后不能发布那么这个作品也将毫无用处。
不用担心，勤能补拙。或许你的Mod发布三四次之后，你就熟练技巧了！
发布5周前
集中所有权
你应该指定团队中的一名成员为发售负责人（SL）此人将在接下来的五周内推动Mod的开发进展。从现在开始对Mod所作的所有更改都应在发售负责人的授权下进行，并且所有更改请求都应该通过此人进行，除非发售负责人要求他们进行特定的更改，否则任何团队成员都不应该对Mod进行任何修改，无论多么微小。这并不意味着团队的其他成员失去了Mod的控制权，发售负责人仍然时团队的一部分，并且将听取所有的反馈。发售负责人的重点是确保对Mod的修改都经过了一个特定的成员。这避免了诸如地图制作者在最后时刻对地图进行了修改从而破坏了游戏性等类似问题,因为他没有意识到游戏代码中的其他内容因为他的修改而产生了变化。发售负责人将在接下来的五周内随时了解游戏中的每个组件（代码，地图，模型，纹理等）的状态，以确保这种情况永远不会发生。
选择发售负责人不是一个简单的指派问题。这里有一些提示：
- 不要立刻假设管理当前Mod的人是发售负责人的最佳人选，尤其是如果该Mod已经开发了几个月并且还没有接近发布。
- 游戏程序员可能是最好的选择。随着发布过程的结束，大多数修复将在游戏代码中进行。
- 发售负责人应该是高度积极的、有纪律的、有组织的，并且不那么自我的。发售负责人需要能够将他/她生命中的五周尽心尽力的投入到发售过程中的。
- 发售负责人应该能够为Mod做出全局决策。发售负责人应该明白消减功能和内容是发布过程中常见的事情。
建立构建过程
你需要创建一个流程来构建你的Mod，构建是完成所有工作并生成可安装版本的过程（通常以安装文件的形式）。这个流程应该由发售负责人在发布前五周内专门完成，并且发售负责人应该有一个始终遵循的严格流程。为此闯进一个严格的流程能够保证你不会把时间浪费在检查错误上，这些错误可能仅仅是因为人与人之间不同的构建方式产生的。
从现在开始发售负责人应该维护该Mod的最终版本或是发布候选版本。所有的修改都应提交给发售负责人，由发售负责人将这些更改一一合并到Mod的副本中，并充分了解更改对Mod各个部分的影响。记住！不要忘记定期对内容和代码进行定期备份。
发售负责人应该为了游戏测试日复一日构建Mod。稍后我们会谈论这些。
特性锁定
发售是锁定Mod部分功能的过程。“锁定”意味着这一部分将不会再被修改。应该仔细考虑在Mod锁定部分发现的bug。除非该bug非常重要（游戏的精彩部分），否则只需要记下它并且在Mod下一次更新中修复它。不管尝试修复这个bug是不是个“简单”的事情，都应该尽可能避免解锁Mod的锁定部分。
在发售流程这一过程中，这五周内，你也应该锁定功能。这代表着你不应该在这期间向Mod添加任何新功能。如果您的团队中的一部分人不参与发售流程但想继续Mod的开发，那应该让他们在独立的内容和代码中工作。大多数的版本控制软件都允许团队以这种方式进行分支开发。（是的，我们强烈建议您使用某种形式的版本控制）。从现在开始，应该只做bug修复。发售负责人应该严格执行这一策略。即便程序员想到一个他们说只需要10分钟就能开发完成的精彩功能，也不能让他们对Mod进行修改。即使程序员将已完成且没有错误的代码发送给发售负责人，也不要将其合并到Mod中。留到下一个版本！
对于发售负责人来说，一个正常的态度应该是从现在开始对Mod的每一次修改都要延长两天发布日期。
游戏测试
从现在开始，你应该每天进行一次游戏测试，如果你觉得太多的话，应该每隔一天游玩一次。游戏测试应基于发售负责人构建的可安装版本。不要让团队成员游玩他们自己的个人版本。让团队成员测试玩家将安装和使用的内容来测试。如果不这样做你将浪费很多时间来查找不兼容版本引起的错误。
为了使游戏测试更加方便，Mod必须保持随时可用的状态。每天都要关注模组是否可能进行游玩。如果程序员或者地图制作人做出的更改破坏了Mod，请在将修改合并到发售负责人构建版本时仔细考虑将会影响游戏测试多长时间，有多少团队成员因为游戏不能正常运行而无法工作。不破坏Mod应该是团队的信仰。
当进行游戏测试时，请确保尽可能多的团队成员都在进行游戏测试。每个从事游戏开发工作的人都应该定期玩游戏。确保你也有一些项目之外的玩家。打开服务器控制台日志记录（在Server.cf文件中将"log"设置为"on"）,这个操作将会把所有服务器内的输出转储到gamedir/logs目录中（文件名将与日期匹配）。每当游戏中有任何玩家发现bug时让他们使用“说话”按键说出“BUG:描述”。然后当游戏结束时，你可以打开日志文件搜索"BUG"来找出所有bug。
Bug及修改
发售负责人应该维护所有bug更改及其当前状态的完整列表。最好应该使用某种真正的数据库来完成。电子邮件完全不足以跟踪bug。每次游戏测试后，日志文件中的错误和必要的修改都应该由发售负责人添加到列表中，并分配给团队成员。当团队成员修复bug或完成更改时，他们应将新的内容提交给发售负责人，发售负责人应对其验证是否已经完成了bug的修复，然后更新bug列表中的状态。
bug列表是评估进展情况的绝佳工具。它可以用来找出谁的工作超出负荷，谁的工作过于轻松，谁还没有修复他的bug，你的Mod哪部分离完成还早等等。不要从bug列表中删除任何内容，即使bug已被修复（当然，你应该用某种方式将其标记为已修复）。查看整个项目中修复了那些错误将非常有用。某些地方可能会倒推，重新创建新的bug，并且能够知道上次修复的人可以很容易的联系到此bug修复者是什么原因造成的bug。在项目结束时，应该能够看到在整个发售过程中修复的每个bug以及在Mod中所作的所有更改。发售负责人应将错误、更改在错误列表中进行详细说明，否则不应该将修复后的版本或者更改合并到发售游戏的副本中。
有些软件可以帮助您创建和维护bug列表。或者Excel也可以充当bug列表。但是请记住！电子邮件是一个糟糕的选择。
删除或推迟有问题的功能
发售过程中最难，最讨厌，但又不得不做的部分是删除特性。我们在Valve有一个说法，即每个人都会从游戏中删除他们最喜欢的功能。虽然这并不是真理，但确实可以帮助每个人将拥有他们喜欢的特性，或者他们花了一些时间为删除的事实做好了准备。你的游戏不可能拥有每一个很酷的功能还能在合理的时间内发布。发售负责人应该根据你在发布过程中的进度来决定要完成什么和删掉什么。
你越接近发布日期你就越应该在发现每个错误的时候考虑它。这个版本中必须要保留这个有bug的特性吗？需要多久能够修复它？这个功能是不是可以被删除，还是推迟到高版本后再发布？
精工细活
正如我们一遍又一遍的提起，发售过程很困难，如果你不仔细去考虑要做什么那就更难了。大量工作并不能代替仔细选择要修复的内容、推迟的内容以及完全删除的内容。发售负责人应该非常小心应该处理那些bug/更改，以及由谁来处理。不要仅仅因为某个功能很酷就花一周来解决某个功能中的小问题。修复崩溃bug（精彩内容bug）。修复那些完全阻止你发布游戏的bug。修复那些阻止其他成员修复bug的bug。发售负责人应该为bug分级以做出正确的决定。良好的分级是 必须修复、严重、中等、轻微、不影响、推迟。
随着项目接近交付，发售负责人应该仔细评估出现的每个bug。请记住每一个被修复的bug都需要更多的游戏测试，而且通常会产生更多错误。如果距离发布日期还有两周，并且遇到了一个需要花费三天时间需要敲500行代码才能修复的错误，那么除非你将其删掉或者推迟该部分的发布否则你讲不能确定游戏的发布日期。
发布三周前
内容锁定
到目前为止，你的目标应该是内容完整。这意味着游戏中除了代码外的所有的内容都处于锁定状态。所有地图、模型、材质、贴图、声音、HUD样式、加载器样式等都应该完成并集成在发售负责人的主版本中。
结束修改
这个曾在发布前五周中提到过，但是现在更加重要。发售负责人应该是唯一应该能够接触到游戏主版本的人，他应该只是滚动添加程序员对bug的修复，程序员应该只修复程序员交给他们修复的bug。
游戏测试
Mod应该每天进行至少两个小时的游戏测试。从现在到发行期间应该由尽可能多的人对Mod进行测试。现在做出任何重大的游戏设计更改都为时已晚，不要被诱惑！
发布一周前
不要在最后一刻修改
发售负责人应该评估每一个必须要做出的修改，并决它们是否应该推迟到下一个版本。同样，记得之前说的每一次修改即便是一行代码都要使发布日期推迟两天。
两天安全期
即使要修复的每个错误都已经被修复，其他要推迟的内容已经确认推迟那也还没有结束。现在你至少要等待48小时，在此期间应该应该疯狂进行游戏测试。尝试让每个人都尽可能的在游戏中疯狂游玩。如果你发现更多需要修复的bug，请修复它们然后重新开始48小时的游戏测试。
如果你的Mod通过了48小时的重度游戏测试而没有发现任何新问题，那么就可以发布你的Mod了。
发布后
现在你已经发布了，玩家喜欢这个游戏，到处都在谈论你的Mod是多么的有趣。现在是否结束完全取决于你了。根据我们在多人在线游戏领域的经验，一个Mod只有在受到支持的情况下才会流行。无论你的Mod多么出色，它的第一个版本都不会获得真正重要的玩家数量。随着新内容的不断发布，bug修复，还有社区支持，玩家会随着时间的推移而增长。反恐精英和军团要塞都是从小规模开始，并随着时间的推移而发展壮大。每次他们发布一个新的版本，都会有很多新玩家尝试游玩。
知道要修复什么，改变什么以及如何倾听社区的声音是一个持续学习的过程。
祝你好运！
