| Re: 自己削除 ( No.1 ) |
- 名前：いっち 日時：2010/02/13 15:05
私自身、クラスの設計にはまったく自信が無いので大変お答えしにくいのですが、
うまく動かないのはクラス間の関係が適切でない可能性が高いので再設計を行う必要があるのだと思います。
RPGは考えうる状況や演出が多すぎて具体的にこうしたほうが良いとは言いにくいのですが、
MAPの切り替えはどの様な状況で発生するのでしょうか？
もし、私ならMAPの切り替えは出来る限り隠蔽して、外部には座標(アドレス)の表現方法を提供するような形にすると思います。
そう考えると外部からはMAPを切り替えるという発想が無くなると思うのですがどうでしょうか？
(場面転換のような一時的なMAP展開をどうするのかと言われるとまた悩みますが)
※ 恥ずかしながら、私はRPGどころかまともなゲームを完成させたことが一度もありません。
実際のゲーム製作では何の役にも立たない可能性が高いですが、お許し下さい。
|
| Re: 自己削除 ( No.2 ) |
- 名前：さかな 日時：2010/02/14 17:39
いっちさん、ありがとうございます。
クラスの再設計ですか・・・。
>外部には座標(アドレス)の表現方法を提供するような形にすると
あ、それは思いつきませんでした。でも、
現在は、マップ移動イベントの発動はMap以外のクラスが受け持っているので、
必然的にマップデータは外部からの操作が必要なのです。
やはり、親クラスの削除のようなことができれば一番早いかと...
今は、別の独立関数を呼び出してしのいでいるのですが、
これって例のセキュリティホールの「戻り先がデータ」ってやつですよね...
|
| Re: 自己削除 ( No.3 ) |
- 名前：いっち 日時：2010/02/14 23:05
子クラスが親クラスを削除するのは無理だと思いますので、クラス構成を変えられないのであれば、
やはりフラグを使うなどの力業的な方法でしのぐしか無いかもしれません。
とりあえず動くものを作ってしまい後から手直しをするというアプローチでも良いのではないでしょうか？
(始めて作ったプログラムはどうせ後から直したくなるものですし)
|
| Re: 自己削除 ( No.4 ) |
- 名前：sy(サイ) 日時：2010/02/15 02:01
マップ移動イベント発動フラグを受け取り、マップクラス内でロードし直した方が便利のような気がします。
マップデータは配列で管理して、マップクラス内に保持して、イベント時にデータの中身をロードし直すのが適当と思われますが。
インスタンス化してしまうと、Javaなら良いですがC++だと後始末が少々面倒だと思います。
|
| Re: 自己削除 ( No.5 ) |
- 名前：さかな 日時：2010/02/16 18:38
みなさんありがとうございます。
>インスタンス化してしまうと、
はい、確かにそうなのですが、基底クラスのポインタに
派生クラスのポインタを代入する方式で、異なる
イベントの動作を管理しているので、「データの再ロード」ができないのです。
>後から手直しをするというアプローチでも良いのでは
はい、とりあえずそれでいってみます。
みなさんお忙しいところすいませんでした。
|