Now that a few months have passed and I've rewatched the new Star Wars movie, it's time for a critique! I know this will have a widespread, profound effect on its sales and box office performance, so I had to think about it for a while.
My hatred of JJ Abrams is pretty well-known, and in the end that's going to be a huge shadow across this review. I have no respect for him as anything other than a very limited action director, even when backed up by seriously skilled heavy hitters. But let's talk about the movie.
First off, the movie is pretty decent. Better than the prequels by a long shot. Probably my third favorite Star Wars movie, and that's not bad at all.
It has very charming characters, most of whom are excellent actors. I love the newfound diversity, it makes the universe feel even bigger. I love the artful blend of CG and practical effects. Several of the sets are extremely nice, the props are all top-notch. The music and sound effects, of course, couldn't be much better. And the comedy bits are often in service of the characters, which is rare and very welcome.
Now, let's talk about the crappy parts!
I went with a group of 9 people to see it in theaters, ages 7 - 65. Several of them had seen it before. And we all came out of it confused and dissatisfied by the same elements. Some of us liked it, some of us hated it, but we all went "what the heck was up with that?" about the same things.
A big example was the tie fighter crash - you know, with Poe's coat. All of us were annoyed by that whole sequence.
But upon watching it again on DVD, I found the explanation was clearly written into the script, probably even shot correctly. It was just slapped up for a mere half-second and attention drawn away from it. Upon watching it knowing what to look for, it's clear that Poe takes off his coat, hangs it on his seat. It's clear Finn is ejected, so Poe obviously could have been, too. It's clear Finn finds the coat on the front canopy, not near the rear of the ship where Poe was seated, so it must have shaken free from the seat before it ejected.
The explosion still makes no sense, but let's just let that action schlock slide.
All of those elements are just fine on the written page. You can see the writers saying "THIS is how we'll give Finn that coat". Unfortunately, those elements weren't given to the audience on the screen. Even the parts that were on the screen, such as Poe taking off his coat, were not lingered on or highlighted. Instead, they were background elements in clips where the focus was clearly elsewhere, and even those clips were really tightly clipped.
This is how a magician does things - distract the audience with one hand while doing something with another. Unfortunately, if you do that in a movie, you end up with an audience that never knows you did the second thing and presumes you just have a basket full of continuity errors.
There are several elegantly written arcs in the movie, that one included. But half of the things on the screen are choppy and slapdash, badly paced and unpolished, like someone was in a hurry to slap more action on the screen.
For example, the double-defection of Finn and Rey, where they both have the exact same "I'm scared and gonna run away" arcs separately, within the same minute. This is a very badly paced element, and I can only presume that's not how it was originally written. Perhaps there was more time between them, or perhaps it was written so that Rey felt lost and betrayed by Finn and that was given time to grow on the screen to seed her own fear. Perhaps there were two scripts written, each with one of the characters panicking, and then for some reason both arcs were filmed and smashed together.
Another example: the murder of Han Solo. This is an amazing scene to most RPG players, because that's how a really good dark side arc in a game would go. It's completely legit, very powerful, especially the "thank you". It makes sense narratively and within the rules of the universe, as well as fitting in with every character.
Unfortunately, what we actually got on the screen wasn't so good.
"They're on your father's ship. You know, Han Solo, your dad?" "Yes, my father, Han Solo." "He's your dad." "Oh gosh, Evil McEvil noticed I still have good in me, gramps!" "Our son is up there, Leia!" "Our son, Kylo?" "Our son Kylo, Leia." "Grandpappy, help me, you're my grandpap." "He has good in him!" "Who, our son, Kylo?" "Kylo, yes, our son." "My dad landed on the planet." "Your dad Han?" "Han, my dad." "Oh, that dad." "Gramps, give me strength!" "Hello, Kylo my son. You still have good in you!"
I have a feeling that the writers knew half their scenes wouldn't get to the screen, so they just wrote twice as many and crossed their fingers.
I get that feeling a lot, actually. Because this movie has two plots, and they are both pretty sad.
In one plot, a bigger, badder Death Star sits on its butt in the middle of nowhere waiting to be found. In the other plot, a bigger, badder Luke sits on his butt in the middle of nowhere waiting to be found. Both are full of plot holes and neither is even vaguely compelling or personal.
It's clear the "bigger Death Star" plot exists because Disney wanted to prove they were oldschool Star Wars fans who were going to make oldschool Star Wars movies. But it's also clear that they thought that plot was pretty threadbare, so they stole a plot from a different draft and shoved it alongside.
I think either of these plots could have been made hundreds of times better without much trouble by simply choosing one. If either had more screentime, the glaring holes could have been explained away. Instead, they're pushed past with action sequences in a desperate attempt to gloss over everything.
The third plot - big baddie that runs everything - is established as a next-movie thing, but it also looks extremely uninteresting. I've already covered all the ways they could have made that interesting in an earlier essay. For example, it could be a holocron. That'd be amazing: all the Sith are gone, it's just one dumb kid with delusions and a holocron, but the dark side still manages to be a threat.
Any way you cut it, the movie could have been a lot tighter with different priorities. The inclusion of clips like "whoo, damn that pilot is good!" and the exclusion of clips like explaining why they had the last 2/3 of the map on a galaxy view but still needed the first 1/3 means that the whole thing feels very schlocky, as if the only thing that really matters are the action setpieces and a few pieces of comedy for pacing.
I have to wonder. The editing seems pretty tight, so why are there so many clips and sequences that don't seem like they fit right? Why is there such a laser focus on stuff that would have been great either way, while letting stuff that could have been great lay as unpolished stumbling blocks? Is this because of the director? It sounds like it might be the fault of the editors.
The editors Mary Jo Markey and Maryann Brandon, JJ Abrams' primary editors for almost all his films.
I hate JJ Abrams.
Monday, July 25, 2016
Sunday, July 10, 2016
Games Writing: Thematic Elements and Motifs
So, I've been playing a lot of games that get a lot of press. Most recently, I played Metal Gear Solid Five.
This essay's gonna be full of spoilers for it.
If you've ever taken lessons on writing books or movies, you've probably learned about themes and motifs. These repeating elements bind your work together and make it ring. Done well, they lead the audience straight into your premise and bind them to it before they've even noticed.
In video games, these are even more important. Not only are they more effective, but they are also more easily applied than other writing elements since they can be worked into any part of the game, including both cut scenes and raw gameplay.
Let's talk concrete a bit. Let's do some MGSV spoiling!
One of the motifs of MGSV is the idea of being ripped apart but having to live on. Missing limbs, missing voices, missing pasts, missing futures. This motif is so prevalent it's literally the title of the game: "The Phantom Pain" refers to the main character's missing arm and, through it, all of the other linked elements in the motif.
The motif isn't used as well as it could be. It's really only brought up right at the beginning and then again in Skull Face's final scenes. It could have been a lot stronger by linking it into the many times pain or loss is brought up. The child soldiers lost their families and that pain pushed them into a life of murder and violence... why not frame it as a lingering pain? Why not link it to Big Boss's missing arm with a simple camera pan?
These seem like small things, but they really aren't. Having good motifs and themes will make your story resonate for a lot longer. Like a trumpet, you need to have a funnel of themes for the player to breathe through, and then the note will ring out loud and clear.
I kept playing MGSV in hope that they would pull it together, but they never did. Kojima was, as usual, focused almost entirely on flash and glamour instead of the underlying power of the story. In the end, the plot was a muddled mess.
How could themes have helped? How could motifs have brought it together? What was wrong with the writing in what most people consider a gem of a game?
Well, let's consider the revenge element. This is a theme that rings pretty clear, it's brought up a lot. I don't consider it very convincing, though: there was never really any time I felt "in tune" with the main cast's lust for vengeance.
That could have been helped by some pretty subtle changes to the game itself. For example, instead of the utterly useless chicken hat that they keep trying to force onto you when you fail a mission, they could have marked your murderer and made it very hard for him, in particular, to spot you. And it could stack - if you are killed by 10 different people in this level, 10 people are now a bit blind.
This would be more universally useful than the chicken hat, but it would also push the player towards taking vengeance. Not only are they angry at the jerk that murdered them, they know that person is now weaker and open to retribution... or at least open to being snuck past.
There are a lot of other vengeance-related gameplay things you could have done - for example, causing me to actually lose any of the NPCs I cared about would have worked. But that doesn't happen until the heart of the vengeance arc is complete.
There's no doubt that the vengeance arc is the strongest arc in the game. The intention with this theme is to show that everyone's actions descend from a deep rage, a lust for vengeance. It could have been addressed clearer, but the basic idea is extremely solid.
And it has an extremely powerful ending. Themes and motifs are intense, and can be used to build up a finale that leaves a hell of an impact. If you do it right, people will remember your story for decades. It'll stay in their head.
In MGSV, the vengeance arc comes to a head with the death of Skull Face. Injured and trapped by debris, Skull Face is at the mercy of the two main characters, both of whom have lost limbs to his schemes. Instead of killing him, they blow those limbs off of him, then tell him to kill himself if he wants, and walk away.
It's a hard-to-watch scene and a dark note, but then the stupid engineer nobody likes simply goes over and shoots him. Then goes "yay! I got vengeance!"
This would have been the perfect ending, if it had been paced a little better. Two people obsessed with their deep, decade-long fury set up their brutal plan for vengeance... and then some little shit with a small, recent grudge ruins it to take vengeance himself.
That could have been perfect, turning the whole concept of vengeance into a sour note, a farce. It would have been subtle, understated, and heavy. Like a trumpet, one of the best ways to use a theme in the end is to have it ring hollow.
But that's not what MGSV does. It doesn't pace it right, it doesn't hit it cleanly, and then it immediately sweeps away to a long set of interminable speeches that have almost nothing to do with vengeance. Even if they were about vengeance, they're filling a gap - a hollow, ringing space that needs to remain empty. The trumpet turns into a whimper when you fill the bell with glitter.
You can argue that the "real ending" of MGSV is better and not flubbed, but just as an example, this is how you would have turned the vengeance theme into a powerful ending.
The difficulty is that you really have to trust that empty space. The themes and motifs don't need your help, they need space. The player has to have time to digest it and let it grow. But once it does, it will stay with them forever.
Bioshock Infinite is another example of a badly flubbed ending, but in BI's case it was all done subconsciously. Say what I like about Kojima's lack of depth, he at least uses his themes consciously. Levine does not.
As I was playing BI and getting steadily more annoyed, I started to suspect the themes were used consciously, and the touch was just incredibly subtle. Of course, that wasn't the case, and BI's plot ended up being trash.
What themes?
It's clear that BI was written by dads, and the trashy plot progression seemed to be leading to one hell of a powerful ending: DeWitt had to learn to let his daughter go, let her be her own person, maybe even kill himself to save her from his own endless meddling.
All of the game's muddy and backtracky plot elements - all the racism, all the sexism, all the old friends you have to kill, the other me, the past me, the future me, the alternate daughters that have all suffered at my hands - all of that would suddenly shine and shout if it turns out that the problem is just me. It's all... me fucking it up. Me judging it by my own biases. Me acting to protect and control, only to end up poisoning everything because my grip is too damn tight.
I know some people liked the faux-philosophical ending of BI, and I won't say you're a bad person for it, but it doesn't hook into the themes and motifs set up during the play. And the reason is because Levine didn't realize he was including themes of being an oppressive daddy figure. He just... is one. It bled in naturally, mixed with the natural juices of murderous first-person gameplay, and turned into a truly noxious mix.
It doesn't cost anything to get an ending right. It's actually cheaper, because you don't need another fifteen minutes of pomp and glitter. Just a slow pan across a scene you already built.
But it takes an enormous amount of trust in yourself, in your writing, in your editing. It takes a lot of convincing to tell yourself "the game should just... end here. I don't need to make a long speech. I don't need to set up the next game. I don't need to do anything. I can just... hold here for ten seconds and roll credits."
There are plenty of movies and books that do just that. For example, Fight Club. Fight club's ending is probably still in your head. You probably remember it even now, the self-inflicted gunshot, the burning city.
But in games it's super rare. Games are too nervous to let things sit, to let things ring on their own. Devs want to fill that space, and in the end it just muddies things up and leaves the endings tasting of sawdust.
What's the last game ENDING you remember?
I bet you remember a lot of middles! But the endings?
...
Anyway, this essay was just written immediately before bed, no editing. I hope you enjoyed it anyway, let me know what you think.
This essay's gonna be full of spoilers for it.
If you've ever taken lessons on writing books or movies, you've probably learned about themes and motifs. These repeating elements bind your work together and make it ring. Done well, they lead the audience straight into your premise and bind them to it before they've even noticed.
In video games, these are even more important. Not only are they more effective, but they are also more easily applied than other writing elements since they can be worked into any part of the game, including both cut scenes and raw gameplay.
Let's talk concrete a bit. Let's do some MGSV spoiling!
One of the motifs of MGSV is the idea of being ripped apart but having to live on. Missing limbs, missing voices, missing pasts, missing futures. This motif is so prevalent it's literally the title of the game: "The Phantom Pain" refers to the main character's missing arm and, through it, all of the other linked elements in the motif.
The motif isn't used as well as it could be. It's really only brought up right at the beginning and then again in Skull Face's final scenes. It could have been a lot stronger by linking it into the many times pain or loss is brought up. The child soldiers lost their families and that pain pushed them into a life of murder and violence... why not frame it as a lingering pain? Why not link it to Big Boss's missing arm with a simple camera pan?
These seem like small things, but they really aren't. Having good motifs and themes will make your story resonate for a lot longer. Like a trumpet, you need to have a funnel of themes for the player to breathe through, and then the note will ring out loud and clear.
I kept playing MGSV in hope that they would pull it together, but they never did. Kojima was, as usual, focused almost entirely on flash and glamour instead of the underlying power of the story. In the end, the plot was a muddled mess.
How could themes have helped? How could motifs have brought it together? What was wrong with the writing in what most people consider a gem of a game?
Well, let's consider the revenge element. This is a theme that rings pretty clear, it's brought up a lot. I don't consider it very convincing, though: there was never really any time I felt "in tune" with the main cast's lust for vengeance.
That could have been helped by some pretty subtle changes to the game itself. For example, instead of the utterly useless chicken hat that they keep trying to force onto you when you fail a mission, they could have marked your murderer and made it very hard for him, in particular, to spot you. And it could stack - if you are killed by 10 different people in this level, 10 people are now a bit blind.
This would be more universally useful than the chicken hat, but it would also push the player towards taking vengeance. Not only are they angry at the jerk that murdered them, they know that person is now weaker and open to retribution... or at least open to being snuck past.
There are a lot of other vengeance-related gameplay things you could have done - for example, causing me to actually lose any of the NPCs I cared about would have worked. But that doesn't happen until the heart of the vengeance arc is complete.
There's no doubt that the vengeance arc is the strongest arc in the game. The intention with this theme is to show that everyone's actions descend from a deep rage, a lust for vengeance. It could have been addressed clearer, but the basic idea is extremely solid.
And it has an extremely powerful ending. Themes and motifs are intense, and can be used to build up a finale that leaves a hell of an impact. If you do it right, people will remember your story for decades. It'll stay in their head.
In MGSV, the vengeance arc comes to a head with the death of Skull Face. Injured and trapped by debris, Skull Face is at the mercy of the two main characters, both of whom have lost limbs to his schemes. Instead of killing him, they blow those limbs off of him, then tell him to kill himself if he wants, and walk away.
It's a hard-to-watch scene and a dark note, but then the stupid engineer nobody likes simply goes over and shoots him. Then goes "yay! I got vengeance!"
This would have been the perfect ending, if it had been paced a little better. Two people obsessed with their deep, decade-long fury set up their brutal plan for vengeance... and then some little shit with a small, recent grudge ruins it to take vengeance himself.
That could have been perfect, turning the whole concept of vengeance into a sour note, a farce. It would have been subtle, understated, and heavy. Like a trumpet, one of the best ways to use a theme in the end is to have it ring hollow.
But that's not what MGSV does. It doesn't pace it right, it doesn't hit it cleanly, and then it immediately sweeps away to a long set of interminable speeches that have almost nothing to do with vengeance. Even if they were about vengeance, they're filling a gap - a hollow, ringing space that needs to remain empty. The trumpet turns into a whimper when you fill the bell with glitter.
You can argue that the "real ending" of MGSV is better and not flubbed, but just as an example, this is how you would have turned the vengeance theme into a powerful ending.
The difficulty is that you really have to trust that empty space. The themes and motifs don't need your help, they need space. The player has to have time to digest it and let it grow. But once it does, it will stay with them forever.
Bioshock Infinite is another example of a badly flubbed ending, but in BI's case it was all done subconsciously. Say what I like about Kojima's lack of depth, he at least uses his themes consciously. Levine does not.
As I was playing BI and getting steadily more annoyed, I started to suspect the themes were used consciously, and the touch was just incredibly subtle. Of course, that wasn't the case, and BI's plot ended up being trash.
What themes?
It's clear that BI was written by dads, and the trashy plot progression seemed to be leading to one hell of a powerful ending: DeWitt had to learn to let his daughter go, let her be her own person, maybe even kill himself to save her from his own endless meddling.
All of the game's muddy and backtracky plot elements - all the racism, all the sexism, all the old friends you have to kill, the other me, the past me, the future me, the alternate daughters that have all suffered at my hands - all of that would suddenly shine and shout if it turns out that the problem is just me. It's all... me fucking it up. Me judging it by my own biases. Me acting to protect and control, only to end up poisoning everything because my grip is too damn tight.
I know some people liked the faux-philosophical ending of BI, and I won't say you're a bad person for it, but it doesn't hook into the themes and motifs set up during the play. And the reason is because Levine didn't realize he was including themes of being an oppressive daddy figure. He just... is one. It bled in naturally, mixed with the natural juices of murderous first-person gameplay, and turned into a truly noxious mix.
It doesn't cost anything to get an ending right. It's actually cheaper, because you don't need another fifteen minutes of pomp and glitter. Just a slow pan across a scene you already built.
But it takes an enormous amount of trust in yourself, in your writing, in your editing. It takes a lot of convincing to tell yourself "the game should just... end here. I don't need to make a long speech. I don't need to set up the next game. I don't need to do anything. I can just... hold here for ten seconds and roll credits."
There are plenty of movies and books that do just that. For example, Fight Club. Fight club's ending is probably still in your head. You probably remember it even now, the self-inflicted gunshot, the burning city.
But in games it's super rare. Games are too nervous to let things sit, to let things ring on their own. Devs want to fill that space, and in the end it just muddies things up and leaves the endings tasting of sawdust.
What's the last game ENDING you remember?
I bet you remember a lot of middles! But the endings?
...
Anyway, this essay was just written immediately before bed, no editing. I hope you enjoyed it anyway, let me know what you think.
Wednesday, July 06, 2016
!ScriptableObject
Recently, a lot of people have been referencing Richard Fine's video on ScriptableObjects. I'm gonna go ahead and rebut it.
A few details: I loved ScriptableObjects. I made videos about how to use them. I certainly don't dislike Richard Fine, I think he does pretty solid work. But I think his obsession with ScriptableObjects is really muddying waters, and his video is misleading.
Things have changed in the prefab world.
Used to be that if you wanted something shared everywhere, you used ScriptableObjects. No matter the scene, no matter the situation, references to that ScriptableObject would point to the asset in the project, and one change would change it everywhere.
However, in the past few years, prefabs have grown a lot of muscle. It's easy to overlook, because prefabs wear baggy clothes, but now you can (and should) use prefabs for many of the things he recommends using ScriptableObjects for.
(And for the rest, you should use a real database.)
You can reference uninstantiated MonoBehaviours now. You can read their values, call their functions, trigger their events - all without instantiating. What does this mean?
It means that everything ScriptableObjects used to be good for, MonoBehaviours can do... and can unlock much more powerful patterns than ScriptableObjects tend to allow. Unity was built around the concept of prefabs and MonoBehaviours, and now we can merge that power with prefab referencing.
Let me describe the patterns I'm using in The Galactic Line. These are MonoBehaviours-with-muscly-prefabs patterns.
The Magic Mixin
I have a lot of space ship parts. I don't like instantiating them, because they're heavy: they have LODed visuals, sound clips, lights, lots of stuff that I want to leave on the cutting room floor if the ship is too far away to see... but I still want to simulate the ships. Hundreds of ships you can't see, still being simulated as their resources drain away and their mission timers tick up.
Ships are easy enough to simulate, but you need each of their parts to tell you what it does as time passes. What does this reactor do? It drains water and creates power. It drains antimatter and creates power, heat, and radiation. It's pressurized. It's not pressurized. It has these external visuals and collision meshes, these internal visuals and collision meshes. It makes these sounds in these situations. It has beds in it for some reason. Or maybe not.
When I get close, these parts resolve into a GameObject. They have to, because we have to see them and hear them in the scene. I could bend over backwards to avoid making a prefab... but why? It makes sense to make it a prefab, that's what prefabs are for.
The problem is that I want to access all that juicy functional stuff without instantiating the part.
I could make all of them ScriptableObjects, but then we have a staggering number of floating loose ends. A radiation-production ScriptableObject saved off in some other directory, values specific to this reactor. It makes more sense to have a radiation-production MonoBehaviour and stick it onto the part. I can just customize it right there, no need to have dangling assets. That's what the GameObject is for.
And I can access all of that directly, without instantiating anything. If I want to know how much power this reactor creates and how fast it guzzles fuel, I just ask it. If I want to know if it's air-tight, I just ask it if it has an air-tight mixin. If I want to know what its UI thumbnail is, I just ask it. Want to know what sounds it makes? Just ask. I need to simulate ten weeks of warp travel? Just ask it for those values and multiply by ten weeks.
I can load everything I need onto the part prefab. It doesn't matter how complex the part is. It doesn't matter whether it involves nested objects or flat mixins. Modders can clone and alter the part, and it won't screw up the default because the values are per-prefab.
In addition to being super easy to take care of and keep track of, I can then just drop it into the scene. Whether it's in play mode or edit mode, I can drop it into the scene and it will instantly be the thing it is. I can mount in anything I want, visually. LOD? Or not. Lighting or not. Hell, additional cameras displaying to holographic monitors? Sure. Sounds that play differently depending on how much the generator is being taxed? Why not!
In this way, anyone can create ship components, drop on the relevant mixins (such as "Reactor" and "PressurizedSpace"), save it. They know what they'll get, and the game engine automatically optimizes to prevent any bloat. Advanced users can hook UnityEvents up to create nice triggers and visuals, or even create new scripts. Just drop 'em in. No loose ends, no complicated dependencies.
Now, if the thought of a largely undifferentiated ball of objects makes you cringe... this method of creating and saving content is a fundamental in Unity. This is how Unity is engineered to work, and this is how it works most easily.
You can engineer around it, but why? Use the engine in the way it's meant to be used, and you'll have a much easier time of it.
The Meta-Instantiator
My ships have a lot to keep track of, but I don't instantiate any of the parts if I can get away with this. This means I can have a fleet of Star Destroyers, each containing thousands of crew members, and from the perspective of the game it's just a bit of data that gets processed whenever it needs to be.
The ship has a link to the blueprint prefab for the ship class, which in turn contains all the ship parts. If I instantiate that blueprint, I get a nice, shiny ship full of visuals and noises and stuff.
But I don't have to instantiate it. Instead, I crawl through the parts compiling a list of all the resources and potential mission parameters and that jazz. A small algorithm calculates out the next "keyframe" in the ship's future - when the mission completes, when resources get dangerously low, when it reaches its destination, etc.
The universe sim trickles forward at whatever pace the player wants, and when the in-universe time hits that keyframe, we crawl through the ship again to find the new situation and calculate out the next keyframe. This simple method allows us to have thousands of Star Destroyers without any slowdown at all. No per-frame update, we don't even really need an in-scene object to represent them. (And, since they're probably 500 light years away, that's good.)
Well, we get close to a fleet of Star Destroyers, and therefore the ones nearby start getting instantiated into the game world. The player accidentally rams one, breaking one of those big engines. An NPC commander is generated and yells at the player.
Oh no, this is awful! How do we remember things like a specific engine being broken, or a specific commander existing? We're just referencing a blueprint!
... just save the instance as a custom ship.
Since the blueprint contains a reference to its prefab and each component contains a reference to its own prefab, we can do whatever we want. We can easily save this "baked" blueprint, and then compare its stats to the changes in the definitions of things like engines and reactors. We could even just save the one damaged component, and leave the rest as references.
We can also generate a mission to repair the ship, and when the mission completes, we can delete the custom blueprint and restore it to an ordinary blueprint reference. We could also save the commander - either as part of this ship or separately, as we prefer.
Unlike a ScriptableObject, a prefab can easily be cloned, compared, reloaded, partially cloned, merged, instantiated piecemeal...
The Monster's Database
If you're a fan of ScriptableObjects, hopefully by now you're thinking "well for your specific application, sure, but IN GENERAL-"
Most of the uses of ScriptableObjects are as data objects. The big advantage is that there's no extra stuff.
For example, I have a list of various factions and species. If each was a MonoBehaviour, I could drag it onto a property on another class in the same way as I could do with a ScriptableObject - it'd automatically resolve the reference to the prefab as a reference to the specific MonoBehaviour on the prefab. It'd behave exactly like a ScriptableObject, but it'd have a GameObject lurking in the background being... nonoptimal.
I mean, why would you ever instantiate a whole faction, right? Just drag it into the scene? You'd never need that, so it's just junk stapled onto my data class!
I could argue that it allows for mixins, but we already did that. Let's argue for something else.
Before that level of garbage starts to get noticeable, we run into another problem: managing hundreds of ScriptableObjects is just as obnoxious as managing hundreds of prefabs.
There's a reason why GameMaker and RPGMaker use databases for this kind of thing: databases are a really great way to handle it. You could manipulate the editor to create a pseudo-database front end for your ScriptableObjects (or your prefabs), but... JUST MAKE A DATABASE. It's faster, less overhead, and can be easily exported and imported from Excel or an HTML form or whatever.
The big problem with databases is that it's hard to drag a specific entry into a field in the inspector. I don't know the best solution for this, right now I'm using an editor trick to fake it, but it's not very good.
In the end, my thoughts are simple: if you have dozens of entries, you probably need a database. If you have only a few, the extra garbage of having a GameObject attached isn't enough to worry me, and you can usually leverage mixins to add a lot of extra functionality on the cheap.
The Custom Prefab
My argument is simple: the prefab is now more powerful than the ScriptableObject.
In the video above, Richard Fine creates a ScriptableObject to handle playing custom explosion sounds. This is the part of the video that upsets me the most, because it's a magic handwave that hides the fact that it does nothing useful at all.
There's no reason to have a ScriptableObject "ShellExplode" floating around separately from the shell prefab that's going to explode. Just put it on the goddamn shell. Even the "play mode editing" would work the same way, because you're editing the prefab and it gets instantiated every time you hit shoot!
And, of course, now you just have A Shell Object instead of a shell object and some random dangling object in another directory that may or may not be referenced correctly. Moreover, you can easily clone the shell prefab and create your Big Boss Shell and your Tracer Shell and your Rocket Shell, tweak away!
It's not magic, it's the way Unity is built to work best.
The idea that a prefab is somehow "fragile" is not true any more. The classic example of a ScriptableObject is that if you have ten monsters, they can all have the same stats and you'll never "accidentally" edit just one monster to have different values.
If you have a lot of monsters, you'll probably be using a monster spawner that references a prefab, rather than hardcoding every monster. Even if you do hand-place each monster, changes to the prefab automatically update instances, as long as the instance's values haven't been manually altered. This works per property.
So, for example, if I have ten orcs and I want one of them to have extra HP, I can increase the HP. And I change his AI role to "leader". And I add a potion to his inventory. And I put a hat on him. Later, I change the orc prefab's damage from 4 to 6. The orc I modified will have his damage correctly updated, while still keeping his hat and potion and HP and AI role!
Sure, it's possible to accidentally change a value and not realize it, but that seems inconsequential compared to the overhead of needing a new, permanent asset file in your project directories for every slightly tweaked monster.
That's the point of Unity. The point of Unity's entire approach is that you can tweak things in scene view! Using ScriptableObjects to "work around" that is like "working around" the game of basketball by taking out the ball. Yeah, you could probably come up with something, but it's not going to be a very effective use of your basketball pros or your basketball courts!
Use Interfaces and Delegates
I've seen a few other arguments for ScriptableObjects - for example, externalizing coroutines so you can plug them in willy-nilly, or using delegates bound up in ScriptableObjects to do things like flexible AI processing.
Just... uh... just use C#.
Not to sound elitist, but C# has delegates and interfaces already. Use them. Don't find an excuse to wrap them in ScriptableObjects, just mainline the stuff.
Unity's support for these in the inspector view is kinda crappy, which is the big argument against it. Fortunately, you can use UnityEvents instead of delegates, and those do show up in the inspector fine.
Interfaces are similarly inspector-unfriendly, but they're very powerful and useful and don't limit you to either a ScriptableObject or a MonoBehaviour - you can use either, or even a raw C# class, or have instances of all three for different applications that are referenced from a single system!
Personally, I think using MonoBehaviour mixins as implementations of interfaces is really underestimated, but that's another topic entirely.
Use ScriptableObjects
Am I arguing that ScriptableObjects are useless?
No, not at all. They are more optimal than prefabs, so if it occurs to you to use them, you should use them. They're especially nice when it comes to instantiating them outside of the scene, or moving references between clients.
Fundamentally, ScriptableObjects are classes. That is, you've written lines of code. I generally suggest using them when you can write less code by using them, and I tend to find that means situations where I need to create and track arbitrary references and complex data.
I've stored options menu defaults in ScriptableObjects, level code, galaxy definitions...
But, in the end, I've never found them to be much earthshakingly better than either using prefabs or raw data. So I only use them when I'm in the mood to optimize.
ScriptableObjects CAN do a lot of things, but that's because they're a C# class. They're not substantially better at those things than either a MonoBehavior or a C# class. Any optimization you can get by using them is marginal, and they don't offer any particularly astounding new patterns or workflow.
I'm not against using them. I just don't want people to think they can do these amazing things... without ever realizing that simple prefabs can already do those things, and many other things at the same time.
A few details: I loved ScriptableObjects. I made videos about how to use them. I certainly don't dislike Richard Fine, I think he does pretty solid work. But I think his obsession with ScriptableObjects is really muddying waters, and his video is misleading.
Things have changed in the prefab world.
Used to be that if you wanted something shared everywhere, you used ScriptableObjects. No matter the scene, no matter the situation, references to that ScriptableObject would point to the asset in the project, and one change would change it everywhere.
However, in the past few years, prefabs have grown a lot of muscle. It's easy to overlook, because prefabs wear baggy clothes, but now you can (and should) use prefabs for many of the things he recommends using ScriptableObjects for.
(And for the rest, you should use a real database.)
You can reference uninstantiated MonoBehaviours now. You can read their values, call their functions, trigger their events - all without instantiating. What does this mean?
It means that everything ScriptableObjects used to be good for, MonoBehaviours can do... and can unlock much more powerful patterns than ScriptableObjects tend to allow. Unity was built around the concept of prefabs and MonoBehaviours, and now we can merge that power with prefab referencing.
Let me describe the patterns I'm using in The Galactic Line. These are MonoBehaviours-with-muscly-prefabs patterns.
The Magic Mixin
I have a lot of space ship parts. I don't like instantiating them, because they're heavy: they have LODed visuals, sound clips, lights, lots of stuff that I want to leave on the cutting room floor if the ship is too far away to see... but I still want to simulate the ships. Hundreds of ships you can't see, still being simulated as their resources drain away and their mission timers tick up.
Ships are easy enough to simulate, but you need each of their parts to tell you what it does as time passes. What does this reactor do? It drains water and creates power. It drains antimatter and creates power, heat, and radiation. It's pressurized. It's not pressurized. It has these external visuals and collision meshes, these internal visuals and collision meshes. It makes these sounds in these situations. It has beds in it for some reason. Or maybe not.
When I get close, these parts resolve into a GameObject. They have to, because we have to see them and hear them in the scene. I could bend over backwards to avoid making a prefab... but why? It makes sense to make it a prefab, that's what prefabs are for.
The problem is that I want to access all that juicy functional stuff without instantiating the part.
I could make all of them ScriptableObjects, but then we have a staggering number of floating loose ends. A radiation-production ScriptableObject saved off in some other directory, values specific to this reactor. It makes more sense to have a radiation-production MonoBehaviour and stick it onto the part. I can just customize it right there, no need to have dangling assets. That's what the GameObject is for.
And I can access all of that directly, without instantiating anything. If I want to know how much power this reactor creates and how fast it guzzles fuel, I just ask it. If I want to know if it's air-tight, I just ask it if it has an air-tight mixin. If I want to know what its UI thumbnail is, I just ask it. Want to know what sounds it makes? Just ask. I need to simulate ten weeks of warp travel? Just ask it for those values and multiply by ten weeks.
I can load everything I need onto the part prefab. It doesn't matter how complex the part is. It doesn't matter whether it involves nested objects or flat mixins. Modders can clone and alter the part, and it won't screw up the default because the values are per-prefab.
In addition to being super easy to take care of and keep track of, I can then just drop it into the scene. Whether it's in play mode or edit mode, I can drop it into the scene and it will instantly be the thing it is. I can mount in anything I want, visually. LOD? Or not. Lighting or not. Hell, additional cameras displaying to holographic monitors? Sure. Sounds that play differently depending on how much the generator is being taxed? Why not!
In this way, anyone can create ship components, drop on the relevant mixins (such as "Reactor" and "PressurizedSpace"), save it. They know what they'll get, and the game engine automatically optimizes to prevent any bloat. Advanced users can hook UnityEvents up to create nice triggers and visuals, or even create new scripts. Just drop 'em in. No loose ends, no complicated dependencies.
Now, if the thought of a largely undifferentiated ball of objects makes you cringe... this method of creating and saving content is a fundamental in Unity. This is how Unity is engineered to work, and this is how it works most easily.
You can engineer around it, but why? Use the engine in the way it's meant to be used, and you'll have a much easier time of it.
The Meta-Instantiator
My ships have a lot to keep track of, but I don't instantiate any of the parts if I can get away with this. This means I can have a fleet of Star Destroyers, each containing thousands of crew members, and from the perspective of the game it's just a bit of data that gets processed whenever it needs to be.
The ship has a link to the blueprint prefab for the ship class, which in turn contains all the ship parts. If I instantiate that blueprint, I get a nice, shiny ship full of visuals and noises and stuff.
But I don't have to instantiate it. Instead, I crawl through the parts compiling a list of all the resources and potential mission parameters and that jazz. A small algorithm calculates out the next "keyframe" in the ship's future - when the mission completes, when resources get dangerously low, when it reaches its destination, etc.
The universe sim trickles forward at whatever pace the player wants, and when the in-universe time hits that keyframe, we crawl through the ship again to find the new situation and calculate out the next keyframe. This simple method allows us to have thousands of Star Destroyers without any slowdown at all. No per-frame update, we don't even really need an in-scene object to represent them. (And, since they're probably 500 light years away, that's good.)
Well, we get close to a fleet of Star Destroyers, and therefore the ones nearby start getting instantiated into the game world. The player accidentally rams one, breaking one of those big engines. An NPC commander is generated and yells at the player.
Oh no, this is awful! How do we remember things like a specific engine being broken, or a specific commander existing? We're just referencing a blueprint!
... just save the instance as a custom ship.
Since the blueprint contains a reference to its prefab and each component contains a reference to its own prefab, we can do whatever we want. We can easily save this "baked" blueprint, and then compare its stats to the changes in the definitions of things like engines and reactors. We could even just save the one damaged component, and leave the rest as references.
We can also generate a mission to repair the ship, and when the mission completes, we can delete the custom blueprint and restore it to an ordinary blueprint reference. We could also save the commander - either as part of this ship or separately, as we prefer.
Unlike a ScriptableObject, a prefab can easily be cloned, compared, reloaded, partially cloned, merged, instantiated piecemeal...
The Monster's Database
If you're a fan of ScriptableObjects, hopefully by now you're thinking "well for your specific application, sure, but IN GENERAL-"
Most of the uses of ScriptableObjects are as data objects. The big advantage is that there's no extra stuff.
For example, I have a list of various factions and species. If each was a MonoBehaviour, I could drag it onto a property on another class in the same way as I could do with a ScriptableObject - it'd automatically resolve the reference to the prefab as a reference to the specific MonoBehaviour on the prefab. It'd behave exactly like a ScriptableObject, but it'd have a GameObject lurking in the background being... nonoptimal.
I mean, why would you ever instantiate a whole faction, right? Just drag it into the scene? You'd never need that, so it's just junk stapled onto my data class!
I could argue that it allows for mixins, but we already did that. Let's argue for something else.
Before that level of garbage starts to get noticeable, we run into another problem: managing hundreds of ScriptableObjects is just as obnoxious as managing hundreds of prefabs.
There's a reason why GameMaker and RPGMaker use databases for this kind of thing: databases are a really great way to handle it. You could manipulate the editor to create a pseudo-database front end for your ScriptableObjects (or your prefabs), but... JUST MAKE A DATABASE. It's faster, less overhead, and can be easily exported and imported from Excel or an HTML form or whatever.
The big problem with databases is that it's hard to drag a specific entry into a field in the inspector. I don't know the best solution for this, right now I'm using an editor trick to fake it, but it's not very good.
In the end, my thoughts are simple: if you have dozens of entries, you probably need a database. If you have only a few, the extra garbage of having a GameObject attached isn't enough to worry me, and you can usually leverage mixins to add a lot of extra functionality on the cheap.
The Custom Prefab
My argument is simple: the prefab is now more powerful than the ScriptableObject.
In the video above, Richard Fine creates a ScriptableObject to handle playing custom explosion sounds. This is the part of the video that upsets me the most, because it's a magic handwave that hides the fact that it does nothing useful at all.
There's no reason to have a ScriptableObject "ShellExplode" floating around separately from the shell prefab that's going to explode. Just put it on the goddamn shell. Even the "play mode editing" would work the same way, because you're editing the prefab and it gets instantiated every time you hit shoot!
And, of course, now you just have A Shell Object instead of a shell object and some random dangling object in another directory that may or may not be referenced correctly. Moreover, you can easily clone the shell prefab and create your Big Boss Shell and your Tracer Shell and your Rocket Shell, tweak away!
It's not magic, it's the way Unity is built to work best.
The idea that a prefab is somehow "fragile" is not true any more. The classic example of a ScriptableObject is that if you have ten monsters, they can all have the same stats and you'll never "accidentally" edit just one monster to have different values.
If you have a lot of monsters, you'll probably be using a monster spawner that references a prefab, rather than hardcoding every monster. Even if you do hand-place each monster, changes to the prefab automatically update instances, as long as the instance's values haven't been manually altered. This works per property.
So, for example, if I have ten orcs and I want one of them to have extra HP, I can increase the HP. And I change his AI role to "leader". And I add a potion to his inventory. And I put a hat on him. Later, I change the orc prefab's damage from 4 to 6. The orc I modified will have his damage correctly updated, while still keeping his hat and potion and HP and AI role!
Sure, it's possible to accidentally change a value and not realize it, but that seems inconsequential compared to the overhead of needing a new, permanent asset file in your project directories for every slightly tweaked monster.
That's the point of Unity. The point of Unity's entire approach is that you can tweak things in scene view! Using ScriptableObjects to "work around" that is like "working around" the game of basketball by taking out the ball. Yeah, you could probably come up with something, but it's not going to be a very effective use of your basketball pros or your basketball courts!
Use Interfaces and Delegates
I've seen a few other arguments for ScriptableObjects - for example, externalizing coroutines so you can plug them in willy-nilly, or using delegates bound up in ScriptableObjects to do things like flexible AI processing.
Just... uh... just use C#.
Not to sound elitist, but C# has delegates and interfaces already. Use them. Don't find an excuse to wrap them in ScriptableObjects, just mainline the stuff.
Unity's support for these in the inspector view is kinda crappy, which is the big argument against it. Fortunately, you can use UnityEvents instead of delegates, and those do show up in the inspector fine.
Interfaces are similarly inspector-unfriendly, but they're very powerful and useful and don't limit you to either a ScriptableObject or a MonoBehaviour - you can use either, or even a raw C# class, or have instances of all three for different applications that are referenced from a single system!
Personally, I think using MonoBehaviour mixins as implementations of interfaces is really underestimated, but that's another topic entirely.
Use ScriptableObjects
Am I arguing that ScriptableObjects are useless?
No, not at all. They are more optimal than prefabs, so if it occurs to you to use them, you should use them. They're especially nice when it comes to instantiating them outside of the scene, or moving references between clients.
Fundamentally, ScriptableObjects are classes. That is, you've written lines of code. I generally suggest using them when you can write less code by using them, and I tend to find that means situations where I need to create and track arbitrary references and complex data.
I've stored options menu defaults in ScriptableObjects, level code, galaxy definitions...
But, in the end, I've never found them to be much earthshakingly better than either using prefabs or raw data. So I only use them when I'm in the mood to optimize.
ScriptableObjects CAN do a lot of things, but that's because they're a C# class. They're not substantially better at those things than either a MonoBehavior or a C# class. Any optimization you can get by using them is marginal, and they don't offer any particularly astounding new patterns or workflow.
I'm not against using them. I just don't want people to think they can do these amazing things... without ever realizing that simple prefabs can already do those things, and many other things at the same time.
Tuesday, July 05, 2016
Galactic Politics
The 4X genre is incredibly stagnant, and nowhere is that clearer than in the complete failure to offer any kind of political gameplay.
This means that the 4X games are always going to have that fourth X: "Exterminate". If you can't really build a relationship with other nations, you don't have any choice.
There have always been vague, hamhanded concessions to those of us that like "pacifist" gameplay, such as cultural victories or voting for yourself in the galactic senate, but these are very passive experiences that don't feel as strong as the warfare gameplay.
There's no reason for that. Let's do a very easy experiment: let's re-engineer Stellaris so it has political gameplay.
And by "re-engineer" I mean "a mod".
Stellaris is a very flawed game, largely because they tried to extend the midgame but didn't add in much midgame play. We can fix that by adding in politics, and it doesn't require much of a change at all.
Trade Fix
First, let's get rid of the "trade" system. We're replacing that with a new way of gaining favor and benefiting from other nations. Instead of trade agreements, we should instead have outreach activities - they fill the same spot and work in the same way, but there are a few differences.
(This makes more sense to me anyway, since individual diplomats would handle details.)
One is that activities have an in-world color. Rather than donating 200 energy, you spend 200 energy hosting a Glarthian history exhibit on your homeworld for ten years. Or you spend it on Glarthian refugees. Or you spend it on raising patrols on the border, creating a trickle of material input due to seized smuggling goods.
The Glarthians will respond in a way that makes sense to their culture, which means different activities will result in different things from different cultures.
The best thing about this approach is that the activities can adapt to the current relationship. The treaties can still exist: if you close your borders, certain things become impossible and others become possible. If you're in a defensive pact, more things are possible and some of the "getting to know you" ones are scrapped. Even during an outright war, you'll still have political actions you take take: to lay the groundwork for peace, to exploit their weaknesses, to perform spy actions.
It's outside of the realm of a mod, but it'd also be pretty easy to set up N-way activities by simply allowing you to invite people to help you do the activity. Whether it's hosting a Glarthian history month or setting up an economy-shredding blockade, just invite anyone you want.
Buildings
Since Stellaris has colonies that are very building-centric, let's introduce some political buildings. Museums, market districts, embassies. We can even put them on space stations!
Some of these are multi-purpose. Market districts give a steady flow of materials, while museums decrease cultural drift (already a thing in Stellaris). But they also affect the relationship between your nation and any nation whose border is within N light years of the installation.
Rather than trying to get a +1 trust per month by randomly spraying them with credits, how about we use these buildings? Because colonies have limited space, this produces some wonderful new tradeoffs. Right now, having a colony crammed against a few borders is a panic-inducing state of affairs, but how about if you dedicate that colony to international politics? Now it's establishing good relations between you and them, reducing or even reversing the penalty for having borders touching.
People
Since the colonies are inhabited by populations with explicit values and traits, we can make those buildings modify the populations on the affected worlds. Xenophilic groups will tend to pop up, and if possible, we could add species-specific xenophilia as the people on the planet learn to love Glarthians specifically.
We can even have the various facilities push different traits. Embassies might create pacifism, while museums might create xenophilia (if near a border) or xenophobia (if not near a border).
This would let us take advantage of the already-existing population engine, and a clever person could seed xenophilia throughout a neighboring nation, then use outreach activities to put those populations in power and change the nature of their empire.
Now imagine if that xenophilia was specific to your species! Or imagine it was pacifism, and you've changed a warlike nation! There's a lot of potential to let the player customize their approach.
While it'd be tough to mod it into Stellaris, it'd be fun to have some control over the pro-you factions in other nations. Right now there is a faction control system in Stellaris, why not have foreign factions that you have some control over in that list?
Ships
One thing that's easy to overlook is that the Enterprise was always as much a political vessel as a science vessel. Why don't we add a few new science ship components?
Specifically, political/outreach facilities. You can research and upgrade them just like sensor kits.
Ships with political facilities will automatically improve relationships with whoever they are orbiting. As long as you have open borders, you can use your science ships to wage peace.
We could have the facilities mirror our colony facilities, allowing us to create traits such as xenophilia or a physics specialty or pacifism on the planets we orbit, instead of at random. Moreover, this would mean we could park our science ships over our own planets to mold our own populations in that way.
Although it'd be hard to mod it into Stellaris, it'd be nice to have another category of science mission: political outreach missions. These might pop up at random, or maybe you have to survey worlds again every few years to have a chance of uncovering one. The science ships with outreach modules can perform these outreach missions and things will go better between your people and theirs.
Counter-agency
There's also how to counteract these cultural attacks. Even closing your borders doesn't completely prevent them. So why not have some more policies, facilities, or science ship components that specifically negate the effect of museums or science ships, preventing your people from developing traits you don't like.
And, of course, you can take political stances that force them to back off - cultural preservation or something.
There's a lot of potential here, and it's so close to being something we could simply mod into Stellaris.
So... why are 4X games so stagnant? Look at all this stuff we could be doing with it!
This means that the 4X games are always going to have that fourth X: "Exterminate". If you can't really build a relationship with other nations, you don't have any choice.
There have always been vague, hamhanded concessions to those of us that like "pacifist" gameplay, such as cultural victories or voting for yourself in the galactic senate, but these are very passive experiences that don't feel as strong as the warfare gameplay.
There's no reason for that. Let's do a very easy experiment: let's re-engineer Stellaris so it has political gameplay.
And by "re-engineer" I mean "a mod".
Stellaris is a very flawed game, largely because they tried to extend the midgame but didn't add in much midgame play. We can fix that by adding in politics, and it doesn't require much of a change at all.
Trade Fix
First, let's get rid of the "trade" system. We're replacing that with a new way of gaining favor and benefiting from other nations. Instead of trade agreements, we should instead have outreach activities - they fill the same spot and work in the same way, but there are a few differences.
(This makes more sense to me anyway, since individual diplomats would handle details.)
One is that activities have an in-world color. Rather than donating 200 energy, you spend 200 energy hosting a Glarthian history exhibit on your homeworld for ten years. Or you spend it on Glarthian refugees. Or you spend it on raising patrols on the border, creating a trickle of material input due to seized smuggling goods.
The Glarthians will respond in a way that makes sense to their culture, which means different activities will result in different things from different cultures.
The best thing about this approach is that the activities can adapt to the current relationship. The treaties can still exist: if you close your borders, certain things become impossible and others become possible. If you're in a defensive pact, more things are possible and some of the "getting to know you" ones are scrapped. Even during an outright war, you'll still have political actions you take take: to lay the groundwork for peace, to exploit their weaknesses, to perform spy actions.
It's outside of the realm of a mod, but it'd also be pretty easy to set up N-way activities by simply allowing you to invite people to help you do the activity. Whether it's hosting a Glarthian history month or setting up an economy-shredding blockade, just invite anyone you want.
Buildings
Since Stellaris has colonies that are very building-centric, let's introduce some political buildings. Museums, market districts, embassies. We can even put them on space stations!
Some of these are multi-purpose. Market districts give a steady flow of materials, while museums decrease cultural drift (already a thing in Stellaris). But they also affect the relationship between your nation and any nation whose border is within N light years of the installation.
Rather than trying to get a +1 trust per month by randomly spraying them with credits, how about we use these buildings? Because colonies have limited space, this produces some wonderful new tradeoffs. Right now, having a colony crammed against a few borders is a panic-inducing state of affairs, but how about if you dedicate that colony to international politics? Now it's establishing good relations between you and them, reducing or even reversing the penalty for having borders touching.
People
Since the colonies are inhabited by populations with explicit values and traits, we can make those buildings modify the populations on the affected worlds. Xenophilic groups will tend to pop up, and if possible, we could add species-specific xenophilia as the people on the planet learn to love Glarthians specifically.
We can even have the various facilities push different traits. Embassies might create pacifism, while museums might create xenophilia (if near a border) or xenophobia (if not near a border).
This would let us take advantage of the already-existing population engine, and a clever person could seed xenophilia throughout a neighboring nation, then use outreach activities to put those populations in power and change the nature of their empire.
Now imagine if that xenophilia was specific to your species! Or imagine it was pacifism, and you've changed a warlike nation! There's a lot of potential to let the player customize their approach.
While it'd be tough to mod it into Stellaris, it'd be fun to have some control over the pro-you factions in other nations. Right now there is a faction control system in Stellaris, why not have foreign factions that you have some control over in that list?
Ships
One thing that's easy to overlook is that the Enterprise was always as much a political vessel as a science vessel. Why don't we add a few new science ship components?
Specifically, political/outreach facilities. You can research and upgrade them just like sensor kits.
Ships with political facilities will automatically improve relationships with whoever they are orbiting. As long as you have open borders, you can use your science ships to wage peace.
We could have the facilities mirror our colony facilities, allowing us to create traits such as xenophilia or a physics specialty or pacifism on the planets we orbit, instead of at random. Moreover, this would mean we could park our science ships over our own planets to mold our own populations in that way.
Although it'd be hard to mod it into Stellaris, it'd be nice to have another category of science mission: political outreach missions. These might pop up at random, or maybe you have to survey worlds again every few years to have a chance of uncovering one. The science ships with outreach modules can perform these outreach missions and things will go better between your people and theirs.
Counter-agency
There's also how to counteract these cultural attacks. Even closing your borders doesn't completely prevent them. So why not have some more policies, facilities, or science ship components that specifically negate the effect of museums or science ships, preventing your people from developing traits you don't like.
And, of course, you can take political stances that force them to back off - cultural preservation or something.
There's a lot of potential here, and it's so close to being something we could simply mod into Stellaris.
So... why are 4X games so stagnant? Look at all this stuff we could be doing with it!
Subscribe to:
Posts (Atom)