【ゲーム開発】伝統的にゲームが作り方

元々此の記事は、コンソール向けのゲーム開発に特化して書こうと思っていました。
考えてみると、PCやスマートフォンでの開発と基本的に変わらない事に気づいたので、全てのプラットフォームに適用出来る内容にしました。
但し、コンソールゲーム開発者として、記事の大部分はコンソールゲーム開発に焦点を当てた物になります。

経歴

具体的には3DSとWii U以降、ニンテンドーシステム向けのゲームを作ってきました。
技術的にはDSの頃からですが、其れはライフサイクルの終盤だった為、デモを作った程度で、本格的なプロジェクトは作った事がありません。
然し、あたしはパートナーの中最初企業ではないサードパーティ開発者の一人でした。
其の結果、大手企業の有名な開発者と直接メールで話す機会を得る事が出来ました。
NDPでもそれは変わりませんが、現在は名前とメールアドレスが匿名化されている為、誰と話しているのか分からなくなってしまい、残念です。

此の様なユニークな立場にいたおかげで、ゲームエンジンを使う事と、ゼロからゲームを作る事を深く理解する事が出来ました。
2010年代初頭は、ゼロからゲームを作るのが主流だった時代と、ゲームエンジンを使うのが主流になった時代の間の橋渡し的な世代でした。

最初はUnityを使っていました。
然し、Unityのランタイムだけで3DSの利用可能なRAMの殆どを消費してしまい、真面なゲームを作るのがほぼ不可能になった為、Unityを使った3DSゲームを公開した直後に、ゼロからゲームを作る方法を学び始めました。
其れは遥に難しかったですが、ずっと楽しくて、其れ以来戻っていません。

何故ゼロからゲームを作るのか？

今日では、殆どの開発者がUnityかUnrealを使っています。
此れは、インディー開発者がリソースや知識に欠けている事が多く、大企業は忍耐力に欠け、出来るだけ簡単に複数のプラットフォームに公開したい為です。

然し、ゼロから独自のエンジンを作るインディー（あたし達の様な）や大企業もあります。
殆どの人は「UnityやUnrealがあるのに、何故苦しむのか？」と思うでしょうが、其れには正当な理由があります：

• 従来のエンジンでは出来ない方法でパフォーマンスを最適化出来る
• 従来のエンジンでは扱えないコンセプトを実験出来る
• 自分の成果に特別な誇りを持てる
• 従来のエンジンを使っていると当たり前だと思われるプラットフォームの内部動作について多く学べる
• 只楽しい

又、殆どの個人や企業は、金銭的な理由で従来のエンジンを使っています。
出荷可能なゲームを遥に早く作れるからです。
あたし達の場合、ゲームを作るプロセス自体が優先されます。
あたし達は企業体なので、勿論お金を稼ぐ事も重要ですが、喜ばせるべき投資家も、耳を傾けるべきパブリッシャーも、給与を支払うべき従業員も、SaaSみたいなミドルウェアも使いません。
其の為、優先順位を好きな様に再配置出来ます。

時折、開発キットや描画タブレット、DAWプログラム等の大規模な購入が必要になるだけです。
又、ゲームリリース近くでは年齢レーティング、マーケティング、カートリッジ生産に多くの費用がかかりますが、此れらは全て1回限りの費用であり、継続的な物ではありません。
そして、失ったお金の多くは、ゲームが販売され始めると、eShop経由で直接、又は小売店経由で間接的に回収されます。

ゼロからゲームを作る方法

PC

特にPCでは、複数の道筋があります。
PCには、複数のSDK、フレームワーク、プログラミング言語、ストアから選べる贅沢があります。

人気のフレームワークにはSDL、SFML、そして最近ではRaylibがあります。
ゲーム開発が初めてなら、Raylibを強くお勧めします。
シンプルで使い易く、柔軟性があり、優れたドキュメントがあるからです。

以前はSDLも使っていましたが、多くのライブラリに依存している為、OS全体を一緒に配布しなければならない様な物です。
PongとBrick Breakerの両方でSDL2を使いましたが、今後の「楽しむ為」のプロジェクトではRaylibを使いたいと思います。

以前、あたしはフレームワークを使うのが嫌いだと言いました。
此れは主にWeb開発に当てはまります。
Web開発では、ゼロからウェブサイトやWebバックエンドを構築するよりも、不必要な複雑さを追加する事が多いからです。
Laravelプロジェクトをセットアップするよりも、本物のPHPを使う方が遥に簡単だと感じます。

然し、ゲーム開発では状況が異なります。
基盤となるシステムは遥に複雑で断片化されている為、フレームワークは実際には歓迎されます。
Webとは異なり、フロントエンドはBlinkとGecko（互いに追従し合う）によって支配され、バックエンドは主にLinux又はBSD（かなり似ている）ですが、ゲームは様々なプラットフォーム固有のAPIを扱わなければなりません：

• ウィンドウイングと入力：WinAPI、X11、Wayland、Cocoa
• グラフィックス：OpenGL、DirectX、Vulkan、Metal
• シェーダー：GLSL、HLSL、MSL
• オーディオ：WASAPI、sndio、OSS、ALSA/Pipewire、其の他macOS、NetBSD、Haiku、Plan9、Redux、FreeDOS、TempleOS、AROS、Mac OS classic等無数の物

又、以前スペースインベーダーでやった様に、XlibとC言語だけで独自のフレームワークを作る事も可能です。
又は、GLFWをウィンドウイングとコントロールに使い、其の他全てを自分で作る事も出来ます。
あたしが全てのプログラミング言語レビューでやった様に。
然し、デモシーン以外の殆どの人はそうしません。

フレームワークとエンジンの違い

求人掲示板では、「フレームワーク」と「エンジン」が同じ意味で使われているのをよく見かけます。
此れは、自転車をトラックと呼ぶのと同じくらい正しいです。

自転車は車輪とコントローラーを与えてより速く移動し、特定の方向に操縦出来る様にしますが、トラックは室内、モーター、荷物を運ぶスペース、他の人のための座席、複数の速度オプションなど、自転車にはない多くのものを提供します。
ゲーム開発の場合も同じです。

フレームワークは、ウィンドウを作成し、其の中でOpenGLやVulkanグラフィックスをレンダリングし、入力、クロスプラットフォームのオーディオライブラリ、FPSカウンター、ファイルシステム、ネットワーキング、UIシステム、アセットマネージャー等の便利な物を提供するクロスプラットフォームの方法を提供します。
ゲームエンジンはそれらすべてを提供しますが、さらにスクリプトエディタ、シーンハンドラ、レベルエディタ、物理エンジン、プラットフォーム抽象化レイヤー等を追加します。

フレームワークは基本的に、作業しているプラットフォームの低レベルSDKの上に重ねられた抽象化レイヤーの束です。
其の為、WinAPIやX11を手動でセットアップする代わりに、1つか数個の関数を呼び出すだけで、空のウィンドウが手に入ります。

ゲームエンジンはフレームワークの上に更に重ねられた抽象化レイヤーですが、物理エンジン、エディタ、スクリプト言語、アセットマネージャーなどを追加します。
勿論、独自のエンジンを作る場合、どの機能を含めるか、どの機能を含めないかを選べます。
例えば、あたしはスクリプト言語を持たないことを選択し、エディタはランタイム上にあり、デバッグビルドでのみ利用可能です。
出来るだけリーンに保ち、開発時間とハードウェアリソースをより多くゲームに割り当てられる様にしたいのです。

もう一つの覚えておくべき違いは、ゲームエンジンは意図されたゲームデザインを反映するべきですが、フレームワークは出来るだけ汎用的に保たれるという事です。
此れが、ゲームの続編や似たメカニクスを持つ新しいゲームに同じエンジンを使うのが一般的である理由ですが、フレームワークは複数のジャンルにわたって同じままです。

UnityとGodotは汎用エンジンである事で此れを少し歪めています。
Unreal Engineも今は同じ事をしようとしていますが、元々はEpic Games固有のファーストパーソンシューターエンジンとして始まり、此れ以前はUnreal Tournament専用でした。
此れが、Unrealが意図されていないジャンルで苦労する事が多い理由ですが、UnityとGodotはそうではなく、後者の2つは最初から汎用エンジンとして設計されたからです。

従って、ある意味で、企業のマネージャーや採用担当者が「エンジン」と「フレームワーク」を混同する事が多いのも理解出来ます。

コンソール

コンソールの場合、此れは遥に調和されています。
C++が唯一の選択肢で、プラットフォームホルダーが提供するSDKを使わなければならず、プラットフォームホルダーのストアを使わなければなりません。
自由に選べるのはフレームワークだけです。
然し、殆どの場合、お気に入りのフレームワークは存在しない為、独自のフレームワークを作る可能性が高いです。

DSでは、ゼロから独自のフレームワークを作らなければなりませんでしたが、Wii、3DS、Wii U、Switch、Switch 2ではNintendoWareを利用出来ます。
NintendoWareは任天堂が自社の主力ゲームで使っているフレームワークで、パートナー企業にも提供されております。

此れは言及するのに良い例です。
NintendoWareはフレームワークですが、NintendoWare Bezel EngineはNintendoWareの上に構築された完全なゲームエンジンで、フレームワーク自体にはないスクリプト用のLuaと物理用のPhysXも実装しています。

コンソールの利点は、独自のフレームワークを作ったとしても、コンソールのライフスパン全体を通じて使い続ける事が出来る事です。
独自のフレームワークを作るだけでも、プラットフォームによっては約1〜2年かかる事があります。
フレームワークが完成したら、次にゲームを作らなければなりません。
フレームワーク自体は商用ゲームではなく、次の全てのプロジェクトで再利用出来るツールチェーンだからです。

SwitchとSwitch 2では、実際には2つの方法を並行して実行しています：NintendoWareを使う方法と、独自のフレームワークを作る方法です。
其の理由は、NintendoWareを使うと商用ゲームに早く到達出来る一方で、独自のフレームワークはプラットフォームをマスター出来るからです。

NintendoWareは非常に薄いレイヤーとして宣伝されていますが、カスタムフレームワークで自分で実装する必要がある多くの詳細を事前に実装しています。
例えば、Nintendoシステム向けに高度に最適化されたプロプライエタリなファイルフォーマットへのアクセスを提供します。
カスタムフレームワークでは、JPEG、PNG、glTF、WAV等の対応を自分で手動で実装しなければなりません。
勿論 stb_image や tiny_gltf を使う事も出来ますが、自分で実装する事で、此れらのファイルフォーマットが実際にどの様に動作するかをより深く理解出来、あたしは此れを非常に価値ある物と思っています。

最大の違いは、NintendoWareを使う場合、直ぐにゲームエンジン開発フェーズに入れるのに対し、カスタムフレームワークの場合、先ず其れを構築してからゲームエンジンを作る事になるという点です。
以前言った様に、ゲームエンジンは意図されたゲームデザインを反映します。

多くの人は、ゲームエンジンを作るのは非常に苦痛で、10年かかる作業だと思っています。
実際には、ゲームデザインによります。
ゲームがシンプルなSnakeやPongのクローンなら、ゲーム＋ゲームエンジンを30分から4時間で簡単に作れます。
FF7リメイク規模の物を作ろうとするなら、エンジンだけでも実際に何年もかかり、多くの人手が必要になります。

此れが、あたし達の戦略が1つの大きなプロジェクトと数個の小さなプロジェクトを同時に行う理由です。
此れにより、大きなプロジェクトに多くの努力を注ぎつつ、短期間でeShop上で小さなインディー風のゲームをリリース出来ます。

０７６スタジオのウェブサイトで、最近「SB」が「Spacebeast」を意味する事を明らかにしました。
此れは最終的な名前ではなく、大きなプロジェクトのコードネームです。
そうした理由は、プロジェクトが十分に進捗していて、キャンセルされないと確信出来る程ですが、ゲーム自体を見せるには未だ早過ぎるからです。
コミュニティがゲームの内容について推測する事を許可します。
然し、ゲームが発表出来る状態になったら、「インディーゲーム」の意味が変わると思うでしょう。

とても誇りに思っているので、未だあんま話せないのが残念です。
然し、此の段階で公開しても意味がありません。
見えるのは1つのアニメーションモデルと残りが全て静的なシンプルなプレースホルダーアセットだけだからです。
現在の作業の殆どはシステムレベルの実装とアート作成です。
1つの特定の機能の実装とアートに多くの時間がかかっています。
正しくやるには更に時間がかかります。

初期プロダクションパイプライン

エンジン段階では、主に衝突検出、物理エンジン、シーンローダー、カメラシステム、VFXシステム、アセットを操作する方法を作っています。
同時に、通常はエンジンの初期段階が実装された後に、ゲームの開発も行っています。
最初は、ゲームは実装が動作するかをテストする為のシンプルなシーンだけです。
ゲーム業界では、これは「テストステージ」と呼ばれます。

多くの場合、1つのテストステージだけでなく、複数のテストステージを作ります。
シーンローディングだけでなく、1つのテストレベルを肥大化させずに多くの異なるメカニクスをテストする為です。

其の後、ゲームに入れる予定の全てのシーンを作りますが、シンプルなプリミティブ、シンプルなマテリアル、シンプルなテクスチャで作ります。
無駄にシーンを作る事を恐れないで下さい。
最終ゲームに決して入らないシーンを持つ事は非常に一般的です。
又、ステージがどの様に見えるかを心配しないで下さい。
非常に大まかに、望むような見た目であれば十分です。

此れは「グレイボクシング」と呼ばれ、プログラミングの量が減り、ゲームデザインが増える段階です。
大規模なゲーム会社では、グレイボクシング以前の全ては通常R&D部門が行い、グレイボクシング以降は全てコアゲーム開発チームが行います。
あたし達の場合、あたしは完全に一人なので、本質的にR&D部門とコアゲーム開発チームの両方です。

其の後、ゲームプレイプログラマーとアーティストが作業を開始し、アーティストが最終アセットを作成し（修正は可能）、プログラマーが其れらのアセット用のスクリプトを作成します。
然し、最初の数ステージだけが準備され確定され、残りは今はプレースホルダーの状態のままです。
此れは「ビューティフルコーナー」と呼ばれます。

此れは通常、社長、投資家、パブリッシャー等にゲームのピッチとして示され、承認を得る必要があります。
スタジオは、此れらのシーンを雑誌や会社のブログで少しのティザーとして紹介する為に使うかどうかを選択出来ます。
此れが、所謂「ベータコンテンツ」が生まれる理由でもあります。
初期のスクリーンショットで示された物が最終製品と異なる事が非常に多いからです。
違いは軽微な物から大きな物まであります。

然し、最近ではゲームが益々後期の段階で発表される傾向にある為、1990年代のプレリリースゲームが最終ゲームと完全に異なっていたのに対し、今日のプレリリースゲームは最終ゲームとほぼ同一である事が多いのです。
此れは計画が時間と共に大幅に改善されたからではなく、発表がリリース日により近くなってきているからです。
然し、勿論各企業はゲームをいつ発表するかを自由に決められるので、非常に初期のプロトタイプスクリーンショットが二度と見られなくなるというわけではありません。

基本的な概要

従って、一般的な要点は、ゼロからゲームは以下の様に作られるという事です：

1. プラットフォームのSDKを選ぶ
2. SDKのAPI呼び出しの上にフレームワークを構築する
3. ゲームデザイン文書（GDD）を作成する
4. GDDを念頭に置きながら、フレームワークの上にエンジンを構築する
5. エンジンを構築しながらゲームを構築する
6. ゲームを完成させる

ゲームが既存のフレームワークで作られている場合、ステップ1と2の作業を最小限にするか、フレームワークに応じて完全に省略する可能性が高いです。
ゲームエンジンを使う人々の場合、ステップ1、2、4は完全に省略され、5は「ゲームを構築する」だけに最小化されます。

Unreal EngineとGodotのソースコードを修正してニーズに合わせて調整する事は可能ですが、Unityではそうではありません。
上記3つの中で完全にクローズドソースなのはUnityだけだからです。

新入社員に、ステップバイステップでガイド付きで独自のフレームワークとエンジンをゼロから作る方法を教える内部文書を用意しています。
然し、PCゲーム開発用に書き直して、秘密保持契約に違反する事なく、此のブログでも公開出来る様にするつもりです。
内部文書はほとんど同じですが、SwitchとSwitch 2のゲーム開発向けに調整されており、此のブログで合法的に公開する事は出来ません。

今後のチュートリアルシリーズの意図は、低レベルな知識が益々失われつつある時代に其れを保存し続ける事と、将来的に当社に入社する事に興味がある人々の為の公開リソースを持つ事です。
2年以内に採用を開始出来ると予想しているので、早めに加入したい場合は、必要なスキルを学ぶのに十分な時間があります。

以上