ツクマテ

ツクールMV作品におけるエラーでの強制終了においての情報を集めております。
（Webブラウザ版ではなく、PC版です）

SNSやレビューサイトなどで「プレイ中、二回落ちた」とか「戦闘開始直後にいきなり落ちてプレイ出来なかった」という報告をよく見かけるのですが、私のPC環境下（Mac OS X(10.10.5)、Windows10）においてはプラグインの問題以外での強制終了にはいまだ遭遇した事がありません。

重くなったりBGMが遅延したりするのはスペックの問題であるとは思うのですが、
落ちる状況では実際どの様なエラーが発生していて、どの様な原因、対策が考えられるのでしょうか？
情報いただければ幸いです。

お疲れさまです。

こちらも厳密な検証を行ったわけではないので、ある程度予測を含んでいることをご了承ください。

強制終了ですが、画像をキャッシュして表示しようとするタイミングでクラッシュする場合があるようです。
この場合、ツクール上でエラーメッセージ等は表示されず、なんの前触れもなく突然画面が閉じます。

表示しようとしている画像のサイズ（容量ではなく縦横の大きさ）が大きいほど、
また一度に読み込もうとする画像が多いほどクラッシュする危険が高まると思われます。

よって、マップ移動や戦闘開始直後、もしくはピクチャの表示で一度に大量に表示したタイミングで落ちる可能性が高いです。
戦闘アニメ画像なんかもサイズが大きいので要注意ですね。

なお、ここでいう表示というのは、必ずしも実際の画面に表示されることと同義ではありません。
キャッシュを開始した時点で、内部で以下の処理が行われるのですが重いのはこの二つの処理です。

1. 画像ファイルをロードする。（非同期実行。ブラウザの場合は数秒かかる場合もある）
2. ロード完了後、ロードした画像を描画する。（同期実行）

描画エンジンのPixi.jsやツクールのコアスクリプトにも、細かい点で最適化されていない部分はあるのかと思いますが、
突き詰めるとそもそもHTML5（ツクールMVで画像の表示に使用されている開かれた技術）自体が重いという壁にぶつかるので難しい問題です。

可能な対策としては、とにかく負荷を分散させることだと思います。
例えば、「並列プリロードプラグイン」では、上記の1.の処理だけを事前に行い、2.の処理は画像が実際に要求されたタイミングで行うことで負荷を分散させています。

・並列プリロードプラグイン
https://raw.githubusercontent.com/triac ... Preload.js

また、戦闘アニメを自作している場合、画像の色相を無闇に変えない方がいいかと思います。
色相を変えると、別の画像として扱われ再度キャッシュが行われるからです。
例えば、データベース上で色相119と色相120の画像を指定している場合、見た目はほとんど変わらなくても別々にキャッシュしてしまうので統一した方がいいかと思います。

正直、まだ分かってない部分も多々あり、また1.3.0の本体アップデートによって状況が変わってくる可能性もあります。
現状テストプレーで問題が発生しておらず、またクラッシュの報告もあがっていなければ無理に対策する必要もないのかなと思っています。

＞トリアコンタンさま
情報ありがとうございます。なるほどですね。
特にファイルサイズではなく画像の大きさが関連しているというのは初めて知りました。
並列プリロードによってある程度の負荷を分散させるのは一度試してみたいと思います。

ver1.3.0はPixi.jsのバージョンアップによって、かなり描画まわりが改善されるという話は聞いていますが、確かに現状で無理に対策に講じるよりは様子見が妥当かも知れませんね。

こんばんは。

現在、ツクールMVでNPCとのシューティング対戦を作成しているのですが（何を作ってんだかｗ）、メモリが結構な勢いで溜まっていき、数分後にはクラッシュしました。

動作としては、
・プレイヤーの位置を１フレーム単位で監視し、そこに透明なイベントを集めます。
・その後、YEPのボタンコモンイベントで指定したキーを押すことでスイッチがONとなり、弾丸を発射します。
・発射された弾丸の位置は４フレームごとに監視され、このフレーム間動きが無かった場合に消失します。
・対象に当たった際（４フレーム動きが止められた場合）には、指定位置でエフェクト用のイベントと入れ替わり、エフェクトイベントが代わりに一定時間その場にとどまります。
・エフェクトイベントでは、５フレームごとにプレイヤーとイベントの位置を監視しており、これらの位置が一致している場合にフラッシュなどの演出処理を行います。
・一定時間後、エフェクトはページを切り替えられて、処理のないイベントに変わります。

これらの動作を繰り返して、一定の条件を満たすとゲームを終了するのですが、タスクマネージャーを開いてみたら、13-15MB/秒程度の速度でメモリが増えていき、数分後にはクラッシュしました。

たぶん、数フレーム単位での監視処理がメモリ増加を引き起こしていると思いますが、対処方法がわかりません。（こういったところは全く知識がないので）


何か、良い対処方法があったら、助けてください。

ネコタ様
お世話になります。
そのシューティング対戦ほとんど並列処理のイベントで構成されているようですね。
いくらなんでもクラッシュすることはそうそうないと思いますが・・・。

１プレイヤーの位置を１フレーム単位で監視し、そこに透明なイベントを集めます。
だめです。必ずイベントコマンド「ウェイト」で猶予を持たせてください。
あと、どうして透明なイベントを集める必要があるんですか。

２その後、YEPのボタンコモンイベントで指定したキーを押すことでスイッチがONとなり、弾丸を発射します。
スイッチが条件のコモンイベントまたはマップイベントでプレイヤーの近くにイベントを移動させた方が
多分分かりやすくなるんじゃないかと思います。

３発射された弾丸の位置は４フレームごとに監視され、このフレーム間動きが無かった場合に消失します。
問題ないと思います。ただ、弾丸の数が少なくて連射はできないものとイメージしております。

４対象に当たった際（４フレーム動きが止められた場合）には～
３の消失をトリガーに発生するイベントのようですね。

５エフェクトイベントでは、５フレームごとにプレイヤーとイベントの位置を監視しており～
プレイヤーの位置は１番で取得しているので参照するだけですね。
イベントの位置とはどのイベントなのかが深い謎に包まれています。
多分エフェクトイベントは一つだけで
位置は被弾するイベントの座標だと思いますが・・・。
これはそんなに重くないかと思います。

６一定時間後、エフェクトはページを切り替えられて、処理のないイベントに変わります。
エフェクトを発生させる時の条件ページのみで足りるはずなので、イベントページは１ページでは？

まっつＵＰ さんが書きました:ネコタ様
お世話になります。
そのシューティング対戦ほとんど並列処理のイベントで構成されているようですね。
いくらなんでもクラッシュすることはそうそうないと思いますが・・・。

１プレイヤーの位置を１フレーム単位で監視し、そこに透明なイベントを集めます。
だめです。必ずイベントコマンド「ウェイト」で猶予を持たせてください。
あと、どうして透明なイベントを集める必要があるんですか。

２その後、YEPのボタンコモンイベントで指定したキーを押すことでスイッチがONとなり、弾丸を発射します。
スイッチが条件のコモンイベントまたはマップイベントでプレイヤーの近くにイベントを移動させた方が
多分分かりやすくなるんじゃないかと思います。

３発射された弾丸の位置は４フレームごとに監視され、このフレーム間動きが無かった場合に消失します。
問題ないと思います。ただ、弾丸の数が少なくて連射はできないものとイメージしております。

４対象に当たった際（４フレーム動きが止められた場合）には～
３の消失をトリガーに発生するイベントのようですね。

５エフェクトイベントでは、５フレームごとにプレイヤーとイベントの位置を監視しており～
プレイヤーの位置は１番で取得しているので参照するだけですね。
イベントの位置とはどのイベントなのかが深い謎に包まれています。
多分エフェクトイベントは一つだけで
位置は被弾するイベントの座標だと思いますが・・・。
これはそんなに重くないかと思います。

６一定時間後、エフェクトはページを切り替えられて、処理のないイベントに変わります。
エフェクトを発生させる時の条件ページのみで足りるはずなので、イベントページは１ページでは？

回答ありがとうございます。

１については、今日、車に乗っている時に気づきました（笑）なんで集めてたんだろう？（笑）一応、１フレームウエイトは入れていました。

２、これは１と関連しているので、そうしようと考えていた所でした。

３、弾丸の数は一応10発用意しています。自動回復が間に合いそうなので、この位でも結構連射できます。

５、エフェクト用イベントの位置にプレイヤーが重なるとダメージを受ける仕様なので、プレイヤーとイベントの位置をここで監視しています（正確には、監視しているのはプレイヤーの位置だけでしたね。エフェクトイベントの位置は動かないので条件分岐で参照しているだけでした）。複数の弾丸により、マップ上に複数のエフェクト用イベントが滞在できるので、対戦相手と自分で理屈上は最大20個できます。

６、これは、イベントコマンドで｢イベントの位置交換｣の操作をした際に、条件を満たしたイベントのページが存在しないとのイベント交換が行われなかったため、空のページを用意させました。ただ、この処理を作っていた段階の話ですが、何故か変数301番だけが増減操作を行うと10倍された数値で処理されるバグがあり（なにかのプラグインで使われている？-１と入力すると-10ずつされていくことに気が付きましたので）、うまくイベントの条件が働かなかったこともあります。それ以降は試していませんので、また後ほどこの操作も試して見る予定でした。


とりあえず、重そうなところは最初の集める処理だと思うので、ここを修正する予定でした。修正が終ったらまた書き込みますね。

取り急ぎ、失礼します。

まっつUP様

おはようございます。
色々と試してみて、とりあえず、メモリを喰ってる原因が分かりました。

プラグイン以外の処理のせいかと思ったら、原因はプラグインでしたので、また別途トピを立てようかと思います。


変数301番の件ですが、こちらは原因が未だに分かっておらず、たぶん、イベント交換で移動されないのではなく、イベント交換後に消える時間が本来300フレームかかるところ、変数301番を使っていたために10倍速の30フレームで処理されていたため、見えなかったのだと思われます（とはいえ、30フレームなら一瞬見えそうなものですけど）。

問題ない変数を利用したら、空ページを削除しても問題なく動作しました。


お手間をおかけしました。
また、別トピにてよろしくお願いします。