現環境でフルスクラッチでゲームを開発するならどうするのが最適解か?

こんばんは。
九条です。

別プロジェクトのプログラマに就任

私が将棋ソシャゲを作っていることは告知済みです。今回、別のプロジェクトを兼任することになりました。
これは、今流行りのSTSの影響を強く受けたカードゲームです。
また、このプロジェクトの延長としてカードゲーム制作キット(RPGツクールを、カードゲーム版にしたもの)を作るという野望もあります。

言語や開発環境はどうするの?

まず、ゲームエンジン(Unity や Unreal Engine)は使いたくありません。
これはライセンス料の問題があるほか、そもそもカードゲーム制作キットのようなものを作るとライセンス違反になるのではないかという懸念があります。
また、カードゲーム制作キットに繋げることを考えた場合、自由度にも懸念があります。
例えば、カードの効果を Visual に(グラフィカルエディタを使って)編集できるようにしたいという要望がありますが、果たしてそこまでゲームエンジンでできるでしょうか?
ライセンスの問題だけなら、Godot(STS2 に採用される予定のエンジン)というフリーエンジンがありはしますが、上記のような自由度の問題は依然として残りますし、Godot は資料も少ないです。
そこで、作るとしたら、フルスクラッチか、使うとしてもエンジンではなく、ライブラリに留めるということにならざるを得ません。

フレームワームもエンジンも一切使わずに作ってみた。

そこで、フレームワームもエンジンも一切使わずに作ってみました。
使用した言語は、C#、ライブラリはすべて.NET標準のもの、つまりGDI+です。
結論から言うとこれは使い物になりません。最近、パソコンが故障して比較的新しく高価なものに買い替えたのですが、新しいパソコンでも、背景画像と立ち絵とテキストを描画しただけで、コマ落ちが発生しました。

WPF はどうか?

C#には、比較的新しいフレームワークとして、WPFというものが存在します。これは、GDI+を使った古典的なライブラリと違い、描画処理をGPUで行ってくれます。なので、GDI+よりは有望ではないかと思われました。
しかし、WPFは、はっきり言って使い物になりません。
まず、1ピクセルの線を引くという簡単な操作さえまともにできません。座標系の単位がピクセルではないうえに、アンチエイリアスがかかってしまい、解除する方法も不明なのです。
また、描画関数を使ったプリミティブな処理は、GPUを使わず、結局CPU処理で行われていることも判明しました。
これは、アプローチを根本的に考え直す必要があるということで、Chat-GPT に相談しました。

Chat-GPT からの意外な提案

Chat-GPT も、ゲーム開発では、WPFは使いものにならないよ、ということを言ってきました。しかし、代案として提示されたものに意外なものが含まれていました。

  • Unity
  • Unreal Engine
  • MonoGame

MonoGame は知らなかったので、何だそれ!?となりました。
非常にマイナーなものに思われる方もいるかもしれませんが、実は、調べてみるとそうではないことが判明しました。過去にXNAというライブラリが存在し、その後継として開発が継続されているものということでした。
XNAは、十数年前、Windows や Xbox のような Microsoft 系のプラットフォームで動作するライブラリとして、大変な人気があったものです。

MonoGame について追及して訊いてみた。

そこで、より詳しく、Chat-GPT に MonoGame について訊いてみました。
そうすると次のようなことが判明しました。

  • EXEファイルを生成することができ、アプリストアを経由して配布する必要がない。
  • エンジンではなく、あくまでライブラリである。
  • 完全無料である。

以上は、我々のプロジェクトには非常に向いている特徴です。あくまでエンジンではなくライブラリなので、カードゲーム制作ツールに繋げられますし、何より無料なのがうれしいです。

資料も充実している。

MonoGame というと非常にマイナーなイメージがあります。しかし、既に述べた通り、XNAというライブラリの後継であり、こちらは大変人気がありました。そして、XNA向けに書かれたコードの大半がそのまま実行できるそうです。
XNAのドキュメントは、無料でもたくさん存在しており、おそらく資料がなくて困ることにはならないでしょう。

DirectX や Cocos2d-x はどうか?

実は、これら以外に DirectX というライブラリがあることを知っていたのですが、これはできるだけ使いたくなかったので、選択肢から外していました。
DirectX は言語がC++になってしまうのですが、C++では何もしないウィンドウを表示するだけでも50行ぐらいのコーディングが必要ですし、ポリゴン(三角形)1枚を表示するだけでも、追加で50行ぐらい書かないといけません。GC(ガベージコレクション)もなく、著しく生産性は低いです。
それと、調査の過程で知ったのですが、Cocos2d-x というものもあるらしいです。
これも論外かなと思いました。言語がC++なのはともかくとして、ライブラリではなくゲームエンジンなので、上でも述べましたが、ゲームエンジンはガードゲーム制作ツールには馴染みません。

MonoGame で実際にサンプルを作ってみた。

以上から、我々のプロジェクトに、MonoGame を採用することが決定したため、実際にサンプルを作ってテストしてみました。
なるほど、画像の描画は爆速としか言いようがありません。古いPCでも安定して60FPS出せます。
ただし、想定していなかった欠点もありました。

MonoGame の欠点

MonoGame は文字列の描画に難があるという欠点があります。というのは、フォントを「MS ゴシック」のように指定して使うことができず、あらかじめフォントに対して、「コンパイル」に近い操作を行って、画像化してリソースとして埋め込むという構造なのです。
これだと、「MS ゴシック」のような商用利用ができないフォントの場合は、使うことができなくなります。また、フォントのサイズ別にこのようなコンパイル作業をする必要がある上に、カードゲーム制作キットとしては、ユーザにこの「コンパイル」作業を押し付けることになるため、非常に難があります。
これについて、考え抜いて海外サイトも調べた結果、文字列の描画だけGDI+を使うことになりました。
これはかなり重たい処理にはなってしまうのですが、カードゲームの場合、文字列を描画する場面が少ないですし、ノベルゲームパートを作ったとしても、多少のコマ落ちなら許されます。

最後に

将棋ソシャゲはどうなっているかというと、PHPとJavaScriptです。こちらは、STS風のカードゲームや、カードゲーム制作キットには使えません。スタンドアロンアプリを作るための言語ではなく、Webアプリを作るための言語だからです。

Chat-GPT とのやり取りを掲載しておきますので興味がある方はご覧ください。

Chat-GPT とのやり取り

記事のタグから探す

月別アーカイブ

限定特典から探す

記事を検索