ゲームエンジンって？結局なんなの？
皆さんは"ゲームエンジン"というものについて、
どういった認識を持っていますか？
一般的には「ゲーム作る上で便利なツール」とか「ゲーム制作を効率化し、楽にするもの」と思っている人が多いはずです
が
.
.
.
それは真っ赤なウソです
なぜそう思ったのかについて後述します
ゲームエンジンはただの足枷
制約が多すぎる
はい、
そもそも制約が多すぎるんです
C++からC#のように、高級言語になることによって
制約が増える代わりにとっつきやすくなることは皆さんご存じでしょう。
それは勿論よいことです。
いや、違うんです！
ゲーム会社に勤めている私たちゲームプログラマーは、ゲーム開発のプロなのです。
そもそもある程度の知識があれば、ソフトウェアやプログラミング言語を扱えるのは当たり前で、
開発し始めのスタートダッシュがよくても、ゲームエンジンによって実現可能なものが少なくなるということは、ただの足枷にしかなりません
勿論、内製エンジンの場合はエンジンチームに機能追加の依頼を出すことで可能になることがあるでしょう
ただ、それは正直とても面倒くさいです
筆者の経験上、ゲームエンジンを作ってる人は頭の良い人が多い傾向にあります。
クライアントサイドが使うであろう関数のために、面倒くさい計算とか、レンダリング部分の設計、難しい海外の資料を読み漁ってらなければならないことも多いためです。
そういった頭の良い人って、自分本位で頭が固いことが多いです。（諸説あります）
頭が固いということは、、、
そうです
相談しに案件を持っていっても、すぐに実装してくれなかったり、
説教じみた文章を添えて「エンジン思想に合ってないので無理です」の一点張りで、取り合ってもくれません。
相談する場合は、当然ですがその方々がわかるよう、
なぜ必要なのかをまとめ、筋が通った文章を毎回用意してから相談する必要があります
正直、骨が折れます
というか、ゴマすりながら相談しに行く自分に呆れますし、
不必要な配慮で無駄なストレスが発生します
※勿論、中には頭が固い人だけはなく、仏のような方々も存在しています。経験上、立場が上の人ほど遜っていて、腰が低く、相談を親身になって聞いてくれます。そういった方々は尊敬していますし、喜んで草鞋を温めたいです。
例え実装してくれたとして、「エンジン側で機能追加してくれた！やった！」と思ってるのもつかの間、そういった細々とした機能実装をエンジン側で実装する関係で、エンジンの動作がハチャメチャに不安定になります
（※クラッシュについては、後述しています）
まぁ、それも内製エンジンの場合の話です。
外勢エンジン（UnityやらUnrealEngine）の場合は、安定ビルドを使うことが当たり前で、機能実装要望なんてそもそもすぐに対応してくれないですし、ソースコード開示するので機能追加とか不具合修正するなら勝手にしてくださいとかになります。
大規模ゲーム開発って、当初の企画のまま完成することって無いんですよね（諸説あります）
それなのに、上述した面倒事のせいで、開発後半で「やっぱりこの機能が欲しい」みたいな機能追加を求められても、「ごめんなさい、実装無理です！！」みたいなことになることが度々あります。
これは、エンジンが一概に悪いわけではなく、企画変更や機能追加を考慮せずに、エンジン側に事前に相談をしていないクライアントサイドに落ち度があったりもします
そういった未来を予測した行動ができるとできないとでは、ゲームプログラマーとしての質が問われたりもするでしょう。
と、ここまで色々述べましたが、はっきり言って、
ゲームエンジンは"製作者の欲望が体現しただけもの"です
使い手のことを全く考慮していない、例えるなら好き勝手に作ったキメラです。
というか、ゲーム制作ってユーザーに面白いゲームを提供することが第１目標のはずなのに、「エンジン思想で～」とか、説教じみた文章をクライアントサイドに対して送っている時点で愚の骨頂です。
ドキュメントが不足しがち
はい、これも内製エンジンの場合の話です
機能を細々と実装しているからこそ、ドキュメントが存在しない機能があったり、ドキュメントまでの導線が全くなかったりと、とてつもなく中途半端な内容となっています
「ドキュメント制作班を作れよ！」と思っても、機能の理解をした人員であるという前提条件があるため、人員を確保するのは大変難しく、かつ重要な機能を作成した方に限って多忙を極めています。
そのため、ドキュメントが一向に作成されず、クライアントサイドでエンジン機能の調査を行ったり、エンジンサイドに「～といった機能は実現可能ですか？」といったような質問をその都度行う必要があります
エンジンサイドに質問をする必要があるということは、、、
そうです
またしても要らない気遣いと論争が発生することになります
キレ気味に「この機能あるからこれ使えよｗ」
みたいに返答してくる輩も存在します
（お前らがドキュメント作っとけば聞く必要なんてないのに）
はたまた、エンジン機能調査の際には、特定のタイトルにしか必要がない無駄な機能があったり実験用コードが含まれたりする関係で、調査期間が長くなりがちです。
動作が不安定/クラッシュが多い
これが正直一番厄介です
メモリ使用率が不必要なタイミングで高くなったり、エンジン終了しているのにメモリが無駄に残留したりで、OSごと再起動することがあります
他にもゲームエンジンといえば、機能をめちゃくちゃに詰め込むことで有名ですが、
その関係でわけのわからないタイミングでクラッシュが頻発します
エンジンを更新したタイミングで発生し出したものに関しては、原因が特定しやすいので比較的問題ありません。しかし、潜在的に眠っているクラッシュは原因を特定しようがなく、開発仕様で終わることが多々あります。
ゲームエンジンは製作者の欲望を体現しただけのものであるため、闇鍋と化してしまっているのが主な原因です
エンジン制作者は一人ではないので、意図しない処理の組み合わせ方が乱立しており、クラッシュの抑制や出所を把握しづらく、修正がいつまでたってもされないのは当たり前となっています
クラッシュが発生するのはまだ良しとしましょう。
わざとクラッシュさせ、原因の特定を可能にすることがありますからね．．．
ただ、問題はエンジン起動してからの動作がとてつもなく遅いことにあります。
Unityでいうとビルトインシェーダーではなく、URP、HDRPを使用したときのイメージです
ビルトインシェーダーに比べてURPやHDRPは、プロジェクトを立ち上げたりビルドしたりといった時間が長くなっています。
機能が増えていたり、ユーザーの要望を経て無理やり機能実装しているわけですから、最適化されておらず、遅いのは当たり前ですよね
それも相まって、10分してようやっと起動やらセットアップが終了したのに、起動してすぐにクラッシュしてエンジンが落ちる…なんてことが多々あります。
それが残業中に発生したら、意気消沈して「今日はもう帰ろう」となりますし、締め切り直前だったらストレスで禿げそうになります。
デバッグがしづらい
主に、ロムの確認中に、エンジン起因なのか自分のコード起因なのかがわかりづらいです
というと、エンジン起因でクラッシュやエラーが発生した際は、
エンジン側の用意したライブラリ内でエラーが発生します。
プログラマーでしたら一度は遭遇したことがある現象でしょう
その際に、ライブラリ内の関数の中身まではわからないので、
自分で強引に見に行って「ここの処理で不具合発生してますよー」っとエンジン側に投げる必要があります
その際に、エンジン側とのお馴染みの相談イベントが発生します
ここでも、「その機能はそういった使い方を想定していないので使わないでください」みたいなことを言われがちです
こっちからしたらドキュメントもないし、「そんなこと知らんわ」って感じですが、その気持ちは心の中に閉まって、いつも通りゴマをすります
他にも、不具合の発生しているエンジン側のソースコードを指摘すると、「勝手に俺のソースコード見て指摘してくるんじゃねーよ」と逆切れされることもあります
そして最悪のパターンが、対応できないと言われた時です
そうするとどうなるでしょうか？
クライアントサイドは、脱法的に必要な機能を実装するわけです
エンジンの機能を使用せずに、望みの機能をクライアントサイドで実装するので無駄に工数が発生します
それでいて、後からエンジン側でしれっと同様の機能が実装されたりするんですよね。車輪の再発明が行われてるわけです。
生産性のないことしてるし、正直バカバカしいです
覚えても身にならないことが多い
ここまで見てくださった読者の皆さんは、もうお分かりかと思います。
正直言って人生で、エンジン側との相談ほど無駄なものはありません
こっちからしたら身にもならないことをしているのに、
無駄にストレスが溜まります
ゲーム会社での嫌なものトップ３には入るでしょう。
それに内製ゲームエンジンって、「もし退社したら絶対に必要ないよな」
と思う知識がほとんどです。
良いところ
とはいったものの、ゲームエンジンも悪いところばかりではありません。
あくまで「ゲームエンジン＝そんなに凄いものじゃない」を強調したいので、細かい内容までは記述しませんが、
以下のような良い点を挙げることができます。
ゲーム制作初心者でもとっつきやすい
チームメンバーに機能解説がしやすい
マルチプラットフォーム対応
実験しやすい
実験に使われるのはよく聞く話かと思います。
論文制作で膨大な計算をするためにUnityを使用して物理の計算をし、見た目に即反映したり、かくいう私もVRが出てきたときに、「こういった歩行だったら酔わないし最高ではないだろうか？」と思いついてすぐに実践したことがありました（VRの件は、そのうちnoteで共有するかもしれません）
これが、DirectXを記述するところからだと、まずウィンドウを表示して～、コマンドリストを積んで～、画面をクリアして～、コマンドリスト実行して～、画面のスワップして～
みたいな実験とは無関係な無駄な労力が必要になりますから、そういった面ではゲームエンジンはよいものだと断言できます
まとめ
なんかゲーム会社の愚痴ばかりで、
「結局のところ、お前は何が言いたかったんじゃい！」というと、
どこまで行っても、便利になる以上何かはできなくなるし、不具合も増える。
全ての不具合が自分の責任でありたいなら、そもそもコンパイラ言語から作ればいいし、それが不便だからみんなC++やC#のような言語、ひいてはゲームエンジンを使用するのです
結局は、自分が一番楽で快適にゲーム制作をできると思う土台での開発をするのが最適解なのです
UnityやUnrealEngineなどのゲームエンジンを使用していた方が自分的には楽と思うのならそれでいいし、DirectXやopenGLを使った実装から作る方が楽な人もいるでしょう
もしかしたらアセンブリ言語を使った開発のほうが楽な人もいるかもしれません
一概にゲーム制作をする土台は”これが良い”と言い切るのは難しいですし、断定はしない方がよいのです
よく見る記事で、「ゲームエンジンは使うべき」とか、「ゲームエンジンを使えると就職で優位に立ちます」とか言ってる人を見かけるが、これは就職をしたことない人か、小規模な会社に就職した人が上っ面だけで語っている謬説にすぎません。
新卒に関していうと、別にアルゴリズムの仕組み知ってたらそんなのどうだっていいし、大手企業だったら研修が充実しているので、アルゴリズムの知識だけあれば、入社してからプログラミング言語を習得するのは容易であると考えているでしょう。
無論、「様々な技術に興味を示していて、知識の探求のために手を出している過程でゲームエンジンを使えるようになった」だったら企業受けがいいし、自分から見ても欲しい人材であります
一個人的に思うことは、
ゲームエンジンは大規模開発ではない小規模開発だったらおすすめです
上で述べた"足枷"は発生しないですからね。
もしくは、本当に完成された修正の施しようがない、神に等しいゲームエンジンであれば大規模開発に向いているでしょう
まぁ、ゲーム作りってすぐに新技術が追加されるので、そんなものは存在しないんでしょうが。
※ここでの内容は筆者の思想が強く反映されていますので、鵜呑みにはしないでください
※このnoteは文化庁のルールに基づいて記述されています
この記事が気に入ったらサポートをしてみませんか？