ここが不人気な部分だ。安易な手法を禁止したことで、実際に時間とお金がかかった。それでも私たちはためらわず、また同じ選択をするだろう。AIゲームビルダーの多くは3Dを偽装している——傾けたキャンバスに遠近法の計算を加えるだけで、午後のうちに完成する。私たちも試したが、見た目通りの結果しか得られなかった。
決定打となったのは、キャンバス偽装と本物のエンジンでレンダリングされたビルドを並べて見た日だった。好みや仕上がりの問題ではなかった。一方はゲームに見え、もう一方は野心を持ったスプレッドシートに見えた。そこでビルダーのガイドラインに厳格なルールを書き込んだ——本物のエンジンでレンダリングするか、しないかのどちらかだ、と。Webゲームはバンドルされたthree.jsと物理演算スタックで動く。ネイティブ品質を謳うものはすべてUnity Labを経由し、そこではエージェントがUnity 6向けに実際のC#コードを書き、ブラウザのタブでプレイできるWebGLビルドをコンパイルする。
誰も警告してくれない部分：アセット
偽レンダラーの禁止は、まだ簡単な半分だった。難しいのは、本物のエンジンは与えられたものしかレンダリングできないという点で、コードだけを扱うエージェントを放っておくと、善意はあってもいびつな球体しかできない、プログラマーアートが生まれてしまう。解決策はより良いレンダラーではなく、パイプラインの順序を変えることだった——まずコンセプト、次にジオグラフィ。エージェントはメッシュに触れる前にコンセプトアートを描く。次にモデリング用のエージェントがそのコンセプトを目指してBlenderスクリプトを書き、ヘッドレスでレンダリングし、ビジュアル監査ループがレンダリング結果をコンセプトと比較し、両者が実際に一致するまでスクリプトを差し戻して修正させる。
このループは遅く、自分自身と議論するために計算資源を大量に消費する。それでも、プログラマーアートを脱却できた唯一の方法だった。ラボの各ページには監査の各ラウンドが公開されているので、私たちの言葉を鵜呑みにせず、収束していく様子を実際に見ることができる。以下は最新の作品、オルガンロフトの1回目と4回目のラウンドだ。
そして、実際にライティングとマテリアルが機能するエンジン内に配置すると、次のようになる。
サウンドも、調は違えど同じ議論だった
キャンバス偽装の音声版とは、ありきたりなオシレーターのビープ音だ。しばらくの間、私たちのゲームはそれで溢れていた——生成は安上がりだが、安っぽさが一発でわかる。診断も治療法も同じだった。厳格なルールと本物のツールだ。今ではすべてがサンプリングされた楽器音源——自社ライブラリの84種類——と、収録された環境音から成っている。港のレベルには、実際に水やカモメらしく聞こえる水音とカモメの声がある。パズルゲームの成功音は、何かによって「演奏」されたものであって、何かによって「計算」されたものではない。
なぜこの混沌をすべて公開するのか
デモリールは最高の5分間しか見せない。ラボはすべてを見せる。モデルの見た目がおかしかったラウンドも含めて。
ラボには現在83件のビルドページが公開されており、Blender Studioではアセット側の全貌を独自の形で見せている——スクリプト、ターンテーブルレンダリング、粗も含めた監査履歴のすべてだ。私たちは意図的に失敗したラウンドも公開している。良い1枚のスクリーンショットだけを選ぶことは誰にでもできる。それは何の証明にもならない。1回目の見苦しいジオメトリを含む、すべての反復を見せることは、はるかに偽装しにくい。そしてそれこそが、このやり方をしている理由そのものだ。
ここで一つ譲歩する。このアプローチへの批判者たちは、コストの点で間違っていない。キャンバス偽装なら午後のうちに出荷できるが、私たちのパイプラインは、何かがプレイ可能になるまでに監査ループ、モデリングエージェント、実際のエンジンのコンパイル時間を必要とする。簡単なプロトタイプや使い捨てのジャムゲームには、このオーバーヘッドは正直割に合わない——キャンバス手法の方が速く、誰も細部までスクリーンショットで見ない5分間のゲームプレイなら、それで十分とも言える。それを否定するつもりはない。ただ私たちは5分の使い捨てゲームを作っていないだけで、品質そのものが製品になった時点で、実際のプレイヤーとの接触に耐えられるのは、この遅い道だけなのだ。
