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

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

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

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

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

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

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

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

Unityアクションゲーム制作記 その9 コンボ追加〜

 ここ1ヶ月くらい、ずっと細かい調整と何か機能を追加するたびに起こるエンバグデバッグ作業の繰り返し…。ようやく、今度こそ攻撃コンボはコレで! というところまでこぎつけました(あちこちバグはアリだけど)。

youtu.be

 これまでに用意していた攻撃コンボは、連打とチャージ(押しっぱなし)の2種類でした。そこにタイミングを見て攻撃する目押し系のコンボを追加したのですが、これがまた難産というか、適当に仕様も決めずにやってきた継ぎ足し継ぎ足しのフラグ管理のツケが回ってきたというか……あっちこっちで不具合を引き起こして、ホント対応に苦慮しました(泣)。しかも片手1タップの操作だけで、3つのコンボを気持ち良く使い分けなければ意味がないので、その辺りの調整もしんどかった。

 で、最終的にまとまったのが以下の3つの連続攻撃です。

連打攻撃>特徴:前方への範囲攻撃が強い

 操作:とにかく連打しているだけで、連続攻撃を繰り出してくれる

コンビネーション攻撃>特徴:360度、全方位への攻撃が可能

 操作:攻撃マーカー(赤いもやもや)の出るタイミングにタップすると全方位への連続攻撃を繰り出してくれる。他のタイミングでタップしてしまうと攻撃は繋がらない

チャージ攻撃>特徴:突進による強力な吹き飛ばし攻撃で敵を砕く

 操作:ダブルタップ後、押しっぱなしにしているとエフェクトが発生。最大まで大きくなったあと、画面から話すと現在向いている方向へ突進する

 コンビネーション攻撃の受付時間には、ド派手なエフェクトを用意して、タイミングがわかる用意もしてあります。ただ、受付時間自体が短いので、見てから押しても間に合わないこともあるのかも…ここは体でタイミングを覚えてもらうしかないかなと。

f:id:hamazakifactory:20160901180034j:plain

 とりあえず、これでなんとか遊びやすくまとまったはず! しかしテストプレイしている自分が慣れてしまっているだけの可能性もあり、ちゃんとできているかどうかは判断に苦しむところですけど。

 ま、これからバグを潰しつつ細かい演出面での課題を拾いながら、ゲームとして面白くするための方法を探っていきます(いまさらだけど)。とにかく前に進めて頑張っていかないとだ。うん。

Unityアクションゲーム制作記 その8 メニュー周り

 やることはいっぱい、ゲームの中身を作り込まなくてはいけないのですが、ここのところは中身とは関係のないメニュー周りをいじり倒してました。縦横自由に持ち替えられるようにするためのメニューはどうすればいいのかなーと、ぼんやり考えながら行き着いた先がコレ⬇︎

youtu.be

 ぶっちゃけていうと、メニューとして置くパーツ(ボタンやイメージ)それぞれに縦・横のレイアウト情報(表示の位置座標)を持たせ、切り替わったらそれぞれの位置へDOTweenを使って移動させるだけという力技。まだボロが出るときもなきにしもあらずですが、一応、さまざまな解像度の端末で、ある程度見苦しくない程度でレイアウトを維持できるような仕組みができたかなと。予想通りというか、完全自動化とかは無理でしたけど♪ あと、せっかく(?)なので背景の穴埋めにFayeちゃんを置いて、見た目だけは豪華にしてみました。他には、ゲーム中に敵へ与えたダメージ表示を入れたり、ゲームオーバー場面を作ったりしているだけで結構な時間が経過してしまいました。

 このゲーム、そもそも「わらわらと集まって来る敵をぶっ倒す」というコンセプトだけで適当に制作を進めてきたおかげて、ゲーム全体の構成をどうするかとかを考え、具体的に形にしようとすると…とにかく決めなくてはならない細部&作らなきゃいけないものが多いことに気づかされます。やっぱりゲームを作るのは大変だなぁ。楽しいけど。ということで、広げすぎた風呂敷をうまくバランスよく整えつつ、引き続きがんばっていこう。うん。