異世界チート転生RPG+NTR#11　【HPゲージを導入】

どうも アリテイシア です！

最近何とか落ち着きを取り戻しつつあります（仕事の話）

前回の雑記の続きの話をします。今日の内容は『並列処理とは何ぞや　＆　ツクールの重さの原因』についてです

興味ない方は目次で飛ぼう(^^)/

雑記（ツクールMZの話）

これまではツクールにおける『ピクチャ』の扱いについて色々語ってきました
結論として 『RPGツクールで高解像度の画像を使うのは無意味　＆　初心者向けだがツクールではピクチャを扱いづらい』 ということ

今日はゲーム開発前に調べていた「ツクールは動作が重い」とか「すぐ強○終了する」とか言われているところを深掘りしていきます

えーこれはMZを弄り始めた制作開始前に確認していた内容ですが、画像などが無かったので撮りました

さてまず『並列処理とは何ぞや？』
A.プログラムの実行中や待機中などに『並行して実行しているプログラム』のことです

今作の異世界チートで言うと目をぱちぱちさせる動作とかおっぱいをモミモミするのがそれにあたります
もっと言うと『足踏みやそこらを移動するNPCの動作』も並列処理ということが出来ます

上を踏まえた上で
『ツクールは動作が重い』『すぐ強○終了する』の話をしていきます
しょっちゅう『強○終了する』のはRPGツクールMVくらいです
理由は実験のあとで説明します

実験

◆条件
今回はプログラムの重さという事でCPUについてのみ話していきます。（巷のゲームでいうとメモリクラッシュとか話がたまに出てきますが、あれはメモリは画像などデータの保持的な事なので今回はパスです）

◆主な実験内容
1.並列処理って重いの？
2.ツクールの動作が重いのはなんで？

◆実験場
こちらが実験場の環境です

CPUは裏で何かたまに走るけど、特に重たいアプリを使わないでいれば15％～40％を推移する、平均20％使用ってところですね
メモリは80％……まぁWindowsだけで60％～80％はいつもあるので普通ですね、こんなもんです今回は関係ないですし

実際のゲームを起動するとかなり上がりますね
移動してるとそこそこの頻度でカクつきます。まぁ色々データを処理しているのでしかたにゃあ

じゃあ再起動して実験開始！

①並列処理を実行しよう！

ではまずこんな何もしない並列処理を500個コピーして走らせていきましょう

う～ん、何もないフィールドではヌルヌル動きますね。500個もプログラムが走ってるとは思えない
でも裏ではたまに100％に近づいてカクつきそうになってますね……元々ツクール起動しててもこんな動きなので変化を感じにくい。というか変化してますか？ってレベル

②だったらもっと並列処理しちゃおう！！！

MZさんはコモンイベントが最大9999個つくれるのでおよそ１万もの何もしない並列処理を増殖させてスタート！

ムムッ( ﾟДﾟ)
カクつくというほどではないですが、ズズズズズズーというような動きをします結構重いかも、画像を動かすなどがあったら結構致命的な重さになりそう！
裏でも100％を超える瞬間が何度もある様子、なぜズズズズ動くのか？並列処理を優先している感じかな"(-""-)"　わからんけど

③並列処理とは違うけど『ループ』って機能があるんです

そういえば『ループ』が重いって誰かが言ってたなぁよし試してみよう
ってことで並列処理にぶち込んでみました

ヤバイッ！　死ぬ！　助けてっ！！！ｗｗｗ
カクカクどころかゲームにならないレベルの遅延……。ループの圧倒的な破壊力が伺えますね。並列処理はおそらく『何らかの制限』か『監視』のような性質を持っているようで、ループ君みたいに全力で何もない処理を無限に繰り返さないような仕組みがあるようです('ω')
ループを使う際は必ずウェイトを挟みましょう！ｗ

④MVやMZが重いのはどういう訳か？

これは以前どこかの記事で読んだことなのですが『解像度が高いと重い』ということ

RPGツクールはMVから解像度を変えられるようになっていますただこれはMVのプラグインが元でその後公式に採用された機能だったはず
実際に解像度が高いと重いというのなら何故そうなのかを検証しなくては！

　考察
重くなるって事は処理する情報量が増えるという事。つまり処理している情報の上限を見る方法が必要だ……となるとNPCに特定のルートを走ってもらいどこまで処理するのかを解像度の違いで検証すればいいのだ！('ω')　←答え知ってる奴の顔

よしローザ、君に決めた！　いけぃ！

　検証

▽1280x800

▽816x624

　結果
以上のように1280x800の高解像度ではX軸(横)26マスY軸(縦)16マス分、816x624の初期設定ではX軸(横)17マスY軸(縦)14マス分、先の情報を取得実行している事が分かった

高解像度の方はプレイヤーマスが中央に位置して遠方マスが途中で切れているが実際に描画しているのは縦27横17マス。初期設定では48x48に収まるようサイズ設定になっているので横17マスx縦15マスが画面に描画されている。更に情報を取得し実行するのが高解像度では横12マス縦7マスそれぞれ左右上下に広がっていて、初期設定では横8マス縦5マスそれぞれ左右上下に広がっている。

高解像度が51x31＝2201マス
初期設定が33x25＝825マス

それぞれキャラクターを情報収集・実行していることになる
私の想像だが、マップの描画も同じように処理されている気がする……検証の方法は無いが、広大なマップを全部描画するわけはないし、移動時のカクツキはそれなりに強いので多分そうなんじゃないかと思います( ﾟДﾟ)

とはいえスクリプトを用いた瞬間移動をしてもマップの崩れが発生したりはしない。まぁ当たり前かマップデータに書かれた読み込み済みの画像を張り付けてるだけなので、コンピュータ君の得意分野である計算処理のようなもの

また、自動実行や並列実行のイベントに仕込まれたプログラムはマップ上のどこに居ても実行されるので……キャラクター描画に何かあるのだと思います……"(-""-)"

というわけで、キャラクター(NPC)ってそんな重いんか？ってことについて検証してみなければならない。これを放置してカクカクさせることをカミサマンは許しはしない( ｀ー´)ノ

⑤NPC（イベント）って重いの？

ドドン！　プリシア工場！
499体ものプリシアのハーレムの中をリード君が行く！
きしくも最初の並列処理とほぼ一緒の数になりましたね('ω')
足踏みするだけの全く同じ動きをするキャラクター約500体がどれほど重いものかよ……！？

うぬううううう……！　結構重いぞ！　並列とは違うのだよ！　並列とは！！
並列処理１万に近い動きなんじゃなかろうか……？プリシアの海に隠れてほとんど見えないけどｗｗｗ
スプレットシートだから画像の読み込みが重くてこうなっているとは全く思えない
何を実行しているのかわからぬ！恐らく『動かない』などを実行して居るんじゃないかな……？

キャラクターにはそれぞれ設定できる数値があり『画像』『描画方法』『移動』『足踏み』『向き』『移動速度』『移動頻度』『プライオリティ』『不透明度』などなど
キャラクターがいる（空白のイベントを設定している）だけでも処理が必要になる模様です

つまりキャラクター（RPGツクールではイベントと呼ばれるもの）はそこそこ重い！
解像度と掛け合わせると驚異的な威力を発揮するのではないかな……( ﾟДﾟ)

さて、重い原因が何となくわかってきました。

まず解像度！　大きいほど処理する情報がけた違いに増えていく。
次にキャラクター！　キャラ１体で1つの並列処理の比ではないほどの並列処理がされている（多分）

並列処理は意外にもさほど重くないという事がわかりました！！！

コンピュータ君は計算が得意だから、並列処理にウェイト無しループなどの負荷をかけなければあまり重くはならないようです

（処理上問題が無ければウェイトを1フレームかませることで負荷がほぼなくなります）

さて最初にＭＶは処理落ちすると書きましたね。多分実験中もＭＶだったら何度か死んでいた事でしょう。

なぜＭＶだけなのか？

これは簡単です。解像度を変えれる機能をつけてしまったからです。いわゆる『反応待ち』の状態になるとＭＶの場合大体強○終了するのです。しかも後にＭＺでは実装されることになる強○終了するのを防ぐ機能を実装せずにサポートが終了（正確にはアップデート終了だったかな？まぁほぼ同じ意味だよね）したので、バリバリ強○終了するゲームを生み出すツールになってしまったのです(´Д⊂ヽ
ＭＺになった時点でプレイ側が強○終了するのを防ぐ機能が付いていたかも（少なくとも制作サイドはＭＺになって頻繁に強○終了しなくなってめちゃめちゃ楽になった）……詳しくはそのスジの人に聞いてね

早い話、サ終したから　もう無理！　それだけ。

何かの処理だか読み込みが追い付かないと強○終了するなんてとんでもない！
ユーザー殺しといっても過言ではない。少なくともＭＶで高解像度でお届けするのは避けた方がよろしいです。プログラムの腕に自信が無い限りは……！( ﾟДﾟ)

突然の強○終了に筆者の心が幾度へし折られた事か！　…そして画面の前の同人エロゲーマーも頷くことでしょう！

ちなみにMZで画像の読み込みが終わっていない状態があっても表示が追い付かないまま処理したり待ったりします（表示方法の問題。ピクチャ表示や遠景など処理の仕方に若干の違いがみられます）
おそらくMVでも同じ処理をするかと思いますがMVを主軸にする気が無いので実験は行ってません。強○終了するとかいう結末も見たくないですし。猛者が居たら是非その実験結果を教えてください

以上が本考察・実験での成果となります
面白かったら🌟いいねも押してくんなまーしー(^^)/

興味持ったらアナタも同人ゲー作り始めてもいいのよ？('ω')

異世界チート転生RPG+NTR#10

どうも アリテイシア です！

今回はプログラムも書けないド素人がRPGツクールの 『ピクチャ移動』 というプログラムについて語ります

続きの容量（軽量化）の話をしようかと思ったのですが、前回のコメ返信の言い訳のような内容となります
興味ない方は目次で飛ぼう(^^)/

雑記（ツクールMZの話）

これまではツクールにおける『ピクチャの表示』について限定して色々語ってきました
結論として 『RPGツクールで高解像度の画像を使うのは無意味』 ということ

しかしゲームとなれば当然ビジュアルに拘りたいと思うもの。見やすくしたらその存在が気になってしまったり、一長一短を繰り返し出来上がっていきますからね……！('ω')

そんなビジュアル構成上ピクチャを表示しそれを『移動・変形』したりすることはゲームにおいて非常に大切である！
ということで、RPGツクールの『ピクチャ移動』について掘り下げていきます

ピクチャを『移動・変形・透過』したりできる！のが『ピクチャ移動』！！！　…………なのですがぁ、

そんなRPGツクールのビジュアル性を担う『ピクチャ移動』が決定的に扱いづらい理由をまずお話ししようと思います
こちらです

これはエロステータスの増加を変数入力するだけで並列処理してしまおうというプログラムのピクチャ表示系の一部になります（トリアコンタン様の動的文字列ピクチャプラグインを使用しています）

同トリアコンタン様のメッセージスキッププラグインを使っている関係（あえてウェイトを入れない限り速すぎて一瞬で文字が通り過ぎる）からウェイト無しで並列処理するようにしてあります。並列処理の中にウェイトを挟むとその間に入力された変数の処理をしてくれません（処理が飛ぶ感じ）

さて……それはさておき、ツクールの問題についてです
『ピクチャの移動』というコマンド、こいつが問題なんです( ﾟДﾟ)

『ピクチャの移動』というコマンドだけで『座標』『不透明度』『伸縮率』『イメージング・動作時間』の全てを入力しなければならないのです。唯一の救いは座標だけは変数も使える……。というか『それだけ』動作時間も最大999フレームとなっていて17秒以上の操作は受け付けません。（やり様としては途中までの処理を何度も差し込んで。つなげていけばできるが、並列処理でやると別の問題が生じる）

例えば時間経過でどんどん透明になるように10秒間ピクチャ移動で命令します。これをある一定の段階（プレイヤーの操作）で移動させたい時、命令が上書きされて移動して終わってしまいます……　なぜか……？　不透明度を0にする600フレームの命令が新たなピクチャ移動の命令、例えば……不透明度が100ほどまでいっている状態新たな命令『X軸500Y軸500不透明度255動作時間60フレーム』があったとした場合、画像が1秒で指定の場所に移動します。その1秒の間にゆっくり透過してたものがくっきりと表示されながら。つまり、命令を上書きして100だった不透明度への命令が255で終わってしまうのです

ちょっと何言ってるかわかんないと思うので、情報を足して視覚化してみます

このようなプログラムを実行します
すると

こうなります('ω')

（プログラムだから当たり前だけど）命令を無視しない。後発の命令が『座標』『不透明度』『伸縮率』『イメージング・動作時間』の全てを支配してしまうのです。ただそれぞれの与えられた命令を着実に実行してくれます！実に面白い

これを解消する方法は簡単です
『思惑通りの状態になるまでウェイトを入れて待たせればいい』
これは早い話、プレイヤーが処理待ちを常にさせられるという事でもあるので、ものすごくテンポの悪いゲームになるってこと

ピクチャ色調はフェード指定（動作時間）もあるのになんで……なんで不透明度は
せめて不透明度くらいは別のコマンドで実装して欲しかった
ピクチャの色調とか回転とかあるけど、ピクチャの移動だけ稼働率がヤバい！！！
ピクチャの回転とか使いにくすぎて誰も使わねーよ！( ﾟДﾟ)
……誰が使うんだ画像がクルクル回るだけのこの機能。角度や動静をコントロールできるならともかく回る方向と速度しか弄れないし、最低の速度でも1秒で20度以上も回転するとか誰得なん！？

座標はともかく、他の部分で変数が使えないのはかなり痛い。ピクチャの状態を判断してそれを反映できない訳ですから……ツクールは初心者向けだけど、凝りだすと中々に難しい部分が見えてくるツールなのです"(-""-)"

このような問題はプラグインの導入で簡単に解決する場合があります。しかしピクチャ系のプラグインは個人的な見解として『競合しやすい』背景があり、導入しても意図した動作がされなかったり別のプラグインの動線を乱す場合もあるので初期段階でどのようなゲームにするのかをしっかり考えて導入する必要があります(´Д⊂ヽ

む　ず　か　し　い　ね　('ω')

関係ないけど、量子コンピュータはすごいね！
スイッチがONでもOFFでもありどちらでもない状態から、正解っぽいを探し出すという処理手順らしいけど……　自分で言ってても、言ってることの意味がまったくわかりません！( *´艸｀)

並列処理って何ぞや？　と思われたかと思いますので、次回は並列処理とゲームの重さについて話そうかなと思います

興味持ったらアナタも同人ゲー作り始めてもいいのよ？('ω')

異世界チート転生RPG+NTR#8

どうも アリテイシア です！

毎度御贔屓いただきありがとうございます！
本日はネタバレを含めた作品紹介をしますので見たくないよって人はジャンプしたってやぁ(^^)/

雑記

ツクールMZのお話

以前#1で『高解像度のピクチャの縮小に向かない開発ツールだよ』と言いましたが、ツクールの拡大縮小の描画仕様についてもう少し深く掘り下げていきます

Ci-enに投稿すると画像ファイルはjpegに変換圧縮されてしまうので微妙な違いが全然分からないので、お伝え出来ないかもしれない事を先にお詫びしておきますm(_ _)m

①

②

③

④

⑤

以上の事からツクールが美麗な高解像度のピクチャの表現向かないツールだという事がわかりますね？

ツクール自身が行う拡大縮小の描画処理の影響は『50%を越えて縮小するとカクつき、拡大するとボヤケる』と端的に言うことが出来ます
また②と③は上の画像ではほとんど差が見て取れないほど酷似していますが同じ画像ではありません

②

くり抜いて拡大するとこんな感じで差が出ています

ちなみにちょうどゲーム画面サイズに縮小した画像を拡大すると

Ci-enスライドショーで見ればその違いが分かるかと思いますが③が一番忠実に再現しています。
なのでピクチャ表示の100％の信頼度はかなり高いと言えます。逆を言えばそれ以外はあまりよろしくないといった感じ
ツクール持ってる人はご自身でお確かめあれ～！
ツクールを使う以上はゲーム画面と同サイズへの縮小をお勧めする理由はこういう事です

また高解像度のデータをツクールで使ってもあまり意味が無いという事はつまり『データ容量を軽減できる』という利点につながります

ちなみに今回使った②と③のデータ容量の差で言うと2.5倍になります。6割ほど軽量化しかなりデータ容量が増えるんじゃないかと思います。ピクチャデータをかなり縮小できます（軽量化の話はまた別で話をしたいと思ってます）
ツクールに限らずゲームにおいては、画像の解像度の大きいピクチャ表示は処理的に重くなりがちです。ツクールMZで処理待ちが発生する事ってことは、MVだと処理落ちする可能性が高いという事ですし……( ﾟДﾟ)ﾑﾊｧ

早い話、ツクールを使ったゲーム制作はピクチャの解像度（データ容量）がある方が作者の表現したい方向からより乖離していくという事ですね

残念ですが、事実です(´Д⊂ヽ

またツクールではボヤケて拡大されていくという事から、ボヤケた（ボヤケていい）ピクチャは解像度を小さくしてツクール側で拡大して表示できるという成果を得ました！……というか#1の時点で知ってたので、既に使ってます。実は一枚絵の時に使用するムラムラムンムン湯気（あれなんて言うんだろう……えっち湯気？むわぁ～ん？）は半分どころか１／４に縮小したものをツクール側で拡大して使ってます

まだ全部のCG抽出してないですけど、ツクールMZを使う限り……私の作品のデータサイズは500Mすら超えないです！

何故かって？

……だって1～2シーンに使うCG差分含めても1MBにすら達しないんです。体験版v0.1時点で300M、Windows11が標準搭載してるZIP圧縮したデータが150M……基本CG300枚とかこっちが無理だし、超えられる要素がどこにもない！！！これは流石に笑っちゃう( *´艸｀)ﾌﾟﾌﾟﾌﾟ

フルボイスとかすれば超えてくるんでしょうが、BGVくらいでは超えないんじゃないかな