BABYMETALは赤くて黒いシン・ゴジラ・メタル!!

9/20東京ドームでBABYMETALを観た。僕にとっては昨年のOZZFESTに次いで2度目のBABYMETALのライヴである。

開場前、東京ドーム周辺では中高生から中高年まで幅広い年齢層のファンの姿が見られた。女子中高生と父親という組み合わせもちらほら。中学生の時から20年以上メタル聴いてきてこんな光景は初めて見た。メタルというものがここまで一般に広まったことに確かな感慨があった。

昨年のOZZFESTでのモッシュピットが楽しかったため指定席で観ることに正直不安があった。洋メタルリスナーにとってドームなんてただ大勢の客を押し込める所でしかない。しかし、ドームに入って巨大なステージセットを観た時にその不安は払拭された。これは絶対にドームでしかできない。ドームでやることについて説得力ある理由を用意する。さすがにその辺は抜かりない。BABYMETALが世界屈指のライブアクトであることの証明である。三方向に大きくせり出たステージはスタンドからも距離を感じさせない。

開演時の煽りビデオで初めて知ったことなのだが、2日かけて1st/2ndアルバムの曲を全て演奏する、そして同じ曲を2回やることはない、つまり1日目のセットリストに入ってた曲はこの日やらない。これは2日間足を運ぶ人にとっては最高だと思う。自分は聴きたい曲聴けなかったりしたけど。

客席側に3方向に突き出たステージの先に、3人のメンバーがそれぞれ貼り付けられた十字架が下から現れライヴがスタート。十字架が中央の円形のステージに移動して3人が合流すると今度はその円が回転し始めて、全方向に対してダンスを見せる。凄い。当たり前に盛り上がる演出。

この日は1stアルバム収録の曲が多かったが、キーの高い初期の曲ではSu-MetalはAuto-Tuneを使ってるように聴こえた。まあこれは仕方ない。年齢的に声が変わる時期なので。

個人的に最も好きな曲「紅月」が聴けてよかった。これはちゃんと歌ってた。ヴォーカリストSu-Metalの最大の見せ場。

MCなし、アンコール無しで一気に突き進む90分間の戦い。洋メタルすら忘れてしまった様式美。そしてクライマックスでは観客全員に配られたコルセット(ヘッドバンギングにちなんでいる)が赤く光る。この数万人の観衆の一体感。スタンディングのライヴが楽しいバンドなのに「もう一度ドームで観たい」と思わせてしまう体験の価値。

僕はもうBABYMETALのことをKISSやMANOWARやBLIND GUARDIANやDARK TRANQUILLITYと同じくらい好きになってるのかもしれない。この年齢でしかできないパフォーマンス、今しか見られない芸術だから、本当に愛おしく思える。来年もまたドームで2日間や3日間やるんなら全て行きたいと思う。

既に頂点を極めた感があるが、来年は何を見せてくれるだろうか。ジャーナリストの常見陽平さんが指摘していたが、この2日間で演奏された数々の名曲も過去のメタルのオマージュやパロディという所からは脱却できてないのは事実。
http://blogos.com/outline/191213/
1stは日本のラウドロックやジャパメタのオマージュ。2ndは洋メタルのオマージュだった。3rdアルバムは一体どんな内容になるだろうか。

この日、BABYMETALとは何か改めて考えた。洋メタルリスナーの中には3人が楽器を演奏しないし作曲もしないことを理由にBABYMETALを嫌う人たちがいるが、何を言うか、このパフォーマーの3人を中心にバックバンド、作曲家、作詞家、プロデューサー、マネージメントその他企画演出スタッフというチーム体制で作り上げるプロジェクトこそが日本でしかできないメタルじゃないか。まさに「シン・ゴジラ」で観られた日本の最大の武器であるチーム力。BABYMETALはシン・ゴジラ・メタルで良い。赤いし、黒いしね。

CEDEC2016まとめ(1日目)

CEDEC2016で見たもの聞いた話を時系列順に。当初3日分のことを全て1つの記事に書こうと思っていたが凄く長くなりそうなので1日ずつに分けて書くことにした。懇親会の話やCEDEC運営への意見も書く。

8/24(1日目)

HTCViveを体験(The Blu)

基調講演を聴かずにすぐにHTCViveの体験コーナーに向かった。VRには完全に乗り遅れていて、Viveは初めての体験だったのだが、まずその重さに萎えた。重すぎて頭痛くなってくる。まず最初に体験したコンテンツはThe Bluの3つあるコンテンツのうちLuminous Abyssという深海の底をライトで探索するもの。探索するって言っても3~4m四方の箱の中で「周囲を見回す」ことができるだけで全然探索している感じがしない。ここで10分くらい使ったが、はっきり言って途中で飽きてしまった。すぐに他のコンテンツに変えてもらえば良かった。次に残った時間で同じThe BlueのWhale Encounterを体験した。これも歩く意味はまるでないのだが、沈没船の看板に乗る自分と海底との高低差が確かに感じられ、目の前に巨大なクジラが現れた時はその迫力に圧倒された。Viveの高画質もここで生きる。やはりスケール感こそがVRの売りではないだろうか。なので、狭い部屋の中を歩き回るルームスケールVRは今の所どうでもいいと感じる。脱出ゲームとかは応用できそうだけど。とりあえず今回の体験はここまで、他のコンテンツも体験したいので夕方の整理券を貰った。

PSVRを体験

PSVRも初めての体験だった。その軽さ、装着感の良さ、着脱の容易さに驚いた。これがSONYか。コンシューマーエレクトロニクスを製造する事に対する意識がまるで違う。HTCとSONYの間には越えられない壁がある気がした。PSVRのハードウェアとしての完成度はただ賞賛する他ない。体験したコンテンツはモーションコントローラーを両手に持って積み木を投げるだけというしょぼいものだったが、一応モーションコントローラーを使って「右手で上に放り投げた積み木を左手でキャッチ」する事くらいはできるのが分かった。あと、モーションコントローラーによる移動はちょっとストレスがあった。この「移動」のストレスをなくすだけでもViveのルームスケールVRのメリットはあるのかなと思ったが、PSVRでストレスや違和感のない移動のメカニクス考えるのがゲームデザイナーの仕事だよなと思った。いやあそれにしても楽しみだPSVR。

ゲーミングとVRにおけるマシーン・ラーニングの未来 The Future of Machine Learning in Gaming and VR

さて最初のセッションはこれ。受講した理由は今作ってる2030年を舞台にしたゲームの設定に説得力を与えるために未来の技術についてもっと知りたいと思ったから。深層学習とはなにか、強化学習とは何かを詳しく解説。この分野にも乗り遅れていた私としてはそれだけでも勉強になるけど、ゲームへの応用というと、FPSでシングルプレイでの練習がマルチプレイでまるで役に立たないという問題に対し、シングルプレイで使用するAIに上級プレイヤーの動きをシーケンス単位で学習させた所かなり好評だったという話があった。VRへの応用はあまり話していなかった。というより私があまり理解できなかっただけかもしれない。その他、Alpha Goが次に挑戦するStarcraftは局面の多様性が碁の比ではないという話。はっきり言ってついていけない部分が多かったので、CEDILにアップされたスライドで復習が必要に感じる。

MIDI復活ッッ!! レガシーテクノロジーを駆使してインタラクティブミュージックに挑戦せよ!!

これは素晴らしかった。スマフォゲームにおいて、状況に応じてトラックやエフェクトをオンオフしたりパラメーターを変化させるインタラクティブミュージックをやりたい場合、全てオーディオストリーミングにするとどうしても複数トラック分サイズを食うので、Wwiseというミドルウェアを使ってPS1の頃のゲームみたいに自前で小サイズのサンプラー音源を作ってそれをMIDIで鳴らすというもの。また、全てMIDIにしちゃうとクオリティが微妙なので、ブラスやギター等はオーディオトラックにして、MIDI音源と同期させたらしい。そのような場合でもWwiseなら各トラックの再生タイミングをしっかり合わせられる。普段私が使ってるUnityでやろうとした場合、はたしてちゃんと同期取れるのか分からず実装コストも読めなかったので、インタラクティブミュージックは全く考えてなかったのだが、かなりの興味が湧いてきた。多分次回作でWwise導入すると思う。なお、「インタラクティブミュージックは企画側からの要望だったのか?サウンド側からの要望だったのか?また、実装にあたってゲーム内のトリガーとサウンドのパラメーターを紐づける仕様は企画側とサウンド側どちらで決めるのか?」と質問したところどちらもサウンド主導であったが、後者に関しては企画とプログラムとサウンドで顔突き合わせて仕様をつめていくという話だった。音を消してプレイすることの多いスマフォゲームにおいても音で楽しませようとする姿勢等、ゲーム会社内製のサウンドはかくあるべしと感じたセッションでもあった。

モーションマッチング – 次世代アニメーションへの道 Motion Matching – Road to Next-Gen Animation

GDCで発表されたUBIの新たなアニメーションワークフローの話。正直GDCの時の記事を読んだ時はあまり理解できていなかったのだが、やっとどういうものだか理解できた。事前に渡した「ダンスカード」という演技内容をダイアグラム化した指示書の指定の通りにアクターが20分間演技を続け、キャプチャーする。そこから一つ一つアニメーションを切り出すのが従来の作り方だが、UBIのこれでは、ゲーム中のキャラクターのステートやプレイヤーの入力から20分間のアニメーションデータの中をフレーム単位で「次にとるべきポーズ」を検索し最適なアニメーションを生成するという。発想としては明快かつ画期的。それを実装する技術を数式まで見せながら解説。ここでも強化学習が出てくる。はっきり言って途中ついていけなくなった。これも復習必要。一つ面白いなと思ったのは、前述したダンスカード。これは、既存のステートマシーンの概念を図面化して収録すべきモーションを網羅したものだと思ってる。ちなみに「ミドルウェアとして他社にライセンスする予定はないのか」という質問に対しては「会社の上の方と交渉中」という回答だった。そういう質問が出てくるくらいにインパクトの大きいシステムだと思う。

Tokyo Demo Fest ~ a state of demoscene ~

インタラクティブセッション。モニターにリアルタイムで映される名作デモの数々に観入っていた。今年のTokyo Demo Fest以来の再会となるFL1NEさんから色々話を聞かせてもらった。高性能のデスクトップPCを台車に積んで電車で運んで来たらしい。今年は音楽とデモと両方出品してどっちつかずになってしまったけど来年はどうしようかなと考えてる。自分は専業のプログラマーじゃないけど自分でシェーダー書いて綺麗な映像出せる人には憧れる。一方で自分は音楽に専念した方が良いのではという気もする。いずれにせよ2月にああいうイベントがあって、そのために冬季鬱で低下しがちな創作のモチベーションが再燃するのはありがたい話である。

HTCViveを体験(Tilt Brush)

この日2回目のHTC Vive体験。ここで体験したのはGoogle開発の3DペイントツールTilt Brush。これは面白い。体を大きく動かして空中に絵を描き、自分の描いた絵に囲まれる体験の新鮮さ。これはViveの重さや不快感を忘れてやり続けてしまった。もしかしたらルームスケールVRはコンテンツを体験するよりコンテンツを作ることの方が向いているのではないかと思った。例えばゲームのレベルデザインをする時に自分でレベルの中に入ってオブジェクトを手に持って運んで配置していく等。考えただけでわくわくする。VRがコンシューマーエンターテイメントとして普及するのはまだまだ先だと思うけど、プロユースのツールとしての導入はかなり早く進むかもしれないと思った。要注目。

ゲームアニメーション制作時に発生する課題に対するラウンドテーブル

当初はこっちの方を観に行こうか迷っていたが、たまたま講演者控室の前でモデレーターの2人とスタッフパスで手伝いに来ていたFFアギトの時の同僚に会って談笑し、その流れでラウンドテーブルに参加する事となった。(しかし何故アニメーションのセッションを同じ時間に重ねるか・・・)入場時の待機列がもの凄かったのだが、「議題を書いてくれた人は優先入場して座れる」とのことだったので議題を書いた。ラウンドテーブルでは以下の議題が話し合われた。

  • フォトリアルなモデルに対するアニメーション

各社ともに「キャプチャーそのままじゃなくて何らかの手付けアニメーションの上乗せはする」という話。キャプチャーしても結局ループで使うことになるアイドルアニメーションは特に違和感が目立つのでループに対してランダムでノイズを上乗せするという話等。

  • アニメーションのアウトソーシング

アニメーションのリファレンスも見つからないし、自分で演技もできない時は結局のところ発注元と発注先とモーションアクターで顔突き合わせてつめていくしかない、そういう意味で海外へのアウトソースはかなりリスクが高いという話。海外へのアウトソースで結局海外に出向いて指導しているというケースも。

  • アートディレクターが自分の作業できない問題

ある程度自分が作る仕事ができなくなるのは仕方ないが、アートディレクターの役割はあくまでもアートの品質を向上させるためのクリエイティブディレクターであるので、マネージメントは別に人を当てた方が良いという話。

  • 非実在系クリーチャーの動かし方

体の各部位の重さを考えて物理法則に従って動かせば自ずとリアルなアニメーションになるという話。

  • Unity等ゲームエンジン/ミドルウェアの活用について

これが私のあげた議題。例えばせっかくUnity使うプロジェクトなのにアニメーターはFBXをエクスポートするだけで、ゲーム内でのState Machine(Animator Controller)の実装はプログラマーやゲームデザイナーに任せてるケースがある。もちろんアニメーターが実装した方がクオリティは上がる。ちなみにこの話をした時State Machineってものを知らないって人が結構な数いたし、FBXエクスポートする所までしかやらない人は多かった。しかしある会社さんでは、アニメーターがUnityを触らなくても最終的な実装の形だけでも理解して、ゲームデザイナーやプログラマーとState Machineの組み方を相談する所まではやっていると言っていた。その場合はUnityやUnrealがアニメーターとそれ以外の職種との共通言語となっているのでそれだけでも導入する意味は大きいと私が答えたところ、その「共通言語」という言葉をモデレーターのアレクシスさんがいたく気に入ったようだった。外国人だからその大切さがわかるのかも。その他私の方から「多くのプロジェクトでプログラマー以外にUnity触らせないのは、Unityのライセンスの問題もある。」という話をした。それに同意する人もいた。

他にもアニメーション制作において役立つ話が色々聞けた。個人的には元職場の人たちが問題意識、目的意識を持ってワークフローの改善に取り組んでる事を知って嬉しくなった。行って良かった。

CEDECの運営について

さてこの日、2日目に私と一緒にパネルディスカッションする人達が講演者受付でパスを受け取れないという事態が発生した。パスそれ自体が用意されてなかったし、「代表者の私がまとめて受け取ったのでは?」とか言われたらしい。(そもそも誰に何を渡したかを記録してないのが有りえない。)「昨年と同じ会社さんですか?毎年のようにこんなことばかりで困ります」と伝えたら昨年トラブルあった時に対応してくれた担当の方が出てきてその後丁寧に対応してくれたので良かった。また、他の多くの参加者も言っていたことだが、常に大混雑で、どのセッションの待機列もすごいことになっていて、せっかく並んでも教室に入れないケースが目立った。そんな中会場整理のボランティア(2017年度の新卒内定者や専門学校の学生が中心)が、スピーカーが並んでる受講者に対して優先入場の条件について呼びかけていても一緒に声をかけることなくぼーっと突っ立っていたり、受講者として一緒に列に並んでいたり、人から聞いた話であるが立ち見のいるセッションで席に座って寝ていたりと色々と対応のまずさが目立った。ボランティアについてはボランティアなのでしょうがないと思う。これを業者に全て委託した結果わけわからない学生バイトが来たらもっと嫌だ。CEDECというイベントがどういうものか理解して、業界への貢献を少しでも考えている人がいるだけましと考える。どちらかというとオリエンテーションに不備があっただけと思える。このイベント自体、運営事務局の委託会社もボランティアも現状の体制では手に負えないような開催規模に育ってしまっただけの話に思える。来年度については4日間の開催も含めて運営委員会には改善策を検討していただけたらと思う。

ウェルカムレセプション(講演者懇親会)

初日の夜は毎年講演者だけ招待される懇親会がある。今年は主にFL1NEさんと話してた気がする。また、佐野信義さん(佐野電磁さん)にも7年ぶりくらいに再会できて良かった。まだ音楽を続けていることを報告できた。この懇親会は名刺交換するとこじゃなくて知ってる人と話をする雰囲気。そういうとこが好きなんだけど2日目のパネルディスカッションの準備をまだやり残していたのであまり長居せずに早々に帰った。

 

 

「The Next Generation パトレイバー 首都決戦 ディレクターズカット」の奇跡

STARチャンネルで録画してたTNGパトレイバー首都決戦ディレクターズカットを観た。最初の劇場公開版も観てないし、ドラマシリーズも観てない。TNG観るのはこれが初めて。「パトレイバー2 the move」がとても好きなので、TNGを観るのは楽しみでもあり怖くもあり、それだから劇場版もドラマ版も映画館に観に行こうと思えなかったしそのためにSTARチャンネル契約してまで観ようと思わなかった。(最近ゲームオブスローンズのためにSTARを契約した。)
結論としては、これは奇跡的な作品だと思う。
 
・押井守が実写映画撮るとロクなことにならない
・押井守がやりたいことやりすぎるとロクなことにならない
・伝説的な名画「パトレイバー2 the move」の続編
 
こんだけの失敗リスクがあるのにそれら全てが上手くはまった。「今更レイバーなんてどうでもいい」って監督自身のメッセージと警察内での特車二課の扱いが重なるところにこの映画の意味がある。「平成の226」から13年後。日本国内の建設ラッシュが終わって民間のレイバー需要もレイバー犯罪も激減。警察内ではパトレイバーは単なる金食い虫でレイバーのパイロットも整備士も税金泥棒って扱い。原作でも税金泥棒扱いだったけど2015年では輪をかけて冷遇されている。CGでなく実写で出てくる自衛隊のヘリや航空機の頼もしいこと。警察の手に追えないなら法整備して自衛隊に出動して貰えばいい。そういう世界。警察から特車二課がなくなり、レイバーがいなくなる未来を明示したうえで、虚構の平和を守る戦いは続くよというメッセージ。久々に押井守らしさが上手く嵌ったのを観た。そして押井守のやりたいことが「俺らの観たい押井守」とうまく嵌っていた。前述した実写の航空機はもちろんのこと、ロシアからのインターンの女性隊員のアクションシーンロシア語喋るクールな美女が銃剣つけたAKぶん回して大立ち回りって明らかに押井守の趣味以外の何物でもないんだけど、それがまたかっこいい。未来のヒロイン像を提示してたと思う。(本人としては20年以上前からそれを描き続けてるつもりかもしれないが。)また、「レイバーどうでも良い」という世界を描きながらもパトレイバー2へのセルフオマージュを盛り込み、ファンに対しては「君が今実写で見てるのはあの世界だよ」って意識させることを忘れない。特に「あの人の」登場のさせ方は誰もが納得する形だったろうと思う。しかしこんな良い映画ならお金払って観に行くべきだったなあ。ガルム・ウォーズ観に行こうかな。

Unity5.3のパーティクルで遊んでみる

この記事はUnityアドベントカレンダー12月25日分の記事です。

前日の記事はtnayukiさんの「宴のカスタムコマンド作成について」です。


Unity5.3になってParticle SysytemのEmitterの形状にSkinned Meshが利用できるようになったということでそれについての記事を書こうと思ったが、なんとバグがあって利用できない(5.3.1p1で未解決)ので、Unity5.3になってスクリプトからアクセスできるようになったParticle Systemのプロパティについて書くことにした。以下が5.3のParticle Systemの変数の一覧である。New!!と書かれているのが新しく追加された変数である。

collision New!! Access the particle system collision module.
colorBySpeed New!! Access the particle system color by lifetime module.
colorOverLifetime New!! Access the particle system color over lifetime module.
duration The duration of the particle system in seconds (Read Only).
emission Access the particle system emission module.
externalForces New!! Access the particle system external forces module.
forceOverLifetime New!! Access the particle system force over lifetime module.
gravityModifier Scale being applied to the gravity defined by Physics.gravity.
inheritVelocity New!! Access the particle system velocity inheritance module.
isPaused Is the particle system paused right now ?
isPlaying Is the particle system playing right now ?
isStopped Is the particle system stopped right now ?
limitVelocityOverLifetime New!! Access the particle system limit velocity over lifetime module.
loop Is the particle system looping?
maxParticles New!! The maximum number of particles to emit.
particleCount New!! The current number of particles (Read Only).
playbackSpeed The playback speed of the particle system. 1 is normal playback speed.
playOnAwake If set to true, the particle system will automatically start playing on startup.
randomSeed Random seed used for the particle system emission. If set to 0, it will be assigned a random value on awake.
rotationBySpeed New!! Access the particle system rotation by speed module.
rotationOverLifetime New!! Access the particle system rotation over lifetime module.
scalingMode New!! The scaling mode applied to particle sizes and positions.
shape New!! Access the particle system shape module.
simulationSpace New!! This selects the space in which to simulate particles. It can be either world or local space.
sizeBySpeed New!! Access the particle system size by speed module.
sizeOverLifetime New!! Access the particle system size over lifetime module.
startColor The initial color of particles when emitted.
startDelay Start delay in seconds.
startLifetime The total lifetime in seconds that particles will have when emitted. When using curves, this values acts as a scale on the curve. This value is set in the particle when it is create by the particle system.
startRotation The initial rotation of particles when emitted. When using curves, this values acts as a scale on the curve.
startRotation3D New!! The initial 3D rotation of particles when emitted. When using curves, this values acts as a scale on the curves.
startSize The initial size of particles when emitted. When using curves, this values acts as a scale on the curve.
startSpeed The initial speed of particles when emitted. When using curves, this values acts as a scale on the curve.
subEmitters New!! Access the particle system sub emitters module.
textureSheetAnimation New!! Access the particle system texture sheet animation module.
time Playback position in seconds.
velocityOverLifetime New!! Access the particle system velocity over lifetime module.

全てについて触れる時間はないので、効果が見て確認しやすいcolorOverLifeTimeを使って簡単なプログラムを組んでみようと思う。

まず最初に断っておきたいのだが、全てにおいてこのようなプロパティをスクリプトでコントロールすることを推奨しない。何故なら「コードを書かずにエディターだけでゲームが作れる」のが最も理想的なUnityの利用方法であって、原則としてコードを書かない手段を優先的に探したほうが良い。今回紹介するランタイムでパーティクルの色を変える方法は色の設定だけ違うprefabを複数用意すれば同じことはできる。しかし、いずれにせよコンポーネントを1つ作るならAssetsフォルダ以下のprefabの数も、一つのシーンにロードするprefabの数も少ない方が良い。そういうわけで1つのParticle SystemのcolorOverLifeTimeを次々と変える方法について紹介する。

interactiveParticleInspector

まずは、色を変更するためのコンポーネントを1つ用意する。ここではInteractiveParticleSystemと名付けた。今回はそこまで紹介できないが、ゲームプレイの展開に合わせてパーティクルの色やサイズを変化させることを想定したためにそのような名称にした。

Gradientの配列でParticleの色の設定を複数用意する。今回はColor Change Timeが経過するとランダムでそれらの設定のどれかに変更するというのを試して見る。

    public ParticleSystem particle;
    public Gradient[] colorOverLifeTime;
    public bool randomColor = false;
    public float colorChangeTime;
    float colTime;

    void Update () {
        if(particle != null && randomColor == true){
            RandomColor();
        }
    }

    public void RandomColor(){
        colTime+=Time.deltaTime;
        if(colTime >= colorChangeTime){
            colTime = 0;
            int i = Random.Range(0,colorOverLifeTime.Length);
            var col = particle.colorOverLifetime;
            col.color = new ParticleSystem.MinMaxGradient(colorOverLifeTime[i]);
        }
    }

実行結果は以下のようになる。左手首のパーティクルをこのInteractiveParticleSystemが管理している。

particleColorChange1

放出済みのパーティクルまで瞬間的に色が変わってしまっている。この表現が適している時もあるが、放出済みのパーティクルについては色を変えずに、新たに放出されるパーティクルだけ色を変えたい。

そこで、1つのParticleSystemのcolorOverLifetimeを変更するのではなく、新たに色を設定しなおしたParticleSystemを生成して、時間差で古いParticleSystemを消すことにした。複数のprefabを用意すれば同じことができると書いたのはこのことである。

   public void RandomColor(){
     colTime+=Time.deltaTime;
     if(colTime >= colorChangeTime){
        colTime = 0;
        int i = Random.Range(0,colorOverLifeTime.Length);
        StartCoroutine(ChangeColor(colorOverLifeTime[i]));
      }
    }

  IEnumerator ChangeColor(Gradient gradient){
     //既存のパーティクルをクローン
     GameObject newParticleObj = Object.Instantiate(particle.gameObject);
     newParticleObj.transform.parent = transform;
     newParticleObj.transform.localPosition = Vector3.zero;
     ParticleSystem newParticleSystem = newParticleObj.GetComponent<ParticleSystem>();
     ParticleSystem.ColorOverLifetimeModule col = newParticleSystem.colorOverLifetime;
     col.color = new ParticleSystem.MinMaxGradient(gradient);
        //既存のパーティクルを削除
     StartCoroutine(DestroyOldParticleSystem(particle));
     particle = newParticleSystem;
     yield return true;
  }

 IEnumerator DestroyOldParticleSystem(ParticleSystem oldParticleSystem){
     yield return new WaitForSeconds(1.0F);
     ParticleSystem.EmissionModule emit = oldParticleSystem.emission;
     //emissionを停止
     emit.enabled = false;
     float duration = oldParticleSystem.duration;
     //放出済みのパーティクルが消えるまで待つ
     yield return new WaitForSeconds(duration);
     Destroy(oldParticleSystem.gameObject);
     yield return true;
 }

すると以下のように自然に色がグラデーションしていく。

particleColorChange2

どちらかというと、先に挙げた放出済みのパーティクルも含めて色を変える方が以前はできなかったことであり、今回のアップデートの恩恵を受けているのだが、いずれにせよcolorOverLifetimeにアクセスできるようになったことにより、色については自由にどうとでも変化させられるようになった。

今回紹介したのは非常に初歩的な手法であるが、スクリプトからいずれの変数にもアクセスできるようになったことで、一段とパーティクルの表現力が増したと思う。

パーティクルを使った表現はモデリングやテクスチャと違って、絵が描けない人でも工夫次第でゲームのグラフィックスの品質をあげることできるし、アニメーションち違ってUnityの中だけで作業が完結する。そしてシェーダーほどプログラミングは難しくない。GDH2030のように予算も時間も限られたプロジェクトにおいては大変重宝するといえる。ちなみに画像のキャラクターはGDH2030に登場するオリジナルキャラクターである。今回はアドベントカレンダーということで初めてUnityに関する記事を書いたが、今後はこのキャラクターの紹介も兼ねてこのような記事を書いていくかもしれない。

「ファイナルファンタジー アギト」のサービス終了について思うこと

先月末のことだが、1つのスマフォ用ゲームがサービス終了した。BFBが順調にサービス継続されFF11でさえ未だに続いているが、自分が開発に大きく関わったゲームが市場から消えて一切プレイができなくなるという体験は初めてであった。(コーエー時代に関わった「三國志 Online」もサービス終了しているが、あれは開発ではなく運営として関わっていたしそこまで中心的なポジションではなかった。)

僕は2012年末のプロジェクト立ち上げからサービス開始直前の2014年3月までFFアギトの開発チームにいて、主に戦闘部分の仕様設計とプログラム実装を行っていた。サービス終了のこのタイミングで自分にとってこのプロジェクトは何だったのかを色々と振り返ったので、それをここに記す。ここではギョーカイ評論家の人達が喜びそうな話をするつもりはない。2年経たずにサービス終了したからには商業的な失敗と言わざるを得ないが、何が原因で失敗したとかの分析はここでは一切やらない。もちろん仕事としてゲームを作ってる以上、反省や分析は行っているが、それを公開してもギョーカイ分析芸人の皆様をただ喜ばせるだけだし、途中でチームを抜けた人間がそれをやってるのを見たって最後までこのゲームの運営・開発に携わった方達は良い気はしないだろう。自分にも他者にもメリットが全然ない。今自分にとって最も大切なことは、この失敗したFFアギトにも一定数のファンの方達がいたこと、サービス終了を惜しむファンの中に、自分に温かい声をかけてくれた人がいたことである。今回はその人たちのために何か書こうと思った。

また、一緒に仕事をしたスクエニの方達のことは尊敬しているが、具体的にどのようなやりとりがあったかもゲーム業界オタクの人たちを喜ばせるだけなので、割愛する。よって必然的にスクエニの方達の成果についてはあまり言及できない形となってしまうことをご了承いただきたい。スクエニの方達の努力があり、その成果があったことは十分に認識しているし、尊敬していることだけは伝えたい。

プロジェクト参加の経緯

2012年末にBFBがリリースされた。当時の主幹開発会社は株式会社たゆたうで、僕はゲームデザイナーとしてたゆたうと業務委託契約を結んでBFBの中心的な部分を作っていた。当時のたゆたうとの契約は必要な作業単位での契約であり、作業が段々と落ち着いてくる開発後期にはパートタイムの仕事になっていたし、BFBが完成したら次はどうなるかも分かっていなかった。BFBの開発が終わる頃、たゆたうから「スクエニとの新しいUnity案件が始まるから、BFBと並行してそちらにも参加してくれないか?」という話を頂いた。僕は以下の点を鑑みてプロジェクトへの参加を決めた。

  1. 目標だったオリジナルゲーム開発のための資金が足りない
  2. BFBはなんとか作れたが、Unityで1人でゲームを作り切るスキルも足りない
  3. 上記2点のために1年単位のまとまったUnityの仕事がしたかった
  4. スクエニ在籍時の待遇が酷かったのでいつか見返してやりたいと思っていた
  5. FFに思い入れがあり、もう一度くらいFFに関われたらと思っていた
  6. BFBに対しても、もっと貢献したいと思っていた
  7. たゆたうに常駐するならBFBの仕事ももっとやれると思った

当時は船橋の自宅で仕事をしていたが、たゆたうに常駐することになったために、たゆたうから徒歩5分の所に部屋を借りて、平日はそこから通うことにした。

チーム内におけるポジション

たゆたうの社員でもスクエニの社員でもない僕は、両社における分業制度の範疇外となり、両社でプランナーと呼ばれる人達がやってる仕様考案や設計の仕事とプログラマーの仕事である実装の両方を手掛けた。自分で思いついたアイディアをすぐにプログラミングして、ゲームとして動く形でスクエニに対してプレゼンする。このやり方のおかげで開発初期のプロトタイピングでは大きな成果が出た。BFBとこのプロジェクトで実績のあったこの仕事スタイルのメリットについては2014年のCEDECで紹介し、大きな反響をいただいた。

Game Watch 記事【CEDEC 2014】雑用ばかりの「プランナー」から脱するには?

FFアギトで目指したこと

FFアギトはPSPで出た「ファイナルファンタジー零式」のフランチャイズ展開という企画だった。僕はFF零式については、とてもスピード感ある戦闘が印象として残っていた。「クラスゼロ」と呼ばれる少年少女の戦闘エリートが戦場を素早く動き回り、武器や魔法を駆使して勢いよく敵を「殲滅」して行くのがFF零式の魅力だと思っていた。FFアギトの戦闘の内容について最初に提案する機会があった時、僕は迷わずターン制の戦闘ではなくAIがリアルタイムでFF零式と同じようなテンポの戦闘を繰り広げるデモを作った。その内容がスクエニからも好評いただけてFFアギトの戦闘の原型ができた。そこから先はスクエニの方達と一緒にUIの試行錯誤の連続だった。そのスピード感ある戦闘をスマフォゲームユーザーに気軽に楽しんで貰うためにUIや行為に対するフィードバックの表現を改善していくというのが、プロジェクトを通した目標になった。

自分には思いつかなかった「アビリティチェーン」

FFアギトでは、プレイヤーは武器による技や魔法などの「アビリティ」を用いて戦う。海外製のPC用MMORPGなどでよく見る画面下部に並ぶアイコンをタップすると「スキル」が発動するあれである。僕自身そのようなゲームが好きなこともあり、デファクトスタンダードであるそのUIを踏襲することにした。画面下部にボタンとして並ぶアイコンをタップすればアビリティが発動するのである。しかし、ここで問題があった。戦闘中に多くのアビリティを使えるようにしないとプレイヤーが取り得る戦略が広がらないが、そんなに多くのアイコンを画面上に並べることはできなかった。そこでスクエニの方達と何度もミーティングして、試作を繰り返して生まれたのが、1つのボタンの中に連続して発動する複数のアビリティをセットできる「アビリティチェーン」の仕組みだった。例えばMMORPGをプレイしていると、魔法使い系のクラスのプレイヤーが同じタイミングで複数の種類のバフ(強化)スキルを発動するのをよく目にすると思うが、使いたいタイミングが同じアビリティというのは必ずある。それらをひとまとめに発動できるようにして、画面上のボタンの数を減らすことと戦闘に持っていけるアビリティの数を増やすことを両立できた。また、攻撃系アビリティの連続発動はゲームプレイにFFらしい派手さを加えてくれた。実は最初このような提案を受けた時に僕はあまり乗り気ではなかった。どうしても戦闘のUIやアビリティの位置付けをPC用MMORPGのスタンダードに近づけたいという思いがあった。それは長続きするゲームのモデルでもあったし、確実に面白さがわかっているものに近づけて失敗を防いでからゲームバランスを作り込むことでゲームプレイのクオリティアップを図りたいという狙いがあった。結果的には、前述したように連続発動によってスピード感が向上し、ボタンが減ったことでPC用MMORPGなどに馴染みのない人もプレイしやすくなった。これに関してはスクエニとのコラボレーションの1つの成果だと思っている。自分の好きなゲームの姿に囚われないということを1つ学んだ。

ユーザーテストでの確信

開発期間の後期において、プロジェクトの部外者にテストプレイして頂く機会があった。その時、何の説明をしていないのにも関わらず前述のアビリティを駆使してゲームを進めていくテスターの姿を見て鳥肌がたった。プロジェクト上様々な課題は残っていたのだが、このゲームは通用する、受け入れられるという自信がついた。結果的には失敗したゲームであったが、このテストプレイの時からサービス終了の時まで、ゲームプレイそれ自体の評価は決して低くなかったということを伝えておきたい。

リリース直前のチーム離脱

そのように開発に深く関わっていて最後にこんな文章書くくらいには思い入れのあったゲームであったが、リリースの直前に開発会社たゆたうとの契約を終えて開発チームから離れることになった。理由はいくつかある。

  1. たゆたうの近所に部屋を借りていたのは期間限定と思っていたから
  2. 度重なるリリースの延期でその期間が延長されていた
  3. オリジナルゲームの開発を2014年から始めたかった
  4. 並行して参加していたBFBの開発・運営がたゆたうから他社に移管された
  5. スクエニ及びたゆたうがBFBの都合を一切考慮してくれなくなると考えた

当初の考えでは、ゲームがリリースされたら一区切りして、その後運営・開発に参加し続けるにしても100%ではなく30%くらいの関わり方にするつもりだった。しかし、そのリリースがいつになるか分からなくなってしまったため、リリースを迎える前に区切りを付けることにした。また、当時の状況では100%参加するか0%とかどちらか一つであり、時間を減らして関わり続けるという選択肢はなかった。リリース直前にチームを抜けるのは迷惑と思う人もいるだろうが、当時はゲームデザイン自体は既に終わっていて、その実装を僕以外の専業のプログラマーがリファクタリングするという段階だったので、仕様書さえあれば僕がいなくてもなんとかなった。その当時僕が心配していたことは僕がいなくなってゲームがダメになることではなかった。むしろこのゲームが大成功した時に僕がチームを抜けたことを後悔しないだろうかということだった。最後の最後まで、僕はこのゲームの成功を信じていた。

リリース後の評判

結局FFアギトは2014年の5月にリリースされたのだが、当時としてはハイスペック過ぎてプレイできる端末が限られたこと、それまで類を見ない膨大なサイズのデータを扱うために、通信時間やロード時間などでストレスを与えてしまったことなどが災いして、ゲームプレイ以前の問題として叩かれてしまった。また、僕の作った戦闘の部分にしても、PSPのFF零式のアクションのクオリティが高かったため、同じように自分でキャラクターを操作して戦うのを期待していた人たちからの評価は芳しくなかった。FF零式のファンはこのゲームのリリースと同時に絶対飛びついたはずなので、最初の評価としては当然覚悟していた。そしてその不満というのが僕にも直接ぶつけられることとなった。

僕にしかできなかったこと

スクエニの社員でもたゆたうの社員でもない、そして既にチームを抜けている僕は、Twitterで唯一FFアギトの開発スタッフだったことを公言してゲームについて自由に発言していた。そのため、ゲームに不満がある人たちからも目につく存在となった。忘れられないのは、FFアギトの戦闘がFF零式の戦闘と違うことに不満があったある一人のユーザーである。その人は最初とても厳しい口調で僕に意見を寄せてきた。それに対して僕はじっくりとFFアギトの戦闘の実装意図について説明をした。すると段々と分かってきてくれて、最後には「応援してます」とまで言ってくださった。また、他にもFFアギトに不満があるというのをきっかけとしてよく話をするようになって、今でもゲーム以外の話題で交流が続いてる人がいる。自分のゲームをプレイしてくださった人とはできるだけ交流したいと常に思っている。こういうことがあったから評判は別としてFFアギトを作ってよかったと思っている。これから作るゲームでその人たちを楽しませたいと思う。

このプロジェクトから得たもの

FFアギトはリリース時の躓きから大きくユーザー数や売り上げを増やすことができずにサービス終了を迎えた。リリース後の運営・開発についてどのような意思決定があったかは僕には知る由もないし、知っていたとしてもそれを批評したくはない。確かなことは僕はこのゲームを作ることを楽しんだし、このゲームを作る過程でスキルアップできたし、ユーザーの方を含めていろんな方と知り合えたし、得るものが多かった。もちろん、このゲームをプレイして残念に思った人たちのことは忘れてはならない。商業的な失敗について自分の責任が全然ないとはいえない。しかしその失敗についても「ここまで予算が大きく有名なIPで失敗した」という経験はなかなかできるものではない。改めて、スクエニにもたゆたうにもユーザーの皆様にもお礼を申し上げたい。そしてこの恩返しというのはこれからもゲームを作り続けることで果たして行きたいと思う。FFアギトの開発を抜けてまで作り始めたGDH2030というゲームを来年は必ずリリースさせる。

今後の課題

プロジェクトの失敗は抜きにして自分のゲームの作り方や仕事の進め方は間違っていたか?と聞かれれば、それは良いところも悪いところもあったとしか言いようがない。Unityでのプロトタイピングは確実に成果があったものの、プロトタイプから内容を膨らませていく段階において、効率の低下があったのは事実である。現在開発中のGDH2030においては適切なタイミングでリファクタリングを行うなど効率化を図って既に成果が出ている。その辺の話については今年のUniteで話をすることができた。

ゲーム開発の. 始め方、育て方、終わらせ方. 「Game Dev Heroes」. における生産性チャレンジ

スライドはこちら

Unityによる開発の効率化はまだまだ改善の余地がある。せっかくUnityを使っているのにFFアギト以上に非効率な開発になってしまうこともある。これからの自分の仕事を通してUnityやその他ゲームエンジンの上手い使い方を伝えていけたら良いと思う。全てはもっと面白いゲームを作るために。