読者です 読者をやめる 読者になる 読者になる

ゲーム開発者が偉ぶるブログ

ゲーム開発のビジネスやマネジメントについて日々思うことをあれこれ偉ぶって書き綴ったもの。

Forza Horizon 3 の空

“現実の空”をゲーム内にまるごと再現した「Forza Horizon 3」の空表現 - GAME Watch

GDCになると海外の記事で賑わいテンションがあがる。英語はサッパリなので表面的なところしか追えないが…

 

さて、フォルツァの空の記事の写真を見てすげー!と思ったら実写撮影素材なのか。少々残念。

しかしこれだけガチ装備で撮影に挑むというのは開発者の体験としてもとても良いな。

タイムラプス撮影はかなりしんどいと聞く。高価な機材を置きっぱなしにはできないので交代で見張りが必要だし、時間に応じて適切な露出を予め割り出しておかないと行けない。

そして時間ごとの設定を変更しつつの自動撮影を行うならノートPCから専用のアプリケーションで制御するようなセッティングが必要だ。

難しいのは次回作以降でどう進化させるのかという部分だろうか。

最終的には全時間帯の動画をシークして長す日が来るのだろうか。

それこそCrytechの「Ryse Son of Rome」がジオメトリキャッシュを活用して破壊表現のために数十ギガを費やしてリアルタイムで再生していたのを彷彿とさせる。

非常にアリだろう。

ノウハウの言語化について

何か仕事を与えられた際に、すっと手順を理解して高い品質でこなす人がいる。

それはその人にとって得意とする分野であり、それまでの経験や考え方との親和性が高く、どうすべきか特別に意識する必要がない。感覚でやってのける。

センスが良いと言い換えることもできる。

この場合、ノウハウとして言語化するのが難しく、できない人の気持ちがその人には理解できないケースが多いのではないかと思う。

 

逆に、同じ失敗を繰り返したり何度も指摘されたり、思うように品質の良いアウトプットができない場合には、ノウハウを言語化して明示的にした上で理屈として理解するという努力のプロセスが必要になってくる。

そしてこれが興味のある分野なら良いが、そうではない場合には苦労する。興味があっても難解な内容なら同じことだろう。

ここはどうしても努力を繰り返して少しずつ習得して行かなければならないだろう。

ショートカットはできないものか考えた時には、その分野の物事の捉え方や考え方、本質といったことに気付き目覚めるという、その人の中でのイノベーションを起こすのが良いとは思うのだが、その具体的なアプローチとしてはノウハウを言語化して得意分野に変わったという人に教えを請うくらいしか思いつかない。

感覚でやってのける人にはカリスマ性の高いタイプが多い印象で、そういう人にお近づきになりたいとかノウハウを聞いてみたいとか思いがちだが、そういう人に聞いても参考になるケースは珍しそうだ。

開発者視点での「NieR:Automata」プレイ感想

f:id:game_dev:20170305191340j:plain

PS4専用タイトルの「NieR:Automata(ニーアオーオマタ)」をとりあえず3周クリアしたので、その感想をつらつらと書いてみる。

前提としてシリーズのプレイは本作が初めてで、ヨコオ氏のファンという訳では無く過去作の知識も全くない。メインキャラクターが吉田明彦氏のデザインでありプラチナゲームズ開発のアクションであることがプレイ動機として大きく、発表からずっと楽しみにしていた。

素晴らしいことに、国内の売り上げ本数が初週で20万本近い。

続きを読む

今Houdiniが熱い

今は2017年の初頭。

2015~2016年は日本国内のゲーム開発でUnreal Engine 4の採用報告が一気に増えた年だ。

一方でSubstance DesignerやPainterの導入も徐々に進み始めてきた。ボーンデジタルがかなり前よりデモを行っていた記憶があるが、Uncharted 4のスタッフとタッグを組んでのアプローチもあり、ようやく実りを見せてきたという印象だ。

これらに共通するのはノードベースのエディティングだ。
UE4のブループリントしかりマテリアルエディタしかり。非破壊であり、流用性の高いノードネットワークを構築することも可能だ。今や多くの開発者がノードベースが珍しくなく感じてきていることだろう。

そんな中、2016年頃からゲーム業界にもHoudini導入の兆しが見えてきている。

ノードベースと言えば、何よりもHoudiniが歴史があるイメージだ。だが非常に高価で、予算をかけた映画や大手のスタジオでのVFXで一部使用されている‥という印象でしかなかった。

それが、Apprenticeという無料学習版の登場により自宅で無料で学習できるようになった。
そしてHoudini Engineの登場だ。

Houdiniを触ってみたりチュートリアルなど漁ってみた感触としては、破壊やパーティクル、流体といったダイナミクス系の表現がシェルフから手軽に試せて、しかも品質が高い‥という面も良い面であることに違いは無いが、何よりも「何でもできる」と言わんばかりのGUI周りの仕様とモデリングのみならずダイナミクスにまでプロシージャルに構築していける柔軟さに心を打たれる。

そして個人的には、プロシージャルということ以上にGUI周りの自由度の高さがすごい。パラメータを別のパラメータに自由に関連付けたり、パラメータにエクスプレッションを設定したり、果てはパラメータを自由に増設可能だ。

だが、ゲーム開発のワークフローにどこまで組み込めるかというと、気になる点がいくつかある。

・お値段の高さ。

・0からのモデリングのし易さ。

・アニメーションの制作のし易さ。

Pythonを使った強化周り(開発資産にしていけるのか)。

・Mayaとの間で情報を失わず柔軟な行き来が可能かどうか。

・バージョンアップでの互換性(過去資産をそのまま運用できるか)。

・Houdini Engineの有用性。

日本国内のゲーム開発はSIが減ったこともあり今やMayaがシェアを独占状態だろう。
その中で、Houdiniをワークフローの一部にだけ使用するという導入はあっても、Mayaになり代わっていく未来はまだまだ見えない。

国内のHoudiniユーザーの少なさ、情報の少なさからも導入したは良いが使いこなせるのか‥という危惧もある。先を見据えて、TA素養の高いスタッフ1人2人をHoudiniのスペシャリストを育てるつもりであてがうようにする必要がありそうだ。そのためにはどういった用途に力を発揮するのか明確に理解している必要がある。また、スペシャリストを育てる余力があるのか?という問題もある。

スペシャリストが育つ土壌ならHoudini EngineをMayaやUE4に導入していく道もあるだろう。だがまだ事例が見当たらないからだろうか。メリットが見えにくい。
だがゲームエンジンとDCCツールの行き来を少しでも軽減できるなら、それだけでも価値はあろうというものだ。開発がなるべくゲームエンジン上で完結し、かつ快適であるのならそれに越したことはないからだ。

Houdiniが広がるのかどうかは、実例が充実してきてからだろう。

それが5年後なのか、10年後なのかはまだ分からないが、今触っておいて損の無いツールであることは間違いない。

技術書の執筆の難しさ

先日、CG関連の技術書の印税の話をした。

日本は今でもCG関連書籍が少ないように感じる。が、それは出しても売れないことの裏返しだろう。書籍はゲームソフトとは違い、小売店(本屋)から返品が可能であるという。売れる見込みが無いと本を刷れない。

電子書籍のみで出せば在庫の心配が無くてノーリスク?

いや、それでは購入者はさらに減り、また筆者の執筆料に最低保証をどうするのかという問題がある。紙の書籍の場合は最初に発行部数があり、それに合わせてある程度の部数を原稿料として払ってくれるのだ。一冊も売れなかったとしても最低保証分は払ってもらえるからこそ、執筆しようという気持ちになるものだ。

だが難しいのは売るだけでなく中身の問題もある。

沢山売りたいなら広く浅くという内容になり、ニッチな技術を扱う場合は入門書からとなる。執筆者にとって入門書ほど書くのが面倒なものはない。ソフトウエアの解説書なら、インストールとGUIから説明しないといけないのだ。そんなもの、マニュアルを読めと言いたくなる。しかしマニュアルを読まない読者層に読んでもらうためにも、イラストや図をふんだんに使って文章少な目でテンポ良く展開してゆく必要がある。

そして簡単に陳腐化する。一番困るのはメジャーバージョンアップが激しいソフトウェアを扱う場合だ。一年経つともう書籍の通りにいかない箇所が出てくるのは書き手としてもツラい。

こういった理由によって技術書を書く技術者としては非常にモチベーションが上がり難い。技術者は情報発信はしたくても、自分でなくてもできる余計なことに貴重な時間を割きたくないものだ。

しかも書籍になるともなるとブログによる発信とは違って間違った情報を書いてしまった時にリカバリーか効きづらい。いや、当然ながら「間違った情報は書けない」という心持ちで臨むものだ。なので当たり前のように知っていることでさえも、単語の使い方は正しいか、言い回しは正しいかという部分から始まり、技術回りについても入念に調べて書く必要がある。

「知っていることをそのまま書く」だけでは全く済まないのだ。非常に大変な労力がかかる。

ブログは書く方にとっては気楽だが、読み側にとっては情報があまりに分散されていてまとまっていないため、リファレンスとしても、集中して学びたい場合にも向かない。

ただ近年は技術書の同人誌が増えてきている。これは嬉しいことでもある。ただしこれらは当然ながら赤字覚悟で有志で制作しているものであろう。

もう少し、大手企業が業界全体のために書籍を出すのを助長するような動きがあると良いのだが。国から補助金とノルマでも与えられない限り実現は難しいだろうか。

技術書の印税の現実

「印税」と聞くと夢のある言葉のように思えるだろう。
だがそれは1万部以上は売れる書籍の場合だ。

悲しいかな、日本ではCGの技術書は2000部も売れなかったりする。

書籍を書くチャンス自体は意外と転がっているもので、特にまだ書籍が出ていないソフトウェアは狙い目だ。マニアックなソフトをSNSやブログで解説し続けていればオファーがやってくる。

今ならSubstance DesignerやSubstance Painterの書籍をどこの出版社も早く出したがっているだろうし、ニッチ所を狙うならBodyPaint 3DとかMariとかMarvelous Designerあたりが注目を集めやすいのではないだろうか。
特にSubstance DesignerやSubstance Painterは現場でようやく導入が進みつつあるが専門学校では全くと言っていいほど導入されていない印象だ。書籍があればベテラン講師が見つからなくとも授業を開設できる。

だが問題はどれくらい購入者がいるかなのだ。
ニッチなものほど売れにくいし絶版になりやすい。
企画は通り易くも通りにくくもあるだろう。あまりにニッチ過ぎると出版社に思われれば企画は通らないかも知れない。でもまだそのソフトウェアを扱った書籍が一冊も国内にないなら通ったりもする。

一昨年のCEDECの出版社による講演は非常に生々しい話だった。金額も売上もかなりの部分公開されていて、好感が持てる反面「CG書籍に印税の夢は無いなあ‥」と悲しくなったものだ。私も過去に執筆させて頂いて出版された書籍があるが、ネットで調べた通りのものだった。

印税は定価の7~8%、多い人で10%。

つまり7%だった場合、定価3000円の書籍なら1部売れれば210円、1000部売れれば21万円、2000部売れれば42万円。しかし冒頭に書いたように現実には2000部売れなかったりするのだ。

2ヶ月まるまる家に引き籠って40万円いかないかも知れない。
そうなると、金銭を得るための仕事としては割りの良いものとは思えなくなってくる。

しかし一方で、一冊書籍を書けば知名度が上がり、仕事は舞い込んで来るようにもなる。そういう意味では一冊書いておくのはとても良いように思う。

翻訳されて海外でリリースできるならまた話も違ってくるかも知れないが。

 

ウン万部売れるような本を世に出して印税ウハウハになってみたいものだ。

 

ゲーム業界の守秘義務の境界線

日本のゲーム業界は閉鎖的だと感じる。

まだまだ業界全体的に、会社間での交流、ノウハウの発信等に対する否定的・懐疑的な空気があり、そのため業界で働く人にとって交流や発信には抵抗感が生まれている。

会社によっては他社の従業員との飲み会が禁止されている。

勉強会は見知った同士でクローズドで行わないと発言や発表がやりにくいし、開催自体が難しい。

だがそれは裏を返せば自分達が自分達を信用していないことに他ならないように思える。

他社の人間と飲めば社内事情をネガティブに語り、SNSでは匿名なのを良いことに「今日、仕事であった出来事」などそれとなく発信してしまう、そういう事例が後を絶たない事実がある。
(匿名というのは案外脆い。HNの正体を明かしている相手がいれば知れ渡る可能性があるし、告知系ツイートのRTやフォローしている中に社名を出しているアカウントがあればそれでなんとなく想像できてしまうものだ)

それだけではない。

パブリッシャーにはパブリッシャーの、ディベロッパーにはディベロッパーの守秘義務の壁が存在する。

パブリッシャーはちょっとした情報漏洩が株主や株価に大きく影響する可能性がある。新しいハードの情報や新作の大型タイトルの情報ではリーク情報が飛び出すことも日常茶飯事で、蓋を開けてみれば実際にリーク情報の通りだったりすることも多い。

ディベロッパーはパブリッシャーの許可が得られないことには開発情報を出せない。未だに社名を出したくても社名すら出せないケースがある。反対に守秘義務を固く守ることをクライアントへのアピールポイントとしていたりもする。そのため守秘義務に過敏になるのもやむを得ない面がある。

そんな中で「じゃあ何もかもが守秘義務なのか?」というとそんなことは全無い。
境界がハッキリしていないから「何も言わないことが一番安全だ‥」という保守的な状態になっているだけに思える。

そこでまずハッキリさせたいのは、開発中であり未発表であるハードやタイトルの内容について触れるのは完全にNGで、それは誰にとっても当たり前と分かっていることだ。今開発しているタイトルの物語はこうで、こんなキャラが登場して‥みたいな話をして良い訳は無い。
とは言えすでに一般公開されている情報なら当然問題は無い。関わっているタイトルについて社外の人間に話す際には、何がどこまで公開されているかをちゃんと把握しておく必要がある。

次に開発環境。開発体制やワークフロー、使用ソフトやミドルウェアなどは守秘義務に触れるカテゴリだ。信頼できる人間関係の中で、クローズドな場で情報交換として話し合う分にはどんどん行えば良いと個人的には思うが、一歩間違えると問題になる可能性もある。
そして、この時考えないといけないのが単なる愚痴やチーム批判になっていないかということだ。そういったやり取りで得た情報をちゃんと業務に活かせるのか、よく自問した方が良い。

それから、一般的に入手可能なツールやゲームエンジンの仕様・使用方法・ちょっとしたTIPSなどをまるで「弊社独自のノウハウ」かのように「秘匿した方が良いのでは」と考えてしまうのは完全に間違っていると感じる。例えばUnityを開発で使用していて、開発スタッフが匿名のHNを持つSNS上でUnityのちょっとしたTIPSを公開していたとして、そのHNが同じチームのスタッフと知っている場合に「これ大丈夫なのか?問題なのでは?」とすぐに考える人間がいる。
こういう時「本当に日本国内の開発現場は面倒臭いな」と思わざるを得ない。

情報発信する内容の何がチームとって問題があるのか、クリティカルになる可能性があるのか、そういったことを考えた上で問題と感じているのか、よく考えて欲しい。
はっきり言って、職人気質な日本人スタッフが「秘伝のタレだ」と思っていることの多くのTIPSは海外サイトに普通に転がっている。単に世間知らずなだけの場合が多いというのが私の実感だ。
(ただし所属企業や本名を明かしてSNSで情報発信する場合は、細心の注意を払う必要があるとは思う)

CEDECのような会社を通して発表するような場だけでなく、個人単位の勉強会やSNSでももっと開発手法や技術情報について活発にやり取りされる世の中になっていって欲しい。