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

0 Members and 3 Guests are viewing this topic.

Offline JustAnotherDude

  • Sub-Lieutenant
  • ******
  • J
  • Posts: 114
  • Thanked: 56 times
Re: C# Aurora v0.x Suggestions
« Reply #135 on: April 16, 2018, 07:02:36 PM »

This is more me just putting my thoughts out there, as I don't know how interested Steve is in doing this kind of stuff, but it won't hurt to shareI imagine.

So, Spoilers.  I'm personally very fond of them and thought I would share some ideas I had about possible additions to their roster.

Note that I do reference other Spoilers in these, so the uninitiated should be wary!
Crusaders
Off-Topic: show
So with the big improvements to ground combat, I thought that it would be nice to have an enemy that fully exploits these new new mechanics.  This Spoiler would have a chance of spawning on habitable and near habitable terrestrial worlds/moons.  They start out as a colony with of ground force production centers, enough population to service those centers, and a massive number of ground forces.  They would have the unique feature of being protected by a planetary shield, which are projected by buildings that the player can study after they are defeated.  The planetary shield absorbs damage from weapons fire much like a normal shield, but with far greater recharge rate and strength.  Ground forces and fighters, however, can still be deployed onto the planet.

The big thing with the Crusaders is that they want to fight, and fight honorably.  They consider space combat to be deeply dishonorable, so they will not participate unless forced to.  Their ground based anti-ship batteries will not fire on nearby ships unless fired upon first.  They will have a timer that is reset whenever an empire fights them on the ground, so long as said combat lasts for a little while.  When that timer hits zero several massive troop transports, which are armed with weapons and defenses scary enough to make Invaders wary, will move to the nearest large population and drop off their troops.  If the planet is taken it becomes another Crusader world, where the population will be drafted into their armies and shields erected.  The troop transports will not use their weaponry unless attacked by a onworld weapons batteries or space based enemies.  The message mechanic can be used here to make sure you know not to shoot, as one of their ships can message either your planet or a ship.


Parasites
Off-Topic: show
This is about what you'd expect.  Their whole shtick is taking over ships.  Whenever a parasite ships destroyers something, that ships is, instead of dying, it is instead disabled for a day and then brought back as another Parasite ships, completely healed of all damage.  The Parasite's unique component would be an armor regeneration effect, one not quick enough to be useful in combat but enough that it matters on the strategic scale.  These would be added to all ships that the Parasites take over and could be salvaged from wrecks.

Parasites would spawn much like the Star Swarm does.  It would begin with a small fleet of >20,000t ships with no singular design philosophy (the implication being that it stole those ships) and a big, missile armed behemoth that uses overwhelming volleys of size 1 or 2 ordinance to kill things, the idea being that those missiles are the Parasites themselves. 

Their behavior would pretty simple.  Roam around the galaxy until they find something, when they do find something incorporate it into itself.  This includes the populations of planets, which are harvested by the big Mothership when it enters orbit.  After some number of people are absorbed a new mothership is formed, which created another fleet which acts independently of the other one.  Also, I think that the crew of the Parasite ships should get combat bonuses when it comes to boarding.


Anyways, with both of these I tried to emphasis on unique mechanics and behaviors.  I also really like the Spoilery shields, because they're a really cool reward that makes fighting the Invaders feel meaningful, so I thought I would give each one something useful that seriously changes the way the game is played, but no so much as to break the basic flow.  Thanks Steve for the awesome game, and I hope I gave you some inspiration!
 
The following users thanked this post: JacenHan

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: C# Aurora v0.x Suggestions
« Reply #136 on: April 18, 2018, 06:43:47 AM »
An idea for a new technology: Capacitor

Instead of having a bulky reactor onboard, why not having a smaller one, but loading some batteries which "save" energy that then can be "released" when needed. This would give two basic choices of ship designs:

The Default: Your beam weapons need 46 Energy to maintain a 10 sec firing rate. So you build a reactor of power 23.
The Capacitor: Same energy demand, but instead you load up a reactor of power 11.5 and a battery which can store 230 Energy. The gain would be to have a 5 sec firing rate for the first couple of shots, which then, after the battery is used up, slow down to 20 sec firing rate (because of the smaller power reactor). The gain would also be having a lighter ship which would be faster. Whilst the beam weapons are not charged, the energy would go back into the battery.
 
The following users thanked this post: Demonides

Offline TCD

  • Lt. Commander
  • ********
  • T
  • Posts: 229
  • Thanked: 16 times
Re: C# Aurora v0.x Suggestions
« Reply #137 on: April 18, 2018, 07:40:05 AM »
An idea for a new technology: Capacitor

Instead of having a bulky reactor onboard, why not having a smaller one, but loading some batteries which "save" energy that then can be "released" when needed. This would give two basic choices of ship designs:

The Default: Your beam weapons need 46 Energy to maintain a 10 sec firing rate. So you build a reactor of power 23.
The Capacitor: Same energy demand, but instead you load up a reactor of power 11.5 and a battery which can store 230 Energy. The gain would be to have a 5 sec firing rate for the first couple of shots, which then, after the battery is used up, slow down to 20 sec firing rate (because of the smaller power reactor). The gain would also be having a lighter ship which would be faster. Whilst the beam weapons are not charged, the energy would go back into the battery.
That's a nice idea. I wonder how attractive it would be in reality though? You'd presumably be using up your capacitor charge on long range/low accuracy shots and then be down to slow fire as the range drops and effectiveness increases.

It would be an obvious choice for jump defense/assault though where the early shots are what matter most.
 

Offline El Pip

  • Lieutenant
  • *******
  • E
  • Posts: 197
  • Thanked: 165 times
Re: C# Aurora v0.x Suggestions
« Reply #138 on: April 18, 2018, 09:19:13 AM »
That's a nice idea. I wonder how attractive it would be in reality though? You'd presumably be using up your capacitor charge on long range/low accuracy shots and then be down to slow fire as the range drops and effectiveness increases.

It would be an obvious choice for jump defense/assault though where the early shots are what matter most.
That's what the AI would do certainly.

As a player, if you had a speed advantage but shorter ranged weapons then it could be useful. You'd try to rush in close while holding your fire, let rip with the rapid shots to try and cripple them, then pull back out of range to recharge. Not sure if that would actually work, or how often you actually have fast ships but shorter range guns, but it would be interesting to try it out.
 

Offline Bremen

  • Commodore
  • **********
  • B
  • Posts: 743
  • Thanked: 150 times
Re: C# Aurora v0.x Suggestions
« Reply #139 on: April 18, 2018, 12:15:58 PM »
I had an idea for capacitors once, but I saw it as an option for weapon design; weapons would by default have capacitor storage for their fire rate, but there would be a box to select additional tonnage for capacitor that would let them charge to a higher max level. How much a capacitor weighed would probably be best based on your weapon recharge tech level.
 

Offline Jovus

  • Lt. Commander
  • ********
  • J
  • Posts: 220
  • Thanked: 81 times
Re: C# Aurora v0.x Suggestions
« Reply #140 on: April 23, 2018, 10:29:42 AM »
Partial maintenance failures.

Right now, as it stands maintenance failures in Aurora are all or nothing. A part fails, and either you have the MSP to repair it, at which point carry on, or you don't, at which point the part is completely inoperable.

What would be cool is if parts can fail partially, and be partially repaired. For example, your drive stops working. You have some MSP, and your engineering crew makes a roll. They get a partial success, so they use less/more/same MSP, and get the drive back online, but your max speed is reduced until you overhaul. Or your fuel efficiency decreases. Or the mean time between failures decreases. Or the MSP needed for future repairs goes up. Or the part simply can't be repaired again. (All until overhaul, where your shipyard crews rip everything out and refurbish it anyway.) Needless to say, the old possibility of complete failure and complete repair should still exist. Chances for a partial repair would be much increased when the ship is low on MSP, as engineers try to conserve spares.

Balanced correctly, I think this would not change the current balance point by making play either easier or harder. However, it would broaden play by creating a space of flexibility and a wealth of new tactical considerations. For example:

  • You have a drive failure in an exploration ship. You get it partially repaired, but instead of making 3000km/s you can now make 1000km/s. Do you send out a supply tender to escort it home, a transport to unload the crew, or just limp home hoping to make it before your failures add up?
  • You are designing an interceptor that is meant to chase down and kill enemy ships of a known estimated top speed. You could make an engine that will just do the job, saving on fuel. Or, knowing you might have reduced top speed at an inopportune moment, you could overtune the engine and get a comfortable margin.
  • You have a defense screen guarding a forward jump point. You've suffered several partial failures in your armament, so now your missile launchers take longer to load and your railguns require a higher capacitor charge to fail. Do you send them home for an overhaul and lose coverage, or do you keep them on station?
 
The following users thanked this post: Barkhorn

Offline Barkhorn

  • Commodore
  • **********
  • B
  • Posts: 719
  • Thanked: 133 times
Re: C# Aurora v0.x Suggestions
« Reply #141 on: April 23, 2018, 11:49:54 AM »
Jovus

That should be tied in with damage too.  Incoming fire should be able to cause partial failures as well.
 
The following users thanked this post: Jovus

Offline Jovus

  • Lt. Commander
  • ********
  • J
  • Posts: 220
  • Thanked: 81 times
Re: C# Aurora v0.x Suggestions
« Reply #142 on: April 23, 2018, 03:38:19 PM »
Definitely!
 

Offline QuakeIV

  • Registered
  • Commodore
  • **********
  • Posts: 759
  • Thanked: 168 times
Re: C# Aurora v0.x Suggestions
« Reply #143 on: April 24, 2018, 04:17:19 PM »
That could be highly amusing, you could have ships typically be partly functional and get weird numbers for a slightly lowered top speed which could both make things look a little more realistic and give you an intuitive sign about when you might want to go in for overhaul.
 

Offline Rabid_Cog

  • Commander
  • *********
  • Posts: 306
  • Thanked: 28 times
Re: C# Aurora v0.x Suggestions
« Reply #144 on: April 25, 2018, 05:24:32 AM »
A requirement for this would be coding in the concept of "partially functioning" (%) parts and what effect that would have on functionality. For some it is easy:
Engines: Deliver % of engine power.
Jump engines: % of tonnage capacity (this would effectively mean 'non-functioning' unless you overdesigned your jump engines)
Missile launchers: % of firing rate (rounded down?)
Sensors: % of range/sensor strength
Magazines: Increased magazine explosion chance (on hit) (% of non-explosion chance if that makes sense)
etc.

But what impact would it have on a Laser? Reduced range? Reduced rate of fire? Reduced damage? All of the above?
What about a turret? What about a CIWS? What about a fuel tank?

Only once these questions have been answered, can this be implemented. And only once % part functionality is implemented can a fractional maintenance system as you describe really make sense.  However, as a simpler alternative, I can suggest the following:
  • Increase the MSP cost for parts. This is the full replace cost for the part, basically ripping the whole thing out and replacing it. Increase cost accordingly.
  • Change the repair cost to instead of being the full msp for the part, make it a random % of the full MSP, randomly rolled upon breakage.
  • Complicate as necessary. (Increased every time a part breaks, etc)

This doesnt really fit the fractional maintenance system as you suggest, as parts are still only in the binary state of 100% or 0%, but it does make maintenance a bit easier and could tie into a future fractional maintenance system.
I have my own subforum now!
Shameless plug for my own Aurora story game:
5.6 part: http://aurora2.pentarch.org/index.php/topic,4988.0.html
6.2 part: http://aurora2.pentarch.org/index.php/topic,5906.0.html

Feel free to post comments!
http://aurora2.pentarch.org/index.php/topic,5452.0.html
 
The following users thanked this post: Jovus

Offline Jovus

  • Lt. Commander
  • ********
  • J
  • Posts: 220
  • Thanked: 81 times
Re: C# Aurora v0.x Suggestions
« Reply #145 on: April 25, 2018, 04:48:18 PM »

But what impact would it have on a Laser? Reduced range? Reduced rate of fire? Reduced damage? All of the above?
What about a turret? What about a CIWS? What about a fuel tank?


Sure. But I don't see that as a problem so much as extra work. (Of course, I'm not suggesting I do the work, so I don't see it as a problem.) You yourself just gave some good examples, and I can do more. Frankly, in the ideal world where Steve took this suggestion and ran with it (while also not adding to his own workload at all, nor the time to release, because he let his magical basement gremlins do the coding), each relevant part would have multiple partial failure states. Some examples:

Engines:
  • Lower top speed (aka lower EP)
  • Higher fuel consumption (aka higher fuel per EPH)

Sensors:
  • Lower power
  • Higher (as in coarser) resolution
  • Lower sensitivity
  • Higher EM signature

Fire controls:
  • As sensors, plus
  • Increased lag time for FC lock-on or target switch
  • Chance to lose lock (thus requiring crew to re-acquire, and losing any unguided missiles)

Power plants:
  • Lower power output
  • Higher explosion chance

Shields:
  • Lower shield HP per generator
  • Higher fuel cost
  • Lower recharge rate
  • Higher EM signature

Lasers (and other beam weapons):
  • Lower range
  • Higher power requirement
  • Lower capacitor recharge
  • Lower damage
  • Increased damage dropoff (where relavent)

Turrets (which can combine with failures for any turreted weapons, of course):
  • Lower tracking speed
  • Lower HTK

Flag bridge:
  • Lower bonus percentage

Launchers and magazines:
  • Lower reload rate
  • Chance for delay on firing
  • Possibility of explosion (very harsh, so probably not)

etc. etc.

On top of all these, I would also include failure states for every part that give it a MSP requirement per production cycle to continue functioning, and a failure state such that it will require increased MSP to recover from any other failure. (These two would be separate, of course, but could both apply to the same part if it partially fails often enough.)
 

Offline TCD

  • Lt. Commander
  • ********
  • T
  • Posts: 229
  • Thanked: 16 times
Re: C# Aurora v0.x Suggestions
« Reply #146 on: April 26, 2018, 08:10:31 AM »
Sure. But I don't see that as a problem so much as extra work. (Of course, I'm not suggesting I do the work, so I don't see it as a problem.) You yourself just gave some good examples, and I can do more. Frankly, in the ideal world where Steve took this suggestion and ran with it (while also not adding to his own workload at all, nor the time to release, because he let his magical basement gremlins do the coding), each relevant part would have multiple partial failure states. Some examples:

<snip>
I think the flaw with your plan I see is that many of these changes would be very annoying for players. Any changes to the weapon ranges/fire rates/fire controls is likely to lead to more micromanagement in battle, for instance. Varying speeds and fuel efficiencies will lead to more fuel management problems. etc etc

You'd have to have a very strong gameplay benefit to counter-balance adding more micro-management, imho.
 
The following users thanked this post: DIT_grue

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11649
  • Thanked: 20349 times
Re: C# Aurora v0.x Suggestions
« Reply #147 on: April 26, 2018, 08:29:06 AM »
You'd have to have a very strong gameplay benefit to counter-balance adding more micro-management, imho.

Yes, this is the key to any change involving extra detail. Does it add consequential decisions which add game play benefit greater than the additional micromanagement?
 

Offline Jovus

  • Lt. Commander
  • ********
  • J
  • Posts: 220
  • Thanked: 81 times
Re: C# Aurora v0.x Suggestions
« Reply #148 on: April 26, 2018, 11:23:06 AM »
I think the flaw with your plan I see is that many of these changes would be very annoying for players. Any changes to the weapon ranges/fire rates/fire controls is likely to lead to more micromanagement in battle, for instance. Varying speeds and fuel efficiencies will lead to more fuel management problems. etc etc

You'd have to have a very strong gameplay benefit to counter-balance adding more micro-management, imho.

Yes, this is the key to any change involving extra detail. Does it add consequential decisions which add game play benefit greater than the additional micromanagement?

Exactly true. I do see a potential game-play benefit from such a system, however. Namely, with the current system a ship is either battle-ready or not, whereas with the proposed system, the player has a whole slew of logistical and doctrinal decisions about repair schedule and station time that do not exist under the current system.

The way I envisioned it above is that the 'effective' operating time of a given ship would be increased over the current system, because while mean-time-to-failure would decrease (probably slightly), the definition of failure is not as extreme. Thus, you could (and probably would, in most cases) keep a partially-malfunctioning ship on station.

This opens up the field of decisions for a player with regard to maintenance schedules, station time, and fleet coverage.

The fact that it scratches the realism itch by providing a middle-ground between 'optimal function' and 'catastrophic failure' is just an added benefit.
 

Offline Rogtuok

  • Chief Petty Officer
  • ***
  • R
  • Posts: 41
  • Thanked: 2 times
Re: C# Aurora v0.x Suggestions
« Reply #149 on: April 27, 2018, 01:38:12 AM »
Not sure if this has been mentioned.

Fleet training

Make it harder to get fleet training.

Have 1 fleet train
Have 2 fleet train and so forth.

Meaning if you have let's say 5 fleets you can designate 1 of them as training target and that target will get better faster then the rest. Many even get some special skill or host after a long time of training similar to HOI.

Ther is probobly more that can be added like skirmish tactics to this as 1 of the fleets is training in that.
And when they have learned it they can be set as fleet tactic later when assaulting or defending and will then use it's fast ships and fighters on hit and run on aprotching fleet/s

This is just a rough thought.