The shield change is not a nerf

[schema]

Hello players,

as there was some confusion with the latest change in the shield system, here is an explanation:

The shield thing is NOT a nerf. it's a buff from complete deactivation when hit, to just a little nerf on recharge.

Basically before: when hit, shields will not recharge at all for the "recovery time" indicated in the buildmode stats

Now: When hit, shields will recharge, but with a lower rate, which gets higher the more empty the shield gets.

When the recovery time is over the recharge will jump to 100% like before.

Thanks for playing StarMade,

- schema

 

[Commodore]

So from 100%-40% shielding, they recharge under fire at the lower rate, then from 40%-0% they recharge faster? is it a sloped relation (like max recharge at 1%, then linear to 40% then constant to 100%?

 

[schema]

its basically a percentual relation. So if you have 100% shields the first hit will give you 0% recharge, if you have 99% you have 0.4% recharge, and so forth.... at 50% shields you have 20% recharge, and at 0% you have 40% recharge.

The recharge is now also indicated in the shield bar, so it\'s easy to keep track

 

[Commodore]

Awesome, it will be interesting to see how this effects battles.

 

[Moph]

Is there any moment when there\'s no recharge at 0%?

Since the shield level doesn\'t contribute to anything other than preventing hull damage until it\'s spent, there\'s no real need for them to have a complex algorithm for recharging, they might as well be linear and save on processing?
At the end of the day, the shields are still going to have X amount of time before they get exhausted under constant fire regardless of which method is used to recharge them.
I suppose the only difference here is that it\'s more critical to keep your target in your crosshairs the longer you\'ve been shooting it. But then the attacker isn\'t going to know how much shielding they\'ve taken off their target anyway, so they wouldn\'t know if they should focus on getting a stronger aim. I.e. since you don\'t know how much shielding your victim has, you could either be 80% of the way in, or just have scratched the surface at 5%.
Maybe if there was a visual representation to the attacker of the level of the shields it would make more sense for this change to happen. Like a gradual change between blue and red rather than the sudden change when they\'re almost completely out of shields.

To me this sounds like the way the shields used to work before (which I like the sound of), but with a processing heavy algorithm?

It does sound like a cool addition to how the shields work, from the pilot\'s point of view, but I can\'t see how it will affect the gameplay to be worth the extra processing cost?

 

[4plains]

This doesn\'t really create more processing cost compared to thousands of AMC projectiles/sec out of scattercannon designs.

 

[Moph]

Sure, but that has nothing to do with the price of cheese in my country, so what\'s your point?

Let\'s try to keep the discussion linked to the actual content perhaps?

Try comparing shielding methods with other shielding methods. Because you can either have one or the other, and the comparison between the two makes a difference.

Shields are what is in question here, not AMCs. The point is that you should try to find the best method of implementing something while you are doing it, not think that because something else is worse, this doesn\'t matter, so just throw it in anyway. AMCs can be considered at another point in time.

 

[Nebulon-B_Frigate_FTW]

If I\'m understanding Schema\'s idea right, it\'s this: f(x)=-(2*x/5)+40 where f is the shield recharge percent while in combat and x is the percent of shields remaining. If you want your shield percent remaining for a given time in a battle...well then I\'ll have to break out the differentials (bottom of this post).

So it should be rather simple for the game to process and it will be interesting to see how it affects balance. I suspect it may actually make shields on larger ships too powerful again.



DiffEq time! Hopefully I don\'t make numerous mistakes here.
Let\'s not deal with percents and instead let our max shield strength be some constant S. Let s(t) be our shield strength at a given time t in seconds and let d(t) be the damage done by the enemy, which we assume is a linear increasing function starting at the origin (they\'re firing constantly with no change in how much damage they do per time. In other words, dd/dt=D where D is a constant and is the damage per second (DPS)). Therefore, while in combat ds/dt = (-t*100*2*S/5 + 40)*S/100 - D and d(t) = S - s(t). If we integrate to find s(t), we get s(t) = (-200*S*(t^2)/10 + 40*t)*S/100 - D*t + C where C is a constant. We can find C by s(0) = S, since we are assuming to have started at t=0 with full shields. s(0) = S = (-200*S*(0^2)/10 + 40*0)*S/100 - D*0 + C, which implies S = C.

Pretty sure I made a mistake somewhere, but I\'ll figure it out later.

 

[Nebulon-B_Frigate_FTW]

Many mistakes. d(t) =\\= S-s(t). s(t) = S + ds/dt - D*t. ds/dt = (-200*s(t)/5 + 40)*S/100 - D. Stupidly had a t in ds/dt instead of s(t).

 

[Visitor]

Still, is the AMC relation to the shields and hull as it should be or will the cannons be further balanced?

So far AMC are still far overpowered and - as per the best suggestion I saw so far - adding additional power demand per block (as in, second block in AMC would take 105% of power of single block, third 115% etc) as well as per amount of cannons linked together would help a bit in curling ease of making AMC arrays.

 

[Masochist4Melons]

I really like that idea.



Also \\o/ Shield buff! Thanks. Hopefully cap verse cap battles will be a little longer now.

 

[Moph]

Oh god, why are you pulling out differentiation and integration? It\'s only a percentage problem.
You\'re making this ten times more complex than what you\'re trying to defend.

At any tick through the game loop, with a linear calculation of shield regeneration, it will be as simple as:

CurrentShieldValue = CurrentShieldValue + ShieldRechargeIncrement;

ShieldRechargeIncrement will not change unless shield blocks are destroyed, or if there isn\'t enough power, so it doesn\'t always need to be recalculated with each iteration.
Addition is the simplest, easiest and fastest possible operator to process (compared with other mathematical operators).

With the percentage method it would be something more like:

CurrentShieldValue = CurrentShieldValue + ( ShieldRechargeIncrement x ( 0.4 - ((CurrentShieldValue / MaximumShieldValue) x 0.4 )

The increment to be added on each tick would have to be calculated with each iteration, because the value would be constantly changing.
You will notice how many extra operations a computer will have to process with that with each cycle. Also, division is incredibly slow next to simple addition, subtraction or even multiplication.

It probably won\'t make any difference, but once you start to consider multiple entities each with shields, turrets, stations, ships, and then on multiplayer, multiplying that higher, it can build up to the point where it does start to make a noticable difference. So small changes to small bits of code which seem insignificant now, can easily grow out of hand.
Afterall, we\'re only talking about the shields here, which is one small part of the game. It\'s best to get your head used to thinking like that because there are loads more systems which will be a lot more complex.

A lot of multiplayer games out there use simplified ways to calculate things precisely because of the number of times a server will need to calculate a particular algorithm.

For example, a very well known RPG style game uses a much simplified method of calculating combat damage.
Your character has a 50% hit chance, and a 50% crit chance.
You\'d naturally think that the game first takes your 50% to hit chance, calculates that like this:
/random 100, if 0-50, then hit, if 51-100, miss.
Then if you hit, it runs through another algorithm to determine if you crit.
/random 100, if 0-50, then crit, if 51-100, normal hit.

What actually happens is that they boil this down to a single algorithm, or random roll, which takes it all into account, such as:
/random 100, if 0-25, crit, if 26-50, normal hit, if 51-100, miss.

On those servers, while there are many attacks going on, they\'re not even as frequent as having to calculate it per game frame cycle, as you would need to with the shields.

 

[Human Zombie]

star-made.org/content/my-take-new-amc-system

 

[Human Zombie]

star-made.org/content/my-take-new-amc-system

 

[Nebulon-B_Frigate_FTW]

ds/dt = (-200*s(t)/5S+40)*S/100 - D.

s(t) we do not know until we solve via ds/dt. Massive derp on my part.

It ends up being s(t) = -(5/2)*e^((-2/5)*(t-(5/2)*(i*pi+ln(D))) - (5*D)/2 + S.

Real fun equation...but it actually isn\'t too bad when you graph it.

 

[Nebulon-B_Frigate_FTW]

All the game has to do each tick is calculate a linear equation. That\'s it. The differentials are about finding how total shields left change over time (so we can see how long it takes to take down shields or if you can even take them down for a given DPS).

 

[Nebulon-B_Frigate_FTW]

The parens up there are wrong. Bad things happen when notation is replaced by parens.

Also, choosing a better form for calculating C, I got rid of the natural log and the i and the pi and the ridiculousness: s(t) = (5*D/2)*e^(-2*t/5) + S - 5*D/2. This is a much more reasonable form. Here are some graphs I made using GNU octave showing 10K shields at 50, 500, and 5000 DPS for 100 seconds of combat (note only the last one goes below 0):

 

[Nebulon-B_Frigate_FTW]

It takes almost exactly 14 seconds for the shields to drop from being hit by the minimum DPS needed to take them down (min DPS = 40% of max shields).

 

[Nebulon-B_Frigate_FTW]

...and it takes less than 4 seconds for shields to drop from being hit by a DPS of 50% of shield strength.

 

[Draren Thiralas]

Sounds great, but how about the AMC\'s? As far as i looked into it, that change you made screwed the balance even more. Here\'s some math:

As far as i know, weapon dps is counted with this formula: 1000 / reload speed * damage.

I used it to find that this connected weapon group(X=AMC block):

XXXX

deals 132 dps, but this group(S=Shield, X=amc):

XSXS

deals 167 dps while taking up the same space and also providing shields to the vessel. With such a titanic diffirence even in small weapon groups, there is little to no use in connecting weapons, while your new secondary fire mode will increase the accuracy of those scattercannons. Thus, you should either do a drawback to previous, not-so-unbalanced weapon system, or actually use that suggestion thread everyone is telling you about. But under no circumstances should you release the update with the current system.