Watch this video on how the “random” loot drops in the original Legend of Zelda were actually determined:
I found it very interesting. In my game projects, one of the more difficult areas of game design is getting the frequency of the loot drops to feel right.
Let’s look at the ways in which the loot drops in Zelda are not random.
- Loot drops happen because of an event, eg defeating an enemy. They don’t happen “randomly” for no apparent reason. This drives a feedback loop of “kill monster, get treasure”.
- Which type of item gets dropped is actually not random. However, it’s important for the drop to seem random to the player, so they never can be sure of what they’re going to get. This keeps them guessing and curious: “What will I get if I kill this monster? There’s only one way to find out; better kill it!” invites play much more than “Ho hum, here’s another [enemy]; I know they only drop [type], and I don’t need that right now, so I’ll just walk by it.”
- It does seem that certain types of enemies do drop certain types of loot a bit more often. For example, in the overworld Tektites seem to be pretty reliable about dropping rupees, and tend to yield a higher proportion of blue rupees that are worth 5. They do drop other things, bombs and hearts, and fairies, but it does seem like they will drop rupees a bit more than other types of enemies. There may be a similar relationship between other types of enemies and other types of loot. This gives certain areas of the map, where these types of enemies appear, have strategic value for “farming” a given type of resource.
- It would make sense that more challenging enemies might yield more/better loot, but I don’t notice this so much when I play LoZ. It seems that as you progress through the game, the difficulty of the monsters ramps up, matching your own power increase, but that the reward remains more or less constant. Still, in many games, there’s a directly relationship between challenge and reward.
- By connecting the frequency and type of loot dropped to a complex conditional based on the internal state of the game’s various counts, it’s possible to tune the difficulty of the game to a far more precise degree than could be done through purely random loot drops. For example, if the player is low on hearts, you could use that data to drive a slight increase in the amount of health drops, to make the game easier. Or, to make the game more challenging, you could make health drops rarer when you’re low. This can be tweaked so that “easier” areas of the game have the more generous/forgiving drop rate, while the harder areas have stingy/unforgiving drop rates.
Up until now, I have thought of loot drops as something based on completely random chance, not influenced by various factors being tracked in the game. I had played with various stochastic functions to create what felt like “right” odds to give the game the right “feel”, and wondered why simple random distribution never felt quite right.
But what is “right” is highly subjective, difficult to define, and requires extensive time spent playtesting in order to gauge “feel”. But now, I see a much more interesting potential in tying the frequency and/or item dropped to causal relationships to various stat counters. What’s great about tying the loot drops to in-game stats is that it allows you to directly apply mechanisms to balance the game, based on how the stats reflect the player’s performance, their progress in the game, and the amount of difficulty you want at that point in the game.
Exactly how to do this will still be very subjective, and require extensive play testing, of course, but it will be tune-able and in the control of the developer, rather than purely random chance. I am excited by the possibility of using the stats model to drive feedback loops which can help to govern the game’s challenge level, or to provide certain items when they are more likely to be needed, or just to make the loot drop frequencies seem a little more interesting and less totally random. It seems like a potentially much more elegant way of distributing items in the game.
2 CommentsAdd a Comment
Interesting. While the video doesn’t touch at all on the design implications of using this kind of lookup table, there are a few definite takeaways for designers.
Guaranteeing certain drops at certain times does mean tighter control over the player experience, in particular with pacing. If everything is totally random then you are going to get some occasional long runs (with Zelda that would mean something like getting 20 fairies in a row, or killing 1000 consecutive enemies without getting a single bomb drop), which in this case would be obviously detrimental. So this provides a way to modulate the randomness (particularly important for a game where the player relies on certain random drops, and the game would be literally impossible to finish if an unlucky player got no drops or only certain kinds of drops forever due to bad luck). Sid Meier touched on this in one of his GDC talks as well, about how players perceive randomness, and how in Civ they actually fiddle with the random generator (e.g. if you have a repeated 50/50 check and you fail the first time, maybe the second time it’s 60/40, the third time it’s 70/30, and so on until you succeed, because even if failing 6x in a row should happen 1 in 64 times with “true” odds, it’s not fun, and players will often misperceive it as the computer cheating or the random numbers being buggy). I could also see the application of this in games where there’s a lot of loot drops (MMOs, Action-RPGs, etc.) – sure, a random drop of epic loot should be rare, but at the same time you can appreciate the benefit to making it something like “generate a random number from 1 to 10000; when the player’s kill counter equals that number, drop epic loot, and after 10000 kills generate a new number for the next block of 10000 kills” as opposed to “each kill has a 1 in 10000 chance of dropping epic loot”.
Another interesting thing to me is the detective work that obsessed players were willing to do, even 20 years after the fact, to deconstruct the game’s core mechanics (I saw a similar analysis of the Pac Man AI on Gamasutra awhile ago). I’m actually quite surprised that for the amount of time they’ve spent playing the game and testing hypotheses through trial and error using a realtime RAM readout, apparently none of them bothered to just look at the ROM, convert it to assembly language, and read through the actual code to figure out what was going on definitively… particularly for a project like this, where the exact mechanics would actually be of not only historical interest, but also practical interest to today’s professional and student game designers.
Excellent points, Ian, and just what I was thinking.
I thought that it was interesting that the Zelda designers essentially take advantage of the player’s behavior as a pseudo-random number generator. Assuming the player is unaware of their role in causality, and plays rationally, it gives very good control over item drops, and also gives the designer opportunity to adjust the difficulty of the game dynamically by weighting more helpful drops more when the player’s situation is dire.