hi, how do people make an interface to the server of a mutiplayer game, more specifically a persistant online RPG (e.g. something like an MMORPG)? i know i have seen in the past hplus recommended to build a web interface, so that you could access the server via a web browser. but why is such a thing done exactly? why not just make a program which communicated directly with the server? then that program could query for things and the server just sends it the data. the program would also be able to send messages which could do things such as kick / ban people, send a global message to everyone on the server, etc. i could even make a "game master" version of the client which had powers including access to this interface. it would also make for a nicer GM client because then i could have everything in one place. i also think that it would be harder to code, as well. i guess im just wondering.. what are the bonuses to a web interface that im not seeing? and also any other tips or advice anyone has on this is appreciated. thanks for any help.

With a web browser, you can administer from everywhere.

Operators know how to use web browsers, but would have to learn to use your custom application.

Microsoft and the Gecko people update the web browser, you'd have to work on your custom client.

When you're managing a cluster of potentially hundreds of individual machines, a game-client-based interface probably isn't the right metaphor.

There are tools that already know how to speak to web interfaces -- Perl, wget, python, etc. Thus, to automate management, you don't need to write your own modules and tools.


If you're running the server on Windows, you COULD put up a regular Windows dialog, with buttons and checkboxes and a zillion tabs at the top (or an expando-list on the left), and use remote desktop access to get to it, running on the actual server. It's still not as nice as a web interface for large things, though, and doesn't automate well.

If you don't like a web interface, the only other interface I could recommend a little bit is SNMP (Simple Network Management Protocol).

hey hplus,

i see your points. im going to be the *only operator and there is only *one server, but i understand now why you recommend it. the other thing is i just remembered i would have to make some sort of GUI for this and ive never used any GUI API's or app friendly languages before. even my level editor i made in OpenGL *shudder*. right now im just trying to decide what will take longer, me learning a windowing API (or C# winforms) or me learning HTTP. also i have to weigh in the advantages http has.

*yes, i know, this might change one day [grin]

you would need to create a typical windows application.The network code should be done in another thread, so the main window can reply the messages.

Personally I'd say build it into the normal client app, unless there's some really good reason to do otherwise.

The server process could have a physical console which accepts text commands - that is also really easy to implement (and of course, existing remote access / sharing solutions exist already, like screen etc)

But if you build a console into the normal client, you can have operator commands in there.

Or you could even just accept chat commands which start with a "/" (which pretty much seems to be the standard, like IRC) which are sent to a command processor rather than shown to other players.

Quite a lot of games have some operator commands which can be used from the console etc.

Mark

mark raises a good point.. those are 2 other options i have that i thought about myself.. how bad would it be for me to just code the interface right into the server? i could make non-blocking input using kbhit() and have a sort of command line, so i could do something like /print players online, or /kick bob, or /message the server is going down in 10 minutes, etc..

the other option is to just make a "GM" client for myself.. would be kind of cool to run around, all god like.. usefull for things like customer support as well.

If you do that, make sure you build in extra security. There'd be nothing worse than someone getting hold of your password or figure out an exploit to barge into your command system. I think you should have a couple of layers, perhaps have 'mods' or 'ops' in the game that can kick/ban players, but then have another interface that's a whole new client (web or otherwise) which will allow you to control things such as the economy and/or item positions, etc. If you add ops, I'd go the extra stage of them having to enter another password to 'op-up', meaning that if someone got into an operator's account, they'd still need another pass to cause mayhem. If you build your client/server to be modular you could easily create your idea (separate GM client) without the need to rework too much.

well, i think simply password protecting should be sufficent for my game. however im most likely going to "turn on" secure connections. i use RakNet which has an awesome secure connection feature, which handles encryption and authentication using all kinds of nice things i dont understand [grin].

Well, our production system uses XML for transport of administration and diagnostics data (and there's lots and lots of that available, if you have the right authorization :-). We can stick a CSS reference at the top, which can generate a basic HTML form for administrating through a web browser; we can write command line tools in scripting languages that do all kinds of tings (including the e-mail alerts and graphing), and we can write a GUI tool to perform certain events, that would run on top of the XML-over-HTTP channel.

However, the operators are sufficiently happy with the command-line and web-browser environment we set up for them, and in fact believe a custom GUI would be a step backwards, because then they can't fix things when they go wrong. (Our operators are "real" sysops; not just cheap button jockeys)

Anyway: do whatever you think is easiest, and do it better once you see the limitations. Start with the administrator-enabled client, perhaps; it should be easy to tie a "special powers" privilege to a specific login account, and use the chat command line for status and commands.