By request of Cornflakes_91 I'm cross-posting a post of mine in another thread to here because it is more relevant here. This post explores the idea of
role hierarchy. One thing this post doesn't discuss which is important and something I said I would reformulate from my original suggestion was the idea of
command hierarchy. I'll share some thoughts briefly here. Originally I suggested that the hierarchy of command could be based on fleets, wings and squadrons. This idea was criticised in that it would make it too tedious for the player to give orders to units. This is a valid criticism and I agree, so no more fleets, wings and squadrons.
I like the suggestion offered that the hierarchical structure arises organically simply out of assigning base types (entities and roles) to defer to orders from other base types. I imagine that if you select a unit (or bunch of units) and right-click, you should get something like the following options:
- Defer selected unit (units) to this ship
- Defer selected unit (units) to this ship's role
- Defer selected unit's (units') role (roles) to this ship
- Defer selected unit's (units') role (roles) to this ship's role
Additionally, if you're deferring a role or set of roles to the command of another ship or role, you should be able to specify a cap, saying how many entities belonging to a particular role should defer at this point in the command hierarchy. If assigning the
Interceptor(Heavy Fighter Mk II) role to temporarily defer to a scout, you probably don't want every single ship with that role in local space to be following this single scout about.
The command hierarchy will be calculated dynamically from any ship if you wish to see the chain of command visualised with the selected ship as the root.
Lastly, I'm not in favour of the "multiple tags" suggestion, only because I think it would conflict with the ideas presented below.
---
DWMagus wrote:ThymineC wrote:As Gazz says, roles will be specific to ship classes. If you had a class of ship Vega Fighter Mk II and you wanted to base an interceptor role off of it, you'd create a roll Interceptor(Vega Fighter Mk II). A role node would inherit all the sub-nodes of the class it's based off along with a few additions, "behaviour" being one of them. This ensures that any behaviour specified in the role node will be perfectly handled by any ship assigned to that particular role.
But then this introduces just as much micromanagement.
[...]
But it still comes down to the same thing; how can you generalize when each ship can be specific enough that generalizing doesn't work? Once you have a big enough fleet you can mass-produce cookie-cutters, I understand, but until then, or if you choose not to, you're still micromanaging.
You make a good point. I've been thinking about a way to make the ship management system more flexible while reducing a lot of the necessary micromanagement involved for someone who isn't interested in that kind of stuff. This is what I'm considering:
- Ships can be classified into roles (as previously).
- Roles will be specific to particular ship classes (as previously).
- Roles can be thought of as classes as defined within object-oriented programming (not to be confused with 'ship classes').
- A role hierarchy is a hierarchical inheritance relationship between roles, similar to inheritance relationships between classes in OOP.
- There are a set number of pre-defined role templates e.g. Interceptor, Escort, Support, Saboteur, etc.
- The player may or may not be allowed to modify this set of templates.
- A role is formed by combining a role template with a ship class.
- E.g. Interceptor (role template) + Basic Fighter (ship class) = Interceptor(Basic Fighter) (role)
- Each role allows the behaviour, loadout and equipment of ships with that role to be specified. These are the properties of the role.
- Roles will be able to inherit these properties from other roles in a manner specified by the role hierarchies.
- Every role hierarchy begins with a role template. Role templates are like interfaces in OOP. Role templates define general behaviours but not loadouts or equipment requirements.
- Every role will be able to declare its behaviours, loadout and equipment as private or protected properties.
- Private properties will apply to a particular role only and will not be inherited by any subclassing roles.
- Protected properties will apply to a particular role and any roles subclassing the role unless overridden.
- Properties inherited by roles from parent roles can be overridden or eliminated.
- When a ship is being assigned to a role, the role hierarchies are traversed to determine if that role exists. One of two outcomes can result:
- The role is found - The ship is assigned to the role. It will automatically update its behaviour as specified by the behaviour properties of that role. If a hangar, equipment bay or other source of equipment is in the local region of space, it will attempt to adapt its equipment to suit its role (configurable). If a hangar, station or carrier is in the local region of space, it will attempt to dock and adapt its loadout to suit its role (configurable).
- The role is not found - A new role is created as a combination of the type of role being assigned (e.g. interceptor) and the particular class of ship. The system will try to subclass the most suitable role that already exists. If I've just researched Heavy Fighter Mk III, built one of them and tried to assign it to be an escort, the system will create a new role Escort(Heavy Fighter Mk III) as a subclass of Escort(Heavy Fighter Mk II) (assuming that I've tried to assign a Heavy Fighter Mk II as an escort already - see point below). Escort(Heavy Fighter Mk III) will try to inherit the properties of Escort(Heavy Fighter Mk II) (or whatever parent role it happens to have) as best as possible.
- One potential issue with this system is if you try to assign a Heavy Fighter Mk III to be an escort before you try to assign a Heavy Fighter Mk II to be an escort. Assuming Heavy Fighter already has a corresponding escort role, you will end up with an inheritance pattern Escort(Heavy Fighter) → Escort(Heavy Fighter Mk III) → Escort(Heavy Fighter II). One way to prevent this from happening is to automatically generate the roles corresponding to all role templates as the new ship class is researched or otherwise discovered.
- When a role subclasses another role, it may not be possible for the subclassing role to inherit all the properties exactly as they are in the parent role. For instance, if Heavy Fighter Mk II has 6 weapon hardpoints and specifies a loadout including 6 Ion Accelerators, and Heavy Fighter Mk III only has five weapon hardpoints, it will not be possible for the Mk III to assume the same loadout as a Mk II.
- In the case that a subclassing role has too few hardpoints to assume a given loadout, the system will intelligently try to remove modules from the loadout specification until the role is able to assume the loadout. The system will try to keep in accordance with the Liskov Substitution Principle as well as possible; if Role B subclasses Role A and Role A can perform actions X, Y and Z, and Role B is deficient in hardpoints, then the system will try to intelligently remove modules in such a way if one exists that Role B will still be able to perform X, Y and Z, if perhaps not all of them so well as Role A. The following are examples of guidelines that can be used to do this:
- Prioritise retaining modules that are unique. Remove modules that there are many of. For instance, if a Heavy Fighter Mk II has 6 Ion Accelerators and 1 Afterburner, drop one of the Ion Accelerators and retain the Afterburner for the Heavy Fighter Mk III.
- Prioritise retaining modules that suit the behaviours of the role well. If Role A has 3 turrets and 3 remote repairers, but Role B is subclassing Role A and only has 5 hardpoints, a remote repairer should be dropped if we're talking about offensive roles and a turret should be dropped if we're talking about support roles.
- In the case that a subclassing role has additional hardpoints, I would suggest leaving the hardpoint blank and letting the player allocate a module to it directly. No assumptions should be made as to what the player would want in that hardpoint, as there are often trade-offs for equipping particular modules e.g. additional mass to the ship (lowered agility).
- A similar way of handling other conflicts between parent and subclassing roles can be designed and thought over.
- Although roles are automatically generated, the player should have the freedom to modify any properties of any roles as they desire.
Based on the similarities of this idea and OOP, I use something analogous to UML to demonstrate the idea:
.
(Full size image
here)
In this diagram, role inheritance is denoted by the usual inheritance symbol of a line with an arrow at the end connecting the two roles. Roles are specified in the diagram with the following format:
-----------------------------------
< Role Template >
< Ship Class >
-----------------------------------
Eliminated Behaviour A
Eliminated Behaviour B
...
Behaviour A
Behaviour B
...
-----------------------------------
Eliminated Equipment/Module A
Eliminated Equipment/Module B
...
Additional Module A
Additional Module B
...
Additional Equipment A
Additional Equipment B
-----------------------------------
As with ordinary UML, properties prefixed with "-" are private properties. "Cowardly (Shields - 40%)" is a behaviour specific to the
Interceptor(Basic Fighter) role and
will not be inherited by subclassing roles. Properties prefixed with "#" are protected properties and will be inherited by subclassing roles. Any behaviours, modules or equipment wrapped inside ¬{...} are properties inherited from the parent role that are being eliminated within the subclassing role.
The benefits of this system to the ease of handling fleets are substantial, even if it may not seem it from its complexity. Say I want to assign a bunch of ships in a region of space to be escorts. With this system, I could click-drag the mouse to select that bunch,
right-click → Assign to... → Escort.
I don't care how many ships I just selected, I don't care what kind of ships they are, I don't care what the fleet hierarchy involved is - the system will traverse the role hierarchy for the
Escort role template for each of those ships and find the role corresponding to each of their classes. All of them will behave as escorts appropriate to the class of ship they are, and if configured, automatically try to adapt their equipment/loadout to something appropriate for an escort. If I want to only select ships of a particular class to be escorts, then perhaps I find an example of that type of ship among the bunch and double-click it to select all ships of that class in the local region (think Command and Conquer). All of these ships will be assigned to the escort role for that ship class.
Therefore I could research/design new types of ships and not have to worry about individually specifying roles for them. Each ship class will still need roles to be specific to it, but the system will intelligently try to generate roles for them based on the roles for similar classes of ships. If I want to be the player that makes a bunch of different ships and just wants to order some to be fighters, some to be escorts and some to be support, the system will automatically generate the roles to make the ships behave sensibly for their assigned roles. If I want to be the micromanaging freak who wants to optimise everything, I can dig in to all of those role hierarchies and tweak any of the roles in them to be how I like.