ゲームの容量削減・軽量化について

[スズラン]

　長文失礼します。

　ツクールMVを購入して約ひと月ですが、
ふとこのまま制作をつづけた時の容量について気になり
今からでも——仕様変更が容易な今だからこそ削れるところは削っていこうと思いました。
　しかし私はツクールMVについてあまり詳しくないのでお知恵を借りようと思った次第です。
　質問は以下の通りです。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

１．マップについて
現在トリアコンタン様の半歩移動プラグインを使用していて
半歩分ずれた置物などはイベントを用いて描画しているのですが

1. イベントを使わず半歩ずれたタイルを作成しそれを使用する
2. イベントもタイルも用いず遠景とリージョンによる通行判定でマップを作る
3. 現在のまま（イベントをたくさん配置）

だとどれが一番容量を抑えられますか？


２．イベントはマップ内で記述するのと
マップ上ではコモンイベント呼び出しだけ書いて詳細はコモンイベント内に記述するのとでは
どちらが容量を抑えられますか？


３．一つのイベントページ内に長文を書くのと
細かくページ分けをしたり複数のコモンイベントで分割するのとでは
どちらが容量を抑えられますか？


４．データベースで私はよくあとあと追加することを見越したり確認しやすくするために
スキルや武器などを分類ごとに50や100刻みで区分けしているのですが、
最終的に使用しなかった——要するに空欄となるIDは容量に影響しますか？
少しでも影響するのであれば隙間なく詰めようと思います。


５．ダメージ計算式はあまり長くないほうがいいですか？
個人的にはパッシブスキルなどで細かくアイテムの種類や特定の魔法ごとに
効果を上昇させるシステムを採用したいので計算式に
『特定のスキルを所持していたら』を複数組み込んでいるのですが
動作に大きく影響するのであれば考え直そうと思います。


６．データベースの量はそこまで容量には影響しませんか？
武器強化システムを作りたいのですが、
同名の武器をたくさん用意する方法をとるので
武器の数がそれなりに多くなりそうです。


７．このサイトからの引用ですが、

『ツクールMVの保存は保存回数ごとに
　その記録データを保存されている可能性があり、
　容量が蓄積されていくために
　保存するごとに編集時のエラーが発生しやすくなるのです。』

これはつまり編集時にセーブすればするほど重くなるということですか？
1分に1回くらいのペースでセーブしないと気が済まないセーブ魔なので
これが事実だとすると割と厄介です......

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

　よければ回答していただけると助かります。

[Plasma Dark]

配布またはアップロードするゲームデータの容量の話であれば、1～7全て影響が全くないか誤差です。
マップ、イベント、データベースはテキストデータですので、ゲームデータ全体から見れば小さいです。
確かにデータベース上の空欄も配布データには含まれますが、せいぜいアイテム1つにつき300B程度です。

一度、開発途中の状態であってもデプロイメントしてみて、容量を一番大きく取る場所をご確認されると良いかと思います。
だいたい、容量を大きく取るのは音声と画像です。
容量を気にされるのであれば、これらを切り詰めていくことを考えることになるでしょう。

5. ダメージ計算式

あまり複雑な式にするとパフォーマンスに影響が出るかもしれませんが、元々1行しか書けないところなので問題にはならないかと思います。

7. MVエディタでプロジェクトを保存すると重くなる

環境次第では、保存時にエディタが落ちたり、プロジェクトデータが壊れたりする現象が報告されています。
該当記事の記述は、環境次第でメモリリークする可能性があるという話だと思われます。

保存回数はゲームデータの容量には影響ありません。
プロジェクトデータの破損は恐ろしいので、こまめにバックアップを取ったほうが良いですが、気にするべきはそれくらいです。

[スズラン]

Plasma Dark 様
回答ありがとうございます

　追加で質問なのですが
マップイベントを大量に配置することで容量ではなく
処理のほうが重くなる可能性はありますか？
また処理が重くなる場合イベントの有無でも変化するものなのでしょうか？
　大量のマップイベントでマップの置物を設置しているので
この辺りがどうしても気になってしまいます。

[Plasma Dark]

マップイベントを大量に配置することで容量ではなく
処理のほうが重くなる可能性はありますか？

よっぽど並列処理で変なことしない限りにおいては、これも誤差だと思います。
少し古い記事ですが、MVにおいてマップイベントを999個置いてみたという実験結果もあります。

[スズラン]

Plasma Dark 様

　ありがとうございます。
そのあたりも特に考慮する必要はないのですね。

[スズラン]

　再び失礼します。
現在キャラメイク的なシステムを検討しており
立ち絵の画像について少し質問です。

　立ち絵を体、顔、髪、服などのパーツに分けて重ねる方法だと画像は少なく済むけど同時に表示するピクチャが増えて重くなり、
パーツなどを全てまとめた一つの立ち絵をたくさん用意する方法だと表示するピクチャは減るもののゲームの容量自体が大きくなると聞きました。
　この場合どちらの方法をとるべきですか？

[Plasma Dark]

差分の総容量や配信形式による制約、開発者から見た管理のしやすさ次第です。

結合済みの立ち絵画像を1枚用意して、それが何枚必要になる見込みかどうかから計算すると、立ち絵だけでどれだけの容量が必要になるかがわかります。
これがゲームの容量全体に対して無視できず、パーツごとに分割した場合にしっかりと容量が抑えられるのであれば、パーツごとに分けて差分を管理したほうが良いですし、そうでなければ管理しやすいほうを選択すると良いと思います。

配信形式がアツマールやPliCyなど、ブラウザプレイ用のプラットフォームで、容量に制約がある場合は特に総容量が大切になります。
ゲームをダウンロードさせる場合の容量は個人の感覚に依存する部分があるとは思いますが、あまり大きいとダウンロードする側にとって負担になります。
結合済みの立ち絵をすべて含めるとゲーム全体の容量が1GBを超えるが、パーツごとに分割すれば20％抑えられる、とかであれば、分割を検討したいですね。(数字は個人の感覚です)

開発者から見た管理のしやすさは、これも開発者個人の感覚に依存します。
キャラメイクでは組み合わせ爆発を起こして、差分の総数が100や200では足りないということになりがちなので、そういう場合はパーツごとに分けたほうが管理しやすいかもしれません。

同時に表示するピクチャの数が増えると、その分だけIOは発生しますが、それはイベントの組み方次第でプレイヤーに意識させずに済むんではないかと予想します。
パーツ1枚1枚の容量やピクセル総数がさほど大きくなければ、キャラメイク後の立ち絵はある程度の頻度で使われるであろうこと、さほど頻繁に変更されないであろうことから、キャッシュにも残り続けるでしょうし、画像の読み込みの重さは気にするほどのものではないと思います。

[スズラン]

ありがとうございます。
とりあえず差分をゲーム内で重ねる形にしてみようと思います。