Post reply

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.

Note: this post will not display until it's been approved by a moderator.

Name:
Email:
Subject:
Message icon:

shortcuts: hit alt+s to submit/post or alt+p to preview

Please read the rules before you post!


Topic Summary

Posted by: Jorgen_CAB
« on: January 05, 2017, 06:41:02 PM »

Yep... I missed this one too... :)

I would like if ships had XO commanders listed and that lower ranked officers... especially the lowest rank could randomly be killed on ships that are damaged. Depending on the number of crew on said ship.

I assume that lower ranked commanders with no direct assignment are actually enlisted on military ships in some form some of the time.
Posted by: MarcAFK
« on: January 04, 2017, 07:04:05 AM »

Somehow I missed this thread, I like these changes, especially the commander transit time thing, I used to micromanage commander reassignments with shuttles but that's a hell of an effort for no real gain.
Posted by: TMaekler
« on: September 28, 2016, 07:13:14 AM »

That would also come in handy storewise when the CO is killed during a fight an the XO takes over command...  :D "Make it so, Number One."
Posted by: schroeam
« on: September 26, 2016, 10:48:51 AM »

Having an XO would alleviate the issue of a vacant slot.  Let the XO be the CO temporarily until the new CO arrives, and the XO's bonuses count toward ship performance.  As far as showing the command slot as vacant or not, just list the new CO, but grayed out with (in transit).
Posted by: TMaekler
« on: September 26, 2016, 09:49:04 AM »

Basically keeping it as it is would be best. There is definitely no need for more micromanagement in Aurora  ;D
Like the idea of a travel time when re-assigned (as well as it happening instantly when auto-assigned). This does not add new micromanagement but increases realism.
Posted by: sloanjh
« on: September 26, 2016, 07:14:50 AM »

If a commander is 'assigned', I create some form of interim assignment record which touches nothing else in the game except flagging the commander as unavailable and recording the intended assignment. In effect, the commander vanishes for a while. When the transit time is up, the new assignment takes place at that point. Until he arrives, the assignment hasn't happened.

Biggest issue I see with this is that the command slot might look unoccupied while the new commander is in transit, so player (or auto-assign) might try to assign a 2nd commander.  I was thinking more in terms of having a Boolean as private data in the commander (plus a "previous location/assignment" record in case bad things like the target command being blown up happen).  If the Boolean is set to "InTransit", then commander's bonuses are all zero, the commander is immune from bad things happening, and the commander's name property/get method would tack (In Transit) on the end.  Other than that, none of the clients of the commander object would change.  Of course that's assuming you've got the code set up that way - the above is just an idea :)

John
Posted by: alex_brunius
« on: September 25, 2016, 02:03:27 PM »

With regard to the various suggestions regarding abstracted relocation times; my first thought was that this was a lot of work trying to check if the bonuses of a newly assigned commander were active yet, or he was still in transit. The post above made me realise it is a lot easier than that.

If a commander is 'assigned', I create some form of interim assignment record which touches nothing else in the game except flagging the commander as unavailable and recording the intended assignment. In effect, the commander vanishes for a while. When the transit time is up, the new assignment takes place at that point. Until he arrives, the assignment hasn't happened.

Of course, this could get a lot trickier with automated assignments as suddenly thousands of commanders will be running around the galaxy with no one in charge of anything :). Perhaps automated assignments are instant (planned ahead of time by the Administratum) while manual player assignments have transit times.

Yeah. That makes alot of sense.

Another thing that needs to be handled is what happens if the location is destroyed or lost before arrival, in which case the commander in transit probably needs to be sent back home again ( could be instant ).
Posted by: Steve Walmsley
« on: September 25, 2016, 01:59:33 PM »

With regard to the various suggestions regarding abstracted relocation times; my first thought was that this was a lot of work trying to check if the bonuses of a newly assigned commander were active yet, or he was still in transit. The post above made me realise it is a lot easier than that.

If a commander is 'assigned', I create some form of interim assignment record which touches nothing else in the game except flagging the commander as unavailable and recording the intended assignment. In effect, the commander vanishes for a while. When the transit time is up, the new assignment takes place at that point. Until he arrives, the assignment hasn't happened.

Of course, this could get a lot trickier with automated assignments as suddenly thousands of commanders will be running around the galaxy with no one in charge of anything :). Perhaps automated assignments are instant (planned ahead of time by the Administratum) while manual player assignments have transit times.
Posted by: alex_brunius
« on: September 25, 2016, 12:22:02 PM »

2) Commanders can be assigned anywhere instantly but once in a location they are tracked for combat purposes, so if a research lab gets hit a scientist might be killed. The commanders of ground units can be killed in action, ship officers can be killed by a hit to the bridge, etc. In this scenario, any unassigned commander is ignored and doesn't have a physical location (unless they are on a ship for some reason anyway, perhaps after being rescued from a life pod). There is some scope for exploitation (transferring someone from a ship about to be destroyed for example), but that is self-cheating so not a major issue.

...

My personal preference is currently 2) so please shout if you have a strong opinion about one of the others.

Agree that 2 is the best option of the ones listed.

And I would also like to see it with the two logical improvements that others already have mentioned above. Maybe something like this:
  • Commanders not assigned anywhere have a physical location at your homeworld or planet containing the academy where they graduated, and a % chance to be killed according to population killed on that planet ( if 10% of all pops are killed all commanders have 10% chance to be included )
  • Shuttles and redeployments are abstracted. Commanders that are redeployed to another physical location are given the status "in transit" for X time calculated as the time it would take your fastest commercial ship to complete the travel distance, but the "shuttles" themself they travel on are not modeled or possible to intercept. While in transit the commander does not contribute any if it's stats and the previous commanders remain in charge (unless you order that commander away ). Arrival of commanders to their destination is tracked in the log with an event "Commander X has relieved Commander Y on duty at location Z. Commander Y is now awaiting new orders.
  • An option to toggle "automatic redeployment home after X months idle". This will have Commanders return to their saved "home" location if they have been deployed idle for X months, so if you forget about them somewhere they are not exposed to harm unnecessarily.
Posted by: chrislocke2000
« on: September 25, 2016, 10:42:31 AM »

Somehow posted in bugs, is that a bug itself?!

Option 2 with chance of additional loss based on population damage sounds good, especially if we end up with multiple officers on each ship.
Posted by: Steve Walmsley
« on: September 25, 2016, 10:20:13 AM »

Quote
PS - While reading this, realized that you probably want life pods to implement both "IHasLocation" and "IPotentialCommanderLocation" (or whatever you're using for these abstractions),  since they're a place commanders might end up.

I already track commanders in life pods so that part is handled :)

If someone is on a ship, even if not in a commander position, they are checked for making it into a life pod.
Posted by: sloanjh
« on: September 25, 2016, 10:14:41 AM »

2 is fine with me, but if you wanted a compromise that would give the gaming experience a bit of the feel of not having instantaneous translocation you could do some of the following (some of which were already suggested up thread):

1)  Fundamental idea:  At the moment that you want to assign officers to an empty slot, you randomly determine where unassigned officers are, and then build in a distance-based time lag between the act of giving them their orders and the actual filling of the command slot to which they've been assigned.  Possible locations are colonies or TG/Fleets.  The commanders' location wouldn't be tracked while in transit; their location would simply be "In Transit" with an arrival time data member.  I imagine the random location assignment would be triggered by e.g. opening the commander screen.

2)  You could do the same thing for the possibility of getting killed when a ship or planet explodes/is damaged - the damage/combat routine triggers a reassignment pass.

3)  The assign commander screen would have a lag time next to each officer, and could be sorted based on lag times, so you could prefer assigning officers who are on board.  Until that time, the command slot would be filled by the commander, but with an "in transit" flag (so bonuses/risk of destruction don't apply).  The idea here is that High Command won't be managing the location of every JG; an assignment to a slot will be filled more quickly if done from "on board" resources.  If performance is a problem, you could specify a "max jumps" search radius to only present officers that are close to the command location (rather from the entire empire).  If you did this, you'd probably want another mode for the screen that presented officers without displaying a delay (and only calculated a display when selected or assigned).

4)  To allow High Command to stockpile special officers (and to give micro managers more control) you could add an "officer pool" category of assignment to each possible officer location to which the player can assign officers.  This would have transit time just like a "real" assignment, but would not be overrideable by the random assignment phase, i.e. this is an officer that High Command (the player) IS paying attention to and wants in a particular location until further notice (presumably as a reserve or for a future change of command).

5)  Resolving the "in transit" state for a commander could require going into the same system as any colony after the lag has expired (I'm not keen on this one - I think it's in the same category as over micro-management of maintenance).

6)  You would probably want to have a minimum time delay between calls to the random location assignment routine (e.g. a week) so that opening then closing the commander screen wouldn't magically teleport people all over creation (and/or so that commanders don't magically appear/disappear on board ships between hits).  There could also be an explicit "update commander locations button" that could be used to more frequently update, or even as the only way to move people.

7)  Probability of a commander being at a particular location could be dependent on the planetary population size, fleet tonnage/military presence (system defense score), whether a HQ is present ....  Presumably Fleet and/or sector HQ would have a very high weight.

8 )  Slightly more tracking, but a bit more realistic, would be to have every officer always be assigned to a location (either "present" or "in transit"), and the random location assignment phase would actually be a "generate commander relocation orders" that would randomly assign a small fraction of the commanders to a new location and put them in transit.  This presumably would be done during the weekly update phase.  This might actually be less coding, since commanders would only have two states: "present" or "in transit", while the other situation has to deal with "location unknown" through the random assignment stuff.

9)  I can already hear the calls from people saying "If you put any of this in, please put in a flag that gives us just a raw behavior #2" :)

10)  Survey teams could presumably be set up to use the same "lag time" mechanism if desired. 

So the 50K view of the above suggestion (especially with #8 included) is to NOT abstract away the location of commanders, but to abstract away the travel mechanism in favor of a magic lag time.  This knocks out the instantaneous teleportation aspect, while not getting snarled up in tracking the actual motion of the officers, which is where I suspect most of the coding complexity that you're worried about would come from.

That being said, even if you like it I think this is probably a "should have" (i.e. should wait until after 1st release), since #2 would get the job done and can be enhanced to use this mechanism at a later date.

John

PS - While reading this, realized that you probably want life pods to implement both "IHasLocation" and "IPotentialCommanderLocation" (or whatever you're using for these abstractions),  since they're a place commanders might end up.
Posted by: bitbucket
« on: September 25, 2016, 09:40:10 AM »

I say go with 2.

When you assign a commander or governor somewhere, you're merely specifying this position is where you want them stationed, and you can handwave it off that they figure out a way to get there on their own. Have their bonuses kick in right away to eliminate micromanagement, and chalk it up to sending orders via telecommunications until they arrive in person.

Maybe that getting-commanders-to-their-posts mechanic can become part of an abstract layer of the civilian sector. Keep the civilian shipping lines around as is, as being the Microsofts and the Googles of the moving-stuff-in-space industry, and merely simulate a large number of small independently owned and operated spacecraft who make their business moving around VIPs and small amounts of trade goods—no population transfers, these wouldn't be able to carry enough people to be measureable. Again, there wouldn't be any ships actually being tracked, but based upon the size of your empire's economy and its government type (a simple multiplicative modifier on how much private enterprise your empire allows), every month or so have a few tons of (non-infrastructure) trade goods move automagically from A to B based on supply and demand, then generate a little tax revenue for it.
Posted by: Steve Walmsley
« on: September 25, 2016, 05:29:30 AM »

I kind of like option 1 myself, but with a slight modification/addition. Maybe we could have civilian/automated shuttles that can go between planets/systems taking a commander to where they need to go, whether they are built via a building(like tying in the spaceport to this or having to build a transfer hub of some sort) or player design like a normal ship.

Alternatively we could have a mix of 1 and 2 in that you can assign commanders anywhere, but they have a travel time based on engine technology.

Possible but, as I mentioned above, a lot of work to track all the routes for potentially thousands of commanders and keep track of when the commanders are in position, when their bonuses apply, when research projects begin, if they can be intercepted, etc.. An interesting challenge but my concern is the game play benefit doesn't justify the effort.
Posted by: QuakeIV
« on: September 25, 2016, 04:04:46 AM »

I like 2, with the amendment mentioned where they can get killed if civilians are bombed.