この記事は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に関する記事を書いたが、今後はこのキャラクターの紹介も兼ねてこのような記事を書いていくかもしれない。

「FINAL FANTASY AGITO」のサービスは、 2015年11月30日(月)23:59をもちまして終了させていただきました。 今まで多くのご支援をいただきましたこと、心より御礼申し上げます。 (1/2)（運営）#FFAGITO

— FFアギト 運営公式 (@FFAgitoOfficial) 2015, 12月 1

先月末のことだが、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やその他ゲームエンジンの上手い使い方を伝えていけたら良いと思う。全てはもっと面白いゲームを作るために。

僕の誕生日は7月2日で、スクウェア・エニックスで働き始めたのが2005年の7月1日。今1人でやってる株式会社degGの創立日が2010年6月30日。それぞれのタイミングがほぼ重なっていて、1歳年齡を重ねるとキャリアが1年積み重なって会社も1年続いた事になるから、誕生日に自分のそれまでのキャリアや1年間の実績を振り返るのが習慣となっている。ちょうど今年で年齡が35歳となりゲームの仕事をして10年という大きな区切りになるので、10年続けて分かってきた事をシェアしようと思う。

プランナーはやばい

僕はゲームデザイナーになりたくてスクウェア・エニックスでゲームデザイナーにあたるプランナーという肩書きでキャリアをスタートさせたが、プランナーというのは色々とやばい。具体的にどうやばいかを話すとCEDECのセッション1回分になってしまうので、ここでは割愛。

【CEDEC 2014】雑用ばかりの「プランナー」から脱するには？ 「ゲームの面白さ作り」に特化する専門職業としての「ゲームデザイナー」の話

CEDECに出るのは当たり前の事

CEDECと言えば今年もCEDECでセッションを持つ。

絶対に夢を叶える！〜オリジナルゲーム開発への挑戦〜

発表者としてCEDECに参加するのはこれで5回目となる。よくこの事について「凄いですね」と言われるのだが、ゲームデザイナーは作ったゲームが全てなのでそれ以外の事で凄いですねとか言われても反応に困る。よく勘違いされているのだが、ゲームデザイナーとして認められているからCEDECでセッションを持てる訳ではない。CEDECの公募の審査は応募者の名前を伏せてそのセッションの内容だけで判断される。また、ここまで大規模でセッション枠が多いカンファレンスだと競争倍率が低いのでとりあえず誰でも公募に出せば通る可能性は高い。僕は「スピーカーになればパスが無料で手に入る」って理由でセッション案を公募に出している。CEDECのセッションは「講演」とは違う。日本社会における講演という言葉の意味は「成功者がためになる話をする」であり、CEDECもそういうものだと勘違いしている人が多い。CEDECに権威のイメージを感じとりセッション内容やスピーカーに対して過度に反発する人も見受けられる。しかしCEDECはカンファレンスであって、カンファレンスというのは情報共有の場である。それ以上でもそれ以下でもないので大げさに捉えず気軽にセッション案を公募に出した方が良い。CEDEC行っただけで何か成長した気分になるのも、セッション内容の揚げ足とるのも同様に時間の無駄である。

プラットフォームが変わっても仕事は変わらない

僕は最近仕事としてスマートフォン用のゲームを作りながら自分のお金と時間を使ってPC/MAC用のゲームを作っている。どちらもUnityで作っているし、まず面白いゲームを作る事を最優先している。仕事の質としては何も変わらない。ネットを見るとコンソール用ハイエンドゲームを作ってる人とスマフォ用ゲームを作ってる人で二分対比して前者を応援するつもりで後者を叩く人をよく見かける。けど人材の流動性から言って両者の区別ってさほどない。それにスマフォ用ゲームも既に「ハイエンド」の域に達してるし、「スマフォ用ゲームばっか作ってるとコンソールのゲーム作れなくなる」ってのも実感としてない。ゲームはゲームだ。

議論はあまり必要ない

議論してる暇あったらとにかくゲームを出して一般の消費者に評価を問う方が明らかに得る物が大きい。失敗のリスクを減らすために議論しようという意見もあると思うが、ゲーム会社でも個人でも最大のリスクは成果を出せないまま時間を過ごす事だと思う。

読書量とかどんだけ映画観たとかあまり関係ない

この業界では物凄い読書家や映画マニアと出会う事がある。ではそういう人が凄いストーリー書いてるかと言ったら必ずしもそうじゃないし、逆に読書も特にしないし、映画も人並みにしか観ないけど良い仕事する人はたくさんいる。なので僕は読書にしろ映画にしろ「数ある趣味の一つ」という評価しかしない。もちろん夢中になれる趣味を1つ持っている事それ自体は素晴らしいと思うけど。

コミュニケーション能力は必須

勘違いしてる人多いけどコミュニケーション能力って大学生とかが言う「コミュ力(ステレオタイプなリア充として立ち回るうまさ）」の事ではない。仕事で必要なのは自分の仕事の進捗や直面している問題や作業指示に対する疑問点、あるいは自分で思いついたもっと良いアイディアを自分の言葉で速く正確に伝える能力の事であって別に飲み会の幹事なんかやってくれなくて良い。そしてゲーム開発の仕事ではそれは全職種に要求される。繰り返す。全職種に要求する僕は。前述したステレオタイプなリア充（ネットスラングでは「ウェーイ」とか呼ぶのかな？）への嫌悪感からか「職人や技術者は寡黙であるべき」とか「言葉で仕事をしてはならない」とか思い込んでる人が多いけど、ディレクターの視点では勝手に一人で仕事抱え込んで自分からは何も話そうとしないプログラマーやCGアーティストの存在はプロジェクト進行上のリスクとみなす。メールで進捗確認すると自分で納得行く成果物が出来上がるまで返信してくれない人とかいるけど、そういう時って本人が思ってる以上に発注側はストレスを感じている。中途半端な物見せてはならないとかそういう精神論はいらない。「コミュニケーションが苦手な人でもプログラミングや絵のスキルが高ければ認めて欲しい。そもそも両立する能力じゃない。」って意見もあると思うが、僕が知ってる限り本当に凄いプログラマーやアーティストはコミュニケーションもしやすいんだよなこれが。

プログラミングと英語は誰でもやった方が良い

プログラマーじゃなくてもUnityのC#を使って簡単なデモを動かせるくらいになると自分のアイディアを仕事と実現しやすくなる。アーティストの場合はMELで仕事を効率化する事ができるし、Unityでエフェクトを作る場合は、プログラムも書けると表現の幅が広がる。また、英語が書けなくても読めた方がマニュアルの日本語化を待つ事なく最新のツールに触れる事ができる。もちろん海外のゲームをいち早くプレイできる。Gamastraに載ってるようなゲームデザイン関連の小論文も読むことが出来る。英語が読めると確かに知識がつく。もちろん読むだけでなく書くこともできればリモートで海外と仕事をする事もできる。

収入は上げられる

ゲームの仕事は低収入と思われてる。実際僕もスクエニ時代は死ぬほど給料少なかったが、結局の所この10年で年収は3.5倍以上になった。経営者からすれば「この人を1ヶ月働かせれば確実にこれだけの成果がある」というのが分かっていてなおかつ「この人に辞められたら困る」と思えればお金を出すことができる。僕は今オリジナルゲーム「Game Dev Heroes」の開発において人にお金を払って仕事をしてもらう立場でもあるが、パートタイムで開発に参加してもらっているある優秀な学生プログラマーには時給換算で明らかにゲーム会社の平均値を上回る報酬を支払っている。それは仕事したもらった分の成果が明らかなのと、ゲームが完成するまでいて欲しいからである。

ゲーム産業におけるブラック企業/ホワイト企業の判断基準

ゲームは複雑高度な知識集約産業であり開発スタッフそれぞれのキャリアパスはその知識やスキルに大きく依存する。そのため、開発スタッフが専門家として成長できる環境こそがホワイト環境と言える。そして開発スタッフの成長は実務や成果物の評価を伴う研修においてしかなし得ないし、一緒に仕事をするスタッフのレベルにも左右される。そこを勘違いして熟練スタッフの中途採用に力を入れずにただ本棚に最新の書籍を揃えるだけで「学習できる環境です」と言ってる会社さんは気をつけた方が良い。「自主性に任せる」という言葉もそうだが、それぞれが作った成果物の内容についての評価をおざなりにしてホワイト企業を気取るのは、知識集約産業においては形を変えたブラック企業と言える。これからゲーム産業で働きたい人はステレオタイプなブラック/ホワイトのイメージにとらわれる事なく吟味した方が良い。

行動が全て

色んな人と会って来た。時には「創りたい物がある！」と熱く語り合って意気投合したつもりになった事もあった。しかし、多くの人はその後何もしない。僕もかつてはそうだったが、とにかく語ってる暇あったら成果を出した方が良い。ゲームってのはプログラミングかCGのどちらかができれば成果が出しやすい。どっちもできなかったらとにかく学習すれば良い。本もネット上の資料もたくさんある。勉強会とかその後の懇親会とか行って何かした気になる前に、家で集中して勉強したほうが良い。

10年間でインパクトがあった事その1

GREE/Mobageブームとその後に続くスマフォゲーム市場の好景気。既存のゲーム業界の外から一気にお金が流れて来てゲーム業界としても顧客層を一気に拡大したのは大きい。最初のうちはDeNAとグリーのお金の儲け方に反発する空気があったけど、今となってはDeNAとグリーが作った市場を既存のゲーム会社が食ってしまう形となった。このおかげで既存のゲーム業界の平均収入も上がったはずだと思う。僕自身もこれによってオリジナルのゲームを開発する資金を得る事ができた。

10年間でインパクトがあった事その2

Unity3Dの登場とそれに伴うゲーム開発の民主化。僕はバージョン2の頃から触れているが、豊富なAPIとWYSIWYPなエディターによりゲームデザイナーが自分のアイディアをすぐにゲームにできるようになった。また、同じツールとプログラミング言語を使う人たちの開かれたコミュニティが出来上がった事により、学習効率が明らかに上がった。もちろん市場のニーズに応えるようなゲームを作ろうと思ったら何もかも1人で作るというのは無理な話だが、最初に自分でゲームメカニクスを実装する所に限って言えばもうこれで作れないゲームはないと感じる。

10年間でインパクトがあった事その3

twitterで自分が作ったゲームのユーザーと交流できるようになった事。僕の場合は会社員じゃないので自由に発言できるからというのもあるが、自分が作ったゲームのユーザーがそのゲームを辞めた後も声をかけてくれるのは嬉しい。それは、ゲームの向こう側に作り手の人格を認めてくれた事の証拠であり、これがあるからゲームの仕事を続けて行ける。

これから楽しみなこと

Game Dev Heroesが完成したら次はVRのゲームを作りたいと思っている。次の10年間でゲームのプラットフォームや人々のゲームへの接し方がどう変わるかは分からないが、絶対に変わる事だけは確かだと思う。どうなろうがゲームはゲームだと仕事を続けて行きたい。