いまどきゲームを作るとしたら便利なゲームエンジンがいくらでもあるけど、あえて C 言語で作るということを考えてみる。案外なんとかなるし便利な側面も多いのではというのが言いたいこと…だけど書いてたらなんかとりとめがなくなってしまった。
コード駆動ゲームプログラミングという概念(今考えた)があると思っていて、よくあるゲームエンジンはアセットデータがあってシーンにオブジェクトを置いて…みたいなのをデータとコードと行き来しながら作ってくものだという理解をしているんだけど、コード駆動だととにかくコードで全部実現する(データもコードに埋め込まれることが多い)みたいなやりかたで作ることになる。これがプログラマが 1 人でシンプルなゲームを作るという範囲にうまくマッチしているように思う。やっぱり main()から書きたいんですよ。今どきな話でいうと LLM による vibe coding との相性がよさそうというのもある。
C 言語で書くといっても全てを自分で書く必要はなくて、マルチプラットフォーム対応なライブラリがまあまあある。
stevinz/awesome-game-engine-dev: Awesome list of resources for Game Engine Development.
たとえばSDLはメジャーバージョン 3 が最近出たし、floooh/sokolというのも活発に開発されている。SDL は単体だと 3D の表示ができないので OpenGL とかと組み合わせて使うことになるけど、OpenGL を使うと MacOS や iOS でそのうち動かなくなるんでは…というのは気になる。まあ今のところその需要は自分の中で高くないし、動かなくなって困ったらその時はその時で…と思ってる。sokol はちょっと使った感じ、複数の描画バックエンド/対応プラットフォームを持ってて悪くはないけど、まだまだ API の破壊的変更が行われてたりして付いていくのが大変そうな印象をもった。
その上で、他の言語じゃなくてなんで C 言語なの?ってところはあるけど、何か困った時にコードを追ったり手直しができる範囲が大きいのがいいところかなあと。何かしらの既存のライブラリを組み込むのも容易だし、問題があればデバッガで処理を追っていける。C 言語でライブラリを書いた上で Lua のような言語を組み合わせるのも悪くはない(love2dとか良く出来てる)…が、複数の言語や処理系の組み合わせによって作られているプログラムはそれぞれデバッグする必要があって面倒という話が出てくる。
C 言語は最近の言語と違って言語処理系自体にパッケージ管理の仕組みが備わっていなくて、ライブラリをビルドして path を通してというライブラリを導入するまでの手間がまあまあある。これをなんとかする仕組みとして、header-file library という風習と vcpkg というパッケージマネージャを紹介する。
C のライブラリは header-file として提供されているものもある。代表的なのがstb。header-file として提供されているライブラリであれば、使う人はヘッダファイルを#include するだけでよい。C 言語だと.h と.c という 2 種類のファイルに分けて.h に関数宣言、.c に関数定義を書くというスタイルになっていることが多いけど、header-file ライブラリは.c に相当する内容を得るために「事前にこの HOGE_IMPLEMENTATION マクロを定義しておけば関数定義に相当する部分を得られるよ、どこか 1 つの.c から#include してね」というものを提供していたりする。なんだったらヘッダファイルをプロジェクトにコピーしてしまえば簡単にリポジトリに含めることもできるし、ライブラリを導入するまでの手数が(C 言語にしては)めっちゃ少ない。
vcpkg は Microsoft が主体となって開発しているパッケージマネージャ。ライブラリもライブラリを利用する側も CMake で管理されている場合にいい感じにビルド方法を統合してくれる。(一応 CMake 以外でも使えるっぽいが… )。
細かいところでいうと、C99 の指示付初期化という構文がめっちゃ便利。複雑な構造体や配列の入れ子構造をサクッと初期化できる。 例。C++20 でC++でも一部使えるようになったけど、配列には対応してないっぽい。
ここまで書いておきながら、自分は operator overload が使いたいので結局 C++を使うんですが… n3051きてくれ～
というふうなことを考えながらneguse/ngというライブラリを作っています。裏で作ってる機能がちょいちょいあるけどまだ public repo に出せてない…