I really like analyzing IP franchises for the kinds of stories they support, and the kinds of cultural baggage they are weighted with.
By "IP franchises" I mean things like Star Wars or Lord of the Rings or Mass Effect: universes that can support many stories. Universes with a lot of fanon. I guess it includes things like My Little Pony and Adventure Time and such, but I do try to limit my analysis to universes I've actually witnessed. I don't try to guess at the sorts of stories and baggage MLP carries, since I've never seen it.
When I say that a universe can carry a kind of story, I don't mean that it's the only kind of story that can be told, just that it's the kind of story the universe is best at. For example, Star Wars is best at stories of redemption and combating darkness - internal, systemic, or universal. Star Trek is best at stories that explore the breadth and diversity of life and culture. Both have other kinds of stories in them, but their iconic stories are of those types.
I've always analyzed universes like that, and I've enjoyed how those stories reflect on fanon. Star Wars has a fanbase very dedicated to the original movies because the fanbase wants stories like those: stories of fighting against darkness. Later movies had a weaker focus on that. If you read the expanded universe stuff, you can see much of it sticks very close to the core stories that Star Wars seemed best at, and nearly all the fanfiction does. Fighting darkness is very compelling, no matter where the darkness is found or how it is embodied.
Star Trek, on the other hand, has many fans but they rarely highlight the same seasons. I think this is because the best story type is "exploring diversity from the point of view of white bread mainstream culture", and that's a story type that evolved with each season along with cultural norms. So you get attached to the seasons that were closest to your cultural norms, and therefore tickled your concept of "diversity" most.
It's really fun to think on this level, although a lot of the thoughts are guesswork. You can certainly disagree with this kind of analysis, especially if you were struck differently by the same universes I've described. But one thing I have started to notice is that these universes, these franchises, they are more than just the stories they can support. They are also the baggage they bring with them.
What made me really start to notice this was the rapid-fire discussion of Mass Effect, Star Wars, and Super Mario happening on Twitter recently. All of these franchises have baggage.
Baggage isn't inherently bad. For example, Star Wars has light sabers as baggage. If you tell a Star Wars story that includes Jedi, it's going to include light sabers, and you're going to have to keep in mind that the Jedi can, you know, cut anything apart in a flash. It'll weigh on your mind and constrain your story, but that's not necessarily bad and, like all creative work, the right constraints can actually fire you up.
Not all baggage is as intentional as light sabers, though.
The easiest example of unintentional baggage is deeply ingrained sexism and racism. Especially with older universes, there's a lot of passive assumptions about sex and race. For example, Japanese game studios are still struggling to stop being total creepers in how they treat characters like Peach and Samus. American companies aren't doing much better, with the new Star Wars featuring a grand total of one new woman into the cast.
Racism is also part of the culture of many universes. Not introduced on purpose, but just incidentally as part of the culture of the developers that they failed to properly account for. Fantasy settings tend to have this worst.
The older a setting is, the more sexist and racist it tends to implicitly be. For example, in Tolkien's works, the good guys are all European white men. Whether Tolkien was racist or sexist isn't the point: the setting has baggage. Unless you actively rebel against it, it'll creep into every related story. This limits what cultures it can appeal to: as time passes, what we are willing to put up with changes, and that kind of exclusion is less acceptable.
More modern universes tend to be more inclusive, but they use a technique that will, in the long run, be equally problematic. This is the "generic diversity" approach.
As an easy example, in Mass Effect the human species is represented in a fairly diverse manner, especially in the later games. Decent spectrum of color, decent gender ratio, even a steadily increasing diversity of sexual preference.
However, this isn't a situation where a woman's point of view is represented, or a Hispanic point of view, or a gay point of view. Instead, they are all given the default point of view of the developer. That is, they are all written as straight white men, and most of the intercharacter relationships among the human cast are relationships straight white guys have, with the focus on the kinds of strife straight white guys tend to have with each other - that one coworker who's racist, for example.
All of the cultural pieces actually relating to being female, or black, or gay, or religious, or homeless, or poor - these are all given to aliens.
This doesn't mean the aliens represent the point of view of these cultures, or the people who have these issues. Nope, they still don't have much of a word in these games. Instead, the issues can still be treated in the same way as they have been for decades, just now people have a harder time calling you out on it because you've changed out the faces.
Not only is this lazy, it's also not very good at keeping up with the changing culture in the real world. The Asari and the Quarians both carry a lot of aging sexist and/or racist baggage with them. In time, those species will need to be completely reinvented to stay acceptable, let alone relevant. In fact, you can already see that happening with the Asari, whose representation grasps at dozens of different straws, some more unfortunate than others.
Although I say this is lazy, it's still 100x better than the exclusionary settings of last century.
Anyway, that's my own opinion on the matter.
Wednesday, April 30, 2014
Monday, April 28, 2014
Survival and the Compromised Base
Recently I played a game called FarSky. This isn't a review of FarSky, but instead about an idea it inspired.
Originally I wrote a long, meandering essay on the hows and whys of this idea, but instead I'll save you some time and just present it straight-up.
You live at the bottom of the ocean. You have a science fiction backpack - it's an electrolysis machine that can put out quite a lot of atmosphere, limited only by battery life. You can recharge batteries from any power source, or deploy a very long thermal wire to float high above, and sit still for a long time. Of course, as long as you have battery power, the backpack can keep you breathing, but the real use of the backpack is to fill up aquatic bases.
You can make an aquatic base out of anything. Shipping containers. A cave. A sunken ship. An abandoned research base. Sunken houses and vans, if they aren't too rotted. Subways. Any place that is vaguely airtight. Activate the backpack and pump air into it. If there's holes, the water level will stop dropping at that point and you'll need to patch them to put more air in. If there's multiple rooms, maybe you close the bulkhead and fill one room at a time, slowly conquering the base bit by bit.
The issue is that you're not really very useful. All you really do is fill things with air and patch small holes. You can't drag heavy things around, or mend a shattered window, or cobble together a bed, or grow plants. You need NPCs for that. And, of course, the NPCs need some place with air to stay.
Not all locations are created equal. Like most survival games, as you become better-equipped you'll want to move further afield, into areas with unique new resources. Unlike most such games, the bases aren't completely stable. While there is some advanced tech to help scrub a base's air supply, fundamentally they only have as much oxygen as you put in using your backpack. That means that you'll want to keep your NPCs consolidated to just one or two bases, or you'll spend all your time running around refilling your bases rather than exploring. So as you march onward, you'll need to abandon one base and move to another in a new location. Fortunately, as long as there's decent resting stops along the route, the NPCs will happily drag all the stuff in the old base to the new base.
The early part of the game will be mostly to get you used to the idea of moving around the ocean, finding small places to fill with air, acquiring one or two NPCs to help you with basic crafting. You tag resources you find in the open ocean, the NPCs will go fetch it and bring it home, allowing you to steadily get a grasp on how that sort of thing works.
But the gameplay of expanding into a base is the heart of the game. Reclaiming a base room by room, patching the cracks you can patch, sealing off the rooms with larger holes. Creating an airspace, moving your NPCs into it. Having them patch up the holes you can't handle, arrange the furniture. Going out to find things like shipping containers or vans, tagging them for recovery, and then attaching them to your base to steadily expand it. Making your base larger has purpose even if you don't plan to put any more stuff in that space: every additional airspace volume you add is more time the base can go without being refilled.
The NPCs have classes, tiers, and levels. For example, an NPC might be a retrieval specialist, able to quickly move large objects. Or they might be a craftsman, capable of building furniture. An electrician, capable of repairing or creating complex devices, including tools other classes might need. A plumber, capable of sealing up holes and creating infrastructure for things like toilets and showers. Many others.
Levels steadily increase as time passes. The higher someone's level, the faster they accomplish tasks.
Tiers are based around quality of life. If someone is living huddled in a shipping container, they aren't going to be capable of doing much work. But if they live in a vast base with all the amenities, they'll be able to create masterpieces rivaling anything that was created on land.
Hopefully the framework of the game is becoming clear. A cycle of expanding into bases, improving existing bases, scouting for resources, getting NPCs, and shuttling NPCs between bases.
I think this could be really compelling, but the flavor would need to be managed well. You'd want to create an environment where swimming around felt really compelling. You'd want the steady way you convert a base to feel heavy: you go from swimming in these rooms to walking in them, little by little. You'd want hanging around with NPCs to feel relaxing and interesting, so you feel like these are people you would enjoy being stuck at the bottom of the ocean with.
Hm. I'd love a game like that. Maybe I'll program something like that someday, because the basic concept is a powerful one that isn't really explored much.
There are games where you cobble together bases, but it's typically just attaching individual pieces and then they work. This is being inside the base and steadily filling it with air one room at a time.
Originally I wrote a long, meandering essay on the hows and whys of this idea, but instead I'll save you some time and just present it straight-up.
You live at the bottom of the ocean. You have a science fiction backpack - it's an electrolysis machine that can put out quite a lot of atmosphere, limited only by battery life. You can recharge batteries from any power source, or deploy a very long thermal wire to float high above, and sit still for a long time. Of course, as long as you have battery power, the backpack can keep you breathing, but the real use of the backpack is to fill up aquatic bases.
You can make an aquatic base out of anything. Shipping containers. A cave. A sunken ship. An abandoned research base. Sunken houses and vans, if they aren't too rotted. Subways. Any place that is vaguely airtight. Activate the backpack and pump air into it. If there's holes, the water level will stop dropping at that point and you'll need to patch them to put more air in. If there's multiple rooms, maybe you close the bulkhead and fill one room at a time, slowly conquering the base bit by bit.
The issue is that you're not really very useful. All you really do is fill things with air and patch small holes. You can't drag heavy things around, or mend a shattered window, or cobble together a bed, or grow plants. You need NPCs for that. And, of course, the NPCs need some place with air to stay.
Not all locations are created equal. Like most survival games, as you become better-equipped you'll want to move further afield, into areas with unique new resources. Unlike most such games, the bases aren't completely stable. While there is some advanced tech to help scrub a base's air supply, fundamentally they only have as much oxygen as you put in using your backpack. That means that you'll want to keep your NPCs consolidated to just one or two bases, or you'll spend all your time running around refilling your bases rather than exploring. So as you march onward, you'll need to abandon one base and move to another in a new location. Fortunately, as long as there's decent resting stops along the route, the NPCs will happily drag all the stuff in the old base to the new base.
The early part of the game will be mostly to get you used to the idea of moving around the ocean, finding small places to fill with air, acquiring one or two NPCs to help you with basic crafting. You tag resources you find in the open ocean, the NPCs will go fetch it and bring it home, allowing you to steadily get a grasp on how that sort of thing works.
But the gameplay of expanding into a base is the heart of the game. Reclaiming a base room by room, patching the cracks you can patch, sealing off the rooms with larger holes. Creating an airspace, moving your NPCs into it. Having them patch up the holes you can't handle, arrange the furniture. Going out to find things like shipping containers or vans, tagging them for recovery, and then attaching them to your base to steadily expand it. Making your base larger has purpose even if you don't plan to put any more stuff in that space: every additional airspace volume you add is more time the base can go without being refilled.
The NPCs have classes, tiers, and levels. For example, an NPC might be a retrieval specialist, able to quickly move large objects. Or they might be a craftsman, capable of building furniture. An electrician, capable of repairing or creating complex devices, including tools other classes might need. A plumber, capable of sealing up holes and creating infrastructure for things like toilets and showers. Many others.
Levels steadily increase as time passes. The higher someone's level, the faster they accomplish tasks.
Tiers are based around quality of life. If someone is living huddled in a shipping container, they aren't going to be capable of doing much work. But if they live in a vast base with all the amenities, they'll be able to create masterpieces rivaling anything that was created on land.
Hopefully the framework of the game is becoming clear. A cycle of expanding into bases, improving existing bases, scouting for resources, getting NPCs, and shuttling NPCs between bases.
I think this could be really compelling, but the flavor would need to be managed well. You'd want to create an environment where swimming around felt really compelling. You'd want the steady way you convert a base to feel heavy: you go from swimming in these rooms to walking in them, little by little. You'd want hanging around with NPCs to feel relaxing and interesting, so you feel like these are people you would enjoy being stuck at the bottom of the ocean with.
Hm. I'd love a game like that. Maybe I'll program something like that someday, because the basic concept is a powerful one that isn't really explored much.
There are games where you cobble together bases, but it's typically just attaching individual pieces and then they work. This is being inside the base and steadily filling it with air one room at a time.
Wednesday, April 23, 2014
Violence in Sci Fi Construction Games
There's a lot of cool games in the pipeline these days, and a lot of them are about building cool things in scifi settings. The problem is, they all then universally talk about blowing things up with the things you built.
That's really a bad call.
Combat is not compatible with the sort of internally-focused construction games these people are building. We've become so used to adding combat to everything that people have forgotten to think about whether combat is a good fit. I think the reason most designers seem to lose track of whether combat is a good fit is because they are used to customization rather than construction.
See, in most space combat games, you can customize your ship. Add in a better laser, change how much energy is going to your shields, restock on missiles, and stick in a better engine. Customization is fine for a combat game, because it's fundamentally the same as equipping a character. You are changing how your ship relates to the world around it: improved firepower, faster speed, more cargo, whatever.
But with a lot of these new games, you aren't simply customizing a ship. You're constructing it, brick by brick. For example, in Space Engineers, you build a ship out of Minecraft-style bricks.
These ships are built with combat in mind, because uh... because... ... well... uh... lasers are cool?
The problem is that this kind of construction is an internally-focused system. The end result of weapons, shields, engines, and other combat stats ends up feeling very forced, because the actual construction of the ship is about making a ship exist. This is not about making a ship relate to the outside world, it is about making the ship exist in its full complexity, with all the walkways and landing pads and sleek planes and whatever.
If you just care about how it relates to the outside world, you end up with a very ugly optimized ship. It feels wrong and stupid-looking. Even if you do that, the combat is never very interesting because it is too, well, too realistic. Things get damaged arbitrarily. Things resist arbitrarily. It's hard to tell how much damage you're doing. It's hard to tell how much damage you're actually taking. There's too much noise introduced by the extremely fine grain of detail that everything has.
You really need to consider whether your game is about customization or construction, because construction is not compatible with external challenges.
When you're building something where each piece relates to specific other pieces in direct ways, the challenges need to be about THAT. This trap moves a person towards that trap. This walkway connects that hall to this warp core. This wire hooks that light to this power source. That building creates a certain amount of cash but annoys all other buildings within 200m.
But there are base-building games that are externally-focused. For example, every RTS.
An externally-focused base-building game looks the same as an internally-focused game at first glance. They share a lot of similarities: putting things down in specific places, managing resources, and so on. However, an RTS base is not very internally complex. The buildings don't relate to each other very directly, but instead only indirectly through resource production and consumption. Where you choose to put them is more about the constraints of the map and your guess as to your enemy's tactics, rather than having to place them to directly relate to other buildings.
You could argue fine points. For example, you could argue that a combination of turrets and walls is sometimes used, and those do physically relate to each other. Similarly, you could argue that something like a goo field directly relates to other buildings. In the end, the line can be a bit vague, but I don't think anyone would argue that building long lines of walls is the core gameplay of Starcraft.
Putting aside the sometimes blurry edge cases, I would argue that internally-focused construction games are inherently a bad match for combat gameplay. Combat boils your avatar's performance down to some stats, while complex construction is focused on exactly the opposite.
That's really a bad call.
Combat is not compatible with the sort of internally-focused construction games these people are building. We've become so used to adding combat to everything that people have forgotten to think about whether combat is a good fit. I think the reason most designers seem to lose track of whether combat is a good fit is because they are used to customization rather than construction.
See, in most space combat games, you can customize your ship. Add in a better laser, change how much energy is going to your shields, restock on missiles, and stick in a better engine. Customization is fine for a combat game, because it's fundamentally the same as equipping a character. You are changing how your ship relates to the world around it: improved firepower, faster speed, more cargo, whatever.
But with a lot of these new games, you aren't simply customizing a ship. You're constructing it, brick by brick. For example, in Space Engineers, you build a ship out of Minecraft-style bricks.
These ships are built with combat in mind, because uh... because... ... well... uh... lasers are cool?
The problem is that this kind of construction is an internally-focused system. The end result of weapons, shields, engines, and other combat stats ends up feeling very forced, because the actual construction of the ship is about making a ship exist. This is not about making a ship relate to the outside world, it is about making the ship exist in its full complexity, with all the walkways and landing pads and sleek planes and whatever.
If you just care about how it relates to the outside world, you end up with a very ugly optimized ship. It feels wrong and stupid-looking. Even if you do that, the combat is never very interesting because it is too, well, too realistic. Things get damaged arbitrarily. Things resist arbitrarily. It's hard to tell how much damage you're doing. It's hard to tell how much damage you're actually taking. There's too much noise introduced by the extremely fine grain of detail that everything has.
You really need to consider whether your game is about customization or construction, because construction is not compatible with external challenges.
When you're building something where each piece relates to specific other pieces in direct ways, the challenges need to be about THAT. This trap moves a person towards that trap. This walkway connects that hall to this warp core. This wire hooks that light to this power source. That building creates a certain amount of cash but annoys all other buildings within 200m.
But there are base-building games that are externally-focused. For example, every RTS.
An externally-focused base-building game looks the same as an internally-focused game at first glance. They share a lot of similarities: putting things down in specific places, managing resources, and so on. However, an RTS base is not very internally complex. The buildings don't relate to each other very directly, but instead only indirectly through resource production and consumption. Where you choose to put them is more about the constraints of the map and your guess as to your enemy's tactics, rather than having to place them to directly relate to other buildings.
You could argue fine points. For example, you could argue that a combination of turrets and walls is sometimes used, and those do physically relate to each other. Similarly, you could argue that something like a goo field directly relates to other buildings. In the end, the line can be a bit vague, but I don't think anyone would argue that building long lines of walls is the core gameplay of Starcraft.
Putting aside the sometimes blurry edge cases, I would argue that internally-focused construction games are inherently a bad match for combat gameplay. Combat boils your avatar's performance down to some stats, while complex construction is focused on exactly the opposite.
Thursday, April 17, 2014
Interstellar Archaeology
My friend ran a KickStarter about space and time being insanely vast. Most scifi compresses both space and time, but he wanted to show it in the proper scale. Me too! It inspired me, and I spent a lot of time thinking about it. And I decided that my contribution to this theme would be interstellar archaeology.
No matter how many millions of years your society has, it's just a tiny blip. You will never meet another living alien species. Even if you live for a million years on a million suns, you won't meet them. Space is too big, time is too vast.
But you can meet them. As long as you don't mind them being dead.
So this is a game about archaeology, about discovering ancient, lapsed civilizations and digitally recreating them to live anew in a huge simulation. You aren't part of a civilization yourself: humans have "ascended" and you're just kicking around exploring the galaxy for a few million more years until you get bored of it. And you've decided to search the universe for dead civilizations and bring them back to life in your personal computer, manage your own universe that is chock full of alien species and civilizations. Maybe trade info with other ex-humans that are still kicking around.
The mechanics of finding and studying ruins is not what I want to talk about. Instead, I want to talk about how to seed them. An algorithm for creating dead civilizations.
Now, one way to do this is to simulate the civilization and come up with a big stack of places they went and things they did. However, this has the serious downside of being dull as paste. We would like the players to actually be interested in what happened, and that means humanizing it. Here's what I've come up with:
If you search a given place for archaeological clues, you have a chance of finding a random clue from a random time period. Say, you discover a 100,000 year old derelict space ship caught in orbit around a moon.
There are two keys to what this ship "means", archaeologically speaking.
The first key is that the ship uses "compatible" clues. So if you are aware of a colony on a nearby planet from 2 million years ago, perhaps the ship is related to that. If you are aware of a colony from 110,000 years ago 20 light years away, maybe the ship is related to that. But the timing involved is important: if the ship is related to the 2 million year old colony, it certainly couldn't have come from it. Instead, it must have been searching for it, well aware of its age and likely demise.
That brings us to the second key: the archaeological find is not categorized by where it is from or what it belongs to, but instead by mission. This gives players a strong hook to get interested. Usually, where they are from will arise pretty obviously from their mission. Moreover, as the mission emerges, archaeological seeds are laid for the player to discover elsewhere.
For example, there is a million-year-old colony nearby. Is the ship involved with it somehow? There is a 110,000-year-old colony 200 light years away. Is the ship involved with that somehow?
We don't simply determine where the ship is "from" or who built it. No, we care about the mission. Is the ship related to the million-year-old colony? If so, what was its mission? To reach the colony, almost certainly. Why would they have wanted to reach the colony?
Well, not to put too fine a point on it, but we don't know why. The player doesn't know either. All they know is that the ship had that colony in the last surviving star chart.
There's not a whole lot of research the player can do aboard the derelict, because it is truly ancient and basically just a jumble of floating rust particles. All the player can really do to follow the lead is to head for that colony. At least until some new information tells them what to look for in this ship.
Maybe this player doesn't even know there is a colony there, just this star chart. Either way, when she searches for events ~100,000 years ago, she finds an archaeological event that was seeded by the discovery of the ship. What is it, exactly? Well, like the original discovery of the ship, it's largely random. She discovers that (rolls dice) a seed vault was stolen.
A seed vault from an ancient civilization was stolen?
There's a lot of ways she can go from this. One is to read into the million-year-old colony more, since she's obviously going to discover it exists given that its seed vault was stolen. However, she can also keep concentrating on the seed vault.
It automatically works its way into the mission parameters of the ship that stole it. They were going to the ancient colony... for seeds... and they got them. What? Why?
We need to come up with a driving response, so the algorithm looks up all possible explanations in the dictionary and decides there was a genetic plague on the 110,000-year-old colony, and they needed 'pure' ancient DNA samples to fight it. This, in turn, plants several more archaeological seeds. One on the 110,000-year-old colony - evidence of genetic collapse. One on the ship: evidence of the seed vault.
These missions can keep expanding, but a key point is that this isn't a one-player game. This player isn't the only one working with this set of facts.
Another player lands on the 110,000-year-old colony and searches for clues related to it. Since he's in the right place and searching in the right era, he discovers evidence of the genetic plague. He doesn't know quite what it is, though: a massive ecological collapse off some kind. The chain itself knows that a ship was launched with a specific mission because of this catastrophe, so it spawns an event for the new player to discover: the construction of a fleet of ships to try and find pure DNA. This seed of a space exodus is planted with the discovery of the ecological collapse: it generates only when needed.
The new player can discover this event by continuing to search in the right place and time. Rather than discovering the location of the originally-discovered ship, this player instead finds star charts pointing to dozens of planets. Each of these planets is then allocated a "phantom" of the originally-discovered quest line. If the player goes to search one of those locations, it will randomly determine which elements to clone from the original quest line. It might have a million-year-old colony. It might have an event 100,000 years ago where someone stole seed banks (or attempted to, if there was no colony spawned). It might have a ship lying derelict nearby.
Even if the original player gets sidetracked and never finished fleshing out what happened to the originally discovered ship, their progress lives on in the phantom missions descended from that work. And, as people stumble into pieces of the missions, they will usually be able to track the missions back to the homeworld. Many people will become familiar with the way that colony was destroyed by the plague, and their desperate final missions to save themselves. As they explore that time and space, they will discover more and more details about who these people were, what they were like, and what happened afterwards and before. These facts will be easier and easier for subsequent players to discover and, in turn, creating digital recreations of these people and this colony becomes easier and easier.
So the basic progression is like this:
1) Discover something. It will relate to existing discoveries via a mission template, and will create new clues to partially fill in that template.
2) Discover clues spawned as part of a mission template. This will spawn more clues filling out the mission template or spawn pre- and post-mission events. The more interesting/sensical clues will be discovered first, creating a sort of filter to weed out the worst randomness.
3) Research pre- and post-mission events to create echoes of the partially-filled-out mission template. This will allow for events/civilizations to become big and spread between players.
4) Connect clues/events to clues/events from other chains that happened in the same place and time. This will allow civilizations to become dense and have coherent culture/items/event chains.
In the end, the civilization is not formed by a series of algorithms determining how they expanded and what tech they had. Instead, it is determined by a random events being connected and amplified. The hard part is creating the unique content elements such as alien race design, ship appearance, and so on. The second most hard part is writing up a set of adaptive mission templates.
Anyway, that's my idea.
No matter how many millions of years your society has, it's just a tiny blip. You will never meet another living alien species. Even if you live for a million years on a million suns, you won't meet them. Space is too big, time is too vast.
But you can meet them. As long as you don't mind them being dead.
So this is a game about archaeology, about discovering ancient, lapsed civilizations and digitally recreating them to live anew in a huge simulation. You aren't part of a civilization yourself: humans have "ascended" and you're just kicking around exploring the galaxy for a few million more years until you get bored of it. And you've decided to search the universe for dead civilizations and bring them back to life in your personal computer, manage your own universe that is chock full of alien species and civilizations. Maybe trade info with other ex-humans that are still kicking around.
The mechanics of finding and studying ruins is not what I want to talk about. Instead, I want to talk about how to seed them. An algorithm for creating dead civilizations.
Now, one way to do this is to simulate the civilization and come up with a big stack of places they went and things they did. However, this has the serious downside of being dull as paste. We would like the players to actually be interested in what happened, and that means humanizing it. Here's what I've come up with:
If you search a given place for archaeological clues, you have a chance of finding a random clue from a random time period. Say, you discover a 100,000 year old derelict space ship caught in orbit around a moon.
There are two keys to what this ship "means", archaeologically speaking.
The first key is that the ship uses "compatible" clues. So if you are aware of a colony on a nearby planet from 2 million years ago, perhaps the ship is related to that. If you are aware of a colony from 110,000 years ago 20 light years away, maybe the ship is related to that. But the timing involved is important: if the ship is related to the 2 million year old colony, it certainly couldn't have come from it. Instead, it must have been searching for it, well aware of its age and likely demise.
That brings us to the second key: the archaeological find is not categorized by where it is from or what it belongs to, but instead by mission. This gives players a strong hook to get interested. Usually, where they are from will arise pretty obviously from their mission. Moreover, as the mission emerges, archaeological seeds are laid for the player to discover elsewhere.
For example, there is a million-year-old colony nearby. Is the ship involved with it somehow? There is a 110,000-year-old colony 200 light years away. Is the ship involved with that somehow?
We don't simply determine where the ship is "from" or who built it. No, we care about the mission. Is the ship related to the million-year-old colony? If so, what was its mission? To reach the colony, almost certainly. Why would they have wanted to reach the colony?
Well, not to put too fine a point on it, but we don't know why. The player doesn't know either. All they know is that the ship had that colony in the last surviving star chart.
There's not a whole lot of research the player can do aboard the derelict, because it is truly ancient and basically just a jumble of floating rust particles. All the player can really do to follow the lead is to head for that colony. At least until some new information tells them what to look for in this ship.
Maybe this player doesn't even know there is a colony there, just this star chart. Either way, when she searches for events ~100,000 years ago, she finds an archaeological event that was seeded by the discovery of the ship. What is it, exactly? Well, like the original discovery of the ship, it's largely random. She discovers that (rolls dice) a seed vault was stolen.
A seed vault from an ancient civilization was stolen?
There's a lot of ways she can go from this. One is to read into the million-year-old colony more, since she's obviously going to discover it exists given that its seed vault was stolen. However, she can also keep concentrating on the seed vault.
It automatically works its way into the mission parameters of the ship that stole it. They were going to the ancient colony... for seeds... and they got them. What? Why?
We need to come up with a driving response, so the algorithm looks up all possible explanations in the dictionary and decides there was a genetic plague on the 110,000-year-old colony, and they needed 'pure' ancient DNA samples to fight it. This, in turn, plants several more archaeological seeds. One on the 110,000-year-old colony - evidence of genetic collapse. One on the ship: evidence of the seed vault.
These missions can keep expanding, but a key point is that this isn't a one-player game. This player isn't the only one working with this set of facts.
Another player lands on the 110,000-year-old colony and searches for clues related to it. Since he's in the right place and searching in the right era, he discovers evidence of the genetic plague. He doesn't know quite what it is, though: a massive ecological collapse off some kind. The chain itself knows that a ship was launched with a specific mission because of this catastrophe, so it spawns an event for the new player to discover: the construction of a fleet of ships to try and find pure DNA. This seed of a space exodus is planted with the discovery of the ecological collapse: it generates only when needed.
The new player can discover this event by continuing to search in the right place and time. Rather than discovering the location of the originally-discovered ship, this player instead finds star charts pointing to dozens of planets. Each of these planets is then allocated a "phantom" of the originally-discovered quest line. If the player goes to search one of those locations, it will randomly determine which elements to clone from the original quest line. It might have a million-year-old colony. It might have an event 100,000 years ago where someone stole seed banks (or attempted to, if there was no colony spawned). It might have a ship lying derelict nearby.
Even if the original player gets sidetracked and never finished fleshing out what happened to the originally discovered ship, their progress lives on in the phantom missions descended from that work. And, as people stumble into pieces of the missions, they will usually be able to track the missions back to the homeworld. Many people will become familiar with the way that colony was destroyed by the plague, and their desperate final missions to save themselves. As they explore that time and space, they will discover more and more details about who these people were, what they were like, and what happened afterwards and before. These facts will be easier and easier for subsequent players to discover and, in turn, creating digital recreations of these people and this colony becomes easier and easier.
So the basic progression is like this:
1) Discover something. It will relate to existing discoveries via a mission template, and will create new clues to partially fill in that template.
2) Discover clues spawned as part of a mission template. This will spawn more clues filling out the mission template or spawn pre- and post-mission events. The more interesting/sensical clues will be discovered first, creating a sort of filter to weed out the worst randomness.
3) Research pre- and post-mission events to create echoes of the partially-filled-out mission template. This will allow for events/civilizations to become big and spread between players.
4) Connect clues/events to clues/events from other chains that happened in the same place and time. This will allow civilizations to become dense and have coherent culture/items/event chains.
In the end, the civilization is not formed by a series of algorithms determining how they expanded and what tech they had. Instead, it is determined by a random events being connected and amplified. The hard part is creating the unique content elements such as alien race design, ship appearance, and so on. The second most hard part is writing up a set of adaptive mission templates.
Anyway, that's my idea.
Tuesday, April 01, 2014
Backstories are not characterization
I find that the biggest pitfall video game RPGs suffer is that the characters are pretty static and shallow.
That's because the depth of the game is in the fighting. The character personalities, lifestyles, and beliefs don't evolve, but their levels, stats, equipment, and inventory does.
Think about it: in Dragon Age, you have a bunch of reasonably interesting (if very stock) characters. DA is one of the few games to really highlight intercharacter interactions. Not only do you actually have a camp where everyone hangs out and they try to sell you for-pay DLC, but while you're wandering around the characters will usually chat amongst themselves. Out of all of the RPGs you can get, this is probably the one with the most intercharacter interactions and character arcs.
However, even then it is incredibly bad at it compared to even the most poorly-run of tabletop games.
The problem is that the way we interact with characters is via interactive dialogs. This is a terrible way to do it. Firstly, because we don't have a personality, so it's hard to contrast them against us. Secondly, because the fundamental concept of a dialog tree and relationship end states is awful.
As an example, look at the characters in Dragon Age. Alistair is a templar that is secretly a high prince. Morrigan is a total jerk that is inheriting an exotic form of blood magic while living in a forest. Wynne is an elderly mage that has been secretly resurrected by a spirit that isn't supposed to exist.
Dialog is really the only way to get to know these characters, and the dialog engine is a branching tree. So when you talk to these characters, you slowly learn their stories bit by bit as the game progresses. However, the backstories are literally just grist for the dialog wheel. Since you can only get to know them through dialog, you need to have scads and scads of dialog.
If you remove their backstory, what happens? Your labyrinthine dialogs vanish.
Does that make them worse characters?
Not really. In fact, I would argue it makes them better characters, because it allows them to shine without being caged by their pasts. BUT. You can't get to know them through dialog trees very well at all.
Think about the memorable characters in movies and books. Han Solo didn't have any backstory beyond "I need money and I have a space ship". Frodo and Sam didn't have any backstory besides "We grew up in a farming village". Even characters that did have backstory, such as Vader or Luke, didn't have giant discussions about it. Instead the backstory existed to drive the plot, not the characters.
Movies and books understand that backstories are not characterization.
These characters grow on you because of the way they interact with each other and with the world, not in describing their painful pasts. It may be that they do have a scene where they tearfully recall something, but it's not the primary means of characterization and you could even argue that their backstories are allowing them to express their character by how they deal with the past rather than actually defining their character in itself.
We don't really do this much in games, because we like dialog trees.
Dragon Age's chitchat method was really good. We got to see all the characters defining themselves relative to each other, often in very delicately constructed ways - like the way Alistair was gently spoiled, and how Wynne took some joy in being motherly but just as much joy in snapping the preconceptions of youth. Almost none of this had to do with backstory, except in a few situations where the backstory gave a topic of discussion and the two people could define themselves relative to it as well as each other.
And... that was beautiful. It was very good.
...
Then you talk to them and it's like EXPOSITIONEXPOSITIONEXPOSITIONloyaltyquestEXPOSITIONEXPOSITION okay, choose whether I'm your friend or your lover.
ARRRRRRRGHGHHGHHHH.
Dialog itself is not the problem. As you can see, I like dialog when it's not mistreated. The problem is that video games abuse dialog horribly, and that needs to stop.
Because of this, I recommend you make the player choose ahead of time. For example, "assign two adjectives to each party member as you meet them. These will determine how you interact with them. You can change this at any time."
One way to make this happen in an RPG is to not have a primary avatar. This used to be popular, but has fallen out of style recently. Maybe we could bring it back.
Another way to happen is to make the interactions between the other characters the primary social interactions, and interacting with the player a very secondary kind of interaction. For example, if you play a spirit or a starship or something while everyone else is an adventurer, they'll have a pretty basic but deep relationship with you while having a very nuanced relationship to each other.
Sam and Frodo, for example. Sam's character is defined more in how he relates to Frodo: his loyalty and courage shine through in all the details. He sets up camp, carries the heaviest loads, watches for danger, urges Frodo to act more safely, and so on. Some of this is reflected in dialog, but much of it is reflected through either actions or simple body language. Imagine if, in Dragon's Age, Alistair continually stared at you and would step between you and any vaguely dangerous-looking NPC as you wandered through towns, and even insist on opening shop doors and going through first?
Or even just imagine that he would push you off of traps or help you out of them.
Some of this would be difficult to pull off because of the mechanics of how the player plays the game. Usually players want to dash from point A to point B at maximum speed, and there's not a lot of room there for body language or interactions with the environment. But I'm sure a clever developer could come up with some way to do something, like how Dragon Age has chitchat that works fine even if you're dashing at full speed through very dull caves.
Anyway, this relates to some ideas I have on how to script characters - especially randomly generated ones - but I think I'll go over that some other day. I'd also like to talk about the evolution of character relationships and characters themselves - I think the paradigm we've got now is pretty crappy and overly confining. But you can sort of see where I'll go with that by thinking about how a game with no player avatar would run if the characters could get into relationships with each other.
Hm. Lots of thinking to do.
That's because the depth of the game is in the fighting. The character personalities, lifestyles, and beliefs don't evolve, but their levels, stats, equipment, and inventory does.
Think about it: in Dragon Age, you have a bunch of reasonably interesting (if very stock) characters. DA is one of the few games to really highlight intercharacter interactions. Not only do you actually have a camp where everyone hangs out and they try to sell you for-pay DLC, but while you're wandering around the characters will usually chat amongst themselves. Out of all of the RPGs you can get, this is probably the one with the most intercharacter interactions and character arcs.
However, even then it is incredibly bad at it compared to even the most poorly-run of tabletop games.
The problem is that the way we interact with characters is via interactive dialogs. This is a terrible way to do it. Firstly, because we don't have a personality, so it's hard to contrast them against us. Secondly, because the fundamental concept of a dialog tree and relationship end states is awful.
As an example, look at the characters in Dragon Age. Alistair is a templar that is secretly a high prince. Morrigan is a total jerk that is inheriting an exotic form of blood magic while living in a forest. Wynne is an elderly mage that has been secretly resurrected by a spirit that isn't supposed to exist.
Dialog is really the only way to get to know these characters, and the dialog engine is a branching tree. So when you talk to these characters, you slowly learn their stories bit by bit as the game progresses. However, the backstories are literally just grist for the dialog wheel. Since you can only get to know them through dialog, you need to have scads and scads of dialog.
If you remove their backstory, what happens? Your labyrinthine dialogs vanish.
Does that make them worse characters?
Not really. In fact, I would argue it makes them better characters, because it allows them to shine without being caged by their pasts. BUT. You can't get to know them through dialog trees very well at all.
Think about the memorable characters in movies and books. Han Solo didn't have any backstory beyond "I need money and I have a space ship". Frodo and Sam didn't have any backstory besides "We grew up in a farming village". Even characters that did have backstory, such as Vader or Luke, didn't have giant discussions about it. Instead the backstory existed to drive the plot, not the characters.
Movies and books understand that backstories are not characterization.
These characters grow on you because of the way they interact with each other and with the world, not in describing their painful pasts. It may be that they do have a scene where they tearfully recall something, but it's not the primary means of characterization and you could even argue that their backstories are allowing them to express their character by how they deal with the past rather than actually defining their character in itself.
We don't really do this much in games, because we like dialog trees.
Dragon Age's chitchat method was really good. We got to see all the characters defining themselves relative to each other, often in very delicately constructed ways - like the way Alistair was gently spoiled, and how Wynne took some joy in being motherly but just as much joy in snapping the preconceptions of youth. Almost none of this had to do with backstory, except in a few situations where the backstory gave a topic of discussion and the two people could define themselves relative to it as well as each other.
And... that was beautiful. It was very good.
...
Then you talk to them and it's like EXPOSITIONEXPOSITIONEXPOSITIONloyaltyquestEXPOSITIONEXPOSITION okay, choose whether I'm your friend or your lover.
ARRRRRRRGHGHHGHHHH.
Dialog itself is not the problem. As you can see, I like dialog when it's not mistreated. The problem is that video games abuse dialog horribly, and that needs to stop.
1) Dialog is not monologue.
Nearly every time you talk with a party member in an RPG, it's not a dialog. It's them talking while you either nod or shake your head. While you can certainly pound home the other person's most basic personality traits by what they are willing to say, they don't have any opportunity for give and take, no opportunity to define themself in relation to your personality except in the most primitive ways.2) Dialog is not interactive.
If the player gets to choose how to respond during a social conversation, you've made a mistake. There are no meaningful choices to be had there. Even in real life, we rarely pause to decide how to respond to a social interaction, because we already have a good feel for the sort of tone and subject matter this relationship is comfortable with. The only pauses we really see are when we're totally blindsided or when we're trying to come up with something new to say. And those can be considered actions, rather than lines of dialog.Because of this, I recommend you make the player choose ahead of time. For example, "assign two adjectives to each party member as you meet them. These will determine how you interact with them. You can change this at any time."
3) Interaction should not be centralized.
Perhaps the most core problem is that everyone is interacting with you, and you alone. Even if you did have a personality, it would be quite a limited spectrum of contrasts. Dragon Age's strength comes from the interactions of their characters with each other. This allows you to use a much greater palette and get a much more nuanced picture of who the characters are.One way to make this happen in an RPG is to not have a primary avatar. This used to be popular, but has fallen out of style recently. Maybe we could bring it back.
Another way to happen is to make the interactions between the other characters the primary social interactions, and interacting with the player a very secondary kind of interaction. For example, if you play a spirit or a starship or something while everyone else is an adventurer, they'll have a pretty basic but deep relationship with you while having a very nuanced relationship to each other.
4) Interaction should not be dialog.
Who needs dialog? Well, okay, dialog is not a bad way to have characters define themselves, but it's vastly over-rated.Sam and Frodo, for example. Sam's character is defined more in how he relates to Frodo: his loyalty and courage shine through in all the details. He sets up camp, carries the heaviest loads, watches for danger, urges Frodo to act more safely, and so on. Some of this is reflected in dialog, but much of it is reflected through either actions or simple body language. Imagine if, in Dragon's Age, Alistair continually stared at you and would step between you and any vaguely dangerous-looking NPC as you wandered through towns, and even insist on opening shop doors and going through first?
Or even just imagine that he would push you off of traps or help you out of them.
Some of this would be difficult to pull off because of the mechanics of how the player plays the game. Usually players want to dash from point A to point B at maximum speed, and there's not a lot of room there for body language or interactions with the environment. But I'm sure a clever developer could come up with some way to do something, like how Dragon Age has chitchat that works fine even if you're dashing at full speed through very dull caves.
Anyway, this relates to some ideas I have on how to script characters - especially randomly generated ones - but I think I'll go over that some other day. I'd also like to talk about the evolution of character relationships and characters themselves - I think the paradigm we've got now is pretty crappy and overly confining. But you can sort of see where I'll go with that by thinking about how a game with no player avatar would run if the characters could get into relationships with each other.
Hm. Lots of thinking to do.
Monday, March 31, 2014
Semiautomatic NPCs
In which I write a very long essay as if I know what I'm talking about.
We've gotten to the point where creating random NPCs is pretty easy. In turn, a lot of games have started to use random NPCs as primary NPCs or even player avatars, rather than just filler characters. However, when brought into the limelight these characters tend to fade a bit, so lets talk about some facets of creating and using NPCs.
The first things to consider is the role the NPC is intended to play. Originally, random NPCs were simply intended to give the world a bit more color and liveliness - not every enemy you shoot has the same face, for example. However, we've started seeing a lot of other roles.
Random NPCs in tactical RPGs are very common as party members, in which case the NPCs play the role of a bundle of stats and algorithmic growth. Unfortunately, scripted NPCs have a lot of extra oomph here, as they have personalities, character arcs, unique looks and abilities, and often unique relationships with other characters. In games like Final Fantasy Tactics, most players prefer to use scripted NPCs instead of random NPCs, and there is a certain amount of annoyance at the inarguably more complex and interesting character you get later on forcing you to kick a staple random NPC off your front line. Random NPCs can have personalities and relationships, but usually they are only in the player's head and pale in comparison to a scripted NPC with actual in-game storyline.
If you want random NPCs to fill that role well, then you need to include the hooks for the social half of these RPGs - the parts where we learn to care about the characters.
We're not talking about a powerful social AI or anything, just some basic hooks.
In practice, this is an absolutely awful idea if you want to care about the NPCs at all. A better option is to dramatically throttle access to NPCs. If the player ever has more than six or seven active NPCs, they are going to lose track. So regardless of what sort of game you're programming, if the NPCs need to matter then you'll need to make sure only a few of them matter.
The best way to do this is to have certain exceptional visual traits. You can have hundreds and hundreds of variable NPCs just floating around the cities or whatever, but it's the ones with exceptional traits that stand out and lure the player into including them onto the player team. While there can be a rich variety of them available, the player shouldn't actually be able to accept very many of them: every character counts.
It's not just a matter of losing track of who is who, but also a matter of the social dynamics that arise. In groups of 4-7, you can create compelling group interactions pretty easily. Lower than that and you need to make the interactions super nuanced, higher than that the individual interactions start to blur together into mush.
Of course, that many characters is rather low for any decent-length game, so you would probably use mechanisms to introduce churn. Plots that pull characters away, settling characters into specific towns for bonuses, characters getting thrown in jail, characters retiring... but don't flood the player with characters. You don't need nearly as many characters as most designers think - just a few!
But that kind of complexity is actually very pedestrian. It's useful - if you can do it you should - but to show it to the player is a huge mistake. For things like the exact percentage of red in their eye color, you obviously wouldn't go showing that to the player during gameplay... but, on the other hand, you do show them the exact strength rating, exact level, exact inventory...
This is stuff is obviously going to come up in the course of play, but it is just a distraction when initially scoping out a new NPC. That stuff has value only when the player has a grip on it - IE, only when the player is actively upgrading the character - IE only after the character has joined the player's team.
For things like stats, I think the best option is to randomize very chunkily. A new NPC doesn't have "strength 68", their stats are all represented in a multiple of 25 or 50, so the player can quickly understand their basic category and not worry so much about the precise number.
For things like techniques or spells, the same general idea applies. It was always annoying in Dragon's Dogma to try and find a healer pawn, because you have to read through all these techniques that the mage just happens to know looking for that one. Obviously those NPCs were not random, but if they had been it would have been smart to have a "healer" category. Any random NPC with that mage subtrait would have all the healing spells up to their level, even if a party member would normally have to buy them individually.
Their inventory also needs to be simpler to understand. I've been sticking to fantasy RPGs, and in those games the individual inventories tend to be pretty slim, focusing on the party-wide inventories. If you are in a fantasy RPG, a randomly generated NPC's inventory can be very basic default stuff, because the player is expected to quickly upgrade them using party resources. This removes the inventory as a thing that needs to be considered.
But there are a lot of situations where the inventory matters a lot more, depending on the game type. This is a bit theoretical because nearly all random NPCs are in action or RPG games at the moment, but imagine something like Animal Crossing. Except, instead of a stock town, you "adopt" random NPCs into your town. Not only is their appearance random, but also their clothes, home, inventory...
This could get quite complex to examine, so again I would simplify things. By assigning categories of interests and content, you can make it clear what sort of NPC you're talking about and insure they have a solid variety of that kind of thing. A character might be "gothy". Rather than coming with a particular "goth" costume and a particular "goth" house, they have a variety of goth costumes in their closet and a randomly created house containing goth decorations. You know what you're getting when you choose the goth even if you don't know the exact contents you'll get in the end.
Personalities are also a concern, although we'll talk about them later. Basically, the issue is that if your personalities have a lot of little fiddly stats that drive them, you'll want to summarize those stats in the same way as we've talked about above.
When you are manually writing a scripted NPC, you can add a lot of long-term characterization that can really help make the character feel real. However, random NPCs can't do that, at least not without pioneering some new kind of algorithm. Instead, you have to use shtick to give the character a maximum initial impact, to try and cement them into the head of the player enough that the player will fill in all the pseudorandom garbage that happens over the course of the game with personality.
Because of that, shticks have to leave a really strong impression. I don't recommend making atomic shticks, but instead combining two or three basic categories of subshtick into one, so you can get maximum variety. Each kind of subshtick needs to have both a visual and personality element that makes the character both look and feel unique.
For example, you might stumble across a character whose shtick seems to be "pirate". However, that's not quite true: pirate is a very obvious visual, but you instantly know a lot more about the character. For example, "Pirate queen/king", "brutal pirate", "noble pirate", "ghost pirate" - fragments of shtick that get glued together. Each one creates a specific visual and expected personality, as well as having certain statistical effects.
Depending on your needs, your shticks may be a bit more reserved. If you were making a game about high school, for example, "jock" would be a subshtick... but in a fantasy RPG, that'd be a pretty weak choice.
In addition to fitting into your setting, shticks need to be high-contrast. In order to make the characters jump out of the background noise, the shticks need to have a lot of punch. Basically, the people with shticks are exemplars of your setting, representing the highest order of some setting element. If the visual impact lies within or near the range that can be achieved by random variation, it's not a shtick, it's just a high stat. And that's a really dull thing to be your characterization.
So our pirate isn't just some grungy lady with an eye patch. She's got to go "full pirate". Some statistical forcing, yes: rings around the eyes, grubby, some bling. But most of the characteristics should be nearly unique, and certainly not found in the general population. Tricorner hat, peg leg, hook hand, parrot, eyepatch, red longcoat - pick 3.
If she's a "brutal" pirate, you get the brutal elements. That certainly involves some statistical forcing - and some of it may combine. We're going to get a lady with a lot of scars and dirt. However, brutal also comes with a custom set of animations and some body and face morphs that aren't normally available, so she'll look significantly more dangerous and hungry. After all, this "brutal" means "an epitome of this world's brutality."
If she's a "ghost" pirate, she'd obviously have some undead features - perhaps being partially see-through, or having a skull for a head. "Brutal" requires some thought as to how to make it stand out as unique, but "ghost" has obvious traits that you can just plug in.
This is a bit iffy, because by "personality" I actually mean "personality expressed in-game". Just labeling someone as shy or heroic or whatever is fine, but if it never comes up in gameplay it's totally irrelevant. If you have a "shy" personality element, then you'll need a way for them to be recognizably shy during gameplay.
If your game is just endless combat and buying new weapons, you're not going to be able to use that "shy" trait because there's nothing social to be shy about. So you can't reasonably have a "shy" trait in that kind of game, and would instead stick to traits that show during fighting and leveling and buying gear, such as "bloodthirsty" or "careful".
Normally, if I want random NPCs to feel real, I rely heavily on them feeling real to each other. Personalities can be defined in contrast to the world, or to an enemy, but in most cases personalities shine most when interacting with the people nearby.
So I usually try to implement some kind of camaraderie system where the characters chatter with each other. A pool of supplies and responses can be used to make it seem convincing, such as a shy person getting flustered in response to another person's chatter. This reveals both character's personality traits.
However, this chatter is not the same as a relationship.
If you want relationships, I recommend that you allow the player to create them, since the player knows how their personal lives are developing better than you do. Other than that, the chatter is largely stateless. It just exists to express the personalities of the characters and shake up the player's internal representations a little bit to keep it from getting stale.
First, I don't think it's that important. The characters should have a fairly rich internal life in the player's head, so enforcing some kind of arc on them would be awkward. If you do that, you should choose the most basic arcs and make it really obvious which characters are going to go through which arcs.
Instead, I like to think of this as an opportunity to introduce much-needed churn and emotional plot points.
So a character doesn't necessarily have an arc, but once the party has been settled into its configuration for a while, they should randomly pull the outside world into view.
For example, after wandering with us for a while, our pirate queen character would suddenly be approached by her old crew, or find a batch of pirates in the next town, or realize there are wanted posters of her all over town and the sheriff is hunting her.
There are three keys to these plot "arcs".
1) They should be very simple and have only a few resolution states. One of those states should be that the character is retired for a fair while. This probably means they all need to be preprogrammed, at least in terms of their rough structure and progression. Many shticks can share the same set of quests.
2) They should have between one and three new, unique NPCs involved. If there's a bounty on her, it's not just that there are endless hordes of faceless bounty hunters. You also have a sheriff that is an interesting character, an interesting bounty hunter, and an interesting side character who might also have a bounty on their head, or look so much like the pirate queen that they are being attacked in turn. Obviously, these slots have to be programmed into the event ahead of time, and there would be restrictions on the sorts of shtick they could have.
3) There should be real threat to someone outside your party. It's not just that bounty hunters are after your pirate queen: there are others at risk. Every unique NPC should be at risk in some way, even if the risk is just that they will lose their job. Categories of basic NPCs can also be threatened. For example, every woman that has red hair like hers. Or other bounty targets that haven't really done much wrong. Or perhaps the sheriff has bet his job on this bounty. In the end, some people will be hurt no matter which resolution you aim for.
Churn is really important in these games, or you'll settle on one party and stay with it forever. Plot arcs introduce churn, but they are hardly the only method of doing so.
Another method is "easy plots", where you have to leave characters behind to deal with a particular situation while you move on ahead. These can be suuuuper-vague, and in general should give you the choice of two party members to leave behind, and you can choose either one or both. The rate at which this needs to happen varies - it certainly doesn't need to happen in every new dungeon. These characters can come back later, perhaps a few levels higher, after the situation has been resolved.
Another method is to make dropping characters a major mechanic, like in Valkyrie Profile. By settling characters into specific locations you can prepare for the endgame or whatever. You can even make this temporary, so the characters can return later.
Anyway, those are my extreeeeeemely long thoughts on random NPC generation.
Well, that's not true. There's actually another essay this long that I want to write on the nature of interior, exterior, and pan-character growth and challenge, but I'll spare you that.
FOR NOW.
We've gotten to the point where creating random NPCs is pretty easy. In turn, a lot of games have started to use random NPCs as primary NPCs or even player avatars, rather than just filler characters. However, when brought into the limelight these characters tend to fade a bit, so lets talk about some facets of creating and using NPCs.
The first things to consider is the role the NPC is intended to play. Originally, random NPCs were simply intended to give the world a bit more color and liveliness - not every enemy you shoot has the same face, for example. However, we've started seeing a lot of other roles.
Random NPCs in tactical RPGs are very common as party members, in which case the NPCs play the role of a bundle of stats and algorithmic growth. Unfortunately, scripted NPCs have a lot of extra oomph here, as they have personalities, character arcs, unique looks and abilities, and often unique relationships with other characters. In games like Final Fantasy Tactics, most players prefer to use scripted NPCs instead of random NPCs, and there is a certain amount of annoyance at the inarguably more complex and interesting character you get later on forcing you to kick a staple random NPC off your front line. Random NPCs can have personalities and relationships, but usually they are only in the player's head and pale in comparison to a scripted NPC with actual in-game storyline.
If you want random NPCs to fill that role well, then you need to include the hooks for the social half of these RPGs - the parts where we learn to care about the characters.
We're not talking about a powerful social AI or anything, just some basic hooks.
Reduction
First, let's think about cutting away rather than adding. A big problem with random NPCs (and massively singleplayer content generation, if you're using that instead) is that you have so many options. So there's an impulse to just throw more and more of it into the game. An unlimited number of random NPCs.In practice, this is an absolutely awful idea if you want to care about the NPCs at all. A better option is to dramatically throttle access to NPCs. If the player ever has more than six or seven active NPCs, they are going to lose track. So regardless of what sort of game you're programming, if the NPCs need to matter then you'll need to make sure only a few of them matter.
The best way to do this is to have certain exceptional visual traits. You can have hundreds and hundreds of variable NPCs just floating around the cities or whatever, but it's the ones with exceptional traits that stand out and lure the player into including them onto the player team. While there can be a rich variety of them available, the player shouldn't actually be able to accept very many of them: every character counts.
It's not just a matter of losing track of who is who, but also a matter of the social dynamics that arise. In groups of 4-7, you can create compelling group interactions pretty easily. Lower than that and you need to make the interactions super nuanced, higher than that the individual interactions start to blur together into mush.
Of course, that many characters is rather low for any decent-length game, so you would probably use mechanisms to introduce churn. Plots that pull characters away, settling characters into specific towns for bonuses, characters getting thrown in jail, characters retiring... but don't flood the player with characters. You don't need nearly as many characters as most designers think - just a few!
Reducing Complexity
A lot of random NPC generators have very organic, diverse options. For example, in an Elder Scrolls game you can randomize every little detail of their body, stats, skills, powers, inventory... All of that stuff can be tweaked very precisely.But that kind of complexity is actually very pedestrian. It's useful - if you can do it you should - but to show it to the player is a huge mistake. For things like the exact percentage of red in their eye color, you obviously wouldn't go showing that to the player during gameplay... but, on the other hand, you do show them the exact strength rating, exact level, exact inventory...
This is stuff is obviously going to come up in the course of play, but it is just a distraction when initially scoping out a new NPC. That stuff has value only when the player has a grip on it - IE, only when the player is actively upgrading the character - IE only after the character has joined the player's team.
For things like stats, I think the best option is to randomize very chunkily. A new NPC doesn't have "strength 68", their stats are all represented in a multiple of 25 or 50, so the player can quickly understand their basic category and not worry so much about the precise number.
For things like techniques or spells, the same general idea applies. It was always annoying in Dragon's Dogma to try and find a healer pawn, because you have to read through all these techniques that the mage just happens to know looking for that one. Obviously those NPCs were not random, but if they had been it would have been smart to have a "healer" category. Any random NPC with that mage subtrait would have all the healing spells up to their level, even if a party member would normally have to buy them individually.
Their inventory also needs to be simpler to understand. I've been sticking to fantasy RPGs, and in those games the individual inventories tend to be pretty slim, focusing on the party-wide inventories. If you are in a fantasy RPG, a randomly generated NPC's inventory can be very basic default stuff, because the player is expected to quickly upgrade them using party resources. This removes the inventory as a thing that needs to be considered.
But there are a lot of situations where the inventory matters a lot more, depending on the game type. This is a bit theoretical because nearly all random NPCs are in action or RPG games at the moment, but imagine something like Animal Crossing. Except, instead of a stock town, you "adopt" random NPCs into your town. Not only is their appearance random, but also their clothes, home, inventory...
This could get quite complex to examine, so again I would simplify things. By assigning categories of interests and content, you can make it clear what sort of NPC you're talking about and insure they have a solid variety of that kind of thing. A character might be "gothy". Rather than coming with a particular "goth" costume and a particular "goth" house, they have a variety of goth costumes in their closet and a randomly created house containing goth decorations. You know what you're getting when you choose the goth even if you don't know the exact contents you'll get in the end.
Personalities are also a concern, although we'll talk about them later. Basically, the issue is that if your personalities have a lot of little fiddly stats that drive them, you'll want to summarize those stats in the same way as we've talked about above.
Shtick
More important than the statistical variation of the random NPCs is their shtick. In fact, if you have to choose between adding more variation or more shtick options, always go with shtick! Even if everyone has the same face or animation, the shtick will make them feel unique.When you are manually writing a scripted NPC, you can add a lot of long-term characterization that can really help make the character feel real. However, random NPCs can't do that, at least not without pioneering some new kind of algorithm. Instead, you have to use shtick to give the character a maximum initial impact, to try and cement them into the head of the player enough that the player will fill in all the pseudorandom garbage that happens over the course of the game with personality.
Because of that, shticks have to leave a really strong impression. I don't recommend making atomic shticks, but instead combining two or three basic categories of subshtick into one, so you can get maximum variety. Each kind of subshtick needs to have both a visual and personality element that makes the character both look and feel unique.
For example, you might stumble across a character whose shtick seems to be "pirate". However, that's not quite true: pirate is a very obvious visual, but you instantly know a lot more about the character. For example, "Pirate queen/king", "brutal pirate", "noble pirate", "ghost pirate" - fragments of shtick that get glued together. Each one creates a specific visual and expected personality, as well as having certain statistical effects.
Depending on your needs, your shticks may be a bit more reserved. If you were making a game about high school, for example, "jock" would be a subshtick... but in a fantasy RPG, that'd be a pretty weak choice.
In addition to fitting into your setting, shticks need to be high-contrast. In order to make the characters jump out of the background noise, the shticks need to have a lot of punch. Basically, the people with shticks are exemplars of your setting, representing the highest order of some setting element. If the visual impact lies within or near the range that can be achieved by random variation, it's not a shtick, it's just a high stat. And that's a really dull thing to be your characterization.
So our pirate isn't just some grungy lady with an eye patch. She's got to go "full pirate". Some statistical forcing, yes: rings around the eyes, grubby, some bling. But most of the characteristics should be nearly unique, and certainly not found in the general population. Tricorner hat, peg leg, hook hand, parrot, eyepatch, red longcoat - pick 3.
If she's a "brutal" pirate, you get the brutal elements. That certainly involves some statistical forcing - and some of it may combine. We're going to get a lady with a lot of scars and dirt. However, brutal also comes with a custom set of animations and some body and face morphs that aren't normally available, so she'll look significantly more dangerous and hungry. After all, this "brutal" means "an epitome of this world's brutality."
If she's a "ghost" pirate, she'd obviously have some undead features - perhaps being partially see-through, or having a skull for a head. "Brutal" requires some thought as to how to make it stand out as unique, but "ghost" has obvious traits that you can just plug in.
Personality and Relationships
While the shtick serves to create an impression of the character in the mind of the player, it's also important to keep reinforcing that image over the course of the game. This is why you do need some concept of a personality.This is a bit iffy, because by "personality" I actually mean "personality expressed in-game". Just labeling someone as shy or heroic or whatever is fine, but if it never comes up in gameplay it's totally irrelevant. If you have a "shy" personality element, then you'll need a way for them to be recognizably shy during gameplay.
If your game is just endless combat and buying new weapons, you're not going to be able to use that "shy" trait because there's nothing social to be shy about. So you can't reasonably have a "shy" trait in that kind of game, and would instead stick to traits that show during fighting and leveling and buying gear, such as "bloodthirsty" or "careful".
Normally, if I want random NPCs to feel real, I rely heavily on them feeling real to each other. Personalities can be defined in contrast to the world, or to an enemy, but in most cases personalities shine most when interacting with the people nearby.
So I usually try to implement some kind of camaraderie system where the characters chatter with each other. A pool of supplies and responses can be used to make it seem convincing, such as a shy person getting flustered in response to another person's chatter. This reveals both character's personality traits.
However, this chatter is not the same as a relationship.
If you want relationships, I recommend that you allow the player to create them, since the player knows how their personal lives are developing better than you do. Other than that, the chatter is largely stateless. It just exists to express the personalities of the characters and shake up the player's internal representations a little bit to keep it from getting stale.
Plot Arcs And Churn
Probably the biggest concern for a lot of people is the idea of a plot or character arc. Written NPCs grow and change over the course of a game! Random ones really don't.First, I don't think it's that important. The characters should have a fairly rich internal life in the player's head, so enforcing some kind of arc on them would be awkward. If you do that, you should choose the most basic arcs and make it really obvious which characters are going to go through which arcs.
Instead, I like to think of this as an opportunity to introduce much-needed churn and emotional plot points.
So a character doesn't necessarily have an arc, but once the party has been settled into its configuration for a while, they should randomly pull the outside world into view.
For example, after wandering with us for a while, our pirate queen character would suddenly be approached by her old crew, or find a batch of pirates in the next town, or realize there are wanted posters of her all over town and the sheriff is hunting her.
There are three keys to these plot "arcs".
1) They should be very simple and have only a few resolution states. One of those states should be that the character is retired for a fair while. This probably means they all need to be preprogrammed, at least in terms of their rough structure and progression. Many shticks can share the same set of quests.
2) They should have between one and three new, unique NPCs involved. If there's a bounty on her, it's not just that there are endless hordes of faceless bounty hunters. You also have a sheriff that is an interesting character, an interesting bounty hunter, and an interesting side character who might also have a bounty on their head, or look so much like the pirate queen that they are being attacked in turn. Obviously, these slots have to be programmed into the event ahead of time, and there would be restrictions on the sorts of shtick they could have.
3) There should be real threat to someone outside your party. It's not just that bounty hunters are after your pirate queen: there are others at risk. Every unique NPC should be at risk in some way, even if the risk is just that they will lose their job. Categories of basic NPCs can also be threatened. For example, every woman that has red hair like hers. Or other bounty targets that haven't really done much wrong. Or perhaps the sheriff has bet his job on this bounty. In the end, some people will be hurt no matter which resolution you aim for.
Churn is really important in these games, or you'll settle on one party and stay with it forever. Plot arcs introduce churn, but they are hardly the only method of doing so.
Another method is "easy plots", where you have to leave characters behind to deal with a particular situation while you move on ahead. These can be suuuuper-vague, and in general should give you the choice of two party members to leave behind, and you can choose either one or both. The rate at which this needs to happen varies - it certainly doesn't need to happen in every new dungeon. These characters can come back later, perhaps a few levels higher, after the situation has been resolved.
Another method is to make dropping characters a major mechanic, like in Valkyrie Profile. By settling characters into specific locations you can prepare for the endgame or whatever. You can even make this temporary, so the characters can return later.
Anyway, those are my extreeeeeemely long thoughts on random NPC generation.
Well, that's not true. There's actually another essay this long that I want to write on the nature of interior, exterior, and pan-character growth and challenge, but I'll spare you that.
FOR NOW.
Thursday, March 20, 2014
Constraining Construction For Improved Construction
In the last post, I mentioned the possibility of turning the act of building something in a construction game into gameplay. Normally, building something is just a choice you make: the gameplay is how what you've built works, whether you can afford it, whether it fits - the actual construction is just click and maybe wait a bit.
But turning the act of construction itself into gameplay may make for a more interesting game, and result in more interesting constraints and results.
There are three aspects to this. Let's give a quick demo of each.
The first is the the idea of constraining the physical act of constructing. For example, in Minecraft you have to be within a few meters to mine or place a block, which makes it difficult to build large things or things in awkward locations. However, this doesn't mean players don't build large or awkward things: in fact, that's what they love to build most. It's a great test of skill, and very popular.
Contrarily, modders that use construction aides can build at any size pretty easily. Their challenge is in how dense, realistic, and interesting they can make their constructs. So that's what they focus on. Obviously, they also build very large things, but they don't typically challenge themselves to just build something as big as possible, because that has very little meaning once the in-game construction constraint goes away.
The second aspect is constraining the resources or space available to construct with. In Kerbal, this is the launch constraint: if you can't launch it, you can't use it. So whatever you build has to resist launch forces, and is therefore constrained. Building larger, less launch-friendly ships or ships that combine in orbit is a fun challenge a lot of people get into.
In Minecraft the situation is often reversed. In survival mode, if you are hunting diamonds, you'll build up a massive stockpile of lesser ores like iron. The sudden over-availability of this ore means you'll often get the urge to embark on significant construction projects and, say, build a house out of iron. Dirt and stone are so common that they actually surpass that and become gauche, worth less than the time it takes to place them. It's a balancing act.
Starbound uses a pixel furnace that turns ores into cash. This really helps when crafting things, since crafting requires a lot of cash. But it's detrimental to constructing things, because construction requires resources. If Starbound wanted to be more construction-focused, it would let the player drown in a glut of low-grade metals and thereby make them want to construct things with them - not necessarily out of iron blocks, but out of iron-derived elements such as iron beds or doors.
Either way, it's not just materials, but also topology. For example, if you build a house in Minecraft you may find that when you go to wire it, the size of your wiring basically destroys the house you built. Similarly, building a rocket in Kerbal sometimes runs you up against the maximum hanger size, or you find you can't do something because it'd put an object inside another object. Maia and other base-building games often have specific places you can build specific things.
The third aspect is how extensible the construction is. Basically, anything which allows players to make things they put in the game world do stuff later, relate to things strangely, or be important in a unique way.
Extending the function of your constructs is a huge part of personalizing them. Whether this is a redstone circuit or a book you can write in, Minecraft allows you to extend your construction a lot. Some of this might be in construction phase, such as redstone and pistons needing to be constructed the same way as doors and walls. Other times, it might be in an alternate mode, such as typing into a book.
The programming may be passive (adding setting details such as text in a book), automatic (sensors wired to a logic system), or manual (switches that need to be manually flipped). Of course, these things can all combine, and you can do something like display text (passive) with a series of logic gates (automatic) wired to a button (manual).
On the other hand, it can be quite simple.
To show how simple this can get, Kerbal's docking system is an extensibility mechanic. It's super simple to set up, but it can be used in a wide variety of ways. It doesn't involve any upfront programming, but it allows for very complex interactions and operations during the mission via manual activation.
Extensibility is addictive, and once you give a little bit, people want more. This is why so many of the early functional mods for Kerbal were docking-related - docking assists, hardpoint locks for docked ships, short-range fuel-beaming without docking, modular magnetic docks for base construction...
Later on, the extensibility was extended to things like cargo, power and data relays, life support requirements, fuel and materials manufacturing... all of these are individually very simple elements that require basically no upfront "programming" - you just stick them on your ship. However, it requires you to use that ship properly in complex and varied missions.
Similarly, many of the "extended" spaces in Minecraft are levels generated for people to play through. The vast engine of redstone machinery orchestrates a complicated story where players explore a space, solve puzzles, and face challenges. Well, this kind of programming requires a whole lot more care and effort in the construction phase, but the idea is the same: you give players the ability to make their construction mean more, and they'll run with it.
It allows for very high-level self-expression.
This essay was mostly for myself, since I'm thinking about how to use these methods to give a strong feel to my base-repair game prototype. Haven't got it sorted yet.
But turning the act of construction itself into gameplay may make for a more interesting game, and result in more interesting constraints and results.
There are three aspects to this. Let's give a quick demo of each.
The first is the the idea of constraining the physical act of constructing. For example, in Minecraft you have to be within a few meters to mine or place a block, which makes it difficult to build large things or things in awkward locations. However, this doesn't mean players don't build large or awkward things: in fact, that's what they love to build most. It's a great test of skill, and very popular.
Contrarily, modders that use construction aides can build at any size pretty easily. Their challenge is in how dense, realistic, and interesting they can make their constructs. So that's what they focus on. Obviously, they also build very large things, but they don't typically challenge themselves to just build something as big as possible, because that has very little meaning once the in-game construction constraint goes away.
The second aspect is constraining the resources or space available to construct with. In Kerbal, this is the launch constraint: if you can't launch it, you can't use it. So whatever you build has to resist launch forces, and is therefore constrained. Building larger, less launch-friendly ships or ships that combine in orbit is a fun challenge a lot of people get into.
In Minecraft the situation is often reversed. In survival mode, if you are hunting diamonds, you'll build up a massive stockpile of lesser ores like iron. The sudden over-availability of this ore means you'll often get the urge to embark on significant construction projects and, say, build a house out of iron. Dirt and stone are so common that they actually surpass that and become gauche, worth less than the time it takes to place them. It's a balancing act.
Starbound uses a pixel furnace that turns ores into cash. This really helps when crafting things, since crafting requires a lot of cash. But it's detrimental to constructing things, because construction requires resources. If Starbound wanted to be more construction-focused, it would let the player drown in a glut of low-grade metals and thereby make them want to construct things with them - not necessarily out of iron blocks, but out of iron-derived elements such as iron beds or doors.
Either way, it's not just materials, but also topology. For example, if you build a house in Minecraft you may find that when you go to wire it, the size of your wiring basically destroys the house you built. Similarly, building a rocket in Kerbal sometimes runs you up against the maximum hanger size, or you find you can't do something because it'd put an object inside another object. Maia and other base-building games often have specific places you can build specific things.
The third aspect is how extensible the construction is. Basically, anything which allows players to make things they put in the game world do stuff later, relate to things strangely, or be important in a unique way.
Extending the function of your constructs is a huge part of personalizing them. Whether this is a redstone circuit or a book you can write in, Minecraft allows you to extend your construction a lot. Some of this might be in construction phase, such as redstone and pistons needing to be constructed the same way as doors and walls. Other times, it might be in an alternate mode, such as typing into a book.
The programming may be passive (adding setting details such as text in a book), automatic (sensors wired to a logic system), or manual (switches that need to be manually flipped). Of course, these things can all combine, and you can do something like display text (passive) with a series of logic gates (automatic) wired to a button (manual).
On the other hand, it can be quite simple.
To show how simple this can get, Kerbal's docking system is an extensibility mechanic. It's super simple to set up, but it can be used in a wide variety of ways. It doesn't involve any upfront programming, but it allows for very complex interactions and operations during the mission via manual activation.
Extensibility is addictive, and once you give a little bit, people want more. This is why so many of the early functional mods for Kerbal were docking-related - docking assists, hardpoint locks for docked ships, short-range fuel-beaming without docking, modular magnetic docks for base construction...
Later on, the extensibility was extended to things like cargo, power and data relays, life support requirements, fuel and materials manufacturing... all of these are individually very simple elements that require basically no upfront "programming" - you just stick them on your ship. However, it requires you to use that ship properly in complex and varied missions.
Similarly, many of the "extended" spaces in Minecraft are levels generated for people to play through. The vast engine of redstone machinery orchestrates a complicated story where players explore a space, solve puzzles, and face challenges. Well, this kind of programming requires a whole lot more care and effort in the construction phase, but the idea is the same: you give players the ability to make their construction mean more, and they'll run with it.
It allows for very high-level self-expression.
This essay was mostly for myself, since I'm thinking about how to use these methods to give a strong feel to my base-repair game prototype. Haven't got it sorted yet.
Subscribe to:
Posts (Atom)