So, I'm going to be one of those guys that brings in suggestion/food for thoughts for the game. Sorry, but I really had to do it. Especially now with the dev build featuring parts of the new HP/Armor system, which I'm still a bit skeptical about.
Even though its in the suggestion sub-forum, Its all up to discussion. Its just that I wasn't really sure it was good idea to put this in the general discussion sub-section or here.
What I'm going to suggest is going to be pretty flexible, and mostly builds upon what we have, instead of changing everything from the ground up. I don't claim to have the perfect answer, nor do I claim that all of this is worth implementing. Parts of this post also merely suggest focusing on some of those aspects sooner rather than later.
Oh, and I'm very aware that a lot of these things were brought up separately, or that those will probably be addressed in the future. So, if you're only here to tell me about that, don't waste your time reading this, or telling me. Thank you.
The devs might have their ideas on how to do this, but that's why I'm throwing in this suggestion. Its possible that some of the things here weren't considered by them yet. But there isn't any way to really be sure of that.
But I digress.
( If you don't feel like reading too much, I suggest quickly reading the list of issues below, skip the observations. Then read section 1.2, section 1.3, and section 3.1. Those contains the most important bits, and most have pictures that explains things much better. )
First, what are the game's most annoying balance issues right now ?
There are a bunch, but lets take a couple of generic ones that comes up often:
- Larger ships are always better.
- Weapons are unbalanced and missiles are almost without contest the king of the battlefield.
- No scarcity, no implicit cost, no value, to most things.
- Ships lacks weaknesses.
This is of course, relative to each player's own reality. And is aimed mainly at the sandbox / survival game mode. But you gotta start somewhere, no ?
Considering those issues, here are a few observations:
Based on these observations here are some suggestions:
1. Ship Systems
1.1. Effectiveness Coefficient:(Need some re-thinking)
1.2. Multiblock Tiered Systems: (Pictures)
1.3. System Weakness
2. Ship combat
That's pretty much it. I tried to keep it short, but I've re-written this thing at least 4 times now, over a month, and I can't shorten it anymore.. Especially since the game is changing faster than I'm writing this..
But anyways, the point of all this is to bring ideas, and feed discussion. So I'd like to hear some feedback, and possible improvements to these. I suggest specifying what point you're commenting on, to make discussion easier.
Also, congrats if you read it all !
I'm predicting this won't be the case for most.. Which is somewhat understandable at this point ^^;
Even though its in the suggestion sub-forum, Its all up to discussion. Its just that I wasn't really sure it was good idea to put this in the general discussion sub-section or here.
What I'm going to suggest is going to be pretty flexible, and mostly builds upon what we have, instead of changing everything from the ground up. I don't claim to have the perfect answer, nor do I claim that all of this is worth implementing. Parts of this post also merely suggest focusing on some of those aspects sooner rather than later.
Oh, and I'm very aware that a lot of these things were brought up separately, or that those will probably be addressed in the future. So, if you're only here to tell me about that, don't waste your time reading this, or telling me. Thank you.
The devs might have their ideas on how to do this, but that's why I'm throwing in this suggestion. Its possible that some of the things here weren't considered by them yet. But there isn't any way to really be sure of that.
But I digress.
( If you don't feel like reading too much, I suggest quickly reading the list of issues below, skip the observations. Then read section 1.2, section 1.3, and section 3.1. Those contains the most important bits, and most have pictures that explains things much better. )
First, what are the game's most annoying balance issues right now ?
There are a bunch, but lets take a couple of generic ones that comes up often:
- Larger ships are always better.
Smaller ship do nothing better than larger ones. While larger ships do everything smaller ship do and more. Besides not being laggy, and being small.
- Weapons are unbalanced and missiles are almost without contest the king of the battlefield.
Module to effectiveness ratio is tremendous for missiles. And some other weapons are limited by the game's behavior and bugs themselves. Some others have no reasons to exist, no practical purpose.
Since all weapons are just generic damage dealers, offering little perks on their own, there are no reasons not to use the most effective one. The ones that can't miss, and deal the most damages, aka missiles.
Since all weapons are just generic damage dealers, offering little perks on their own, there are no reasons not to use the most effective one. The ones that can't miss, and deal the most damages, aka missiles.
- No scarcity, no implicit cost, no value, to most things.
No value to planets or sectors, because their resource can be obtained anywhere else, at no extra costs for anyone. No cost for travelling around in space, shops and “shipyards”(build mode) are everywhere, climate and environmental differences between planets cause no issues to anyone or anything (basically all planets are habitable, and exploiting them and building bases isn't more complicated on any of them, unless they're in the star's killzone..).
That means, no resource/territory wars, no real worth in trading, less value to maintaining alliances with other factions economically.
Transport and storage in large quantities has no costs, or doesn't require much “effort” or planning, or specialized tools/ships. A single storage container can contain an entire planet's worth in blocks.
Shops spawn like flies, and stock up on everything.(and they have strange and random quantities of items available)
No reliance on supplies, so a fleet can camp a sector indefinitely, without having a forward base or supply chain, or having to head back to base to resupply.
That means, no resource/territory wars, no real worth in trading, less value to maintaining alliances with other factions economically.
Transport and storage in large quantities has no costs, or doesn't require much “effort” or planning, or specialized tools/ships. A single storage container can contain an entire planet's worth in blocks.
Shops spawn like flies, and stock up on everything.(and they have strange and random quantities of items available)
No reliance on supplies, so a fleet can camp a sector indefinitely, without having a forward base or supply chain, or having to head back to base to resupply.
- Ships lacks weaknesses.
One has to find and destroy the core block with pinpoint accuracy to truly defeat a ship. Internal systems are so spread out, thanks to the game implicitly forcing the player to spread things out, that it takes a while to disable a ship this way. And that's not a “good difficulty factor”, because the only reason its taking so long is because of the size of the target to hit. Not because of the design or combat prowess of the ship you're facing !
Low output per individual system blocks means you need to destroy more of them to even cripple another ship. And the way power blocks need to be laid out further complicate things. On medium-sized ships, they're most often spread into lines, which makes it hard to cripple the power system of a ship in as few shots as possible, not factoring the armor or shields. And on large sized ships, because of the post 1 million e, limit, builders can spread the power blocks further with no restrictions, which complicates things even more so..
Thrusters can be put anywhere, and will be, because they do not need to be exposed to space to work. And also because you can't customize how they look. This means that, often shipbuilders prefer to cover them up with something prettier, and/or just put them in some random places.
Weapons systems arrays have to have each of their groups separated from eachothers, which is fine in itself, but it furthers makes disabling weapons complicated. Not to mention, that, sometimes if you manage to ruin one weapon system, and its slaved weapon system wasn't nearby, it can still be used against you.. So in essence, destroying a weapon system doesn't guaranty you're actually going to reduce the other ship's firepower..
Example:
Low output per individual system blocks means you need to destroy more of them to even cripple another ship. And the way power blocks need to be laid out further complicate things. On medium-sized ships, they're most often spread into lines, which makes it hard to cripple the power system of a ship in as few shots as possible, not factoring the armor or shields. And on large sized ships, because of the post 1 million e, limit, builders can spread the power blocks further with no restrictions, which complicates things even more so..
Thrusters can be put anywhere, and will be, because they do not need to be exposed to space to work. And also because you can't customize how they look. This means that, often shipbuilders prefer to cover them up with something prettier, and/or just put them in some random places.
Weapons systems arrays have to have each of their groups separated from eachothers, which is fine in itself, but it furthers makes disabling weapons complicated. Not to mention, that, sometimes if you manage to ruin one weapon system, and its slaved weapon system wasn't nearby, it can still be used against you.. So in essence, destroying a weapon system doesn't guaranty you're actually going to reduce the other ship's firepower..
Example:
You have a sniper beam or cannon array. And you made sure the modules for the beam/canon and missile are far apart. If they somehow managed to destroy your canon/beam computer, or all your modules for it, you'll still have a pretty potent and powerful unguided missile system at your disposal. (perhaps even more powerful than the canon/beam was actually..)
Of course, power could be an issue in this example, but, I doubt I'm alone when I'm building ships that produce more power than they need..
So, from a player point of view, ships have no other serious weaknesses that could put them out of commission nearly as fast and as reliably as destroying the core. You even know about where the core is thanks to the HUD. Which makes it even more the target of choice on a ship!Of course, power could be an issue in this example, but, I doubt I'm alone when I'm building ships that produce more power than they need..
This is of course, relative to each player's own reality. And is aimed mainly at the sandbox / survival game mode. But you gotta start somewhere, no ?
Considering those issues, here are a few observations:
- Focusing on scarcity/economy, and taking advantage of those, would mitigate potentially a lot of those issues. Along with other issues that are directly or indirectly connected. (see below)
- Establishing a proper resources tiering system, and spreading “high-tier” resource density, and availability around more thinly would give more worth to some planets and systems over others. While more basic, omnipresent resources could be found more commonly everywhere.
- Diverting from the current way of how systems blocks calculate output would do much good. Something that wouldn't implicitly reward people as much for filling everything with modules, leaving no empty space.
- Going with the classic “smaller ships are generally faster” model would be a simple, cheap, yet tried and true and very effective method of helping balance thing out. At the cost of some backyard “realism” of course. (actually, we have no ideas if structural constraints, technical issues related to scale, and other unforeseen factors, wouldn't limit the mobility and top speed of larger ships, regardless of whether there is no real counter-force to hamper them or not..)
- Going towards more of a more rock-paper-scissor influenced kind of approach to combat could implicitly keep in check some of the more implicitly effective weapons like missiles, while still being simple and easy to grasp on the surface.
- Adding more weaknesses to a ship than its core, like an actual complex system would, would open up a range of strategies and building constraints and approaches. More so than the current model, or even than a typical 1 hull, 1 HP bar model.
Based on these observations here are some suggestions:
1. Ship Systems
Given the current system is implicitly biased towards larger ships, I suggest as a first line of defense against the problem, a simple counter. Its already more or less implemented in a way for a few blocks, but this would make it a little more “even”. This counter could work with the current systems only, but it was mainly thought to be used in conjunction with the “Multi-blocks tiered systems” described below, or any other systems not based solely on proportions.
It consists in simply determining a coefficient, a little like the angular acceleration coefficient that's used for the ship's turning speed. But based on the ship's total size on all axis and the amount of blocks used in the ship. This coefficient would increase as the ship gets bigger/gets more blocks. And affect the ship overall, in goods and in bad ways instead of only a few things here and there.
It would primarily represent the ship's system efficiency losses and the ship getting bigger/more cluttered. Considering that, longer wires and cables means more power is lost through increased resistance. And also considering that a lots of systems tends to scale up badly in the “real world”.
We'll refer to it “Effectiveness Coefficient” in this article, for a lack of better name.
It could be used differently on a per system basis, on various aspects of each systems, as seen fit. For example, as the coefficient increases and the ship becomes bigger, it could get an armor bonus, while raw power output would be diminished. But in most cases, using it to affect the raw output of a system would probably be the best approach. It would also affect docked entities, pulling anything from the parent ship, such as turrets.
This would kill two birds with one stone, serving as incentive to build smaller, and giving a buff to smaller ships on most things. Additionally, it would also encourage most people to build within the limitations of the engine, without forcing them to. So people would just go overboard when they really want to. And it wouldn't leave large ships at a complete disadvantage either, thanks to a few perks that could be computed from that coefficient.
Here's a little example on how this could work:
It consists in simply determining a coefficient, a little like the angular acceleration coefficient that's used for the ship's turning speed. But based on the ship's total size on all axis and the amount of blocks used in the ship. This coefficient would increase as the ship gets bigger/gets more blocks. And affect the ship overall, in goods and in bad ways instead of only a few things here and there.
It would primarily represent the ship's system efficiency losses and the ship getting bigger/more cluttered. Considering that, longer wires and cables means more power is lost through increased resistance. And also considering that a lots of systems tends to scale up badly in the “real world”.
We'll refer to it “Effectiveness Coefficient” in this article, for a lack of better name.
It could be used differently on a per system basis, on various aspects of each systems, as seen fit. For example, as the coefficient increases and the ship becomes bigger, it could get an armor bonus, while raw power output would be diminished. But in most cases, using it to affect the raw output of a system would probably be the best approach. It would also affect docked entities, pulling anything from the parent ship, such as turrets.
This would kill two birds with one stone, serving as incentive to build smaller, and giving a buff to smaller ships on most things. Additionally, it would also encourage most people to build within the limitations of the engine, without forcing them to. So people would just go overboard when they really want to. And it wouldn't leave large ships at a complete disadvantage either, thanks to a few perks that could be computed from that coefficient.
Here's a little example on how this could work:
If you'd build a really really huge ship, the biggest you can think of, crammed with weapons systems shields and armor, with barely any empty space, its coefficient could be say, 50%(0.5).
And so, your ship's individual reactor groups output would be cut in half. Your ship's weapons could perhaps deal only 50% damages, or just use 50% more energy, or even just fire 50% slower. But that ship would get a large armor buff, lets say each armor block would be 50% more durable.
Or even something more cumulative, depending on how the devs' newly announced/rumored armor system will work. Thus the ship would need less armor, and get more free space for other things.
While if you'd build a tiny ship, you'd get a coefficient of say, 1%(0.01). You'd lose only 1% of your reactor output, and so on..
This is over-simplified of course. It would need some fine-tuning to get it right, and perhaps need to be calculated non-linearly, using a curve. Of course, this would imply there would be a “sweet spot” on this curve. A size where the amount of systems and ship size would be optimal. And that's why the next section will bring up something to potentially help with this.And so, your ship's individual reactor groups output would be cut in half. Your ship's weapons could perhaps deal only 50% damages, or just use 50% more energy, or even just fire 50% slower. But that ship would get a large armor buff, lets say each armor block would be 50% more durable.
Or even something more cumulative, depending on how the devs' newly announced/rumored armor system will work. Thus the ship would need less armor, and get more free space for other things.
While if you'd build a tiny ship, you'd get a coefficient of say, 1%(0.01). You'd lose only 1% of your reactor output, and so on..
In order to supplement/complement the current more or less proportion based system, and transition towards something a little more flexible for players, I'd suggest adding 2 tiers to the basic single-block system used currently.
Those would involve building a shaped structure using certain blocks, a little like the portals in minecraft, or maybe a little like the thinker construct's smelter. They would go from simple tier 2 made up of maybe 2 to 3 different block types, to more complex tier 3 structures that could be made of perhaps 3 to 6 types of different blocks.
Those tiers would use the current system's block as core, and build around it, to facilitate upgrading. All 3 tiers could be used together on the entity ship too.
Here's an example (Shapes and designs are just for demonstration purpose):
Customization of a System.
Changing the proportions of each block types used in assembling a multi-block system would affect the way it work, depending on the system type. Like for example, adding more core blocks in a reactor system could possibly increase the power output and possibly fuel consumption (if fuel happens), but in turn would need more of the other blocks.
Another very interesting trait of this system would be that, you could substitute blocks in the design for others that might add different properties to the system overall.
For example, if the system was a canon, you could replace half of one block type used in building the structure with one that makes projectiles explosive. And then half of what's left with something that makes your projectile penetrate more armor. Then you could replace half of another block type used in the structure with blocks that makes the weapon shoot faster.
The result would be a canon system that shoot 50% faster than the base one, has 50% of the explosive effect applied to its projectile, and got 25% of armor penetration effect applied to it. The proportions of the system would implicitly balance out combined effects in the end. Moreover, each isolated group, within a weapon array sharing a single computer could each be customized differently, since each group is isolated from eachothers. So you could have a few EMP canons with a few fast-firing machine gun explosive canon.
So, you'd be able to tweak your weapons just like it is possible currently, and even further, using as much, if not less space, and on a much more versatile(combining several effects together) and compact level than the system linking made it possible before.
And, that also leaves the possibility of using this approach to change the weapon's behavior, instead of slaving systems together. Thus, no bad surprises when destroying an enemy's weapon system, and finding out it was linked to a huge missile system, which is now being used against you and basically nullifying your efforts invested in destroying the opponent’s weapons..
Here are a few examples of blocks proportion and types variations (designs are again only for demonstration, choosing shapes that can be better customized/covered up by player will have to be done by the designers themselves as I have no insights into the engine structure, or the team's short/long terms design goals ):
Dynamically Tweaking a System.
If the rail system ever allows it, it could even be possible to dynamically change the system's output/behavior by sliding blocks next to the core blocks ! Which for example, in the case of a power reactor, could mean that short burst of power in exchange for possibly higher fuel consumption (again if fuel is implemented. Its just a convenient example) would be doable with this system. (It could also be made to look a little like an actual fission reactor's control rod system, which is pretty cool )
How it All Works Together.
Higher tier multiblocks systems would be superior to the single block system in terms of raw output, something that is more desirable for larger ships if using the “Effectiveness Coefficient”, and they'd bring in the bonus of being customizable too. But in turn, they would create a weaknesses in requiring to be centralized more and more(more vulnerable to weapon fire), they'd be more expansive, and require slightly more space for their “smallest possible design”. A single block is always more compact than several..
Another big advantage here is that, since you could chose not to be relying on a system requiring a significantly larger proportion of the ship filled with blocks, you'd have more room for other things, such as decorations, hangars, weapons, cargo space(see cargo system below), shields, cockpit, escape pods, etc.. The “Effectiveness Coefficient” would take care of good part of the size balancing issue transparently without having to deal with what feels like useless filler blocks that are only there as some kind of penality.
And to top it off, if you'd want to slap a tier 3 system in your fighter craft design, you could. You'd have to make trade-offs to fit that within the design, such as assigning more space to those systems, dealing with the additional vulnerability to weapon fire, and ensuring the requirements of the system are met. But you'd benefit from a better “Effectiveness Coefficient”, and higher raw system output, and potentially more customization and maybe even dynamically changing your system's output.
This would balance itself out, thanks to the higher tier systems being also reliant on their individual size to provide output(a little like the current power systems, but this way you can't cram nearly as much individual systems next to each-others given the structure are more complex, and terminator/wrapping blocks could help isolate systems implicitly), and thanks to size reducing system efficiency. It would balance things more so if bigger ships are slower than smaller ones in the future, as ship builder will have to keep in mind many more variables to make a good ship.
For example, fighters with a large tier 3 reactor would need more blocks, be larger, and slower than if they hadn't a tier 3 system. And if not larger they'd have less room for other things than fighters of a comparable size.
For larger ships, using all 3 tiers to optimize the entire setup would probably be a plus in order to reduce total size/block count and get the best “Effectiveness Coefficient” possible.
Going further with this, and throwing a little extra idea:
Maybe tier 2-3 systems could be the only ones requiring resources to consume, such as fuel or ammunition, while Tier 1 would still work mostly as it does right now ?
Those would involve building a shaped structure using certain blocks, a little like the portals in minecraft, or maybe a little like the thinker construct's smelter. They would go from simple tier 2 made up of maybe 2 to 3 different block types, to more complex tier 3 structures that could be made of perhaps 3 to 6 types of different blocks.
Those tiers would use the current system's block as core, and build around it, to facilitate upgrading. All 3 tiers could be used together on the entity ship too.
Here's an example (Shapes and designs are just for demonstration purpose):
Customization of a System.
Changing the proportions of each block types used in assembling a multi-block system would affect the way it work, depending on the system type. Like for example, adding more core blocks in a reactor system could possibly increase the power output and possibly fuel consumption (if fuel happens), but in turn would need more of the other blocks.
Another very interesting trait of this system would be that, you could substitute blocks in the design for others that might add different properties to the system overall.
For example, if the system was a canon, you could replace half of one block type used in building the structure with one that makes projectiles explosive. And then half of what's left with something that makes your projectile penetrate more armor. Then you could replace half of another block type used in the structure with blocks that makes the weapon shoot faster.
The result would be a canon system that shoot 50% faster than the base one, has 50% of the explosive effect applied to its projectile, and got 25% of armor penetration effect applied to it. The proportions of the system would implicitly balance out combined effects in the end. Moreover, each isolated group, within a weapon array sharing a single computer could each be customized differently, since each group is isolated from eachothers. So you could have a few EMP canons with a few fast-firing machine gun explosive canon.
So, you'd be able to tweak your weapons just like it is possible currently, and even further, using as much, if not less space, and on a much more versatile(combining several effects together) and compact level than the system linking made it possible before.
And, that also leaves the possibility of using this approach to change the weapon's behavior, instead of slaving systems together. Thus, no bad surprises when destroying an enemy's weapon system, and finding out it was linked to a huge missile system, which is now being used against you and basically nullifying your efforts invested in destroying the opponent’s weapons..
Here are a few examples of blocks proportion and types variations (designs are again only for demonstration, choosing shapes that can be better customized/covered up by player will have to be done by the designers themselves as I have no insights into the engine structure, or the team's short/long terms design goals ):
Dynamically Tweaking a System.
If the rail system ever allows it, it could even be possible to dynamically change the system's output/behavior by sliding blocks next to the core blocks ! Which for example, in the case of a power reactor, could mean that short burst of power in exchange for possibly higher fuel consumption (again if fuel is implemented. Its just a convenient example) would be doable with this system. (It could also be made to look a little like an actual fission reactor's control rod system, which is pretty cool )
How it All Works Together.
Higher tier multiblocks systems would be superior to the single block system in terms of raw output, something that is more desirable for larger ships if using the “Effectiveness Coefficient”, and they'd bring in the bonus of being customizable too. But in turn, they would create a weaknesses in requiring to be centralized more and more(more vulnerable to weapon fire), they'd be more expansive, and require slightly more space for their “smallest possible design”. A single block is always more compact than several..
Another big advantage here is that, since you could chose not to be relying on a system requiring a significantly larger proportion of the ship filled with blocks, you'd have more room for other things, such as decorations, hangars, weapons, cargo space(see cargo system below), shields, cockpit, escape pods, etc.. The “Effectiveness Coefficient” would take care of good part of the size balancing issue transparently without having to deal with what feels like useless filler blocks that are only there as some kind of penality.
And to top it off, if you'd want to slap a tier 3 system in your fighter craft design, you could. You'd have to make trade-offs to fit that within the design, such as assigning more space to those systems, dealing with the additional vulnerability to weapon fire, and ensuring the requirements of the system are met. But you'd benefit from a better “Effectiveness Coefficient”, and higher raw system output, and potentially more customization and maybe even dynamically changing your system's output.
This would balance itself out, thanks to the higher tier systems being also reliant on their individual size to provide output(a little like the current power systems, but this way you can't cram nearly as much individual systems next to each-others given the structure are more complex, and terminator/wrapping blocks could help isolate systems implicitly), and thanks to size reducing system efficiency. It would balance things more so if bigger ships are slower than smaller ones in the future, as ship builder will have to keep in mind many more variables to make a good ship.
For example, fighters with a large tier 3 reactor would need more blocks, be larger, and slower than if they hadn't a tier 3 system. And if not larger they'd have less room for other things than fighters of a comparable size.
For larger ships, using all 3 tiers to optimize the entire setup would probably be a plus in order to reduce total size/block count and get the best “Effectiveness Coefficient” possible.
Going further with this, and throwing a little extra idea:
Maybe tier 2-3 systems could be the only ones requiring resources to consume, such as fuel or ammunition, while Tier 1 would still work mostly as it does right now ?
In order to make ship combat less based around exploiting the fact that a ship's only real weakness is its core, I'd suggest turning some of the mandatory systems into bigger weaknesses than they are right now. Not radically though.
In the real world, you do not obliterate an entire ship to destroy it, or any other vehicles. You hit its critical systems/parts, trigger an explosion inside by hitting its ammunition stores or fuel tanks, or you disable the crew. Those are the fastest most reliable ways of disabling/putting out of commission an opposing vehicle. And they're especially relevant to consider in starmade, considering voxels works a little like real-life objects, that can be broken in parts.
Right now, in StarMade, the quickest way to put out of business another ship is to destroy its core. That can make it unfair/lame however, as its a single block amidst potentially thousands upon thousands of others. Most other games avoid all this by turning the whole ship into a single entity with a set HP rating, which addresses completely the issue of needing weaknesses. But that's not really such a great solution, especially for a voxel based game, where a good chunk of the point of using voxels would be thrown out the window.. ( pun intended :p )
A way to address this is to make systems more vulnerable to weapons. This solution is tightly linked with the Multi-blocks system's tendency of inciting more vulnerable designs on large scale vessels, and also from the dependency on fuel and ammunition for some weapons, as brought up later in section 2 and 3 below.
But its also possible to have systems explode, or burn, or malfunction temporarily after being hit. Some systems could also be vulnerable to being disrupted at least temporarily after being hit by certain weapons. Such as EMP weapons for instance.
Having more weaknesses would encourage players to get a little more creative and avoid pretty much using module blocks as a damage sponge layer between the armor and the core more or less. And instead separate systems for optimal protection and based on their vulnerability.
So for example, if whenever the power system is hit you'd get some kind of debuff, you wouldn't put your power systems right under the most exposed part of your ship. Given that if a shot comes through, and hit it you'd be penalized. Since its a critical system to your ship, you'd probably put that it in the hardest to hit spot. You'd probably opt to expose less vulnerable systems instead. And you wouldn't put single blocks variants of that system in exposed positions either considering you'd run the same risk. Additionally the tier and the size of a system could determine the severity of the debuff.
But then, if there are other systems that are also just as vulnerable on your ship, you might have to make a hard choice, and have to expose a little more at least one of your weaknesses.
Those compromises and the way they're made would open up opportunities for pilots and opponents alike.
More weaknesses, along with the “Effectiveness Coefficient”, would help keeping in check the tendency of wanting to fill up every nook and cranny with modules. And it could be backed up with the Multi-Blocks systems having the potential for freeing up more space on large ships, and leaving more room for strategic placement of each systems.
In the real world, you do not obliterate an entire ship to destroy it, or any other vehicles. You hit its critical systems/parts, trigger an explosion inside by hitting its ammunition stores or fuel tanks, or you disable the crew. Those are the fastest most reliable ways of disabling/putting out of commission an opposing vehicle. And they're especially relevant to consider in starmade, considering voxels works a little like real-life objects, that can be broken in parts.
Right now, in StarMade, the quickest way to put out of business another ship is to destroy its core. That can make it unfair/lame however, as its a single block amidst potentially thousands upon thousands of others. Most other games avoid all this by turning the whole ship into a single entity with a set HP rating, which addresses completely the issue of needing weaknesses. But that's not really such a great solution, especially for a voxel based game, where a good chunk of the point of using voxels would be thrown out the window.. ( pun intended :p )
A way to address this is to make systems more vulnerable to weapons. This solution is tightly linked with the Multi-blocks system's tendency of inciting more vulnerable designs on large scale vessels, and also from the dependency on fuel and ammunition for some weapons, as brought up later in section 2 and 3 below.
But its also possible to have systems explode, or burn, or malfunction temporarily after being hit. Some systems could also be vulnerable to being disrupted at least temporarily after being hit by certain weapons. Such as EMP weapons for instance.
Having more weaknesses would encourage players to get a little more creative and avoid pretty much using module blocks as a damage sponge layer between the armor and the core more or less. And instead separate systems for optimal protection and based on their vulnerability.
So for example, if whenever the power system is hit you'd get some kind of debuff, you wouldn't put your power systems right under the most exposed part of your ship. Given that if a shot comes through, and hit it you'd be penalized. Since its a critical system to your ship, you'd probably put that it in the hardest to hit spot. You'd probably opt to expose less vulnerable systems instead. And you wouldn't put single blocks variants of that system in exposed positions either considering you'd run the same risk. Additionally the tier and the size of a system could determine the severity of the debuff.
But then, if there are other systems that are also just as vulnerable on your ship, you might have to make a hard choice, and have to expose a little more at least one of your weaknesses.
Those compromises and the way they're made would open up opportunities for pilots and opponents alike.
More weaknesses, along with the “Effectiveness Coefficient”, would help keeping in check the tendency of wanting to fill up every nook and cranny with modules. And it could be backed up with the Multi-Blocks systems having the potential for freeing up more space on large ships, and leaving more room for strategic placement of each systems.
2. Ship combat
2.1. Counter-Measures
2.2. Weapon Balance:
3. Scarcity, Cargo, and EconomySomething that could possibly work well at keeping in check the missiles problems, would be more specialized and varied missiles counter-measures. For example, active and passive counter-measures.
Chaff/Radar Jammer for radar based missiles, aka homing missiles, would allow to counter the tendency of players to counter point defense and players shooting down missiles by firing an enormous quantity of them at the same time.
The Jammer is already in the game, even though its a little glitchy. But the thing is, if the people who corrected me in the past are right, the radar jammer is too effective, and its counter, the scanner, is likewise too effective.
This in turns means that the radar jammer, no matter how effective it is, is essentially not very useful because its easy to to counter it by having several ships with scanners. Not to mention that using your own scanner disables your own jammer... If the jammer was a bit less effective, and if there was an active countermeasure to pair it with, or use as alternative, this would mean people would have a little less reasons to put a jammer counter on their ships. And thus the jammer would gain some strategic value, as its not as likely to be used on a ship.
The radar jammer's counter shouldn't be a radar however. Especially considering the scanner might actually be required on a spaceship at one point for other reasons. Maybe having to install a backup optical tracker instead of a radar one ? Like a camera block ? The missiles could switch to laser guided mode for the next shot. And that tracker could be countered with the cloaking system. (The cloaker would possibly need some kind of “overheat” meter though. And juggling with both of those using the current hotbar interface wouldn't be easy at all..)
Chaff would be an active counter-measure, and the most efficient missile counter compared to the radar jammer. However, it would require that the operator trigger chaff grenades when missiles are nearby, in order to fool them into losing the target. The cooldown would increase the bigger the ship is, considering the bigger the target the harder it gets to hide, even temporarily. Which would mean, large ships would be much more susceptible to missiles in large quantities, and in turn more reliant on their escort fleet's own counter-measures and coverage.
Flares / Cloaking would work for IR guided missiles, aka heatseeking missiles. It works in a similar way to the radar jammer and chaff grenades, only with the flares replacing the chaff grenades as active counter measure, and the cloaker as the “passive” one. And cooldown on the flares would work in a similar way to the chaff.
If heat-seeking missiles are going to be just a niche for swarm missiles, it might be better to just combine both radar guided and heat-seekers countermeasures together.
It would also be possible to recycle the damage pulse weapon into a kind of effective missile counter-measure system with some tweaking. It would give the weapon a use. For example capital ship escorts could mount those, or the capital themselves, with the above limitations for counter measures on larger ships included. It would need to act over a short period of time, instead of being nearly instantaneous, to account for lag and collision issues.
Chaff/Radar Jammer for radar based missiles, aka homing missiles, would allow to counter the tendency of players to counter point defense and players shooting down missiles by firing an enormous quantity of them at the same time.
The Jammer is already in the game, even though its a little glitchy. But the thing is, if the people who corrected me in the past are right, the radar jammer is too effective, and its counter, the scanner, is likewise too effective.
This in turns means that the radar jammer, no matter how effective it is, is essentially not very useful because its easy to to counter it by having several ships with scanners. Not to mention that using your own scanner disables your own jammer... If the jammer was a bit less effective, and if there was an active countermeasure to pair it with, or use as alternative, this would mean people would have a little less reasons to put a jammer counter on their ships. And thus the jammer would gain some strategic value, as its not as likely to be used on a ship.
The radar jammer's counter shouldn't be a radar however. Especially considering the scanner might actually be required on a spaceship at one point for other reasons. Maybe having to install a backup optical tracker instead of a radar one ? Like a camera block ? The missiles could switch to laser guided mode for the next shot. And that tracker could be countered with the cloaking system. (The cloaker would possibly need some kind of “overheat” meter though. And juggling with both of those using the current hotbar interface wouldn't be easy at all..)
Chaff would be an active counter-measure, and the most efficient missile counter compared to the radar jammer. However, it would require that the operator trigger chaff grenades when missiles are nearby, in order to fool them into losing the target. The cooldown would increase the bigger the ship is, considering the bigger the target the harder it gets to hide, even temporarily. Which would mean, large ships would be much more susceptible to missiles in large quantities, and in turn more reliant on their escort fleet's own counter-measures and coverage.
Flares / Cloaking would work for IR guided missiles, aka heatseeking missiles. It works in a similar way to the radar jammer and chaff grenades, only with the flares replacing the chaff grenades as active counter measure, and the cloaker as the “passive” one. And cooldown on the flares would work in a similar way to the chaff.
If heat-seeking missiles are going to be just a niche for swarm missiles, it might be better to just combine both radar guided and heat-seekers countermeasures together.
It would also be possible to recycle the damage pulse weapon into a kind of effective missile counter-measure system with some tweaking. It would give the weapon a use. For example capital ship escorts could mount those, or the capital themselves, with the above limitations for counter measures on larger ships included. It would need to act over a short period of time, instead of being nearly instantaneous, to account for lag and collision issues.
2.2.1. In General
2.2.2. Missiles (Need some re-thinking !)
The current design philosophy of StarMade is to allow people to tweak weapons however they want by slaving systems and such.
But, there are some issues to keep in mind here.
Whatever they do, our weapon systems will always be limited to the few variations they've planned. Only some variables change, but their overall working principles are always the same.
Currently, weapon types are too generic and similar in functionality, with only marginal differences. And those that differ significantly, like the damage pulse, are not really capable of finding a niche because they are not practical enough within the constraints of the game.
Considering this, I believe it would be a good thing to come up with weapons that works in different ways. Some that don't work nearly exactly the same way as all the others.
In order to create a sense of variety, some weapon systems could require to be built differently than others.
Or they could induce damages in a different way.
For example, local temporary area of effect warheads/bombs, ramming “stakes”, streams of burning hot hull melting liquids, etc..
If there was a weapon for which you could design a projectile, you could do even more.
Giving most weapon types a niche, or innate advantage in certain situations, beyond range, projectile trajectory and speed, and accuracy, could also spice things up. For example, beams could have a basic bonus against shields, canons against armor, something like a 25% bonus. Canons could also just have an all-around bonus, like 12% shields, 12% armor. Or maybe even just penetrate armor further by default. It doesn't have to be a huge advantage either. Just something to make some weapon a little bit more suitable in some circumstances.
This isn't anything really new to the game, missiles have an innate explosive and penetrating ability, its just not applied to other weapons. It just so happens that currently that niche is the most useful.
But, there are some issues to keep in mind here.
Whatever they do, our weapon systems will always be limited to the few variations they've planned. Only some variables change, but their overall working principles are always the same.
Currently, weapon types are too generic and similar in functionality, with only marginal differences. And those that differ significantly, like the damage pulse, are not really capable of finding a niche because they are not practical enough within the constraints of the game.
Considering this, I believe it would be a good thing to come up with weapons that works in different ways. Some that don't work nearly exactly the same way as all the others.
In order to create a sense of variety, some weapon systems could require to be built differently than others.
Or they could induce damages in a different way.
For example, local temporary area of effect warheads/bombs, ramming “stakes”, streams of burning hot hull melting liquids, etc..
If there was a weapon for which you could design a projectile, you could do even more.
Giving most weapon types a niche, or innate advantage in certain situations, beyond range, projectile trajectory and speed, and accuracy, could also spice things up. For example, beams could have a basic bonus against shields, canons against armor, something like a 25% bonus. Canons could also just have an all-around bonus, like 12% shields, 12% armor. Or maybe even just penetrate armor further by default. It doesn't have to be a huge advantage either. Just something to make some weapon a little bit more suitable in some circumstances.
This isn't anything really new to the game, missiles have an innate explosive and penetrating ability, its just not applied to other weapons. It just so happens that currently that niche is the most useful.
Missiles could use a few tweaks. Namely, introducing an ammunition cost would greatly help with their balance, without requiring nerfing their offensive power too much.
Requiring ammunition would serve several purposes:
Missiles becomes something you want to save up on, instead of spamming constantly.
Large missile arrays are less desirable, for their higher ammunition costs.
The amount of missiles carried is dependent on available limited cargo space. (see section 3 below)
It rewards players that invests in missile defenses and countermeasures, by ultimately paying off, instead of being a temporary “lucky charm”. (point defense turrets can be eventually bopped, and countermeasures avoided, but an infinite flow of perfect accuracy missiles can't be stopped easily )
The other weapon systems become a more interesting choice.
Specialized missile crafts have a niche, instead of being omnipresent.
I could suggest 2 courses of actions here. Of course there are probably others.
1. Ammo Cost + Systems Scale Up Worse:
2. Ammo Cost + Ammo Determine Power and Speed
Requiring ammunition would serve several purposes:
Missiles becomes something you want to save up on, instead of spamming constantly.
Large missile arrays are less desirable, for their higher ammunition costs.
The amount of missiles carried is dependent on available limited cargo space. (see section 3 below)
It rewards players that invests in missile defenses and countermeasures, by ultimately paying off, instead of being a temporary “lucky charm”. (point defense turrets can be eventually bopped, and countermeasures avoided, but an infinite flow of perfect accuracy missiles can't be stopped easily )
The other weapon systems become a more interesting choice.
Specialized missile crafts have a niche, instead of being omnipresent.
I could suggest 2 courses of actions here. Of course there are probably others.
This one is fairly simple. Missile systems needs generic “missile parts” items to fire. The quantity of items used up is proportional to the size of the missile system. So while a 1 block missile launcher might use up a single item, a 12 blocks long tube could use say 12.
Then, as the missile system get bigger, and the damage output increases the missiles gets slower, turns slower, gets bigger/longer.(could be calculated from the launcher tube group's size) But it would also get a sufficient HP buff to go along. The slow speed of the missile could be mitigated by being fired by fast ships. Their velocity would make the missile go faster until the natural “drag” of the physics engine brings it back down to its top speed slowly.
Then, as the missile system get bigger, and the damage output increases the missiles gets slower, turns slower, gets bigger/longer.(could be calculated from the launcher tube group's size) But it would also get a sufficient HP buff to go along. The slow speed of the missile could be mitigated by being fired by fast ships. Their velocity would make the missile go faster until the natural “drag” of the physics engine brings it back down to its top speed slowly.
For this one, the missile system would also use up ammunition, but the damage output, and the missile speed would be calculated differently, and would depend at least in part on the ammunition used.
Instead of using generic “missile part” items, the systems could use craftable warheads with special attributes. Better warheads would cost more to produce and require a higher tech level, and higher tech level/rarer resources.
“Slaving” weapon systems would still determine how the missile is fired.
This could be pushed further by having optionally the missile systems use up a “missile engine” item as well as the above warhead item when fired. This would change the way the missile flies to its target. Possibly making the missile faster, tougher, or have a particular flight path.Instead of using generic “missile part” items, the systems could use craftable warheads with special attributes. Better warheads would cost more to produce and require a higher tech level, and higher tech level/rarer resources.
“Slaving” weapon systems would still determine how the missile is fired.
3.1. Cargo System (Pictures)
3.2. Resource Dependency
3.3. A Word on Resource Spread
3.4. Resource Exploitation
In order to make the cargo system dependent on an amount of storage blocks, I'd like to suggest the following approach. Its also meant to look decently good, and give immediate visual feedback on how much space is used up for storage.
I originally was going to suggest just making a boring storage modules + storage computer combo. But then, it occurred to me, while reading a StarCitizen update, that it might be nice to have some kind of visual feedback as cargo space gets filled up. Nothing nearly as fancy as they're going for though. And it also encourage people to group things together, which is another plus in that it creates a weakness.
So, why not designate a volume, using blocks to draw a bounding box, that would get filled up proportionally with universal "boxes" blocks, as the cargo bay gets filled up ?
The boxes are easier to handle than individual blocks representing the content. And the cargo boxes' capacity can be fine tuned during development without ever needing to change the model, or the amount of blocks displayed in the volume.
In cases where the system is damaged, items that were inside destroyed cargo box blocks would be expelled, and others unharmed boxes would stay there, with their content safe.
Some boxes could be orphaned if the system is damaged enough, but their content wouldn't be lost, and it would still be possible to re-assign them into the repaired system by merging them back with the system's volume.
What I meant about the system getting damaged, and the orphaned blocks getting re-assinged:
- = cargo volume delimiter block
B = cargo box block
O = orphaned cargo box block
Original (The volume is full with cargo boxes):
-------
-BBBBB-
-------
Broken ( Two cargo boxes are destroyed, and some of the cargo modules forming the system's bounding box were destroyed. Leaving the system in a disabled state, and a block orphaned ):
- ---
-O BB-
- ---
Fixed (the lone orphan block is re-assigned, and the boxes are re-organized within the volume[a little like defragmenting a hard drive]):
-------
- BBB-
-------
It would also be possible to just break the boxes which would just drop their content, like a "piggy bank".
Using a salvage beam on a box would just put its content into the salvaging entity's inventory. The box block itself would not drop a block item upon salvage, to avoid anyone exploiting those box spawning at will.
The interface to this system would work nearly similarly to an improved shop interface, and allow transfer between docked entities or other cargo systems easily with a few clicks, without having to consider item stack issues. And it would be easy to just drop items into the cargo system from the player inventory, and take them back too. ( The shop interface could be massively improved by simply adding a quantity box next to each items, so you can get more than a single thing at once if you wish. And of course adding a drop area on the menu to drag and drop item(s) into the system. )
It also means, that the AI would probably be better able to carry freight between ships/stations/etc, given the system would be very straightforward and centralized.
Moreover, to provide access to the storage systems across a stations or ships, access nodes blocks could be made. And various logic blocks along with a jettison port block could also be thrown in to allow greater control on the system.
Mass and size of each items wouldn't be taken into account, simply because the player's grid inventory doesn't, and so it wouldn't make much sense..
Though, it could certainly be changed very easily in the future if needed, thanks to the way the system works, given everything is handled "behind the scene", with no need to consider a fitting stacks in a grid.
Additionally, this means that, any new resources that can't be represented in a grid inventory could be easily be stored in this system. Fuel, ammunition, captive fauna, etc.. Separate systems meant for each of those could also be made, based around the same framework.
For example, a separate cargo system for storing fuel could be implemented. Its “piggy bank” blocks could be made to have a chance to explode when shot at. This would make it easier to create a potential weakness out of fuel storage containers on a ship, given its guaranteed to contain fuel, and not have to deal with checking the content of the container that was hit.
With a system like this it would also be possible to make dockable item/fuel/ammunition containers. And those would be taken in charge readily by the system. This would open up a lot of possibilities for trade ships and the like. Not having to dock to transfer goods from ship to ship, and using small crafts to move containers around.
I originally was going to suggest just making a boring storage modules + storage computer combo. But then, it occurred to me, while reading a StarCitizen update, that it might be nice to have some kind of visual feedback as cargo space gets filled up. Nothing nearly as fancy as they're going for though. And it also encourage people to group things together, which is another plus in that it creates a weakness.
So, why not designate a volume, using blocks to draw a bounding box, that would get filled up proportionally with universal "boxes" blocks, as the cargo bay gets filled up ?
The boxes are easier to handle than individual blocks representing the content. And the cargo boxes' capacity can be fine tuned during development without ever needing to change the model, or the amount of blocks displayed in the volume.
In cases where the system is damaged, items that were inside destroyed cargo box blocks would be expelled, and others unharmed boxes would stay there, with their content safe.
Some boxes could be orphaned if the system is damaged enough, but their content wouldn't be lost, and it would still be possible to re-assign them into the repaired system by merging them back with the system's volume.
What I meant about the system getting damaged, and the orphaned blocks getting re-assinged:
- = cargo volume delimiter block
B = cargo box block
O = orphaned cargo box block
Original (The volume is full with cargo boxes):
-------
-BBBBB-
-------
Broken ( Two cargo boxes are destroyed, and some of the cargo modules forming the system's bounding box were destroyed. Leaving the system in a disabled state, and a block orphaned ):
- ---
-O BB-
- ---
Fixed (the lone orphan block is re-assigned, and the boxes are re-organized within the volume[a little like defragmenting a hard drive]):
-------
- BBB-
-------
It would also be possible to just break the boxes which would just drop their content, like a "piggy bank".
Using a salvage beam on a box would just put its content into the salvaging entity's inventory. The box block itself would not drop a block item upon salvage, to avoid anyone exploiting those box spawning at will.
The interface to this system would work nearly similarly to an improved shop interface, and allow transfer between docked entities or other cargo systems easily with a few clicks, without having to consider item stack issues. And it would be easy to just drop items into the cargo system from the player inventory, and take them back too. ( The shop interface could be massively improved by simply adding a quantity box next to each items, so you can get more than a single thing at once if you wish. And of course adding a drop area on the menu to drag and drop item(s) into the system. )
It also means, that the AI would probably be better able to carry freight between ships/stations/etc, given the system would be very straightforward and centralized.
Moreover, to provide access to the storage systems across a stations or ships, access nodes blocks could be made. And various logic blocks along with a jettison port block could also be thrown in to allow greater control on the system.
Mass and size of each items wouldn't be taken into account, simply because the player's grid inventory doesn't, and so it wouldn't make much sense..
Though, it could certainly be changed very easily in the future if needed, thanks to the way the system works, given everything is handled "behind the scene", with no need to consider a fitting stacks in a grid.
Additionally, this means that, any new resources that can't be represented in a grid inventory could be easily be stored in this system. Fuel, ammunition, captive fauna, etc.. Separate systems meant for each of those could also be made, based around the same framework.
For example, a separate cargo system for storing fuel could be implemented. Its “piggy bank” blocks could be made to have a chance to explode when shot at. This would make it easier to create a potential weakness out of fuel storage containers on a ship, given its guaranteed to contain fuel, and not have to deal with checking the content of the container that was hit.
With a system like this it would also be possible to make dockable item/fuel/ammunition containers. And those would be taken in charge readily by the system. This would open up a lot of possibilities for trade ships and the like. Not having to dock to transfer goods from ship to ship, and using small crafts to move containers around.
As you all probably know, having players depend upon a steady flow of certain resources, renewable or non-renewable, would help with several aspect of the game:
Adding resource dependency is a big part of the survival aspect. So I'm assuming that there is indeed a lot of these things planned. However, I'm writing this merely in order to put emphasis on how it could help with balance right now, and actually making the game a bit more playable/complete, on the way to release.
- Requiring a “fuel” source to cover great distances would put a cost on traveling in space. Which in turn would mean that locations where fuel is processed and mined would gain significant value. Trade of fuel would be profitable. Expeditions to distant places could be more costly. Jumpgates would become even more meaningful than they already are. Fleets would require resupply after a while, it wouldn't be as easy to camp the same spot, and cutting their fuel supply would be a mean of repelling an enemy siege. It would also mean, possibly having to bring/protect supply ships along with a fleet, or use them to resupply a forward base.
- Requiring ammunition for certain weapons, such as missiles, means that sustaining a constant barrage of those would have an actual cost in terms of logistic. There would be a need for ammunition factories, and a market for ammunition. It would also help balance missiles, and make them a little less common.
Adding resource dependency is a big part of the survival aspect. So I'm assuming that there is indeed a lot of these things planned. However, I'm writing this merely in order to put emphasis on how it could help with balance right now, and actually making the game a bit more playable/complete, on the way to release.
Spreading around resources is a good thing. And you know why ?
Progress. That's why.
Silly one word magic answers aside, when the first explorers came to america, for example, they were looking for a shorter way with less obstacles to get to the east and trade spices and etc.. This was so important economically that more effort and resources were put by competing nations into developing better tools for exploring.
For example, the Caravelle was developed to make that trip easier. But then other things were developed as well. All those somehow branched off from transportation and exploration.
Essentially, when you need to figure out how to go from point A to B, in order to get something precious, to make it worth your troubles, you're more likely to figure something out. Spreading resources and putting the rarest in hard to get places will motivate people to overcome the obstacles however they can.
And in a game with emergent gameplay like starmade, that's ideal.
This is also why a resource tiering system is urgently needed, along with some harsher terrains and locations. With tools to overcome them of course.
Progress. That's why.
Silly one word magic answers aside, when the first explorers came to america, for example, they were looking for a shorter way with less obstacles to get to the east and trade spices and etc.. This was so important economically that more effort and resources were put by competing nations into developing better tools for exploring.
For example, the Caravelle was developed to make that trip easier. But then other things were developed as well. All those somehow branched off from transportation and exploration.
Essentially, when you need to figure out how to go from point A to B, in order to get something precious, to make it worth your troubles, you're more likely to figure something out. Spreading resources and putting the rarest in hard to get places will motivate people to overcome the obstacles however they can.
And in a game with emergent gameplay like starmade, that's ideal.
This is also why a resource tiering system is urgently needed, along with some harsher terrains and locations. With tools to overcome them of course.
As of now, the only way to gather resources is through using salvage beams, and building “planet eaters”. Planet eaters have proven to be an issue performance wise, so maybe making them a bit less important could help, while not ruining anyone's fun ?
I'd suggest basically allowing people to build mining platforms on planets. Which would return a constant income of resources that wouldn't be minable by using a salvage beam. (The main downside though would be that some kind of “away” system would need to be worked out. Like a chunk loader in minecraft. But since the core of a planet isn't made with voxels, it migth be easier to just “register” mining platforms into the planet core object, and have them accumulate resources while the planet is unloaded. And once a player is in range the accumulated resources for each platform is sent through the storage triggering logic blocks and etc if possible. )
The minable resources and the amount available in one planet, would vary depending on the planet. Since these details would be most likely stored in the planet's core, this would mean people wouldn't be able to just mind their own business on their own plate. And thus they'd need to interact if they live on the same planet.
Different mining platforms would be able to mine only certain resources, and adding more platforms would mean faster mining. (Those could make use of the multi-blocks systems mentioned above too! )
Possibly that, this kind of mining could eventually destroy the planet's core, if all the mineral is gone, without exploding it, but still releasing the plates.
This would mean direct visual feedback on whether a planet is emptied out or not. It would also mean its probably not to wise to mine your homeworld to the last rock, unless you really need to.
I'd suggest basically allowing people to build mining platforms on planets. Which would return a constant income of resources that wouldn't be minable by using a salvage beam. (The main downside though would be that some kind of “away” system would need to be worked out. Like a chunk loader in minecraft. But since the core of a planet isn't made with voxels, it migth be easier to just “register” mining platforms into the planet core object, and have them accumulate resources while the planet is unloaded. And once a player is in range the accumulated resources for each platform is sent through the storage triggering logic blocks and etc if possible. )
The minable resources and the amount available in one planet, would vary depending on the planet. Since these details would be most likely stored in the planet's core, this would mean people wouldn't be able to just mind their own business on their own plate. And thus they'd need to interact if they live on the same planet.
Different mining platforms would be able to mine only certain resources, and adding more platforms would mean faster mining. (Those could make use of the multi-blocks systems mentioned above too! )
Possibly that, this kind of mining could eventually destroy the planet's core, if all the mineral is gone, without exploding it, but still releasing the plates.
This would mean direct visual feedback on whether a planet is emptied out or not. It would also mean its probably not to wise to mine your homeworld to the last rock, unless you really need to.
That's pretty much it. I tried to keep it short, but I've re-written this thing at least 4 times now, over a month, and I can't shorten it anymore.. Especially since the game is changing faster than I'm writing this..
But anyways, the point of all this is to bring ideas, and feed discussion. So I'd like to hear some feedback, and possible improvements to these. I suggest specifying what point you're commenting on, to make discussion easier.
Also, congrats if you read it all !
I'm predicting this won't be the case for most.. Which is somewhat understandable at this point ^^;
Last edited: