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] 2
1
C# Aurora / Re: Research changes planned?
« on: January 15, 2018, 04:21:45 AM »
Diminishing returns and research penalties would just cause there to be a tipping point where making more labs isn't worth it. This is, admittedly, exactly the point... However, it wouldn't "increase decision making", because the decision you'd make there is a no brainer. If it's more efficient to research 10 things at once with 10 labs each, than it is to research 1 thing with 100 labs, you would research the 10 things at once instead.

I think your missing the real trade-off here though.

What your decision is all about is how quickly you can progress down a specific key field, for example engines.

Sure putting your 100 labs at 100 different things might be optimal from a making the most out of the RP standpoint, but it still means your progressing 20 times slower in the field of engines then if you put 40 labs on that ( with diminishing returns for example halving your speed ).

It also requires 100 different scientists, which you might not have available, and it also means you get less out of the higher scientist bonuses.


How important each key field will be for you ofcourse depends ( with engines most of the time being the top priority ) on a sliding scale, and that's where the diminishing returns come in. It will shift the focus so that it's a bit more worth it to spread out your labs instead of the current no brainer approach of always putting as many labs as possible and go through your list of priorities one at a time ( with a few 1 lab projects to train new scientists ). But I still have no doubt that there would be some situations where you want the max labs a scientist can handle to rush techs ( at less efficiency ), and finish them ASAP.

With diminishing returns there is a point to assign 3-5 labs to projects even if you can assign 20.
The following users thanked this post: King-Salomon

2
C# Aurora / Re: C# Aurora Changes Discussion
« on: January 08, 2018, 07:56:56 AM »
There will be some form of logistic units. I've been holding off on exactly how they work because of issues around tracking supply point usage but it finally struck me how to do it. Each logistic unit (probably static base type) will use up a set amount of maintenance supply points (MSP) during creation. When combat takes place, each side will use up a certain amount of MSP (to be determined) during each combat phase, based on that type of units engaged.

Lets assume that each logistic unit includes 100 MSP. If combat consumes 230 MSP that would use up two logistic units with a 30% chance of a third unit being consumed. Over time, that will work out fine with no record-keeping needed. If no logistic units remain then combat will become far less effective (major penalty to hit, or perhaps no offensive fire at all). This will give an incentive to land a number of logistic units with the initial invasion, plus the potential for resupply runs against hostile defences.

Something I would like to see when it comes to logistics is variable rates of consumption.

Real Grounds units are not going to consume at 100% their full rate until they have 0 left and then go from 100% efficiency to X% (very low) efficiency overnight / in a single update tick.

Ideally they should see a gradual reduction since when supply go below say X% of max capacity they can carry with them and no deliveries are in sight they will start to conserve their remaining stock to last longer. This means you can start to see an upcoming supply shortage well in advance and preempt it, and at first the penalty will not be so big, units will just consume a bit less and fight a slight bit worse. But if left ignored it will grow worse and worse, similar to how dept can ruin your economy gradually if ignored or how life support failures gradually can spiral out of control.
The following users thanked this post: Scandinavian

3
C# Aurora / Re: C# Aurora Changes Discussion
« on: December 26, 2017, 03:58:59 PM »
But it's better than developing a niche game for a small audience. As far as making money  goes.

Depends. That's how minecraft started out...

Very few indie games or single man games aiming for a "broad-appeal game for a wide audience" get anywhere at all. They just become very bad clones of what the AAA devs already are doing 100 times better with 500 times more resources. To succeed with an indie game you need to make something unique ( like minecraft or Aurora ).
The following users thanked this post: MagusXIX

4
Aurora Suggestions / Re: Bringing Back Mothballing
« on: November 13, 2017, 06:20:40 AM »
What the heck is mothballing?
I've done a quick search but Google had no satisfactory answer.

https://en.wikipedia.org/wiki/Mothballing

( Aircraft boneyard and Reserve fleet are relevant entries to this use of the word ).
The following users thanked this post: Seolferwulf

5
C# Aurora / Re: Replacing PDCs
« on: October 26, 2017, 08:35:25 AM »
For C# Aurora, a ground 'unit' will be an individual soldier or vehicle, while a group of units will be a 'formation', although you will be able to name formations as companies, battalions, etc..

...

Each individual unit within a formation will fortify separately, so there is no problem fortifying a formation that includes infantry, static and vehicles.

In terms of combat mechanics, units will fire at units, using the chance to hit...

Is it really wise to use individual soldiers from a performance & database size perspective?

If numbers are similar to current we could be looking at upwards to 50000 soldiers if not more per side that all need to have individual fortification, individual hit chance / fire rolls / targeting and so on.

I don't think you would lose out much by reducing the scale to squads of 10 soldiers or companies of 100 soldiers which are modeled as the smallest infantry "unit", at least for purposes of calculation ( even if you can track individual casualties in more detail if you want ).


Something else which isn't totally clear is how vehicle crew will be handled ( if at all ).
The following users thanked this post: obsidian_green

6
C# Aurora / Re: Replacing PDCs
« on: October 25, 2017, 10:39:22 AM »
Apologies if this has already been covered.   I usually build PDC's at new colonies as a quick and easy way to keep unrest under control.   If I remember correctly, ground troops do  not have a Population Protection Value so they can only reduce, not prevent unrest.  If PDC's go away, will ground forces get some sort of PPV?

Since PPV seems to represent the ability to defend against enemy spaceships it would make sense to give ground forces that can fire at orbiting spaceships the same PPV that identical firepower from other sources ( like PDC or a space station ) would have.
The following users thanked this post: DIT_grue

7
C# Aurora / Re: Replacing PDCs
« on: October 20, 2017, 05:46:16 AM »
On the other hand Marski, if you are tossing ground detonation nukes around in such numbers that the fireballs overlap you can be fairly confident that whatever formation existed there does so no longer.

It quickly becomes a problem of math and economics...

Earth has a total surface land area of ~150 million km^2.

Submarine launched nukes are often considered the upper border of what would be a "tactical" nuke, so let's take one of the most common (W-76) in the US/UK arsenal. It has a fireball radius of 500 meters when detonating on the ground meaning the fireball covers an area of 0.79 km^2.
( Source: https://nuclearsecrecy.com/nukemap/ )

You would need to drop around 200 million such nukes to cover the entire land surface of the Earth and ensure you wipe out all hiding & dug in spread out infantry.

Even if you use an airburst and the larger air blast radius ( resulting in universal injuries and widespread fatalities for exposed & unprotected, but most dug in infantry probably survives ) we get 33.5km^2 area covered and around 5 million warheads needed to cover the surface of the earth.


See the problem?
The following users thanked this post: 83athom

8
C# Aurora / Re: Replacing PDCs
« on: October 19, 2017, 07:41:40 AM »
Actually, if you are tossing around lasers with similar energy delivery profiles as a nukes you are basically nuking the planet anyway. You just don't use an actual nuclear warhead to make the kiloton and up explosions happen.

This means you can actually destroy a defending force to the last with orbital laser bombardment alone, just keep in mind the collateral. Because, you know, kiloton range explosions and up are pretty bad at only hitting targets smaller than a city. Usually everything around it also dies.

This assumes that your nuke can deliver 100% of it's energy directly into the ship ( like a laser would ), and that your laser suffers zero energy reduction from a planets atmosphere on it's way down towards the target ( like a nuke would ).

If nukes in space deliver for example just 1% of their energy into the ship ( proximity hit around ~1 ship length away ) while a laser delivers 100%, and if the atmosphere reduce laser energy by say 90%, then what we are looking at is a laser impact with same damage vs space ships transferring 1000 times less energy delivered into a ground target then a nuke.

( At also assume that the energy from shockwave and heat in the nuke is as damaging as the energy from a beam weapon ).



Regardless of what values you use I think it's safe to say that beams deliver several times less total energy, especially when firing at a planetary surface target, then nukes even if they do the same damage against a spaceship.
The following users thanked this post: 83athom

9
C# Aurora / Re: Replacing PDCs
« on: October 03, 2017, 05:18:32 AM »
Agree on the re-designation of combat walker. Some type of super-heavy vehicle designation makes sense.

Isn't walker / vehicle distinction something that could be a design option instead?

Vehicles would be superior in flat terrain and have better max speed, while walkers perform better in rough terrain giving you a more consistent speed. Then the very large vehicles/walkers both carry 3 component slots regardless of method of propulsion.

This would also allow you to reduce complexity a bit since ARM level for Vehicles & Walker types overlap.

Something like this (instead of the 7 you proposed with overlapping ARM levels):

Scout Vehicle/Walker - ARM 2 - 2 slots ( maybe even 1 slot? )
Light Vehicle/Walker - ARM 4 - 2 slots
Medium Vehicle/Walker - ARM 6 - 2 slots
Heavy Vehicle/Walker - ARM 9 - 3 slots
Super-Heavy Vehicle/Walker - ARM 12 - 3 slots

This also allows you to make a total of 10 different vehicles+walker variants.


Transport will be either infantry or vehicle (inc aircraft). In this case I am assuming that 'ground-based' aircraft are more like armoured helicopters (Mi-24) than high-flying jets (mainly because in many cases there would be no atmosphere anyway). Infantry transport will be the existing troop transport bays and combat drop modules. I will add vehicle equivalents.

It would make sense to have a shared bay for all vehicles/walkers/aircraft yeah, they require pretty similar bulk storage for transport I would say. In fact I dislike all the splitting up of "cargo" into special roles going on in Aurora 4x. Why not just have a single Cargo bay that I can put whatever I want in, be it maintenance supplies, vehicles, building parts or minerals? Or maybe 2 types, pressurized and unpressurized.

Looking at current armies they airlift in everything they need from infrastructure to tanks and troops using pretty much the same ( or very similar ) bulk cargo planes.

A few more things to think about surrounding aircraft implementation. Can they go in Hangars? Do they really need drop pods/modules? How would they interact with space based fighters? ( Maybe they get attack bonus vs space based fighters doing ground support role, and space based fighters can provide ground support without needing "Orbital Fire Support Controller" + be hit by AA? )


Ground combat will now take place in the same time frame as ship combat, with each unit firing at specified intervals (except that time won't slow for ground combat - it will instead run multiple cycles depending on turn length). It will still take a while for ground combat though as hit chances will be very low.

Please keep in mind that real war is 99.9% waiting and 0.1% of terror when doing firing times. It would be sweet to have epic campaigns stretching for months or years.

Could intensity maybe be scaled by planet size in some way so that assaulting say large massive jungle planets are year long affairs soaking of huge number of units while landing on a small 10km mining asteroid can be over in a day?

Something else to consider tied to planet size is how do you defend your rear echelon if you land with say 3 units of tanks on a huge planet and order them to take it over? Basically you can't, right?

So maybe there is a need for some kind of "width" for how many units needed to cover the front and prevent breakthroughs, and an inherit advantage to a defender which can move more unhindered through known terrain if the attacker over-extends or can't cover the front (guerrilla defense).
The following users thanked this post: DIT_grue

10
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

11
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

12
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

13
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

14
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

15
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

Pages: [1] 2