Considering Change to Naval Organization

[Steve Walmsley (OP)]

I've been thinking about this over the last few days (although no time to code until today). There are three main options:

1) A commander can control a certain number of ships. I believe this would be too much micromanagement, as players would have to keep track of this and adjust when ships changed fleets or new ships were built
2) The benefit provided by the commander is diluted across all ships under his command. Easier than 1), but may lead to the situation where the 'power gaming' route is to create a lots of small admin commands, which I don't think would be good for the game either.
3) Location-based, with the range at which other systems can be influenced based on rank. This is my current favoured option because there is no need to micromanage and no 'power game' need to create more commands than you require.

Option 3) does have the realism drawback that one good commander can influence a lot of ships, but this is no different than sector commanders influencing population. Also, if I create different types of admin command (Military, survey, logistic, patrol, etc.) with different bonuses, this will allow a lot of variety within the same systems.

In terms of the benefits, I am assuming something on the lines of 1/4 the major bonus of the commander to ships within the command (Survey bonus for a survey command, Logistic bonus for logistic commands, perhaps a boost to crew training in military commands, etc), plus some secondary effects such as survey commands having greater ranges. Although I haven't really made a final decision on how this will work.

I've been working on the Fleet window today and I think I will make it a combined Fleet / Ship window. I'll post a screenshot later to show what I mean.

[Steve Walmsley (OP)]

This is very much a work in progress but the screenshots below show the current sidebar for the Fleet window. There are four levels. Admin Commands, Fleets (or Task Groups), Sub-Fleets and Ships.The Admin Commands in green and the sub-fleets in light blue are purely admin constructs and don't appear on the tactical map.

    

Every race starts with a single top level Admin Command (which can't be deleted but can be renamed). All other Admin Commands descend in a tree from this one. You can only attach an Admin Command to another Admin Command but you can have an unlimited number of levels in the Admin Command hierarchy.

Fleets can only be attached to Admin Commands. Many fleets can be attached to a single Admin Command but each fleet can only be attached to one Admin Command

Sub-Fleets can only be attached to a Fleet, or to another sub-fleet. You can have an unlimited number of levels within the sub-fleet hierarchy. These are used to organise the ships within the larger fleets. Sub-fleets have no on-map function and all ships within the sub-fleet hierarchy move within the parent fleet.

A Ship can be attached to a Fleet or to a sub-fleet. When attached to a sub-fleet, it is still a member of the parent Fleet at the top of the sub-fleet hierarchy.

The tree has full drag and drop functionality so you can move Admin Commands, Fleets, Sub-Fleets and Ships around as long as the above rules are followed. You can also drag ships and sub-fleets between different fleets as long as they are in the same physical location. Entire sections of the tree can be moved with a single drag-drop. Also, you can open up multiple Fleet windows and drag and drop between the trees in two different windows.

You will be able to detach a sub-fleet with a single click, at which point it becomes a full fleet in its own right. Any sub-fleets further down the hierarchy become sub-fleets of this new fleet.

I will create a 'join as sub-fleet' order so when one fleet joins another, its ships will comprise a sub-fleet within the joined fleet allowing them to detach as a whole unit.

There is still a lot of work to do in this area, one item of which is to include some visual cue for when a fleet is out of range of its admin command.

[Sheb]

So, if I get it, Admin Commands get some kind of staff officers, and the fleets and sub-fleets are directed by the senior officer present?

[sloanjh]

On sub-fleets:

First, from the description, it sounds like the new fleets are what we used to call task groups, i.e. something that can be moved with a single move order.

Second, I think you should build the ability of constituents within a fleet/TG to independently move around the base course.  One of the things I liked in (I'm pretty sure it was) the old computer version of Harpoon was having a tactical layout for a task group.  It had 2-3 concentric zones (e.g. core/screen/scout); each zone was divided into several arcs.  You could put an escort in one of the zones and it would do sprint/drift ASW within its zone without the human having to micromanage.  Aurora is a little different here, but the current system already has the ability for one TG to key its motion off another.

One thing Rule the Waves does (which I got hooked on from the Off Topic thread, btw) is have "divisions" as the smallest grouping of ships that can take move commands.  When in full realism mode (where you're the Admiral), you give them orders such as "scout" "screen" "support" "independent" and their AI decides what they'll do. 

So I think you might want to consider having the grouping immediately beneath "fleet" also have significance on the map - you might call it "element" (as in "a picket element" or "the inner screen element").  The idea is that the elements would generally conform to the fleet's base course, but might position themselves at some stand-off distance.  Rule the Waves also sets things up so certain roles are only available to certain types of ships (e.g. "scout" can't be given to DD since that was out of doctrine in WW1).  In Aurora, designs could have flags like "area escort" or "tight escort" that could be used by AI to assign them to special elements that would behave in various ways.

John

[Steve Walmsley (OP)]

On sub-fleets:

First, from the description, it sounds like the new fleets are what we used to call task groups, i.e. something that can be moved with a single move order.

Second, I think you should build the ability of constituents within a fleet/TG to independently move around the base course.  One of the things I liked in (I'm pretty sure it was) the old computer version of Harpoon was having a tactical layout for a task group.  It had 2-3 concentric zones (e.g. core/screen/scout); each zone was divided into several arcs.  You could put an escort in one of the zones and it would do sprint/drift ASW within its zone without the human having to micromanage.  Aurora is a little different here, but the current system already has the ability for one TG to key its motion off another.

One thing Rule the Waves does (which I got hooked on from the Off Topic thread, btw) is have "divisions" as the smallest grouping of ships that can take move commands.  When in full realism mode (where you're the Admiral), you give them orders such as "scout" "screen" "support" "independent" and their AI decides what they'll do. 

So I think you might want to consider having the grouping immediately beneath "fleet" also have significance on the map - you might call it "element" (as in "a picket element" or "the inner screen element").  The idea is that the elements would generally conform to the fleet's base course, but might position themselves at some stand-off distance.  Rule the Waves also sets things up so certain roles are only available to certain types of ships (e.g. "scout" can't be given to DD since that was out of doctrine in WW1).  In Aurora, designs could have flags like "area escort" or "tight escort" that could be used by AI to assign them to special elements that would behave in various ways.

John

Yes, Fleet is Task Group.

I plan to replicate the current 'formation' functionality from VB6 Aurora. This was based on Harpoon and allows you to designate a threat axis (based on an enemy contact for example), a task group to protect and a distance. The task group will move to position itself between the threat and the protected task group at the desired range. In C# Aurora, I will have the same and you can detach a sub-fleet to take up that role. I will add the formation orders to the sub-fleet, so they can be acted upon when it detaches and I will retain the formation orders when the escorting fleet becomes the sub-fleet or a large fleet.

[TCD]

There is still a lot of work to do in this area, one item of which is to include some visual cue for when a fleet is out of range of its admin command.

Will there be a building connected with each admin command? If not, presumably the power gamers can keep creating new colonies in each system their fleet is in and moving their commands appropriately.

Also, does this mean the flag bridge component is now irrelevant?

Edit- Oh, I should also say that I love the new drag and drop functionality. That will make a huge difference, and is a great addition. Thanks so much for all your work on this Steve, its very exciting.

[Steve Walmsley (OP)]

Will there be a building connected with each admin command? If not, presumably the power gamers can keep creating new colonies in each system their fleet is in and moving their commands appropriately.

Also, does this mean the flag bridge component is now irrelevant?

Edit- Oh, I should also say that I love the new drag and drop functionality. That will make a huge difference, and is a great addition. Thanks so much for all your work on this Steve, its very exciting.

I am considering some form of building, although it would house multiple admin commands. This is partly because it would provide a target for enemy attack, putting senior officers at risk, and partly because I believe that having command headquarters in key systems adds to the 'feel' of the game. This may have to be mobile in some way (Command Centre component instead of a building), or perhaps could be prefabricated. I still have to give this some thought

I've not decided what to do with the flag bridge yet. One option is that fleet (task group) commanders have some impact on the ships under their immediate command (beyond the current RP aspects) and this is reduced if they are in a ship without a flag bridge.

[bean]

I would really like to see some form of seagoing command, with multiple tiers.  The powergamer problem can be solved by setting a threshold for the maximum number of ships which can benefit from a commander's full bonus, and not giving any additional benefit if there are less ships in the command.  So long as the thresholds are reasonably high, you're not going to penalize normal players. 
If anything, I'd want to encourage players to split up their forces a bit more than seems typical now.  I tend to lump all of my units together (within reason), instead of using formations or maneuvering separately against the enemy.  Having it so that a typical player might want to run 3 or 4 TGs in a typical fleet might well make gameplay better.
As for buildings vs mobile for fleet commanders, I'd go with something vaguely like the maintenance/recreation system.  It's easiest to do from planets, but a big ship can do the job, too.

[TCD]

Thanks for the reply Steve, sounds good.

Byron, I think the number of TGs is simply based on micromanagement. Its so much quicker to stick everything in one TG than setting up multiple TGs with formation and protection orders. I might do that every once in a while if I expect a battle to be particularly close, but otherwise...

[bean]

Thanks for the reply Steve, sounds good.

Byron, I think the number of TGs is simply based on micromanagement. Its so much quicker to stick everything in one TG than setting up multiple TGs with formation and protection orders. I might do that every once in a while if I expect a battle to be particularly close, but otherwise...

I get that, but I think it would be relatively simple to tune the numbers so that in most cases, the penalties to having one TG are pretty small and/or it's not really worth it to make more than 3-4 TGs for all but the largest battles.  Powergaming will always happen unless you take really extraordinary steps to stop it.  The key is not making it too powerful relative to normal play.

[sloanjh]

I will add the formation orders to the sub-fleet, so they can be acted upon when it detaches and I will retain the formation orders when the escorting fleet becomes the sub-fleet or a large fleet.

When I read this, it made me confused about whether or not you were thinking about nesting of escorts (I wasn't).  Now that I am, I think this gets at the heart of what I'm proposing.  I think the question to think about is "If B is escorting A, and C is escorting B, what happens to C's orders if B is merged into A (e.g. to transit a wormhole)?  What happens when B is split out again?  And who (B or C) controls these behaviors".

In current behavior (I suspect) B knows about A and C knows about B, but A doesn't know about B and B doesn't know about C.  In other words a TG knows who it's escorting, but the escorted fleet doesn't know who it's escorts are (it's been a long time since I've messed with this, so I don't remember if this is true).  I think what I'm suggesting is that you give the C# Fleet object a collection of
escort TG objects.  Actually, now that I think of it, you've probably already got this - I assume you're implementing your command structure as a tree, so each command knows its sub-command nodes.  So what I'm really suggesting is that you add a flag to a sub-command indicating it's an escort, and that you add commands to the fleet that allow you to e.g. "Recall escorts (for jump)" or "Deploy Escorts".  Now that I think of it, you might want to deploy escorts into different formations (under missile threat or beam threat, for example).  What would be really cool is if you had a Formation object that remembered a canned set of escort deployments.  You could then have a DeployEscorts(Formation) command on the parent fleet that would automagically set the orders of the constituents.  This would also make nesting easy - the formations could nest.  So for example you could have an AMM forward picket with a few beam-armed PD escorts escorting a bigger formation, and you could remember the configuration.

This of course leads to the development of a formation editor screen.  I suspect you'd want to have two abstractions in it: a "FormationTemplate" object that can be put in a library and used as a starting point for a particular fleet's formations, and an "Element" (or TG) object that is used by FormationTemplate to position the elements of the formation.  When creating a formation for a particular fleet, you'd start with a formation template, possibly set distance parameters, and assign sub-fleets/TG to the elements in the formation instance.

This is complicated enough that I imagine it's in the "do it later" wish list (assuming you like the idea) - just wanted to get the idea out there.  And if you're thinking along those lines, I'd advocate thinking about a naming convention where a Fleet is a mobile command that has constituent task groups that can show up as counters on the map or be hidden (as it is now).

John

PS - Don't remember if you've gone there or not, but now is also the opportunity to add the ability to bind multiple allowed missile load-out configurations to a class of ships.

[Steve Walmsley (OP)]

When I read this, it made me confused about whether or not you were thinking about nesting of escorts (I wasn't).  Now that I am, I think this gets at the heart of what I'm proposing.  I think the question to think about is "If B is escorting A, and C is escorting B, what happens to C's orders if B is merged into A (e.g. to transit a wormhole)?  What happens when B is split out again?  And who (B or C) controls these behaviors".

In current behavior (I suspect) B knows about A and C knows about B, but A doesn't know about B and B doesn't know about C.  In other words a TG knows who it's escorting, but the escorted fleet doesn't know who it's escorts are (it's been a long time since I've messed with this, so I don't remember if this is true).  I think what I'm suggesting is that you give the C# Fleet object a collection of
escort TG objects.  Actually, now that I think of it, you've probably already got this - I assume you're implementing your command structure as a tree, so each command knows its sub-command nodes.  So what I'm really suggesting is that you add a flag to a sub-command indicating it's an escort, and that you add commands to the fleet that allow you to e.g. "Recall escorts (for jump)" or "Deploy Escorts".  Now that I think of it, you might want to deploy escorts into different formations (under missile threat or beam threat, for example).  What would be really cool is if you had a Formation object that remembered a canned set of escort deployments.  You could then have a DeployEscorts(Formation) command on the parent fleet that would automagically set the orders of the constituents.  This would also make nesting easy - the formations could nest.  So for example you could have an AMM forward picket with a few beam-armed PD escorts escorting a bigger formation, and you could remember the configuration.

This of course leads to the development of a formation editor screen.  I suspect you'd want to have two abstractions in it: a "FormationTemplate" object that can be put in a library and used as a starting point for a particular fleet's formations, and an "Element" (or TG) object that is used by FormationTemplate to position the elements of the formation.  When creating a formation for a particular fleet, you'd start with a formation template, possibly set distance parameters, and assign sub-fleets/TG to the elements in the formation instance.

This is complicated enough that I imagine it's in the "do it later" wish list (assuming you like the idea) - just wanted to get the idea out there.  And if you're thinking along those lines, I'd advocate thinking about a naming convention where a Fleet is a mobile command that has constituent task groups that can show up as counters on the map or be hidden (as it is now).

John

PS - Don't remember if you've gone there or not, but now is also the opportunity to add the ability to bind multiple allowed missile load-out configurations to a class of ships.

Most of the above is already in VB6 Aurora. You can already create formation plans then deploy and recall escorts to/from the main body. There is a Formation table in the database that holds the information. The planning section is on the second tab of the TG window while the deploy and recall escorts buttons are among the buttons at the bottom of the same window.

Your example of “you could have an AMM forward picket with a few beam-armed PD escorts escorting a bigger formation, and you could remember the configuration” is possible in VB6 Aurora.

I will try to make this easier though in C# Aurora and improve the UI. The formation editor should probably be visual as per Harpoon rather than the current set of dropdowns.

[sloanjh]

Most of the above is already in VB6 Aurora. You can already create formation plans then deploy and recall escorts to/from the main body. There is a Formation table in the database that holds the information. The planning section is on the second tab of the TG window while the deploy and recall escorts buttons are among the buttons at the bottom of the same window.

Your example of “you could have an AMM forward picket with a few beam-armed PD escorts escorting a bigger formation, and you could remember the configuration” is possible in VB6 Aurora.

I will try to make this easier though in C# Aurora and improve the UI. The formation editor should probably be visual as per Harpoon rather than the current set of dropdowns.

Cool - sorry I didn't remember the details of what's already available better.  I like the idea of a visual editor.

John

[chrislocke2000]

Really like the new fleet window and the idea of a visual fleet formation editor. Couple of thoughts:

- On the fleet window it would be helpful if, when you click on a ship or fleet, then other fleets / ships in the same location where highlighted so you can quickly see where you can drag and drop to. Alternatively have a filter which only shows ships in that location when fleet window opened.

- I was also wondering about a logistics version of that window where for each ship it details ordnance, maintenance and fuel held such that you can quick move this stuff around rather than using the current miscellaneous tab in the ship window.

I have to admit that I don't use the fleet formation piece as much as I would like largely because of the missile intercept mechanics and the effectiveness of area defence v final defensive fire which to me means keeping everything as a single blob is really the only logical position. If it was possible to manage missile intercepts so that an escort on picket was able to engage missiles going through their engagement range rather than just landing in their engagement range on any 5 second tick then that would make the whole formation piece far more valuable and better used. 

[serger]

Some sketch-thoughts.

1. Any leader can operate with some number of _subordinates_, not ships, planets etc. I think this global law can be coded through some quite simple and "natural" rules, as those:
1.1 Each direct (next-level) subordinate is adding some probability of "lag" (failure of delivering commands or leader bonuses in this cycle). This increase can be level-independent, and I think a value of 5% for each subordinate will be fine, so operating with 6 or even 12 sub-units of little importance will be ok, but if you want to use your really valuable battleships and task forces properly, then you must deploy them in 2, 3 or 4 sub-units maximum.
1.2 Each rank gives an ability to operate with problems, that was delivered by some number of overall, lowest-level subordinates. Lieutenant will be ok with dozen of crew members, for example, and Fleet Admiral will operate with millions of crew members fleet. I think, 5-times increase of overall subordinate number for each rank level will be fine. Exceeding this rank-dependant number of overall subordinates will result in proportional penalty, so twice number of overall subordinates - is simply halving all leader bonuses, for example.
1.3 Contrariwise, the same numbers of direct and overall subordinates can be valued, calculating probability of increase in leader skills, so overladen leader will make more errors, but will train himself quicker. It must be some non-linear dependence, I think some fractional power will be fine. This rule can prevent from huge structures under command of most skilled leader, and the same way it prevents from empty staff structures, that can train officers doing nothing at all.

2. Normally (without lags of overladen) any leader deliver some part of his bonuses to his direct subordinate, and I think one half of bonus value (therefore a quarter - to next level of sub-subordinates, etc.) will be fine.

3. Hierarchy is quite stiff thing. So:
3.1 Any subordinate must be of lower rank or the same rank with closer promotion time. Unconditionally.
3.2 Those, whose leader have the same rank as theirs, must have some probability of "pissed of" event, resulting in those probable outcomes: additional lag, decreasing of training level or another unit value, and even resignation of this subordinate.

4. Each separating interstellar jump in any command chain is an extra probability of lags (the same way as in p.1.1, but lag probability value may be higher - about 25% for fleet command, I think) and extra penalty in delivering leader bonuses (25% too, I think). For administrative bonuses these values may be lower, may be about 10%, or it may depend on some tech level.

5. Any bonuses depends on stationary objects (infrastructure, stores, system traffic control local features, etc.) in the same way, as on moving objects (as staff, ships, laboratory samples, etc.), and that can be coded, if each administrator position will have some "knowledge of stationary" value, that will drop with changing leader or moving fleet to another system, and command position will have the same "knowledge of movables". Those values can rise depending on leader values (I think 1 month for increasing from 0 to 100% is great, and a year is maximum adaptation time for any lazy ass). This rule will prevent from shuffling leaders at will, even before battle or another burning need.

6. It will be great to see the same principles not only in fleet structures, but in army too, and in government administration (empire - sector [- system] - colony hierarchy), and maybe in colony branches too! R&D leader scientist can lead the whole branch, not only one project, for example, and factory fleet specialists can be used as SY administrators - and the same way, each one can pick the only SY, or all shipyards of colony, [system,] sector or empire.