Author Topic: C# Aurora v0.x Suggestions  (Read 350849 times)

0 Members and 1 Guest are viewing this topic.

Offline Alsadius

  • Lieutenant
  • *******
  • Posts: 176
  • Thanked: 87 times
Re: C# Aurora v0.x Suggestions
« Reply #1680 on: January 09, 2020, 01:44:34 PM »
Well it works pretty well in games such as Distant Worlds which have far less intricate ship design systems. They work pretty much as described above and it work fairly well and is not difficult to comprehend or design around. There you have three different speed settings which all use different amounts of energy and thus fuel. You need fuel to power the power plants and the efficiency of burning fuel is connected to the type of power plants that you have.

I don't think it would be difficult to handle if it was changed down the line, it would at least open up several new possibilities to build ships and why you do it.

It'd make for a decent game, but it'd also make for a very different game. Just assume that the power plants are included in the weight of the other modules, especially the engines. (Yes, this makes the power plant modules slightly odd - call them "power converters" or something?)

Offline Father Tim

  • Vice Admiral
  • **********
  • Posts: 2162
  • Thanked: 531 times
Re: C# Aurora v0.x Suggestions
« Reply #1681 on: January 09, 2020, 04:08:59 PM »
Ships already have a 'power budget' -- power plants vs capacitors -- so if this expanded to include additonal components on either side of the (in)equation I wouldn't mind.

. . . But I absolutely DO NOT WANT any sort of in-combat power allocation decisions.  If I'm hurling a thirty-six vessel battlefleet versus a hundred-odd bug ships of the Arachnid Omnivoracity it would be a nightmare of micro-management.  Tell me at ship design that I need extra power converters or batteries or auxiliary warp reactors for my sensor suite, fine, but don't slow down my gameplay.
 
The following users thanked this post: AlStar

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2837
  • Thanked: 673 times
Re: C# Aurora v0.x Suggestions
« Reply #1682 on: January 09, 2020, 05:22:33 PM »
Ships already have a 'power budget' -- power plants vs capacitors -- so if this expanded to include additonal components on either side of the (in)equation I wouldn't mind.

. . . But I absolutely DO NOT WANT any sort of in-combat power allocation decisions.  If I'm hurling a thirty-six vessel battlefleet versus a hundred-odd bug ships of the Arachnid Omnivoracity it would be a nightmare of micro-management.  Tell me at ship design that I need extra power converters or batteries or auxiliary warp reactors for my sensor suite, fine, but don't slow down my gameplay.

It probably would simply work like power plants do right now, more or less if you don't have enough power to power all the systems at once it would shut down system  according to a priority list. You probably could decide what that is. So it could shut down sensors first, reduce engine speed second and weapons last... or some such. You should not need to micromanage it. It would be a power pool like now but for more things than just weapons.

Or it would just make weapons fire slower, active sensors to be reduced in power and engines slowing down... until you say turn of the sensors or change the speed of the ships yourself.

The same when the reactors get damaged.

At least that is how I envision it could work.

It should not be a complicated system and it should only include active system, those that you don't always use, such as active sensors, weapons, shields and engines... perhaps even hangars. Less power to the hangar means lower reload, repair and refuel rates of crafts. More permanent passive system should probably be excluded for simplicity such as crew, maintenance, bridge systems and the like.
 
The following users thanked this post: shepard1707

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2837
  • Thanked: 673 times
Re: C# Aurora v0.x Suggestions
« Reply #1683 on: January 10, 2020, 02:39:57 AM »
One more suggestion I would like to see in C# is a change in how the capacitor work with energy weapons. Certain weapons and levels are really bad in how they line up with Capacitor technology and the required energy. Since weapons only fire every five seconds there are often huge waste of the the energy the goes into the weapon making them very inefficient. Particle Beams have a particular problem with this.

I think that energy should go into the weapon power bank and stored so that weapons sometimes fire 5s earlier once in a while if possible.

Example
A Particle beam with Strength 3 has a power requirement of 7, there are no Capacitor level to correctly charge the weapon and capacitor of 3 is normal at that tech level and that makes the gun fire every 15s. But if you charged the weapon with 9 power then 2 power should remain in the gun and transferred to the next cycle so now it will fire after 10s two times in a row. So this way the particle beam would fire 15s, 10s, 10s.

This way you would not have to figure what capacitor to stick in a weapon as long as it does not supply more power than it can use to fire every 5s.

You could show the fire cycle in the profile like 15s/10s(2) or something.
 
The following users thanked this post: Alsadius

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11667
  • Thanked: 20436 times
Re: C# Aurora v0.x Suggestions
« Reply #1684 on: January 10, 2020, 04:54:32 AM »
I'm a big fan of Star Fleet Battles, which had an extensive power management system. However, that is a tactical game and Aurora is more at operational level. I consciously left out tactical elements such as facing, weapon arcs, hiding behind terrain, power management, etc..

Adding that type of detail would be overwhelming in large battles. Also, detail is important in tactical battle games because careful management of small edges can make a difference in a balanced engagement. Conversely, many Aurora battles are decided before the first shot is fired and careful management of small edges is often irrelevant to the outcome.
 
The following users thanked this post: Bremen, Kristover

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2837
  • Thanked: 673 times
Re: C# Aurora v0.x Suggestions
« Reply #1685 on: January 10, 2020, 06:49:12 AM »
I'm a big fan of Star Fleet Battles, which had an extensive power management system. However, that is a tactical game and Aurora is more at operational level. I consciously left out tactical elements such as facing, weapon arcs, hiding behind terrain, power management, etc..

Adding that type of detail would be overwhelming in large battles. Also, detail is important in tactical battle games because careful management of small edges can make a difference in a balanced engagement. Conversely, many Aurora battles are decided before the first shot is fired and careful management of small edges is often irrelevant to the outcome.

One interesting effect that I miss from Aurora is the ability to run from a fight as speed are sort of arbitrary. If tied to some power systems it would be able to build ships that can run away fast but not fire its weapon or perhaps not even use their shields. Since you would have to juggle these things you are likely to be able to sprint out of danger as the enemy can't sprint as fast AND shoot their weapons at the same time. If you design a ship around max speed and weapons firing the ship would have to sacrifice allot of other operational benefits such as total weapon power, defensiveness leaving them vulnerable in other ways.

At least there would be a wider gap between moving at chasing speed and fleeing speeds that I think would add to the tactical element of the game.

So there could be some potential interesting effects from being able to do this. I do agree with too much micromanagement... it would have to be a system that is highly automatic and streamlined to work well.

Or for simplicity if you would allow for such tactics then introduce a flanking speed mode where the ship move at say +25% speed but can't use any weapon systems or active sensors and burns twice the amount of normal fuel AND run the maintenance cycle like four times the speed or something. A ship could not even use missile fire-controls thus guide missiles in flight during such speeds, missiles would simply stop until you slow down and acquire the target again to guide the missiles. Once a ship stop moving at flank speed there should be a grace period before weapon and system can be activated, much like making a combat jump. Otherwise you could flank speed at a fleeing enemy and drop out when you are right on top of them and fire your weapons.
« Last Edit: January 10, 2020, 07:22:15 AM by Jorgen_CAB »
 

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11667
  • Thanked: 20436 times
Re: C# Aurora v0.x Suggestions
« Reply #1686 on: January 10, 2020, 07:27:15 AM »
One interesting effect that I miss from Aurora is the ability to run from a fight as speed are sort of arbitrary. If tied to some power systems it would be able to build ships that can run away fast but not fire its weapon or perhaps not even use their shields. Since you would have to juggle these things you are likely to be able to sprint out of danger as the enemy can't sprint as fast AND shoot their weapons at the same time. If you design a ship around max speed and weapons firing the ship would have to sacrifice allot of other operational benefits such as total weapon power, defensiveness leaving them vulnerable in other ways.

At least there would be a wider gap between moving at chasing speed and fleeing speeds that I think would add to the tactical element of the game.

So there could be some potential interesting effects from being able to do this. I do agree with too much micromanagement... it would have to be a system that is highly automatic and streamlined to work well.

Or for simplicity if you would allow for such tactics then introduce a flanking speed mode where the ship move at say +25% speed but can't use any weapon systems or active sensors and burns twice the amount of normal fuel AND run the maintenance cycle like four times the speed or something. A ship could not even use missile fire-controls thus guide missiles in flight during such speeds, missiles would simply stop until you slow down and acquire the target again to guide the missiles. Once a ship stop moving at flank speed there should be a grace period before weapon and system can be activated, much like making a combat jump. Otherwise you could flank speed at a fleeing enemy and drop out when you are right on top of them and fire your weapons.

Some form of increased speed with a penalty or associated risk might be OK - perhaps like Orion Pirates in SFB or the engine tuners in Starfire. I'll give that some thought.
 
The following users thanked this post: Kristover, Alsadius

Offline Bughunter

  • Bug Moderators
  • Rear Admiral
  • ***
  • Posts: 929
  • Thanked: 132 times
  • Discord Username: Bughunter
Re: C# Aurora v0.x Suggestions
« Reply #1687 on: January 10, 2020, 08:04:54 AM »
In most scenarios I think the stronger side would just chase down the weaker regardless, wait out whatever timer and kill them. I don't like that version at all.

Maybe if it was introduced as pushing engines over safe limits and involve a risk of them (per engine) breaking or even exploding? The weaker side would not have much to lose from taking the risk, the stronger would by definition have to risk more assets to pursue. Fuel efficiency penalty also seems appropriate.

Still they would have to be relatively equal in speed to begin with for this to give you edge enough to flee so I would not expect that scenario to play out too often. And how long can you sustain it? They might chase you for days if they know where you are going. If it can be sustained for any length of time it would be used for other purposes as well.

Even if only a temporary speed increase can be achieved I would expect it to be weaponized somehow regardless of risk. Missiles where you accept a certain failure rate, AMM:s, dropships..

But I could see some interesting things coming out of going in this direction. The risk/reward approach to designs, more depth to how many engines/repair capacity to include. The decision if to boost or not. Even on a tactical level trying to lure enemies into boosting after your smaller force and pick off stragglers who blow their engines with your second taskforce.
 

Offline clement

  • Pulsar 4x Dev
  • Sub-Lieutenant
  • *
  • c
  • Posts: 137
  • Thanked: 13 times
Re: C# Aurora v0.x Suggestions
« Reply #1688 on: January 10, 2020, 08:21:51 AM »
Instead of linking engine tuning to a time limit, have it trigger a higher failure rate for engines. If the failure rate of an engine was increased by a factor of 10 or 100, then there would be a serious trade off. If tuning was a flat speed boost, I am sure Steve can figure out what kind of increased failure rate for engines would be sufficient to prevent it from being abused. If the tuning level is variable, then it could be a scalar for the increase in the failure rate.

This means ships fleeing could escape but run the risk of engine failures and detonations if they run out of maintenance supplies..

It could of course also prevent weapon firing while active.
 

Offline Kristover

  • Gold Supporter
  • Lt. Commander
  • *****
  • K
  • Posts: 259
  • Thanked: 135 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
    2023 Supporter 2023 Supporter : Donate for 2023
Re: C# Aurora v0.x Suggestions
« Reply #1689 on: January 10, 2020, 09:06:50 AM »
I'm a big fan of Star Fleet Battles, which had an extensive power management system. However, that is a tactical game and Aurora is more at operational level. I consciously left out tactical elements such as facing, weapon arcs, hiding behind terrain, power management, etc..

Adding that type of detail would be overwhelming in large battles. Also, detail is important in tactical battle games because careful management of small edges can make a difference in a balanced engagement. Conversely, many Aurora battles are decided before the first shot is fired and careful management of small edges is often irrelevant to the outcome.

I think I agree with Steve that given this is primarily an operational simulator, power management might be too much in the weeds to create enjoyable game play - there is essentially a lot of detail work for minimal game play benefit once the battle is actually joined.  Certainly one can always build faster ships but the sacrifice for weapons is already built in it seems.  If catching those fleeing ships is a problem, divide your force and box them in.  Take long range missile shots and score engine shots and pick off stragglers.  I think there are some other options to be consider:  Steve indicated a possible modifier which might be do the trick.  Perhaps doing something with Commander or Engineer's engineering skill allows one to get more speed out of an engine.  I think I also like the idea of a 'disruptor' sort of weapon system - an EM warhead on a missile which makes a temporary debuff perhaps?
 

Offline Alsadius

  • Lieutenant
  • *******
  • Posts: 176
  • Thanked: 87 times
Re: C# Aurora v0.x Suggestions
« Reply #1690 on: January 10, 2020, 09:10:22 AM »
Some form of increased speed with a penalty or associated risk might be OK - perhaps like Orion Pirates in SFB or the engine tuners in Starfire. I'll give that some thought.

Suggestion: How about a checkbox that I'll call "Brave Sir Robin Mode"?

Penalty: All power plants, shield generators, sensors, and fire controls are disabled.
Bonus: Engine power is increased by a factor of (tonnage of above module types / tonnage of engines) * 50%. Fuel use and thermal signature increases by a factor of (tonnage of above module types / tonnage of engines) * 2.

Example: Consider a 10,000 ton ship with 1000 tons of engines and 500 tons of power plants/sensors/fire. If it checks Brave Sir Robin Mode, all its sensors turn off, but their power is now diverted to the engines. That 500 tons of gear acts like 250 tons of engine, and increases the ship's speed by 25%. However, it's just lost its eyes and its ability to fire most weapons. It's also doubled fuel use and thermal signature, because high-power mode on the engines is pretty inefficient.

It's simple, it can be a checkbox on the fleet, and it isn't something you'll normally want to use(since the mass and fuel ratios are much worse than for dedicated engines, and most of that gear is more expensive per HS as well). But it'd be an option if you just need to GTFO back to the nearest gate as soon as possible.

Offline sloanjh (OP)

  • Global Moderator
  • Admiral of the Fleet
  • *****
  • Posts: 2805
  • Thanked: 112 times
  • 2020 Supporter 2020 Supporter : Donate for 2020
    2021 Supporter 2021 Supporter : Donate for 2021
Re: C# Aurora v0.x Suggestions
« Reply #1691 on: January 10, 2020, 09:29:18 AM »
Instead of linking engine tuning to a time limit, have it trigger a higher failure rate for engines. If the failure rate of an engine was increased by a factor of 10 or 100, then there would be a serious trade off. If tuning was a flat speed boost, I am sure Steve can figure out what kind of increased failure rate for engines would be sufficient to prevent it from being abused. If the tuning level is variable, then it could be a scalar for the increase in the failure rate.

This means ships fleeing could escape but run the risk of engine failures and detonations if they run out of maintenance supplies..

It could of course also prevent weapon firing while active.

I agree with Steve and Father Tim 100% about the micromanagement hell that would arise if SFB-esque energy management were introduced in Aurora.

OTOH, I really like this (and Bughunter's) "engine tuners" idea as something to contemplate, where tuning leads to very high risk of engine breakdown (or explosion).  A few observations:

1) It instantly brings to mind the scene from one of the Hornblower books (Hotspur perhaps), where he's scouting for the Brest blockade force and a French frigate comes out and pursues him in a long stern chase in heavy weather.  My recollection is that they both pile on too much sail for the weather until someone's mast breaks, which is analogous to an overstressed (from tuning) engine breaking down.  From this point of view it's a really cool idea.
2) Steve is intimately familiar with the "engine-tuning-chase-leading-to-breakdown" scenario - there are a bunch of these in the Rigellian Diaries.  So I think he'll have a good feeling for whether he thinks it's a positive or negative game mechanic.
3) One of the things I remember from the diaries is that both sides essentially always tuned.  IIRC this was because the pursuing force was usually a (bug) swarm, and the only bad thing that would happen was non-catastrophic, i.e. and engine breakdown.  So this kind of takes away the ability to make choices - tuning is obviously superior over not tuning in the pursuit scenario.  So if Steve did put this in, I would advocate having the breakdown penalty include a significant (e.g. 50% of the time) risk of explosion.  That would make the decision a lot more stark, and add to fiction possibilities (especially if it were technobabbled that when tuning goes bad the engines run away and there's e.g. a 15 second window where the crew (not the player) can recognize this and try to shut tuning down with a 50/50 chance of explosion vs damage.  Just enough time for the engineer to say "Captain, engines are destabilizing.  Attempting to [BOOM]")
4) There are two scenarios: 1) small tactical advantage in combat, i.e. closing to beam range 2) long term running away (where you have to get all the way across the system to get to the warp point/out of sensor range).  This means that for it to be a useful mechanic the failure rates would probably need to be fairly low; on a timescale of 1 week mean time to boom.  OTOH, if you just need to stay out of beam range, or if you're just a little inside the enemy's sensor envelope they could be shorter.  In other words, I'm not sure the coolness factor outweighs the coding work.
5)  I would put the flag at the TG level, and I would have it increase the max possible speed.  This is because some ships in the TG might be able to go faster, and should not be penalized as badly.  In other words, it's only that slow BB (or whatever) that needs to tune to keep of with the rest of the TG while running away.

John
 

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11667
  • Thanked: 20436 times
Re: C# Aurora v0.x Suggestions
« Reply #1692 on: January 10, 2020, 09:31:48 AM »
Starfire - the  distant, original ancestor of Aurora - had two game play concepts that might work here.

1) Detuning: A mode that could used for all engines. In Aurora terms, this would be an on/off function at the ship level that provides a small boost to speed (perhaps 20%), reduces sensor range, impairs fire control and has an increasing risk of damage to engines.

2) Engine Tuners. A system built into engines that provides a boost to speed without penalty for a given period. The system itself requires additional space. In Aurora terms, it would be on/off at the ship level for ships with engines equipped with tuners. As the tuners add mass without power, they would either reduce normal speed or reduce available space in exchange for a short-term, tactical speed advantage.
 

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11667
  • Thanked: 20436 times
Re: C# Aurora v0.x Suggestions
« Reply #1693 on: January 10, 2020, 09:37:20 AM »
I think it is also worth mentioning that in Starfire, everyone was essentially at the same speed, so small speed advantages made a difference. That won't be true very often in Aurora, so the speed boost and penalties would have to be much larger for it to be relevant.
 

Offline Kristover

  • Gold Supporter
  • Lt. Commander
  • *****
  • K
  • Posts: 259
  • Thanked: 135 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
    2023 Supporter 2023 Supporter : Donate for 2023
Re: C# Aurora v0.x Suggestions
« Reply #1694 on: January 10, 2020, 09:38:12 AM »
I  think 2) sounds like a reasonable solution.  Give Engine Tuners a research line with increased power per level, or size.  I think making it a fixed size that makes them not a consideration for fighters or frigate-sized vessels - it is a module that really be viable for light-cruisers or above - would reduce the chances of unhittable small craft.