2025年にエンジンなしでゲームを作る

355日前原文(noelberry.ca)

概要

20年にわたりゲーム開発を続けてきた筆者の経験と哲学を紹介
UnityやUnrealなどの大手ゲームエンジンを使わず独自ツールを活用する理由を解説
C#を中心としたプログラミング言語選定やSDL3・FMODなどのライブラリ活用法を説明
アセット管理・レベルエディタ・UIツールの自作と既存ツールの使い分けを提案
クロスプラットフォーム開発やLinux移行の実体験を共有

20年続くインディーゲーム開発と独自ワークフロー

エンジンを使わない理由と哲学

Unity や Unreal などの大規模ゲームエンジンを使わず、 独自ツール で開発する理由を重視すること
大手エンジンの 90%の機能が不要 であり、独自のゲーム性や操作感を実現するために自作システムを構築すること
商用エンジンの ビジネス的リスク （方針転換やアップデートによる破壊的変更）を避けるため、ツールコントロールを重視すること
問題発生時に 自力で解決 できる安心感と、将来の 保守性 確保を優先すること
小規模チームや個人開発においては、 必要最小限のツール自作 が効率的であることを提案

ゲーム開発におけるプログラミング言語選定

C# をメインに使用し、かつては C++ も経験したが、C#の進化と利便性を評価すること
2025年のC#は パフォーマンス と 記述性 が大幅に向上し、 ホットリロード 機能も開発効率化に貢献すること
小規模チーム での学習コストの低さや、 リフレクション によるエディタツール開発のしやすさを重視すること
C#のアクセシビリティ が、初心者でも急速に戦力化できる点を強調すること

システムレイヤーとライブラリ選定

SDL3 をクロスプラットフォームな ウィンドウ管理・入力・レンダリング の抽象化レイヤーとして活用すること
SDL3の GPU抽象化 により、DirectX・Vulkan・Metalなど主要APIに対応し、幅広いプラットフォームで動作すること
SDL3の上に 独自C#ラッパー を実装し、プロジェクト間で再利用すること
オーディオには FMOD を採用し、ダイナミックな音声制御が必要な場合は商用ツールも適宜利用すること
必要に応じて MoonWorks 等の代替ライブラリも検討すること

アセット管理とロード戦略

アセットは 必要なときに必要な分だけ ロードする、シンプルな実装を推奨すること
小規模なピクセルアートゲームでは 全アセット一括ロード も現実的であること
大規模アセットの場合は オンデマンドロード・アンロード を実装し、メモリ効率を最適化すること
必要に応じて プリプロセス用スクリプト を自作し、ビルド時にアセット変換を自動化すること

レベルエディタとUIツールの設計

LDtk、 Tiled、 Trenchbroom などの既存レベルエディタを活用しつつ、必要に応じて 独自エディタ も開発すること
ゲームデータとエディタの 密結合 を重視し、特定用途に特化したシンプルなツールを自作すること
UI実装には Dear ImGui を利用し、 即時モードGUI による軽量なエディタツールを高速開発すること
C#リフレクション と組み合わせて、ゲームオブジェクトを自動でインスペクト・編集できる環境を構築すること
複雑なツールが必要な場合のみ、外部ツール（例：Trenchbroom）を併用すること

クロスプラットフォーム対応とポーティング

かつては C#のJIT制約 のためC++への移植やBRUTE等のツールを利用していたが、 Native-AOT の登場でC#でも全主要コンソールに対応可能となったこと
FNAプロジェクト の積極的な貢献により、C#ゲームのマルチプラットフォーム展開が容易になったこと
SDL3 のプラットフォーム抽象化を活用し、幅広い環境で「そのまま動く」設計を推奨すること

開発環境の変遷とLinux移行

開発環境は Windows から Linux へ完全移行し、オープンソース・クロスプラットフォームツールの活用を推進すること
Windowsの ビジネスモデルや操作性 への不満からLinuxへの移行を決断したこと
一部Microsoft製品（VSCode、C#、GitHub等）は継続利用しつつ、 Linuxユーザー増加によるオープンソース対応拡大 を期待すること
日常的なゲームプレイも Steam Deck などLinuxベースの環境で完結していること

このように、 大手ゲームエンジンに依存しない開発手法 は、独自性・保守性・柔軟性を重視するインディー開発者にとって、現代でも十分に現実的かつ魅力的な選択肢であると提案します。

Hackerたちの意見

ゲームを「何でもできる」エンジンなしで作る方が、実際には簡単で楽しいし、オーバーヘッドも少ないと思ってる。俺は「何でもできる」ゲームを作ってるわけじゃないし、これらのエンジンが提供する機能の90%も必要ない。そうなると、エンジンなんていらないよね。とはいえ、エンジンの特定の機能に本気で深く掘り下げた時、例えばUnrealの逆運動学やアニメーションブレンディングなんかで、「ああ、数週間かけてゼロからコーディングしなくてよかった」と思ったことがある。ミニマリズムやアンチブロートの主張もあるけど、エンジンが人気なのは、実際にかなりの作業を手伝ってくれるからだよ。

└

アニメーションブレンディングはそんなに悪くないよ。もし二つのポーズがクォータニオンと位置のリストで表現されてるなら、クォータニオンの間をスラーップして、位置の間をレープすればいいだけ。FABRIK IKアルゴリズムは、約100行の関数だよ。

└

昔の俺もこんな感じだった。初めての3Dゲームを作ってた時、入力、オブジェクト管理、カリング、モデル読み込み、数学ライブラリ、グラフィックス、ノーマルマッピング、SSAA...を実装するのに数週間かけたけど、ゲームの進捗は0%だった。でも、趣味の2Dプロジェクトでは、依存なしでウェブキャンバスで自分でやってる。ブラウザをエンジンと呼んでもいいけどね。

└

エンジンを使うことで、インフラを構築するために大きな時間をかけるのではなく、プロジェクト自体の進捗を進められるんだ。車輪を再発明するのは、ほとんどの人にとって楽しくないよね。

└

私の卒業論文は、NeXTSTEP/Objective-CからWindows 95/Visual C++へのパーティクル可視化エンジンのポーティングで、OpenGLをベースにしていて、マーチングキューブのようなサンプルがあった。これは現代のエンジンの機能リストの一つの箇条書きに過ぎない。

└

「ああ、ゼロからそれをコーディングしようと何週間も費やさなくてよかった」と思うよね。もしあなたの目標が独立した開発者として数十年のキャリアを築くこと（OPのように）なら、a) トピックを深く理解するための数週間の投資や、b) 深く理解し、100%所有し、将来のプロジェクトで再利用できるソースコードを持つことは、何の問題もないと思うよ。

└

逆運動学とアニメーションブレンディングこれがゲームの中心的な機能なら、書く価値があるよね。逆に、技術的な無駄遣いなら、必要ないってことだ。

多くの人が、エンジンをゼロから作るのに時間がかかりすぎると言うけど、UnrealやUnityをしっかり学ぶのにどれくらい時間がかかると思う？アイデアを持って、それをゲームにするのに摩擦がないレベルまで。おそらく、エンジンが完成したら、そのレベルの専門知識にすぐに達するから、時間の節約になる。俺の意見では、エンジニアとしての経験が増えれば増えるほど、自分で作る方が時間の観点から有利になる。ゲームがユニークでニッチであればあるほど、これはより真実だよ。UnrealのひどいUIを3ヶ月も彷徨って、やりたいことがエンジンの一般的でオフ-the-shelfな性質のせいでほとんど不可能だと気づくのは、いい経験じゃない。一方で、ハイパーリアルなオープンワールドRPGを作りたいなら、自分で作るのはあまり良いアイデアじゃないと思う。たとえそれが常に最も効率的な方法ではなくても、カスタムメイドの専門エンジンを使うことで自分に制限を設けると、創造性が本当に流れ出て、ゲームが最も進んでいなくても、その結果としてもっとユニークになると思う。

└

2Dゲームを作った経験があるところからスタートして、Unrealでアセットを作るためのチュートリアルやドキュメントをいくつか日間かけて進めた結果、ゲームを作るのにボトルネックになったのはアセット制作だった。Godotでは、数時間でひどいゲームを作れるところまで行った。現代のゲームエンジンがあなたのためにやってくれる作業量は驚異的で、ゼロからエンジンを書くよりも既存のエンジンでゲームを実装する方が早いと主張する人は、自分を騙してると思う。

└

Unrealには詳しくないけど、Unityはゼロからプログラミングするよりもずっと早いよ、簡単に10倍以上。明らかな例は物理挙動で、これをゲームに追加するのに1分もかからないけど、自分のエンジンだと外部ライブラリを適切に統合するのに1日か2日かかる。Noelがここで見せている内部状態の可視化は、Unityではデフォルトで既に組み込まれてる。バウンディングボックスを描いたり修正したりするための良いツールがあって、エンジンの挙動が足りない稀なケースでも、高度に拡張可能（ImGuiやUnityのYogaベースのCSSエンジンを使うのが好き）。Unityには、洗練されたパーティクルエディタ、高度な「一度書けばどこでも実行」できるシェーダー言語、モジュラーデータをストリーミングして追跡するためのシステムなど、数えきれないほどの機能がある。理想的な世界では、こういうものを自分で書きたいけど、時間はどんどん過ぎていくし、残念ながらゲームを早く完成させることを優先したい。

└

ゲーム、グラフィックス、物理エンジンの間には大きな重複があるため、誤解が生じていると思う。グラフィックスは2Dや3Dのレンダリング、シェーダー、シーングラフ、アニメーションなど何でも含まれる。物理や関連するものはシーングラフと相互作用する。ゲーム部分は動的な挙動を可能にし、もちろんゲームロジックやトリガーも含まれる。UIやリソース管理を追加して、最後にもちろんAIも。異なるアーキテクチャを持つ自分のエンジンを作ることは、エンジンがどうやって機能するかを学ぶ最良の方法だが、それに伴うすべての詳細は本当に多くて、一人には多すぎるかもしれない。Unreal Engineの中にどれだけのものが詰まっているか、驚くかもしれないよ。

└

多くの人がエンジンをゼロから作るのは時間がかかりすぎると言うけど、UnrealやUnityをちゃんと学んで、アイデアをゲームにするのにどれくらい時間がかかると思う？たぶん、エンジンが完成したら、すぐにそのレベルの専門知識に達するから、すごく時間の節約になるよ。私の意見では、エンジニアとしての経験が多ければ多いほど、自分のエンジンを作る方が時間の面で有利になると思う。私は一度、自分のゲームエンジンを作る実験をしたことがあるんだけど、約1年かけて作りながら学んだ（試行錯誤で、最初は多くの行き止まりがあったけど）。それには、ゲームに典型的に見られる多くの機能が含まれていた（すべての機能が揃った3Dレンダリング、flexboxに触発された適応型UIフレームワーク、スケルタルアニメーション、セーブファイルフォーマット、スマートオブジェクトシステム、パスファインディング、スクリプト言語、音声、物理などなど）。特に、Braidのシステムを再現しようとしたんだけど（存在を知らずに）、ゲームを任意の時点に巻き戻すことができるんだ。これにはエンジンのすべてのサブシステムのサポートが必要だった - スクリプトや物理を巻き戻すためにね。自分のゲームエンジンの細かい部分をすべて知っていることは確かにプラスだった。エンジンがほぼ完成した後は、どんなに野心的な機能でも追加するのにせいぜい数時間で済んだ。何かがうまくいかなかったときは、何が起こっているのか正確にわかった。でも、1年の構築の後、ちょっと疲れてしまって、続けるモチベーションが消えちゃった :)

└

大きなエンジンでは、無料で得られる素晴らしいものがたくさんあって、自分でやるのは面倒くさいことが多いよね。特にUnityストアなどがあるし。個人的なプロジェクトにはLibGDXが大好きだけど、締め切りが重要な真剣な開発では、ダイアログツリーやUIなど、すぐに使えるものがあって、エッジケースがきれいに仕上がっているのは非常に良いことだよね。もちろん、コンソールとのクロスプラットフォームは、自分で作るのがずっと難しいし、これはしばしば大きな問題になる。こういうことが、Slay the Spireが続編のためにUnity/Godotに切り替えた理由なんだ。

└

あなたのビジョンが変わっているかニッチなものであれば、最初からそれに基づいたツールセットを構築する方が、長期的にはずっと効率的かもしれないよ。

└

エンジンが完成したら、たぶん二度と？明らかに、GameObject.Instantiate(myPrefab, Vector3.zero)が適切に実行されるために必要なことを理解するのは、そんな基本的な操作のために必要なことを実装するよりも、はるかに少ないオーダーの大きさだよね。2D/3D物理、シェーダー、プラットフォームサポートなどのことを考えてみて。もしエンジンを作ることが目標なら、エンジンを作ればいい。もし実際にゲームを届けることが目標なら、ゲームを作ればいいんだ。

└

一方で、ハイパーリアリスティックなオープンワールドRPGを作りたいなら、自分でエンジンを作るのはあまり良いアイデアじゃないと思う。むしろその逆だね。そのジャンルでは、自分でエンジンを作るか、オープンソースのものを選ぶのがベスト。私が実際に経験した問題のリスト：エンジンにはたくさんの機能やオプションがあるけど、同時に使えるものは限られてる。一つの機能が他の機能を無効にしちゃう。エンジンができる素敵なことのリストを見て、でもある時点で、絶対に必要なことができない（または効率的にできない）ことに気づく。あんなに素晴らしいグラフィックも、実際には使えなかったり、パフォーマンスが悪かったり、互換性がなかったりする。特定の機能は「ベイク」モードでしか動かない。エンジンエディタで「ベイク」して、ゲームの実行時にそれを変更する方法はない。Unrealはこの点で最も制限があるけど、Unityもあまり良くない。一部のゲーム開発者は、Unityの内部アセットフォーマットを逆アセンブルして、実行時に機能の動作を変更できるようにしてる。その時点で、自分でエンジンを作る方が理にかなってくる。私が見た例では、開発者がライトプローブグループのアセットファイルを逆アセンブルして、実行時に新しいライトプローブグループを追加できるようにしてた。エンジンのAPIはバージョンごとに大きく変わる。すべてのコードやスクリプトは常にリファクタリングが必要。壊れるバグにぶつかると、唯一の解決策はアップグレードだけど、アップグレードすると全コードベースが壊れちゃう。エンジンの抽象化を通り抜ける必要があって、運が悪いとそれが効率的にできないこともある。この例として、UnityのHDRPはスクリーンスペースの環境オクルージョン（他のエフェクトも含む）を適用する。全画面にエフェクトを適用するから、キャラクターの三人称視点や一人称の手や武器が描画されるときにも影響が出る。その結果、一人称の手や武器の周りに白いハローができて、見栄えが悪くなる。カスタムエンジンでは、解決策はシンプルで、フルスクリーンエフェクトを一人称の手が描画される前に適用して、その後に手をエフェクトなしで描画すればいい。数行のコードの順序を入れ替えるだけの話。解決策はGitHubとBSD/MIT/Apacheライセンスのゲームエンジンやライブラリだね。

└

多くの人が、エンジンをゼロから作るのは時間がかかりすぎると言うけど、UnrealやUnityをちゃんと学ぶのにどれくらい時間がかかるのか、アイデアを持ってそれをゲームにするのにどれくらい時間がかかるのか、2つの異なる質問をしてるよね。もし半端なアイデアをくれたら、両方のツールを使って数時間でプレイできるようになるよ。Unityは最初にプログラミングが必要だけど、Unrealはブループリントだけで「ほぼゲームを出荷できる」ところまで行ける（特にシングルプレイヤーゲームの場合）。ここ[0]には、誰かが10分でスーパーヘキサゴンスタイルのゲームをプロトタイプする10分の動画があるよ。もちろん、何を作るかを正確に知らないとこれは実現できないけど、これがこれらのツールがゲームアイデアを作るのにどれだけ強力かを示してると思う。そこにはコンポーネント以外のUnity特有のものはほとんどなくて、他は「ゲーム開発に依存しない」ものだと思う - 入力処理、updateとfixedUpdate、ベクトル数学、スプライトなど。スポーナーのプレハブはその動画の中で唯一のUnity特有のもので、10分の動画の中で約15秒を占めてる。俺はゲーム開発者（Unreal）だけど、Unityで似たようなプロトタイプを1時間ほどで作れると思うよ、前後して[0] https://www.youtube.com/watch?app=desktop&v=p8MzsDBI5EI

└

でも、UnrealやUnityをちゃんと学ぶのにどれくらい時間がかかるのか、アイデアを持ってそれをゲームにするのにどれくらい時間がかかるのか？エンジンを作るだけのゲーム開発の知識があるなら…それなら、プロトタイプを作り始めるのにこれらのことを学ぶのは本当に1日くらいだよ。習得するには時間がかかるけど、ゲームに取り組むのが目的なら、ターンアラウンドタイムは全然違うから。

自分の（2D）ゲームエンジンを約5年間作ってきて、関連する仕事もしてきたけど、多くの人があまり気づいていないことを説明したいんだ。エンジン自体は簡単な部分なんだよ。実際の重要な部分は、エンジンの周りにあるツールやコンテンツ、アセットパイプラインなんだ。考えてみてほしいんだけど、実装しなきゃいけないことはたくさんあるんだよね：- 様々なソースやフォーマットからデータをインポートすること、テクスチャ、音声、gltfやfbxのようなモデルファイル、アニメーションなどなど。- 期待される標準的な編集機能を持ったエディターアプリ、カット、コピー、ペースト、アンドゥ、リドゥ、保存、削除などなど。- ゲーム開発者がエディターを使って実際にデータやエンティティ、アニメーション、シーン、音声グラフ、スクリプトサポートなどを作成・操作できるようにするための視覚化や操作。- 静的ジオメトリのベイク、シェーダーのコンパイル、テクスチャや音声のリサンプリングとパッキング、ゲームコンテンツアセットパックの作成などのデータパッケージングやベイキング。- などなど。これはエンジン部分を活用するために必要な機能や作業のほんの一部に過ぎないんだ。これらがすべて終わると、実際のゲームエンジン（つまり、ゲームのメインループやサブシステムを実装するランタイム部分）は、実は全体のシステムの中ではかなり小さい部分だってことがわかるんだ。だから、ゲームスタジオは通常、エンジンに取り組む比較的小さなチームと、全体の成功にとって超重要な隣接作業を扱う「ツール」プログラマーの大群を持っているんだよね。[1] https://github.com/ensisoft/detonator

└

最近、続編のためにエンジンをリライトしたんだけど、これにはすごく同意するよ。私のポストモーテム[1]では、こう書いたんだ：> ほとんどの人は「ゲームエンジン」をゲームの実行可能ファイルに同梱されるコードだと思っている。でも、それは半分に過ぎない。もう半分は、ゲームに同梱されていないコード - レベルエディター、コンテンツパイプライン、デバッグ/プロファイリングツール、開発ワークフローなどなんだ。ツールを書くことは、エンジンを書くことに比べて退屈で面倒だと言えるし、そこが「カスタムエンジンでゲームを作る」タイプのプロジェクトが行き詰まるところなんだよね。[1] https://ruoyusun.com/2025/04/18/game-sequel-lessons.html

└

エンジンって、アセットパイプラインの端っこにぶら下がってるちょっとしたランタイムの付属品に過ぎないってずっと言ってるんだ ;) （シェーダーコンパイラと3D APIの関係もどんどんそうなってきてるよね - 面白いことはシェーダーコンパイラで起こってて、3D APIはシェーダーを起動して入力データを渡すだけって感じ）

└

どんなビデオゲームが出荷されるのも奇跡だよね。

└

エディタをゼロから作るのは本当に大変だよね。だから、できるだけ既存のエディタを使う理由の一つなんだ。例えば、TrenchBroom（Quakeエディタ）とfunc_godotはGodotユーザーの間で人気が出てきてるし、Tiledも2Dゲームにはかなり良さそう。ゲームデータ管理にはCastleDB（使ったことはないけど）、今はHideという本格的な3Dエディタに統合されてるみたい。どちらにしても、ツールが動き出したら、次の大きなステップは実際にゲームをデザインして、すべてのコンテンツを作ることだね。 :)

└

エンジンの周りのツールやコンテンツ、アセットパイプラインが本当に重要だよ。これは作るゲームのタイプによって大きく変わる。例えば、コンテンツが多くの部分で自動生成される場合、マップエディタはシンプルにできるし、インポートするデータフォーマットの種類も少なくて済む。また、ジャンルによっては他のジャンルよりも「外部コンテンツ」が必要な場合が多い。ジャンルを一定に保っていても、「価値提案」がゲームエンジンにあるものとアセットにあるものがあることがわかる。特にインディーゲームでは、AAAタイトルに比べてゲームの構造をもっと柔軟にできる。

└

自分の「エンジン」を作るときは、すべてのゲームを扱えるようにする必要はないことを忘れないで。自分のゲームを扱えればそれでいいんだ。そして、UIや圧縮などを扱うために取り入れられるライブラリやフレームワークはたくさんあるよ。OPはimGUIを使っていて、これはゲーム内エディタを作るための優れた小さなUIライブラリだよ。その道を選ぶときは、「すべてのゲームのためのエンジン」を作ってるわけじゃないから、やらなくていい仕事がたくさんあるんだ。

└

僕が以前働いていたインディーのスタジオでは、エンジンの経験がある人たちがいたから、自分たちで3Dエンジンとアセットパイプラインをゼロから作ったんだ。でも、エディターの予算はなかったから、アセットパイプラインをホットリロードできるように設定したんだ。メッシュ、シーン、マテリアル、アニメーションはMayaから、テクスチャはPhotoshopから、オーディオはWAVの山で、スクリプトはLuaで、UIレイアウトはXMLで。アセットファイルを変更すると、ゲームがリアルタイムで変わる仕組みだった。それから「ExcelからエクスポートしたLuaの状態マシン」を追加したんだ。行が状態、列がイベント、セルが状態+イベントの組み合わせに応じて実行するコード。これを何度かやったけど、大きな状態マシンを管理しやすくしてくれた。僕たちのゲームは統計が重視されていて、デザイナーたちはExcelが好きだったから、新たに「ExcelからエクスポートしたLuaの動的データソース」を追加したんだ。普通にExcelのシートを埋めるだけで、Excelスクリプトの代わりに、各セルは評価可能なLuaコードになってる。文字列、数値、ブール値、関数はLuaの値として扱える。だから、あるセルには数値が入っているかもしれないし、他の二つのセルの内容をチェックして、別のオブジェクトでイベントをトリガーする関数が入っているかもしれない。これを使って、単一の実行ファイルで複数のゲームを出荷したんだ。アーティストたちは3Dシーンや2D UIをLuaで制御できるようにレイアウトできたし、デザイナーたちはゲームの状態に応じてシーンやUIをExcelから動的に埋められた。プログラマーたちは主にC++でゲームに依存しない機能に取り組んで、Luaでゲーム特有の機能のスクリプトを重視してた。ちなみに、Luaは動的型付けだから、大規模なソフトウェアエンジニアリングには向いてないけど、https://teal-language.org/ はLuaのための良いTypeScriptかもしれない。試したことはないけど。また、古いhttps://github.com/unknownworlds/decoda以外で、ゼロ統合で使えるLuaデバッガーはある？Decodaは実行ファイルのpdbがあれば、Luaライブラリを通過するスクリプトを自動的にデバッグできるんだ。最終的には、企業の理由でUnityに切り替えたんだ。カスタムエンジンの主な実装者として、切り替えは全体的に良いことだったと思う。僕たちのゲームは小さなエンジンチームが提供できる範囲を超え始めてたから。アーティストたちはUnityのエディターで少し生産性が下がったと報告してた。僕はUnityで遭遇した文書化されていないバグを見つけて回避策を考える役割に切り替えた。その後、リリースノートに言及されずに修正されたバグを見つけて、回避策を削除できるようにした。企業の理由でUnityに切り替えたのと同じ理由で会社が燃え尽きるまでの数年間は、本当に退屈だったよ :P

└

エンジンは簡単な部分だよ。 > 本当に重要なのは、エンジンの周りのツールやコンテンツ、アセットパイプラインなんだ。人々がエンジンについて話すとき、アセットパイプラインやエディターもデフォルトで含めることが多い。今のエンジンは単なるメインループ+3D APIコールじゃないからね。ほとんどの開発者は「Unityを使うけど、レンダリングコードだけ」なんて言わないよ。（もちろん、UnityやUnrealを使う限り、自分のアセットツールを書く必要がないとは言ってないけど。）

└

ゲーム開発をしていたとき、エンジンよりもツールにずっと多くの時間を費やしてたんだ。小さなチームの日々はもう過ぎ去ったから、少なくともプロの環境では、エンジンに集中できる一方で、他の誰かがエディターを作らなきゃいけないことが多いだろうね。

└

そうだね！エンジンライブラリなしでゼロから2Dゲームを作ったことがあるよ。リソース、フレームレート、衝突判定、簡単な物理演算とかを自分で作ったんだ。一つはグラフィック資産が全くないやつで、もう一つはあるやつだよ。 https://github.com/raould/pn0gstr0m https://github.com/raould/sheepgate

こういう投稿を読むのはいつもすごく楽しみなんだ。理由もなく幸せな気持ちになるし。最近はゲームを作ってないけど、楽しんでる人たちが好きなプロセスを説明してるのを読むのが大好き。そうすることで、インディーゲームの世界で何が起こってるのかを理解するための新しい視点も学べるしね。この（あまり）秘密の願望を心の片隅に持ってるけど、家族や国（ウクライナ）を支えるためにお金を稼がなきゃいけないから。いつかもっとゲームを作るかもしれないな…この投稿を書いてくれてありがとう、ノエル！

└

たくさんの人が流行に流されてる中で、IMOではとても賢い技術選択を見られるのは新鮮だね（先週のRustゲーム開発の投稿を思い出す）。C#、SDL3、そして他にも素敵なライブラリがいくつか。問題は、何を選ぶべきかを知るために十分な経験と判断力を持つのが簡単じゃないってこと！新しいゲームを始めるとき、エンジンの数に圧倒されて動けなくなることがよくある。ゲーム制作を始めた頃は、GWBASICしか持ってなかったのに…

ソフトウェアプロジェクトはいつもゼロから始めるのが好きなんだ。大規模なソフトウェアプロジェクトに慣れてる人は、すごく時間がかかるって知ってるよね。でも、ゼロから始めるのは早い！最低限のものを実装するだけだから。でも、開発の後半では抽象化が進んで、新しい機能を実装するのがさらに早くなる。企業向けソフトウェアプロジェクトと、自分でゼロから書いたエンジンでの作業は全然違う。自分で書いたものなら、1000倍早く作業できるし、好きなように切り取ったりリファクタリングしたりできるからね。だからこそ、マイクロサービスアーキテクチャと小さなチームを推奨してるんだ。自分でゼロからやると、物事がずっとスムーズになる。ただ、いくつかの地雷を踏む必要があって、どのアーキテクチャや抽象化がうまくいくかを感じ取るまでには何年も試行錯誤が必要だし、使ってる言語やプラットフォームの細かいところを学ぶ必要がある。

著者がこのゲームを書いたことをお知らせしておくね、>300万本売れたよ: https://en.wikipedia.org/wiki/Celeste_(video_game)

何かを作ろうとすると、いつもエンジンと戦ってる気がする。GodotでもUnityでもUnrealでも。どれも、アセットを追加して改造するだけの完成されたゲームみたいに感じる。私にとっての問題は、ほとんどの場合、そのゲームを作りたいわけじゃないってこと。ウェブ開発の世界から思いつくアナロジーだと、エンジンはWordPressみたい。事前に焼き付けられてコンテンツを表示する準備ができてるけど、自分の目的がその事前設定と完全に一致しない瞬間に、膨大なハッキングや workaround が必要になる。

└

その通り。もし自分のゲームをGoogle Playにある他のゲームと全く同じにしたいなら、長いジャンクなスプラッシュスクリーンやレンダリングのひっかかり、ちょっと変なテキストレンダリング、ランダムなオーディオグリッチがあるUnityを使えばいいよ。そういうのは、モバイルのアドウェアまみれの「アイドルRPG」スタイルのゲームには許容されるかもしれないけど（今のところそういうゲームばっかりだし）。でも、VRでUnityを使う人が多いのは本当に腹が立った。スタンドアロンのVRヘッドセットでUnityのゲームがうまく動くのは非常に難しい。Meta Quest Storeのパフォーマンス目標を達成するには、Unityが無秩序でシングルスレッド、アロケーションが多すぎるという事実を回避するために、エンジンの大部分を書き直さなきゃいけない。もし自分のゲームを質の高いソフトウェアにしたいなら、ゴミを基盤にするのは無理だよ。

└

火に油を注ぐのは、タイトル画面やいくつかのモデルを置き換えるだけで自分のゲームを作れる「ゲームテンプレート」がたくさん売られてることだね。例えば、https://assetstore.unity.com/packages/templates/systems/stor... Steamのゲームを開いて最新のものを見ると、リリースのほぼ半分が少し変えた「スキン」の一般的なUnity/Unrealテンプレートゲームのバージョンだってわかるよね。https://store.steampowered.com/app/2488370/Cash_Cleaner_Simu... https://store.steampowered.com/app/2073910/A_Webbing_Journey... https://store.steampowered.com/app/3498270/Better_Mart/ https://store.steampowered.com/app/2625420/Drive_Beyond_Hori... https://store.steampowered.com/app/3163790/Toy_Shop_Simulato... https://store.steampowered.com/app/3023600/Horse_Farm_Simula... https://store.steampowered.com/app/3124550/Liquor_Store_Simu...

これにはかなり同意するし、俺もXNA/Monogameの精神的後継として、コードだけのC#ゲームフレームワークを作ってるんだ（SDLの代わりにSokolを使ってる）：https://zinc.graphics/ OPの投稿でも、現代のC#が素晴らしい理由のいくつかを挙げてるね： - クロスプラットフォーム開発（とランタイム）。 - NativeAOTコンパイル（コンソール向けに最高、バックエンドヘッダーがあれば）。 - ネイティブホットリロード。 - リフレクション。俺が追加したいのは： - ソースジェネレーター。現代のC#は本当に素晴らしい。人々はその悪いレガシーのせいでまだ過小評価してると思うけど、ここ5年のC#とCoreCLRの開発は、本当に必要なものがすべて揃っていて、バロックでも過負荷でもない言語だと感じさせてくれる。俺の唯一の大きなリクエストであるユニオン型も提案中で、（願わくば）来年には実現するはずだよ：https://github.com/dotnet/csharplang/blob/main/proposals/Typ...

└

ちょっと興味があって、こういうプロジェクトにC#を始めるためのアドバイスってある？僕はC#をスタンドアロンのwin32アプリケーションとUnityの中でしか使ったことがないんだ。C/C++の低レベルなゲームエンジンのことには詳しいけど、C#はクロスプラットフォームプロジェクト（ゲームコンソール向け）には不向きだと思ってた。間違ってたみたいだね。 :)

これは、俺が数年前にやったこととほぼ同じだよ[1]。SDL2と少しのC++で「スプライト」クラスを作った。スプライトクラスに衝突コードも入れた…もし俺が追加したものを「エンジン」と呼ぶなら、それはペダルアシスト自転車みたいなもんだった。エンジンがプロジェクトやゲームを引っ張ってしまうことが多すぎる。つまり、ゲームをエンジンに合わせて書くことになるんだ。それが、俺がUnityなどを避けている理由だよ。ああいう高レベルのエンジンは、他の人が書いているのと同じゲームを書くように導いてくる - ただし、異なるアセットを使って。俺の意見では、エンジンを学ぶのに時間をかけすぎて、ゲームを書く時間が取れない。確かにSDLを取り入れるのには学習曲線があったけど、それは少しで、SDLを知っておくことは他のクロスプラットフォームプロジェクトでも使えるから、もっと普遍的に役立つと思ったよ - ゲームだけじゃなくて。[1] https://store.steampowered.com/app/2318420/Glypha_Vintage/

└

子供の頃、家族のMac IIciで君のゲームを遊んでたのを覚えてるよ。楽しい思い出をありがとう、そしてこれからも頑張ってね！

僕はLuaとLove2Dを使って、似たような理念でゲームを作ってるよ。自分の制約を設定できるのが楽しいし、それがゲーム開発の醍醐味だと思ってる。何かが楽しくなくなったら、間違ってるって気づくし、もっと良い方法があるはず。僕のゲームYOYOZOは39KBの小さなサイズだけど、Ars Technicaの「2023年のベストゲーム」リストに、スーパーマリオワンダーやゼルダの伝説ティアーズオブザキングダムと一緒に載ったんだ！ https://news.ycombinator.com/item?id=38372936

└

やあ、そのゲーム知ってるよ、素晴らしい仕事だね！僕はPlaydateを数年使ってるけど、やっとこの前の週末にSDKをいじり始める気になったんだ。Luaは今まで使ったことがなかったから、それも学びの一部だよ。強い型付けや他の言語の安全機能が欲しいけど、必要なことをするには良い感じだよ。今のところ作ったのは、クランクに関連して偽3D空間で回転するテキストの小さなテックデモだけなんだ。iOSのオプションピッカーみたいな感じ。ここにクリップがあるよ: https://bsky.app/profile/haydenblai.se/post/3lpgnya4cqk2a このプロジェクトから学んだもう一つのことは、CRUD/webアプリ開発の間に思った以上に三角関数のスキルを忘れてしまったことだよ。Playdateの開発で一番良い点は、描画する固定キャンバスがあることだね。すべてのUIをレスポンシブにしなきゃいけないのに慣れてるから、ピクセル値で何かを配置できるのがすごく好きなんだ。みんなのデバイスでちゃんと動くってわかってるから。

└

おめでとう！素晴らしい仕事だね。

ハクソク