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

0 Members and 4 Guests are viewing this topic.

Offline professorpicke

  • Able Ordinary Rate
  • p
  • Posts: 4
  • Thanked: 1 times
Re: C# Aurora v0.x Suggestions
« Reply #2070 on: March 16, 2020, 05:52:55 PM »
Quote from: Father Tim link=topic=9841. msg119594#msg119594 date=1584184414
Uh, there isn't one.   There's no 'dodge bonus' or anything for Agility -- it has zero effect on defense, only on chance to hit.

Oh I didn't even think of that.  I guess agility does serve a real purpose.  I'd like to change my suggestion to keep agility, but do not make it a size you type in.  Instead make it a technology you choose to equip or not equip, that reduces your speed by say 20% but increases hitchance by 50% (for the slower speed), with the hitchance increasing with research.  Really all I cared about was getting rid of the spreadsheet.
 

Offline QuakeIV

  • Registered
  • Commodore
  • **********
  • Posts: 759
  • Thanked: 168 times
Re: C# Aurora v0.x Suggestions
« Reply #2071 on: March 16, 2020, 06:08:48 PM »
Quote from: Steve Walmsley
It's extremely complex and therefore unlikely to happen any time soon.  The AI currently decides on a doctrine and then designs and builds a fleet according to that doctrine.  It knows what everything does, because it was built to a plan.  It would be a lore more complex for the AI to understand everything designed by the player and then develop a doctrine of its own based on those designs.
Quite understandable.  I reckon the AI could just roll for the doctrine and ignore any potentially pre-existing designs, that would cut some corners and make it a bit less complex for the AI.  That would risk losing some work, but I suppose a warning message about AI ignoring certain stuff would prevent it from being a surprise for the player.  Handing the stuff for AI to handle once you've set up stuff, like colonies in multiple pre-generated systems with various installations, and so forth, would make things less prone for accidents.  I do realize that it can be done through already existing tools to a degree via SM, but the ability to double-check the details before handing the keys would be handy.  I'm aware that my scenario is going to be most likely a very rare in nature compared to the average playthrough and I'll make do with any tools available to the best of my abilities  :)

I mean, the ai won't know what to do with the ships you give it at all, so ignoring them would presumably mean the ships are stationary and do nothing.
 

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2837
  • Thanked: 673 times
Re: C# Aurora v0.x Suggestions
« Reply #2072 on: March 16, 2020, 06:14:20 PM »
Quote from: Steve Walmsley
It's extremely complex and therefore unlikely to happen any time soon.  The AI currently decides on a doctrine and then designs and builds a fleet according to that doctrine.  It knows what everything does, because it was built to a plan.  It would be a lore more complex for the AI to understand everything designed by the player and then develop a doctrine of its own based on those designs.
Quite understandable.  I reckon the AI could just roll for the doctrine and ignore any potentially pre-existing designs, that would cut some corners and make it a bit less complex for the AI.  That would risk losing some work, but I suppose a warning message about AI ignoring certain stuff would prevent it from being a surprise for the player.  Handing the stuff for AI to handle once you've set up stuff, like colonies in multiple pre-generated systems with various installations, and so forth, would make things less prone for accidents.  I do realize that it can be done through already existing tools to a degree via SM, but the ability to double-check the details before handing the keys would be handy.  I'm aware that my scenario is going to be most likely a very rare in nature compared to the average playthrough and I'll make do with any tools available to the best of my abilities  :)

I mean, the ai won't know what to do with the ships you give it at all, so ignoring them would presumably mean the ships are stationary and do nothing.

Yes... I think that making the player do anything for the NPR are probably off the table in any instance, that seem very complex and not worth doing. You should at best choose a specifc theme for the AI and the the NPR is created from that theme using that themed AI behaviour.
« Last Edit: March 16, 2020, 06:34:19 PM by Jorgen_CAB »
 

Offline QuakeIV

  • Registered
  • Commodore
  • **********
  • Posts: 759
  • Thanked: 168 times
Re: C# Aurora v0.x Suggestions
« Reply #2073 on: March 17, 2020, 12:35:21 AM »
I think that is potentially a pretty good option.  Have some ability to configure (some/all?) of the factors that go into the AI's design behavior that would have otherwise have been random.
 

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11667
  • Thanked: 20428 times
Re: C# Aurora v0.x Suggestions
« Reply #2074 on: March 17, 2020, 05:08:04 AM »
I think that is potentially a pretty good option.  Have some ability to configure (some/all?) of the factors that go into the AI's design behavior that would have otherwise have been random.

I won't do this for release, but this should be straightforward when I get to it.
 
The following users thanked this post: Garfunkel, QuakeIV, hostergaard, DIT_grue, Alsadius, Zhatelier

Offline hostergaard

  • Warrant Officer, Class 2
  • ****
  • h
  • Posts: 73
  • Thanked: 27 times
Re: C# Aurora v0.x Suggestions
« Reply #2075 on: March 17, 2020, 06:06:16 AM »
Not sure if its been suggested or already in the game, the list over features is getting pretty long so its hard to find out but

Being able to use theoretical designs and research projects in ships design and other projects

I have before made various suggestions on ship design, but one thing that would be lovely is being able to use designs that you have made but not yet researched when designing ships and other things. Its really annoying having to guess or calculate how big a jumpdrive or cloak or whatever you need when designing a ship and getting it wrong and having to design and research a new one that fits cause you it more crew quarters than you expected or something. Instead you could make a ship that included various possible designs that are yet to be researched and then research the design.
 

Offline Akhillis

  • Chief Petty Officer
  • ***
  • A
  • Posts: 46
  • Thanked: 5 times
Re: C# Aurora v0.x Suggestions
« Reply #2076 on: March 17, 2020, 06:26:24 AM »
Not sure if its been suggested or already in the game, the list over features is getting pretty long so its hard to find out but

Being able to use theoretical designs and research projects in ships design and other projects

I have before made various suggestions on ship design, but one thing that would be lovely is being able to use designs that you have made but not yet researched when designing ships and other things. Its really annoying having to guess or calculate how big a jumpdrive or cloak or whatever you need when designing a ship and getting it wrong and having to design and research a new one that fits cause you it more crew quarters than you expected or something. Instead you could make a ship that included various possible designs that are yet to be researched and then research the design.

http://aurora2.pentarch.org/index.php?topic=8495.msg119332#msg119332

Already in.
The Sorium must flow
 

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: C# Aurora v0.x Suggestions
« Reply #2077 on: March 17, 2020, 07:02:15 AM »
When Quasar4x is up it will have external access to the AI - and if that system works maybe that sparks ideas in Steve's mind to go into same/identical direction. Would be nice if AI could be improved over time.
 

Offline SevenOfCarina

  • Lieutenant
  • *******
  • Posts: 170
  • Thanked: 95 times
Re: C# Aurora v0.x Suggestions
« Reply #2078 on: March 17, 2020, 10:34:59 AM »
At some point in the future it'll be nice to have a certain 'fuzziness' to active and passive sensor detection. Detection of vessels is only guaranteed till a certain percentage of the sensor range against that TCS, with the percentage detection chance per increment (probably an hour?) dropping linearly till the maximum sensor range. Effectively, at the edge of sensor ranges ships could remain undetected or they could only be tracked very sporadically. This will extend to missile fire controls and the like. ECM and ECCM will modify the detection chance per increment for both active sensors and missile fire controls, but not passive sensors.

There could also be a modifier allowing you to trade between maximum sensor range and the maximum range at which detection is guaranteed while maintaining sensor cost and GPS. I think this might quite neatly solve the fighter issue - with active sensors modified to have a very high maximum range but a very low maximum range at which detection is guaranteed, fighter squadrons will eventually be detected by shipborne active sensors at long ranges, but they won't be tracked continuously and firing missiles will be foolhardy. You'll have to dispatch a destroyer squadron or two to investigate, so you'll be encouraged to maintain escort vessels for your fleets.

Of course, the main drawback as usual will be game performance degradation. On the plus side - more choices to active sensors design, a reason to bring along escorts, more vulnerable box launcher fighter squadrons, etc.
 

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11667
  • Thanked: 20428 times
Re: C# Aurora v0.x Suggestions
« Reply #2079 on: March 17, 2020, 10:40:07 AM »
At some point in the future it'll be nice to have a certain 'fuzziness' to active and passive sensor detection. Detection of vessels is only guaranteed till a certain percentage of the sensor range against that TCS, with the percentage detection chance per increment (probably an hour?) dropping linearly till the maximum sensor range. Effectively, at the edge of sensor ranges ships could remain undetected or they could only be tracked very sporadically. This will extend to missile fire controls and the like. ECM and ECCM will modify the detection chance per increment for both active sensors and missile fire controls, but not passive sensors.

There could also be a modifier allowing you to trade between maximum sensor range and the maximum range at which detection is guaranteed while maintaining sensor cost and GPS. I think this might quite neatly solve the fighter issue - with active sensors modified to have a very high maximum range but a very low maximum range at which detection is guaranteed, fighter squadrons will eventually be detected by shipborne active sensors at long ranges, but they won't be tracked continuously and firing missiles will be foolhardy. You'll have to dispatch a destroyer squadron or two to investigate, so you'll be encouraged to maintain escort vessels for your fleets.

Of course, the main drawback as usual will be game performance degradation. On the plus side - more choices to active sensors design, a reason to bring along escorts, more vulnerable box launcher fighter squadrons, etc.

The sensor model used to function differently. For example, you only saw a thermal signature - but you couldn't tell the ship. The consequence was extra micromanagement to send out a ship to check every contact, which got tedious fast, so I moved to the current immediate-knowledge model instead.
 
The following users thanked this post: SevenOfCarina

Offline SevenOfCarina

  • Lieutenant
  • *******
  • Posts: 170
  • Thanked: 95 times
Re: C# Aurora v0.x Suggestions
« Reply #2080 on: March 17, 2020, 10:52:10 AM »
The sensor model used to function differently. For example, you only saw a thermal signature - but you couldn't tell the ship. The consequence was extra micromanagement to send out a ship to check every contact, which got tedious fast, so I moved to the current immediate-knowledge model instead.

That sounds fair enough. Speaking of small ship detection, what is your verdict on the modifier to detection range for TCS smaller than sensor resolution? I recall that we had a conversation earlier where I mentioned that the (TCS / Resolution)^2 dropoff was too steep and reducing the size of fighters by 50-100 dT, which is quite trivial for box launcher fighters, often makes existing sensors totally useless. Having a single fighter-resolution sensor is fine, but being forced to have three or four separate sensors to find small, medium and large fighters, and FACs gets annoying and expensive fast.

You mentioned that you would check and rebalance if necessary?
« Last Edit: March 17, 2020, 10:56:58 AM by SevenOfCarina »
 

Offline Ektor

  • Lieutenant
  • *******
  • E
  • Posts: 191
  • Thanked: 103 times
Re: C# Aurora v0.x Suggestions
« Reply #2081 on: March 18, 2020, 03:03:27 PM »
Some people were talking about ground combat on the Discord and one guy basically came up with the idea of "engineers" or "anti-fortification" roles, basically, it would be a weapon type put onto infantry or vehicles that would counter-act the fortification bonus of an entrenched enemy.  He was thinking more on the lines of support vehicles and engineers, whilst I though it might also represent SPGs and other types of fortification busters.

Some other people gave the idea of adding a medical type to add to formations that would reduce the number of casualties.

I found those pretty good ideas, what do you guys say?
 
The following users thanked this post: Zhatelier

Offline Hazard

  • Commodore
  • **********
  • H
  • Posts: 643
  • Thanked: 73 times
Re: C# Aurora v0.x Suggestions
« Reply #2082 on: March 18, 2020, 04:29:51 PM »
The problem with a medical unit with a saving chance is that they basically shift the combat investment, by possibly a large margin and with great difficulty to predict when and how. A medical unit saving PW infantry doesn't save you that much in shipping and minerals, but a medical unit saving an Ultra Heavy Vehicle with 4 weapon slots? That's a big chunk of resources that suddenly didn't go up in a ball of fire. And worse, for the opposing side that's a big chunk of resources they invested in bringing the UHV down that just got cancelled. UHVs ain't cheap, but they are also very tough, and difficult to destroy.

A key component of good game design is that you can predict, at least to some extent, how a given event is going to play out. A random result should not be capable of majorly impacting the course of an event, especially when you can't know what you will be up against and thus not predict what you'll be dealing with anyway. It just gets frustrating.


As for the engineering trait/component, that idea has merit to me, but I don't think Steve's going to implement it for Aurora C# 0.1. It's something for later at a minimum.
 
The following users thanked this post: Kristover

Offline Zhatelier

  • Chief Petty Officer
  • ***
  • Posts: 46
  • Thanked: 19 times
Re: C# Aurora v0.x Suggestions
« Reply #2083 on: March 18, 2020, 05:18:43 PM »
One way to implement the medical units would be another tech line for field medicine.  Say the first level (potentially one you start with) would be 1% and the tech goes up to 10%.  Casualty trickle back would be calculated by ( medical efficiency / armour level of the unit).  That way the infantry would get the full benefit of the medical unit but armoured units would benefit less.  What takes down a trooper is more likely to be of smaller calibre than something that takes out a heavy tank.  The numbers could be tweaked, but personally I wouldn't go over 25% as a max.  Another idea to add to this would be the amount of personnel that a single medical unit can service, again improvable by tech, but to that, I'm unable to give example figures at this time.
 

Offline Hazard

  • Commodore
  • **********
  • H
  • Posts: 643
  • Thanked: 73 times
Re: C# Aurora v0.x Suggestions
« Reply #2084 on: March 18, 2020, 05:47:23 PM »
This would be useful if there was a manpower mechanic attached to ground combat, but there isn't. Ground units are very much depicted by their equipment, and the manpower attached to it is utterly inconsequential. A PW(L) infantryman may be rated at 3 tons in weight/shipping, but does that mean that a 60 ton Heavy Anti Vehicle Static Unit is made up of 20 men?
 
The following users thanked this post: backstab