Tramway SDK – Half-LifeとMorrowindエンジンの冒涜的な融合
(racenis.github.io)- Tramway SDKは過去3年間にわたって開発されてきたグラフィックパッケージ／フレームワーク／ゲームエンジンで、主流エンジンの高い要求スペックとモノリシックなエディターフローに反対する軽量エンジンを目指している
- UnityやGodotのような主流エンジンは、単純なローポリゲームにも過剰なハードウェアを要求すると見ており、直近15年以内のハードウェアやソフトウェアラスタライズまで実行対象としている
- 制作方式は、ノードGUIとコードを行き来する代わりに、Entityクラスの継承でコードを書き、必要なエディターだけを選んで使う構造
- レベル制作はQuake式のブラシワークフローを基盤に、
.map変換器、ライトマップ、Gouraudシェーディング、Source式の入出力システムを活用する - オープンワールドストリーミングと、3D RPG Makerに近いRPGフレームワークを目標としているが、まだ初期開発段階のため、APIの不安定さや未実装要素を考慮する必要がある
Tramway SDKが狙う問題
- Tramway SDKはグラフィックパッケージであり、フレームワークであり、ゲームエンジンでもあり、“T̈ra̦m̊ẅa̦ÿ SD̈K”というヘヴィメタル風の表記も併用している
- 主流エンジンへの批判はTurbobloatに集中している
- Unityは非常に強力なハードウェアと多くの電力を要求すると見ている
- GodotはUnityより少し良いが、それでも比較的性能のあるハードウェアが必要だと見ている
- ローポリホラー・ローグライト・デッキビルダー・シミュレーターのようなゲームは、15年前のハードウェアでも十分に実行できるべきだという立場
- Tramway SDKはTurbobloatがないため、直近15年以内のほぼすべてのハードウェアで実行できるとうたっている
- グラフィックカードなしでも動作するよう、ソフトウェアラスタライズへ切り替え可能
- トースターや冷蔵庫のような機器にグラフィックを表示する例まで挙げている
- 「もっと良いコンピューターを買えばいい」という反論には、3つの理由で対抗している
- 多くの人には強力なハードウェアを買う余裕がないという購入可能性の問題
- コンピューターチップの生産は環境に悪く、ソフトウェアが肥大化していなければ、故障して修理不能になったときだけ新しいハードウェアを買えばよいという電子廃棄物の問題
- すでに問題なく動作するコンピューターがあるのに、他人のTurbobloatのために新しいコンピューターを買う理由はないという立場
制作方式と機能
- ノードベースの制作方式は、「1つのもののように見える複数のもの」を扱わなければならず、ノードGUIとコードの間を行き来しなければならない点で批判の対象になっている
- Tramway SDKでは、Entityクラスを継承してコードを書いたうえで、レベルエディターでレベルを作ればよい
- ノードを使わず、エンティティ中心で構成する
- コードとノードGUIを行き来する流れを避ける
- 主流エンジンのモノリシックなエディターも問題視している
- 使わない機能まで含むエディター全体がロードされるのを待たなければならないと見ている
- Tramway SDKのエディター群はすべて任意
- フレームワークとしてだけ使うならC++ランタイムだけを使用できる
- レベル制作だけが必要ならレベルエディターだけを使用できる
- データファイルは空白区切り値の形式なので、エディターなしで手作業で修正することもできる
- グラフィック面では、ライトマップとGouraudシェーディングだけでもサンプル画像を作れる
- このサンプルはDirect3D 7レベルのグラフィックカードの固定機能パイプラインでもレンダリング可能
- レベル制作はQuake系のブラシベースワークフローに対応している
- Tramway SDKは
.mapファイル変換器を提供し、ブラシを三角形メッシュに変換する - Trenchbroomでレベルを作成し、Tramway SDKのレベルエディターで設定する流れを示している
- エンジン内でライトマップが適用されたレベルをレンダリングする
- Sourceに似た入出力システムで、レベル内のエンティティ間の相互作用を設定できる
- 将来的にはSourceのlogic entity全体を実装し、レベルエディター内でビジュアルスクリプティングできるようにする計画
- Tramway SDKは
- RPG方面では、RPG Makerのようなツールや、MorrowindベースのMOD・トータルコンバージョンで多くのものをデータ変更によって作れる点を興味深い事例と見ている
- Tramway SDKには、3D向けRPG Makerに近いRPGフレームワーク拡張がある
- エンジンは最初からレベルストリーミングに対応するよう設計されており、オープンワールドRPG風のゲーム制作を素早く簡単にできると見ている
- まとめると、Tramway SDKはQuake/Sourceスタイルのエンティティベースゲームエンジンであり、オープンワールドストリーミングやRPGフレームワークのような任意の拡張を提供する
- 開発状況はまだ非常に初期段階
- APIが不安定
- 機能が壊れていたり、動作しなかったりする可能性がある
- まだ実装されていない要素が多い
- 急速に改善中だとしている
- GitHubリポジトリ: racenis/tram-sdk
1件のコメント
Hacker News のコメント
「単にもっと良いコンピュータを買え」と言う人もいるだろうが、だからこそ、もっと良いコンピュータを買うのが悪いことだという点には全面的に同意する。多くの人、特に発展途上国の人々は Turbobloat を動かすためのハードウェアを買う余裕がなく、チップ生産は環境に悪影響を及ぼす。
現代のソフトウェアがそこまで肥大化していなければ、既存のハードウェアが壊れて修理不能になったときにだけ新しく買っていただろう。ちゃんと動くコンピュータがあるのに、他人の肥大化したソフトウェアのせいで新しいコンピュータを買う理由はないし、そのお金があれば Dr. Pepper を1000缶買うことだってできる。本当に良いプロジェクトなので、進捗を投稿し続けてほしい。
もちろん娯楽用途なら判断は難しく、古い Game Boy のほうが1000Wの最新ゲーミングPCより面白いこともある。
「一つは一つでなければならない。一つのふりをした複数であってはならない。ノードを使うと、複数の集まりを一つのふりにしなければならない」という文は、本当に Terry Pratchett っぽくて素晴らしい。
Sam Vimes が複雑な捜査をしながら思い浮かべそうな文で気に入ったし、今後も発展してほしい。まだ自分では試していないが、自分の AI プロジェクト に活用できそうなアイデアがある。
人間は身体部位の集まりで、身体部位は化学物質の集まりで、化学物質は分子の集まりで、分子は原子の集まりだが、それでも各段階で一つとして見る。それをできなくするのは筋が通らない。それでもプロジェクトは格好よく見える。
そして Vetinari の エンティティコンポーネントシステム は複雑に見えるがきちんと動き、いまいましい都市を回している。
ノードエディタのユーザー体験が、
FingerたちのVectorのようなものに属性や関係を付与するよう促すが、結局Vectorは「ものの集まり」にすぎず、それ自体の振る舞いを持つ「種類」ではないためコードを付けにくい、という意味なのかと思った。「すべては Entity であり、ただコードを書け」というのは、
Vectorよりも Fingers を含み、独自の状態と振る舞いを持つ Hand クラスを作る方向だという意味なのか気になる。あるいは、特定の静的な値と関係メンバーをあらかじめ束ねたノードインスタンスを作るのではなく、Entity のサブクラスをさらに継承して、より具体化しろという意味なのかもしれないとも思う。Godot の Node/GDScript 構成は、この主張への一種の応答と見ることができる。
$演算子や自動補完などによって、その「行ったり来たり」をできるだけ滑らかで統合されたものにしようとする試みだ。それでも最終的にはゲームをリリースしなければならないので、「一つは一つ」という考え方が最後には勝つと思う。時間が経つほど、ゲームエンジンの品質を下げる外部の力があるように思える。技術全般で広く普及するものは、たいていカリキュラムを作りやすいものだ。
Unityのようなノードベースのエディタは、複数回の授業にわたって説明するのに構造がちょうどよい。逆にraylibのようなエンジンは午後半日もあれば理解できるので、大学レベルのraylibの授業は成立しにくい。だからブートキャンプ系の学校からUnity/Unrealしか知らないアマチュア開発者が出てきて、企業がUnity/Unreal人材を採用し、大学がまたそれを教える、という循環が生まれる。Javaが人気である現象にも似ている。
また、会社ごとにUnityプロジェクトの要件は違うので、Unityは不満を抱えた一人のプログラマーではなく、顧客を相手にする営利企業としてエンジンを合わせ続けなければならず、結局Turbobloatになる。Half-LifeとMorrowindのエンジンは、情熱的なプログラマーたちが自分たちのかっこいいと思うものを開発するために給料をもらっていた独特の状況だったので、プロのゲーム開発者に合った最小限のエンジンと優れた技術が生まれた。
このプロジェクトはraylibとUnityの間あたりに見える。アマチュアプログラマーに訴求するには物足りず、小さなエンジンを求めるプログラマーにはやりすぎなのではないかという心配もある。自分が間違っていればいいのだが、性能と完成度は良さそうに見える。Unityに疲れた開発者は確実にいるし、ノスタルジアの周期が2000年代に移るにつれて、Half-Life 2ほどグラフィック的に複雑ではないゲームを遊び、作りたいという需要も実際にある。Webデザインとドキュメントのトーンも良い。
両方を一緒に設計すれば、追加した機能を積極的に活用できるし、苦手な機能は避けたり、そもそもアートスタイルをエンジンに合わせたりできる。Minecraftのピクセル化された角ばったモブはエンジンとよく合っているが、より精巧に作り始めると、十分なポリゴンでまともにレンダリングされるようになるまでは、かえってMinecraftより古く不格好に見える不気味の谷に落ち込む。
人々が複雑さを好む教授に間違って教わったからUnityを使っているわけではないと思う。
Epic GamesがFortniteにしたことを見ればいい。滑らかに動いていた競技シーン中心のゲームを、Turbobloatなグラフィックとスキンのために潰してしまった。
ターボ肥大化の問題には全面的に同意する。今のマシンははるかに強力なのに、ほとんどのプログラムはむしろ昔より遅く感じる。
プロジェクトも非常に素晴らしいし、WebサイトのデザインはA+だ。
Windows 98/2000/XP時代に普通のハードウェアを使っていた立場からすると、SSD付きの安価な現代のノートPCでWindows 10/11/KDE/Gnomeなどを動かすほうが、vscodeやSlackのような肥大化しているとされるWebアプリを実行しても、はるかに反応が良い。
単に「非常に肥大化している」という意味なのか気になる。サイトをさらに読んでみると「超現実的な物理シミュレーション」のような表現もあったので、結局「非常に肥大化している」という意味のようだ。
「Unity製ゲームの大半は、派手なシェーダーやノーマルマッピング、その他の手法を使っても非常に見栄えが悪い」という見方は、特定の世代のあいだでますます一般的になっているように思う
何らかの種類のテクスチャマッピング技術が失われたのは確か。Ikarugaの背景は必要以上に素晴らしく、序盤の単純な森のエフェクトは特にそう。PS2時代の一部の鉄道シミュレーターもこれを実現していた。
ただし、太陽のように強い指向性の光源が光沢のある物体を照らし、プレイヤーが動くと、この方式は破綻する。曇った環境で動的オブジェクトがまったくないなら、現代的な小細工のかなりの部分は迂回できる
もともとSilent Hillの設定は、最適化の小技を正当化するために作られたものだった。画面上のオブジェクト管理を容易にするため、「霧の空間」という恒久的に霧がかった空間を置いたのに、リメイクは超自然的に見える霧ではなくリアルな霧を作ろうとして、膨大な処理を浪費している
見栄えを良くするための美術的な技術はまったく失われておらず、ただ非常に不均等に分布しているだけ。優れたモデラー、テクスチャアーティスト、アニメーター、ビジュアルプログラミング能力を持つチームなら、UnrealでもUnityでも自社エンジンでも見事に見せられる
Super Mario Sunshineで、GameCubeがレンダリングできなかった「シャープな」影には、実際には平たいメッシュが使われていた。Delfino PlazaのShine Gate近くのひさしの下の影はテクスチャではなくメッシュ。一方、そのメッシュ影が置かれたタイル広場が良く見える理由は、巨大なテクスチャ1枚ではなく、数十枚の128x128pxテクスチャをきちんとUVマッピングしているからだ。
現代のゲームなら、レンガのテクスチャ2枚とそれらを混ぜるノイズパターンを使い、3つとも2048x2048pxで、影はレイトレーシングで鋭いエッジを作っていただろう。皮肉なことに、VRAMとバス速度が増えたのに、私たちはより多くのテクスチャではなく、より大きなテクスチャを選んでいる。ノーマルマッピングも同様で、より細分化されたモデルと併用するのではなく、ノーマルマップは古臭く、すべてのディテールを実際にモデリングすることこそ技術的に進んだ道だと勘違いしている。角ばりの少ない球体は良いが、球のすべてのひびや傷まで実際にモデリングするのは愚かで計算資源の無駄だ
Factorioのような「2D」ゲームでも、初期リリース、1.0、現在のバージョンのあいだでポリッシュの差は非常に大きい。Mod入りのゲームでもこの差は明確で、Modのアセットはたいてい「使える」ものではあるが、本編ほど磨き込まれて見えない
最近Half-Life 2をやり直してみたが、高解像度テクスチャパックなしでも今見てどれほど素晴らしいかに驚いた
光沢のある表面も大半は光りすぎないので、それも助けになっている。こうした選択は、古びて占領された極端なディストピア世界によく合っていて説得力があり、落ち着いた色調のテクスチャが全体をまとめている
Valveは技術的制約の中でディテールを入れ、最大限引き出すことにリソースを集中し、20年が経った今でもまとまりがあり、よく設計された姿のまま残っている
Godotでローポリゲームを作る小さなチームで働いている立場から見ると、これは素晴らしい
「ノードで何かを作るときは、ノードGUIとコードのあいだを行き来し続けなければならない」、「主流エンジンには単一の巨大なゲームエディタがあり、どの機能を使うにしても全部がロードされるまで10分待たなければならない」という話は大いに刺さる。Godotでも派手な機能はほとんど使っていないのに、デバッグループが他の環境でプログラミングするときよりずっと遅く感じられた。
1つのデータファイル仕様を中心に複数のエディタが連携して動くというアイデアも良い。統合IDEは複数の開発者がマージコンフリクトを起こしやすくするので、より具体的な目的のエディタは、役割ごとの開発者が変更範囲と性質を制限する助けにもなり得る。エンジンがどう発展していくのか楽しみだ
性能の低いネットブックでも自分の分を貢献できた。C#は1行も書いたことがなかったが、コマンドラインでのTDDを諦める気はなかった。可能だと分かり、最終的には動くようにした。みんな私のことをおかしいと思っていたし、スポンサー企業の開発者リレーション担当者たちも何の助けにもならなかった。
その週末で最大の摩擦は、相変わらず一番良いコンピュータが忌々しいUnity IDEを起動して再起動するのに永遠の時間を費やさなければならなかったことだった。人々が耐えている足かせには驚くばかりだ
「Turbobloat」や、エンジンが「肥大化している」という言い方をしているが、ある程度は正しい。ただし、それが本人にとって何を意味するのか、どの機能を肥大化と見なし、Tramwayプロジェクトから何を外したのかを説明する価値はある
例えば、人によってはRPGフレームワークを含めることも肥大化に見えるかもしれないが、Tramwayにはそれが入っている
C++の「使ったものに対してだけコストを払う」という原則が好きだ
「C++が怖い、あるいは単にできない初心者のためのフレームワークの使い方」と書かれているけれど、私は後者で、Getting Started ページにはありがたみを感じた。
ティーポットが表示され、自分には理解できないだろうと思っていたことを理解できた。今は昼休みの30分しかなく、チュートリアルを終える時間はないが、続けたいと思えたこと自体が、このドキュメントがどれだけ面白く、取っつきやすいかをよく示している。
Design Patterns ページを見つけた人いる？ 目標100%のスコアボードなんだけど、すごく気に入っている。