ゲーム開発の友人、一條さんの一連のtweet。

おれの事業目的は「社会人になって創作をやめる」をいかに無くすかってことにありまして。特にゲームにおいては個人の創作活動を継続していける支援の仕組みが全然足りない。職業、補助金、業界全体のバックアップ、ないものづくしから組み立てていかないとならん。

— Ichijo (@Takaaki_Ichijo) 2017年7月10日

最も力を入れたいのは、個人創作と関連業務のバランスをクリエイターが決められること。全部趣味か全部仕事じゃなくて。たとえばイラストレーターさんなら、本の挿絵を受注しつつ、オンラインや個展などで自分の作品を売ることもあるだろう。そんな感じの選択肢を作る。 — Ichijo (@Takaaki_Ichijo) 2017年7月10日

「好きなものならどんなに忙しくても続けられるじゃん！」ってな、嘘よ。いくら好きでも泥のように疲れてたら何もできんよ。素敵なものを作る人がタフだとは限らんのよ。精神的パワがある人やチームだけが、社会人と同人を両立させて生き残ってる感じがある。

— Ichijo (@Takaaki_Ichijo) 2017年7月10日

腹立つのは個人ゲーム開発やろうぜって言ってると外野から「じゃあ起業して人生オールインしてね！！」とかのたまう人がよく見られること。それは単に１つの手段で、他にもやりようはある。いきなり全リスクしょえるほど覚悟のできる人間なんて一握りでしょ、起業起業うるせえんだよ — Ichijo (@Takaaki_Ichijo) 2017年7月10日

僕自身は2014年からはクライアントの理解を頂いて時間を作り、それまで稼いだ金を外注につぎ込んでオリジナルのゲームを作っているのだが、正直言って全く理想通りに行っていない。そのゲームの開発が自分の人生を豊かにしてるとはちっとも思えなくなった。方法を変える必要がある。

ゲームはとにかく作業量が多くて時間がかかる

ゲームが小説や漫画やイラストなどの他の創作物と比較して大変だと言うつもりはない。ただし、1つの作品を「商業レベルで」完成させるまでの作業量が他と比較にならないのは事実である。アート、プログラミング、サウンド、それら1つ1つの作業量の膨大さ、それに加えてゲームは楽しめるものでなくてはならない。ゲームプレイの検証を繰り返し、場合によってはせっかく作ったものを捨ててまた1からやり直すことも必要である。時間と予算の制約の中で作業に追われるとどうしてもその検証がおざなりになりがちだ。もしフルタイムの仕事に就いて週末だけに作業をするとなると1つのゲームを完成させるのに5年はかかってしまうだろう。実際に海外のインディーゲームの人気作品の中にはそのようなものが目立つ。そのような時間と苦労を経てゲームを完成させた結果、多くのゲーマーから評価され、商業的にも成功するのは一見素晴らしいストーリーだが、一生の間にいくつのゲームを作ることができるか考えると、5年という数字はリスクとして無視できない。

作品の発表は人生を豊かにする経験

それが仕事だろうと趣味だろうと、ゲームや漫画や小説や音楽を作ることは人生を楽しむ手段である。作品を完成させて発表して知り合い以外の多くの人たちから内容についての感想や評価を得ること。それは1つの社会参加の形であり、専門的な技術者としても1人の人間としても、その経験から得られるものは大きい。pixivやtwitterがプロ/アマ問わずイラストレーターや漫画家の成長の場になっているのは言うまでもない。一方で1つの作品を完成させるのに時間がかかるゲームの場合、作品の発表の頻度はどうしても減ってしまう。5年かけてようやくリリースした作品がクソゲーと言われたり小遣い程度の収入にもならなかった時、同じようにまた5年かけて挑戦しようと思えるだろうか。

じゃあ小さいゲーム作れば良いのか？

本当に作りたいものがそれなら良い。時間の制約、予算の制約の中で本当に自分の好きなものを作れるのは相当なセンスや才能のある人だろう。実際にそういう人はいる。しかし大抵の場合、ゲームという表現形態を選ぶからには一定以上の作業量を必要とするものになるだろう。少なくとも僕にとってはゲームは大きいものだった。作り始めた頃は半年くらいで完成させるつもりだったが、細部の作り込みがあって初めて表現の核心が浮かび上がるようなゲームを作っていることに後から気づいてしまった。

収入を減らして時間を作れば良いのか？

結論から言うとそれでもまだ時間が足りなかった。2014年から開発を続けてるゲームがいつになっても完成の目処が立たないため、昨年からクライアントにお願いして仕事の時間を大きく減らし、自分のゲームを作る時間を増やした。また、契約の終了後もしばらく次の仕事を入れずに、自分のゲームに集中した。しかし、完成する前に資金が尽きてしまった。また、そのように収入を減らした状態をずっと続けるわけにも行かず完成を急いだせいで、ゲームプレイの検証がおろそかになった。2014年からそれまで稼いだ金を外注につぎ込み、自分の作業時間を作るためにギリギリの収入で生活を続けたことで、今となってはそのゲームの開発に対しては苛立ちしか感じなくなってしまった。本当にこんなことがしたかったのだろうかと自問自答する。

仕事として金をもらってゲームを作れるのは幸せな事

自分のゲームは引き続き作っているのだが、最近、新しいクライアントと新しいゲームを作り始めている。自分のゲームとは全然ジャンルもターゲットも違うし、クライアントのディレクションに従って作るわけなのだが、これが意外と楽しい。久々にゲームデザイナーとしてのアイデンティティを認められてる気がする。ディレクターが僕が仕事しやすいように配慮してくれてるのもあるが、多分楽しいと感じる一番大きな理由は、最初から完成の見えたプロジェクトだということ。事業としてのスケールとスケジュールが決まっていて、まともな開発会社をアサインするならスケジュールから大きくずれることはない。事業という形が与える安心感や精神的充足の価値を再認識した。結局のところ自分のゲームの開発は、プロジェクトの進行の全てが自分に依存しているのにその自分は完成するまでお金を生み出さないそのプロジェクトに全てを捧げることができないという中途半端さに問題があった。今後は、事業として資金調達や共同開発などの形でプロジェクト進行の責任を他社(他者)と分担した上で、ゲームデザイナーとして自分の作りたいゲームを作れるように努力しなければならないと考えている。その布石として、実は9月にデンマークで行われるアクセラレーターに参加予定である。

考える時間はあった方が良い

結論としては「ゲームは作業量が多く時間がかかるから資金調達などして100%コミットできるようにしよう」って話なのだが、最初に紹介した一條さんの意見に反対しているわけではない。僕がこのような結論に達したのも、一條さんが提案してるようなことを3年近く続けた上での話であり、他社との契約の仕事と自分のゲームの仕事を並行することで視野が広がったとも感じる。毎月200時間仕事するような会社員生活を辞めた次の瞬間に起業して資金調達ってのは難しいだろう。準備する時間が必要だ。仕事を選んだり、適切な距離感を保って少しずつ自分のやりたいことに傾倒していけば良いと思う。人によって作りたいものも全然違うし、自ずとそれに適したスタイルも違ってくる。一條さんが言ってるのもそう言ったスタイルの多様性を許す環境であって欲しいという話である。

以前書いたこちらの記事も参考にして欲しい。

好きな創作活動を仕事にするか他の仕事と両立するか

また、一條さん交えたパネルディスカッションのまとめも。

作りたいものを作ることとそれを持続させること。日本のインディーの未来

日本のインディーゲームの状況に関しては決して楽観的ではない意見が多かったように思える。それでも登壇者たちがいわゆる「インディーゲーム」にこだわらず、作りたいゲームのために多様な開発スタイルを模索していく姿は逆説的に極めインディーゲームらしいと感じた。

そうだね。

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

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

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

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。

ゲーミングとＶＲにおけるマシーン・ラーニングの未来 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日目のパネルディスカッションの準備をまだやり残していたのであまり長居せずに早々に帰った。

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

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

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

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

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

まずは、色を変更するためのコンポーネントを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が管理している。

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

そこで、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;
 }

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

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

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

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