Waylithへの移行で変わること
RimWorldの開発元Ludeon Studiosは、アップデート1.7でゲームエンジンをUnityから自社開発のWaylithへ切り替えました。ゲームの見た目やプレイ感は従来どおりとしつつ、同社のテストでは処理性能が2〜4倍になったとしています。
Waylith版1.7は、現在Steamの不安定版ベータブランチで試せます。通常プレイに使われるメインブランチは、告知時点では1.6のままです。
改善の対象はゲームの起動、MODを多く入れた場合の読み込み、マップや世界の生成、ゲーム内の処理速度などです。終盤のコロニーを使ったテストでは1.6比で2.2倍、1,500個のMODを含む構成では読み込み時間が14分から6分になりました。
セーブとMODは引き継げる
1.6のセーブデータは1.7で読み込めるほか、1.7で保存したデータを1.6に戻して使うこともできます。バージョンを切り替える際に、セーブデータの変換作業は必要ありません。
MODも大半は作者による変更なしで1.7に対応します。バージョン番号の変更だけを理由に「未対応の可能性あり」と表示される場合があり、MOD作者は動作確認後に1.7対応のバージョンとして公開するよう案内されています。
一方、10年以上前のPCでは1.7が動作しない可能性があります。Ludeon Studiosは、問題が起きた場合に開発用Discordへ知らせるよう呼びかけています。
ticks per secondが示す処理速度
RimWorldの「tick（ティック）」は、ゲーム内で状態が変化する際の処理単位です。通常速度では現実の1秒あたり60ティックが進み、ゲーム内の1時間は2,500ティックで構成されています。
ゲーム速度を上げると、1秒あたりに実行しようとするティック数も増えます。Dubs Performance Analyzerの説明では、通常の1倍速で毎秒60、2倍速で180、3倍速で360ティックを目指し、開発モードの4倍速では900ティックになります。
そのため、tpsが高いほどゲーム内の作業や時間経過を現実の時間内に多く進められます。ただし実際に達成できる速度はPCなどの条件に左右され、高速設定でも必要な処理が追いつかなければ目標のtpsに届かないことがあります。
自社エンジンの強みと開発負担
Game Developerの寄稿者Maxim Kiselevは、自社エンジンなら作品に必要な機能へ合わせて技術を組み立てられる一方、既存エンジンが備える描画、入力、保存などの仕組みを自分たちで用意する負担があると論じています。 機能の範囲を見誤ると開発に長い時間がかかり、ゲームの要件が変わった際にエンジン側の作り直しが必要になる場合もあると指摘しています。
同じ寄稿者は、既存エンジンでは新しい技術や開発者間の知識を活用しやすいのに対し、自社エンジンでは更新や技術統合を自分たちで担う必要があると説明しています。 RimWorldでは、移行後もセーブや大半のMODを使えるようにしながら、ゲームの処理性能を高めたとLudeon Studiosが報告しています。
開発者Rez Grahamは、自社技術を作品に合わせて設計できることや、将来の作品にも基盤を使えることを利点として挙げています。 その一方で、開発には初期の時間がかかり、既存エンジンに関する開発者の知識や、自動的に得られる技術更新を利用しにくくなるとも述べています。 RimWorldで実際にどれだけ開発負担が生じたかは、発表されたテスト結果からは分かりませんが、MOD作者向けには新しいC#言語機能や複雑なMODの性能面での利点が案内されています。
Waylithを使う新作も開発中
Ludeon Studiosは、WaylithがRimWorldだけでなく、開発中の新作にも使われると明らかにしました。新作の詳細を共有できるまでには、もうしばらく時間がかかるとしています。
アップデート1.7のベータ版は、不安定版ブランチを選択して試せます。メインブランチは1.6のままなので、試用する場合はSteamのライブラリでRimWorldのプロパティを開き、ベータ設定から「unstable」を選びます。
Ludeon Studiosは、問題の報告先として公式開発Discordを案内しています。また、Waylithの登場に向けて20人を超えるMOD制作者がテストとフィードバックに協力したとしています。
