【プチコン4講座】アクションRPG風バトル構築:企画編

プチコン4

プチコン4 バトルシステム 企画

こんにちは。継続の錬金術士なおキーヌです。

ブログ毎日更新は181日目になります。

前回「【プチコン4講座】RPGのステータス画面を実装しよう」でステータス画面の作成と開閉を可能にしました。

ついにバトル編に突入です。

RPGのバトルシステムの企画を立ててみましょう。

プチコン4では解像度が上がったグラフィックが実装されているので、
バトルシーンに画面を切り替えようと思います。

バトル専用シーンを設けることで他の制約に囚われなくなりますね。

戦闘だけアクションRPGにするには便利な手法です。

JavaScript版ではコマンド選択式のバトルを実装。

プチコンBIG版ではATB風バトルを実装しました。

RPGの半分以上はバトルが重要だと思っている世代の人間なので
バトルだけは同じものを作らないでおこうというスタンスで記事を書いています。

コードを書いてばっかりだったのでたまには考えることをしようと思うので
今回はコーディングはおやすみにします。

バトルシーンを小分けに目次化したら長くなってしまったので
1を読んだらその作り方を見て次は2を見てその作り方を見るというやり方をしてもらうと
余計なことを頭に入れずにその機能作成に集中できるかと思います。

もちろん、一通り見てから1からじっくり作っていくというのでも大丈夫です。

それではプチコン4でRPG作りその18回目始めましょう。

  1. どんなバトルシステムにするか考えてみよう
  2. トランジションを実装する
  3. シーンの切り替えを自由にできるようにする
  4. シーンを切り替え時に情報を保持しておく
  5. 保持した情報を元に暗転中にバトルの準備をする
  6. バトルマップを描写する
  7. キャラクターを配置して動かせるようにする
  8. 攻撃を実装してみる:アニメーション編
  9. 攻撃を実装してみる:衝突判定編
  10. ダメージをステータスに反映させる
  11. 勝利時にリザルト処理を行う
  12. 敗北時にゲームオーバーシーンに移す

どんなバトルシステムにするか考えてみよう

マップ画面からバトル専用画面に切り替えるのは確定項目として、
どんなバトルにしてくかが問題ですね。

FF風のバトルはすでに作っている方がいましたので、
私はもうちょっと難易度をあげて作ってみようと思います。

RPGにアクション要素の有無は賛否両論かとは思いますが、
私が最初に再現したいなって思ったバトルがスターオーシャン1の戦闘です。

スターオーシャンは正直2から一気に知名度が上がった気がするというか
私自身が2からプレイしたっていうのもありますが(笑)

スターオーシャン1の原作の方はプレイされた方は思ったよりも少ないのではないでしょうか?

PSPのリメイク版はスターオーシャン2と同じような戦闘になっていましたが、
SFC版の方は1画面でスクロールなしの自由に動けるバトルシステムでした。

自由に動いて攻撃できるバトルって当時ではかなり画期的だったのではないでしょうか?

私も幼い頃はゲームばっかりしてた人生でしたがRPGはドラクエとFFとか、
有名どころのRPGしかやってこなかったのもあり、あの時代でそんなバトルだったのかと驚いたものです。

話を戻しますと、プチコン4でスターオーシャン1風の戦闘システムを構築して行こうと思います。

採用理由は

  • 1画面完結なので画面スクロールを実装しなくていい
  • プチコンデフォルトのアニメーションで意外と再現ができそう
  • プチコンデフォルトの衝突判定機能を活用できそう
  • シビアなアクション戦闘ではない

以上です。

それでは必要な要素を考えてみましょう。

トランジションを実装する

プチコン4以前に作ってきた1画面RPGはフィールドの状態からそのままバトルに突入していました。

なのでプチコン4ではバトル専用の画面に切り替えてみたいと思います。

シーン管理としては「G_SceneFlag」変数で管理しているのでそこを変更すればOKですね。

しかしいきなりシーンを変えてしまってはぶつ切りで戦闘画面に切り替わってしまいます。

市販のRPGではシームレスタイプでなければ戦闘に入る前にトランジションを挟んで画面を切り替えます。

PS版のFF7で例えると、シュワァァアアアという効果音と共に画面が渦状になって暗転後に戦闘に入ります。

ドラクエなら点滅してから黒い細かいブロックが画面を覆っていき暗転したところで戦闘になりますね。

ゲームによっては現在写っている画面を1枚絵にして、
ガラスのように見立ててガシャーン!と崩して戦闘にはいるものもあります。

この際、1枚絵にして裏で色々ロードしているのをみられないように工夫しています。

これらを総じてトランジションと言います。

正直今までトランジションなんて実装したことがないので実装方法がわからないです。

RPGツクールやその他ゲーム制作ツールをみていると一部半透明のグレースケールのグラデーションを、
プログラム側でいろいろやっているようなことは理解していますがそこまでしかわかりません。

おそらくはその一部半透明の画像を乗算やらなんやらでいい感じにしているのでしょう。

トランジションに関してはシステムが完成してからでも間に合いますので、最後に回しましょう。

シーンの切り替えを自由にできるようにする

シーンの切り替えはマップとステータスとイベントで既にやっているので楽勝ですね!

違っているのは、画面全体を切り替えるのでバトルシーン入るときは楽勝ですが
マップシーンに戻るときはちょっと厄介です。

そのまま最初と同じように描写してしまうと倒したモンスターも描写されてしまいます。

なので状態を描写する時は保存された状態を参照するようにすればいいわけですね。

バトルシステムを作るときはまずこのシーン切り替えと現状の保存を実装する予定です。

  • モンスターを調べる
  • 戦闘シーンに切り替える
  • Yボタンを押したら戦闘終了とみなしてリザルトモードに入る
  • リザルトモードでAボタンを押したら状態を保存
  • 保存後にマップシーンに戻す
  • 調べたモンスターは倒したことにする

後はここに少しずつ戦闘システムを足していくだけです。

シーンを切り替え時に情報を保持しておく

シーン切り替えが実装出来たら切り替え時に情報を保持しておかなければ
どの敵と戦うのかわかりませんね。

基本的にはイベントを調べた時にそのイベントが持っている情報を
変数に保持しておいてその変数を使ってバトル準備をします。

もしくは、規模が大きくなってきたらイベントごとに情報を持たせるのは厳しいので
情報をデータベースに格納しておいて、イベントIDによって引っ張ってくるデータを変更します。

イベントは必ずユニークなIDを持っているので被ることはありません。

保持した情報を元に暗転中にバトルの準備をする

情報を保持出来たらその情報を元にバトルの準備をします。

実際には暗転している時に得た情報から表示する敵のグラフィックや能力値を決めます。

ここで通常のモンスターなのかボスモンスターなのかを判別してもよさそうですね。

通常であれば通常のBGMにしてボスであれば専用のBGMにするということも出来ます。

バトルで使う値は基本的にここですべて準備しましょう。

バトルマップを描写する

画面を切り替えるので背景を表示しなければ真っ暗な画面で戦うことになります。

ターン制のバトルならドラクエ2~4みたいな感じで作ることはできますが、
動き回ることのできるバトルの場合背景は必須ですね。

ですが、障害物は作るつもりはいまのところないので基本的には画面内であればどこでも動けるようにしたいです。

その為バトルマップを表示するのはトランジションと同じで完成後でもいいかもしれません。

絵を用意するのは時間がかかりますが、プログラムには影響しないので後回しでも構いません。

私みたいに見た目の土台がちゃんとなっていないとなんか作りにくい……
って人もいるかもしれないので私は簡単ではありますが何か背景を作ろうと思います。

幸いプチコンにはそういった絵を用意してくれているので、
マップシーンと同じようにマップデータを作ってそれ通りに描写するだけです。

マップシーンと違ってレイヤー別にマップを作らなくていいので楽ですね。

そしてマップチップ描写関数はすでに完成しているのでそれを流用するだけです。

その際に現状だとマップシーンのものを描写するようになっているので、
シーンフラグによって描写する配列を差し替えてるように改良しなければいけません。

キャラクターを配置して動かせるようにする

キャラクターが居ないと何も面白くないですね。

点やテキストだけでやるってのもある意味面白いかもしれませんが(笑)

マップシーンではグリッドに沿って動くようにしましたが、バトルシーンではドット移動で作っていきます。

グリッドにしてもそれはそれで面白い戦闘がつくれそうなのですが、
アクションRPGにはあまり向かないかもしれません。

グリッドでのバトルとなるとどうしてもターン制のローグライクじゃないと相性が悪そうです。

アクションRPGの醍醐味はテクニック次第では敵の攻撃をギリギリのところでかわしつつ
攻撃に転じられるというところでしょう。

グリッド仕様だと避けるのが困難になってストレスにしかなりません。

なのでモンスターとプレイヤーを表示してそれぞれが自由に画面内を動けるようにしたいです。

幸いスプライト毎に固有の変数を持つことが出来るので座標や能力保持が容易なため、
アクションRPGを作るならプチコン4は結構便利な機能がそろっています。

攻撃を実装してみる:アニメーション編

攻撃をしなければバトルにはなりません。

どのボタンで攻撃するかを決める必要があります。

ここは自分の好きなボタンでもいいと思いますが、
攻撃のほかにも必殺技ちっくな特殊行動を実装したいので攻撃はAボタンにしようと思います。

もちろん、私がそう決めているだけなのでYボタンでもBボタンでもいいですしZRやZLでもいいわけです。

そしてボタンを押して攻撃モードになったらアニメーションを切り替えたり、
攻撃エフェクトを出したりしてあげるとユーザーにもわかりやすくなります。

ここではまだ衝突判定を設けていないので実際にダメージを与えられません。

とりあえずボタンを押したらキャラクターが攻撃をするといったアニメーションを実装します。

攻撃を実装してみる:衝突判定編

攻撃アニメーションを実装できたので今度は攻撃時に判定を与えて、
その判定を元に攻撃を受ける側も判定を実装しなければいけません。

プチコン4にはデフォルトで衝突判定を処理する命令が用意されています。

自力で実装して勉強にしてしまうのもいいですが、衝突判定は結構複雑な仕組みなので
プログラミング初心者が結構挫折しやすいかなと個人的には思っています。

なので難しいことは抜きにしてありがたくプチコン4の機能を使わせてもらいましょう。

ダメージをステータスに反映させる

衝突判定を検知出来たら攻撃されたのかしたのかで数値の増減をします。

計算式はここですれば大丈夫でしょう。

しかし今までやってきたアルテリオス計算式(攻撃ー防御=ダメージ)をすると、
レベルが1あがるだけで難易度がガラリと変わってしまうクソゲーになるので
計算式を少し考えなければいけません。

独自のダメージ計算式を考えるのって計算が得意な人じゃないといい感じの計算式は生まれません。

なので素人は素人らしく既存のゲームのバトルシステムから拝借してしまうのも有りです。

古いゲームであれば解析されて計算式の詳しいところまで書かれていたりするので
そのまま使っても良いですし、そこにオリジナルを加えてしまうのもいいです。

素人が変に改変したらバランスがダメなゲームになるので基本的には改変しないほうがいいでしょうが。

どんなことであっても人のモノをパクるなんてとんでもない!

って言う考えの人もいるかもしれませんが、
ファミコン時代なんて企業でもパクってなんぼの世界でした。

もちろん、著作権にかかわるグラフィックをそのままパクるのはダメですよ。

計算式なんて特許とかを取らない限りは基本的に使っちゃダメなんてことはありません。

もちろん、自分で考えたわけではないので作者に最大限の敬意を払いましょう。

そもそも私が今作ろうとしているのは完全にスターオーシャン1のバトルのパクりなので(笑)

余談として、FFのATBはちゃんと特許を取っているものですから使用する際に許可を得てお金を払わなければいけません。

なのでプチコンBIGの戦闘システム構築ではATB風という風にあえて強調していました。

ATB風であってATBではないということです。(屁理屈みたいなもんですが

勝利時にリザルト処理を行う

相手のHPが無くなったら戦闘終了になります。

その後はリザルト画面を表示する必要がありますね。

倒して何を得たのか。

勝利戦闘BGMを流しつつウィンドウを表示して情報を表示するという、
RPGの戦闘後によくあるシステムを導入します。

その後に暗転させてマップシーンに戻すのが基本ですね。

敗北時にゲームオーバーシーンに移す

リザルト画面とは逆にこちらのHPが0になったらゲームオーバーとして切り替えます。

ゲームオーバーになったらタイトル画面に戻したりリトライさせるかどうかを選ばせると良いでしょう。

この辺はゲーム性によって変化させるべきです。

バトルに負けてまた長い道のりを通ってこないといけないゲームだと、
それだけでユーザーのストレスが溜まり最悪プレイされなくなってしまいます。

FF3のラストダンジョンセーブ無しみたいなのは今のユーザーには絶対に受け入れられないでしょう。

個人的にはそれはそれで歯ごたえがあるRPGだと思いますが、
私自身がそういったゲームの時代を体験してきたから言えることですね。

社会人目線から見たら確実にそんなゲームは途中でやめてしまいます。

なのでコンティニューをするかどうかはユーザーに選ばせた方が良いでしょう。

どこから再開するのかはゲームのバランスと相談するのがベストです。