Space EngineersのDedicatedサーバをWindowsで構築する

内容について

ほとんど以下の公式ページに書いてあります。
http://www.spaceengineersgame.com/dedicated-servers.html

SpaceEngineersのサーバを立てる際に自分がやった内容を残しておきます。
とはいえこのゲームをやるEngineerならこの程度は問題とならないような気もしますが、手間を省く一助となれば幸いです。
ちなみに、Dedicatedサーバはゲームクライアントを起動せず、スタンドアローンのサーバアプリケーションのみを起動して使うものになります。

確認環境

この内容は全て以下の環境で確認しています。
特にSpaceEngineersはBeta版での確認となるため、仕様が変更となる可能性が大きくあります。

  • SpaceEngineers 01.168 Stable
  • Windows10 64bit

Dedicatedサーバのインストール

SteamクライアントでダウンロードするゲームアプリケーションにもDedicatedサーバが同梱されていますが、ここではSteamCMDでダウンロードする方法をとります。

SteamCMDの準備

以下からSteamCMDをダウンロードして、適当な場所に解凍。
https://steamcdn-a.akamaihd.net/client/installer/steamcmd.zip

ダウンロード/アップデートバッチの作成と実行

「steamcmd.exe」と同じディレクトリに以下の内容のバッチファイルを作成。
名前は任意なので、ここでは例として「SE_inst_updt.bat」とする。

※「C:\SE」の部分はDedicatedサーバのインストール先となるため。任意に変更する。
※app_updateで指定するIDはここを参照。

@echo off
start "" steamcmd.exe +login anonymous +force_install_dir "C:\SE" +app_update 298740 validate +quit

作成後、バッチを実行し、終わるまで待つ。

以上で、インストールは完了。

サーバの起動

サービスへの登録を行う場合、以下の作業はAdministrators権限のあるユーザで行うこと。

サーバ管理アプリケーションの起動

[(バッチで指定したインストールフォルダ)\DedicatedServer64\SpaceEngineersDedicated.exe]を起動。

インスタンス選択画面

インスタンス(サービス/OS起動時の自動起動)を設定するか否かで以下の手順が異なります。

インスタンスを作成しない場合

「Lcal/Console」を選択して「Continue to Server Configuration」を押す。

インスタンスを作成する場合

「Run as Admin」ボタンで管理者権限を与えて、「Add new instance」ボタンからインスタンス名を決めて作成。
その後、作成したインスタンスを選択して「Continue to Server Configuration」を押す。

サーバ設定画面

ここの設定値については、ドキュメントが見つからなくってよくわからない部分が多い。

とりあえず、新規にワールドを作るときは以下になる。
1. Nwe gameを選択
2. Scenarioを選択
3. Server portが標準のUDP27016意外であれば変更(当然ですが、NAT等でインターネットからアクセス可能であること)
4. Server nameを入力(サーバリスト上で表示される)
5. World nameを入力(サーバリスト上で表示される)
6. 適当にその他の設定値を入力。
7. Save & startでサーバを起動

これで、ゲーム上のサーバリストから見えて、サーバに入ることができる状態になっている。

以前に作成したワールドを再度起動する場合

Saved worldsと、起動したいワールド名を選択して起動。

インスタンスで自動起動されるワールド

最後に起動したワールドが自動起動で使用されているように見えるが、設定場所も正確な記述もわからなかった。

アップデート

SpaceEngineersは定期的にアップデートがあり、ほとんどの場合、新しいクライアントから古いサーバへはアクセスできなくなる。
そのため、ある程度定期的にサーバのアップデートが必要になると思われる。
サービスを停止してバッチを動かすだけのため、自動化もむすかしくはなさそう。

アップデート方法

サーバをサーバ設定の「Stop」ボタンで停止し、インストール時に使用したバッチファイルを実行する。

Modの設定

ワールド内で、ワークショップで公開されているModが使用できる。

ModのIDを調べる

ワークショップのページから適当に入れたいModを探しページを開く。
URLの後ろの方の[id=]の後の数字をメモする。

サーバ設定

サーバ設定のModタブに入力する。
複数の場合は改行して入力していく。

あとは起動すればModの内容が使用可能な状態となっており、クライアントが接続するとクライアント側で必要なModのデータがダウンロードされるようになる。
一度ダウンロードすれば2度目以降は差分のみとなるため、素早くサーバに入れる。

適用されないMod?

ブループリントとスクリプトはサーバで指定しても出てこないっぽい?
クライアントでサブスクライブしてれば使えるから?

グループメンバーのみが入れるように設定する

サーバは公式のリストに載せられてしまうため、そのままだと誰でも簡単に入ってこれる状態となる。
しかし、Steamで作成したグループのメンバーのみがサーバに入れるよう設定することができる。

グループを作成

Steamクライアントからであれば、以下で作成画面に行ける。

  1. (ユーザ名)->グループを選択。
  2. 「新しいグループを作成」をクリック。

グループを作ったら、サーバに入れるようにしたいユーザを招待する。

グループIDを調べる

グループ管理画面から「フレンドを招待」をクリックし、その後のページのURLの「invitegid=」の後の数字列がグループID。
(例)http://steamcommunity.com/profiles/???????????/friends/?invitegid=(グループID)

サーバ設定

サーバ設定の「Steam Group IDに調べたグループIDを入力して起動。

Ubuntu16.04にnginx-rtmp-moduleを入れてRTMP配信をする

最終的にストリーミングキーにパスワードを入れる簡易認証について書くのですが、全て一つの投稿にすると長くなるのでまずは前段の環境構築から。
[追記] RTMPSできないと中間者攻撃対策できなくて、nginx-rtmp-moduleで対応していないということもあり一旦保留。

RTMPについて


ストリーミングでデータをやり取りするためのプロトコルで、ここでは映像をライブストリーミング(生放送)するために使用する。
通常利用するポートはTCP 1935番。

NginxでRTMPを扱うためのモジュールが公開されており、ソースに追加してMakeすることで利用可能。

確認環境


  • ubuntu 16.04

インストール手順


必要パッケージのインストール

makeするために必要なものを一通り準備。

sudo aptitude install build-essential libpcre3 libpcre3-dev libssl-dev unzip

Nginxのソースとrtmpモジュールをダウンロードしてmake/install

mkdir -p ~/work/nginx
cd ~/work/nginx

wget http://nginx.org/download/nginx-1.11.7.tar.gz
wget https://github.com/arut/nginx-rtmp-module/archive/master.zip

tar -zxvf nginx-1.11.7.tar.gz
unzip master.zip

cd nginx-1.11.7/

./configure --user=www-data --group=www-data --with-http_ssl_module --with-http_realip_module --add-module=../nginx-rtmp-module-master

make
sudo make install

サーバ起動時に自動起動するためSystemdにサービスとして登録

sudo vi /lib/systemd/system/nginx.service

/lib/systemd/system/nginx.service

[Unit]
Description=The NGINX HTTP and reverse proxy server
After=syslog.target network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/local/nginx/sbin/nginx -t
ExecStart=/usr/local/nginx/sbin/nginx
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Nginxの設定

RTMPと、テスト用のプレーヤーページを用意。

sudo vi /usr/local/nginx/conf/nginx.conf

/usr/local/nginx/conf/nginx.conf

worker_processes  1;

user  www-data www-data;
pid        /run/nginx.pid;

events {
    worker_connections  1024;
}

rtmp {
    server {
        listen 1935;

        application app {
            live on;
            record off;
        }
    }
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    server {
        listen 80;
        server_name  localhost;
        #デフォルトのルートディレクトリは /usr/local/nginx/html
        #変えるのめんどいのでそのまま使う
        location / {
            root   html;
            index  index.html index.htm;
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
        index index.html index.htm;
    }
}

テスト用のプレーヤーページを作成

テストなのでCDNのvideo.jsを利用させていただき簡易的に作る。

sudo vi /usr/local/nginx/html/live.html

/usr/local/nginx/html/live.html

<!DOCTYPE html>
<html lang="en" class="">
<head>
    <title>Test Live</title>
    <link href="//vjs.zencdn.net/5.11/video-js.min.css" rel="stylesheet">
    <script src="//vjs.zencdn.net/5.11/video.min.js"></script>
</head>
<body>
    <video id="player" class="video-js vjs-default-skin" height="450" width="800" controls autoplay preload="auto">
        <source src="rtmp://(サーバのIP or ドメイン)/app/StreamKey" type='rtmp/mp4' />
    </video>
    <script>
        var player = videojs('#player');
    </script>
</body>
</html>

一応、所有者を変更しておく。

sudo chown www-data:www-data /usr/local/nginx/html/live.html

Nginxの起動と自動起動設定

sudo systemctl start nginx.service
sudo systemctl enable nginx.service

OBSで配信する際のURL指定


OBSClassicを使う場合は以下の値をいい感じに設定。

設定 -> 放送設定
FMS URL : rtmp://192.168.30.16/app
プレイパス/ストリームキー : StreamKey

使用方法は別途調べてください。

視聴


HTML5が見れるWEBブラウザで以下を開く。

http://(サーバのIP or ドメイン)/live.html

もちろん、配信していないと何も再生されないので注意。

TeamSpeak3をセットアップする時に使うクエリ

TeamSpeak3を立て直す時に、いつも同じようなクエリを叩くので残しておく。

ローカルからTelnetでTS3のクエリポートにアクセス


telnet localhost 10011

ログイン


パスワードはTeamSpeak3の初回起動時に表示されるやつ。
トークンと間違えないよう注意。

login client_login_name=serveradmin client_login_password=パスワード

バーチャルサーバを選択


デフォルトは1。
複数ポートで運営している方は適当に変更。

use sid=1

公開リストにサーバ情報を載せない


デフォルトだとサーバ立ててることをどこかのリストにおっぴろげてしまうらしい。
特定の用途や趣味により立てるのであれば、以下でオフにしたほうが良いかも。

serveredit virtualserver_weblist_enabled=0

ビューワからクエリで情報を参照できるようパーミッションを設定


TSStatusを使ったときのパーミッション設定。

servergroupaddperm sgid=1 permsid=b_virtualserver_info_view permvalue=1 permnegated=0 permskip=0
servergroupaddperm sgid=1 permsid=b_virtualserver_channel_list permvalue=1 permnegated=0 permskip=0
servergroupaddperm sgid=8 permsid=b_virtualserver_servergroup_list permvalue=1 permnegated=0 permskip=0
servergroupaddperm sgid=8 permsid=b_virtualserver_channelgroup_list permvalue=1 permnegated=0 permskip=0
servergroupaddperm sgid=1 permsid=b_virtualserver_select permvalue=1 permnegated=0 permskip=0

もしそれでもパーミッションが足りなくて「failed_permid=25」みたいなエラーが出る場合は以下を参照して適当に追加。
https://www.tsviewer.com/index.php?page=faq&id=12

ビューワからのクエリは時間による回数制限がかかるため、無制限にするならホワイトリストにIPを追加しておくこと。

  • /(TS3のインストールディレクトリ)/query_ip_whitelist.txt

セッションを切る


quit

ownCloudとPydioをいっぺんに使ってみての比較

ownCloudとPydioは、ファイルの同期・共有が可能なWebアプリケーションのPHP製パッケージです。
ownCloudはDropboxライクな感じで、Pydioはビジネス用途向けなことをよく言われるようです。

具体的には以下のようにして両方を使ってました。

  • ownClowdをさくらインターネットのVPSに導入して、サイズの小さいファイルの同期管理
  • Pydioを自宅サーバに入れて、それなりの大きさがあるファイル(100M~1G)をやり取り

で、結論から言うと、基本的な機能は同じなので単にファイルのやり取りに使うだけであればどちらも大差なかったです。

しかしそれ以外の管理面などでは結構違いがあるので、私の使った範囲で特徴を上げるとしたら、以下の点となります。

  1. ストレージ領域の考え方

    ownCloudはユーザアカウント、Pydioはワークスペースが中心

    スライド1

    ファイル保存のために割振る領域の扱い方が、それぞれの大きな違いになっています。
    ownCloudはユーザそれぞれに1つの領域が割振られます。Dropboxを使ったことがあるなら、ほぼ同じだと思っていいです。
    Pydioは「ワークスペース」という領域に対してユーザのアクセス権を割振ることで複数の領域を使用する事ができ、容量制限などの設定もワークスペース単位でできます。

  2. 共有についての考え方

    ownCloudは領域の一部を使い、Pydioは新たな領域を作成

    スライド2

    ownCloudはユーザ領域の特定ディレクトリを他ユーザに公開することで共有を可能にします。
    Pydioは領域を新たに作成し、それを共有対象のユーザから見えるようにします。
    ownCloudの共有の場合、容量は共有元のユーザの領域が使われるため、大量にデータを入れる目的に使用しにくい部分があります。
    目的や用途によって領域を作れるPydioは、このあたりがビジネス用途向けらしい感じ。

  3. 設定

    ownCloudは設定が少なく、Pydioは多い

    ownCloudはGUIから設定できる項目が少なめで、構築はとても楽にできるようになっています。
    逆に、Pydioには設定項目が多数あり、導入要件に対応したチューニングが可能となっていました。

  4. プラグインのリリース

    ownCloudはコミュニティでのプラグイン公開が盛ん

    どちらもプラグインによる機能拡張に対応しており、特にownCloudは有志の開発者によってリリースされているプラグインが多数公開されています。
    ownCloud Applications – apps.ownCloud.com

    Pydioは検索しても公式以外で公開しているものが見つかりませんでした。


  5. ユーザの使いやすさ・日本語への対応

    操作性は大差ないけど、Dropboxと似てるからownCloudのほうが楽かも

    初期の操作性で言えば、ownCloudがユーザとしても使いやすかったです。Dropboxを使ったことがあれば、ほぼ同じですし。
    また、日本語の対応具合もownCloudはほとんど問題ないレベルです。
    プラグインを追加している場合に一部英語が気になるぐらいかと思われます。
    Pydioは日本語の対応が不完全で、インタフェースの操作も最初は慣れが入りますが、ユーザが使用できる機能が多くないので難しくはないと思われます。

  6. 管理・運用

    ownCloudはユーザ任せ、Pydioは管理者の操作が多い

    管理面から言うと、ownCloudはアカウントを作れば後はユーザが勝手にやるのに任せるため、大して手間はかからなそう。
    逆に、Pydioはワークスペースの設定を管理者が行うため、[ユーザが管理者に申請->管理者が操作]のような形になりそう。

個人で少し使う分にはownCloudのほうが簡単そう。
複数人で多目的に使うのであれば、Pydioを入れる価値があるかも。

という感じでした。