PaganDogmaSCRAMBLE 完成！
4月から始まったコロナ禍。
うちの会社もその煽りを受けてしばらく自宅で自粛の流れとなっております。
喜ばしい話でないのは百も承知ですが、私にとってはゲーム開発を一気に進めるための機会！
というわけで連日ClickteamFusion(インディーゲームクリエイター)と向き合い続け、ようやく昨日この作品を公開することができました(ﾉ´∀｀*)
ゲーム中素材は以前までのもののほぼ流用なのですが、スマホでも遊べるようにする・ゲーム性の変更・それに伴うバランス調整・新モードの追加といろいろ変更点が多く、
｢素材使い回すからそんなに時間かからないかな～｣などと甘い考えを抱いていた自分が愚かでした(ﾉД`)
しかしながら………ClickteamFusionでゲーム開発に集中するのはすごく楽しい！！！
実装してはテストして～を繰り返すと時間が溶ける。誇張でなくマジで一瞬で過ぎていきますね。
｢ここはもうちょっとこうしたい｣｢この要素も付けておこう｣とやっているといつ中断すべきかがわからなくなり、本当に恐ろしいツールだなと体感しました。もちろん良い意味でね。
その甲斐もあって、見た目は前作とさほど変わりませんがゲームとしての楽しさはかなり上げられたのではないかな、と個人的には思っております。
比較的シンプルなシューティングで誰でもすぐ遊べますので是非一度触ってみてネ！(宣伝)
語りたいことはPlicyの攻略本の部分にめっちゃ書いたので、以下はいつも通りに誰かの役に立ったらうれしいClickteamFusionでの備忘録。
・フォント
文字列オブジェクトでフォントを自由に変えられる嬉しい仕様がついているんですが。
気づいてなかったんですけど、これ他の人が見る分には当然ながら該当するフォントがインストールされてないと変換されないんですよね(；´∀｀)
PCゲームであれば共用のフォントを使用すれば問題ないんですが、今回のゲームはスマホでも遊ぶ前提。
調べてみるとスマホのフォント自体は機種によって違えどだいたい一種類しか使用していないようで、とりわけAndroidはフォントの種類が全然統一されてないので機種によってフォント自体が全然違うと。
これアカンやつや……
どうしたらよいのかということで更に調べていったところ、
このようなウィジェットを作成しておられる方が！
やはりみんなこの問題には困らされていたようです。先人の知恵に感謝。
と思ったんですが、文字用の画像を作成した上で細かな設定をしていく必要があり、実際に使用するには結構手間がかかりそうなこと。
またこのツール自体が会話文のようなメッセージ表示で使うように設計してあること。
これらを鑑みて、｢これ、UIの文字を表示するのには向いてねぇな｣と感じ、今回は使用を断念しました…(ﾉД`)
結局どうしたかと言うと、表示用に使う文字は全部Aseprite使って画像にして取り込みました。
ゲーム中に出ている文字は全部画像付けたアクティブオブジェクトです。
これならどんな機種でも好きなフォントで文字表示できますね！最強ですね！手間増えますけどね！！！！
・タップ用ボタン
スマホで操作するために画面下部にタップ用のボタンを用意しました。
タップ自体は｢マルチタップオブジェクト｣を画面外に置き、イベントでこれの｢タップ｣部分の項目を選べば実装できました。
マウスの左クリックでもできるかと思いますが、専用のオブジェクトがあるならしっかり使った方がええかなと。
｢オブジェクト上で新規タップを開始｣にしてボタンの画像を指定してやれば設定完了や。楽勝や。
なんでキャラ移動すると位置ズレるんや！！！！！
｢動作領域に固定｣はチェック外して画面移動とともにボタンを移動してるんですが、そのボタンの上をタップしてもキャラが動かない。
んで、適当に別の場所をタップしてみるとたまに変な所でボタンタップが反応する。
これ、見た目のボタンの座標は移動してるけどタップの判定は移動してねえな……？
というわけで、手抜きはせずに｢ボタンの画像用オブジェクト(表示する)｣と｢ボタンのタップ反応用オブジェクト(非表示)｣の2つを同じ位置に用意。
｢常に実行｣にて、反応用の方のみを同じ座標に固定する。
これでボタンを押した際に該当のボタンの動作をするようになりました(о´∀`о)
この方法であれば反応用オブジェクトのサイズを変えればよりボタンが反応させやすくなりますので、今作でもサイズ大きくして操作しやすくしました。というかボタンと同じサイズでテストしたら凄まじく動かしづらかった(；´∀｀)
一般的にボタンの判定は見た目よりも大きい方が操作しやすくてユーザビリティが高くなると思うので、何も問題が起きてなくてもしっかり判定用の部分は大きくしておくべきやなぁと思います(反省)。
・オブジェクトイベント
むっちゃ便利。
今までろくに使ってなかったんですが、別のフレームで同じオブジェクト使い回すぞって分かってるなら必要事項は最初に全部オブジェクトイベントに書いていった方が間違いなくいいですね。とても二度手間やらかしてました……。
オブジェクトイベントってそのオブジェクトが作成されてなければ非アクティブになるんだよなと思ってたんですが、どうやらオブジェクトが作成されてなくても実行されるっぽいですね。テストしてみると明らかに他のオブジェクトイベント(作成されてないやつ)の影響受けてるようなので。
イベントリストから一部切り抜いて関連するものに貼り付けられるよ、って感じなのかしら。
オブジェクトイベントでもイベントグループでもそうですが、細かく関連するイベントごとに分けておいて適宜コピペして使っていけるとメンテナンスもしやすいし開発自体もラクになりそうです。
こういうのは話だけは聞いていたけども実際に面倒さを味わってみないと身に沁みないなぁと( •̀ㅁ•́;)
移動速度とかの変数も、移動するオブジェクトの変数をそのまま書き換えていくよりはデータベース用オブジェクトを作ってそいつの変数を参照していく方が、いっぱい作成されるオブジェクトでもブレがなくなっていいのかなと思ったり。スクランブルモードは一応そういう方法で実装してみてます。
・条件の指定に関して
｢条件を制限｣の中に｢このイベントを一回だけ実行｣ってのと｢イベント連続中にアクションを一回のみ実行｣ってのがあって、違いがよくわかってなかったんですが今回とてもよくわかりました。
前者は｢フレーム中に一回だけ｣なので、同じイベントをループしても最初の一回だけしか実行されない。
後者はフレーム内での回数縛りはないので単純にここで一回だけイベント動かしたい、って時に入れる。
ノーマルモードではボスが繰り返し出てくることはなくてどちらでも一緒だったんですがスクランブルモードではボスが何度も出るので、前者だと2回目に登場したときに動かなくなってしまうんですね。原因がわからなくて割と焦る。
書いておくべきことがいろいろとある気はするのですがひとまずここまで。
ちょっとボリュームの多いゲームを作ったことで開発の仕方が結構飲み込めてきたかなと思います。
また次作のために頑張るぞい！！
