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.

Sunday, May 25, 2014

How game forms are shaped by their environment




We often consider artistic works from a creative or cultural perspective, but I find it just as enlightening to examine them from an economic or evolutionary lens. How does the economic environment within which a developer finds themselves shape the form that art takes?

As a case study of this in practice, I’ve been fascinated by a class of content-focused game that’s recently found a stable niche in the maturing mobile, PC and console markets. In mobile, we see examples like Sword & Sworcery, Device 6 or Monument Valley. In PC, you've got Kentucky Route Zero, Proteus and Gone Home. On console the trend is less pronounced, though Journey and Flower share some aspects.

These games generally have the following characteristics
  • Strong focus on evocative content: Most of the game is composed of arcs that deliver heavily authored payloads. The player’s cognitive load is consumed by interpretation of stimuli not the planning or execution of actions.
  • Light use of systems: Mechanically, the games tend to have limited interactive loops. There is little room for play within a mechanical space. The systems used are often highly traditional with a long history within other genres.
  • Short playtime: Often 1-3 hours.
This form thrives not due to some sudden explosion of artistic appreciation within the human race, nor due to universally-applicable intrinsic attributes of Truth and Beauty. No, instead these games thrive because they competently execute a development strategy that matches well with the current socioeconomic environment.

Form shaped by environment risk

Form is an accepted and standardized structure for a work of art. A painting stretched on canvas painted in oils that fits roughly on a living room wall is a common form of painting. A haiku is a form of writing.

Unlike many media, the forms that a game might take are still quite fluid. Where authors of literature might feel locked into to well-established structures such as poem, short story, essay or novel, game forms are both broader and have less sharp boundaries. They vary radically in mechanics, scope, topic, number of participants, and hardware. The difference between a game of Tetris and a game of Charades can seem far vaster than that of a Shakespearean play and an encyclopedia entry. And as a designer, you often get to chose the unique form of your game.

How risks shape game forms

However, different forms of game have different levels of risk and trade offs. There’s internal risk such as design risk, technical risk, production risk. And then there's external risk such as distribution risk, market fit and many others. If any one of these aspect of the project fails, the development investment is lost. Any game design can be judged by the costs associated with building the game, the benefits of success and the downsides to failure.

Fig 1. Valid terrain based off existing environmental risks

These are not abstract decisions. Most developers (even large ones) operate a paycheck or two away from bankruptcy. Paying the rent and putting food on the table are very real concerns. Many smart teams therefore choose projects of a form that minimize overall risk in order to dramatically increase their chances of future survival.

Thus game developers have a great incentive to evolve game forms to fit whatever environmental pressures are present. If something changes in the environment that increases a type of risk, then you’ll see developers selecting, from this vast palette of potential forms, the options that mitigate that risk. Picture a thousand little Brownian developers blindly adapting their game forms to half felt market forces and thus converging on useful strategies.

Using survivors to determine dominant strategies

The process of evolving games forms can feel invisible. The vast majority of projects that don’t balance their risks correctly, fail and sink out of the cultural consciousness. Most creators are barely conscious of their influences and constraints. All we really know are the the survivors.

When you see a new species of game thriving in the marketplace, you can start to ask some interesting questions. What are the culling mechanisms that let those games survive? What strategy was used that gave them an advantage over other possible designs? The things that make it through the filter give you some insight into the shape of the filter.

Some forces at play

What are some meaningful forces acting upon the modern indie developer attempt to sell a game for a fixed upfront price?
  • Digital distribution and cheap tools: At the heart of the emergence is ability for small teams to build and release games at low cost. However, those markets are now maturing.
  • A large audience trained on content consumption: The past decade of AAA titles perfected a variety of secondary content delivery standards via cutscenes, level design, voiceovers, etc. Gamers know and understand these methods. Over the decades, we've built up the equivalent of a trained audience that knows how to read.
  • Average revenue for a product is dropping. In fact they are close to zero in mobile markets. The exponential distribution of revenue looks more L-shaped, with small number of titles making the majority of the money and no middle market to speak of. You have hits or failures with little in-between.
  • Price per unit for games with an upfront cost is less than $0.99. As Steam opens up further, bundles proliferate and consoles introduce more free games, expect further price erosion for premium titles. You need to reach more people to make less money.
  • Discoverability is weak. Discovery mechanisms are weak and heavily gated. Channels are also flooded with games of difficult to determine quality. A game benefits from being able signal quality 1 to 30 seconds of exposure since that is likely all the time it will get.
  • Cost of production is increasing: Cheap tools bring the capital cost down, but labor costs remain stable. The need to hit ever increasing levels of quality results in an escalating cost curve. Five years ago, a hit premium game on mobile might cost $50,000 to build (including sweat equity). Now, for less revenue, you’ll see costs range from $200k - 1M (or higher). This expense is almost entirely due to content and feature competition: more art, more animation, increased use of 3D, more ‘required’ features.
So it is hard to stand out, hard to make money and very easy to spend more than you make.

A content-focused strategy

Given such a landscape, what is a species of game that might survive? We are looking for solutions to the problems listed, but also ways of tackling multiple problems with the same resources. Efficient solutions survive.

Fig 2. A strategy that mitigates technical and design risk.
While taking on some distribution risk.

Note that the following is by no means the only strategy. If you look around at other thriving developers, there are many alternatives. Nor is it a preferred one. This strategy has no inherent value beyond its functional benefits. Nor for that matter is it likely that the half-blind creators explicitly planned out their strategy. Like the flying fish and the (sadly extinct) flying shark, common strategies converge unwittingly from disparate perspectives as if shaped by an invisible hand.  Environments have local maxima whether or not we are smart enough to perceive them ahead of time.

With those disclaimers duly dispensed, consider a content-focused development strategy for small teams...

Reduce costs
  • Target a smaller scope: Content is expensive, but what if you make a game that is 1 to 3 hours, not 20 or 30? This simple change means you can cost 1/10th what a bigger title might. This is the defining economic attribute of this game form.
  • Remove systems and features: Trim as many standard elements as possible and focus the game focus on one or two key features. Dear Esther, you walk around. In Gone Home, you walk around and click on objects. NPCs? Cut. Combat? Cut. Branching narratives? Cut.
  • Keep your team small. Since labor is your largest cost, a small team means lower investment. Team members should being able to execute multiple aspects of development so you don’t need part time specialists.
  • Keep your development cycle short(er): Spend 9-12 months on a title, not 18-24 months.
  • Excel at what you attempt: It helps to have at least one or more people who are world class. Then build your game around their signature style. This makes up for some of the inevitable weaknesses that arise from small teams sizes, wearing too many hats and short schedules.

Reduce distribution risk
  • Make high impact video and images. Since you have limited contact with potential players, you want the briefest glimpse of a game to excite them. Gorgeous visuals, evocative narrative hooks that can be grasped in a couple seconds work well. All many buyers need to see of Monument Valley is a single screenshot.
  • Form relationships to amplify your signal for free: With a small team and a low marketing budget, free distribution is ideal. By forming relationships with journalists, streamers, taste makers and platform curators, you may get a mention or a feature. Of course, what you provide in return is a sellable story or validation of their long simmering world view. ‘Games as art’ is currently easy topic to bond over and all games with this form make the most of it. 

Reduce design and production risk
  • Rely heavily on static content: Art and video rarely fails on a functional level. There’s a risk in discovering an artist initially, but once on board, a competent artist tends to continue to produce competent art. Especially over short production schedules. You already need to make high impact visuals in order to get distribution, so there’s synergy here.
  • Use existing mechanics: New mechanics take time to discover and often don’t work out. Invention is hard. By using well proven traditional mechanics, it is unlikely that the systems will delay your game. Turning a page or clicking a hyper-link is quite reliable.
  • Reduce systemic emergence: Unplanned surprises hurt the schedule and cost you money.

Reduce technical risk
  • Use existing technology: Well proven, simplistic technology. Again, you can get away something that simply puts quality content on the screen
  • Avoid complex technologies: Technology that require strong expertise such as multiplayer servers or advanced 3D rendering is likely to blow up. So don’t do that.

Reduce audience risk
  • Make the game easy to finish: You want people to play the game, finish it and then talk to their friends while still in midst of the afterglow. This is a fast virus, not a slow one. Challenge is a useful tactic in other contexts (Dark Souls, Spelunky), but it is a poor fit when you want to deliver your beautiful load of content as smoothly as possible.
  • Keep content highly interpretable: To offset the risk of the game being too short, you can implement content that either vague or open to many interpretations. This means that quality of your content can be lower without anyone being able to concretely describe it as such. A certain air of mysterious brilliance can act as a prophylactic against common criticisms; seed the doubt that a player may simply be unschooled in Imperial fashion.
  • Engage the community: Ideally, you kick off a secondary wave of community engagement as players and critics invent their own detailed explanations for what may in fact be random (yet highly evocative) noise.
Notice how all these pieces fit together into a coherent strategy. A small team with a strong artist and / or writer makes a short, attractive game that sells a light narrative. This also happens to be small enough a scope that they can finish and release it. Such a game is pretty enough to be featured and can be easily talked about. There’s also little risk for the player...they get this nice watchable nugget of content that’s super cheap and feels like a reasonable value relative to other comparable consumables like books or movies.

A deeply conservative take on games

This strategy formula isn't new in the grand scheme. Cheap, consumable content differentiated on gatekeeper-approved quality variables is at the heart of most media markets.

In grand spectrum of possible games, the crop of boutique content games is one of the most conservative possible development strategies. Rosy cheeked media critics who might imagine the real history of games started in 2007 are likely excited by such titles. However, when compared to the rich systemic and narrative experimentation of the last 30 years, these forms are ultimately a retreat; survivalist risk mitigation marketed as hip cultural advancement. Such games tacitly give up on the idea that games could be a different type of thing than traditional media and adopt whole hog similar methods and limitations. At the crudest level, you flip pages, you see content.

One should tread lightly in labeling this as a ‘bad’ change. Evolution does not judge. This strategy works. Good, passionate people are making money and surviving to build another game. That’s all you can really hope for as a game developer in a staunchly capitalist world.

The future

Since we are dealing with a conservative product strategy, comparable markets suggest where these might evolve over the next 5 years.

Fig 3. Increasing costs put new pressure on the content heavy form.
Player desire for the new form increases the overall market opportunity.


  • Rapid market saturation: Since costs of entry in terms of skills and technology are quite low and first movers have almost zero competitive moats, new entrants should flood the market. This reduces the average success rate; most will not be profitable.
  • Costs increase: As more entries appear, quality becomes more important. Those with cash spend more to keep or capture profitable audiences. Form-specific blockbusters emerge that spend the maximum amount to get the maximum audience. (I've called these genre kings in the past).
  • Shorter length: Increased costs put pressure on decreasing the length even further. At some point players may decide that even an amazing 20 minutes is not worth 99 cents.
  • Use of portfolios: Anthologies, bundles or subscriptions to content streams (aka magazines) are common methods of paying a population of authors in a hit driven ecosystem. If this shift in market structure occurs, middlemen begin dictating tastes even more strongly.
  • Attempted differentiation based off thematic genre: Essentially the market fragments. As customers become trained in this new form, they’ll start to prefer specific types of content, much like we we see romance or mystery novels. First movers in thematic areas could tap a new sub-niche.
  • Fragile specialist firms: Developers will need to specialize in this specific form to produce the best of breed content. However, this makes them inflexible when the need arises to adapt to new forms. We've seen this situation play out in the past with adventure games.

It may seem silly to predict a future of saturation and collapse when there are so few of these games around. Yet markets are never eternal. Due to the lack of competitive moats, this one will mature rapidly and any golden period is likely to be short.

Fig 5. Fragmentation into sub-forms due the changing landscape


In some sense, these short content focused games have made a deal with the devil. They've reduced their inventive mechanical scope and deliver all their value through highly polished content. However, one constant of the game industry is that content costs are always rising on a given platform. The cost curve is the monster that eats our industry. It is great to trim 1/10th of the content in a game to get your costs down, but what happens when the cost of making content then jumps by 10X? That brief advantage disappears.

Lessons

Though I don't personally make short content-driven games, I find this lens immensely useful in understanding how and why my work impacts the world. All art is shaped by the economics of a specific time and place. All standardized forms of art are but niches within a socioeconomic ecosystem. They are not eternal, they shift over time. Knowing that common forms are not some absolute truth empowers the clever and observant developer.

It pays to ask: Who is making money? How do the developers, journalists, museums, critics or other middlemen benefit from promoting the works that they promote? Any creative work that depends on money-making institutions (big or small) is a commercial artifact, shaped by commercial constraints. None of us are truly independent creative entities. That’s at best a pleasant illusion, a lie. We all create within systems that cull our impassioned work with pragmatic brutality. We also, like it or not, preempt this culling through self-censorship.

The flip side of this analysis is to look at the failures.  Ask who is doing something different and failing? What structural and environmental factors explain why they are not making enough to eat? Once you've identified the problem areas, is it possible to spot gaps and come up with a new strategy that lets you thrive?

When you see a new form of game emerging, ask why. Seek to understand the confluence of forces. Then use this rich understanding to invent your own unique form of game. Do your part to ensure that the evolution of games never stagnates.

take care,
Danc.

Tuesday, December 31, 2013

Multiplayer Logistics

How do we get players to play together in a manner that fits their schedules? This is a key logistical challenge a designer faces when building multiplayer games.

The promise
We are seeing a blossoming of innovative multiplayer systems. In previous eras there were a handful of default models that games might use (matches, play-by-mail). Games today exist on a spectrum from fully concurrent to fully asynchronous and everything in between. A game like Dark Souls is predominantly single player, but includes interactions that are asynchronous (the leaving of messages and deaths) or fully concurrent (the joining of another player into your game for PvP or Coop.)

We are entering a golden era of multiplayer gameplay. Server costs are falling dramatically with the advent of cloud computing. Broadband internet and always on mobile connections are spreading rapidly across the globe. Business models like in game payments, crowd funding and service-based gaming are evolving to the point to financially support a broad range of long-lived communities. Designers are playing with these new capabilities to invent new forms of multiplayer gaming.

The challenge
However, multiplayer is both expensive to build and has a high risk of failure. Often teams invest 50 to 100% of their development budget into creating a multiplayer mode. It seems worth it. During development, the team plays every Friday and has so much fun they are convinced that multiplayer is what will turn their game into the next League of Legends or Counter Strike.

The real test occurs when the game faces a live population of players. Upon launch, multiplayer games often see only a few weeks of active multiplayer activity. Too many people show up. Then not enough. Players visit sporadically and the player experience is deemed unreliable. The active matches trickle down to nothing. The traditional matchmaking lobbies (a design from the 1990’s) are left empty and will never be full ever again. The multiplayer portion of the game dies a sad sputtering death.

I see this as a challenge of logistics. There were players who wanted to play. However the way that the game put those players together results in weak community that was unable to self sustain.

Are there atomic elements of multiplayer logistics that lets us approach the topic of inventing new systems in a more rigorous fashion? Simply copying multiplayer patterns from previous eras works poorly. To invent new multiplayer modes, we must have conceptual tools that let us clearly and concisely manipulate topics like logistics, concurrency and interaction schedules.

Concepts when talking about multiplayer

Here are some concepts I think about when designing a multiplayer game.

Interactions

You can break up any multiplayer system into a series of interactions. An interaction is anytime players interact with one another via a game system (be it chat, hitting one another, etc.) These are the multiplayer verbs of your game. Usually a game has a set of single player verbs (move, quit, etc) and another set of multiplayer interactions mixed in. Interactions have a wide range of multiplayer properties such as frequency, scope, mode, etc.

If you map an interaction onto time, it looks something like this
  • The player starts the interaction
  • They end the interaction
  • They wait for a response.
  • If no response is forthcoming, they leave.
Interactions aren’t a new thing. The structure is identical to that found in atomic game loops. However, instead of a single loop you have something closer to a figure 8 with at least two participants. These concepts go back to communication theory that Chris Crawford adapted to games design theory in the 1980’s. This is fundamental stuff that all professional game designers should know.


Initial loop:
  • Model A: Player formulates an action and a target player or group.
  • Action A: Player performs the action.
  • Rules: The results of the action are mediated by the game logic.
  • Response A: Player A sees the immediate results as generated by the game.
  • Response B: Player B sees the immediate results as generated by the game. Note that what Player B sees is likely different than what occurs for player A. This naturally leads to divergent mental models and enables gameplay concepts such as hidden information or Yomi.
Reciprocating loop
  • Model, Action, Rules, Response B: The target players tries to understand what happened and formulates a response.
  • From here the loop ping pongs back and forth between participants.
Frequency of interaction

What is the frequency of interaction necessary to yield the impression of concurrency? You may find that you need to interact once every 5 minutes in a strategic game like Civilization while you need to interact every 200 ms to create the same impression in a twitch-based action game like Counter-Strike. See the article “Loops and Arcs” for a more detailed explanation.

In general, the higher the frequency of interactions, the more information being communicated between players. This can increase the pace of relationship formation.

As with many interaction variables, there are distinct phase changes in the players perception as the frequency hits a threshold. Simply by changing the spacing between interactions, we get radically different forms of play (and associated logistical challenges):
  • Real time: Players perceive interactions as ‘real-time’ when the frequency reaches the point where: A player starts and ends an interaction and then sees a response before they move onto other tasks; interactions overlap. Chat, for example, can feel real-time despite there often being more than a minute between responses. Real-time systems have less need for persistence but are often more expensive to run and build.
  • Asynchronous interactions: The frequency at which a player can start an interaction and end the interaction and then quit the game without seeing a response is seen as asynchronous. Generally you build in some sort of persistence so that a player that logs in later can see the results of the interaction and formulate a response.
Types of interaction
There are a variety of interaction types. Think of these as ‘how’ players interact. For a much more in depth description of all the various multiplayer interactions, see Raph Koster's seminal talk on social game mechanics.
  • Spacial avatar interaction: Two or more avatars interact with one another. Shooting players in Quake is the classic example. Following a player in Journey is another.
  • Spacial environment interaction: Players also interact through the intermediate environment. In Minecraft, players build castles that other players then explore. For a higher frequency example, in Bomberman, players place bombs that open up passages or do damage to others.
  • Decoration and Display: Players signal status, affiliations and history via what they wear or how they decorate their weapons, pets and houses.
  • Economic: Players give, trade or pay for various resources to transform or transfer to another player. This can be a typical sale of a sword to another player for gold. Or it can paying mana for a buff that boost the health of a nearby player. See Joris Dormans work on internal economies for more on this topic.
  • Text: The most common method of introducing language into an online game is through text. It tends to be low cost and there’s a rich set of tools (spam filters, stylistic conventions) for dealing with common issues. It tends to work best with a keyboard.
  • Voice: Voice offers additional nuance including emotions, age, gender and more. It has limits for group size, bandwidth and is notoriously weak when it comes to filtering.
  • Body language: In local spaces like on a couch or around a table, we pick up on high bandwidth communication such as facial expression, posture, body height and physical presence. When a tall pretty boy looks you in the eye and asks that you trade your rare treasure with him, you may be getting signals that go far beyond what is found in other types of interaction. This creates rich emergent multiplayer gameplay. However, it is also hard to mediate and incorporate explicitly into the game systems.
Size of community
There are also massive phase changes that occur as you increase the number of participants in a community.
  • 1 player: Mastery, progression, exploration, narrative are available as design tools.
  • 2 players: Communication, relationships, status, gifting, trade, cooperation and competition become available.
  • 3-4 players: Alliances, politics, gossip, othering/stereotyping become available.
  • Small group (5+): Group vs group interactions, Official leadership, role specialization, official punishment
  • Medium group (12+): Factions, barter economies, and banishment
  • Large groups (40+): Hierarchy (leaders and sub-leaders), Currency-based economies, role enforcement. Adhoc systems of government, public codification of social norms.
  • Very Large groups (200+): Merchant classes, market-based pricing, codified systems of government, underclasses, celebrity, propaganda. This is the point at which a players is guaranteed not to know everyone and official systems are required to make social norms work. (see Dunbar's Number)
  • Massive groups (1,000+): Polling, city-scale production efforts. There are very few dynamics that happen at this scale that aren't also explore with 200+ or even 40+ groups.
I'm defining these groups in the context of player interactions.  The actual game population may be much larger.  For example with trade in Realm of the Mad God, we saw simple trade interactions happen with as little as two people even in populations that are in the thousands.  Two good rules of thumb when considering group size is to ask:

  • Who does this action impact or target?  This gives a rough estimate of the group size your system needs to support. 
  • Is a larger group size necessary for this behavior to emerge?  If not, you can usually get by by targeting your design at multiple instances of a smaller group size. 

The actual transition points fluctuate around these numbers based off contextual factors. For example, the transition to the dynamics of a Very Large Group can occur as soon as 60 or 70 people if there are weak communication channels that stress a player’s ability to maintain relationships.

Also, large groups are inevitably composed of smaller groups. So as systems are added, the dynamics of lower number groups are still present.

The dangers of large group sizes: It can be tempting to make epic multiplayer games with thousands of interacting players that could theoretically all fit in the same room. However, the technology and design costs are high and the benefits weak. Past 150-250 players, your game is in territory beyond Dunbar’s theorized biological limit on maintaining meaningful relationships.  All those extra people end up just being treated as number or abstractions by your players. A simple sim or polling system can often capture the major benefits of the next highest group size. 

Realm of the Mad God was completely playable as an MMO with action sequences of 40-80 players and trade / hub interactions of 150.  Players did not miss the 1000s of players. 

This reality raises serious questions about the need for designs that emphasize ‘massively multiplayer’ experiences. Just because a concept sounds exciting (“a million people building a new society!”) doesn't mean it is a smart design. Human social capacities are limited and we can (and have!) over-engineer multiplayer systems.

Scope of interaction
How many people does a single interaction impact? A player can interact with a single individual or they can interact with one of the group sizes listed above.

  • Targeting a player interaction at small groups: With smaller group sizes you get communication similar to a conversation. There is a clearly defined interaction loop that can stabilize on a set of shared vocabulary and social norms quickly.
  • Targeting a player interaction at larger groups: With larger group sizes you see more broadcast scenarios and interactions are broader, less tailored to individuals. When interacting with large groups, it is common for the massive response to flood the recipient with too much information. Extreme reactions are also more common as people talk over and past one another.


Degree of interaction
  • Parallel: Players can behave independently from one another. A ghost racing car rarely impacts another player. Often the primary benefit here is a sense of presence though it can also tie into lower frequency zero sum interactions like a leaderboard.
  • Zero Sum: The action of one player blocks or reduces the interaction of another player. In Habbo hotel, movement is a zero sum interaction since the placement of one character blocks another character from occupying the same spot. This was famously used as a griefing tactic to box in players.
  • Non-Zero Sum: The action of one player benefits another player. In Realm of the Mad God, shooting an enemy makes that enemy easier to kill for other players. Killing an enemy gives XP to everyone on the screen.
Matchmaking
Matchmaking is the computer mediated act of introducing players to one another so they might interact.

This is a very broad definition of matchmaking, but is useful in the context of the wide range of multiplayer systems available. For example, a traditional console title might match players together by requiring players in a shared lobby to manually join a specific game. In Realm of the Mad God, players notice groups of players on a shared map and teleport to them. Both are forms of matchmaking, but they appear quite different in the player’s mind.

You can treat matchmaking abstractly as another interaction with a wait time.

Matchmaking window

The time you have to introduce a player looking for a multiplayer experience to another player. If the window is too long (and the player is not entertained during the window), they will leave.

Matchmaking failure
When a player comes online and there is not another player immediately online, the players will quickly become bored and leave. There is often an implicit promise of a fun multiplayer experience and if you don’t deliver that in seconds, your game is judged as a failure.

What can be frustrating to the developer is that another player pops in a minute later and experiences the same exact thing. If one players sticks around long enough, another player will show up.

Calculating daily failure threshold: If the matchmaking window is W in minutes, then failure will occur when the daily active population is less than Minutes In a Day / W. So for example if people are only willing to wait half a minute, you’d need a daily active population of 1440 / 0.5 or 2880 players. Actual results will be lumpy because we are dealing with a statistical process and player populations peak around specific times of day.

This may seem quite reasonable, but if you are matchmaking primarily with small groups of friends, players may feel like no one they know is ever on.

Fragmentation
When the player population is segmented by social groups, game modes, players skill levels, time playing and other factors, it becomes fragmented. This reduces the actual concurrent player numbers available to the matchmaking system and increases the chance of a matchmaking failure.

Example of fragmentation: Suppose a game has 3 multiplayer modes and matches players into 10 skill categories. If the daily failure threshold is 2880 (from the previous example), then in the worst case scenario, you’d need 3x10x2880 or 86,400 concurrent players for everyone to get their first choice.

Fragmentation creeps into a design. Someone wants to add another event or another game mode. The code is free, so why not? Surely the players will self sort. They do a little, but mostly they wonder why the matchmaking experience is so painful and then leave your game in frustration. Avoid fragmentation creep and put players together in big easily matched buckets when possible.

Concurrency ratio
Any game has a number of active accounts and a number of players that are online at once. Players cannot be playing constantly and are often offline For example, an MMO might have 100 active subscribers, but only 10 of those are on at any one time. This would result in a concurrency ratio of 10:1.

Some typical concurrency ratios:
  • MMO: 10:1
  • Online Console Service (like Xbox Live): 25:1
  • Individual Console game: 150:1
  • Flash game: 250:1
  • Couch multiplayer: 1000:1
The Active User Trap: One common mistake is that developers assume that high active player numbers will result in robust multiplayer communities. However you really need to look at actual concurrent users since many game types have extreme concurrency ratios. A game may have 1000 players but when each of those logins last 5 minutes and are spread over a week, you’ll average 0.5 concurrent players. If your matchmaking system doesn’t deal well with these sporadic, tiny populations, the game dies.

Relationship strength
Not all player interactions are equal due to unique relationships between players. Players build complex social models of other players both in game and out of game. Strangers are understood through simple, stereotype-based models. Close friends are understood through complex individual models built up over thousand or millions of minute reciprocation sequences.

Building mental models of another human is a biologically expensive operation. We seem to be able to keep 5 to 9 detailed models active at any one time though we can store many more at various levels of detail. Friendship is rare, complicated and built over long periods of time.

There are numerous benefits and trade offs that come from gaming with strangers or friends and friend-based play is often highly desirable. Games can help create friends by promoted repeated positive interactions. The higher the frequency, the quicker the relationship evolves.

Relationship strength is a spectrum, but there are two commonly drawn categories
  • Multiplayer with Strangers
  • Multiplayer with Friends
Multiplayer with Strangers
Let’s tackle multiplayer between strangers online first.

Pros:
  • Anyone playing the game can be matched with anyone else with little regard for existing social bonds.  This model becomes immensely attractive when there is a small initial player base. Often this means if 10 people are online, 10 people can be playing together.
  • Strangers, particularly young males, historically tend to compete with one another. This means that player vs player games that emphasize open conflict are an easy means of generate fun for some stranger populations.
Cons:
  • Strangers have weak bonds and will not naturally engage in prosocial activities like collaboration.
  • Skill differentials matter since players tend to compete. This forces developers to focus on segregating experts from newbies and fragments the population.
  • Not all player populations thrive on overtly competitive gameplay. Some players prefer to collaborate. Others compete quietly for status by manipulating social relationships. These are difficult in stranger scenarios.
Multiplayer with Friends

Pros
  • Players are much more likely to schedule time together to play.
  • Cooperative and communication heavy activities are considered fun.
  • Mentoring between divergent skill levels is more likely to occur.
  • Competitive play is still valid.
Cons
  • There’s often little overlap between existing social groups and interest in a specific game.
  • There’s often little overlap between existing social groups and share scheduled.
  • Friend groups are small. Engaged players typically have 5-9 close relationships. Casual acquaintances may be higher in number, but in practice may act more like strangers. If you have 10 friends and the concurrency ratio for a service is 25:1, you will essentially never stumble upon them online.

Tools for dealing with multiplayer logistics

So far I’ve just talked about the concepts behind multiplayer. Now we’ll dig into some common patterns that make use of these. There are three broad architectures:
  • Match-based games
  • Room-based games
  • Asynchronous games

Tools: Match-based games

Due to the long history of event-based matches in sports and board games multiplayer computer games often are organized into matches that start at a specific time and stop at a specific time or win condition.

Matches are the default logistics model used for many console and PC-style online games. They are immensely problematic. The matchmaking interaction has a very narrow window during which it requires a full set of players to show up in order to enter the game successfully. If you don’t get in, you need to wait till the next match starts. If this time is longer than the wait window, you’ll quit. Considering concurrency ratios, fragmentation and the burden of a tiny matchmaking window, it is not surprising that only the most popular match-based online titles survive.

Scheduled Events
Ask people to show up at the same time. This essentially shifts play times so that they are on at the same time. Scheduling is an expensive planning activity on the part of the player. You’ll get a low overall engagement rate but those who do participate are likely to find others to play with. A special Halloween boss encounter in a MMO is an example of a scheduled event.

Events can be scheduled by the game developers or they can be scheduled by the players. Player scheduled events have the benefit of stronger social ties in play. Folks that get together for a board game night are such an event. The downside is that arranging meeting is a convoluted process (as anyone that tries to set up meetings with more than 6 people can attest). It often requires leadership or persistence, attributes that are often in low supply for lightly engaged players.

Regularly scheduled events
If you can make the event regular, people will get in the habit of being at a particular place at a particular time. This reduces the cost of planning for the player and they can just reliably show up at a specific time instead of worrying about conflicts. A standard Wednesday game night for a guild is an example of a regularly scheduled event.

Short matches
If matches are short enough (2 minutes? 30 seconds?) players that don’t get into the current match wait less time than the matchmaking window and thus are still around when the next match starts. Online word games do this, but it could be readily applied to other titles.

Spectating on matches while waiting
If you can keep players entertained by letting them watch the game in progress, you can lengthen the matchmaking window. Games like Counter Strike do this upon entrance into a server and upon death.  Chatting is often tossed into this mix since it is a nice downtime activity that can build relationships.

Bots during matchmaking to fill waits
Instead of putting players in a queue where nothing happens, put them directly into a match with bots as the opponents.

Getting bots that act like humans is often a tricky Turing test to pass. Not letting players talk and having a very narrow window of expression helps.
When players learn this is happening they will start to distrust the game and question if all opponents are bots.

Mechanical Interdependencies
Create activities that require multiple people to show up in order to achieve success. Not showing up lets down the group and thus increases the social pressure to show up. This can take the form of explicit roles or by limiting resources so that players can’t accomplish large goals independently.

Tool: Room-based games

Ultimately match based games result in often insurmountable logistical issues for smaller games. A favorite alternative is room based games. Unlike a match which has a distinct start and exit, room-based games create a persistent playspace that players may independently join the game in progress (or leave the game in progress)

Rooms have a maximum number of ‘slots’ or spaces for players to join them. Once the room is full, no more players may join. This dramatically reduces the load on matchmaking. All you need to do is find a room with an empty slot available and dump players into it.

The downsides to rooms is that they eliminate certain game types. Group starting times are obviously out which eliminates most traditional sports. Games with progression arcs result in players that start at different types having differing levels of progress. You need to get creative.

A game like Journey is essentially a room based game with join and leave in progress. The max slots was 2 and as long as there were two concurrent players you could have a multiplayer experience.

Most MMO’s are room-based games with very large rooms.

Join In Progress, Leave in Progress
One reason why rooms offer such improved logistics over strict matches is that players may join or leave at any time.  Since it is highly unlikely that everyone will leave at once, especially in games with a predominance of parallel interactions, shortly after one person leave another person will join and you'll get a consistent average population in the room.

Pure match-based games are often quite rare because many popular games treat the individual server as a room and the match-based elements are merely scoring atop a dynamic population of players joining and leaving in progress.

Elastic Room Instances
Create and remove rooms to fit that maximum currency. Given a room of maximum size N, you create new rooms so that the number of rooms equals Concurrent Player / N. So if 10 players are online and your default room size is 4, you’ll make sure there are 3 rooms to join.

To collapse a room, just wait until it naturally empties out as players leave the game or kick people out due to some in-game event intended to free up the instance. Once the room is empty, delete it. By giving rooms priority, you can fill the highest priority rooms first and kill off the low priority rooms. The result is that almost all rooms are constantly full and only the remainder are left alone.

We used this when creating world shards in Realm of the Mad God. The world generally felt full even when the concurrent population fluctuated dramatically.

Default to single player gameplay for rooms with one player
Room-based games have the ‘remainder’ issue. A given maximum room size rarely divides evenly into the concurrent population. If the room size is 2 and there are 3 players online, there will be 1 player placed in a new room by themselves.

To deal with this scenario, it helps to have a game that is playable as a single player game until the next player joins the room.

A retail game like Dark Souls assume very low concurrency and plays almost entirely as a single player game (with light async ghost interactions) The concurrent matchmaking is a silent parallel interaction that happens without interrupting the single player adventuring. Since having a second player in the right place at the right time is uncommon, the game instead treats it as a special occurrence. (Note that since Dark Souls promises a single player game, they make the concurrent multiplayer experience opt-in through the use of soapstones. The soapstones signal that a successful match has occurred and the player must accept it. Respect your initial promise when you mix single player and multiplayer interactions.)

Asynchronous techniques

Play-by-mail
A player completes an interaction and then the game signals to them that they have a very long period of time before the other player responds. The next day or so, the other player sees the first player’s action and composes their response. This can take place over days.

Words with Friends is a modern example of this technique, but the practice goes back decades if not centuries (if you include play-by-mail board games). It is an intimate method of play that works well with text communication much like instant messages or email. Play-by-mail is very amenable to play between friends.

A downside is that players are deeply impatient. A single turn may not be all that satisfying and then having to wait multiple days for a response has a major drop off in retention. There are still matchmaking issues if fragmentation is too high but the explicitly long wait window ensures players don’t get too worried that the system is broken (they may just not like the system).

The other downside is that in turn-based games, the non-response of one player may block another player.

High Capacity Play-by-mail
One solution is for a player to start a large number of play-by-mail games. Given a response time of T days and a desired average wait time of W days, then the optimal number of games going at once is T/W. (So if you want a game popping in every hour and it takes 24 hours to response, then you need 24 games going.)

One added benefit of all this is that player response times are semi-random. This acts as a random reinforcement schedule and can result in very long term retention.

The downside to the technique is that it requires players to start up a lot of games in order to reduce the wait window and motivating players to do so is tricky. Automated game matching may be an answer.

Inviting
You can leverage active players to invite new players to the game. These players often have strong relationships with the player and can potentially act as a source of new players into the game.

Match with friends
Since async forms of multiplayer rely heavily on players to come back later, their game designs often relies on social connections outside the game as a form of additional pressure. If you can get people to invite or match with friends (as in Farmville) a lack of reciprocation in interpreted as putting their existing relationships at risk. The threat of being rude or seeming like you don’t care to someone you like is often enough of an incentive to encourage returning to the game.

Systems that play off existing relationships run the risk of alienating players. Players not invested in the game tend to find mechanical interactions annoying. Authenticity and intentions matter when it comes to human relationships.

Visiting
In building games, you may create a persistent structure such as a town that other players can then visit independently of your presence.

Clash of Clans uses this when players attack your town. The town is a persistent structure that then acts as a level for the other player to conquer.

Visiting usually boils down to a simple resource exchange despite the trapping of being something more meaningful. The issue comes from questions of what happens when multiple people visit at once and the solution is to spin up different instances.

Jason Rohrer’s The Castle Doctrine uses the unique design of making visiting a blocking interaction. This opens the possibility for permanent changes being made to the visited location. One can imagine more complex versions of musical chairs as the foundation for some innovative designs.

Ghosts
Record players behaviors and then play them back alongside the player in a similar environment. This works particularly well with parallel interactions like you see in racing games. It can also work with the rare non-zero sum interactions like you see in multiple time track games like Cursor 10 or Super Time Force. Ghosts gives a sense of presence but removes the matchmaking time constraints.

The downside is that ghosts usually works poorly with blocking or zero-sum interactions. The other downside is that if the ghost data and the environment get out of sync, then the ghost data becomes invalid. These can be alleviated slightly by either skipping blocked actions or falling back on AI behaviors that manage exceptions

On a more abstract level, ghosts are just tracks of player data that can be replayed on any sort of trigger. They can be triggered at the start of a race, when the player comes onscreen or when the player uses the special amulet of Ally Summoning.

General practices

This essay has covered a lot of ground (and is still incomplete!), but I’ll leave you with a few quick recommendations.
  • Don’t fragment your matchmaking population. Be very wary of the point at which your concurrent game’s matchmaking fails due to high concurrency ratios.
  • Use room-based methods where possible, not match-based play.
  • Persistence is your friend since it enables asynchronous interactions.
  • Relationships are your friend since they increase retention. Try to build them where possible.
  • Prototype early and deal with low populations density issues during the prototyping phase.

Conclusion

I remain quite excited about new multiplayer games. When I look at the theoretical advances being made with game grammar via Joris Dormans internal economies and some of the multiplayer concepts in this essay, the unexplored space for new forms of game seems vast. If you want to make your mark on our modern world, make a great multiplayer game. Solve the logistical issues that prevent people from playing together and build a game that spreads quickly and easily throughout communities.

take care,
Danc.

Notes and references

Topic for future investigation
Concurrency is a statistical process; there’s a chance of a player being on at a given time. This whole topic could stand to be dealt with in a mathematically more rigorous fashion.

Essays and books

Wednesday, October 23, 2013

Prototyping Challenge: 3D Modeling Tool for 2.5D RPG Art


I was creating some 2.5D art for an game jam recently in a perspective similar to a 2D RPG like Zelda. Naturally my next step was that I started thinking about how you might recreate this style using a custom 3D modeling tool. Yes, another art tool design challenge. :-)

I’ve played with voxel editors in the past, but I’m not completely happy with the blocky results that they produce. So where's a quick and dirty minimalist 3D modeling tool design with the following goals:
  • Enable artists to make beautiful 3D models that include curves, ramps, intersecting shapes, and other sophisticated elements.
  • Make a 3D modeling tool that is as easy to use as a pixel art editor. In particular, I’ve realized that this editor can avoid a lot of the messiness that usually appears when you include 3D rotation.
The result should be art that is still stylized, but has still has an immense range for a talented illustrator. I've made other attempts at this in the past, but I think this one has legs. :-)

Target style

I put together a set of 2D art for a future game jam. The resulting 3D modeler in this essay should be able to easily create everything in this image, plus a whole bunch more.


When making this art, it occured to me that there is a rather magical property of the traditional 2.5D view that I don't think has been well tapped before. Once you adopt a forced 2.5D perspective, most 3D primitives are possible to be represented in a 2D plane. This makes a ton of traditional 3D operations dramatically simpler. You can think of a 3D space being reduced to a couple of 2D controls
  • Top Plane: The top of a cubic volume enclosing the primitive. 
  • Front Plane: The front of a cubic volume enclosing the primitive. 
Here's an example with a cylinder and the planes made explicit

With these, you can do basic moving and scaling of the object. The trade off is that you lose rotation.  My bet is that like voxel editing, you can lose rotation and still end up with a vast visual play space.

If you get fancy, you can flip an object 90 degrees forward so that:
  • Front Plane: Extrusion, XY position
  • Top Plane: Scale, XZ position

The basic flow of modeling

Here's what you do to make a model. 
  • Add primitives to an object
  • Arrange (scale, position) and color them.
  • Combine these tile-like objects together in a game to create complex scenes.

List of Operations

Here's the list of features that a simple prototype of the editor would support.

1. Add a primitive
You can add a primitive to the scene
  • Cube
  • Cylinder
  • Arc (half cylinder)
  • Ramp (NSEW variants)
2. Select a primitive
Click on a primitive in the scene to select it.
  • 6 dots appear
  • The bottom 4 define the front plane.
  • The top 4 define the top plane.
3. Move in XY plane
Grab the front face of a primitive to move in the X,Y plane

4. Scale in XY plane
Grab the corners of the front face of the primitive to scale it.

5. Extrude in Z
Grab back corners or edge of the primitive to extrude it.

6. Move in XZ plane
Grab the top of the primitive.

7. Select a color
Once you have selected a primitive, click on a color from the color palette to change the color.

Constraints

There are a variety of limitations enforced that make modeling far easier and closer to pixel art.
  • Snapping: All operations snap to a 16x16x16 grid.
  • Primitive budget: Each object is made up of a total of 32 primitives.
  • No rotation of primitives. Again, this is a hard problem in 3D. So we avoid it.
  • Limited colors: All primitives use the same 16 color palette. This allows us to appear to make complex objects out of multiple primitives by simply connecting simple shapes of the same color.
  • Surface details are generated using other primitives. Primitives whose surfaces are coplanar are rendered cleanly as 2D textures. See bricks in the example above. Use creation order or order in the selection list to determine what shape is on top.

Bonus features

The above features are the minimal set.  There are other features you could add to flesh out the tool.
  • Selection list: A list of all 32 primitive in the object. Click on one to select that primitive. Thumbnails are a plus. Bonus points if you can rearrange these. 
  • Hiding/Showing primitives: There is an eye icon in the selection list next to each primitive and you can hide or show that.
  • Rounded corners: Give the selected primitive rounded corners. These are in 1, 2, 3 or 4 grid width rounds.
  • Flip Front / Top: Rotate the primitive forward or backwards 90 degrees. Example: A flat disc becomes a wheel.
  • Cutter object: The selected primitive now subtracts from the solid instead of adding. This lets you cut holes. 
  • Textures: In addition to colors, you can specify some simple textures.

Special rendering tweaks

There is a reasonable chance that objects will look like rather ugly without the right rendering. Play with this till you get something that works.  Here's what I take into account when drawing things manually.
  • Parallel Light source (think sun) from the top so the front is in slight shade.
  • Shadows on other objects. Slight ambient occlusion will tend to make the objects feel more connected. 
  • Shading objects darker near the bottom and lighter near the top help preserve a sense of depth.

Test cases

Making art tools without art samples is tricky. The following are test cases that you can try to replicate once you’ve built the basic tool.
House

Factory

Stone

Tree

Woodchuck

If anyone makes a prototype, I'll link to it here. 

*Update!* Angry Octopus has a prototype.  (The more the merrier, so keep making 'em.)


All the best, 
Danc.