ゲーム観察

わざと不完全なカーネル：RocketWerkz はいかにして BRUTAL をエディタ無しのゲーム基盤として開き、Ludeon の RimWorld Unity 離脱を助けたか

小光 · 2026-10-21

Ahwoo/RocketWerkz が BRUTAL を公開：エディタ・シーングラフ・レンダラ無しの C# 基盤、NuGet 分包とスコープ逸脱 PR の却下。Ludeon は helped make Waylith possible と謝し、RimWorld 1.7 テストは約 2��4 倍。

保存した記事 ↗

ここ十数年のインディーの定石が「まず Unity プロジェクトを開き、シーンツリーに物を置く」だったとすれば、2026年10月中旬に重なった二つの公式発表は、その定石を横から押した。10月12日、Ludeon Studios は RimWorld 1.7 を自社エンジン Waylith へ移すと発表し、社内テストでは性能が約2〜4倍になったとした。三日後、Ahwoo と RocketWerkz は複数の自社タイトルを支えてきた C# フレームワーク BRUTAL を GitHub に置き、NuGet パッケージごと公開した。

私は GitHub の README、Ludeon 公式ブログ、Dean Hall の r/gamedev 長文を転載した GameFromScratch、そして Game Developer の10月19日付報道を突き合わせた。固まっている事実は多くない。BRUTAL は自らをフレームワークと呼び、完全なエンジンではないと書く。エディタもシーングラフもレンダラもなく、それらを足さないとも明記している。Ludeon の謝辞は慎重で、Brutal framework が "helped make Waylith possible" とある。Waylith を可能にした助け、という言い方だ。公式文はエンジン全体を RocketWerkz への外注だとは書いていない。

本稿を貫くイメージは「わざと不完全」だ。宣伝文句に聞こえるが、コードとライセンスに落とすと、検証可能な拒否のリストになる。

一、業界の既定、エンジンがアーキテクチャ選択を先に済ませる

長いあいだ、インディーや中小スタジオはエンジン選びをプラットフォーム選びのように扱ってきた。Unity、Unreal、後の Godot はそれぞれエディタ、シーングラフ、アセットパイプライン、スクリプトモデル、既定の描画経路を連れてくる。プロジェクトを開いた時点で、すでに他人の世界仮定の中にいる。カメラの付け方、Prefab の生成、物理がどの層で Tick するか、GC があるフレームで頭を上げないか。そうした問いは、しばしばゲームプレイより先にエンジンが答えている。

大半のプロジェクトではこの既定は妥当だ。「まず絵、それから遊び」の敷居を下げ、採用や外注の共通語にもなる。困るのは別種のゲームだ。宇宙飛行シミュは実スケールで位置を追う必要がある。コロニーシミュは後期に数千エンティティと大量モッドを同じフレーム予算に押し込む。鉄道や百科型の作品は古典的シーングラフを要しないこともある。Dean Hall は r/gamedev の長文（GameFromScratch が全文転載）で率直に書く。現代の汎用エンジンは平均ケースに合わせて調整されており、ゲームが平均から遠いほど、開発時間は「ゲームに何が要るか」より「エンジンの仮定に合わせる」へ食われていく、と。

RocketWerkz 自社の Kitten Space Agency はその平均から遠い例だ。公開資料で繰り返し出るのは位置表現、描画タイミング、メモリ割り当てのリズムだ。Hall によれば BRUTAL はおよそ四年で育ち、少数のライブラリから、ゲーム全体やエンジン全体を支えられるフレームワークになった。当初は外から見ると赤旗に近く、社内でも秘密だった。2026年10月にはすでに KSA を直接支え、Ludeon の Waylith にも入っている。

既定と BRUTAL の分岐点はここにある。完全なエンジンはアーキテクチャ選択を先に済ませる。BRUTAL は選択を返し、「まず自分が何をしたいかが分かっている必要がある」を製品の気質に書き込む。Hall 自身も認める。人によっては難しさが増すが、自分たちが作りたい種類のゲームではかえって速い。エンジン作者の意図を何週間も読み解き、その仮定を迂回する必要が減るからだ。

二、拒否リスト、エディタ無し、逸脱 PR の却下、必要な NuGet だけ

README は「BRUTAL ではないもの」を機能一覧よりはっきり書く。エディタもシーングラフもない。レンダラも範囲外で、足さないと明記する。社内の「もっと足せ」圧力にも抵抗する。明確な用途から外れた Pull Request は却下される。理由は硬い。何でも詰め込んだ結果が、自分たちが使いたくない種類のエンジンだ、という主張だ。

これは姿勢だけの話ではない。検証可能なパッケージ構成に対応する。リポジトリの各トップレベルフォルダが一つのライブラリで、それぞれ NuGet として出る。`Brutal.Core`、`Brutal.Interop`、`Brutal.Memory`、`Brutal.Collections`、`Brutal.Strings`、`Brutal.Concurrency`、数学と数値、ログとローカライズに加え、Vulkan / OpenGL、GLFW / SDL、Dear ImGui、FMOD / OpenAL、RakNet、Jolt / Box2D、glTF とテクスチャデコードなどのバインディングがある。必要なものだけ参照すればよい。入門例は Core と Glfw だけで、グラフィックス API 無しのウィンドウを開ける。描画、デバッグ UI、ジョブ、音声、ネットワークは次に自分で繋ぐ。

中核はカスタム interop 層で、現代の C# からネイティブ API と高性能 C/C++ ライブラリ（Vulkan を含む）へ直接届く。周辺ライブラリは割り当てと余計なオーバーヘッドの削減に執着し、有用なところでは unmanaged メモリと unsafe を使う。README の前提は .NET 10 SDK、描画するなら Vulkan 1.3 対応 GPU、公開で挙がるプラットフォームは現時点で Windows と Linux だ。

わざと不完全には二層ある。機能境界ではシーンを描かず、ノードも並べない。レンダラも自分で書く。工学単位では能力を選び取れるパッケージに分け、丸ごと積まなければ動けない巨石にはしない。Hall は Linux カーネルと Ubuntu の関係に譬える。厳密ではないが意図は伝わる。BRUTAL が基礎を出し、配布形態のエンジンは各チームが作る。Kitten Space Agency は BRUTAL の上に直接建つ。Ludeon はその上に Waylith を建てる。

Ahwoo のエンジニアリング責任者 Rian Drake は通稿で名前の由来を言い切る。BRUTAL と呼ぶのは、使うと時に過酷だからで、先にそう言っておきたかった、と。ガードレールはない。自分が組んだシステムと犯した誤りに責任を持ち、同時に直し切る権限もある。GamingOnLinux など二次報道がこの一節を伝える。Drake は続けて、誰もがこの道具でゲームを作るべきだとは思わない、とも言う。

Game Developer 配図、Kitten Space Agency と BRUTAL

三、Waylith の場面、「助けた」とエンジン丸ごと外注のあいだの言葉

Ludeon の10月12日ブログは、この技術ニュースでいちばん措辞を詰めるべき一次資料だ。アップデート 1.7 は RimWorld を Unity から Waylith へ移す。Waylith は Ludeon 自社エンジンと明記される。見た目と遊びは同じで、テストでは性能が約2〜4倍。後期コロニーのストレステストは 1.6 比で約 2.2 倍。1500 モッドのパックは読み込みが14分から6分へ。セーブは 1.6 と 1.7 を行き来できる。大半のモッドは作者改修なしで動く。末尾の謝辞は thanks to RocketWerkz, whose Brutal framework helped make Waylith possible だ。

helped という語が重要だ。公開の語りでは、Waylith はなお Ludeon のエンジン判断と実装の産物だ。BRUTAL は低レイヤの C# フレームワーク能力を出し、Unity の残りを剥がす助けになった。Ahwoo の通稿（複数媒体が転載）も近い言い方で、Ludeon used BRUTAL to help extract the last bits of Unity out of RimWorld to create their Waylith engine と書く。RimWorld のエンジン全体を RocketWerkz へ外注した、と読むのは公式文と合わない。資料観察としては、Ludeon が Waylith を自作し、BRUTAL は謝辞を受けた低レイヤフレームワークの一つ、とする方が安定する。

モッダー向けに Ludeon はいくつか変化も列挙する。新しい C# 言語機能が使える。複雑なモッドを書いても性能を潰しにくい。大きな見た目変更や独自エフェクトへ手が届きやすい。二十人超のモッダーが Waylith 公開前のテストとフィードバックに参加した。これらの細部は、エンジン移行が描画バックエンドの付け替えで終わらないことを示す。後期コロニーに巨大モッドリストを載せた、RimWorld がいちばん高い道筋を、保守可能な .NET スタックへ打ち直している。

README のプロジェクト表は利用関係を並べる。RimWorld / Ludeon / Waylith。Kitten Space Agency、Torpedia、Art of the Rail、Gruntz は RocketWerkz が BRUTAL 上に直接構築。Afterskies は Floating Origin Interactive。Ahwoo 通稿はさらに、三スタジオ六タイトルを現在支えているとも言う。Kerbal Space Program の Felipe Falanghe が KSA で協力し、次作でも BRUTAL を使う、という記述もある。Unity から BRUTAL への感想は、最初は少し怖かったが、一度入ると自分が作ったものをすべて所有し、動き方も分かる、というものだ。

四、ライセンス、独立性の標語、わざと不完全の使い方

BRUTAL は商用ゲームでも無料で、ロイヤリティも売上配分もない。ライセンスは MIT を基に帰属要件を足したものだ。クレジット相当に著作権表示を入れ、プレイ開始前に BRUTAL ロゴを出し、NOTICE.txt を同梱する必要がある。条件を満たしたくなければ別途商用ライセンスを交渉できる。非営利、およびロゴ表示が用途を損なう場合は README 上でロゴ免除があり得る。ライセンスはまだ OSI 未提出で、チームは提出とコミュニティフィードバックでの改訂を意図すると書く。一部の二次報道はそのため source-available と呼ぶことを好む。一次の README はなお open source と自称し、MIT 系文書と fork 可能性を根拠にする。本稿本文では README の自称に合わせてオープンソースと書き、OSI 状態は出典注に置き、未承認を承認済みと書かない。

Hall は物語を一文で打つ。You are only as independent as your tools are。独立の度合いは、道具がまだ自分の言うことを聞くかに掛かる。同時に境界も補う。誰もが自前エンジンを作れとは言わない。誰もが、四年かけて基礎を積まずにその選択肢を持て、と言う。Game Developer 報道は 2025 年の Unity ライセンス紛争の公開背景にも触れ、Hall が BRUTAL を業界単一標準にするより、似た発想のより単純なフレームワークが他からも出てほしいと望む、とも伝��る。

インディーにはこの標語が励ましに聞こえやすい。BRUTAL の実体に落とすと、もっと雇用契約に近い。手に入るのは interop、割り当てを抑えたコレクション、ジョブシステム、Vulkan バインディング、自分で配線する原生ライブラリの列だ。開いた瞬間に遊べるプロトタイプになるエディタ体験は得られない。公開 README は、ソースからビルドするためのプロジェクトファイル、ソリューション、ビルドスクリプトはまだ途上で、当面は NuGet を使い、リポジトリは読む・fork するために使う、とも書く。Indie Tooling など二次整理は、公開当日に文書サイトが一般公開されていなかった可能性、macOS・コンソール・モバイルが現行 README の明確な約束に入っていない点も指摘する。これら端は資料観察として選定リストへ入れ、成熟した一式約束として書かない方がよい。

だから、インディーにとっての「わざと不完全」の実行意味は具体的だ。まず自分のゲームが平均ケースから遠いかを見る。普通の 2D / 3D コンテンツ向けなら、Godot や Unity、より完成度の高いフレームワークの方が命を削らないことが多い。ボトルネックが明らかに割り当て、ジョブ、ネイティブ連携、自前レンダラなら、BRUTAL の分包が値段を出し始める。Glfw か SDL で窓を開け、痛みのある Memory / Collections / Concurrency だけ足す方が、初日に自前エンジン全貌を夢想するより設計に近い。LICENSE と NOTICE を読み、ロゴとクレジットをリリースチェックに入れる。Waylith の公開数字は激励にはなるが、自分の予算表にはならない。Ludeon には既存の遊び、モッド生態、何年もの C# がある。自分のチームにあるとは限らない。

結び、独立は「何をしたいか先に知る」ところで値付けし直される

BRUTAL を 2026 年秋の制作現場に戻すと、まず叩くのは静かな制作慣性だ。エンジンが先でゲームが後、アーキテクチャはエディタのウィザードに任せてよい、エンジン離脱は巨大スタジオだけの話、という既定だ。RimWorld 1.7 と BRUTAL 公開が同じ週に重なり、別の道を広げた。フレームワーク上で直接ゲームを作る人もいる。その上に自前エンジンを建てる人もいる。どちらも、バインディングを繋ぐ前に要件を書き下ろす必要がある。

Hall は Reddit 長文で、いちばん重要な決定の一つは BRUTAL に何を入れないかだ、と言う。逆に読んでもよい。インディーにとっていちばん高い決定は、しばしば何を持ち込まないかだ。既定システムが一つ減れば、理解できないまま迂回しなければならない仮定も一つ減る。自前責任が増えれば、問題が起きたときに根まで直す権限も増える。どちらも過酷だ。BRUTAL は少なくともその過酷さを名前に書いた。

実行用の短い指針は次のとおりだ。

まず三つのリストを書く。ゲーム自身が決めなければならないアーキテクチャ、既存エンジンに委ねてよい部分、チームが維持し切れるネイティブ境界。三つが噛み合わなければ、まだ BRUTAL に触る段階ではない。
NuGet で最小実験をする。Core とウィンドウ用パッケージで窓を開け、痛みに応じて Memory、Collections、Concurrency、Vulkan 抽象を足す。週末で、自前スタックがエンジンへの合わせ込みより本当に速いかを見る。
LICENSE を読んでから企画する。クレジット、起動ロゴ、NOTICE.txt をリリース検査表に入れる。免除が必要なら書面で取り、発売直前に気づかない。
Ludeon の謝辞では helped を見つめる。自前エンジンはなお自分の製品判断だ。フレームワークは四年分の基礎コストを下げるだけで、遊びと中身は自分で担う。

十月の二つのニュースは汎用エンジンを消さない。道具がまだ自分の言うことを聞くか、という値付けをやり直しただけだ。その値段を払う人には、少なくとも読めるソース、選べるパッケージ、README にすでに書かれた警告がある。名前は BRUTAL だ。社交辞令ではない。