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

0 Members and 1 Guest are viewing this topic.

Offline alex_brunius

  • Rear Admiral
  • **********
  • Posts: 984
  • Thanked: 36 times
Re: C# Aurora v0.x Suggestions
« Reply #45 on: March 01, 2018, 01:53:01 AM »
I guess in that case there should be the option to build cheaper training missiles

No I don't think that level of complexity would add much to the game. Just have them fire less real missiles instead ( if training missiles would be 20% cost and you fire 20 of them then mechanically it's the same to fire 4 live missiles ). Leaving it optional so players that really want to micro either for minmax or for RP could "design" their own training missiles using standard tools I think would work better.

Something else I thought would be pretty cool is to be able to use your own uncrewed obsolete ships as training targets, and in the process learn both about their damage resistance and your own weapon efficiency.

Id kindof prefer a training missile item.  Doesn't need to be specially designed by the player but it adds some depth if ships out on training are carrying less live ordnance due to their load of training missiles and get caught by the enemy.  Making even more things just an MSP cost is a terrible cop out that isnt even worth adding imo.

This could maybe be handled by having ships on training not be allowed to use their full munitions load-out but a certain percentage?
 

Offline El Pip

  • Warrant Officer, Class 2
  • ****
  • E
  • Posts: 59
  • Thanked: 9 times
Re: C# Aurora v0.x Suggestions
« Reply #46 on: March 01, 2018, 02:19:57 AM »
All this talk about training missiles got me thinking, could we have crew experience gain make a bit more sense?

Having crew gain experience when their ships armour is hit, but not when the shields are hit always seemed a bit odd. It also seemed odd that causing damage didn't give the firing crew any experience gain.

A system where the crew can gain grade from firing training missiles (and maybe other crews could get grade from shooting them down) could be interesting and would add a bit more depth to Fleet Training. You could set up fleet exercises, have one portion of your fleet try to sink the other, that sort of thing.

It would give you something to do while you wait for your explorers to find aliens. :)
 
The following users thanked this post: MasonMac

Offline chrislocke2000

  • Captain
  • **********
  • c
  • Posts: 460
  • Thanked: 17 times
Re: C# Aurora v0.x Suggestions
« Reply #47 on: March 01, 2018, 02:52:55 AM »
Hopefully a fairly simple suggestion, in the orders list we currently have jump and split task group and also detach non survey craft. Would it be possible to have the reverse of these orders so I can get a survey group to jump and then detach the survey craft instead?
 

Offline Steve Walmsley

  • Moderator
  • Admiral of the Fleet
  • *****
  • S
  • Posts: 7234
  • Thanked: 2376 times
    • http://www.starfireassistant.com
Re: C# Aurora v0.x Suggestions
« Reply #48 on: March 01, 2018, 04:01:40 AM »
All this talk about training missiles got me thinking, could we have crew experience gain make a bit more sense?

Having crew gain experience when their ships armour is hit, but not when the shields are hit always seemed a bit odd. It also seemed odd that causing damage didn't give the firing crew any experience gain.

A system where the crew can gain grade from firing training missiles (and maybe other crews could get grade from shooting them down) could be interesting and would add a bit more depth to Fleet Training. You could set up fleet exercises, have one portion of your fleet try to sink the other, that sort of thing.

It would give you something to do while you wait for your explorers to find aliens. :)

The reason for damage having an impact while firing doesn't is an effort to simulate combat stress. Blowing up helpless enemy ships can't compare to being engaged in heavy combat, so firing doesn't necessarily indicate combat stress, while damage does.
 

Offline Steve Walmsley

  • Moderator
  • Admiral of the Fleet
  • *****
  • S
  • Posts: 7234
  • Thanked: 2376 times
    • http://www.starfireassistant.com
Re: C# Aurora v0.x Suggestions
« Reply #49 on: March 01, 2018, 04:50:17 AM »
A system where the crew can gain grade from firing training missiles (and maybe other crews could get grade from shooting them down) could be interesting and would add a bit more depth to Fleet Training. You could set up fleet exercises, have one portion of your fleet try to sink the other, that sort of thing.

It would give you something to do while you wait for your explorers to find aliens. :)

That is a very interesting idea. The ability to designate part of your own forces as a 'red force' would not only permit training, but allow players to understand combat without losing ships. Perhaps ships could also be set to 'training mode'. If they take damage from friendly ships that are also in training mode, that damage vanishes when they exit training mode (using the assumption it was all simulated damage). Missiles fired in training mode would reappear in magazines (simulated fire). That could even allow allies to train against each other.

Training mode would end automatically if a hostile contact was detected. 
 
The following users thanked this post: orfeusz, Kytuzian, TheBawkHawk, serger, Titanian, Rye123, Rook

Offline alex_brunius

  • Rear Admiral
  • **********
  • Posts: 984
  • Thanked: 36 times
Re: C# Aurora v0.x Suggestions
« Reply #50 on: March 01, 2018, 05:12:39 AM »
That is a very interesting idea. The ability to designate part of your own forces as a 'red force' would not only permit training, but allow players to understand combat without losing ships. Perhaps ships could also be set to 'training mode'. If they take damage from friendly ships that are also in training mode, that damage vanishes when they exit training mode (using the assumption it was all simulated damage). Missiles fired in training mode would reappear in magazines (simulated fire). That could even allow allies to train against each other.

Training mode would end automatically if a hostile contact was detected.

That would be really cool. I also always wanted a better way to test out or "simulate" the performance of my fleets without actually having to risk them or spending hours in spreadsheets & on the wiki. Perhaps some stats could even be unknown or quite inaccurate before you have run weapons through actual tests ( like too hit chance vs certain speeds for example ).
 

Offline sloanjh

  • Global Moderator
  • Admiral of the Fleet
  • *****
  • Posts: 2730
  • Thanked: 65 times
Re: C# Aurora v0.x Suggestions
« Reply #51 on: March 01, 2018, 07:43:27 AM »
Perhaps some stats could even be unknown or quite inaccurate before you have run weapons through actual tests ( like too hit chance vs certain speeds for example ).

Do you mean something like the following by this?

1)  The hit chance when a system is originally designed is a "nominal" value.
2)  The actual value would be NominalValue*RandomMultiplier where random multiplier runs from e.g. 0.5x - 2x (uniformly on a log scale).
3)  The player would originally see the nominal value in dialogs, but as the system gets exercised/tested/used in combat the value would gradually change to actual value.
4)  The value would be tracked on a researched component level.  So e.g. an engine might have the power and fuel consumption adjusted, and would use the same parameters in all classes in which it was used.

On the one hand, I think that's really cool and realistic from the point of view of actual systems no matching design specs (e.g. early WWII US torpedoes).  OTOH it's more micromanagement.  OTGH, it puts a lot more fog of war into component design - minmax players wouldn't be guaranteed that subtly tweaking a design for an extra 5% would actually give them that 5%.  It would make component design more like rolling characters in D&D, with the tweak that you have to do real-life testing of the components to tell if you got a lemon and want to reroll the same design.

John
 
The following users thanked this post: Kytuzian, TheBawkHawk, Titanian

Offline TMaekler

  • Captain
  • **********
  • Posts: 422
  • Thanked: 55 times
Re: C# Aurora v0.x Suggestions
« Reply #52 on: March 01, 2018, 08:16:05 AM »
Training mode would end automatically if a hostile contact was detected.

It might be fun(ny), if it doesn't :-)
 

Offline alex_brunius

  • Rear Admiral
  • **********
  • Posts: 984
  • Thanked: 36 times
Re: C# Aurora v0.x Suggestions
« Reply #53 on: March 01, 2018, 08:26:04 AM »
Do you mean something like the following by this?

1)  The hit chance when a system is originally designed is a "nominal" value.
2)  The actual value would be NominalValue*RandomMultiplier where random multiplier runs from e.g. 0.5x - 2x (uniformly on a log scale).
3)  The player would originally see the nominal value in dialogs, but as the system gets exercised/tested/used in combat the value would gradually change to actual value.
4)  The value would be tracked on a researched component level.  So e.g. an engine might have the power and fuel consumption adjusted, and would use the same parameters in all classes in which it was used.

On the one hand, I think that's really cool and realistic from the point of view of actual systems no matching design specs (e.g. early WWII US torpedoes).  OTOH it's more micromanagement.  OTGH, it puts a lot more fog of war into component design - minmax players wouldn't be guaranteed that subtly tweaking a design for an extra 5% would actually give them that 5%.  It would make component design more like rolling characters in D&D, with the tweak that you have to do real-life testing of the components to tell if you got a lemon and want to reroll the same design.

John

Yes, although instead of actually change to correct value it would "calculate" value derived empirically based on actual data of hits achieved. So if your really lucky with rolls when testing out a weapon it could lead you to thinking the design was much better then it actually is, and so you can't predict in what direction it will move ( if it started moving in one direction that would instantly give away if it was a good or bad "roll" ).

For balance you probably want the distribution of actual values to not be able to go all the way up to 2x ( so that you can't accidentally make an engine that's 3 tech levels more advanced ), but it could go quite far downwards on the scale ( especially for munitions which if untested could be really bad like mentioned US WW2 torpedoes ). The mean value of actual should be same as Nominal display though.

Probably not something practical possible for the game but it's fun to dream :)
 

Offline TMaekler

  • Captain
  • **********
  • Posts: 422
  • Thanked: 55 times
Re: C# Aurora v0.x Suggestions
« Reply #54 on: March 01, 2018, 08:37:56 AM »
How about some kind of "fake buoy" which emits the identical attributes of the ship that launches it. Would be a nice "help" in case you are a lone scout which is encountered by an enemy. So you launch two or three of those buoys into different direction which makes the enemy have to choose which one he wants to follow, or make him having to split up his fleet.

Limits of this buoy: can emit only for a certain amount of time (which might be researchable). 1 hour, then 2 up to 8 at maximum. Also when coming to a certain range and sensor capacity the fake information breaks together and it is identified as a fake buoy.
 

Offline Titanian

  • Warrant Officer, Class 1
  • *****
  • T
  • Posts: 87
  • Thanked: 18 times
Re: C# Aurora v0.x Suggestions
« Reply #55 on: March 01, 2018, 11:37:27 AM »
1)  The hit chance when a system is originally designed is a "nominal" value.
2)  The actual value would be NominalValue*RandomMultiplier where random multiplier runs from e.g. 0.5x - 2x (uniformly on a log scale).
3)  The player would originally see the nominal value in dialogs, but as the system gets exercised/tested/used in combat the value would gradually change to actual value.
4)  The value would be tracked on a researched component level.  So e.g. an engine might have the power and fuel consumption adjusted, and would use the same parameters in all classes in which it was used.
I really like this although I'd say the ranges have to be smaller.
 

Offline Whitecold

  • Lt. Commander
  • ********
  • W
  • Posts: 271
  • Thanked: 59 times
Re: C# Aurora v0.x Suggestions
« Reply #56 on: March 01, 2018, 03:31:30 PM »
In VB6 you can use the Combat Overview window to assign fleet wide targeting.

In the combat overview one can copy either one target to the entire fleet, or get each ship to target a different unit. But this is restricted as far as I can tell to ships of the same class, and has only these few special functions that are available. What I would like to see is a vast expansion of this system, that instead of assigning targets to fire controls on each individual ship assigns weapons to targets on a fleet basis.
Basically a screen that shows all FC in a fleet, all missiles in flight, and controls to assign multiple targets to FCs, and control how many salvos should be fired on each target, how many salvos fired in total. Again if you wanted 100 fighters fire at 50 specific targets, you right now have to assign each individual fire control, instead of selecting all fighters, and the 50 wanted targets and assign them to each other, letting the fighters sort out which one fires at which.
 
The following users thanked this post: papent, Graham, Rye123

Offline TMaekler

  • Captain
  • **********
  • Posts: 422
  • Thanked: 55 times
Re: C# Aurora v0.x Suggestions
« Reply #57 on: March 02, 2018, 03:27:14 AM »
To simplify managing bigger empires having civilian trade also transport minerals would be an ideal addition. Maybe in terms of using the "mineral limit" values as a measurement of automating those orders. If on a colony the mineral amount is lower than the minimum this generates a demand for this mineral and the civilians take a look around which planets do have that mineral in abundance (maybe two or three times over the minimum value) and transport that to the target planet.
 

eponymous

  • Guest
Re: C# Aurora v0.x Suggestions
« Reply #58 on: March 02, 2018, 07:47:20 AM »
user-defined trade good routes

i would like a screen where i could define a trade good route:  mars needs illegal drugs and produces precious metals, alpha centauri 2 produces drugs needs precious metals.   longer cycles would be useful but two-planet ones would suffice i believe.

the computer would look at the smallest of those four numbers (the two annual supply and two shortfall), and would appropriate that much of all four quantities for the "caravan".   computer could auto-assign ships to the route and update the capacity of the route intermittently (as populations expand and productivity tech improves).   conceivably the ships on a route form a single task force (make map nicer and maybe help with processor slowdown), and new ships assigned would be the smallest available class with a speed at least equal to the caravan's current speed.   civvies in a caravan would be unavailable for other hauling duties (as they are in use 100% of the time).
 

Offline the obelisk

  • Warrant Officer, Class 2
  • ****
  • t
  • Posts: 64
  • Thanked: 9 times
Re: C# Aurora v0.x Suggestions
« Reply #59 on: March 02, 2018, 08:06:46 AM »
To simplify managing bigger empires having civilian trade also transport minerals would be an ideal addition. Maybe in terms of using the "mineral limit" values as a measurement of automating those orders. If on a colony the mineral amount is lower than the minimum this generates a demand for this mineral and the civilians take a look around which planets do have that mineral in abundance (maybe two or three times over the minimum value) and transport that to the target planet.

If we go down that route, I think it would be ideal to have a way to specify which planets/colonies civilian freighters are allowed to consider when they're looking for where to acquire minerals, and maybe even the ability to designate which minerals they're allowed to take from which planets/colonies.
 

 

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