「DefenceAndKnight」開発振り返り記_5

第5回となりました！今回も敵についてです。

DefenceAndKnightの近接敵の作成

初めての近接敵を作成した

これまでは射撃型敵キャラクターばかり作成してきたので、正真正銘の初近接型敵キャラクターです。モデルはアセットを使用していますが、AIはしっかり取り組みました。

プレイヤーの攻撃に対して全く怯むことがない強すぎる体幹

怯み機能を導入せずに戦った結果、プレイヤーの攻撃に対して無慈悲にゴリ押しで突っ込んでくる敵になりました。あまりにも体幹が強すぎたので、怯み機能を追加してプレイヤーが攻撃を当てる度に怯むようにしてみました。そうすると、攻撃連打で怯ませ続ければ必ず勝てるようになりました。
極端すぎる！！

攻撃回数に応じて怯み値を蓄積するようにし、怯み値の回復機能を入れることで、極端なバランスにならないように調節可能にしました。
今回の開発の中で得た知識の中でも特に良さげ!!

防御する敵AI

このモデルは盾を持っているので、防御行動が欲しいですね。待機状態でいるときにプレイヤーが攻撃し始めると防御行動を取るようにしました！

プレイヤーの防御システム

今回、防御について語ったのでプレイヤーの防御システムについても解説！
攻撃のタイミングピッタリに防御できれば、完全にダメージを受け流すことができます！！タイミングがずれてもダメージは軽減できるので、敵の攻撃に合わせて防御することがクリアにつながります！
うまく攻撃と防御のタイミングを見極めるとノーダメージクリアできるかも！

ゲームらしくなってきた

ゲームに必要な駆け引きがようやく作れたので、ここでタイトル決めをすることにしました。「DefenceAndKnight」
今回の開発では技術的に取り組みたいことがあったので、ゲームのコンセプトがかなり曖昧な状態で進めていました。開発者として満足のいくシステムを作れても、ゲームとして面白かったら本末転倒ですからね。今後は気をつけて開発していきたいと思います。

ということでここまで読んでいただき、ありがとうございました。

「DefenceAndKnight」開発振り返り記_4

第4回からは開発中期に突入です。今回はプログラム関係多めです。

DefenceAndKnightの敵AIの作成

敵のAIについて

これまではテスト用として簡単なスクリプトは作成していたのですが、ようやく本腰をいれて敵のAI作成に乗り出しました。今回の開発ではステート駆動AIで挙動を作成することにしました。ゲームでは割と利用されるAIなのではないでしょうか？
分かりやすくお伝えするために、UnityのAnimatorで表現します。
以下の画像のようにそれぞれの状態ごとに振舞いを変えるAIですね。

敵のAI実装

これまでは、プレイヤーがどんな距離にいても問答無用で攻撃してきていたのですが、一定距離内に入るまでは発見しなくなりました。また、敵に発見されても索敵範囲外に行ってしまえば、見失うなどの機能を追加することでようやく敵らしくなってきます。
待機状態、索敵状態、発見状態、攻撃状態など状態を作成して、それぞれに応じて行動させるようにするのは比較的簡単でした。敵のAI作成って楽しいね！

そんな思いを簡単に吹き飛ばしてしまうのがバグ！
アニメーション処理とAIの振舞いがずれてしまうバグが発生しました。最初は良いものの、どんどんアニメーションと攻撃処理がずれていきました。最終的には、敵が予備動作なしの「不可避の理不尽攻撃」を放ってきます。

バグ確認タイム

まずはどこがずれを起こす原因なのかの調査から始めます。状態ごとのアニメーションと振舞いを１つ１つ確認していくことから始め、原因らしき場所を発見したら検証、再度確認...。
アニメーションの開始、終了を判定する機能を使いながら検証を進めていると、一番の原因を見つけました。アニメーションブレンド君！？
Unityにはアニメーションをブレンドして、滑らかにアニメーション遷移させる機能があるのですが、それを使用した影響で遷移の際にアニメーションのずれが起こっていました。(゜_゜)
いやはや、どうにか原因を見つけられたものの、発見まで骨の折れる作業でした。

バグ修正タイム

しかし、まだ発見しただけなんです。これから修正しなければならない！！
適切にアニメーションされているかどうか、コールバックや非同期処理が状態と合致しているかどうかをクリプトとにらめっこしながら、進めていきました。
頭が過熱するのを感じながら、修正できた時の達成感はすごくいい！！

流用できそうな部分はしっかり作っておくべき！

今回の敵の根幹システムをかなり綿密に作成しました。その思惑通り、新しい敵を追加するときでも、AIシステムは流用が効き、比較的楽でした。
今後の開発でも汎用性があるシステムをガンガン設計していきたいですね～。

ということでここまで読んでいただきありがとうございました。

「DefenceAndKnight」開発振り返り記_3

第3回ですが、まだ開発初期のお話です。

DefenceAndKnightグラフィックの改善

まずは、ステージを作り始めましたが、ここでも問題が起こります。
いつも問題起きてんなこの開発

ステージ作り直し事件

3日ほどかけて、ステージも出来上がってきたので実機テストをしました。
fps(frame per seconds)や実機でのプレイ感覚の確認ですね。
その結果、平均15fpsしか出ない！！カクカクすぎて遊べないいいい！！
快適なプレイとは程遠いレベルでした。
実機テスト用のスマートフォンはGooglePixel 3aという古い世代ですが、作っているのは高負荷のゲームではないのでこのデバイスでさくさくプレイできないと話になりません。
いつもデスクトップPCのデバイスパワーで処理の負荷を気にせずに作っていた結果がこれです。使っていたアセットがバチバチのPCゲーム向けのハイポリゴンモデルだったので、それらを全とっかえとかいう地獄を見ました。
ああ、作業が振り出しに...。(@_@。）

キャラクターたち

ステージ、敵のモデルとプレイヤーのモデルを導入したことでようやく殺風景ではなくなりました。なんかファンタジーっぽい！！
軽量化のためにローポリゴンモデルを多く使用したがこちらです。

グラフィックは大変

かなり短くまとめたのですが、このグラフィック関係の作業はとにかく手探りで進めていたため、かなり時間がかかっています。
ステージデザインとかは苦手で、迷走しまくりでした。配置を考えるのも大変な作業ということが身に沁みました～！ステージデザインできる人すごいいぃ。

ということでここまで読んでいただきありがとうございました。

「DefenceAndKnight」開発振り返り記_2

第2回ということで、今回も開発初期について振り返ってみます。

DefenceAndKnight基礎システムの作成

カメラの挙動作成

開発初期は某闇魂系のゲームをプレイした影響もありまして、カメラのロックオンシステムはかなり似通ったものを作っています。
ここで想定よりも大変だったのは、ロックオン状態のカメラの挙動とそれ以外の時のカメラの挙動の切り替え処理でした。スムーズな切り替えを目指して試行錯誤していたのですが、ちょっとでも制御を間違えると、かなり酔いやすいカメラワークに...。
このカメラ切り替え処理だけで一週間は超えてしまって、本筋の開発が進まなかったので、ある程度区切りをつけました。完璧とは程遠いものの、プレイに支障のないくらいにはなったのかな～と思ってます。

防御機能の追加

ここで箱を切るだけのゲームに敵の攻撃を防御する機能を追加し始めました。ゲームのコンセプトがここでガラッと変わります。
最初に決めておけよ！って感じなんですけどね(-_-;)
防御があるだけでそれっぽい！！とテンションがあがっておりましたが、この時点では敵の攻撃判定なんてもんはありません。それどころか敵の攻撃の仕様すら決まってません。

敵の攻撃を作成

さっそく、敵の攻撃を作ることにしました。
これまで作ってきたゲームでは射撃系の敵しかいなかったため、今回も射撃系の敵を無意識に作り始めました。まあ、射撃系の敵は作りやすいですからね。
当たったらプレイヤーのHPを削る弾と弾を生成して発射するだけの簡単な敵です。
う～ん。これ戦闘の駆け引きとか存在しないよね。アクション（笑）みたいな思いがありましたが、プロトタイプなので良し！！という感じで進めました。

ここまで一か月くらいの道のり

システムはある程度できてきたものの、見た目に一切進捗がないため、パッと見て変わった部分はほとんどありません。

ということでここまで読んでいただきありがとうございました。

「DefenceAndKnight」開発振り返り記_1

第一回ということで、開発初期について振り返っていきます。

DefenceAndKnight開発のスタート

スマートフォン向けの3D戦闘アクションゲームを作りたいと思い、見切り発車で開発が始まりました。
最初はただの箱を切るだけのゲームにする予定だったので、ただの箱と剣を振るだけのプレイヤーを作りました。どんな感じだったかというと以下の画像のような何もないステージにポツンと箱があるだけでした。ゲームかこれ？

移動と攻撃、カメラ操作を実装するだけだったので、土台づくりは簡単だと高を括っていました。しかし、それを裏切るように問題が発生しまくりでした。

入力の問題

PCでは遭遇しなかった同時タップという問題やカメラ操作のための入力システムの作成など、思っていた3倍ほどの要素があり、いきなり壁にぶち当たりました。
この時点でスマートフォンの入力処理についての現実を認識しはじめましたが、頑張って実装しました。（よくやった）

当たり判定の問題

3Dゲームでありがちな問題...。特に攻撃の当たり判定で困りました。
このゲームでは当初、剣の当たり判定を見た目通りにつけていました。理由はその方が納得感出るだろうという曖昧な考えがあったからで、これが大失敗。アニメーションによって連続で攻撃が当たり続けてしまうことや、一切当たらないことが起きました。見た目通りの当たり判定だから全部OKというわけにはいかないんですね。
あと、今回はスマートフォンでプレイできるようにパフォーマンスにも気を配る必要も...ぐぇぇ...。
良作ゲームたちの当たり判定がいろいろ工夫されている理由が分かった気がします。

移動と攻撃

攻撃アニメーション中に移動や回転を行うと氷の上のようにツルツルとスライドしてしまうことがあったので、攻撃中は移動と回転に制限をかけました。
そうすると、今度は連続攻撃したときに敵がいる方向に向けない！とフラストレーションがたまる要因になったので、攻撃と攻撃の間のみ方向転換をできるように変えました。
その結果、比較的快適さを保ちつつ、違和感のない攻撃にできたと感じています。
ここの部分の実装は楽しかったです！

本当に簡単な土台づくりだったはずの初期

上記で挙げた問題は氷山の一角で、他の部分でも苦戦しまくりでした。
そもそも直感的な操作を作るっていうのは本当に難しいんですよね。遊んでいて快適なゲームは操作の部分から相当の工夫がされており、開発者さんたちの凄さを実感できました。

まとめ

スマートフォン向け3D戦闘アクションというジャンルに初挑戦かつ見切り発車で開発した結果こうなっちゃいました。この負債は開発中期、開発後期にも影響を与えることになるとはトリガモは考えていなかった...。

ということでここまで読んでいただきありがとうございました。