ゲームにおけるデータ構造・クラス設計・パターンat GAMEDEVゲームにおけるデータ構造・クラス設計・パターン - 暇つぶし2ch■コピペモード□スレを通常表示□オプションモード□このスレッドのURL■項目テキスト198:issei 07/01/28 01:38:40 ViuHLna9 >>197 > >>issei(誰?w) 日記の人です。 > また寝ながら考えたんだけど、要はこれはエンティティクラスの主要なメソッドを使うには > このctxインターフェイスを実装しているオブジェクトをなんとかして用意してください。 そうそう。 本当のマネージャとは別に、エンティティの単体テスト用とかデバッグ用に ICtx*** インターフェースを実装した別のマネージャーも作ってました。 確か別のプログラマがエフェクト用の対話型エディタを作ってたんだけど、そこで デザイナからキャラクタにエフェクト乗せて見たいとリクエストがあって、エフェクト エディタにキャラクタ用のコンテクスト実装してたんじゃなかったかな。もちろん、 大半の仮想関数はダミー(ヒット判定なんかの関数は、常にヒットしないと返す だけ)だけど。 199:名前は開発中のものです。 07/01/28 19:27:03 aVNVY6/P 風呂はいりながら考えたんだけど ようは移植用区画、エンティティクラス、実装を委譲したい関数群、 それぞれをシステム内で1対1対1。ひとまとめにしたいわけだ。それはわかる。 だが無駄に暗黙的な命名の制約を持ち込むvisitorインターフェイスには反対。 contextというが、それらが文脈として差異を持たされるのは結局はプロジェクト全体で複数作られる 実行単位ごとなわけだ。それに対してvisitor風に関数レベルで型への依存を表明するのは 適当だとは思えない。何がどのレベルで変わるのかがきちんと示せてるのがいいコードっすよね。 ついでに実装をまとめるだけが目的の節操のないmixinも反対だ。 俺はこうする。 class Player { public: void exec() { CreateShoot(); } void Method0(); private: static void CreateShoot(); // どこか他のコンパイル単位で定義してやる }; どこか他のシステムへもっていってもstatic関数を定義した.cppの方だけ取り替えれば移植が完了する。 次ページ最新レス表示レスジャンプ類似スレ一覧スレッドの検索話題のニュースおまかせリストオプションしおりを挟むスレッドに書込スレッドの一覧暇つぶし2ch