プログラミングでのRPGの作り方と大変さを伝える：後編
こんにちは。継続の錬金術士なおキーヌです。
ブログ毎日更新は128日目になります。
プログラミングでのRPGの作り方と大変さを伝える：前編の続きになります。
前後編の結論から先に言うとRPGそのものを作りたいならRPGツクールを使った方が良いです。
俗にいうRPGツクール臭が嫌だという人も結構いますが、それだけを理由に1からRPGを作ろうとすると
凄まじい労力のわりに出来上がるのはWindows95すら出ていない時代のツクール以下のものが出来上がります。
ただ、RPGを作るのはプログラミングの基礎訓練としてこれ以上ないものだと体感しました。
前回はキャラクターを出して衝突判定まで作りましたが、肝心なキー入力操作を書くのを忘れていました。
今回GWゲーム制作チャレンジ記事ではコントローラークラスは、
既にマップエディタの時に作っていたので省略していましたが少しばかり説明いたします。
- キー入力を作る
- 衝突判定をチェックする方法
- イベントを作る
- テキストを実装する
- 各種パラメーターを実装する
- シーン切り替えフラグを作る
- バトルシステムを作る
- ダメージ計算式を考える
- キー入力待ちを作る
- 完成したゲームの配布について考える
- 結論：RPGを作りたいならツクールMVを使うべき
キー入力を作る
結論から書くと、キー入力処理は別にファイルを作ったほうがあとのことも考えると楽になります。
実装方法はプログラミング言語によって変わってきます。
ゲームループ中にあるメイン処理の前に置くか後に置くかはゲームの種類によっても変わります。
キー入力処理はマップ移動であろうが会話中であろうが戦闘中であろうが動き続けるのが理想ですね。
入力した値はどこからでも参照できるようにしておくと作るのが大幅に楽になります。
本来は特定の関数を介してじゃないとアクセスできないようにしとくのがお作法なのですが、
最初からがんじがらめな作りにしておくとゲームを作りたいというモチベーションを下げてしまうので、慣れてくるまではグローバル変数にキー入力の値を保持しておくと良いです
イベントを作成する
プレイヤーは１人ですが、イベントは複数います。
宝箱もモンスターもトラップもすべてスプライトという形で表現できるので
スプライト型の配列を用意しましょう。
イベント情報は外部ファイル、例えばjsonでデータを定義しておいて
ファイルを読み込んでその情報を元にスプライトを生成していきます。
イベントも画面上のグリッドを移動するのですがマップチップ用配列に描写すると
マップチップが消えてしまうので、衝突判定用配列を作ったようにイベントが存在できるようにイベント用配列を増やしましょう。
準備が整ったら、ループを使って配列を回して描写していくのが基本です。
イベントデータもjsonに書いておけば、プレイヤーは目の前にあるイベント配列の数値を見て
対応するイベントのデータを引っ張ってきて処理を起こすという風にすればイベントシステムは完成です。
あとはイベント配列の数値に対して処理を作り込んでいくだけですね。
イベントシステムはそれだけで記事にできそうなのでそのうち解説記事でも書きます。
衝突判定をチェックする方法
プレイヤーとイベントグラフィックもキー入力も衝突判定配列もイベント用配列も作りました。
プレイヤーキャラが衝突判定をする場合は、移動可能な状態でキー入力後に
押した方向の衝突判定配列を参照して、ぶつかっていなければイベント用配列を参照し、問題なければ移動先のイベント配列の数値を書き換えて他のイベントが同じ配列に入ってこれないようにした後、やっとプレイヤーの移動処理にうつります。
イベントも移動を組み込む際は同じ処理で大丈夫です。
テキストを実装する
テキストも言語によって実装方法は様々です。
フォントデータを使って簡単に文字を表示できるものもあれば、
文字を画像化してスプライトとして矩形で表示するのが基本になります。
最近のPCではあんまり問題ないと思いますが、日本語のフォントデータは英字フォントに比べて重たいのでなるべく使いたくないところですが楽をできるなら使ったほうがいいでしょう。
テキストはプレイヤーに情報を与えるための重要な役割があります。
文字を一切なくして画像だけで伝えるという手法も素晴らしいですが、
RPGを作る上ではテキストは避けられないので使い方を覚えておきましょう。
各種パラメーターを実装する
テキストを実装できたらプレイヤーやモンスターにデータをもたせましょう。
現在のHPやレベル、強さなどを保持しておき増減したら画面更新をするという感じにすれば
ユーザビリティも高まりプレイヤーも今どんな状況なのか一目でわかります。
あえてプレイヤーに見せない隠しパラメータとかを作っても面白いですが
すべて隠してしまってはプレイヤーのストレスになるので基本的なパラメーターは表示しましょう。
シーン切り替えフラグを作る
あえてここまで話していませんでしたが、ゲームにはシーンというものがつきものです。
マップを移動するシーン・イベント会話シーン・バトルシーンと
様々なシーンがRPGにはあります。
プログラム側では現在どのシーンにいるかを管理しておかなければいけません。
いままではマップを移動するためのシーンだけを作ってきましたが、
イベントを調べるためにはイベントシーンを設けなければいけません。
設定されているイベントが終わったあとはマップシーンに戻すといった感じです。
フラグは真偽値では２つしか持てないので数値で管理すべきでしょう。
言語によっては構造体などで数値に名前をつけたりして管理するとよりわかりやすくなります。
バトルシステムを作る
RPGにはなくてならないシステムですね！
シーン切り替えフラグを作ればバトル用の数値に変更してしまえばバトルシーンに突入することができます。
RPGのバトルは大きくドラクエのようなターン制バトルやFFのようにリアルタイム(厳密にはリアルタイムではない)風のバトルに分けられます。
初心者の場合はドラクエ方式を採用した方が無難でしょう。
ターン制の場合は流れがプログラミングと同じような感じなので結構簡単に作れてしまいます。
キャラクターを動かすとなるとタイミングとか、アニメーション実行中の監視など様々な要素が増えてくるのでまずはテキストだけで戦闘を作ってみるのがベストです。
ダメージ計算式を考える
バトルで必要になるのがダメージ計算式ですね。
じゃんけんタイプみたいな１回負けたらライフが１減るといったものには計算式は不要ですが、
普通のRPGの場合敵の攻撃力やプレイヤーの防御力を考慮したダメージにするのが基本です。
私が今回のゲーム制作チャレンジで実装した計算式は、通称アルテリオス計算式です。
攻撃力ー防御力＝ダメージ
といった凄まじく単純な計算式です。
最近のRPGにはあまりない計算式ですがレトロなRPGではこの計算式が普通でした。
アルテリオス計算式のメリットはシンプルだということですね。
デメリットはレベルが上がると一気にバランスが崩れてしまうことです。
なので攻撃が全く通らなくなった場合は最低でも１のダメージを与えるようにしたほうがいいでしょう。
今回私がなぜアルテリオス計算式を採用したかというと、用意するパラメーターが少なくて済むのと
考える時間を減らしたかったのもあります。
キー入力待ちを作る
メッセージ送りや止まってほしい場所で停止してくれないと、一瞬で戦闘が終わったり
重要なメッセージを飛ばしてしまいます。
本来はコントローラークラスで制御するべきなのですが、javascriptだと色々面倒だったので
メイン処理の部分で止めたいときにコントローラークラス側のフラグをONにして連続でボタンが押されないように制御しました。
コントローラー側ではボタンが離されたらそのフラグをOFFにするようにしています。
本来はこのようなつくりはバグを引き起こすのであまりよろしくはありません。
JavaScriptのスコープはガバガバなのでこのようなことも簡単にできてしまう分大作になると複雑になって頓挫する確率が上がります。
コントローラークラスで特定の変数を変更するためのメソッドを介さなければ変更できないという風にするのがベストです。
完成したゲームの配布について考える
今回、JavaScriptで作ったのは私がWeb側の人間だったというのと、RPGツクールMVでPONG GAMEをpixi.jsのみで作ったこともあり採用しました。
そしてデスクトップアプリに出来るElectronというものと、javascriptを型付けで書けるように作られたTypeScriptを使って開発しました。
最大の問題点は配布にあります。
javascriptは完全に暗号化することは難しく、少し知識のある人であれば折角作った素材を簡単に抜き取れてしまいます。
市販のゲームも解析されてリソースぶっこぬかれていたりしますが、javascriptは基本リソースが丸出しの状態なので
そこから暗号化などをしまくっても結局は自動で戻せるツール等があるので複合化が容易です。
配布したいのであれば素直にUnityを使うかRPGツクールを使った方がよいですね。
もしくはJavaScriptではなくてJAVAで組んでAndroidアプリにしてしまってもいいかもしれません。
ですがそうなるとiPhoneがハブになってしまうのでよろしくありません。
UE4はオーバースペックなのとC++があんまりできないので今のところ2Dも作りやすくて
配布もしやすいUnityが一番いいかもしれませんね。
結論：RPGを作りたいならツクールMVを使うべき
最初にも言いましたが、RPGを作ってみてわかったのがRPGツクールをつかった方が良いということです。
pixi.jsを使いたいならRPGツクールMVのスクリプトを弄ればOKです。
問題はES5で書かないといけないのと既に作られているライブラリ群の解読もしないといけないという苦行が待っています。
それなら素直にUnityで1から作った方が色々と良いです。
1からRPGを作るメリットはプログラミングの勉強になるというところでしょうか。
今回のRPG作りでかなりプログラミングの腕の基礎が固まった気がします。
それでは。
