【解決済み】ボタン連打やタイミングで罠を脱出できるイベントの制作について

[Arkroyal]

皆さん、こんにちは。猿の悪夢からようやく解放されてゲーム作りに集中できるようになりました。

この場を借りて改めてムノクラ様とDarkPlasma様に感謝の言葉を申し上げます。



今回は私が作っている罠回避イベントについての質問ですが、

ゲージ化して作ることは成功したものの、いくつか自己解決が難しいことがありこうして質問することになりました。





1．脱出イベント中にキャラクターの操作を防ぐ方法

イベント中にキャラクターの操作ができないようにするには、イベント内にexecuteMoveの関数を空にするスクリプトを入れればいいんでしょうか？（もちろん終わりの部分にはもとに戻す）

もっといい方法がありましたら是非教えてください。

また戦闘中ではイベントが起こるとBUSY判定になりウィンドウが隠されるので、カーソル操作を禁止する必要はないのでしょうか？







2． 左から右に満たされるゲージの作り方

ピクチャーを利用したゲージは幅の拡大率を操作してゲージ化するため、XとYは固定されたままでその位置を中心に左右に広がる形になってしまいます。

なので私が考えたのは



1)色がついているゲージを表示しておく。

2)透明のゲージをその上に被せる。

3)変数の変化に応じて透明げーじのx座標を移動させる。



の方式ですが、2)において透明ゲージが色ゲージを隠せないのが問題です。

ピクチャー番号が大きいほど前に優先して描かれるのかと思いましたけど違ったみたいです。

もしピクチャー一枚で右方向に満たされるゲージを具現できる方法か、

私のアイデアにおいて間違っているところを教えていただけるのでしょうか？






皆さんのアドバイスを心から待たせていただきます。よろしくお願いいたします。

[WTR]

executeMove() が実行されなければ移動できないのは正しいと思いますが
関数を空にするスクリプト…というのが文字通りゲームの途中で関数の中身を書き換えるという意味であれば
思わぬ事故を防ぐためにも止めた方がいいと思います。

おそらくスイッチとかで脱出イベント中かどうか判定してるんじゃないかと思うので
そのスイッチで処理を分岐するように executeMove() を作り変えてしまうのが妥当ではないでしょうか。

戦闘中とかウィンドウとかカーソルとかは
このページの質問内容からは関連性を理解できなかったのでなんとも…

＞XとYは固定されたままでその位置を中心に左右に広がる形になってしまいます。
これはピクチャの原点が中央になっているためだと思います。
左上原点にすれば解決しそうです。

＞ピクチャー番号が大きいほど前に優先して描かれるのかと思いましたけど違ったみたいです。
違わないのですが、透明画像について勘違いされているように思います。
透明な画像を重ねても、その下にある画像が透明になるわけではありません。
透明な画像が重なるだけだから見た目は何も変わりません。画像の重ね合わせとはそういうものです…

[ムノクラ]

2． 左から右に満たされるゲージの作り方

ピクチャーを利用したゲージは幅の拡大率を操作してゲージ化するため、XとYは固定されたままでその位置を中心に左右に広がる形になってしまいます。

なので私が考えたのは



1)色がついているゲージを表示しておく。

2)透明のゲージをその上に被せる。

3)変数の変化に応じて透明げーじのx座標を移動させる。



の方式ですが、2)において透明ゲージが色ゲージを隠せないのが問題です。

ピクチャー番号が大きいほど前に優先して描かれるのかと思いましたけど違ったみたいです。

もしピクチャー一枚で右方向に満たされるゲージを具現できる方法か、

私のアイデアにおいて間違っているところを教えていただけるのでしょうか？

左から右に満たされるのイメージが逆だったらごめんなさい。
基本は原点を左上にすることで解決すると思います。

下記の例は右上に50%ゲージを表示してから、10%に減らす例です。
拡大率をマイナス値にすると、原点座標を中心として上下左右が反転されて表示されます。

◆ピクチャの表示：#1, blue-bar, 左上 (816,0), (-50%,50%), 255, 通常

◆ピクチャの表示：#1, blue-bar, 左上 (816,0), (-10%,50%), 255, 通常


と変化すれば右上を原点に短くなるのが分かると思います。

参考
https://fungamemake.com/archives/11444


※質問が複数に分けられる時はトピックを個別にしたほうが解決しやすいと思います。
今回は２つに分けられます。
個別にするとメリットは下記のようなものです。
1.タイトルがより厳密にできる
2.片方しか解決しないまま（返信数で）解決されたと勘違いされるのを避けられる。

[Arkroyal]

executeMove() が実行されなければ移動できないのは正しいと思いますが
関数を空にするスクリプト…というのが文字通りゲームの途中で関数の中身を書き換えるという意味であれば
思わぬ事故を防ぐためにも止めた方がいいと思います。

おそらくスイッチとかで脱出イベント中かどうか判定してるんじゃないかと思うので
そのスイッチで処理を分岐するように executeMove() を作り変えてしまうのが妥当ではないでしょうか。

戦闘中とかウィンドウとかカーソルとかは
このページの質問内容からは関連性を理解できなかったのでなんとも…

＞XとYは固定されたままでその位置を中心に左右に広がる形になってしまいます。
これはピクチャの原点が中央になっているためだと思います。
左上原点にすれば解決しそうです。

＞ピクチャー番号が大きいほど前に優先して描かれるのかと思いましたけど違ったみたいです。
違わないのですが、透明画像について勘違いされているように思います。
透明な画像を重ねても、その下にある画像が透明になるわけではありません。
透明な画像が重なるだけだから見た目は何も変わりません。画像の重ね合わせとはそういうものです…

アドバイスしてくださっておかげでフィールドでのQTEはできました！ありがとうございます。

原点の意味ってそういうことだったんですね。今まで誤解していました。

透明のゲージの件は…質問自体が…なんとも言えませんね。恐縮です。

残りはバトル中でのQTEイベント作りです。

戦闘中とかウィンドウとかカーソルとかは
このページの質問内容からは関連性を理解できなかったのでなんとも…

これはバトル中のQTEを作ることに関した質問でした。めちゃくちゃな内容で申し訳ありません…。質問を改めさせていただきます。



Q．バトル中にQTEイベントを発生させる方法

まずバトル中に上のようなQTEイベントを発生させるにはスイッチではできないことを確認しました。

正確にはQTEスキルを使用するとQTEスイッチをONにして、

そのスイッチを条件に発動するQTEコモンイベントを戦闘中に呼び出そうとしましたが、

フィールドの時とは違い、何も起こらないまま次のターンになりました。

（スイッチはONになっていることを確認しました。）

何がいけなかったんでしょうか？フィールドの時との違いがよくわかりません。

[Arkroyal]

左から右に満たされるのイメージが逆だったらごめんなさい。
基本は原点を左上にすることで解決すると思います。

下記の例は右上に50%ゲージを表示してから、10%に減らす例です。
拡大率をマイナス値にすると、原点座標を中心として上下左右が反転されて表示されます。

◆ピクチャの表示：#1, blue-bar, 左上 (816,0), (-50%,50%), 255, 通常

◆ピクチャの表示：#1, blue-bar, 左上 (816,0), (-10%,50%), 255, 通常


と変化すれば右上を原点に短くなるのが分かると思います。

参考
https://fungamemake.com/archives/11444


※質問が複数に分けられる時はトピックを個別にしたほうが解決しやすいと思います。
今回は２つに分けられます。
個別にするとメリットは下記のようなものです。
1.タイトルがより厳密にできる
2.片方しか解決しないまま（返信数で）解決されたと勘違いされるのを避けられる。

アドバイスしてくださり、ありがとうございます…！

質問のトピックを複数上げると、他の方々のトピックが流されるので迷惑にならないかと思い一つのトピックでまとめさせていただきました。

今後は気を付けます。気を使ってくださり感謝いたします。



逆方向にゲージを満たす場合は⁻数値を入れればいいんですね。

確かに座標には負数を使えましたよね。見逃してしまうところでした…！

[WTR]

フィールドでのQTEについてもう１点
executeMove() をどうにかするだけだとメニューは開けてしまうので
メニュー回りも同様に対処したほうがいい気がします。
Game_System.prototype.isMenuEnabled　あたりを弄って QTE スイッチが ON のとき false が返ってくるようにすればいいかな…

戦闘中の QTE イベントについてはなかなか難しそうな気がします。
QTE イベントそのものの作り方にも依ると思いますが
ボタン入力を監視して変数を加算する…とかいうのを並列処理でやっているのではないかと推測します。
戦闘中はコモンイベントの並列処理が動かないのでまずそれをどうにかしないと…
↓こんなプラグインはあるようです。
http://newrpg.seesaa.net/article/477740800.html

これで並列処理が出来たとして…

また戦闘中ではイベントが起こるとBUSY判定になりウィンドウが隠されるので、カーソル操作を禁止する必要はないのでしょうか？

これが課題として見えてくるわけですね。
１つずつクリアしていくしかないと思いますけど
パーティーコマンドウィンドウとかアクターコマンドウィンドウを一時的に閉じるとか対処が必要な気がします。

[Arkroyal]

フィールドでのQTEについてもう１点
executeMove() をどうにかするだけだとメニューは開けてしまうので
メニュー回りも同様に対処したほうがいい気がします。
Game_System.prototype.isMenuEnabled　あたりを弄って QTE スイッチが ON のとき false が返ってくるようにすればいいかな…

戦闘中の QTE イベントについてはなかなか難しそうな気がします。
QTE イベントそのものの作り方にも依ると思いますが
ボタン入力を監視して変数を加算する…とかいうのを並列処理でやっているのではないかと推測します。
戦闘中はコモンイベントの並列処理が動かないのでまずそれをどうにかしないと…
↓こんなプラグインはあるようです。
http://newrpg.seesaa.net/article/477740800.html

これで並列処理が出来たとして…

また戦闘中ではイベントが起こるとBUSY判定になりウィンドウが隠されるので、カーソル操作を禁止する必要はないのでしょうか？

これが課題として見えてくるわけですね。
１つずつクリアしていくしかないと思いますけど
パーティーコマンドウィンドウとかアクターコマンドウィンドウを一時的に閉じるとか対処が必要な気がします。

左右キーでゲージが変化するように作っていたので、メニューのことは完全に盲点でした…！指摘してくださりありがとうございます！


戦闘中はコモンイベントの並列処理が動かない、なので戦闘中では並列処理のqteコモンイベントが作動しなかったんですね。


QTEイベントについては、WTR様の推測通りに作っています。(隣でコードを見て下さったかのように大正解です。すごいですね…。)


とりあえずは家に帰り次第WTR様が教えてくださったプラグインを持って色々試してみて、

一人では解決できない問題や疑問などがあったらまた質問させていただきます。

この記事は閉じさせていただきます。ありがとうございました！