我是测试玩家公司的员工（意味着我负责管理测试和自己进行测试）。经过~50次测试跨越不同的项目，我想分享一些实际上可能会有帮助的东西。要开始，总是会有一个事实：那些“一切都工作正常”的测试会教会我几乎没有什么东西。那些东西崩溃的测试才是真正推动设计进步的。 我看到了很多第一次进入游戏开发领域的开发者会将测试视为验证：“这是否有趣？”“这是否按照预期工作？”但那不是这项工作的任务。早期测试的目的就是测试你的假设。 如果没有什么出错，你很可能没有将系统推到极限，如果玩家无法打破你的游戏，我认为他们并没有真正测试它。那么我在实践中真正意味着什么“打破它”？ 玩家完全忽略的机制玩家不问就误解的规则永远不会出现或完全主导的能力绕过你试图测试的系统的场景 这就是我所说的信号，而不是人们是否说他们有趣。还有一个事实：玩家不会按照你期望的方式行为。绝不会。 我见过团队完全忽略核心机制，只因为它不是很明显。没有抱怨或困惑，他们只是从来没有触摸过它。 我也见过玩家建造了完全符合他们理解的角色，但却完全轻视或破坏了我准备的场景。 我还见过相反的情况：玩家想使用某个能力，但游戏从来没有给他们一个真正的机会。 还有那句老话：当每个人都按照预期玩的时候，游戏看起来很平衡……然后一旦有人不按照预期玩，游戏就会崩溃。 给玩家自由突然支持能力就成了最佳伤害路径，或者一个选项就默默地超过了其他一切。 我学到的是，你不通过引导玩法来捕捉这一点，而是通过让事情脱离轨道。几个实用的技巧帮助我作为测试玩家提供更好的信号，而我希望更多的设计师在将我安排到桌子上之前就设置好：

测试之前 1.测试你的机制在孤立中，在将它们混合在一起之前。只运行数字，模拟回合，故意打破它们。你会在早期捕捉到明显的问题。（奖励：如果你同时测试三个未测试的系统，某个系统崩溃时，你不知道哪一个系统引起了它。） 2.准备一个简单的场景，实际上会强迫你想要测试的机制。如果你在测试战斗，确保战斗发生得快，不要在最后 3.使用预生成的角色，如果你想获得干净的数据。角色创建会在你不测试的东西上添加很多噪音。 4.如果你的系统有任何复杂性，请制作一个短的速查表。如果我需要在测试期间解释所有内容，我就无法展示它实际上失败的地方。

测试期间 1.听起来很明显，但要明确你正在测试什么，而不是过多地解释如何使用它。 2.让我们做出决定，即使它们看起来是错误的。这通常是有用的数据的地方。 3.然后记录实际发生的事情： * 使用的内容 * 被忽略的内容 * 游戏的速度 * 玩家困惑或犹豫的地方 4.注意不匹配的内容。也就是说，如果我们建造了不符合你的场景的角色，这并不总是我们的责任。

测试之后 1.首先开始开放式反应，然后问具体问题。 2.不要依赖我们解释，因为我们擅长告诉你我们感觉到了，而不是为什么我们感觉到了。我们还很糟糕地预测我们会喜欢什么，所以请小心。 3.比较我们说的话与我们做的。这个差距往往是真正问题的所在地。 4.一旦你有了需要修复的问题，优先级就很重要。不是所有的破坏都同等重要的。有些问题是根本的，另一些是来自一个不寻常的群体的噪音。

提示 朋友在早期很好，但他们知道你，并且会不自觉地帮助你的游戏成功，而陌生人不会有一点，让别人运行你的游戏，而你只是观察。这很不舒服，但非常有用*最终，尝试“盲目”的测试，完全没有你的存在。你可以通过Reddit和Discord的社区，或者通过像PlaytestCloud或Play2Review这样的平台来找到玩家，如果你想要更结构化的反馈。测试频繁，不要害怕运行混乱的测试。如果你的游戏能经受住那样的测试，那么你就成功了。如果它不能，那么你就早早发现了。