制作一个模组
Template:Finishtranslation:zh-cn 本章旨在帮助你对起源引擎做出修改，或是制作一个Mod。首先，这里有一些关于开始创建Mod和组建团队的建议。接下来，是一些有关于确定游戏设计相关的提示。最后，是制作Mod最困难的部分，即如何为你的收尾并完成你的Mod。
开始
让我们从如何组建团队开始。
这部分的规则是保持团队轻量化。管理一个团队的人是一个全职工作，即便是所有员工都在一个工作地点。如果你想组建的团队都在线上工作，你可能除了管理团队外就没有多余时间来亲临制作模组活动了。为团队增加更多的成员并不意味着工作进度就会加快，因为更多的人就需要更多的时间去管理。
军团要塞的核心团队是三人，
反恐精英的核心团队是一人。
当寻找团队成员时，尽量去招募那些不可替代的人。你的第一直觉可能是招募任何能够编程、建模和地图制作等工作的人。但是对于你的第一个版本，你在以下每个领域（编程、音效、建模、地图）的团队都不需要超过一人。甚至你可能都不需要创建新的模型、声音或地图，所以在看到工作示例之前不需要招募任何人。确保他们都完成了他们的工作——一个模型师做了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做出全局决策。发售负责人应该明白消减功能和内容是发布过程中常见的事情。
建立构建过程
You need to create a process by which you build your mod. Building is the process of taking all your work and producing an installable, working version of the mod (generally in the form of an install file). This should be done exclusively by the SL for the next five weeks, and the SL should have a strict process that is always followed. Creating a strict process for this will ensure you don't waste hours tracking down bugs that are simply a result of someone building in a different way than the previous person.
The SL should maintain the final/release candidate version of the mod from now on. All changes should be sent to him, and he should incorporate them into his copy of the mod one by one and with a full understanding of the impact of the changes on all parts of the mod. Don't forget to backup your code and content regularly!
The SL should build the mod every day for playtests. More on that later.
特性锁定
Shipping is the process of locking down portions of your mod. "Locked" means that the portion is not to be touched from then on. Bugs found in locked portions of your mod should be thought about carefully. Unless the bug is really important (showstopper), just note it down and fix it in the next update of your mod. Regardless of the temptation to make that one "easy fix", unlocking portions of your mod should be avoided as much as possible.
At this point in the shipping process, five weeks out, you should also be feature locked. This means you shouldn't be adding any new features to your mod whatsoever. If part of your team is not involved in shipping but wants to continue working on developing the mod, they should be working in a separate content and code database. Most source code control packages allow for branching of code in this fashion. (Yes, we strongly recommend that you use some form of source control ). Every change made to the mod from now on should be a bug fix. The SL should ensure this. Even if a coder thinks of another cool feature that they say will only take them 10 minutes to code, do not let them add it in. Even if the coder sends the code, finished and bug-free, to the SL, do not add it to the mod. Save it for the next version.
A healthy attitude for the SL to have is that every change to the mod from now on will add two days to the release date.
游戏测试
From now on, you should be running playtests every day, or every second day if that's too much. Playtests should be based on installable versions of the game, built by the SL. Don't let team members play from their personal versions of the game. Everyone should be running a version of the mod installed from a build sent out by the SL (that's what your viewing public will be installing and using, that's what you should be testing). You'll waste many hours on finding bugs caused by incompatible versions if you don't do this.
To make this easier, the mod must be kept in a playable state at all times. Get very, very worried for every day the mod isn't playable. If a coder or mapmaker makes a change that breaks the mod, think about it carefully before incorporating it into the SL's build. How long will the game remain unplayable? How many playtests will you miss? How many team members won't be able to work because the mod isn't running? Not breaking the mod should be religion for the team.
When you do playtest, make sure as many of your team members are playing as possible. Everyone working on the game should be playing it regularly. Make sure you have some external players as well. Turn on server console logging (set "log" to "on" in the server.cfg file). This will dump all the output of the server into a file in the gamedir/logs directory ( the name of the file will match the date). Whenever any player in the game spots a bug, have them use their "say" key to say "BUG: description of bug". Then, when the game is over, you can open up the log file and get all the bugs out of it by searching for the word "BUG."
Bug及修改
The SL should maintain a complete list of all bugs and changes, and their current status. Preferably this should be done using some kind of true database. E-mail is totally insufficient for tracking bugs; it's just too easy for items to drop of the first page of a user's mailbox, etc. After each playtest, the bugs and necessary changes from the log file should be added to the list by the SL, and assigned to team members. When a team member has fixed a bug or change, they should submit the new content to the SL, who should verify that it is fixed and then update the status on the bug list.
The bug list is a fantastic tool to evaluate how well you are progressing. It can be used to find out who is overloaded with work, who is underloaded, who is not fixing his bugs, which area of your mod is farthest from completion, and so on. Don't remove anything from the bug list, even when it has been fixed (though you should mark it as fixed in some way, of course). It's very useful to see what bugs have been fixed throughout the history of the project. Something might regress, re-creating a bug, and knowing who fixed it last time makes it easy to ask them what caused it. At the end of the project, you should be able to see every bug fixed and every change made in your mod for the entire shipping process. The SL shouldn't allow any bug fix or change into the SL's master copy of the game unless the bug/change has been detailed in the bug list.
There is software that will help you create and maintain a bug list. Alternatively, a spreadsheet will work just fine. Again, e-mail is a bad choice.
删除或推迟有问题的功能
The hardest, nastiest, and unfortunately most necessary part of shipping is the act of being realistic and cutting features. We have a saying at Valve that everyone will have their favorite feature cut from the game. While it's not true, it does help everyone prepare themselves for the fact that they will have features they like -- or that they spent some to a lot of time on-- cut. Your game simply cannot have every cool feature and still ship in a reasonable time frame. The SL should make decisions about what to finish and what to cut, based on how far along in the release process you are.
The closer you get to releasing, the more you should think about each bug as you find it. Is the bug in a feature that absolutely must be in this version? How many days will it take to fix this feature? Can this feature be cut, or deferred to a later version?
精工细活
As we've said over and over again, the shipping process is hard, and it's even harder if you don't think carefully about what to work on. Working a lot is no substitute for carefully choosing what to fix, what to defer, and what to cut out altogether. The SL should be extremely careful about which bugs/changes should be worked on, and by whom. Don't spend a week fixing a minor problem in a feature just because the feature is cool. Fix crash bugs (showstoppers). Fix bugs that utterly prevent you from shipping the game. Fix bugs that are preventing other team members from fixing their bugs. The SL should develop categories for bugs to aid in making the right decisions. A good level of granularity is Must Fix, Severe, Medium, Minor, Zero, Deferred.
As the project gets closer to shipping, the SL should be carefully evaluating every bug that shows up. Remember, every bug that's fixed creates more playtesting, and usually more bugs. If you are two weeks from your release date, and you've got a bug that will take someone three days and 500 lines of code to fix, you're not going to make that release date unless you cut or defer that portion of the game.
发布三周前
内容锁定
By now you should aim to be content complete. This means that all content in the game is in a locked state, except for the game code itself. All the maps, models, textures, sounds, HUD art, launcher art, and so on should be finished and in the SL's master copy.
结束修改
This was mentioned at the five week mark, but it's even more important now. The SL is the only person who should be touching the master copy of the game, and he should simply be rolling in the bug fixes from the coders, who should be fixing only the bugs the SL hands them.
游戏测试
The mod should be being playtested every day, for at least two hours. Between now and when you ship, you want as many people as possible hammering away at your mod. It's too late now to make any major game design changes – don't even be tempted.
发布一周前
不要在最后一刻修改
The SL should be evaluating every change that has to be made, and deciding whether they should be deferred to the next version. Again, a healthy way to think about it is that every single change, even if it's a single line of code, will add two days to the release date.
两天安全期
Once every bug that is going to be fixed has been fixed, and everything else has been deferred, you're not done. Now you wait at least 48 hours, during which time you should playtest like crazy. Try to get everyone hammering away at the game for as much time as possible. If you find any more bugs that have to be fixed, fix them, and start the 48 hours again.
If your mod passes 48 hours of heavy playtesting without finding any new issues, you're ready to release!
发布后
So you've released, the players love it, and web pages everywhere are talking about how much fun your mod is. Whether you're done now is up to you. From our experiences in the on-line multiplayer field, a mod only stays popular as long as it's supported. No matter how great your mod is, it's not going to garner really significant player numbers with its first version. Player numbers are grown over time through repeated releases of new content, bug fixes, and of course, community support. Both Counter-Strike and Team Fortress started out small and grew over time. Each time they released a new version, more players tried them out and started playing them.
Knowing what to fix, what to change, and how to listen to your community is a continual learning process.
Good luck!