Tuesday, August 23, 2011

Asynchronous Participation

I was thinking about creative games that use player generated content, and the various schemes to share and remix and use that content.

There are various "small scale" methods where the players generate some content in a limited fashion that is then used in the world. Eve Online is a great example of this: the player generated content is primarily limited to factions and corporations, and if the players want to generate physical goods they are limited to the goods in the master list.

But I'm thinking of a "deep" method where the players actually generate the majority of the in-game content. Second Life is the canonical example, and there are precious few others (Spore, the Sims, etc).

Most of them follow a "massively single player" model, where one player creates the whole of a given thing (for example, a house or hat or monster) and distributes it to others.

But what of an actually multiplayer model? Where content creation is actively multiplayer, with several people working together on something?

As I see it, there are three methods to multiplayer content creation.

1) Simultaneous participation. This is where players are working on the same thing with loose and informal boundaries. This is extremely vulnerable to griefing, whether on purpose or just because the other player has a different idea/is incompetent.

To minimize griefing in these situations, it's common to reduce player investment in the product, reduce algorithmic reliance between areas of the product, and restrict the participants to invite-only. All three of these are things I want to avoid.

2) Walled participation. This is when players work on the same thing, but with extremely clear boundaries. For example, if each player designs one of the characters that will end up in the party. Or if one player designs the starship model and the other designs the code that makes it move and fire. Or one person builds the level and the other builds the NPC bots within it.

Walled participation has some good points and some bad points, and it's worth keeping in mind. But I'm also not interested in that for this post.

3) Asynchronous participation. This is when one player will do a bit, then let another player do a bit, then another, and so on.

This is less subject to griefing than simultaneous participation because you can do strict version control and roll back to before the griefer did anything, or fork it to allow the griefers their own version. This is much harder with simultaneous participation because the boundaries as to what changes are what becomes very, very blurry very rapidly.

Asynchronous participation has the downside that the maximum "intent chunk" is pretty low, because each player only maintains control for a short piece of the whole project. If your intent is to build a starship in a Star Trek Federation style, and you leave and come back to find a beautiful starship built in Star Wars Empire style, it's going to be impossible for you to enforce your own intent without undoing or ignoring huge amounts of useful work.

Still, I believe this asynchronous participation deserves more consideration.

One thing to consider is that we may actually be thinking about it wrong. We're thinking in terms of big projects. What if we think in terms of little projects?

Instead of thinking about it like architecture, what if we think about it like improv? What if each player's action leads to a response which literally builds on that action?

For example, let's say there's a shared town and someone blows up one of the buildings in it (perhaps for fun, perhaps in the course of some adventure). Instead of rolling back and considering that griefing, you can use classic improv methods and build on it.

Move a bunch of squatters from a marginalized neighbor state into the rubble. Reveal a magic door to an underground area full of monsters. Have the explosion break windows in all the houses for a mile around. Send out an insurance hit squad to collect payment from that nasty team of adventurers. Small or large, just use the classic "yes, and" , "yes, but", and "yes, then" statements. Make the other player's action seem like it was perfect, cleared the way brilliantly, or added a kernel of a grand idea.

The idea here is to let go of your pure and lofty intentions. You don't need to build a city that is exactly like you want it to be: you need to build a city that people live in. It's possible to take content from other players who are interacting and use that to springboard in a new and vigorous direction.

A key reason this matters is because most players are not virtuoso content creators. Most players are only going to create/manipulate content clumsily, and often only in the course of doing other things. To pull them into the world proper, you need to have a way for those clumsy newbies to get pulled in with interesting new details, a way to make their contributions valuable.

On the other side, you may wonder how the players capable of creating good content would benefit. The answer is that most of the high-tier creators wouldn't benefit. They are people who enjoy working for a long time on perfect things, and then releasing them into the wild.

However, there is a type of content creator not really tapped: the event/questline coordinator. These are players whose content creation skills are probably mediocre, and may mostly be about choosing what existing content to replicate and stick into an area. But these are very valuable players, because they tie the player base together into a fun mesh.

So, what I'm saying is that asynchronous participation can A) allow beginners to contribute meaningfully, B) not interfere with high-level content creation, and C) give rise to a new kind of content creator that serves to bind the players together and build a world.

No comments: