I've started working on admin functionality for my game. Before I put too much work into it, only to discover I need to redo everything, I'd like to see what other people have found is necessary for an admin. One goal for getting admin working is to have the ability to shadow testers, to have a client that can attach to another player and observe their game play, as if looking over their shoulder. What other admin functionality am I going to discover I need? (especially to help with testing/balancing) (The game is a flash top-down 2D space game where each player controls a single capital ship in a sector of space)

This is somewhat of a too broad question.

In theory, there would be a ACL associated with every single operation. Different types of users would then be able to perform different operations, depending on their role.

Client application would in theory be capable of performing anything, meaning that if admin uses their login, they will get access to other operations as well.

This type of system is not entirely incredibly difficult to implement, especially if client is dumb and doesn't check anything. When someone logs in, their role is checked based on account or similar. Then an ACL policy is chose for them. Whenever they perform any action, the action is checked against ACL.

For convenience, you might want hint client at what the user can do, so that admin buttons or similar don't show up.

ACL is probably easiest to implement as whitelist - anything that is not specifically allowed is forbidden. Then you can make ACL a simple text file which contains a list of actions as strings or similar.

As long as system is based primarily on "verbs" (users interact by sending simple commands, something like debug consoles), it is fairly easy and fast to implement. The advantage is the simplicity, since all commands are implemented without regard to ACL, and ACL is then applied on per-connection.

Java uses this type of security model, and it seems to be adequate, although it should be treated with slight suspicion, since it is not necessarily 100% safe.

Quote:One goal for getting admin working is to have the ability to shadow testers,

Client app would be designed in a way to allow anyone to control any entity. Regular user would only be allowed to control their own ship. Admin would be able to control any ship, both rules enforced by policy.

So rather than implementing limited mode, implement the general case, then constrain that.

Quote:(especially to help with testing/balancing)

Full server-side logging, a good statistics model, preferably versioned and tied into code/release repository, automated error logging facility, preferably tied into repository as well, ability to run multiple versions of the server/client at the same time for A/B testing, client-side data gathering facility for troubleshooting bugs, an error submission contact form where users can communicate with you, perhaps even a forum or ticketing/support system and probably a ton of other details.

It depends a bit on audience as well.

Some good suggestions. It's since occurred to me that a simple form of shadowing can be implemented almost entirely client-side, since it's mostly a matter of centering the view on a particular entity. What the admin won't see is any private information sent to the shadowed client.

I had considered creating a separate admin app, but you may be right that it should be the regular client app with admin privileges turned on.

Quote:Original post by justkevin

I had considered creating a separate admin app, but you may be right that it should be the regular client app with admin privileges turned on.

Hence my suggestion to implement all security checks on the server.

You might perhaps want to use some temp GMs or CMs or CRs, who might need to interact beyond what regular user can, but don't want to give them spawn ability. You might want to allow developers to interact with server in real time, but would only give them limited non-interactive commands to observe only parts of the world alone (to prevent stalking they wouldn't have access to chat perhaps). Or you might want to add a logging or some other tracking service that would only need a single function.

Using ACLs gives a consistent way to implement that, regardless of what client is capable of, especially since such clients are never a priority and will likely be of subpar quality most of the time, leaving more room for error.

Having clients which adapt or exceed intended capabilities then isn't a problem anymore.

And since this is flash and online, this could be integrated with web access, so depending on account used to login, different application or view shows up.

And as mentioned, just log as much as possible during testing, even if it can be only processed off-line. It's much less likely that you will complain about having too much data than not having enough.

On text MUDs, it's quite simple in terms of implementation, and is much the way Antheus describes. Players send commands to the server and the server checks your level to see if you're allowed to execute them or not. Typically you get access to commands based on your level (where admin players have a level that is above the max level reachable by a player) but one high-level command was to allow you to bestow certain extra commands on individuals. eg. You might want to give your newbie helpers access to a separate channel or to be able to teleport a newbie around. All players have access to the command that lists the commands at their disposal, and there's an additional admin-level command that just lists the other admin-level commands you have, for convenience. Finally, all admin-level commands should be logged so that there's a (digital) paper trail of who has done what.

In terms of what functionality you'll actually need, again from my time spent on MUDs (where the functionality is generally much more advanced relative to the complexity of the game when compared to MMOs), it came down to these:

- content creation and amendment (ability to spawn things, move them, rename them)
- player modification (removing or bestowing items, amending broken statistics or items)
- communication (private admin->admin channels, trusted admin->players channel)
- logging (capture a player's current activities and/or communications to a file, save a snapshot of something's current state for future analysis, view the game through another player's viewpoint)
- punishment + moderation (ban player, ban IP address or range, reduce a player's communication privileges, prevent a player from moving, remove messages from noteboards etc)
- live statistics (list of all players and their session details, current up-time, which areas are most busy)
- static information (ability to view stats on a creature, player, area, item)
- server maintenance (schedule reboots, restrict logins to certain characters during test periods, broadcast official messages to players)

Make a separate client for the admins, basically all you would do is take the player client an revamp it so it has all of it's functions such as.

-Shadow Player
-Mute Player
-Ban Player
-Fly(Move anywhere any time)
-Invisible(Visible to only Admins or to players you wish to show yourself to)

So basically this way you have a separate database for all the admin accounts, but it connects to the same server, as the player would. This would create much more ease of use I think.