アンリアル日記 ― 第 3 日目 (2015/3/4)
(By Christopher ‘Jack’ Nilssen)
稼ぎの効率？
インディー系のゲーム開発とお金のことについて、少しだけお話します。
Unity 5 関係の掲示板を開くと、アンリアル・エンジン 4 と比較するコメントがたくさんあります。それらの大多数は、Unity の独立性とアンリアルの 5% のロイヤリティが話題となっています。
計算してみると分かりますが (ゲーム開発者ならお手の物ですね)、アンリアルの方は、ゲームが 1 四半期で 3 千米ドルを超えると、その超えた分に対してコストが生じます (訳注: 5% のロイヤリティが課せられます)。一方、Unity では、年間で 10 万米ドルを超えた場合にコストが生じます。それは 1 ヶ月に 75 ドルです。会計的な観点からは、Unity が勝ります。
この観点による議論を読むと、戸惑ってしまうことがあります。それは、多くのデベロッパーたちが、ファンタジー的なこの最低ラインの金額に魅せられてしまっている (そのせいで物事が見えなくなってしまっている) ということです。そのような議論はすべて、年間で 10 万ドルを超える収入をもたらすゲームを作ったデベロッパーたちによって発せられている、ということはないでしょう。それどころか、多くのデベロッパーたちはその額を達成してはいないはずです。
だから、「お金を稼ぐなら、Unity の方がいっぱい稼げる」という意見が出てきます。いいでしょう。でも、経済のスケールやその他のファクタも考慮に入れなければなりません。その多くは、稼げるゲームを作らなければならないということです。結局、これが誰にとっても一番難しい。時間が経つにつれ、ますます難しくなるばかりです。
アンリアル vs Unity のネット上における論争に戻りましょう。面白いことには、両者のエンジンを擁護する人たちにはいささか異なっています。おおざっぱに言うと、Unity を盲信している人たちは、いい時も悪い時もどんな時でも、いくつものバージョンに渡ってこのテクノロジーを利用してきた人たちです。それについては全くもって尊敬できます。僕もそうでしたから。ところが、アンリアルを支持する人たちは、まずゲーマーという立場を取り、デベロッパーという立場はその後になります。これは何かを物語っていますね。
平均的なゲーム コンシューマーがどの程度ゲームのテクノロジーに詳しいかと尋ねられれば、僕なら「それほどでも」と「まあまあ」の間くらいと答えてみたいです。ただし、「まあまあ」から平均以上のテクノロジー知識をもったプレイヤーたちが、その知識に基づいてゲームを購入するならばどういうことになるでしょうか？また、あなたのゲームの売上のうち 5% が、そのテクノロジーでゲームが作られているから購入した人たちによるものだとしたらどういうことになるだろうか？絶対に考慮しなければならないことでしょう。
また、ヒット作を作るためにどの開発用ツールチェーンを使うべきか、というような重要な決定をする場合は、理性と感情を分離しなければなりません。少なくても、僕はそのように信じています。なぜなら、ずいぶん長い間 Unity にべったりでしたから。最終的には、生産やビジネスにとって、究極的にはユーザーにとって最善の選択を、客観的な知識に基づいて行うことが大切だということになります。いつものことながら、X というエンジンが Y というエンジンよりも優秀だということを言おうとしているのではありません。
少なくても今は。
さらに言えば、これらのエンジンは両方とも無料で開発できるので、理論的には、どちらかのエンジンでゲームを作って、後からもう片方に移植できます。たとえば、(今後) 100 万ドルという法外な収益が見込まれ、それに対するロイヤリティの 5%、つまり 5 万ドルをアンリアルに支払いたくない場合は、Unity でよりコストパフォーマンスが高いバージョンを作って、アンリアルのバージョンを発売中止にすることができます。(訳注: 計算は 1 四半期ごとなので、1 四半期で 3 千ドルを超えた分は、途中で発売中止にしても支払う義務があります。ただし、発売中止以降は収益がなくなるので、3 千ドルを超えること自体がなくなりますが。)
このようなことは、ありうることです。面白そうです。なぜなら、両テクノロジーの大きな違いが (ユーザーにとって) 明らかになるからです (違いというものがあるとしたらですが)。これまでそのようなことが行われたと聞いたことはありませんが、ひょっとしたらあるのかもしれません。確かに、僕が 3月2日以来やっていることなのですが。
よく眠れなくて、2:45 頃に目を覚ましました。それで、アセットのパイプラインに手を加えました。本サイトには、Unity でコンセプトをどのように展開したかということに関する図がどこかにあります。アンリアルでも大差ありませんでした。ただし、アンリアルの方がオリジナルのレンダリング パッケージの見栄えにずっと近い点が異なります。
これまでに気が付いた不明な点
初めてアセットを保存すると、Unreal Project フォルダ内にディレクトリができるのですが、これができなかった。ということは、アンリアルでそのフォルダを作っておき (たとえば、Meshes フォルダ)、アンリアル内部からアセットをインポートする必要があるということです。その後に、Meshes フォルダが Windows Explorer に表示され (僕の環境は Win 8.1/64 です)、直接 3DS Max からアンリアルに保存できるようになります。
そのあとは、Unity とほぼ同じでした。ただし、外部でアセットを編集する場合に 1 段階余計にかかる点は異なりました。Unity の場合であれば、メッシュまたはテクスチャを編集する場合、外部の編集ソフトウェアでそのプロジェクトのアセットを開いて保存し、Unity に戻ると、自動的に更新されました。アンリアルでは、外部で保存するとインポーターが再度初期化されるため、更新される間、クリックして待たなければなりません。わずかな時間ですが、この点については Unity の方が勝ります。
再インポート時の Substance の複製。これはイラッとする点です。すでにあるマテリアルと同じ名前を付けたくても、複製が作られ見苦しくなります。これは、Substance がアンリアルにネイティブで (まだ) サポートされていないことに関係するのですが、マテリアルを編集および再インポートする場合には覚えておくべきことです。
このようなことは別にして、編集ソフトウェアとアンリアルを行き来することは、とてもおもしろいです。アンリアルのカスタム コリジョンのインポート オプションはとても気に入っています。この機能は、『Child』の建築物ジオメトリに多用しました。かなり前に作ったアセットをお見せしましょう。インポートすると Substance の Yebis レンダー ウィンドウで表示されたものと全く同じように見えます。
(アセットが全く同じように見えることは、僕にとって非常に重要なことです。これによって、この移植プロセスが即座に価値あるものとなりました。)
C++ で少しコードを書いてみましたが、Unity で C# を使ってやっていることとあまり変わらないように思えます。どちらも C がベースになっているからでしょうか。Resharper が有効化されている Visual Studio 2013 IDE はまったく同じです。
新しい言語の構文を覚える時に大切なことは、開かれた心で接することです。ある言語が、この用語はこれこれこういう意味だ、というのだったら、それを習い性になるくらい覚えてしまうのです。多くのプログラマーがこの点をおろそかにしています。「なぜこれにはこんな名前がついているのか」とか「なぜこんな動作なのか」ということに無駄に時間とエネルギーを費やしているのです。プログラミング言語を再定義するとか、独自の言語を作るというのでしたら、それも良いでしょうが、使い方をマスターするのでしたら、とにかく受け入れるという単純なやり方の方がはるかに容易です。
アンリアル・エンジンの wiki には Blueprint Jump Starts シリーズが用意されています。カラーグレーディングがとても簡単なのには衝撃を受けました。カラーグレーディングは、ビジュアルに関する出力にフィルターをかけて、違った見栄えを作り出すことです。たとえば、黒をつぶすとか、カラーを入れ替えるなどです。やるべきことは、(ダウンロード無料の) LUT と呼ばれる特定のカラー ストリップをともなって、画像編集ツール (Photoshop など) でシーンを開くだけです。フィルターや調整レイヤー、エフェクトを使って画像を編集して、カラーストリップを保存します。カラーストリップはアンリアルのポストプロセス エフェクトのボリュームの中にドラッグアンドドロップされます。あっという間のカラーグレーディングです。Unity であれば、コミュニティ メンバーが作ったプラグインにお金を払ってやるしかないのです。
https://www.youtube.com/watch?v=oBzHB-VRCS0&index=4
(間もなくリリースされるインディー系のタイトル『SUPERHOT』を動かすコアのメカニズムを模したブループリントがクールだ)
アンリアル エディタには、もう一つ極めて重要な機能が備わっています。それは、K キーを使って、テスト中に変更した変数を保存できる機能です。Unity 4 では (そして K キーを押さなければアンリアルでも)、シーンをテストしてエクスポーズされている変数に変更を加える (たとえば、武器によるダメージ量を増やしたり、プレイヤー キャラクターのジャンプできる高さを増やす) ならば、テストを終了するとそれらの変更は失われてしまいます。かつて保存できるプラグインがありましたが、それと同じ機能がアンリアル エディタでキーを押すとデフォルトで利用できるようになったのです。もちろん、ある種の大惨事につながる可能性はありますが、事態を正確に把握しているデベロッパーであれば、これが神機能であることに同意するはずです。
本当にこのツールは気に入りました。