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

エディトリアルデザイナーのアプリ制作日記

Unityで遊ぶ個人開発者のメモ書き

Unityアクションゲーム制作記 その16 ボスらしい動きをするロジックを組み込む

 

youtu.be

  ようやく懸案となっていたボスの挙動の目処が、ある程度立ちました。本当は昨年内に終わらすつもりだったもの……ここまで引っ張ってしまった原因として、ゲームとして盛り込んだアクションのシステムにありました(要は根幹に関わる部分)。

 まず、今回制作しているアクションゲームは、1対多の戦闘がメインになっています。敵の数が多いということは、それだけプレイヤーが囲まれることも多くなり、下手をするとすぐ多数の敵にボコボコにされてしまう危険があります。そうなるとプレイヤーは、敵からボコられないために集団から離れて攻撃をする、ヒットアウェイ戦法を選択し、チクチクと戦うことに……これではゲームとして爽快感に欠けてしまいます。

 せっかく多くの敵と戦っているのだから、バッタバッタと敵をなぎ倒すような、より気持ちいい戦闘にするにはどうしたらいいんだろう? そこでひねり出したのが、攻撃を受けた相手の動きを封じるようなリアクションをさせるというものでした。

 今回用意したのは、以下の4つ(プレイヤー・敵ともに設定可能)。

  • ノーマル:ダメージのみを与える
  • ブロウ:相手を一瞬ひるませる(相手の攻撃をキャンセルする)
  • ノックバック:相手を一定距離吹き飛ばす(相手の攻撃をキャンセルする)
  • ブラックアウト(気絶):一定時間、行動不能状態にする

 基本的にプレイヤーが連続攻撃を使った際には、初弾(ノーマル)>二段目(ブロウ)>三段目(ブロウ)>フィニッシュ技(ノックバックなど)と設定してあります。初弾をノーマルにしたのは、さすがに出合頭で敵の攻撃をつぶせてしまうと、本当に一方的な無双状態になってしまうので、ここは敵にも反撃できる余地を残してあります。結果として、プレイヤーが積極的に攻めることで敵の動きを封殺でき、いい感じの無双アクションを楽しめるようになったかな? という具合です。攻撃の間合いが違ったり、遠距離攻撃をしてくる敵などバリエーションを用意して、いっぺんに登場させれば、それなりに緊張感のある戦闘バランスになっていたりしました。

 ただし、ボス戦のときに問題が起きました。雑魚の場合は、数の暴力でプレイヤーへの反撃の余地はあったのですが、ボス単体とのサシ勝負では、ブロウによって攻撃がつぶせることが仇になってしまったのです。極端な話、あまりに簡単に敵の攻撃がつぶせてしまうので、ボスを一方的に殴るだけで戦闘が終わってしまうということも……結果、ボス戦がすげーつまらないものになってしまったのです。ボスの行動自体、雑魚と同じくプレイヤーとの状況(攻撃されたとか、見つけたとか)などに応じて、幾つかの行動を選択し、ループさせているだけなのも原因の一つだったといえます。

 じゃあ、ボスでは「ブロウ」を無効化すりゃーいいじゃん? 対プレイヤー用にロジックを組み直せばいいじゃん? と思わなくもないのですが、単に「ブロウは無効」としてしまうだけでは、あまりにゲーム的な都合が見え見えになってしまいますし、ボスごとにロジックを組むのは、ボスを量産する際にかなりきつそう……。

 そんな感じで、攻撃し続けていると、いい感じに敵が判断して回避して反撃したりできないかと、ここ数ヶ月ず〜〜〜〜っと頭を悩ませていたのです。まぁ、プレイヤーに対するリアクションを逐一判定し、対応する反撃方法を組み込んでやるのが王道なんでしょう、きっと。ただ、ロジックそのものを組み込んでしまうと、どういう反撃をしてくるのかすぐプレイヤーにバレるだろうし、後々、敵の強さを調整したいときにすげーめんどくさそうだったので、ない知恵絞ってうだうだと考え込むことに。どーしよっかなーと、どうすればいいかなーと悩み続けたのですが、結局やりたいことは、

  • 状況が悪化したら、有利な状況に変化するように自律的に行動してほしい

これに尽きます。これができれば、ボスとの戦闘も駆け引きのあるものになるはず! そして、状況が悪化するということは、敵にとって不利な状況に追い込まれることにほかなりません。今回のゲームで敵にとって不利な状況とは、

  • 壁際に追い詰められる
  • プレイヤーからダメージを受け続ける

単純化すれば、この2つに集約されるかなーと。そしてこの2つそれぞれにストレス値を用意して、敵にとって不利な状況を明確に数値化することにしました。

  • 壁際に追い詰められる = 地形ストレス上昇
  • プレイヤーからダメージを受け続ける = 攻撃ストレス上昇

 ボスが壁に近づけば近づくほど=プレイヤーに追い詰められる=地形ストレスは上がる。プレイヤーから攻撃を受ければ受けるほど攻撃ストレスは上がっていく。それぞれがある一定のしきい値を超えた時に、ボスへ回避や反撃する行動を起こさせるという具合です。

 しかし、これだけでは地形・攻撃ストレスで2パターンしかバリエーションを作れません。そこでさらにストレスレベルを用意して、そのストレスレベルに応じて回避や反撃行動を設定できることにしました。ストレスレベルはひとまず5段階。ストレスレベルが上がる条件は、ストレス値がしきい値を超えた時で、ストレスレベル下がる条件は時間経過のみとしました。かなり単純な仕組みですが、しきい値(レベルに関係なく固定)とストレスレベルを下げる時間(レベルごとに設定)をうまく調整することで、敵の攻撃をより激しくできたり、いったんレベルが上がってしまったら下がりにくくしたりできるので、これによってボスの個性も出せるようになっています。

 さらに、ボスに対して有効な攻撃をするプレイヤーに対しては、常にストレスレベルが高くキープされ、激しい反撃を多くするようになり、アクションが苦手なプレイヤーに対してはストレスレベルの上昇が抑えられるといった、難易度調整も自動でできるようになりました。

 結局のところ、ボス固有の攻撃のバリエーションを考えなきゃいけないし、各種数値の設定もちゃんとしないといけないしで、今回の方法でボスの制作が楽になったわけではありません。とはいえ、ある程度の共通な仕組みでボスの量産ができそうな感じになってきました。あとはちゃんと忘れずにドキュメントを整理するだけ……なんですけど、めんどーなことはいつも後回し。これまでも、メモとしていろいろ書き残しているのですが、たまーに間違ったコマンドとか変更前の仕様とか書いてあったりして、油断がなりません(常に過去の自分と戦っている…)。

 とはいえ、大きな問題が一つ片付いて一安心。次は、テストプレイしていう間にず〜っと気になっていたダッシュとチャージの使い勝手の悪さ(=操作性の悪さ)を、少しでも良くしなければ……そろそろちゃんと考えなきゃいけないゲームそのもののデザインとともに悩むとします。がんばろっと。

Unityアクションゲーム制作記 その15 オープニングを作る

youtu.be

 さて、ゲーム本体のシステムも作り終えないうちに、どうにも煮詰まってしまって気分転換にオープニング映像を作り始めてしまいました。 とはいえ、映像制作なんて、Live2D Creative Award 2016用に応募用に作ったくらい。どう手をつけようかなーと悩みましたが、まずは「なにをやりたいか」を明確にして、映像のイメージを膨らます作業から始めました。

1)音楽との連動

 目指すはBGMとの完全同期……なんてことは、これっぽっちも思わず、要所要所でカットの切り替えをしたりして「なんとなくそれっぽい」風に見えればいいやー、ということを目標にしました。

2)アングルとカメラワークを可能な限り単調にしない

 使おうとしていたBGMが約80秒で、ちょうどテレビアニメのオープニングくらいのサイズ。個人的にもよくアニメは見るので、記憶にあるいい感じのオープニングを思い出しつつ、アクションゲームらしい見せ方にこだわる方針に。

3)UnityエディタとDOTweenとTypeface Animaterと少々のスクリプトでなんとかする

 こういった映像を作るためには、それ専用のタイムラインエディタを使うのが筋です。しかし、ツールを覚えるのも面倒だし、80秒くらいならTween系でなんとかなるだろうということで、Unity エディタのシーン上にオブジェクトをぽちぽち置き、カメラやオブジェクトの制御はDOTweenとスクリプト、クレジットなどの文字の演出はTypeface Animaterでゴリゴリ作っていきました。

 まぁ、「とりあえずやってみよう! 無理だったらちゃんとツールなり導入する」という、いつも通りの見切り発車スタートってことです。

・まずは絵コンテを作る

 映像制作に慣れているプロならともかく、どう見せたいかもわからない素人がツールも使わずにやるわけですから、それなりに作りたいものをきっちり書き出しておく必要があります。要するに絵コンテというやつですね。その試行錯誤の結果がコレ↓

f:id:hamazakifactory:20170114193658j:plain

 音楽と映像の流れをそれっぽくということで、フリーのサウンド編集ソフトであるAudacityで表示される曲の波形を縦軸(時間)にして、時間ごとにどのようなカットを再生するかをゴリゴリと記入していく超アナログスタイル。前半はプレイキャラのFayeとアクションをじっくり見せ、後半にゲームの魅力となる敵とのアクションをモリモリと入れ込んで行こうという方針にしました。

 ちなみに使用ツールは、illustrator(笑)。仕事で使い慣れているので、手で書くよりはいろいろ楽かなーというだけの理由です。

・Unityエディタに落とし込む

 ここからは力技。絵コンテに書かれたカットごとに見せるオブジェクト、カメラ、ライト、キャンバスを作ってシーン上に配置していきます。再生時には、指定された時間に再生したいカットの親オブジェクトをアクティブにしていくだけ。もちろん、カットごとに使い回せるモデルやカメラ、ライトを置くのは、はっきり言ってメモリの無駄です。しかーし、今回はそういう細かい事(?)は気にせず突っ走ることにしました。

f:id:hamazakifactory:20170114202332j:plainf:id:hamazakifactory:20170114203230j:plain

  ちなみにモデルで使っているシェーダーは、標準のUnityChanシェーダーです。ただ、単色のイメージにするため、テクスチャをグレースケールにしてあります。この状態で、カメラのBackGroundとDirectionLightのカラーを一緒にすると、今回のようなイメージになります。

f:id:hamazakifactory:20170114204940j:plain

 ただ、目だけはオリジナルのモデルの色を残したかったので、目のメッシュだけに当たるように専用のライトを用意して、体に当たる色とは別になるようにしてあります。

f:id:hamazakifactory:20170114205658j:plain

コンポーネント(制御スクリプト

 ここも単純に、移動する、アニメーションを再生するといった、単機能のものを対象のオブジェクトにペタペタ貼り付けていくスタイルでごり押し。例えば、カット再生開始後にwaitTimeだけ待ってからアニメーションさせたい場合は↓のようなスクリプトを対象オブジェクトへ貼り付けます。

f:id:hamazakifactory:20170114210145j:plain

 ちなみに同カット内で連続的にアニメーション再生させたいときには、もう1つくっつけて、開始時間と再生アニメーションの名前を入れていく……。

f:id:hamazakifactory:20170114210544j:plain

  ……バカですねぇ。それでも、前半まではオブジェクトの数も少なく、複雑なカメラワークもなかったので良かったのですが、後半のバトルシーン的なものを作りたくなってからは地獄でした;; とはいえ、半分まで作ってしまったものですから仕方ない。後半も泣きながら突っ走りましたヨ。

・結論 ちゃんとしたツールを使おうぜ!

 クオリティはとにかく、なんとか無理やりにでもやりたい事を詰め込んだオープニングができました(10日くらいかかったのかなぁ)。作ってみてわかったことが一つ。「こういった映像系のものを作る時には、ちゃんとタイムラインエディタを使いましょう」です(当たり前だぁ)。今回の方法は、とにかく編集・調整がしにくいのが問題ででした。何度ぶん投げようかと思ったことか……(80秒って意外と長い)。次にやるときは、ちゃんとやります、きっと……さて、気分転換も済んだし、ゲーム本編を作らなきゃだ。がんばろ。

 

>OPでとてもお世話になったアセット(モデル・エフェクトは除く)

・Fire Music Pack

https://www.assetstore.unity3d.com/jp/#!/content/61607

 ・DOTween

https://www.assetstore.unity3d.com/jp/#!/content/27676

・Typeface Animater

https://www.assetstore.unity3d.com/jp/#!/content/37445

Unityアクションゲーム制作記 その14 攻撃時の軌跡エフェクトの変更

youtu.be

 年末にいろいろあって、久しぶりの更新となった今回は、軌跡エフェクトの変更をしてみました。攻撃の軌跡には、これまでアセットの「X−WeaponTrail」を使っていたのですが、モーションとの相性も悪く「なんとなく微妙だなぁ」と常々思ってました。そこで、ちょっと試しとばかりに、エフェクト用に購入したアセットの中から適当なテクスチャを選び、単純なメッシュにテクスチャを貼り付けて回転させてみたところ、いい感じのエフェクトに! これまで、なんとなく剣先の位置とかモーションにエフェクトをちゃんと合わせないとダメだろうなぁと思い込んでいました。それが、こんな単純な手段でそこそこの見栄えになったことにちょっとびっくりです。

 ただ、本当に1枚のメッシュにテクスチャを1枚貼り付けているだけなので、角度が悪いとペラペラの板であることが丸わかりになってしまいます。とはいえ幸いなことに見下ろし視点からそれほど自由に動くこともなく、一気に攻撃がゲームらしくなりました。ついでに、軌跡のテクスチャも下の写真のように4パターン作り、それぞれ試してみたところ、なかなか悪くないエフェクトに。これなら、最小限の手間で武器のレベル表現もできそうな気配です。

f:id:hamazakifactory:20170104180742j:plain

 ゲーム要素として「成長」を組み込めれば、ゲームが持つ楽しさの大きな一要素となります。まぁ、その分バランスやら大変なことも増えますが、ゲームとして面白くなるのは間違いないのでちょーっとは頑張りたいところ。まだまだやらなければならないことがてんこ盛りの中、やりたいことを増やしてしまうのは不安ですが……なんとかなるっしょ。うん。

Unityアクションゲーム制作記 その13 ちまちまと作業を進める

youtu.be

 懸案のダンジョンの生成がなんとかなって、ほっと一息。次に手をつけたのが、かねてよりやらなきゃと思い続けてきた、ボスクラスの敵のロジックを実装すること…ではなく、大量の敵が出現するときにも対応出来るようなオブジェクトプールシステム…でもなく、会話イベントシステムでした。

 モーションの新規作成が難しく(単純に作れない)、たいしたものはできないのですが、とりあえず、キャラを表示して会話くらいできるようにしたいなーということで…

・3Dオブジェクトを登場させる

・吹き出しを表示、文字送りをさせる

・アニメーションの切り替え

やれることをこれくらいに絞ってみました。UI(メニュー)を表示するシステムを、少し弄り回すだけでなんとかなりはしました。ついでに欲が出てきて、チュートリアルなどでよくある操作説明をするときに表示する、ダミーカーソル的なものもやってみたいなーと思いつき…無理やり実装。ただし、Canvasに表示させたカーソルの座標を変換して、そのままタップされた座標にしているため、カーソルを動かしている最中に縦・横回転が起きると座標が飛んでしまうというアホ仕様ですが。このため対処療法的にダミーカーソル動作中には縦・横回転をNGにしました。解決策がないわけではないのですが、とりあえず余裕があったら直そう、なくらいで放置することにします。

youtu.be

 次にやったのは、操作系の改良です。これまで連打・目押し・チャージと3つの連続攻撃を入れていましたが、どうにも使い分けというか、操作の煩雑さがうっとおしいなあと思い続けてました。そこで、チャージによる連続攻撃をボツにして、連打&目押しで発生したHit数とKill数でポイントを発生させて蓄積、その蓄積されたポイントが一定数あれば、少しの時間タップし続けるだけで必殺技っぽいものを使えるように攻撃の流れを変更しました。

 改良により、連打・目押し・チャージ、それぞれの操作によって出せるアクションが明確になり、そこそこ気持ちのいいものに仕上がったかと。とはいえ、タップした場所が細かくブレてしまったり、他の連続攻撃の合間にチャージ要素入れられないかとか余計なことを考えてしまい、意外に「タップし続けている」という状況をどう判定したらいいか、どう組み込めばアクションがより気持ち良くなるか、うまい方法が見つからず手間取っている最中です。

 もう一つ操作で追加した要素が、フリック操作によるダッシュ移動です。緊急脱出用とか、連続攻撃中に出すとキャンセルして移動できたり、こちらもそこそこいい感じになっているのですが、ただ高速で移動するだけでは芸がありません。ボスクラスの敵の背後に回り込めたりとか、もーちょっと使い勝手を上げられないか、これまた余計なことを思案中です。

 しっかし、そろそろ作り始めてから半年が経過。半年かかっていまだ操作系の調整をしているって…アクションゲームって難しいなぁ。やりたいことは結構入れられたけど、ゴールはまだまだ…とりあえず、がんばろ。うん。

Unityアクションゲーム制作記 その12 ダンジョンを作る

youtu.be

  引き続き前回出た課題、シーンに配置したオブジェクトが、直にアプリサイズに影響するということで、ダンジョンを構成するオブジェクトを生成(ダンジョン自体を自動生成するわけではない)するアプローチをしていきました。

 作りたいダンジョンはこんな感じ(↓)。

f:id:hamazakifactory:20161022171550j:plain

  1. 部屋は四角のみ(穴開きはなし)
  2. 部屋の大きさは3×3以下にしない
  3. 部屋の一辺に一つの通路のみ接続
  4. 高低差はなし

 これくらいの単純なダンジョンであれば、床のある場所の上下左右を調べ、空白であればその方向に壁を置く、やることはこれだけ。ただ、一つ問題が……床と壁のメッシュが分離しているアセットはいいのですが、購入した背景アセットの一つが、床と壁が一体化したメッシュのものでした。

f:id:hamazakifactory:20161022172318j:plain

  それぞれ別にするのもアレなので、結局は、一体化したパーツに統一してダンジョンを作っていくことに。まぁ、パーツの規格を統一することで、少ない手間でバリエーション(外観だけだけど)を増やせるというものです。

f:id:hamazakifactory:20161022172922j:plain

 ダンジョンを構成する最小単位のオブジェクトはどんなものを用意すればいいのかなーと、パターンを書き出してみると、どうやら最大16パターンのパーツがあればいい模様。 f:id:hamazakifactory:20161022173044j:plain

  • 0の位置(上)空白だった場合は+1
  • 1の位置(右)空白だった場合は+2
  • 2の位置(下)空白だった場合は+4
  • 3の位置(左)空白だった場合は+8

と順番に調べて足していけば、必要なパターン番号が求められます。しかも、同じ形状を回転しているだけのものも多いので、それらを省いていくと実際に使われるオブジェクトは、さらに少なく6個で済みます(しかも1個はほぼ未使用)。パターン番号から使うプレハブと回転の変換テーブルを用意しておけば、6個のプレハブを用意するだけで一つのダンジョンの基本形状をまかなえるということですね。

 実際は通路に別形状を使いたかったり、一つのダンジョン内で複数の壁や床のバリエーションを使いたかったりするので、もう少しパーツの種類は増えます。それでも、シーンにおいて実体化させるよりは格段にアプリサイズを削減できました。

f:id:hamazakifactory:20161022174414j:plain

 左が調整前のダンジョンの外観バリエーションが一つ、ステージが二つの状況です。そこから、ダンジョンの外観バリエーションを三つに増やし、ステージも7つ用意しても劇的な変化。ちなみに、このダンジョン作業をしてミニマップを作り終えたくらいでSSDが吹き飛んで作り直しを余儀なくされました……ということで、左側の状況は作り直し前の状況の画像なので、あくまで参考という感じの比較になってしまいましたが……。

 とはいえ、当初の目的であるアプリサイズを削減することは達成できたので、ひとまずヨシとしておきます。 なおどれくらいまで一度に表示しても大丈夫なのかなーと広めのマップを作ってみたところ、これくらいが限界っぽい(Zenfone2を使用)。

f:id:hamazakifactory:20161022180211j:plain

  うーん、全般的におりこうさんな作りにしてないとはいえ、もう少し頑張りたいところだなぁ。まだ知識が全然追いついていないので、最適化までは考えが及ばないのが悲しい現実だけど。ひとまず動く範囲の大きさで抑えつつ、やりたいことを突っ込んで行こう。まだまだ作らなきゃいけないものはわんさかあるからね…がんばろ。

Unityアクションゲーム制作記 その11 アプリサイズで七転八倒

 日々、適当仕様のバグ取りに追われながら制作していたとき、ふと唐突にアプリサイズのことが頭をよぎりました。

 アプリの省サイズ化は、もう少しやりたいことを突っ込んでからと思っていたのですが、試験勉強のときに部屋の掃除がはかどるように、煮詰まっていたり、やらなければならないことがあるときに限って、本筋とは違うことが気になって仕方ない状態になり……少しはスリムにしておいたほうがいいだろうと、結局手をつけることになりました。 

 まずは、アプリの中身がどうなっているのかがどうなっているのか調べなきゃ、と見つけたのがここ↓。

soyliquid.blogspot.jp

 ごちゃごちゃとアセットを突っ込みまくっているので、何が出るかなーと思っていたら、使いもしない9MのWAVデータ(テスト用に初期状態として突っ込んでいたファイル。すぐ書き換えられて実際には使用されることはない)やら、初期の頃にメインタイトルの背景として使っていた8Mくらいの画像ファイル(放置していたオブジェクトにアタッチされてた)などが、ログにゴロゴロ出てきました……。これらを整理しながら、テクスチャや音楽データなどのサイズを変更したりして、だいたい60Mあたりに落ち着かせたのですが、ある日、2つのシーンを行き来できるようになったタイミングで、問題が起きました。

f:id:hamazakifactory:20161004135218j:plain

 正確には問題というか気付いたことが1点、内訳の中になにやら突出してクソでかいサイズのものがある……。巨大なLevelsという項目の中身はなんなのか、しばし検索してみるも、どうにもよくわからず。名称からゲームレベル(=シーン)なのかなとあたりをつけて、試しにステージのオブジェクトを置いている2つのシーンを外してビルド。すると……

f:id:hamazakifactory:20161004140304j:plain

すげー減ってる!

f:id:hamazakifactory:20161004140551j:plain

f:id:hamazakifactory:20161004140605j:plain

 ちなみに2つのシーンに置いていたオブジェクトはコレ↑です。いまさらながら中身を確認していくと、パーツ1つで、最大15Kの頂点、9Kの面で構成されていて、FBXのサイズが200K〜300Kくらい。これが50個ほど、1つのシーンに置かれていたのですから、サイズがでかくなるのは当然といえば当然。なのですが、「このアセットかっこいいよねー、モバイルでも動くから大丈夫かなー」と頭の悪い子状態で購入したときには、こんなことになろうとは全く想像していませんでした。

f:id:hamazakifactory:20161004143057j:plain

f:id:hamazakifactory:20161004143123j:plain

 シーンを1個にしてオブジェクト群をON/OFFしたり、メッシュインポートの圧縮設定を変えたり、試しにオブジェクトを増やしてみたり、いろいろ条件を変えて見たところ、シーンに生成されたオブジェクト(+α)が、ビルドしたときにがっつり含まれていると判明。知らないって怖い……。

 AssetBundleを利用して、必要に応じてシーン(ステージデータ)を読み込むようにすればいいのでしょうが(1シーンを数Mまで圧縮することもできそう、ふつーのゲームはそうしているんだろうなあ、きっと)、AssetBundleを使うとなると、当然シーンデータをやりくりするためのモノを作らなきゃならないだろうし、そもそも現在のUnityエディタの上でステージを作成する方法自体も手間のかかるもの。パーツの大きさだけが問題なら利用するアセットのサイズが小さいものに変えればいいともいえますが、これもすぐに物理的限界(アプリサイズ100M)を迎えそうで、根本的な解決になりません。設計段階できっちり仕様を決めておく、という当たり前のことをしていなかったツケがきたということでした。

 やれるだろうと思っていたことが無理と分かり、折れかけている心をなんとか騙しつつ、なんとか現状でステージを増やせないかアレコレ調べたりしましたが、解決策は見つからず。手間をあまりかけずにいい方法はないか、と思い詰めていたときに降ってきた言葉が「自動生成」でした。

 ダンジョン自体の自動生成までやらなくても、↓こんな感じで、

f:id:hamazakifactory:20161004150806j:plain

スプレッドシートに書かれたマップ情報からダンジョンの生成をシーンにできないか……しばし悩むこと数日。うん、これならなんとかなるかもしれない。という方法が見つかったので、できるかどうか……いや、できるよにするためにがんばっていこう、きっとなんとかなる!

 

 

Unityアクションゲーム制作記 その10 ダンジョンを走る!

 

youtu.be

 終わらない敵ロジックの実装&バグ取りをしつつ、遠隔系の攻撃を実装し、なんとか、ダンジョン内を走り回れるまでになりました! あちこちバグだらけですが、同じことばかりやっていて気が滅入っていたので、敵ロジックはある程度見切りをつけて放置。やりたいことを優先して詰め込むように作業を進めました。

 アセットストアにあったド派手なエフェクトを使い(↓コレとか)、

>Magical - Pro Edition

https://www.assetstore.unity3d.com/jp/#!/content/55713

扇状にオブジェクトを発射するものと、噴射タイプの二種類を実装。オブジェクトを発射するタイプは、生成したオブジェクト任せで自律行動できるように組み込むようにしました。今回このアセットを使って学んだのが、

「機能ごとに特化したコンポーネントスクリプト)をうまく組み合わせて使う」

ということでした。「Magical」では、移動するのみ、出現時にランダムの回転・位置を与えるといった単純なものから、何かに当たったら別のオブジェクトを生成するといった感じのスクリプトなどが用意され、それを必要に応じてスクリプトをアタッチしているという構成。必要な機能を組み合わせて、最小限の大きさでいろいろなものを作っていく、Unityのゲーム制作の基本というか 当たり前のことをいまさらながら体感しました。なにぶん古い時代のマイコン世代でのプログラミング経験しかないので、汎用的に使えるものを作ろうとしたときに、なんでもかんでも1つのスクリプトに詰め込んでいた始末。この辺をうまく機能を切り分けるのも、今どきの出来るプログラマーなんだろーなーと一人で納得してました。

 とりあえず使えるものは使いつつ、似たような感じで作り直していきましたが、特に問題となったのが、接触判定。アセットのままでは単純な接触判定しか行っておらず、魔法のオブジェクト同士が干渉してしまったりするので、うまくレイヤーの設定やら詳細なチェックが必要だったりするなど、自分の作っているゲームに合わせての調整は必要でした。

  ダンジョンでのゲームを進行は、

・部屋に入る

・扉が閉まる

・出てきた敵を全滅させたら扉が開く

という具合にして、敵とのバトルを中心にダンジョン内を探索する楽しみも提供できたらなーと。ダンジョン自体は、もりもりとオブジェクトを置いていき、1シーン=1階層という形にしてみました。次の階層へ移動したときは、該当シーンを読み込んでいけばOKって感じです。

f:id:hamazakifactory:20160928180559j:plain

 ここでハマったのが、扉の初期状態を作るところ。鍵のかかっている扉は閉じたままにしておき、それ以外は開けておくというふうにしていたのですが、エディタ上ではちゃんと動いているのに、スマホの実機上では開いているはずの扉が閉まったまま…。どうにも初期化処理がうまくいっていない。

 扉の管理は、扉オブジェクトの一つ上に置いておいた管理用のオブジェクトでまとめて管理していました。実機で動かないものをチェックしていくのは面倒だなぁと思いながら丁寧に追いかけていくと、どうやら管理している扉のオブジェクトの生成が初期化処理のタイミングで間に合っていない模様。管理用のオブジェクトが扉の初期化処理を行おうとしたタイミングで、初期化したい扉のオブジェクト自体がないわけですから、初期化されるわけがない。

 要は、シーンデータが読み込まれて実際にオブジェクトが生成される順番は決まっていないという大前提を、すっかり忘れていた(というより考えもしなかった)というものでした。結局、扉自身に初期化を行わせるように変更してなんとか解決しましたが、ごくごく基本的な考えなのに、いまだ慣れないなぁ……ちゃんと順番を考えた安全な作りを心がけないといけないのね……と反省。

 なんとかダンジョン内を探索っぽい動きもできるようになったところで、セーブデータはどうするんだ? とか、ギミックも多少入れないプレイヤーは飽きるぞ? とか、報酬アイテムはどうするの? などといった根本的な問題が大噴出……この辺は、階層移動の仕組みを組み込んだあとにちゃんと考えよう、きっと考えるだろう。うん。