マルチプレイヤーの概要

マルチプレイの全体像

Factorio はシングルプレイの印象が強いですが、 マルチプレイヤーにも本気で対応しています。
数人で協力して工場を組むのは、 1 人プレイとはまったく違う楽しさがあります。
ベルトを引いた次の瞬間、 隣で誰かが鉄鉱石を補充してくれている、 という体験は意外と中毒性が高い。
デフォルトは全員協力プレイで衛星を載せたロケットを打ち上げる CO-OP のフリープレイシナリオ、 PvP マップなどの追加シナリオは Maps and Scenarios フォーラムから入手できます。

実プレイでは、 2-4 人くらいが最も波風立たずに進むサイズ感です。
5 人を超えると分業をきっちり決めないと、 ベルトが衝突したり、 誰かの未完成施設を別の人が解体したりといった事故が増えがちで、 序盤の鉄板や銅板の供給を 1 人が独占してしまって他のメンバーが手持ち無沙汰になるパターンも頻繁に起きるので、 役割分担と地理的な縄張りはセッション開始前に口頭で合意しておくのが平和です。
100 人サーバーは確かに存在しますが、 これは別ジャンルだと割り切った方がいいです。

サーバーの 3 形態

マルチプレイの構成は大きく 3 つあります。
自分でプレイしながらホストする形式、 専用 (dedicated) サーバーを建てる形式、 既存ゲームに参加する形式。
friend と数時間遊ぶなら最初の形式で十分ですし、 24 時間動かしっぱなしの大規模工場を回したいなら 2 番目が必要になります。
経験上、 4-6 時間以上のセッションになると、 ホストの PC 負荷でだんだん UPS が落ちてくるので、 専用サーバーへの移行を検討する閾値はそのあたり。

ホスト側の準備

メインメニューから Multiplayer を選び、 ホストとしてプレイするためのオプションを設定します。

• Host new game: 希望するシナリオを指定し、 マップ生成設定を調整し、 サーバーの表示設定を行います
• Host saved game: リストからセーブを選び、 同じく表示設定を行います

サーバーの表示設定 (visibility) はゲームが他プレイヤーにどう広告されるかを決める設定です。
Public はパブリックゲーム一覧に掲載され、 蒸気 は 蒸気 の Join Game 機能と連動、 LAN はローカルネットワーク上だけに表示されます。

参加側の選択肢

既に動いているゲームに参加する場合は、 次のいずれか。

• Browse public games: 条件に合うパブリックゲームを検索
• Browse LAN games: ローカルネットワーク上のゲームに参加
• Connect to address: サーバーの IP アドレスを直接入力

Connect to address はホストが表示設定を使わずに非公開で建てている場合に役立ちます。
友人グループだけで遊ぶ時は、 これでアドレスを共有するのがいちばん手っ取り早い。

通信回りの基本

技術的な前提として、 全プレイヤーは まったく同じゲームバージョンと MOD 構成 で揃える必要があります。
デフォルトポートは 34197、 プロトコルは UDP のみ。
ゲームは UDP の上に独自の信頼性のある配信層を構築し、 パケットロスや順序入れ替わりを吸収しています。

UDP パケットがファイアウォール、 アンチウイルス、 ルーターのいずれかでブロックされていると、 「ホスト側からは LAN ゲームが見えているのに、 別 PC からは見えない」 みたいな症状になります。
一部のルーターはアウトバウンドパケットの送信元ポートをランダム化していて、 これが NAT 配下のクライアント同士の通信を破壊する地味な事故の温床になっていて、 「Factorio だけ繋がらないが 蒸気 のフレンド機能は動く」 みたいな現象は大抵このランダム化が原因なので、 ルーター設定で source-port preservation を有効にすると一発で直ることが多いです。
プレイヤー上限はハードリミットで 65,535 人ですが、 実用は 100 人未満が現実的なラインです。

専用 (ヘッドレス) サーバー

--start-server コマンドラインオプションで起動できます。
factorio --help を実行すれば、 Factorio が受け付ける全引数の一覧が出ます。
通常のゲームバージョンでもヘッドレスモードで動きますが、 Linux 環境ではグラフィックを含まない Headless パッケージを使う方がダウンロードサイズが小さく、 また Xlib や libGL に依存しないのでクラウド VM でも動かしやすいです。

ヘッドレスモードの挙動

ヘッドレス起動の特徴は次のとおりです。

• グラフィックは初期化されない (起動が速く、 メモリ使用量も低い)
• コマンドラインで渡したセーブを読み込んで即座にゲーム開始
• サーバーにはゲーム内キャラクターが存在しない
• プレイヤーが接続していない間はゲームは一時停止 (no-auto-pause で上書き可)
• 終了時にゲームを自動保存 (通常のオートセーブも別途行われる)

0.13 以降は --start-server の後ろにセーブファイルのパスを指定する形式です。
セーブが必須なので、 起動前にセーブを作っておく必要があります。
--create 引数で簡単に作れます。

初回セーブの作り方

実プレイで初めて Linux 専用サーバーを立てる時、 「セーブが無いと起動できない」 「セーブを作るには起動が必要」 という鶏卵問題に詰まる人をよく見ます。
解は次のように --create を使う流れです。

./bin/x64/factorio --create ./saves/my-save.zip
./bin/x64/factorio --start-server ./saves/my-save.zip

1 行目で 「New Game ボタンを押した相当」 のセーブを作り、 2 行目でそれをホストします。
これで完結します。

設定ファイル 3 種

サーバーやマップの挙動を変えるのに、 JSON 設定が 3 種類あります。

• map-gen-settings: マップ幅・高さ、 鉱石パッチの頻度やサイズなどマップ生成パラメータ
• map-settings: 汚染の広がり方、 ビターの拡張と進化
• server-settings: コマンドラインオプションを 1 ファイルにまとめたもの

各サンプルは data サブディレクトリに同梱されています。
GitHub の wube/factorio-data でも最新版を確認できます。
大規模サーバーを運営している人ほど、 この 3 ファイルを git で管理して PR ベースで運用していたりします。

サーバー起動時の指定

--map-gen-settings と --map-settings は新マップ作成時に --create と一緒に使います。

./bin/x64/factorio --create saves/my-save.zip \
  --map-gen-settings my-map-gen-settings.json \
  --map-settings my-map-settings.json

起動時には server-settings.json のパスも指定します。
デフォルトでは Factorio の data フォルダにあります。
「最新セーブで起動」 はこんな形。

./bin/x64/factorio --start-server-load-latest --server-settings ./data/server-settings.json

Windows なら .bat ファイルにまとめると便利です。

start /wait .\bin\x64\factorio.exe --start-server-load-latest --server-settings .\data\server-settings.json

Linux サーバーの構築

Factorio は現在 glibc 2.31 以降が必要です。
CentOS/RHEL 7 は 2.17 しか提供していないので、 glibc を手動で組まないと動きません。
実用上は Ubuntu 20.04 以降か Debian 11 以降を選ぶのが楽です。
ガイドは /opt/factorio にヘッドレスサーバーを入れる前提で書かれていますが、 別パスでも問題ありません。

パッケージ選択

Linux 向けには通常のフルゲーム版とヘッドレス版の 2 種類があります。
ヘッドレス版にはグラフィックやサウンドが含まれず、 Xlib、 libGL、 libasound に依存していないので、 ライブラリが揃っていないサーバー環境でも素直に動きます。
サードパーティのホスティングサービスを使う場合はこちらを選びます。

基本インストール手順

選択したパッケージをサーバーの /tmp にアップロード、 /opt/factorio に展開、 専用ユーザーを作成して所有権を移す、 という流れです。

$ cd /opt/
$ sudo tar -xzf /tmp/factorio.tar.gz
$ sudo useradd factorio
$ sudo chown -R factorio:factorio /opt/factorio

root で実行するのは避けます。
動作確認は次のように。

$ su factorio
$ /opt/factorio/bin/x64/factorio --start-server savename

savename.zip が見つからないエラーで止まれば、 ここまでの導入は OK です。
自前セーブを /opt/factorio/saves に置くか、 --create で新規作成します。

マッチングサーバーへの掲載

公開サーバーリストに載せるには、 セーブの場所だけでなく追加の情報が必要です。
これらは server settings file に書きます。
推奨手順は data/server-settings.example.json をコピーして編集する形。

設定可能な主要項目は次のとおり。

• Name: サーバーブラウザに表示される名前
• Description: 最大 5,000 文字の説明
• Tags: ゲームタグのリスト
• Max Players: 同時接続上限 (0 で無制限)
• Visibility: public / LAN / hidden のいずれか
• Auth: factorio.com の username + password、 または認証トークン
• game_password: サーバーパスワード

セキュリティ観点では、 認証トークンを使う方が安全です。
ただしトークンも機密情報なので、 ファイルパーミッションは厳重に。
chmod 600 推奨。

技術的な仕組み

開発チームが Friday Facts で公開している技術詳細はいくつかあります。

• Lock step architecture: 全クライアントが同一シミュレーションを走らせる
• Client-server connections: 0.12.4 で導入されたサーバー中継
• NAT punching: 0.13 で導入

DNS SRV レコード対応

Factorio は 1.1.67 以降で DNS SRV レコードをサポートします。
Nintendo Switch 版はサポート外。
これにより 1 台のホストに複数の Factorio サーバーを立てて、 ポート番号入力なしに別サブドメインで接続できます。
サービス名は _factorio、 プロトコルは _udp のみサポート。

Domain: subdomain.domain.tld
IP: 192.0.2.2
Port: 10002

DNS:
  subdomain.domain.tld IN A 192.0.2.2
  _factorio._udp.subdomain.domain.tld IN SRV 0 0 10002 subdomain.domain.tld.

Cloudflare で SRV レコードを設定する場合は、 GUI 上で 「サービス: factorio」 「プロトコル: UDP」 と指定するだけで済みます。
verbose ログで DNS SRV lookup returned [...] が出ていれば成功、 didn't return any usable records が出ていれば設定漏れです。

ロックステップ・アーキテクチャ

マップ上での活動量が膨大になりうるため、 ゲームエンジンはロックステップ方式を採用しています。
全インスタンスが世界全体の完全なシミュレーションを実行し、 ネットワーク上で送られるのはプレイヤーの操作だけ。
これがマルチプレイで巨大工場を動かしても帯域が膨らまない理由です。
一方で、 1 人でも desync (同期外れ) を起こすと全員が影響を受けるので、 MOD のバージョン不一致には強い制約があります。

レイテンシ隠蔽

0.12.0 から、 一部のプレイヤー操作をローカルで先読みする「レイテンシ隠蔽 (latency hiding)」 が導入されました。
キャラクターの移動など、 結果がほぼ確実な操作は即座に画面に反映され、 サーバー応答を待たずに済みます。
ただし車両の運転、 戦闘射撃などは対象外です。
高遅延の海外サーバーでも、 ベルト設置や移動が遅延を感じにくいのはこの仕組みのおかげ。

マルチプレイのちょっとした Tips

実プレイで知っておくと差が出る小ネタを並べます。

チャットとコマンドの区別

コンソールキー (GRAVE) はチャット開始キーと共用です。 マルチプレイでコマンドを実行したい時は、 先頭に/cを付ける必要があります。 実行されたコマンドは全プレイヤーに見えるので、 チート系を使う前に一声かけるのがマナー。 そもそも--allow-commands` で許可されていないサーバーではコマンドが弾かれます。

/color r g b で自分の色を変えられます。
r, g, b は 0 から 1 の範囲です。

/color 0.2 0.8 1.0

これで水色っぽくなります。
RGB 0-255 換算で書きたいなら、 各値を 255 で割って小数にします。
視認性を考えると、 マップ上で見える色は背景と被らないものを選ぶのが無難です。

管理者権限の付与

自分に管理者権限を付ける場合、 factorio-current.log と同じディレクトリに server-adminlist.json を作る必要があります。
中身はこう。

[ "user1", "user2" ]

このファイルはコンソールからプレイヤーを昇格させると自動生成されます。
最初の 1 人だけは手動で書く必要があって、 そこから先は GUI 経由で増やせる、 という二段構えになっています。

マルチプレイへの参加方法

0.13 以降、 ポートフォワード無しでも参加できるようになっています。
蒸気 経由か、 ポートフォワード済みホストに直接接続するか、 のいずれか。

参加経路の選択

参加経路はいくつかあり、 状況によって最適解が変わります。
サーバーのパブリック IP を知っているなら、 Play -> Multiplayer -> Connect to server から IP とポートを入力する直打ち経路がいちばん確実で、 ソーシャルメディアや Discord で IP を共有する場合の標準ルートです。
サーバーリストから参加するには Play -> Multiplayer -> Browse public games で Factorio.com にログインしてから一覧を表示する流れで、 多くはパスワード必須ですが完全公開のサーバーもあります。
ちなみに、 大規模 MOD 入りの常設サーバーはこのリストに登録されていることが多く、 上位のものは数日単位で安定運用されています。
蒸気 経由ならポートフォワードもアドレス共有も不要で、 フレンドリストから直接 Join できるので一般プレイヤーには最も簡単な方法、 同じネットワーク内の友人と遊ぶなら Play on LAN を選べば遅延もほぼ無いので PvP の真剣勝負にも向いています。

NAT 越えと中継

Factorio はクライアント-サーバーモードで、 サーバーが公開可能な IP を持つか、 全員が同じ LAN にいるかが前提です。
NAT 配下の場合、 ポートフォワード設定をするか、 Hamachi などの仮想 LAN ソフトを使う必要があります。
サーバー経由でパケットが中継されるので、 1 ホップ余分にかかり遅延は少し増えますが、 NAT 配下のホストと外部クライアントが混在する構成でも一応動きます。

PvP モード

PvP では、 プレイヤーは異なるフォース (勢力) に属します。
各フォースは 1 人 (FFA) でも複数人 (チーム) でも構成可能。
各フォースは独立した研究を持ち、 軍事ユニットと構造物は停戦が無い限り他プレイヤーを攻撃します。

シナリオの選び方

シナリオによっては停戦が一方向のみになっている場合があり、 「こっちは停戦したのに相手は攻撃してくる」 という事態が普通に起こります。
PvP に入る前には、 そのシナリオの停戦ロジックを確認しておくと事故が減ります。
PvP シナリオは Play メニューから選ぶか、 カスタムシナリオをダウンロードしてシナリオディレクトリに置きます。

手動でフォースを作る

コンソール経由で手動作成もできます。
任意のマップを PvP 化したい時に使えます。

game.create_force("Name")
game.players["Player_name"].force = game.forces["Name"]
game.forces["Name"].set_cease_fire("Other_force_name", true)
game.forces["Name"].set_spawn_position({x = 10, y = 20}, game.surfaces[1])
game.print(#game.forces)
for name, force in pairs (game.forces) do
  game.print(name)
end

事前作成された PvP シナリオほど便利ではありませんが、 細かい調整は効きます。

フォースを跨ぐ相互作用

敵フォースの構造物にも、 一部は手動干渉が可能です。

• Manual pickup from belts: 対立フォースのベルト上アイテムを手で拾えます。
  ただしインサーターは取れません
• Belt network connection: ベルトはフォースに関係なく接続するので、 相手の搬送線を延長してアイテムを流せます
• Fluid network connection: パイプも同様に接続。
  相手のタンクから流体を抜くことも
• Power leeching: 対立フォースの電力ネットワークから電力を引ける、 電柱カバレッジに入ると自動で繋がる

意外と緩い仕様で、 完全な隔離はできない設計です。
PvP マップを設計する側は、 これを踏まえた配置になっています。

履歴と進化

ナラティブな歴史

マルチプレイは 0.11.0 で導入されました。
当時は P2P 接続のみで、 全員が互いに直接通信可能である必要がありました。
0.12.4 でクライアント-サーバーモードが導入され、 サーバーがメッセージを中継するように変更。
これで全員直接接続が不要になりました。
0.13 以降、 P2P 接続は完全削除されています。

バージョン履歴 (抜粋)

メンテナノート: 以下は完全に最新かつ網羅的ではない可能性があります。

• 0.14.14: Autosave only on server オプション追加、 デコン時に last user セット
• 0.14.10: 32bit (x86) マルチプレイ無効化、 全員 64bit 必須
• 0.14.8: 10 人超セッションでサーバー保存頻度を低下
• 0.14.0: 遅いクライアントでゲームが止まらないように、 desync 3 回で自動退出
• 0.13.10: stdout メッセージにタイムスタンプとタグ追加
• 0.13.0: マルチプレイの UX 改善、 P2P モード削除、 建築音が他プレイヤーにも再生
• 0.12.30: MOD のチェックサム比較で desync を防止
• 0.12.4: サーバー中継方式の導入
• 0.12.0: レイテンシ隠蔽、 ヘッドレスサーバー、 基本 PvP、 IPv6、 DNS 名対応
• 0.11.0: マルチプレイヤー初導入

歴史を見ると分かりますが、 0.11 - 0.14 のあいだに大きなネットワーク刷新が連続しています。
安定したのは 0.15 以降で、 1.0 リリース時点ではほぼ完成形になりました。
2.0 でも基本構造は変わっていません。