GameTech Weekly 001

GameTech Weekly

ゲーム開発に関わる記事を毎週まとめて紹介する連載です。 Unity Weeklyさんなど、似たような連載は沢山ありますので、それらと差別化するために、「ゲーム開発に役立つかもしれない」記事であれば、直接関係しない内容であっても、ここで紹介したいと思います。

毎週火曜更新予定。

【Rider】RiderにHeap Allocations Viewerを導入してヒープアロケーションを可視化する(Unityでもオススメ)

https://www.hanachiru-blog.com/entry/2023/06/22/120000

  • RiderのPluginであるHeap Allocations Viewerの導入と、Heap Allocationが発生するコードの実例を紹介しています。

[Unity] Debug.Logの呼び出しをリリースビルドから除外 & GC低減ラッパークラスを作る

https://qiita.com/old_friend/items/4fae64616a87fa1d9dad

  • Debug.Log()をReleaseビルドから除外するために、[Conditional]属性を使ったラッパークラスの実装例を紹介しています。
  • ZStringを活用して、文字列結合や、boxing発生に伴うGC.Allocを低減する手法を示しています。

Now Available: NVIDIA DLSS 3 for Unreal Engine 5

https://developer.nvidia.com/blog/now-available-nvidia-dlss-3-for-unreal-engine-5/

  • NVIDIA公式が、AIを用いた超解像技術DLSS 3がUnreal Engine 5で使えるようになったことを紹介しています。
  • DLSS 3の基礎的な技術についても説明しています。

【Unity】 URP10,URP12,URP14でのMRTの実装の方法の違い

https://zenn.dev/r_ngtm/articles/unity-mrt-urp10-urp14

  • URPのver.10, 12, 14それぞれで、MRT (Multi Render Target)をどう実装するかを説明しています。
  • URP14で導入された RTHandlesを利用すれば、より安全にRenderTargetを管理できるようです。

C# 12.0 の新機能 - C# によるプログラミング入門 | ++C++; // 未確認飛行 C

https://ufcpp.net/study/csharp/cheatsheet/ap_ver12/

  • 現在Preview版であるC#12.0の新機能をまとめています。

RustとWebAssemblyによるゲーム開発 ―安全・高速・プラットフォーム非依存のWebアプリ開発入門 | Eric Smith, 中田 秀基 |本 | 通販 | Amazon

https://www.amazon.co.jp/Rust%E3%81%A8WebAssembly%E3%81%AB%E3%82%88%E3%82%8B%E3%82%B2%E3%83%BC%E3%83%A0%E9%96%8B%E7%99%BA-%E2%80%95%E5%AE%89%E5%85%A8%E3%83%BB%E9%AB%98%E9%80%9F%E3%83%BB%E3%83%97%E3%83%A9%E3%83%83%E3%83%88%E3%83%95%E3%82%A9%E3%83%BC%E3%83%A0%E9%9D%9E%E4%BE%9D%E5%AD%98%E3%81%AEWeb%E3%82%A2%E3%83%97%E3%83%AA%E9%96%8B%E7%99%BA%E5%85%A5%E9%96%80-Eric-Smith/dp/481440039X

  • 7/19日発売書籍

凄腕エンジニアさんから学んだ例外の話 - Qiita

https://qiita.com/TairaNozawa/items/ab878eaa0b9f64b9854f?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items

はてなブックマークの活用のすゝめ

https://qiita.com/lilpacy/items/998f4da9777b77b1fc37

  • 個人的にも、はてなブックマークは活用しているのでここで紹介。ただ、ゲーム開発に直接関係する技術の情報収集に、はてブは向いてないと思う･･･

AI駆動開発とビジュアルスクリプティングとUnreal Engine

今、開発の現場ではAI導入がすさまじい速度で進んでいる。

実装に悩んだらChatGPTに聞くのは当たり前になったし、先進的な企業では、Github Copilotを導入し、コーディングの手伝いをさせているとも聞く。直近では、パナソニックが自社用にチューニングしたAIチャットツールを導入したことで話題になった。

ascii.jp

私もご多分に漏れず、開発にAIを活用している。仕事では、Googleに聞くよりChatGPT-4に聞くことの方が多くなったし、プライベートでは、Github Copilotを使って、書き慣れていないコードを書くときの手伝いをしてもらっている。（最近だとUnityでの並行プログラミングの実装をさせた）もはやAIアシスタントのいない開発は考えられないほど、AIのお世話になっている。

こうした「AI駆動開発」手法は今後も開拓され続けていくのであろう。しかし、現状のAI駆動開発技術ではどうしても対応が難しいであろう分野が存在する。「ビジュアルスクリプティング」だ。

ビジュアルスクリプティングとAI駆動開発の相性の悪さ

ここでいう「ビジュアルスクリプティング」とは、ノードベースのプログラミング・開発のことを指す。ゲーム開発の分野だと、ノードベースの開発で最も今主流なのはUnreal Engineの「Blueprint」だろう。Blueprintの登場のおかげで、プログラミングができないゲームデザイナーも、遊びのロジックを作ることができるようになった。

他にも、Unityでシェーダー実装に使うShaderGraph、MayaやBlender等の、アーティストが使う前提のマテリアルエディタなど、ノードベースの開発ツールは多数存在する。

これらのビジュアルスクリプティングはテキストで完結しない故に、現状のテキストベースのAI駆動開発とは相性が悪い。GPT-4では将来的に画像の入力に対応するようだが、巨大で混沌としたノードベースの開発画面をGPT-4に食わせても、「お力になれません」と帰ってくるだけだろう。

▼巨大で混沌としたノードベースの画面の例

プリプロ段階で、ゲームデザイナーが遊びを簡単に作れる、という売り文句で広まったBlueprintも、まさかAI駆動開発と相性が悪いからという理由でケチをつけられるとは思わなかっただろう。では、Blueprintが使いにくくなった（時代にそぐわなくなった）から、Unrael Engineは使われなくなるか、というとそうではないと思う。

まだまだ強いUnreal Engine

Unreal Engine(以後UE)の最大の強みは、UEを使えば「Fortnite」が作れることが保証されているという実績だと捉えている。実際にゲームを作っている会社がゲームエンジンも作っているため、UEにはゲーム開発の現場に求められる機能が多数備わっている。その点、ゲームエンジン開発屋でしかないUnityと明確な差別化ができている。

また散々BlueprintとAI駆動開発の相性が悪いと話してきたが、別にAIがBlueprintに対応できないことはない。C#で書いたコードををAIに食わせて「どこが悪い？」と聞くように、Blueprintで実装したもの全体をAIに見てもらうことは難しいだろうが、「この機能を実現するにはどのノードが必要？」と部分をAIに頼むことは可能だ。

加えてBlueprintはノードベースでありながら、そのノードをテキストで表現している。この仕組みのおかげで、BlueprintUE.comのような、BlueprintをWeb上で共有するサイトも存在する。将来的にBlueprintをテキストとしてAIが解釈し、AIがそのBlueprintを修正することも可能かもしれない。

Blueprintの価値はAI駆動開発の流行でその価値を若干落としたが、UEそのものの価値は全く落ちていない。故に、UEが使われなくなることはここしばらくはないだろうというのが私の考えだ。

Unreal Engineの未来予測

UEは今後、AI時代に合わせた進化をするだろうと思う。その中で考えられるのは、UEにテキストベースで書けるスクリプト言語が導入されることだ。

最近リリースされたUEのFortnite専用拡張「Unreal Editor For Fortnite」には、Verseというプログラミング言語が搭載された。

dev.epicgames.com

Verseそのもの、もしくはVerseに類するテキストベースのスクリプト言語が今後UEに搭載されるんじゃないかと予想している。テキストベースの、ゲームデザイナーが触れるスクリプト言語が搭載されれば、そのスクリプト開発をAIがサポートするのは容易だ。

テキストベースのスクリプトをデザイナーが書くのは辛いため生まれた、ノードベースのスクリプトが、またテキストベースに先祖返りするかもしれないのは、なかなか面白い話だ。

Unreal Engineユーザーが今後どういう開発環境を求めるのか、そしてEpic Gamesはどんな解答を出すのか、今後注目したい。

色んなブログサービスを比較し悩んだ末、はてなブログを開設した

雑記 ブログの話

この度、「一度インターネット上の人間関係をリセットして一からインターネット人格を作りたい」と思い至り、Twitterアカウントを新たに開設した。

twitter.com

転生前のアカウントも動かしているし、何かトラブルがあったわけではない。しかし、10年間同じハンドルネームで活動してきて少し飽きが来ていた。というわけで、新たに「クレイ」という名前を作って、インターネット活動を始めることにした次第。

とりあえず、簡単に自己紹介を。 私はゲームプログラマーとして、ゲーム業界の端で働いている。ゲームプログラマーにも「グラフィックエンジニア」「UIエンジニア」「サーバーエンジニア」などいろいろいるが、私は「クライアントエンジニア」に属すると思う。

ブログサービスあれこれ

私は比較的古いタイプのインターネット人なので、「ブログ」というものが好きだ。なので、今回転生するときも、ブログを新たに始めるのは早々に決まった。

難航したのが、どのブログサービスを選ぶかだった。

10年以上前、初めてのブログはFC2ブログだった。流石に今の時代にFC2を選ぶというのは 倫理的にもない。

まず候補に上がったのは、Github Pages。

自分が憧れるソフトウェアエンジニアの多くの人は自前でブログをホスティングしているイメージがあるのだが、サーバーサイド・Webの知識が乏しい私が、今自前でサーバーを立てて運営する、というのはイメージができなかった。そこで、Github Pagesにサイトのホスティングを任せて、デザイン面は先人たちの知識（記事）を借りてなんとかしようというのを考えた。

これはかなり有力だった。Github Pagesに関するいくつかのページを読み漁り、なんとかできそうという手応えをつかみ、リポジトリを立てるところまでは進めた。

しかしここで問題発生。Github Pagesには1GB制限があったのだ。

GitHub Pages サイトには、次の使用制限があります:

GitHub Pages ソース リポジトリには、1 GB の上限をお勧めします。 詳しくは、「GitHub での大きいファイルについて」をご覧ください 公開されたGitHub Pagesのサイトは1GB以上であってはなりません。 GitHub Pages サイトには、月当たり 100 GB の ソフトな 帯域幅制限があります。 GitHub Pages について - GitHub Docs

テキストだけで完結するブログであれば、1GBもあれば十分だろう。しかし、自分は画像のない、テキストだけのブログにするつもりはない。また、技術的な話題はZennに書き、ブログには生活のことや、Zennに上げるには忍びない思想の強い記事を書くといった（政治的なものを書くつもりはない。今のところ）、使い分けをするつもりだ。そういう記事では画像を使うだろうから、直のこと1GBで収まる気がしない。

他にも、noteやObsidian Publishなども検討した。しかし、最終的には信頼と実績のはてなブログを選ぶことにした。markdownで書けて、自分の性格にマッチしたブログサービスはやはりここだった。はてなアカウントの切り替えはかなり面倒なので、いつか事故が起きそうだが仕方ない。

まとめ

とはいえ、いつかGithub Pagesでページは立ててみたい。転生したこのHNで実績を作れたら、ポートフォリオサイトを作ってみようかな？