つくりえいと

トップ 我流RPG制作論 小回りを利かせよう

 小回りを利かせよう

 進路変更は避けられない

  • 「もう少しお塩を入れた方がいいんじゃない?」
  • 「ああ悪い。ここに窓を付けてくれないかなぁ?」
  • 「もう少しこう…明るい感じにならない?」

これらはとある人物が作ったものに対して、 発言権のある第3者が注文をつけている場面を現したセリフです。 いずれも比較的よく聞かれることからわかるように、 物を作ることにおいて、後の変更というのは、 避けて通れないものなのです。

これはRPGにおいても同じことが言えます。 テストプレイで意見を求めたり、 友人にプレイしてもらったりすると…

  • 「戦闘終了時のメッセージがありがち過ぎるよ」
  • 「敵が強すぎる」
  • 「夜の画面ってもう少し明るくできない?」
  • 「カッコの前の"。"は要らないんじゃない?」
といった注文を必ず受け取ることになります。

第3者に意見を頂戴しなければいいという問題ではありません。 なぜならば、「ここはもっとこうした方がいいかも」 という思いつきが自らの心の中で生じるからです。 "変更は必ずあるもの"と考えるべきでしょう。

 進路変更のリスク

「戦闘終了時のメッセージがありがち過ぎるよ」 これならば「はいはい…」と言いながら、 データベースをちゃっちゃと書き換えれば済みます。 「敵が強すぎる」に関しても、 多少面倒ではありますが、数時間もあれば変えられるでしょう。 それでは、「夜の画面ってもう少し明るくできない?」はどうしましょう?

画面色調変更のイベントが"夜になる時"だけだったら、 まだ救いの手はあります。しかし、"建物に入ると明るくなる" なんて仕様にしていたら最悪です。夜に行くことができる建物の 移動イベント1つ1つを書き換えなければなりません。 1つの建物に移動イベントが3つくらいあるとして… 1つの町に建物が5〜6個。町が全部で10個くらいあって、 それに加えてダンジョンも10個くらい… なんていったら書き換えるイベントは膨大です。

 リスクを抑える設計とは

進路変更を避けられない以上、 取れる対策としては"変更のリスクを抑える"ことが挙げられます。 具体的にどうすればいいのか考えたところ、 次のような項目が挙がりました。

  1. 複数回呼ばれるイベントは、コモンイベント化する
  2. システムは、機能ごとに細分化する
  3. 設定値はイベント上部で設定する
  4. 適宜注釈を書き入れる
  5. 常に変更を意識する

 複数箇所で呼ばれるイベントは、コモンイベント化する

呼ばれる回数が多いということは、変更時の手間も大きいと言えます。 こういったイベントは、コモンイベント化することによって、 1箇所の変更で全ての変更を行えるようにするのが効果的です。 一見コモンイベント化するのが不可能に見える"イベントの動作指定"であっても、 移動させるイベントのIDを一致させることによって、 違うマップで同じコモンイベントを併用することができるようになります。 存在しないIDを指定しちゃうと、ゲームが落ちるというリスクがありますが...(^^;)

 システムは、機能ごとに細分化する

システム全体を1つのコモンイベントに書くのはお勧めできません。 そうすると、目的の部分を探すのが一苦労ですし、 ページの読み込みにも時間がかかり、効率的な制作が行えなくなります。 また、変更を加えて上手く動かなくなった時に、 どこの部分が原因なのかを突き止めにくいという欠点も生じます。

システムは"メイン""変数の桁分け処理""画面へのピクチャ出力" "キー入力""カーソル移動"といった機能ごとに分類しましょう。 こうすることで、ソースがすっきりするだけにとどまらず、 "別のシステムで同じ機能を再利用できる"、 "変更すべき部分が明確になる"、"結果的に機能の変更が容易になる" といったメリットを得ることができます。

 設定値はイベント上部で設定する

ピクチャを表示する座標やアイテム、特殊技能のIDは、 あらかじめイベントの上部などで変数として指定しておくと便利です。 座標やアイテムを変更する度に、わざわざソースを辿るのは時間の無駄ですからね。 システムが大きくなればなるほどこれは効果を発揮します。

 適宜注釈を書き入れる

作った当初はわかっていても、何日もすれば何をしているのか さっぱりわからないというのがプログラムのソースです(^^;) これはツクールのイベント群に関しても同じことが言えるでしょう。 従って、後の変更時に解読不能にならないように、 作りながら適宜注釈を入れておくのが良いと言えます。

ツクール2003になって、 注釈の先頭行だけ(^^;)文字が緑色になりましたが、 それでもまだまだ見つけやすいとは言いがたいので、 コメントは


	**********************************************

	変数の値を1桁ごとに分ける

	**********************************************

	
といった具合にすると良いでしょう。 アスタリスク(*)の前後に1行ずつスペースを空けるのがポイントです。 しかし、先頭行だけ緑って…手抜きとしか言いようが...(^^;;)

注釈には何を書けばいいのか。私もさっぱりです(待ちなさい) とりあえず、見てわかることは必要ありません。


	**********************************************

	変数"アイテムID"の値を"tmp"に代入する

	**********************************************

	
なんてのがそれですね。 細分化されたイベント(機能)の場合には、 "使い方"とか"注意事項"なんかを書くといいらしいです。

	**********************************************

	機能:
		指定された2桁の値を桁ごとに分割する
		例)"12"は、"1","2"に分割される

	使い方:
		1.変数"引数"に桁わけ処理を行う値を代入する
		2.このイベントを呼び出す
		3.変数"戻り値1"に一の位が、"戻り値2"に十の位が入る

	注意事項:
		このイベントでは、2桁までしか値を返しません。
		3桁目以上の部分は無視されます。


	**********************************************

	
ってな具合でしょうか。

 常に変更を意識する

機能の限られたイベントコマンドで作業を行う ツクールにおいてはなかなか難しいかもしれませんが、 ちょっとした心の持ち方次第で、後の変更が容易になるケースが多々あります。 上で挙がった「もう少しこう…明るい感じにならない?」というのも、 あらかじめ"明るさは後で変えたくなるかもしれない"と考えてコモンイベント化していれば、 1カ所の修正だけで済むことでしょう。

 まとめ

RPGにおいて仕様の変更は避けて通れないものです。 変更を常に意識して、変更時に困らないような設計を心がけましょう。 心がけとアイディア次第で、きっと大幅な作業効率の向上が図れることでしょう。

[2005/02/06に書いたよー]


トップ 我流RPG制作論 小回りを利かせよう

(C)2001-2010 つくりえいと All rights reserved.