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

papent and 3 Guests are viewing this topic.

Offline Zincat

  • Commander
  • *********
  • Z
  • Posts: 318
  • Thanked: 37 times
Re: C# Aurora v0.x Suggestions
« Reply #1245 on: July 03, 2019, 08:25:37 AM »
Defining which events break up the time progression cycle

Copy of posting from here:
http://aurora2.pentarch.org/index.php?topic=9835

Would be nice if we could choose which actions stop a time progression cycle early and which don't. At least for some of them I cannot understand why they stop it early.

Not sure if this was added or not, but choosing what stops time cycles is something I am hoping for :)


Same. Would be very relevant to my interests
 

Offline Kristover

  • Petty Officer
  • **
  • K
  • Posts: 23
  • Thanked: 8 times
Re: C# Aurora v0.x Suggestions
« Reply #1246 on: July 04, 2019, 10:13:09 AM »
Just a shout out to say I'm really looking forward to C# version.  It has become my most anticipated game because more than anything, Aurora lets me play out a specific science fiction fantasy and really scratches my details oriented itch.  I have stopped playing 7.10 because I've never had particularly top of the line computers and there did become a point where the games do become too hard to go through due to the interrupts and long turn times and by all accounts the new version addresses it.  I'm especially looking forward to the new features, particularly on ground combat and the possibility of NPR ground invasions.  I would gladly play premium price for this version.

My suggestion is towards Commander traits.  I really dig the role-playing aspect of Aurora and the management of commanders and oddly the traits really make the characters come alive to me - I even write little notes about the commanders based off of them and their associated dramas.  Though it isn't strictly necessary, I would like to see some game play effects associated with the traits - modifiers to existing skills based off the traits and the possibility of trait gain/loss over an interval (every 5 years or so).  Some of the traits could be intrinsic and not subject to change but others could change.  I feel this system could create the illusion of even more dynamic nature to the Commanders/Leaders.
 
The following users thanked this post: Viridia

Offline TMaekler

  • Captain
  • **********
  • Posts: 481
  • Thanked: 64 times
Re: C# Aurora v0.x Suggestions
« Reply #1247 on: July 08, 2019, 03:22:29 AM »
Duration of Escape Pod Life Support

I found the duration of Life Pods always a bit short. Was wondering if it would be a nice addition to C# if you could define the endurance of life pods at the level of ship design. It would for example make sense if a slow long distance cargo hauler would have life pods which would endure let’s say 60 days and those of a local system transport only 15. The additional space needed for bigger life pods could be calculated into the space requirements for crew.
 
The following users thanked this post: Jorgen_CAB, Scandinavian, SpikeTheHobbitMage

Offline Bughunter

  • Commodore
  • **********
  • Posts: 627
  • Thanked: 44 times
Re: C# Aurora v0.x Suggestions
« Reply #1248 on: July 08, 2019, 01:44:30 PM »
I like the escape pod idea. But it should probably come with some more negative effects from not rescuing your personnel. Otherwise I think it will be too tempting to just go with the minimum time on every design. Or perhaps set 14 days as the minimum time.
 

Offline Father Tim

  • Vice Admiral
  • **********
  • Posts: 1164
  • Thanked: 134 times
Re: C# Aurora v0.x Suggestions
« Reply #1249 on: July 08, 2019, 02:10:26 PM »
I like the escape pod idea. But it should probably come with some more negative effects from not rescuing your personnel. Otherwise I think it will be too tempting to just go with the minimum time on every design. Or perhaps set 14 days as the minimum time.

I, too, love the idea of variable escape pod time that one sets when designing ships.  But I strongly disagree that there should be increased penealties for not rescuing personnel or a fixed minimum duration for life pods.

Whether or not an empire rescues survivors is a *role-playing* decision for that empire, and should not be inflicted on me by game mechanics.  What if my empire is a machine race, and automatically downloads all crew before ship destruction?  What if my empire is a hive mind and sees zero value in rescuing drones?  What if my empire suffers from military chauvinism and views 'death before dishonour' as the overriding principle (in which case, it would be nice if I could prevent my ships from having life pods at all)?

The 'penalty' for too-short a time on your life pods is that you don't get your crew back.  If you want a three-day window, or a three-month window, that should be up to your empire to decide.
 
The following users thanked this post: Garfunkel, clement, JacenHan, SpikeTheHobbitMage, DEEPenergy

Offline Jorgen_CAB

  • Vice Admiral
  • **********
  • J
  • Posts: 1041
  • Thanked: 80 times
Re: C# Aurora v0.x Suggestions
« Reply #1250 on: July 08, 2019, 04:51:34 PM »
I like the escape pod idea. But it should probably come with some more negative effects from not rescuing your personnel. Otherwise I think it will be too tempting to just go with the minimum time on every design. Or perhaps set 14 days as the minimum time.

I, too, love the idea of variable escape pod time that one sets when designing ships.  But I strongly disagree that there should be increased penealties for not rescuing personnel or a fixed minimum duration for life pods.

Whether or not an empire rescues survivors is a *role-playing* decision for that empire, and should not be inflicted on me by game mechanics.  What if my empire is a machine race, and automatically downloads all crew before ship destruction?  What if my empire is a hive mind and sees zero value in rescuing drones?  What if my empire suffers from military chauvinism and views 'death before dishonour' as the overriding principle (in which case, it would be nice if I could prevent my ships from having life pods at all)?

The 'penalty' for too-short a time on your life pods is that you don't get your crew back.  If you want a three-day window, or a three-month window, that should be up to your empire to decide.

I would agree, penalties of that sort is part of the role-playing in Aurora. If you want to "waste" tonnage on advanced life pods should mainly be a role-playing decision.

I would also like if a ships damage control system could prevent a ship from exploding for a short while to allow more crew to get to their pods as well. This would give damage control another interesting and realistic thing to do in the game.
 

Offline alex_brunius

  • Vice Admiral
  • **********
  • Posts: 1018
  • Thanked: 44 times
Re: C# Aurora v0.x Suggestions
« Reply #1251 on: July 09, 2019, 01:53:37 AM »
I, too, love the idea of variable escape pod time that one sets when designing ships.  But I strongly disagree that there should be increased penealties for not rescuing personnel or a fixed minimum duration for life pods.

Good point about penalties not being ideal.

But how about going from it in the other direction? Now it was some time since I played Aurora 4x, but I don't recall there being a meaningful enough bonus in retained experience from rescuing crew/leaders most of the time.

Perhaps if more crew / leaders survived ship destruction on average and if they gained a bit of extra experience simply by surviving ( failure is the greatest teacher ), then it would be worth more for players to rescue their crew so that the decision to leave them to their fate instead of trying a risky rescue mission isn't quite as easy.

This could probably give alot of flavor to the game IMO, especially for fighter crews as it was a huge thing in WW2 that USA rescued fighter crews and put them back in fighters, now with the experience of how their enemy had shot them down, while Japanese pilots often preferred to not even bring parachutes and die a warriors death.

I think it also adds plenty more opportunities for storytelling about epic rescue missions both failures and successes.
 

Offline DIT_grue

  • Lieutenant
  • *******
  • D
  • Posts: 169
  • Thanked: 20 times
Re: C# Aurora v0.x Suggestions
« Reply #1252 on: July 09, 2019, 07:52:39 AM »
Speaking of rescue missions that succeed or fail by a hair, would it be worth having at least a day or two of possible uncertainty in when escape pods die? On the one hand you have the Cold Equations experience several people have written up of the Admiral looking at when they will expire, knowing there isn't a fast enough ship to reach them by then, and turning back through the jump point in futility. But that means you never have the pod that lasted a little longer because not every one assigned to it made it off the ship (... perhaps suspiciously so? Did a coward abandon potential survivors to maximise their own chances?) and the supplies therefore stretched far enough, or there was heroic sacrifice so some of them could see home again, or... For that matter, there's no overcrowded pod with people dying just hours before rescue when there was still days left in the according-to-specifications survival window, sabotage or poor maintenance killing those that had just started to process that they have barely escaped with their lives, ...
 

Offline TMaekler

  • Captain
  • **********
  • Posts: 481
  • Thanked: 64 times
Re: C# Aurora v0.x Suggestions
« Reply #1253 on: July 10, 2019, 04:21:48 AM »
Maybe the survivors begin dying at the beginning of the end of the survival pod life time which will last for a while until the last one dies. So if you arrive let’s say a day late you will still be able to rescue 25% of the original survivors.
 

Offline TMaekler

  • Captain
  • **********
  • Posts: 481
  • Thanked: 64 times
Re: C# Aurora v0.x Suggestions
« Reply #1254 on: July 10, 2019, 04:26:52 AM »
Another idea: when a planetary governor dies his bonuses immediately disappear. Which can be annoying if they were the factor that kept you over a certain margin. And the new governor still isn’t there yet.

How about bonuses fade into the new values over time. The people in the beginning are still used to the old ways of the former governor and therefore continue with the bonus. But over time (let’s say 3 to 6 month) they have to adjust to the new ways of the new governor and loose or gain his bonuses. Same when a leader gets better at a job. He needs time to implement his new knowledge until it yields full fruition.
 

Offline TMaekler

  • Captain
  • **********
  • Posts: 481
  • Thanked: 64 times
Re: C# Aurora v0.x Suggestions
« Reply #1255 on: July 10, 2019, 04:49:06 AM »
Tractor ships: I think tractor ships will become more important in C# Aurora. So I was thinking about utilizing them better. Let’s say you build an immovable space station and want to carry it into its final destination after construction. So you attach it to a tractor ship and move it there. You 15.000kms tractor ship will of course only move it there at 110kms because of the massive size of the space station. In reality you would attach 10 tractor ships to get it moved a bit quicker. So maybe it can be made possible that when you have five tractor ships in a task group, that their summary of thrust is calculated for max transport speed rather than for just one of them?
 

Online SevenOfCarina

  • Warrant Officer, Class 2
  • ****
  • Posts: 55
  • Thanked: 12 times
Re: C# Aurora v0.x Suggestions
« Reply #1256 on: July 10, 2019, 01:11:31 PM »
Could we please replace the current design screen UI with something along the lines of how the turret design screen works? It's really annoying having to use step sizes of 1 HS for components and it's even more annoying to scroll down the extremely long list of available sizes. I'm suggesting something like inputting two out of three of the following with a keyboard to build an engine : fuel draw per EPH/boost, engine power, engine size, with fuel efficiency being selected automatically. It'll be really useful for engines, sensors, and especially fire controls, where the step sizes are aggravating.
 
The following users thanked this post: Doren, Titanian

Offline QuakeIV

  • Registered
  • Commander
  • *********
  • Posts: 326
  • Thanked: 29 times
Re: C# Aurora v0.x Suggestions
« Reply #1257 on: July 11, 2019, 02:47:15 PM »
I agree, that would be really nice.
 

Offline TMaekler

  • Captain
  • **********
  • Posts: 481
  • Thanked: 64 times
Re: C# Aurora v0.x Suggestions
« Reply #1258 on: July 12, 2019, 03:52:00 AM »
Front / Rear Beam Weapons for Fighters. Once an engagement has closed in to dogfight machineguns... eh, I mean beam weapons take over. Usually the one with either speed and/or range advantage can destroy the opponent whilst „running away“ from him. Armor really doesn’t count in those battles.
I would suggest to add a limitation option for area of engagement for small fighter beam weapons. They can either point forwards or backwards. If you equip a fighter only with forward weapons then you can’t engage your enemy as he closes in, whilst he already can fire on you - even if you would have a range advantage. If you want to fire back directly (with a bomber for example), you install a backwards firing beam weapon.

What would be the gain here? An additional command for fighters „Turn around at range x, fire weapon y on target z, then resume previous course“ gives you the advantage of firing back at a distance where your weapons are effective and can potentially one-kill the pursuer. So we add a tactical element to beam dogfights.
 

Offline Rich.h

  • Captain
  • **********
  • R
  • Posts: 469
  • Thanked: 22 times
Re: C# Aurora v0.x Suggestions
« Reply #1259 on: July 12, 2019, 07:38:12 AM »
On the point of lifepod penalties, could this not be implemented by using a racial trait? We already have various ones so add in a new one that could be called compassion or such, the higher it is then the greater the morale penalties a population suffers from losses such as lifepods. This then easily allows folks to create races of custom opinions and keeps a scalable mechanic in place also.
 

 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55