Permissions

From HEWIKI
Jump to: navigation, search

Contents

Overview

HeroEngine supports a fine-grained permission system granting users specific capabilities within the engine ranging from the ability to log into a world using the edit client(HeroBlade) to modifying script code.

Permissions are set in the Account Management System(AMS) by the group administrator(s) in the form of a Role granting the user the ability to perform different roles such as World Builder or Testor. A user can have multiple Titles associated with his/her account. Each Title has associated permissions that grant him/her access to various things within HeroBlade. In AMS if a user is designated as a title it will be shown as a green check mark in the table in that user account's row.

Permissions

The following is the list of individual permissions supported by the engine, which are set as enabled/disabled by the Account Management System(AMS) based on the role(s) assigned to a user.

HeroBlade
Allows the user to connect to the game world using the edit client(HeroBlade)
Repository Browser
Allows the user to connect to the game world using the Repository Browser to upload new content
Modify Scripts
Allows the user to use the Hero Script Editor in order to create/modify/delete scripts
Modify Game Object Model
Allows the user to modify things that exists in the GOM using the CLI
Modify Data Object Model
Allows the user to modify things that exists in the DOM using the CLI and DOM Editor such as creating class and field definitions.
Edit Areas
Allows the user to edit Areas by creating new environment schemes, changing terrain, adding assets (etc.)
HeroEngine Admin
Allows the user to perform special global operations such as Asset Replacement
GameMaster
Allows the user to do game-specific things implemented by the development team

Account Management System Roles

AMSAccountPermissions.png

The Account Management System simplifies permission management through the concept of roles, which each role having the correct permissions enabled to perform that role. For example, the WorldBuilder Role allows its users to run the edit client(HeroBlade) and edit areas.

When a user posses multiple roles, the permissions will be set to the highest level of permission for the aggregate roles (in other words, adding the World Builder role to an Administrator does not remove permissions enabled by the Administrator Role).

Note: Each product has its own set of flags restricting whether or not users of a certain role are permitted access to a world. Functionally that means, the ability to access any given functionality is a combination of the product's role access restrictions and the specific permissions of a role.

Administrator(Admin)
Administrators are HeroEngine's equivalent of a super-user, they can do everything.
HeroEngine Administrator
HeroBlade
Repository Browser
PlayerClient
Modify Scripts
Modify Game Object Model
Modify Data Object Model
Edit Areas
GameMaster


Developer(Dev)
Developers are the standard level account allowed to do everything from scripting, world building, to uploading new content, creating/modifying Spec System data.
HeroBlade
Repository Browser
PlayerClient
Modify Scripts
Modify Game Object Model
Modify Data Object Model
Edit Areas
GameMaster


Quality Assurance(QA)
Quality Assurance personnel are able to use the edit client(HeroBlade) to test on the Development Server, investigate and provide detailed reports for issue tracking. They cannot make permanent edits to the Development Server.
HeroBlade
PlayerClient


Beta Tester(Beta)
Beta testers are able to use the player client to test gameplay features. They have no access to the development tools. Player Clients are only available on Alpha and Beta servers, not on development servers.
No access to development tools
May access beta world
PlayerClient


Customer(Cust)
A normal customer playing your game using the player client. They have no access to the development tools.
No access to development tools or world.
May access production world
PlayerClient


GameMaster(GM)
A customer service agent with access to game specific tools exposed by your developers through the player client..
No access to development tools
Allowed to use tools created by your developers that check for the _GameMaster permission

HSL Interface

The existing permissions can be used within the game through HSL calls to two external functions. One way to use this capability is to take tools created by your developers and restricting access to them based on one of the existing permissions. For example, if your developers create a spawner system that you want to allow people who edit areas (World Builders) to use to place spawn points a check could be added to allow only accounts that have the __IsAllowedToEditAreas permission.

external function _DoesAuthorizationNameExist(accountId as ID, permission as String) as Boolean
 
external function _GetAuthorizationValue(accountId as ID, permission as String) as Boolean

The following permissions are defined:


Restricting Script Execution to a Specific Permission

For this example, we will assume your developers have exposed the capability on the client to place a spawn point through a client-side User Interface(UI) that invokes a remote procedure call on the server. Since we have decided that world builders should be able to place spawn points, we choose to check the permission __IsAllowedToEditAreas which from above we know is set enabled for Developers and Administrators (but not QA or other roles).

// add a spawn point at the user's current position
untrusted method RequestCreateSpawnPoint( spawn_name as string )
  if _GetAuthorizationValue( SYSTEM.REMOTE.CLIENT, "__IsAllowedToEditAreas" )
    account as noderef of class _PlayerAccount = SYSTEM.REMOTE.CLIENT
    $SPAWN.AddSpawnPoint( spawn_name, account.GetPosition() )
  .
.

Restricting Asset Library Commands to a Specific Permission

The Asset Library exposes the capability to execute a 'chat' command by clicking on one of its icons. This capability can be used to expose and invoke a variety of tools during the instantiation of asset instances or as a stand-alone command. Library commands are ultimately handled by a server script (as specified by the chat command registry /REGISTER).

For this example, assume your developers have created a /spawn command that places a new spawn point at the user's position.

// in the script specified for the /spawn command
shared function HE_ProcessCommandInput(account as NodeRef, input as String)
  if not (_GetAuthorizationValue( account, "__IsAllowedToEditAreas" ))
    $CHAT.CHATPLAYER( account, "", "You are not permitted to do that." )
    return
  .
 
  // continue processing normally
  spawn_name as string = getID()
  $SPAWN.AddSpawnPoint( spawn_name, account.GetPosition() )
.

See Also

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox