Artemis - Dedicated Server mode

I would like to second a request for a dedicated server mode. But let's... call it dedicated server. Because the moment you write "The Cloud" my anti-buzzword browser plugin replaces that with "My Butt".

https://github.com/panicsteve/cloud-to-butt ^_^

hahahaha fair enough.

Just some food for thought--and I agree that this "headless" mode sounds like a good idea--but consideration needs to be made for how to set the parameters on the server when it is "headless". Currently the 3D support is required, even for parameter setup, because it is using the same mechanism for display.

Not that I'm providing an answer to this issue--that'll be up to Thom to work out a good solution there, as any number of solutions will solve such issue. Solutions include use of command-line parameters, setting the parameters via clients, a "text-only" mode, etc.

Command line parameters sound good. Perhaps even let users specify a .xml file that contains the server settings, that way you can run multiple servers and keep the settings in individual xml files.

A Command line mode would be ideal actually. Frees up resources for the server. Set it up to accept ssh logins would be great.

I'll vote for this.. and agree with the 'dedicated server' designation as I have this lovely V20z which has worthless video.. but 2 quad core procs and 16GB RAM... that I can't use for artemis....

Xml files give issue with one-offs, such as specifying different missions to play (you aren't going to want to set up a different Xml file for every mission and combination of parameters). But this is easily solvable via other mechanisms. Command-line parameters do open up being able to set all the parameters easily, except that the command line could get ugly with enough parameters to set. A combination of a command settings file (such as Xml) and command line parameters would probably provide the best of both worlds.

But, then having to deal with end of mission and starting a new one has to be figured out as well. When the mission ends, how do you show all the stats? Should the server restart to get a new mission ready? Or should it exit so that new parameters could be set? And what if you just want to restart without completing a mission?

Oh, and there's the question that hasn't been asked--when should the game start? Right now it does not start until "Start" is clicked on the server. But if there is no user interface, should it start immediately, risking getting blown up before all the clients can connect? or should it wait for some kind of signal from one of the clients?

Just more food for thought.

Why not learn from other games? i.e. server shows scores for a set amount of time before next mission starts.

The server could allow for multiple mission definitions to be included one after another, and either run them one-shot or in a loop.

I would presume that Dedicated server mode would roll up with the Game Master Screen taking over those functions such as start button and mission configuration.. possibly even the selection/loading real time of XML files.

Well--that could work if you have a Game Master client connected. That isn't always going to be the case. The only clients you can count on being connected with every game are helm and weapons. None of the rest are required to play.

True, but if you're running a headless server, I'd say odds are you're packing more IT firepower than a helm/weap only rig... Of course I suppose an NCurses or other ANSI interface could be rigged in as well.

Yeah, if you're hosting a dedicated server you better have the know-how to multi-task and manage multiple windows. Also Russ, it's not hard for any client to take multiple consoles, we so it all the time.

As for ther headless setup, i can't see many parameters have to be set. If its i Casio. You have [diff/sector], mission reduces that to diff/mission, and if you're doing elite co-op each variable could be set with a single number something like passing -e 11432 (i think there are five elite settings, idk, don't use it often)

Buy honestly headless would be the best option. With game master controls or an alternate server control console that allows taking/relinquishing control

As for mission starts/ends because of the nature of Artemis i would suggest missions require a manual start, thus reinforcing the need for a server control console. Dedicated servers should be able to run with or without password protection, and definitely allow presets/rotation if in mission mode

What you could do is put a check box on the opening screen where you set the screen size for "run headless". I would have that flag set it to bypass the Direct3D check, and open a command line window with some sort of ASCII display showing who's linked and the current game settings with a command prompt for the game master to set the parameters and start the game remotely through an SSH log in or through VNC, or from the server side monitor.

You can tell I used to run a mud back in the day. hahah.

@JoeGreene: Yeah, I'd agree, that if you are running an headless server, you are probably doing something more than just helm/weap. However, Game master is still one of the least-likely used clients--unless a mission specifically makes use of the Game Master, then it would have no other function but to set your server parameters--so in that case, why not just make the Game master console the server?--my opinion is to find a better mechanism for setting the parameters.

@lucas99801: I also have run multiple clients on a single PC a lot--my friend and I are usually the only two that can get together for a game, so either I usually run the server on my laptop, or he runs it on his, along with the client for the selected consoles. That is not so much the issue--it's for finding a simplified way of setting game parameters when the server has no direct user interface with the normal Direct3D graphics. Kind of inconvenient, in my mind to have a special client set up somewhere just to set the parameters--but possibly the only solution if you don't have Direct3D on the server.

As I pointed out earlier, a trick to overcome, if no user interface is used, will be having to indicate when to start the game--if the game starts before all clients are ready, bad things could happen. But how would the server know everyone who is going to connect is connected and ready? And what should the server do when the game ends (currently stats are shown, and the user has the option of restarting or exiting)? Those are questions for Thom to work out, if he implements the headless server.

As timechick pointed out, though, all our ideas so far would require some kind of command access to the machine to start the Artemis server, whether it is remote desktop, physical access, SSH, VNC, etc. But there is yet another option: running the Artemis server as an installed Windows service, where it runs constantly (or at least as configured in the service). This would have the advantage of auto-restart if it crashed. It would require a bit of code refactoring on Thom's part to enable this, but it could be done. This design, however, would require that at least one of the clients would be able to configure parameters using Thom's proprietary Artemis protocol (SSH or VNC directly to the service does not really make sense in this case--the entire command structure and SSH/VNC protocol would need coded into Artemis--but coding to work with the existing Artemis protocol would require the least work--at least from Thom's perspective, but would mean he would also have to build the user interface to enable the configurating).

If you run it as a service, you could do something new with the whole game. You can set up world parameters and just let the game regenerate the populations of enemy and friendly ships and bases when they get destroyed. Set a fixed number of each and after a time they re-pop so you can go and kill them again for exp. You could play unlimited at that point. Now wouldn't that be fun? Don't forget to let your crew eat and sleep. lol