【ゲーム開発】開発ログ・その001

「その001」と名付けた物の、開発ログを100回以上投稿する保証はありません。
抑々、此れから継続的に書いていけるかどうかすら分からないからです。
というのも、Volt Engineの動画を皆さんにお見せしてから、もう2年も経ってしまったからです。
其の後、現実の生活に邪魔をされ、仕事を失い、ハローワークに3か月通った末に新しい仕事を見つけました。
そして、他のプロジェクトに次々と枝分かれしていったせいで、いつの間にかエンジンのコードを思い出せなくなってしまいました。
しかもVolt EngineはOOPスタイルで書かれており、此れは当時の自分が犯した最大の失敗でした。

然し、あたしのPeerTubeインスタンスは消滅し、FediverseのインスタンスはPostgreSQLによって吹き飛び、Xでは「投稿は1週間だけアクセス可能にしておく」という新しい方針にしています。
詰り、今ではVolt Engineは事実上、記憶の彼方へ消えてしまったわけです。
でもご心配なく。
此処に動画があります：

此れは2024年10月から2025年夏の何処かの時点までの、Volt Engineの姿です。
8か月前にSVNからGitへ移行したので、もう正確な履歴は残っていません。

０７６スタジオでは、複数のプロジェクトに跨るゲーム制作や、コンセプトアート、3Dモデル、ストーリー資料等に携わってきました。
新しいフルタイムの仕事では、トンネル建設に使用する3Dレンダラーと3Dシミュレーターを作っている為、LiDAR関連の作業もかなりあります。
又、ウェブ系開発用のツールしか知らず、C#を始めたばかりで、プログラミングにAIへ大きく依存している同僚達の為に、実用的なライブラリも作らなければなりません（其の為、完全なソースコードを提供する事には慎重になっています）。
こうした事情と、新しいフルタイムの仕事を始めたタイミングが重なった事で、Volt Engineを一から作り直す絶好の機会が生まれました。
今回は関数型の方式で書き、OOPを使う部分はシーン管理だけにしています。

其の結果、軽量で柔軟性が高く、非常に移植性の高いコードになりました。
Vulkanに搭載されている最新の機能も活用出来、Nintendo SwitchやSwitch 2ではNVNも使用出来ます。
又必要になれば、更に多くのグラフィックスAPIやプラットフォームへ簡単に拡張出来ます。
更に、2つの会社が全く異なる用途で同じエンジンを使う必要がある為、ゲーム開発者にも建設作業員にも対応出来る様になっています。

其れに、もうウェブ開発の仕事をしていないというのも助けになっています。
どうせ来週には忘れる事になる新しい人気フレームワークを覚える為に、時間を無駄にする必要がなくなりました。
又、オープンソースを辞めた事も、実際の仕事に集中出来る様になったという点でプラスです。
LLMや、あたしの仕事を盗むだけで一銭も払わない共産主義者達を感心させる事に費やす時間も減りました。

紹介

此の作業を始めたのは2か月前、新しい会社に入社する直前でした。
其れ以来、3色の三角形だった物が、完全にプレイ可能な3Dデモへと成長しました。
然し、此のデモだけが作業対象というわけではありません。
此れから数週間のうちに、2Dと3Dのデモを大量に作る予定です。
そうする事で、実際のゲームを旧Volt Engineから新しいVolt Engineへ移行する前に、此のエンジンがどの程度プロダクション環境に対応出来るのかを検証出来ます。
旧エンジンは放棄したと言いましたが、使えなくなる其の時まで、実は旧エンジンでゲームを作り続けていました。
然し、新しいVolt Engineはよりシンプルになった為、かなり印象的な結果を出すのがずっと簡単になっています。

昨日、此の動画をXに投稿しました：

此の動画も既に古い物ものです。
物凄い勢いで開発を進めています！

前回の動画では、他に用意しているテストシーンについて説明しなかったので、今回は其れらを見ていきましょう。
先ずは、一番退屈な物から：

此の2つのシーンは、2Dグラフィックスのレンダリングをテストする為だけの物です。
1つ目は基本的な2D図形を表示するだけで、2つ目は其れらの2D図形を使ったGUIレイアウトエンジンです。
其れ以上の物はありません。
レイアウトシーンは、唯一スカイボックスを使用していないシーンです。
此れは、スカイボックスが設定されていない場合でもクラッシュしないかどうかを確認する為です。

此処から、少しずつ面白くなってきます。
シーン名は「シンプル」ですが、実際にはファイルから様々な3Dモデルを読み込むテストを行うシーンです。
画面にはOBJファイルが1つ、GLBファイルが2つ、FBXファイルが2つ表示されています。
画面外にはもう1つアニメーションするGLBファイルがありますが、其れは島のシーンにも登場するので、此処で見せる必要はありません。

次は3Dプリミティブのシーンです。
此処では、立方体、球、円柱、カプセル、平面など、予め定義された3D形状の読み込みをテストしています。
更に、シェーダー、ライティング、透明度のテストにも使用しています。
カプセルは透明になっているのですが、そうは見えません。
此れはトゥーンシェーダーがアウトラインも描画する為で、透明処理との相性があんま良くないからです。
円柱には発光用のエミッシブシェーダーを使用しています。
但し、未だブルーム効果を実装していない為、現状では単なる単色に見えています。
そして、影が落ちているのも確認出来るでしょう。

そして最後に、昨日見せた島のシーンです。
本物のゲームの様に見えますが、実際にはゲームではありません。
此のシーンはゲーム全体を動かせる能力をテストする為の物なので、ゲームらしく見える様に作っています。
デバッグメニューも表示されています。
此れはいつでもオン・オフを切り替えられますが、便利なので今はオンにしています。

「3Dモデルを作るのにそんなに時間をかけて、後で捨てるだけなんて時間の無駄じゃない？」と思うかもしん。
実際の所、此れらのモデルはどれもあたしが作った物ではありません。
島のモデルは此方から拝借しただけで、其れを編集して変更し易くし、更にパフォーマンスも改善しました。
元のモデルではフレームレートが12 FPSまで落ちてしまい、かなり酷かったからです。
狐のモデルはKhronos Groupによるサンプルモデルの1つです。
此方も法線を追加する為に変更しただけです。
そうしないと、トゥーンシェーダーがあんまにも場違いな見た目になってしまいます。

旧Volt EngineではデバッグメニューにImGuiを使用していましたが、今回は100%自作しました。
ImGuiが嫌いだからではありません。
寧ろ、最高のGUIライブラリだと思っています。
単純に、Nintendo 64、GameCube、Game Boyの古いゲームからインスピレーションを受けたからです。
其れらには、こういうデバッグメニューがありました。
単純に、カッコいいと思うんですよね。

今日はコリジョン検出に取り組みました。
上のスクリーンショットの様に、コリジョンを表示する事も出来ます。
通常、ゲームでコリジョン検出を実装するのはかなり面倒で、特に3Dでは猶更です。
然し、Blenderを使ってコリジョンを管理しているSuper Mario 64のROMハッカー達からインスピレーションを受けたので、其れを真似した自分のシステムを作りました。
現時点では、島、桟橋、岩1個、木1本にしかコリジョンを設定していません。
未だコリジョンシステムが完成していないからです。
今はかなり基本的な物ですが、此れから数日のうちに、もっと高度な物にしていくつもりです。

因みに、此のエンジンは建設作業員にも使用してもらう事を想定しているので、Windowsでも動作します。

ご覧の通り、主な違いはDevice IDが割り当てられない事です。
此れはNintendoSDK専用の機能だからです。
又、PCでは画面上のキーボードが必要ない為、SwitchとSwitch 2で「ソフトキーボード」と表示されている場所には、ウィンドウ表示とフルスクリーン表示を切り替える為の「全画面」が表示されます。
もう1つの違いは、SwitchとSwitch 2ではFPSが、其々の機種がレンダリング可能な上限に制限されている事です。
其の為、Switchでは60 FPSを超える事が出来ず、Switch 2では携帯モードで120 FPS、TVモードで60 FPSを超える事が出来ません。
一方、PCではCPUとGPUが許す限り高いFPSまで出せます。
但し、デモを出来るだけ同じ条件で見せる為、3機種全てで人為的に60 FPSへ制限しています。

「SwitchやSwitch 2で、こんなに快適に此のテストベッドを動かせるわけがない」と思っているなら、実際に両方の機器で動かしている写真をお見せします。

そして、青猫ちゃんが本当に動いている事を証明してくれます。

此のエンジンは未だ完成していませんが、最初のマイルストーンの完了にはかなり近づいています。
2つ目のマイルストーンでは、幾つかのサンプルゲームを実装し、其のPC版をItch.ioで配布して、皆さんに楽しんで貰う予定です。

此れから先、何が待っているのでしょうか？

以上