My last project - For SCIENCE! - developed in a pretty straightforward manner. I put it on pause mostly because it turned out to not really be any fun. I learned a lot from it, and starting up my next project really punched me in the face with those lessons. So let's talk about it again!
The reason For SCIENCE! was so easy to develop was because my mood was strong throughout. I never felt uninspired by my game. And a big part of that was the content. By buying content from the asset store, I filled my game with detailed, fully-textured models right from the start. Even in its early stages, every test run felt like I was building something. A lot of devs can get away with placeholder art, but I evidently can't.
When I moved on to Gravity Grain, I knew I'd need a lot of content, so the first thing I did was create a content creation system. But this really distracted me from creating the game. As I should have realized, content creation tools are really something separate from the game. In fact, the concepts are so distinct that I literally packaged my voxel-object tools up as their own library, so they could be used and reused and imported and exported into any game, anywhere.
STOP! Why?
... Why not just import actual models, at that point? Why not just let people make great stuff in Blender or Maya and import it through the standard Unity asset pipeline? Why create a complicated, difficult-to-maintain voxel system?
Sure, the voxel system had some theoretical advantages. Shared materials between all in-game objects. Easy and meaningful deformation and damage. But... it's a TON of work, and the result has a very specific kind of awkwardness even with the cool smoothing mechanics. It would be more rewarding in the long run to give the players and developer(s) the kind of freedom you get with professional modeling tools.
So, I'm throwing it away.
I'm going back to the proven method I used in For SCIENCE!: getting third party content and feeling like I'm making progress rather than struggling to create both a tool and a game simultaneously.
Friday, May 30, 2014
Wednesday, May 28, 2014
The Hacker's Privilege
I haven't played Watch Dogs, but it has permeated my Twitter feed from both the computer geeks and the gaming geeks. As far as I can tell, it fell afoul of the same problems that plagued my own hacker game prototypes. Well, plus an unhealthy dollop of typical first-person-shooter problems.
Putting aside the FPS issues, the hacker side of the game is plagued by the same issue that always plagues mine:
Hackers are overprivileged little shits.
Fundamentally, hacking is the act of breaking into private places, guarded areas... then using whatever is in there for personal gain. At best, the personal gain might not hurt the target - the hacker might just be doing it for kicks or reputation. But, in general, hackers are going to harm their targets.
This is fine if their targets are simply corporations or other large, faceless entities. A few games have been like this. But those are largely logic puzzles with very little interpersonal interactions. Something like Watch Dogs, where you play a human walking around a human world, is very different. The most interesting targets in that world will be human, because it is a human-centric world.
So you hack people.
In the end, you cannot help the people you hack. You can only either ignore them or abuse them, just like pedestrians in GTA.
Fundamentally, GTA characters are also overprivileged little shits. Even if they are cast as being broke and oppressed by "the man", in terms of actual gameplay they are by far the most powerful people on the planet. They face no real repercussions for their actions, even if their actions are mass murder.
When you add hacking to that, you instantly magnify that problem. Now you don't simply have power over the bodies of unnamed passerbyes. You have power over their minds and lives. It is no longer faceless violence, but directed abuse. You're tormenting someone that has a backstory and personality, however sparse and random it might be. You're tormenting someone with PTSD, or someone that is proud of his olympic athlete sister, or is on parole. You've hacked into their history to learn more about them, and now you're stealing their cash or having them arrested or bringing life to their nightmares.
This is why my hacking game prototypes all lie discarded in my archive directories. As interesting as the mechanics were, the only path forward was to torment individuals. There's not even any real way to help people with video game hacking: at best, your hacks are merely intrusive.
I was thinking about it, and I can't really think of any good way to make a hacking game that isn't about you, the player, being awful. Even if you make the point of the game to hack people's stuff to help them, you're still invading their privacy in a really abusive and dismissive manner.
That's my problem with hacking games.
Watch Dogs, of course, has a lot of other problems. Horrible writing, deeply embedded misogyny, glorifying torture, boring gameplay, and so on. But even in the absence of those, a hacking game revolving around people will always be problematic on its own.
Putting aside the FPS issues, the hacker side of the game is plagued by the same issue that always plagues mine:
Hackers are overprivileged little shits.
Fundamentally, hacking is the act of breaking into private places, guarded areas... then using whatever is in there for personal gain. At best, the personal gain might not hurt the target - the hacker might just be doing it for kicks or reputation. But, in general, hackers are going to harm their targets.
This is fine if their targets are simply corporations or other large, faceless entities. A few games have been like this. But those are largely logic puzzles with very little interpersonal interactions. Something like Watch Dogs, where you play a human walking around a human world, is very different. The most interesting targets in that world will be human, because it is a human-centric world.
So you hack people.
In the end, you cannot help the people you hack. You can only either ignore them or abuse them, just like pedestrians in GTA.
Fundamentally, GTA characters are also overprivileged little shits. Even if they are cast as being broke and oppressed by "the man", in terms of actual gameplay they are by far the most powerful people on the planet. They face no real repercussions for their actions, even if their actions are mass murder.
When you add hacking to that, you instantly magnify that problem. Now you don't simply have power over the bodies of unnamed passerbyes. You have power over their minds and lives. It is no longer faceless violence, but directed abuse. You're tormenting someone that has a backstory and personality, however sparse and random it might be. You're tormenting someone with PTSD, or someone that is proud of his olympic athlete sister, or is on parole. You've hacked into their history to learn more about them, and now you're stealing their cash or having them arrested or bringing life to their nightmares.
This is why my hacking game prototypes all lie discarded in my archive directories. As interesting as the mechanics were, the only path forward was to torment individuals. There's not even any real way to help people with video game hacking: at best, your hacks are merely intrusive.
I was thinking about it, and I can't really think of any good way to make a hacking game that isn't about you, the player, being awful. Even if you make the point of the game to hack people's stuff to help them, you're still invading their privacy in a really abusive and dismissive manner.
That's my problem with hacking games.
Watch Dogs, of course, has a lot of other problems. Horrible writing, deeply embedded misogyny, glorifying torture, boring gameplay, and so on. But even in the absence of those, a hacking game revolving around people will always be problematic on its own.
Thursday, May 22, 2014
Gravity Grain: Mining is Hell
Mining is the most boring game mechanic that was ever thought up. You trade time for a dribble of resources. In the most boring exchange known.
It's boring in Eve. It's boring in Space Engineers. It's boring in FarSky. It's just boring.
Gravity Grain features mining!
HA HA HA HA... ha...
No, it's not nearly as bad in Gravity Grain.
My philosophy is that player time should only be spent on personalization, and then only as much as the player wants. So you can spend any amount of time designing a ship. Then you can put it together largely automatically while you do other things... or you can participate in putting it together in order to customize some of the details. While putting the ship together does take time, Gravity Grain has a time-acceleration system so you don't have to actually wait through it if you don't want to.
Similarly, a player goes on expeditions and missions with the ships they designed. I want them to have to spend time with the things they personalized, and only on those things. So they spend time managing the crew and the crew's resources. They spend time trying to repair damage from a meteorite hit, or running from a pirate. These things reflect on their ship design, their crew choices, the cargo they carry...
But the actual act of mining does not reflect their choices much.
So I don't want them to spend time on it.
I want them to spend time on the mining expedition, the mission, but not the actual act of mining.
Fortunately, there's an easy way out: time acceleration!
When the player goes to mine an asteroid, she has to park her ship on the asteroid using landing clamps. This is done in real time, because it reflects upon the ship design. It's affected by her customization. Then she starts up the gravity auger. This, too, is done manually. But once the gravity auger has punctured the asteroid, there's nothing more for her to do and she is encouraged to accelerate time and get it over with nice and quick.
There isn't any need to choose exactly which square foot to mine: the asteroid is considered a unit. And when you've sucked it dry, it breaks into much smaller pieces that float away. In theory you could mine them, too, but unless your first asteroid was quite huge, they'll probably be too small to deal with.
But, as you can see, it's an automated process. You just let it run until it's obviously finished. Then you can make the choice and customize your mission: do you pursue some of the fragments, too, or just head back with your current haul?
In this way, mining is made painless.
...
Now, unlike something like Space Engineers, FarSky, Terraria, etc, valid mining spots aren't something you just stumble across. Asteroids are scattered tens of thousands of kilometers apart, or further. You'll need some kind of survey ship in the region to scan the area with a telescope to identify likely good mining targets. Then you can either take a scout ship out to sample them for actual good targets, or just cross your fingers and head out with a mining ship without the local survey. Scanning takes time... but is it something that takes the player's time?
Well, it runs automatically in the background, continually scanning. If you want to focus it on specific regions, you can. That doesn't take much time, though. So it doesn't really take the player's time. The player can time-accelerate, or build a ship, or customize the crew, or whatever.
Anyway, all this talk about a game that's still just a voxel tech demo is obviously just hot air. But I wanted to make it clear that wasting a player's time is pretty high on my shit list.
A player's time should be spent on the parts of the game that let them express themselves, rather than bled away on some arbitrary treadmill desperately forcing them to slow down. That's just a sign that your game can't keep players without resorting to cheap tricks.
It's boring in Eve. It's boring in Space Engineers. It's boring in FarSky. It's just boring.
Gravity Grain features mining!
HA HA HA HA... ha...
No, it's not nearly as bad in Gravity Grain.
My philosophy is that player time should only be spent on personalization, and then only as much as the player wants. So you can spend any amount of time designing a ship. Then you can put it together largely automatically while you do other things... or you can participate in putting it together in order to customize some of the details. While putting the ship together does take time, Gravity Grain has a time-acceleration system so you don't have to actually wait through it if you don't want to.
Similarly, a player goes on expeditions and missions with the ships they designed. I want them to have to spend time with the things they personalized, and only on those things. So they spend time managing the crew and the crew's resources. They spend time trying to repair damage from a meteorite hit, or running from a pirate. These things reflect on their ship design, their crew choices, the cargo they carry...
But the actual act of mining does not reflect their choices much.
So I don't want them to spend time on it.
I want them to spend time on the mining expedition, the mission, but not the actual act of mining.
Fortunately, there's an easy way out: time acceleration!
When the player goes to mine an asteroid, she has to park her ship on the asteroid using landing clamps. This is done in real time, because it reflects upon the ship design. It's affected by her customization. Then she starts up the gravity auger. This, too, is done manually. But once the gravity auger has punctured the asteroid, there's nothing more for her to do and she is encouraged to accelerate time and get it over with nice and quick.
There isn't any need to choose exactly which square foot to mine: the asteroid is considered a unit. And when you've sucked it dry, it breaks into much smaller pieces that float away. In theory you could mine them, too, but unless your first asteroid was quite huge, they'll probably be too small to deal with.
But, as you can see, it's an automated process. You just let it run until it's obviously finished. Then you can make the choice and customize your mission: do you pursue some of the fragments, too, or just head back with your current haul?
In this way, mining is made painless.
...
Now, unlike something like Space Engineers, FarSky, Terraria, etc, valid mining spots aren't something you just stumble across. Asteroids are scattered tens of thousands of kilometers apart, or further. You'll need some kind of survey ship in the region to scan the area with a telescope to identify likely good mining targets. Then you can either take a scout ship out to sample them for actual good targets, or just cross your fingers and head out with a mining ship without the local survey. Scanning takes time... but is it something that takes the player's time?
Well, it runs automatically in the background, continually scanning. If you want to focus it on specific regions, you can. That doesn't take much time, though. So it doesn't really take the player's time. The player can time-accelerate, or build a ship, or customize the crew, or whatever.
Anyway, all this talk about a game that's still just a voxel tech demo is obviously just hot air. But I wanted to make it clear that wasting a player's time is pretty high on my shit list.
A player's time should be spent on the parts of the game that let them express themselves, rather than bled away on some arbitrary treadmill desperately forcing them to slow down. That's just a sign that your game can't keep players without resorting to cheap tricks.
Monday, May 19, 2014
Gravity Grain: Gangly Ships
One of the things I hate about modern space-ship building games is that they always produce the same kinds of visual profiles: boxy, utilitarian. 45-degree angles are considered the height of fashion. People can go out of their way to build interesting ships, but if they do, it is at the price of lower efficiency: more weight, more vulnerabilities, etc.
Now, I don't actually hate boxy ships. I just don't want every ship to be boxy.
Gravity Grain features a similar kind of construction system. If I don't go out of my way to make another kind of layout preferable, Gravity Grain will have boxy ships.
The major mechanic Gravity Grain will use is "exclusion zones" - (usually) spherical zones of danger around specific modules. For example, a fusion reactor might have a 200m heat exclusion zone, while an inertialess drive might have a 300m "gravity wobble" exclusion zone. In theory I could model propagation and stuff, but it's easier to both model and understand these things as spheres in space, regardless of how full or empty that space is.
As you enter the heat exclusion zone, your suit would have to work overtime to keep you cool - your time here is limited to your battery life. Similarly, there are many kinds of things that can't function while in an exclusion zone. A bed can't be slept in. An IR transceiver can't broadcast. A telescope can't focus.
More critically, if any two exclusion zones overlap, that area is destructive. If you have two reactors close to each other, or a reactor and an inertialess drive, the place where they overlap will quickly cause damage to anything in that area, whether it's a tile or a person. You can easily rip your own ship apart, and you probably will do exactly that at first.
Obviously this means you have to spread your ships out. That'll be the first thing people learn when building a ship, and I imagine we'll see a lot of long, cylindrical ships from newbies.
But there are a lot of clever tricks hiding under the surface, if you want better performance. Use nacelles: the space between them might have overlapping exclusion zones, but it's just empty space, so it's fine. Use ship modes: balance modules that produce exclusion zones so they either scale back as another one scales up, or turn on and off such that no two ever overlap. And, of course, the ever-popular mechanical extensions - swing things far from the ship to turn them on...
You can even creatively use exclusion zones as shields or weapons, if you're clever. Fire an "inertialess missile" at an enemy, and wherever its field overlaps with an enemy's own internal fields, the enemy takes damage. Doesn't even have to hit - actually, it'd be most effective if it was fired at great speed, then decelerated to a relative stop and just sat near an enemy. Gatling turrets are your best friend, I guess.
All of these reasons lend themselves to spread-out ships. In addition, mass is not as big a concern in this game - structural elements are very, very light, so wasting space on them doesn't really affect your performance characteristics. Of course, those kinds of lightweight elements are also very, very easy to rip apart...
And there are reasons to want a dense ship. First off, a dense ship is easier to land. Also, FTL speeds are based on bounding boxes, so dense ships are faster at warp, if only modestly. Lastly, dense ships tend to have their critical systems in the center, well-protected against meteorite impacts or weapons fire, and are very hard to physically sunder, unlike ships that are mostly long, frail connections. Obviously, a dense warship is also much easier to properly armor, as you need much less armor.
The warp speed thing alone should lead to some fun "fold-out" designs, where the ship is sleek in warp mode, then drops into realspace and extends various kinds of projections, wings, and so on, unfolding for better exclusion-zone performance.
Now, I don't actually hate boxy ships. I just don't want every ship to be boxy.
Gravity Grain features a similar kind of construction system. If I don't go out of my way to make another kind of layout preferable, Gravity Grain will have boxy ships.
The major mechanic Gravity Grain will use is "exclusion zones" - (usually) spherical zones of danger around specific modules. For example, a fusion reactor might have a 200m heat exclusion zone, while an inertialess drive might have a 300m "gravity wobble" exclusion zone. In theory I could model propagation and stuff, but it's easier to both model and understand these things as spheres in space, regardless of how full or empty that space is.
As you enter the heat exclusion zone, your suit would have to work overtime to keep you cool - your time here is limited to your battery life. Similarly, there are many kinds of things that can't function while in an exclusion zone. A bed can't be slept in. An IR transceiver can't broadcast. A telescope can't focus.
More critically, if any two exclusion zones overlap, that area is destructive. If you have two reactors close to each other, or a reactor and an inertialess drive, the place where they overlap will quickly cause damage to anything in that area, whether it's a tile or a person. You can easily rip your own ship apart, and you probably will do exactly that at first.
Obviously this means you have to spread your ships out. That'll be the first thing people learn when building a ship, and I imagine we'll see a lot of long, cylindrical ships from newbies.
But there are a lot of clever tricks hiding under the surface, if you want better performance. Use nacelles: the space between them might have overlapping exclusion zones, but it's just empty space, so it's fine. Use ship modes: balance modules that produce exclusion zones so they either scale back as another one scales up, or turn on and off such that no two ever overlap. And, of course, the ever-popular mechanical extensions - swing things far from the ship to turn them on...
You can even creatively use exclusion zones as shields or weapons, if you're clever. Fire an "inertialess missile" at an enemy, and wherever its field overlaps with an enemy's own internal fields, the enemy takes damage. Doesn't even have to hit - actually, it'd be most effective if it was fired at great speed, then decelerated to a relative stop and just sat near an enemy. Gatling turrets are your best friend, I guess.
All of these reasons lend themselves to spread-out ships. In addition, mass is not as big a concern in this game - structural elements are very, very light, so wasting space on them doesn't really affect your performance characteristics. Of course, those kinds of lightweight elements are also very, very easy to rip apart...
And there are reasons to want a dense ship. First off, a dense ship is easier to land. Also, FTL speeds are based on bounding boxes, so dense ships are faster at warp, if only modestly. Lastly, dense ships tend to have their critical systems in the center, well-protected against meteorite impacts or weapons fire, and are very hard to physically sunder, unlike ships that are mostly long, frail connections. Obviously, a dense warship is also much easier to properly armor, as you need much less armor.
The warp speed thing alone should lead to some fun "fold-out" designs, where the ship is sleek in warp mode, then drops into realspace and extends various kinds of projections, wings, and so on, unfolding for better exclusion-zone performance.
Monday, May 12, 2014
Fun Damage
I've been playing some Space Engineers recently, and I didn't get any sleep last night, so let's talk about the square-cube law. Keep in mind that I'm developing my own space-ship-game prototype right now, so this isn't necessarily commentary on what Space Engineers should do as much as me analyzing gameplay tidbits for future use.
It hasn't really been talked about much, but Space Engineers is really a game about the square-cube law. As your ships get larger, they quickly become too large to destroy. A fighter can be destroyed with one missile. A frigate with two or three. But even a middling-size capital ship can survive dozens and keep going - missiles are more of an annoyance. This is especially nasty given the relatively high manufacture cost of missiles and the manual reload required for fighter missiles. Antimissile systems are in the works, so that means it's going to get even worse!
Basically, it's unfeasible to blow up a capital ship. Aside from disabling missile turrets, it's clear that taking large ships is going to have to be done on foot.
There's a lot of flaws in how Space Engineer does this - for example, the best ground assault is to build a cockpit on the outer hull. That's a dominant strategy that shortcuts nearly all combat. Also, there are no subsystems or systemic failures - a large ship remains one completely intact ship except in the most astounding of situations. That means taking a ship can never be piecemeal, and is always all-or-nothing.
Anyway, there's also the ship after the battle. Space ships built brick by brick have a lot of emotional presence to them. Every brick means something. These are the crew quarters you build. This is the gyroscopic center, it looks cool. That double-command-bridge thing was an awesome idea.
Seeing those places shattered, walls twisted, pieces floating free - that's freaking amazing. I still say the most interesting part of Space Engineers is wandering through devastated ships, and I would love to see a game mode where you rescue survivors or look for dropboxes or something.
But, again, the redundancies and all-or-nothing nature of these ships make it difficult to get that kind of gameplay. Even after being battered to hell and back, a large ship probably has all the things it needs to be a ship - power, engines, gyroscopes, control chairs. Board a large ship devastated by battle and you will usually find all the lights are on, all the engines are raring to go. This gets more and more likely the larger the ship gets.
In both situations, the game would be a lot more interesting if the ship could be divided up properly, with various subsystems, actual pipes and wires, and the chance of systemic failure. Destroying all the engines of a decently-constructed capital ship is quite a task, involving saturation-bombing many areas of the ship. If you don't do that, the ship can still move under its own power. If you DO do that, the ship takes forever to repair because you literally have to build the engines from scratch again.
Imagine if you could knock the engines off-line by aiming for a power conduit. This would be a better situation all around. It would make combat against capital ships more skill-based. It would make capital ship designing more interesting with more tradeoffs. It would allow damaged ships to have systems knocked off-line and require players to route around damage or jerry-rig them back on-line. It would allow people storming the facility to break internal connections.
Required connectivity also allows for subsystem management - wire certain consoles up to certain things and that is all they can control. If some weirdo builds a console on your outer hull, they aren't wired into anything. Maybe use wifi to communicate without wires... but then you can get hacked by someone using wifi on a fighter nearby.
I would also argue that there needs to be more focus on shockwaves rather than blast radii. A missile completely destroys everything within its blast radius and leaves everything beyond that completely unharmed, with the result being that a tiny tick-bite is made. Instead, there should be a shockwave that spreads out from the contact point and deals partial damage to all nearby tiles with a dropoff rate as they are further away. This would allow you to knock components offline with a "near miss". Engines disabled in this way would go dark but not vanish, and you could feasibly repair them. The wider "hit" radius makes the missiles more effective, bringing space combat back to the forefront for another few size classes. It would also "spread out" ship designs, making sprawling, fluted, nacelle-based designs more useful due to shockwave negation.
Both of these changes (connected subsystems and shockwaves) increase the number of things that can go wrong and be repaired afterwards. This has the potential for a lot of fun in combat and in the cleanup afterwards. It also makes ship design matter a lot more, opening up a lot of more advanced tradeoffs. It will also give the inside of the ship more of a function besides "large empty space".
Anyway, the reason I'm considering this is for my new prototype, which involves building space ships out of bricks. I'm trying to keep an eye on the long game, with the idea that the game be fun in many scales. The square-cube law is an important factor. In Space Engineers it appears to crush space combat into a singularity. I think I can avoid that if I keep my eye on the ball. Moreover, the techniques used to bring the square-cube law under control can also provide gameplay at the smaller levels. For example, if you're in a scout ship and get hit by a micro-meteorite, you could suffer secondary damage to several of your tiles, then have a system failure that knocks your main power off-line. That'd be kind of fun.
The planned structure of my prototype involves missions. If you are in a small scout ship, you probably deployed yourself from a larger mothership with a specific mission in mind. You aren't struggling to build a mothership from a scout ship: you're struggling to complete the mission and return to the mothership for more resources and points. Because of this, the way you build and repair things is not the same as in Space Engineers.
You probably would not make any large structural changes to your ship, or put on a new engine. Your repairs would be limited to jerry-rigging, because your ship is task-focused. When you get back to the mothership, yeah, then you can refit and transform your small ship, or build a new one. This mission-based system means you will have large patches of time where you don't have access to your best tools, resources, or facilities. This makes your design (and the ways it fails) much more important, because it is 90% of what gets you through the missions.
Anyway, you can probably tell by how I wrote this essay, but I'm working on no sleep. So I'm done talking.
It hasn't really been talked about much, but Space Engineers is really a game about the square-cube law. As your ships get larger, they quickly become too large to destroy. A fighter can be destroyed with one missile. A frigate with two or three. But even a middling-size capital ship can survive dozens and keep going - missiles are more of an annoyance. This is especially nasty given the relatively high manufacture cost of missiles and the manual reload required for fighter missiles. Antimissile systems are in the works, so that means it's going to get even worse!
Basically, it's unfeasible to blow up a capital ship. Aside from disabling missile turrets, it's clear that taking large ships is going to have to be done on foot.
There's a lot of flaws in how Space Engineer does this - for example, the best ground assault is to build a cockpit on the outer hull. That's a dominant strategy that shortcuts nearly all combat. Also, there are no subsystems or systemic failures - a large ship remains one completely intact ship except in the most astounding of situations. That means taking a ship can never be piecemeal, and is always all-or-nothing.
Anyway, there's also the ship after the battle. Space ships built brick by brick have a lot of emotional presence to them. Every brick means something. These are the crew quarters you build. This is the gyroscopic center, it looks cool. That double-command-bridge thing was an awesome idea.
Seeing those places shattered, walls twisted, pieces floating free - that's freaking amazing. I still say the most interesting part of Space Engineers is wandering through devastated ships, and I would love to see a game mode where you rescue survivors or look for dropboxes or something.
But, again, the redundancies and all-or-nothing nature of these ships make it difficult to get that kind of gameplay. Even after being battered to hell and back, a large ship probably has all the things it needs to be a ship - power, engines, gyroscopes, control chairs. Board a large ship devastated by battle and you will usually find all the lights are on, all the engines are raring to go. This gets more and more likely the larger the ship gets.
In both situations, the game would be a lot more interesting if the ship could be divided up properly, with various subsystems, actual pipes and wires, and the chance of systemic failure. Destroying all the engines of a decently-constructed capital ship is quite a task, involving saturation-bombing many areas of the ship. If you don't do that, the ship can still move under its own power. If you DO do that, the ship takes forever to repair because you literally have to build the engines from scratch again.
Imagine if you could knock the engines off-line by aiming for a power conduit. This would be a better situation all around. It would make combat against capital ships more skill-based. It would make capital ship designing more interesting with more tradeoffs. It would allow damaged ships to have systems knocked off-line and require players to route around damage or jerry-rig them back on-line. It would allow people storming the facility to break internal connections.
Required connectivity also allows for subsystem management - wire certain consoles up to certain things and that is all they can control. If some weirdo builds a console on your outer hull, they aren't wired into anything. Maybe use wifi to communicate without wires... but then you can get hacked by someone using wifi on a fighter nearby.
I would also argue that there needs to be more focus on shockwaves rather than blast radii. A missile completely destroys everything within its blast radius and leaves everything beyond that completely unharmed, with the result being that a tiny tick-bite is made. Instead, there should be a shockwave that spreads out from the contact point and deals partial damage to all nearby tiles with a dropoff rate as they are further away. This would allow you to knock components offline with a "near miss". Engines disabled in this way would go dark but not vanish, and you could feasibly repair them. The wider "hit" radius makes the missiles more effective, bringing space combat back to the forefront for another few size classes. It would also "spread out" ship designs, making sprawling, fluted, nacelle-based designs more useful due to shockwave negation.
Both of these changes (connected subsystems and shockwaves) increase the number of things that can go wrong and be repaired afterwards. This has the potential for a lot of fun in combat and in the cleanup afterwards. It also makes ship design matter a lot more, opening up a lot of more advanced tradeoffs. It will also give the inside of the ship more of a function besides "large empty space".
Anyway, the reason I'm considering this is for my new prototype, which involves building space ships out of bricks. I'm trying to keep an eye on the long game, with the idea that the game be fun in many scales. The square-cube law is an important factor. In Space Engineers it appears to crush space combat into a singularity. I think I can avoid that if I keep my eye on the ball. Moreover, the techniques used to bring the square-cube law under control can also provide gameplay at the smaller levels. For example, if you're in a scout ship and get hit by a micro-meteorite, you could suffer secondary damage to several of your tiles, then have a system failure that knocks your main power off-line. That'd be kind of fun.
The planned structure of my prototype involves missions. If you are in a small scout ship, you probably deployed yourself from a larger mothership with a specific mission in mind. You aren't struggling to build a mothership from a scout ship: you're struggling to complete the mission and return to the mothership for more resources and points. Because of this, the way you build and repair things is not the same as in Space Engineers.
You probably would not make any large structural changes to your ship, or put on a new engine. Your repairs would be limited to jerry-rigging, because your ship is task-focused. When you get back to the mothership, yeah, then you can refit and transform your small ship, or build a new one. This mission-based system means you will have large patches of time where you don't have access to your best tools, resources, or facilities. This makes your design (and the ways it fails) much more important, because it is 90% of what gets you through the missions.
Anyway, you can probably tell by how I wrote this essay, but I'm working on no sleep. So I'm done talking.
Tuesday, May 06, 2014
Starship Grid+
A few days back I posted a video about how grids, voxels, and Minecraft-style bricks aren't well-suited to ship design.
Fundamentally, voxel- or grid-based play is about either controlling flow or ordering a chaotic topology, neither of which are concepts starship games use. I caught a little flak from Space Engineer fans, because Space Engineer almost sort of kinda makes a vague attempt to be about controlling flow. Theoretically, in the future, Space Engineers could be about controlling flow and then their construction method would work well.
But I thought a little about the other half of the equation: grids are also useful for organizing chaotic topology. Could we make a starship construction system out of that?
My idea is that you start with a large-scale grid, a 3D grid where each tile is something like 10x10x5m. You can put all sorts of stuff in there, use mirroring, and all that good stuff. Not every module is 1x1x1: many modules are more awkward shapes that aren't even cubic. For example, a particular engine might be shaped like a pyramid, growing larger and larger as it goes further back.
Some modules can also be arbitrarily extended, such as interior deck space: a long wafer of starship would be a deck, and you could drag it to scale it longer or wider, each "tick" of "wider" or "longer" being one tile unit. You wouldn't make them taller, though: if you wanted another deck level, you'd attach another deck wafer. You could shape these to "hug" the complex shapes of the core functional modules.
Within each deck wafer there is a smaller grid, something like a 2m grid. This grid would be 2D simply because handling it would get too complex otherwise. Within this 2D space you can place various rooms and facilities that are intended to be pressurized, such as bunks, kitchens, gardens, hallways, doors, airlocks, cargo closets, atmospheric exchangers, etc. The large grid means there would be a 5x5-tile "fine grain" grid per large-scale tile, but it wouldn't be a simple 5x5 grid: each kind of deck wafer might have a different shape within that space, and a different reaction to being expanded in various ways. At the minimum, most of the edges would be covered in a hull tile, excepting for occasional spots where you could run a hallway through to another area or put in an airlock.
By giving the deck wafers an internal layout and having it depend on the gross layout of the ship, you create a complex topology inside the ship. The player is then challenged to put the facilities inside that space not simply according to what space is available, but also with concerns as to where the halls are, which parts of a room can have maintenance access to an automated system, which areas should be restricted to what kind of security level...
The best part about this approach is that it could easily be turned into a functional map, where the player moves through that space. Whether in 3D or 2D, the player could be made responsible for his decisions - forced to access the automated systems that were hidden behind someone's wall, forced to traverse the length of the ship, forced to search for a stowaway in all the nooks and crannies, fight a fire, whatever. Leaving the pressurized areas of the ship would be possible, but only if you put on a bulky space suit and not in situations where the ship is accelerating, being bombarded by radiation, or so on.
You can actually use this more deeply, too. While there would undoubtedly be a lot of stock parts, something like a reactor would also be made up of an interior grid. If you wanted to make your own, you could get a particular shape of chassis and put reactor parts into it. Reaction chamber, coolant, control computers, power station, and so on. In doing so you could create a reactor of your own design. This may be a bit complex - for example, if you create a chain of power stations, is that better than just having one? Depends on your application! And, of course, you may have to repair or resupply it during gameplay, so be sure to lay it out reasonably!
Similarly, you can go finer-grain. You don't like the default cabin? Well, each 2x2x3m fine-grain tile consists of a 2x2x3 grid. Place things inside that - walls, furniture, functional elements. Newly researched technologies, epic cultural artifacts, whatever. Now you have a custom room.
You could go even finer, allow the player to construct individual objects using a more typical voxel grid system, then determining the bounds of the object for inclusion into the room editor or equipment system.
Now, just laying out the ship like this is pretty ugly. Ships locked to a large grid layout are generally brutish and bland. A fine grid can work out because you can sculpt it somewhat, but when the grid is 10x10x5m, steps and sweeps are not as feasible. Rather than force the player to carefully create custom shapes for every time they don't like the flat brick approach, we allow the player to warp objects. Each object has a spine and each node in the spine can be moved out of alignment to warp the whole object along a spline. This is really not hard, it's a simple envelope deform.
This offers a number of advantages aside from looking nice.
The first is that a single, continuous object is both cheaper and more durable than the same amount of space using different objects. Rather than breaking your ship up with a deck wafer here and there and there, having one deck wafer that bends to be in those spaces is much more efficient.
The second is that attachments inherit rotation from their root. So if you have a bent deck or module, the item attached to it will be arranged along that tangent or normal instead of the global one. This allows for things like angled wings, huge solar arrays that don't collide, and other grid-breaking alignments.
The third is that a lot of modules are awkwardly shaped due to the requirements of their construction. IE, since particle accelerators have to be arranged in strict lines, your fusion reactor has long-ass prongs coming out of it. By warping either the reactor or the modules passing nearby, you can dodge and weave to keep your ship tightly designed. While there's no penalty for having spidery, sprawling ships, since you have to actually move through them during gameplay it's often hugely advantageous to have a more compact ship.
More interestingly from my perspective, warping the spine of the object also warps the fine-grain mesh within the object. If you've got a deck wafer that is curling right, the outside grid tiles are going to be much larger than the inside grid tiles. Most things can't be compressed that much: if you have a kitchen, you could put it on the outside track and it'd be a more spacious kitchen than normal, which is nice. But if you put it on the inside, you wouldn't even be able to fit a human inside that crushed space, so you can't place a kitchen there.
So the curling introduces a new kind of topological challenge. Put hallways on the inside track, because they are okay with being crushed. Don't bend things like reactors too sharply, because some of the interior components will be crushed and the reactor will not work... but, on the other hand, some reactors might be okay with being warped in one direction but not another, or you could design your own with the final warping in mind from the start.
Of course, as we can go finer-grain, we can also warp finer-grain.
This doesn't matter much for rooms like staterooms, which are probably something like 2x2. Warping really only works if you have something much longer than it is wide - for example, a hallway, or a row of hydroponic plants. Why would you ever want to warp one?
Fundamentally, these long rooms are very much like the deck wafers: you stretch them longer and longer to get more space and performance. There's an overhead with each room, and by simply extending them you save a lot. For example, a hydroponic garden uses 5 space watts plus 1 space watt per tile. The final tile on each end of a hallway is a bulkhead tile, which costs 3 space credits extra and also can't have rooms attached.
If you draw a zig-zag hallway, you end up with 3 hallways and 4 bulkheads. However, if you draw a single long hallway and warp its spine to move from one side to the other, you have only 1 hallway with 2 bulkheads. Of course, this doesn't turn as sharply, so you do end up obstructing some tiles that would have been available otherwise, so it's up to you whether that's worth it. Is it worth saving 6 space credits? It could end up being more than that, depending on how much zig-zagging you need to do.
You can also warp items that you create. Are you creating a custom chair out of voxels? Sounds great! No reason to make it all one object, though. Why not model the back of the chair separately, then add it into the editor and warp its spine so it has a graceful curve to it? Looking to make a fancy shirt? Why not warp the edge between two colors, or create a graceful scoop neck instead of a blocky square-neck.
In these situations, the spin might not just warp: it might also bulge, allowing you to grow or shrink the radius of the voxels in that area. Want to shape your character? Resize the arm spines for bulging biceps. Creating an alien? Stretch out the neck and then give it ominous bulges.
This also works in tandem with the recent idea of the Starship Vignette. If you design a starship with retrofits programmed in right at the start, then your ship's shape needs to be able to handle new modules in new shapes. By warping them cleverly, you can allow your ship to handle several different engines or whatever by making sure they're in the right place to attach properly, and out of the way of the prongs. You can try to get around this by just building sprawling ships, but it'll be really awkward and still might not work any better than reshaping things better.
...
Of course, all of this is just a thought experiment. The content required to create such a game is pretty significant, and I'm working on For SCIENCE at the moment. However, I'm confident in the technology: I've created many demos in Unity where you warp meshes via envelope spline deforms, and they work fine. The game doesn't require any magical AI or anything. It's roughly as complex as Space Engineers or Kerbal.
Even though I don't specifically plan to make this game, I wanted to post it as an example of how you can stretch the concept of construction further than most people think.
Fundamentally, voxel- or grid-based play is about either controlling flow or ordering a chaotic topology, neither of which are concepts starship games use. I caught a little flak from Space Engineer fans, because Space Engineer almost sort of kinda makes a vague attempt to be about controlling flow. Theoretically, in the future, Space Engineers could be about controlling flow and then their construction method would work well.
But I thought a little about the other half of the equation: grids are also useful for organizing chaotic topology. Could we make a starship construction system out of that?
My idea is that you start with a large-scale grid, a 3D grid where each tile is something like 10x10x5m. You can put all sorts of stuff in there, use mirroring, and all that good stuff. Not every module is 1x1x1: many modules are more awkward shapes that aren't even cubic. For example, a particular engine might be shaped like a pyramid, growing larger and larger as it goes further back.
Some modules can also be arbitrarily extended, such as interior deck space: a long wafer of starship would be a deck, and you could drag it to scale it longer or wider, each "tick" of "wider" or "longer" being one tile unit. You wouldn't make them taller, though: if you wanted another deck level, you'd attach another deck wafer. You could shape these to "hug" the complex shapes of the core functional modules.
Within each deck wafer there is a smaller grid, something like a 2m grid. This grid would be 2D simply because handling it would get too complex otherwise. Within this 2D space you can place various rooms and facilities that are intended to be pressurized, such as bunks, kitchens, gardens, hallways, doors, airlocks, cargo closets, atmospheric exchangers, etc. The large grid means there would be a 5x5-tile "fine grain" grid per large-scale tile, but it wouldn't be a simple 5x5 grid: each kind of deck wafer might have a different shape within that space, and a different reaction to being expanded in various ways. At the minimum, most of the edges would be covered in a hull tile, excepting for occasional spots where you could run a hallway through to another area or put in an airlock.
By giving the deck wafers an internal layout and having it depend on the gross layout of the ship, you create a complex topology inside the ship. The player is then challenged to put the facilities inside that space not simply according to what space is available, but also with concerns as to where the halls are, which parts of a room can have maintenance access to an automated system, which areas should be restricted to what kind of security level...
The best part about this approach is that it could easily be turned into a functional map, where the player moves through that space. Whether in 3D or 2D, the player could be made responsible for his decisions - forced to access the automated systems that were hidden behind someone's wall, forced to traverse the length of the ship, forced to search for a stowaway in all the nooks and crannies, fight a fire, whatever. Leaving the pressurized areas of the ship would be possible, but only if you put on a bulky space suit and not in situations where the ship is accelerating, being bombarded by radiation, or so on.
You can actually use this more deeply, too. While there would undoubtedly be a lot of stock parts, something like a reactor would also be made up of an interior grid. If you wanted to make your own, you could get a particular shape of chassis and put reactor parts into it. Reaction chamber, coolant, control computers, power station, and so on. In doing so you could create a reactor of your own design. This may be a bit complex - for example, if you create a chain of power stations, is that better than just having one? Depends on your application! And, of course, you may have to repair or resupply it during gameplay, so be sure to lay it out reasonably!
Similarly, you can go finer-grain. You don't like the default cabin? Well, each 2x2x3m fine-grain tile consists of a 2x2x3 grid. Place things inside that - walls, furniture, functional elements. Newly researched technologies, epic cultural artifacts, whatever. Now you have a custom room.
You could go even finer, allow the player to construct individual objects using a more typical voxel grid system, then determining the bounds of the object for inclusion into the room editor or equipment system.
Now, just laying out the ship like this is pretty ugly. Ships locked to a large grid layout are generally brutish and bland. A fine grid can work out because you can sculpt it somewhat, but when the grid is 10x10x5m, steps and sweeps are not as feasible. Rather than force the player to carefully create custom shapes for every time they don't like the flat brick approach, we allow the player to warp objects. Each object has a spine and each node in the spine can be moved out of alignment to warp the whole object along a spline. This is really not hard, it's a simple envelope deform.
This offers a number of advantages aside from looking nice.
The first is that a single, continuous object is both cheaper and more durable than the same amount of space using different objects. Rather than breaking your ship up with a deck wafer here and there and there, having one deck wafer that bends to be in those spaces is much more efficient.
The second is that attachments inherit rotation from their root. So if you have a bent deck or module, the item attached to it will be arranged along that tangent or normal instead of the global one. This allows for things like angled wings, huge solar arrays that don't collide, and other grid-breaking alignments.
The third is that a lot of modules are awkwardly shaped due to the requirements of their construction. IE, since particle accelerators have to be arranged in strict lines, your fusion reactor has long-ass prongs coming out of it. By warping either the reactor or the modules passing nearby, you can dodge and weave to keep your ship tightly designed. While there's no penalty for having spidery, sprawling ships, since you have to actually move through them during gameplay it's often hugely advantageous to have a more compact ship.
More interestingly from my perspective, warping the spine of the object also warps the fine-grain mesh within the object. If you've got a deck wafer that is curling right, the outside grid tiles are going to be much larger than the inside grid tiles. Most things can't be compressed that much: if you have a kitchen, you could put it on the outside track and it'd be a more spacious kitchen than normal, which is nice. But if you put it on the inside, you wouldn't even be able to fit a human inside that crushed space, so you can't place a kitchen there.
So the curling introduces a new kind of topological challenge. Put hallways on the inside track, because they are okay with being crushed. Don't bend things like reactors too sharply, because some of the interior components will be crushed and the reactor will not work... but, on the other hand, some reactors might be okay with being warped in one direction but not another, or you could design your own with the final warping in mind from the start.
Of course, as we can go finer-grain, we can also warp finer-grain.
This doesn't matter much for rooms like staterooms, which are probably something like 2x2. Warping really only works if you have something much longer than it is wide - for example, a hallway, or a row of hydroponic plants. Why would you ever want to warp one?
Fundamentally, these long rooms are very much like the deck wafers: you stretch them longer and longer to get more space and performance. There's an overhead with each room, and by simply extending them you save a lot. For example, a hydroponic garden uses 5 space watts plus 1 space watt per tile. The final tile on each end of a hallway is a bulkhead tile, which costs 3 space credits extra and also can't have rooms attached.
If you draw a zig-zag hallway, you end up with 3 hallways and 4 bulkheads. However, if you draw a single long hallway and warp its spine to move from one side to the other, you have only 1 hallway with 2 bulkheads. Of course, this doesn't turn as sharply, so you do end up obstructing some tiles that would have been available otherwise, so it's up to you whether that's worth it. Is it worth saving 6 space credits? It could end up being more than that, depending on how much zig-zagging you need to do.
You can also warp items that you create. Are you creating a custom chair out of voxels? Sounds great! No reason to make it all one object, though. Why not model the back of the chair separately, then add it into the editor and warp its spine so it has a graceful curve to it? Looking to make a fancy shirt? Why not warp the edge between two colors, or create a graceful scoop neck instead of a blocky square-neck.
In these situations, the spin might not just warp: it might also bulge, allowing you to grow or shrink the radius of the voxels in that area. Want to shape your character? Resize the arm spines for bulging biceps. Creating an alien? Stretch out the neck and then give it ominous bulges.
This also works in tandem with the recent idea of the Starship Vignette. If you design a starship with retrofits programmed in right at the start, then your ship's shape needs to be able to handle new modules in new shapes. By warping them cleverly, you can allow your ship to handle several different engines or whatever by making sure they're in the right place to attach properly, and out of the way of the prongs. You can try to get around this by just building sprawling ships, but it'll be really awkward and still might not work any better than reshaping things better.
...
Of course, all of this is just a thought experiment. The content required to create such a game is pretty significant, and I'm working on For SCIENCE at the moment. However, I'm confident in the technology: I've created many demos in Unity where you warp meshes via envelope spline deforms, and they work fine. The game doesn't require any magical AI or anything. It's roughly as complex as Space Engineers or Kerbal.
Even though I don't specifically plan to make this game, I wanted to post it as an example of how you can stretch the concept of construction further than most people think.
Monday, May 05, 2014
Starship Vignette
I've been brainstorming about a very specific kind of game. A game where you build something, and over the course of its mission/life, chunks of it are destroyed. For example, Kerbal's stages as you launch, transfer orbits, land, etc. This pattern allows the player to build many ships, and also to build their ships to a wide variety of complex, targeted tasks.
I came up with a few ideas, but the one I want to talk about here is the idea of the "Ship Vignette".
In this game, you build a starship. This is a proper scifi starship, with FTL engines and all that stuff. So you might put down various structural hull elements, lay out a crew area, plug in a few engines and generators and stuff. This isn't a brick-by-brick thing, and instead it's mostly module-focused.
However, when you complete your ship design, you don't pilot it. Instead, it enters mass production. Everyone begins to use your ship. You are presented with a variety of short vignettes you can play aboard your ship. Resisting a boarding attempt. Trying to safely land while damaged. Trying to repair it after a meteorite hit. Whatever else. Vignettes don't happen "now". They happen at some point in the future. 5 years. 10 years. 2 years. 100 years.
Each vignette you play through adds to the ship's effectiveness on the market right from the start, though.
Because that's what you're really doing. You're engineering a ship to be useful to a lot of people in the galactic market. So if you build a freighter, the economy will improve. Build a patrol vehicle, the safety will improve. Build a science vessel, you'll get breakthroughs. Build a colonizer, a hospital ship, an explorer... each one has a statistical effect, determining how your civilization expands and behaves.
And, of course, your success in the vignettes will be affected by the design of your ship. The layout, the available supplies, the amount of redundancies. Do you design in redundancies despite the high expense? Do you mount a turret on every ship because it helps get through vignettes? Or perhaps you release military vessels to reduce to the amount of piracy, and thereby reduce the number and difficulty of those kinds of vignettes?
I think this sounds relatively interesting already, but here's the real hook:
When you design your ship, modules you haven't researched yet are available to you. Oh, that warp drive isn't available right now, but it will be available in ten years. That cargo autoloader isn't available yet, but in twenty years...
Similarly, all the modules you have researched have a duration. Oh, that engine has a halflife of 10 years. That garden dome has a halflife of 5 years.
When you design your ship, you can pan forward and backwards along its operational life-cycle. Put the engine you have now into the ship at the beginning. Move forward 10 years in the ship's life span. Now you will have discovered the new kind of warp drive: remove the original one and put in the new one. If you were smart enough to plan ahead for its different size, shape, and resource requirements.
Or, alternately, mark the part for replacement with an identical part... adding to the cost of the ship, but meaning you won't have many 'engines failed in deep space' vignettes screwing you up.
Move forward another 10 years, mark it as "retired", so you won't have to worry about vignettes taking place further in the future than that. Oh, it may show up in other vignettes as an old clunker, but you won't have to worry about trying to push through brutal "everything is broken" vignettes. Of course, that limits the timespan in which its effectiveness is applied - take a cargo ship off the market after 20 years, and that means the economic boost will fade after 20 years. Extend its lifespan with replacement parts, it'll boost for longer... but less effectively or at a much higher up front cost.
As you build ships, the future steadily changes even as you march slowly towards it. Put out a fleet of cop ships and subsequent ships won't have nasty pirate vignettes, even though earlier ships the same distance into the future did have nasty pirate vignettes. Put out a science fleet and the new engine that was 10 years away is now 5 years away. Of course, your original designs still have it plugged into their design assuming a 10 year delay, so your older ships will feel clunkier, adopting that tech long after more recently-designed ships.
There's a lot of promise here, especially when you consider both "soft" and "hard" multiplayer.
Hard multiplayer would be when multiple players control either the same faction, simultaneously using the same resources and putting out ships; or control multiple factions with time moving forward at a specific set rate. These are strongly resource-limited and would really put a heavy emphasis on excellent design and future management.
Soft multiplayer would be sharing universe elements without actually chaining them together. For example, running into a nation or ship that was created by another player, although that player is not controlling them and may never even know you encountered them. Since these interactions are primarily via vignettes, there's no risk of a technologically advanced or warlike player dominating a less advanced player: there's no such thing as "going on an offensive" or "conquest". Moreover, stealing technological tidbits or performing cultural exchange during a vignette can net valuable resources for your next ship design without actually harming the other player at all.
I especially like the way that the ships you build continue to stack up. If you build a cop ship as your 4th design, it may have a vignette where it tries to save your 2nd ship design from your 3rd ship design. The 1st design may still be kicking around after your 30th design, a vintage clunker still serving as a staple in the less urban areas of your civilization.
Combined with a steady stream of current events as "today" moves forward, you can have a very strong sense of place.
I like it!
I came up with a few ideas, but the one I want to talk about here is the idea of the "Ship Vignette".
In this game, you build a starship. This is a proper scifi starship, with FTL engines and all that stuff. So you might put down various structural hull elements, lay out a crew area, plug in a few engines and generators and stuff. This isn't a brick-by-brick thing, and instead it's mostly module-focused.
However, when you complete your ship design, you don't pilot it. Instead, it enters mass production. Everyone begins to use your ship. You are presented with a variety of short vignettes you can play aboard your ship. Resisting a boarding attempt. Trying to safely land while damaged. Trying to repair it after a meteorite hit. Whatever else. Vignettes don't happen "now". They happen at some point in the future. 5 years. 10 years. 2 years. 100 years.
Each vignette you play through adds to the ship's effectiveness on the market right from the start, though.
Because that's what you're really doing. You're engineering a ship to be useful to a lot of people in the galactic market. So if you build a freighter, the economy will improve. Build a patrol vehicle, the safety will improve. Build a science vessel, you'll get breakthroughs. Build a colonizer, a hospital ship, an explorer... each one has a statistical effect, determining how your civilization expands and behaves.
And, of course, your success in the vignettes will be affected by the design of your ship. The layout, the available supplies, the amount of redundancies. Do you design in redundancies despite the high expense? Do you mount a turret on every ship because it helps get through vignettes? Or perhaps you release military vessels to reduce to the amount of piracy, and thereby reduce the number and difficulty of those kinds of vignettes?
I think this sounds relatively interesting already, but here's the real hook:
When you design your ship, modules you haven't researched yet are available to you. Oh, that warp drive isn't available right now, but it will be available in ten years. That cargo autoloader isn't available yet, but in twenty years...
Similarly, all the modules you have researched have a duration. Oh, that engine has a halflife of 10 years. That garden dome has a halflife of 5 years.
When you design your ship, you can pan forward and backwards along its operational life-cycle. Put the engine you have now into the ship at the beginning. Move forward 10 years in the ship's life span. Now you will have discovered the new kind of warp drive: remove the original one and put in the new one. If you were smart enough to plan ahead for its different size, shape, and resource requirements.
Or, alternately, mark the part for replacement with an identical part... adding to the cost of the ship, but meaning you won't have many 'engines failed in deep space' vignettes screwing you up.
Move forward another 10 years, mark it as "retired", so you won't have to worry about vignettes taking place further in the future than that. Oh, it may show up in other vignettes as an old clunker, but you won't have to worry about trying to push through brutal "everything is broken" vignettes. Of course, that limits the timespan in which its effectiveness is applied - take a cargo ship off the market after 20 years, and that means the economic boost will fade after 20 years. Extend its lifespan with replacement parts, it'll boost for longer... but less effectively or at a much higher up front cost.
As you build ships, the future steadily changes even as you march slowly towards it. Put out a fleet of cop ships and subsequent ships won't have nasty pirate vignettes, even though earlier ships the same distance into the future did have nasty pirate vignettes. Put out a science fleet and the new engine that was 10 years away is now 5 years away. Of course, your original designs still have it plugged into their design assuming a 10 year delay, so your older ships will feel clunkier, adopting that tech long after more recently-designed ships.
There's a lot of promise here, especially when you consider both "soft" and "hard" multiplayer.
Hard multiplayer would be when multiple players control either the same faction, simultaneously using the same resources and putting out ships; or control multiple factions with time moving forward at a specific set rate. These are strongly resource-limited and would really put a heavy emphasis on excellent design and future management.
Soft multiplayer would be sharing universe elements without actually chaining them together. For example, running into a nation or ship that was created by another player, although that player is not controlling them and may never even know you encountered them. Since these interactions are primarily via vignettes, there's no risk of a technologically advanced or warlike player dominating a less advanced player: there's no such thing as "going on an offensive" or "conquest". Moreover, stealing technological tidbits or performing cultural exchange during a vignette can net valuable resources for your next ship design without actually harming the other player at all.
I especially like the way that the ships you build continue to stack up. If you build a cop ship as your 4th design, it may have a vignette where it tries to save your 2nd ship design from your 3rd ship design. The 1st design may still be kicking around after your 30th design, a vintage clunker still serving as a staple in the less urban areas of your civilization.
Combined with a steady stream of current events as "today" moves forward, you can have a very strong sense of place.
I like it!
Subscribe to:
Posts (Atom)