Beta 测试游戏的技巧？
我们正在完成一款想要进行 Beta 测试的游戏。 我们没有时间和预算进行大规模测试，我们只是将游戏展示给我们的一些朋友。 （我希望我们仍然可以收集到一些有用的东西。）在《帝国时代》事后分析中（游戏开发者的事后分析）我发现了以下内容：
AOE 公测于 1997 年 8 月，但我们没有接近 充分发挥潜力 它。 我们已经接近结束了 可以玩任何游戏的项目 尽管有丰富的有用信息，但仍会发生变化 我们收到的反馈。 手册是 已经准备好印刷了，而且大部分 设计已经一成不变。 全部 我们真正能做的就是修复任何错误 已找到。
这是个好的观点。 还有其他好的建议吗？ 我们应该（不）提前告诉人们什么？ 我们应该寻找什么？
We are finishing a game that we would like to beta test. We don’t have the time nor the budget to do a large scale testing, we will simply show the game to some of our friends. (I hope that we can still gather something useful of it.) In the Age of Empires post mortem (Postmortems from Game Developer) I found the following:
A public beta test of AOE was held in
August 1997, but we didn’t come near
to exploiting the full potential of
it. We were too close to the end of
the project to make any game play
changes, despite the wealth of useful
feedback we received. Manuals were
already set to be printed, and most of
the design had been set in stone. All
we could really do was fix any bugs
that were found.
This is a good point. Are there any other good advices? What should (not) we tell the people beforehand? What should we look for?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
通过进行一些走廊测试，您可以快速了解有关游戏界面的事实； 随便找一些人，让他们试试游戏，然后看他们玩（你可以录制桌面，或者从后面录制玩家）。
正如 @AlbertoPL 所说，您可能需要找到一些专门的玩家，以获得有关
不要忘记安装易于使用的问题跟踪系统； 您可以使用它来跟踪缺陷、想法和一般反馈。 我推荐trac，因为它有一个wiki并且很容易使用。
关于建立社区的好建议@Midpoint。
You can discover quick facts about your game interface by doing some hallway testing; just find some random people, ask them to try the game, and watch them playing (you can record the desktop, or record the player from the back).
As @AlbertoPL said, you may want to find some dedicated players, for advanced feedback on
Don't forget to have an issue tracking system installed and easy to use; you can use it to track defects, ideas, and general feedback. I recommend trac, because it has a wiki and it's easy to use.
Great tips @Midpoint for setting up a community.
当然，你需要超越朋友。 只与朋友一起测试的问题是他们会希望你成功，从而告诉你这很好。 （我的意思是看看所有鼓励参加《美国偶像》的人大声喊叫！）
如果你能进行某种私人测试，那将是理想的。 因为你没有任何大规模的预算，所以它必须这样做。 如果你能获得足够多的人口，你应该能够得到比仅仅从朋友那里更好的反馈。 我不会太担心人口统计的多样化，但肯定会瞄准那些实际上对你的游戏所属类型感兴趣的人（我将根据你所展示的示例假设 RTS）。
Certainly you need to go beyond friends. The problem with only testing with friends is that they'll want you to succeed, and thus tell you it's good. (I mean look at all the people encouraged to try out for American Idol for crying out loud!)
If you can get some sort of private beta going, that would be ideal. Because you do not have the budget for anything large scale, it will have to do. If you can get a decent enough population you should be able to get better feedback than from just friends. I wouldn't worry too much about diversifying the demographics, but certainly target people who would actually be interested in whatever sort of genre your game is in (I'm going to assume RTS based on the example you've shown).
我的建议是建立一个在某处设置论坛的网站，以便公众可以申请测试版访问权限并能够向您提供反馈。 在某些时候，您可能还希望有人定期在论坛中查找错误报告并阅读一般反馈。 错误报告可以添加到错误跟踪数据库中，以便您可以处理社区提出的问题，并且可以使用一般反馈向团队其他成员提供定期报告，因为并非每个人都有时间阅读每一篇文章。
一旦建立了社区并制定了收集反馈的流程，您就应该开始考虑您想要实际测试的内容。
如果您不确定特定的游戏区域，请直接向社区询问这些区域的信息。 如果您希望测试网络代码或服务器的可扩展性，请组织定期测试之夜（但不超过 1-2 小时）并执行一组特定的任务。 这将在第二天产生大量反馈，但您会发现它主要集中在您要求人们测试的领域，从而省去了将其随机散布在论坛中的麻烦。
一般来说，人们会希望帮助改进游戏，让社区尽早参与进来，不仅能让你在游戏完成后从玩游戏的人那里得到重要的反馈，还能让社区有一种主人翁意识。 这是他们的游戏，他们帮助让它变得更好。 您以某种方式与社区互动的越多，在有组织的测试方面您就能从他们那里得到越多的东西。
My suggestions are to get a website with a forum set up somewhere so that members of the public can apply for beta access and are able to provide you with feedback. At some point, you'll probably also want someone to regularly trawl the forum for bug reports and read the general feed back. The bug reports can be added to a bug tacking database so that you have a handle on the issues being raised by the community and the general feedback can be used to provide a regular report to the rest of the team as not everyone will have time to read every single post.
Once you have a community built up and the processes in place for gathering feedback, you should start to think about what you want to actually test.
If you have specific game play areas you are unsure about, ask the community directly about those areas. If you are looking to test the network code or scalability of servers, organise regular test nights (no more than 1-2 hours though) with a specific set of tasks to perform. This will produce a ton of feedback the next day, but you'll find it mostly focused on the areas you asked people to test saving you the trouble of having it randomly scatter through the forums.
Generally, people will want to help improve the game and getting the community involved earlier will not only get you important feed back from the people who will be playing it when it's finished, but also gives the community a sense of ownership. It's their game and they've helped make it better. The more you can interact with the community in some way, the more you will get from them when it comes to organised tests.
您可能想阅读这篇有关 他们为光环 3 所做的测试的文章。 我知道您没有这样的预算，但它可能会激发一些想法或替代方式来看待您的游戏。 我发现有趣的一点是记录击杀/玩家死亡以及在地图某些区域花费的时间，这样他们就知道人们被困在哪里，或者地图在任何团队游戏中是否存在偏见。
You might like to read this Wired article about the testing they did for Halo 3. I know you don't have that kind of budget but it might inspire a few ideas or alternative ways to look at your game. One bit I found interesting was the logging of kills/player deaths and time spent in certain areas of the maps so they knew about where people got stuck or if a map was biased in any team play.
一个非常重要的方面是，您应该实际上观察人们玩游戏，了解他们真正在做什么，而不是事后才询问他们对游戏的看法。
这将使您更好地了解他们存在问题的地方，即真正的学习曲线（这通常不是人们自己注意到的）以及应该在教程中更容易地明确教授什么。 它还会向您显示用户界面中的问题，当人们找到解决方法时可能不会报告这些问题； 他们只是记得用户界面不方便。
我目前还参与了游戏测试（一款跳跃和奔跑游戏），一个有趣的轶事是，那些玩电脑游戏经验很少的测试人员没有意识到角色在跌倒时可以侧向移动。 有趣的是，一些测试者实际上在陷入致命情况时确实移动了角色，并且经常避免以这种方式死亡 - 但当需要到达某个地方并直接跌落时，却没有有意识地记住该能力不会导致死亡。
结论是，在游戏早期需要出现一种情况，绝对明显的是，继续下去的唯一方法是在跌倒时移动，在这种情况下，直接跌倒不会造成伤害。
One very important aspect is that you should actually watch people play to see what they're really doing, rather than just asking them afterwards what they think about the game.
This will give you a much better idea of where they have problems, i.e. the real learning curve (which is often not something people notice themselves) and what should be made easier ot taught explicitly in a tutorial. It will also show you problems in the user interface, which people may not report when tey've found a workaround; they just remember the UI to be inconvenient.
I'm currently also involved in game testing (a jump'n run game) and an intersting anecdote is that testers who had very little experience playing computer games didn't realize that the character could move sideways while falling. The funny thing is that some testers actually did move the character when falling into deadly situations and often avoided dying that way - but then did not consciously remember that ability when it was required to get somewhere and falling straight down would not result in dying.
The conclusion was that there needed to be a situation early in the game where it was absolutely obvious that the only way to continue was to move while falling, in a situation where falling straight down was not harmful.
让广泛的人来测试你的游戏。 有些人认为显而易见的事情对其他人来说并不明显。
此外，招募家人和朋友，以及那些没有动机说“你的游戏太棒了！”的人。 不管他们实际上怎么想。
Get a wide range of people to test your game. Things that some find obvious are not close to apparent for others.
Also, recruit family members and friends, as well as people with no motive to say "your game rocks!" no matter what they actually think.