作者：EvilKimau

有时候我们会遇到需要在无法测试的前提下设计游戏的情况。例如，设计一个系统，让1万名玩家在一个带有前进机制的持续竞争世界中花费3个多月的时间进行异步互动。

force map(from flickr)

规则1：尽量保持灵活性

你的工具链和装备必须有助于快速进行编辑，甚至是批量编辑。我非常推荐Python（游戏邦注：一种面向对象、直译式计算机程序设计语言）或Lua，它们能够帮助你更有效地编辑数据和常数。如果你拥有编辑滑动器或者快速可视化HUD就更好了。

确保能够通过数据获得任何可能的内容，最简单的内容是一些幻数，基本的行为和条件等。

确保任何内容都能够明确地用数据表现出来。举个例子来说，如果你早期的游戏设计状态，如“武器威力”与能够通过数学方程式表现出来的月球关卡和玩家关卡相呼应，那么请不要将这些方程式用代码的形式表现出来。反倒是你的数据必须包含方程式。这么做有很多原因，最普遍的便是你能够从中发现哪个关卡失去了平衡。然后你便能够无需改变复杂的方程式（作为一种基础）而调整任何关卡了。

同时你还需要确保你的数据足够有活力，能够在两个版本之间相互转换，并在数据结构发生改变后仍然有效。而有时候当某些数据不能够发生转换时你也应该适时放弃它们，不过这只能作为最后一招来用。

规则2：创建模型

创建数学模型就像是组织一个非常复杂的系统，如人口增长或者人体血液中的氧化作用。通过监视输入，输出以及其它变量控制。我们能够创建一个可理解的系统。

我知道，这些听起来似乎很夸张，并且这的确是一个非常复杂的过程，但是即使是非常有限的理解也能够帮助我们收获巨大的回报。例如在行动类MMO中安置一种武器。这种武器拥有100个不同的数据，我们可以从两个方面表达10个等级中的1个，即速度和破坏性，而我们要测量的是杀戮/死亡比率。我们可以通过所收集的数据进行复原。尽管需要投入更多的努力，但是我们可以用杀戮/死亡比率为范例创造2D飞机的模型。你所创造的模型越完整，你便能够从中了解到越多信息。

始终牢记，无论如何，实践与理论总是存在区别。

我实在无法形容模型在大规模设计框架中的重要性。假设你拥有一个复杂的模型，如果你可以使用Python创建一个简单的模型代表或者创造一个能够实时调整的模型便再好不过了。通过一些简单的图形，你可以快速地判断行动效能，如在早期任务中设置一大笔金币是否有效，是否能够将其安插到游戏系统中。

我建议所有的设计师都去看看关于这个话题的书籍，如果感到疑惑可以咨询程序设计部或财务部人员。这点听起来虽然很奇怪，但他们当中会有一些拥有相关背景知识的人，能够帮助你创建基本的模型。

规则3：衡量所有内容

当然了，以上提到的所有内容如果不经过衡量便不再有意义。任何内容都有一个基准点。你必须动用自己的分析细胞快速获得系统或其它有关理论和感觉的详细数据。劣等的数据将直接导致游戏失败。

这里就会产生一个亚规则，即当你在处理一些大型系统时并不能够按直觉办事。你的常识是以原始的即时反馈为基础。当然了，获得一些直白的反馈再好不过了，但是如果你常常需要面临大量的数学系统，你便很容易被绕进难以走出的谜圈中。

即使你已经明确了某些内容，你也需要去衡量并证实它。如此你便能够满怀信心地判断一个简单的事物是否合理。随后，当一个复杂的系统突如其然地出现时你也不需要浪费多余的时间，因为基本的假设很可能是错的。

规则4：速度和自动控制

在复杂系统中，时间跳跃或加速游戏时间的作用不容忽视。

但是前提是你必须确保能够为渲染解耦。

尽量在较低的程度调整时间的跳跃或加速。

可以考虑一个月进行一次delta管理。我知道这听起来很疯狂，但是值得一试。如果你的浮点数被打破了，一些数字超值了，某些代码出错了，那就真的糟糕了。虽然有时候这种方法很有效，但是你必须先明确最大的时间度，并确保自己在整个过程中不会超越这个范围。如此也能够帮助我们确保这个估值的安全性。

与AI程序设计员商量；获得一个有序的代码估值：一个随机的bot，一个非自我毁灭型的bot，一个愚蠢的bot，一个合理的bot，一个具有完美解决方法的bot。虽然最后一个bot听起来不大可能，但是事实上我们经常会提到它。通常会有成千个随机bot，虽然其计算成本很高，但是却能够帮助我们起一个好头。它们能够帮助我们快速确定一些优势或者劣势。同时我们还需要牢记，最智能的bot往往在游戏改变时最容易破裂。

当游戏趋于稳定时，甚至是发行后，它就更加需要保持这些bot。它们将帮助你更好地验证预发布的候选版本，以防你在这个过程中引进一些不稳定或毁灭性问题。

规则5：接受失败

最后，你必须学会接受失败。更重要的是你必须明确失败的程度并且快速且有自信地调整游戏系统。

第一步是为游戏创建一系列明确的目标和门槛。并设置警报，当游戏越过门槛时响起警铃以示提醒。你能够越快解决这些问题，便越能够保持模型的稳定。

在未真正理解原因之前绝不要轻易调整任何数值！

这点仅停留在实验阶段，但是如果游戏已经上线，你便需要好好理解其数值的每个细微差别。你可以利用模型以及一些明确的文件说明内容帮助理解数值。即使是一张描写数值如何整合进系统中的粗劣图像也是非常有帮助的。

如果不了解这些内容，你可能将一直埋头制作一些错误的内容。

（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Designing for the Untestable

Sometimes you’re asked to design for the untestable scenario. For instance, design a system for 10,000 players to asynchrously interact in a persistent competitive world with progression mechanics that plays out over 3 months.

Disclaimer: The entire time you are reading this remember one basic truth or else everything else contained herein is useless.

Focus on second-to-second play first. Nail it. Move on to minute-to-minute, then session-to-session, then day-to-day, then month-to-month (and so on). If your second-to-second play doesn’t work, nothing else matters. Along these lines, if your day-to-day fails, no one will care about month-to-month, either.- Brenda Brathwaite

“force map (mission impossible?)” by Yish

1st Rule: Be as Flexible as possible

Your toolchain and setup should allow for the quickest possible editing as possible as well as bulk editing. I highly recommend integrating a Python or Lua console which allows live editing of data and constants. If you can get sliders for editing or fast visualisation HUDS then all the better.

Ensure that everything possible is loaded from data, the simple stuff like magic numbers to basic behaviours and conditions.

Everything should be in data explicitly. For instance if your original design states that the Weapon Strength is proportional to the phase of the moon and character level which can be expressed in a mathematical equation then DO NOT put the equation in code. Instead your data should contain the equation. There are several reasons for this the most common is when you discover a level is off balance. Then you can adjust level 22 without altering a complex equation which was used as the base-line.

Ensure that your data is robust enough to migrate between versions and survive minor alterations to the structure of the data. Sometimes you may need to throw away some data because it can’t be migrated but this should always be a last resort.

2nd Rule: Model It

Okay I lied, everything is testable but you need to be clever about it.

Mathematical modelling is a process by which we take massively complex systems like population growth or oxygenation in the human blood stream. By monitoring the inputs, outputs and some control variables we can build an understanding of a system.

I know this all sounds like really heady stuff and it is a complex field but even a limited understanding can reap massive rewards. For example take a weapon in an action MMO. Given a weapon that has 100 different stats we can express a rating out of 10 in two areas, Speed and Damage, and our measurement is Kill / Death ratio. We could start by building regression fit by some data we have gathered, thank you WolframAlpha. Though with a bit more effort we could model a 2D plane with K/D as the height which provides even more information. The richer the model the more you can learn.

Always remember the Lab is NOT the real world however.

I cannot strongly enough express the power of models in large scale designs for the broad strokes. Even better if you have a complex model you can create a simple representation of it using Python or similar to create a model which you can adjust in realtime. With simple visuals you can quickly see the potency of an action, such as rewarding a sum of gold in an early quest, can inject into the system.

I highly recommend all designers pick up a book on the subject and if lost ask your programming or financial department. I know that sounds strange but there are likely a few people there with the background to help you build a few basic models.

3rd Rule: Measure Everything

Of course all the above is useless without measurement. Everything is a datapoint. You must have the analytical muscle to get detailed data out of the system fast or else everything will always work from theory and feeling. Poor data will lead to instant failure.

Which leads to a sub-rule which is never trust your intuition when dealing with large scale systems. Your common sense is built on very primitive immediate feedback. It’s great for telling you if a tiger is about to eat you or a date is going well but when it comes to massive mathematical systems more often than not it will lead you down dead ends and false leads.

Even if you’re certain about something, measure it and confirm it. That way you know with confidence that the simple stuff is true. Then when a complex system throws a wobbly you won’t waste countless hours because a basic assumption was false.

4th Rule: Speed and Automata

The ability to time-jump or accelerate the game-time can be immensely useful in complex systems.

Ensure you can decouple rendering or else this is impossible. This is a basic, “Are your shoelaces tied?” question but it bears repeating.

Try making your time jump or acceleration as low level as possible. It should be as stupid and unaware of the game systems of possible.

Consider a delta of a month. I know it sounds crazy but try it. If your floating point math breaks, a number overflows, something clamps, or some code clamps or assumes a delta then that’s bad. Sometimes it can be helped, but then algorithmically (if possible) calculate the maximum time step and ensure you can’t overstep it. It’s also a good idea to pad this estimate to be safe.

Talk to your AI programmer; get an estimate for coding up in order: a random bot, a non-suicidal bot, a stupid bot, a reasonable bot, a perfect solution bot. The last one may not be possible but it usually is. Often a thousand random bots, while computationally expensive, are the best place to start. They will quickly identify edge cases or dead end scenarios. Bearing in mind that the smarter bots will be more prone to breaking when the game changes.

As the game becomes more stable it becomes more and more useful to have these bots around, even post launch. They will quickly let you thrash at a release candidate before letting it out in case you introduced an unstable equilibrium or exploding problem, bad designer no cookie!

5th Rule: Accept your Failure

After all this work you must accept you’re guaranteed to fail. What’s important is the size of the failure and how quickly and confidently you can adjust your system once it’s gone live.

First step is build a bunch of predicated milestones and thresholds for your game. Setup alerts so the moment the live game is drifting outside those thresholds warning bells go off. The sooner you can address them the less likely the model is to explode.

NEVER EVER ADJUST A VALUE WITHOUT UNDERSTANDING IT!!!

This is fine in the lab or experimentation phrase but once things are live and you’re working on a live game you need to understand every nuance of that value. Your models will help here along with clear documentation. It’s helpful to have a rough graph or visual for how the value will propagate out into the system.

Without this knowledge you could just be making things worse. Honestly this is where the true value of your understanding of the systems and numbers behind your impossible system come into play.

Conclusion

Well I hope this helps anyone who has been asked to design the untestable. I know I now have a notebook full of footnotes on the topic. It’s a complex and tricky thing todo. Remember though the first thing to consider is the second to second but then maybe you can look at the year to year.(source:FLAMMABLE PENGUINS BLOG)