大まかなマップ

全体マップの設計

今週はUnity作業できず。

そろそろ全体像を決めておこう、
と思ってマップ全体のおおまかな設計をした。
あと、タイルマップ機能の使い方とかを調べた。

これは概念図で、マス数とか画面数は考慮していない状態。
２Ｄゼルダよりはキャラのサイズが大きいので、
一画面に何マスあると良いのかは作ってみないと分からない。
敵がプレイヤーよりでかい点もややこしそう。

ダンジョンがいくつもあるようなゲームではなく、
小ぶりな世界なことは見て取れると思う。

これは旧版の画面。
旧版では、プレイヤーは３人組の探検隊で、
トラブルのためジャングルに取り残されてしまう。
３人は危険な状況に対処しながら、
川に橋をかけたり、水を手に入れたりして脱出を目指す。

今回は３人ではなく、とりあえず１人で作る。
実のところ、旧版でも
「一人ずつ減っていってゼロになるのがそそるな～」
というフレーバー的な理由で３人にしただけで、
スキルとかの違いを作るつもりはなかった。
今回も、余裕があればそうしたいけど、
何せ３人いると作業量が３倍になってしまう箇所がどうしても出てくる。
まずは１人で。

旧版は、ひたすら右に右に進んでいって、
川下りができるような川まで辿り着くというゲームだった。
今回は自由に動けるので、キーアイテムを集めるゲームにする。
故障したボートを修理して脱出するために、
木材、燃料、電子部品の３つを回収する。

なので、ボートの地点からスタートして、
アイテムを集めて、ボートのところに戻って来てＥＮＤ。
その合間で、川を渡ったり岩を壊したりする箇所が出てくる感じ。

戦闘の扱い

難しそうなのは、
「敵との戦闘をどれくらい強○するか」という部分。
自由に動けるゲームなので、
敵を避けようと思えば避けれてしまう。
あっというまにクリアできちゃうかもしれない。

「倒さないと進めない」ようにしたらどうか。
ベルトスクロールみたいに、倒さないとスクロールできないとか、
倒さないと重要アイテムをドロップしないとか。

正直なところ、
あんまり戦闘を作り込めると思っていなくて、
戦闘を面白くする自信がない。
そもそもそういうゲームでもない。
しかし、だからといって障害がなさすぎると、
いまいち完成品に見えなかったりするものだ。

この辺も、作ってみないと分からないところがある。

次の予定

コードのリファクタをするか、
タイルマップ機能を試しに使ってみるか。
またはメニュー画面とかの設計。
メニュー画面を一から作るのは何気に面倒くさい。
アプリだったらタップ操作できるのだが、
いちおう十字キー操作するゲームなので、
カーソルの仕組みとか作らないといけない。

アニメーションのテスト２

アニメ画像分離テスト

　
プレイヤーと敵のアニメーションを分離するテスト。
見た目は前回と同じだが、
敵を前景と後景に分けて、その間にプレイヤーを挟む形にした。

前景と後景を分ける手間は発生するが、
プレイヤーの画像をある程度他に使いまわせるし、修正も楽なはず。

位置の連動に関しては、HoldあるいはVoreが始まる瞬間に、
敵位置に合わせてプレイヤー位置を瞬間移動させている。
その動きは、アニメクリップとは別にスクリプトを書いておいて、
アニメクリップのイベントとして呼び出すことにする。
アニメ中、プレイヤーの位置を細かく動かしたい場合なども同様。

位置移動とアニメクリップを分離しておくことで、
一つのプレイヤー動作を違う敵に使い回しやすくなる。はず。

8方向か4方向か

「8方向に動けるけど、画像は4方向のみ」
でいこうかと思ったけど、
飛び道具の発射方向が不自然になるという弱点がある。

主人公側は自分で操ってるからまだいいが、
敵の攻撃方向が読めないのはつらい気がする。

やっぱりいっそ、4方向だけにしようかなあ。
敵の飛び道具が4方向の場合、斜めの位置が安全地帯になっちゃうから、
簡単になりすぎるかと思ったけど、
別に簡単でいい気がする…。

予定見直し

進め方を見直す必要が出てきた。

「仮素材で全部動くようにしてから絵を作る」
という方針だったけど、
アニメーションでそれをやると、だるいことになる。

というのも、アニメーションの場合、
素材が何種類・何枚要るかは「絵の内容による」。
どのタイミングで動かすか、どう連動させるかも「絵の内容による」。
なので、仮素材では確定しない。
または、仮素材としては細部を詰めて作るか。
かなり詰めないと「あとは本番素材に差し替えるだけ！」とはならない。

そして、ステージギミックとか武器の種類とかも、
作りながら微妙なコード修正が発生するだろう。
または、仮素材としては細部を詰めて作るか。
本番画像と同じ種類・枚数の仮素材を作ることになってくる。

それは、最初から本番素材を作って詰めた方がいいのでは？という気がしてくる。

仮素材の役割

仮素材は、基幹システムの動作をざっくり確認するためのもの、
と考えた方がよさそうだ。
それに必要な分だけに留めたい。

アニメーションは、最初から本番素材を作った方がいい。

なら、基幹システムができた時点で、
マップを区画に区切って、本番素材を作り始めた方がいい気がする。
ということで、少し予定を見直す。

必要なものの見直し

１．キャラクター系
　時間かけていいので、基盤をしっかりリファクタする。
　全種族・全行動まで作らなくてもいい。
　
２．アニメーション系
　使い方は大体分かった。
　レイヤー分けと連動の検証がうまく行けば大丈夫そう。

３．進行管理系
　ライフ、残機、アイテム欄、武器欄、スポーン、ゲームオーバーの規定。
　連動の検証がうまくいけばキャラ変更を入れるかも。
　でもそれは後に回せるように。

４．マップ上のもの系
　キャラクター系とほぼ同義のようだ。
　中身を作るのは実際にステージギミックを作る時でＯＫ。

５．マップ系
　UnityにTile Paletteという機能があるようだ。
　それの使い方を覚えるのと、スクロールの実装くらいまでやる。

６．音系
　アニメとの連動はイベントでＯＫ。
　連動があるので、本番素材を入れていく段階で作ったほうがよさそう。

７．セーブ系
　フラグ管理に絡むので、実はこれ後かも。
　ＵＩにさほど絡まないから最後に作ってもいいかも。

ということで、
１，２、３、５がざっくりできれば、
全体マップを考えて、
区画ごとに本番実装を始める進め方にしようと思う。

アニメーションのテスト

他用で忙しく、間が開いてしまいました。

Unityのアニメーション機能のことを知らずに進めるのが不安なので、
とりあえずアニメーションを使ってみることにした。

だいたい分かった。
８方向の歩行アニメとHold、Vore、体内描写の骨組みを作ってみた。

画像は仮素材です。
棒人間で構わない段階だけど、せっかくだから雰囲気だけそれっぽいものを。
待機アニメがないからちょっと寂しい。
※ヘビに重なってる四角は当たり判定

連動はあきらめる？

vore時の連動がネックだったけど、
いったん連動はあきらめて、
敵とプレイヤーが一個の画像に含まれる形にしてみた。

というのも、捕食描写では動きの中で「重ね順」を変える必要があり、
飲み込まれる前はプレイヤーが上、
飲み込まれた後はプレイヤーが下、
その境界線は敵の口の形に合わせてマスクして……
と、複雑なものになる。
それをUnityのアニメーションで実現しようとするのは、
多分けっこうややこしい……。

なので、敵の画像を、
敵とプレイヤーを両方含む画像に差し替えてしまうことにする。
予め、そういう画像を用意しておく。
その間、プレイヤー本来の表示は消しておく。

これで一応、シンプルに作ることができる。
Unity上での連動を諦めて、
画像を作る時点で連動するように描く形。

しかし、このやり方には多大な欠点もある。
まずプレイヤーキャラの画像を後から差し替えることができないので、
後からデザイン変更をする場合、全描き直しになる。

プレイ中にプレイヤーキャラを切り替えることも無理になる。
もしやろうとすると、すごい数の画像が必要になる。

何より、種類が異なる敵のアニメ間で、
プレイヤーの画像を使いまわすことができない。

このやり方はほとんど人海戦術に近い。
ほんとにそれでいいのか？
それはそれで画像を作る労力がやばすぎないか？

もうちょっと考えよう

やばそうな気がする。
もう少し考えることにする。

敵を複数パーツで表現するようにして、
「プレイヤーの上になるパーツ」
「プレイヤーの下になるパーツ」
をくっきり分けてはどうか。
つまり例えば、敵を頭部・口内・身体に分けて、
頭部・身体はプレイヤーより上、
口内はプレイヤーより下のレイヤーに設定する。

ヘビの巻き付きの場合、
プレイヤーの前に来る部分と後ろに来る部分を別レイヤーにする。

そういう構造を前提にアニメーションを考える。

これで、もうちょっとましにできないか？

プレイヤーと敵の動きを別個に設定することになるので、
場所とタイミングは一個一個合わせないといけないが、
作業の仕方は大体分かったから、一応できそうに思う。
どっちの手間を取るかだ。

とりあえず次回、複数パーツ＆レイヤー分けの実験をやってみよう。

8方向アニメの省略

動きは８方向でも、絵は４種類でいけるんじゃないか。
例えば右上に動かす場合、右向いた画像のまま斜めに動いていく感じ。

描いてみて思ったけど、横向きの画像を「真横」にする必要はなくて、
ちょっと角度がついた絵の方がかっこいい。
ちょっと角度がついていれば、斜めに動いてもそこまで違和感ない。

そうしないと、やられアニメとかの手間がすごいことになる。
逆に言えば、方向を絞ることでそのへんに凝ることができる。

ということで、実験と修正を挟んでから、キャラクタ―系のリファクタをしたい。

キャラクター系のシステム２

引き続きシステムを作っていきます。
一週間に一回くらい報告できたらと思いますが、未定です。

プレイヤーに「チェック」行動、
キャラクター固有系に「Massage」を追加。
「チェック」の当たり判定に「Massage」オブジェクトが入った時、
メッセージウインドウを表示する。
中身はインスペクタからオブジェクトごとに書いておく。

複数ページ送りやスキップ等も作らないといけないが、今はこれだけでよし。

プレイヤーの武装はＡキーとＳキーの２スロット制にした。
メニューで好きに割り当てて使う。
Ｚキーには「チェック」が固定で入っている。

「ジャンプ」行動も入れて簡単なステージギミックにしたいが、
特殊なので後回しにする。

プレイヤーに「シールド」行動を追加。
キーを押している間、通常攻撃を防ぐ。
攻撃に当たると大きめにノックバックする。
敵も「シールド」を使えるように作った。

いくつかステータスを足した。
赤字はGP（レバガチャポイント）、
青字はMP（メンタルポイント）、
黒字はHP（ヒットポイント）。

敵の攻撃を受けるとMPが減り、０になるとピヨリ（Dizzy）になる。（HPも少し減る）
レバガチャでGPを100まで上げると復帰する。

ピヨリ状態で接触攻撃を受けるとVore状態になり、HPが徐々に減る。
HPが０になると死ぬ。
まだ死亡処理を作ってないけど。

敵に「ホールド」攻撃を追加。
掴み攻撃でプレイヤーの動きを止め、拘束状態にする。（ピヨリとほぼ同じ）
レバガチャで脱出できる。
脱出しないとMPが少しずつ減っていき、0になるとVoreに移行する。

Vore演出は以上を基本形に考えていく。

MPがあってもダイレクトにVoreに移行する攻撃や、
一定ダメージで自動解除される攻撃も考えられるが、
それらも基本形のバリエーションで作れるはず。
MPは、今は回復してないが、時間経過で回復するようにする。
それかアイテムで。

あと、動画では４方向しか動いてないけど、８方向対応した。

揃ってきたけど…

アクションは最小限揃ってきたけど、
細かいところに不安が残るので、少しリファクタしてから進みたい。

まず、当たり判定が不完全で、壁とか敵にめり込んでしまう。
物理演算以外の仕組みで動かしているところがあるため。
たぶん押し返し処理を作らないといけない。

同じ理由で、当たり判定がキャラの動きに置いて行かれることがある。
RectTransformで動かすときは、親を動かせば子も動いてくれるが、
iTweenや物理演算で動かすと子が置き去りになってしまうため。
子にも同じ動きをコピーしてやらないといけない。

あと、コードがこんがらかりかけてるところがある。
特に、ホールドとかVoreはプレイヤーと敵双方が絡む動きなので、
誰が制御しているのか分かりにくくなってしまっている。
整理して、この段階で頑強に作っておきたい。

アニメーション

…しかし、コードの整理は、
アニメーションの制御と併せて考えるべきかもしれない。

何しろアニメーション機能のことをほとんど知らずにやってるので、
今あるコードだけ先に整理しても無駄になるかも。

リファクタの前にアニメーション機能を触ってみるべきかもしれない。