Recently I've been thinking about space ships. AH HA that was a joke. I've been thinking about them since I was three.
One of the things I've done in the past is focus on the concept of systems in a space ship. You need life support, engines, fuel, solar panels, batteries - by breaking down the ship into a pile of parts, you can create a lot of complexity. It's also useful because you can add in additional complexity easily - just create or mod in new parts with new functions.
But there is another approach to ship design: having many of the same modules.
You can see this most commonly in space ships from movies or concept art: the artist doesn't need a space ship that statistically "works". They need one that looks and feels "right". So it has dozens of repeating modules - hundreds of engines, dozens of rows of unnamed windows, glittering lights aplenty. You can also see this in parts of Space Engineers, due to the fact that modules cannot be scaled, so larger ships need more repeating modules rather than larger versions of the modules.
There is something to this design sense, both mechanically and visually. Space Engineers doesn't really take advantage of it - I can't blame them, because nobody has.
Space Engineers (and most other non-physics ship games) use non-topological modules. That is, aside from some minor restrictions, it doesn't matter where in the ship the modules are put. If you need 50 engines, you can arrange them however you want, as long as nothing is directly behind them. This is good in that it gives you a lot of freedom as to how your ship looks, but it's bad in that it's not very compelling gameplay.
One easy way to make it more compelling is to make topological relationships matter. For example, imagine that an engine module has an efficiency rating based on the modules around it. Maybe the engine module generates heat, and if that heat is allowed to build up efficiency falls off... but if it is kept too cold, it also falls off. Maybe having high-pressure fuel raises efficiency, but every engine on the "fuel chain" diminishes the pressure for the rest. Maybe the engine module vibrates, reducing the efficiency of neighbors. There's a lot of options.
Addressing these options is a fun part of building a ship. Not only will you want to place your engine modules carefully, but you'll want to use support modules such as heavy-duty pumps, heaters, heat vents, dampeners - and those support modules may also have a variety of requirements.
Topological constraints can really make building ships interesting, but there are some constraints on the constraints. Lemme 'splain.
In order for topology to be fun, it has to be bumpy, have texture - the player needs to be able to properly grip it. Every piece the player adds has to make the player think "oh, this is going to be fun to put together!"
If every module is a 1x1x1 brick in 3D space, the player will never think that. Every piece will just be a bundle of basic stats.
One way to give the pieces "texture" is to change how they are shaped. Giving them various sizes and shapes will make it fun to figure out how they can be interlocked in interesting ways. If certain points on each one are hardpoints or resource intakes/outputs, fitting them together becomes even more complex - but don't accidentally make it so restrictive that there's only one way to fit things together!
There is another way to give the pieces texture: restrict where they can be placed.
An endless 3D grid doesn't give the player anything to grip onto. But if you make assumptions about how your ship "needs" to be laid out, you can really change the end result. for example, we can assume a standard "spinal" ship design. Then we can allow the player to choose how long or broad to make their ship, and split the spine into sections - crew section, support section, engineering section, engine section. Each module can only be attached to one section, or to a part that is ultimately anchored to that section.
However, modules near each other are "smoothed" together with the ship skin, linking them physically in the final form even if the modules are actually anchored to completely different parts of the ship. In this way modules from different segments can interact with each other and be linked together, allowing them to affect and support each other, and forming the basis for topology more complex than a simple branching tree. Basically, branching tree construction, but realspace interactivity.
Another option is to create a spaceframe of some simple shape (like a 'U'), then allowing you to put modules anywhere... but never attach modules to modules. All modules must be attached to the spaceframe. This "surface area" approach allows you to relate whatever mods you like, but space constraints become absolutely critical. Obviously, larger spaceframes have major drawbacks.
There are a lot of other methods, but the basic idea is simple.
I've been thinking about this a bit recently, partly because it produces much more refined ships. Rather than being a simple string of every required module, the space ships have repeating motifs. If you wander around inside of them, you'll walk through a ship that seems to be engineered to fight against space: halls of pulsating engines, rows of churning computers, life support pumps hammering away. It's not just a checklist - "life support, check!" - it exists properly. It's been designed, carefully balanced and placed by a rocket scientist (or, at least, someone pretending to be one).
It also looks better from outside. Regardless of the constraints used, the repeating module motif produces much more interesting ships than the "one of everything" motif.
Anyway, those are my thoughts.
Thursday, August 28, 2014
Tuesday, August 19, 2014
Fluid Time
I realized a little while ago that I've been leaning very heavily on a particular concept nobody else seems to use at all. I call it "fluid time". I have to explain it in order to explain my NPC-mod system, so here we go!
Most of my recent prototypes involve being able to fast forward, pause, even rewind. They feature going to some other location, but still having the first location processing in the background.
Normally, if you have things that change over time in a game, you'd attach them to the frame or physics loop and process them each iteration. But that doesn't scale very well as timescales change and the number of changing objects reaches the thousands or millions.
Using fluid time lets me get around that, and handle extremely large numbers of objects at any timescale I please.
It's a pretty basic idea. You take the statistics that behave predictably, and instead of calculating that predictable change every frame, you just create a function for it.
For example, let's say Anna is the only farmer we have. She produces food. When we plonk her into the game world and assign her that task, the "food" stat begins to change in a predictable way. The formula becomes "at day 1: 0 food. +1 food per day."
Now, if we zoom off to the far side of the galaxy and do a million other things, that function continues to exist. It doesn't take up our CPU, Anna doesn't need to be loaded into the scene. If we want to know how much food we have, we just call that function with the current day and it calculates out how much food we have.
Let's say that farmers stop producing food in winter. In that case, our function would simply have a bound. "At day 1: 0 food. +1 food per day until day 270."
We know when the function becomes invalid, so we know when to revisit and recalculate.
If we want to do it strictly, we can: day 270 dawns, we revisit the situation, and the formula changes to "At day 270: 269 food. +0 food per day until day 360."
Alternately, we could simply pause time in that area until we revisit - time stops there at day 270, and the player gets to take control at that time, even though the day might be 190,028 in another sector.
We also have a lot of options about historical info. Once day 270 rolls around, we can either save that now-obsolete span of time, or we can discard it if we don't need to remember. What would historical info get us? Well, you could rewind time, you could look at historical trends, you could play in multiple times simultaneously...
Another big advantage of this method is that it allows synching multiplayer really cheaply. It doesn't work for everything - for example, it can't respond easily to details like movements or the moment-to-moment choices of other players - but it works well for cheaply keeping track of thousands of low-maintenance shared objects. Of course it does: that's what it's intended to do locally, and it works just as well on a network.
There's one more big advantage, and this one's a doozy: it's easy to mod.
One of the core problems with mods is that they can only usually interact with the "surface" of the game. Mods that affect core functionality are usually not possible, to the point where several Skyrim mods come with a java program that runs in the background to forcefully intervene against the core code base. The reason it's hard to do isn't malice, it's architecture: the code is intermeshed with itself to do a specific kind of job, and there's no "cracks" in the wall for mods to break in through.
An event-driven system is a lot more flexible, as you can either overwrite the delegate assignments or start catching events.
But there are some problems with event-driven frameworks.
The biggest for us is that Unity doesn't serialize event subscriptions or delegate assignations, so saving and loading and transferring them over a network is nightmarish. The biggest problem for everyone else is that events are hard to debug, hard to keep track of - too many asynchronous pieces moving in every direction.
So most games don't expose much event-driven stuff, and mods have to break in. This results in things like Skyrim's dreaded "script cancer", where scripts run every frame to check all the relevant stats and states, bogging things down to a crawl. Events would allow you to do this more fluidly, attaching your functions to events like "onStrengthChanged" or "onEquippedItem" or whatever. But... it doesn't serialize and it's hard to debug.
We can tackle both of these issues at once if we create an event handling framework that can serialize and deserialize properly. The framework can easily keep track of who is signed up for what and make it easy to debug and even visualize in real time.
It's annoying to have to build this kind of framework when the C# event/delegate framework works almost well enough on its own, but on the plus side it lets us integrate into Unity and our specific project much more firmly. For example, press F12 and you can see the rays of connectivity between watchers and watchees.
Fluid time benefits from this due to the large number of interconnected moving pieces. A new farmer, or a storm, or a mod that introduces crop blight - they can all interact with the "food" fluid time system and run in a very low-maintenance, cheap way.
Press F12, and you can see what mods are affecting the crop totals, what mods are waiting for food production to reach certain levels, what mods are reflecting food values in some ways, when the current formula is due to be obsolete, what is making it obsolete...
Anyway, soon I'll write a post about how we can use this to make moddable NPCs, but this is long enough as it is. A hint: it involves scripting in the lexical sense!
Most of my recent prototypes involve being able to fast forward, pause, even rewind. They feature going to some other location, but still having the first location processing in the background.
Normally, if you have things that change over time in a game, you'd attach them to the frame or physics loop and process them each iteration. But that doesn't scale very well as timescales change and the number of changing objects reaches the thousands or millions.
Using fluid time lets me get around that, and handle extremely large numbers of objects at any timescale I please.
It's a pretty basic idea. You take the statistics that behave predictably, and instead of calculating that predictable change every frame, you just create a function for it.
For example, let's say Anna is the only farmer we have. She produces food. When we plonk her into the game world and assign her that task, the "food" stat begins to change in a predictable way. The formula becomes "at day 1: 0 food. +1 food per day."
Now, if we zoom off to the far side of the galaxy and do a million other things, that function continues to exist. It doesn't take up our CPU, Anna doesn't need to be loaded into the scene. If we want to know how much food we have, we just call that function with the current day and it calculates out how much food we have.
Let's say that farmers stop producing food in winter. In that case, our function would simply have a bound. "At day 1: 0 food. +1 food per day until day 270."
We know when the function becomes invalid, so we know when to revisit and recalculate.
If we want to do it strictly, we can: day 270 dawns, we revisit the situation, and the formula changes to "At day 270: 269 food. +0 food per day until day 360."
Alternately, we could simply pause time in that area until we revisit - time stops there at day 270, and the player gets to take control at that time, even though the day might be 190,028 in another sector.
We also have a lot of options about historical info. Once day 270 rolls around, we can either save that now-obsolete span of time, or we can discard it if we don't need to remember. What would historical info get us? Well, you could rewind time, you could look at historical trends, you could play in multiple times simultaneously...
Another big advantage of this method is that it allows synching multiplayer really cheaply. It doesn't work for everything - for example, it can't respond easily to details like movements or the moment-to-moment choices of other players - but it works well for cheaply keeping track of thousands of low-maintenance shared objects. Of course it does: that's what it's intended to do locally, and it works just as well on a network.
There's one more big advantage, and this one's a doozy: it's easy to mod.
One of the core problems with mods is that they can only usually interact with the "surface" of the game. Mods that affect core functionality are usually not possible, to the point where several Skyrim mods come with a java program that runs in the background to forcefully intervene against the core code base. The reason it's hard to do isn't malice, it's architecture: the code is intermeshed with itself to do a specific kind of job, and there's no "cracks" in the wall for mods to break in through.
An event-driven system is a lot more flexible, as you can either overwrite the delegate assignments or start catching events.
But there are some problems with event-driven frameworks.
The biggest for us is that Unity doesn't serialize event subscriptions or delegate assignations, so saving and loading and transferring them over a network is nightmarish. The biggest problem for everyone else is that events are hard to debug, hard to keep track of - too many asynchronous pieces moving in every direction.
So most games don't expose much event-driven stuff, and mods have to break in. This results in things like Skyrim's dreaded "script cancer", where scripts run every frame to check all the relevant stats and states, bogging things down to a crawl. Events would allow you to do this more fluidly, attaching your functions to events like "onStrengthChanged" or "onEquippedItem" or whatever. But... it doesn't serialize and it's hard to debug.
We can tackle both of these issues at once if we create an event handling framework that can serialize and deserialize properly. The framework can easily keep track of who is signed up for what and make it easy to debug and even visualize in real time.
It's annoying to have to build this kind of framework when the C# event/delegate framework works almost well enough on its own, but on the plus side it lets us integrate into Unity and our specific project much more firmly. For example, press F12 and you can see the rays of connectivity between watchers and watchees.
Fluid time benefits from this due to the large number of interconnected moving pieces. A new farmer, or a storm, or a mod that introduces crop blight - they can all interact with the "food" fluid time system and run in a very low-maintenance, cheap way.
Press F12, and you can see what mods are affecting the crop totals, what mods are waiting for food production to reach certain levels, what mods are reflecting food values in some ways, when the current formula is due to be obsolete, what is making it obsolete...
Anyway, soon I'll write a post about how we can use this to make moddable NPCs, but this is long enough as it is. A hint: it involves scripting in the lexical sense!
Friday, August 15, 2014
Moddable NPCs
I've talked a lot about mods a lot, and I'd like to talk about NPCs.
Even with highly-moddable games, the NPCs are miserably difficult to manage. Skyrim probably has the most moddable NPCs, but the way the NPCs are implemented in the base game really limits their behavioral flexibility.
So, let's talk about a game where modding NPCs is the point.
You play a godling. Not in a gods-eye view, but as an actual person in-world, similar to Skyrim. Your big power is to create people out of clay. They turn into living NPCs, and you can interact with them.
The basic loop is that the NPCs generate resources for you. You can gather some resources on your own - clay, water, grass, and whatever else you can find - but those are very basic and there's no crafting. Instead, you set the NPCs up to generate resources. First you create a farmer, and they make food. Lots of food - enough to feed everyone else nearby and still give you a stack of foodstuffs if you decide you need them. Maybe you create a woodcutter to create lots of wooden planks so you can build wooden houses instead of log cabins. Maybe you create a carpenter to turn wood into furniture, so you can fill those new wood houses with nice furniture. Maybe you put a shrine in the house so they can worship you and give you spirit points. Or a library, so they can generate new ideas...
As time passes, the NPCs will get better at their jobs. This isn't stored as some internal skill variable. Instead, it is evident in the tools they use. Their tool shed becomes more full with higher-quality tools. Their bookshelf is filled out. Their yokes & ploughs upgrade to the next tier. Their skill is represented quite concretely by the objects in their home. Trying to move these items to a new home will lose a lot of the upgrades, so it's kinda-sorta-vaguely NPC-specific.
While there is some challenge to creating a good flow for all the resources you'd like, the real challenge is in keeping your NPCs alive. You can create them easily enough, but if they are put under too much stress, they revert back to clay statues. They're not really dead - you can wake them back up as long as the statue isn't destroyed - but they certainly aren't living.
Unfortunately, these NPCs are very vulnerable to stress. Their default state is "dead of stress", and it gets much worse if they have a job. You have to build their homes to alleviate that stress.
For example, if you're going to start by building a farmer, you'll obviously need to give her all her farm tools and so on... but you'll also need to set up her home so she can survive. A bed, kitchen, and so on are all required to prevent added stress due to exhaustion and hunger. Then you also need to set things up to reduce the stress she is under! A fireplace, candles, some books, a veranda, some company...
There's no need to simulate the NPC's stress in real time - it all derives from the furniture in her house. The NPCs are simulated when you are nearby, but that's for social purposes, not for statistical purposes.
So, you set up a little farmer family. They farm, and they support each other, and stress is kept to a minimum. However, nothing lasts forever. As time passes, all the furniture in the house drifts and/or decays. This won't affect something like a workbench, but things like beds and chairs and bureaus and costumes all migrate and/or degrade. So your carefully balanced house steadily falls out of true, and stress becomes an issue. Eventually things will drift far enough or decay badly enough that the NPCs turn back into clay statues.
This is often a catastrophic spiral, because a lot of the stress relief comes from other NPCs. The farmer parent's bed is a double, with each side assigned to one of them. This creates a romantic relationship between them, and that really reduces stress quite dramatically. But if mom turns to clay, that stress relief stops happening and dad quickly turns to clay. Of course the children are likely to turn to clay as well, since much of their stress relief comes from being taken care of by their parents (indicated by the parents ownership of things like the kitchen, front door, etc).
Now, the moment-to-moment behavior of the NPCs is actually handled the same way. Every object can create a "state" for the character, and that state has certain kinds of behaviors and takes certain kinds of inputs. It's very freely done, and the heart of the modding system. Each state gets to "vote" on what it thinks the action of the NPC should be at any given time.
For example, the parents share a bed, which sets up their romantic relationship. In addition to being stress control, this also creates a behavior state for each - the romantic interaction state. Romantic interaction probably doesn't mean "having sex" - it means the gentle interactions over the course of the day that show they are used to each other and think of each other frequently. The romantic state only votes on situations involving their lover, and it doesn't always win the vote: another piece of furniture might cause the pair to fight, or just do things other than get along gently.
Moreover, the state of the bed can really change the nature of their interaction. Different beds might have different nuances - perhaps certain relationships are more bitter, or more brusque. Each side of the bed can be customized with a pillow, or perhaps have several states such as made/unmade, bedspread, etc. These can all be used as markers for different tones in the relationship.
It might feel stupid to rely on things like a specific color pillow to represent a specific kind of interaction, but the point is that the NPCs can swap out the components randomly over time and their relationship will drift. By controlling how things get swapped out and how likely things are to be swapped in various ways, you can control how relationships grow or degrade. This is still clumsier than having a simple state machine hidden inside the NPCs, but it's much easier for the player to understand and control.
Moreover, the relationship system is bound to the specific bed item type. Use a different bed for a different kind of relationship - not necessarily just a different nuance: it can be a completely unrelated mod with similar functionality. You can have both mods loaded into the game without difficulty: one is tied to beds A&B, the other to bed C. In fact, there's nothing preventing you from having several beds for one pair of people, each with a different relationship attached, resulting in several simultaneous romantic relationships.
That might sound broken, but there is a limiting factor:
The more rooms and furniture you have in a house, the more maintenance stress. This stress is distributed evenly among everyone, unless you have cleaning supplies assigned to specific people, in which case it is dropped on them. In the short run, mom and dad having three beds is quite nice, and stress is really kept very low thanks to the stress-relieving property of beds. However, as the beds decay, their stress relief drops off quickly and the relationships become rocky. The amount of maintenance stress does not drop off, so stress relief drops off three times faster than it would with a single bed.
You can build a wealthy nobleman's house, lots of beds... just assign the maintenance duties to servants. That's how the pampered live their lives. Of course, their position of authority may involve taxing their citizens, in which case the citizens will all gain more stress because of the nobleman lording it over them... but there are advantages to that, with the nobles generating resources ordinary people can't generate. Well, that's one approach, at any rate. Maybe you have a different set of "nobility" mods loaded in.
Anyway, all of this is done through an open API, allowing anyone to compile a plugin using the Unity framework. An integrated mod manager is actually pretty easy using the asset management tools in Unity, so this would be pretty easy to mod. It could also easily support multiplayer shared worlds due to the low amount of simulation required.
There's a lot of other details. For example, the alignment and position of furniture often matters. A chair facing the fire is relaxing; a chair facing a desk will help generate ideas; a chair next to another chair will make the two people assigned to those chairs get along and have lower stress. Another thing to keep in mind is that NPCs might have different "hearts" - while they are all made out of clay, the seed you build around can be any small item. This can allow for NPCs to also be directly modded rather than always relying on furniture.
Well, all in all it's actually not a hugely difficult game to start. At the beginning, it's just a simpler version of The Sims.
Even with highly-moddable games, the NPCs are miserably difficult to manage. Skyrim probably has the most moddable NPCs, but the way the NPCs are implemented in the base game really limits their behavioral flexibility.
So, let's talk about a game where modding NPCs is the point.
You play a godling. Not in a gods-eye view, but as an actual person in-world, similar to Skyrim. Your big power is to create people out of clay. They turn into living NPCs, and you can interact with them.
The basic loop is that the NPCs generate resources for you. You can gather some resources on your own - clay, water, grass, and whatever else you can find - but those are very basic and there's no crafting. Instead, you set the NPCs up to generate resources. First you create a farmer, and they make food. Lots of food - enough to feed everyone else nearby and still give you a stack of foodstuffs if you decide you need them. Maybe you create a woodcutter to create lots of wooden planks so you can build wooden houses instead of log cabins. Maybe you create a carpenter to turn wood into furniture, so you can fill those new wood houses with nice furniture. Maybe you put a shrine in the house so they can worship you and give you spirit points. Or a library, so they can generate new ideas...
As time passes, the NPCs will get better at their jobs. This isn't stored as some internal skill variable. Instead, it is evident in the tools they use. Their tool shed becomes more full with higher-quality tools. Their bookshelf is filled out. Their yokes & ploughs upgrade to the next tier. Their skill is represented quite concretely by the objects in their home. Trying to move these items to a new home will lose a lot of the upgrades, so it's kinda-sorta-vaguely NPC-specific.
While there is some challenge to creating a good flow for all the resources you'd like, the real challenge is in keeping your NPCs alive. You can create them easily enough, but if they are put under too much stress, they revert back to clay statues. They're not really dead - you can wake them back up as long as the statue isn't destroyed - but they certainly aren't living.
Unfortunately, these NPCs are very vulnerable to stress. Their default state is "dead of stress", and it gets much worse if they have a job. You have to build their homes to alleviate that stress.
For example, if you're going to start by building a farmer, you'll obviously need to give her all her farm tools and so on... but you'll also need to set up her home so she can survive. A bed, kitchen, and so on are all required to prevent added stress due to exhaustion and hunger. Then you also need to set things up to reduce the stress she is under! A fireplace, candles, some books, a veranda, some company...
There's no need to simulate the NPC's stress in real time - it all derives from the furniture in her house. The NPCs are simulated when you are nearby, but that's for social purposes, not for statistical purposes.
So, you set up a little farmer family. They farm, and they support each other, and stress is kept to a minimum. However, nothing lasts forever. As time passes, all the furniture in the house drifts and/or decays. This won't affect something like a workbench, but things like beds and chairs and bureaus and costumes all migrate and/or degrade. So your carefully balanced house steadily falls out of true, and stress becomes an issue. Eventually things will drift far enough or decay badly enough that the NPCs turn back into clay statues.
This is often a catastrophic spiral, because a lot of the stress relief comes from other NPCs. The farmer parent's bed is a double, with each side assigned to one of them. This creates a romantic relationship between them, and that really reduces stress quite dramatically. But if mom turns to clay, that stress relief stops happening and dad quickly turns to clay. Of course the children are likely to turn to clay as well, since much of their stress relief comes from being taken care of by their parents (indicated by the parents ownership of things like the kitchen, front door, etc).
Now, the moment-to-moment behavior of the NPCs is actually handled the same way. Every object can create a "state" for the character, and that state has certain kinds of behaviors and takes certain kinds of inputs. It's very freely done, and the heart of the modding system. Each state gets to "vote" on what it thinks the action of the NPC should be at any given time.
For example, the parents share a bed, which sets up their romantic relationship. In addition to being stress control, this also creates a behavior state for each - the romantic interaction state. Romantic interaction probably doesn't mean "having sex" - it means the gentle interactions over the course of the day that show they are used to each other and think of each other frequently. The romantic state only votes on situations involving their lover, and it doesn't always win the vote: another piece of furniture might cause the pair to fight, or just do things other than get along gently.
Moreover, the state of the bed can really change the nature of their interaction. Different beds might have different nuances - perhaps certain relationships are more bitter, or more brusque. Each side of the bed can be customized with a pillow, or perhaps have several states such as made/unmade, bedspread, etc. These can all be used as markers for different tones in the relationship.
It might feel stupid to rely on things like a specific color pillow to represent a specific kind of interaction, but the point is that the NPCs can swap out the components randomly over time and their relationship will drift. By controlling how things get swapped out and how likely things are to be swapped in various ways, you can control how relationships grow or degrade. This is still clumsier than having a simple state machine hidden inside the NPCs, but it's much easier for the player to understand and control.
Moreover, the relationship system is bound to the specific bed item type. Use a different bed for a different kind of relationship - not necessarily just a different nuance: it can be a completely unrelated mod with similar functionality. You can have both mods loaded into the game without difficulty: one is tied to beds A&B, the other to bed C. In fact, there's nothing preventing you from having several beds for one pair of people, each with a different relationship attached, resulting in several simultaneous romantic relationships.
That might sound broken, but there is a limiting factor:
The more rooms and furniture you have in a house, the more maintenance stress. This stress is distributed evenly among everyone, unless you have cleaning supplies assigned to specific people, in which case it is dropped on them. In the short run, mom and dad having three beds is quite nice, and stress is really kept very low thanks to the stress-relieving property of beds. However, as the beds decay, their stress relief drops off quickly and the relationships become rocky. The amount of maintenance stress does not drop off, so stress relief drops off three times faster than it would with a single bed.
You can build a wealthy nobleman's house, lots of beds... just assign the maintenance duties to servants. That's how the pampered live their lives. Of course, their position of authority may involve taxing their citizens, in which case the citizens will all gain more stress because of the nobleman lording it over them... but there are advantages to that, with the nobles generating resources ordinary people can't generate. Well, that's one approach, at any rate. Maybe you have a different set of "nobility" mods loaded in.
Anyway, all of this is done through an open API, allowing anyone to compile a plugin using the Unity framework. An integrated mod manager is actually pretty easy using the asset management tools in Unity, so this would be pretty easy to mod. It could also easily support multiplayer shared worlds due to the low amount of simulation required.
There's a lot of other details. For example, the alignment and position of furniture often matters. A chair facing the fire is relaxing; a chair facing a desk will help generate ideas; a chair next to another chair will make the two people assigned to those chairs get along and have lower stress. Another thing to keep in mind is that NPCs might have different "hearts" - while they are all made out of clay, the seed you build around can be any small item. This can allow for NPCs to also be directly modded rather than always relying on furniture.
Well, all in all it's actually not a hugely difficult game to start. At the beginning, it's just a simpler version of The Sims.
Monday, August 11, 2014
These are a few of my favorite things (to mod in)
Last year, my gaming preferences underwent a massive shift. Whatever the reason, it's nearly impossible for me to get excited about games these days. It doesn't matter the genre, the target audience, the technical specs - nothing interests me.
For a while, the only two games I would play at all were Skyrim and Kerbal. Now I find myself suddenly playing Space Engineers, even though I had tried it and stopped in boredom. Why did I want to play it again?
Mods. They just introduced mod support.
Ugh, it's kind of obvious in retrospect. Skyrim and Kerbal both have massive levels of mod support and swarms of mods. Space Engineers has started to join in the fray with a truly amazing mod management system, although the mods themselves are still primitive due to lack of scripting support.
So the first thing I did was download a bevy of mods to make me think harder. A ventilation mod, a wiring mod, and interior walls mod... none of them do anything, technically-speaking, but they let me build more complex, immersive stations. And I'm really enjoying it.
...
Why do I only like mods?
I think it boils down to authorship.
Games have a specific team or a specific person creating them. In some cases that authorship is really effective, such as in Papers, Please or Gone Home. But nearly all of the time, the game isn't an attempt to say something meaningful. It's just an attempt to build a cool game.
But I'm not impressed by cool games any more.
When I can twist and reshape a game as I see fit, the game becomes much more interesting to me. When I can take the twists and reshapings of other players, that's when the game really takes off.
Simple logic: if your game allows mods, it has hundreds or thousands of developers. I can pick and choose which ones I want to hear from, which ones seem to have the most interesting ideas. I can include their thoughts into my game at any level. If the system is particularly agile, I can put down my thoughts and then hear their responses.
This is not the same as playing together with people. I have no interest in massively multiplayer games, because those aren't about taking the works of those other players into my own game. We're all stuck in the same game that plays the same way - we're in a place together, instead of building a new place as we like.
On the other end of things, this isn't a sketch jam. Each of these games has a strong underlying scaffold we build on. A mod for Kerbal doesn't make any sense for Skyrim, and visa-versa. Even putting aside technical differences, the concept of the mods doesn't make any sense in the other game. The shared scaffold guides our discussion... but it also makes our discussions compatible.
See, the real strength of a moddable game is not any one mod. It's combining several compatible mods into an interesting result that is flavored just how you want it. I combine Universal Storage, Karbonite, and Spaceplane 1.3 - and all the sudden I have a space program none of them could have accomplished on their own.
Even just aesthetically, in Space Engineers I have a wiring mod, a ventilation mod, a grated-floor mod, and an interior walls mod. The four work together superbly, while each alone is visually incompatible with vanilla.
Because we are all "talking 'space station'", we each have our own ideas as to what space stations need. Combine the best and you get a very dense, deep discussion on the topic of space stations. In the form of digital LEGO bricks.
This is the secret of moddable games.
I have grown tired of what devs think. That's not their fault, but it does mean I have zero interest in their game. It's like listening to someone explain their dream: some people have amazingly interesting dreams, but 99% of people do not.
You will have more than 100 players. At least one of them will have an interesting take on your dream.
For a while, the only two games I would play at all were Skyrim and Kerbal. Now I find myself suddenly playing Space Engineers, even though I had tried it and stopped in boredom. Why did I want to play it again?
Mods. They just introduced mod support.
Ugh, it's kind of obvious in retrospect. Skyrim and Kerbal both have massive levels of mod support and swarms of mods. Space Engineers has started to join in the fray with a truly amazing mod management system, although the mods themselves are still primitive due to lack of scripting support.
So the first thing I did was download a bevy of mods to make me think harder. A ventilation mod, a wiring mod, and interior walls mod... none of them do anything, technically-speaking, but they let me build more complex, immersive stations. And I'm really enjoying it.
...
Why do I only like mods?
I think it boils down to authorship.
Games have a specific team or a specific person creating them. In some cases that authorship is really effective, such as in Papers, Please or Gone Home. But nearly all of the time, the game isn't an attempt to say something meaningful. It's just an attempt to build a cool game.
But I'm not impressed by cool games any more.
When I can twist and reshape a game as I see fit, the game becomes much more interesting to me. When I can take the twists and reshapings of other players, that's when the game really takes off.
Simple logic: if your game allows mods, it has hundreds or thousands of developers. I can pick and choose which ones I want to hear from, which ones seem to have the most interesting ideas. I can include their thoughts into my game at any level. If the system is particularly agile, I can put down my thoughts and then hear their responses.
This is not the same as playing together with people. I have no interest in massively multiplayer games, because those aren't about taking the works of those other players into my own game. We're all stuck in the same game that plays the same way - we're in a place together, instead of building a new place as we like.
On the other end of things, this isn't a sketch jam. Each of these games has a strong underlying scaffold we build on. A mod for Kerbal doesn't make any sense for Skyrim, and visa-versa. Even putting aside technical differences, the concept of the mods doesn't make any sense in the other game. The shared scaffold guides our discussion... but it also makes our discussions compatible.
See, the real strength of a moddable game is not any one mod. It's combining several compatible mods into an interesting result that is flavored just how you want it. I combine Universal Storage, Karbonite, and Spaceplane 1.3 - and all the sudden I have a space program none of them could have accomplished on their own.
Even just aesthetically, in Space Engineers I have a wiring mod, a ventilation mod, a grated-floor mod, and an interior walls mod. The four work together superbly, while each alone is visually incompatible with vanilla.
Because we are all "talking 'space station'", we each have our own ideas as to what space stations need. Combine the best and you get a very dense, deep discussion on the topic of space stations. In the form of digital LEGO bricks.
This is the secret of moddable games.
I have grown tired of what devs think. That's not their fault, but it does mean I have zero interest in their game. It's like listening to someone explain their dream: some people have amazingly interesting dreams, but 99% of people do not.
You will have more than 100 players. At least one of them will have an interesting take on your dream.
Tuesday, August 05, 2014
Good and Bad Scifi
I realized that a lot of the things I have really negative reactions to, I hate because they are bad scifi. And, sure, there's a lot of bad scifi out there... but the ones I really hate are the ones that everyone else accepts blithely. Obvious examples include Bioshock Infinite, Serial Experiments Lain, Prometheus, and so on.
I realized that the issue is simply that I've read waaaaaaaaay more science fiction than most anybody else, and it's turned me into a snob. I've read literally thousands of science fiction stories. It was easy: back in Ye Olde Day, the best scifi was in short story and novelette form. You could read two or three a day just on the bus.
Because of that, I've become a bit of a scifi snob. So... I can't claim my opinions are "the only way to make good sci fi" or whatever, but I can say that most of the science fiction most people consume is trashy action flick scifi.
When you're done reading/watching/consuming good scifi, you can still feel its fingers around your neck for hours.
That's the kind of scifi most people haven't seen.
One thing to remember is that scifi appeals to different people at different times. There are good pieces of science fiction that do not appeal to me. And that's the problem with good scifi. It hits very hard against people who are in the right place. Trashy blockbuster scifi is much easier. It hits a much wider range of people.
But nobody is left stunned at the end. Nobody can feel it gripping their neck.
Things like Lain and Infinite fall very short as scifi goes... but people have been left gasping. The reason is because they have seen so little of substance that they have nothing to compare to. If the only photograph you've ever seen is a grainy, unlit photo of a penny, you're going to think it's amazing. That doesn't make it a good photograph.
Let's talk about the weaknesses of Lain, Infinite, and Prometheus, at least as I perceive them.
...
Secrets, mysteries, and gaps play a big role in science fiction. All three of our examples fail at this, misusing secrets. They use secrets like Lost uses secrets.
Let's talk about secrets.
One of the most fundamental practices in science fiction is to leave huge gaps unexplained in order to create large spaces.
For example, "Khan Noonien Singh was a general in the Eugenics Wars..." That's a powerful statement. It creates a massive block of "space" - these unexplained Eugenics Wars are interesting, and their name is extremely powerful. They are tied into the story, but left unexplained.
On a different scale, "Romulan blue ale". It serves no real purpose to the story, but it creates a vast expanse in your mind: the Romulans have a culinary culture and it's interesting and weird! A tiny detail that serves to create a world without actually cementing anything down.
It also goes the other direction. The internal life of characters is often left implied. Science Fiction rarely spells out motivations and emotions as clearly as other genres do. You're left with people who act a little inexplicably at times, stare a bit too long, covet something a bit too much. This creates a space inside their life, a space the reader can sense but not see. An easy example of this is Obi Wan Kenobi. Why does he live in the desert? Why does he let Darth kill him? How does he have all of these powers? What the hell are these powers?
Part of the draw of the original movies was that they doled out most of these answers in a trickle, so you kept watching to see more of them. But many of them were never really filled in until decades later, and fan theories were everywhere. Alternate explanations exist for virtually everything - for example, some people have proposed that the droids are actually hugely important 'shadow leaders' of the rebellion... and there are enough gaps that this explanation can weave through them fairly convincingly.
Secrets, mysteries, and gaps create life in these universes. They do so in a very powerful way because they let the audience fill those gaps at their leisure, as they see fit.
I think I'm understating that last bit, so let me harp on it:
The audience fills the gaps with whatever they can.
This is the primary tool used to make science fiction accessible to a wider range of people. When scifi has few gaps, the only people it can appeal to are the people who are in tune with the story as it is being told. If every aspect of the Eugenics Wars is explained, then only people who can accept the specific details of why the war happened and how it developed can be interested. Everyone else will say "oh, that's not very interesting" or "oh, that's not very likely".
By leaving it a mystery, each reader can presume it happened in a specific way according to their current... level? Place? The current way their brain works. The more they think about it on their own, the more it falls in tune with their own thinking, and the more interesting it becomes. Used wisely, this trick makes the best scifi twists rip you apart: they gave you space to imagine and assume. Then they kick that out from under you and show you just how feeble your imaginings were.
Now, this isn't the only thing scifi does. A lot of people would say that Star Trek and Star Wars aren't even proper scifi, just fantasy dolled up with technotrappings. Well, leaving that argument aside, this particular practice of creating gaps is commonplace and very powerful. The practice of subverting what the audience puts in those gaps is also a common technique, mostly used when you want to create "mindfuck" scifi.
...
Back to Lain, Prometheus, and Infinite. There will be spoilers, but who the hell cares?
All three of these attempt to use that last technique - the "create a gap, let the audience imagine what's inside, then subvert that" method.
Unfortunately, they do it clumsily.
First off, what's in the gap is rarely a mystery. They attempt to obfuscate something relatively simple, but burying something simple in a fog doesn't make it complicated. The only way that can work is if the audience is so inexperienced that they can't recognize the simple shape of a stumbling transhumanist singularity (Lain), interconnected multiverse anchor (Infinite), or villainous ancients (Prometheus). These stories are SUPER COMMON. I've read dozens of each.
Secondly, rather than create a legitimate gap, they simply drop fog everywhere to obfuscate it. For example, if I say the phrase "scie_ce F_ction", there's not much mystery as to what is underneath those underscores. Fogging them up doesn't make my writing more interesting, it just makes me annoying. And, yeah, I could reveal that it's actually "science FACTION", but it's like, whatever, okay, there were a few options and you chose one of the slightly less common ones. It's not interesting.
Compare this to Satoshi Kon's work, such as Paranoia Agent. Or the anime that blew my mind as a kid, Armitage the Third.
These create legitimate gaps. Paranoia Agent creates gaps by being batshit, leaving you grasping at straws in a maelstrom. It reveals the pattern near the end, just slowly enough that you can start to understand how it all works, and then it rushes ahead to extrapolate what that would actually mean. This overwhelming and powerful technique works because the idea is not common, and it's revealed fast enough that you aren't given time to extrapolate.
Armitage the Third seems like a typical robots and androids anime - they were common at the time. And you enjoy it on that level, but something feels just a touch off. The reveal might not surprise anyone who's seen a lot of scifi, but at the time it was not something that was written about in American science fiction. It really surprised me and left me thoughtful.
You can also talk about how these are also about real-world cultural issues. Paranoia Agent is arguably about the self-destructive hollowness of modern society, and Armitage is about racial purity. Those things matter. They matter a lot. Not only do they tie the story to your life, they also tie the story to the lives of the people in the story. They give incredible power to the characters, because the characters are moving through the same space. They give power to the scenes, because those scenes have happened in the real world.
The fact that Armitage is about racial purity is what gives many of its scenes so much more power than other campy blockbusters with the same basic premise. The sight of burning robot bodies piled high is devastating because it's not about robots.
This is something that only becomes clear near the end - same with Paranoia Agent. You could even say that the twist of these science fiction pieces is simply that they are ABOUT SOMETHING.
Lain, Prometheus, and Infinite not only have dull reveals, they aren't about anything. They just waddle through what someone thought was a cool scifi premise without breathing life into anything.
Sigh.
I really like science fiction.
But if it doesn't grab your neck and leave you breathless for hours afterwards, don't accept it. It's not good enough.
I realized that the issue is simply that I've read waaaaaaaaay more science fiction than most anybody else, and it's turned me into a snob. I've read literally thousands of science fiction stories. It was easy: back in Ye Olde Day, the best scifi was in short story and novelette form. You could read two or three a day just on the bus.
Because of that, I've become a bit of a scifi snob. So... I can't claim my opinions are "the only way to make good sci fi" or whatever, but I can say that most of the science fiction most people consume is trashy action flick scifi.
When you're done reading/watching/consuming good scifi, you can still feel its fingers around your neck for hours.
That's the kind of scifi most people haven't seen.
One thing to remember is that scifi appeals to different people at different times. There are good pieces of science fiction that do not appeal to me. And that's the problem with good scifi. It hits very hard against people who are in the right place. Trashy blockbuster scifi is much easier. It hits a much wider range of people.
But nobody is left stunned at the end. Nobody can feel it gripping their neck.
Things like Lain and Infinite fall very short as scifi goes... but people have been left gasping. The reason is because they have seen so little of substance that they have nothing to compare to. If the only photograph you've ever seen is a grainy, unlit photo of a penny, you're going to think it's amazing. That doesn't make it a good photograph.
Let's talk about the weaknesses of Lain, Infinite, and Prometheus, at least as I perceive them.
...
Secrets, mysteries, and gaps play a big role in science fiction. All three of our examples fail at this, misusing secrets. They use secrets like Lost uses secrets.
Let's talk about secrets.
One of the most fundamental practices in science fiction is to leave huge gaps unexplained in order to create large spaces.
For example, "Khan Noonien Singh was a general in the Eugenics Wars..." That's a powerful statement. It creates a massive block of "space" - these unexplained Eugenics Wars are interesting, and their name is extremely powerful. They are tied into the story, but left unexplained.
On a different scale, "Romulan blue ale". It serves no real purpose to the story, but it creates a vast expanse in your mind: the Romulans have a culinary culture and it's interesting and weird! A tiny detail that serves to create a world without actually cementing anything down.
It also goes the other direction. The internal life of characters is often left implied. Science Fiction rarely spells out motivations and emotions as clearly as other genres do. You're left with people who act a little inexplicably at times, stare a bit too long, covet something a bit too much. This creates a space inside their life, a space the reader can sense but not see. An easy example of this is Obi Wan Kenobi. Why does he live in the desert? Why does he let Darth kill him? How does he have all of these powers? What the hell are these powers?
Part of the draw of the original movies was that they doled out most of these answers in a trickle, so you kept watching to see more of them. But many of them were never really filled in until decades later, and fan theories were everywhere. Alternate explanations exist for virtually everything - for example, some people have proposed that the droids are actually hugely important 'shadow leaders' of the rebellion... and there are enough gaps that this explanation can weave through them fairly convincingly.
Secrets, mysteries, and gaps create life in these universes. They do so in a very powerful way because they let the audience fill those gaps at their leisure, as they see fit.
I think I'm understating that last bit, so let me harp on it:
The audience fills the gaps with whatever they can.
This is the primary tool used to make science fiction accessible to a wider range of people. When scifi has few gaps, the only people it can appeal to are the people who are in tune with the story as it is being told. If every aspect of the Eugenics Wars is explained, then only people who can accept the specific details of why the war happened and how it developed can be interested. Everyone else will say "oh, that's not very interesting" or "oh, that's not very likely".
By leaving it a mystery, each reader can presume it happened in a specific way according to their current... level? Place? The current way their brain works. The more they think about it on their own, the more it falls in tune with their own thinking, and the more interesting it becomes. Used wisely, this trick makes the best scifi twists rip you apart: they gave you space to imagine and assume. Then they kick that out from under you and show you just how feeble your imaginings were.
Now, this isn't the only thing scifi does. A lot of people would say that Star Trek and Star Wars aren't even proper scifi, just fantasy dolled up with technotrappings. Well, leaving that argument aside, this particular practice of creating gaps is commonplace and very powerful. The practice of subverting what the audience puts in those gaps is also a common technique, mostly used when you want to create "mindfuck" scifi.
...
Back to Lain, Prometheus, and Infinite. There will be spoilers, but who the hell cares?
All three of these attempt to use that last technique - the "create a gap, let the audience imagine what's inside, then subvert that" method.
Unfortunately, they do it clumsily.
First off, what's in the gap is rarely a mystery. They attempt to obfuscate something relatively simple, but burying something simple in a fog doesn't make it complicated. The only way that can work is if the audience is so inexperienced that they can't recognize the simple shape of a stumbling transhumanist singularity (Lain), interconnected multiverse anchor (Infinite), or villainous ancients (Prometheus). These stories are SUPER COMMON. I've read dozens of each.
Secondly, rather than create a legitimate gap, they simply drop fog everywhere to obfuscate it. For example, if I say the phrase "scie_ce F_ction", there's not much mystery as to what is underneath those underscores. Fogging them up doesn't make my writing more interesting, it just makes me annoying. And, yeah, I could reveal that it's actually "science FACTION", but it's like, whatever, okay, there were a few options and you chose one of the slightly less common ones. It's not interesting.
Compare this to Satoshi Kon's work, such as Paranoia Agent. Or the anime that blew my mind as a kid, Armitage the Third.
These create legitimate gaps. Paranoia Agent creates gaps by being batshit, leaving you grasping at straws in a maelstrom. It reveals the pattern near the end, just slowly enough that you can start to understand how it all works, and then it rushes ahead to extrapolate what that would actually mean. This overwhelming and powerful technique works because the idea is not common, and it's revealed fast enough that you aren't given time to extrapolate.
Armitage the Third seems like a typical robots and androids anime - they were common at the time. And you enjoy it on that level, but something feels just a touch off. The reveal might not surprise anyone who's seen a lot of scifi, but at the time it was not something that was written about in American science fiction. It really surprised me and left me thoughtful.
You can also talk about how these are also about real-world cultural issues. Paranoia Agent is arguably about the self-destructive hollowness of modern society, and Armitage is about racial purity. Those things matter. They matter a lot. Not only do they tie the story to your life, they also tie the story to the lives of the people in the story. They give incredible power to the characters, because the characters are moving through the same space. They give power to the scenes, because those scenes have happened in the real world.
The fact that Armitage is about racial purity is what gives many of its scenes so much more power than other campy blockbusters with the same basic premise. The sight of burning robot bodies piled high is devastating because it's not about robots.
This is something that only becomes clear near the end - same with Paranoia Agent. You could even say that the twist of these science fiction pieces is simply that they are ABOUT SOMETHING.
Lain, Prometheus, and Infinite not only have dull reveals, they aren't about anything. They just waddle through what someone thought was a cool scifi premise without breathing life into anything.
Sigh.
I really like science fiction.
But if it doesn't grab your neck and leave you breathless for hours afterwards, don't accept it. It's not good enough.
Monday, August 04, 2014
Little Crashes
I took a while off Kerbal while I waited for 2.4 to come out. When it did come out, I had a lot of fun problems where missions went awry in humorous ways - not bad enough to revert the mission, but bad enough to make things complicated and wonky.
After a few days, I polished up my skills again and haven't really had any failures since. The only real mission screwups I've had for the past week or so have been when KSC decides it should unload my whole crew and just put in Jeb. While it was funny the first 100,000 times, that's starting to get a bit stale.
Anyway, I really enjoyed "partial failure" missions. Let's go over a few:
A rescue mission with too few seats, requiring one of the rescuers be left in space and another rescue mission launched to rescue him.
A mun lander that landed a bit too hard and destroyed all its engines, but still had all its science and life support intact. Required another launch to recover the science and the stranded astronaut.
A rover with a full load of monopropellant that I forgot to attach any RCS jets to. Required tipping and tilting at high speeds to rip monoprop tanks off to improve performance.
A science base without an antenna, requiring the aforementioned rover to dock with it to broadcast science. The rover's mission had landed on the opposite side of the mun, so it was a bit of a drive.
...
These kinds of issues tread a delicate line. They're just bad enough to change the mission profile, but not so severe that the mission needs to be scrapped.
All of these sample mistakes are user errors - forgetting something or misjudging something. The problem is that after a while, you stop misjudging and forgetting. The entertaining mistakes stop, and now you have much more boring issues. Slightly misaligned RCS jets, slight tilts on landing zones, forgetting to gather gravioli data above a specific biome. Having your crew replaced by just Jeb.
I really liked the clumsy errors. I want that back!
Let's try to design a game where the whole point is to adapt to missions going wrong, rather than creating missions that go right. Let's presume that the player does not create the missions, but tries to successfully complete them as things go wrong. Think of the missions as levels in any other game.
Missions are not levels, because a big part of the play is in how missions interact with each other. Do you need to send out a second mission to rescue the first one? Can you use a mission that landed before to complete the mission that came afterwards? Can you use this screwed-up mission as a stepping stone for another mission?
There's also the fun within the mission. Can you make things work with fewer resources? Can you adapt some of the mechanisms and supplies intended for one thing to serve another thing? Can you change the mission profile to accomplish things and stay alive even though you can no longer perform a fundamental task such as firing rocket engines?
There is also the fun of imagining what it'd be like to be living in those conditions - stuck alone on the moon for 3 weeks, carefully rationing out your power during the night cycle, going a little bit... idiosyncratic.
...
If we were to make a game like this, what would we need?
Well, first and foremost, we'd need a more adaptive system than Kerbal. Kerbal's adaptiveness is up front, in mission planning. When on the mission, the only things you can change or repair are landing legs/wheels. Everything else exists in a state of true/false: it's either there and working or gone completely.
Our game would need to feature a much wider variety of states. Damaged or broken equipment needs to be repairable, but not by simply floating over to it and clicking a button. Instead, we need to make systems repurposable.
Repurposing systems involves moving them, changing their function, or scrapping them for makeshift parts. The result should repair or augment another system, but not to a comfortable level. Part of the in-game requirement for repair-by-repurpose should be that it is awkward, full of annoying side effects, or radically lower/more expensive performance.
For example, if your CO2 filter is damaged, you should be able to repair it by sacrificing some other system. The water processing system, or maybe the edible bacteria system, or perhaps by scrapping your spare clothes (as when this actually happened), or perhaps by scuttling an engine for a specific, deeply-buried part. All of these methods will let the astronauts continue to breath.
But they all have downsides. Firstly, they decommission some important system intended for another role. You'll have to strictly ration water, food, clothes - perhaps you won't even be able to land at all, and will need to be rescued once you return to earth-local orbit.
Secondly, the new carbon scrubber is way more annoying. It's louder, or hotter, or colder, or smells, or some other defect that makes living in the space capsule a bit more nightmarish.
If it was something a bit less important, the repair could have functional flaws. The repaired lights use up too much power, so you need to keep them off 18 hours a day. The repaired solar panels can't be tilted towards the sun, so you have to make do with radically lower power intake, and maybe have to park your rover at a specific angle during the day to regenerate your battery store.
The basic idea is that you need to decommission another system, and then you need to live with not only the decommissioned system, but also the shortcomings of the repair job. Hey, it just has to last long enough to get the job done!
The player actually has a lot of freedom here. She has her choice of which systems to repurpose, and that will depend a lot on what she plans to do with the rest of the mission, combined with what other repairs she needs to make.
For example, if you need to repair the carbon scrubber, your first instinct might be to sacrifice the spare clothes, as they serve the least mission-critical part of the mission. However, that system has no additional parts, and cannot be used to repair anything else afterwards. If you decide to sacrifice the rocket engine, then you have a massive slew of additional rocket parts and fuel (perhaps even hydrogen-oxygen fuel that can create water). If anything else goes wrong, you can probably repair it from the already-sacrificed rocket engine.
Similarly, if you had another moon base a few hundred kilometers away, rather than sacrifice any of your systems, it might make sense to scrap that base and haul over those components.
And it'll matter how long it'll take for you to try and rescue them. Do you need a week? Sacrificing spare clothes is probably the least dangerous option. Do you need three months? Sacrifice the engine, keep the astronauts happier and healthier.
...
Seems like it'd be an easy game to make, if you keep the interface simple!
After a few days, I polished up my skills again and haven't really had any failures since. The only real mission screwups I've had for the past week or so have been when KSC decides it should unload my whole crew and just put in Jeb. While it was funny the first 100,000 times, that's starting to get a bit stale.
Anyway, I really enjoyed "partial failure" missions. Let's go over a few:
A rescue mission with too few seats, requiring one of the rescuers be left in space and another rescue mission launched to rescue him.
A mun lander that landed a bit too hard and destroyed all its engines, but still had all its science and life support intact. Required another launch to recover the science and the stranded astronaut.
A rover with a full load of monopropellant that I forgot to attach any RCS jets to. Required tipping and tilting at high speeds to rip monoprop tanks off to improve performance.
A science base without an antenna, requiring the aforementioned rover to dock with it to broadcast science. The rover's mission had landed on the opposite side of the mun, so it was a bit of a drive.
...
These kinds of issues tread a delicate line. They're just bad enough to change the mission profile, but not so severe that the mission needs to be scrapped.
All of these sample mistakes are user errors - forgetting something or misjudging something. The problem is that after a while, you stop misjudging and forgetting. The entertaining mistakes stop, and now you have much more boring issues. Slightly misaligned RCS jets, slight tilts on landing zones, forgetting to gather gravioli data above a specific biome. Having your crew replaced by just Jeb.
I really liked the clumsy errors. I want that back!
Let's try to design a game where the whole point is to adapt to missions going wrong, rather than creating missions that go right. Let's presume that the player does not create the missions, but tries to successfully complete them as things go wrong. Think of the missions as levels in any other game.
Missions are not levels, because a big part of the play is in how missions interact with each other. Do you need to send out a second mission to rescue the first one? Can you use a mission that landed before to complete the mission that came afterwards? Can you use this screwed-up mission as a stepping stone for another mission?
There's also the fun within the mission. Can you make things work with fewer resources? Can you adapt some of the mechanisms and supplies intended for one thing to serve another thing? Can you change the mission profile to accomplish things and stay alive even though you can no longer perform a fundamental task such as firing rocket engines?
There is also the fun of imagining what it'd be like to be living in those conditions - stuck alone on the moon for 3 weeks, carefully rationing out your power during the night cycle, going a little bit... idiosyncratic.
...
If we were to make a game like this, what would we need?
Well, first and foremost, we'd need a more adaptive system than Kerbal. Kerbal's adaptiveness is up front, in mission planning. When on the mission, the only things you can change or repair are landing legs/wheels. Everything else exists in a state of true/false: it's either there and working or gone completely.
Our game would need to feature a much wider variety of states. Damaged or broken equipment needs to be repairable, but not by simply floating over to it and clicking a button. Instead, we need to make systems repurposable.
Repurposing systems involves moving them, changing their function, or scrapping them for makeshift parts. The result should repair or augment another system, but not to a comfortable level. Part of the in-game requirement for repair-by-repurpose should be that it is awkward, full of annoying side effects, or radically lower/more expensive performance.
For example, if your CO2 filter is damaged, you should be able to repair it by sacrificing some other system. The water processing system, or maybe the edible bacteria system, or perhaps by scrapping your spare clothes (as when this actually happened), or perhaps by scuttling an engine for a specific, deeply-buried part. All of these methods will let the astronauts continue to breath.
But they all have downsides. Firstly, they decommission some important system intended for another role. You'll have to strictly ration water, food, clothes - perhaps you won't even be able to land at all, and will need to be rescued once you return to earth-local orbit.
Secondly, the new carbon scrubber is way more annoying. It's louder, or hotter, or colder, or smells, or some other defect that makes living in the space capsule a bit more nightmarish.
If it was something a bit less important, the repair could have functional flaws. The repaired lights use up too much power, so you need to keep them off 18 hours a day. The repaired solar panels can't be tilted towards the sun, so you have to make do with radically lower power intake, and maybe have to park your rover at a specific angle during the day to regenerate your battery store.
The basic idea is that you need to decommission another system, and then you need to live with not only the decommissioned system, but also the shortcomings of the repair job. Hey, it just has to last long enough to get the job done!
The player actually has a lot of freedom here. She has her choice of which systems to repurpose, and that will depend a lot on what she plans to do with the rest of the mission, combined with what other repairs she needs to make.
For example, if you need to repair the carbon scrubber, your first instinct might be to sacrifice the spare clothes, as they serve the least mission-critical part of the mission. However, that system has no additional parts, and cannot be used to repair anything else afterwards. If you decide to sacrifice the rocket engine, then you have a massive slew of additional rocket parts and fuel (perhaps even hydrogen-oxygen fuel that can create water). If anything else goes wrong, you can probably repair it from the already-sacrificed rocket engine.
Similarly, if you had another moon base a few hundred kilometers away, rather than sacrifice any of your systems, it might make sense to scrap that base and haul over those components.
And it'll matter how long it'll take for you to try and rescue them. Do you need a week? Sacrificing spare clothes is probably the least dangerous option. Do you need three months? Sacrifice the engine, keep the astronauts happier and healthier.
...
Seems like it'd be an easy game to make, if you keep the interface simple!
Subscribe to:
Posts (Atom)