使われていない関数のメモリの無駄

[ウーパールーパー山田]

現在、1つのボタンだけで操作できる簡単な格闘ゲームの製作を計画しております。
それに関連して疑問に思ったことがあるのでここで質問させてください。


今回のような単純な格ゲーでは考慮していないのですが、
市販されているような格ゲーでは操作できるキャラクターがたくさん存在していて、それぞれがとても複雑な動作をしています。
とすると現在操作されていないたくさんのキャラクターの動作について書かれているたくさんの関数は結構大きなメモリ領域を無駄に占有していると思います。
この使われていない無駄なメモリ領域についてどういった解決策があるのか気になりネットで色々調べてみました。
そうしたところ解決策になりうるものを二つ見つけました。

1つ目はメインプログラムの途中でＤＬＬをリンクさせる方法です。
2つ目は外部ファイルでスクリプトを置いといてメインプログラムで読み込むという方法です。

それぞれに利点欠点はあると思うのですが皆様ならどちらを使用するべきだと考えますか？又、他に良い方法があれば教えてください。


実はもう一つ思うところがありまして、検索の仕方が悪いのかしれませんが私の求めている情報がネットであまりヒットしないような気がします。
もしかして使用していない関数の無駄なメモリ領域というのは無視していいほど小さなものなのでしょうか？ここら辺も教えてくれるとありがたいです。

[あんどーなつ]

昔は問題だったと思うけど、
今は「メモリを2GB使用します」終わり

な気が...

[hide]

オブジェクト指向でまともに書ける言語であれば、全キャラクターをメモリに置かなけれ良いです。
ある程度の大きさのゲームで全て静的に持っていたらそれは設計がおかしいです。
エンディングの動画はタイトル画面ではロードする必要がない。とかそういうことですね。

全てのキャラクターが全員別のインターフェースを持つせいでメソッドが大量発生する
という話であれば、それもそれでもうちょっとちゃんと抽象化したほうがいいでしょうね。

DLLでどうのという小手先でやるよりは、まともに設計するところからです。

オフトピック

C言語とかでやってて関数大量に書かざるおえない状況ならば、
そろそろ別な言語にお引越しするのもいいでしょう。

[ウーパールーパー山田]

今は「メモリを2GB使用します」終わり

どれくらいの処理がどれくらいのbyte数になるのかはわかりませんが、
メモリ2GB使用するのって結構プレイヤーを選別しちゃっているような気がします

全てのキャラクターが全員別のインターフェースを持つせいでメソッドが大量発生するという話であれば、それもそれでもうちょっとちゃんと抽象化したほうがいいでしょうね。

プログラミングは初心者なので"今は"C言語以外は勉強したくないです（あまえ）
格ゲーってキャラクターごとにそれぞれ千差万別で多彩な動きをしているように感じますし、
それが数十キャラも登場しようものなら（なんならスマブラみたいにたくさんのステージギミックやアイテムの性能も合わさったら）
頑張って共通項を見つけて関数化しても結構な大きさになると思うのですが、それは仕方のない犠牲でしょうか？

私の話は机上の初心者論なので、おかしなところがあればツッコんでくれるとうれしいです

[hide]

格ゲーってキャラクターごとにそれぞれ千差万別で多彩な動きをしているように感じますし、
それが数十キャラも登場しようものなら（なんならスマブラみたいにたくさんのステージギミックやアイテムの性能も合わさったら）
頑張って共通項を見つけて関数化しても結構な大きさになると思うのですが、それは仕方のない犠牲でしょうか？

これをうまい具合に実装するための手段が、C言語ではない言語に存在するのです。
それが抽象化といった技術です。
C言語でやるのは大変ですができないこともないかとは思います。でもあまりしません。
それが楽にできる言語にうつる方がずっと簡単だからです。

オフトピック

ちなみに、そもそも単純な関数ごときではメモリはそんなに食いませんよ。

[ISLe]

ある程度大きな規模になると、キャラクターの画像や動き、ステージやそこにあるギミックなどは、プログラマではなく、デザイナと呼ばれるひとが作ります。
市販のものや独自に制作したオーサリングソフトを使ってデータを作り、そのデータをそのまま、あるいはさらに独自の形式に変換して、必要に応じて読み込みます。

千差万別で多彩な動きが、いくつかの単純な仕組みだけでできているということに気付けるかどうか。
既存のゲームを遊びながらでも観察し想像することはできるかと思います。

[Tepp]

限定的な場合を除いて、コード量をそこまで気にする必要性を感じませんし、
hideさんもいっていますが、関数が大量に増えたからといって、たかが知れてます。

オフトピック

リソースデータのほうがかなりメモリ使うのでメモリがキツイならまずそっちから最適化します。

[ウーパールーパー山田]

抽象化というのは入門サイトの抽象クラスや抽象関数について説明しているページを読めばよかったでしょうか？

自作ゲームを実行してタスクマネージャで確認したところDLLかスクリプト言語にすれば数百MBのメモリが節約できるのではないか
という予測ができました（合っているかは知りません）。
これに対して抽象化がどれくらいのメモリ節約に貢献してくれるかはわかりませんが、この方向でもう少し調べてみたいと思います。

御回答ありがとうございました！

オフトピック

私は耳音痴、筆音痴を併発しているのでリソースデータについて全くいじれません（あまえ）

[hide]

抽象化というのは入門サイトの抽象クラスや抽象関数について説明しているページを読めばよかったでしょうか？

C言語のままやるのならば今読んでもあまり意味はないです。
抽象化が直接的にメモリの節約をするわけでもありません。（間接的にはできるかと思いますが。）

どうやってタスクマネージャからそんな高度な情報を読み取ったのかわかりませんが、
DLLやスクリプトをつかったところで、プログラムの構造をちゃんとしないと何の意味もないので気をつけて頑張って下さい。

[あんどーなつ]

ウーパールーパー山田 さん

みんな、はぁ、うぅん？、とかうなってるんじゃないかな？

100MB, 200MB分のソースコード（100万行位？）を書くのは大変だし、もし、ウーパールーパー山田さんがそれだけ書けたとしたら、どんなコーディングテクニックも(DLL分けとか抽象化とか)楽勝になっているはず。

そこ、そこなんだよね。きっと

[ウーパールーパー山田]

どうやってタスクマネージャからそんな高度な情報を読み取ったのかわかりませんが、

コード量の違う２つの実行ファイルを同時に実行して、タスクマネージャの「メモリー（プライベートワーキングセット）」の欄を見比べました
もしかして何かマズかったですか

100MB, 200MB分のソースコード（100万行位？）を書くのは大変だし、もし、ウーパールーパー山田さんがそれだけ書けたとしたら、どんなコーディングテクニックも(DLL分けとか抽象化とか)楽勝になっているはず。

さっき上記の方法で見比べたら、百行ぐらいしか違わないのに数MB違っていたような気がするんです
ただ今見たらそうでもなかったので単なる見間違いだったかもです　お騒がせしました

[Dixq (管理人)]

あんどーなつさんは実行ファイルの大きさのことを言ってるのでしょうか？
私は質問者さんは実行中に確保するメモリ使用量の話をしているのかと思いました。

関数が沢山あるから実行中の使用メモリが膨大になるなんてことはないので別に考える必要はないと思います。
(その関数内にstatic変数がべらぼうにあるとかむちゃくちゃな設計でなければ・・)
一人でゲームを作成している分にはC言語でひたすら関数分けして問題ないです。

もし沢山のキャラクタが似たような行動をするがゆえに似たようなコードが至る所に点在しているということであれば
C++を学び、オブジェクト指向で設計して・・というアドバイスになるでしょうけど、現在の質問はそうじゃないようなので。

よくゲーム制作において、コアとなるエンジン部分はC++でがっつり作り、変動する部分やAI部分等はスクリプトで書くという場合がありますが
(FF11やFF14の敵の行動等はLuaスクリプトで書かれています)
こういうのはエンジンを作る技術者とゲームデザインをするデザイナーが分かれているので分担作業しやすくするためで合って
もし一人で中規模程度のゲームを制作するのであれば無理にスクリプトに分ける必要性を感じません。

それから、使用メモリはロードする画像ファイルと音楽ファイル(その他3Dモデル等のリソース)がほぼ9割を占めると言ってもいいと思いますので、
設計でメモリ使用量をどうのこうのする必要はないかと思います。
それよりも的確にリソースをロード・解放する方がずっと重要かと思います。

[あんどーなつ]

あんどーなつさんは実行ファイルの大きさのことを言ってるのでしょうか？
私は質問者さんは実行中に確保するメモリ使用量の話をしているのかと思いました。

え、私が悪いの？
ウーパールーパー山田さんは、「関数」という言葉を使っているし、Teppさんも「関数」について触れてますし。
リソース（画像・音楽等）のメモリ管理は言語関係ないでしょう（むしろC言語なら簡単ですよね）。


ウーパールーパー山田さん

ちなみになんですけど、言語ごとに実行時メモリが違うのは、ガーベジコレクションなどの仕組みで左右されることもあります。

[あんどーなつ]

ちなみになんですけど、言語ごとに実行時メモリが違うのは、ガーベジコレクションなどの仕組みで左右されることもあります。

ごめんなさい、実行時メモリをどうやって算出しているかは、私も詳しく把握しているわけじゃないのですが、
要因がいろいろあって、

・動的メモリ確保（malloc, new）：プログラムによってメモリを確保しますが、実際にはユーザーのメモリ空間が足りなくなったら言語ライブラリのほうで一括でとりに行きます。

・ガーベジコレクション：動的メモリ確保よりもメモリの確保・開放をシステムにゆだねている形になります。

・ＤＬＬ：DLLのコード領域の開放タイミングはOSにゆだねられます

ごめんなさい、わけわかんないですよね。メモリってわけわかんない動きするんですよ。ホント。

[usao]

>あんどーなつさんは実行ファイルの大きさのことを言ってるのでしょうか？
>私は質問者さんは実行中に確保するメモリ使用量の話をしているのかと思いました。

質問文からは，
プログラムの実行コードの大きさを問題にしているように見えますね．
（DLLとかスクリプトとかが挙げられているので，とにかく必要なコードだけをメモリにロードしたいということかな，と．）

個人的には，PC上で動かすプログラムの実行コードサイズが問題になった経験はないです．
（組込み方面でなら悩んだこともありますが，PC上のプログラムでは特別気にしたことがないです）