I find a lot of writers fall into a trap: trying to write a story with the wrong ingredients.
No matter what story you want to write, you need the foundation of having the right amounts of the right things. The more of something there is, the less unique and distinct it is.
If there's loads of swords in your story, then a sword is not unique or distinct.
If there's only one sword, a lot of your story will be about why there's only one.
By carefully deciding how many swords to put your story, you get just the right amount of swordiness in your story.
Pretty basic, right?
One
One sword, and a lot of the story is about that one sword. Whether it's because that's the Sword of Light that no weapon can match, or whether it's because only one character in your office comedy show carries a sword.
While that one thing will always be distinct, you can make it more important by defining related things as blandly "not that". Or you can play it down by having a lot of variation.
For example, if your story is about twelve nearly-identical adventurers and a shlubby dude, the story is about the shlub. On the other hand, if your story is about thirteen people, only one of which works in a coffee shop... well, presumably, the others work in other places and the coffee shop employment will be distinct but not a major driving force.
This is also an easy one to accidentally trip over.
If your story features six white guys and a black lady... that one lady is going to stand out far more aggressively and distinctly, even if you didn't intend her to.
An example of this would be Bulk and Skull in Power Rangers. They're usually considered as "one unit", and they're really the only non-superpowered unit in the series. Because of this, they draw a lot of attention - people often feel more strongly about those two than about any individual rangers. As a plus, they can be split apart when needed and used as...
Two
If there's two swords, the story will be about how those two swords get along. A sword of fire and a sword of ice: who has them, how do they shape the world, what happens when they fight? You can see Lodoss Wars for an example of that.
Having exactly two of something draws attention to it. It can't be played down as much as if there's only one, or if there's a lot. Two is a really loud number.
Whether it's two swords that fight, or two amulets belonging to twin dragons, or two short people in a land of tall people, or two countries on the continent, or two species in your fantasy setting - it's all about how those two connect, and the differences in how they affect the world around them.
A lot of people write dualities like this into their stories without realizing how important it can become.
For example, you might set up a hero and a rival as being the only two people with a specific ability. If you then resolve their conflicts and have them move into the third act together, it's going to feel strangely flat and cheap... because their tension was far more powerful than whatever random baddie you're having them team up against. Makes more sense for the rival to take over as the big bad.
Some
If there's "some" swords, then the swords usually map to a specific category of character, and represent that character. They separate that kind of character from other kinds of characters, and become projections of that character's desires.
The easy example of that is Star Wars, where each space wizard has their own sword. It sets them apart from non space wizards, and the swords are usually considered to be extensions of the space wizard. If someone uses a sword that's not theirs, it won't work right unless they are "accepted", and if you find an abandoned sword, it probably still echoes with the space wizard that made it.
This may sound very spiritual, but it's an extremely handy way to extend your characters into your story space. Space wizards can have an outsized effect on the story because they are able to extend themselves into the story with their magic swords. The swords reflect and project who they are and what they want.
A non-swordy example might be superpowers in a comic book, or adventurer licenses in a fantasy manga. For less combat-centric things, it might be jobs in an office comedy.
When setting this up, it's important to choose a thing that extends the characters in a way your story needs. If space wizards had magic wands instead of swords, the story would feel more ephemeral and distant... but swords are immediate and primal, suiting the melodramatic conflicts of Star Wars. Similarly, in an office comedy, having distinct job roles extends the characters into the office space in a suitable way. If they had swords... well, it'd be funny, but it'd be a very strange office comedy.
"Some" may also be used to define a unified group, but in this case it's really just "one". For example, there are "some" ring wraiths, but in story terms there is "one" group of ring wraiths, and a lot of the story is spent on exactly how and why they exist. There are "some" Borg, but it's really just one group, etc, etc.
Lots
When there's lots of swords, they stop being unique and start being a functional prop. Their existence is important to the story, but individual swords are not terribly interesting and the things they do are often glossed over and taken for granted. They are often used as a framing device or narrative engine, rather than being used as swords.
For example, if absolutely everyone has swords, that says a lot about the kind of world they live in... but individual swordfights are likely to be glossed over and summarized. A Game of Thrones and The Hobbit show that.
If you want the swords to be more important, you have to come up with more important swords. So these are magical swords. Oh, too many magic swords? This one is a super-duper magic sword...
This isn't necessarily bad writing, but it's essentially separating the thing into "a lot" of ordinary swords and "some" special swords. This is why Bilbo's sword Sting can be easily thought of as an extension of Bilbo: short but sharp and shines when things get dangerous. There are "a lot" of ordinary swords and then "some" swords that are extensions of specific characters.
Again, swords are just an example. Another example might be monsters in Power Rangers, or species in Star Wars. They push the plot along and frame the story, but they are only distinct or unique as required to do that.
Summary
This is a very basic, easy, and primitive way to consider what ingredients you're adding to your story world.
Regardless of the type of story you want to write, if your ingredient proportions are wrong, you'll end up struggling to write what you wanted to write.
This is especially important when you're not writing the story.
If you're designing a world for a tabletop game, or for an extended series of stories, you need to arrange the ingredients to support the kinds of stories you want to exist!
At least, that's my take. Let me know what you think.
Tuesday, October 01, 2019
Monday, September 16, 2019
Writing CRPG Characters
I've come to have very strong opinions about how characters should be written in CRPGs.
Here's the rule: the character needs to engage with the player.
This is a funny thing about a CRPG. The game can have terrible writing and unbelievably poorly written characters... as long as the characters properly engage with the player. Similarly, even if you have wonderfully written characters voice acted by legends, if they don't properly engage with the player, they're background noise.
So here's the exercise:
Don't write a backstory. None of your characters have any backstory.
Now your writing will radically improve.
----
In order for a character to feel real, they have to exist in the same time and place as the player character. They have to talk to the player character. Negotiate, exchange ideas, come to a shared understanding of the world they exist in and their places within it. Their relationship has to evolve.
Backstories are poison to this, because a backstory exists in another time and place. Dripping a backstory into the player's ears as they earn relationship points doesn't establish a shared reality, doesn't involve negotiation or an exchange of ideas, doesn't improve the character's understanding of anything, and rather than evolve the relationship, it happens after the relationship evolved!
Some games try to bring the backstory into the present. This is possible, but it's more likely that you'll screw it up.
The basic rule is that you should never close loose ends without opening at least as many.
Most character backstories come into the present to close off loose ends - essentially ending the backstory and closing out the character. I have no idea why this is common, but it's just the worst approach.
Since I've been playing Pathfinder: Kingmaker, let me give some examples.
(Keep in mind that this game is written abominably.)
There's a warrior you'll use as your primary tank. I think every player uses her. Her backstory is that she's just so gosh-darn pretty that she was adopted by the religious order of beauty. She got angry with everyone telling her she was pretty, and quit.
Seriously.
Her "loyalty mission" is a character from her backstory showing up, fighting her, and scarring her face. The end. She's apparently no longer pretty and apparently the church no longer cares about her. All the loose ends are tied up and her character is now in limbo. No more interests, no more goals, no more looming threats, no more opinions.
There's another character that's undead. Her loyalty mission involves figuring out who killed her and, again, tying all the loose threads up so she has no more plot.
There's a character that's a ranger. His loyalty mission? Murdering innocent trolls because a troll killed his family. Again, it's tying the loose ends and closing the story of his life.
There is one character that qualifies, that passes the "loose threads" test. That would be the dumbass barbarian poseur.
Her backstory is that she ran away from her tribe because they didn't respect her. Her loyalty mission? Earning your respect and her self-respect at the same time by hunting a monster and taking the lead against it.
That's how you do it.
You and her are in the same time and place, discussing something happening in this time and place. It's not a monster from her past, it's just some random monster-of-the-week threatening your kingdom.
You and her are negotiating and exchanging ideas, finding a good balance between her heritage, her need to prove herself, her desire to belong, and the very blunt threat of a giant monster.
She grows as a person, having proven herself to herself. She's a little less of a poseur, and has found a place that accepts her.
You and she have an evolving relationship: you're no longer just 'a baron of some land I happen to be on', but her adopted tribe leader. A more fun and unusual relationship than the normal "strangers->friends->lovers" route!
I won't say her character is good or interesting. It's written with all the subtlety of a freight train... falling on another freight train...
But the structure of her character beats is solid, and therefore her character seems to exist and be a part of my story. She didn't close any loose threads off, she just joined my story as a living, growing person.
Could you adapt the other character beats the same way?
Sure. If the fighter's beauty is so great, let her lure in an ever-increasing volume of ever-richer and ever-more-aggressive suitors. Eventually it gets out of hand, and you have to choose: do the two of you get married in name only just to keep the suitors off, or does she carve a scar into her own face to stop them from coming?
It's not great writing, because the premise is dumb, but it's a situation that exists in the present and evolves your relationship to each other.
---
If we look at other characters from other games, we can see the same basic premise.
Did you, like everyone, like Garrus? Well, guess what? He's the one that followed these rules. His character beats were always about something happening right now, he grew as a character, you negotiated and exchanged views with him, and your relationship steadily evolved.
Did you like Aeris? Well, guess what? She followed these rules.
Did you like Celes? Well, guess what? She followed these rules.
Even characters like Solas, weighed down by a ponderous backstory, are popular not because of their backstory, but because of how they bring their backstory into the present. How their backstory creates more problems, more loose threads... rather than resolving any.
I think there may even be some compelling characters whose names don't end with S. Try to find some, and see whether they follow these rules. I think they will.
So, my take:
1) Character beats should take place here and now, about things that matter here and now.
2) Character beats should involve debating, exchanging ideas or opinions, not just listening.
3) Character beats should evolve the character. Remember that weakness is strength, and that their place in the world is changing.
4) Character beats should evolve your PC's relationship with the character.
If you follow these guidelines, even if you write terribly, you'll at least have a compelling character!
At least, I think so. Let me know what you think.
Here's the rule: the character needs to engage with the player.
This is a funny thing about a CRPG. The game can have terrible writing and unbelievably poorly written characters... as long as the characters properly engage with the player. Similarly, even if you have wonderfully written characters voice acted by legends, if they don't properly engage with the player, they're background noise.
So here's the exercise:
Don't write a backstory. None of your characters have any backstory.
Now your writing will radically improve.
----
In order for a character to feel real, they have to exist in the same time and place as the player character. They have to talk to the player character. Negotiate, exchange ideas, come to a shared understanding of the world they exist in and their places within it. Their relationship has to evolve.
Backstories are poison to this, because a backstory exists in another time and place. Dripping a backstory into the player's ears as they earn relationship points doesn't establish a shared reality, doesn't involve negotiation or an exchange of ideas, doesn't improve the character's understanding of anything, and rather than evolve the relationship, it happens after the relationship evolved!
Some games try to bring the backstory into the present. This is possible, but it's more likely that you'll screw it up.
The basic rule is that you should never close loose ends without opening at least as many.
Most character backstories come into the present to close off loose ends - essentially ending the backstory and closing out the character. I have no idea why this is common, but it's just the worst approach.
Since I've been playing Pathfinder: Kingmaker, let me give some examples.
(Keep in mind that this game is written abominably.)
There's a warrior you'll use as your primary tank. I think every player uses her. Her backstory is that she's just so gosh-darn pretty that she was adopted by the religious order of beauty. She got angry with everyone telling her she was pretty, and quit.
Seriously.
Her "loyalty mission" is a character from her backstory showing up, fighting her, and scarring her face. The end. She's apparently no longer pretty and apparently the church no longer cares about her. All the loose ends are tied up and her character is now in limbo. No more interests, no more goals, no more looming threats, no more opinions.
There's another character that's undead. Her loyalty mission involves figuring out who killed her and, again, tying all the loose threads up so she has no more plot.
There's a character that's a ranger. His loyalty mission? Murdering innocent trolls because a troll killed his family. Again, it's tying the loose ends and closing the story of his life.
There is one character that qualifies, that passes the "loose threads" test. That would be the dumbass barbarian poseur.
Her backstory is that she ran away from her tribe because they didn't respect her. Her loyalty mission? Earning your respect and her self-respect at the same time by hunting a monster and taking the lead against it.
That's how you do it.
You and her are in the same time and place, discussing something happening in this time and place. It's not a monster from her past, it's just some random monster-of-the-week threatening your kingdom.
You and her are negotiating and exchanging ideas, finding a good balance between her heritage, her need to prove herself, her desire to belong, and the very blunt threat of a giant monster.
She grows as a person, having proven herself to herself. She's a little less of a poseur, and has found a place that accepts her.
You and she have an evolving relationship: you're no longer just 'a baron of some land I happen to be on', but her adopted tribe leader. A more fun and unusual relationship than the normal "strangers->friends->lovers" route!
I won't say her character is good or interesting. It's written with all the subtlety of a freight train... falling on another freight train...
But the structure of her character beats is solid, and therefore her character seems to exist and be a part of my story. She didn't close any loose threads off, she just joined my story as a living, growing person.
Could you adapt the other character beats the same way?
Sure. If the fighter's beauty is so great, let her lure in an ever-increasing volume of ever-richer and ever-more-aggressive suitors. Eventually it gets out of hand, and you have to choose: do the two of you get married in name only just to keep the suitors off, or does she carve a scar into her own face to stop them from coming?
It's not great writing, because the premise is dumb, but it's a situation that exists in the present and evolves your relationship to each other.
---
If we look at other characters from other games, we can see the same basic premise.
Did you, like everyone, like Garrus? Well, guess what? He's the one that followed these rules. His character beats were always about something happening right now, he grew as a character, you negotiated and exchanged views with him, and your relationship steadily evolved.
Did you like Aeris? Well, guess what? She followed these rules.
Did you like Celes? Well, guess what? She followed these rules.
Even characters like Solas, weighed down by a ponderous backstory, are popular not because of their backstory, but because of how they bring their backstory into the present. How their backstory creates more problems, more loose threads... rather than resolving any.
I think there may even be some compelling characters whose names don't end with S. Try to find some, and see whether they follow these rules. I think they will.
So, my take:
1) Character beats should take place here and now, about things that matter here and now.
2) Character beats should involve debating, exchanging ideas or opinions, not just listening.
3) Character beats should evolve the character. Remember that weakness is strength, and that their place in the world is changing.
4) Character beats should evolve your PC's relationship with the character.
If you follow these guidelines, even if you write terribly, you'll at least have a compelling character!
At least, I think so. Let me know what you think.
Tuesday, August 13, 2019
Topological Construction Play With Scenarios
I love building things in games. Whether it's cities, planets, space ships, or nanomachines, I just love putting things together and letting them do their work.
But this kind of play requires careful construction. A lot of games rely on a "spreadsheet" approach, where the modules just add to numbers on a spreadsheet. This is almost universal on mobile, and is sadly common in indie games on every platform.
You want to build a city? Add a fishery for +5 food! A space ship? Add an arc reactor for +5 energy!
The problem is that spreadsheet play is fundamentally passive. The thing I'm building doesn't do anything, it just drifts along as a pile of numbers.
The things that bring a construction to life are the challenges it faces.
If I build a city, how does it fare in winter? If I build a castle, how does it fare against siege? If I build a starship, how does it fare during re-entry?
It's possible to push a spreadsheet to respond to challenges, but I prefer having more direct control.
I prefer topological construction. That is, where I put things matters.
The details of this matter. How do you make placing things relative to other things matter?
Well, there's three pieces: the mechanic, the load, and the scenario modules.
The mechanic is how you make the location matter. The key to the mechanic is that is has to be a local effect with consequences. It shouldn't be pass-fail: the whole point is to create a soft, widely interlocking mechanic that the player can adjust in a lot of ways.
For example, in SimCity, the main mechanic is traffic. Traffic produces pollution, and if you fall short, it also produces economic slowdown, unhappiness, and road failure (in that overtaxing a road results in a traffic jam).
In a space ship game, the mechanic might be power. Power transfer produces lot of heat and nearby elements may degrade, and the laser will fire slowly and weakly if you fall short... Or perhaps the mechanic could be damage, coming in from an outside vector, needing to be blocked and dispersed...
In a boat or plane game, the mechanic might be water or airflow - how it exerts pressure at various speeds.
As you can see, not all mechanics are internal-only. Many of them are about how your system interacts with the wider world. And, of course, most construction games have many mechanics, some larger, some smaller: SimCity has traffic as a mechanic, but also pollution, economics, happiness, weather, water...
The load is how the mechanic expresses itself in local space, and what modules the player can use to handle that.
For example, SimCity has roads for cars... and also road/car variants like subways, buses, etc. The player is given freedom to optimize: put in a subway from the residential district to the commercial district, and most of that kind of traffic will go through there instead of through the more limited surface roads, freeing those up for shipping...
In a space ship game, it might be power cables, capacitors, etc. Or, if damage is the mechanic, it might be armor, magnetic screens, shock absorbers, air gaps, shield projectors... the idea is to make it something local, so shipwide shield generators do not count.
In a boat or plane game, it'd obviously be the hull itself, both hull plates and elements that happen to be exposed.
Scenario modules are elements you install specifically to create or respond to scenarios. Sometimes these are not specifically spawned by devices inside the creation, but even then the creation will be arranged to respond to a specific scenario and you must allow that scenario to be fired.
In SimCity, houses and office buildings create an interlocked scenario where traffic goes from one to the other, then the reverse. In exchange, you get money. There are constraints to prevent you from crowding houses and offices together (noise pollution, etc) so you're forced to connect them via long traffic routes.
Of course, SimCity has dozens of traffic scenarios and the modules to affect them. Shopping centers, airports, external highways for import/export, farms, floods, etc. And SimCity also has scenarios that aren't traffic-related, such as whether to use green energy or high-pollution coal energy or a nuclear reactor.
Allowing the player to choose which scenarios to accept in which locations gives the player a lot of room to explore and express themselves.
In a space game, scenario modules would be things like engines, lasers, etc. These are installed with the understanding that they will be useful in the scenarios of the world at large, and that those scenarios are the ones this ship will usually be in. Of course, they create load by being used, but they also take up space and perhaps have a secondary load even when not in use...
In a boat or plane game, one scenario module set would be engines, with the idea that different amounts of different engines would propel you at different speeds and different heights. Are you building a submarine? A high-altitude spaceplane? Which engines you choose will determine what kinds of scenarios you can face, so those engines are a scenario module.
The point is to get the player to select what scenario challenges they want to face, and allow them to create something that deals with those challenges. The idea is almost never to deal with a single challenge, but is instead to deal with a parade of challenges, often tightly themed.
An example of this would be Dwarf Fortress, where there are four or five categories of challenge: invasions, mood swings, the elements, supplies, etc. The player builds their fortress with these considerations in mind, depending on where they built. Your fortress has a death zone for attacking invaders - but make sure you know what kind of invaders you'll be facing. You have a jail for depressed or berserk folk. You have dug deep to find water, and now need to pipe it up into the living quarters.
You can see how each of these challenges can be abstracted to traffic patterns with side effects. Here's the pattern for incoming enemies. Here's the pattern for water. Here's the pattern for farmers going to work. Here's the pattern for quickly isolating a self-destructing inhabitant. Here's how they interact - the farmers walk right across the incoming enemy lane, that seems dangerous...
Well, it's the same thing no matter what the theme of the game.
My space ship should face the challenges I want it to face, and that will test the setup I created.
Not a spreadsheet, but a living entity that responds and changes on a local level.
But this kind of play requires careful construction. A lot of games rely on a "spreadsheet" approach, where the modules just add to numbers on a spreadsheet. This is almost universal on mobile, and is sadly common in indie games on every platform.
You want to build a city? Add a fishery for +5 food! A space ship? Add an arc reactor for +5 energy!
The problem is that spreadsheet play is fundamentally passive. The thing I'm building doesn't do anything, it just drifts along as a pile of numbers.
The things that bring a construction to life are the challenges it faces.
If I build a city, how does it fare in winter? If I build a castle, how does it fare against siege? If I build a starship, how does it fare during re-entry?
It's possible to push a spreadsheet to respond to challenges, but I prefer having more direct control.
I prefer topological construction. That is, where I put things matters.
The details of this matter. How do you make placing things relative to other things matter?
Well, there's three pieces: the mechanic, the load, and the scenario modules.
The mechanic is how you make the location matter. The key to the mechanic is that is has to be a local effect with consequences. It shouldn't be pass-fail: the whole point is to create a soft, widely interlocking mechanic that the player can adjust in a lot of ways.
For example, in SimCity, the main mechanic is traffic. Traffic produces pollution, and if you fall short, it also produces economic slowdown, unhappiness, and road failure (in that overtaxing a road results in a traffic jam).
In a space ship game, the mechanic might be power. Power transfer produces lot of heat and nearby elements may degrade, and the laser will fire slowly and weakly if you fall short... Or perhaps the mechanic could be damage, coming in from an outside vector, needing to be blocked and dispersed...
In a boat or plane game, the mechanic might be water or airflow - how it exerts pressure at various speeds.
As you can see, not all mechanics are internal-only. Many of them are about how your system interacts with the wider world. And, of course, most construction games have many mechanics, some larger, some smaller: SimCity has traffic as a mechanic, but also pollution, economics, happiness, weather, water...
The load is how the mechanic expresses itself in local space, and what modules the player can use to handle that.
For example, SimCity has roads for cars... and also road/car variants like subways, buses, etc. The player is given freedom to optimize: put in a subway from the residential district to the commercial district, and most of that kind of traffic will go through there instead of through the more limited surface roads, freeing those up for shipping...
In a space ship game, it might be power cables, capacitors, etc. Or, if damage is the mechanic, it might be armor, magnetic screens, shock absorbers, air gaps, shield projectors... the idea is to make it something local, so shipwide shield generators do not count.
In a boat or plane game, it'd obviously be the hull itself, both hull plates and elements that happen to be exposed.
Scenario modules are elements you install specifically to create or respond to scenarios. Sometimes these are not specifically spawned by devices inside the creation, but even then the creation will be arranged to respond to a specific scenario and you must allow that scenario to be fired.
In SimCity, houses and office buildings create an interlocked scenario where traffic goes from one to the other, then the reverse. In exchange, you get money. There are constraints to prevent you from crowding houses and offices together (noise pollution, etc) so you're forced to connect them via long traffic routes.
Of course, SimCity has dozens of traffic scenarios and the modules to affect them. Shopping centers, airports, external highways for import/export, farms, floods, etc. And SimCity also has scenarios that aren't traffic-related, such as whether to use green energy or high-pollution coal energy or a nuclear reactor.
Allowing the player to choose which scenarios to accept in which locations gives the player a lot of room to explore and express themselves.
In a space game, scenario modules would be things like engines, lasers, etc. These are installed with the understanding that they will be useful in the scenarios of the world at large, and that those scenarios are the ones this ship will usually be in. Of course, they create load by being used, but they also take up space and perhaps have a secondary load even when not in use...
In a boat or plane game, one scenario module set would be engines, with the idea that different amounts of different engines would propel you at different speeds and different heights. Are you building a submarine? A high-altitude spaceplane? Which engines you choose will determine what kinds of scenarios you can face, so those engines are a scenario module.
The point is to get the player to select what scenario challenges they want to face, and allow them to create something that deals with those challenges. The idea is almost never to deal with a single challenge, but is instead to deal with a parade of challenges, often tightly themed.
An example of this would be Dwarf Fortress, where there are four or five categories of challenge: invasions, mood swings, the elements, supplies, etc. The player builds their fortress with these considerations in mind, depending on where they built. Your fortress has a death zone for attacking invaders - but make sure you know what kind of invaders you'll be facing. You have a jail for depressed or berserk folk. You have dug deep to find water, and now need to pipe it up into the living quarters.
You can see how each of these challenges can be abstracted to traffic patterns with side effects. Here's the pattern for incoming enemies. Here's the pattern for water. Here's the pattern for farmers going to work. Here's the pattern for quickly isolating a self-destructing inhabitant. Here's how they interact - the farmers walk right across the incoming enemy lane, that seems dangerous...
Well, it's the same thing no matter what the theme of the game.
My space ship should face the challenges I want it to face, and that will test the setup I created.
Not a spreadsheet, but a living entity that responds and changes on a local level.
Tuesday, July 23, 2019
Making Things Seem Bigger
One thing I love about video games is that I can make things as big as I want.
However, I've quickly learned that bigger isn't always bigger.
The human brain uses a lot of specific techniques to "feel" how big something is, and those are not the same techniques a game uses to render bigger things.
As a result, a lot of indie content is overly huge... but doesn't feel big. It just feels boring.
So my focus now is on how to make content feel bigger without actually making it that big.
This shares a lot of techniques with various architecture, theme park, and interior design practices, but it's distinct from them because we're working with something that doesn't actually exist.
With that in mind, here's some half-formed ideas I had about it. Feel free to chime in.
---
One thing is to "clutter" the right amount.
Say you have a 10mx10m area. That's about the footprint of a small house. How do you make it feel big?
Well, one way is to declutter. If the area is wide open, flat, and brightly lit... it'll feel bigger. But it'll also feel empty and pointless when you move through it.
Another way is to clutter. For example, if we put in islands of furniture, maybe add some pillars... we can add a lot of density to the space. In this case it will feel smaller to the eye, but it'll feel much larger and more interesting when you actually move through it.
We can probably get the best of both worlds by using "zoning" tactics instead of simple clutter tactics. For example, using different flooring types to cut the room into areas, adding a raised or lowered section, creating drop ceiling elements, using ceiling topology to create complexity up high, adding lights that create patterns or focal points in the corners... these keep the room feeling large to the eye, but still make it feel detailed as you move through it.
If I was creating a complex level, I might focus on decluttering on neighboring spaces the player won't travel to much, so I can make them physically smaller but feel like they are quite large when glimpsed by the player. Spaces with dense gameplay, I might use clutter to reduce travel times and create overlapping concerns. Spaces with a moderate combination of both gameplay and travel might focus more on zoning...
This is a really basic example, but I wanted to show that what I'm thinking about is not simply "how to make things look bigger", but "how to make things feel bigger as you move through them". After all, video games are interactive.
---
If you are walking up to a space ship, how can you make it seem like a really big space ship?
How about if you're flying up to one? Swimming? Teleporting?
Controlling the kind of movement the player is using is critical, because that's how you amplify the size of a ship.
For example, if the player is walking on the outside of a ship, the ship is basically terrain, very close to the player's face. Even small ships like fightercraft can feel very large if you're clomping across their wings in magnetic boots! They'll feel even bigger if you're going hand-over-hand along a guide rail, your helmet a mere foot from that same wing surface...
If the player is coming in from a distance, it's important to allow them to feel the distance of the ship by giving them nearby motion. For example, walking through gates, or passing through a cloud of debris, or walking past parked cars. To amplify this, the nearby motion does not have to be parallax: as you approach the ship, cars drive past you away from the ship. Barriers lift in front of you. The wind kicks up a dust storm. These motions will help to give the ship a sense of scale, even though they're not technically parallax.
The ship itself is also optimizable.
One thing you can do is simply add elements of scale to the ship, like a heavy crane loading up cargo, or a worker squatting on the wing, touching up the paint. These are things that we think we understand the size of, so our brain will naturally get a feel for how large the ship is. If they're slightly undersized as compared to what we expect, then the ship will feel oversized: workers should be crouching or kneeling to reduce their apparent size, cranes can be built with "heavy industrial" feel even when they're medium industrial size, etc.
The ship itself has a particular layout that can be optimized to create parallax. Smaller ships should have protrusions and/or limbs: head, wings, engine nacelles, antennae or cannons that stick out. These need to stick out in directions that create parallax: having an antenna stick up is good to create a sense of presence, but it doesn't create any parallax unless it's sticking outward. Things like antennae should have lights at the tip: this will make the parallax clearly visible and also make the ship feel larger at greater distances since the lights will define a perimeter.
Larger ships can be thought of as places rather than things. For them, it's more important to create an approach vector that creates nice views, rather than having protrusions. If the player is moving towards a large ship on a curved approach to dock or enter on a specific spot, that will allow the player plenty of time to see the parallax grow as they get close. However, if the player is approaching on a direct path, the parallax will be minimized.
Entryways like docking bays and gangways should be nestled into concave areas. The surrounding protrusions will create a sense of parallax as you move towards or away from the entrance. So... overhangs, side braces, giant clamps, whatever you can do.
You can also use "bristles" on ships, large or small. Any kind of semitransparent lattice will work, with the idea being that regardless of your approach vector, these will have noticeable parallax. Lighting concave areas and areas behind the "bristles" will also produce a lot of changes as those regions become more or less visible due to parallax.
If the ship has large topologically uninteresting zones, add lighting or paint elements to create demarcations. They don't have to be visible at large ranges, they're specifically to break it up when the player gets close, so faint greebling or motion-sensor lights are plausible.
In addition to parallax tricks, you can use a million other tricks. Small ships can "bulk up" when parked by raising their wings, opening their canopies or fueling covers, half-ejecting fuel rods. How heavy they feel is also a factor: do the feet sink into the ground? Does the howling wind knock their antennae around but leave them unbudged?
There's also things like atmospheric effects, depth of field, and converging lines to think about... placing a parked ship noticeably above or below the horizon will make it seem closer, while on the horizon it will feel further away. Therefore, small ships should park on the horizon line and large ships should park above or below it... keeping in mind that the player's horizon line is determined by camera height, not by eye height or walkway height, so approach vectors should have ceilings to force the player's camera into a predictable horizon line.
And that's just the exterior...
---
Making areas feel big on the interior is perhaps even more critical, because you don't want the player to have to walk long distances inside of a building or space ship. So things need to feel big without being big.
Level design conversations about this are not impossible to find, but here's some basic tips I'm eager to try:
Windows or overlooks onto interior spaces, not just exterior windows. Central spaces with complex traffic patterns, including multi-floor elements.
Clean straight paths through cluttered rooms with a clear view of the next room, curved paths through larger, uncluttered rooms...
Light the corners more aggressively than usual, but while remembering to break the cubey feel of corners. IE, stick well-lit furniture into corners.
Use cut-out alcoves to create workspaces, rather than putting workspaces into the main floor area.
Trying "false windows" instead of Jefferies Tubes: IE, a grate or transparent panel with a largish, lit area behind it.
Having screens default to scenery instead of black.
Using the wall lines common in sci fi to enhance the size of the room instead of just making it feel cluttered. This is easiest on scales larger than a small hallway: for example, in cargo bays. One critical part of this is to use lighting in any sci fi recesses: IE, if you have a head-height outwards bend, put lights in it.
Use furniture/functional elements that take the room's major axis into account. For example, if I want a hallway to feel shorter, I can use vertical banding (braces and bulwarks). If I want it to feel longer, I can use horizontal banding (stripes and shelves).
Using small rises and falls, both in large rooms and in chains of small rooms. The rising and falling can be floor, ceiling, or both.
Create centerpiece elements that aren't actually in the center of the room, since players shouldn't be using 100% of the room evenly. Centerpieces should make the room feel larger when you're passing by, and usually only one or two edges of a rectangular room are travel lanes.
Interrupt the flow of a room logically, but not visually. Using glass, transparent hologram, floor and ceiling patterns...
And I want to try adding things like diffusing drapes and frosted glass rather than just big heavy metal doors.
---
So that's what I've been thinking about this week.
However, I've quickly learned that bigger isn't always bigger.
The human brain uses a lot of specific techniques to "feel" how big something is, and those are not the same techniques a game uses to render bigger things.
As a result, a lot of indie content is overly huge... but doesn't feel big. It just feels boring.
So my focus now is on how to make content feel bigger without actually making it that big.
This shares a lot of techniques with various architecture, theme park, and interior design practices, but it's distinct from them because we're working with something that doesn't actually exist.
With that in mind, here's some half-formed ideas I had about it. Feel free to chime in.
---
One thing is to "clutter" the right amount.
Say you have a 10mx10m area. That's about the footprint of a small house. How do you make it feel big?
Well, one way is to declutter. If the area is wide open, flat, and brightly lit... it'll feel bigger. But it'll also feel empty and pointless when you move through it.
Another way is to clutter. For example, if we put in islands of furniture, maybe add some pillars... we can add a lot of density to the space. In this case it will feel smaller to the eye, but it'll feel much larger and more interesting when you actually move through it.
We can probably get the best of both worlds by using "zoning" tactics instead of simple clutter tactics. For example, using different flooring types to cut the room into areas, adding a raised or lowered section, creating drop ceiling elements, using ceiling topology to create complexity up high, adding lights that create patterns or focal points in the corners... these keep the room feeling large to the eye, but still make it feel detailed as you move through it.
If I was creating a complex level, I might focus on decluttering on neighboring spaces the player won't travel to much, so I can make them physically smaller but feel like they are quite large when glimpsed by the player. Spaces with dense gameplay, I might use clutter to reduce travel times and create overlapping concerns. Spaces with a moderate combination of both gameplay and travel might focus more on zoning...
This is a really basic example, but I wanted to show that what I'm thinking about is not simply "how to make things look bigger", but "how to make things feel bigger as you move through them". After all, video games are interactive.
---
If you are walking up to a space ship, how can you make it seem like a really big space ship?
How about if you're flying up to one? Swimming? Teleporting?
Controlling the kind of movement the player is using is critical, because that's how you amplify the size of a ship.
For example, if the player is walking on the outside of a ship, the ship is basically terrain, very close to the player's face. Even small ships like fightercraft can feel very large if you're clomping across their wings in magnetic boots! They'll feel even bigger if you're going hand-over-hand along a guide rail, your helmet a mere foot from that same wing surface...
If the player is coming in from a distance, it's important to allow them to feel the distance of the ship by giving them nearby motion. For example, walking through gates, or passing through a cloud of debris, or walking past parked cars. To amplify this, the nearby motion does not have to be parallax: as you approach the ship, cars drive past you away from the ship. Barriers lift in front of you. The wind kicks up a dust storm. These motions will help to give the ship a sense of scale, even though they're not technically parallax.
The ship itself is also optimizable.
One thing you can do is simply add elements of scale to the ship, like a heavy crane loading up cargo, or a worker squatting on the wing, touching up the paint. These are things that we think we understand the size of, so our brain will naturally get a feel for how large the ship is. If they're slightly undersized as compared to what we expect, then the ship will feel oversized: workers should be crouching or kneeling to reduce their apparent size, cranes can be built with "heavy industrial" feel even when they're medium industrial size, etc.
The ship itself has a particular layout that can be optimized to create parallax. Smaller ships should have protrusions and/or limbs: head, wings, engine nacelles, antennae or cannons that stick out. These need to stick out in directions that create parallax: having an antenna stick up is good to create a sense of presence, but it doesn't create any parallax unless it's sticking outward. Things like antennae should have lights at the tip: this will make the parallax clearly visible and also make the ship feel larger at greater distances since the lights will define a perimeter.
Larger ships can be thought of as places rather than things. For them, it's more important to create an approach vector that creates nice views, rather than having protrusions. If the player is moving towards a large ship on a curved approach to dock or enter on a specific spot, that will allow the player plenty of time to see the parallax grow as they get close. However, if the player is approaching on a direct path, the parallax will be minimized.
Entryways like docking bays and gangways should be nestled into concave areas. The surrounding protrusions will create a sense of parallax as you move towards or away from the entrance. So... overhangs, side braces, giant clamps, whatever you can do.
You can also use "bristles" on ships, large or small. Any kind of semitransparent lattice will work, with the idea being that regardless of your approach vector, these will have noticeable parallax. Lighting concave areas and areas behind the "bristles" will also produce a lot of changes as those regions become more or less visible due to parallax.
If the ship has large topologically uninteresting zones, add lighting or paint elements to create demarcations. They don't have to be visible at large ranges, they're specifically to break it up when the player gets close, so faint greebling or motion-sensor lights are plausible.
In addition to parallax tricks, you can use a million other tricks. Small ships can "bulk up" when parked by raising their wings, opening their canopies or fueling covers, half-ejecting fuel rods. How heavy they feel is also a factor: do the feet sink into the ground? Does the howling wind knock their antennae around but leave them unbudged?
There's also things like atmospheric effects, depth of field, and converging lines to think about... placing a parked ship noticeably above or below the horizon will make it seem closer, while on the horizon it will feel further away. Therefore, small ships should park on the horizon line and large ships should park above or below it... keeping in mind that the player's horizon line is determined by camera height, not by eye height or walkway height, so approach vectors should have ceilings to force the player's camera into a predictable horizon line.
And that's just the exterior...
---
Making areas feel big on the interior is perhaps even more critical, because you don't want the player to have to walk long distances inside of a building or space ship. So things need to feel big without being big.
Level design conversations about this are not impossible to find, but here's some basic tips I'm eager to try:
Windows or overlooks onto interior spaces, not just exterior windows. Central spaces with complex traffic patterns, including multi-floor elements.
Clean straight paths through cluttered rooms with a clear view of the next room, curved paths through larger, uncluttered rooms...
Light the corners more aggressively than usual, but while remembering to break the cubey feel of corners. IE, stick well-lit furniture into corners.
Use cut-out alcoves to create workspaces, rather than putting workspaces into the main floor area.
Trying "false windows" instead of Jefferies Tubes: IE, a grate or transparent panel with a largish, lit area behind it.
Having screens default to scenery instead of black.
Using the wall lines common in sci fi to enhance the size of the room instead of just making it feel cluttered. This is easiest on scales larger than a small hallway: for example, in cargo bays. One critical part of this is to use lighting in any sci fi recesses: IE, if you have a head-height outwards bend, put lights in it.
Use furniture/functional elements that take the room's major axis into account. For example, if I want a hallway to feel shorter, I can use vertical banding (braces and bulwarks). If I want it to feel longer, I can use horizontal banding (stripes and shelves).
Using small rises and falls, both in large rooms and in chains of small rooms. The rising and falling can be floor, ceiling, or both.
Create centerpiece elements that aren't actually in the center of the room, since players shouldn't be using 100% of the room evenly. Centerpieces should make the room feel larger when you're passing by, and usually only one or two edges of a rectangular room are travel lanes.
Interrupt the flow of a room logically, but not visually. Using glass, transparent hologram, floor and ceiling patterns...
And I want to try adding things like diffusing drapes and frosted glass rather than just big heavy metal doors.
---
So that's what I've been thinking about this week.
Tuesday, June 18, 2019
Space Survival Gameplay
I was asked a little while ago how I would do a space survival game, since I've been ragging on them recently. I also mentioned it in a video or two. So let's talk.
Let's get started simple. Let's say I'm a Star Citizen dev, out to put survival mechanics into my pew pew shooty game. I already have gorgeous starship interiors, now it's time to leverage them. How do I do it?
Well, my goal is to turn survival into a yarnball. A soft, complicated challenge that interlaces with a lot of other things. I also want to make sure that it unfolds into a narrative according to the choices the player makes.
So I implement a The Simslike survival system. Every time you make a space jump, your various meters go up. Hunger and filth, for example.
Actually using kitchens and showers is a repetitive and uninteresting task, so rather than requiring you to use the facilities, we simply reduce the meter if you have them. If you have a kitchenette, your hunger goes up 90% slower. A full kitchen? It doesn't go up at all... until your food runs out.
We do want to push the player to exist in that space, so we do allow the player to use a facility for a temporary boost - until the end of the next jump. If we use the kitchen, we get a +20%, but it uses up a bit of food. If we use the shower, we get a +10%, but it doesn't use up anything. This bonus doesn't reduce your meters, it simply enhances your performance. It doesn't stack.
To make this into a more narratively cohesive experience, we have to decide on the narrative we want. And the narrative we want is how the pressures of space travel shape our life aboard a ship.
This is not simply about "life aboard a ship". The point is to turn challenges - the challenges of a human surviving in space - into narrative beats. The ship is our tool to do that, but the challenge it parses is the challenge of survival.
If we want a gritty feel, we could get things like life support involved. But the ships in Star Citizen are ridiculously high tech, so instead we're thinking more about the social narrative. How does the mind fail, rather than the body.
So we add a few more meters. Loneliness, claustrophobia, boredom.
When they go up, you have to bring them down. Find someone to talk to. Land on a planet or space station and step outside. Have some fun by daredevil flying or fighting or driving a different vehicle.
...
A new player buying a new ship finds it comes with a little pocket gym. The gym reduces the meter growth of those three stats by 50% each, maybe.
But the player knows they are playing solo, and are planning to go on long explorations. So the big threat here is loneliness. The others can be dealt with in the middle of nowhere by visiting any random rock, but finding a person will be tough.
So the player rips out the gym, replaces it with a media console that constantly blares news shows and comedies. She puts portraits of her family on the wall, or pinups maybe. She buys a wisecracking robot companion.
These keep her company. And she can use them to boost: give the family a kiss, get +30%. Watch a TV show, get +40%, but use up a media slot - she'll need to buy the next season of Game of Space Thrones or trade SpaceYouTube caches with someone else to get those slots filled up with new stuff. Better to keep that cache intact, so it burns at the slower default rate and lasts longer.
And sure, she gets twitchy from the claustrophobia and the boredom. But that's why canyon racing was invented.
...
On the other hand, someone else might be playing on a team. They know loneliness won't be an issue, because there's another player around here. So they max out the others. They buy giant 3D landscapes for their walls - radically reducing claustrophobia, but actually increasing loneliness. They replace their gym with a video game console.
They can go for a long ways without having to land or play around, but they have to chat with someone every two jumps to stay happy.
No problem, they're sitting next to you.
...
We can see how the player's construction choices change the narrative. The player is choosing what narrative beats to include, which ones to play up or limit. One of those players is having a long, lonely journey hopping from planet to planet. The other is on a road trip with friends.
Those are very different narratives. We didn't write those narratives: we allow the challenges to be faced in a way that turns them into narratives.
We can push this in a lot of ways. For example, if we make it so that talking to a specific person works worse every time you do it, then those long journeys get more challenging because you have to find new people to talk to. If you burn media to keep your boredom under control, maybe you change one of those "size three hardpoints" from a gun to a giant subspace antenna that lets you transfer media from space stations a hundred light years away. Need food? There's a variety of greenhouses both internal and external...
These ramifications are polish on a core concept. If we didn't have the core progression, they'd be pointless. Most of this would be pointless if the player had to return to a station every time they logged off, for example: long journeys would be limited by a player's capacity to sit at their desk and play. But since you can log off in midjourney and come back, we can assume many players will go on very long journeys.
The question becomes: what of the players that don't?
What about the players that are short-haul? Players that specialize in fighting or shipping people or freight over shorter distances?
It's a common thing. A lot of players want to sit and do A Mission Now, and be done in half an hour. They don't want to log off midmission and come back to the same thing.
Can we make our survival systems create their narratives, too?
Well... no. It's not survival. But we can use the same core mechanics.
...
We could try to add stats like paperwork that go up as you dock... but what sort of narrative unfolds with that?
Not much of one. How can we make it messier and more entangled?
Well, most short-haul specialists will have specific hub stations - or, at least, specific preferred factions.
This is where it can't be Star Citizen, because their faction system has a ceiling. But if we throw that away, we can allow the player to build their contacts with the faction.
Rather than focusing entirely on the ship, we can allow the player-generated content to include people. Both NPC crewmembers aboard your ship and people you have agreements with on various space stations.
I would do it using a similar modular setup to the one used for ships and interiors:
As you rank up, you get a better "dossier" for that faction.
Like a ship, a dossier has specialties and hardpoints. This dossier specializes in freight permissions. This one improves insurance and rates on being a passenger liner. This one's exploration-based.
The hardpoints are people. This one's a tier 3 diplomat hard point, and you can slot in any NPC diplomat that rank or lower to act as your "weapon", giving you access to more options, more goods, more security, more sites. Reduce the rank by one just like you'd do for hardpoint turrets, and hire that person as a crewmember on your ship instead of being specific to their home space station...
Because the dossiers are essentially ships, we can offload our survival mechanics onto them.
As time passes and things happen, you might gain criminality, or disinterest, or distrust. These can be reduced if you equip the right kind of person on your hardpoints, but otherwise you'll have to do faction missions to clean them up.
And now, again, we've turned a challenge into a narrative.
Building small dossiers is easy, but you quickly learn you need to tweak it to suit your style. Do you do some... not so legal missions? You'll want a lawyer and a fence installed. Do you do a lot of business with other factions? You'll want a politician, to keep the distrust low. You go on long journeys? You'll want a reporter, to keep disinterest under control. You trade with a lot of different systems from that faction? Buy a one-rank-lower trader as a crewmember, so you get that advantage in every system.
These could even be tweaked per-faction. Both by the player, depending on their interactions with the faction... and by the devs.
Your Vulcan-ish faction might never gain disinterest, but gives bonus distrust if you sell science data to other factions. Your Klingon-ish faction loses interest extremely rapidly but never gives out criminality...
This has an extremely high ceiling. At upper levels, you might be adding the president of a space station to your dossier, or using a cross-contact politician to transfer stats to another faction's dossier.
And you can go negative. You're disliked by the Vulcan-ish faction? Add specific nemesis to your unhappy dossier. It's got a few good hard points - contacts from other factions or even turncoats from this faction - but you have to fill all your negative hardpoints first, adding in suspicious cops, angry politicians, and persistent bounty hunters.
Again: build your own narrative out of the challenge. *You choose* how your story of banditry or war unfolds.
...
Hopefully this has been a fun exploration of how to make player-created content that can turn simple things (survival, faction rank) into more robust, soft, complex mechanics that create a narrative.
To be clear: I think you could create an entire game around these concepts, rather than the shooty pew pew gameplay that I find so dreary.
There's also a lot to talk about in regards to things like resource tiering and keeping inflation under control, and it's tightly related. But... I think this is long enough.
Let's get started simple. Let's say I'm a Star Citizen dev, out to put survival mechanics into my pew pew shooty game. I already have gorgeous starship interiors, now it's time to leverage them. How do I do it?
Well, my goal is to turn survival into a yarnball. A soft, complicated challenge that interlaces with a lot of other things. I also want to make sure that it unfolds into a narrative according to the choices the player makes.
So I implement a The Simslike survival system. Every time you make a space jump, your various meters go up. Hunger and filth, for example.
Actually using kitchens and showers is a repetitive and uninteresting task, so rather than requiring you to use the facilities, we simply reduce the meter if you have them. If you have a kitchenette, your hunger goes up 90% slower. A full kitchen? It doesn't go up at all... until your food runs out.
We do want to push the player to exist in that space, so we do allow the player to use a facility for a temporary boost - until the end of the next jump. If we use the kitchen, we get a +20%, but it uses up a bit of food. If we use the shower, we get a +10%, but it doesn't use up anything. This bonus doesn't reduce your meters, it simply enhances your performance. It doesn't stack.
To make this into a more narratively cohesive experience, we have to decide on the narrative we want. And the narrative we want is how the pressures of space travel shape our life aboard a ship.
This is not simply about "life aboard a ship". The point is to turn challenges - the challenges of a human surviving in space - into narrative beats. The ship is our tool to do that, but the challenge it parses is the challenge of survival.
If we want a gritty feel, we could get things like life support involved. But the ships in Star Citizen are ridiculously high tech, so instead we're thinking more about the social narrative. How does the mind fail, rather than the body.
So we add a few more meters. Loneliness, claustrophobia, boredom.
When they go up, you have to bring them down. Find someone to talk to. Land on a planet or space station and step outside. Have some fun by daredevil flying or fighting or driving a different vehicle.
...
A new player buying a new ship finds it comes with a little pocket gym. The gym reduces the meter growth of those three stats by 50% each, maybe.
But the player knows they are playing solo, and are planning to go on long explorations. So the big threat here is loneliness. The others can be dealt with in the middle of nowhere by visiting any random rock, but finding a person will be tough.
So the player rips out the gym, replaces it with a media console that constantly blares news shows and comedies. She puts portraits of her family on the wall, or pinups maybe. She buys a wisecracking robot companion.
These keep her company. And she can use them to boost: give the family a kiss, get +30%. Watch a TV show, get +40%, but use up a media slot - she'll need to buy the next season of Game of Space Thrones or trade SpaceYouTube caches with someone else to get those slots filled up with new stuff. Better to keep that cache intact, so it burns at the slower default rate and lasts longer.
And sure, she gets twitchy from the claustrophobia and the boredom. But that's why canyon racing was invented.
...
On the other hand, someone else might be playing on a team. They know loneliness won't be an issue, because there's another player around here. So they max out the others. They buy giant 3D landscapes for their walls - radically reducing claustrophobia, but actually increasing loneliness. They replace their gym with a video game console.
They can go for a long ways without having to land or play around, but they have to chat with someone every two jumps to stay happy.
No problem, they're sitting next to you.
...
We can see how the player's construction choices change the narrative. The player is choosing what narrative beats to include, which ones to play up or limit. One of those players is having a long, lonely journey hopping from planet to planet. The other is on a road trip with friends.
Those are very different narratives. We didn't write those narratives: we allow the challenges to be faced in a way that turns them into narratives.
We can push this in a lot of ways. For example, if we make it so that talking to a specific person works worse every time you do it, then those long journeys get more challenging because you have to find new people to talk to. If you burn media to keep your boredom under control, maybe you change one of those "size three hardpoints" from a gun to a giant subspace antenna that lets you transfer media from space stations a hundred light years away. Need food? There's a variety of greenhouses both internal and external...
These ramifications are polish on a core concept. If we didn't have the core progression, they'd be pointless. Most of this would be pointless if the player had to return to a station every time they logged off, for example: long journeys would be limited by a player's capacity to sit at their desk and play. But since you can log off in midjourney and come back, we can assume many players will go on very long journeys.
The question becomes: what of the players that don't?
What about the players that are short-haul? Players that specialize in fighting or shipping people or freight over shorter distances?
It's a common thing. A lot of players want to sit and do A Mission Now, and be done in half an hour. They don't want to log off midmission and come back to the same thing.
Can we make our survival systems create their narratives, too?
Well... no. It's not survival. But we can use the same core mechanics.
...
We could try to add stats like paperwork that go up as you dock... but what sort of narrative unfolds with that?
Not much of one. How can we make it messier and more entangled?
Well, most short-haul specialists will have specific hub stations - or, at least, specific preferred factions.
This is where it can't be Star Citizen, because their faction system has a ceiling. But if we throw that away, we can allow the player to build their contacts with the faction.
Rather than focusing entirely on the ship, we can allow the player-generated content to include people. Both NPC crewmembers aboard your ship and people you have agreements with on various space stations.
I would do it using a similar modular setup to the one used for ships and interiors:
As you rank up, you get a better "dossier" for that faction.
Like a ship, a dossier has specialties and hardpoints. This dossier specializes in freight permissions. This one improves insurance and rates on being a passenger liner. This one's exploration-based.
The hardpoints are people. This one's a tier 3 diplomat hard point, and you can slot in any NPC diplomat that rank or lower to act as your "weapon", giving you access to more options, more goods, more security, more sites. Reduce the rank by one just like you'd do for hardpoint turrets, and hire that person as a crewmember on your ship instead of being specific to their home space station...
Because the dossiers are essentially ships, we can offload our survival mechanics onto them.
As time passes and things happen, you might gain criminality, or disinterest, or distrust. These can be reduced if you equip the right kind of person on your hardpoints, but otherwise you'll have to do faction missions to clean them up.
And now, again, we've turned a challenge into a narrative.
Building small dossiers is easy, but you quickly learn you need to tweak it to suit your style. Do you do some... not so legal missions? You'll want a lawyer and a fence installed. Do you do a lot of business with other factions? You'll want a politician, to keep the distrust low. You go on long journeys? You'll want a reporter, to keep disinterest under control. You trade with a lot of different systems from that faction? Buy a one-rank-lower trader as a crewmember, so you get that advantage in every system.
These could even be tweaked per-faction. Both by the player, depending on their interactions with the faction... and by the devs.
Your Vulcan-ish faction might never gain disinterest, but gives bonus distrust if you sell science data to other factions. Your Klingon-ish faction loses interest extremely rapidly but never gives out criminality...
This has an extremely high ceiling. At upper levels, you might be adding the president of a space station to your dossier, or using a cross-contact politician to transfer stats to another faction's dossier.
And you can go negative. You're disliked by the Vulcan-ish faction? Add specific nemesis to your unhappy dossier. It's got a few good hard points - contacts from other factions or even turncoats from this faction - but you have to fill all your negative hardpoints first, adding in suspicious cops, angry politicians, and persistent bounty hunters.
Again: build your own narrative out of the challenge. *You choose* how your story of banditry or war unfolds.
...
Hopefully this has been a fun exploration of how to make player-created content that can turn simple things (survival, faction rank) into more robust, soft, complex mechanics that create a narrative.
To be clear: I think you could create an entire game around these concepts, rather than the shooty pew pew gameplay that I find so dreary.
There's also a lot to talk about in regards to things like resource tiering and keeping inflation under control, and it's tightly related. But... I think this is long enough.
Tuesday, June 11, 2019
Boiling the Yarnball
I've been thinking about why I like the construction games I like.
I'm including things like The Sims into this category. Whether you're constructing vehicles or facilities or people, there is one specific feel I like, and a bunch I don't.
I think it's yarnballs.
Big, soft, messy challenges that can be approached in a lot of different ways with a lot of different entanglements to the rest of the game.
For example, you're playing a space game. The rules are: you must have one point of life support per astronaut.
This is a small, hard constraint. There's no softness, no flexibility, no entanglement... no mess.
But in Oxygen Not Included, that rule is turned into a yarn ball thanks to the physics sim. I can create drafts of carbon dioxide, let rooms sort themselves into bands of gases and keep people in the oxygen zone, let them breath diseased oxygen, use pressure gates to optimize pressure for ideal algae conversion...
A combination of complex approaches (scrubbers, cleaners, algae, natural oxygen sources, etc) combined with complex topological possibilities (pressure, natural air sorting, air filtering, wind, etc) creates a lot of possibilities, a lot of bizarre, fun approaches that affect everything else in my facility.
It's not me balancing a spreadsheet. It's me building a facility, with all the complexity that entails.
One thing that makes this yarnball approach shine is how it ties into the rest of the construction, and how it turns a challenge into a narrative.
Challenge: you need to provide air.
Narrative: "the third and fourth floors of our Mars base are pressurized. Whenever we venture down to the first floor to change out the algae, we hold our breaths and work fast. Sandra got real sick when she couldn't hold her breath long enough."
The thing about yarnballs is that you do, eventually, sort them. Maybe not to some perfect standard, but you develop a method that works for you, and you'll usually stick with it.
That's why it's so important that the construction game is a huge pile of yarnballs.
If I sort one, there's another behind it.
More importantly, as I sort that one, I realize it's tied to the first one, and I didn't sort it well enough!
This creates an endless chain of narratives as I watch my facilities struggle with challenge after challenge, all their difficulties largely being my fault.
Another example of a yarnball is having children in The Sims.
Not only are the children themselves fairly complex, but caring for them is a convoluted, messy yarnball. You may think you have it solved, but then you realize your stay at home parent this time is a neat freak or something, and your timetable falls apart.
Or how about building a defensive entrance in Dwarf Fortress?
You have to deal with the threat of invaders, so you build a defensive gate. But how big is it? How do people get through it on their daily lives? How many resources can you afford to spend on it? What traps can you build? When you need to upgrade it, how will that work out?
And when the invasion happens, the gate helps turn the rather blunt narrative of "you lose, everyone dies" into a more nuanced narrative: "Bjornblatt lost an arm fighting off the goblins that got through the traps, and Hjornol is now responsible for rebuilding those traps into something more effective..."
I think yarnballs require a certain presentation to catch my attention.
I call it "boiling the yarnball".
This is a technique where nearly all of the game is incremental. In The Sims, your skills slowly go up, money slowly trickles in, you slowly do better at your job. In DF, you slowly farm, slowly build another bunkroom. It's all incremental.
Except then it's not. There's a challenge you're working towards.
In The Sims, is it time for a kid? Time to move? Time to get a promotion? Maybe just time to throw a big party?
In DF, is it time to build a defensive gate? Internal waterways? A magma forge? Maybe just time to rearrange who sleeps where?
What the player considers to be "a big thing" will vary depending on skill and interest. But you're usually working towards at least one big thing. You're playing the game to push the edge of what you can do, what you understand.
If the goblins trashed you last time, this time you're playing to build goblin defenses. If your sim died old and alone last time, this time you're playing to make a family. You build towards those challenges, and some part of your construction is difficult and challenging... because you haven't mastered that yarnball yet.
So the premise here is that the yarnball isn't thrown at you. It's something you walk up to. Something you explore.
The challenge that creates the yarnball might not be so gentle. The goblins will eventually attack. You will eventually get old and die. But you have some leeway before then.
Otherwise, there's not enough time to try and detangle the yarnball.
So I like to "boil the yarnball". You let the challenge that defines the yarnball simply sit there and simmer. When the player's ready, they can begin pulling at it... at which point, the narrative becomes more concrete.
To make it more concrete, I think there are four phases to this. I'm just getting started with my thoughts on this matter, but here's what I've come up with so far.
1) Planning
What challenge does the yarnball address? How will that challenge affect your facility? How will different levels of addressing it change that? How much space do you have to build in? How many resources do you have? How many workers can you divert, for how long, before things get risky?
Tie the planning into the overall flow of your facility, so it becomes part of the narrative: "in fall of 392, we began to defend ourselves. As harvest season ended, the farmers turned their hands to construction..."
2) Construction
Did you plan it right? What goes well? Poorly? What opportunities do you seize, or threats do you face that affect your construction efforts? Again, the construction is part of the narrative of the facility: "The great iron gates in the plan were changed to wood, at the request of the lord of the land, whose brother owns a lumberyard..."
There should be no real randomness in the mechanisms of construction. The randomness comes from outside: "oh, there's a gold seam where I wanted to put a wall. Oh, my workers are throwing tantrums because of the rain..."
3) Daily life
How does your construction affect things that aren't that challenge? The 'daily life'? What new opportunities does it create? What troubles? How does it integrate into your normal daily narrative?
For example, "The gate lay open, guarded by a single lookout. The lookout became very good friends with the hunters and lumberjacks, as they passed by nearly every day..."
4) Spotlight
How does your construction actually do its job? Specifically, how does it change a challenge into a narrative?
For example, "When goblins attacked, our lookout was slacking. Several got through the gate before it could be closed. Fjornblatt is fighting the intruders while, outside, torches are being lit..."
Each of these four phases of a yarnball helps to cement the narrative of the overall facility. The yarnball is positioned specifically to turn a challenge into a narrative, not just in the moment that the challenge arrives, but in an unbroken chain throughout the course of planning, construction, and daily life.
If you turn this idea towards other genres, you can see hints of it in other games. Coincidentally, those tend to be the games I like.
In an open world RPG? Building a character is several yarnballs. Watching the character face the challenges I intend them to face is great fun, as is watching that build struggle through challenges not related to their specialty. That's the part of an open world game I like.
Contrarily, without boiling yarnballs, even games in genres I like aren't very interesting to me.
For example, most "factory builders" where you assemble cars or medicines or whatever don't hold my interest. Either because the optimizations are all very cut and dry, or because the yarnball isn't presented in a way that helps me digest it.
How about you? Any of this fit into your idea of what's fun and what's not?
I'm including things like The Sims into this category. Whether you're constructing vehicles or facilities or people, there is one specific feel I like, and a bunch I don't.
I think it's yarnballs.
Big, soft, messy challenges that can be approached in a lot of different ways with a lot of different entanglements to the rest of the game.
For example, you're playing a space game. The rules are: you must have one point of life support per astronaut.
This is a small, hard constraint. There's no softness, no flexibility, no entanglement... no mess.
But in Oxygen Not Included, that rule is turned into a yarn ball thanks to the physics sim. I can create drafts of carbon dioxide, let rooms sort themselves into bands of gases and keep people in the oxygen zone, let them breath diseased oxygen, use pressure gates to optimize pressure for ideal algae conversion...
A combination of complex approaches (scrubbers, cleaners, algae, natural oxygen sources, etc) combined with complex topological possibilities (pressure, natural air sorting, air filtering, wind, etc) creates a lot of possibilities, a lot of bizarre, fun approaches that affect everything else in my facility.
It's not me balancing a spreadsheet. It's me building a facility, with all the complexity that entails.
One thing that makes this yarnball approach shine is how it ties into the rest of the construction, and how it turns a challenge into a narrative.
Challenge: you need to provide air.
Narrative: "the third and fourth floors of our Mars base are pressurized. Whenever we venture down to the first floor to change out the algae, we hold our breaths and work fast. Sandra got real sick when she couldn't hold her breath long enough."
The thing about yarnballs is that you do, eventually, sort them. Maybe not to some perfect standard, but you develop a method that works for you, and you'll usually stick with it.
That's why it's so important that the construction game is a huge pile of yarnballs.
If I sort one, there's another behind it.
More importantly, as I sort that one, I realize it's tied to the first one, and I didn't sort it well enough!
This creates an endless chain of narratives as I watch my facilities struggle with challenge after challenge, all their difficulties largely being my fault.
Another example of a yarnball is having children in The Sims.
Not only are the children themselves fairly complex, but caring for them is a convoluted, messy yarnball. You may think you have it solved, but then you realize your stay at home parent this time is a neat freak or something, and your timetable falls apart.
Or how about building a defensive entrance in Dwarf Fortress?
You have to deal with the threat of invaders, so you build a defensive gate. But how big is it? How do people get through it on their daily lives? How many resources can you afford to spend on it? What traps can you build? When you need to upgrade it, how will that work out?
And when the invasion happens, the gate helps turn the rather blunt narrative of "you lose, everyone dies" into a more nuanced narrative: "Bjornblatt lost an arm fighting off the goblins that got through the traps, and Hjornol is now responsible for rebuilding those traps into something more effective..."
I think yarnballs require a certain presentation to catch my attention.
I call it "boiling the yarnball".
This is a technique where nearly all of the game is incremental. In The Sims, your skills slowly go up, money slowly trickles in, you slowly do better at your job. In DF, you slowly farm, slowly build another bunkroom. It's all incremental.
Except then it's not. There's a challenge you're working towards.
In The Sims, is it time for a kid? Time to move? Time to get a promotion? Maybe just time to throw a big party?
In DF, is it time to build a defensive gate? Internal waterways? A magma forge? Maybe just time to rearrange who sleeps where?
What the player considers to be "a big thing" will vary depending on skill and interest. But you're usually working towards at least one big thing. You're playing the game to push the edge of what you can do, what you understand.
If the goblins trashed you last time, this time you're playing to build goblin defenses. If your sim died old and alone last time, this time you're playing to make a family. You build towards those challenges, and some part of your construction is difficult and challenging... because you haven't mastered that yarnball yet.
So the premise here is that the yarnball isn't thrown at you. It's something you walk up to. Something you explore.
The challenge that creates the yarnball might not be so gentle. The goblins will eventually attack. You will eventually get old and die. But you have some leeway before then.
Otherwise, there's not enough time to try and detangle the yarnball.
So I like to "boil the yarnball". You let the challenge that defines the yarnball simply sit there and simmer. When the player's ready, they can begin pulling at it... at which point, the narrative becomes more concrete.
To make it more concrete, I think there are four phases to this. I'm just getting started with my thoughts on this matter, but here's what I've come up with so far.
1) Planning
What challenge does the yarnball address? How will that challenge affect your facility? How will different levels of addressing it change that? How much space do you have to build in? How many resources do you have? How many workers can you divert, for how long, before things get risky?
Tie the planning into the overall flow of your facility, so it becomes part of the narrative: "in fall of 392, we began to defend ourselves. As harvest season ended, the farmers turned their hands to construction..."
2) Construction
Did you plan it right? What goes well? Poorly? What opportunities do you seize, or threats do you face that affect your construction efforts? Again, the construction is part of the narrative of the facility: "The great iron gates in the plan were changed to wood, at the request of the lord of the land, whose brother owns a lumberyard..."
There should be no real randomness in the mechanisms of construction. The randomness comes from outside: "oh, there's a gold seam where I wanted to put a wall. Oh, my workers are throwing tantrums because of the rain..."
3) Daily life
How does your construction affect things that aren't that challenge? The 'daily life'? What new opportunities does it create? What troubles? How does it integrate into your normal daily narrative?
For example, "The gate lay open, guarded by a single lookout. The lookout became very good friends with the hunters and lumberjacks, as they passed by nearly every day..."
4) Spotlight
How does your construction actually do its job? Specifically, how does it change a challenge into a narrative?
For example, "When goblins attacked, our lookout was slacking. Several got through the gate before it could be closed. Fjornblatt is fighting the intruders while, outside, torches are being lit..."
Each of these four phases of a yarnball helps to cement the narrative of the overall facility. The yarnball is positioned specifically to turn a challenge into a narrative, not just in the moment that the challenge arrives, but in an unbroken chain throughout the course of planning, construction, and daily life.
If you turn this idea towards other genres, you can see hints of it in other games. Coincidentally, those tend to be the games I like.
In an open world RPG? Building a character is several yarnballs. Watching the character face the challenges I intend them to face is great fun, as is watching that build struggle through challenges not related to their specialty. That's the part of an open world game I like.
Contrarily, without boiling yarnballs, even games in genres I like aren't very interesting to me.
For example, most "factory builders" where you assemble cars or medicines or whatever don't hold my interest. Either because the optimizations are all very cut and dry, or because the yarnball isn't presented in a way that helps me digest it.
How about you? Any of this fit into your idea of what's fun and what's not?
Friday, April 19, 2019
Modding
I love mods, and people are talking a lot about mods, so let's do more talking about mods.
A lot of people are annoyed that Unity and Unreal don't make modding easy... but modding has never been "easy".
Flash, CryEngine, IdTech, RPGMaker... none of them are "moddable" right from the ground up. Modding has always been something the devs decide to include.
With that in mind, we can talk about mods in two ways. From the perspective of the person installing the mod ("player"), and from the perspective of the person making the mod ("creator").
---
From the player's perspective, there are probably three kinds of mods:
1) Piecemeal Content
This is content that will almost never conflict with other piecemeal content, except in the most trivial ways. Piecemeal content is probably the most popular kind of mod, including things like recruiting other players' characters, sharing messages about sun-praising, downloading vehicles from the workshop, adding new skins, etc.
2) Local Content
This is content which will conflict with any other content in the same locale. For example, if you install a mod to turn you into Bayonetta and a mod to turn you into Link, they won't get along. Similarly, you can't be in two levels at once, two missions at once, etc.
Local content can be turned into piecemeal content if you add a tool to help the player manage this kind of conflict - for example, Bayonetta and Link can both be "skin options" instead of simply overriding your appearance.
3) Core/Process
Some mods change fundamental rules of the game. For example, Skyrim mods that make character progression different, or change how weather works, or make you need to eat and sleep, or make the shaders work better.
Sometimes the mods are completely invisible, such as mods which allow other mods to work, or mods that clean up memory usage.
Frequently, core/process mods are part of a chain of required mods, like 'install the event mod, then the silent talking mod, then the progression revamped mod, and only then you can install the custom skill pack'.
---
The reason to think of mods like this is simple: it helps us to think about how mods work within our game. Can our game support piecemeal content additions? If the gameplay allows for certain kinds of piecemeal content, what is required to surface that and allow the players to load it in? If the game can support local content, can we change the way our game presents it to turn that into piecemeal content?
Can our gameplay support core/process mods? Can our game architecture? Can we revamp it? Can we create a tagging system so that we can have mods say what other mods they require, at what version?
The answer is rarely a flat yes. This kind of thing is a bit difficult to engineer, and it may damage your core gameplay. But even a small amount of moddability is a good thing, and you can leverage it to either make your game more appealing or make your game stickier.
For example, in Guacamelee, the only kind of moddable content is custom skins. However, they sent out custom skins to popular YouTubers, enticing them to play the game and be more positive about the experience. The modding made for great outreach.
---
The other half of the equation is how the creator of the mod thinks about the mod. This is equally important.
1) Diegetic assembly
When the creator never leaves the game to create the content. In the best case, the content is created simply by playing the game, but nearly all of the time this is an in-game editor. For example, you create your character, build your ship, assemble your house - all using an in-game editor.
The key here is that diegetic assembly happens in the course of normal play. A character builder counts because every player will use it at least once and consider it part of their playthrough, their experience. A mission editor generally doesn't count, because it's never used in the course of playing the game.
There is a challenge to keep the editor simple enough for everyone to use but powerful enough to let players create complex or nuanced results. There is also a challenge to leverage the editor: a character editor for a game where you only create one character is not as well-leveraged as a game where you create multiple characters over the course of the game.
Compare The Sims' character editing to Fallout 4's.
2) Tool-assisted assembly
The creator uses a separate tool to assemble the content. This tool may be in-game, such as a mission editor. It may be out-of-game, such as photoshop or visual studio or even just notepad. Either way, this is a thing the player has to go and do, separate from playing the game.
This is quite a hurdle. Few players will go and use a tool that is not required over the course of play. Because of this, it's usually ideal if you can leverage a tool in both the main gameplay and as an asset creator. Normally this is done by using the same tool, but having a creative mode where the player's specific play constraints are relaxed.
Done well enough, this turns into diegetic assembly.
Core/process mods are a good example of mods that are almost always created with tool assists. It is exceedingly rare for a game to allow its own rules and progressions to be overwritten in the course of play. Normally these mods are created with visual studio or notepad, the code then injected back into the game.
3) Hacked assembly
If the creator has no way to add their mod to the game, they may hack the game to force it to accept the new content.
You might consider this similar to a tool-assisted mod at first glance, but a tool-assisted assembly uses an injection method the developers intended for modders. That text you edited, that DLL you compiled, the game goes out to look in that directory for those things because the dev decided to support those kinds of mods in that way.
Hacked mods usually take advantage of things the dev accidentally left available instead of intended for mods. For example, they might be "trainers", hacking the game's memory space to give you infinite health or cash. Or they might overwrite the game's core assets with new assets.
As a game dev, hacked assembly is something to avoid. Mods assembled via hacking almost always conflict with other mods just due to how they work, so it's best to try and create a proper interface for mod injection.
---
When I think about mods, that is how I think.
What kinds of content can be injected? What kinds of tools can I use to make that injection easier, more useful, more potent?
What methods of creating content are there? What kinds of interfaces can I create to help modders create mod packs and chains of mods that don't conflict?
Unfortunately, no game engine natively supports this kind of thinking, because it's part of every individual game's unique design. There's not really any low-hanging fruit here: you have to design your game to be modded.
A lot of people are annoyed that Unity and Unreal don't make modding easy... but modding has never been "easy".
Flash, CryEngine, IdTech, RPGMaker... none of them are "moddable" right from the ground up. Modding has always been something the devs decide to include.
With that in mind, we can talk about mods in two ways. From the perspective of the person installing the mod ("player"), and from the perspective of the person making the mod ("creator").
---
From the player's perspective, there are probably three kinds of mods:
1) Piecemeal Content
This is content that will almost never conflict with other piecemeal content, except in the most trivial ways. Piecemeal content is probably the most popular kind of mod, including things like recruiting other players' characters, sharing messages about sun-praising, downloading vehicles from the workshop, adding new skins, etc.
2) Local Content
This is content which will conflict with any other content in the same locale. For example, if you install a mod to turn you into Bayonetta and a mod to turn you into Link, they won't get along. Similarly, you can't be in two levels at once, two missions at once, etc.
Local content can be turned into piecemeal content if you add a tool to help the player manage this kind of conflict - for example, Bayonetta and Link can both be "skin options" instead of simply overriding your appearance.
3) Core/Process
Some mods change fundamental rules of the game. For example, Skyrim mods that make character progression different, or change how weather works, or make you need to eat and sleep, or make the shaders work better.
Sometimes the mods are completely invisible, such as mods which allow other mods to work, or mods that clean up memory usage.
Frequently, core/process mods are part of a chain of required mods, like 'install the event mod, then the silent talking mod, then the progression revamped mod, and only then you can install the custom skill pack'.
---
The reason to think of mods like this is simple: it helps us to think about how mods work within our game. Can our game support piecemeal content additions? If the gameplay allows for certain kinds of piecemeal content, what is required to surface that and allow the players to load it in? If the game can support local content, can we change the way our game presents it to turn that into piecemeal content?
Can our gameplay support core/process mods? Can our game architecture? Can we revamp it? Can we create a tagging system so that we can have mods say what other mods they require, at what version?
The answer is rarely a flat yes. This kind of thing is a bit difficult to engineer, and it may damage your core gameplay. But even a small amount of moddability is a good thing, and you can leverage it to either make your game more appealing or make your game stickier.
For example, in Guacamelee, the only kind of moddable content is custom skins. However, they sent out custom skins to popular YouTubers, enticing them to play the game and be more positive about the experience. The modding made for great outreach.
---
The other half of the equation is how the creator of the mod thinks about the mod. This is equally important.
1) Diegetic assembly
When the creator never leaves the game to create the content. In the best case, the content is created simply by playing the game, but nearly all of the time this is an in-game editor. For example, you create your character, build your ship, assemble your house - all using an in-game editor.
The key here is that diegetic assembly happens in the course of normal play. A character builder counts because every player will use it at least once and consider it part of their playthrough, their experience. A mission editor generally doesn't count, because it's never used in the course of playing the game.
There is a challenge to keep the editor simple enough for everyone to use but powerful enough to let players create complex or nuanced results. There is also a challenge to leverage the editor: a character editor for a game where you only create one character is not as well-leveraged as a game where you create multiple characters over the course of the game.
Compare The Sims' character editing to Fallout 4's.
2) Tool-assisted assembly
The creator uses a separate tool to assemble the content. This tool may be in-game, such as a mission editor. It may be out-of-game, such as photoshop or visual studio or even just notepad. Either way, this is a thing the player has to go and do, separate from playing the game.
This is quite a hurdle. Few players will go and use a tool that is not required over the course of play. Because of this, it's usually ideal if you can leverage a tool in both the main gameplay and as an asset creator. Normally this is done by using the same tool, but having a creative mode where the player's specific play constraints are relaxed.
Done well enough, this turns into diegetic assembly.
Core/process mods are a good example of mods that are almost always created with tool assists. It is exceedingly rare for a game to allow its own rules and progressions to be overwritten in the course of play. Normally these mods are created with visual studio or notepad, the code then injected back into the game.
3) Hacked assembly
If the creator has no way to add their mod to the game, they may hack the game to force it to accept the new content.
You might consider this similar to a tool-assisted mod at first glance, but a tool-assisted assembly uses an injection method the developers intended for modders. That text you edited, that DLL you compiled, the game goes out to look in that directory for those things because the dev decided to support those kinds of mods in that way.
Hacked mods usually take advantage of things the dev accidentally left available instead of intended for mods. For example, they might be "trainers", hacking the game's memory space to give you infinite health or cash. Or they might overwrite the game's core assets with new assets.
As a game dev, hacked assembly is something to avoid. Mods assembled via hacking almost always conflict with other mods just due to how they work, so it's best to try and create a proper interface for mod injection.
---
When I think about mods, that is how I think.
What kinds of content can be injected? What kinds of tools can I use to make that injection easier, more useful, more potent?
What methods of creating content are there? What kinds of interfaces can I create to help modders create mod packs and chains of mods that don't conflict?
Unfortunately, no game engine natively supports this kind of thinking, because it's part of every individual game's unique design. There's not really any low-hanging fruit here: you have to design your game to be modded.
Wednesday, February 20, 2019
Adaptive Modules in Construction Games
One thing I like in construction games is being able to create different modes within a creation. For example, a car that can turn into a jet, or a space ship that can switch between science mode and warp speed mode.
Very few games reward this kind of thinking due to one big constraint: single-purpose, static modules.
Non-adaptive modules.
For example, if I want a space ship that can switch between science and warp speed mode, there has to be some advantage to switching rather than just being in both modes at the same time.
But the modules for science and warping are always the same size, always the same configuration, always require the same amount of power, etc, etc. The only "switching" we'll likely do is simply turning one or the other off to save power, rather than something that creates a fun visual or play impact like sliding parts around, expanding or shifting, etc.
There are a few ways to create the opportunity for players to build adaptive designs, and they all boil down to adaptive modules. Here's some types.
1) Folding modules.
If our science and warp elements can both fold down to take up less space, then we can have them share their expanding zone. To allow for more interesting results, we'll want to allow for at least some adaptiveness in the folding. Perhaps science modules come in a variety of shapes and expansion zones, while warp engines can expand arbitrary amounts, allowing us to pick and choose exactly how much space they share, when.
This can get even more complex with things like power capacitors and tanks being extended when full, etc.
The folding can also be complexly related to the flow of ship resources. Perhaps the science devices unfold and create a new control room people can walk into, meaning it has to be butted up to the pressurized section. Or maybe it has in/out fluid flow, and the position of the outlets changes as it inflates...
2) Expensive timing elements.
If our science and warp elements take quite a bit of juice, simply turning them off and on is important. But to make things feel meaty, simply turning things on and off won't work. We need timing elements.
Perhaps the computers take a little while to boot. The engines need to spool up. The science sensors require a massive influx of water to extend.
To make this really meaty, give us the option to accelerate the timing with outside resources. Computers boot faster if other computers lend it processing power. Engines spool up faster if you use a flywheel assist. Science sensors expand faster if you send them water faster.
Note that these all start up fine with no assist, it's a matter of time savings. That way, even newbies can create this stuff, no need to wire it up in a complex way to just get it working at a baseline level.
3) Incompatibilities.
If modules are incompatible, then turning them on and off is an important technique. To make this especially meaty, the incompatibility should be manageable in some way if you make your ship clever enough.
For example, the warp drive spits out a ton of radiation noise when active, rendering science sensors useless. Computers vibrate when in use, radically lowering the performance of nearby modules. Science sensors require 180hz power, while warp drives require 30hz power.
These incompatibilities mean you can't simply throw more power at your systems to have them all on at the same time. But you can design cleverly. Have an extending strut move the engine away if you need science sensors on at the same time. Have the computers on their own module off to the side of the ship. This gives a reason to create fun, unusual designs.
4) Service requirements.
Requiring human access can make your ships very interesting to design. Why is the engine on a piston rather than permanently floating way out behind the ship? Because that brings it in line with the rigging, so spacewalkers can get to it quickly and easily for maintenance purposes.
This does require you to put in some adaptive human access options. Extending ladders, cables, etc. But those also look great, so they're not a bad call!
5) Stacked modules.
It may seem obvious that every identical module should have identical requirements, but for the sake of making things meaty, the opposite is true.
If modules are stacked on top of each other in a specific way, they should have different performance stats and require subtly different resources. IE, every science sensor arranged in an exact row performs better than the last, but requires power at a higher hz, or requires more cooling.
This will allow players to stack or destack modules to fit their personal vision and constraints. One player might have five stacked science sensors and a big module for providing them with their complex support needs, while another player might have ten unstacked science sensors... requiring more people and more space, but without the complexity.
6) Careful design of multipurpose baseline elements.
Obviously there are baseline elements constraining your operational modules. The most obvious example is electricity, used in nearly every construction game. Other examples might be fluid, food, computation, etc.
Designing these carefully is the key. You want them to inspire specific layouts all on their own.
The easiest way to do that is to make categories of element, then allow a multipurpose system to handle anything within that category. This allows for the same infrastructure to serve multiple roles, while also creating bottlenecks. For example, pipes can handle water, fuel, oil, air, exhaust - anything that flows. Players can create huge numbers of dedicated pipes or fewer pipes that take up less space if they can figure out how to switch the load on the fly...
The basic approach I use is designed to make these baseline elements inspire interesting configurations.
a) Flow types: one type of module moves the generic resource around, one type collects it in a spot (often adaptively sized), one type pushes or pulls it, one type transforms or creates it. For example, pipes, tanks, pumps, intakes. Or network cables, tape archives, sensors, and computers.
This four-fold approach gives me a flexible way to drive different layouts by simply changing which elements take up space in what kinds of ways, or require which secondary resources to run. For example, there's a huge difference between tanks that can expand and tanks that can't. Similarly, there's a huge difference between pipes that take up one voxel space per pipe, as opposed to network cables, where you can bundle any number of them along the same one-voxel channel.
b) Reward both centralization and decentralization. There's beauty both in duplication and in centralization. People should be able to find a cool way to implement "a hundred pipes" approach, but also be able to implement a cool "one big pipe" approach.
In general, one big pipe is what players will tend to rely on if they're just piping lots of one resource. If every module requires water, there's going to be one big water pipe. But as the resources get more varied, the player will tend to go for multiple pipes. Whether this is different temperatures of water, or different fluids, creating converters or mode switching is overhead some players do not relish.
Having resources that vary inside themselves can be very powerful, especially if they can change state and be moved in another way.
For example, if the engine needs fuel... well, maybe each stacked engine performs better, but prefers fuel injected at a hotter temperature. Therefore, the fuel subresource varies on another axis (temperature), making wrangling it more complex without requiring any extra content. Clever players might supherheat the fuel into gas for fast transit, or even freeze it into wax for long-term storage.
Either way, this complexity should arise only as the player embraces it, since this complexity can create a difficulty cliff.
c) Allow suboptimal setups. Allowing the player to fall short while still having a decent result is critical, both for players that aren't great at construction and for players that are trying to be very clever.
An example of this might be if the science sensors require computation to run. If the player doesn't have enough, the science sensors continue to function, but at a reduced rate. Even at zero computation, the science sensors should still function a bit.
You can make this more complex by creating pseudogenerics. For example, the science sensors require quantum computing. Any kind of computer can generate quantum computing, but at less than half speed if they aren't quantum computers. This allows players to use somewhat unsuitable setups in a fun way.
Similarly, you might have pumps specialized in fluids... but they can pump gases a bit. Or visa-versa.
Combining these elements means the players have a ton of flexibility. It also makes for the opportunity for them to add complexity by creating switching systems to use the proper pumps/computers when required, while reusing the same generic flow containers (pipes/wires).
Allowing for extremely high-performance single-use elements is fun as well, but make sure they have other constraints. IE, the fuel-only pump requires tremendous cooling...
... anyway, them's my thoughts on the matter.
Very few games reward this kind of thinking due to one big constraint: single-purpose, static modules.
Non-adaptive modules.
For example, if I want a space ship that can switch between science and warp speed mode, there has to be some advantage to switching rather than just being in both modes at the same time.
But the modules for science and warping are always the same size, always the same configuration, always require the same amount of power, etc, etc. The only "switching" we'll likely do is simply turning one or the other off to save power, rather than something that creates a fun visual or play impact like sliding parts around, expanding or shifting, etc.
There are a few ways to create the opportunity for players to build adaptive designs, and they all boil down to adaptive modules. Here's some types.
1) Folding modules.
If our science and warp elements can both fold down to take up less space, then we can have them share their expanding zone. To allow for more interesting results, we'll want to allow for at least some adaptiveness in the folding. Perhaps science modules come in a variety of shapes and expansion zones, while warp engines can expand arbitrary amounts, allowing us to pick and choose exactly how much space they share, when.
This can get even more complex with things like power capacitors and tanks being extended when full, etc.
The folding can also be complexly related to the flow of ship resources. Perhaps the science devices unfold and create a new control room people can walk into, meaning it has to be butted up to the pressurized section. Or maybe it has in/out fluid flow, and the position of the outlets changes as it inflates...
2) Expensive timing elements.
If our science and warp elements take quite a bit of juice, simply turning them off and on is important. But to make things feel meaty, simply turning things on and off won't work. We need timing elements.
Perhaps the computers take a little while to boot. The engines need to spool up. The science sensors require a massive influx of water to extend.
To make this really meaty, give us the option to accelerate the timing with outside resources. Computers boot faster if other computers lend it processing power. Engines spool up faster if you use a flywheel assist. Science sensors expand faster if you send them water faster.
Note that these all start up fine with no assist, it's a matter of time savings. That way, even newbies can create this stuff, no need to wire it up in a complex way to just get it working at a baseline level.
3) Incompatibilities.
If modules are incompatible, then turning them on and off is an important technique. To make this especially meaty, the incompatibility should be manageable in some way if you make your ship clever enough.
For example, the warp drive spits out a ton of radiation noise when active, rendering science sensors useless. Computers vibrate when in use, radically lowering the performance of nearby modules. Science sensors require 180hz power, while warp drives require 30hz power.
These incompatibilities mean you can't simply throw more power at your systems to have them all on at the same time. But you can design cleverly. Have an extending strut move the engine away if you need science sensors on at the same time. Have the computers on their own module off to the side of the ship. This gives a reason to create fun, unusual designs.
4) Service requirements.
Requiring human access can make your ships very interesting to design. Why is the engine on a piston rather than permanently floating way out behind the ship? Because that brings it in line with the rigging, so spacewalkers can get to it quickly and easily for maintenance purposes.
This does require you to put in some adaptive human access options. Extending ladders, cables, etc. But those also look great, so they're not a bad call!
5) Stacked modules.
It may seem obvious that every identical module should have identical requirements, but for the sake of making things meaty, the opposite is true.
If modules are stacked on top of each other in a specific way, they should have different performance stats and require subtly different resources. IE, every science sensor arranged in an exact row performs better than the last, but requires power at a higher hz, or requires more cooling.
This will allow players to stack or destack modules to fit their personal vision and constraints. One player might have five stacked science sensors and a big module for providing them with their complex support needs, while another player might have ten unstacked science sensors... requiring more people and more space, but without the complexity.
6) Careful design of multipurpose baseline elements.
Obviously there are baseline elements constraining your operational modules. The most obvious example is electricity, used in nearly every construction game. Other examples might be fluid, food, computation, etc.
Designing these carefully is the key. You want them to inspire specific layouts all on their own.
The easiest way to do that is to make categories of element, then allow a multipurpose system to handle anything within that category. This allows for the same infrastructure to serve multiple roles, while also creating bottlenecks. For example, pipes can handle water, fuel, oil, air, exhaust - anything that flows. Players can create huge numbers of dedicated pipes or fewer pipes that take up less space if they can figure out how to switch the load on the fly...
The basic approach I use is designed to make these baseline elements inspire interesting configurations.
a) Flow types: one type of module moves the generic resource around, one type collects it in a spot (often adaptively sized), one type pushes or pulls it, one type transforms or creates it. For example, pipes, tanks, pumps, intakes. Or network cables, tape archives, sensors, and computers.
This four-fold approach gives me a flexible way to drive different layouts by simply changing which elements take up space in what kinds of ways, or require which secondary resources to run. For example, there's a huge difference between tanks that can expand and tanks that can't. Similarly, there's a huge difference between pipes that take up one voxel space per pipe, as opposed to network cables, where you can bundle any number of them along the same one-voxel channel.
b) Reward both centralization and decentralization. There's beauty both in duplication and in centralization. People should be able to find a cool way to implement "a hundred pipes" approach, but also be able to implement a cool "one big pipe" approach.
In general, one big pipe is what players will tend to rely on if they're just piping lots of one resource. If every module requires water, there's going to be one big water pipe. But as the resources get more varied, the player will tend to go for multiple pipes. Whether this is different temperatures of water, or different fluids, creating converters or mode switching is overhead some players do not relish.
Having resources that vary inside themselves can be very powerful, especially if they can change state and be moved in another way.
For example, if the engine needs fuel... well, maybe each stacked engine performs better, but prefers fuel injected at a hotter temperature. Therefore, the fuel subresource varies on another axis (temperature), making wrangling it more complex without requiring any extra content. Clever players might supherheat the fuel into gas for fast transit, or even freeze it into wax for long-term storage.
Either way, this complexity should arise only as the player embraces it, since this complexity can create a difficulty cliff.
c) Allow suboptimal setups. Allowing the player to fall short while still having a decent result is critical, both for players that aren't great at construction and for players that are trying to be very clever.
An example of this might be if the science sensors require computation to run. If the player doesn't have enough, the science sensors continue to function, but at a reduced rate. Even at zero computation, the science sensors should still function a bit.
You can make this more complex by creating pseudogenerics. For example, the science sensors require quantum computing. Any kind of computer can generate quantum computing, but at less than half speed if they aren't quantum computers. This allows players to use somewhat unsuitable setups in a fun way.
Similarly, you might have pumps specialized in fluids... but they can pump gases a bit. Or visa-versa.
Combining these elements means the players have a ton of flexibility. It also makes for the opportunity for them to add complexity by creating switching systems to use the proper pumps/computers when required, while reusing the same generic flow containers (pipes/wires).
Allowing for extremely high-performance single-use elements is fun as well, but make sure they have other constraints. IE, the fuel-only pump requires tremendous cooling...
... anyway, them's my thoughts on the matter.
Subscribe to:
Posts (Atom)