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

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

Unityアクションゲーム制作記 その33 オマケのアイテムプレゼントキャラの出現率

 珍しく短めの期間での更新。しかもゲーム本編の話(!)です。

f:id:hamazakifactory:20180328230754j:plain

 今回のゲームでは、基本無料+広告(Unity Adsのみ)+課金アイテム(計画中)の良くあるモバイルアプリのマネタイズを予定しています。広告を見せる場所は、いまのところゲームオーバー時のコンティニュー(コンティニューアイテムを所持していない場合のみ)と、アイテムを欲しいと思わせるボス前の2箇所と、ここは入れた方がいい、というアドバイスをもらった場所の3箇所に入れる予定です。

 コンティニュー時は、判定するアイテムの所持によって出現するのでいいとして、悩んだのはボス前のお助けキャラの出現率です。確実に出してしまうとありがたみがないし、かといって純粋な確率だけではコントロールができずにイライラしそう。

 万枚神様のプレミアムゴッドを引いたこともあるけど、確変継続率80%のモードに入って喜んだら単発を引き当てて大負けしたこともある人間としては(わかる人だけわかってください)、純粋な確率判定はあんまり信じたくないところ。出現して欲しい時にはそこにいて、なおかつ程よく出現しないような落としどころはないか、試行錯誤してました。

 とはいえ、いくら信用ならんといっても、判定自体は確率で行うしかありません。問題は、変動させる要素をどこにするかです。

 結果から言うと、以下の3つの要素を加味して出現確率を設定するようにしています。 

  1. 前回出現した時間との差
  2. 回復アイテムの個数
  3. エリアクリア回数 

1)前回出現した時間との差

 まず、天井を用意しました。これは確率の偏りによる出現頻度をならすためです。ニューペガサスのような差枚数(誰もわからねーよ)のように、お助けキャラの出現呼び出された時間が、前回から長くなればなるほど確率を上げていき、一定時間を超えた時に100%出現させるってやつです。これで、延々とお助けキャラの出現がないという事態は避けられます。

2)回復アイテムの個数

 お助けキャラからもらえるのは、回復ポーションを中心としたものなので、アイテム個数のチェックも行いました。直接的ですが、所持数が少なければ確率をアップし、多ければダウンさせます。

3)エリアクリア回数

 ゲームっぽい味付け、かつそれほど複雑な判定が不要な要素が、コレ。今回のゲームでお助けキャラは、必ずボス前に置いているので、一度そこまで移動した後であれば、ゲーム離脱と再開を繰り返すことでアイテム収集ができます(お助けキャラが出現してくれれば)。それはそれでいいのですが、ちゃんと最初のエリアからゲームを進めてくれたプレイヤーとの差別化をしたいなーと思っていました。その差別化に一番簡単に利用できそうな数値が、ボス前までに移動したエリアの数でした。

 敵と戦って 経験値を稼ぎながら進めていけば、ボス前で回復アイテムがもらえるお助けキャラがいてくれる、出現のロジックがわかったとしても、まあ悪くないかなと。

 これで万全! といいたいところですが、しょせん確率は確率。イラッとすることもあります。それでも、我慢できないほどではないかな? という調整になっているはずです。

 次は、クリア後報酬と広告を結びつけるための方策をもう少し練り上げるのと、武器・アーマー以外のオプション装備をどうやったらうまく追加できるかの見直しをしていく予定。いろいろとやることがありすぎて何から手を付けたらいいのかわからなくなりつつありますが、とりあえずここから手を付けます(実際にやるかどうかいつものごとく怪しいけど)。がんばろっと、うん。

www.hamazakifactory.com

 

「Unity道場 初心者のためのゲームデザインワークショップ」に行ってきました!

 「ブラック・ブラッド・ブレイカー」をβ公開して腑抜け状態になって一週間……。気分転換もかねて「Unity道場 初心者のためのゲームデザインワークショップ」に行ってきました!

 「ワンダと巨像」などの作品に関わった簗瀬氏の指導のもと、4人でのグループワークで、それぞれがおススメしたいゲームを分析して、そのポイントを簡潔にアピールしたり、10分ほどの短い時間でゲームの企画を考えるといった内容。

 現在「ブラック・ブラッド・ブレイカー」では、システムとして目指すものはある程度できてきました。しかし、ここのところ、ゲームとしての面白さをどう盛り込んでいけばいいのかまとまらない&それをアピールすることができていないという悩みを、ずっと抱えたままでした。

 そんな状態で、ちょっと基本に立ち返ってみたくて参加したワークショップ。結果としては、改めてゲームを作るときには、どういうことを考えていけばいいのかを再認識できたので、期待通りの収穫を得られたと言えます。

 個人的に納得したことをざっくりまとめてみます。

 まず、ゲームの企画を考える・プレゼンなどをするときには、以下の層に分けて考えるといいというもの。

1)ゲームのテーマはなにか?
2)プレイヤーができる行動
3)ゲームのメカニクス
4)どんな物語・シナリオがあるか

 ゲームのシステムから説明するのではなく、大きな概要をまず伝えるようにするのが大切だという。そのあとにプレイヤー(ゲームを遊ぶ人)がどんなことができるのか、ゲームの細かいシステムのメカニクス、シナリオと続けていくといいらしい。

 そして、それぞれが別の要素と分けて考えるのではなく、ゲームのテーマがプレイヤーの行動につながるし、メカニクスもプレイヤーの行動に密接に関わるため。 また、テーマと行動が一致していることが重要とのこと。ここが一致していないと、遊ぼうとしたゲームがプレイヤーに理解されないことになりかねないという。

 あと、ゲームを遊ぼうと思っている人がどのようなプロセスで、ゲームを手に取るかという流れも面白かった。

1)聞いておもしろい
2)見て面白い
3)触っておもしろい
4)続けておもしろい

 当たり前と言えば当たり前な話ですが、この当たり前の話すら失念したまま作り続けてたんだなぁ。「ブラック・ブラッド・ブレイカー」では、3)の触って面白い部分のみ考えていたので、そりゃほかの人にゲームの魅力を伝える言葉がないはずだと反省。

 以上、適当なメモ書きとうろ覚えの記憶なので、ちょっと勘違いしているところもあるかもしれませんが、多分使ったスライドはどこかにアップされるでしょう(いずれ公開されるはず)。

 会場では、簗瀬氏の関わったプロジェクトのちょとした裏話なども聞けたりして、非常に楽しく有益な時間を過ごせました。

 現在鋭意制作中の「ブラック・ブラッド・ブレイカー」、さすがに最後の仕上げをするのに、これまで通りの成り行き制作だとゲームが崩壊しそうなので、今回得られたことを踏まえて、ちょっとだけ時間を使って企画の練り直しをしていこうと思います。

 最後に、β版に限らずDLして遊んでくれてた人々には感謝のことばもありませぬ。もっといい体験をしてもらえるようにがんばるぞ! うん。

www.hamazakifactory.com

 

Fur~~~~~~~で遊んだ話♪

「ブラック・ブラッド・ブレイカー」の制作も佳境の中、今回はtwitterで流れてきたお遊びに乗っかってみました。

f:id:hamazakifactory:20180221184357j:plain

f:id:hamazakifactory:20180221184733j:plain

 いつもお世話になっているUnityアセットストアの企画であることと、Furアセットはちょっと気にしていたこともあり、投げられた餌にぱくりと食いつきました。

f:id:hamazakifactory:20180221184941j:plain

 モデルはおなじみのFayeちゃん。んで、Furアセットの使い方はシンプルそのもの。ベースのテクスチャ、もじゃもじゃの長さを決めるHightmap、風っぽい動きを決めるWindmapなどを設定して、シェーダーを設定した適当なマテリアルにパラメータをつけてモデルにセットするだけ。

f:id:hamazakifactory:20180221185308j:plain

すると……

f:id:hamazakifactory:20180221185528j:plain

  ボンバー!

見事なボンバーヘアになりました!

f:id:hamazakifactory:20180221185717j:plain

……どうやらモデルが小さいせいか、Heightのパラメータをかなり小さくしないとダメっぽいので、ちょいちょいっと調整してみるとこんな感じに。Fur……っぽい? 面に対して垂直なとげとげを出すだけのようなので、こういった細かいキャラモデルには向かないのかなあと思いつつも、肝心の耳部分がやけにネムイ。

 なんだろーなーと思いめぐらせて気づいたのが、ネコミミに割り当てられているテクスチャが小さいことでした。

f:id:hamazakifactory:20180221190341j:plain

f:id:hamazakifactory:20180221190516j:plain

 ほかの服のテクスチャの隙間に無理やり突っ込んだので、耳部分に使われているテクスチャが小っちゃいので、ネコミミのみにUVを展開し、テクスチャを合わせました。 

f:id:hamazakifactory:20180221190549j:plain

 これで無事、耳ももふもふっとした感じになったかな。Windmapの使い方はこれからやってみないとですが、クオリティ的には「まぁこんなもん?」というところですかね(Hightmapの作り方でも変わりそうですけど)。

 モバイルで使えればよかったのですが、どうやら非対応のようだし、かといって、このままだとPCで使うにはちょっと微妙だよねーな絵……ポストプロセスをかけると多少変わるかなー。

 重くはなさそうなのはいいですけどね。HeightmapとWindmapを自前で書けばカスタマイズもできるので、知恵と勇気でもふもふできる! かもしれませんね。うん。

UnityのPost Processing Stackを使ったらApkサイズが11.3Mb増えた話

 地味~にシステム内部を更新したり、アイテムバランスの調整したりと目に見えた進歩のない昨今、無計画に処理を適当に実装しているため、日々動作が重くなるアプリにちょっとだけブルーになりつつ作業を進めていました。同時に動作だけでなく、色々ぶっ込みすぎてアプリの肥大化が止まらないなぁとも思っていたのですが、ふとApkファイルを見てみるとサイズが90Mバイトを超えている! この間まで70だか80Mバイトだった気がするので、おかしーなーとビルド後にログを確認してみると……

f:id:hamazakifactory:20171227212557j:plain

なんかでかいのが居座ってる!(NotoSansさんは了承済み)

 パッと見て、Post Processing Stackで使ってるシェーダーだよね、というのは分かるのですが、ここまで大きな理由がわからない。スマホでPost Processing Stackなんか使うなよーという話もなきにしもあらずですが、iPhone6sなら、アンチエリアスにブルームとブラーをONにしてもゲームは動くので、動く機種を持っている人は、オプションで切り替えられるようにはしておきたいものです。

 つーことで単にPost Processing Stackを外すのではなく、どうにかサイズを小さくできる方法がないものだろうかと、Google先生に聞いてみました。

github.com

 ありました。

 要は、Uber Shader内の#program~の部分で、使わないものをコメントアウトしちゃえば、サイズ小っちゃくなるよ! ということなので……

f:id:hamazakifactory:20171227213654j:plain

BLOOM以外の場所を、バッサリとコメントアウト

f:id:hamazakifactory:20171227213520j:plain

f:id:hamazakifactory:20171228114955j:plain

 これで無事、11MちょっとがApkから去りました。一応問題なく動いているようですが、本当に無事なのかどうかはこれから気を付けておかないといけませんけどね。ひとまず、危機は去った!

 あと、この解決方法以外にUnityのフォーラムで「V2にするとResorcesフォルダを使わなくなっているから解決しているよ!うんぬん」のようなことも見つけたのですが、V2ってなんだろう?(※Post Processing Stack V2について下に追記しましたー) アセットストアから再インストールしようとしても更新されない……ので、ひとまずシェーダーの中身を書き換える方法で対処しました。

 ということで、何か問題が起きて戻すときに困るので、忘備録として残しておきました(戻す方法を確実に忘れる)。リリースまであと少し、あと少しなんだよなぁ……がんばろ、うん。

>追記

 コガネブロクでおなじみの@baba_s_様からメッセージをいただき(ブログ見てます! いつもお世話になっています!)、Post Processing Stack V2を教えていただいたので、ちょっとだけ試してみました。まだβ段階のようですが、オブジェクト単位でエフェクト掛けられるようになっていたりだとかするみたい(Google翻訳で読んだ限り)で、すごい人が使うとすごいことができそうだなぁと、頭の悪い感想を抱きつつ、インストール。使い方がV1とちょっと変わってて戸惑いましたが、クイックスタートガイドに丁寧に書いてあったので、Google翻訳様の力を借りてお試し! んで、結果!

●Post Processing Stack V1(そのまま使用)

f:id:hamazakifactory:20171228120001j:plain

●Post Processing Stack V2(BLOOMのみ使用)

f:id:hamazakifactory:20171228120052j:plain

●Post Processing Stack V1(Uber Shderを書き換えて、BLOOMのみ使用)

f:id:hamazakifactory:20171228120114j:plain

……減ってはいるけど、V1に比べて中途半端というか、こんなもん? 使い方も正しいのかどうかも怪しいので、とりあえず、まだβなV2はいったん保留にして、V1に戻すことにしました。サイズだけでなく実行速度もちゃんと検証しなきゃいけないしね。

 てか、なんで私は本番プロジェクトでこんな検証やってんだろ……と、すべて終わってから気づく馬鹿。ま、動いてるからいいや。

Unityアクションゲーム制作記 その32 ゲーム起動からチュートリアルの流れ

 いまさらですが、ようやくゲーム起動からチュートリアルまでの流れが、ほぼ確定しました。すでに前半部分はできていて「残りはどうとでもなるだろう」と、後回しにしていただけなんですけどね。最終的に決まった全体の流れは下の通りです(下から上に流れているのでちょっと見づらいですが)。

f:id:hamazakifactory:20171123182358j:plain

 丁寧にやるとどこまでも手間がかかるチュートリアルですが、今回やりたかったことは以下の3つでした。

1.ゲーム初起動>チュートリアル開始

 タイトルとかメニューとかの余計なことは一切経由せずに、アプリ初回起動後、即チュートリアルへという流れを考えていました。ですが、最終的にチュートリアルそのものをやりたくないプレイヤーのために、チュートリアル選択メニュー>操作説明開始という流れに修正。

2.最短手順で実戦投入

 ゲームとしての魅力、特にバトルの楽しさを可能な限り早くプレイヤーに体験してほしかったため、必要最低限の「移動」「攻撃」を教えたら、ボスクラスの敵とのイベントバトルを用意しました。イベントバトルとはいえ、ゲームオーバーありの通常戦闘です。

 プレイヤーの死亡ナシ、もしくは、プレイヤーor敵が死亡したら勝手に進むというパターンも考えたのですが、緊張感がないし、わざわざ戦ったのに意味なしかよ、と思われるのも気持ち悪かったので、死んだらきっちりゲームオーバーにしました。

3.いつでもチュートリアルを終了できる

 チュートリアルは、各部屋に入ると自動で説明が始まり、説明通りの操作ができると次へ進めるようになっています。説明を受けている時以外はプレイヤーが操作できるので、「かったるいなぁ」と思ったら、ポーズメニューから「ステージ終了」を選べば、いつでもチュートリアルを終了できるようになっています。イベントバトル後にも、続けるか、終わるかの選択ができるように移動ポータルを複数用意したりしています。ただ、次へ続く移動ポータルの前に宝箱を置いたりして、さりげなく「続けていくといいことあるよ?」と思わせるように誘導してありますけどね。

 こんな感じでチュートリアルが終わると、一息入れてもらうために晴れてオープニングシーンへ。じっくり鑑賞してもいいし、スキップしてもOK。なんとか、可能な限りストレスなくゲーム本編への流れができたかなぁと。

 しかし、冒頭で行ったチュートリアルは、操作説明のみの簡単なもので、バトルの仕方やらゲームの流れの説明も適宜行っていかないといけません。プレイしながら、イイ感じのタイミングでゲームルールの説明を入れていかなきゃいけないのですが……ま、そのうち思いつくだろうということで、粛々と実装作業を進めていきます。うん、がんばろ。

 

 

 

 

 

Unityアクションゲーム制作記 その31 unityroomアセットキャンペーンへの応募&デジゲー博へ出展してきました!

f:id:hamazakifactory:20171115141011j:plain

BLACK BLOOD BREAKER ver.0 | 無料ゲーム投稿サイト unityroom - Unityのゲームをアップロードして公開しよう

 デジゲー博後、思いっきり体調を崩し、ようやく復帰しつつ状態でぽちぽちと久しぶりのブログ更新です。今回も体験版の公開でお世話になったunityroomで、使用したアセットを登録するとバウチャーがもらえる豪気なキャンペーンをやっていることを思い出し、一通り使用しているアセットを登録してみました。雑感ですがアセットを使ってみた時のコメントも入れておきました(購入アセットをどうゲームへ実装したかは、いずれブログネタの1つとしてやりたいなぁ)。

 今回のゲームを作るにあたって、多数のアセットを購入しているわけですが、闇雲にあれもこれも手当たり次第に購入したわけではありません。心がけたのは、ゲーム内でどう使う? これは本当に必要なアセットなのか? を具体的にイメージすることでした。やはり具体的なイメージを持っていないと、購入したっきり使わないとか、アセットの数は多いけどほとんど使わなくて無駄ばかりとなりかねませんからね。

デジゲー博の反省

 さて、もう1ネタの11/12に行われたデジゲー博です。これまで参加した試遊会やイベントとは、比べ物にならないくらいの人と熱気に圧倒されてきました。結論から言えば、「楽しかった。参加してよかった。来年も出したい!」と大満足の結果だったといえます。

 特に21インチのディスプレイを使ってのデモは効果的だったかなぁと。デモを遊んでいる人がいる間も、後ろで足を止めて画面を見ている人がそこそこいたし、垂れ流しのオープニングも目立つた形になったしで、いいことづくめ(帰りの荷物が多くなった以外は…)。手間をかけてPC版をわざわざビルドしたかいがありました。

f:id:hamazakifactory:20171115153320j:plain

 問題があったとすれば、展示スペースが意外に狭かった点ですね。今回1枠(机の1/2スペース)で参加したのですが、これが微妙な広さでした。モニタを置いた残りのスペースにノートPCと試遊できるスマホ×2を置いたのですが、かなりキツキツ。一人試遊しているだけでも余裕はあまりなく、横に2人並ぶとスペースギリギリな状態でした。せっかく遊べるものを用意しても、手に取ってもらう機会を逸していたなぁという感じでした。

 あと、配布物はもったいないことをしたと反省。今回用意したのは、余り物のチラシとネームカードだったのですが、チラシは前回の使いまわしだし、ネームカードはただの名刺だしで、せっかく体験版を置いたunityroomへの導線もなく、ただの紙切れを配っていたも同然でしたね。もったいなかった……。

 多少問題があったにせよ、わざわざスペースを訪ねてくれた人には感謝しかありませんし、たくさんの人に触ってもらえて、しかも感想をいただけたりもして大満足、制作のモチベーションをたくさんいただきました。リリースまであと少し(多分)、頑張るしかない! 

Unityアクションゲーム制作記 その30 デジゲー博Ver ボスラッシュ!

youtu.be

 今回の映像は、Unityエディタからキャプチャしたデジゲー博Verのお試しステージの1つです。以前あったボスラッシュのド派手バージョンって感じです。まあ、デジゲー博Verなんて言ってるけど、テンポのいいステージを見繕い、コンパクトにまとめましただけなんですけどね(現状4ステージ分)。

 制作の手を止めてまで、わざわざ専用Verなんて作る時間がもったいないなーと思い、これまでイベントで展示したり、試遊会で遊んでもらったときには、ほぼ実際のゲームと同じ状態のフリープレイのものを出していました。しかし、限られた時間の中、こちらの見てほしいところ、遊んでほしいところをプレイしてもらうのは難しいという、当たり前のことにいまさら気づき、パッと触れて、パッと終われるゲームプレイの流れと、売りとなるポイント、制作者として遊んでほしいところをすぐ体験してもらえるようなものを用意するようにしたということです。

 ただ、慣れに慣れた人間のセレクトなので、かなり難易度が高い物に……。単純に敵の攻撃を減らしたりするといったパラメータ調整でも対応できなくはないですが、もう1アクション、気持ちよさを加速させる脳汁がドバドバ出るような仕掛けというか調整を入れていきたいなー……あそこをああして、判定をなくすとガンガン戦えるかも……ブツブツブツブツブ…あとでやってみよう。

 イベント専用Verついでに展示のPCでデモ映像だけでなく、パッドを使ってプレイしてもらえるように対応してみました。スマホゲーなので、実機でプレイしてもらえればいいと言えばいいのですが、やはりプレイしている映像がほかの人に見えないのが難点。ふらりと通過した人の目にも入るようにノートPCのモニタでプレイの様子を見せられれば、よりアピールできるんじゃないかという目論みです。

 実装自体は、もともと1タップ操作で遊ぶものをスティック&ボタン操作に変えるだけ、らくしょーと思っていたのですが意外にめんどいものだと実感(根本的な実装方法がダメって話もありますが)。とりあえずスマホ実機でのタッチ操作と、ちょっとだけ操作感覚が違うけど一通り遊べるようにはなったのでヨシとします。

 とにかく無計画、成り行き設計のツケがきついですが、とにかくゲームとして遊べる形へと仕上げるために手を動かすしかありません。年内リリースに向けて……希望は捨てちゃいかんな。うん、がんばろう。