ゲームのタイトルメニュー画面から派生する、カスタマイズ画面とゲーム画面のデータのやり取りについて
アクションゲームなどで、プレイヤーの武器をカスタマイズできるゲームがあるのですが、どのようにデータを渡すのが正しいのかわかりません。
カスタマイズした情報はどこでどのタイミングでインスタンス化され、ゲームに反映される?という疑問です。
今まで考えていたのは
カスタマイズ画面でインスタンス化した武器データやキャラクターを、
グローバル変数(シングルトン)に渡し、そのままゲーム画面で使うという方法
だったのですが、
わざわざロード画面を作る以上、インスタンス化などの負荷の高い処理はゲームをする直前に読み込みたいです。
よって、↑の設計では武器をチェンジしたりプレイヤーキャラクターを変更するたびにdeleteしてnewするのは、
オブジェクト指向として (シングルトン使って言うのもなんですが) なんだかなーと思いました。
そこで思いついたのが、
カスタマイズ画面でクラス名(文字列)を指定して、ゲームのロード画面で文字列で指定されたクラスをインスタンス化する
という方法なのですが、
聞いたこともない方法ですし、if文の連続になりますし、コードも見づらくなるし
どうしたものかなーと思って質問しました。
スパロボみたいな、カスタマイズ画面⇔メニュー画面⇔ゲーム画面
みたいな画面移動にメニュー画面を中継するゲームがグローバル変数にしてるのか気になります。
どのようにするのが正攻法なのでしょうか?
カスタマイズ画面からゲーム画面へのデータの受け渡し
Re: カスタマイズ画面からゲーム画面へのデータの受け渡し
武器やキャラクターぼデータと、リソース(画像など)は別に管理するのが普通です。
つまり、画像はロード画面でまとめてロードしておき、後から生成されるインスタンスは画像の番号とか名前だけ持っておくようにします。
そうすれば、インスタンスの生成コストはずっと小さくなります。
また、インスタンスの生成コストが高い場合でもポインタを渡せばコストはかかりません。
つまり、画像はロード画面でまとめてロードしておき、後から生成されるインスタンスは画像の番号とか名前だけ持っておくようにします。
そうすれば、インスタンスの生成コストはずっと小さくなります。
また、インスタンスの生成コストが高い場合でもポインタを渡せばコストはかかりません。
-
珈琲
Re: カスタマイズ画面からゲーム画面へのデータの受け渡し
インスタンスそれぞれがコンストラクタでリソースを管理するクラスにファイルパスを送って、2度目からはそのコピーを取得するようにしているのですが、
「別に管理」に当てはまりますか?
また、画面をまたぐインスタンスのやり取りについてちょっとよくわからないです。
特に、カスタマイズ画面でインスタンス化してもいいとなった場合、所有しているアイテムすべてインスタンス化して、やり取りするというか
なんかnewすることに抵抗があるような文章ですいません。
「別に管理」に当てはまりますか?
また、画面をまたぐインスタンスのやり取りについてちょっとよくわからないです。
特に、カスタマイズ画面でインスタンス化してもいいとなった場合、所有しているアイテムすべてインスタンス化して、やり取りするというか
なんかnewすることに抵抗があるような文章ですいません。