Tuesday, December 23, 2014

Top 5 design debates I ignored in 2014

Back in the 80’s and 90’s, when conversation about game design was first bubbling up out of our community of insecure practitioners, a few polarizing topics would arise again and again. You’ll recognize them:
  • The correct definition of ‘game’
  • Narrative vs Mechanics
  • Randomness vs Skill
  • The importance of realism
  • Casual vs Hardcore
Many were (and are) merely the irritated observations of game players picking at specific games. However, with a flip of the rhetorical switch, players become designers expressing a universal design truth. Opinions inevitably differ and thus positions harden in the absence of data. And it snowballs from there.

Thankfully, as a developer community, we've grown older. With time and the accumulation of thousands published games, experienced game makers have a lot more insight into how game design actually works. It turns out there’s plenty of room for nuance.

There’s also the growing maturity to ignore false dichotomies and worn out talking points. Honestly, we don’t have time any more. We should be making great games, not arguing ancient design politics.

In the spirit of becoming a forward looking designer, here are my top 5 design debates that I've ignored in 2014.

#1 The correct definition of 'Game'


I've seen a metric ton of definitions for game over the years and have dabbled in crafting them myself. Not a single one has been useful to me in my daily practice of making great games.

Why this discussion is outdated
Games are vast and varied. A single definition tends have one or more of the following issues:
  • Overly broad: The definition is unable to provide any direction or guidance.
  • Overly narrow: The definition eliminates useful tools and influences from other areas of systems, thought or art.
  • Overly convoluted: The definition is only useful to lawyers who care primarily about edge cases and not about getting things done.
Alternative discussions to have instead
I focus on finding and exploring useful design tools. I don’t need to care about the definition of ‘woodworking’ in order to be damned happy that hammers and nails exist. The same goes for games. I focus on scaffolding. And loot drop tables. And internal economies.

A useful goal is to find general tools that a smart designer can use to radically improve their work. Like any tool, they should to be applied in the proper context. So they are rarely universal or one-size fits all. And like a craft tool, they need to be applied with skill. They aren’t a pattern that you toss at a problem and get a fixed result.

Recommendation: Build your flexible design toolbox. Master those tools. Apply them where appropriate. Ignore pedants obsessed with defining ‘game’.

#2 Narrative vs mechanics


Science was once plagued by the idea that certain behavior derived entirely from genetics (nature) or entirely from environmental effects (nurture). This turned out to be a naive simplification of a vastly most intricate and interrelated system genetic predispositions, environmental triggers and feedback loops.

Narrative and mechanics have proven to be similarly intertwined.

Why this discussion is outdated
In the end, the human brain has neither a pure systemic understanding the world. Nor does it have a purely narrative understanding of the world. Memory, learning, emotional triggers, cause and effect all feed into how our brain adapts to environmental mechanics and then flow out again as a social response.

So the model suggested by the supposed conflict is simply broken. There is no ‘versus’.

There are many explanations for how this argument even arose. My favorite: A cocky tribe from old linear media clashed with an isolated tribe of game makers. They fought a stupid fight about authority and status that had almost nothing to do with making games. Meh.

Alternative discussions to have instead
A modern discussion could include:
  • What existing schemas are activated by my game?
  • How should we implement learning and scaffolding structures?
  • What is the impact of various forms of stimuli within game loops?
  • How should we tighten or loosen our systems of cause and effect?
  • What are systems of pacing?
  • What social role does narrative serve? How can we engineer human systems to encourage it?
Theories like Interaction Loops or Emotion Engineering integrate narrative and mechanics. In the process of banging our heads against building great interactive experiences, we've been forced to break down ‘narrative’ and ‘mechanics’ into atomic chunks and see how they fit in practice. Let’s discuss the rich synthesis of story, world building and mechanical techniques that thrives in interactive systems.

Recommendation: Consider how narrative emerges from existing mechanics. And consider how theme illuminates mechanics by activating existing mental schema. We need holistic, integrated models. Ignore antagonistic dichotomies.

#3 Randomness vs Skill


There’s been a sad resurgence of this 80’s wargamer rant. Randomness is obsessively derided as less masterful or strategic relative to pure skill games.

Why this discussion is outdated
Randomness is just another design tool. Used with skill, it yields some amazing games.
  • Random systems are rife with mastery. ‘Randomness’ can provide strong elements of mastery, in terms of learning distributions, managing options and adapting to new situations.
  • Games involve loops. Random outputs almost never occurs in isolation, but are part of an internal game economy. Randomness is often an essential tool for creating strategic variation and context.
  • There are different, equally valid playstyles. Not everyone is a rigidly intellectual young man who desires only mental-skill games that let them dominate others. Some play to relax, some to socialize, some for physical mastery, some to feel part of a shared purpose. Randomness can be a beneficial tool when designing for these players.
Alternate discussions
  • What games use randomness in interesting ways?
  • How does your game use randomness as skill?
  • How does randomness map onto noise?
  • What are other noise generators? Complexity noise, social noise, feedback noise, etc.
  • How do we make people better through play?
Recommendation: Practice using randomness where appropriate. Explore the space. Make a game with randomness that is about mastery. If you happen to be someone that values intellectual rigor over chance, make a game for someone other than yourself. Stretch your humanity.

#4 Realism


Past futurists sold a vision where games must inevitably become indistinguishable from reality. We marketed the hell out of that vision to the point it became dogma. You bought a new console, a new video card, a new computer to creep ever closer to the dream. You argued for 1080p as a paladin fighting for the glorious Holodeckian cause.

Why this discussion is outdated
Realism in graphics or simulations no longer is a dominant goal for most game developers. In practice, it turned out it wasn't really an essential feature for a successful games. In our far future era, you can snub realism and still make a billion dollars with a game like Minecraft or Puzzle & Dragons.
  • Realism has niche appeal. It is an aesthetic choice that tends to appeal to a singular sub-culture that we've trained with our decades of marketing. Cartoons, text and other stylized forms of representation are also appealing.
  • Realism can be an unnecessary expense. We sometimes wholesale replicate reality when we don’t know what specific stimuli actually appeals to players. It is sort of a shotgun approach that wastes vast amount of effort to hopefully make something interesting. A substantial portion of the exponential escalating cost of game development can be attributed directly to the pursuit of realism.
  • Simulation adds design risk: Many simulations are complex and difficult to manipulate. They also are not inherently emotionally satisfying. Insisting on mechanical realism while simultaneously trying to make a fun game tends to yield failed game designs.
  • Games are also endogenous systems of value. They are like little self contained baubles of math that set up interesting internal relationships. A game like Tetris has immensely value independent of references to the real world.
  • When players ask for realism, they often aren't asking for realism. The desire for realism is often best understood in terms of how players learn and apply existing mental schema to new system. A request for realism could be: A new player asking for a metaphor that helps them understand an abstract system. Or it could be an advanced player pointing out unnecessary edge cases. Both these have solutions outside belabored realism.
Alternative discussions to have instead
  • What is the right art style for your audience?
  • What are the trade offs between art style, production concerns and budget?
  • What sort of math or systems are interesting independent of their appearance in the real world?
  • How do we make game-like, cartoon-like, info rich, surreal virtual reality games?
Recommendation: Ask what utilitarian feedback your game truly needs. Invest your art resources making those elements amazing. Ask what level of modeling a system needs to create rich gameplay. Invest your design resources to create a tiny rule set with deep emergence. Be smart. Be frugal. When someone demands realism, try to figure out what they really want.

#5 Casual vs Hardcore


There’s a set of cultural stereotypes that casual players act one way while hardcore players act another. A surprising number of design decisions are made based off these stereotypes.

Why this discussion is outdated
The casual and hardcore stereotypes suffer from the problems typical of stereotypes. They are gross simplifications that yield the incorrect design decisions.
  • Many of the stereotypes are simply wrong: The longest average playtimes? Not console or PC. Handheld games, particularly those ‘kiddy’ Nintendo titles dominate session length. Regular daily play happens more often on smartphones and tablets than it does on consoles. When I look at data, there are very few ‘casual’ or ‘hardcore’ stereotypes that hold true. And when they do there are massive exceptions. 
  • The variation within a specific game is huge: You've got a half dozen or more distinct playstyles within almost any game of reasonable complexity. Each game is a vast city with many different people living within it. Mere averages tell you very little about how to improve the state of your game.
  • The market is shifting: Service-based games are driving for improved retention by doubling down on play. Women are playing more. Console owners are aging and slowing down. A lot of the old lessons about demographics and play styles have shifted. And they’ll continue to change in the future.
I see ‘casual’ or ‘hardcore’ as poisoned tribal labels like ‘gamer’ or ‘skinner box’. Mostly they are just weaponized stereotypes, deployed to enforce perceived group boundaries. They have little productive place in a modern design (or marketing) discussion.

Alternative discussions to have instead
  • How do you break out of thinking in cheap stereotypes in order to gain an advantage over the dinosaurs that don't see the market has it truly exists?
  • How do different groups unique to your game behave? (Hint: We can get the data!)
  • What motivates the groups unique to your game?
  • How do you include diverse hooks to appeal to multiple passionate audiences?
  • How do you make a targeted niche game using iteration with a live community?
I personally tend to make games that look 'casual', but consistently melt the brains of self identified 'hardcore' players trained on endless tutorials, cut scenes and QTEs. Some of the best players are smart 30-40-year old women that have the intense mental stamina for activities like logic, planning and creative thinking. They thrive on hard games. My market doesn't even exist if you see the world through a 'casual / hardcore' lens. Yet there it is, merrily enjoying games amidst the vast diversity of this planet's billion odd players. 

Recommendation
No one really makes 'hardcore' or 'casual' games. At best, we use existing markets, tribes and distribution channels to get a tentative foothold in a player’s psyche. But then it gets complicated. Embrace the complexity of your players. Learn who they actually are. Create elegant solutions that serve your many types of players.

Thoughts for 2015

If you happen to find yourself facing these 5 topics: Turn away. Our creative lives are limited. Pour your time into something productive.
  • Teachers that spread these memes: Consider teaching modern game design tools. Cull disproved dogma. 
  • Academics that expound on these ideas: Stop naive theory crafting and start referencing nuanced data from working designers.
  • Students that gnaw at these bones: Arguing ancient talking points in comment sections gets you nowhere in life. Make games instead. Base your design conversations around your hands-on experiments. You'll learn more, faster. 
Goodness knows that conversations on dead design ideas will not end. Players and their innumerable derivatives (fan press, forum warriors, cultural critics, etc) continue talking about these topics. Some talk for entertainment. Some for status. Some for business. Some talk about their game experiences in order to process them mentally and emotionally. For many of these purposes, simplistic polarizing hooks are more enticing than deep comprehension.

So these inane design views become practically tradition, or at least common hazing rituals. Like yelling at televised football games. Or laughing at trucknuts. Sure, players aren't having a productive craft conversation, but they shouldn't be judged by the same rubric. Consider their chatter a cultural performance.

As for designers, you have a different role to fill. Recognize when you are accidentally acting like a uninformed player or student. Instead of getting caught up in the babble of ill-informed internet backwash, try talking directly with other working designers. Build tools and knowledge together.

Here's to a more productive 2015,
Danc.

Sunday, December 7, 2014

Loot Drop Tables

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 die 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 it 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. (Thanks to a Reddit commenter for this idea)

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:
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.

(And before I forget – I've recently freed up some time to do some games consulting. Ping me if you need help with your games!)

take care,
Danc.