結局、余計な部分にばかり固執し、まるで本編が進まない。進捗状況としては、物語自体はオープニングが半分程度、マップに関しても最初の町を半分程度作れた程度だ。では一体、ツクールで何をしているのかと言えば、どうでもいいイベントを作ったり、ツクール2000よろしく並列処理の時間遷移イベントを作ったり、スクリプトを改変してみたり、そうした脇ばかりを攻めているというわけだ。脇フェチなのだろうか。
時間の概念に関しては、数フレームで1分、あとは現実時間と同じ進み方にした。どれくらい現実と似せたかと言えば、1月や12月は31日まであり、2月は基本的に28日までだが、現在の年数を4で乗除し、結果が0の時は閏年として29日まで。さらに4～12時間おきに天候が変化し、晴れ、曇り、雨、嵐、から無作為に実行される。ただし、1月、2月、12月に関しては、選択肢の中に雪が加わる。この天候に関しては、自分が関東出身のため、雪が珍しいという感覚から設定している。ちなみに、町の中では時間が経過しない。
スクリプトに関しては、海外サイトのカテゴリ別アイテムを導入している。戦闘以外の全てのシーンにおいて、アイテムがカテゴライズされるようにしてある。また、今回もデパート(百貨店)を作ったため、返品カウンターを設け、返品カウンターのみ、売却価格を100％(購入時と同じ値段)とした。売却専用のショップ処理だと、他所で購入したアイテムまで売却できてしまうため、売却選択画面には、そのデパート内で売っている商品のみ並び、所持していないアイテムについては、無効状態での表示にした。この処理に関しても、アイテム数が多くなるため、カテゴリー別に対応させることにした。返品可能として表示されるアイテムの取得方法は、メモから「返品可能」などと参照させるか迷ったが、この方法だと、デパートが各地に存在した場合、何処でも返品できてしまうため却下。返品ショップ用スイッチがＯＮの場合に限り、イベントコマンドのショップ処理で選択したアイテムを表示するようにした。具体的には以下。
#--------------------------------------------------------------------------
# ● アイテムを許可状態で表示するかどうか
#--------------------------------------------------------------------------
def enable?(item)
$game_party.has_item?(item, include_equip = false)
end
#--------------------------------------------------------------------------
# ● アイテムリストの作成
#--------------------------------------------------------------------------
def make_item_list
@data = []
@shop_goods.each do |goods|
case goods[0]
when 0; item = $data_items[goods[1]]
when 1; item = $data_weapons[goods[1]]
when 2; item = $data_armors[goods[1]]
end
if item && include?(item)
@data.push(item)
end
end
end
Window_ItemListを流用し、上記Winsow_ShopBuyのアイテムリストの作成を加えたもの。許可状態での表示可否については、"パーティが所持しているか"を判定させるようにした。あとは下記のように、選択肢に購入を表示させないようにした。ちなみに、"アイテムをリストに含めるかどうか"の書き換えについては、前述の海外サイトのカテゴリ判定をそのまま使っているため、紹介は割愛する。
ところで、先ほどのアイテム処理にも関連したことだが、RGSS2からRGSS3になり、新しい仕組み、たとえばシーンマネージャなどが全く判らず、使えないでいる。そのため、素材として手に入る鉱石を熔かし、その鉱石に応じた数のジュエルが手に入る、という専用のショップ処理も作ったのだが、そこに白の魔様のアイテム合成スクリプトを組み込めないでいる。RGSS2の時は、ショップ画面の選択肢で「合成、融解、やめる」ように改変し、手間の無い状態だったのだが、同じことがRGSS3だとやり方が変わっていて出来ない。あと、さば缶様の武器強化システムについても、以前行っていた、ジュエルを消費して強化させるという処理が組み込めない。かといって、連休が無いため、あまり時間も無いので、妥協し現状に甘んじている体たらくだ。
また、これは無印VXの頃からだが、スクリプト素材との競合だろうか、イベントコマンドでループ処理を行うとエラーが発生する。イベントコマンドのスクリプト内に表記しても、for、loop共にエラーとなる。ゆえに折角作ったランダムパーティの処理が使えない。というか、色々と不便だが、ラベルを使うことで擬似ループさせるように頑張っている。ただ、パーティの状態を調べる処理を行う際に、人数別で分けてそれぞれイベントを組む必要がある。実に面倒だが、それでも病院の処理が出来た。病院の処理とは、ドラクエの教会と同じようなもので、蘇生や解毒を行う処理だ。イベントの長さを節約するため、最後尾の仲間から順にチェックする挙動だが、それ以外は問題無く動いている。誰かの参考になるかもしれないので、ランダムパーティと併せて記載しておく。ちなみに、6人パーティを想定している点に注意してほしい。
ランダムパーティ(イベントコマンドのスクリプト用)
一度パーティメンバーを全て外し、ランダムでアクターを加えます。
for i in 1...$data_actors.size
$game_party.remove_actor(i)
end
for i in 1...6
$game_party.add_actor(rand($data_actors.size)+1)
end
ランダムパーティ(上記処理でエラーが出たため作り変えてみたものの、やっぱり同じエラーが出て閉口バージョン)
変数の操作[10..11] = 0
◆ループ
変数の操作[10] += 1
$game_party.remove_actor($game_variables[10])
条件分岐:変数[10] == $data_actors.size
ループの中断
医者の処理(一部)
追記
序でに、コモンイベントを利用した消耗アイテムを捨てる処理を作った。無駄に拘る人向け。下準備として、Scene_Itemクラス内、on_item_okに$game_variables[003] = item.idを記述しておく。これにより、アイテムを使った時、そのアイテムのIDが変数3番に代入される。この処理を作っておくことで、捨てられるアイテム毎に別々のコモンイベントを用意する手間が省ける。また、メッセージ中にアイテム名を表示させる機能を追加しておきたい。個人的には、ひきも記様のアイコンまで表示される追加制御文字を使用している。以下、コモンイベントの詳細。※条件分岐などのfalseルートに関してはほぼ割愛。
文章表示：\T[\V[3]]を捨てますか？
選択肢：はい の場合...
item = $data_items[$game_variables[003]]
$game_variables[13] = $game_party.item_number(item)
# 変数13番に捨てるアイテムの所持数を代入。
条件分岐：変数[13] >= 1
変数の操作：[10] = 1
数値入力の処理：[10] , 2桁
# 実は数値入力に使う変数は、現在その変数に入っている値が初期値として出てくる。たとえば、変数10番に23が既に入っているとしたら、入力する際に23という数値が出力されていて、プレイヤー側としては厄介だ。そのため、先に変数10番に1を代入しておく。これで、例えば決定キーを連打していた場合に、間違って大量のアイテムを捨ててしまう心配が無くなる。
条件分岐：変数[10] = 0
item = $data_items[$game_variables[003]]
$game_party.gain_item(item,1)
イベント処理の中断
条件分岐：変数[10] = 1
ラベルジャンプ：捨てる個数が1つの場合
# アイテムを0個捨てた。などという妙な文章を表示させないために、0個の場合は必須。1個の場合の条件分岐は細かい人向き。捨てる個数が1個だけの場合、また、所持していた数がそもそも1個しかなかった場合の分岐を、ラベル設定し末尾に置いておく。
item = $data_items[$game_variables[003]]
if $game_variables[10] >= $game_variables[13]
$game_party.lose_item(item,$game_variables[13])
$game_variables[11] = $game_variables[13] + 1
else
$game_party.lose_item(item,$game_variables[10]-1)
$game_variables[11] = $game_variables[10]
end
id = $game_party.alive_members[0].id
$game_variables[12] = id
# 要求された個数(数値入力で入力された数[10])が所持数(変数[13])より大きいか同じ場合、所持数の数だけアイテムを捨てる。変数[11]に、捨てた数より1つ多い数を代入しておく。また、要求された個数が所持数に満たない場合は、要求された数より1個少ない数だけアイテムを捨てる。これは、消耗品を使用してコモンイベントを呼び出した時点で、既にアイテムが1つ減っているために行う措置。先の代入命令についても、同じような理由から。この調整を行わないと、アイテムを10個捨てると指定したのに、実は11個減っているという不都合が起こる。そしてこの場合は変数[11]に要求した数だけ代入する。最後に、生存メンバーの中から先頭アクターのIDを変数10番に代入する。これは文章表示に違和感が出ないようにするため。(ただパーティメンバーから参照すると、死者が行動したようなメッセージになるため)
※まとめて捨てた場合のメッセージ
メッセージ：\C[6]\N[\V[12]]\C[0]は、
\C[5]\T[\V[3]]\C[0]を \V[11]個
まとめて投げ捨てた！
※1つだけ捨てた場合のメッセージ
メッセージ：\C[6]\N[\V[12]]\C[0]は、
\C[5]\T[\V[3]]\C[0]を 投げ捨てた！
※捨てなかった場合はメッセージ無しで、アイテムを1つ補充。(消耗アイテムは使った時点で1つ減っているため)
ここまで書いて、アイテムを捨てたマップIDや座標を変数に残しておいたら、後で同じ場所を調べた時に、自分で捨てたアイテムを拾えるように出来そうだ。と思ったが、アクションゲームでもないのに、それは凝りすぎのような気がする。いやしかし、ネットゲームならそうして暫く放置すると腐敗するといったことが当然で・・・。そうして今日も、ストーリーが進むことは無かった。
時間の概念に関しては、数フレームで1分、あとは現実時間と同じ進み方にした。どれくらい現実と似せたかと言えば、1月や12月は31日まであり、2月は基本的に28日までだが、現在の年数を4で乗除し、結果が0の時は閏年として29日まで。さらに4～12時間おきに天候が変化し、晴れ、曇り、雨、嵐、から無作為に実行される。ただし、1月、2月、12月に関しては、選択肢の中に雪が加わる。この天候に関しては、自分が関東出身のため、雪が珍しいという感覚から設定している。ちなみに、町の中では時間が経過しない。
スクリプトに関しては、海外サイトのカテゴリ別アイテムを導入している。戦闘以外の全てのシーンにおいて、アイテムがカテゴライズされるようにしてある。また、今回もデパート(百貨店)を作ったため、返品カウンターを設け、返品カウンターのみ、売却価格を100％(購入時と同じ値段)とした。売却専用のショップ処理だと、他所で購入したアイテムまで売却できてしまうため、売却選択画面には、そのデパート内で売っている商品のみ並び、所持していないアイテムについては、無効状態での表示にした。この処理に関しても、アイテム数が多くなるため、カテゴリー別に対応させることにした。返品可能として表示されるアイテムの取得方法は、メモから「返品可能」などと参照させるか迷ったが、この方法だと、デパートが各地に存在した場合、何処でも返品できてしまうため却下。返品ショップ用スイッチがＯＮの場合に限り、イベントコマンドのショップ処理で選択したアイテムを表示するようにした。具体的には以下。
#--------------------------------------------------------------------------
# ● アイテムを許可状態で表示するかどうか
#--------------------------------------------------------------------------
def enable?(item)
$game_party.has_item?(item, include_equip = false)
end
#--------------------------------------------------------------------------
# ● アイテムリストの作成
#--------------------------------------------------------------------------
def make_item_list
@data = []
@shop_goods.each do |goods|
case goods[0]
when 0; item = $data_items[goods[1]]
when 1; item = $data_weapons[goods[1]]
when 2; item = $data_armors[goods[1]]
end
if item && include?(item)
@data.push(item)
end
end
end
Window_ItemListを流用し、上記Winsow_ShopBuyのアイテムリストの作成を加えたもの。許可状態での表示可否については、"パーティが所持しているか"を判定させるようにした。あとは下記のように、選択肢に購入を表示させないようにした。ちなみに、"アイテムをリストに含めるかどうか"の書き換えについては、前述の海外サイトのカテゴリ判定をそのまま使っているため、紹介は割愛する。
ところで、先ほどのアイテム処理にも関連したことだが、RGSS2からRGSS3になり、新しい仕組み、たとえばシーンマネージャなどが全く判らず、使えないでいる。そのため、素材として手に入る鉱石を熔かし、その鉱石に応じた数のジュエルが手に入る、という専用のショップ処理も作ったのだが、そこに白の魔様のアイテム合成スクリプトを組み込めないでいる。RGSS2の時は、ショップ画面の選択肢で「合成、融解、やめる」ように改変し、手間の無い状態だったのだが、同じことがRGSS3だとやり方が変わっていて出来ない。あと、さば缶様の武器強化システムについても、以前行っていた、ジュエルを消費して強化させるという処理が組み込めない。かといって、連休が無いため、あまり時間も無いので、妥協し現状に甘んじている体たらくだ。
また、これは無印VXの頃からだが、スクリプト素材との競合だろうか、イベントコマンドでループ処理を行うとエラーが発生する。イベントコマンドのスクリプト内に表記しても、for、loop共にエラーとなる。ゆえに折角作ったランダムパーティの処理が使えない。というか、色々と不便だが、ラベルを使うことで擬似ループさせるように頑張っている。ただ、パーティの状態を調べる処理を行う際に、人数別で分けてそれぞれイベントを組む必要がある。実に面倒だが、それでも病院の処理が出来た。病院の処理とは、ドラクエの教会と同じようなもので、蘇生や解毒を行う処理だ。イベントの長さを節約するため、最後尾の仲間から順にチェックする挙動だが、それ以外は問題無く動いている。誰かの参考になるかもしれないので、ランダムパーティと併せて記載しておく。ちなみに、6人パーティを想定している点に注意してほしい。
ランダムパーティ(イベントコマンドのスクリプト用)
一度パーティメンバーを全て外し、ランダムでアクターを加えます。
for i in 1...$data_actors.size
$game_party.remove_actor(i)
end
for i in 1...6
$game_party.add_actor(rand($data_actors.size)+1)
end
ランダムパーティ(上記処理でエラーが出たため作り変えてみたものの、やっぱり同じエラーが出て閉口バージョン)
変数の操作[10..11] = 0
◆ループ
変数の操作[10] += 1
$game_party.remove_actor($game_variables[10])
条件分岐:変数[10] == $data_actors.size
ループの中断
医者の処理(一部)
追記
序でに、コモンイベントを利用した消耗アイテムを捨てる処理を作った。無駄に拘る人向け。下準備として、Scene_Itemクラス内、on_item_okに$game_variables[003] = item.idを記述しておく。これにより、アイテムを使った時、そのアイテムのIDが変数3番に代入される。この処理を作っておくことで、捨てられるアイテム毎に別々のコモンイベントを用意する手間が省ける。また、メッセージ中にアイテム名を表示させる機能を追加しておきたい。個人的には、ひきも記様のアイコンまで表示される追加制御文字を使用している。以下、コモンイベントの詳細。※条件分岐などのfalseルートに関してはほぼ割愛。
文章表示：\T[\V[3]]を捨てますか？
選択肢：はい の場合...
item = $data_items[$game_variables[003]]
$game_variables[13] = $game_party.item_number(item)
# 変数13番に捨てるアイテムの所持数を代入。
条件分岐：変数[13] >= 1
変数の操作：[10] = 1
数値入力の処理：[10] , 2桁
# 実は数値入力に使う変数は、現在その変数に入っている値が初期値として出てくる。たとえば、変数10番に23が既に入っているとしたら、入力する際に23という数値が出力されていて、プレイヤー側としては厄介だ。そのため、先に変数10番に1を代入しておく。これで、例えば決定キーを連打していた場合に、間違って大量のアイテムを捨ててしまう心配が無くなる。
条件分岐：変数[10] = 0
item = $data_items[$game_variables[003]]
$game_party.gain_item(item,1)
イベント処理の中断
条件分岐：変数[10] = 1
ラベルジャンプ：捨てる個数が1つの場合
# アイテムを0個捨てた。などという妙な文章を表示させないために、0個の場合は必須。1個の場合の条件分岐は細かい人向き。捨てる個数が1個だけの場合、また、所持していた数がそもそも1個しかなかった場合の分岐を、ラベル設定し末尾に置いておく。
item = $data_items[$game_variables[003]]
if $game_variables[10] >= $game_variables[13]
$game_party.lose_item(item,$game_variables[13])
$game_variables[11] = $game_variables[13] + 1
else
$game_party.lose_item(item,$game_variables[10]-1)
$game_variables[11] = $game_variables[10]
end
id = $game_party.alive_members[0].id
$game_variables[12] = id
# 要求された個数(数値入力で入力された数[10])が所持数(変数[13])より大きいか同じ場合、所持数の数だけアイテムを捨てる。変数[11]に、捨てた数より1つ多い数を代入しておく。また、要求された個数が所持数に満たない場合は、要求された数より1個少ない数だけアイテムを捨てる。これは、消耗品を使用してコモンイベントを呼び出した時点で、既にアイテムが1つ減っているために行う措置。先の代入命令についても、同じような理由から。この調整を行わないと、アイテムを10個捨てると指定したのに、実は11個減っているという不都合が起こる。そしてこの場合は変数[11]に要求した数だけ代入する。最後に、生存メンバーの中から先頭アクターのIDを変数10番に代入する。これは文章表示に違和感が出ないようにするため。(ただパーティメンバーから参照すると、死者が行動したようなメッセージになるため)
※まとめて捨てた場合のメッセージ
メッセージ：\C[6]\N[\V[12]]\C[0]は、
\C[5]\T[\V[3]]\C[0]を \V[11]個
まとめて投げ捨てた！
※1つだけ捨てた場合のメッセージ
メッセージ：\C[6]\N[\V[12]]\C[0]は、
\C[5]\T[\V[3]]\C[0]を 投げ捨てた！
※捨てなかった場合はメッセージ無しで、アイテムを1つ補充。(消耗アイテムは使った時点で1つ減っているため)
ここまで書いて、アイテムを捨てたマップIDや座標を変数に残しておいたら、後で同じ場所を調べた時に、自分で捨てたアイテムを拾えるように出来そうだ。と思ったが、アクションゲームでもないのに、それは凝りすぎのような気がする。いやしかし、ネットゲームならそうして暫く放置すると腐敗するといったことが当然で・・・。そうして今日も、ストーリーが進むことは無かった。
※コメント投稿者のブログIDはブログ作成者のみに通知されます