News:

Want to praise Simutrans?
Your feedback is important for us ;D.

Discussion about Simutrans server management software

Started by Ashley, August 17, 2011, 03:21:20 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Ashley

I thought I'd start a discussion to get some ideas about how a management application would work and what features are considered essential.

So far I am working on something along the following lines...

Basic admin:
Start/stop/restart/shutdown server
Start+stop based on a schedule
Start next map (with a playlist/rotation system)/upload new map
Send an admin chat message (using nettool)
Turn auto-restarting of server on/off (linked to monitor process to restart server if it crashes)
Turn auto-map-roation on/off (playlist of maps on a rotation system e.g. weekly)

Status page, listing summary info about the server including:
A full-size minimap representation (requires upgraded nettool, patch mostly written)
Player information + statistics
Status (online/offline and responding/not responding - linked to monitor process)
Pakset info + download

Sysop page, listing users with controls:
Username, player ID on server, IP address(s) etc.
Ban/Kick user (Needs enhancements to the game/nettool regarding blacklist/whitelists - e.g. preserve across restarts etc. I plan on producing patches to implement this functionality)
Change user's password (requires nettool enhancement)
Change username on server (requires nettool enhancement)
(Assign user to slot - see authentication integration)

Chat logs (partially implemented):
Full log archive
Page with "tail" log, last 200 messages
(Mapping usernames of integrated servers onto users within the system)

Server admin:
Create a new server instance
Remove server instances
Change pakset in use on a server
Upgrade/change game binary version (probably choosing from a list, e.g. "current stable, current nightly, current experimental stable, current experimental nightly" etc. depending on demand for versions)

Other:
Listing of servers (tailored view based on logged-in user's permissions, allowing for private/hidden servers?)


I'm going to make the system compatible with Simutrans Standard and Experimental (subject to nettool support in Experimental). I'll also try and keep the functionality which depends on special patches modular (though I'd hope that all the patches will be included into the main trunk in time).


The system would come with a user authentication model. You'll sign up with the service (usual email sign-up with a profile type deal) and then be granted rights based on actions (and action groupings) within the system. E.g. "admin", "sysop" etc. Each game server can have one or more admins, they can then decide which players can play in which slots, and if a game is open to the public or closed-membership. This is where user integration comes in.

My idea for doing this is simple. Have a way to turn off the ability to change your username/password in-game (option in simuconf.tab probably). I'll write a patch to do this, and also to enhance nettool to give it a command to change a player's username/password. All network games will then be set up to have a (secret) common password for all the free player slots. In the web UI you sign up, then the admin of a game assigns you to a player slot (or if the game is more open you can pick a slot yourself). The system then uses nettool to connect to the game instance and set up your username/password. You then log into the game as normal.

This system would be optional and down to the admin of the game to use or not. Obviously community-based features can be built on top of the system too but that will come later. I'll also integrate OpenID authentication so you don't have to have yet another login to remember...


The actual game admin password (used by nettool) will be kept secret (system internal) so that all user authentication is handled by the system in case the admin needs to change. I'm going to implement patches which will bring whitelist/blacklist functionality to the game (so that you can permit admin commands only from a specified list of IP addresses, e.g. localhost). I'll also probably look into enhancing cryptographic functionality within the nettool/admin system as well.


I intend to make this an opensource project based around the Django/Python framework, but also to run it as a not-for-profit commercial service for those wishing to rent a Simutrans server without any hassle. Comments on this plan are also welcome.

Thoughts?


Edit:

Ideas from moblet:

Identify abandoned players (last login timestamp)
Email groups for individual games for admin messages
Email relay for players of a game to communicate/some kind of PM system?
Some kind of out-of-game chat function
Scheduled servers which only run at defined times
Splash page/listing page to display all current netgames managed by the server
Use Firefox? Interested in IPv6? Try SixOrNot the IPv6 status indicator for Firefox.
Why not try playing Simutrans online? See the Game Servers board for details.

Dwachs

great idea.
Quote
The system would come with a user authentication model. You'll sign up with the service (usual email sign-up with a profile type deal) and then be granted rights based on actions (and action groupings) within the system. E.g. "admin", "sysop" etc. Each game server can have one or more admins, they can then decide which players can play in which slots, and if a game is open to the public or closed-membership. This is where user integration comes in.
So you want to provide a "central" (ie super server wide) user authentication? There we would need another layer in the program itself, which separates 'users' (persons in front of computers) from 'transport companies' in-game.
Parsley, sage, rosemary, and maggikraut.

ojii

Quote from: Timothy on August 17, 2011, 03:21:20 PMI intend to make this an opensource project based around the Django/Python framework, but also to run it as a not-for-profit commercial service for those wishing to rent a Simutrans server without any hassle. Comments on this plan are also welcome.

Let me know if you need help with the python/django part, as that's where I could finally contribute something to simutrans.

Ashley

Quote from: Dwachs on August 17, 2011, 04:44:44 PM
great idea.So you want to provide a "central" (ie super server wide) user authentication? There we would need another layer in the program itself, which separates 'users' (persons in front of computers) from 'transport companies' in-game.

I wasn't going to be quite this ambitious. For the server instances managed by the software there would be a single source of authentication. This would require fairly minimal modification to the game as I envision it currently. I want to retain the ability for people to run servers which require no sign-up to just start playing while providing people like Moblet who want to run more exclusive servers a good option for user management.

So my idea was for the management software to keep track of the users and then set the usernames/passwords via the nettool in the game itself. That way you don't have to change the auth mechanism in the game.

An alternative would be to build a registration system into the game, linked to the management software. Lets discuss which approach makes more sense?

Quote from: ojii on August 17, 2011, 05:09:08 PM
Let me know if you need help with the python/django part, as that's where I could finally contribute something to simutrans.

Well, how can you help? I am quite seasoned with Python, but not especially with Django, I'm just sketching out a basic data model at the moment. Do you have any ideas?
Use Firefox? Interested in IPv6? Try SixOrNot the IPv6 status indicator for Firefox.
Why not try playing Simutrans online? See the Game Servers board for details.

ojii

Quote from: Timothy on August 17, 2011, 05:39:50 PM
Well, how can you help? I am quite seasoned with Python, but not especially with Django, I'm just sketching out a basic data model at the moment. Do you have any ideas?

I'm developing Django websites for a living and maintain one of the biggest open source Django apps out there (django-cms.org, not useful for this, just me showing off), so any Django/Python problem I should be able to help with :D

Maybe we should brainstorm at some point (I'm always on IRC, which is the easiest place to get a hold of me).

Ashley

Use Firefox? Interested in IPv6? Try SixOrNot the IPv6 status indicator for Firefox.
Why not try playing Simutrans online? See the Game Servers board for details.

jamespetts

This is an excellent idea - much kudos to Timothy for proposing this and setting it up. The hosting service will be most invaluable, as well as the tools. Might I suggest one additional feature - a timer for server uptime. It would be useful for an administrator to be able to provide that a server will only run during certain times of day (when people are most likely to be playing) so that people can be online for a higher proportion of elapsed game time. (It would also be good to have a system in which the game is paused if nobody is logged in, although this is likely to require substantial modification to the way in which Simutrans works over the network).

As to compatibility with Experimental - if you have any problems with this, please let me know (preferably on the public board so that others can offer assistance, too), and I shall do what I can to help.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ashley

An automatic start/stop based on a timer is totally possible. I'll add it to the feature list (it could even be configured to send automatic admin messages to the players informing them of the impending shutdown...)

Pausing when nobody is logged in would definitely be something to implement in the game itself. I doubt it'd be hard to do either - maybe experiment with it in Experimental? :)
Use Firefox? Interested in IPv6? Try SixOrNot the IPv6 status indicator for Firefox.
Why not try playing Simutrans online? See the Game Servers board for details.

jamespetts

It is probably very difficult to do the pausing thing, as, currently, when a client tries to connect to a server when the game is paused, it does not respond at all; this would need some tinkering with networking fundamentals, which is rather beyond me, I'm afraid.

Another possible suggestion: automated or remote-control screen-shots at a location and zoom level set by command-line input.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ashley

For automated screenshots you'd need the server to be running the graphical interface, which I have no plans to do personally... If someone wanted to implement that functionality in nettool/the game then I'd be happy to build it into the management interface though.
Use Firefox? Interested in IPv6? Try SixOrNot the IPv6 status indicator for Firefox.
Why not try playing Simutrans online? See the Game Servers board for details.

jamespetts

Ahh - it's probably not worth the overhead for the server to run graphics just for screenshots. Hadn't thought of that.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Dwachs

Quote from: Timothy on August 17, 2011, 09:02:36 PM
Pausing when nobody is logged in would definitely be something to implement in the game itself. I doubt it'd be hard to do either - maybe experiment with it in Experimental? :)
it is now implemented in standard, r4782. However, playing on the paused server is not quite possible, as it is paused, and the effect of all actions will be visible after unpausing the server by connecting with a new client.
Parsley, sage, rosemary, and maggikraut.

Ashley

Use Firefox? Interested in IPv6? Try SixOrNot the IPv6 status indicator for Firefox.
Why not try playing Simutrans online? See the Game Servers board for details.

Dwachs

see the simuconf.tab file in the svn repository in trunk/simutrans/config:

# Pause server if no clients are connected
#pause_server_no_clients = 1

Parsley, sage, rosemary, and maggikraut.

jamespetts

Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ashley

This gives me a thought, there are many settings in simuconf.tab which are useful to edit on a server-by-server basis. I wonder if I can set this up so that each game instance runs in a kind of virtualised directory structure constructed using symlinks. I assume that Simutrans has no problems following symlinks for its various files?

File management and version management are going to need to be built into this system too. E.g. savegames must be linked to versions both for the game and for pakset. Paksets need to have compatibility data for game binary versions. All the files for these must be kept track of in the filesystem and linked to objects in the database... Using a virtualised environment for the game to run from may actually simplify things a bit, since for any given savegame you can set up the environment dynamically to include the game binary, support files and so on. simuconf.tab and other config files could be generated dynamically by the system and installed too. By symlinking to pak files disk space can be conserved when running multiple instances too.
Use Firefox? Interested in IPv6? Try SixOrNot the IPv6 status indicator for Firefox.
Why not try playing Simutrans online? See the Game Servers board for details.

moblet

I have no prior experience in administering netgames and the IT stuff is over my head, but based on experiences so far my comments are:

All great ideas Timothy and all look useful. The way I look at it is that if we can't completely replace this forum as the place for administering a game, there is limited benefit in building parallel admin systems since we'll have to come here to do it anyway. In other words I think we should either have a complete admin package or one that does little more than upload, manage, and start maps.

Having the chat outside the game would be ideal, it allows us to address issues with players unable to log in and to communicate easily when the game is down or suffering syncing problems. The user management system should also provide for admins to send and receive emails/PM's to/from individual or all players in a game, and perhaps also for any player to email/PM any other player in their game.

Admins should to be able to see when each player was last in the game to help identify players who may have abandoned.

We have discovered that the public player has the ability to overwrite player passwords; while this remains the case we have a hack for locking players out, but it would be better to have a formal and more transparent system for booting players.

Pausing when no one's playing is a mixed blessing and should be optional, it has the problem that players can't predict how much game time will elapse until they are next online. In large games where players are scattered around the world (the eight players in our game #2 are on four continents) there may not be much pausing anyway. I think the option of running a game on a schedule (e.g. only running between 1600-1800 UTC) is a good one, I get the sense that some players with limited time might feel more comfortable playing on this basis.

If, as I hope, netgaming develops to the point where we have a variety of netgames simultaneously available with diverse maps, objectives, rules and languages, then ideally we'd have some kind of splash page listing all the games running and linking to, say, a standard form for each game explaining the game's objectives and rules, admins, number of players, number of vacancies, etc, and any other specific information.

Ashley

I don't really want to re-implement email/forums again so that kind of functionality I won't go near. Registered players on the system will have to sign up with a valid email address which can be used as a point of contact, and I'll try and make it easy for server admins to link to forums/discussion threads about the servers themselves.

The system will be more for the admins to run the game and assign players to game slots, discussion about in-game rules and policies could be conducted anywhere the players wish. Beyond permitting the upload of maps, configuration of server settings etc. it would be down to the admins of a game to actually enforce any rules they come up with (albeit this would be much easier with a single place to perform admin functions).

I like your idea about a splash screen/listing, and the "pause mode" would be optional. I personally see little value in it but I know that it depends on the playing style of those using the server. Having a scheduled start/stop is also quite possible.

At the moment I'm working on re-implementing the current server listing to improve its reliability and once that's done I'll restart work on this project. The first step will be to write a set of Python tools for interacting with Nettool and managing the game binaries and pakset files.
Use Firefox? Interested in IPv6? Try SixOrNot the IPv6 status indicator for Firefox.
Why not try playing Simutrans online? See the Game Servers board for details.

jamespetts

I should note that the pause mode is optional - it is a simuconf.tab setting.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.