Author Topic: C# Aurora Changes Discussion  (Read 442041 times)

0 Members and 4 Guests are viewing this topic.

Iranon

  • Guest
Re: C# Aurora Changes Discussion
« Reply #750 on: May 17, 2017, 05:58:56 AM »
From a tactics point of view fighters are really more weapons systems like missiles than independent warships.
...
The mere fact that they're fighters means that the fuel use is less likely to bother them on a strategic level since they'll remain docked in their carriers when not fighting. If anything I think the losers here will be smaller escort ships; larger engines mean that big warships will have better fuel economy.

Ofcourse you normally want to crank up the power mod on the fighters more then you capital ships as well, but that does give them a significant speed advantage, so you get something important for it in return.

Which mechanics actually encourage these assumed characteristics of fighters? I think that is more player habit or roleplaying things how they play out in various SF settings. In some ways, I think we are more encouraged to use fighters designed for years of independent operations and full-sized parasite warships designed for 3-day missions.

Maybe it's time to dust off my idea for parasite warships that remain in hangers until battle starts :)

Agreed. They're already attractive, and the mechanics changes will encourage fuel-hungry designs to be as large as practical (fuel economy changes, but other logistics changes may also play into this... 50 FACs will no longer be easier to maintain away from an empire's core than 5 warships).

If the original rationale for fast fighters on carriers was to extend range and save fuel on strategic movement... does this still exist when building a fast warship instead will reduce fuel use to 20% while retaining the high speed on the strategic level and eliminating the overhead for the carrier?
 

Offline alex_brunius

  • Vice Admiral
  • **********
  • Posts: 1240
  • Thanked: 153 times
Re: C# Aurora Changes Discussion
« Reply #751 on: May 17, 2017, 06:53:03 AM »
Which mechanics actually encourage these assumed characteristics of fighters? I think that is more player habit or roleplaying things how they play out in various SF settings. In some ways, I think we are more encouraged to use fighters designed for years of independent operations and full-sized parasite warships designed for 3-day missions.

IMO The 3 main mechanics which encourage "realistic" design here is cost, research cost and explosion chance.

  • Cost of equipping your entire fleet with max power mod engines and then carrying them along in hangars is going to be astronomical compared to just equipping some small fighters carrying around only the missiles. To power up your capital ships you need vastly more engines to carry around all their armor, shields, supply, fuel, sensors, reloads for the entire fleet and mission, rather then just enough missiles and fuel for a small 500M km strike (fighters). And on top of that the bigger hangars and extra efficient engines needed for a big fleet.
  • Research cost is going to be prohibitive for designing a 400 HS max power mod engine. It will probably cost more then unlocking a next level drive technology does!
  • Explosion Chance. A Fighter is fine if it explodes to kingdom come when hit as you have hundreds more of them, your 50k+ ton capital warship going up from a single unlucky meson hit exploding it's massive engine? Not so much! (I have tried high power mod capital ships and it's not fun when their engine goes up).



What mechanics is it that you think promote using fighters for long endurance missions and capital ships for short ones?
« Last Edit: May 17, 2017, 06:57:57 AM by alex_brunius »
 

Offline iceball3

  • Captain
  • **********
  • Posts: 454
  • Thanked: 47 times
Re: C# Aurora Changes Discussion
« Reply #752 on: May 17, 2017, 10:28:52 AM »
Hey, Steve, later on the development path, will the AI shipbuilding/design doctrine and superficial (potentially forced) behaviors be changed any to reflect the new changes to logistics and fuel?
For instance, cutting down the "allowed traveling range" of AI ships with bad fuel/maintenance economy, making them use the new tech that's been rolled out, making them at least superficially use the new deep space hangars, etc.
This is assuming you're not gonna tackle AI that actually suffers from and directly handles these logistics drawbacks, of course.
 

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11649
  • Thanked: 20350 times
Re: C# Aurora Changes Discussion
« Reply #753 on: May 17, 2017, 11:48:14 AM »
Hey, Steve, later on the development path, will the AI shipbuilding/design doctrine and superficial (potentially forced) behaviors be changed any to reflect the new changes to logistics and fuel?
For instance, cutting down the "allowed traveling range" of AI ships with bad fuel/maintenance economy, making them use the new tech that's been rolled out, making them at least superficially use the new deep space hangars, etc.
This is assuming you're not gonna tackle AI that actually suffers from and directly handles these logistics drawbacks, of course.

There is already an 'allowed travelling range' for AI carrier-based fighters so I could extend that to ships. However, I am considering adding fuel use to the AI. With the improved execution speed there should be scope for adding more complex AI behaviour. Not sure yet about AI maintenance.
 
The following users thanked this post: palu

Iranon

  • Guest
Re: C# Aurora Changes Discussion
« Reply #754 on: May 17, 2017, 12:55:15 PM »
@ alex_brunius:
In response to your points...

Cost: If we replace a 10000t fighter strike group with a 10000t warship of the same speed, total engine cost won't increase. Going bigger would allow installing all sorts of fluff, but as a direct replacement for the fighters it could be just as lean.

Research Cost: Size 400 may well be excessive, and that's quite an advanced tech anyway. But cutting down fuel use of the current generation by 2/3 (for which size-40 would be sufficient compared to fighter-sized engines) may be worth the expenditure. Fighters may also be forced to use excessively compact engines (requiring higher multiplier tech) to remain within 500t where warships can freely trade a little tonnage efficiency for considerably better fuel efficiency.

Explosion chance: Agreed somewhat, and there are other matters of redundancy - where a larger ship makes better use of passive defences, tiny ships make the opponent waste firepower on overkill.

*

On to your question: Mostly the scaling of sensor footprint and fuel use. A very simplified take on it:

The reduction of sensor footprint by using fighters for missile delivery is very beneficial. If speed is no major objective, the losses in fuel efficiency won't be too relevant, and giving them a decent mission life is more economical than putting them in an expensive, highly visible and vulnerable carrier.

For fast, high-powered beam attackers, fuel consumption is a concern even if they spend most of their time in a hangar. On stressed ships, weight is the enemy; carting around more fuel means we need even more high-powered engines to maintain speed. Also, if I'm willing to spend the resources on speed, I may also want long beam range to take little or no return fire. Speed + long-ranged weapon + associated FC usually doesn't fit into 500t.
Sensor footprint isn't a major option if we need to cross the AMM envelope.
 

Camilo

  • Guest
Re: C# Aurora Changes Discussion
« Reply #755 on: May 17, 2017, 03:40:01 PM »
Hi,

If we want to avoid the posibility of having big fighters, there could be a rule where hangars don´t just add in size.  A 1000 ton hangar can only carry 1000 tons of ships.  A ship with 2 1000 ton hangars can not carry a 1500 ton ship, it can carry 4 500 ton ships, 10 250 ton ships, 2 750 ton ships or 2 1000 ton ships.

We could have techs for biger and biger hangars with biger hangars being more efficient in their space cost.
 

Offline iceball3

  • Captain
  • **********
  • Posts: 454
  • Thanked: 47 times
Re: C# Aurora Changes Discussion
« Reply #756 on: May 17, 2017, 11:38:25 PM »
Steve, if I may pitch a small request/suggestion:
Could the population cap on tidally locked planets be turned into a soft cap? Specifically, even if it is colony cost 0 at the time, allow population above the limit with a slow-exponential growth on infrastructure cost.
This would emulate the fact that infrastructure could be built outside of the "safe zone" band around the planet, just at reduced efficiency. The temperature the folks living there would suffer would be minor atmospheric hazards compared to living on a voided atmosphere planet, I imagine, or on venus.
 

Offline Barkhorn

  • Commodore
  • **********
  • B
  • Posts: 719
  • Thanked: 133 times
Re: C# Aurora Changes Discussion
« Reply #757 on: May 17, 2017, 11:47:30 PM »
Hey Steve, I had a good idea for how to solve the problem of civilian shipping taking obnoxious amounts of processing power for large empires.

Abstract the individual ships away.  Not completely, of course, but they don't need to be tracked perfectly 100% of the time.

It should be (relatively) trivial to compute how densely populated each shipping lane is, it's just distance between each destination divided by # of ships on the lane.  From there we can get a figure for how quickly cargo is moved.  It also can handle commerce raiding.  When a foreign (or maybe only enemy?) ship approaches the route, a dice-roll, based on the lane density, can be made to decide whether any ships are there.  If the roll succeeds, one or more of the ships on the line are pulled from abstraction and made concrete.  This is done before they are detected; the approaching ship will need to pass the usual detection checks you would expect from Aurora.  If the civilian ship survives the encounter, it is de-spawned at some point and put back in the abstraction.  Possible good times for de-spawning include when either this ship or the enemy ship leave the current system, or when some suitably large distance between the ships is achieved.

This should dramatically cut down on the processor overhead caused by civilian shipping.  The number of routes will never be higher than the number of ships.  You do not need to do any movement calculations on the routes.  The routes themselves do no detection calculations.  Further, fewer things will have to do detection calculations on them or the ships on them.
 

Offline iceball3

  • Captain
  • **********
  • Posts: 454
  • Thanked: 47 times
Re: C# Aurora Changes Discussion
« Reply #758 on: May 18, 2017, 12:18:44 AM »
Abstract the individual ships away.  Not completely, of course, but they don't need to be tracked perfectly 100% of the time.

It should be (relatively) trivial to compute how densely populated each shipping lane is, it's just distance between each destination divided by # of ships on the lane.  From there we can get a figure for how quickly cargo is moved.  It also can handle commerce raiding.  When a foreign (or maybe only enemy?) ship approaches the route, a dice-roll, based on the lane density, can be made to decide whether any ships are there.  If the roll succeeds, one or more of the ships on the line are pulled from abstraction and made concrete.  This is done before they are detected; the approaching ship will need to pass the usual detection checks you would expect from Aurora.  If the civilian ship survives the encounter, it is de-spawned at some point and put back in the abstraction.  Possible good times for de-spawning include when either this ship or the enemy ship leave the current system, or when some suitably large distance between the ships is achieved.

This should dramatically cut down on the processor overhead caused by civilian shipping.  The number of routes will never be higher than the number of ships.  You do not need to do any movement calculations on the routes.  The routes themselves do no detection calculations.  Further, fewer things will have to do detection calculations on them or the ships on them.
This abstraction becomes a problem for multiple player controlled lines, especially when the hostile nation has a DSTS anywhere in the system.
Given sufficient thermal coverage, you'll have players annoyed in frustration that their quarry just vanished due to ranges, or what have you, on top of sheer unpredictability of the target abstraction.
Even in single player, a similar issue crops up: you can't effectively defend your shipping lines if you don't know where the ships in it are.
 

Offline MarcAFK

  • Vice Admiral
  • **********
  • Posts: 2005
  • Thanked: 134 times
  • ...it's so simple an idiot could have devised it..
Re: C# Aurora Changes Discussion
« Reply #759 on: May 18, 2017, 12:45:07 AM »
Abstraction would be and interesting option to work on, however it remains to be seen if anyone will actually have a problem with the civilian shipping in C# due to the major performance increase.
Smarter ship usage by the AI would come a long way to avoiding slow downs, already major gains was made by giving civilians more power to cull or upgrade their ship size, similar performance gains might be made by making civilians less efficient when it comes to picking up and delivering things. For instance large ships picking up multiple cargos that are near each other, individually each delivery might take longer, but as only one large ship is being used for multiple orders it's more efficient.
" Why is this godforsaken hellhole worth dying for? "
". . .  We know nothing about them, their language, their history or what they look like.  But we can assume this.  They stand for everything we don't stand for.  Also they told me you guys look like dorks. "
"Stop exploding, you cowards.  "
 

Offline alex_brunius

  • Vice Admiral
  • **********
  • Posts: 1240
  • Thanked: 153 times
Re: C# Aurora Changes Discussion
« Reply #760 on: May 18, 2017, 05:49:43 AM »
On to your question: Mostly the scaling of sensor footprint and fuel use. A very simplified take on it:

The reduction of sensor footprint by using fighters for missile delivery is very beneficial. If speed is no major objective, the losses in fuel efficiency won't be too relevant, and giving them a decent mission life is more economical than putting them in an expensive, highly visible and vulnerable carrier.

For fast, high-powered beam attackers, fuel consumption is a concern even if they spend most of their time in a hangar. On stressed ships, weight is the enemy; carting around more fuel means we need even more high-powered engines to maintain speed. Also, if I'm willing to spend the resources on speed, I may also want long beam range to take little or no return fire. Speed + long-ranged weapon + associated FC usually doesn't fit into 500t.
Sensor footprint isn't a major option if we need to cross the AMM envelope.

Most of my current fighters in Aurora end up around 5-10% of their tonnage fuel, and I think similar ratios, maybe upwards to 15% max might be motivated with the changes.

If you replace the entire Carrier wing with a single big ship instead you could save maybe 5% of the tonnage in fuel and thus increase performance or mission tonnage by around 10-15%, but is the increased risk in explosion chance, vulnerability and loss of stealth really worth this? I can't see how it can be the way I operate my Carriers at least.


Also remember that small size not only gives you the advantage of harder detection, but also making it much harder for enemy missile systems to lock on. A single massive ship will be targetable from significantly further away by most ASM systems then the small 250-500 ton fighters will, and thus need to achieve a range advantage in both ASM sensors, FC and missile range as well, which proper missile fighters don't need to worry about any off since they sneak in below the resolution of all ASM systems.
« Last Edit: May 18, 2017, 05:54:05 AM by alex_brunius »
 

Offline Silvarelion

  • Warrant Officer, Class 2
  • ****
  • S
  • Posts: 63
  • Thanked: 4 times
Re: C# Aurora Changes Discussion
« Reply #761 on: May 18, 2017, 09:43:57 AM »
If I may be so bold as to add an example to the discussion between @alex_brunius and @Iranon , attached is an abstraction I did of a heavy fighter fleet (of 16.6 ships) and a scaled up version of the same ship (16.6 times larger than the fighters). 16.6 was to keep the engine size ratios the same.  These are all using the numbers in 7.1. As you can see, the ship, with size 50 engines, has twice the range of the fighters. My understanding is that the fighter range will drop by about half in C#, meaning this ship is likely to have 4 times the range of the fighter fleet. This comparison should become even more extreme at larger engine sizes.


Most of my current fighters in Aurora end up around 5-10% of their tonnage fuel, and I think similar ratios, maybe upwards to 15% max might be motivated with the changes.

Even with such small fuel ratios, the fleet-wide fuel savings are nothing to scoff at, and would require a distinct advantage to offset it.  For missile fighters, their near invisibility, salvo dispersion, increased missile performance and increased strike flexibility are viable, in my opinion, and a doctrine I have used in the past, and probably will again in the future.

Sensor footprint isn't a major option if we need to cross the AMM envelope.

To echo @Iranon, any beam fighter fleet I have created all end up chewed up once they cross the AMM envelope. In the case of beam ships, it seems like the extra survivability of a larger ship more than makes up for the damage dispersion (leading to overkill) of a fighter fleet. A larger ship also gives you much more flexibility on weapons loadout and doctrine (alpha strike vs sustained fire). Throw the fuel savings of a larger engine on top of that, and this becomes a viable strategy, one that I am using in my current game.
Mistake Not My Current State Of Joshing Gentle Peevishness For The Awesome And Terrible Majesty Of The Towering Seas Of Ire That Are Themselves The Mere Milquetoast Shallows Fringing My Vast Oceans Of Wrath.
  ~The Mistake Not, Hydrogen Sonata, Iain Banks
 

Offline Bremen

  • Commodore
  • **********
  • B
  • Posts: 743
  • Thanked: 150 times
Re: C# Aurora Changes Discussion
« Reply #762 on: May 18, 2017, 12:48:24 PM »
Using larger beam gunships instead of fighters makes them less vulnerable to AMMs (though not by as much as you'd think), but it makes them more vulnerable to ASMs, because of overkill, longer detection ranges, and engine explosions.

Considering the reduced range of AMMs we'll probably see in this expansion, I think having parasites be very inefficient targets for ASMs may be worth the increased vulnerability to AMMs.
 

Offline Silvarelion

  • Warrant Officer, Class 2
  • ****
  • S
  • Posts: 63
  • Thanked: 4 times
Re: C# Aurora Changes Discussion
« Reply #763 on: May 18, 2017, 12:58:16 PM »
For myself, anyways, I wouldn't get into beam range without first drawing out as many ASMs as I could. Certainly that kind of passive missile defense does have value, though.
Mistake Not My Current State Of Joshing Gentle Peevishness For The Awesome And Terrible Majesty Of The Towering Seas Of Ire That Are Themselves The Mere Milquetoast Shallows Fringing My Vast Oceans Of Wrath.
  ~The Mistake Not, Hydrogen Sonata, Iain Banks
 

Offline Barkhorn

  • Commodore
  • **********
  • B
  • Posts: 719
  • Thanked: 133 times
Re: C# Aurora Changes Discussion
« Reply #764 on: May 18, 2017, 01:02:33 PM »
This abstraction becomes a problem for multiple player controlled lines, especially when the hostile nation has a DSTS anywhere in the system.
Given sufficient thermal coverage, you'll have players annoyed in frustration that their quarry just vanished due to ranges, or what have you, on top of sheer unpredictability of the target abstraction.
Even in single player, a similar issue crops up: you can't effectively defend your shipping lines if you don't know where the ships in it are.
Ships would not be de-spawned until some satisfactory condition is met.  Perhaps no enemies (or foreigners) in system.  Perhaps de-spawn when the enemies/foreigners are a suitably large distance away, preferably far outside detection range.  Or some combination of these.  Ships would not de-spawn when detected, or even when anywhere near detection.

You can still defend your shipping lines because you'll know where the shipping lanes are.  Sure you can't do convoys, but you already can't with civilian shipping; there's no way to coordinate with them.

Abstraction would be and interesting option to work on, however it remains to be seen if anyone will actually have a problem with the civilian shipping in C# due to the major performance increase.
Smarter ship usage by the AI would come a long way to avoiding slow downs, already major gains was made by giving civilians more power to cull or upgrade their ship size, similar performance gains might be made by making civilians less efficient when it comes to picking up and delivering things. For instance large ships picking up multiple cargos that are near each other, individually each delivery might take longer, but as only one large ship is being used for multiple orders it's more efficient.
With abstraction, you don't need this arbitrary culling of ships.  Look at real life, we have civilian shipping of all sizes, not just huge Panamax freighters.  Abstraction will allow shipping of all sizes to still exist.

But if C# does make all this discussion moot, that's fine with me too.