2
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

2025年1月: 個人的クリエイティブコーディングフレームワーク選定

Last updated at Posted at 2025-01-10

完全なる独断と偏見で、自分が個人的に2025年に使っていきたい、クリエイティブコーディング関連のフレームワークについてまとめていこうと思う。

(プロプライエタリ = 非オープンソース のものは、TouchDesignerのみ一応紹介して、あとは選定から外している点に注意。)

なお、半年以上前にまとめた以下の記事も参考になるはず。

とにかくスクラッチで書きたい! → LÖVR

上記動画で、LÖVRが最も簡単な3Dゲームエンジンではないかと紹介されているけれど、自分も同意する。

元々人気のあったLua用ゲームエンジンであるLove2D (LÖVE)を、Vulkan対応などによって3Dに進化させたもの。同様の亜種は複数あるものの、ドキュメントが豊富で、スター数なども考慮して、一番安定して使いやすいものではないかと思う。

現時点のデメリットとしてはiOS非対応なことだけれど、Androidには既に対応しているし、時間の問題かもと一瞬思ったが、このフレームワークの主眼はVR/XRにあるようで、今のところ対応予定はないとのこと。ただ、visionOSの存在もあるので、今後の動向に注目。

エディタがやっぱりほしい! → Godot

ゲームエンジンについては多種多様に存在するので、正直自由に選んでもらえればと思うのだけれど、GDScriptの完成度や、C#も併用したり、C++(や他の言語)で自由に拡張したりといった総合評価で、自分はGodotをおすすめしたい。

前述のLÖVR同様、書いていて楽しいと思うのはGodotも間違いないと思う。例えばシェーダ言語が書けなくても、ビジュアルエディタが豊富にあり、アニメーションやスプライトについてもエディタでサクサク作っていけるので、初心者にも上級者にもおすすめできると感じる。

ただし、LÖVRもそうかもしれないけれど、Vulkan対応等によって必須スペックは過去のゲームエンジンに比べて上がっていて、もし旧来のマシンやGPU、古いスマホにも対応したいという思惑があるのであれば、レンダラーを変更したり、他のOpenGL対応のゲームエンジンも検討するなどしてほしい。

ECSでバリバリ書いていきたい! → Bevy

LÖVRの存在を知るまでは、スクラッチで書くならこれしかないとすら思っていた。先進的な機能と拡張性を併せ持っていて、Rust以外の何もインストールを必要としないのも嬉しい。(VSCodeさえあれば完璧に補完が効くのもありがたい。)

注意点としては、Bevyフレームワークのおかげでコーディングが比較的簡単になっているとはいえ、Rustの難易度は低くはないこと。そして、Rustの特徴として関連ライブラリを含めてすべてビルドするので、プロジェクトフォルダのサイズが大きく、(最初の)ビルド時間が大きい。これについては諸刃の剣であるし、sccache等の対応策も一応ある。

また、先進的な機能を次々に取り入れている結果、破壊的変更が多いことに注意。セマンティックバージョニング (0.xx.yy) で、0.xx (例えば 0.14) が変わらなければAPIは維持されているが、例えば 0.14 と 0.15 はもはや別物レベルで違う。(ただし、マイグレーションガイドという丁寧なドキュメントや、豊富なコミュニティサポートにより、移行自体は個人的にはそこまで苦労はしないと感じている。ただ、英語中心。)

古き良きOpenFrameworksなどと同じように、Bevy Assetsと呼ばれる拡張機能が多数存在するので、「これってできないのかな?」と思うことはたいてい拡張機能で対応できるのも嬉しい。コミュニティが厚いというのはこの辺が嬉しいところ。Examplesもブラウザで動いているものを確認しながらコードも見れるのが楽しい。

ちなみにBevyは、ECSのおかげもあって自動的にマルチスレッドかつパイプライン対応してくれるのがありがたい。つまり、自然なコードを書けばフレームワーク側が自動でパフォーマンスを最適化してくれるので、ゲーム開発者にとっては助かる部分だと思う。

バランス良く書いていきたい! → Delve Framework (および zig-gamedev)

300164821-45b64806-7829-4542-80d5-5a892eebf80d.png

スクリーンショット 2025-01-14 13.16.41.png

スクリーンショット 2025-01-14 14.32.29.png

こちらは追記にあたるのだけれど、元々後述の「今後に期待シリーズ」に入れていたもののなかで、Delve Frameworkは特に光るものがあったので、ピックアップしておきたい。

Zig言語というのは言語のなかでも比較的新しいもので、近年ではRustやC/C++に次いでよく使われているのではないかと思う。(bunというJavaScript処理系がZigで書かれていることでも知られている。)

手動でメモリ管理を行う言語ではありながら、自分が以前書いたアリーナ・アロケータに関する記事のように、いくつか注意していれば、普通に書き進めていくことのできるバランスのとれた言語。(その他、deferといったメモリ解放忘れを防ぐ仕組みが元々あったり、zigrcのようなスマートポインタ実装も最近は登場している。)

今回、2025年らしい先進的なフレームワークに的を絞って集めたつもりなのだけれど、Delve Frameworkは特にバランスが良いと感じていて、Zigのおかげでビルドはすごく高速だし、Luaを使うこともできる。

Delve FrameworkではSokolという描画エンジンが使われていて、Metal/DX11/OpenGL/WebGL(Vulkanは非対応)に自然と対応しながらも、とてもサクサク書き進めていける。一方でSokolは並列での描画には基本的に向いていないので、Delve Framework自身がなにか今後工夫をする可能性はありつつ、本気でマルチスレッドのパフォーマンスやスケーラビリティを求める場合は前述のBevyの方が良いかなとは思う。

プログラミング言語の好みもあると思うので、そういう意味でもZig言語のゲームエンジンを一つ紹介してみた。Zig言語の他のゲームエンジンとしては、本当はいつかMach Engineが完成してほしいと期待している。(Rustの難しさに悩んでいる人は、Zigを一度試してみると良いかもしれない。)

ノーコードがいい! → TouchDesigner

TouchDesignerはオープンソースでも無料でもないので、紹介程度に留めておきたいけれど、ゲームエンジンでいうところのUnityくらい、デファクト・スタンダードとなっているので、紹介だけはしておくべきかなと思う。

TouchDesignerのオープンソース的代替候補については冒頭紹介した記事で挙げているし、きっと他にもいろいろあるはず。ちなみに元々TouchDesignerはバックエンドとしてOpenGLを使っていたが、2022年頃にVulkanに刷新された。

プロプライエタリとはいえ、コミュニティは大きいので、ノーコードで制作したい、VJやりたいというときには真っ先に選択肢に挙げて良いものだと思う。

その他 (今後に期待シリーズ)

以下、自分が個人的にウォッチしていて、今後のアップデートや動向次第では積極的に使っていきたいものリスト。

特にSDL3については、近日中に正式リリースになるので、特にSDL GPUをベースにした新しいフレームワークが次々と誕生するのではないかと予想。

ちなみに今回は挙げていないけれど、ProcessingOpenFrameworksのような、旧来のOpenGL系の枯れたフレームワーク群も、まだまだ使えるし今後もおそらく使えるので、特に古いマシンやスマホとの互換性を保つ場合には是非検討してほしいと思う。(Web系も同様2。)

  1. Odin言語については、各種描画APIへのバインディングが公式で既になされているので、ライブラリではなく言語自体を列挙した。が、BGFXRGLのようなクロスプラットフォーム描画APIへのバインディング、かつ安定したものがあるとさらに使いやすくなりそう。

  2. Web系はもしかするとthree.js一択といえるのかもしれないし、最近WebGPUなどの動きが活発なので、BevyのExampleもWebで動くものが見れるし、選択肢は豊富にあるともいえるかもしれない。

2
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?