Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - alex_brunius

Pages: [1]
C# Aurora / Re: Replacing PDCs
« on: September 19, 2017, 04:06:18 AM »
My main concern here is that this will greatly change the timespans involved and troop needs for ground invasions. Most beam weapons fire every 5-30 seconds and have infinite ammo, while ground combat updates on the 5 day cycle, so after around 86400 such 5 second pulses.

No matter how much the orbital bombardment hitchance is reduced by ground unit concealment any sufficiently large beam fleet will be able to precision wipe out 100% of the defending ground units in very short order, meaning all ground units any attacker needs will be for garrisoning purposes.

Real campaigns like Vietnam, Afghanistan and Iraq have taught us that no matter how much superior firepower you have, that is not how reality works. Boots on the ground are always a must.

What I propose to resolve this is the following balance:

  • New beam FC component added "Orbital bombardment Firecontrol", which enables aiming and firing beams on ground units
  • New techline added "Orbital bombardment sensors & firecontrol" that gradually increase Orbital bombardment precision stat
  • Mechanics: Only ground units with heavy weapons for firing on space ships can be 100% destroyed by orbital bombardment, but when destroyed by bombardment their cadre survives ( making them faster to rebuild )
  • Mechanics: Maximum damage possible to inflict on all other ground units is based on a comparison between orbital bombardment and concealment stats. High bombardment vs low concealment might result in being able to reduce unit morale and readiness by 80% while the reverse situation could reduce them by just say 20%. Equal tech level results in for example 50% damage cap

This should ensure that bombardment can neutralize ground-space weapons, as well as support ground assaults, but not remove the need of ground assaults entirely.

If you want to make a more accurate and detailed model then the land surface area as well as vegetation & animal life (biosphere) and tectonics could influence how easy it is to conceal units. Hit chance reductions could also help ground-space weapons inflict disproportional damage on bombarding warships before they can be destroyed/knocked out.
The following users thanked this post: Gyrfalcon, DIT_grue

C# Aurora / Re: C# Aurora Changes Discussion
« on: July 10, 2017, 02:10:59 AM »
Quote from:    Steve Walmsley
As missiles (for now anyway), don't have thermal reduction or an option to travel below maximum speed, their thermal signature is equal to the power of their engines. Combined with the changes to passive detection, this means that missiles in C# Aurora will probably be detected by thermal sensors at much greater distances than in VB6 Aurora.

Hmm. I wonder if you could make an effective passively guided AMM after this change?

With all the changes to Thermal and EM emissions as well as these being serious ways to guide missiles now it really feels like we need some way for Missile Fire Controls to fire on calculated interception points of target and relying on missiles picking up their emissions once close enough.

Doing that math and geometry by hand every time while possible is going to be pretty frustrating.

This way of playing could also could support making missile design even more interesting and deep. Maybe a 0.1 MSP component to enable a search pattern or loitering if missiles find nothing at their destination as well (continuing until out of fuel), or Friendly Fire risk for passively guided missiles unless you equip a 0.1 MSP IFF component to missiles.
The following users thanked this post: Titanian, superstrijder15

C# Aurora / Re: Aurora C# Screenshots
« on: July 06, 2017, 04:49:38 AM »
It's not that counter intuitive. Turret armour is extra hardening of the turret, armour in Aurora is all ablative anyway.

It's counter intuitive that the turrets which are external and outside of any armor belt, citadel or protection on all real warships is put underneath it in Aurora.

It's counter intuitive that the same identical turret design when I put it on my battleship with 15+ armor layers is super hard to knock out while if I put it on my unarmored scout it is super easy to knock out.

I realize that it's a simplification, but I still would love to see some more detail with separate ablative armor boxes for turrets, for outer hull and for inner thicker armored citadel ( I don't care about my crew quarters or fuel storage, but might want the engine, powerplants and ammunition under extra layers of ablative armor ).
The following users thanked this post: MagusXIX

One can probably use SM to make new commanders, then rename them and maybe even give them the same attributes, but this would be a lot simpler.

AFAIK you sadly can't SM commander attributes :(
The following users thanked this post: superstrijder15

Regarding NPR Tactics what I feel is important is to give the AI a basic sense of tonnage/threat and not mindlessly throw ships away.

This is done by estimating a few things:

- Technology of an enemy can be estimated by comparing the speed of enemy ships & missiles observed to those of your own.

- Estimating how offensive your ships are based on previous encounters weight of missile/beam fire or salvage results ( scoring their threat from for example 0.2 to 3.0 based on how much tonnage they have dedicated to weapon systems and how deadly the salvo fire is ).

- Total tonnage of an enemy fleet can be estimated by knowledge of their known ships and amount ( If the NPR have observed you having a total of five 10k ton ships and fifteen 2k ton ships previously it will estimate your fleets to be worth 16k ton "threat" for each 10k ton ship it observe even before it's sensors can detect a 2k ton signature ).

A practical example:

The AI is observing an enemy fleet made up of eight 20k ton warships approaching in one of it's systems and is tracking it on resolution 160 actives from a long range scout.

Based on a speed advantage of 15% the fleet is estimated to be 1 TL above the AI and as such is given a x1.15 multiplier in perceived "threat". Based on previous encounters the fleet has been observed to be fairly balanced with a bit of offensive focus, so it's given a x1.3 multiplier in perceived "threat". Based on a total of known enemy ships  (108x 4k ton screens, 16x 20k ton warships and 12x 12k ton warships), combined with the fact that the actives can detect any warships larger then 8k ton in the fleet, the fleet approaching is estimated to consist of 8x 20k ton warships and 37x 4k ton screens (160k ton observed / 464k known tonnage that should be observable = fleet is estimated to be composed of 34.5% of the enemy empires warships ). This gives the enemy fleet an estimated calculated tonnage of 308k tons, which is multiplied by x1.15 and x1.3 for technology and offensive firepower. The AI NPR thus judges that it will need to amass at least 460k tons of own warships in a single fleet to be able to meet the threat. This could further be multiplied by the inverse of the racial aggressiveness scoring, such that an aggressive/reckless race can attack with less and a defensive race will want more just to be safe.

If the AI can meet or exceed the fleet size needed (without leaving colonies without defense), it tries to gather the fleet and engage. If not it tries to get as close as it can and defend either the next jump point (if possible to beat the enemy fleet to it), or the closest / likely targeted colony the enemy fleet is approaching.
The following users thanked this post: lordcirth

Aurora Suggestions / Re: Considering Changes to Terraforming
« on: January 04, 2017, 03:35:08 AM »
This may be an uninformed question.  However, if small planetary bodies (e.g., moons of sufficient size) are faster to terraform than large planetary bodies (e.g., a planet like Mars), then why would the player bother terraforming large planetary bodies short of minerals?

Is there a correlation between the size of the planetary body and mineral generation or accessibility?

Pretty sure larger body = higher chance of more minerals in 7.1 Aurora

If there a maximum population that a planetary body can hold based on size?

Not in 7.1 Aurora.

But I think you make an excellent point.

What if each body had a "population capacity" which is based on available surface area - hydrosphere coverage. Any population above this would basically count as requiring colony cost 1 infrastructure to not have population growth halt or turn negative.

This would make it worth it to terraform larger bodies I think.

Another related thing I posted previously in suggestions a few years ago is that it would make sense if the population capacity would not reach max until you reached optimal conditions. Right now there is no point in keeping terraforming temperature/oxygen once you crossed the absolute minimum required point, which kind of doesn't make sense... ( in reality each person have a different tolerance and some areas of the planet would be warmer/cooler higher/lower oxygen to suit your needs ).

What would be really cool is if when you reached the minimum tolerance, "population capacity" started growing from 0, linearly up towards the maximum which is achieved when oxygen, temperature and such reach the optimal value.
The following users thanked this post: Demonides

C# Aurora / Re: C# Aurora Changes Discussion
« on: December 19, 2016, 06:27:35 AM »
Restricted fuel would not be too bad in a classic Sol start with no other NPRs on Earth. However I found in v6.43 if there are NPRs on Earth with the player race then while you can beat them to the first jump, to beat them the second is very difficult unless you sink all your tech points into fuel economy techs. Additionally the NPR exploration ships keep going and unless they run into something unpleasant youi can not catch them.

Couldn't there be some simple range limit at least in place to keep NPRs within reasonable ranges? For example NPRs are not allowed to enter JPs further away then X% of their max range from closest friendly colony? ( X being around 30-50% ).
The following users thanked this post: palu

I wouldn't use something like this in any of my games. To exploity and to much micro design/missiles needed for me.
The following users thanked this post: Knuckles2095

C# Aurora / Re: C# Aurora Changes Discussion
« on: October 21, 2016, 02:23:47 AM »
Just for simplicity. It would be extra work without extra game play if players had to know the tonnage limit for every different system body. The same applies to terraforming (at the moment anyway) with the size of the body not affecting the amount of atmosphere required.
The math doesn't really work that way.  It's a lot more complicated, depending on the nature of your launch system.  I'd suspect that the infrastructure is going to dominate in most of Aurora, not the physical payload of the shuttles themselves.

Alot of stuff in Aurora have math that "doesn't really work that way" in reality  ::)

Even with the TN technobabble Aurora is not really modelling economy of scale except for warship armor for example. And I'm thankful because it would be a pain to calculate and estimate for example factory output or infrastructure needs if they used a non-linear formulas instead.

My point was that if shuttles are worth the effort of adding they should be a meaningful constraint, and as such having gravity impact their efficiency in a linear way ends up closer to reality then it having zero impact does.

To be honest I feel that Steve is missing a big opportunity in Aurora to have the planets feel unique and special when he is hesitating to use their gravity, surface area and other properties in as much of the game mechanics as possible.

I think it would help alot to make the game more immersive and tell interesting stories if you didn't just terraform planet #20 in a long row of planets that in game mechanics feel identical to eachother until it also can sustain infinite population, but if you actually had to spend 5 times as long time to terraform the planet due to it's larger surface area, and in return it could sustain 4 billion instead of the 300 million the smaller moon can sustain, but as a tradeoff the large size and gravity put extra requirements on your shuttle needs.
( just example numbers )

I'm sure there are many other areas and game mechanics where the same concept could be expanded into like:
  • Planets with larger surface areas and larger biospheres could slow down ground combat resolution ( harsh fighting for years on the huge planet with endless jungles )
  • On low gravity bodies assembling PDCs might be much easier
  • A large amount of water/hydrosphere might reduce the surface area you can live on without infrastructure
  • Certain planets could have other unique traits or economical bonuses ( similar to the research anomalies )

The following users thanked this post: hiphop38, palu

C# Aurora / Re: C# Aurora Changes Discussion
« on: October 20, 2016, 10:58:43 AM »
Well, why don't we just factor in the gravity of the body in question when considering what we're trying to do? It's kind of ridiculous to treat a super-earth with 3g the same way as a 10-km asteroid with 0.00005g. Why not just impose a upper gravity limit on where you can use PDC hangars and restrict them to small bodes with microgravity that doesn't disrupt the aether enough to disable engines? You can still have your giant PDC hangers, you're just going to have to build them into asteroids instead of on earthlike planets.

This would be interesting to do for shuttles/ lift capacity too, so with ×2 gravity you need twice as many shuttles  ( they each manage half the cargo to orbit. )
The following users thanked this post: palu

C# Aurora / Re: C# Aurora Changes Discussion
« on: October 03, 2016, 07:04:56 AM »
I'll create some carrier-specific rules for the rate of refuel/reload.

Could be interesting to have a new hangar component for modelling refuel/reload/recover/launching so you have the tradeoff between fast turnarounds and high storage capacity when designing your Carriers.

Edit: If a separate system for Carriers is implemented it should probably be limited based on the Carrier output so you can't just get around it by making many smaller fighters (with less fuel & ammo each ). Refueling 8 x 125 ton fighters should logically take at least the same time to refuel as a single 1000 ton FAC with 8 times as much fuel in the same Carrier.
The following users thanked this post: 83athom

Mechanics / Re: Change Log for v7.2 Discussion
« on: February 14, 2016, 06:27:24 PM »
While Titans have a nice cool factor going for them it's not my first pick for making ground combat fun and engaging, and as others pointed out Titans might even work better as designable "land ships". The most important thing to improve ground combat IMHO is to integrate it well with space combat and with logistics so the game feels connected and you design and plan both tactics and strategy where they can mutually support each other.

Here is what I would like to see if ground combat is the area you want to improve:
  • Mechanics allowing all space beam weapons to engage units on the ground on planets with atmospheres, but very inefficiently ( maybe -95% accuracy debuff for earth thickness atmosphere ). Units get some new stuff to shoot back, see points below.
  • Barrel life, all beam weapons have a base barrel life of 100 shots after which they are destroyed by combat damage automatically ( needs to be repaired by MSP/Damage control ), and a new technology is added which makes the weapon bigger in exchange for longer barrel life. This is to not make un-opposed beam fleets able to wipe out big ground defences, combined with above a basic beam weapon can only fire 5 hits on average against ground targets before it's destroyed.
  • Beam Fire Controls get bombardment targeting technology so you can design them for shooting at stuff on the ground helping them hit a little bit better trading size and cost
  • Light AAA/AS battalions - shoots Gauss PD at enemy ships, fighters or stuff within 10kkm range ( no or less accuracy debuff since ships make a nice silhouettes ), automatic final fire defense
  • Heavy AAA/AS battalions - shoots Laser at enemy ships in range randomly, fighters or stuff using your biggest designable laser ( no or less accuracy debuff since ships make a nice silhouettes )
  • SAM/SSM battalions - Can load and shoot your favorite size 1 AMMs at whatever you got lock on, appears similar to PDCs as a single unit per planet with as many tubes as you got battalions and has your missile reload rate.
  • Fighters get a module (starting at 100ton and made smaller by tech) allowing them to fly inside the atmosphere ( fight with all weapons without the accuracy debuff )
  • Fighters get a damage buff vs Titans and become a great "Anti titan" weapon
  • All ground units hit by fighters fire back in self defense and have 10% chance to inflict 1 point of damage per attack run
  • Ammo/Supplies for ground units. All ground units need ammo & supplies produced so you can't fight forever without supply-lines open. If the ammo is not stored in PDC it appears as a valid target for enemy space sensors and can be targeted and destroyed, but ammo carried by units is dispersed so can't be hit.
  • Sensible rules for transport of ground units so Light/Garrisons can be transported easily, but heavy assault needs much more space and time to load/unload for their heavy stuff.
  • Ability to transport all "light" infantry units on board your warships ( risking overloading their life support unless they have spare berths ) for emergency evacuations or un-opposed invasions.
The following users thanked this post: Spaceman Spiff

Mechanics / Re: Shipyards able to produce multiple designs?
« on: January 18, 2015, 11:41:01 AM »
From the wiki:
( Seemed to work fine when I tested in game ).

It is possible that other ship classes can be built in the same shipyard without retooling. For a second class to qualify as eligible for construction, it must be possible to refit a ship of the primary class to that class for less than 20% of the primary ship class cost. See Refitting below.

Refitting a ship means turning it into a ship of a different class. Whether that makes sense depends on the Refit cost, as shown in the field on the right. That cost depends on the actual components that have to be changed, plus an extra Refit overhead cost, plus 1/10th of size difference. For example, updating a 4,000-ton "Broadsword Mk II" destroyer to "Broadsword Mk II-B" by installing just a few modernized sensors and an additional fuel tank, for a total cost of 25% of original build points might be worth the effort, but turning it into a 7,000-ton light cruiser would cost more than scrapping the destroyer and building a new cruiser.

You can look up the actual refitting cost in the design window, under the "DAC/Rank/Info" tab. To estimate whether it is worth updating a ship class, look at the component breakdown in the Component summary tab.
The following users thanked this post: Tor Cha

Pages: [1]