Skip to content

Instantly share code, notes, and snippets.

@mnrn
Last active September 15, 2020 03:04
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save mnrn/55269ea79e914fd91d51c76734b66c86 to your computer and use it in GitHub Desktop.
Save mnrn/55269ea79e914fd91d51c76734b66c86 to your computer and use it in GitHub Desktop.

プライベートでのゲーム開発について

グラフィックスに関する開発

もともとゲームの開発者であったため学習の一環としてOpenGL/Vulkanに触れる中で、Fragment ShaderによるシェーダープログラミングやCompute Shaderによる高速計算などのプログラムを試していました。
また、Compute Shader以外にもCUDAによるGPGPUプログラミングなどにも手を出していました。

開発の中で感じたこと

私は学生時代にDirectX9を学び、その後、DirectX11やOpenGL、そして次世代グラフィックスAPIであるVulkanを学びましたが、世代が後ろになるに連れ、ローレベルな要求に答えるためにプログラムの記述量が増えていくのを実感しました。
OpenGLでは制御しきれない部分への要望に答えるという、Vulkanが登場した経緯を考えれば当然かもしれません。
また、家庭用ゲーム機のSDKを使用しても結局はこれぐらいかそれ以上にローレベルな記述が求められます。

しかし、そのように学習コストが大きくなっても、コンシューマーゲームの売上本数自体はたいして変わらず、大きく値上げもしていないという点が非常に疑問でした。

UnityやUE4のようなゲームエンジンは上記の問題を解決できるかもしれませんが、ゲーム開発の忙しさ自体の解決にはおそらく繋がらないものと思われます。

そして、結局のところ、プログラムの挙動やデバッグに必要な知識として根本的な部分であるローレベルAPIの知識が最終的には必要になってしまうかもしれません。
もちろん、VulkanやMetal, DirectX12で1から書き始めるよりはよっぽど効率はいいのでしょうが。

苦労した点

ゲームの技術に関する記述は意外とネットにも少なく、ましてやVulkanとなると当時はかなり少なかったです。
仕事ではOSはWindowsを使用していましたが、自宅で使用していたWindowsはしょっちゅう不具合を起こしていたためメインPCのOSをUbuntuに変更したのもあり、Linux上でVulkanを動かしていたがこの情報が本当に少なく、なかなか苦労しました。
またサブPCはMacBookでしたがこちらはOpenGL4.1まで対応していたため一応OpenGLの動作チェックには使えました。

上記のように環境整備には苦労しましたが、VulkanはValidation Layersがなかなか優秀なため、環境を整えたあとはOpenGLよりも苦労しなかったかもしれません。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment