I was asked a little while ago how I would do a space survival game, since I've been ragging on them recently. I also mentioned it in a video or two. So let's talk.
Let's get started simple. Let's say I'm a Star Citizen dev, out to put survival mechanics into my pew pew shooty game. I already have gorgeous starship interiors, now it's time to leverage them. How do I do it?
Well, my goal is to turn survival into a yarnball. A soft, complicated challenge that interlaces with a lot of other things. I also want to make sure that it unfolds into a narrative according to the choices the player makes.
So I implement a The Simslike survival system. Every time you make a space jump, your various meters go up. Hunger and filth, for example.
Actually using kitchens and showers is a repetitive and uninteresting task, so rather than requiring you to use the facilities, we simply reduce the meter if you have them. If you have a kitchenette, your hunger goes up 90% slower. A full kitchen? It doesn't go up at all... until your food runs out.
We do want to push the player to exist in that space, so we do allow the player to use a facility for a temporary boost - until the end of the next jump. If we use the kitchen, we get a +20%, but it uses up a bit of food. If we use the shower, we get a +10%, but it doesn't use up anything. This bonus doesn't reduce your meters, it simply enhances your performance. It doesn't stack.
To make this into a more narratively cohesive experience, we have to decide on the narrative we want. And the narrative we want is how the pressures of space travel shape our life aboard a ship.
This is not simply about "life aboard a ship". The point is to turn challenges - the challenges of a human surviving in space - into narrative beats. The ship is our tool to do that, but the challenge it parses is the challenge of survival.
If we want a gritty feel, we could get things like life support involved. But the ships in Star Citizen are ridiculously high tech, so instead we're thinking more about the social narrative. How does the mind fail, rather than the body.
So we add a few more meters. Loneliness, claustrophobia, boredom.
When they go up, you have to bring them down. Find someone to talk to. Land on a planet or space station and step outside. Have some fun by daredevil flying or fighting or driving a different vehicle.
...
A new player buying a new ship finds it comes with a little pocket gym. The gym reduces the meter growth of those three stats by 50% each, maybe.
But the player knows they are playing solo, and are planning to go on long explorations. So the big threat here is loneliness. The others can be dealt with in the middle of nowhere by visiting any random rock, but finding a person will be tough.
So the player rips out the gym, replaces it with a media console that constantly blares news shows and comedies. She puts portraits of her family on the wall, or pinups maybe. She buys a wisecracking robot companion.
These keep her company. And she can use them to boost: give the family a kiss, get +30%. Watch a TV show, get +40%, but use up a media slot - she'll need to buy the next season of Game of Space Thrones or trade SpaceYouTube caches with someone else to get those slots filled up with new stuff. Better to keep that cache intact, so it burns at the slower default rate and lasts longer.
And sure, she gets twitchy from the claustrophobia and the boredom. But that's why canyon racing was invented.
...
On the other hand, someone else might be playing on a team. They know loneliness won't be an issue, because there's another player around here. So they max out the others. They buy giant 3D landscapes for their walls - radically reducing claustrophobia, but actually increasing loneliness. They replace their gym with a video game console.
They can go for a long ways without having to land or play around, but they have to chat with someone every two jumps to stay happy.
No problem, they're sitting next to you.
...
We can see how the player's construction choices change the narrative. The player is choosing what narrative beats to include, which ones to play up or limit. One of those players is having a long, lonely journey hopping from planet to planet. The other is on a road trip with friends.
Those are very different narratives. We didn't write those narratives: we allow the challenges to be faced in a way that turns them into narratives.
We can push this in a lot of ways. For example, if we make it so that talking to a specific person works worse every time you do it, then those long journeys get more challenging because you have to find new people to talk to. If you burn media to keep your boredom under control, maybe you change one of those "size three hardpoints" from a gun to a giant subspace antenna that lets you transfer media from space stations a hundred light years away. Need food? There's a variety of greenhouses both internal and external...
These ramifications are polish on a core concept. If we didn't have the core progression, they'd be pointless. Most of this would be pointless if the player had to return to a station every time they logged off, for example: long journeys would be limited by a player's capacity to sit at their desk and play. But since you can log off in midjourney and come back, we can assume many players will go on very long journeys.
The question becomes: what of the players that don't?
What about the players that are short-haul? Players that specialize in fighting or shipping people or freight over shorter distances?
It's a common thing. A lot of players want to sit and do A Mission Now, and be done in half an hour. They don't want to log off midmission and come back to the same thing.
Can we make our survival systems create their narratives, too?
Well... no. It's not survival. But we can use the same core mechanics.
...
We could try to add stats like paperwork that go up as you dock... but what sort of narrative unfolds with that?
Not much of one. How can we make it messier and more entangled?
Well, most short-haul specialists will have specific hub stations - or, at least, specific preferred factions.
This is where it can't be Star Citizen, because their faction system has a ceiling. But if we throw that away, we can allow the player to build their contacts with the faction.
Rather than focusing entirely on the ship, we can allow the player-generated content to include people. Both NPC crewmembers aboard your ship and people you have agreements with on various space stations.
I would do it using a similar modular setup to the one used for ships and interiors:
As you rank up, you get a better "dossier" for that faction.
Like a ship, a dossier has specialties and hardpoints. This dossier specializes in freight permissions. This one improves insurance and rates on being a passenger liner. This one's exploration-based.
The hardpoints are people. This one's a tier 3 diplomat hard point, and you can slot in any NPC diplomat that rank or lower to act as your "weapon", giving you access to more options, more goods, more security, more sites. Reduce the rank by one just like you'd do for hardpoint turrets, and hire that person as a crewmember on your ship instead of being specific to their home space station...
Because the dossiers are essentially ships, we can offload our survival mechanics onto them.
As time passes and things happen, you might gain criminality, or disinterest, or distrust. These can be reduced if you equip the right kind of person on your hardpoints, but otherwise you'll have to do faction missions to clean them up.
And now, again, we've turned a challenge into a narrative.
Building small dossiers is easy, but you quickly learn you need to tweak it to suit your style. Do you do some... not so legal missions? You'll want a lawyer and a fence installed. Do you do a lot of business with other factions? You'll want a politician, to keep the distrust low. You go on long journeys? You'll want a reporter, to keep disinterest under control. You trade with a lot of different systems from that faction? Buy a one-rank-lower trader as a crewmember, so you get that advantage in every system.
These could even be tweaked per-faction. Both by the player, depending on their interactions with the faction... and by the devs.
Your Vulcan-ish faction might never gain disinterest, but gives bonus distrust if you sell science data to other factions. Your Klingon-ish faction loses interest extremely rapidly but never gives out criminality...
This has an extremely high ceiling. At upper levels, you might be adding the president of a space station to your dossier, or using a cross-contact politician to transfer stats to another faction's dossier.
And you can go negative. You're disliked by the Vulcan-ish faction? Add specific nemesis to your unhappy dossier. It's got a few good hard points - contacts from other factions or even turncoats from this faction - but you have to fill all your negative hardpoints first, adding in suspicious cops, angry politicians, and persistent bounty hunters.
Again: build your own narrative out of the challenge. *You choose* how your story of banditry or war unfolds.
...
Hopefully this has been a fun exploration of how to make player-created content that can turn simple things (survival, faction rank) into more robust, soft, complex mechanics that create a narrative.
To be clear: I think you could create an entire game around these concepts, rather than the shooty pew pew gameplay that I find so dreary.
There's also a lot to talk about in regards to things like resource tiering and keeping inflation under control, and it's tightly related. But... I think this is long enough.
Showing posts with label multiplayer. Show all posts
Showing posts with label multiplayer. Show all posts
Tuesday, June 18, 2019
Friday, October 10, 2014
Mechanics as Self-Expression
For the past week I've alternated between talking about mods and talking about collaborative content, but today I'd like to combine the two.
One of the things I like about Kerbal is that everyone has such different priorities, and installs a completely different set of mods. I think most moddable games are like this, but in Kerbal it's really really clear because the majority of mods are visible the majority of the time.
In the end, every high-level Kerbal player has very strong opinions on which mods are the most fun. In turn they have a game that plays completely differently, with very different mission objectives or methods.
Then I started to think about collaboration.
Most of the time, when I think of collaboration I think of players expressing themselves artistically.
When I think of mechanics, I think of cooperation. People working together to get a good statistical result. But that's not really the kind of collaboration I'm talking about, because it's normally just players trying to implement an ideal solution, not players expressing themselves.
But if we make the mechanics of the game part of their self-expression, that suddenly changes.
Previously, creating something in the game world was mostly about either expressing yourself OR accomplishing objectives. But if the players can choose the mechanics they include, now creating things is both at the same time, because your mechanical options are a result of your self-expression.
Collaborations can arise within this space. For example, in a fictional version of Kerbal, one player has the faster-than-light mod installed, and another has the karbonite resource-mining mod installed.
The two players can collaborate. Use FTL ships to move mined materials between distant planets. Restock your long-range transports at colonies that produce life support resources.
If the mods are created with the intent to help collaborate with people who aren't using the mods, there would also be additional parts. Set up an FTL beacon so ships without FTL-mod drives can travel faster than light. Set up an automatic waystation that can hurl goods into space without needing direct docking or control, to allow the other player to get resources from you even if your mods are incompatible...
Even in a game with no mods, this sort of collaboration is possible. However, it requires a certain approach.
Let's consider a tabletop RPG.
The issue with this kind of collaboration is that it requires the creation of long-term content. Classically, most of the collaboration in a tabletop game comes from social collaboration - telling stories together, acting out something together, choosing a path together. These don't require a long-term record of your choices, although you can certainly have one.
But with mechanical collaboration, I can't see any way aside from using a long-term record.
With that in mind, this is a tabletop RPG where the players do a lot of creating. You actually create a lot in every tabletop RPG - your avatar is a bundle of creative choices. However, you rarely collaborate with others regarding the specifics of your character sheet. Instead, it makes more sense to move those choices somewhere more convenient and shareable.
My thought is that the game could be about makers of some kind. Perhaps it's about mecha, or pokemon, or it's a hacker game, or maybe it takes place in dreams, or it's a Harry Potter game where you get to invent spells and enchantments...
The "classes" wouldn't be about the role these people play in combat. Instead, you would choose a few classes, and each class would contain an entirely different kind of infrastructure you would build with.
For example, if it was a Harry Potterlike, you might choose "potions". This would allow you to brew up potions, which in turn means you'll need to keep a stock of various potions. But you don't choose potions alone: you also have another class. Say, "botany", the study of plants. These get along well together, since plants provide many ingredients for potions... and there are potions that enhance plants. So as you build up your infrastructure for each class, you get synergy and they build each other up.
Potions and botany seem like they go particularly well together due to the fact that plants make good ingredients, but there's nothing mechanically linking them aside from the output of one going into the input of another. Which means that the two don't actually mix very well and aren't very interesting to combine. You have a garden, you have an alchemy lab, and never the twain shall meet.
To fix that, we use a "Kerbalish" system, where all our classes invest in shared infrastructure. In this case, you are allowed a certain amount of space in an environment of your choice. Like a Kerbal rocket launch, you design your rocket around all your mods. So our space would naturally try to combine botany and alchemy in one space when possible.
Each comes seeded with concepts that can help the other. The tools you would use for the extensive and prolonged brewing processes are also valuable in gardening: drip-feeding plants, hydroponics, delivering magical fertilizer, and so on. Gardening concepts are valuable in your alchemy lab: leeching from still-growing plants, using gentle sunlight, soil-filtered modules, fermentation, mold - all of these can be used in an alchemical setup. And, in any given setup, it might be difficult to see where one kind of lab ends and another begins.
It's not that botany and alchemy have a particularly deep bond, either. All the classes support each other in this way, and most players will choose, say, three.
The key to this is that the player has to build medium-duration constructs as part of their play. The player doesn't get a mortar and pestle and mix up whatever potion she needs today. Instead, if she wants to brew healing potions, she'll make that a dedicated part of her next setup. If she wants to grow pixieleaf, she'll have part of her next setup dedicated to that. And then, a month later, she'll get another chance to build something. And, during that month, who knows what resources she'll find on her adventures to help her build her next setup?
This seems quite complex, dumping all this interactive machinery on the players, but it is a gentle learning curve. When you start, it's all very basic space management - how much stuff can you fit on a tabletop, a windowsill?
Complications are gradually introduced in the same way as any RPG.
The whole thing needs to synergizes with the adventure phase. There needs to be a nice resonance. To that end, the adventures have to be carefully constructed to allow you to benefit from your setups, and also to gain new resources/information that will help you in your following setups.
We also have to allow players to collaborate with each other. That's pretty easy, it's just a matter of how far we want to take it. The more freely players can add to each other's setups, the more each class needs to diverge as you level up.
If only you can add alchemical stuff to your garden, then the alchemy class can be pretty linear. But if anyone with the alchemy class can add stuff to your garden, then each person needs their own, very different concept of how alchemy should work. Otherwise there's no advantage to having multiple alchemists.
Well, anyway, that's just a quick example, half of a Harry-Potterlike. You can do the same kind of thing with any setting. Just make sure that the classes build with each other on a shared framework, and resonate well with the more active play sections.
There are also other options, such as having these things be part of the active play session... I've barely scratched the surface of the possibilities here.
One of the things I like about Kerbal is that everyone has such different priorities, and installs a completely different set of mods. I think most moddable games are like this, but in Kerbal it's really really clear because the majority of mods are visible the majority of the time.
In the end, every high-level Kerbal player has very strong opinions on which mods are the most fun. In turn they have a game that plays completely differently, with very different mission objectives or methods.
Then I started to think about collaboration.
Most of the time, when I think of collaboration I think of players expressing themselves artistically.
When I think of mechanics, I think of cooperation. People working together to get a good statistical result. But that's not really the kind of collaboration I'm talking about, because it's normally just players trying to implement an ideal solution, not players expressing themselves.
But if we make the mechanics of the game part of their self-expression, that suddenly changes.
Previously, creating something in the game world was mostly about either expressing yourself OR accomplishing objectives. But if the players can choose the mechanics they include, now creating things is both at the same time, because your mechanical options are a result of your self-expression.
Collaborations can arise within this space. For example, in a fictional version of Kerbal, one player has the faster-than-light mod installed, and another has the karbonite resource-mining mod installed.
The two players can collaborate. Use FTL ships to move mined materials between distant planets. Restock your long-range transports at colonies that produce life support resources.
If the mods are created with the intent to help collaborate with people who aren't using the mods, there would also be additional parts. Set up an FTL beacon so ships without FTL-mod drives can travel faster than light. Set up an automatic waystation that can hurl goods into space without needing direct docking or control, to allow the other player to get resources from you even if your mods are incompatible...
Even in a game with no mods, this sort of collaboration is possible. However, it requires a certain approach.
Let's consider a tabletop RPG.
The issue with this kind of collaboration is that it requires the creation of long-term content. Classically, most of the collaboration in a tabletop game comes from social collaboration - telling stories together, acting out something together, choosing a path together. These don't require a long-term record of your choices, although you can certainly have one.
But with mechanical collaboration, I can't see any way aside from using a long-term record.
With that in mind, this is a tabletop RPG where the players do a lot of creating. You actually create a lot in every tabletop RPG - your avatar is a bundle of creative choices. However, you rarely collaborate with others regarding the specifics of your character sheet. Instead, it makes more sense to move those choices somewhere more convenient and shareable.
My thought is that the game could be about makers of some kind. Perhaps it's about mecha, or pokemon, or it's a hacker game, or maybe it takes place in dreams, or it's a Harry Potter game where you get to invent spells and enchantments...
The "classes" wouldn't be about the role these people play in combat. Instead, you would choose a few classes, and each class would contain an entirely different kind of infrastructure you would build with.
For example, if it was a Harry Potterlike, you might choose "potions". This would allow you to brew up potions, which in turn means you'll need to keep a stock of various potions. But you don't choose potions alone: you also have another class. Say, "botany", the study of plants. These get along well together, since plants provide many ingredients for potions... and there are potions that enhance plants. So as you build up your infrastructure for each class, you get synergy and they build each other up.
Potions and botany seem like they go particularly well together due to the fact that plants make good ingredients, but there's nothing mechanically linking them aside from the output of one going into the input of another. Which means that the two don't actually mix very well and aren't very interesting to combine. You have a garden, you have an alchemy lab, and never the twain shall meet.
To fix that, we use a "Kerbalish" system, where all our classes invest in shared infrastructure. In this case, you are allowed a certain amount of space in an environment of your choice. Like a Kerbal rocket launch, you design your rocket around all your mods. So our space would naturally try to combine botany and alchemy in one space when possible.
Each comes seeded with concepts that can help the other. The tools you would use for the extensive and prolonged brewing processes are also valuable in gardening: drip-feeding plants, hydroponics, delivering magical fertilizer, and so on. Gardening concepts are valuable in your alchemy lab: leeching from still-growing plants, using gentle sunlight, soil-filtered modules, fermentation, mold - all of these can be used in an alchemical setup. And, in any given setup, it might be difficult to see where one kind of lab ends and another begins.
It's not that botany and alchemy have a particularly deep bond, either. All the classes support each other in this way, and most players will choose, say, three.
The key to this is that the player has to build medium-duration constructs as part of their play. The player doesn't get a mortar and pestle and mix up whatever potion she needs today. Instead, if she wants to brew healing potions, she'll make that a dedicated part of her next setup. If she wants to grow pixieleaf, she'll have part of her next setup dedicated to that. And then, a month later, she'll get another chance to build something. And, during that month, who knows what resources she'll find on her adventures to help her build her next setup?
This seems quite complex, dumping all this interactive machinery on the players, but it is a gentle learning curve. When you start, it's all very basic space management - how much stuff can you fit on a tabletop, a windowsill?
Complications are gradually introduced in the same way as any RPG.
The whole thing needs to synergizes with the adventure phase. There needs to be a nice resonance. To that end, the adventures have to be carefully constructed to allow you to benefit from your setups, and also to gain new resources/information that will help you in your following setups.
We also have to allow players to collaborate with each other. That's pretty easy, it's just a matter of how far we want to take it. The more freely players can add to each other's setups, the more each class needs to diverge as you level up.
If only you can add alchemical stuff to your garden, then the alchemy class can be pretty linear. But if anyone with the alchemy class can add stuff to your garden, then each person needs their own, very different concept of how alchemy should work. Otherwise there's no advantage to having multiple alchemists.
Well, anyway, that's just a quick example, half of a Harry-Potterlike. You can do the same kind of thing with any setting. Just make sure that the classes build with each other on a shared framework, and resonate well with the more active play sections.
There are also other options, such as having these things be part of the active play session... I've barely scratched the surface of the possibilities here.
Thursday, October 09, 2014
Cooperative vs Collaborative
Recently I've hit on some really neat little ideas. They came from one basic concept: there is a line between cooperative play and collaborative play. They are different.
Right now, collaborative play doesn't exist in computer games. There are collaborative games, but they don't involve collaborative play. For example, in Spore you collaborate with the player base to populate the universe with aliens - but there's no play involved. It just happens. Similarly, in Sim City you can collaborate by having neighboring cities, but the only "play" involved is trying to have the right kinds of inputs and outputs.
Mods are collaborative by nature, but although they create play, they don't use collaborative play. They are created by one person and used by another without any play between the two.
I think this is a big oversight. I think there is a lot of potential that we haven't really investigated.
There are things with collaborative play. Most tabletop RPGs are collaborative. The underlying structure of the game provides a framework of statistics and mechanics, and the players can build their own stories on top of that foundation. Putting aside the actions of the GM, the players collaborate with each other to distinguish their characters, move the experience in the way they prefer, and help augment another player's actions.
Jazz is collaborative in basically the same way. The foundation of jazz is a set of musical patterns that give everyone a similar foundation. They can collaborate with each other to distinguish themselves, move the experience in a way they like, and augment other players' music.
Most collaborative play today is face to face, and uses the incredibly fluid and nuanced signals inherent in human socialization. This allows collaborators to "stay on the same page", and collaborate tightly with each other.
However, that's not really possible in a video game. The most nuanced signals in a video game are less nuanced than a facial expression, and they flow less smoothly. Even incidental signals, like the timing of your turn, are more effort than a raised eyebrow.
We just have to live with that. We need to live with the fact that, aside from voice chat, we're going to rely on in-game signaling to synchronize our collaborators. That means slower, rougher, more awkward synchs.
The good news is that it also means we can save and play back signals.
The basic idea is that we can trickle in a bunch signals bit by bit, then let them flow over another user all at once. Asynchronous collaboration.
Minecraft multiplayer is probably the biggest current example of this. In shared universes, you can collaborate really entertainingly. This is often done asynchronously - the players aren't directly working on the same rooms at the same time. In fact, if playing is done synchronously, it's often cooperative play (exploring/mining ore) rather than collaborative play (building houses).
Asynchronous construction allows players to spend hours building their house on their own, without a whole lot of interference. Other players that visit the house are exposed to all those decisions in a quick and fluid experience as they wander around the house. It can even be done synchronously, with the host explaining the house as you walk. The host sets the stage ("this is the bedroom, and there's a secret passage behind the bookshelf...") and the nuance is provided by the level (exact placement of beds, nature of ceiling, choice of furniture, etc).
Minecraft doesn't really focus on that idea, so let's take this a few steps further.
The first step we want to take is to step on our own feet.
Because our game is the storehouse of signals, we can play back signals whenever we like. That includes allowing the player to collaborate with themself.
Let's draw the idea more clearly using The Sims.
In The Sims, you will typically play off of your own content. You have a house full of people, and you make decisions based on the nature of those people. However, even though each day builds off the last day, you are not "collaborating with yourself" in the way we're talking about, because the content is not represented as if it belonged to someone else. You always have full authority.
Now, on the other hand, if you build a second family in that neighborhood and invite the first family over - now you are collaborating with yourself. The original family is no longer "yours". They are presented as if they were created and controlled by someone else, and that someone else just happens to be "past you".
The Sims doesn't have a lot of persistent nuanced signals, so this collaboration isn't as rich as it might be. Mostly, The Sims relies on a player's internal fictions - if I download your family, I won't glimpse the rich lives you've built around them. The only signal from you that I can see is their appearance and maybe their basic personality.
Now, Kerbal has a LOT of persistent nuanced signals. Not just because the ships can be designed so diversely, no - that's only a small part of it. It's because modding plays a huge role in how Kerbal plays. You can tell which mods someone has installed by the parts on their ships, yeah. But you can also tell what role within the arc of that mod the ship plays, and how the player is interleaving their mods.
These gameplay-centric signals are a great idea, but it does require that the game vary massively from player to player, to the point where each player has an exceptionally wide number of in-game, mechanically-supported goals.
In Minecraft, that's not usually the case. No matter how awesome your house is, there's only a few mechanically-supported goals, and most of them aren't very nuanced. Instead, the value of a home in Minecraft lies in its sense of style.
This lets players put some of their personal style into the house, but I don't think that's anywhere near good enough. See, most people are not architects. We can build voxel homes, but we can't communicate very well with the nuances of these designs.
Most players are concerned with being people. So... perhaps the signals we should let them build should reflect the fictional people in the world?
A lot of Minecraft mansions try to do just that. The mansion is filled with decorations that suit the fictional lives of the player. Nonfunctional furniture, desks that will never get used, decorative racks of armor that will never be appreciated...
Some of the mansions contain multiple fictional people living fictional lives. "This ship I built has 12 sailors. This is where they sleep, this is where they eat..."
But that's just the surface of what's possible if we actually let the players create that content instead of just keeping it in their head where nobody else can see it.
There are a lot of possible ways to let players build their own people-living-lives content. One is to let them place NPCs. However, I think that's not very good, because NPC behavior will be very sterile, especially if modded furniture is introduced and they don't know what to make of it.
My recommendation instead is to build machinima systems. IE, you become a sailor. You "record" yourself sleeping in a bunk, eating at a table, scrubbing the floor. NPCs can play back those recorded bits, with the sterile pieces of their behavior being limited to pathfinding from bit to bit.
Allow bits to link up: I record myself as a pirate captain, I record myself responding to my pirate captain as a first mate, and now there are skits that can play. Collaborating with myself.
This is a very basic system that doesn't take into account how these NPCs should react to a new presence. But it's a damn sight more interesting than not having NPCs.
Players that are allowed to can further build out your scenario. Adding new places, new skits, new NPCs...
Sounds like a pretty great way to add nuanced content and collaborate with other players.
Sounds fun to me!
This is just one of the ideas that started to arise when I started to think about collaboration as a distinct kind of play. There's lots of space here!
Right now, collaborative play doesn't exist in computer games. There are collaborative games, but they don't involve collaborative play. For example, in Spore you collaborate with the player base to populate the universe with aliens - but there's no play involved. It just happens. Similarly, in Sim City you can collaborate by having neighboring cities, but the only "play" involved is trying to have the right kinds of inputs and outputs.
Mods are collaborative by nature, but although they create play, they don't use collaborative play. They are created by one person and used by another without any play between the two.
I think this is a big oversight. I think there is a lot of potential that we haven't really investigated.
There are things with collaborative play. Most tabletop RPGs are collaborative. The underlying structure of the game provides a framework of statistics and mechanics, and the players can build their own stories on top of that foundation. Putting aside the actions of the GM, the players collaborate with each other to distinguish their characters, move the experience in the way they prefer, and help augment another player's actions.
Jazz is collaborative in basically the same way. The foundation of jazz is a set of musical patterns that give everyone a similar foundation. They can collaborate with each other to distinguish themselves, move the experience in a way they like, and augment other players' music.
Most collaborative play today is face to face, and uses the incredibly fluid and nuanced signals inherent in human socialization. This allows collaborators to "stay on the same page", and collaborate tightly with each other.
However, that's not really possible in a video game. The most nuanced signals in a video game are less nuanced than a facial expression, and they flow less smoothly. Even incidental signals, like the timing of your turn, are more effort than a raised eyebrow.
We just have to live with that. We need to live with the fact that, aside from voice chat, we're going to rely on in-game signaling to synchronize our collaborators. That means slower, rougher, more awkward synchs.
The good news is that it also means we can save and play back signals.
The basic idea is that we can trickle in a bunch signals bit by bit, then let them flow over another user all at once. Asynchronous collaboration.
Minecraft multiplayer is probably the biggest current example of this. In shared universes, you can collaborate really entertainingly. This is often done asynchronously - the players aren't directly working on the same rooms at the same time. In fact, if playing is done synchronously, it's often cooperative play (exploring/mining ore) rather than collaborative play (building houses).
Asynchronous construction allows players to spend hours building their house on their own, without a whole lot of interference. Other players that visit the house are exposed to all those decisions in a quick and fluid experience as they wander around the house. It can even be done synchronously, with the host explaining the house as you walk. The host sets the stage ("this is the bedroom, and there's a secret passage behind the bookshelf...") and the nuance is provided by the level (exact placement of beds, nature of ceiling, choice of furniture, etc).
Minecraft doesn't really focus on that idea, so let's take this a few steps further.
The first step we want to take is to step on our own feet.
Because our game is the storehouse of signals, we can play back signals whenever we like. That includes allowing the player to collaborate with themself.
Let's draw the idea more clearly using The Sims.
In The Sims, you will typically play off of your own content. You have a house full of people, and you make decisions based on the nature of those people. However, even though each day builds off the last day, you are not "collaborating with yourself" in the way we're talking about, because the content is not represented as if it belonged to someone else. You always have full authority.
Now, on the other hand, if you build a second family in that neighborhood and invite the first family over - now you are collaborating with yourself. The original family is no longer "yours". They are presented as if they were created and controlled by someone else, and that someone else just happens to be "past you".
The Sims doesn't have a lot of persistent nuanced signals, so this collaboration isn't as rich as it might be. Mostly, The Sims relies on a player's internal fictions - if I download your family, I won't glimpse the rich lives you've built around them. The only signal from you that I can see is their appearance and maybe their basic personality.
Now, Kerbal has a LOT of persistent nuanced signals. Not just because the ships can be designed so diversely, no - that's only a small part of it. It's because modding plays a huge role in how Kerbal plays. You can tell which mods someone has installed by the parts on their ships, yeah. But you can also tell what role within the arc of that mod the ship plays, and how the player is interleaving their mods.
These gameplay-centric signals are a great idea, but it does require that the game vary massively from player to player, to the point where each player has an exceptionally wide number of in-game, mechanically-supported goals.
In Minecraft, that's not usually the case. No matter how awesome your house is, there's only a few mechanically-supported goals, and most of them aren't very nuanced. Instead, the value of a home in Minecraft lies in its sense of style.
This lets players put some of their personal style into the house, but I don't think that's anywhere near good enough. See, most people are not architects. We can build voxel homes, but we can't communicate very well with the nuances of these designs.
Most players are concerned with being people. So... perhaps the signals we should let them build should reflect the fictional people in the world?
A lot of Minecraft mansions try to do just that. The mansion is filled with decorations that suit the fictional lives of the player. Nonfunctional furniture, desks that will never get used, decorative racks of armor that will never be appreciated...
Some of the mansions contain multiple fictional people living fictional lives. "This ship I built has 12 sailors. This is where they sleep, this is where they eat..."
But that's just the surface of what's possible if we actually let the players create that content instead of just keeping it in their head where nobody else can see it.
There are a lot of possible ways to let players build their own people-living-lives content. One is to let them place NPCs. However, I think that's not very good, because NPC behavior will be very sterile, especially if modded furniture is introduced and they don't know what to make of it.
My recommendation instead is to build machinima systems. IE, you become a sailor. You "record" yourself sleeping in a bunk, eating at a table, scrubbing the floor. NPCs can play back those recorded bits, with the sterile pieces of their behavior being limited to pathfinding from bit to bit.
Allow bits to link up: I record myself as a pirate captain, I record myself responding to my pirate captain as a first mate, and now there are skits that can play. Collaborating with myself.
This is a very basic system that doesn't take into account how these NPCs should react to a new presence. But it's a damn sight more interesting than not having NPCs.
Players that are allowed to can further build out your scenario. Adding new places, new skits, new NPCs...
Sounds like a pretty great way to add nuanced content and collaborate with other players.
Sounds fun to me!
This is just one of the ideas that started to arise when I started to think about collaboration as a distinct kind of play. There's lots of space here!
Friday, December 20, 2013
Immediacy in Online Games
Well, the term "MMORPG" is really obsolete, so let's refine how we talk about online games!
There are two pieces to how players interact in online games, and these pieces are simply not talked about much. I don't even think there's defined terms for them. The two pieces are the number of players interacting, and the immediacy of their interactions.
So I'll propose some terms for immediacy, some ways to think about online games.
Pitched immediacy: When lag severely impacts how well players can interact. Usually only matters in battles alongside or against other humans, although some battles are lag-resistant and some non-battle situations might be lag-vulnerable. Due to the difficulties involved with both technology and player awareness, the number of players involved in pitched immediacy is typically pretty low.
Critical immediacy: When players interact in near real-time while tightly bound together. Lag isn't a serious issue, but a player dropping out entirely for a few minutes would be pretty serious. This is typically the "party" part of the game, and may include lag-resistant combat sections. It may also include chatrooms and so on: it doesn't require avatar-on-avatar interactions. The number of players is often quite low due to cat-herding-related difficulties.
Noncritical immediacy: When players interact in near real-time, but loosely bound. If a player drops out, the other players can continue on without much difficulty - or perhaps without even noticing. This typically includes non-party interplayer dynamics, such as wandering around a town where other players are hanging out.
Asynchronous immediacy: When players interact in a way that has a flexible gap between action and reaction, allowing players to interact without being available at the same time or place. Please note this is about interacting with players, not with the game. Skills that grow in real-time, for example, are not players interacting with other players. Messaging someone is, and the giant forum accompanying any large game is also asynchronous immediacy even though the game itself is not actually involved.
Prepared immediacy: When a player doesn't have much (or any) control at the moment of interaction, but has set it up so that things unfold according to their preference. Things like auto-shops, guilds, homes that can be visited, and "NPCified" parties are all prepared immediacy. Creating content and then allowing other players to use/experience it is also prepared immediacy. Actually, drawing fanart or making music videos may also be prepared immediacy, even though the game is not really directly involved.
Incidental immediacy: When a player interacts with other players accidentally or indirectly without really meaning to. Auction houses are a big one, here. Maintaining wikis is another. Also, in some games you can create content that is automatically reshared with others (such as Spore). This "massively single player" style content is also incidental immediacy.
Anyway, those are my suggestions.
As you can tell, every game has more than just the game. The community around the game will start up asynchronous, prepared, and incidental interactions outside of the game itself. But these kinds of immediacies can also be part of the game design from the start.
In many cases, the feel of a game is easy to understand once you start putting numbers into these different tiers. Like in City of Heroes, you could argue that there are typically 1-6 players in pitched immediacy, the same for critical, but several thousand for noncritical immediacy due to the shared cityscape. Functionally, that "several thousand" is more like 80 or so due to the way the city is constructed and the way the servers are sharded.
Those are my suggestions. Let me know what your thoughts are.
There are two pieces to how players interact in online games, and these pieces are simply not talked about much. I don't even think there's defined terms for them. The two pieces are the number of players interacting, and the immediacy of their interactions.
So I'll propose some terms for immediacy, some ways to think about online games.
Pitched immediacy: When lag severely impacts how well players can interact. Usually only matters in battles alongside or against other humans, although some battles are lag-resistant and some non-battle situations might be lag-vulnerable. Due to the difficulties involved with both technology and player awareness, the number of players involved in pitched immediacy is typically pretty low.
Critical immediacy: When players interact in near real-time while tightly bound together. Lag isn't a serious issue, but a player dropping out entirely for a few minutes would be pretty serious. This is typically the "party" part of the game, and may include lag-resistant combat sections. It may also include chatrooms and so on: it doesn't require avatar-on-avatar interactions. The number of players is often quite low due to cat-herding-related difficulties.
Noncritical immediacy: When players interact in near real-time, but loosely bound. If a player drops out, the other players can continue on without much difficulty - or perhaps without even noticing. This typically includes non-party interplayer dynamics, such as wandering around a town where other players are hanging out.
Asynchronous immediacy: When players interact in a way that has a flexible gap between action and reaction, allowing players to interact without being available at the same time or place. Please note this is about interacting with players, not with the game. Skills that grow in real-time, for example, are not players interacting with other players. Messaging someone is, and the giant forum accompanying any large game is also asynchronous immediacy even though the game itself is not actually involved.
Prepared immediacy: When a player doesn't have much (or any) control at the moment of interaction, but has set it up so that things unfold according to their preference. Things like auto-shops, guilds, homes that can be visited, and "NPCified" parties are all prepared immediacy. Creating content and then allowing other players to use/experience it is also prepared immediacy. Actually, drawing fanart or making music videos may also be prepared immediacy, even though the game is not really directly involved.
Incidental immediacy: When a player interacts with other players accidentally or indirectly without really meaning to. Auction houses are a big one, here. Maintaining wikis is another. Also, in some games you can create content that is automatically reshared with others (such as Spore). This "massively single player" style content is also incidental immediacy.
Anyway, those are my suggestions.
As you can tell, every game has more than just the game. The community around the game will start up asynchronous, prepared, and incidental interactions outside of the game itself. But these kinds of immediacies can also be part of the game design from the start.
In many cases, the feel of a game is easy to understand once you start putting numbers into these different tiers. Like in City of Heroes, you could argue that there are typically 1-6 players in pitched immediacy, the same for critical, but several thousand for noncritical immediacy due to the shared cityscape. Functionally, that "several thousand" is more like 80 or so due to the way the city is constructed and the way the servers are sharded.
Those are my suggestions. Let me know what your thoughts are.
Friday, August 09, 2013
Alternate Mod Multiplayer
I said this in passing on Twitter, but the more I think about it, the better an idea it seems to be.
Part one: multiplayer Kerbal. A shared universe where you can dock at each other's space stations and so on. I think it'd be a lot more fun to build things if other people could see what you built. The complexity here is in the inherent asynchronous nature of the game, but I think you could use a combination of check-ins and flight reviews to handle that. So if I launch a rocket, then the other players can watch how it is going/how it went at whatever speeds they like, including allowing me to make notes (audio or text) explaining things.
Live multiplayer might also be possible and fun, with each player controlling a piece of the mission. For example, one player launching a rocket and the other player tracking it and beaming power to it.
Part two: multiplayer Kerbal with mods.
Here's the key: each player can have different mods installed. Think of it as each player being a different nationality, and each nation having slightly different technologies. If you want to change out your mods, just switch nationalities - or create a new nationality that has the mods you want.
Part mods tend to work very well with each other - there's not going to be a crash because you installed three different kinds of fuselage parts. But operational mods do tend to conflict and crash, at least in the older versions. I say - okay! Let's make that a part of the gameplay! If you have operational mods installed and they conflict then, guess what? The the technologies aren't compatible. One nation should have one, another nation the other! You can download "nation packs" of parts and mods as well as downloading those separately, allowing for a wider variety of customization. Nation packs could also alter things like texture packs, flags, Kerbin colors...
Multiplayer games could therefore be with each player playing a given nation, giving them unique capabilities. I might have those giant 5-meter launch arrays, but I don't have the enregy-beaming capabilities that my friend does. Maybe I launch one of his payloads on one of my rockets! I can't use his ship - that mod isn't active for me, so I can't take control - but, conversely, he can't take control of the launch stage. Cooperation!
Also, very relaxed asynchronicity as we need it. I could simply hit "pause" on the mission when I separate from his payload, then check in the universe. He would then be able to play that mission out visually, see my commentary, and immediately take control over his payload when he hits the end of the recorded mission.
Of course, you could do all the same things single player, but it wouldn't be as interesting...
Anyway, I like the idea. It's sort of like allowing players to have different tech trees, but with player-constructed mods as the "levels" of the "tree" instead of pre-planning it!
Part one: multiplayer Kerbal. A shared universe where you can dock at each other's space stations and so on. I think it'd be a lot more fun to build things if other people could see what you built. The complexity here is in the inherent asynchronous nature of the game, but I think you could use a combination of check-ins and flight reviews to handle that. So if I launch a rocket, then the other players can watch how it is going/how it went at whatever speeds they like, including allowing me to make notes (audio or text) explaining things.
Live multiplayer might also be possible and fun, with each player controlling a piece of the mission. For example, one player launching a rocket and the other player tracking it and beaming power to it.
Part two: multiplayer Kerbal with mods.
Here's the key: each player can have different mods installed. Think of it as each player being a different nationality, and each nation having slightly different technologies. If you want to change out your mods, just switch nationalities - or create a new nationality that has the mods you want.
Part mods tend to work very well with each other - there's not going to be a crash because you installed three different kinds of fuselage parts. But operational mods do tend to conflict and crash, at least in the older versions. I say - okay! Let's make that a part of the gameplay! If you have operational mods installed and they conflict then, guess what? The the technologies aren't compatible. One nation should have one, another nation the other! You can download "nation packs" of parts and mods as well as downloading those separately, allowing for a wider variety of customization. Nation packs could also alter things like texture packs, flags, Kerbin colors...
Multiplayer games could therefore be with each player playing a given nation, giving them unique capabilities. I might have those giant 5-meter launch arrays, but I don't have the enregy-beaming capabilities that my friend does. Maybe I launch one of his payloads on one of my rockets! I can't use his ship - that mod isn't active for me, so I can't take control - but, conversely, he can't take control of the launch stage. Cooperation!
Also, very relaxed asynchronicity as we need it. I could simply hit "pause" on the mission when I separate from his payload, then check in the universe. He would then be able to play that mission out visually, see my commentary, and immediately take control over his payload when he hits the end of the recorded mission.
Of course, you could do all the same things single player, but it wouldn't be as interesting...
Anyway, I like the idea. It's sort of like allowing players to have different tech trees, but with player-constructed mods as the "levels" of the "tree" instead of pre-planning it!
Thursday, February 14, 2013
Pangame Multiplayer
There's a steadily rising amount of buzz about the concept of recording your gameplay footage automatically, so you can share it instantly if you think "oh that was cool!" This is already common in fighting games, but it's popping up in various other places. Evidently, it's going to be an automatic feature of the PS4, at least.
I really think it's a great idea, but not for the idea of sharing your plays in video form. No, I think it's great because it enables pangame multiplayer.
Let's say I design a number of semi-casual semi-social games. In the first one you play a hero who wanders the land killing monsters and collecting loot. The second one is a word-forming game like Boggle. The third is a Farmville-esque game.
Each of these games stands on their own well enough, with some social gaming hooks as such games tend to have. However, each game also automatically records the last thirty seconds of your gameplay. And participates in the "pangame API".
The "pangame API" is a game-agnostic event stream. Each game can connect to any other participant(s) and stream events to them. For example, if you make a word combo in your Boggle clone, you send out a 'success!' event with the point value attached. The other game catches it and interprets it. If the other game is also the Boggle clone, then you might increase their timer or, if competitive, lock down a few of their letters.
But if another game is the other participant, it also catches the event just fine. The Farmville game interprets the success as a burst of productivity on your cows. The wandering hero interprets it as an HP-restore or, if competitive, a new monster entering the fray.
By laying down a foundation of basic multiplayer events, you can allow two players playing completely different games to still cooperate or compete. Whether the two people are sitting in the same living room, Skyping across states, or even have never met, they are gaming together. Of course, it's no fun to just randomly see things pop up and not have any clue what's going on with the other player, so that's where the auto-recorded video comes into play.
When the Boggle player finds a good word, it sends out the points event, yes. But it also sends out an audiovideo "blurb" that lets the other player see what's going on. There can also be a number of small "touch" events that don't change game state, but keep the two players connected via video. This kind of awareness is important in any kind of multiplayer game.
The API can be a lot more complex than that. Each game has the standard events, yes, but each game also has a number of call-and-response challenges.
For example, the Boggle game could get a message from the hero game: "My player is in dire trouble, your player needs to accomplish a medium-difficulty task to save him!" The Boggle game goes "medium difficulty, hmmm, okay: my player! Save the other guy by forming a word starting with 'K'!" And the Boggle game ALSO goes: "Hey hero game, here's a video stream of me challenging my player to do that!"
The hero game never knows what challenge the Boggle game has issued its player. To the hero game, it doesn't matter what game the other player is playing. Just that the quest was accepted and if it was accomplished. It doesn't understand what the video contains - the video is a message to the player to let the player know what's going on in the other game. The hero game doesn't really know or care.
On the other end of the spectrum, the Farmville game might say "hey, you, friend game over there! I have some resource trading stored up. Offer some resources for resources, would you?" And the Boggle game would go "Hey, my player: every letter you use in the next word will be sent over to your buddy and replaced with a random GOLD letter."
Or the hero game could go "I cleared out this level with this event trail yesterday. You want to do a ghost race against it?"
Obviously, there are concerns with spoofing or game balance, but there are always issues with such things. Fundamentally, I think this would be a great way to let players cooperate even when they aren't interested in playing the same game at the same time on the same type of device.
I really think it's a great idea, but not for the idea of sharing your plays in video form. No, I think it's great because it enables pangame multiplayer.
Let's say I design a number of semi-casual semi-social games. In the first one you play a hero who wanders the land killing monsters and collecting loot. The second one is a word-forming game like Boggle. The third is a Farmville-esque game.
Each of these games stands on their own well enough, with some social gaming hooks as such games tend to have. However, each game also automatically records the last thirty seconds of your gameplay. And participates in the "pangame API".
The "pangame API" is a game-agnostic event stream. Each game can connect to any other participant(s) and stream events to them. For example, if you make a word combo in your Boggle clone, you send out a 'success!' event with the point value attached. The other game catches it and interprets it. If the other game is also the Boggle clone, then you might increase their timer or, if competitive, lock down a few of their letters.
But if another game is the other participant, it also catches the event just fine. The Farmville game interprets the success as a burst of productivity on your cows. The wandering hero interprets it as an HP-restore or, if competitive, a new monster entering the fray.
By laying down a foundation of basic multiplayer events, you can allow two players playing completely different games to still cooperate or compete. Whether the two people are sitting in the same living room, Skyping across states, or even have never met, they are gaming together. Of course, it's no fun to just randomly see things pop up and not have any clue what's going on with the other player, so that's where the auto-recorded video comes into play.
When the Boggle player finds a good word, it sends out the points event, yes. But it also sends out an audiovideo "blurb" that lets the other player see what's going on. There can also be a number of small "touch" events that don't change game state, but keep the two players connected via video. This kind of awareness is important in any kind of multiplayer game.
The API can be a lot more complex than that. Each game has the standard events, yes, but each game also has a number of call-and-response challenges.
For example, the Boggle game could get a message from the hero game: "My player is in dire trouble, your player needs to accomplish a medium-difficulty task to save him!" The Boggle game goes "medium difficulty, hmmm, okay: my player! Save the other guy by forming a word starting with 'K'!" And the Boggle game ALSO goes: "Hey hero game, here's a video stream of me challenging my player to do that!"
The hero game never knows what challenge the Boggle game has issued its player. To the hero game, it doesn't matter what game the other player is playing. Just that the quest was accepted and if it was accomplished. It doesn't understand what the video contains - the video is a message to the player to let the player know what's going on in the other game. The hero game doesn't really know or care.
On the other end of the spectrum, the Farmville game might say "hey, you, friend game over there! I have some resource trading stored up. Offer some resources for resources, would you?" And the Boggle game would go "Hey, my player: every letter you use in the next word will be sent over to your buddy and replaced with a random GOLD letter."
Or the hero game could go "I cleared out this level with this event trail yesterday. You want to do a ghost race against it?"
Obviously, there are concerns with spoofing or game balance, but there are always issues with such things. Fundamentally, I think this would be a great way to let players cooperate even when they aren't interested in playing the same game at the same time on the same type of device.
Friday, May 16, 2008
Knights of the Greenback
I have a long-standing interest in the economies (and cultures) of massively multiplayer games. There are a few things that really interest me about these systems, but a few of the major factors are that (A) they adapt much faster than a real economy and (B) the distribution/creation of goods does not have to follow real-world algorithms.
Of course, to economists, massively multiplayer games are something of a silver bullet. If only they could find a way to load them into their gun, they could really get some great research in!
But, like all games that have a "purpose", games that are economic experiments will pretty much suck. So economists grind their teeth.
To me, the cool thing is not the idea that we could study shadows of real-world economies. I'm of the opinion that such studies would be hopelessly damaged by factor B. It would be equivalent to calculating the optimum approach for the space shuttle with a high school physics textbook. You know, the one that starts every question with "ignoring air resistance, we can calculate the..."
Instead, I'm a big fan of taking factor B and running with it. After all, as technology advances, our method of creating and distributing goods (and what kinds of goods) radically changes. The idea that technological advances are "more of the same, but better" is crap.
A cell phone is not "more of the same, but better" to third world populations. It's "this changes everything!" Similarly, vaccines aren't just "more of the same, but better" medicine. The combustion engine isn't just "more horses, but better". The gun isn't "a bow and arrow, but better". It may appear that way at first blush, but once it's out of the starting gate, it will finish the race before its predecessor even gets in one lap.
My interest is therefore in modeling the effects of this kind of advancement. Since a massively multiplayer game can more or less arbitrarily set the distribution and type of goods (and what those goods can do), I think it would be interesting to create a world to take advantage of that, and get some interesting data on how it affects things.
Specifically, I'm thinking of the idea of many worlds, each of which has different economic and technological underpinnings. For example, a post-apocalyptic world where technology is high enough that people can survive in small enclaves. A world of high fantasy and magic, where monsters run rampant and the economy is largely about how to travel and communicate over distance... a world of tribal plainspeople where gods exist and a major part of the economy is in sacrificing to them and receiving their blessings... there are a million possibilities.
One of the big problems with this is player population. It's almost impossible to guess how much population a game will have, and if you aim for a specific amount, you'll probably either never reach it or blow right past it. This idea of "gated worlds" would allow you to control the population in any given economy by allowing or disallowing players access: if a world is getting too hot, block new players from going there. If a world is too cold, make the player advantages of getting goods from that world higher. Add new worlds (even simple duplicates) as needed.
Of course, you'll still have the problem of a minimum player number you'd have to reach... you need the game to be fun and exciting enough to draw players in. Economies aren't fun and exciting as they stand.
The idea of a bunch of very unique worlds... that's pretty exciting. Especially if there's some kind of advanced crafting system and interpretive transitions: if you're a shaman moving from the tribal world to the future world, you transform into a hacker and all your shamanistic equipment transforms into equivalent hacker tools...
This creates a semi-permeable barrier allowing you to see how things flow between economies, and it also gives the players something really interesting to play around with.
Most interestingly, if you could figure out exactly how, you could actually allow the players to establish and back different kinds of economic models. Not just "pick and choose" from existing models, but actually implement entirely new models. For example, what about an economic model where copyright protects a work from corporate or government duplication, but not from individual duplication? What about an economic model where the primary currency is dragon scales, and they degrade over time? What about an economic model where data is completely free - no copyright, no government-assisted protection... if you can find it, you can duplicate it infinitely? What about an economic model where cash is backed by acres of arable land?
Anyway, that's how I would do it, if someone gave me a few million dollars of grant money. :D
Of course, to economists, massively multiplayer games are something of a silver bullet. If only they could find a way to load them into their gun, they could really get some great research in!
But, like all games that have a "purpose", games that are economic experiments will pretty much suck. So economists grind their teeth.
To me, the cool thing is not the idea that we could study shadows of real-world economies. I'm of the opinion that such studies would be hopelessly damaged by factor B. It would be equivalent to calculating the optimum approach for the space shuttle with a high school physics textbook. You know, the one that starts every question with "ignoring air resistance, we can calculate the..."
Instead, I'm a big fan of taking factor B and running with it. After all, as technology advances, our method of creating and distributing goods (and what kinds of goods) radically changes. The idea that technological advances are "more of the same, but better" is crap.
A cell phone is not "more of the same, but better" to third world populations. It's "this changes everything!" Similarly, vaccines aren't just "more of the same, but better" medicine. The combustion engine isn't just "more horses, but better". The gun isn't "a bow and arrow, but better". It may appear that way at first blush, but once it's out of the starting gate, it will finish the race before its predecessor even gets in one lap.
My interest is therefore in modeling the effects of this kind of advancement. Since a massively multiplayer game can more or less arbitrarily set the distribution and type of goods (and what those goods can do), I think it would be interesting to create a world to take advantage of that, and get some interesting data on how it affects things.
Specifically, I'm thinking of the idea of many worlds, each of which has different economic and technological underpinnings. For example, a post-apocalyptic world where technology is high enough that people can survive in small enclaves. A world of high fantasy and magic, where monsters run rampant and the economy is largely about how to travel and communicate over distance... a world of tribal plainspeople where gods exist and a major part of the economy is in sacrificing to them and receiving their blessings... there are a million possibilities.
One of the big problems with this is player population. It's almost impossible to guess how much population a game will have, and if you aim for a specific amount, you'll probably either never reach it or blow right past it. This idea of "gated worlds" would allow you to control the population in any given economy by allowing or disallowing players access: if a world is getting too hot, block new players from going there. If a world is too cold, make the player advantages of getting goods from that world higher. Add new worlds (even simple duplicates) as needed.
Of course, you'll still have the problem of a minimum player number you'd have to reach... you need the game to be fun and exciting enough to draw players in. Economies aren't fun and exciting as they stand.
The idea of a bunch of very unique worlds... that's pretty exciting. Especially if there's some kind of advanced crafting system and interpretive transitions: if you're a shaman moving from the tribal world to the future world, you transform into a hacker and all your shamanistic equipment transforms into equivalent hacker tools...
This creates a semi-permeable barrier allowing you to see how things flow between economies, and it also gives the players something really interesting to play around with.
Most interestingly, if you could figure out exactly how, you could actually allow the players to establish and back different kinds of economic models. Not just "pick and choose" from existing models, but actually implement entirely new models. For example, what about an economic model where copyright protects a work from corporate or government duplication, but not from individual duplication? What about an economic model where the primary currency is dragon scales, and they degrade over time? What about an economic model where data is completely free - no copyright, no government-assisted protection... if you can find it, you can duplicate it infinitely? What about an economic model where cash is backed by acres of arable land?
Anyway, that's how I would do it, if someone gave me a few million dollars of grant money. :D
Wednesday, February 20, 2008
Press Start to Join!
GDC week = time to post all my rambly crap.
I'm interested in the difference between single- and multi-player games.
There's a lot to be said for multiplayer games: human players add a lot to the game. Even if they are not permitted to create content, they are content. An easy example is the Street Fighter series: these kinds of fighting games only really come alive when there is another human playing the other fighter.
For a long time, games have been primarily about competitive multiplayer. Some games are marginally cooperative, in that they have two teams competing, but fully cooperative games are very rare. These days, they are becoming a bit more common with games like Shadows Over Camelot (board) and coop story mode in Halo-like games.
Either way you slice it, competitive, cooperative, or both, the other humans add a lot to the game.
But they also take a lot away from the game, a point that is often missed.
...
An interesting note is that cooperative and competitive team size remains the same. A fully cooperative game has a "maximum player count" of almost precisely half the competitive-teams maximum player count in games using the same basic mechanics.
Why?
A game dedicated to one player makes that player the focus of the entire universe. That player doesn't need to worry about going at the right speed or doing the right things: he can just play around without any such concerns.
As you add players, the game allows each of them to play on a more-or-less even footing. Basically, you have to play with the other player, rather than just doing whatever you want. Each player adds more limits.
For example, a two-player fighting game: you and another person fight... to the death!
A four-player fighting game like Smash Brothers is the same on the surface, but it's actually a lot less free: each player has to watch every other player and make sure nobody gets a sneak attack on them. Their choices are limited by the existence of the other players. Some four-player games are tag-battles: two in, two out at any given time. This simply reduces the game to a two-player hotseat, meaning the complexity of a two player game, but you spend half your time not doing anything.
Players really can't track too many variables at a time, so as you add more than four players, you have to start figuring out how to reduce the chaos. Games like Quake allow for large deathmatch games of six or eight players, but the levels are designed to keep you from encountering more than a few other players at any given time.
This doesn't completely write out the complexity of having a lot more players: someone is in the lead, better watch for them. Someone just got the quad-damage, better watch out for him... global multiplayer concerns still exist. But you don't have to worry about all the players simultaneously. This does reduce the player's agency: the player's access to information is brutally limited.
These global multiplayer concerns get too difficult shortly thereafter. With ten or twelve players, hunting down the man in the lead is a herculean task, and the random chaos will frequently lead to wild, crowded encounters that players can only "track" by lobbing explosives towards the general area.
One easy method to reduce complexity is to reduce the number of enemies a player has. By making the game team-based, half the players are allies and half the players are enemies. This allows for much greater cohesion and predictability, and easily allows for games of up to twenty or thirty players, if you have decent training. Of course, this further reduces the player's agency, as now he plays a specific role as a tiny cog in a large team.
Even this has its limits. As you pass thirty, the teams are so large that any given player will have no real effect on the state of the game. Because the teams are so large and most players have to have an even amount of power, you can't really change the tide of battle much.
At this point, games usually break down into social events. Basically, the designers say "well, we've reduced the power of the player to pretty close to nothing, so I guess there's no point to truly competitive play..."
But, of course, competitive play is popular, so there's always a few outs. Arenas, PvP, etc. You will find that these subgames follow the same pattern listed above.
Actually, you will find that a social game breaks up fuzzily and follows the patterns listed above even in non-competitive areas. For example, cohesive guilds tend to max out at thirty players. Most groups on-the-fly tend to be four or five people, and larger groups tend to have a chain of command that splits them into wings of three or four...
Also to be considered is unfairness. Not all players want the same thing: many people are happy being the star-bit-collector in Super Mario Galaxy. Many people are happy crafting and buying/selling, rather than the "primary" game of killing shit. But this doesn't change the fundamental nature of multiplayerness. It simply changes the texture. If Mario's world was much more complicated, more than four star-bit-collectors would be chaotic and cripplingly confused. However, you can consider the star-bit-collectors to be on a different "team" than Mario (noncompetitive teams...), so the star-bit-collectors could number three or four and the Marios could number three or four without "overloading" the players too much.
"Unfair" (more accurately, "uneven") situations are another method of splitting players into groups to shrink the complexity of their interactions. But, as I said, this doesn't change the basic situation.
I would personally like to see a massively multiplayer game that leaves the player with power over the universe... but uses some of these other techniques to control player interactions. Maybe even some techniques not listed here.
There's a lot you can do to reduce the "chaos" of multiple players. Reducing player power to zero isn't really my favorite.
Spore promised an interesting variant, where each player has their own universe in which they have huge amounts of control. But each player "leaks" into other universes, hopefully granting a portion of the power of multiplayer. I tend to think that the social aspect is probably the most important aspect of multiplayer, and this system had no social aspect.
Now, though, they've expanded the Spore backbone to include a lot of social elements like card trading and so forth. I think it will probably be done very poorly, but it's an interesting attempt to solve the multiplayer "problem" of balancing chaos with power.
...
(By the way, player power is being measured in terms of ability to affect the global game state. A player's ability to blow away a monster has nothing to do with that, since the monster respawns a few seconds later and nothing changes.)
I'm interested in the difference between single- and multi-player games.
There's a lot to be said for multiplayer games: human players add a lot to the game. Even if they are not permitted to create content, they are content. An easy example is the Street Fighter series: these kinds of fighting games only really come alive when there is another human playing the other fighter.
For a long time, games have been primarily about competitive multiplayer. Some games are marginally cooperative, in that they have two teams competing, but fully cooperative games are very rare. These days, they are becoming a bit more common with games like Shadows Over Camelot (board) and coop story mode in Halo-like games.
Either way you slice it, competitive, cooperative, or both, the other humans add a lot to the game.
But they also take a lot away from the game, a point that is often missed.
...
An interesting note is that cooperative and competitive team size remains the same. A fully cooperative game has a "maximum player count" of almost precisely half the competitive-teams maximum player count in games using the same basic mechanics.
Why?
A game dedicated to one player makes that player the focus of the entire universe. That player doesn't need to worry about going at the right speed or doing the right things: he can just play around without any such concerns.
As you add players, the game allows each of them to play on a more-or-less even footing. Basically, you have to play with the other player, rather than just doing whatever you want. Each player adds more limits.
For example, a two-player fighting game: you and another person fight... to the death!
A four-player fighting game like Smash Brothers is the same on the surface, but it's actually a lot less free: each player has to watch every other player and make sure nobody gets a sneak attack on them. Their choices are limited by the existence of the other players. Some four-player games are tag-battles: two in, two out at any given time. This simply reduces the game to a two-player hotseat, meaning the complexity of a two player game, but you spend half your time not doing anything.
Players really can't track too many variables at a time, so as you add more than four players, you have to start figuring out how to reduce the chaos. Games like Quake allow for large deathmatch games of six or eight players, but the levels are designed to keep you from encountering more than a few other players at any given time.
This doesn't completely write out the complexity of having a lot more players: someone is in the lead, better watch for them. Someone just got the quad-damage, better watch out for him... global multiplayer concerns still exist. But you don't have to worry about all the players simultaneously. This does reduce the player's agency: the player's access to information is brutally limited.
These global multiplayer concerns get too difficult shortly thereafter. With ten or twelve players, hunting down the man in the lead is a herculean task, and the random chaos will frequently lead to wild, crowded encounters that players can only "track" by lobbing explosives towards the general area.
One easy method to reduce complexity is to reduce the number of enemies a player has. By making the game team-based, half the players are allies and half the players are enemies. This allows for much greater cohesion and predictability, and easily allows for games of up to twenty or thirty players, if you have decent training. Of course, this further reduces the player's agency, as now he plays a specific role as a tiny cog in a large team.
Even this has its limits. As you pass thirty, the teams are so large that any given player will have no real effect on the state of the game. Because the teams are so large and most players have to have an even amount of power, you can't really change the tide of battle much.
At this point, games usually break down into social events. Basically, the designers say "well, we've reduced the power of the player to pretty close to nothing, so I guess there's no point to truly competitive play..."
But, of course, competitive play is popular, so there's always a few outs. Arenas, PvP, etc. You will find that these subgames follow the same pattern listed above.
Actually, you will find that a social game breaks up fuzzily and follows the patterns listed above even in non-competitive areas. For example, cohesive guilds tend to max out at thirty players. Most groups on-the-fly tend to be four or five people, and larger groups tend to have a chain of command that splits them into wings of three or four...
Also to be considered is unfairness. Not all players want the same thing: many people are happy being the star-bit-collector in Super Mario Galaxy. Many people are happy crafting and buying/selling, rather than the "primary" game of killing shit. But this doesn't change the fundamental nature of multiplayerness. It simply changes the texture. If Mario's world was much more complicated, more than four star-bit-collectors would be chaotic and cripplingly confused. However, you can consider the star-bit-collectors to be on a different "team" than Mario (noncompetitive teams...), so the star-bit-collectors could number three or four and the Marios could number three or four without "overloading" the players too much.
"Unfair" (more accurately, "uneven") situations are another method of splitting players into groups to shrink the complexity of their interactions. But, as I said, this doesn't change the basic situation.
I would personally like to see a massively multiplayer game that leaves the player with power over the universe... but uses some of these other techniques to control player interactions. Maybe even some techniques not listed here.
There's a lot you can do to reduce the "chaos" of multiple players. Reducing player power to zero isn't really my favorite.
Spore promised an interesting variant, where each player has their own universe in which they have huge amounts of control. But each player "leaks" into other universes, hopefully granting a portion of the power of multiplayer. I tend to think that the social aspect is probably the most important aspect of multiplayer, and this system had no social aspect.
Now, though, they've expanded the Spore backbone to include a lot of social elements like card trading and so forth. I think it will probably be done very poorly, but it's an interesting attempt to solve the multiplayer "problem" of balancing chaos with power.
...
(By the way, player power is being measured in terms of ability to affect the global game state. A player's ability to blow away a monster has nothing to do with that, since the monster respawns a few seconds later and nothing changes.)
Subscribe to:
Posts (Atom)