Overview
A SkyNet simulation consists of a collection of entities and agents. An entity represents an object in the game and has a collection of attributes. Each entity also belongs to a class. The entity class maintains the state of the entity and is responsible for controlling access to querying and modifying the state of the entity.
An entity, by itself, is just a collection of data; entities do not, by themselves, know how to react to or alter the state of the world. All behaviors of an entity are accomplished through an agent that acts on behalf of the entity.
Entity Classes
An entity class represents a type of entity. It can be thought of as a template for creating an entity of that type. Once an entity class is created, it cannot be modified; a new entity class must be created instead. Entity classes possess the following attributes:
1)A list of attributes that entities of this type must possess. Attributes can be queried or modified through operations. Agents have to ability to request the simulation to notify the agent when the value of an attribute is read or modified in either a single entity or a group of entities.
2)An access control list specifying who is allowed to create entities of this type (administrators and the internal entity implementation will always have access).
3)An access control list specifying who is allowed to destroy entities of this type (administrators and the internal entity implementation will always have access).
4)A list of operations that agents can use to manipulate entities of this type (see below). Each interface method can be controlled by an associated access control list.
An entity class is represented simply as a .NET class that implements the IEntity interface. Each entity object is an instantiation of this class.
Access Control Lists
All operations that may be performed on an entity are controlled by an access-control list (ACL) maintained by the SkyNet system. The ACL for an entity operation defines which agents (or agent groups) are allowed to perform the operation. For example, in a grid-based battle game, a unit entity class will typically allow the agent that “owns” the unit to move the unit in a controlled manner (with imposed checks to verify the legality of the move), whereas the other agents would not be allowed to control the player at all and, if fog-of-war is implemented, may be restricted in their ability to even retrieve information about the location of the entity.
By restricting the ability of agents to perform actions to perform operations, the entity class can ensure that its entities are used in a fair manner, consistent with the rules of the game.
Agent Groups and Privileges
To allow a class definition to specify access control policies effectively, without knowing about every agent that might enter the world, we create the notion of agent groups. An agent group may be expressed as either an explicit list of agents or a Boolean formula defined in terms of other agent groups. For example, one could define an agent group “foo” to include agents “fie” and “fum” and then define agent “bar” to include all agents not in “foo”. The definition of agent groups does not preclude an agent belonging to multiple groups. If an operation’s ACL allows any group of which an agent is a member to perform an operation, the agent may perform the operation, even if the agent belongs to other groups, which are not allowed.
The SkyNet simulator defines the following built-in agent groups. Additional groups can be specified either in the definition of the particular simulation being run or by the system administrator.
1)Everyone – all agents are members of this group (An administrator cannot
remove agents from this group)
2) Administrators – members of this group can effect the global state of the game
in ways that other agents cannot. Administrator privileges allows an agent to:
a)Execute all operations on all entities in the system, regardless of the ACL
b)Create new agent groups or modify the membership of existing groups other than Everyone.
c)Add new agents to the simulation, or delete existing agents.
d)Create and destroy arbitrary entities, again bypassing the ACL
e)Dynamically introduce new entity classes to the simulation
f)Stop, pause, or restart the simulation
The privileged operations defined above are privileged because other users could cheapen or ruin the simulation if they were allowed to perform these operations. For example, without these checks, any agent could simply tell the world “game over – I win”, and the request would be adhered to.
Other Agent Operations
In addition to being able to perform operations on attributes, an agent may perform the following additional operations, if it has the appropriate permissions:
1)Query the world for a collection of entities whose attributes satisfy some
condition (this collection might be incomplete if the agent does not have permission to read the attributes of all agents in the world needed to answer the query). (Hopefully, if the query is structured properly, we can find a more efficient way to implement this than a brute-force search of all the entities in the system – we will work out details later).
2)Register/unregister a listener to be called when an operation is performed on
an attribute belonging to an entity. This operation will fail if the requesting agent lacks read permission for the requested attribute on the requested entity.
3)Create/destroy an entity (must have permission in entity class or be an
administrator)
4)Request another agent to perform an operation on behalf of the current agent
(which may involve access control checks and/or parameter validation)
The Agent Owner Group
Every entity has a special, built-in attribute called the “owner” attribute. The “owner” attribute is an agent (or agent group) that represents the conceptual “owner” of an entity. Typically, the owner of an entity is the agent that created it, although the owner of an entity may change during the simulation. When the ACL of an attribute is checked against an agent, the ACL may make use of a special agent group called “Owner”. The owner group includes all agents that “own” the entity being acted upon. Unlike all other groups which have static membership regardless of the entity in question, the membership of the “Owner” group is directly determined by which entity the agent is attempted to act upon.
Owning an entity and owning an attribute are very different concepts. Owning an attribute allows an agent to exert arbitrary control over the attribute on all entities in the system. By contrast, owning an entity does NOT give the agent free reign to change all the attributes of that entity (unless the agent happens to be an administrator). Instead, the owner of an entity only gets privileges to the extent that the ACL of the attribute is willing to grant. Typically, the owner of an entity will have some privileges that a non-owner will not have, but this is solely at the discretion of the ACL and may not always happen.
Implementing Security
The security of the system depends on an agent’s ability to reliably authenticate itself whenever it performs a transaction with the simulation system. In particular, measures must be taken to prevent an agent from spoofing another agent. There are multiple ways this could be implemented. One idea is to prevent agents from being able to directly access other agents and force them to use a proxy agent instead. The proxy would be implemented by the system and would be used to send/receive messages with other agents, but it would not be castable to a concrete IAgent implementation and therefore could not be used in spoofing.
In addition, we plan to run all agent code with restricted .NET permissions to prevent unorthodox “hacks” into other agents or the system, such as reflection into private fields, unsafe pointer manipulation, or unmanaged code. Partial trust also prevents malicious agents from using SkyNet as a way to hack into the server and take over the entire computer. Furthermore, the simulation is running on a server which is assumed to be secure – the only code clients can upload to the system is agent code which runs with partial trust. This prevents the possibility of rogue background process groping into and/or modifying the internal state of the simulation (for example, writing of files/databases used by the system, attaching a debugger and modifying the system’s memory, etc.).
Example – Chess
We now illustrate the above concepts by illustrating how the above framework can be used to simulate a game of Chess. We create one entity class for each chess piece (pawn, knight, bishop, rook, queen, and king), plus one global entity to keep track of whose turn it is. We then create two agents – one for the white player and one for the black player.
Each chess piece has one attribute, which is the location of the piece on the board. Each piece supports an operation to move the piece and to retrieve the position of the piece. Each piece has one attribute, which is location. This allows each player to know when the other player moves without having to poll the opponent’s pieces for a change in position. The ACL’s grant everyone the ability to read a piece’s position and the “owner” of a piece the ability to make a move (which will be validated in accordance with the rules of chess by the internal game implementation). No agents are granted permission to create or destroy units, however the internal piece implementation does have this privilege and exercises it to implement capturing and pawn promotion.