Last essay I wrote about a mechanic that can be used in noncombat RPGs. Because the noncombat conflict gameplay is so slow compared to combat, you need to have a tighter relationship between it and other kinds of gameplay.
But there is another big problem with noncombat RPGs: stakes.
To be more clear, players judge the characters in an RPG based on how they face death and challenge, how they respond to threats, and what they want to accomplish. Most NPCs are brought together to try and save the universe, and that's a big part of why the player can respect them. There is usually one NPC that's on board for some other reason (money, escape, duty, simple friendship), but their motives are usually considered "lesser". In fact, their character arc is almost certainly to develop the same world-saving impulse as everyone else.
Well, in our NONcombat RPG, you probably aren't trying to save the universe. It's possible to cram universe-saving into the setting, but it usually ends up feeling rather hilarious: "saving the universe by repairing damaged factories!" "Saving the universe by dancing!" It's, uh... pretty forced.
Fortunately, it doesn't have to be about saving the universe.
I said before that we should look at our standard game stuff and try to figure out what it accomplishes, so we can find other ways to accomplish the same things. Typically, I explore different kinds of gameplay. But the framing of the narrative is also a piece of the game. It also accomplishes something.
It gives all of the characters the same moral and thematic backdrop. Because we can see how they respond to the same questions, we can see their distinct nature.
Nearly all of the characters in Mass Effect echo the central conflict of the Reapers. Tali's species created the Geth, then tried to exterminate them before they could become a threat. Mordin chose to keep the dangerous Krogan suppressed, and explores the ethics of that. Garrus explores the nature of laws and law enforcement, which first appears to be an echo of your human culture's interests, but then appears to be an echo of your larger fight against the Reapers. Liara's endless hunger for information and gradual descent into amoral infobrokering mirrors the Reapers' own hunger for new information. Ashley's racism reflects the Reapers'... well, it goes on.
It could be that the Mass Effect designers didn't realize they were doing this kind of echoing. If they were obsessed with oppression and the nature of power, their own obsession would have been reflected into the characters. It's hard to tell just by looking whether it was on purpose or on accident.
Dragon Age is similar. The characters are all meditations on the nature of undeserved/corrupting power. Again, it's hard to tell whether it was on purpose, or just because the devs were obsessed with that concept.
This is common. In FF6, the characters were obsessed with the concept of identity. In Chrono Trigger, they were obsessed with the nature of change and endings.
The overarching plot explores this concept as well. It is a capstone: all the characters shine their lights on the concepts in their own way. You pile them up and the capstone makes them hold together.
The fact that it's a save-the-world plot is just a wrapper. It's a convenient wrapper, because it A) gets the player a bit pumped and B) allows you to pull a bunch of characters together without too much effort. It's the "you're all in a tavern when..." of computer games.
The question isn't "can we make a noncombat game about saving the world". The question is "can we create a plot with a theme that holds the characters together, and make sure the player finds it compelling?"
The answer is yes and yes, but it requires some thought.
Let's think about our tiny little game design about people who run around and repair broken space stations. Due to the nature of the conflicts, our theme would probably be best as "complexity is a tradeoff". In turn, our characters would explore this concept in their own way.
This could be as simple as "this character has OCD and is obsessed with organizing minutiae", but that's a poor way to design a major character. They aren't just sticking to a theme: they're exploring it. So they generally have an arc related to it. Sometimes an arc works as "they reverse their issue" - cowardly to brave, loner to team player, etc. But those are traits everyone empathizes with, so it's easy to get inside the character's head. Obsessing over details is typically a distancing trait, actually pushing the character further away from both the audience and the other characters. Therefore, the best arc is not "stops being OCD", but is instead something that directly relates them to other characters. For example, goes from having an obsessive crush on the robot party member (no bacteria! No fluids!) to a more gentle romance with a completely different character.
This kind of arc explores how obsessing over details and minutiae affects his or her life. This is how the most compelling characters are created.
All the characters need to have that kind of thought put into them.
And the game's overarching plot also needs to have that kind of thought put into it.
As the capstone, the whole universe needs to be exploring the tradeoffs of complexity and simplicity. It could start small: many of the causes of breakdowns are bacteria that are really hard to get rid of, bacteria that constantly adapts to changing environments and eats plastic, rubber, glass, buckyballs, whatever.
This should be combined with a civilization groaning under its own complexity. Millions of trade agreements and billions of trade routes. Cultures with complex rules of interaction to keep people safe from each other. Governments that sign budgets, laws, and treaties into being but literally cannot understand them, as they are far too complex and apply too broadly.
The culmination would be a coup against the government. However, rather than being on one side or the other, the player party is just trying to keep people alive. By this time, the player should be able to "read ahead" and tell what kind of breakdowns are going to occur, and show up with just the right goods to repair everything. The civilization becomes largely cut off from itself as things collapse, but the player can tell various settlements to ship various things to various places, dragging the fractured system back into alignment, restoring everything to how it was. Then end on some kind of hopeful note.
This is a relatively good theme. Moreover, it gives us an easy chance to recruit NPCs by the bushel. Any NPC that lives anywhere where anything breaks down could have an interest in signing on to your crew, as well as anthropologists, entertainers, wannabee politicians, explorers, merchants: all have some interest in joining your ship.
And all of them have something to say about the tradeoffs of complexity.
Friday, October 17, 2014
Thursday, October 16, 2014
Designing Noncombat RPGs
In my last essay I talked about parts of the RPG experience I love. In the one before that, I talked about how we can put aside standard gameplay tropes if we understand what player experiences are created by that gameplay and do it another way.
Now I'm going to combine the two and talk about a noncombat RPG.
There are few "noncombat RPGs". They are never very good, because the entire idea of an RPG is based around combat.
Sure, all the gameplay loops orbit the concept of combat. Even above that, the way we consider fantasy worlds is through the lens of combat.
For example, I can simply swap combat out with something that is almost mechanically identical. Poker, for example. But the RPG will still end up bad, because the concept of poker players saving the universe is laughable. It actually runs deeper than that: our concept of travel within a fantasy world is linked to the idea of combat. How we judge the merit of characters is based on how they face danger and death, not how well they play poker.
You could make a comedy RPG like that, perhaps. A dance-off RPG. But if you want a reasonably serious RPG (not necessarily dark, but not a straight comedy), you need to deal with this weakness.
As tempting as it is to swap out combat for, say, cooking, you can't do it. You have to rebuild your experience from the ground up. You have to start with cooking, then think about how to build the loops, how to build the experiences, how to build the interactions, how to portray the NPCs...
Let's design a Mass-Effect-like. A game which "feels like" Mass Effect, but has completely different core play.
Our noncombat Mass Effect is about making the horrifyingly complex systems of the science fiction future work. The party repairs, plans, retrofits, and extends infrastructure. They work for the Central Planning Office. We'll call our game CPO for the moment.
The core loop is dealing with specific problems. Rather than cement everything too early, let's just mention some categories of "enemies" you might face: damaged parts, missing parts, misconfigured systems, incompatible hardware, incompatible software, archaic software, daisy-chain failures, missing procedures, and annoying people.
Right away, I can see four basic categories: hardware wrangling, software wrangling, red tape, and people/groups. I can also see various kinds of challenges within those categories: something broke, something crashed, something's missing, something's misconfigured, two things are incompatible, something failed because something else failed (detective work), etc.
Can this be made interesting?
Well, mechanically, anything can be made interesting. The question is whether it can be presented in a meaty way. The big draw of combat is that everyone can feel it. Even if it's presented like an oldschool RPG where someone steps forward, moves slightly, and then steps back, you still understand that there's a monster getting whacked.
There are two things we need in order to make CPO's core loop interesting.
The first is a good presentation. I think this is quite possible. Watching large machines turn on, lights come back, vents start working on the clouds of smoke, water start spraying... these are actually pretty good. You can really feel a sense of accomplishment when you repair a broken thing. This can be further punched up if lives are at risk - genuinely at risk, not just some color text. If you do badly, people will get injured, die, become homeless, or otherwise suffer. Work fast!
The second thing we need is a flexible system. It's easy to make a puzzle game out of this kind of situation - you have a bunch of pieces and you need to arrange them. However, the strength of an RPG's combat system is that it is very flexible. A variety of team builds can take on a variety of challenges in a variety of ways. Even if something is sub-optimal, the team can pull through if you spend a few more resources.
So this isn't a puzzle. Instead, the compromised systems are like enemies to be pounded. You don't just replace a component of a damaged factory: you assault it with ongoing repair attempts. If you have suitable components, it's like having an elemental advantage and your assaults will be much faster/more effective. If software is incompatible, attack with with programming hacks until compatibility is established.
Moreover, in most cases there's cross-compatibility. If software is incompatible, replace hardware modules until you find one with compatible software. If hardware is missing, write software to rebalance outputs and route around the missing piece.
Although I like the realtime combat systems we see these days, it makes more sense for these actions to take many hours or even days. While the player can wander around in real time, the "combat" turns are much slower. This means the exploration loop is actually tighter than the combat loop, because you can explore a whole space station in far less than one turn of "combat".
This is obviously a bit of a concern. Normally you would have combat be the core loop and you would fall into it many times during the explore phase, each time executing a complete combat.
We require a bit of a different approach if we want to do it this "slow loop" way... and we definitely want to do it this way. Aside from combat, there are very few immersive activities that take less time than walking around. Figuring this out would let us build a huge variety of "inverted RPGs" where the core activity iterates more slowly than the support activities.
To make this work, we have to create offramps from combat into exploration, then from exploration back into combat.
Functionally, this means that as you explore a place, the details of the place change. This is obvious: you are changing the place with your repairs. Moreover, the people who live in the place (or the weather or whatever) are also changing over time as their condition progresses.
Exploring becomes less about discovering new terrain, and more about discovering and taking advantage of these changes. Did someone regain consciousness? If so, you can ask them how the vent systems work, and get an "extra attack" in your combat against it. Did one of your people score a "critical hit" on some incompatible software? If so, use partial compatibility to help fuel your assault on the reactor repairs.
Exploration is no longer exploration, it's "resource management" - finding new resources.
With that in mind, we can expand it. Resource management includes blunting or evading new resource drains. It includes deciding to spend resources in a new way (for example, giving a colonist expensive medical treatment if his condition worsens). It includes moving resources - bringing supplies to your NPC team mates, or switching out which shipboard reactor you're using so you can swap out the nuclear core...
In turn, we begin to see this double-loop emerging. There's a lot of resource management happening on the "fairly fast" level. Perhaps each "combat" turn takes four hours, and at the end of each turn you can choose to wander around if you like. The resources supporting you may change a bit, but the big issue is the very predictable ongoing consumption of resources. Power from a limited power bank. Oxygen from a limited life support system. Food from a limited cabinet. These are resources you will wrangle between turns - negotiating for more oxygen, switching to backup power, going on limited rations...
By changing how our resource management system works, we can completely change the feel of our game and get a really good heartbeat going.
For example, we have a bank of 3D printers to print hardware components for us. Hardware work is therefore limited by the max output of these printers. However, you can also "prep". A turn (4 hours) spent prepping will add output to the total, allowing you to stockpile parts for really big job. These parts cannot be kept: they are special-purpose. So most of the time, you'll be working within the constraints of the printers, but it's flexible if you have time and good planning skills.
Hackers will want to combine their efforts with that of the shipboard computer. But that's a limited resource. Programmers only require a computer assist when using an advanced move, such as password cracking or database filtering. Rather than being a specific cap amount that is available, using the computers aboard the ship takes electricity - and not on a linear progression. Getting 10 points of computation is much more than 10x as expensive as getting 1 point.
Of course, electricity is obviously also a component. You have two shipside reactors, but the power output isn't fantastic and you need to keep swapping out fission cores, which takes a turn (4 hours). It's obviously nice if you can pull power from the facility you're repairing - colony reactors are much more powerful. But if the problem is that the colony's power is not working right, well!
But maybe the colony has computers, or 3D printers. Maybe the colony has batteries that you can charge up.
You can see - we can mix the resources you bring with the resources available on site. And they change in predictable ways turn to turn, so you can optimize your efforts.
It's beginning to sound like a fun game to me. You land at a dark space station, go aboard with suits. One party member spends every turn ferrying oxygen to the others, while they struggle to repair the power systems. One is elbow-deep in the reactor, the other is underneath the main breaker, swapping out conduits. The power system comes up, and you watch their faces look up as the lights shudder to life. They high-five.
The station is full of smoke, which causes the newly-resurrected life support to seize up. You use the station power to hack the central database of users, so you can program a new "smoke compatible" life support mode - one turn per action.
Twelve hours have passed, and you can finally take off your life support suits. You're all pretty tired from your twelve-hour shift, so maybe it's time to sleep. Some other party members from your ship step in to keep working while your "A" team sleeps.
They discover some colonists in cryo pods...
That is the basic format: turn-to-turn resource management combined with extended activities. You don't even need a hard party number cap, because party members use resources. It's self-balancing.
In current RPGs, resource management is long-term. You horde potions and mana and health over the course of a dungeon. We've inverted that: the resources are short-term. Each turn is a question of how to arrange them, how to refill them, how to spend them.
The way the two loops relate has been changed. Previously, the combat loop only had one "off ramp" - combat ends, you go back to exploring.
But our combat loop is slowed way down. Our players will take too much time to loop through until completion.
So we have to offer many off ramps. Combat doesn't "end" in exploration. You shuttle back and forth between the two.
The connection between the loops is much tighter, which should make the game quite immersive.
And that's the start of my design.
Now I'm going to combine the two and talk about a noncombat RPG.
There are few "noncombat RPGs". They are never very good, because the entire idea of an RPG is based around combat.
Sure, all the gameplay loops orbit the concept of combat. Even above that, the way we consider fantasy worlds is through the lens of combat.
For example, I can simply swap combat out with something that is almost mechanically identical. Poker, for example. But the RPG will still end up bad, because the concept of poker players saving the universe is laughable. It actually runs deeper than that: our concept of travel within a fantasy world is linked to the idea of combat. How we judge the merit of characters is based on how they face danger and death, not how well they play poker.
You could make a comedy RPG like that, perhaps. A dance-off RPG. But if you want a reasonably serious RPG (not necessarily dark, but not a straight comedy), you need to deal with this weakness.
As tempting as it is to swap out combat for, say, cooking, you can't do it. You have to rebuild your experience from the ground up. You have to start with cooking, then think about how to build the loops, how to build the experiences, how to build the interactions, how to portray the NPCs...
Let's design a Mass-Effect-like. A game which "feels like" Mass Effect, but has completely different core play.
Our noncombat Mass Effect is about making the horrifyingly complex systems of the science fiction future work. The party repairs, plans, retrofits, and extends infrastructure. They work for the Central Planning Office. We'll call our game CPO for the moment.
The core loop is dealing with specific problems. Rather than cement everything too early, let's just mention some categories of "enemies" you might face: damaged parts, missing parts, misconfigured systems, incompatible hardware, incompatible software, archaic software, daisy-chain failures, missing procedures, and annoying people.
Right away, I can see four basic categories: hardware wrangling, software wrangling, red tape, and people/groups. I can also see various kinds of challenges within those categories: something broke, something crashed, something's missing, something's misconfigured, two things are incompatible, something failed because something else failed (detective work), etc.
Can this be made interesting?
Well, mechanically, anything can be made interesting. The question is whether it can be presented in a meaty way. The big draw of combat is that everyone can feel it. Even if it's presented like an oldschool RPG where someone steps forward, moves slightly, and then steps back, you still understand that there's a monster getting whacked.
There are two things we need in order to make CPO's core loop interesting.
The first is a good presentation. I think this is quite possible. Watching large machines turn on, lights come back, vents start working on the clouds of smoke, water start spraying... these are actually pretty good. You can really feel a sense of accomplishment when you repair a broken thing. This can be further punched up if lives are at risk - genuinely at risk, not just some color text. If you do badly, people will get injured, die, become homeless, or otherwise suffer. Work fast!
The second thing we need is a flexible system. It's easy to make a puzzle game out of this kind of situation - you have a bunch of pieces and you need to arrange them. However, the strength of an RPG's combat system is that it is very flexible. A variety of team builds can take on a variety of challenges in a variety of ways. Even if something is sub-optimal, the team can pull through if you spend a few more resources.
So this isn't a puzzle. Instead, the compromised systems are like enemies to be pounded. You don't just replace a component of a damaged factory: you assault it with ongoing repair attempts. If you have suitable components, it's like having an elemental advantage and your assaults will be much faster/more effective. If software is incompatible, attack with with programming hacks until compatibility is established.
Moreover, in most cases there's cross-compatibility. If software is incompatible, replace hardware modules until you find one with compatible software. If hardware is missing, write software to rebalance outputs and route around the missing piece.
Although I like the realtime combat systems we see these days, it makes more sense for these actions to take many hours or even days. While the player can wander around in real time, the "combat" turns are much slower. This means the exploration loop is actually tighter than the combat loop, because you can explore a whole space station in far less than one turn of "combat".
This is obviously a bit of a concern. Normally you would have combat be the core loop and you would fall into it many times during the explore phase, each time executing a complete combat.
We require a bit of a different approach if we want to do it this "slow loop" way... and we definitely want to do it this way. Aside from combat, there are very few immersive activities that take less time than walking around. Figuring this out would let us build a huge variety of "inverted RPGs" where the core activity iterates more slowly than the support activities.
To make this work, we have to create offramps from combat into exploration, then from exploration back into combat.
Functionally, this means that as you explore a place, the details of the place change. This is obvious: you are changing the place with your repairs. Moreover, the people who live in the place (or the weather or whatever) are also changing over time as their condition progresses.
Exploring becomes less about discovering new terrain, and more about discovering and taking advantage of these changes. Did someone regain consciousness? If so, you can ask them how the vent systems work, and get an "extra attack" in your combat against it. Did one of your people score a "critical hit" on some incompatible software? If so, use partial compatibility to help fuel your assault on the reactor repairs.
Exploration is no longer exploration, it's "resource management" - finding new resources.
With that in mind, we can expand it. Resource management includes blunting or evading new resource drains. It includes deciding to spend resources in a new way (for example, giving a colonist expensive medical treatment if his condition worsens). It includes moving resources - bringing supplies to your NPC team mates, or switching out which shipboard reactor you're using so you can swap out the nuclear core...
In turn, we begin to see this double-loop emerging. There's a lot of resource management happening on the "fairly fast" level. Perhaps each "combat" turn takes four hours, and at the end of each turn you can choose to wander around if you like. The resources supporting you may change a bit, but the big issue is the very predictable ongoing consumption of resources. Power from a limited power bank. Oxygen from a limited life support system. Food from a limited cabinet. These are resources you will wrangle between turns - negotiating for more oxygen, switching to backup power, going on limited rations...
By changing how our resource management system works, we can completely change the feel of our game and get a really good heartbeat going.
For example, we have a bank of 3D printers to print hardware components for us. Hardware work is therefore limited by the max output of these printers. However, you can also "prep". A turn (4 hours) spent prepping will add output to the total, allowing you to stockpile parts for really big job. These parts cannot be kept: they are special-purpose. So most of the time, you'll be working within the constraints of the printers, but it's flexible if you have time and good planning skills.
Hackers will want to combine their efforts with that of the shipboard computer. But that's a limited resource. Programmers only require a computer assist when using an advanced move, such as password cracking or database filtering. Rather than being a specific cap amount that is available, using the computers aboard the ship takes electricity - and not on a linear progression. Getting 10 points of computation is much more than 10x as expensive as getting 1 point.
Of course, electricity is obviously also a component. You have two shipside reactors, but the power output isn't fantastic and you need to keep swapping out fission cores, which takes a turn (4 hours). It's obviously nice if you can pull power from the facility you're repairing - colony reactors are much more powerful. But if the problem is that the colony's power is not working right, well!
But maybe the colony has computers, or 3D printers. Maybe the colony has batteries that you can charge up.
You can see - we can mix the resources you bring with the resources available on site. And they change in predictable ways turn to turn, so you can optimize your efforts.
It's beginning to sound like a fun game to me. You land at a dark space station, go aboard with suits. One party member spends every turn ferrying oxygen to the others, while they struggle to repair the power systems. One is elbow-deep in the reactor, the other is underneath the main breaker, swapping out conduits. The power system comes up, and you watch their faces look up as the lights shudder to life. They high-five.
The station is full of smoke, which causes the newly-resurrected life support to seize up. You use the station power to hack the central database of users, so you can program a new "smoke compatible" life support mode - one turn per action.
Twelve hours have passed, and you can finally take off your life support suits. You're all pretty tired from your twelve-hour shift, so maybe it's time to sleep. Some other party members from your ship step in to keep working while your "A" team sleeps.
They discover some colonists in cryo pods...
That is the basic format: turn-to-turn resource management combined with extended activities. You don't even need a hard party number cap, because party members use resources. It's self-balancing.
In current RPGs, resource management is long-term. You horde potions and mana and health over the course of a dungeon. We've inverted that: the resources are short-term. Each turn is a question of how to arrange them, how to refill them, how to spend them.
The way the two loops relate has been changed. Previously, the combat loop only had one "off ramp" - combat ends, you go back to exploring.
But our combat loop is slowed way down. Our players will take too much time to loop through until completion.
So we have to offer many off ramps. Combat doesn't "end" in exploration. You shuttle back and forth between the two.
The connection between the loops is much tighter, which should make the game quite immersive.
And that's the start of my design.
Dissecting the RPG
One of my big interests is RPGs such as Mass Effect, Dragon's Dogma, etc. But these days, I find that the gameplay is seriously getting in the way of the experience - for example, Dragon Age is poisoned by its slavish adherence to standard RPG gameplay and progression.
When I break down what I like about various RPGs, it resolves into two things.
I've done a lot of work trying to figure out how to get that same feeling "on the cheap", and I've discovered that there are very specific systems you need to implement. Obviously, you need all four loops. You can actually use as many variants as you want. Most RPGs have three exploration systems: dungeon, overworld, and city. Most also have several kinds of optimization - gear, leveling, skill/spell, item use. Dragon's Dogma, known for its particularly tasty combat, has three kinds of combat situations: free-for-all, anti-titan, and magic. They are actually very different - not different roles within the combat engine, but fundamentally different kinds of combat.
That's not enough.
I've made loads of prototypes with those constraints, but they didn't keep me in the groove. It turns out, what you need is hooks between them. You can't just drop the player from one to the other without warning, and you can't totally rely on the player to switch loops when they get a bit bored. Instead, what you do is set up a world where you are more likely to switch loops (or want to switch loops) if you do a specific kind of thing in this loop.
For example, if you're exploring a dark cave, that's exploration-loop. As you peek around a corner and see a crowd of cave spiders, you know that the combat play is not far away. You can choose to engage combat - and normally you will. But you can also prep, sneak around, back away, choose a first strike, try to pull just a few...
Even in a game like FF6, with random encounters, you would plan your explorations based around the number of steps you were taking. You headed for a tough boss? Don't waste a step. You trying to level? Wander around the entrance, run home when you run out of magic. And everything inbetween. While the encounters were random, the pattern of encounters was not.
Basically, the player can switch loops, but it's only at off-ramps. It's not just that one loop changes the stats in another: it's that when and how you set up your loop changes is gameplay. Perhaps the most important gameplay.
I like Mass Effect because I like hanging out with the team. Dragon Age has some of the dullest gameplay and character design around, but I like it because the characters are all very interactive.
There's a combination of elements. One is that the NPCs are quite distinct, and feel distinct all of the time. In Skyrim, you can get NPCs to follow you around, but they don't have any significant personality. In Mass Effect, every NPC feels very distinct: distinct personalities, distinct visual designs, distinct voicework, and distinct combat roles. You never forget who you have in your team. You never mistake racist human lady for psychic human lady - they feel completely distinct.
Another element that makes me care is that the NPCs have social interactions - with you and with each other. They are not only distinct, they also exist within the world. Classically this has been backstory exposition, but I think that's an unnecessary holdover. I think social interactions and judgments are far more efficient and effective: Mordin's singing makes more of an impression on the player than his history with krogan genetics.
Social interactions are largely unexplored. At the moment, the three types we have are backstory exposition, random chatter, and loyalty/romance quests. I think there's a lot of room to add in more kinds of social interaction, but it needs a light touch. This is not core gameplay.
The last element that makes me care is the feeling that I can shape them, and perhaps that they can shape me. The most obvious example of this is leveling and gear selection - changing how they fight. But there is a lot more potential.
Part of it is the potential of the character. The path you choose locks away a path you did not take, and just knowing that other path existed makes it clear you've affected their life.
In Old Republic, nearly every character has a very distinct light side and dark side path. I can't play dark side, it's just too badly written, but just knowing that there was a dark side path made me feel that their light side path had more weight. The characters felt more important to me because their lives were changed because of me. Not "oh, the HERO changed their life", but "oh, the PLAYER changed their life."
These big forks are probably not necessary. I think small things are probably more important than big things, although we haven't really gotten that far. Let me give an example:
In Mass Effect, nearly every character is a potential romance target. But once you have chosen a lover, nothing really changes.
Imagine if once you chose a lover, they would ask you to be a bit different. For example, they might steadily redecorate your quarters. They might ask you to wear the NC-7 helmet because it looks soooo good. They might be more upfront about asking you to take specific side missions, or give you optional objectives that are substantially harder. All based on their personality.
For example, you go to explore a new world and Tali might ask you to avoid getting shot: if you get shot, she has to acclimatize to that planet's bacteria. Garrus might ask you to wear specific armor he likes. Liara might ask that you not make anyone angry in conversation, because it gives her an empathic headache. Doing or not doing these things would have no real statistical effect: this is to make hanging out more interesting, not to give you statistical perks.
If all of the NPCs made these kinds of requests, it'd be annoying to try to play the game. However, at this point you've shown that you like a specific NPC enough to spend your fictional lives together. That's permission to be a bit more aggressive with their personality and interests.
Notice, none of these are "loyalty missions". They're not linked to the core plot progression. They just make hanging out a little more interesting.
Anyway, there are a lot of options on how to make NPCs more interesting using these kinds of ideas.
I needed to write this essay before I could write an essay on redesigning the open-world RPG, so that's this essay done. Hopefully you enjoyed reading it.
When I break down what I like about various RPGs, it resolves into two things.
Pacing
First, I really do like the pacing of RPGs, especially with the modern realtime combat systems found in every big-budget game since Oblivion. There's a really powerful pull to this combination of exploration, combat, looting, and optimizing.I've done a lot of work trying to figure out how to get that same feeling "on the cheap", and I've discovered that there are very specific systems you need to implement. Obviously, you need all four loops. You can actually use as many variants as you want. Most RPGs have three exploration systems: dungeon, overworld, and city. Most also have several kinds of optimization - gear, leveling, skill/spell, item use. Dragon's Dogma, known for its particularly tasty combat, has three kinds of combat situations: free-for-all, anti-titan, and magic. They are actually very different - not different roles within the combat engine, but fundamentally different kinds of combat.
That's not enough.
I've made loads of prototypes with those constraints, but they didn't keep me in the groove. It turns out, what you need is hooks between them. You can't just drop the player from one to the other without warning, and you can't totally rely on the player to switch loops when they get a bit bored. Instead, what you do is set up a world where you are more likely to switch loops (or want to switch loops) if you do a specific kind of thing in this loop.
For example, if you're exploring a dark cave, that's exploration-loop. As you peek around a corner and see a crowd of cave spiders, you know that the combat play is not far away. You can choose to engage combat - and normally you will. But you can also prep, sneak around, back away, choose a first strike, try to pull just a few...
Even in a game like FF6, with random encounters, you would plan your explorations based around the number of steps you were taking. You headed for a tough boss? Don't waste a step. You trying to level? Wander around the entrance, run home when you run out of magic. And everything inbetween. While the encounters were random, the pattern of encounters was not.
Basically, the player can switch loops, but it's only at off-ramps. It's not just that one loop changes the stats in another: it's that when and how you set up your loop changes is gameplay. Perhaps the most important gameplay.
Characters
Well, Rogue has that same gameplay, and that's the reason it's got such longevity. But I like Mass Effect better than Rogue. I enjoy RPGs where you have party members. The more personality they have and the more interactive they are, the more I like the game.I like Mass Effect because I like hanging out with the team. Dragon Age has some of the dullest gameplay and character design around, but I like it because the characters are all very interactive.
There's a combination of elements. One is that the NPCs are quite distinct, and feel distinct all of the time. In Skyrim, you can get NPCs to follow you around, but they don't have any significant personality. In Mass Effect, every NPC feels very distinct: distinct personalities, distinct visual designs, distinct voicework, and distinct combat roles. You never forget who you have in your team. You never mistake racist human lady for psychic human lady - they feel completely distinct.
Another element that makes me care is that the NPCs have social interactions - with you and with each other. They are not only distinct, they also exist within the world. Classically this has been backstory exposition, but I think that's an unnecessary holdover. I think social interactions and judgments are far more efficient and effective: Mordin's singing makes more of an impression on the player than his history with krogan genetics.
Social interactions are largely unexplored. At the moment, the three types we have are backstory exposition, random chatter, and loyalty/romance quests. I think there's a lot of room to add in more kinds of social interaction, but it needs a light touch. This is not core gameplay.
The last element that makes me care is the feeling that I can shape them, and perhaps that they can shape me. The most obvious example of this is leveling and gear selection - changing how they fight. But there is a lot more potential.
Part of it is the potential of the character. The path you choose locks away a path you did not take, and just knowing that other path existed makes it clear you've affected their life.
In Old Republic, nearly every character has a very distinct light side and dark side path. I can't play dark side, it's just too badly written, but just knowing that there was a dark side path made me feel that their light side path had more weight. The characters felt more important to me because their lives were changed because of me. Not "oh, the HERO changed their life", but "oh, the PLAYER changed their life."
These big forks are probably not necessary. I think small things are probably more important than big things, although we haven't really gotten that far. Let me give an example:
In Mass Effect, nearly every character is a potential romance target. But once you have chosen a lover, nothing really changes.
Imagine if once you chose a lover, they would ask you to be a bit different. For example, they might steadily redecorate your quarters. They might ask you to wear the NC-7 helmet because it looks soooo good. They might be more upfront about asking you to take specific side missions, or give you optional objectives that are substantially harder. All based on their personality.
For example, you go to explore a new world and Tali might ask you to avoid getting shot: if you get shot, she has to acclimatize to that planet's bacteria. Garrus might ask you to wear specific armor he likes. Liara might ask that you not make anyone angry in conversation, because it gives her an empathic headache. Doing or not doing these things would have no real statistical effect: this is to make hanging out more interesting, not to give you statistical perks.
If all of the NPCs made these kinds of requests, it'd be annoying to try to play the game. However, at this point you've shown that you like a specific NPC enough to spend your fictional lives together. That's permission to be a bit more aggressive with their personality and interests.
Notice, none of these are "loyalty missions". They're not linked to the core plot progression. They just make hanging out a little more interesting.
Anyway, there are a lot of options on how to make NPCs more interesting using these kinds of ideas.
I needed to write this essay before I could write an essay on redesigning the open-world RPG, so that's this essay done. Hopefully you enjoyed reading it.
Tuesday, October 14, 2014
Boring Play
Recently I've been in a bit of a war with myself about game design.
I create a lot of prototypes - typically at least one a week. For a long time, they were mostly about exploring some gameplay idea - a particular tweak on poker rules, or a feel for the timing in a brawler.
As time passed, I became steadily more interested in themes. Pick a theme, then craft the rules out of the giant backlog of gameplay I explored. Fit them together.
In the end, there are only a few kinds of play that are considered "valid". If I come up with a theme such as "fluffy bunnies in the woods", it'll have to rely on the same challenges that every other game relies on.
Movement and timing. Pattern recognition/optimization. Choosing the right option out of an ever-changing crowd of options. Luck.
There are some games that people barely consider games. For example, Gone Home.
But Gone Home still uses these mechanics. You move around the house looking for things to click on. You put together the pattern of the story in your head. The least gamey game is still reliant on the same challenges as the most gamey game, just with very different pacing.
What about Animal Crossing and similar games?
Well, there's a lot of pattern recognition and optimization in Animal Crossing - gathering valuable things, hitting the parts of the town you need to hit, tending your crops, finding jobs and sidequests. Those are all pattern recognition and optimization.
There are some things peeking from the shadows, though. Creating your character involves picking from a list of options, but unlike an RPG battle or math-teaching game, none of the choices is right or wrong. Similarly, in Gone Home the challenges are all about movement and clicking just like in a shooty game, but none of the movement or clicks could really be considered "bad". You can't lose at Gone Home - the challenges just serve to to indicate which way is forward so you can control your own experience a bit more clearly.
In both cases, the "challenge" (picking an option, moving and looking) is there to allow the player to control their own experience. In both cases, the game tells you how to move forward specifically so you can linger or move on as your preferences and mood dictate.
OK, with that in mind, let's back up a little bit.
---
Gameplay is really boring.
Oh, it can keep your mind entrained. I play Kerbal and Skyrim and so on. The mechanics keep me thinking, keep me looking towards the next step.
But when I look at it, there's nothing to the mechanics at all. My outlook on life wouldn't be any different if I couldn't choose the right amount of fuel and thrust to land on a fake moon, or level up my sneak enough to stab a fake skeleton with a fake knife.
There is some value in these games, though.
Through Kerbal I learned a lot about the mechanics of space flight. While the lessons are stilted and simplified, they further my interest in and my understanding of real science, real space flight. By giving me a cartoonish version of something real, the game lets me hold it in my hands, twist it, hold it up to the light, and start to understand.
Skyrim is not so positive. The cartoonish thing Skyrim lets me hold is the culture that formed it. It's a very manly-man Tolkien fantasy with a lot of serious issues. But it serves: when I hold Skyrim in my hand and start gluing other people's pieces onto it, I can see all the weaknesses in that culture, and explore my steadily-increasing distance from it.
Even if you don't read into it as much as I do, Skyrim's strength is the setting, not the mechanics. High-fidelity fantasy world you can wander around in? That's what you'll remember about Skyrim. You won't fondly remember the lockpicking puzzle.
So, why do we do it?
Why do we slap useless gameplay into these things?
1) Pacing. By keeping the mind engaged, players can remain interested in the world even when their preferences aren't lining up and they aren't interested in the bit of setting they're currently looking at.
2) Engagement. By allowing players to choose how they approach the game, we also change how they approach the setpieces. This helps players grip the concepts in the world and hold them up to the light.
3) Synchronization. By giving all players the same emergent tools, we allow every player to have their own unique experiences with the same foundation. Sharing those experiences with other players (or themselves in the past), we allow players to have conversations about the concepts in the game. Even if it's just bragging about headshot counts.
Thinking about gameplay from this perspective is very freeing.
Instead of thinking "what kind of gameplay do I want in this game?" maybe we should think -
1) How do I pace the game so that the player remains interested even when their mood drifts out of synch with the setting?
2) How do I let the player explore the ramifications of change in this world?
3) What commonalities do I rely on to help players understand each other's experiences and choices?
...
I haven't gotten any further than that, yet.
I create a lot of prototypes - typically at least one a week. For a long time, they were mostly about exploring some gameplay idea - a particular tweak on poker rules, or a feel for the timing in a brawler.
As time passed, I became steadily more interested in themes. Pick a theme, then craft the rules out of the giant backlog of gameplay I explored. Fit them together.
In the end, there are only a few kinds of play that are considered "valid". If I come up with a theme such as "fluffy bunnies in the woods", it'll have to rely on the same challenges that every other game relies on.
Movement and timing. Pattern recognition/optimization. Choosing the right option out of an ever-changing crowd of options. Luck.
There are some games that people barely consider games. For example, Gone Home.
But Gone Home still uses these mechanics. You move around the house looking for things to click on. You put together the pattern of the story in your head. The least gamey game is still reliant on the same challenges as the most gamey game, just with very different pacing.
What about Animal Crossing and similar games?
Well, there's a lot of pattern recognition and optimization in Animal Crossing - gathering valuable things, hitting the parts of the town you need to hit, tending your crops, finding jobs and sidequests. Those are all pattern recognition and optimization.
There are some things peeking from the shadows, though. Creating your character involves picking from a list of options, but unlike an RPG battle or math-teaching game, none of the choices is right or wrong. Similarly, in Gone Home the challenges are all about movement and clicking just like in a shooty game, but none of the movement or clicks could really be considered "bad". You can't lose at Gone Home - the challenges just serve to to indicate which way is forward so you can control your own experience a bit more clearly.
In both cases, the "challenge" (picking an option, moving and looking) is there to allow the player to control their own experience. In both cases, the game tells you how to move forward specifically so you can linger or move on as your preferences and mood dictate.
OK, with that in mind, let's back up a little bit.
---
Gameplay is really boring.
Oh, it can keep your mind entrained. I play Kerbal and Skyrim and so on. The mechanics keep me thinking, keep me looking towards the next step.
But when I look at it, there's nothing to the mechanics at all. My outlook on life wouldn't be any different if I couldn't choose the right amount of fuel and thrust to land on a fake moon, or level up my sneak enough to stab a fake skeleton with a fake knife.
There is some value in these games, though.
Through Kerbal I learned a lot about the mechanics of space flight. While the lessons are stilted and simplified, they further my interest in and my understanding of real science, real space flight. By giving me a cartoonish version of something real, the game lets me hold it in my hands, twist it, hold it up to the light, and start to understand.
Skyrim is not so positive. The cartoonish thing Skyrim lets me hold is the culture that formed it. It's a very manly-man Tolkien fantasy with a lot of serious issues. But it serves: when I hold Skyrim in my hand and start gluing other people's pieces onto it, I can see all the weaknesses in that culture, and explore my steadily-increasing distance from it.
Even if you don't read into it as much as I do, Skyrim's strength is the setting, not the mechanics. High-fidelity fantasy world you can wander around in? That's what you'll remember about Skyrim. You won't fondly remember the lockpicking puzzle.
So, why do we do it?
Why do we slap useless gameplay into these things?
1) Pacing. By keeping the mind engaged, players can remain interested in the world even when their preferences aren't lining up and they aren't interested in the bit of setting they're currently looking at.
2) Engagement. By allowing players to choose how they approach the game, we also change how they approach the setpieces. This helps players grip the concepts in the world and hold them up to the light.
3) Synchronization. By giving all players the same emergent tools, we allow every player to have their own unique experiences with the same foundation. Sharing those experiences with other players (or themselves in the past), we allow players to have conversations about the concepts in the game. Even if it's just bragging about headshot counts.
Thinking about gameplay from this perspective is very freeing.
Instead of thinking "what kind of gameplay do I want in this game?" maybe we should think -
1) How do I pace the game so that the player remains interested even when their mood drifts out of synch with the setting?
2) How do I let the player explore the ramifications of change in this world?
3) What commonalities do I rely on to help players understand each other's experiences and choices?
...
I haven't gotten any further than that, yet.
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!
Tuesday, October 07, 2014
Integrating Mods
I like mods. I'd like to talk about how to integrate mods into the core game. I'd like to talk about the future of mods. So let's start with the current generation of mods.
Right now, there are four reigning kings of mods. Kings and queens? Four reigning prime ministers of mods.
These four ministers of mods are Kerbal, Space Engineers, Skyrim, and Minecraft. I haven't done much Minecraft modding, so we'll put that aside and I'll explain my thoughts using the first three.
Kerbal and Space Engineers have similar fundamentals, so their mods often end up having a similar impact on the game. Both games feature picking parts out of a huge list and choosing where to put them. In short, they are construction games.
Most mods for these games add parts. However, this leads to swamping. No matter how many filters and categories you add, the player is tasked to consider all of these parts as potential components at all times. Kerbal has introduced a nice smooth slope via career mode, and Space Engineers is working towards a very diverse set of categories, but neither approach is perfect. In both cases the player will eventually have to be familiar with all parts all the time, and that means the guidance just delays the inevitable.
There are mods that are about things other than parts, but we'll talk about that later. Instead, let's talk about Skyrim.
Many of Skyrim's mods are also about adding stuff into the game - the Skyrim equivalent of "parts". Armor, weapons, spells, NPCs, foods, monsters, dungeons - add it all in and stir it up!
No matter how many Skyrim mods you add, you are unlikely to feel swamped. Even if you add 10,000 new swords, you're not likely to feel like you're drowning in swords. The reason is simple: you are never given a list of swords.
Skyrim is not a construction game, it's a scrounging game. Because of this, there is never a complete list of stuff. You stumble across it - a shop might have one or two, a bandit might equip one, one might pop up in a dungeon somewhere. You are never asked to pick a spear from the 10,000 possible spears. Instead, you're asked to pick between a Spear of Winter's Breath or a Kingfisher Spear.
In Skyrim, stuff is terrain. If you add more stuff, you widen the terrain. The player walks along and stumbles across the things you have added. They can choose whether to carry it with them as they go, or ignore it, or destroy it, or whatever.
The longer the player walks, the more times they stumble across mod content. And, of course, if the player knows what mods they want to focus on, they can seek out that place first and get that stuff first.
The equivalent would be if mods in Kerbal didn't add parts to your rocket construction facility, but instead scattered parts around the cosmos. If you went to the Mun, it wouldn't be to get science. It'd be to collect parts that are seeded there. There would have to be "core packs" too, of course, especially if we want to design decent-looking spaceplanes.
Anyway, these kinds of mods are "content packs".
There's also mods that change how the game works, and mods that do both at the same time. For example, Kerbal's "remote tech" mod, which radically changes how probes and communication work. Or any of Skyrim's "magic rebalancing" mods which change how magic works.
Functional packs that change how things work (while perhaps also introducing new content) are rarer than content packs for a few reasons. One is that it is way harder to program a new kind of activity than to just give new stats to a sword.
But even if they were the same difficulty, a player would still have more content packs installed than function packs. The reason is because of conflicts.
When designing for the future of mods, conflicts are at the heart of our considerations. The future of mods involves dozens, hundreds of mods installed at the same time. Conflicts will arise.
One kind of conflict is just in the player's head. For example, Kerbal has several life support mods. Aside from some minor resource overlapping due to shared resource names, none of them really conflict-conflict. It just doesn't make much sense to have them installed at the same time.
These are "categorical conflicts". Categorical conflicts are limits on the concept of your game. If all the players rush to create the same three mods over and over, it means that they all see your game as lacking in the same fundamental place. However, if the players create dozens of different mods and they rarely have any category conflicts, it means your game is a strong platform for them to explore their interests.
This doesn't necessarily apply to all categories. For example, Skyrim has hundreds of mods about sex and nudity: that's obviously a category the players really wanted to explore. But Skyrim also has dozens of mods about tweaking the rendering settings. That's not really a category in the game so much a thing the game does.
This is a "system conflict": the game has a system that works in a specific way, and two mods that both change that system are likely to conflict. Two mods that change how things render. Two mods that change how airplanes fly.
Kerbal life support mods are not a system conflict, because there was no system for life support in the game. But replacing the planet textures is a system conflict.
Sometimes it's hard to tell whether something is a category conflict or a system conflict. For example, the dozens of Skyrim mods that replace the base body and armor meshes/textures. These categories are not exclusive: many system conflicts are also category conflicts. One tells you what the players are interested in, the other tells you what the game is capable of.
"Resource conflicts" are the last type. This is when two mods conflict due to bad engineering. For example, one Skyrim mod which allows you to kill sleeping people, and another that allows you to drink their blood. When you hit the action button, which action happens?
That's a minor conflict, because most mods learned to add options to a context menu instead of overriding the basic operations. But there are similar conflicts that are more persistent: a mod that makes your NPCs loiter around towns realistically conflicts with a mod that makes them follow you in a more tactically-sound way. The conflict only exists because the NPCs don't understand that they should behave differently between a town and a dungeon.
When engineering a moddable game, it's probably worthwhile to consider these kinds of conflicts and understand how they will shape the modding community.
Categorical conflicts aren't necessarily bad - they let the player base cooperate in a specific way - but keep in mind that these will give rise to all-encompassing mods that dominate your modding community. These huge, complex mods will conflict with everything and everyone, so you need to give the modders the tools to subdivide their mods and/or create variations to get along with other mods.
Skyrim does this well - not through any effort of the Skyrim devs, but through efforts of the modding community. An in-game mod management console and an out-of-game mod install tool both offer players a bevy of options to specify not only what they want the mod to do, but also what mods they would like it to be compatible with.
Larger mods will have versioning, so the mod system should support versions right from the start, and allow for comparing the same mod to itself to see which one is more recent. Ideally, it should even support contacting a server to check whether the installed version is out of date. Super-ideally, a P2P system could be used to host mods to prevent centralization issues such as a primary distributor being bought out by Curse.
If you don't include these features, they'll probably arise on their own, but that usually means a pretty mangy, stumbling distribution system that will fall over dead randomly.
Moving down into the game itself, to prevent resource conflicts you should try to make flexible API integration for mods. Kerbal has a pretty good example of this in their resources system, where mods can specify the nature of resources such as oxygen, water, karbonite, etc. This doesn't require any C# code or libraries or anything, and every mod can access the resources.
A slightly better way to do it would be to allow mods to have part lists inside of resource/mod checks. IE, "if oxygen has been defined, add these three parts, otherwise don't bother" or "if Remote Tech is installed, use these parts instead of these". Allowing the mod to ask the player about configuration both up-front and in an in-game window should also be possible with a simple line of script. If conflicts arise, allow the player to choose which mod has supremacy, perhaps after checking with each mod for a fallback state.
Mods which are modular are probably going to slowly gain importance, so allowing modders to let players turn on and off bits of their mods will probably be more and more important.
However, all that stuff is the basic stuff. What we're really interested in is how mods are integrated into the game.
Those ideas are all about functional mods. But most mods are and will probably always be content packs. In fact, content packs are likely to become so prevalent that players will be creating and downloading them without even thinking of them as content packs, such as with Spore's creature sharing.
Content is going to explode. Space Engineers is touching on this - they let players create ships, and now their game infrastructure is buckling under the demand for better, faster, more interesting sharing options.
In addition to the skyrocketing amount of content and demands for ever-more-flexible content sharing capabilities, there's also the bugaboo that content packs often rely on other mods. If I have a mod which flies random player-created ships through my Space Engineers game, what happens when those ships have mods I do not have?
The Kerbal fail state is self-destruction: the ship flat-out can't be loaded. Space Engineers is slightly less bad, but you're still going to end up with busted ships.
Even if you autoshare mods, the mods will conflict!
The answer is wrappers.
Mod wrappers are in-game conceits that control which mods work, when. Rather than a mod flat-out overwriting the game's base code, the mod's code is only called when the game is "inside" the wrapper.
In Kerbal, that could be "space agency". So if Kerbal implemented a ship-sharing system with automatic mod-loading (impossible given their code base but let's pretend), the idea would be that your friend's ship would belong to their space agency. In turn, the mods their ship uses are considered separately from the mods you're using. Some might allow crosstalk - for example, if you both have a version of Remote Tech installed, the ships might be able to relay for each other. Others might be similar but incompatible, and not allow crosstalk - you have Remote Tech, she has Antenna Range.
The key to wrappers is figuring out the edges. What happens when one of your ships and one of her ships dock?
In Kerbal, the two ships are merged. So, what happens with the mods?
One option is to not allow ships from different agencies to dock. Another is to assign one player as leader and shut down all the mods from the other player - the parts that serve those mods are still loaded, but they are dormant. Another is to make the mods list actually per-part rather than per-agency - although the overhead might get absurd.
Imagine if in the next Elder Scrolls game, mods were by region. As you moved from land to land, things changed - the rendering changed, the rules of stealth changed, which swords were available changed. If you conquer a land, you can choose to change the mods. If you are playing multiplayer, you can shift between their world and yours, and the mods may change...
Anyway, the key to this concept is that the wrappers are clear in-game concepts that allow players to choose exactly what mods should be applied where. These aren't normally under the control of the modders.
To allow this, your code base will need to allow mods to register themselves rather than simply overwriting the game's base function. Your mod API needs to support not just the mod's capabilities within the game, but also the way the game knows the mod exists. It should allow mods to ask which mods are active in which wrappers, and it should ask mods whether they have anything to contribute.
For example, a sword content pack might have 10,000 different swords. Rather than making the mod responsible for littering the swords around the world, the mod would instead tell the game it has opinions about swords (or weapons). Whenever choosing weapons (for NPCs, for stores, as loot), the game would ask all interested mods whether they have any suggestions. Then the game creates a weighted stack and doles out the final result to the player. When you ask the mod for suggestions, you pass it an information pack it can ask questions from - what culture is it? How rich? What level?
If you want to be extra-safe, once you've collected a list, run the list back through the mods to see if they have any weighting adjustments they want to make. This would allow mods to synergize, or shut off the default content, or similar.
Even the information pack should be linked to this concept of suggestions from mods. The base content adds in level, wealth, culture, etc. But a mod might overlay a "biome" information bit, or a "minerals" bit, or any number of other things. This allows functional mods to behave in a way very similar to content mods with a minimum of hacking into the core game code.
Anyway, I'm looking forward to the mods of the future. I hope some of these ideas become common.
Right now, there are four reigning kings of mods. Kings and queens? Four reigning prime ministers of mods.
These four ministers of mods are Kerbal, Space Engineers, Skyrim, and Minecraft. I haven't done much Minecraft modding, so we'll put that aside and I'll explain my thoughts using the first three.
Kerbal and Space Engineers have similar fundamentals, so their mods often end up having a similar impact on the game. Both games feature picking parts out of a huge list and choosing where to put them. In short, they are construction games.
Most mods for these games add parts. However, this leads to swamping. No matter how many filters and categories you add, the player is tasked to consider all of these parts as potential components at all times. Kerbal has introduced a nice smooth slope via career mode, and Space Engineers is working towards a very diverse set of categories, but neither approach is perfect. In both cases the player will eventually have to be familiar with all parts all the time, and that means the guidance just delays the inevitable.
There are mods that are about things other than parts, but we'll talk about that later. Instead, let's talk about Skyrim.
Many of Skyrim's mods are also about adding stuff into the game - the Skyrim equivalent of "parts". Armor, weapons, spells, NPCs, foods, monsters, dungeons - add it all in and stir it up!
No matter how many Skyrim mods you add, you are unlikely to feel swamped. Even if you add 10,000 new swords, you're not likely to feel like you're drowning in swords. The reason is simple: you are never given a list of swords.
Skyrim is not a construction game, it's a scrounging game. Because of this, there is never a complete list of stuff. You stumble across it - a shop might have one or two, a bandit might equip one, one might pop up in a dungeon somewhere. You are never asked to pick a spear from the 10,000 possible spears. Instead, you're asked to pick between a Spear of Winter's Breath or a Kingfisher Spear.
In Skyrim, stuff is terrain. If you add more stuff, you widen the terrain. The player walks along and stumbles across the things you have added. They can choose whether to carry it with them as they go, or ignore it, or destroy it, or whatever.
The longer the player walks, the more times they stumble across mod content. And, of course, if the player knows what mods they want to focus on, they can seek out that place first and get that stuff first.
The equivalent would be if mods in Kerbal didn't add parts to your rocket construction facility, but instead scattered parts around the cosmos. If you went to the Mun, it wouldn't be to get science. It'd be to collect parts that are seeded there. There would have to be "core packs" too, of course, especially if we want to design decent-looking spaceplanes.
Anyway, these kinds of mods are "content packs".
There's also mods that change how the game works, and mods that do both at the same time. For example, Kerbal's "remote tech" mod, which radically changes how probes and communication work. Or any of Skyrim's "magic rebalancing" mods which change how magic works.
Functional packs that change how things work (while perhaps also introducing new content) are rarer than content packs for a few reasons. One is that it is way harder to program a new kind of activity than to just give new stats to a sword.
But even if they were the same difficulty, a player would still have more content packs installed than function packs. The reason is because of conflicts.
When designing for the future of mods, conflicts are at the heart of our considerations. The future of mods involves dozens, hundreds of mods installed at the same time. Conflicts will arise.
One kind of conflict is just in the player's head. For example, Kerbal has several life support mods. Aside from some minor resource overlapping due to shared resource names, none of them really conflict-conflict. It just doesn't make much sense to have them installed at the same time.
These are "categorical conflicts". Categorical conflicts are limits on the concept of your game. If all the players rush to create the same three mods over and over, it means that they all see your game as lacking in the same fundamental place. However, if the players create dozens of different mods and they rarely have any category conflicts, it means your game is a strong platform for them to explore their interests.
This doesn't necessarily apply to all categories. For example, Skyrim has hundreds of mods about sex and nudity: that's obviously a category the players really wanted to explore. But Skyrim also has dozens of mods about tweaking the rendering settings. That's not really a category in the game so much a thing the game does.
This is a "system conflict": the game has a system that works in a specific way, and two mods that both change that system are likely to conflict. Two mods that change how things render. Two mods that change how airplanes fly.
Kerbal life support mods are not a system conflict, because there was no system for life support in the game. But replacing the planet textures is a system conflict.
Sometimes it's hard to tell whether something is a category conflict or a system conflict. For example, the dozens of Skyrim mods that replace the base body and armor meshes/textures. These categories are not exclusive: many system conflicts are also category conflicts. One tells you what the players are interested in, the other tells you what the game is capable of.
"Resource conflicts" are the last type. This is when two mods conflict due to bad engineering. For example, one Skyrim mod which allows you to kill sleeping people, and another that allows you to drink their blood. When you hit the action button, which action happens?
That's a minor conflict, because most mods learned to add options to a context menu instead of overriding the basic operations. But there are similar conflicts that are more persistent: a mod that makes your NPCs loiter around towns realistically conflicts with a mod that makes them follow you in a more tactically-sound way. The conflict only exists because the NPCs don't understand that they should behave differently between a town and a dungeon.
When engineering a moddable game, it's probably worthwhile to consider these kinds of conflicts and understand how they will shape the modding community.
Categorical conflicts aren't necessarily bad - they let the player base cooperate in a specific way - but keep in mind that these will give rise to all-encompassing mods that dominate your modding community. These huge, complex mods will conflict with everything and everyone, so you need to give the modders the tools to subdivide their mods and/or create variations to get along with other mods.
Skyrim does this well - not through any effort of the Skyrim devs, but through efforts of the modding community. An in-game mod management console and an out-of-game mod install tool both offer players a bevy of options to specify not only what they want the mod to do, but also what mods they would like it to be compatible with.
Larger mods will have versioning, so the mod system should support versions right from the start, and allow for comparing the same mod to itself to see which one is more recent. Ideally, it should even support contacting a server to check whether the installed version is out of date. Super-ideally, a P2P system could be used to host mods to prevent centralization issues such as a primary distributor being bought out by Curse.
If you don't include these features, they'll probably arise on their own, but that usually means a pretty mangy, stumbling distribution system that will fall over dead randomly.
Moving down into the game itself, to prevent resource conflicts you should try to make flexible API integration for mods. Kerbal has a pretty good example of this in their resources system, where mods can specify the nature of resources such as oxygen, water, karbonite, etc. This doesn't require any C# code or libraries or anything, and every mod can access the resources.
A slightly better way to do it would be to allow mods to have part lists inside of resource/mod checks. IE, "if oxygen has been defined, add these three parts, otherwise don't bother" or "if Remote Tech is installed, use these parts instead of these". Allowing the mod to ask the player about configuration both up-front and in an in-game window should also be possible with a simple line of script. If conflicts arise, allow the player to choose which mod has supremacy, perhaps after checking with each mod for a fallback state.
Mods which are modular are probably going to slowly gain importance, so allowing modders to let players turn on and off bits of their mods will probably be more and more important.
However, all that stuff is the basic stuff. What we're really interested in is how mods are integrated into the game.
Those ideas are all about functional mods. But most mods are and will probably always be content packs. In fact, content packs are likely to become so prevalent that players will be creating and downloading them without even thinking of them as content packs, such as with Spore's creature sharing.
Content is going to explode. Space Engineers is touching on this - they let players create ships, and now their game infrastructure is buckling under the demand for better, faster, more interesting sharing options.
In addition to the skyrocketing amount of content and demands for ever-more-flexible content sharing capabilities, there's also the bugaboo that content packs often rely on other mods. If I have a mod which flies random player-created ships through my Space Engineers game, what happens when those ships have mods I do not have?
The Kerbal fail state is self-destruction: the ship flat-out can't be loaded. Space Engineers is slightly less bad, but you're still going to end up with busted ships.
Even if you autoshare mods, the mods will conflict!
The answer is wrappers.
Mod wrappers are in-game conceits that control which mods work, when. Rather than a mod flat-out overwriting the game's base code, the mod's code is only called when the game is "inside" the wrapper.
In Kerbal, that could be "space agency". So if Kerbal implemented a ship-sharing system with automatic mod-loading (impossible given their code base but let's pretend), the idea would be that your friend's ship would belong to their space agency. In turn, the mods their ship uses are considered separately from the mods you're using. Some might allow crosstalk - for example, if you both have a version of Remote Tech installed, the ships might be able to relay for each other. Others might be similar but incompatible, and not allow crosstalk - you have Remote Tech, she has Antenna Range.
The key to wrappers is figuring out the edges. What happens when one of your ships and one of her ships dock?
In Kerbal, the two ships are merged. So, what happens with the mods?
One option is to not allow ships from different agencies to dock. Another is to assign one player as leader and shut down all the mods from the other player - the parts that serve those mods are still loaded, but they are dormant. Another is to make the mods list actually per-part rather than per-agency - although the overhead might get absurd.
Imagine if in the next Elder Scrolls game, mods were by region. As you moved from land to land, things changed - the rendering changed, the rules of stealth changed, which swords were available changed. If you conquer a land, you can choose to change the mods. If you are playing multiplayer, you can shift between their world and yours, and the mods may change...
Anyway, the key to this concept is that the wrappers are clear in-game concepts that allow players to choose exactly what mods should be applied where. These aren't normally under the control of the modders.
To allow this, your code base will need to allow mods to register themselves rather than simply overwriting the game's base function. Your mod API needs to support not just the mod's capabilities within the game, but also the way the game knows the mod exists. It should allow mods to ask which mods are active in which wrappers, and it should ask mods whether they have anything to contribute.
For example, a sword content pack might have 10,000 different swords. Rather than making the mod responsible for littering the swords around the world, the mod would instead tell the game it has opinions about swords (or weapons). Whenever choosing weapons (for NPCs, for stores, as loot), the game would ask all interested mods whether they have any suggestions. Then the game creates a weighted stack and doles out the final result to the player. When you ask the mod for suggestions, you pass it an information pack it can ask questions from - what culture is it? How rich? What level?
If you want to be extra-safe, once you've collected a list, run the list back through the mods to see if they have any weighting adjustments they want to make. This would allow mods to synergize, or shut off the default content, or similar.
Even the information pack should be linked to this concept of suggestions from mods. The base content adds in level, wealth, culture, etc. But a mod might overlay a "biome" information bit, or a "minerals" bit, or any number of other things. This allows functional mods to behave in a way very similar to content mods with a minimum of hacking into the core game code.
Anyway, I'm looking forward to the mods of the future. I hope some of these ideas become common.
Subscribe to:
Posts (Atom)