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

0 Members and 1 Guest are viewing this topic.

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2837
  • Thanked: 673 times
Re: C# Aurora v0.x Suggestions
« Reply #1170 on: May 07, 2019, 07:01:22 AM »
Let them add a (very minor) speed up bonus, like 1/10th their base rating, as long as it's a project in their field of specialisation. It'll encourage keeping a stable of well trained scientists on hand rather than dropping everything on that one awesome researcher, only to panic when he dies.

Yes... scientists impact research speed too much, the problem i have with it is the cost... they do it for no cost at all. In manpower or resources... this is not really realistic and a bit immersion breaking at times.
 

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: C# Aurora v0.x Suggestions
« Reply #1171 on: May 07, 2019, 09:04:15 AM »
For a more "random" experience in the research area, maybe going into a different direction might be interesting to think about - whilst keeping a "kind of deterministic" system as it is now.

I personally really, really like that individual control you have over your ship designs. It's not like in most games: Destroyer Class I, Class II, etc. But that concept doesn't transfer to the underlying technologies you have to research. They are Tech I, Tech II, etc.

In todays military, if they for example want to have a new type of fighter, they compose a list of ideas, what that fighter should be able to do. Then the underlying research begins (if that is possible and in what areas new technologies or materials would have to be researched). I imagine a similar kind of system for Aurora without the actually given limits of certain weapons, ranges, etc.: You specify what kind of ship you want to have. In a second step the game then shows you a list of needed technologies for that ship type and what research duration each part would need (the duration would of course highly depend upon what you are actually capable of and the bigger the difference to your actual state of technology is, the bigger the duration will be).
You then go back and forth between design wishes and research list until you are happy with the individual research durations (maybe you didn't like the long duration of the new armor research and toned your wishes down to a "reasonable" duration) and give permission to research the modules.

That system would enable you to
a) react to certain situations individually (like in a war you realize that your laser weapons are slighty (5000km range) to short to overwhelm a certain enemy ship type, so you give a quick research order to increase the laser range and refit your ships quickly with the new weapon type; whilst in the actual system you would have to research the next (full) step of technology - which of course would bring your range 50.000km but would also need 18 month to research instead of 3)
b) give long term research jumps a go if your political situation allows for that in peace times
c) can control technology more precisely, be a bit more in control of your research time, etc.

Again, this would be quite an overhaul - don't know if it would be worth it.
 
The following users thanked this post: Titanian

Offline chrislocke2000

  • Captain
  • **********
  • c
  • Posts: 544
  • Thanked: 39 times
Re: C# Aurora v0.x Suggestions
« Reply #1172 on: May 09, 2019, 05:41:06 PM »
Not sure if already addressed but one common problem I've had in the past with fighter fire control design is that I can often end up with an over engineered and consequently over sized beam fire control which stems from the 4x multiplier to tracking speed. It would be helpful to be able to select a fractional base tracking to speed to both align to fighter speed and also reduce the overall size of the control in the same way you can reduce base range.
 

Offline 01010100

  • Chief Petty Officer
  • ***
  • ?
  • Posts: 38
  • Thanked: 15 times
Re: C# Aurora v0.x Suggestions
« Reply #1173 on: May 13, 2019, 08:51:16 PM »
I'm not sure if these have been addressed already but I'd like to make a couple of suggestions.   

1.  Automated assignment of population governors.  I like to make dozens of small automated mining colonies and it's a bit of chore to make sure they all have proper governors at all times.    For this reason I suggest adding a dropdown box on the population screen where the player can select the desired modifier such as "Mining" or "Shipbuilding" or "Manual" for manual assignment.  Given the desired modifier a similar algorithm could run as is used for assigning ship officers.   

2.  System body modifiers.  Right now system bodies are pretty bland, either you colonize them (perhaps with terraforming) or you don't, but other than that they are basically interchangeable with each other.  The population limit introduced in C# will help differentiate system bodies but only so far.  So I suggest adding system body modifiers, basically a hidden governor but attached to the system body itself.  This would make for much more interesting strategic choices - do I put my shipyards next to the alien system at a planet where it gets +50% shipbuilding rate or do I put them in a more safe location in the middle of my empire but at an efficiency cost because there I've only got +20% shipbuilding rate? - at low effort since presumably the same code which is already in place for creating civilian administrators could be used.   

3.  Remove standing orders and conditional orders and introduce "automatic orders".  Define an automatic order as follows: let TS be the set of possible tasks for standing orders, let CC be the set of possible conditions for conditional orders and let TC be the set of possible tasks for conditional orders, then let an automatic order be a conditional order with possible conditions "CC u true" and possible tasks "TS u TC" where u is set union.  An automatic order is hence of the form "IF condition THEN DO task" where standing orders can be modeled with "IF true THEN DO task. " This way we're not restricted to 2 standing orders and 2 conditional orders, we could have 4 standing orders if we use 4 automatic orders with "true" as the condition or we could have 4 conditional orders by using 4 automatic orders with something other than "true" as the condition or we could mix and match as we want.  It would also be conceptually "cleaner" (and probably easier to maintain code for) by having only 1 type of automatic order that comprises and extends both types we have now, as well as make possible future extensions of the system easier such as letting the player use any number of automatic orders rather than the hardcoded 4 (2 standing + 2 conditional) that we have now.   

3b.  Let taskgroups take automatic/conditional orders from higher up the hierarchy.  For example I like to set all my exploration-type taskgroups (grav survey, geo survey, . . . ) to refuel at 40% fuel.  It would be easier if I could set that order once at the appropriate level in the hierarchy (the command which includes all my exploration taskgroups) rather than for every taskgroup separately, every taskgroup would check its own automatic/conditional orders and then also check up the hierarchy.   

4 Empire-wide research. Right now research is tied to the population so I put all my research labs in one population so as not to have to bother with research being split.  I suggest making the research tab its own top-level window.  The screen could remain as it is, with the number of available labs being the sum over all populations.  That way research labs can be spread out whilst still having all research in a single screen. 
« Last Edit: May 13, 2019, 09:17:24 PM by 01010100 »
 
The following users thanked this post: Barkhorn, Titanian

Offline Jovus

  • Lt. Commander
  • ********
  • J
  • Posts: 220
  • Thanked: 81 times
Re: C# Aurora v0.x Suggestions
« Reply #1174 on: May 18, 2019, 06:38:15 PM »
Would be really cool if in the Empire creation process, when you hand an Empire over to be run by an NPR, if you had an option to specify the kind of AI that would be in charge of its grand strategy and civilizational scope and goals. Something like "suicidally aggressive" or "citadel" or "exploratory" or "xenophilic" or whatever the different AI settings you have in place are. This would let people set up various RP situations (like multi-faction starts) with some assurance that the NPR would develop according to a paradigm they might expect for roleplay purposes.

Should default to random, though, or whatever the current default behaviour is.
 

Offline Hazard

  • Commodore
  • **********
  • H
  • Posts: 643
  • Thanked: 73 times
Re: C# Aurora v0.x Suggestions
« Reply #1175 on: May 19, 2019, 07:51:30 AM »
That's already covered by the various government modifiers, which inform the types of actions a given NPR is likely to consider.

Admittedly, it's a little opaque.
 

Offline Jarhead0331

  • Sub-Lieutenant
  • ******
  • J
  • Posts: 126
  • Thanked: 45 times
Re: C# Aurora v0.x Suggestions
« Reply #1176 on: May 19, 2019, 05:43:38 PM »
Is it possible to add something like this for ship design? This is from the game Rule the Waves. Something like this in Aurora would really be awesome to see what your design looks like...



 

Offline Jovus

  • Lt. Commander
  • ********
  • J
  • Posts: 220
  • Thanked: 81 times
Re: C# Aurora v0.x Suggestions
« Reply #1177 on: May 19, 2019, 09:31:49 PM »
Is it possible to add something like this for ship design? This is from the game Rule the Waves. Something like this in Aurora would really be awesome to see what your design looks like...

Can you be more specific? Are you looking for mechanics, or UI, or something else?
 

Offline xenoscepter

  • Vice Admiral
  • **********
  • Posts: 1157
  • Thanked: 318 times
Re: C# Aurora v0.x Suggestions
« Reply #1178 on: May 19, 2019, 10:09:25 PM »
LINK TO SEPARATE POST HERE ======> http://aurora2.pentarch.org/index.php?topic=10410.0


I like big letters, they're easier to read.  :P

How about making Cloaking Devices a checkbox on the Class Design? Checking it would dedicate a percentage of the ship's tonnage to the Cloak.


The Techs would then be:


Cloaking Efficiency = Same as before.

Mount Efficiency = Reduces the percentage of a ship's tonnage required for a cloaking device.

Minimum Mount = Minimum Tonnage that a Cloak can be mounted on.

Maximum Mount = Maximum Tonnage a Cloak can be mounted on.


Additionally, although this might cause too much bloat, techs could dictate the maximum and minimum size of the device itself. I.E. a 10% Cloak on a 1,000 Ton ship would weight 100 Tons, thus requiring the 100 Ton Minimum Device Size Tech. While the same 10% Cloak on a 100,000 Ton ship would require the 10,000 Ton Maximum Device Size Tech.


So you would have:



Cloaking Efficiency = Same as before.

Mount Efficiency = Reduces the percentage of a ship's tonnage required for a cloaking device.

Minimum Mount = Minimum Tonnage that a Cloak can be mounted on.

Maximum Mount = Maximum Tonnage a Cloak can be mounted on.

Minimum Device Size = Minimum Size of a Cloaking Device in HS.

Maximum Device Size = Maximum Size of a Cloaking Device in HS.


Alternatively Cloaking Efficiency Tech could be a Ratio of Mount Efficiency instead of a flat percentage.So a 1,000 Ton Ship with a 25% Mount Efficiency Tech and a Cloaking Efficiency of 2 to 1 would have a 250-Ton Cloaking Device operating at 50% Efficiency, due to the 250-Ton Cloaking Device being able to completely Cloak up to 500-Tons worth ship, resulting in a 500 Ton TCS. However the same 1,000 Ton ship with a 2 to 1 Cloaking Efficiency and a 10% Mounting Efficiency Tech would be operating a 100-Ton Cloaking Device capable of cloaking only 200-Tons worth of ship, equivalent to an 80% Cloak, or an 800 Ton TCS. A 100,000 Ton ship could do exactly the same, but would simply cost 10x more to do it.

I might suggest a hard cap on efficiency if invisibility is not desirable, maybe 1% or 10% or something, however:

To achieve a TCS of 0 a 1,000 ton ship could use a 10% Mounting Efficiency Tech and a 10 to 1 Cloaking Efficiency Tech. Since Mounting Efficiency would need to start high, like say 75% or more, then drop down; while Cloaking Efficiency would ideally start low at 1 to 1, this would mean such a ship would be at the top [or very nearly the top] of the Tech Tree to do so. Meanwhile a ship of the same tonnage with a 25% Mounting Efficiency and 4 to 1 Cloaking Efficiency Tech could also become invisible, but at a cost of a quarter of all available tonnage. As a matter of fact, tonnage doesn't make a lot of difference under this system, but 1,000 and 100,000 were easy numbers to work with.
  :P


So this would be the tech tree with all of it:


Cloaking Efficiency = Ratio of the Ship's HS Cloaked per HS of the Cloaking Device mounted on the Ship.

Mount Efficiency = Reduces the percentage of a ship's tonnage required for a cloaking device.

Minimum Mount = Minimum Tonnage that a Cloak can be mounted on.

Maximum Mount = Maximum Tonnage a Cloak can be mounted on.

Minimum Device Size = Minimum Size of a Cloaking Device in HS.

Maximum Device Size = Maximum Size of a Cloaking Device in HS.


EDIT:


Addendum, the Techs suggested would scale as follows:


Cloaking Efficiency = Starts at 1 to 1, scales up from there, maybe with 10 to 1 at max or 100 to one if you're feeling a lil' looney. :)

Mount Efficiency = Starts low, maybe 75% or even 80%, then scales down to maybe 10% at max or 1% if you're feeling even loonier. ;D

Minimum Mount = Starts out somewhere between 7,500 to 5,000 or something medium like that, scales down to fighter sized, maybe even Cloaked Missiles! :o

Maximum Mount = Starts out at something modest (again), like between 75,000 and 50,000 or whatever, scales up from there; possibly could end with a No Limit Tech for billion ton invisible Orbital Habitat Super Dreadnoughts or something equally stupid.

Minimum Device Size = Same as Minimum Mount, scales accordingly.

Maximum Device Size = Same as Maximum Mount, scales accordingly.
« Last Edit: May 19, 2019, 10:31:35 PM by xenoscepter »
 

Offline littleWolf

  • Warrant Officer, Class 1
  • *****
  • l
  • Posts: 76
  • Thanked: 13 times
Re: C# Aurora v0.x Suggestions
« Reply #1179 on: May 20, 2019, 05:09:15 AM »
I think about huge "Space Ark" mothership  for "nomads" playstyle, and have 2 suggestions (if possible):

1. Add  "refit" options for Orbital Habitat structures
2. Add factories/shipyards/resear?h modules for Orbital Habitats design.






 

Offline Jovus

  • Lt. Commander
  • ********
  • J
  • Posts: 220
  • Thanked: 81 times
Re: C# Aurora v0.x Suggestions
« Reply #1180 on: May 20, 2019, 07:38:06 AM »
An idea:

To make area defense more viable (especially with the removal of laser warheads, which was the only practical use of it before), make it avoid range drop-off penalties. The way I'd see this most naturally happen is if you can flag BFCs for PD during design; this would give them flat accuracy across an envelope defined by the range parameter, but restrict said range and only be useful to fire at missiles.
 

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2837
  • Thanked: 673 times
Re: C# Aurora v0.x Suggestions
« Reply #1181 on: May 20, 2019, 08:41:26 AM »
An idea:

To make area defense more viable (especially with the removal of laser warheads, which was the only practical use of it before), make it avoid range drop-off penalties. The way I'd see this most naturally happen is if you can flag BFCs for PD during design; this would give them flat accuracy across an envelope defined by the range parameter, but restrict said range and only be useful to fire at missiles.

I think it would be much easier if a weapon could just fire at range AND final fire as well if it is able to recharge it weapons in time for the last 5s. This would make lasers able to shoot two or three times depending on the missile speed and laser technology.

Both railguns and gauss weapons should get some accuracy benefit from the range of their respective guns due to firing multiple shots a turn. The longer the range the sooner the weapon can engage. This bonus (or penalty) should be based on the distance the missile travel during the last 5s and the range of these weapons. A laser or other larger weapon have such long range they don't get any negative or full benefit for range.

CWIS system should be much smaller and cheaper to compensate and in my opinion much cheaper since they are meant for self defence only and is a small self contained system. The Gauss weapon in this system should probably be allot smaller since they only shoot very short ranges. CWIS systems are almost never worth putting on anything but commercial designs which I think is a pity.
 

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11667
  • Thanked: 20439 times
Re: C# Aurora v0.x Suggestions
« Reply #1182 on: May 20, 2019, 03:34:40 PM »
An idea:

To make area defense more viable (especially with the removal of laser warheads, which was the only practical use of it before), make it avoid range drop-off penalties. The way I'd see this most naturally happen is if you can flag BFCs for PD during design; this would give them flat accuracy across an envelope defined by the range parameter, but restrict said range and only be useful to fire at missiles.

I don't really like exception rules. If I can accurately hit a missile at long range, why can't I hit a larger, slower ship?
 

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2837
  • Thanked: 673 times
Re: C# Aurora v0.x Suggestions
« Reply #1183 on: May 20, 2019, 04:47:40 PM »
An idea:

To make area defense more viable (especially with the removal of laser warheads, which was the only practical use of it before), make it avoid range drop-off penalties. The way I'd see this most naturally happen is if you can flag BFCs for PD during design; this would give them flat accuracy across an envelope defined by the range parameter, but restrict said range and only be useful to fire at missiles.

I don't really like exception rules. If I can accurately hit a missile at long range, why can't I hit a larger, slower ship?

Obviously both size and speed should matter for targeting purposes as could even some manoeuvring value such as agility that we have on missiles effect the hit chance.

In real life it is nearly impossible to hit things at very large distances that is both small and travel fast AND have the ability to dodge or make combat manoeuvres. That is why you either need a guided projectile like a missile at range and huge volumes of fast firing bullets or a laser at decent distance since that travels so fast.

At least I hope that you at some time come back to this thing about Beam, Missile and agility stuff in the future... I also would love to see that size matters in terms of hit chance. I would also love something closer to your ideas in Newtonian Aurora in terms of damage with armour and shields. But of course for another time.
 

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 #1184 on: May 21, 2019, 07:52:19 AM »
Is it possible to add something like this for ship design? This is from the game Rule the Waves. Something like this in Aurora would really be awesome to see what your design looks like...

Are you aware that Rule the Waves 2 came out Friday?  It's got aircraft now and the tech tree extends to 1950 IIRC. 

John