This is not logically different from the current user. Chatter is represented just to focus on the fact that a great emphasis should be put on the human interactions between players. Usually players spend a lot of time just to talk: that's why it is reasonable to identify such a kind of player and the consequent use cases. It is also possible to think about games structured just like a small, quiet town, with public areas and private houses, thus using the framework of Ainulindale to create a very advanced chat system.

Is an admin who dedicates its time to develop the gaming framework. In other words, everything which is involved in providing astractions, tools and environment for Game Adminsm basically concerns the Framework admin. He is not aware of the grid layer, as it uses a set of interfaces provided by the Grid Admin, in order to have the gaming framework decoupled from the grid layer as much as possible.

Represents a variation of a playing character. A game keeper is a standard user as it begins as a playing user, it grows and enhances through the game rules, just like every other player. The main difference is that when it experience in the game, he could be able to create quests or similar. Tools and procedures must be identified to allow such a user to create and manage quests for other players, but avoiding any administrative privilege.
A requirement is that no user should grow and obtain any admin privilege by game rules. Of course, things like immortality is not supposed to be a privilege: it is just a player configurable parameter. It will never obtain, for example, control over low-level parameters of users, objects or other.

Represent the group of people who develop services needed by the Framework Admins that fits the OGSA architecture. They administer the grid at low level: resource allocation, problem determination, debug e resource monitoring. They also actually take care of the grid infrastructure, managing every server needed for the use of the grid, like replica servers, giis, certificate authorities, and all needed to deploy and maintain a grid.

Represents the playing user. It is intended as a user during the act of playing actively: this excludes chatters, game keepers, and all kind of administrators at any level.
A player is supposed to be able to move in the simulated world, to explore, to fight and to die. These are not constraints, these just being parameters offered by the framework; but it is so likely to have such actions that a great attention will be given to them.

There are people who 'own' the entire system, or coordinate work from all other categories. They are the interface between the Open Community part of users and the companies, setting the rules that must be followed in order to join the two communities, the commercial and the free one. They decide 'business' guidelines, or in other words define the most high-level directions to move the project. These guidelines, of course, are not technical but more like managerial overviews.

Represents the generic user. It performs common tasks like using the client software package, logging on the grid, binding to a game.
This user is supposed not to have any sort of revenue, but it is possible that it have to pay in order to bind to certain games.
It could have a personal page on the Ainulindale web site, showing for example statistics, records about games played, announcements or links to personal files stored in the grid.

This is the grid itself. With 'Ainulindale Grid' we refer to the whole set of grid services that enables the Ainulindale Gaming Framework to be executed on a grid environment. It takes care of discovering, indexing, allocating resources; running metrics to monitor the grid usage, to perform data replication to opzimize network usage, to take care of resiliency, to incorporate and remove resources (both serv er-like and client-like) from the grid. With this layer, the Ainulindale Gaming Framework can be focused on deploying tools to create games, without caring for resources and allocation.

A person which wants to create an environment could ask to be accounted as a new administrator on the grid. It will need credentials, and will be given (download the appropriate software package) tools to shape the world. These tools must hide as mush as possible about the grid layer. An administrator have full access to all the parameters of the game he is accounted for: it can define the ruleset, the type of world, every single aspect of the game. It will have full control, both on the structure of the game and on the runtime environment. The limit is that he can only operate within the framework created by Grid Admins, and cannot modify any aspect of the grid itself, except acting as a grid user (for example, having the ability to access some underlying services), but no control over the grid is allowed, and tools should be provided in order to hide infrastructure.

Represents an admin with full control over every aspect of the game. Has full access to game structures, both World structures and ruleset. Every privilege inside the framework is accessible, both online, offline or in testing phase. It is truly the 'God' of the game. Its limits are the framework boundaries, but in the optimum case these boundaries should not be encountered: the framework should allow all degrees of freedom to the Game Builder, hiding only the infrasctructure which is not part of the specific game but of the grid itself. A Game Builder is something completey different from a normal user, and should be described and structured in a very different way. The focus of an admin, in general, is posed to the interface and tools provided to control the game, not to interaction with the game itself. A Game Builder is not a 'God' in the Mud way: a God which is part of the narrativum of the world is just 'an immortal and infinitely powerful user', a Game Builder is something completely different and should not be percieved by the players. It could be possible to bind a 'God in the Game' to a Game Builder, but there should be a clear difference, and to avoid problems or incostistencies in the game the two roles should not be allowed to be present in the same time, forcing to switch the role to use commands or privileges of that particular role. A 'God in the Game' should not be able, for example, to edit the basic rules, as even gods are bound to the world rules. Concepts like 'level', 'hp', 'mana' are unknown and uncoded in the Game Builder, as in the World Builder (not the Tester, maybe).

Represent a sort of customizable player. A tester is a dummy player, created and completely editable by World Builders to provide a way to test a piece of world which is not yet published to the players. Even if is possible for the World Builder to bring real players to the testing area, it is wise to provide a way to stress test some aspects of the area. A Tester has ways to modify every parameter used to describe itself inside the world, but should not be allowed to move outside testing areas. A World Builder could create a set of Testers, and publish them in order to provide a tool for other World Builder to deploy quickly their own areas. A tester can have tools for advanced monitoring, in order to have details about the rules applied by the game as responses to certain actions, or to see area's structures in order to search for errors. Every change introduced by the Tester in the area should always be cinsidered transitient, as the only allowed to commit changes are Wolrd Builders.

Represents ad administrator which has a subset of privileges within the administrative layer. It cannot obtain any control over the ruleset, and have limited runtime controls. Typically, a World Builder has no need to modify the game while running. Most of the work is done offline, or online but acting on a set of structures which is not actually published to players. If an area is published and accessible by players, as a general rule the World Builder should be able only to monitor structures underlying the particular area, objects or npc. When the world piece is not yet published, the world Builder should have enough privileges to be able to run the world piece as if it was published, and to monitor and adjust parameters at runtime. It sould also be possible to bring real players, upon their agreement, to act as Real Testers of the area (procedures should be adopted to avoid problems: ideally, a player brought to the testing area sould return to the 'real' world exactly in the same state as it had when entered the testing area).

The framework effectively enables the creation and usage of services (gaming services and others), and would be quite natural to introduce commercial services. A company could deploy an entire game and give access based on a fee; a skilled area builder could create beautiful areas and have the World Builders to pay for its usage, and the Game Admin could have the users to pay in turn to enter and play in that area. Or a software or hardware donor could pretend a fee for the usage of its resources. In all these cases, and many not covered here, it would be great if the grid could be able to manage money transaction by itself, integrating the services from a financial institute. This implies that services by the institute are exposed and integrated by the grid: this is in a very long future...

Game donor is different both from hardware donor and software donor. It implies both the two, but in a very different logical way. It do not grant to the grid generic and non grid or game related softwares: it puts on the grid pieces of software which are specific to a particular game. It could be, for example, a script for a NPC's AI, or a particular script or code for weather simulations, or running a particular area that can be bound to worlds by world builders. Probably, the grid itself could run these codes on donated hardware, but this a way for the user to decide in which way he wants to contribute to the grid.

Represents any hardware resource which is donated to the grid by the owner. The idea is to have a client package which must be installed and configured to specify which type of resources the user wants to donate to the grid. The software is able to manage the resources assigned to it, and to expose those resources onto the grid, making them available to the entire grid. It must also be able to effectively accept jobs or other requests from the grid and run them using the resources. These resources can be every hardware system or element: cpu power, storge disk, or even some special devices (like, for example, a 3D scanner).
Some metrics must be involved in order to measure effectiveness of the resources and eventually account for the usage by the grid or users.

The idea of donating software refers to allowing the grid infrastructure to use particular software instances donated by users. Obviously, this implies that also computing resources needed by the software itself are donated to the grid, but the logical difference between hw donor and sw donor are noticeable: the grid is not allow to manage such resources directly, but it can use just the software. These software can be of any kind: for example, an apache or a povray instances. It is up to the donor to limit the resource used by the donated process, not to the grid itself.