这部分的规则是保持团队轻量化。管理一个团队的人是一个全职工作，即便是所有员工都在一个工作地点。如果你想组建的团队都在线上工作，你可能除了管理团队外就没有多余时间来亲临制作模组活动了。为团队增加更多的成员并不意味着工作进度就会加快，因为更多的人就需要更多的时间去管理。
军团要塞的核心团队是三人，
反恐精英的核心团队是一人。
当寻找团队成员时，尽量去招募那些不可替代的人。你的第一直觉可能是招募任何能够编程、建模和地图制作等工作的人。但是对于你的第一个版本，你在以下每个领域（编程、音效、建模、地图）的团队都不需要超过一人。甚至你可能都不需要创建新的模型、声音或地图，所以在看到工作示例之前不需要招募任何人。确保他们都完成了他们的工作——一个模型师做了20个模型但都是半成品，你肯定不会接受的。
作为一个Mod的作者，最有用的问题就是“为什么有人会玩我的Mod？”。这是一个很难如实回答的问题，但如果你能很好地回答，你就走在了正确的轨道上。探寻一下同行制作的Mod，以及它们提供的功能，你的Mod是否为玩家提供了一些新的东西？您提供的内容是否足以吸引忙于玩其他模组的玩家？纵使你不能回答这个问题，你仍然可以自行思考你的Mod大概会对游戏有什么帮助。
你有商业开发者所没有的权利：你不必担心新游戏风格的商业可行性。商业开发者不得不担心吸引零售、收支平衡和其他令人讨厌的事情，这就是为什么大多数游戏都是对已经证明的游戏玩法进行轻微修改的原因。但你不需要担心，你又不是企业，你可以尝试去做可能成为下一个大事件的全新游戏创意。这是你对于商业开发者的优势。专注于这一优势，让您的工作更轻松，不要花时间尝试在商业产品擅长的领域竞争。大多数模组无法在内容级别(地图、模型、声音等)上与商业产品相抗衡。他们有经验丰富的创作团队，但是对于游戏性，你可以拥有不同于他人的奇特想法，所以你可以在游戏性这一方面对峙他们。有一定规模的玩家会选择去玩一个内容很少，但游戏玩法非常有趣的模组。许多人没有意识到的是，军团要塞在首次发布后的一年内几乎没有任何美术方面的变动。
你还有相较于商业开发者的另一个优势，你可以既快又频繁的发布。我们用“尽快发布，经常发布”来总结这个模组开发理念。商业开发者工作3-5年来发布他们的游戏，希望能有玩家喜欢这些游戏，但你不一定需要“循规蹈矩”，你可以选择设计完模组，制作到25%，并将其打磨至能玩的状态就发布。立刻获得反馈，然后你就可以逐个添加你所设计的其他部分，同时你可以将玩家的反馈添加到你的第一个版本，并继续在一到两个月内发布。你将始终与玩家保持联系减少你在玩家是否会喜欢的问题上所花的时间。诀窍就是把你的模组分成各个部分，初始版本只要能玩就行，不一定需要心急如焚的添加你原先所构想的每个功能。
在思考游戏设计时，不要陷入相信“与众不同更好”的陷阱。如果没有任何有趣的方式改动游戏，你都完全没必要重写霰弹枪的源码并还大费周章的去整一个新的猎枪模型。当别人问你，“为什么人们要玩你的Mod？”的时候你回答说，“我的Mod有一个新的作战系统和一个新的运动系统……”这并不是一个好的回答。难道因为你的作战机制和半条命不同？啊对~对~对~。这会让你的mod玩起来更有趣吗？新的移动系统会让游戏更有趣吗？玩家已经习惯了现有的系统，让他们学习另一个系统对他们来说是值得的。所以，在你考虑改变某些东西之前，你得知道你正在让它变得更好，这会让你的mod更有趣。勿惟恐丢掉和半条命有关的东西。
为自己制定切合实际的目标。想一想商业开发者需要多长时间才能制作一个拥有10种武器的FPS射击游戏。如果您的模组将拥有40种武器，那么将非常影响您的进度。这里要记住的是"质量胜于数量"。玩家更愿意拥有10种独特，平衡且用法有趣的武器，而不是40种不平衡的武器，其中还有一些武器仅仅做了略微调整。
我们选择通过五周时间作为正常开发到交付版本的时间预估。通过连续发布模式可以将mod变得更好且发布更频繁。如果你的Mod想法宏大，或者你的团队是国际化的团队，那么可能需要的时间更长，如果可能的话，试着让团队在这段时间内每天化几个小时投入到模组上。如果某些团队成员做不到这点，你最好将他们从发布过程中删除。让他们将自己负责的部分交给其他人完成。即便是发布一个小的作品也是需要实质性承诺才能做到的。
这一节中可能有许多内容看起来让人觉得很生硬与苛刻。很不幸，但是反映了开发一个作品是一个多么困难的过程。这里的建议是对许多产品发布过程中吸取的经验和教训的总结，其中大部分是导致我们发布日期推迟的苦痛经历。当你觉得这里的某些建议是否那么必要时，我们可能因为这个错误而将产品发布日期推迟了数周。
这也是潜在雇主非常关注的事情。看到一个模组制作团队制作了一堆很酷的东西是一回事，而看到他们制作了一堆很酷的东西并且实际发售后有人游玩这是另一回事。如果这些很酷的地图、模型、代码、音效等因为一点小原因而最后不能发布那么这个作品也将毫无用处。
你需要创建一个流程来构建你的Mod，构建是完成所有工作并生成可安装版本的过程（通常以安装文件的形式）。这个流程应该由发售负责人在发布前五周内专门完成，并且发售负责人应该有一个始终遵循的严格流程。为此闯进一个严格的流程能够保证你不会把时间浪费在检查错误上，这些错误可能仅仅是因为人与人之间不同的构建方式产生的。
从现在开始发售负责人应该维护该Mod的最终版本或是发布候选版本。所有的修改都应提交给发售负责人，由发售负责人将这些更改一一合并到Mod的副本中，并充分了解更改对Mod各个部分的影响。记住！不要忘记定期对内容和代码进行定期备份。
发售是锁定Mod部分功能的过程。“锁定”意味着这一部分将不会再被修改。应该仔细考虑在Mod锁定部分发现的bug。除非该bug非常重要（游戏的精彩部分），否则只需要记下它并且在Mod下一次更新中修复它。不管尝试修复这个bug是不是个“简单”的事情，都应该尽可能避免解锁Mod的锁定部分。
在发售流程这一过程中，这五周内，你也应该锁定功能。这代表着你不应该在这期间向Mod添加任何新功能。如果您的团队中的一部分人不参与发售流程但想继续Mod的开发，那应该让他们在独立的内容和代码中工作。大多数的版本控制软件都允许团队以这种方式进行分支开发。（是的，我们强烈建议您使用某种形式的版本控制）。从现在开始，应该只做bug修复。发售负责人应该严格执行这一策略。即便程序员想到一个他们说只需要10分钟就能开发完成的精彩功能，也不能让他们对Mod进行修改。即使程序员将已完成且没有错误的代码发送给发售负责人，也不要将其合并到Mod中。留到下一个版本！
从现在开始，你应该每天进行一次游戏测试，如果你觉得太多的话，应该每隔一天游玩一次。游戏测试应基于发售负责人构建的可安装版本。不要让团队成员游玩他们自己的个人版本。让团队成员测试玩家将安装和使用的内容来测试。如果不这样做你将浪费很多时间来查找不兼容版本引起的错误。
为了使游戏测试更加方便，Mod必须保持随时可用的状态。每天都要关注模组是否可能进行游玩。如果程序员或者地图制作人做出的更改破坏了Mod，请在将修改合并到发售负责人构建版本时仔细考虑将会影响游戏测试多长时间，有多少团队成员因为游戏不能正常运行而无法工作。不破坏Mod应该是团队的信仰。
当进行游戏测试时，请确保尽可能多的团队成员都在进行游戏测试。每个从事游戏开发工作的人都应该定期玩游戏。确保你也有一些项目之外的玩家。打开服务器控制台日志记录（在Server.cf文件中将"log"设置为"on"）,这个操作将会把所有服务器内的输出转储到gamedir/logs目录中（文件名将与日期匹配）。每当游戏中有任何玩家发现bug时让他们使用“说话”按键说出“BUG:描述”。然后当游戏结束时，你可以打开日志文件搜索"BUG"来找出所有bug。
发售负责人应该维护所有bug更改及其当前状态的完整列表。最好应该使用某种真正的数据库来完成。电子邮件完全不足以跟踪bug。每次游戏测试后，日志文件中的错误和必要的修改都应该由发售负责人添加到列表中，并分配给团队成员。当团队成员修复bug或完成更改时，他们应将新的内容提交给发售负责人，发售负责人应对其验证是否已经完成了bug的修复，然后更新bug列表中的状态。
bug列表是评估进展情况的绝佳工具。它可以用来找出谁的工作超出负荷，谁的工作过于轻松，谁还没有修复他的bug，你的Mod哪部分离完成还早等等。不要从bug列表中删除任何内容，即使bug已被修复（当然，你应该用某种方式将其标记为已修复）。查看整个项目中修复了那些错误将非常有用。某些地方可能会倒推，重新创建新的bug，并且能够知道上次修复的人可以很容易的联系到此bug修复者是什么原因造成的bug。在项目结束时，应该能够看到在整个发售过程中修复的每个bug以及在Mod中所作的所有更改。发售负责人应将错误、更改在错误列表中进行详细说明，否则不应该将修复后的版本或者更改合并到发售游戏的副本中。
发售过程中最难，最讨厌，但又不得不做的部分是删除特性。我们在Valve有一个说法，即每个人都会从游戏中删除他们最喜欢的功能。虽然这并不是真理，但确实可以帮助每个人将拥有他们喜欢的特性，或者他们花了一些时间为删除的事实做好了准备。你的游戏不可能拥有每一个很酷的功能还能在合理的时间内发布。发售负责人应该根据你在发布过程中的进度来决定要完成什么和删掉什么。
你越接近发布日期你就越应该在发现每个错误的时候考虑它。这个版本中必须要保留这个有bug的特性吗？需要多久能够修复它？这个功能是不是可以被删除，还是推迟到高版本后再发布？
正如我们一遍又一遍的提起，发售过程很困难，如果你不仔细去考虑要做什么那就更难了。大量工作并不能代替仔细选择要修复的内容、推迟的内容以及完全删除的内容。发售负责人应该非常小心应该处理那些bug/更改，以及由谁来处理。不要仅仅因为某个功能很酷就花一周来解决某个功能中的小问题。修复崩溃bug（精彩内容bug）。修复那些完全阻止你发布游戏的bug。修复那些阻止其他成员修复bug的bug。发售负责人应该为bug分级以做出正确的决定。良好的分级是 必须修复、严重、中等、轻微、不影响、推迟。
随着项目接近交付，发售负责人应该仔细评估出现的每个bug。请记住每一个被修复的bug都需要更多的游戏测试，而且通常会产生更多错误。如果距离发布日期还有两周，并且遇到了一个需要花费三天时间需要敲500行代码才能修复的错误，那么除非你将其删掉或者推迟该部分的发布否则你讲不能确定游戏的发布日期。
到目前为止，你的目标应该是内容完整。这意味着游戏中除了代码外的所有的内容都处于锁定状态。所有地图、模型、材质、贴图、声音、HUD样式、加载器样式等都应该完成并集成在发售负责人的主版本中。
这个曾在发布前五周中提到过，但是现在更加重要。发售负责人应该是唯一应该能够接触到游戏主版本的人，他应该只是滚动添加程序员对bug的修复，程序员应该只修复程序员交给他们修复的bug。
即使要修复的每个错误都已经被修复，其他要推迟的内容已经确认推迟那也还没有结束。现在你至少要等待48小时，在此期间应该应该疯狂进行游戏测试。尝试让每个人都尽可能的在游戏中疯狂游玩。如果你发现更多需要修复的bug，请修复它们然后重新开始48小时的游戏测试。
现在你已经发布了，玩家喜欢这个游戏，到处都在谈论你的Mod是多么的有趣。现在是否结束完全取决于你了。根据我们在多人在线游戏领域的经验，一个Mod只有在受到支持的情况下才会流行。无论你的Mod多么出色，它的第一个版本都不会获得真正重要的玩家数量。随着新内容的不断发布，bug修复，还有社区支持，玩家会随着时间的推移而增长。反恐精英和军团要塞都是从小规模开始，并随着时间的推移而发展壮大。每次他们发布一个新的版本，都会有很多新玩家尝试游玩。
This article is designed to help you make a Source Engine modification, or mod. First, it has some advice on starting a mod, and assembling a team. Following that is a collection of helpful tips on figuring out the game design for your mod. Finally, it has a step-by-step guide on how to tie up the loose ends and finish your mod, which is actually the hardest part of mod making.
Starting out
Lets start by looking at how to assemble a team. The guiding rule here is to keep it small. Managing a team of people is a full-time job, even when all the team resides in the same building. If you're dealing with an on-line team, you can easily spend all your time managing it, and that means you won't be spending any time on making your mod. Adding more people to the team doesn't mean more work will get done. The more people you have, the more time spent managing them. Team Fortress's core team was 3 people. Counter-Strike's core team was one person.
When looking for team members, try to only hire people you absolutely cannot survive without. Your first instinct might be to hire anyone who can code, or model, or make maps, and so on. But for your first version, you probably won't need more than one person for each area of your mod (code, sound, models, maps). You may not even need any new models, sounds, or maps. Don't hire anyone until you've seen examples of their work. Make sure they've actually finished things. If they're a modeler who's done 20 models, but they're all half-finished, you don't want them.
Mod design
As a mod author, the most useful question you can ask yourself is "Why should someone play my mod?" It's a hard question to answer truthfully, but if you can answer it well, you're on the right track. Think about what other mods are out there, and what they offer. Does your mod offer something new to the players? Is what you offer enough to entice players who are busy playing other mods? Even if you can't answer this question, just thinking about it will probably help your mod.
Compete with gameplay
You have power commercial developers don't: You don't have to worry about the commercial viability of new gameplay styles. Commercial developers have to worry about appealing to retail, breaking even, and other nasty things, which is why most games are slight modifications on already proven gameplay. But you don't. You can try out truly new gameplay ideas that just might become the Next Big Thing. This is your edge over commercial developers. Make your job easier by concentrating on this edge, and don't spend your time trying to compete in the areas that commercial products are strong in. Most mods can't compete on a content level (maps, models, sounds, etc) with commercial products. They've got teams of artists with years of experience. Beat them with your gameplay. Players will play a mod that has very little in the way of new content, but has really fun gameplay. Something many people don't realize is that Team Fortress 1 had almost no new art for a year after it was first released.
Release soon, release often
You have another power over commercial developers. You can release much, much faster and more often than they can. We've summarized this mod development philosophy with the phrase, "Release soon, Release often." Commercial developers work for 2-3 years, release their game, and hope to god people like it. You don't have to make that leap of faith. You can design your whole mod, write 25% of it and polish it to a playable state, then release it and begin getting feedback immediately. Then you can start adding the rest of your design piece by piece, at the same time rolling in the player's feedback to the first version, and continue releasing every month or two. You're in touch with your players at all times, so you'll never be in the situation where you've spent a lot of time on something you're not sure your players will like. The trick is to cut your mod up into slices. The initial version needs to be fun and playable, but doesn't need every cool feature you've thought of.
Be careful. "Release soon" doesn't mean releasing bad quality stuff, it just means doing your mod in small, polished increments. The first version of Counter-Strike didn't have half of the features they have now. The CS team released a high quality, but not big mod. Over the past year, they've been regularly adding more and more features and, in response, their player base has just continued to grow and grow.
Different is not always better
When thinking about your game design, don't fall into the trap of believing that "Different is Better." There's no reason to rewrite the shotgun code and have a new shotgun model if it doesn't impact your game in any interesting way. Keep in mind the first question, "Why should someone play my mod?" The answer, "My mod has a new combat system, and a new movement system," isn't necessarily a good answer. So your combat system is different that Half-Life's. OK... but is it better? Does it make your mod more fun to play? Does a new movement system make the game more fun? Player's are used to existing systems, and making them learn another one needs to be worth it for them. So before you think about changing something, make sure you know you're changing it for the better, and that it'll make your mod more fun. Don't be afraid to just leave something the same as it was in Half-Life.
Realistic goals
Create realistic goals for yourself. Think about how long it takes a commercial developer to make an FPS shooter with 10 weapons. If your mod is going to have 40 weapons, you're making life really hard for yourself. The thing to keep in mind here is "Quality over Quantity." Players would far prefer to have 10 unique, well balanced, and fun to use weapons than 40 unbalanced weapons, some of which are slightly tweaked versions of others.
Don't be afraid to cut content and features. If the mod looks like it's never going to be finished, or there's some content that you don't think meets the quality of the rest of the mod, then start cutting. During the development of HL at least 30% of the original features in the design were cut because it became obvious they were unattainable in our timeline, or because we decided they weren't worth their development time. As we said above, "Quality over Quantity." Players would prefer having 3 really good, well play-tested maps over 10 untested ones, and it'll give your mod a reputation for quality content. Don't let the world see your worst stuff.
Understand the engine
You really should read the documentation included in the SDK. The thing you'll learn most by doing so isn't whether you can do X with the engine, but rather how X should be done so it works well. You can make a gun that fires 50 rockets, but if you don't understand the way the engine works, you might do it in a way that significantly increases the network traffic your mod uses. This is important for everyone in your mod. If your mapmakers don't understand the engine, they'll make huge maps without any thought for how much network data will be sent to the players in them, and everyone will blame your code for being too network intensive. If you're a programmer, it's a good idea to join to HL Coders mailing list, where you'll be able to talk to many other mod programmers, and a few Valve employees as well. The mailing list has archives going back a long way, which contain a lot of useful solutions to common mod problems.
Finishing
We see a lot of mods that start out strong, produce a lot of great looking content, and never quite make the last step of getting it into the player's hands. This section will help you get into a release mode where you're driving towards producing a releasable version of your mod.
We chose five weeks as a starting estimate of the time it'll take to get from normal development mode to a shippable version. It's likely you'll get better, and hence faster, at this with successive releases. If your mod is larger in scope, or your team is substantially international, then it is likely to take more than five weeks, though the steps will be similar to the following.. If possible, try and get the team to commit a few hours of every day to the mod for this period of time. If some team members can't do that, you're probably better off removing them from the shipping process. Get them to hand their part to someone else on the team who can put in the required effort. Shipping a product, even a small product, is hard and requires a substantial commitment.
There are many things in this section that might sound harsh or rigid. This is unfortunate, but a reflection on how hard a process this is. The advice here is a summation of lessons learned in the shipping of many products, and most of it a result of painful mistakes that set back our release dates. When you wonder whether a particular piece of advice here is necessary, it's possible that we once added weeks to our release date because we didn't take it.
This is also something that prospective employers are extremely interested in. It's one thing to see that a mod maker has produced a bunch of cool stuff, it's another thing entirely to see that they produced some cool stuff and actually shipped it out and people played it. The coolest map/model/code/sound/etc. in the world is useless if you couldn't go the last mile and ship it.
Fear not, this gets a lot easier once you've been through it a couple of times. By the third or fourth release of your mod, you'll be an expert!
Five weeks out
Centralize ownership
You should designate a single member of your mod team as the Shipping Leader (SL). This person will drive progress on the mod for the next five weeks. All changes made to the mod from now on should occur only at the request of the SL, and all requests for changes should be funneled through this person. No team member should make any changes, no matter how minor, to the mod unless the SL has requested that they make a particular change. This doesn't mean the rest of the team are losing control of the mod; the SL is still a part of the team, and will be listening to all feedback. The point of the SL is to ensure that all changes to the mod are going through a single person. This avoids problems such as a mapmaker breaking the game by making a last minute change because he didn't realize something else had changed in the game code. The SL will know the state of every component in the game (code, maps, models, textures, etc) at all times throughout the next 5 weeks to ensure this never happens.
Choosing the SL isn't easy. Here are a few tips:
- Don't immediately assume the person who's currently running the mod is the best choice for SL, especially if the mod has been worked on for months and hasn't got any closer to being released.
- Game Coders are probably the best choice. As the shipping process comes to an end, most fixes will be made in the game code.
- The SL should be highly motivated, disciplined, organized, and as ego-less as possible. The SL will need to be able to commit five weeks of his or her life to this process.
- The SL should be able to make global decisions for the mod. The SL should understand that this often requires cutting features and content in order to ship
Establish a build process
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.
Feature locking
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.
Playtesting
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."
Bugs and changes
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.
Cut or defer broken features
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?
Work smart, not hard
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.
Three weeks out
Content Locked
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.
Shutting down
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.
Playtesting
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.
One week out
No last minute changes
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.
Two day safe period
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!
Post-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!
See also
半衰期的开发过程中，设计中至少有30%的原始特性被删减，因为很明显它们在我们的时间线中无法实现。或者因为我们认为它们不值得他们花时间开发.正如我们上面所说，“质量胜于数量”。比起 10 个未经测试的地图，玩家更愿意拥有3个非常好的，经过良好游戏测试的地图，这将使您的模组在优质内容方面享有盛誉。不要让别人看到你做的东西很糟糕。
