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

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

GDH2030のUIデザイナー募集!!

現在開発中のゲーム「GDH2030」のUIデザイナーを募集します。

「GDH2030」とは

今年リリース予定の「2030年のゲーム開発」を題材にしたシミュレーションゲーム。、キャラクター以外はゲームデザイナーの下田賢佑と大学生のプログラマーの2人で作っている。ゲームエンジンにUnityを使用。プラットフォームはPC/Mac。

ss0426

公式facebookページ

「GDH2030」のUIの開発状況

UnityのNGUIを用いて機能としてのUIの実装はできている。しかし、デザインやレイアウトに改良の余地がある。ゲームの画面の見やすさを向上させ、「2030年」という時代設定を感じさせるものにしたい。

募集要項

契約形態:業務委託契約

勤務地:オフィスがないためリモート作業(skype必須)

作業内容:ゲームデザイナーの下田と相談しながらレイアウトを考え、ボタンやウインドウをデザインする

報酬額:時給2000円(税抜き) * 実際の作業時間(50時間前後を想定)

期間:5月〜6月

必要なスキル及び経験

  • ゲームやその他アプリケーションのUIデザインの経験(商用でなくてもOK)
  • チームでの共同作業の経験
  • PhotoshopまたはIllustratorを使いこなせる
  • コミュニケーション能力

Unityの使用について

  • Unityを持っていない人でも素材の納品だけで仕事が成り立つようにします
  • Unity Pro版を持っていてUnityでの実装作業もできる人は上記の作業に加えてそちらも依頼します(その場合時給は増やします)

この仕事が向いてない人

  • 数ヶ月以上フルタイムの仕事をして生活費を稼ぎたい人
  • 最初に仕様書をもらったらあとは自分1人の作業に集中させて欲しい人

この仕事が向いてる人

  • 学業や本業の他に毎日2時間くらいの仕事をしてみたい人
  • コミュニケーションを重ねて改良を繰り返してクオリティアップするのが好きな人

補足事項

報酬額については細く修正を繰り返したいので、最初に見積もりを取っていただくよりも、時給を提示して最終的に実際の作業時間で請求していただく形をとらせてください。また、経験あるフリーランスの方にとっては時給額が少なく感じるかもしれませんが、その代わりに納期を緩く設定しているので、そこで納得いただける方に依頼したいです。学生の方でもOKです。コミュニケーション能力必須と書きましたが、ここでいうコミュニケーション能力とは大学生が言うような人付き合いの「コミュ力」ではなくて、単純に「聞かれたことにすぐ答えること」「疑問点を放置せずにすぐ質問すること」「問題が発生したらすぐに情報共有すること」です。どんな話し合いもすぐに開始することを重視してます。それさえできればOKです。コミュニケーションにはskypeのチャットを用います。必要に応じて通話します。その他質問がありましたらtwitterアカウントか、メールフォームでお問い合わせください。

twitter:kensukeShimoda

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

C言語のポインタとギターのFコード

「プログラミングをやろうと思ったけどC言語のポインタで躓いた」なんてのはよく聞く話だが、似たような話として「ギター始めたけどFコードが抑えられなくて挫折した」というのがある。ギターやったことない人のために説明すると、ギターというのは6本の弦でコード(和音)を作るのが基本的な奏法で初心者が買うギターの教則本では大抵いくつかのコードを覚えて有名な歌の伴奏をしてみる事を教えている。そしてFコードというのは、人差し指を寝かせて6本の弦を全て押さえることが必要なのだが、初心者の場合握力が弱かったり指を棒のように伸ばす事に神経が慣れていなかったりで、まずちゃんと抑えられない。やってもやっても抑えられない。そしてFコードが押さえられないと次の段階に進んではいけないと思い込み、ギターの練習そのものに飽きてしまう。

しかし、「ギター弾きたい」と思う人が本当に弾きたいロックやポップスの曲では、まずその人差し指で6弦全て抑えるFコードを弾く場面なんてものは出てこない。もちろんF(ファ)を基音とする和音はいくらでも出てくるのだが、大抵省略形になっていたりして、少なくとも教則本に載っているような形で6弦全てを1フレット目で押さえる場面は少ない。僕は中学1年生の時にギターを始めて、同じように初心者向けの教則本から始めたのだが、6弦全て使う形のコードを押さえて好きでもないJ-POPsの課題曲をやることにすぐに飽きて来た。ある日大好きなバンドKISSのアルバム「LOVE GUN」の楽譜を楽器屋で見つけたので買って見たらそこに載ってるのは教則本に載ってるコードより押さえるのがずっと簡単な省略形の「パワーコード」ばかりであった。すぐに好きな曲に挑戦してみたら自分でも弾けることに興奮した。その体験のおかげで20年以上ギターを続けている。

プログラミングの話に移ると、僕がUnityとC#を使って一人でもゲームを作れるようになる過程において、Unityの教則本もC#の教則本も見なかった。ただ、「FPSが作りたい」という思いがあったためUnityに付属のTPSのデモの中身を見たりして、真似してみる所から始まった。ギターのFコードで挫折する人とC言語のポインタで挫折する人に共通するのは「弾きたい曲」や「作りたい物」がないことだと思う。このバンドのこの曲を弾いてみたいというのがなしに「ギター弾ける俺」を目指したって、ゲーム作りたいわけでもなく「今の時代文系でもプログラミングくらいできなきゃ」とか思ったって、そこには自分の人生を豊かにするような体験は待っていないだろう。

何故こんな話をしたかというと、直接のきっかけは「プログラミング初心者が躓く点」のような話を目にしたことだが、この手の話は前から社会の闇として気になっているのである。特にやりたいことや好きなこともなしにただ人から評価されることやかっこいい自分を目指して挫折する、いや正確には挫折感もなしにただ無かったことにする人は多い。まあそれだけなら害はない。10代の時に楽器を触って3日坊主なんてことは誰にでもある話だ。しかし、20代、30代でプログラミングの本を買っては積んだり、開発環境をインストールするだけで終わったりすることを繰り返して自己承認欲求をどんどんこじらせていく人たちがいる。何をした方が良い、何をするべき、そういう話ばかり聞かされて来た人たちが特に興味もないことをかじって時間や金を無駄にする。そしてしまいには「趣味がない」とか「友達がいない」とか「仕事に未来がない」とか言い出す。音楽が好きだから楽しみたいとかなくて「twitterで音楽の話をできる人はかっこよくて羨ましい」とか言い出す。「なんでも良いからプロフェッショナル仕事の流儀や情熱大陸に出られる人になりたい。」とか言う人はマジに存在する。イケてる自分になるためのスキルアップとライフハック、それを煽る空気がある。なんか呆れてくるしムカついてくる。わかるかなこれ。