Return to “Suggestions”

Post

Re: Ship Roles (UI)

#16
TanC wrote:
Flatfingers wrote: It would be nice if it could hit a sweet spot that's usable by action-oriented gamers but still fun for the logistics-minded grognards to fiddle with.
Reading through all these I am going to play the devil's advocate and ask how approachable are your proposed systems? They are sounding more like an interface I would find in X3AP; one that may not be intuitive to the non-X3AP user. Or to a user that's more action-oriented than a micro-manager. :problem:
Well... gazz and mine stuff is intended to serve both, action and micromanagement. Except that you offload micromanagement ( like rules how to group new ships) while being fast accesible after having set up your micro
Post

Re: Ship Roles (UI)

#17
Hum... What a bout something like the gambit system in FFXII? It worked really well, and would work wonders for multiple ships.

http://finalfantasy.wikia.com/wiki/Gambits

Basically, you get a character (or in LT a "role" like interceptors), and you give them specific triggers in an specific priority order. So for example, you could tell them to attack bombers if there are any in the field, and to retreat of their health falls to certain point. And land if no bombers on the field. Something like:

If Enemy Bomber HP=<100%: Attack Enemy Bomber
Self: Return to home base/carrier

So basically, all interceptors will attack bombers, and if none are on the field, they will return to base... Now, that is very simple, but we could go a bit beyond that:

If Enemy Bomber HP=<20% Attack Enemy Bomber
If Enemy Bomber HP=<100%: Attack Enemy Bomber
If home base HP=<25%: Defend home base/carrier
If Self HP=<25%: Return to home base/carrier
Any: Return to home base/carrier

This is a bit more complex... It will tell intys to attack any bomber. However, there is an order to prioritize enemy bombers at less than 20% health to finish them off quicker. It will also return when damaged at less than 25% health, and an additional order to defend the carrier against any threat, if the carrier health is less than 25%. Would be bad to sink a carrier with it's interceptors on deck... So that will give is options, but is is also quite tricky... There is actually a big problem with that command set.

The system will also prioritize the commands in the order they are given. So, in that command set, the ship will prioritize attacking targets before returning to base when damaged. So they will never return to base, unless there are no bombers out. So it should be changed to this:

If home base HP=<25%: Defend home base/carrier
If Self HP=<25%: Return to home base/carrier
If Enemy Bomber HP=<20% Attack Enemy Bomber
If Enemy Bomber HP=<100%: Attack Enemy Bomber
Any: Return to home base/carrier

Now, that is a bit different. It will prioritize defending the homebase/carrier, even if the inty is damaged. But it will return to base before attacking any other bomber on the field. It will still prioritize attacking damaged enemy bombers though...

This would give us control over what the AI does with our ships, while reducing the amount of micromanagement. In the end, we will end up with a set of orders for each role that will fit precisely with the way we play. The AI in the game could even go so far, as to asses and copy efficient gambits, and use them itself. For example, the player designed gambit has a 70% win rate, and the AI gambit has 30%. Then it would immediately change the gambit to the player gambit for its ships. Making the game harder, and with a sense of "learning" on it.

Just some ideas. Not sure who played FFXII, but it was fun making gambits that would make your party self sufficient, and "smart".
Post

Re: Ship Roles (UI)

#18
Kalmander wrote:Hum... What a bout something like the gambit system in FFXII? It worked really well, and would work wonders for multiple ships.

<snip>
JoshParnell wrote: @DWMagnus, I'd like to mention that the "gambit" system you described actually fits effortlessly into the high-level AI model that I'm building right now. Almost too effortlessly! This kind of system would take very little work to build in, so I imagine you'll be able to achieve that level of control :)
From when I brought up the same thing here.

I believe it was brought up once more as well. Needless to say, I am always a fan of something like this for AI. :thumbup: :wave:
Image
Early Spring - 1055: Well, I made it to Boatmurdered, and my initial impressions can be set forth in three words: What. The. F*ck.
Post

Re: Ship Roles (UI)

#19
DWMagus wrote:
Kalmander wrote:Hum... What a bout something like the gambit system in FFXII? It worked really well, and would work wonders for multiple ships.

<snip>
JoshParnell wrote: @DWMagnus, I'd like to mention that the "gambit" system you described actually fits effortlessly into the high-level AI model that I'm building right now. Almost too effortlessly! This kind of system would take very little work to build in, so I imagine you'll be able to achieve that level of control :)
From when I brought up the same thing here.

I believe it was brought up once more as well. Needless to say, I am always a fan of something like this for AI. :thumbup: :wave:
:shock:

You guys never cease to amaze... I have not read all the posts, there are just too many... But it seems that all the good ideas have already been pondered and discussed. Which is really awesome :)

This game will be something amazing!
Post

Re: Ship Roles (UI)

#20
Kalmander wrote: :shock:

You guys never cease to amaze... I have not read all the posts, there are just too many... But it seems that all the good ideas have already been pondered and discussed. Which is really awesome :)

This game will be something amazing!
We aim to please! But feel free to stick around, it's the community that makes all these awesome ideas real! :thumbup:
Image
Early Spring - 1055: Well, I made it to Boatmurdered, and my initial impressions can be set forth in three words: What. The. F*ck.
Post

Re: Ship Roles (UI)

#21
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. :P

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:
Image.

(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.
Post

Re: Ship Roles (UI)

#22
You need different tools for different jobs.

X3 (Reunion, Terran Conflict or Albion Prelude) gave you tools essentially to pilot the ship you were in, not to command and control other units. You got a very simplistic map a property menu and deep nested text menus that gave you options but failed in practice when you tried to command anything in real time.

Homeworld 2 gave you a spherical 'tactical view' that you could pan, rotate and zoom to navigate the 3D nature of space plus context sensitive commands that allowed you to view, group and command quickly.

Where X3 and X Rebirth fails even to this day is to incorporate a Homeworld style tool to help command other units under your control. Limit Theory would do well to learn from this mistake i.e. tools for the pilot need to be different than tools for a commander. You don't need to re-invent the wheel learn from examples that got it right, the trick will be how you integrate such tools into Limit Theory and what game play scenarios await...
Post

Re: Ship Roles (UI)

#23
Speaking of different tools, I think we need to define roles in a way the AI can understand. So that once we have AI subordinates in (lower) command positions and assign ships to them they can actually use them as intended.

If I create a new role and name it "Sneaky backstabbing torpedo lubber", I might understand that it is meant for stealth bombers. My AI Lieutenants might not.

So I think we need some generic (and expandable) roles that are known to the AI.
For instance, the "role templates" ThymineC suggested in his cross-post (from Sun Dec 15, 2013 9:33 pm, and I hope the displayed posting times don't depend on the readers' system time ;) ) could be hardcoded in LT and carry some hidden recommendations on how the units following that template should be used.

Then even an AI of limited intelligence could manage to use designated escorts for defense and designated bombers for attack. Smarter AIS might be able to calculate the chances of success for each available shiptype and choose accordingly :) .
Post

Re: Ship Roles (UI)

#24
Rabiator wrote: For instance, the "role templates" ThymineC suggested in his cross-post (from Sun Dec 15, 2013 9:33 pm, and I hope the displayed posting times don't depend on the readers' system time ;) ) could be hardcoded in LT and carry some hidden recommendations on how the units following that template should be used.
why hardcode it? if you give it an "bomber" tag an maybe specify some size range for its targets everything is fine without hardcoding.
the tags could be inherited by ancestor classes, so that every "child" of your original bomber design is also a bomber
Post

Re: Ship Roles (UI)

#25
Cornflakes_91 wrote:
Rabiator wrote: For instance, the "role templates" ThymineC suggested in his cross-post (from Sun Dec 15, 2013 9:33 pm, and I hope the displayed posting times don't depend on the readers' system time ;) ) could be hardcoded in LT and carry some hidden recommendations on how the units following that template should be used.
why hardcode it? if you give it an "bomber" tag an maybe specify some size range for its targets everything is fine without hardcoding.
the tags could be inherited by ancestor classes, so that every "child" of your original bomber design is also a bomber
And the AI still doesn't understand without hardcoding all the possible tags.
Post

Re: Ship Roles (UI)

#27
Because I don't want my commanders to need me for everything. I want to tell them please engage the enemy at #.#.# and they need to know my themselves what ships should be used for what. Otherwise I might as well do everything myself. If they don't understand what the tags mean they will not use the sips as intended.
Post

Re: Ship Roles (UI)

#28
Neandertal wrote:Because I don't want my commanders to need me for everything. I want to tell them please engage the enemy at #.#.# and they need to know my themselves what ships should be used for what. Otherwise I might as well do everything myself. If they don't understand what the tags mean they will not use the sips as intended.
there is still no need for hardcoding, only for good behaviour settings
Post

Re: Ship Roles (UI)

#30
Neandertal wrote:and the behavior settings will need to be hardcoded to know what to do with bombers and what with interceptors ets.
bombers:
preferred target size 300-infinite |---0---0|
ship size range to avoid 0-120 0---0----|
preferred target range 500 metres |--0----|
etc.

interceptor:
preferred target size 0-120 0---0-----|
ship size range to avoid 120-infinite |---0----0
preferred target range 200 metres |-0----|
etc


why do you insist so hard on hardcoding?

Online Now

Users browsing this forum: No registered users and 1 guest

cron