These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

Player Features and Ideas Discussion

 
  • Topic is locked indefinitely.
 

Corporation rights/role management

Author
Yongtau Naskingar
Yongtau Naskingar Corporation
#1 - 2013-07-14 12:43:20 UTC  |  Edited by: Yongtau Naskingar
IMHO the current rights/role management system is unwieldy, slow and vague. I propose the following change:


First, remove the current system with role and checks. Keep the titles, possible extend with more titles or a hierarchy (this is optional), as well as the Divisions.


Then, make a list of events. An event could be "Player tries to take something from a corporation hangar" (E_HANGAR_TAKE or so). Or "Player tries to cancel a corporation research job" (E_RESEARCH_CANCEL). This list should be made public, with a description for each event. Some things in game could be a combination of events. I think the game already sort of works like that, when you try researching a blueprint from corporation hangar, there's multiple checkpoints you need to pass.

The CEO for a corporation could for each event make a set of rules. This would work more or less like the email rules in Outlook or Thunderbird[0]. Basically, for each event you can add a number of rules. Each rule would have a number of tests, be set to "ALL" or "ANY", and be set to "ALLOW" or "DENY". To match an ALL rule, the player must match all tests. To match an ANY rule, the player must match at least one of the tests. The game goes over the rules (in order!), and the first rule that matches determines whether the player is allowed. If no rule matches, the player is not allowed. Exception is for the CEO, who is allowed everything, and for whom the rules don't apply (i.e. don't get tested).

Alternatively, CCP could make a Domain Specific Language. That might be easier to build and more flexible, but it'd be more confusing for people who don't know how to code, though the community would provide snippets and examples.


Example:
Player X wants to see the contents of the corporation hangar in the corporation headquarters for a given division. The server generates a E_VIEW_HANGAR event, for which the CEO has set the following rules:
> Rule 1: ALL, ALLOW
> > IsHeadquarter
> > HasRole("Researcher")
> > IsDivision("Research")
> Rule 2: ALL, ALLOW
> > IsHeadquarter
> > HasRole("Logistics")
> Rule 3: ALL, ALLOW
> > IsStation("Hek IV - Krusual tribe Bureau")
> Rule 4: ANY, DENY
> > IsSystem("Uttindar")
> > IsSystem("Bei")
> Rule 5: ALLOW
> > IsPosModule("Corporate Hangar Array")
> > HasPosModuleName("Betty's ammo emporium")

The system would go over the rules to see if the player may do this thing. For the rules above, the player may view the hangar if:

  • ... it belongs to the Research division hangar at headquarters, and the player has the Researcher role,
  • ... it is at headquarters, and the player has the Logistics role,
  • ... it is at "Hek IV - Krusual tribe Bureau",
  • ... it is at the "Betty's ammo emporium" Corporate Hangar Array, or
  • ... they are the CEO.

They may not view the hangar contents if:

  • ... "Betty's ammo emporium" is at Uttindar or Bei, and
  • ... they are not the CEO.

Anything not in the list is not allowed either.

You could make some pretty complex rules with this, and some rules would be nonsense, but the beauty of the system is that the system itself is very simple / dumb - a simple rule engine with clear rules that need to be checked - while still being really powerful - you can combine rules to your liking.

Adding new rule types (how long has the player been in the corporation, did they join the corporation before, is the moon full, the year 2014 and is the player flying a freighter[1]) is fairly easy since it doesn't depend on integrating everything together.


Pros:

  • Versatile, for example, you can now demand that someone has two roles to access something.
  • Easy to implement while still versatile (CCP doesn't have to make a complicated system to cater to everybody's needs)
  • Clear on how it works, both for CCP and for the players
  • New checks can be added easily since it's a generic system
  • More checks don't complicate the sytem as they do in the current system where everything is connected
  • Shifts complication away from CCP to the corporations that need it, freeing CCP's time.
  • If the player is denied an action, the GUI could tell them the rule number (or name) making it easier to debug for CEOs than the current system.


Cons:

  • While it is more obvious than the current system, making complicated rules might be somewhat tricky. This can be countered if the playerbase makes examples available.
  • Since it's more powerful it could be used to make complicated rules that take up precious server cycles otherwise reserved for pew-pew.[2]



Notes:

  • For CEOs, the rules would not be checked, since CEOs allowed to do everything
  • It'd be handy if rules could have a name
  • The system would do the same thing as it does now, so it would only fire the E_VIEW_HANGAR if the corporation has hangars, the player is at that station, etc. So you don't need to check whether the player is in your corporation or weird things like that.
  • I *think* it's possible to migrate the current system using a list of standard rules, so that we don't need to reset all settings if CCP implements this.


[0] Or IPTables
[1] Note that I don't know if these examples can be done since that depends on how the server is put together.
[2] CCP could limit how many rules/tests any corporation may use if necessary, based on performance tests. You could even give each test type a weight and base your limit on that.
Yongtau Naskingar
Yongtau Naskingar Corporation
#2 - 2013-07-14 12:43:37 UTC
Examples:

Give Betty "take" access to the hangars for the "Research" division at Hek (and nothing else).
Current system:
Make player based at Hek, give "take" access on the Hangar Access (Based at) page for the "Research" division.
New system:
For the E_HANGAR_TAKE event, add the following rule:
> Rule: ALL, ALLOW
> > IsPlayer("Betty")
> > IsLocation("Hek")
> > IsDivision("Research")


Give Betty "take" access to the hangars for the "Research" division at Hek, Uttindar and Bei (and nothing else).
Current system:
Impossible.
New system:
For the E_HANGAR_TAKE event, add the following rules:
> Rule: ALL, ALLOW
> > IsPlayer("Betty")
> > IsLocation("Hek")
> > IsDivision("Research")
> Rule: ALL, ALLOW
> > IsPlayer("Betty")
> > IsLocation("Uttindar")
> > IsDivision("Research")
> Rule: ALL, ALLOW
> > IsPlayer("Betty")
> > IsLocation("Bei")
> > IsDivision("Research")

Give players "take" access to all hangars, if they have the "Logistic" role.
Current system:
  • Give Take access on Hangar Access (Headquarters) page for the "Logistic" role.
  • Give Take access on Hangar Access (Based at) page for the "Logistic" role.
  • Give Take access on Hangar Access (Other) page for the "Logistic" role.
  • New system:
    For the E_HANGAR_TAKE event, add the following rule:
    > Rule: ALL, ALLOW
    > > HasRole("Logistic")

    Give players "take" access to all hangars, if they have both the "Logistic" and "Researcher" roles.CA
    Current system:
    Impossible.
    For the E_HANGAR_TAKE event, add the following rule:
    > Rule: ALL, ALLOW
    > > HasRole("Logistic")
    > > HasRole("Researcher")
    Yongtau Naskingar
    Yongtau Naskingar Corporation
    #3 - 2013-07-15 11:29:39 UTC
    Bump. I can't be the only one who thinks the current system is lousy.
    Tiberu Stundrif
    Nifty Idustries
    Pandemic Horde
    #4 - 2013-07-15 12:36:18 UTC
    I think turning Role Managment into a complicated Logical-based math problem isn't the best way to go. If it takes more than two posts to explain your process, there is probably a simpler fix out there.
    Tchulen
    Trumpets and Bookmarks
    #5 - 2013-07-15 12:47:13 UTC
    Yeah, the system works at the moment, to be honest. It's a bit on the unwieldy side but it works. Allowing titles to be hierarchical would be ok but the rest... not so sure.