I was thinking about childish depictions of mad scientists and construction. Typically, they use everyday objects in ways that almost make sense, but not quite.
For example, in the new Luigi's Haunted Mansion game, the scientist cleans shards of the moon crystal by sticking them on a record-player turntable and spinning it around while scrub-brushes happen to be nearby.
The trope is hardly new. The Incredible Machine is a whole series of games about misusing common devices such as balloons, lighters, and mousetraps to accomplish whatever weird objectives you might have.
I got to thinking about this when I saw a preview of the new Terraria version. It was raining, and a lot of the enemies broke out rain gear. One of the players said they were going to kill a slime because they wanted the umbrella. The slime kicked his ass, so I never learned whether he could have gotten that umbrella, but the idea gelled a bit in my head.
I love constructive games, but one of the biggest issues with them is the functionality of the various pieces you get. If you expand the breadth of parts and functionality, you will start to drown the player in complexly nuanced alternatives that are hard to tell apart. For example, in lightly modded Kerbal, there are fifty different rocket engines. They do all have different stats. Some are vectored, some perform better at sea level, some in vacuum... but they blur together because there's so many of them. You'll typically just choose one for each size category and stick with it.
But if you misuse objects, then they come with additional color context that keeps them feeling distinct. Moreover, if the ability to misuse them is flexible enough, you can also make it easy for mods to add new items and encourage their misuse.
For example, an umbrella. You could see it being added to the game, and the stats are put in. What is it useful for? It, uh, it keeps the rain off your head when you hold it? Not terribly exciting. Maybe you add in the ability to strip it down for resources.
But what if we allowed the player to creatively misuse the umbrella?
The umbrella sheds falling water. If falling water matters, you could mount an umbrella in places to shunt water away - for example, to keep a candle lit, or with a whole bunch of them to serve as a roof. If our physics is decent, then shedding water is the same as being water resistant, so flipping the umbrella upside-down would allow it to become a boat or a water-holding dish. Sure, with low maximum strain, but that's fine.
The added capability of the umbrella to open and close allows you to use the water-shedding/retaining abilities more freely, while the existence of the handle offers a specific mount/control point. So you could create a rain-shade that moves umbrellas out and flicks them open when it rains, and does the opposite when it's sunny.
But the existence of the flip-open mechanism can be used without the water-shedding capability of the umbrella itself. You could use it to nudge things. Glue a string to the umbrella and yank on it by opening and closing. You can also use non-water things - use the umbrella to contain helium, or dog food. Whatever.
You could also go cartoony: the drag on the umbrella acts as a parachute when open. This makes it both more valuable to equip and also suitable for even more misuse if you build devices that go into the air or need to fall slowly.
Anyway, when someone mods in an umbrella, if they know what they're doing they can build it so that the player can misuse it in a fantastic number of fun ways. Moreover, if someone else mods in slimes carrying around umbrellas when it rains, this changes the context and common-ness of the umbrella, effectively completely changing its nature. People who would never have bothered using umbrellas as design objects now find they have plenty of them, and start to look for ways to use them.
The fact that they are umbrellas rather than "extendo-joints" adds a lot to the context and memorability of them. It also allows us to package several distinct pieces of functionality into one object but still make it easy to remember: everyone knows how an umbrella works, so when you see it operating as part of a device, you can quickly grasp that it can open and close and keep water out and is pretty light and so on. There's no mystery. It's one composite object with a lot of functions and attributes... and we already know them all! With a glance!
A lot of modern mechanisms are a bit too slick for this, which is why turn-of-the-20th-century mechanisms are so popular. A vacuum does specific things in grand strokes, and it can be misused in all sorts of delightful ways. A cell phone, however, has a much more nuanced and complex set of operations that makes it difficult to misuse, unless you simplify it down to "vibrates when called".
Any way you cut it, though, adding in these complex, context-heavy items and allowing the player to misuse them should allow for a more vibrant world, and a wider variety of items without the feeling of drowning in variations.
Thursday, September 26, 2013
Wednesday, September 25, 2013
Secrets in an Open World
I was thinking about exploration as a core part of games.
A big part of open worlds is exploration, yes. Awkwardly, they are also incredibly bad at it: most open worlds have very little worth discovering, and most are vast empty areas with just vague variations in layout. This is especially true in generative open-world games like Minecraft.
Minecraft and other generative world games such as Dwarf Fortress, Terraria, and so on do have interesting things to discover, and exploring is rather fun. In the long run, however, these games boil down less to exploring interesting new areas and more to figuring out which preset terrains are nearby and which you have to go search for. What I mean is that, while the world is endless, the secrets are not. Experienced players are not exploring so much as exploiting known terrains.
Of course, non-generative worlds have the same problem, but in those games you play through the game and stop. In a constructive open-world game, you can keep playing pretty much forever. So it makes sense for a constructive open-world game to allow for exploration forever.
Sounds nice, but there's a lot of barriers to this.
The first barrier is the easy one: pacing. In a constructive game, you tend to construct things. This typically means establishing a home. You need to be careful how you define the concept of "home" and "travel" so that even after the player has built a home, they can continue to explore. As far as I know, that means one of three things.
1) The home is portable (a space ship, for example).
2) Travel is often via teleportation or some similar method.
3) The home is temporary, or some other means of making the player create new homes in new places all the time.
The second barrier is much more difficult: you need to have an infinite number of interesting secrets to explore.
Normally, secrets are custom content by the developer. For example, pre-existing mines in Minecraft, randomized super-monsters in Dwarf Fortress, jet packs in Terraria... it's entertaining, but obviously limited. Even if you try to make it never-ending (for example, by randomizing the nature of each super-monster) it still remains a known thing... just a random variation on that known thing.
This brings up the question of what "new" content really is. If I build a fortress and find a demon on Monday and again on Friday, the demons might be different enough that they provide radically different kinds of challenges. The rareness of the content and the high variability means that I'm always taking a gamble.
On the other hand, if I dig down into corruption in Terraria, it becomes pretty rote after a while. It's a common part of each adventure, and even though the layout varies, you quickly figure out various optimal approaches and go into it with the proper equipment.
To be honest, I think that last bit is important. "Proper equipment".
I think "new" doesn't necessarily have to be completely new. It just has to be a new kind of challenge to make you think on your feet. If you know the parameters of what will happen and you're prepared for them, it's not exploration. It's just mining, just a skill challenge.
To that end, I think this question of "how do you give infinite new secrets" is actually two questions: "how do you give infinite new content" and "how do you continually reframe it to keep the player off-balance".
Reframing is a game design decision of the most basic sort. You have to create a game where the player cannot always be "ready", but you still need to allow them to create - since that's the point of the game. There are a lot of options.
One is that the things the player creates are orthogonal to the content in exploration. That is, the player can create their character's appearance, but not equipment. They can create a castle, but when they go to explore they can't bring anything in it with them. The problem with this approach is that reducing the player to a specific baseline power level is just as static a frame as allowing them to perfectly prepare.
So the other option is to somehow come up with ways to allow them to have erratic power-ups based on their creations. For example, they bring two random items from their stack. Or they keep jumping into the body of a random new colonist, who is equipped with whatever the colony provided her to do her job.
You can also offer unique and varying debuffs, such as metal being forbidden in a given cave, or turning the player into a frog. Granting random upgrades has the same effect - allowing the player to fly will shake up the frame just as much as disabling their jump.
In all cases, balance is tough to maintain. It becomes more and more difficult to guarantee that a given piece of content can actually BE explored. Rather than trying to fix that, it's probably best to embrace it. Let the player come back and make steady progress later, but always with a shaky frame, always with shaky prep. Failing is fine, whether you die or go home.
Anyway, with the frame-shaking in place, we can talk about the big nasty: content.
Exploration requires content. And not just any content: meaningful content. Content that the player will notice.
There are a few subtypes of this.
1) Skill challenge content. This is the sort of content offered by something like Spelunky, where randomly generated segments challenge your mastery of the gameplay. May also be puzzles that challenge your mind - it's the same basic idea. A skill challenge. These can be largely randomized.
2) Color content. This is content that sets a mood and helps pace the play. This is difficult to create randomly just because it needs to vary, but it includes things like grottos, overlooks, tunnels decorated with appropriate objects, shattered columns, polished mirror-walls... things that the player notices when they are in any given area, but don't really have any gameplay purpose. Color content is best when it has context - that is, when the content meshes well with the upcoming/ongoing challenges.
3) Narrative content. Sometimes overlapping with color content, narrative content strongly implies that something is/did/will happen/ning/ed, and typically creates implicit sidequests or, at least, side-narratives. For example, a locked door, the key somewhere else, and the clue to help you find the key. Messages about a monster, scrawled in blood on the wall. A fairy prince who helpfully takes you on a tour of the castle. An alien spaceship hanging in orbit, apparently dead. A ring with a name etched into it.
4) Mechanical content. This is content that has strongly idiosyncratic mechanical functions. This can be mechanical as in actual gears and such, but it usually refers to the game mechanics. For example, if you're generating new monsters, you'll want to be able to generate new abilities for them to use in combat. Just adding a die of damage or a bit of health won't make the monster feel mechanically special. But allowing monsters to have extremely unique and far-ranging abilities will make them a challenge, especially since those abilities will frequently interact with the other three types of content.
All four of these kinds of content can be generated algorithmically, usually by defining prescripted segments. You grab the pieces, alter some details, and glue them together with other randomly-grabbed pieces.
But that only lasts so long, and it's pretty expensive to add in more fundamental content.
So the other option, of course, is to use player-generated content. Since we're talking about a constructive game, that's obviously a good idea. They're already building things, after all.
The problem is mechanical content.
The other three can be created by players. In fact, you can shape your game such that they make those things incidentally as they play, so there's no barrier to resharing it. But mechanical content is both the most difficult and the most important.
I'm not sure how to accomplish it, aside from letting players make mods for your game.
Hm. Just to make things complicated, in a constructive game nearly all mechanical content will relate to objects which can be incorporated into player constructions.
HM.
I feel like there's actually an easy way to do this. I just can't quite see it.
A big part of open worlds is exploration, yes. Awkwardly, they are also incredibly bad at it: most open worlds have very little worth discovering, and most are vast empty areas with just vague variations in layout. This is especially true in generative open-world games like Minecraft.
Minecraft and other generative world games such as Dwarf Fortress, Terraria, and so on do have interesting things to discover, and exploring is rather fun. In the long run, however, these games boil down less to exploring interesting new areas and more to figuring out which preset terrains are nearby and which you have to go search for. What I mean is that, while the world is endless, the secrets are not. Experienced players are not exploring so much as exploiting known terrains.
Of course, non-generative worlds have the same problem, but in those games you play through the game and stop. In a constructive open-world game, you can keep playing pretty much forever. So it makes sense for a constructive open-world game to allow for exploration forever.
Sounds nice, but there's a lot of barriers to this.
The first barrier is the easy one: pacing. In a constructive game, you tend to construct things. This typically means establishing a home. You need to be careful how you define the concept of "home" and "travel" so that even after the player has built a home, they can continue to explore. As far as I know, that means one of three things.
1) The home is portable (a space ship, for example).
2) Travel is often via teleportation or some similar method.
3) The home is temporary, or some other means of making the player create new homes in new places all the time.
The second barrier is much more difficult: you need to have an infinite number of interesting secrets to explore.
Normally, secrets are custom content by the developer. For example, pre-existing mines in Minecraft, randomized super-monsters in Dwarf Fortress, jet packs in Terraria... it's entertaining, but obviously limited. Even if you try to make it never-ending (for example, by randomizing the nature of each super-monster) it still remains a known thing... just a random variation on that known thing.
This brings up the question of what "new" content really is. If I build a fortress and find a demon on Monday and again on Friday, the demons might be different enough that they provide radically different kinds of challenges. The rareness of the content and the high variability means that I'm always taking a gamble.
On the other hand, if I dig down into corruption in Terraria, it becomes pretty rote after a while. It's a common part of each adventure, and even though the layout varies, you quickly figure out various optimal approaches and go into it with the proper equipment.
To be honest, I think that last bit is important. "Proper equipment".
I think "new" doesn't necessarily have to be completely new. It just has to be a new kind of challenge to make you think on your feet. If you know the parameters of what will happen and you're prepared for them, it's not exploration. It's just mining, just a skill challenge.
To that end, I think this question of "how do you give infinite new secrets" is actually two questions: "how do you give infinite new content" and "how do you continually reframe it to keep the player off-balance".
Reframing is a game design decision of the most basic sort. You have to create a game where the player cannot always be "ready", but you still need to allow them to create - since that's the point of the game. There are a lot of options.
One is that the things the player creates are orthogonal to the content in exploration. That is, the player can create their character's appearance, but not equipment. They can create a castle, but when they go to explore they can't bring anything in it with them. The problem with this approach is that reducing the player to a specific baseline power level is just as static a frame as allowing them to perfectly prepare.
So the other option is to somehow come up with ways to allow them to have erratic power-ups based on their creations. For example, they bring two random items from their stack. Or they keep jumping into the body of a random new colonist, who is equipped with whatever the colony provided her to do her job.
You can also offer unique and varying debuffs, such as metal being forbidden in a given cave, or turning the player into a frog. Granting random upgrades has the same effect - allowing the player to fly will shake up the frame just as much as disabling their jump.
In all cases, balance is tough to maintain. It becomes more and more difficult to guarantee that a given piece of content can actually BE explored. Rather than trying to fix that, it's probably best to embrace it. Let the player come back and make steady progress later, but always with a shaky frame, always with shaky prep. Failing is fine, whether you die or go home.
Anyway, with the frame-shaking in place, we can talk about the big nasty: content.
Exploration requires content. And not just any content: meaningful content. Content that the player will notice.
There are a few subtypes of this.
1) Skill challenge content. This is the sort of content offered by something like Spelunky, where randomly generated segments challenge your mastery of the gameplay. May also be puzzles that challenge your mind - it's the same basic idea. A skill challenge. These can be largely randomized.
2) Color content. This is content that sets a mood and helps pace the play. This is difficult to create randomly just because it needs to vary, but it includes things like grottos, overlooks, tunnels decorated with appropriate objects, shattered columns, polished mirror-walls... things that the player notices when they are in any given area, but don't really have any gameplay purpose. Color content is best when it has context - that is, when the content meshes well with the upcoming/ongoing challenges.
3) Narrative content. Sometimes overlapping with color content, narrative content strongly implies that something is/did/will happen/ning/ed, and typically creates implicit sidequests or, at least, side-narratives. For example, a locked door, the key somewhere else, and the clue to help you find the key. Messages about a monster, scrawled in blood on the wall. A fairy prince who helpfully takes you on a tour of the castle. An alien spaceship hanging in orbit, apparently dead. A ring with a name etched into it.
4) Mechanical content. This is content that has strongly idiosyncratic mechanical functions. This can be mechanical as in actual gears and such, but it usually refers to the game mechanics. For example, if you're generating new monsters, you'll want to be able to generate new abilities for them to use in combat. Just adding a die of damage or a bit of health won't make the monster feel mechanically special. But allowing monsters to have extremely unique and far-ranging abilities will make them a challenge, especially since those abilities will frequently interact with the other three types of content.
All four of these kinds of content can be generated algorithmically, usually by defining prescripted segments. You grab the pieces, alter some details, and glue them together with other randomly-grabbed pieces.
But that only lasts so long, and it's pretty expensive to add in more fundamental content.
So the other option, of course, is to use player-generated content. Since we're talking about a constructive game, that's obviously a good idea. They're already building things, after all.
The problem is mechanical content.
The other three can be created by players. In fact, you can shape your game such that they make those things incidentally as they play, so there's no barrier to resharing it. But mechanical content is both the most difficult and the most important.
I'm not sure how to accomplish it, aside from letting players make mods for your game.
Hm. Just to make things complicated, in a constructive game nearly all mechanical content will relate to objects which can be incorporated into player constructions.
HM.
I feel like there's actually an easy way to do this. I just can't quite see it.
Monday, September 23, 2013
Lands of Godus
This is a rambling discussion of terraforming as a gameplay mechanic. It's me refining some design details for my mech game.
So, yes, I've been playing Godus on and off since it went into public beta. This is not really a review of Godus, although I do have to talk about Godus to get to what I want to talk about.
I really like the land in Godus. Now, the actual process of terraforming it is quite clunky, but the feel of the land itself is incredibly nice. The fine layers end up building some really nice layouts.
For example, when chasing buried treasure, I ended up digging a deep "bore hole". When building a flat region for a "village", I created some hundred-foot-high pure, sheer cliffs that broke into jagged regions at the edges. When created stepped terrace "villages", I ended up with a beautiful, meandering hilly village.
The feel of the land is spectacular.
Unfortunately, the game itself is pretty crap. But the feel of the land sticks with me. I keep going back for a few minutes each day, not because I care about the game, but because reshaping the land results in very compelling results.
I thought about how to make a game more intricately linked with this kind of land. Godus is just about flattening everything down for human use, which is a very dull kind of landscape to aim for. I started to think about other kinds of uses and aims we might have. Also, since my focus is on science fiction, I'm not thinking about primitive human villages.
So, a big part of the feel of the terrain comes from variation in height. I feel most interested when I create interesting topologies. Cliffs, boreholes, terraces, patchy surfaces. What use could they have?
My concept is basically to make the surface of the planet into a Minecraft-style crafting bench. When you want to build a building, you have a certain size frame in orbit. You call up a reticle, and it highlights an area on the map the same size as the frame. The building that will be constructed depends on the topology of the surface.
If it's just a flat region, you'll build a hab module (at one particular size). On the other hand, if there's a borehole there, you'll build a water trap. If there's a little bump in the center, you'll build a mech assembly tower. If it's a gentle slope, you'll build a terraced vacu-farm. This can be made more complex by having special tiles inside the reticle, such as ore or trees or water or something. It's not just height, but also resource.
This is one way I plan to force the player to spread their colonies across a planetoid instead of just putting everything down in one spot: the resources will be scattered around, so if you want a functioning society on a planetoid, you'll need to have different kinds of colonies specializing in different things in different places.
Unlike Minecraft, the resource tiles are not actually a single tile of that resource, but are simply markers indicating that a tile has access to that resource. For example, an icy tile. You could certainly chip it out and walk away with a block of rock with some ice on it, but that's not a resource tile, it's just some resource. The ice tile in the wild represents the way ice will form in that spot, and therefore a building on top of it will be able to rely on a steady ice diet. Similarly, an iron ore tile doesn't mean there's iron on the surface, but instead represents that there is iron somewhere beneath that tile. A mining building will dig down to the deep ore, but stripping away a few surface layers won't get you much if any actual ore.
This offers a means to help us create interesting terraforming opportunities, because we can talk about resource husbandry.
What causes an icy surface to form on the dust and rock? Well, ice forms in areas that are constantly in shadow. This means that you can create environments which create icy tiles by carving down or building up such that there is a shadow. The height and direction of the wall you'll need to create depends on the latitude you're at. If you're at a pole, the sun will hang low on the horizon, and a single layer of land will cast enough shadow to keep an area perpetually in shadow. Nearer the equator, you'll have to build a very deep hole - and even then, the ice may fade in the summer.
This is a pretty simple system, right? But it creates vast amounts of potential.
For example, what if we want to start terraforming our landscape? We want to create a stream. Well, one way to do it is to create a lot of ice patches and, when they melt in the summer sun, a trickle of water will flow from each. By etching courses into the landscape, you can control this trickle of water and cause it to course along a specific route. Life could grow in the waters, especially if you direct them into still pools that might be able to last until next spring. With enough time and effort, you could even start to grow plants from that water.
This terraforming has nothing to do with putting down buildings or colonies. We create a landscape that serves other purposes. Environmental resources and hazards - weather, radiation, heat, cold, water - respond to the shape of the land to some degree. So we can adapt the world to suit our needs.
A big question with this sort of thing is "what about caves?"
Caves would obviously allow for shadow even at noon, and allow for shelter from wind no matter what the time, and so on. But caves are a complicated topic. They could be a whole game in themselves.
So I don't think I'll allow for caves.
I mean, players can create them because they can alter the surface of the world, but buildings are dropped from orbit, so any kind of overhang prevents structural construction. There might be some way to use overhangs to help generate resources (or you could encase a building after the fact), but the downsides would all be severe enough to make it a curiosity instead of a primary method. It's just too much of a pain to implement the complexities of caves.
Cliffs, on the other hand, have an important role to play. In addition to looking cool, cliffs offer shade and protection from storms. Unlike in a cave, you can still use solar power and transmit radio signals into orbit when you're up against a cliff. So cliffs are useful, especially in areas where the sun is harsh or there is an atmosphere. In addition, some kinds of life will prefer to form between layers of rock, so cliffs would be ideal for them. Another kind of resource husbandry system.
Aside from the raw terraforming, there's also seasons and days. Every planetoid has seasons and days - many of them unreasonably long or short. The flow of husbanded resources (such as shade, ice, life, etc) will change over the seasons, or even from day to night. This means that a building which relies on ice might be robbed of ice for long stretches of time, essentially useless for much of the year. Perhaps building the walls up higher will extend that lifespan...
All of this is fine, but it doesn't change the fact that right now my prototype uses ugly square bricks. A big part of what makes the Godus terrain so inviting is that it is gently curved.
It's actually not too hard to do that same thing with my terrain, but it is worth mentioning that the UV mapping might be really annoying, especially when one layer has several different kinds of bricks. Also, I don't think Godus simply uses rounded square terrain. I haven't really looked into it in detail, but it looks like it either uses hex terrain or square terrain with alternately-weighted columns/rows.
Well, I should be able to design something vaguely decent on that front.
Hm. This was a lot more rambly than anticipated.
I'm never sure whether to publish these rambling essays or not. They're mostly me thinking to myself.
Well, I guess there's no limited page count, so I'll publish.
So, yes, I've been playing Godus on and off since it went into public beta. This is not really a review of Godus, although I do have to talk about Godus to get to what I want to talk about.
I really like the land in Godus. Now, the actual process of terraforming it is quite clunky, but the feel of the land itself is incredibly nice. The fine layers end up building some really nice layouts.
For example, when chasing buried treasure, I ended up digging a deep "bore hole". When building a flat region for a "village", I created some hundred-foot-high pure, sheer cliffs that broke into jagged regions at the edges. When created stepped terrace "villages", I ended up with a beautiful, meandering hilly village.
The feel of the land is spectacular.
Unfortunately, the game itself is pretty crap. But the feel of the land sticks with me. I keep going back for a few minutes each day, not because I care about the game, but because reshaping the land results in very compelling results.
I thought about how to make a game more intricately linked with this kind of land. Godus is just about flattening everything down for human use, which is a very dull kind of landscape to aim for. I started to think about other kinds of uses and aims we might have. Also, since my focus is on science fiction, I'm not thinking about primitive human villages.
So, a big part of the feel of the terrain comes from variation in height. I feel most interested when I create interesting topologies. Cliffs, boreholes, terraces, patchy surfaces. What use could they have?
My concept is basically to make the surface of the planet into a Minecraft-style crafting bench. When you want to build a building, you have a certain size frame in orbit. You call up a reticle, and it highlights an area on the map the same size as the frame. The building that will be constructed depends on the topology of the surface.
If it's just a flat region, you'll build a hab module (at one particular size). On the other hand, if there's a borehole there, you'll build a water trap. If there's a little bump in the center, you'll build a mech assembly tower. If it's a gentle slope, you'll build a terraced vacu-farm. This can be made more complex by having special tiles inside the reticle, such as ore or trees or water or something. It's not just height, but also resource.
This is one way I plan to force the player to spread their colonies across a planetoid instead of just putting everything down in one spot: the resources will be scattered around, so if you want a functioning society on a planetoid, you'll need to have different kinds of colonies specializing in different things in different places.
Unlike Minecraft, the resource tiles are not actually a single tile of that resource, but are simply markers indicating that a tile has access to that resource. For example, an icy tile. You could certainly chip it out and walk away with a block of rock with some ice on it, but that's not a resource tile, it's just some resource. The ice tile in the wild represents the way ice will form in that spot, and therefore a building on top of it will be able to rely on a steady ice diet. Similarly, an iron ore tile doesn't mean there's iron on the surface, but instead represents that there is iron somewhere beneath that tile. A mining building will dig down to the deep ore, but stripping away a few surface layers won't get you much if any actual ore.
This offers a means to help us create interesting terraforming opportunities, because we can talk about resource husbandry.
What causes an icy surface to form on the dust and rock? Well, ice forms in areas that are constantly in shadow. This means that you can create environments which create icy tiles by carving down or building up such that there is a shadow. The height and direction of the wall you'll need to create depends on the latitude you're at. If you're at a pole, the sun will hang low on the horizon, and a single layer of land will cast enough shadow to keep an area perpetually in shadow. Nearer the equator, you'll have to build a very deep hole - and even then, the ice may fade in the summer.
This is a pretty simple system, right? But it creates vast amounts of potential.
For example, what if we want to start terraforming our landscape? We want to create a stream. Well, one way to do it is to create a lot of ice patches and, when they melt in the summer sun, a trickle of water will flow from each. By etching courses into the landscape, you can control this trickle of water and cause it to course along a specific route. Life could grow in the waters, especially if you direct them into still pools that might be able to last until next spring. With enough time and effort, you could even start to grow plants from that water.
This terraforming has nothing to do with putting down buildings or colonies. We create a landscape that serves other purposes. Environmental resources and hazards - weather, radiation, heat, cold, water - respond to the shape of the land to some degree. So we can adapt the world to suit our needs.
A big question with this sort of thing is "what about caves?"
Caves would obviously allow for shadow even at noon, and allow for shelter from wind no matter what the time, and so on. But caves are a complicated topic. They could be a whole game in themselves.
So I don't think I'll allow for caves.
I mean, players can create them because they can alter the surface of the world, but buildings are dropped from orbit, so any kind of overhang prevents structural construction. There might be some way to use overhangs to help generate resources (or you could encase a building after the fact), but the downsides would all be severe enough to make it a curiosity instead of a primary method. It's just too much of a pain to implement the complexities of caves.
Cliffs, on the other hand, have an important role to play. In addition to looking cool, cliffs offer shade and protection from storms. Unlike in a cave, you can still use solar power and transmit radio signals into orbit when you're up against a cliff. So cliffs are useful, especially in areas where the sun is harsh or there is an atmosphere. In addition, some kinds of life will prefer to form between layers of rock, so cliffs would be ideal for them. Another kind of resource husbandry system.
Aside from the raw terraforming, there's also seasons and days. Every planetoid has seasons and days - many of them unreasonably long or short. The flow of husbanded resources (such as shade, ice, life, etc) will change over the seasons, or even from day to night. This means that a building which relies on ice might be robbed of ice for long stretches of time, essentially useless for much of the year. Perhaps building the walls up higher will extend that lifespan...
All of this is fine, but it doesn't change the fact that right now my prototype uses ugly square bricks. A big part of what makes the Godus terrain so inviting is that it is gently curved.
It's actually not too hard to do that same thing with my terrain, but it is worth mentioning that the UV mapping might be really annoying, especially when one layer has several different kinds of bricks. Also, I don't think Godus simply uses rounded square terrain. I haven't really looked into it in detail, but it looks like it either uses hex terrain or square terrain with alternately-weighted columns/rows.
Well, I should be able to design something vaguely decent on that front.
Hm. This was a lot more rambly than anticipated.
I'm never sure whether to publish these rambling essays or not. They're mostly me thinking to myself.
Well, I guess there's no limited page count, so I'll publish.
Thursday, September 19, 2013
Fun in the Mech-Moment
One of the things I've always struggled with is that I really like making games where you can build things, but I also really like making games where you get a really interesting moment-to-moment feel. The two don't really intersect.
As an example of moment-to-moment feel, think about Crackdown (or Saints Row IV). Moving your character around is fun. Think about a good racing game. Think about Pilotwings. Spider-Man 2. There's a simple joy in moving around that comes from a combination of very tight controls mixed with skill challenges. It's fun to move around AND there's an interesting place to move around in, basically.
I made Astrophobia with that kind of thing in mind, although it wasn't "fun" so much as "atmospheric". But... I was having a really hard time enthusing myself to actually turn it into a game, because there's no construction involved.
So I started to think about construction and movement in the same moment. And I started thinking about mecha. Mecha are actually far more suited to construction than combat, and they're large enough to give you a range of view that allows you to build things.
In terms of construction, I have some fun thoughts on that involving a slightly bizarre combination of Minecraft's crafting bench and Populus' land-clearing... but in order to make it worth playing, the mech has to be fun to pilot.
In oldschool mech games, the piloting was an ongoing strategic challenge rather than actually being fun in and of itself. Nobody played Mechwarrior because they enjoyed slowly slouching behind a hill. They slowly slouched behind the hill because they liked playing Mechwarrior.
Newer mech games tend to have mechs that move like first person shooter heroes, blitzing around the game map like crazed weasels. But speed doesn't make piloting them fun, it just reshapes the combat. Piloting the mech is occasionally fun, but more often than not it's still just an ongoing strategic challenge, just like movement in Quake 3 or Left For Dead or whatever.
I was considering, then, how to make a mech fun to pilot. How do you make the player go "HOLY MOLY I JUST WANT TO RUN AROUND AND LOOK AT STUFF IN THIS MECH"?
A lot of the fun in games like Crackdown come from a striking verticality and a lot of collectibles. The collectibles pull you to the next building, while the verticality provides a roughness to the motion that requires you to be vaguely skilled and strategic, switching between climbing, running, jumping, and gliding.
While we could try to make our planets more vertical, that's not really a great idea because our verticality would be broken terrain, which wouldn't be all that fun to navigate. We do want some verticality, especially in specific challenging areas (mountains), but in general verticality will have to play a much smaller role due to our lack of structured surfaces.
To replace it, I plan to use surface type.
Think about a typical airless rock like our moon. Its surface is shaped primarily by meteor hits. Craters on top of craters.
While it may not be perfectly accurate, we can model these surfaces as having different textures. The bottom of the bowl of the crater has been blasted flat down to the rock, so it's a hard, relatively smooth surface. The lip of the crater is where the heavy debris fall, so it's got a kind of heavy dirt-like texture. Outside of the crater is where the light debris (dust and sand) land. The rays radiating from the impact are where large pieces of debris skidded along the surface, clearing a swath clean of dust and leaving bare rock.
As a mech, you would navigate these different areas in different ways. The flat, hard surfaces can be simply walked/dashed across, and you can land or leap without damaging them (unless you're a really heavy mech). The dirt-like slopes are generally amenable to you, especially if you're a lighter mech, but they are slopes and you do leave footprints as you pack down the dirt, even perhaps sliding down the slope. It'd be better to switch to whatever high-traction mode you have, perhaps even using your hands if the slope is severe.
The dust areas... well, dust is basically a liquid to something like a mech. You can walk through it, of course, but you'll sink in it. Throw up huge clouds of dust if you're moving quick or landing, reshaping the dust fields into dust dunes. Drowning in dust is hard on your joints and/or intakes, of course.
But navigating dust doesn't have to be a pain. You just have to change your mindset. You can leap across dust fields - landing in the dust with jets a-blazin will drive it away, then you can jump again before you get swallowed in it. Or have a ski mode where you have jets propel you along on skis. You'll kick up dust, yeah, but it'll all be behind you. Just remember to change back into foot mode when you reach rock... you might even have to jump over that ray where there's exposed rock.
Planets with atmospheres have a different jumble of terrains, but it's still the same kind of deal where you switch stances or navigation methods.
I'm thinking that controlling a mech will be something like this: WASD and mouse camera, just like Lara Croft, right? Shift runs. Space fires jets. If you are holding shift, the jets fire to help you accelerate along the ground (horizontally). Otherwise, that's a jump. You can hold space to keep firing jets, whether to make your jump longer or continue your jet-assisted sprint (especially useful on soft terrains where you want to move fast and not get stuck). Jets will automatically fire to prevent you from cratering after a fall.
Holding control switches your gait to its secondary mode, whatever your design has made that. It might be your feet changing to skis, your hips extending for a lower center of gravity, wings popping out of your back, scrambling on all fours, and so on. That's all up to how you build your mech.
Navigating the world can be done just by walking everywhere, if you want to suck - you can navigate all of Saints Row IV's city without jumping or sprinting, too. But in general, you'll be switching out between jumping, dashing, sprinting, and clutching (whatever your secondary mode is) to help you keep a good speed across varying terrain types. This is more important than your average game, because it takes a considerable amount of effort to get up to speed, but there's really no maximum speed. You can cover vast distances if you have a good lane and a suitable mode to keep your speed high. Skidding is obviously a big factor here, as is ploughing into a terrain type while you're in the wrong mode (or just slamming into a cliff).
Now we need a reason for the player to want to navigate through this world.
One reason - a big one - is the construction half of the game. Different parts of the planet have different resources, and are amenable to different kinds of buildings. So you're likely to have outposts quite removed from one another. You could use jets (if atmosphere) or rockets (if not), but that wastes a lot of fuel and you have to maintain them - and they can really only go between outposts with landing strips/pads. Railways and roads are handy, but you have to build them.
For much of the time, the easiest way to get between settlements across the rocky, blasted landscape will be by mech. This is why a good top speed is often important: you might be trying to cover hundreds of kilometers.
In "overseer" mode you can simply switch between settlements, but if you want to transfer people or resources you'll need to actually have something physical move from A to B. NPCs can use mechs, rovers, trains, or trucks to transfer resources, and you'll be relying on that a lot. But there's also times when you want to transfer something faster, or something that can't be automated. For example, crew cycling to keep people from going stir-crazy. Cables for an emergency repair. And so on.
But just wandering the planet is also fun, because you're in a mech. The things that interest a mech are not the same as the things that interest a human, and this is where collectibles come into play. Forming a "chain" is the basis of any movement-oriented game, whether we're talking about Crackdown's collectible skill orbs, Pilotwing's floating rings, Mirror's Edge's next glowing red structure... the idea is you have to make the player want to go to a place, and the easiest way to do that is to put up a marker of some kind that they want to reach.
In our case, we'll be using the construction half of the game to support this.
Various survey points will be indicated - typically the center of craters and the highest peaks. Reaching one of these does a quick (zero-time) survey of the surroundings. This does a few things.
1) It improves your general knowledge of the planet, slightly increasing the performance of people who work there.
2) It reveals anchorpoints.
3) It reveals, after a day has passed and people have analyzed it in detail, hidden resources.
Anchorpoints are simply places where the underlying rock or ice is unusually solid and reliable. Buildings on anchorpoints will be the "tall" variant, significantly better than the "short" variant normally deployed. Hidden resources are similar: resource tiles are part of what allow you to build buildings (playing the role of a "slot" in a minecraftlike "crafting surface"), so uncovering a small resource deposit means that you may have gained the ability to place an unusual building in that area and can therefore build a more robust base.
Your mech can reshape the earth and designate drop points for buildings at any time, so these aren't simply collectibles. You may find yourself reaching an anchorpoint and stopping, looking around, stamping a flat spot and dropping a building marker on it. It's a combination of exploring and base building.
You may also want to do this groundskeeping near already existing bases, because your mech is good at carrying cables and rails and so on, so you can build the infrastructure of the base if you want. Just be careful: heavy mechs will stamp down dirt and crush rock as they move. Actually, you'll probably leave a trail of destruction in the landscape even in a light mech, if you're moving fast. It's part of the fun.
Another factor unrelated to this is weather.
Even on airless rocks, there is something akin to weather. Plumes of dust you've kicked up, the heavy beat of the sun, even asteroid impacts. In places with weather, wind, rain, sandstorms - even just clouds blocking out the sun.
One aspect of this is the heat or cold. I like the idea of mechs having to worry about hot and cold. You can build your mech with heaters or coolers to blunt the effect somewhat, but in general you'll have to blow coolant (a limited resource) or spend energy (making you unable to move your limbs for a moment).
I like the idea of making your run take these into consideration even while you try to keep your speed up. Run through dark areas, because coolant is 3x more effective when the sun doesn't vaporize the mist. Heat yourself while you're arcing through the air in the middle of a jump - you don't need your legs right that moment... but be careful not to tip over in midair!
I also like the idea of wind, especially with vision-obscuring rain or dust. I like the idea that you can see a given range, and beyond that it's just wireframe or IR-reconstruction or something. This means you can "see" from the point of view of not careening off an edge, but you can't see what kind of terrain it is. You'll have to deduce it from context or play it safe...
Heavy winds can buffet even a mech, and I like having to take them into consideration when you jump. I think the ideal solution would be to have a constant wind gauge, but also a "wind in five seconds" gauge that you can use to either avoid getting swept off your feet... or jump into the air and let it take you in the direction you want to go in a sudden gust. Mind the dust in your joints, of course.
Unrelated to everything, I like the idea of this psuedo-voxel system because it can highlight the trail that mecha leave. If you're trying to track a mech, or find a fallen meteor, or figure out what buildings were damaged, the game can simply compare the map you had to the real map and, if your map has an incorrect tile, it'll fix that tile and flash a little spire of light. So tracking a mech means moving in the same direction and watching for which particular stamped-down areas weren't stamped down last time you were here. They'll flash.
Anyway, that's my idea.
As an example of moment-to-moment feel, think about Crackdown (or Saints Row IV). Moving your character around is fun. Think about a good racing game. Think about Pilotwings. Spider-Man 2. There's a simple joy in moving around that comes from a combination of very tight controls mixed with skill challenges. It's fun to move around AND there's an interesting place to move around in, basically.
I made Astrophobia with that kind of thing in mind, although it wasn't "fun" so much as "atmospheric". But... I was having a really hard time enthusing myself to actually turn it into a game, because there's no construction involved.
So I started to think about construction and movement in the same moment. And I started thinking about mecha. Mecha are actually far more suited to construction than combat, and they're large enough to give you a range of view that allows you to build things.
In terms of construction, I have some fun thoughts on that involving a slightly bizarre combination of Minecraft's crafting bench and Populus' land-clearing... but in order to make it worth playing, the mech has to be fun to pilot.
In oldschool mech games, the piloting was an ongoing strategic challenge rather than actually being fun in and of itself. Nobody played Mechwarrior because they enjoyed slowly slouching behind a hill. They slowly slouched behind the hill because they liked playing Mechwarrior.
Newer mech games tend to have mechs that move like first person shooter heroes, blitzing around the game map like crazed weasels. But speed doesn't make piloting them fun, it just reshapes the combat. Piloting the mech is occasionally fun, but more often than not it's still just an ongoing strategic challenge, just like movement in Quake 3 or Left For Dead or whatever.
I was considering, then, how to make a mech fun to pilot. How do you make the player go "HOLY MOLY I JUST WANT TO RUN AROUND AND LOOK AT STUFF IN THIS MECH"?
A lot of the fun in games like Crackdown come from a striking verticality and a lot of collectibles. The collectibles pull you to the next building, while the verticality provides a roughness to the motion that requires you to be vaguely skilled and strategic, switching between climbing, running, jumping, and gliding.
While we could try to make our planets more vertical, that's not really a great idea because our verticality would be broken terrain, which wouldn't be all that fun to navigate. We do want some verticality, especially in specific challenging areas (mountains), but in general verticality will have to play a much smaller role due to our lack of structured surfaces.
To replace it, I plan to use surface type.
Think about a typical airless rock like our moon. Its surface is shaped primarily by meteor hits. Craters on top of craters.
While it may not be perfectly accurate, we can model these surfaces as having different textures. The bottom of the bowl of the crater has been blasted flat down to the rock, so it's a hard, relatively smooth surface. The lip of the crater is where the heavy debris fall, so it's got a kind of heavy dirt-like texture. Outside of the crater is where the light debris (dust and sand) land. The rays radiating from the impact are where large pieces of debris skidded along the surface, clearing a swath clean of dust and leaving bare rock.
As a mech, you would navigate these different areas in different ways. The flat, hard surfaces can be simply walked/dashed across, and you can land or leap without damaging them (unless you're a really heavy mech). The dirt-like slopes are generally amenable to you, especially if you're a lighter mech, but they are slopes and you do leave footprints as you pack down the dirt, even perhaps sliding down the slope. It'd be better to switch to whatever high-traction mode you have, perhaps even using your hands if the slope is severe.
The dust areas... well, dust is basically a liquid to something like a mech. You can walk through it, of course, but you'll sink in it. Throw up huge clouds of dust if you're moving quick or landing, reshaping the dust fields into dust dunes. Drowning in dust is hard on your joints and/or intakes, of course.
But navigating dust doesn't have to be a pain. You just have to change your mindset. You can leap across dust fields - landing in the dust with jets a-blazin will drive it away, then you can jump again before you get swallowed in it. Or have a ski mode where you have jets propel you along on skis. You'll kick up dust, yeah, but it'll all be behind you. Just remember to change back into foot mode when you reach rock... you might even have to jump over that ray where there's exposed rock.
Planets with atmospheres have a different jumble of terrains, but it's still the same kind of deal where you switch stances or navigation methods.
I'm thinking that controlling a mech will be something like this: WASD and mouse camera, just like Lara Croft, right? Shift runs. Space fires jets. If you are holding shift, the jets fire to help you accelerate along the ground (horizontally). Otherwise, that's a jump. You can hold space to keep firing jets, whether to make your jump longer or continue your jet-assisted sprint (especially useful on soft terrains where you want to move fast and not get stuck). Jets will automatically fire to prevent you from cratering after a fall.
Holding control switches your gait to its secondary mode, whatever your design has made that. It might be your feet changing to skis, your hips extending for a lower center of gravity, wings popping out of your back, scrambling on all fours, and so on. That's all up to how you build your mech.
Navigating the world can be done just by walking everywhere, if you want to suck - you can navigate all of Saints Row IV's city without jumping or sprinting, too. But in general, you'll be switching out between jumping, dashing, sprinting, and clutching (whatever your secondary mode is) to help you keep a good speed across varying terrain types. This is more important than your average game, because it takes a considerable amount of effort to get up to speed, but there's really no maximum speed. You can cover vast distances if you have a good lane and a suitable mode to keep your speed high. Skidding is obviously a big factor here, as is ploughing into a terrain type while you're in the wrong mode (or just slamming into a cliff).
Now we need a reason for the player to want to navigate through this world.
One reason - a big one - is the construction half of the game. Different parts of the planet have different resources, and are amenable to different kinds of buildings. So you're likely to have outposts quite removed from one another. You could use jets (if atmosphere) or rockets (if not), but that wastes a lot of fuel and you have to maintain them - and they can really only go between outposts with landing strips/pads. Railways and roads are handy, but you have to build them.
For much of the time, the easiest way to get between settlements across the rocky, blasted landscape will be by mech. This is why a good top speed is often important: you might be trying to cover hundreds of kilometers.
In "overseer" mode you can simply switch between settlements, but if you want to transfer people or resources you'll need to actually have something physical move from A to B. NPCs can use mechs, rovers, trains, or trucks to transfer resources, and you'll be relying on that a lot. But there's also times when you want to transfer something faster, or something that can't be automated. For example, crew cycling to keep people from going stir-crazy. Cables for an emergency repair. And so on.
But just wandering the planet is also fun, because you're in a mech. The things that interest a mech are not the same as the things that interest a human, and this is where collectibles come into play. Forming a "chain" is the basis of any movement-oriented game, whether we're talking about Crackdown's collectible skill orbs, Pilotwing's floating rings, Mirror's Edge's next glowing red structure... the idea is you have to make the player want to go to a place, and the easiest way to do that is to put up a marker of some kind that they want to reach.
In our case, we'll be using the construction half of the game to support this.
Various survey points will be indicated - typically the center of craters and the highest peaks. Reaching one of these does a quick (zero-time) survey of the surroundings. This does a few things.
1) It improves your general knowledge of the planet, slightly increasing the performance of people who work there.
2) It reveals anchorpoints.
3) It reveals, after a day has passed and people have analyzed it in detail, hidden resources.
Anchorpoints are simply places where the underlying rock or ice is unusually solid and reliable. Buildings on anchorpoints will be the "tall" variant, significantly better than the "short" variant normally deployed. Hidden resources are similar: resource tiles are part of what allow you to build buildings (playing the role of a "slot" in a minecraftlike "crafting surface"), so uncovering a small resource deposit means that you may have gained the ability to place an unusual building in that area and can therefore build a more robust base.
Your mech can reshape the earth and designate drop points for buildings at any time, so these aren't simply collectibles. You may find yourself reaching an anchorpoint and stopping, looking around, stamping a flat spot and dropping a building marker on it. It's a combination of exploring and base building.
You may also want to do this groundskeeping near already existing bases, because your mech is good at carrying cables and rails and so on, so you can build the infrastructure of the base if you want. Just be careful: heavy mechs will stamp down dirt and crush rock as they move. Actually, you'll probably leave a trail of destruction in the landscape even in a light mech, if you're moving fast. It's part of the fun.
Another factor unrelated to this is weather.
Even on airless rocks, there is something akin to weather. Plumes of dust you've kicked up, the heavy beat of the sun, even asteroid impacts. In places with weather, wind, rain, sandstorms - even just clouds blocking out the sun.
One aspect of this is the heat or cold. I like the idea of mechs having to worry about hot and cold. You can build your mech with heaters or coolers to blunt the effect somewhat, but in general you'll have to blow coolant (a limited resource) or spend energy (making you unable to move your limbs for a moment).
I like the idea of making your run take these into consideration even while you try to keep your speed up. Run through dark areas, because coolant is 3x more effective when the sun doesn't vaporize the mist. Heat yourself while you're arcing through the air in the middle of a jump - you don't need your legs right that moment... but be careful not to tip over in midair!
I also like the idea of wind, especially with vision-obscuring rain or dust. I like the idea that you can see a given range, and beyond that it's just wireframe or IR-reconstruction or something. This means you can "see" from the point of view of not careening off an edge, but you can't see what kind of terrain it is. You'll have to deduce it from context or play it safe...
Heavy winds can buffet even a mech, and I like having to take them into consideration when you jump. I think the ideal solution would be to have a constant wind gauge, but also a "wind in five seconds" gauge that you can use to either avoid getting swept off your feet... or jump into the air and let it take you in the direction you want to go in a sudden gust. Mind the dust in your joints, of course.
Unrelated to everything, I like the idea of this psuedo-voxel system because it can highlight the trail that mecha leave. If you're trying to track a mech, or find a fallen meteor, or figure out what buildings were damaged, the game can simply compare the map you had to the real map and, if your map has an incorrect tile, it'll fix that tile and flash a little spire of light. So tracking a mech means moving in the same direction and watching for which particular stamped-down areas weren't stamped down last time you were here. They'll flash.
Anyway, that's my idea.
Tuesday, September 17, 2013
Techtris
Construction is a skill, and that's why construction games are usually very interesting to me. Whether you're building a bridge or a space ship or a castle, you are relating these objects in a complex space and then testing their fitness.
Something like Kerbal has more staying power because it has a lot of different kinds of tests of fitness, especially with mods. If you're doing a bridge-building game, the only test is to have a bridge that things can go over. You can build a lot of random fun stuff, but the game doesn't particularly care. On the other hand, in Kerbal the primary fitness test is launch survival... but then the world opens up and you can choose what kind of challenges you want to take on, and it offers you feedback based on those specific challenges. Successful mission to Eve? There's about a dozen possible approaches to that, and your design can therefore be rated in a dozen different ways. Lots of open-ended design.
That in mind, there are pretty basic restrictions on how you build things - in Kerbal and in everything else. There's a particular primary concern that everything arises from. In a bridge-building game, it's the bridge's ability to resist weight via supports. In Kerbal it's the ship's ability to survive thrust. The specifics of the vehicles/thrust change the fitness test, but it's still the same basic category.
Changing Kerbal or a bridge game to subvert that test weakens the game dramatically. For example, in Kerbal there are mods to help you set up base on the moon and launch from there. This sounds really cool - and it is - but the stresses of launching from the moon are microscopic. The challenge is slack as hell - as slack as if you set all the cars and trains to weigh 0 kilos in a bridge game. This isn't necessarily deadly - if there's another fitness test waiting to be applied, it can still be fun. But there generally isn't.
I was thinking: what other kinds of core fitness challenges could you create for a constructive space game?
Well, I've talked about aging: taking into account how durable things are and how they will break down. Then it's more about balancing time instead of balancing rigid mass. There's also the ever-popular option of combat as a fitness test, but that's boring.
I was watching a few videos about people putting together rockets and the CMS, light techno playing as they painstakingly assemble all the pieces. Here's one short example: CMS install.
And I thought, hey, there's an idea. What if the final structure of the device/station/ship isn't the main fitness test, but instead it's the actual construction?
For example, in the last essay I talked about using chemicals in an alien atmosphere to create drinking water. You'd just slot in the various conversion nodes - air intake, CO2 filter, CO2->O2 converter, O2->H2O converter... while it might be weighty or power-hungry, it's not really part of the core fitness test, because there's nothing particularly interesting about the physical layout of the nodes.
On the other hand, what if you had to ship them into space all disassembled, and then assemble the unit in space? These aren't structural modules you're slotting in. You've got some kind of structural frame, and you're embedding racks, wiring up connectors - all in a confined space, in zero gravity.
Now it's a topological puzzle. You're in space. Can you get the chemical processor into the area you're assembling it in? Can you rotate it to the right orientation? Can you fit it into the right spot, past whatever other things might be in the way? Can you get to the connectors and screws and tubes to actually connect it?
You might think "Oh, just assemble everything in an easy-to-get-to tower..." but you can say the same things about all construction games. "Just connect every part of the bridge to every anchor" "just surround every part of the castle with garrisoned walls".
The question is: what pressures the player to try and cram more and more stuff into less and less space? In most construction games, they limit the number of things you can have by putting price tags on everything. In our game, we would need to find a way to limit the space you are allowed to fill. The obvious answer is to have the containment structures/frameworks have specific sizes and shapes. You certainly can just put one thing in each framework and leave yourself a lot of space... but the framework is the heavy part of the space vessel, so that's going to make it hard to accelerate and turn.
I think it'd be a fun challenge to make the assembly process feel right - feel controllable and not too pat. The player might make a kind of "record" of how to do it while designing the ship in the first place, then NPCs could assemble any number of them in game days. You could even watch them assemble in the background of whatever else you're doing, perhaps with light techno playing in the background.
There are a few key areas to balance:
1) How the shape of the object fits into the chassis is obviously critical, and you might need to make it adaptive or have a variety of each part to support different fundamental shapes of chassis.
2) The connectors between objects are just as important, because you have to connect whatever you put in to whatever else relies on it. This makes the order of construction really matter, because a clever designer will put connectors to object A and B behind object C for space concerns, and then just be sure to add object C after adding and connecting A and B.
3) Mechanical structures matter, because racks which slide out, lids which open, spaces which expand and contract, legs that swing away and then back... these let you get at spaces that will be locked back down, or provide access in ways you would have a hard time with. This means that the chassis variety can be extraordinary: not just spatial configuration.
4) Secondary effects such as vibration and heat matter. If you have something that vibrates butting up against something that's taking pictures, you'll get crappy pictures.
Hm!
Sort of "techtris", if you will.
Something like Kerbal has more staying power because it has a lot of different kinds of tests of fitness, especially with mods. If you're doing a bridge-building game, the only test is to have a bridge that things can go over. You can build a lot of random fun stuff, but the game doesn't particularly care. On the other hand, in Kerbal the primary fitness test is launch survival... but then the world opens up and you can choose what kind of challenges you want to take on, and it offers you feedback based on those specific challenges. Successful mission to Eve? There's about a dozen possible approaches to that, and your design can therefore be rated in a dozen different ways. Lots of open-ended design.
That in mind, there are pretty basic restrictions on how you build things - in Kerbal and in everything else. There's a particular primary concern that everything arises from. In a bridge-building game, it's the bridge's ability to resist weight via supports. In Kerbal it's the ship's ability to survive thrust. The specifics of the vehicles/thrust change the fitness test, but it's still the same basic category.
Changing Kerbal or a bridge game to subvert that test weakens the game dramatically. For example, in Kerbal there are mods to help you set up base on the moon and launch from there. This sounds really cool - and it is - but the stresses of launching from the moon are microscopic. The challenge is slack as hell - as slack as if you set all the cars and trains to weigh 0 kilos in a bridge game. This isn't necessarily deadly - if there's another fitness test waiting to be applied, it can still be fun. But there generally isn't.
I was thinking: what other kinds of core fitness challenges could you create for a constructive space game?
Well, I've talked about aging: taking into account how durable things are and how they will break down. Then it's more about balancing time instead of balancing rigid mass. There's also the ever-popular option of combat as a fitness test, but that's boring.
I was watching a few videos about people putting together rockets and the CMS, light techno playing as they painstakingly assemble all the pieces. Here's one short example: CMS install.
And I thought, hey, there's an idea. What if the final structure of the device/station/ship isn't the main fitness test, but instead it's the actual construction?
For example, in the last essay I talked about using chemicals in an alien atmosphere to create drinking water. You'd just slot in the various conversion nodes - air intake, CO2 filter, CO2->O2 converter, O2->H2O converter... while it might be weighty or power-hungry, it's not really part of the core fitness test, because there's nothing particularly interesting about the physical layout of the nodes.
On the other hand, what if you had to ship them into space all disassembled, and then assemble the unit in space? These aren't structural modules you're slotting in. You've got some kind of structural frame, and you're embedding racks, wiring up connectors - all in a confined space, in zero gravity.
Now it's a topological puzzle. You're in space. Can you get the chemical processor into the area you're assembling it in? Can you rotate it to the right orientation? Can you fit it into the right spot, past whatever other things might be in the way? Can you get to the connectors and screws and tubes to actually connect it?
You might think "Oh, just assemble everything in an easy-to-get-to tower..." but you can say the same things about all construction games. "Just connect every part of the bridge to every anchor" "just surround every part of the castle with garrisoned walls".
The question is: what pressures the player to try and cram more and more stuff into less and less space? In most construction games, they limit the number of things you can have by putting price tags on everything. In our game, we would need to find a way to limit the space you are allowed to fill. The obvious answer is to have the containment structures/frameworks have specific sizes and shapes. You certainly can just put one thing in each framework and leave yourself a lot of space... but the framework is the heavy part of the space vessel, so that's going to make it hard to accelerate and turn.
I think it'd be a fun challenge to make the assembly process feel right - feel controllable and not too pat. The player might make a kind of "record" of how to do it while designing the ship in the first place, then NPCs could assemble any number of them in game days. You could even watch them assemble in the background of whatever else you're doing, perhaps with light techno playing in the background.
There are a few key areas to balance:
1) How the shape of the object fits into the chassis is obviously critical, and you might need to make it adaptive or have a variety of each part to support different fundamental shapes of chassis.
2) The connectors between objects are just as important, because you have to connect whatever you put in to whatever else relies on it. This makes the order of construction really matter, because a clever designer will put connectors to object A and B behind object C for space concerns, and then just be sure to add object C after adding and connecting A and B.
3) Mechanical structures matter, because racks which slide out, lids which open, spaces which expand and contract, legs that swing away and then back... these let you get at spaces that will be locked back down, or provide access in ways you would have a hard time with. This means that the chassis variety can be extraordinary: not just spatial configuration.
4) Secondary effects such as vibration and heat matter. If you have something that vibrates butting up against something that's taking pictures, you'll get crappy pictures.
Hm!
Sort of "techtris", if you will.
Challenge Stacking
I wrote a longggg post on how to get players to prefer elegance in their constructions instead of "bigger = better". But it got out of hand and was much too long, so let's take a whack at one of the central ideas:
One kind of elegance, and the easiest kind to implement for a game, is suitability.
For example, you want to land on an atmospheric planet, like Earth.
One solution is to get a big rocket with heavy landing struts. Use the rocket's thrust to decelerate safely to subsonic speeds and continue thrusting all the way to the surface before landing a huge, empty fuel tank on heavy struts wherever you decided to land.
The other option is to drop a teardrop-shaped probe. The bottom of the teardrop is a heat shield, which safely absorbs the re-entry burn and lets friction take you down from supersonic speeds. Then the parachute deploys, slowing you further. The heat shield drops away and spindly little lander legs deploy - tiny, because they don't need to weather re-entry and don't have to support an entire fuel tank. In the end, you safely land without expending any fuel at all.
It's obvious which of these solutions is more elegant. The question is: how do you reward a player for coming up with the second one instead of the first one?
Giving the player limited resources is one option: you choose the elegant solution because it is cheaper or lighter. However, I'm okay with expensive elegant solutions, with large elegant solutions. So I don't like the idea of limited resources, at least not in the construction phase.
I think what makes the fuel-less probe more elegant is that it deals with the challenges of the mission in an appropriate matter, instead of spending a staggering amount of resources in a sub-par workaround.
By understanding the challenges along the mission path, you can use them as opportunities instead of hazards. The rocket-rocket-rocket approach treats all of the challenges as hazards. The passive-teardrop approach treats the challenges as opportunities to get free acceleration. It's an elegant approach, even though it has a lot more moving parts than a rocket-rocket-rocket approach might.
This same approach can be generalized to all kinds of challenges. For example, you want to build a buggy to drive over the lunar surface. The low gravity is a challenge, because it means your grip on the surface is really poor.
Well, in reality a wheel is a very elegant solution on its own. Wheels use gravity to help you propel yourself efficiently, even if the maximum propulsion is pretty low and gets worse on low-gravity worlds. You could improve things a bit by simply making bigger wheels, but let's consider alternatives.
One option is to make a legged "jumper". Low gravity means that the joints can be much lower-powered and still pace across the surface quite quickly. There are a lot of considerations here, though: unless you're quite practiced in building legged robots, you're probably going to find yourself facing challenges such as dust in the joints, poor balance, slipping on sandy slopes, and so on. These are the same considerations you'd be facing with wheels, but we've got wheels down pat.
Another option is to use a hybrid of wheels and climbing legs. The slow progress on wheels is fine, but it's the rough terrain that prevents you from driving that's the problem. For those situations, hooked "climbing" legs can grip onto slopes or large rocks and help to haul you over. They also serve double duty as devices which can flip you back over if you tip. Of course, these are probably not ideal for climbing up proper cliffs, but they would allow you to navigate broken terrain.
Putting aside mobility, the low gravity offers many opportunities for a rover not related to moving. For example, the rover could have a spring-loaded tether which it fires a hundred feet into the "air" to give a good view of the surroundings. The camera falls back to the ground, but it's durable enough to survive the much lower impact trauma than it would have in high gravity, and the rover can reel it in and reset the spring. There are obviously dust and impact considerations to be made, but the ability to get a panoramic view might be worth it.
You could even use a similar system to fire a hook forward, grip the ground, and then drag yourself towards the hook. The low gravity makes dragging quite easy, if you can get the hook to stick.
Another benefit of low gravity (accompanied by low ground speed) is that you can have very fragile unfolding systems - solar panels, long sampling arms, and so on. In fact, you could even put the wheels on spindly extending mounts to give your rover a much higher added stability, although if that speeds up your rover then it will increase the impact and vibration forces on itself and any other devices you've mounted.
Someone who creates a rover with these kinds of utilities for taking advantage of lower gravity will be creating vastly more interesting rovers - and also performing at a higher skill level than someone who just creates yet another generic rover. These are the sorts of opportunities we want to provide, especially in coordination with soft space/weight constraints.
To do this, we need to provide the player with two things.
1) Construction tools adaptable enough to allow the player to misuse them.
2) Challenges that act as both hazards and opportunities.
This is a little more difficult than it sounds, because in order to make challenges that are both hazards and opportunities, we need to have quite a lot of different play systems in effect. Gravity and atmosphere are easy targets for space games, but what other systems might work?
Some are external. Dust and weather are big examples that generally go unused. Atmospheric chemistry is another example, especially if we allow for chemical reactions that can turn one chemical into another. Minerals that perhaps could be mined. These are all challenges - some are more hazard than opportunity, some are more opportunity than hazard, but there's no need to nitpick.
Other play systems are internal. For example, let's say that NPCs can control vehicles to do automatic exploring and scanning. It doesn't matter the type of vehicle - telescopes, probes, mining ships, comm sats, rovers - all vehicles can be automatically controlled by NPCs to optimize their performance. However, NPCs will hesitate and move very deliberately, making their optimization pretty crap.
Gathering information would help to improve NPC performance (and player performance, if they take the helm and can see the information). For example, if you have a good map of Mars near your rover, then you can plan your rover's movements in advance. Maybe you deploy a satellite that passes over your rover and takes pictures. A camera on the rover would be an obvious requirement, giving you detailed feedback as to how you're doing. The formula for how much a camera improves performance is based on the camera's distance from/height over the target. The satellite is quite far away so its information has some value, but not a whole lot, and it's only taken once per orbit. The on-board camera provides very good feedback, but it's actually too close to the target (the ground), limiting its view.
This is when people start coming up with different solutions, like the launched panorama cam. Optimize the cameras.
This basic "line of scanning" formula can be used more abstractly to allow for dozens of different kinds of scanning in the same way that a weather algorithm allows for dozens of different kinds of atmospheres. We can use the same basic formula to calculate out the scientific value of a scan, whether you detected valuable minerals, whether the people on your hab think they have a nice view, whether your space construction facility can safely construct things with all its spindly arms...
Similarly, the ability to convert chemicals into other chemicals (for example CO2 -> O2 -> H2O) can be implemented for a much wider variety of things. For example, you can model the human crew as eating packaged food, which is then converted into waste and plastic packaging, each of which can be converted into other things or ditched as you prefer.
Now, you shouldn't force the player to deal with every challenge all the time. These challenges should be strictly player's choice. If the player wants to use a precreated hab module that handles the waste and packaging quietly, that's fine. But if the player wants to tackle optimizing things and connecting systems, they should also be allowed to do that. Tackle challenges as you like. The player will, at some point, realize that tacking on 50 more tons of food is less effective than setting up a clever, elegant way to recycle waste.
Hm. Now the primary issue with creating such a game is how you would handle the construction/realtime control side of things without falling into the same pitfalls as Kerbal, but without dumbing it down.
The biggest issue there is that not all of these are physically challenging systems. If you want to take in carbon dioxide and output water, the construction involved is just to slap down three or four modules on top of each other and call it a day. Slapping together units doesn't require any particular skill, so it's not a good match for our physical construction skill-based play.
One alternate option is to make the required skill one of long-term prediction. You can connect things up, but you have to know how well your supplies will last, your chances of breaking, and so on.
Another option is to recast things like chemical conversion and cameras into physical constructions that have strict restrictions. For example, converting chemical A into chemical B is just a node you slap in, but the node puts out a massive amount of heat. Another node puts out vibration. This one, radiation. The physical construction you build will then have to not simply resist the stresses of gravity, thrust, and atmosphere, but also the stresses you cause with your own systems.
That would probably work best with inflatable, unfolding systems...
Hm!
One kind of elegance, and the easiest kind to implement for a game, is suitability.
For example, you want to land on an atmospheric planet, like Earth.
One solution is to get a big rocket with heavy landing struts. Use the rocket's thrust to decelerate safely to subsonic speeds and continue thrusting all the way to the surface before landing a huge, empty fuel tank on heavy struts wherever you decided to land.
The other option is to drop a teardrop-shaped probe. The bottom of the teardrop is a heat shield, which safely absorbs the re-entry burn and lets friction take you down from supersonic speeds. Then the parachute deploys, slowing you further. The heat shield drops away and spindly little lander legs deploy - tiny, because they don't need to weather re-entry and don't have to support an entire fuel tank. In the end, you safely land without expending any fuel at all.
It's obvious which of these solutions is more elegant. The question is: how do you reward a player for coming up with the second one instead of the first one?
Giving the player limited resources is one option: you choose the elegant solution because it is cheaper or lighter. However, I'm okay with expensive elegant solutions, with large elegant solutions. So I don't like the idea of limited resources, at least not in the construction phase.
I think what makes the fuel-less probe more elegant is that it deals with the challenges of the mission in an appropriate matter, instead of spending a staggering amount of resources in a sub-par workaround.
By understanding the challenges along the mission path, you can use them as opportunities instead of hazards. The rocket-rocket-rocket approach treats all of the challenges as hazards. The passive-teardrop approach treats the challenges as opportunities to get free acceleration. It's an elegant approach, even though it has a lot more moving parts than a rocket-rocket-rocket approach might.
This same approach can be generalized to all kinds of challenges. For example, you want to build a buggy to drive over the lunar surface. The low gravity is a challenge, because it means your grip on the surface is really poor.
Well, in reality a wheel is a very elegant solution on its own. Wheels use gravity to help you propel yourself efficiently, even if the maximum propulsion is pretty low and gets worse on low-gravity worlds. You could improve things a bit by simply making bigger wheels, but let's consider alternatives.
One option is to make a legged "jumper". Low gravity means that the joints can be much lower-powered and still pace across the surface quite quickly. There are a lot of considerations here, though: unless you're quite practiced in building legged robots, you're probably going to find yourself facing challenges such as dust in the joints, poor balance, slipping on sandy slopes, and so on. These are the same considerations you'd be facing with wheels, but we've got wheels down pat.
Another option is to use a hybrid of wheels and climbing legs. The slow progress on wheels is fine, but it's the rough terrain that prevents you from driving that's the problem. For those situations, hooked "climbing" legs can grip onto slopes or large rocks and help to haul you over. They also serve double duty as devices which can flip you back over if you tip. Of course, these are probably not ideal for climbing up proper cliffs, but they would allow you to navigate broken terrain.
Putting aside mobility, the low gravity offers many opportunities for a rover not related to moving. For example, the rover could have a spring-loaded tether which it fires a hundred feet into the "air" to give a good view of the surroundings. The camera falls back to the ground, but it's durable enough to survive the much lower impact trauma than it would have in high gravity, and the rover can reel it in and reset the spring. There are obviously dust and impact considerations to be made, but the ability to get a panoramic view might be worth it.
You could even use a similar system to fire a hook forward, grip the ground, and then drag yourself towards the hook. The low gravity makes dragging quite easy, if you can get the hook to stick.
Another benefit of low gravity (accompanied by low ground speed) is that you can have very fragile unfolding systems - solar panels, long sampling arms, and so on. In fact, you could even put the wheels on spindly extending mounts to give your rover a much higher added stability, although if that speeds up your rover then it will increase the impact and vibration forces on itself and any other devices you've mounted.
Someone who creates a rover with these kinds of utilities for taking advantage of lower gravity will be creating vastly more interesting rovers - and also performing at a higher skill level than someone who just creates yet another generic rover. These are the sorts of opportunities we want to provide, especially in coordination with soft space/weight constraints.
To do this, we need to provide the player with two things.
1) Construction tools adaptable enough to allow the player to misuse them.
2) Challenges that act as both hazards and opportunities.
This is a little more difficult than it sounds, because in order to make challenges that are both hazards and opportunities, we need to have quite a lot of different play systems in effect. Gravity and atmosphere are easy targets for space games, but what other systems might work?
Some are external. Dust and weather are big examples that generally go unused. Atmospheric chemistry is another example, especially if we allow for chemical reactions that can turn one chemical into another. Minerals that perhaps could be mined. These are all challenges - some are more hazard than opportunity, some are more opportunity than hazard, but there's no need to nitpick.
Other play systems are internal. For example, let's say that NPCs can control vehicles to do automatic exploring and scanning. It doesn't matter the type of vehicle - telescopes, probes, mining ships, comm sats, rovers - all vehicles can be automatically controlled by NPCs to optimize their performance. However, NPCs will hesitate and move very deliberately, making their optimization pretty crap.
Gathering information would help to improve NPC performance (and player performance, if they take the helm and can see the information). For example, if you have a good map of Mars near your rover, then you can plan your rover's movements in advance. Maybe you deploy a satellite that passes over your rover and takes pictures. A camera on the rover would be an obvious requirement, giving you detailed feedback as to how you're doing. The formula for how much a camera improves performance is based on the camera's distance from/height over the target. The satellite is quite far away so its information has some value, but not a whole lot, and it's only taken once per orbit. The on-board camera provides very good feedback, but it's actually too close to the target (the ground), limiting its view.
This is when people start coming up with different solutions, like the launched panorama cam. Optimize the cameras.
This basic "line of scanning" formula can be used more abstractly to allow for dozens of different kinds of scanning in the same way that a weather algorithm allows for dozens of different kinds of atmospheres. We can use the same basic formula to calculate out the scientific value of a scan, whether you detected valuable minerals, whether the people on your hab think they have a nice view, whether your space construction facility can safely construct things with all its spindly arms...
Similarly, the ability to convert chemicals into other chemicals (for example CO2 -> O2 -> H2O) can be implemented for a much wider variety of things. For example, you can model the human crew as eating packaged food, which is then converted into waste and plastic packaging, each of which can be converted into other things or ditched as you prefer.
Now, you shouldn't force the player to deal with every challenge all the time. These challenges should be strictly player's choice. If the player wants to use a precreated hab module that handles the waste and packaging quietly, that's fine. But if the player wants to tackle optimizing things and connecting systems, they should also be allowed to do that. Tackle challenges as you like. The player will, at some point, realize that tacking on 50 more tons of food is less effective than setting up a clever, elegant way to recycle waste.
Hm. Now the primary issue with creating such a game is how you would handle the construction/realtime control side of things without falling into the same pitfalls as Kerbal, but without dumbing it down.
The biggest issue there is that not all of these are physically challenging systems. If you want to take in carbon dioxide and output water, the construction involved is just to slap down three or four modules on top of each other and call it a day. Slapping together units doesn't require any particular skill, so it's not a good match for our physical construction skill-based play.
One alternate option is to make the required skill one of long-term prediction. You can connect things up, but you have to know how well your supplies will last, your chances of breaking, and so on.
Another option is to recast things like chemical conversion and cameras into physical constructions that have strict restrictions. For example, converting chemical A into chemical B is just a node you slap in, but the node puts out a massive amount of heat. Another node puts out vibration. This one, radiation. The physical construction you build will then have to not simply resist the stresses of gravity, thrust, and atmosphere, but also the stresses you cause with your own systems.
That would probably work best with inflatable, unfolding systems...
Hm!
Monday, September 16, 2013
Ikebana
So, I talked about noncombat starbases and starships a lot for the past few weeks, but one thing I didn't cover were the visual characteristics of these games.
It may sound unimportant, but it can be very important. A big part of the draw of science fiction games is the feel of the world. That grandeur and mystery - sensawunda, if you prefer - is very important. The very first thing that helps to establish it are the core visuals of the ships and stations. Especially if a player can custom-build things, they'll want to custom-build something wonderful.
There are a lot of details about this that really change how everything feels. For example, how customizable are the ships? Are we talking about swapping out the nacelles on a Star Trek vessel, or about sticking together modules, or about arbitrary mesh placement and deformation? Each has its own strengths and weaknesses both in terms of visuals and gameplay restrictions, and each also has constraints in terms of the resulting visual design.
For example, freeform node placement allows you to put ship components like nacelles, hab bubbles, and so on anywhere you like, overlapping with other components and tilted and scaled in whatever way you think looks cool. However, if the components actually have functions (like weapons, engines, etc) this arbitrary placement can make it feel very awkward when someone places them in a manner that should logically prevent them from working properly. It also makes it difficult to internally connect the components, so it's not really possible to have module A clearly connected to module B - they're all just part of the same mishmash.
On the other hand, a hardpoint component system allows you to place components on the hardpoints of other components. This system is extremely good at relating modules to other modules, and therefore you can create resource chains, interiors, and so on that make sense. Visually, however, the locked-in-place modules are quite restrictive, and you have to be careful to design your module components such that they result in a visually interesting result. It's a lot more limited, and typically the result is a very boxy, militaristic style, because that goes well with the aggressively locked-in orientations and edges.
Those are far from the only options, though.
In my case, I really got to thinking about more organic-looking designs. I got interested in the joins between the modules. In most games, the modules just bump into each other or arbitrarily overlap, but there is value in having a very clear joint or clamp. It looks cool and you can make it highly functional. I was examining some examples when I realized that there was no reason for a space station to have to be ship-shaped.
A space station has no real thrust requirements, so it doesn't have to be shaped like a brick. In fact, it makes a lot more sense for a space station to be sprawled over a vast amount of space: more room for solar panels, less collateral damage if one part is destroyed, a wider separation between living areas and loud, possibly radioactive industrial areas...
So my design today is actually inspired by a sprig of flowers. That's why it's named after flower arranging.
The idea is that a space station "seed" is flung from earth out into space at something like 0.3c. It then spends the next few decades slowly decelerating into orbit around a nearby star.
Over the course of the journey, the seed blooms, growing out a branching, bud-heavy space station. When the distant star is reached, everything begins to unfold and bloom with the energy of that star.
This approach has a few strong points.
1) It's very visually distinct. As far as I know, the "unfolding flower" visual is still very rare in science fiction, and I've never seen it as part of a long 'branch' of flowers.
2) It works well with multiple identical modules. Most science fiction visuals start to look bad if you have dozens of the same module attached - for example, dozens of living areas. That's why they have different sizes of living area modules for different sizes of ship. But with my visuals, having dozens of identical modules just makes your space station look more beautiful and lively, because each one is a bud that unfolds into a flower.
3) It creates a very distinct resource chain. Resources flow up or down branches. This is a bit different from having connected modules, because you can have dozens of modules connected to the same branch. But it's also not the overly-simplistic "global resources" approach many designs take, which means you can have pretty complex localization if you want to start designing trickily.
For example, you might want to do a heavy industrial starbase that squeaks by with minimal actual humans. Therefore, to optimize performance, you might have two industrial branches. One is on, one is off - and you can toggle it. So one branch gathers resources, using up all available workers. When your resources are full, you switch to the other branch and turn off this one, temporarily stopping the resource gathering so you can fire mass packets home. Then turn that off and go back to gathering resources.
4) It creates a very easy modularization: you can save branches, and later on if you want to create those branches again, just poke them into the same seed base. Like Japanese flower arrangement - hence the language chosen for our title.
5) Every flower withers, every journey ends. The visual is a good way to communicate to the player that whatever they've built is mission-specific and is not terribly permanent. This impermanence pushes the player to keep launching, and therefore also pushes the player to keep refining their designs. The network of relays, resource-gathering, and seed-launching is ever-changing.
It also gives us a lot of opportunities to design for longevity. For example, if you wanted a really long-lasting signal relay, the problem isn't the signal dish. It lasts hundreds of years. The problem is the humans. Human habs are medium-duration blossoms and therefore they'll die out long before the relay does. Nobody dies due to the the blossoms wilting, but they do go back into cryo sleep and stop working. Which means you have no workers to work the relay dishes.
You could use an expensive multi-generation mega-blossom, but that's incredibly pricey. Instead, maybe you build dozens of normal habs, but you only activate one at a time. You set up your station to automatically activate the next blossom when the current one is fading using a set of resource barricades on the branch itself.
This has the side effect of also forming a very nice "thermometer". The easiest and most robust design for resource blocking steadily works along the branch, so whenever you pop over for a look at your space station, you can quickly count how long it has left by looking at how many colorful buds remain unopened at the end of the branch.
Similarly, you can use it for rolling out in phases. Mining ships require a fair number of resources to build, and if there are several of them on a branch they will share the incoming resources evenly. This can lead to extreme delays in actually getting ships out: it may be better to use resource blocking to grow just one or two at a time and roll the fleet out in waves - otherwise your other blossoms will age pointlessly until you roll some ships out.
Anyway, I rather like this idea.
It may sound unimportant, but it can be very important. A big part of the draw of science fiction games is the feel of the world. That grandeur and mystery - sensawunda, if you prefer - is very important. The very first thing that helps to establish it are the core visuals of the ships and stations. Especially if a player can custom-build things, they'll want to custom-build something wonderful.
There are a lot of details about this that really change how everything feels. For example, how customizable are the ships? Are we talking about swapping out the nacelles on a Star Trek vessel, or about sticking together modules, or about arbitrary mesh placement and deformation? Each has its own strengths and weaknesses both in terms of visuals and gameplay restrictions, and each also has constraints in terms of the resulting visual design.
For example, freeform node placement allows you to put ship components like nacelles, hab bubbles, and so on anywhere you like, overlapping with other components and tilted and scaled in whatever way you think looks cool. However, if the components actually have functions (like weapons, engines, etc) this arbitrary placement can make it feel very awkward when someone places them in a manner that should logically prevent them from working properly. It also makes it difficult to internally connect the components, so it's not really possible to have module A clearly connected to module B - they're all just part of the same mishmash.
On the other hand, a hardpoint component system allows you to place components on the hardpoints of other components. This system is extremely good at relating modules to other modules, and therefore you can create resource chains, interiors, and so on that make sense. Visually, however, the locked-in-place modules are quite restrictive, and you have to be careful to design your module components such that they result in a visually interesting result. It's a lot more limited, and typically the result is a very boxy, militaristic style, because that goes well with the aggressively locked-in orientations and edges.
Those are far from the only options, though.
In my case, I really got to thinking about more organic-looking designs. I got interested in the joins between the modules. In most games, the modules just bump into each other or arbitrarily overlap, but there is value in having a very clear joint or clamp. It looks cool and you can make it highly functional. I was examining some examples when I realized that there was no reason for a space station to have to be ship-shaped.
A space station has no real thrust requirements, so it doesn't have to be shaped like a brick. In fact, it makes a lot more sense for a space station to be sprawled over a vast amount of space: more room for solar panels, less collateral damage if one part is destroyed, a wider separation between living areas and loud, possibly radioactive industrial areas...
So my design today is actually inspired by a sprig of flowers. That's why it's named after flower arranging.
The idea is that a space station "seed" is flung from earth out into space at something like 0.3c. It then spends the next few decades slowly decelerating into orbit around a nearby star.
Over the course of the journey, the seed blooms, growing out a branching, bud-heavy space station. When the distant star is reached, everything begins to unfold and bloom with the energy of that star.
This approach has a few strong points.
1) It's very visually distinct. As far as I know, the "unfolding flower" visual is still very rare in science fiction, and I've never seen it as part of a long 'branch' of flowers.
2) It works well with multiple identical modules. Most science fiction visuals start to look bad if you have dozens of the same module attached - for example, dozens of living areas. That's why they have different sizes of living area modules for different sizes of ship. But with my visuals, having dozens of identical modules just makes your space station look more beautiful and lively, because each one is a bud that unfolds into a flower.
3) It creates a very distinct resource chain. Resources flow up or down branches. This is a bit different from having connected modules, because you can have dozens of modules connected to the same branch. But it's also not the overly-simplistic "global resources" approach many designs take, which means you can have pretty complex localization if you want to start designing trickily.
For example, you might want to do a heavy industrial starbase that squeaks by with minimal actual humans. Therefore, to optimize performance, you might have two industrial branches. One is on, one is off - and you can toggle it. So one branch gathers resources, using up all available workers. When your resources are full, you switch to the other branch and turn off this one, temporarily stopping the resource gathering so you can fire mass packets home. Then turn that off and go back to gathering resources.
4) It creates a very easy modularization: you can save branches, and later on if you want to create those branches again, just poke them into the same seed base. Like Japanese flower arrangement - hence the language chosen for our title.
5) Every flower withers, every journey ends. The visual is a good way to communicate to the player that whatever they've built is mission-specific and is not terribly permanent. This impermanence pushes the player to keep launching, and therefore also pushes the player to keep refining their designs. The network of relays, resource-gathering, and seed-launching is ever-changing.
It also gives us a lot of opportunities to design for longevity. For example, if you wanted a really long-lasting signal relay, the problem isn't the signal dish. It lasts hundreds of years. The problem is the humans. Human habs are medium-duration blossoms and therefore they'll die out long before the relay does. Nobody dies due to the the blossoms wilting, but they do go back into cryo sleep and stop working. Which means you have no workers to work the relay dishes.
You could use an expensive multi-generation mega-blossom, but that's incredibly pricey. Instead, maybe you build dozens of normal habs, but you only activate one at a time. You set up your station to automatically activate the next blossom when the current one is fading using a set of resource barricades on the branch itself.
This has the side effect of also forming a very nice "thermometer". The easiest and most robust design for resource blocking steadily works along the branch, so whenever you pop over for a look at your space station, you can quickly count how long it has left by looking at how many colorful buds remain unopened at the end of the branch.
Similarly, you can use it for rolling out in phases. Mining ships require a fair number of resources to build, and if there are several of them on a branch they will share the incoming resources evenly. This can lead to extreme delays in actually getting ships out: it may be better to use resource blocking to grow just one or two at a time and roll the fleet out in waves - otherwise your other blossoms will age pointlessly until you roll some ships out.
Anyway, I rather like this idea.
Subscribe to:
Posts (Atom)