Shield(and other) support beams explanation

GSB2 GSB2 Gratuitous Discussion
1

So at last I’m getting around to introducing the new modules into the game, and some of the first ones include re-implementing the old shield support beam. This was already in GSB1, with only the empire 9as I recall) having it. It’s back in GSB2, although I’m not sure if every race will have it yet.

The shield support beam basically is a remote projection module which connects two ships and lets one ‘project’ shield energy onto the other. the beam module both generates and projects the shield strength. The idea is that it is a ‘support’ module which lets a small ship help protect a big one.
Although shields in GSB2 are no longer depicted as bubbles, I use that bubble imagery to indicate when support beams are in use. Different colors represent different capabilities…

image
supp.jpg800×500 77.1 KB

In that screenshot, 2 destroyers are following (in formation) a dreadnought and using remote propulsion (blue beam) and tracking support beams (green) to support the dreadnought in front. Effectively, they are tugs, allowing the dreadnought to be highly armored and shielded, without wasting power or slots on too many engines. Once the ship is pushed into the heart of the battle, the destroyers an effectively be sacrificed.

Right now the system supports:

  • Propulsion beams (for tugs)
  • Recon beams (boost tracking speed of target)
  • Shield Support Beams (boost damaged shields)

I’d like to know what people think of the mechanic. I think I may have to cap the number of identical type beams connecting to each ship to prevent people chaining 100 destroyers and using them as a railgun to fire dreadnoughts :D.
I think the effectiveness of the beams needs to be very high, as they come with the penalty of needing to co-ordinate two ship positions, and the vulnerability that exposes. It needs to be worth doing this, rather than just plonking the equiv generators on the target ship.

Also, there is a system where the beams don’t work on fighters, and ships look for the nearest cruiser or dreadnought to support, and if they find none, then consider other destroyers and frigates. These beams will be destroyer-only modules, as that is the support-role class.

I’m not 100% happy with the visual effect, as it evokes ‘shields’ too much, even for propulsion, but every other effect I tried looked worse. I am open to tweaking ideas. I may have to tone down their brightness, maybe work on some kind of scrolling effect to show direction of flow.

Thoughts?

2

You could probably get away with making the propulsion support beams be expensive components that don’t stack on the same ship (i.e. two propulsion support beams on a single destroyer doesn’t do anything more for you than one does), combined with making the net speed of the resulting set of vessels equal to the speed of the hypothetical equivalent vessel with the same total mass and thrust as all the ships in the set combined. I don’t know that that’s easier than just capping the speed boost a ship can receive, though.

I think it’d be rather interesting if there were a sort of multibeam shield support beam intended to support fighters, perhaps as a faction-specific module for a faction that otherwise has relatively poor fighters. Doesn’t give much shielding, probably not worth it for boosting a heavy warship, but does just fine for granting a fighter squadron 5 or 10 shields per fighter.

The propulsion support beam, particularly if it’s implemented as something where the combined thrusts and masses of the ships come into play, sounds a lot like an application of the tractor beam, so I wouldn’t be too surprised if most or all factions had access to it.

The shield support beam I’d tend to think would be for the higher-tech faction(s), as I would think that the shield extension required would be relatively difficult to do. Does it work only on ships that already have (active) shields, or can it provide shielding to a ship that doesn’t have any (operational) generators?

3

its a good point that it is basically a reverse tractor beam :smiley:
Right now you need a shield to be supported, it would be a bit awkward to change that. I may experiment with different widths and textures for the beams to distinguish them a bit more. Right now I’m working on fighter refueling in carrier bays :smiley:

4

Speaking for myself, I’d like to know what shields do look like, if the standard “bubble” effect is gone. It would also help to visualize what the support beam effect would look like if it followed suit. (Something about a shield support beam in particular not looking similar to other beams hitting the shields just doesn’t sit right with me.)

Agreed, the effects as shown are a bit overwhelming. The level of brightness and detail required will depend to a certain degree on the final visual effect.

Is it possible that the beams could have a stacking penalty, not unlike the penalty for stacking the modules they imitate? That way, I have three obvious options (using the “speed-boosting a dreadnought” example):

  • Put engines on the dread itself to give it a constant moderate speed
  • Put little to no engines on the dread and use 2-3 support beams to give it the same moderate speed until the destroyers go, at which point it becomes a turtle
  • Put engines on the dread and use 2-3 support beams to give it a much higher speed until the destroyers are lost or the dread outdistances them, at which point it drops to moderate speed

If the beams had some sort of stack penalty, there would also have to be default AI or specific orders to limit the number of support ships that try to help the same target (as past a certain point, they will actually bring the total level of assistance down).

5

I will have to investigate how easy technically it is to apply stacking penalties in this case, as they would work differently, as they now would need computing on a minute-by minute basis,m depending which beams were attached. it gets messy…

something related to the whole ‘support beams’ mechanic I should mention here is formations work differently now. Formations are a group of linekd ships, where each is offset from the others, an a formation ‘anchor’ is ‘elected’, much like a squadron leader. By default, the formation leader for non fighters is the ship with the most hitpoints. This makes it MUCH easier to set up formations like the one shown in the image above, especially with a cluster of maybe 3 dreadnoughts and twnety supprot destroyers around them.

6

One way that you could do a stacking penalty is by messing with the formula for the speed bonus. For example, perhaps ship speed is (thrust)*(multiplier)/(mass), where (multiplier) is defined as:

   multiplier = 0.5 + (1 + num_speedboosters)/(2 + num_speedboosters)

Each additional speed bonus has less effect than the one before, and the multiplier on the ship speed converges to 1.5 as the number of boosters goes to infinity. Different beams could then count as different numbers of boosters, which could be hidden behind a ‘booster strength’ variable. Doing it in this way also has the added bonus of making it so that you cannot get that 1-engine 20-armor plate monstrosity up to very high speeds.

Another formula would be for the speed bonus to be (per-booster speed bonus)*(multiplier), where (multiplier) defined as:

   multiplier = (num_speedboosters)*10/(9 + num_speedboosters)

So if the per-booster speed bonus is 0.1, the first speed booster would give you the full 0.1 speed bonus, the second would effectively give you an additional 0.082 speed, the third would give you another ~0.07 speed, and so on. With this specific formula, the multiplier goes to 10 as the number of speed boosters goes to infinity, so the maximum speed bonus in this case would be +1.0 speed. Playing around with the numerator can change the limit; for example, using 5 instead of 10 reduces the maximum speed bonus to 0.5 and reduces the effectiveness of lower numbers of boosters, as with 1 booster you’re only getting half the listed speed bonus. Changing the 9 in the denominator to 4 restores full effectiveness to the first booster added and keeps the maximum speed bonus at 0.5. Once again, you can hide the stacking effectiveness inside a ‘booster strength’ variable.

I personally prefer the suggestion I had of making all the ships linked by speed boosters count as one big ship and handling the speed that way (in which case the ‘stacking penalty’ might be more of an efficiency rating which modifies the effective thrust or mass contributed to the multi-ship), in large part because it means that I cannot place 2 speed boosters on a single destroyer and have that destroyer provide twice the speed bonus to the dreadnought next to it (though if the beams are staggered so that at least one of them is always actively supporting the dreadnought, the effect could be similar) as a similar design with only a single speed booster, but I can see how that would cause bookkeeping issues.

One issue with any of these setups is that it might not be entirely clear to the players how and why the boosters work the way they do. Another issue is that it might not be clear how much of a speed bonus you’ll get with beams of differing boost strengths; for example, under the 10n/(9+n) system, you need a boost strength of 2.25 to double the size of the speed bonus, while under the multiplicative bonus listed first, a strength-1 booster gives a 16.7% speed bonus, but it takes a strength-4 booster to get a 33.3% speed bonus. The multi-ship version is the most ‘realistic’ of the systems, but it might not be intuitive that your speed 1, mass 100 destroyer isn’t as good as your speed 1, mass 200 destroyer for boosting the speed of the multi-ship.

Edit:
I’ve had some further thoughts on how you could implement something that looks like it has a stacking penalty without actually having a stacking penalty on the components.

You could make the speed bonus equal to some fraction of the difference between the current speed of the target and the maximum speed of the boosting vessel, such as 10% of the difference. Thus, each additional booster becomes relatively less effective as the difference in differential speed shrinks. This does have some issues, however, as if implemented directly the resultant speed will oscillate while converging to a specific value instead of instantly going to the steady-state solution. This also has some issues with stability if a large number of speed boosters come online on a single target at once; with the 10% example value and 10 boosters all coming online at once, the solution will become stuck oscillating between the speed of the destroyer and the speed of the boosted vessel, while if more than 10 boosters come online at once, the solution diverges (and in fact will begin producing negative values for total speed).

7

Just quickly, I like the idea of stacking for both Shielding and Propulsion.

Especially when you want to have a a few extra destroyers as reserves when pushing a behemoth into battle. Because nothing would be more frustrating if the enemy executed a well coordinated fighter strike against destroyers effectively crippling your artillery platform.

As for the effects of the propulsion beam. What about the effect from the Order - the structure tractor beam that linked the ships together ? (kinda like a tow beam)

Another idea is to use the conical shaped beam but have multiple lines inside the beam

8

A thought about the Shield Support Beam (SSB) mechanics:
It would seem to me that the easiest way to make the SSB stack without making it something in serious need of nerfing the way the Imperial SSB was early in GSB would be to make the SSB affect shield regeneration for as long as its charge holds out, rather than having its charge be the total number of shield points it can restore and some rate at which it can transfer those shield points. If you made it affect the shield recharge rate rather than making it directly transfer shield points, you could use a formula such as one of the example formulas that I gave for the speed boosters to apply a limit to just how powerful of a boost to shield recovery you can get through SSBs without necessarily making it either ludicrously overpowered when stacked or worthless when not stacked. E.g. a shield support beam would have 200 charge and be able to multiply a target’s shield recovery by

   1 + (1 + totalSupportStrength)/(2 + totalSupportStrength)

for 200 time units, or at some other time specified by a discharge rate, where totalSupportStrength is the sum of the strength ratings of all the SSBs currently boosting the target vessel. The specific multiplier given above ranges from 1.5 to 2.0, though it would probably be better to make the multiplier both larger and cover a wider range of values.

Another alternative would be to keep the shield point pool mechanic, but have the transfer rate modified by something along the lines of the following multiplier:

   0.5 + 5/(9 + totalSSBs)

This method keeps more true to the original Imperial Shield Support Beam, with a total strength that it can provide to the target, but makes the shield strength transfer rate variable; in this case, the transfer rate ranges from 100% of the base transfer rate (one SSB active on the target) to 50% of the base transfer rate (infinitely many SSBs active on the target). Dropping more SSBs on the target reduces transfer efficiency, but provides a greater recharge rate. There are three ways that I see that you could go with this:

  1. The amount of time the beam is active depends on the actual transfer rate; an SSB with 200 shield points will always be able to deliver 200 shield points to its supported target, it’s just a question of how long it takes, and the beam will remain active for as long as the beam has shield points to deliver that the target can accept.
  2. The amount of time the beam is active is constant (but terminates early if the target’s shield becomes fully charged prior to the time limit), and transfer efficiency is reflected in the way that the SSB’s shield point pool is depleted. An SSB with 200 points to give, a transfer rate of 10, and a transfer efficiency of 75% will be active for no more than 20 time units, delivering 7.5 shield points per time unit to the target at the cost of 7.5 shield points per time unit from its storage. This method should probably not be used unless the SSB can only fire when fully charged.
  3. The amount of time the beam is active is constant (but terminates early if the target’s shield becomes fully charged prior to the time limit), and transfer efficiency represents a loss during transmission. An SSB with 200 shield points stored, a transfer rate of 10, and a transfer efficiency of 75% will transfer 7.5 shield points to the target every time unit, at the cost of 10 shield points from its storage.

(Note that the transfer efficiency is dependent on the number of SSBs actively supporting the target, not some inherent statistic of the SSB.)

I personally like option #3 for the second method a bit better than the other two, and I like the second method a bit better than the first method. The second method gives you some more choices to play around with (transfer rate, transfer capacity, beam recharge rate) than the first method does (beam ‘strength,’ beam recharge rate) and doesn’t depend on the target having a decent shield regeneration rate to be useful.

9

One of the strongest concerns I have is making sure any mechanic is clear to the player without them having to do tons of reading or breaking out a spreadsheet. The real concern has to be an overuse of it, where there are 4 or 5 beams all boosting one ship.
Of course, there could be some technobabble explanation for why a shield or other system can only be boosted by one beam at a time, but tbh I think it would be cool to have 2 at the same time.
I think that setting a stacking penalty in exactly the same way the shields and other systems already worked would be quite clear to the player, even though it would be implemented differently under the hood. It’s then just a matter of picking the right stacking penalty, and of course that’s something easy to modify in data as the game is in beta.

I reckon it would make sense to have that only apply to beams of the same type, so you could have multiple beams all at 100% if they were boosting the same thing.

Do people agree that the beams should be MORE effective than an engine on the base ship? to compensate for the awkwardness of arranging the formation, and the intermittent nature of the effect? Thats my gut feeling, although it seems weird that its cheaper to build an engine projector than an engine :smiley:

10

I hadn’t thought about this relationship, but I like it. The risk you take is that if you build a formation where the largest ships rely exclusively or near-exclusively on their support ships for appreciable speed, an enemy fleet that focuses on taking out support ships first can leave your giant gun-festooned dreadnought dead in the water, as it were, making it child’s play to hit it.

11

It’s probably not going to be cheaper than putting an engine on the ship, once you account for the cost of the destroyer carrying the beam, as that destroyer must have its own engines, crew quarters, and power plant, and probably also carries weapons, armor, and shields of its own in a weaker package than would be found on a cruiser or dreadnought. If it’s like GSB, that destroyer costs you about half to a third of a cruiser and doesn’t contribute nearly as much effective firepower and effective health as a cruiser would have. Between that, the relative vulnerability of your ‘engines’, the formation issues, the intermittent nature of the boost, the issue of not necessarily being able to guarantee which ship gets the boosts if and when the formation begins to break up (or if you have multiple independent formations that might cut across one another), and the potential issue of wasting the boost when the formation is speed-limited by some other ship in the group, I’d say that it’s probably not at all unfair to make the boost at least equivalent to adding a high-end engine.

Then I would suggest making the charge on the Shield Support Beams into an upper limit on how long the beam can be active, and have it grant the target a regeneration bonus affected by the stacking penalty. I.e., your shield support beam has 200 charge and so can be active for 200 time units or until the target’s shields are fully regenerated, and it adds (regeneration bonus)*f(x) to the target’s shield regeneration, where f(x) is the stacking penalty function and x is the number of beams active on the target. Only the target needs to track how many and what kinds of beams are hitting it to compute the effective shield regeneration bonus; the ships carrying the beams need only concern themselves with turning the beam on or off at the appropriate times.

I will say, however, that I’m not sure that it’s necessarily intuitive that with a stacking penalty of the form Y^(X - 1) where Y is the penalty and X is the number of beams you will eventually reach a value of X beyond which it is actually harmful to add additional beams. A stacking penalty of the form Y/(X + Y - K) where X is the number of beams and Y is the penalty limit reaches a point where more beams effectively do nothing, but never reaches a point where more beams are worse than fewer beams. Depends on what you want to do, but with for example a 70% stacking penalty 3 beams provide the greatest bonus, 4 beams provide a smaller bonus than 2, and 7 beams provide a smaller bonus than 1 beam does, assuming that all beams are identical. Assuming the beams are all of the same type, the break point for an 80% stacking penalty is 4 beams (5 beams provide the same bonus), the break point for an 85% stacking bonus is 6 beams, the break point for a 90% stacking bonus is 9 beams (10 provide the same bonus), and the break point for a 95% stacking penalty is at 19 beams (20 provides the same bonus); going beyond these points reduces the actual benefit provided with the given stacking penalty. It’s probably not a bad thing (especially with the 90% or 95% stacking bonuses - I doubt it would be intended for there to commonly be a situation where you might have 10+ or 20+ beams all active on the same target, and also since it’s entirely understandable for there to be a point where coordinating all the people pushing the box starts to hampering its movement or where there’s too much interference between the beams and the shields or some such), but it’s probably also not intuitive.

For those who are curious, the break points for the stacking penalty of the form Y^(X - 1) using identical beams can be found by solving

   X = 0.5 +/- 0.5*sqrt(A^2 - 4*A*B)/A

where

A = ln(Y)*Y^(X - 2) B = Y^(X - 1)
Y is the stacking penalty percentage expressed as a decimal (i.e. a 90% stacking penalty gives Y = 0.9), X is the number of components, ln(Y) is the natural log of the stacking penalty, and sqrt(Z) is the square root of Z. This will most likely not give an integer result for X; the break point will be one of the two integers closest to X. Be aware that these break points are for when all of the components are of the same type; the break point can shift somewhat if you’re using components that provide bonuses with different magnitudes, and also know that this equation is only valid when all components share the same stacking penalty.