作者：Daniel Cook

许多游戏都带有战利品。通常情况下这些战利品的分配都是随机的。战利品掉落是特别常见的主题，但却也是每个设计师经常会觉得头疼的内容。以下是我在过去几年所遇到的最佳实践。

你的基本战利品表

这里的目标是为了基于特定几率掉落一组道具。假设当你打败一个敌人，你便有机会获得盾牌，稀有的剑，或者什么都没有。

例子

战利品表

道具：

名字：剑

重量：10

道具：

名字：盾

重量：40

道具:

名字：空

重量：50

设置

道具：你想要提供给玩家的一种道具。

战利品表：将一组道具放进战利品表中。这只是一部分道具。例如一个战利品表将包括：剑，盾，空。

重量：每个道具都带有掉落重量：从1到10000。例如一把剑的掉落率可能是10。

空道具：战利品表中会有一个道具是“空”，这意味着如果滚动到它，便不会掉落任何战利品。

滚动战利品

总概率：首先，计算战利品表中的所有重量。在上述例子中便是10+40+50=100。因为这些数值并不是百分比，所以它们并不需要加到100。

接下来分配每个道具的范围。剑=1至10，盾=11至50，空=51至100。

从1至100生成一个随机数。

将该数值与范围进行比较。这便能够决定到底会掉落哪种道具。

再次滚动：生成多个随机数值去模拟多次滚动。

所以玩家会如何看待它们？我们设置剑的掉落几率为10%，盾的掉落几率为40%，而什么都不会掉落的几率为50%。

作为设计师，我可以将空的重量改为100，而现在我将剑的掉落几率设为6.6%（10/150），盾的掉落几率为26%（40/150），什么都不会掉落的几率为66%（100/150）。

映射到其它常见的随机系统

这一系统只是在重申许多其它相似的随机性方法。这是训练你的设计师大脑在基于战利品表，纸牌或筛子上理解任何随机性问题间转换的有趣方法。

纸牌

想象你能够洗牌并获取的桥牌。

桥牌上的每种纸牌类型都是一种道具。

特定类型的纸牌数量便是道具的重量。

洗牌等同于为每种道具分配范围并生成随机数。

抽取纸牌等同于选择掉落的道具。

现在常见的桥牌都拥有52张牌，但如果是基于战利品表，你便可以不受约束地进行操作。你的桥牌拥有1000张各种类型的纸牌。或者它们可以提供与典型的扑克手所拥有的较小的桥牌。

筛子

筛子同样也能够映射到战利品表上。

每一个独立的筛子都是一张战利品表。

筛子的每一面（1至N）便等同于道具。

筛子的每一面都拥有重量“1”（除非你是在使用超重的筛子！）。

多次滚动筛子代表多次滚动同一个战利品表。所以2D6便等同于抽取一个带有6种道具的战利品表2次。

变量

既然我们定义了一个基本的战利品表，我们还可以做些什么？

变量：道具组合

你同样也可以掉落战利品组合。道具并不需要一定是单一的内容。例如我可以扩展它从而让玩家同时获得一个盾牌和一个生命药剂。

例子

战利品表

道具：

名字：剑

重量：10

道具：

名字：盾

名字：生命药剂 数值：2

重量：40

道具：

名字：空

重量：50

变量：总是掉落

常见的需求是标记一个道具从而提升它的掉落频率。这里存在一种惯例，即带有“-1”重量的道具将会更常掉落。

变量：可重复的随机性

有时候你会希望能够重复一个随机滚动。例如当一名玩家保存了游戏，并能在之后重新加载以避免糟糕的战利品掉落结果，这将导致非常折腾的玩家行为。而如果存在一种方法能够避免这种情况，所有玩家都会很高兴吧。

大多数临时的伪随机数生成程序都是使用一个种子值。只要你能够保存该种子值，你便能够再次运行随机数生成程序并获得同意的结果。

变量：无需改变而滚动

上述系统的问题在于玩家可能会一直滚到“空”。这也是玩家常常抱怨的结果。就像“我玩了3000多次却从未获得MegaGoldenLootGun！”。

在统计学中存在两种基本的抽样类型：

放回抽样：你将从列表中抽取数值然后在记录你所获得的数值后，你会将它们放回去。如此你便有可能在下次抽取时拥有同样的几率。

不放回抽样：你将从列表中抽取数值，并且在你记录之后便将其置于一边。如此你在下次抽取时抽到该道具的几率便会下降，而抽到剩下道具的几率便会增加。

《俄罗斯方块》便使用了不放回抽样。每种俄罗斯方块都有自己的战利品表。每次你获得一个特殊组块时，它便会被移出列表。这种方法能够保证你在长时间等待长方形组块时将能获得它。

以下是关于你在战利品表中如何执行不放回滚动。

当你滚动一个道具时，将其的重量减少1。这也等同于将它的范围和最大范围减去1。

确保在玩家下次滚动时他们的战利品表已经进行了修改。

变量：保证特殊的掉落道具

有时候不放回滚动不够快，而你却希望保证战利品的掉落。暴雪便保证了特定稀有道具的掉落从而让玩家无需长时间地刷道具。

你可以只是提升重量，但是随着玩家多次玩游戏，他们会感受到获得某些有保证的道具的低频率与获得一种道具慢慢提升的几率之间的明确区别。

以下是关于如何执行有保证的掉落战利品。

当你滚动任何无保证的道具时，减少X%无保证的道具重量。

X=100/在有保证的道具掉落前滚动的最大数量。

确保在玩家下次滚动时他们的战利品表已经进行了修改。

例子

假设你想要在5个回合后剑能够频繁掉落，尽管它只拥有10%的掉落几率。

如此X=100/5或20%

所以每次当你滚到剑时，盾的重量便会下降8（40*0.2），而空的重量会下降10（50*0.2）。

在5个回合后，所有其它道具的重量将变成0，剑便会拥有100%的掉落几率。

变量：分等级的战利品表

战利品表通常都是新资源的来源。然而你很容易进入一种情境，即你掉落了太多或太少特殊资源。这时候一些限制将很有帮助。

一种解决方法便是使用不放回的分等级的战利品表。当一种特殊资源用尽时，玩家将不再获得该资源。我们在每日货币奖励中便使用了这一方法。我们想要每天派发100个货币，并且不会超过这一数值。但是我们也想将其作为战利品系统的一部分。

创造两个表：奖励和每日货币。

让主要的战利品表参照每日货币表。

当选择每日货币时，滚动列表并明确你获得了多少货币。

例子

战力品表：奖励

道具：

名字：剑

重量：10

道具：

名字：每日货币

重量：40

道具：

名字：空

重量：50

战利品表：每日货币

类型：不放回

更新率：每日

道具：

名字：货币，数值：1

重量：10

道具：

名字：货币，数值：10

重量：4

道具：

名字：货币，数值：50

重量：1

在上述例子中，玩家有40%的机会获得货币。然后我们将滚动每日货币表并看看它们是否能够基于10次奖励每次1个货币，4次奖励每次10个货币以及1次奖励每次50个货币而在一天中获得最多的100个货币。

当每日货币战利品表空了时，它们只有在隔天更新时才会再次被填满。

变量：有条件的掉落

有时候你会想要测试是否应该基于一些外部变量去掉落道具。在《 Realm of the Mad God》中，我们便想要避免未创造任何伤害而杀死boss的“搭便车者”获得战利品。所以在战利品表中，我们添加了检查。如果滚动到战利品表中的一种有价值的道具，我们便会检查玩家对敌人所造成的伤害是否超过X%。

你可以基于玩家的级别或敌人的级别改变战利品的有效性。就像我更倾向于使用多个较小的战利品表，并且系统非常灵活，足以让你能够轻松地使用一些较大的列表和条件去创造数据。

变量：编辑器

你可以基于以下外部逻辑修改掉落物的数量或重量。例如擅长收集的玩家能够获得比不擅长收集的玩家2倍多的特殊掉落道具。或者你可以修改重量。较高级别的角色的所有道具可能拥有-50%的重量，这远低于他们的级别。

其它使用

掉落物列表通常是用于掉落战利品，但我们也可以在其它地方发现它们。

程序生成：使用列表去创造武器或角色。

AI：使用列表去选择行为，如攻击或移动。

这可能有点愚蠢，但的确存在一些更好的方式去创造AI！一种方式便是将随机性当成任何系统的一阶模型。人类大脑是如何创造系统模型？我们为系统创造了观察报告。并注意到这些观察值重复出现的频率和趋势。在之后我们开始理解“为什么”会发生某些情况以及每个部分之间的临时关系。

在物理学中，我们经常会开玩笑地说，为了创造一只奶牛模型，即一个复杂的有机体，我们需要做的第一步便是“想象一只球形的奶牛。”通过创造一个简单的模型，我们便能够以最低成本生成有用的见解。

很多时候，掉落表其实就是一个复杂系统的以人类为中心的近似值。对于许多系统，大多数玩家的移动都不会超过一个基本的概率理解，所以创造更复杂的模型只会浪费时间。有效的游戏设计是创造模型去最小化必要级别以创造出理想的游戏体验。

考虑：《龙与地下城》便基于必要的战利品掉落表创造了完整的宇宙。这就是专注于最小化系统。

战利品掉落表并不是你需要的唯一工具，但在很多情况下，它却是一种很有效的工具。

程序生成思维实验

以下是使用掉落表的简单程序生成系统。存在许多其它方式能够做到这点，但这却是最需要你进行思考的方法。让我们假设你想要创造一个程序生成敌人。

一开始先创造独特的敌人列表。也许你的敌人是由移动类型，攻击类型，防御类型以及财宝类型所组成。

为每种类型创造战利品表。

基于强度提供给战利品表中的每种道具能量值。例如，刀的攻击可能较弱，那么它的能量值便是5。而较大的铁锤的能量值为15。

创造另一个战利品表。这是各种属性的修改内容。例如，“强大”将为攻击增加20%的数值。你也可以将攻击设为“弱”，这将减少50%的数值。

现在让我们生成一个敌人

设定一个目标：为你的生成敌人设定一个目标能量。假设你想要一个拥有40能量值的敌人。

滚动：滚动每个部分并将其添加到列表上。

分数：添加所有的能量值去获得一个分数。

调整：如果这些部分的总和超过目标值，那就为较低的能量部分添加一个攻击或滚动。如果总和低于目标值，那就为较高的能量部分添加一个攻击或滚动。

重复：重复这一过程直到你到达一个预期的错误门槛（远离能量40）或者你耗尽了你想要消耗的迭代数。

现在你便拥有一个程序生成敌人。对于这一基本系统你可以进行多次调整，但它大多数情况下都是有用的。作为练习，你可以想想：

排除列表：如果选择了列表中的两个部分，那就丢掉敌人再次滚动。

多重限制：基于多个标准进行评判的部分。需要注意的是，当你添加更多限制时，你便更加不可能聚集多重结果。

结论

任何时候都会出现关于随机性的讨论，并且也有许多次要问题会发挥作用。我建议你们能够阅读以下内容：

http://www.lostgarden.com/2012/12/understanding-randomness-in-terms-of.html

http://www.lostgarden.com/2012/12/understanding-randomness-in-terms-of.html

抵抗教条式的随机性。作为一个受过良好教育的设计师，你的美学选择应该是基于亲手实践。这里存在的一个经验法则便是，在你成功使用一种设计工具创造出一些成功游戏之前，你不能轻易批评这种设计工具。

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

Loot drop best practices

by Daniel Cook

Many games have loot. Usually this drops randomly. Loot drops are a pretty mundane topic, but one that almost every designer runs into at some point. Here are some best practices I’ve encountered over the years. Many thanks to everyone who contributed to these tips and tricks.

Your basic loot table

The goal is to drop some set of items at a given probability. Let’s say when you defeat an enemy, you have a chance of getting shield, a rare sword or nothing at all.

Example

lootTable
item:
name: sword
weight: 10
item:
name: shield
weight: 40
item:
name: null
weight: 50

Setup

Item: An item is something you want give the player.

Loot Table: A set of items is put into a loot table. This is just a bucket of items. For example a loot table might include: Sword, Shield, Null.

Weight: An item has a drop weight: 1 to 10,000. For example a sword might have a drop rate of 10.

Null items: One of the items in the loot bucket is ‘null’ which means if that is rolled, no loot is given

Rolling for loot

Total probability: First, sum all the weights in the bucket. In the example above, that’s 10+40+50 = 100. They don’t need to add up to 100 since these aren’t percentages.

Next assign each item a range. Sword = 1-10, Shield = 11 to 50, Null = 51 to 100

Generate a random number from 1 to 100.

Compare that number to the ranges. That’s the item that drops.

Reroll: Generate multiple random numbers to simulate multiple rolls.

So what does this look like to the player? We’ve got a 10% chance of dropping a sword, a 40% chance of dropping a shield and a 50% chance of getting nothing.

As the designer, I could go in and change Null’s weight to 100 and now I’ve got a 6.6% (10/150) chance of dropping a sword, a 26% (40/150) chance off dropping a shield and a 66% (100/150) chance of dropping nothing.

Mapping onto other common random systems

This system is a simple restating of many other familiar methods of randomness. It is a fun superpower to train your designer brain to be able to switch between understanding any randomness issue in terms of loot tables, cards or dice.

Cards

Imagine deck of cards that you can shuffle and draw from.

Each type of card in the deck is an item.

The number of cards of a given type is that item’s weight

Shuffling the deck is equivalent to assigning each item to a range and generating a random number.

Drawing a card is the equivalent of selecting the item that drops.

Now a normal deck of cards has 52 cards, but with loot tables, you don’t need to operate with that constraint. Your decks could have 1000′s of cards and a vast array of types. Or they could have tiny decks that are the equivalent of a typical poker hand.

Dice

Dice also map onto loot tables.

Each individual dice is a loot table.

The sides (1-N) are items (labeled 1 through N)

Each side gets a weight of ‘1’. (Unless you are using weighted dice!)

Multiple dice can be represented as rolling the same loot table multiple times. So 2D6 is the equivalent of sampling a 6 item loot table twice.

Variations

Now that we’ve defined a basic loot table, what else can we do with it?

Variation: Items sets

You can also drops sets of loot. An item doesn’t need to be a single thing. For example, I could extend it so that the players gets a shield and a health potion if that option is selected.

Example

lootTable

item:
name: sword
weight: 10
item:
name: shield
name: healthPotion number: 2
weight: 40
item:
name: null
weight: 50

Variation: Always drop

A common need is to flag an item so it always drops. One convention is that items with weight ‘-1′ always drop.

Variation: Repeatable randomness

Sometimes you want to be able to repeat a random roll. For example, when a player saves a game and then is able to reload to avoid a bad loot drop, it can lead to very grindy player behavior. If there is an exploit that ruins the game for them, most will happily go for it.

Most contemporary pseudo random number generators use a seed value. As long as you can save that seed value, you can run the random number generator again and get the same result.

Variation: Rolling without replacement

The problem with the system above is that players may, through chance alone, always roll ‘null’. This is a common complaint by players. “I played that encounter 3000 times and never got the MegaGoldenLootGun!” This can happen.

In statistics, there are two fundamental types of sampling:

Sampling with replacement: You pull the numbers out of the bucket and then after you’ve recorded what you got, you put them back in. So you have the same chance of getting the same thing again in the next draw.

Sampling without replacement: You pull the item out of the bucket and once you’ve recorded it, you set it aside. You have a lower chance of getting that item again and thus a higher chance of getting the remaining items.

Tetris uses sampling without replacement. Each set of Tetris pieces is in a loot table. Every time you get a specific piece, it is removed from the bucket. That way they guarantee that you’ll always get a long piece if you wait long enough.

Here’s how you implement rolling without replacement in a loot table.

When you roll an item, reduce its weight by 1. This shorten its range by 1 and shortens the max range by 1 as well.

Keep the player’s modified loot table around for the next time you roll.

Variation: Guaranteeing specific drops

Sometimes even rolling without replacement isn’t fast enough and you want to guarantee a loot drop. Blizzard does this for certain rare drops so that players don’t grind for very long times.

You could just increase the weight, but a low chance of getting something with a guarantee can feel very different over multiple plays than a slowly increasing chance of getting an item.

Here’s how you implement guaranteed loot drops.

When you roll any non-guaranteed item, reduce all non-guaranteed items weight by X%

X = 100 / Max number of rolls you before the guaranteed items drop.

Keep the player’s modified loot table around for the next time you roll.

Example

Suppose you want the sword to always drop after 5 turns even though it it only has a 10% chance of dropping.

So X = 100 / 5 or 20%.

So every time you don’t roll the Sword, the weight for the Shield drops 8 (40*0.2) and the weight for null drops 10 (50*0.2)

After 5 turns, the weight for all the other items will be 0 and the sword will have a 100% chance of dropping.

Variation: Hierarchical loot tables

Loot tables are generally source for new resources. However, you can easily run into situations where you are dropping too much or too little of a particular resource. Some sort of constraints would be helpful.

One solution is to use hierarchical loot tables without replacement. When a particular resource runs out, the player doesn’t get any more. We’ve used this for our daily coin awards. We want to give out 100 coins a day, but no more. But we want to do it as part of the loot system.

Create two tables: Rewards and DailyCoins.

Have the main loot table reference the Daily Coins bucket.

When Daily Coins get picked, roll that table and see how many coins you get.

Example

lootTable: Rewards
item:
name: sword
weight: 10
item:
name: dailyCoins
weight: 40
item:
name: null
weight: 50
lootTable: dailyCoins
type: noReplacement
refreshRate: Daily
item:
name: coin, number: 1
weight: 10
item:
name: coin, number 10
weight: 4
item:
name: coin, number: 50
weight: 1

In the example above, a player has a 40% chance of getting coins. Then we roll the dailyCoins table and see that they can win a maximum of 100 coins a day with 10 awards of 1 coins, 4 awards of 10 coins and 1 award of 50 coins.

When the dailyCoins loot table is emptied, they’ll get nothing until it refreshes after a day.

Variation: Conditional drops

Sometimes you want to test if you should drop the items base off some external variable. In Realm of the Mad God, we wanted to avoid free riders getting loot for a boss kill without doing at least some damage. So in the loot table, we added a check. If a valuable item in the loot table was rolled, then we’d check to see if the player had done more than X% of damage to the enemy.

You could also build in switches for which loot is valid based off player level or even enemy level. I tend to instead use multiple smaller loot tables, but the system is flexible enough that you can easily architect your data with a few large tables and use of conditionals.

Variation: Modifiers

You can also modify the quantity or weight of a drop based off some external logic. For example, a player with a skill in harvesting could yield 2x as many of a particular item drop compared to a player without that skill. Or you could modify the weight. A high level character might have a -50% weight for all items marked lower than their level.

Other uses

Drop tables are commonly used for dropping loot. But I also find them useful in other areas.

Procedural generation: Use a table to build weapons or characters from components

AI: Use a table to select behaviors such as attacks or moves.

This may seem a little silly..surely there are better ways to model AI! However, one way to think about randomness is that it is a very rough first order model of any system. How does the human brain model a system? We make an observation about a system. We note the frequencies and tendencies for those observations to reoccur. It is only much, much later that we start to understand ‘why’ something happens or the causal relationship between parts.

In physics, we often joke that in order to model a cow, a complex biological organism, the first step is to ‘imagine a spherical cow’. By creating a simplistic, easy to work with model, we can often generate useful insights at a very low cost.

Many times, a drop table is a ‘good enough’ human-centric approximation of a complex system. For many systems, most players will never move beyond a basic probabilistic understanding so modeling more complexity is a waste of time. Efficient game design is an exercise in modeling elements only to the minimum level necessary to create the desired experience.

Consider: D&D modeled entire universes with what were essentially loot drop tables. That was a deliberate focus on minimizing systems that were in many ways just secondary flavoring to the core roleplaying.

A loot drop table isn’t the only tool you need, but in many scenarios, it is good enough.

Procedural generation thought experiment

Here’s a simple procedural generation system using drop tables. There are lots of other ways to do this, but this is more to get your brain thinking. Let’s say you want to build a procedurally generated enemy

Start by making a list of unique enemy parts. Maybe your enemy is made up of a type of movement, a type of attack, a defensive buff and a type of treasure.

Make loot tables for each one of those parts.

For each item in the loot table, give it a power value based off how powerful you think it might be. for example, a knife attack might be weak so it only has a power of 5. But a large hammer attack might have a power of 15.

Create another loot table of buffs. These are modifiers to various attributes. For example, ‘Strong’ boost a value on an attack by 20%. You can have debuffs as well ‘Weak’ might diminish a value by -50%. These have reduce the power value of a part.

Now let’s generate an enemy

Set a target: Set a target power for your generated enemy. Say you want an enemy of power 40

Roll: Roll each of the parts once and add them into a list.

Score: Add up all the power values to get a score.

Adjust: If the sum of the parts is over the target, add a debuff or roll for a lower power part. If it is under, add a buff or roll for a higher power part.

Repeat: Repeat this process until you hit a desired error threshold (distance from power 40) or you’ve exhausted the number of iterations you are willing to spend.

You now have a procedurally generated enemy. There are tons of tweaks you can do to this basic system, but it works most of the time. As an exercise, think about:

Exclusion lists: If two parts are picked that are on the list, throw the enemy away and reroll.

Multiple constraints: Parts are scored on multiple criteria. Note, the more constraints you add, the less likely you are to converge on a viable result.

Conclusion

Any time there’s a discussion of randomness, there’s a huge number of secondary issues that come into play. I recommend the following for further reading:

Understanding randomness in terms of mastery: http://www.lostgarden.com/2012/12/understanding-randomness-in-terms-of.html

Richard Garfield on Luck: https://www.youtube.com/watch?v=av5Hf7uOu-o

Resist being dogmatic about randomness. Be a broadly educated designer whose aesthetic choices are based on hands on experimentation. A good rule of thumb is that you can’t intelligently critique a design tool until you’ve made a couple games that use it successfully.

Anyway, this is just how I’ve done loot tables; a mundane part of any working designer’s life. I’m curious if other folks have other ways of managing loot (and randomness) that they love and live by.

take care,
Danc.(source:gamasutra)