- Joined
- Jun 20, 2013
- Messages
- 268
- Reaction score
- 70
THIS IS A SERIES OF IDEAS. THE FORMATTING ISN'T BRILLIANT ON THIS FORUM SO I'LL DO MY BEST TO ORGANISE THEM IN A WAY THAT ISN'T CLUTTERED. I'll be adding and improving ideas as I flesh them out.
SHIELD POWER CONSUMPTION
Simple suggestion. Shields, like cloaking and jamming, should constantly consume power.
They shouldn't consume very much power, but they should still require power to run. Because of this, shields should be toggleable in order to save power.
Having this system in place would mean a few things.
-Firstly, massive ships wouldn't be able to support massive amounts of shielding.
-Power storage would become far more useful
-Ships would have to make a choice between shield focus or damage focus, or go for a balance.
-Tactical power management. Ships that have a lot of weapons and shields won't be able to support both simultaneously. Pilots will have to decide when to activate shields and when to fire
There should also be a decrease in AMC damage in order to compensate for the decrease in shield power.
_________________________________________________________________________________
FOCUS FIRE/ ZEROING
I've always hated focus fire and have always been an advocate for its removal. For whatever reason this is unpopular, so I propose a compromise.
In order for a sniper to hit his target he needs to zero his sights. If a target is 800m away he needs to zero his sights to 800m in order to hit it.
In Starmade, 'zeroing' happens automatically in the form of focus firing. I propose that this no longetr be automatic and instead pilots must choose a point to focus fire on. By default weapons would be zeroed at their max range, but a skilled pilot or gunner could change the range of their weapons on the fly in order to get maximum damage on their target.
It promotes skill while at the same time lessening the popularity of checkerboard AMC arrays due to the skill required to use them effectively. New players won't be deterred because, by default, weapons fire as you'd expect them to; forwards.
_________________________________________________________________________________
CLIENT-SIDE* DEBRIS AND OBJECT BREAK-OFF
When blocks are destroyed they should spawn client-side debris instead of just disappearing. Being client-side they won't contribute to server lag, though they should be an option for the player as they might cause a drop in FPS.
Exploring the server options file reveals that the option to have ships break in half and have sections blown off of them is already in the game. I checked it out and it's very laggy and buggy but it's also very cool. I'd like to see this in-game but in a very muted form.
A problem I came across is that a lot of single blocks would break off the main ship resulting in dozens, even hundreds of new objects. I propose that objects of a certain size, when broken off, should destroy themselves leaving client-side debris in their place.
This way only large objects that are broken off would remain in game, thus the break-off mechanic can be implemented (once the other issues with it have been resolved, of course) without massively straining servers.
*client-side objects are objects that are created by the client (the player's computer) rather than by the server. Client-side objects are used extensively in multiplayer games to simulate behaviour that would otherwise be a strain on the server. An example might include breaking a crate that is generated server side, but the broken pieces of the crate (gibs) are generated client-side.
_________________________________________________________________________________
REDUCED ENGINE EFFECTIVENESS
Massive ships going from 0 to 100 in .5 seconds is a problem. I propose that engines have hugely diminishing returns meaning that smaller ships are largely unaffected and can accelerate quite quickly, but larger ships take an extremely long time to reach top speed. The top speed of large ships should be unaffected, however.
_________________________________________________________________________________
I'm sure I'll add other ideas in future. This was originally just going to be one suggestions but I figured I'd avoid having a dozen threads going.
SHIELD POWER CONSUMPTION
Simple suggestion. Shields, like cloaking and jamming, should constantly consume power.
They shouldn't consume very much power, but they should still require power to run. Because of this, shields should be toggleable in order to save power.
Having this system in place would mean a few things.
-Firstly, massive ships wouldn't be able to support massive amounts of shielding.
-Power storage would become far more useful
-Ships would have to make a choice between shield focus or damage focus, or go for a balance.
-Tactical power management. Ships that have a lot of weapons and shields won't be able to support both simultaneously. Pilots will have to decide when to activate shields and when to fire
There should also be a decrease in AMC damage in order to compensate for the decrease in shield power.
_________________________________________________________________________________
FOCUS FIRE/ ZEROING
I've always hated focus fire and have always been an advocate for its removal. For whatever reason this is unpopular, so I propose a compromise.
In order for a sniper to hit his target he needs to zero his sights. If a target is 800m away he needs to zero his sights to 800m in order to hit it.
In Starmade, 'zeroing' happens automatically in the form of focus firing. I propose that this no longetr be automatic and instead pilots must choose a point to focus fire on. By default weapons would be zeroed at their max range, but a skilled pilot or gunner could change the range of their weapons on the fly in order to get maximum damage on their target.
It promotes skill while at the same time lessening the popularity of checkerboard AMC arrays due to the skill required to use them effectively. New players won't be deterred because, by default, weapons fire as you'd expect them to; forwards.
_________________________________________________________________________________
CLIENT-SIDE* DEBRIS AND OBJECT BREAK-OFF
When blocks are destroyed they should spawn client-side debris instead of just disappearing. Being client-side they won't contribute to server lag, though they should be an option for the player as they might cause a drop in FPS.
Exploring the server options file reveals that the option to have ships break in half and have sections blown off of them is already in the game. I checked it out and it's very laggy and buggy but it's also very cool. I'd like to see this in-game but in a very muted form.
A problem I came across is that a lot of single blocks would break off the main ship resulting in dozens, even hundreds of new objects. I propose that objects of a certain size, when broken off, should destroy themselves leaving client-side debris in their place.
This way only large objects that are broken off would remain in game, thus the break-off mechanic can be implemented (once the other issues with it have been resolved, of course) without massively straining servers.
*client-side objects are objects that are created by the client (the player's computer) rather than by the server. Client-side objects are used extensively in multiplayer games to simulate behaviour that would otherwise be a strain on the server. An example might include breaking a crate that is generated server side, but the broken pieces of the crate (gibs) are generated client-side.
_________________________________________________________________________________
REDUCED ENGINE EFFECTIVENESS
Massive ships going from 0 to 100 in .5 seconds is a problem. I propose that engines have hugely diminishing returns meaning that smaller ships are largely unaffected and can accelerate quite quickly, but larger ships take an extremely long time to reach top speed. The top speed of large ships should be unaffected, however.
_________________________________________________________________________________
I'm sure I'll add other ideas in future. This was originally just going to be one suggestions but I figured I'd avoid having a dozen threads going.
