Unityアクションゲーム制作記 その35 ランダムダンジョンの生成に挑戦してみた
おかげさまで、なぜかGoogleのノンストップACTゲームカテゴリにフィーチャーされ、DL数が予想を超えてすごい順調に伸びている「ブラック・ブラッド・ブレイカー」β版……（てか、βでフィーチャーしてもらっていいの！？）。
色々なところでクセというか、こなれてないところがあるし、まだ未実装たくさん、不親切さもたくさんあって、離脱率も凄いのですが……それでも楽しんで遊んでもらえている人がいて、感謝感激な毎日です。
プレイした皆さんからいただくフィードバックに感謝をしつつ、のほほんと細かいアイテム作ったりしながら、Fayeちゃんをかわいくするために邁進する日々。そこそこ順調に制作が進み、割と調子づいていたある日、ふと「そーいえばランダムダンジョンって本当にできないかなぁ」と一度諦めた野望が鎌首をもたげてきたのです。
以前は、ちゃんとゲームとして楽しめるものができる自信がなかったので、「ぼくの将来の夢」レベルで放置していたのですが、なにを思ったのか「できるんじゃね？ いや、いまやっときべきじゃね？」と出所不明の自信が突然出てきたのです……。
まぁ結果としては、予想よりも実装に時間は取られましたが、ランダム要素があるダンジョンはできました。
別ワールドにせず、「迷宮」シリーズとして各ワールドの中に点在させるように設定。
部屋・フィールドの大きさを固定にしたシンプルダンジョンです。部屋に登場する敵の種類・最後に出てくるボスはランダムです。申し訳程度に宝箱を散らすようにもしました。
まずは簡単なものから、と一通り実装してみて思ったのが「まるっきりの無駄ではないけど、ゲームとして楽しめるものにするには、もの凄いテコ入れが必要」ということがわかりました。
問題１・やっぱり単純なマップ構成になる
全体の大きさは固定でもいいのですが、その中にある部屋の大きさなども固定にしてしまうと、作られるマップにすぐ飽きてしまいます。作った人間としては、こんな形にもなるんだ～と面白いのですが、遊ぶ立場からみると、ゲームの面白さにはほぼ関係ない要素ですからね。
問題２・ドキドキ、ワクワクが少ない
部屋に入ったら、適当な種類の敵が出てくるだけ。そこそこ強い奴が連続で出てくると、ドキドキしないこともないですが、部屋に入ったときのドキドキ感がほぼないのが現状です。マップ自体のギミックもないので、危機を感じるようなドキドキ感、マップをクリアしたときのワクワク感がないのは問題だよなーと痛感しました。
問題３・繰り返しプレイに耐えられない
各所に散らした宝箱は、毎回入手できるので、小物アイテムを入手するという目的で迷宮に挑戦する意味がなくはないです。しかし、これだけでは、繰り返し挑戦する動機としては非常に弱いのは間違いありません。そこで、今回の迷宮には、装備アイテムを入手するためのイベントアイテム「小さい羽根β」を5枚集めるという挑戦するための目的を与えてみました。
結局、最初は5枚必要にしていた羽根の数を3枚に引き下げましたけどね。理由は簡単、「だってつまんないんだもん……」。マップの生成を見守るために繰り返し遊んでいた時には、へー面白いなぁと何も考えずに繰り返し遊んでいました。しかし、必要枚数を集めるために繰り返し挑戦しなければならない、となったとたんに「作業感」を覚え、それに耐えられなかったのです。最終的には、最短で２回、おそらく5回も挑戦すればクリアできるだろうという数値の3枚に設定したのです。
問題１・２を解消し、ダンジョンを進めていく面白さが、作業感のつまらなさを上回らないとだめなのね……よくわかりました。ちょっとへこんだけど、これをベースに面白さを乗っけていけばいいだけだ！ と開き直ってランダムダンジョンに関しては、練り直します。
実装の話
今回、ランダムダンジョンを実装するにあたってGoogle先生に聞いて、最も参考にしたのがここでした↓
wise9 › ダンジョンマップを生成するアルゴリズムの解説[投稿記事]
正直、ランダムダンジョンを作ろうとするなら、このリンクを参考にして、その通りに実装したほうがいいです。今回自分が行ったアプローチは、こんなことをやっているバカがいる程度のやり方、わざわざ書いたのは自分への忘備録ということで……。
さて、もともと本ゲームのマップデータ自体はCSVで管理していて、そのテキストをもとに地形パーツをシーン上に配置しています。
フロア情報には、床と部屋のマーク。
マップオブジェクト情報には、扉や宝箱、ポータルに障害物といったオブジェクト情報が書かれています。わざわざ分けたのは、一緒くたにするとなんかごちゃごちゃになって自分で管理できそうになかったため、メモリの無駄とわかりつつも２つに分けました。
基本的には、これらの情報をプログラムで作ってやれば、ゲーム中に思うがままのマップを作ることができるようになっています。
できる限り単純に軽く実装したかったので、部屋のサイズに関しては固定にして、大きさもそこそこに。前提条件を端折ってなるべく簡単に簡単に……。
・部屋１、交差点１枠とした４ｘ４のブロックを持つエリアを用意
・ブロックの間には接続用の通路を入れる。
ブロック・接続用通路・ブロック……のようにサンドイッチにする
・部屋の大きさ・通路区画の大きさは固定
・入り口は１、出口は１
・部屋どうしは必ずつながっている
基本方針は上記のような感じです。
処理の流れ
んで、実際にどうしていったかというと。
１）ランダムに部屋を決定
エリア中のブロックから部屋にするものを決めます（4～8個）。
空いているブロックは、交差点として機能させます。
ちなみに各ブロックには、４方向にそれぞれつながっている道や部屋があるかの情報を持たせます。交差点でつながっているブロックがなければブランク（なにもない）ブロックとして処理します。
２）部屋どうしを通路でつなげる
左上からサーチしていき、部屋を見つけたらその部屋を基準に８方向調べて、調べた先に部屋があれば、部屋どうしを道でつなげます。
３）孤立した部屋の処理
どこにもつながっていない部屋があったら、問答無用で近い交差点か部屋を、孤立した部屋とつなげます。
４）出入口を作って完成！
最後に部屋でも交差点でもないブロックに出入口を作って完成。
部屋でも交差点でもないブロックがなかった場合（通路と部屋で全部埋まることもあり）は、交差点に出入口を設置すればOK。
ちなみに、行き止まりも作るようにすると迷路っぽくなる……らしいですが、今回は手間がかかりそうなので端折りました！ ちょっと手を抜きすぎで、自動生成ダンジョンなめんなよ？ と言われそうですが、もーひと工夫入れれば多少は面白くなるはず。
追記：部屋の数しだいで、出入口が生き別れる事態になることが発覚。最終的には、生成後に出入口がちゃんと繋がっているかを確認して、もしもつながっていないときには、無理やり繋げる処理を入れました。
今後の課題としてがんばっていこう、うん。
Unityアクションゲーム制作記 その34 広告動画を視聴してもらうための導線作り
いろいろと思惑が外れたり、流行り終わりのインフルにひっかかったりして、ちょっと低空飛行な進捗の中、なんとか広告関係の処理がまとまりました。ゲームをプレイする立場からすると、基本的に広告は嫌いですし、なければないほうがいい派の人間ですけど。
しかし、基本無料は最初から決めていたことなので、収益を上げるためにも広告は必須。「ブラック・ブラッド・ブレイカー」にも、何らかの形で広告を導入せざるを得ません。そこで、導入にあたっては、Unity Ads meet upなどのセミナーで学んだことや、いろいろな人のアドバイスをもとに、以下の３つを基本方針としてゲームへ組み込むことにしました。
- ゲームプレイのじゃまをしない。
- あくまでゲームプレイを手助けするものとする。
- 広告視聴は、プレイヤーが能動的に行う。
要は「広告を視聴しなくてもゲームは楽しめるけど、視聴することで、もっと快適にゲームを楽しめる」ようにするということです。
結論から言うと、「ブラック・ブラッド・ブレイカー」では、下の図のようなタイミングで広告への誘導ボタンを入れるようにしました。
以下、どのような思惑でゲームの流れと広告をまとめていったのか、紹介していきます。
どこで広告視聴をさせるか？
まずは、どこでプレイヤーに広告を視聴させるか。「ブラック・ブラッド・ブレイカー」でのゲームのループは以下の図の通りです。
特にゲームの中心となるダンジョンでの戦闘とアイテム収集に、それぞれうまく広告を絡められるのがよさげです。プレイヤーの強化は、アイテムによるところが大きいので、ここの要素に絡めることはひとまずパスしておきました。
ダンジョンで広告を視聴してもらうタイミングは？
ダンジョン内の戦闘において、プレイヤーの邪魔とならない、もしくは自発的に広告視聴をしたいと思わせるタイミングとして、すぐに思いつくのは、ゲームオーバー時のコンティニューです。しかし、コンティニューさせることが目的のデザインになってしまっては、ユーザーのストレスを溜めるだけ。なので、あくまでコンティニューアイテムがなくなったときの救済手段として用意しました。
次に広告を入れるタイミングとして思いついたのが、雑魚との戦闘を終え、ダインジョン最奥に待ち構えるボスに挑戦する直前です。「ボス戦だけどアイテム足りてる？」とプレイヤーを煽るセリフをはかせつつ、お助けキャラを出現させるようにしました。ダンジョン内に散らすことも考えましたが、お助けキャラを探すことを目的とすることは避けたかったので、ボス戦直前のみにランダムで出現するようにしてあります。
他にも、ダンジョンクリアタイプのゲームなので、広告視聴をすることでコイン入手＞新たなダンジョンへの挑戦権を得るという流れも考えました。しかし、広告を視聴しないと新たなプレイ体験ができないのはなんとなく嫌かも、ということでひとまず保留です。
アイテム収集に広告視聴を絡めるには？
次にアイテム収集との絡み。簡単なのは、宝箱からアイテムを入手するときに広告を視聴すると良いアイテムが手に入ったり、個数が増えたりする仕組みです。他にやりようもないかな、ということで、これを基本方針にしました。あとは、どのタイミングで広告を視聴してもらうかです。
「ブラック・ブラッド・ブレイカー」でアイテムを入手するタイミングは、いまのところ、ダンジョン内にある宝箱を開ける、ボス戦後の報酬として獲得する、実績して解除してもらう、この３つだけ。報酬が固定されている実績解除のタイミングは、真っ先に除外。ダンジョン内の宝箱は、意外に多く設置してあり、ここに広告視聴への導線を入れてしまうと、いちいち広告を視聴しないとダメと思われそうなので、これも除外しました。そうなると、残りはボス戦後の報酬。ここに手を入れて、なんとか広告へ誘導しないといけません。
ちなみにボス戦後に入手できるアイテムは、バトル評価に応じて最大８個のアイテムを獲得できるという、とってもシンプルなシステムでした。シンプルゆえに、報酬の個数の追加が難しく、広告を視聴してもらったときの報酬としては、獲得確率アップくらいしか組み込めない状況……。
そこで、欲しいアイテムを入手するためには、広告を視聴してもいい、広告の視聴も厭わないようにしたくて、少々手間取りましたが、プレイヤーにボス戦後の報酬を選ばせる仕組みに変更しました。流れは以下の通り。
- 報酬のアイテムが入っている宝箱は、常に8個用意。
- 中に入っているアイテムは、バトル評価によって変動。
- バトル評価によって、宝箱を開けられる個数は変動（最低評価なら１個、最高評価なら５個）。
そして、広告を視聴すると、開けられる個数を増やせたり、宝箱の中身を確認してから獲得したいアイテムを選ぶことができるようにしたのです。より多くの宝箱を開けたい、はずれを引きたくないのであれば、広告を視聴してもらうという流れですね。
ホームメニューから広告視聴への導線を用意
広告導入方法に悩んでいて、いろいろな人に相談に乗ってもらった時に受けたアドバイスとして、アプリ起動直後のホームメニューに、ゲームをプレイしたくなるような導線を用意したほうがいいというものがありました。アプリを立ち上げたときにいいことがあれば、広告視聴の回数も稼げるし、アプリ自体の継続率も上がる可能性が高いというもの。そこで新たに、ホームメニューにブーストチャンスシステムを用意しました。その中身は、バトル評価が必ずAランク以上になるものと、ボス戦後のアイテム獲得確率が２倍になるのものです。
「ブラック・ブラッド・ブレイカー」では、バトル評価が上がる＝良いアイテムが手に入る可能性が高くなるシステムとなっています。ブーストチャンスを受けることで、短時間のプレイで高評価を受けられ、アイテムも集めやすくなるという具合です。基本的に、じっくりがっつり遊ぶアプリなのですが、このシステムによって、アプリを立ち上げて、ちゃちゃっとアイテムを集めて終わるといったこともできるようになりました。ちなみにボス戦後のアイテム獲得確率が２倍も実装してみたのですが、実装してこのブログを更新している最中に「これってバトル評価アップとある意味同じ効果なのでなのでは？」と気づき、ちょっと別の効果に変更していきたいと思います。
次のアップデートは、この広告系の変更と、アイテムドロップテーブルの調整＆変更がすんでからかな。相も変わらずの迷走っぷりで、どこがゴールか見失いかけてなくもないですが、今後もがんばって進んでいこう。うん。
Unityアクションゲーム制作記 その33 オマケのアイテムプレゼントキャラの出現率
珍しく短めの期間での更新。しかもゲーム本編の話（！）です。
今回のゲームでは、基本無料＋広告（Unity Adsのみ）＋課金アイテム（計画中）の良くあるモバイルアプリのマネタイズを予定しています。広告を見せる場所は、いまのところゲームオーバー時のコンティニュー（コンティニューアイテムを所持していない場合のみ）と、アイテムを欲しいと思わせるボス前の2箇所と、ここは入れた方がいい、というアドバイスをもらった場所の3箇所に入れる予定です。
コンティニュー時は、判定するアイテムの所持によって出現するのでいいとして、悩んだのはボス前のお助けキャラの出現率です。確実に出してしまうとありがたみがないし、かといって純粋な確率だけではコントロールができずにイライラしそう。
万枚神様のプレミアムゴッドを引いたこともあるけど、確変継続率80％のモードに入って喜んだら単発を引き当てて大負けしたこともある人間としては（わかる人だけわかってください）、純粋な確率判定はあんまり信じたくないところ。出現して欲しい時にはそこにいて、なおかつ程よく出現しないような落としどころはないか、試行錯誤してました。
とはいえ、いくら信用ならんといっても、判定自体は確率で行うしかありません。問題は、変動させる要素をどこにするかです。
結果から言うと、以下の3つの要素を加味して出現確率を設定するようにしています。
- 前回出現した時間との差
- 回復アイテムの個数
- エリアクリア回数
１）前回出現した時間との差
まず、天井を用意しました。これは確率の偏りによる出現頻度をならすためです。ニューペガサスのような差枚数（誰もわからねーよ）のように、お助けキャラの出現呼び出された時間が、前回から長くなればなるほど確率を上げていき、一定時間を超えた時に100％出現させるってやつです。これで、延々とお助けキャラの出現がないという事態は避けられます。
２）回復アイテムの個数
お助けキャラからもらえるのは、回復ポーションを中心としたものなので、アイテム個数のチェックも行いました。直接的ですが、所持数が少なければ確率をアップし、多ければダウンさせます。
３）エリアクリア回数
ゲームっぽい味付け、かつそれほど複雑な判定が不要な要素が、コレ。今回のゲームでお助けキャラは、必ずボス前に置いているので、一度そこまで移動した後であれば、ゲーム離脱と再開を繰り返すことでアイテム収集ができます（お助けキャラが出現してくれれば）。それはそれでいいのですが、ちゃんと最初のエリアからゲームを進めてくれたプレイヤーとの差別化をしたいなーと思っていました。その差別化に一番簡単に利用できそうな数値が、ボス前までに移動したエリアの数でした。
敵と戦って 経験値を稼ぎながら進めていけば、ボス前で回復アイテムがもらえるお助けキャラがいてくれる、出現のロジックがわかったとしても、まあ悪くないかなと。
これで万全！ といいたいところですが、しょせん確率は確率。イラッとすることもあります。それでも、我慢できないほどではないかな？ という調整になっているはずです。
次は、クリア後報酬と広告を結びつけるための方策をもう少し練り上げるのと、武器・アーマー以外のオプション装備をどうやったらうまく追加できるかの見直しをしていく予定。いろいろとやることがありすぎて何から手を付けたらいいのかわからなくなりつつありますが、とりあえずここから手を付けます（実際にやるかどうかいつものごとく怪しいけど）。がんばろっと、うん。
「Unity道場 初心者のためのゲームデザインワークショップ」に行ってきました！
「ブラック・ブラッド・ブレイカー」をβ公開して腑抜け状態になって一週間……。気分転換もかねて「Unity道場 初心者のためのゲームデザインワークショップ」に行ってきました！
「ワンダと巨像」などの作品に関わった簗瀬氏の指導のもと、４人でのグループワークで、それぞれがおススメしたいゲームを分析して、そのポイントを簡潔にアピールしたり、10分ほどの短い時間でゲームの企画を考えるといった内容。
現在「ブラック・ブラッド・ブレイカー」では、システムとして目指すものはある程度できてきました。しかし、ここのところ、ゲームとしての面白さをどう盛り込んでいけばいいのかまとまらない＆それをアピールすることができていないという悩みを、ずっと抱えたままでした。
そんな状態で、ちょっと基本に立ち返ってみたくて参加したワークショップ。結果としては、改めてゲームを作るときには、どういうことを考えていけばいいのかを再認識できたので、期待通りの収穫を得られたと言えます。
個人的に納得したことをざっくりまとめてみます。
まず、ゲームの企画を考える・プレゼンなどをするときには、以下の層に分けて考えるといいというもの。
１）ゲームのテーマはなにか？
２）プレイヤーができる行動
３）ゲームのメカニクス
４）どんな物語・シナリオがあるか
ゲームのシステムから説明するのではなく、大きな概要をまず伝えるようにするのが大切だという。そのあとにプレイヤー（ゲームを遊ぶ人）がどんなことができるのか、ゲームの細かいシステムのメカニクス、シナリオと続けていくといいらしい。
そして、それぞれが別の要素と分けて考えるのではなく、ゲームのテーマがプレイヤーの行動につながるし、メカニクスもプレイヤーの行動に密接に関わるため。 また、テーマと行動が一致していることが重要とのこと。ここが一致していないと、遊ぼうとしたゲームがプレイヤーに理解されないことになりかねないという。
あと、ゲームを遊ぼうと思っている人がどのようなプロセスで、ゲームを手に取るかという流れも面白かった。
１）聞いておもしろい
２）見て面白い
３）触っておもしろい
４）続けておもしろい
当たり前と言えば当たり前な話ですが、この当たり前の話すら失念したまま作り続けてたんだなぁ。「ブラック・ブラッド・ブレイカー」では、３）の触って面白い部分のみ考えていたので、そりゃほかの人にゲームの魅力を伝える言葉がないはずだと反省。
以上、適当なメモ書きとうろ覚えの記憶なので、ちょっと勘違いしているところもあるかもしれませんが、多分使ったスライドはどこかにアップされるでしょう（いずれ公開されるはず）。
会場では、簗瀬氏の関わったプロジェクトのちょとした裏話なども聞けたりして、非常に楽しく有益な時間を過ごせました。
現在鋭意制作中の「ブラック・ブラッド・ブレイカー」、さすがに最後の仕上げをするのに、これまで通りの成り行き制作だとゲームが崩壊しそうなので、今回得られたことを踏まえて、ちょっとだけ時間を使って企画の練り直しをしていこうと思います。
最後に、β版に限らずDLして遊んでくれてた人々には感謝のことばもありませぬ。もっといい体験をしてもらえるようにがんばるぞ！ うん。
Fur～～～～～～～で遊んだ話♪
「ブラック・ブラッド・ブレイカー」の制作も佳境の中、今回はtwitterで流れてきたお遊びに乗っかってみました。
いつもお世話になっているUnityアセットストアの企画であることと、Furアセットはちょっと気にしていたこともあり、投げられた餌にぱくりと食いつきました。
モデルはおなじみのFayeちゃん。んで、Furアセットの使い方はシンプルそのもの。ベースのテクスチャ、もじゃもじゃの長さを決めるHightmap、風っぽい動きを決めるWindmapなどを設定して、シェーダーを設定した適当なマテリアルにパラメータをつけてモデルにセットするだけ。
すると……
ボンバー！
見事なボンバーヘアになりました！
……どうやらモデルが小さいせいか、Heightのパラメータをかなり小さくしないとダメっぽいので、ちょいちょいっと調整してみるとこんな感じに。Fur……っぽい？ 面に対して垂直なとげとげを出すだけのようなので、こういった細かいキャラモデルには向かないのかなあと思いつつも、肝心の耳部分がやけにネムイ。
なんだろーなーと思いめぐらせて気づいたのが、ネコミミに割り当てられているテクスチャが小さいことでした。
ほかの服のテクスチャの隙間に無理やり突っ込んだので、耳部分に使われているテクスチャが小っちゃいので、ネコミミのみにUVを展開し、テクスチャを合わせました。
これで無事、耳ももふもふっとした感じになったかな。Windmapの使い方はこれからやってみないとですが、クオリティ的には「まぁこんなもん？」というところですかね（Hightmapの作り方でも変わりそうですけど）。
モバイルで使えればよかったのですが、どうやら非対応のようだし、かといって、このままだとPCで使うにはちょっと微妙だよねーな絵……ポストプロセスをかけると多少変わるかなー。
重くはなさそうなのはいいですけどね。HeightmapとWindmapを自前で書けばカスタマイズもできるので、知恵と勇気でもふもふできる！ かもしれませんね。うん。
UnityのPost Processing Stackを使ったらApkサイズが11.3Mb増えた話
地味～にシステム内部を更新したり、アイテムバランスの調整したりと目に見えた進歩のない昨今、無計画に処理を適当に実装しているため、日々動作が重くなるアプリにちょっとだけブルーになりつつ作業を進めていました。同時に動作だけでなく、色々ぶっ込みすぎてアプリの肥大化が止まらないなぁとも思っていたのですが、ふとApkファイルを見てみるとサイズが90Mバイトを超えている！ この間まで70だか80Mバイトだった気がするので、おかしーなーとビルド後にログを確認してみると……
なんかでかいのが居座ってる！（NotoSansさんは了承済み）
パッと見て、Post Processing Stackで使ってるシェーダーだよね、というのは分かるのですが、ここまで大きな理由がわからない。スマホでPost Processing Stackなんか使うなよーという話もなきにしもあらずですが、iPhone6sなら、アンチエリアスにブルームとブラーをONにしてもゲームは動くので、動く機種を持っている人は、オプションで切り替えられるようにはしておきたいものです。
つーことで単にPost Processing Stackを外すのではなく、どうにかサイズを小さくできる方法がないものだろうかと、Google先生に聞いてみました。
ありました。
要は、Uber Shader内の#program～の部分で、使わないものをコメントアウトしちゃえば、サイズ小っちゃくなるよ！ ということなので……
BLOOM以外の場所を、バッサリとコメントアウト。
これで無事、11MちょっとがApkから去りました。一応問題なく動いているようですが、本当に無事なのかどうかはこれから気を付けておかないといけませんけどね。ひとまず、危機は去った！
あと、この解決方法以外にUnityのフォーラムで「V2にするとResorcesフォルダを使わなくなっているから解決しているよ！うんぬん」のようなことも見つけたのですが、V2ってなんだろう？（※Post Processing Stack V2について下に追記しましたー） アセットストアから再インストールしようとしても更新されない……ので、ひとまずシェーダーの中身を書き換える方法で対処しました。
ということで、何か問題が起きて戻すときに困るので、忘備録として残しておきました（戻す方法を確実に忘れる）。リリースまであと少し、あと少しなんだよなぁ……がんばろ、うん。
＞追記
コガネブロクでおなじみの@baba_s_様からメッセージをいただき（ブログ見てます！ いつもお世話になっています！）、Post Processing Stack V2を教えていただいたので、ちょっとだけ試してみました。まだβ段階のようですが、オブジェクト単位でエフェクト掛けられるようになっていたりだとかするみたい（Google翻訳で読んだ限り）で、すごい人が使うとすごいことができそうだなぁと、頭の悪い感想を抱きつつ、インストール。使い方がV1とちょっと変わってて戸惑いましたが、クイックスタートガイドに丁寧に書いてあったので、Google翻訳様の力を借りてお試し！ んで、結果！
●Post Processing Stack V1（そのまま使用）
●Post Processing Stack V2（BLOOMのみ使用）
●Post Processing Stack V1（Uber Shderを書き換えて、BLOOMのみ使用）
……減ってはいるけど、V1に比べて中途半端というか、こんなもん？ 使い方も正しいのかどうかも怪しいので、とりあえず、まだβなV2はいったん保留にして、V1に戻すことにしました。サイズだけでなく実行速度もちゃんと検証しなきゃいけないしね。
てか、なんで私は本番プロジェクトでこんな検証やってんだろ……と、すべて終わってから気づく馬鹿。ま、動いてるからいいや。
Unityアクションゲーム制作記 その32 ゲーム起動からチュートリアルの流れ
いまさらですが、ようやくゲーム起動からチュートリアルまでの流れが、ほぼ確定しました。すでに前半部分はできていて「残りはどうとでもなるだろう」と、後回しにしていただけなんですけどね。最終的に決まった全体の流れは下の通りです（下から上に流れているのでちょっと見づらいですが）。
丁寧にやるとどこまでも手間がかかるチュートリアルですが、今回やりたかったことは以下の３つでした。
1.ゲーム初起動＞チュートリアル開始
タイトルとかメニューとかの余計なことは一切経由せずに、アプリ初回起動後、即チュートリアルへという流れを考えていました。ですが、最終的にチュートリアルそのものをやりたくないプレイヤーのために、チュートリアル選択メニュー＞操作説明開始という流れに修正。
2.最短手順で実戦投入
ゲームとしての魅力、特にバトルの楽しさを可能な限り早くプレイヤーに体験してほしかったため、必要最低限の「移動」「攻撃」を教えたら、ボスクラスの敵とのイベントバトルを用意しました。イベントバトルとはいえ、ゲームオーバーありの通常戦闘です。
プレイヤーの死亡ナシ、もしくは、プレイヤーor敵が死亡したら勝手に進むというパターンも考えたのですが、緊張感がないし、わざわざ戦ったのに意味なしかよ、と思われるのも気持ち悪かったので、死んだらきっちりゲームオーバーにしました。
3.いつでもチュートリアルを終了できる
チュートリアルは、各部屋に入ると自動で説明が始まり、説明通りの操作ができると次へ進めるようになっています。説明を受けている時以外はプレイヤーが操作できるので、「かったるいなぁ」と思ったら、ポーズメニューから「ステージ終了」を選べば、いつでもチュートリアルを終了できるようになっています。イベントバトル後にも、続けるか、終わるかの選択ができるように移動ポータルを複数用意したりしています。ただ、次へ続く移動ポータルの前に宝箱を置いたりして、さりげなく「続けていくといいことあるよ？」と思わせるように誘導してありますけどね。
こんな感じでチュートリアルが終わると、一息入れてもらうために晴れてオープニングシーンへ。じっくり鑑賞してもいいし、スキップしてもOK。なんとか、可能な限りストレスなくゲーム本編への流れができたかなぁと。
しかし、冒頭で行ったチュートリアルは、操作説明のみの簡単なもので、バトルの仕方やらゲームの流れの説明も適宜行っていかないといけません。プレイしながら、イイ感じのタイミングでゲームルールの説明を入れていかなきゃいけないのですが……ま、そのうち思いつくだろうということで、粛々と実装作業を進めていきます。うん、がんばろ。
