VPS as a test Game Server

Hello,
I recently finished the frame of my game server; it runs correctly and I can connect clients to it. Now the next step would be hosting; I figured I'd use a very cheap VPS to test everything, but I am very inexperienced when it comes to network architecture and server concepts.

So here is my question : if I rent a small vps (like these https://www.ovh.com/world/vps/), can I build my server for linux as headless, upload it through FTP and run it on the VPS to connect my clients ?

If so, which distribution would you advise? (Drupal, Virtualmin, a "clean" debian distro...)

Thanks in advance!

 

Yes that works. I run a really small demo on a free google cloud f1-micro instance that uses 0.2 VCPUs, so 20% of one CPU.
I recommend Ubuntu, because that's what Unity officially supports for linux.

 

Thanks a ton ! Regarding the distribution, OVH offers the option to include Docker (an Ubuntu management app) to your vps for free; any chance it might be useful for a non-experienced user like me ? Or just a ressource waste ?

Also, I would assume the process of starting the server once uploaded should be pretty straight forward but I can't find the ressources I'm lookign for; is there any documentation about starting and interacting with a live app on a remote server ?
(basically reading the Debug.Log through SSH )

 

You just ssh into the box and start the game server in the background. I usually specify a location for the logfile as well.

Code (csharp):

1. ./master_server.x86_64 -logFile logs/master_server.log -batchmode -nographics &

Also, the easiest way to copy your game over is to create a tar.gz file and scp it to the server, rather than setting up your own ftp server.

One other thing, if you don't build in a way to remotely shut down your game server, you will need to kill the running game server process whenever you want to restart it or upgrade the build. So I recommend building in some means of remotely shutting it down. But until then:

Code (csharp):

1. killall master_server.x86_64

 

Thank you very much, that does clarify things !

 

Do you think you could make a mini guide on how to upload to google compute instance? I have a linux server, but I can't figure out how to upload the folder to google compute instance or how to run it. I would really appreciate it.

 

Haven't used Google compute, but I'd assume it has ssh access like any Linux server. So in that case you just take your build and compress it as a tar.gz file, SCP it to your server, then on the server you decompress it. To launch it you first set execute permissions on the executable. Then you can launch it with ./yourbuildname.x86_64 like any linux executable, or do it in the background like I mentioned comment #4.

If you're using Windows you can create tar files with 7zip, compress the tar file to a tar.gz with the windows version of the command line gzip tool, and scp the file by getting PSCP. To SSH get a copy of Putty.

On linux you can decompress with gunzip command, untar with the tar command (I think you can tell it to uncompress at the same time as untar all with the tar command, but I've been in the habit of doing it as a 2 step process for so long I don't really care to change my ways ), and you set execute permissions with chmod.

7zip is a GUI based tool, but everything else can be done with command line something like this below. (you can probably find a Windows port of the tar command line tool, I just haven't looked)

On Windows: (you may need to add the file paths to the commands if they aren't added to your path variable by their installers, and obviously I'm including a fictitious IP address which you replace with your server's IP or hostname)

Code (csharp):

1. gzip mybuild.tar          <---- Compress the tar file
2. pscp mybuild.tar.gz myusername@266.266.266.266:              <------ Upload the tar.gz file, don't forget the colon at the end

On Linux after you SSH in:

Code (csharp):

1. gunzip ./mybuild.tar.gz          <---- Uncompress
2. tar -xf ./mybuild.tar          <---- untar the build
3. chmod +xrw ./mybuild.x86_64          <---- I'm adding all permissions here, but you probably only really need to set execute with +x
4. ./mybuild.x86_64 -batchmode -nographics &          <---- The ampersand means to run it as a background process, and don't forget to include the "./" at the beginning which seems silly if you're used to the command line in Windows, but is necessary here

To later kill your game server you can use the killall command by name, or the kill command to kill it by ID. But the best way is to build into your game a way for you to remotely tell your server to itself call application.quit.

Also note that people have their own favorite compression tools, or maybe GUI tools which implement traditional command line tools, etc. So there's of course other ways of doing it. But tar.gz compressed files, using scp for file copying, and Putty to SSH into your server have been the standard approach with Linux servers for a long time.

 

Thank you so much for that. Looks like I need to study more on bash, Linux, and SSH. I got my server up and running in 5 minutes after reading that when I couldn't get it up earlier after trying for hours. I couldn't find any tutorials or anything online, especially not for specific cases. Google has its own upload file thing so I didn't have to use SSH or scp though I may want to familiarize myself with that in case I use a Linux server elsewhere. I now am having trouble connecting to the server external ip, it could be a port problem or something, hopefully I get it working. Also, do you know of any good resources where I can learn more about server hosting and the like? Can be for AWS or anything.Thanks again for the help .

 

See if Google's service includes a firewall you need to configure, and may need to set which ports are open. Most firewalls you configure TCP and UDP ports separately, so make sure you configure the correct one for your network API.

On the hosting resources, I can't help there, as I learned all my Linux stuff on the job in an IT type role like 15 years ago, and I haven't been a fan of the cloud providers since they are overpriced for the resources you get (except the loss leader free tiers I guess).

 

Yup, configured the firewall and opened ports for both udp and tcp. Works like a charm (minus some latency). I see, no worries. Really appreciate your time helping, made my day.