OOとゲームプログラミング

**名無しさん＠お腹いっぱい。** · 01/11/07 23:55

OOをどのように用いれば美しくゲームプログラミングを
行うことが出来るのか語り合うスレです。

**名前は開発中のものです。** · 02/02/04 14:04

やっと C が根付いた所のゲーム業界が新しいパラダイムを先取りするとは思えん。

まずはちゃんと OO を当たり前にすることからだ。

**名前は開発中のものです。** · 02/02/07 00:35

おまへ、そんな理想を持ってゲーム業界入ったらすぐ潰れるぞ。
設計ねえ・・・・。デザインねえ・・・。遠い他所の世界の話だ。

**名前は開発中のものです。** · 02/02/07 00:44

OOってのはまず設計ありきだから仕様が二転三転するゲームのお仕事
じゃ結構つらいトキもあるのよね。あとC++プロジェクトはメンバーに
一人でもC++を理解していない奴がいると破綻するから要注意。

**名前は開発中のものです。** · 02/02/07 01:03

OOとは関係ないが、XPはどうなんだろうか

**名前は開発中のものです。** · 02/02/07 01:15

>>676
大抵の会社ではチームを仕切ってるのは企画屋。
＞一人でもC++を理解していない奴がいると・・・・・
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
・連中がやるのは・・・・変更の前のＰＧ以外への根回し、・・・・・
多数派工作・・・・・・圧力・・・・・追い落とし・・・・・宣伝・・
・・・・・・・とても理解どころの話じゃ・・・・・・・・・・

**名前は開発中のものです。** · 02/02/07 02:00

>>673
うまくやると Croscutting を局所化できるらしいけど、俺もイマイチ具体的な
イメージが湧かなかったり。キャッシュとかは確かに綺麗に書けそうだけど。

**名前は開発中のものです。** · 02/02/07 02:26

>>676
設計じゅーよーなのは確かだが、いきなりシステム全体を作らずにスパイラル的に
開発するのも可能ですわな。モジュール間のインターフェースを明確にしておけば、
あとで仕様変更が入ったときに、モジュールをゴッソリ入れ替えるのも可能だし。

とはいえ、あまりに仕様変更が大きいとやっぱり作り直しだけど。

**名前は開発中のものです。** · 02/02/07 03:19

>>680
　まぁ、ゲーム作成においては設計よりはノリで作ったほうが有利
な事が多いのは確かだよね。どーせ１本上げたらスタッフが半分は
減るのが業界の常なのでC++の再利用性なんてのは業界の体制が変わ
らない限りは全然意味がないよねー（トカ

　ゲームエンジンの切り売りが商売として成り立ってる海外がちょ
っと羨ましいデス。

**名前は開発中のものです。** · 02/02/07 12:21

>>681
バイオハザードのシリーズとか、PS 版のドラクエ 4, 7 なんかは、思い切り
使いまわしっつー気がするが。

**名前は開発中のものです。** · 02/02/07 19:40

OO のが変更楽じゃん。
変更して問題が発生した時に、変更したモジュールに問題があることが
はっきりするから。

ベタ書きだと変更した時に他のモジュールに付け焼刃の修正がかかるから
最終的に複雑になりすぎて手におえない。

**名前は開発中のものです。** · 02/02/09 10:41

それぞれの認識している「変更」に大きな隔たりがあると思われ…

**名前は開発中のものです。** · 02/02/15 06:22

で、みんなどんな所に OO 使ってるの？

**名前は開発中のものです。** · 02/02/15 06:44

>>685
ペニス

**名前は開発中のものです。** · 02/02/15 07:23

自分でゼロから作ったフレームなら
たとえOOを多用していても理解もきいてとっても便利なんだけど
他人が作ったものだと途端にわかりづらくなるよね。
クラスのネストが3つ以上だと、もう読むのもイヤって感じ。
メンバを外部に公開するのは絶対禁止、COMインターフェイスみたいなのだけで
継承をサポートするって形にしないとダメだと思うなあ。
作るのは大変だろうけど。

**名前は開発中のものです。** · 02/02/21 03:36

>>687
いきなりソースを読む前に、ふつうはクラス図やシーケンス図を眺めないか？

**名前は開発中のものです。** · 02/02/21 17:25

>>688
多分、そんな物なかったんじゃない？(ハウスライブラリでは十分ありうるでしょ)

**名前は開発中のものです。** · 02/02/21 17:32

>>683
こいつ本当に開発の経験あんのかよ

**名前は開発中のものです。** · 02/02/21 20:17

>>689

クラス図やシーケンス図を補完している開発会社があるなら、それこそ
無駄だと思う。仕様は日々変わるんだから、そんなものとっておいても
意味がない。

常識的でシンプルな設計すれば、何となく分かってくるものだと思うよ。

**名前は開発中のものです。** · 02/02/21 22:30

>>691
> 仕様は日々変わるんだから、そんなものとっておいても意味がない。
…そいつは凄いな。ふつー（非ゲーム業界）は仕様が変わるからこそ、開発資料を
残しておくんだが。

**名前は開発中のものです。** · 02/02/22 00:27

>>692
パッケージ売り切りだと日々のメンテがないから、そういう風になるのかな？
まだ普通？(情シス)しか知らないから、パッケージ開発がどういう世界かしらない。

しまった、ワナビ～暴露しちゃった。

**名無しさん＠お腹いっぱい。** · 02/02/22 11:31

>>691
で、そういう会社に限ってスタッフに逃げられると、そのままポシャルんだよなぁ･･･
そいつ等の開発水準すら維持できなくて｡

**名無しさん＠お腹いっぱい。** · 02/02/22 11:33

>>694
実際、それでポシャる、もしくは瀕死になったメーカーは相当あるぞ｡

**名無しさん＠お腹いっぱい。** · 02/02/22 11:46

>>691
クラス図やシーケンス図を補完するのは開発者の為ではくて、開発会社の為
なのに、それを否定するって、それでメシ食ってけるのか？
そういうヤシは、すぐ仕事ホサれると思うんだが｡

**名前は開発中のものです。** · 02/02/22 17:13

>>696

開発会社が（経営陣の方々か）欲しいというなら、完成した動くコード
とセットで UML図（といっても、Rose とか自動作成ツールで出力する
ものの可能性が高い）を仕様書と報告書とともに差し上げます。

けど、デザイナーとゲーム開発者と間で、システムの中核の開発が終わってない
ってのに、のんびりと UML図を作っては書き直し、作っては書き直し、なんてマ
ヌケなことはしないでしょう。

**名前は開発中のものです。** · 02/02/22 17:16

開発＝コーディング　なの？

UML で図を書くというのは、何もお絵かきして遊んでるわけじゃなくて、問題の
分析／設計をやってるんだけど。

**697** · 02/02/22 17:20

あ、話の流れを見てみると、
「完成し終わったライブラリのUML図を開発会社が保管」という意味での
UML 図の保管ということみたいですな。

それなら、保管するのは大いにありうることだと思います。
ごめん。

>>698

もちろん、UML図を書くのはいいんですけども、（Extreme Programming 的には）
仕様が変わる可能性を残しているのに、図はとっておくのはムダということでございます。

（なぜなら、どうせすぐに古くなってしまうから・・・）

UML図は紙に描いて意思疎通が終わったら丸めて捨てるのがベストだと思います。

**名前は開発中のものです。** · 02/02/22 17:25

>>699
俺は、仕様が変わるからこそ開発資料を作るけどなぁ。

もちろん全部のクラスやシーケンスについて詳細な図を書くことはなくて、中核と
なる部分と例外的な処理をしている部分だけまじめに書いて、後は適当に書くか
まったく書かないけど。

そうでないと、仕様変更が出てきたときに

- その仕様変更によって、どこがどの程度の影響を受けるのか（インパクト分析）
- 作業工程にどのような影響が出るか
　並行して進めてる作業をとめて、こちらを先に進める必要があるのか
- 結果として、スケジュールにどのような影響が出るか

なんてのを、その場で大雑把にでも見積もるのが難しくない？

**700** · 02/02/22 17:31

追記

> （なぜなら、どうせすぐに古くなってしまうから・・・）
up to date に保てないような図なら、まるてて捨ててしまえ、というのは同意。
だから何でもかんでも図にしろっつーのは俺も反対。

**名前は開発中のものです。** · 02/02/22 17:37

>>700

いやいや、それが「罠」なんですよ。
また、Extreme Programming を引き合いに出すけど、
未来を予測するのは不可能なのです。

もし、仕様変更が無かったらどうしましょう。
仕様変更のために資料を作ったのがムダになってしまいます。

**名前は開発中のものです。** · 02/02/22 18:27

>>702
仕様変更に備えるのは、理由の一つで

- 設計を OO でやってる場合、頭の中に最初に出来るイメージはコードよりは
　UML の図に近い。設計段階で UML の図は自然に出来る。（設計をすっとば
　していきなりコーディングしちゃうヤツを除く）
- コーディングした本人も、数日経つと詳細は忘れる。そのときにコードを追っ
　て理解しなおすよりは、図を見て思い出した方が効率が良い。まして本人で
　はなく、他人がメインで保守しているコードに関してはなおさら。

というのもあるけど。

**名前は開発中のものです。** · 02/02/23 07:28

結局売りきりだからね。開発会社も開発ノウハウを蓄積するためのプロジェクト
運営なんて考えないし。（考えているところもあるんだろうけど。）
だいたい、３～４年たつと新ハードがでて、作ったものがかなり陳腐化するのが
どうしようもない原因であるよ。３ＤといってもＸ－ＢＯＸとＰＳ２とＰＳ１で
も別世界だし。　もうしばらくはその場しのぎを続けるしかないだろうな。

むろんＤＱくらい売れるなら使いまわし前提にプログラムを組む余裕はあるだろう。
シナリオ、バランス調整のほうが時間かかってるだろうし。

**名前は開発中のものです。** · 02/02/23 15:06

>>704
陳腐化が速くて再利用が厳しいのは確かだが、それでも昔の

　プログラマ一人
　開発期間は数ヶ月

という古き良き（？）世界から、

　プログラマは最低数人
　開発期間は 18 ヶ月

という状況になってしまったわけで、「設計は俺の頭の中にあるよ」では通用しな
くなりつつあるのは確か。

開発期間が伸びた場合に嵩むコストも昔の比じゃないし、外から資金を調達し
てる場合にはスケジュールに関して「プログラマは８割方できてると言ってます」
では済ませてくれないしね。

**名無しさん＠お腹いっぱい。** · 02/02/25 14:03

それに自分達がその資料や資産をもう必要としなくても、ほぼ同時並行
で進行中の別チームがソレを切実に必要とするケースは結構あるよ｡

だから「設計は俺の頭の中にある」っていうのは、ソイツの独り善がりの
台詞としか思われなくなってる｡　たとえ腕が確かでも｡

**名前は開発中のものです。** · 02/02/25 19:43

注意すべきなのは、ドキュメント使ってる人がいるかどうか、だよね。

もし、見る人がいなければ、そんなものは作っちゃだめ。

見る人がいれば、できるだけ短い分かりやすい文章で解説して、そして
やっぱ一番効率がいいのは面と向かってのやりとりだね。2ch で設計の
議論やろうとしたら全く非効率極まりない。

**名前は開発中のものです。** · 02/02/25 20:27

>>707
だから使ってる人がいるかどうかってのは、製作者自身が決める事じゃない
ってーの｡
たとえ実際に必要とされなくとも、自分達が作った物に対する詳細な資料を
作製、添付するのは、その完成品で金を貰う人間としては当然の義務だぞ｡

ソレを口で説明するのが一番効率がいいとは、何たる言い草だよ･･･
口で説明する｡で済むなら、同人とかでやってくれ｡

仕事で、そんな事されたら俺は上司にそいつを更迭するよう強く迫るけどな｡
第一、ドキュメントもロクに作れん様な奴が人に判りやすく説明できるわけ
無いだろうが｡

**名前は開発中のものです。** · 02/02/25 20:42

>>708
ドキュメント書かないヤツは論外だが、ドキュメント過剰も良くないとは思う。プロ
ジェクトの規模が大きくなって、それこそ業務用システムのような

　数千人月

みたいな世界になると開発者間で直接コミュニケーションなんてのは不可能だか
ら、細部までドキュメント化してないと話にならないけど、

　開発者数人

という規模だと、コア部分関してはきっちりドキュメント化するのは当然としても、
細部の頻繁に変更される部分までドキュメント化しても無駄になる可能性が高
い。

細部は doxygen あたりのドキュメント作成ツールで済ませることにして、コア部
分だけきっちり資料を作るってのも、現実的な選択肢だと思うよ。

>>707
資料って OO だと UML で大雑把に書いて、そこにノートでコメントを書き込む方
が、文章で書くより分かりやすくないか？

**名前は開発中のものです。** · 02/02/26 03:25

＞だいたい、３～４年たつと新ハードがでて、作ったものがかなり陳腐化するのが
＞どうしようもない原因であるよ。３ＤといってもＸ－ＢＯＸとＰＳ２とＰＳ１で
＞も別世界だし。　もうしばらくはその場しのぎを続けるしかないだろうな。
いっちゃ悪いけど、「描画系」と「アプリ系」をきっちり分別して開発する
ことに困難を感じている君は修行不足だと思う。

**710** · 02/02/26 03:28

特に、PS2 -> X-Box への移植に困難を感じているのならば
開発時の整理整頓を真剣に考えた方がいいと思う。

**名前は開発中のものです。** · 02/02/28 12:39

OO ってプログラムの複雑度を下げるよなぁ…って思ったんだけど、
これについての意見プリーズ。

思いつきだから自分でも確証ないんだよね。どうなんだろう？

**名前は開発中のものです。** · 02/02/28 20:40

>712
構造的にはそうかもしらんが
ソースコードは長くなるぞ

というよりアンチOOから怒濤の煽りが来そうなﾖｶﾝ

**名前は開発中のものです。** · 02/02/28 21:31

スパゲッティがほどけて独立性が上がっても、
その独立したものどうしを繋ぐのに複雑性が上がる罠。

**712** · 02/03/01 00:34

>>713
ソースコードの長さって問題なのかな？たいした問題じゃないと思うんだけど。
みんなそんなにキーボード打つの遅いの？

>>714
なるほど、だから UML とかデザインパターンズとかが重要になるんだね。

**名前は開発中のものです。** · 02/03/01 01:55

ズ

**名前は開発中のものです。** · 02/03/01 02:27

そうズら

**名前は開発中のものです。** · 02/03/01 02:48

複雑度を下げるというより上げると思うんだが
複雑なことが安全にできるようになるって感じ。
ソースコード対効果比（Ｓ／Ｎ比）は高い。
掛ける時間は設計９０％、コード１０％くらいになった。

**名前は開発中のものです。** · 02/03/01 03:50

たしかここだったと思うけど、OOPでSTG（凄く簡単な雛型）作った人が、
ソースUPしてたと思うけど、勝手に弄らせて貰ってます。

何か形になりそうだったら、UPします。

**名前は開発中のものです。** · 02/03/01 09:01

Effective STL買ってきて読んでるけど
shared_ptr（・∀・）ｲｲ!! 怪しい自作スマートポインタとはお別れだな。

**名前は開発中のものです。** · 02/03/01 12:24

>>720
weak_ptr も調べると幸せになれる。(boost 1.27 以降だったかな)

**名前は開発中のものです。** · 02/03/01 12:28

>>719
ライセンス条件は確認した？　BSD ライセンスとかならともかく、そうでないと
「参考にするのは OK だが、コピペで使うと著作権法違反」とかの可能性もあ
るから注意ね。

**narucy56** · 02/03/01 23:18

>>718

設計に時間をかけるのはよい心がけ。

ただ、大抵、設計にかける時間というのは言うなれば「どうすれば簡単になるか」
ということを考える勉強の時間なのよ。

OO に慣れた人なら、ちょっとしたディスカッシヨンですぐに設計は完成しちゃう（・・・と思うんだけど、どうかな）

設計に時間費やすのはいいけど、それでデザイナが求めていないところまで
柔軟性を持たせる意味もないし。

だれもが 3分で内容が理解できるくらい単純な設計でないといけない。
そういう意味じゃ本来は設計には時間を費やさないのが、OO をマスターしてからは
重要なんだと思う。

**名前は開発中のものです。** · 02/03/01 23:40

>>723
> OO に慣れた人なら、ちょっとしたディスカッシヨンですぐに設計は完成しちゃう
気のせい。

**名前は開発中のものです。** · 02/03/02 06:07

>723
その３分程度でできるのはモデリングだけだろ・・・

**718** · 02/03/02 06:46

ありがとうございます。
往々にしてあほ(笑)なので私はまだすぐに設計が完成…という境地には
至ってないですね。がんばりたい。

XP · 02/03/04 04:33

先のことを考えて作らないこと。自分が設計にこもりはじめたり、
一般化をはじめたりしているのに気がついたら、ストップ。動作す
るもっとも単純なことを実装して、今しなくてはいけないことをす
るのだ。「あとで必要になるはずだ」と言っている自分に気がつい
たら、あなたは貴重な時間を無駄にしているということだし、顧客
からプライオリティを設定する権利を奪い取っているということだ。

**名前は開発中のものです。** · 02/03/04 04:57

>>727
正直、リファクタリングは

　ちゃんと設計できる能力がある人

前提の話だと思う。いい加減な設計しか出来ない／設計しない人が言い訳に
使うのは許さん。

**名前は開発中のものです。** · 02/03/04 06:18

もとの設計がダメでそれから派生した多種のクラスもダメだった
その修正がいい加減嫌になって全部捨てて結果
全世界の開発者の貴重な時間を無駄にした例がＭＦＣだよね

**名前は開発中のものです。** · 02/03/04 15:01

>>729
MFC 叩きはよそでやれ。

**名前は開発中のものです。** · 02/03/04 17:42

>>729-730
秀同（ｗ

**名前は開発中のものです。** · 02/03/06 03:48

良スレ期待age

**名前は開発中のものです。** · 02/03/08 16:14

設計のベストなあり方としては、以下のページによいものがあった。

設計の終焉?
http://objectclub.esm.co.jp/eXtremeProgramming/IsDesignDead.html

設計はやっぱしなきゃだめ。
でもそれは複雑になりすぎちゃだめ。
時間をかけすぎてもだめ。
しっかりできても他人に説明できなきゃだめ。

**名前は開発中のものです。** · 02/03/08 18:16

>>733
読んでみたけど、妥当な意見に思えるな。

**名前は開発中のものです。** · 02/03/08 23:38

>>733
どうでもいいが、こうあるべきという主張はやめたほうがいいよ。
XPかぶれてるのはわかるけど。

**名前は開発中のものです。** · 02/03/09 00:33

>>735
> XPかぶれてるのはわかるけど。
リンク先のドキュメントも >>733 の文章（設計の終焉? の要約だと思うが）も、
むしろ XP の中では穏健派の書いた文章だぞ。

XP について賛成するにせよ反対するにせよ、とりあえず XP について調べて
理解しとけ。話はそれからだ。

**名前は開発中のものです。** · 02/03/09 00:50

XPを実践できるのは天才だけ？

**735** · 02/03/09 00:51

>>736
んー？ベストなものなんて世の中には無いって言ってるのさ～。
XPについては何も言ってないぞ。

**名前は開発中のものです。** · 02/03/09 01:23

>>738
> XPについては何も言ってないぞ。

XP について何も知らないのに
> XPかぶれてるのはわかるけど。
と言うの？　ダメじゃん。

**名前は開発中のものです。** · 02/03/09 01:25

>357
＞XPかぶれてるのはわかるけど。
>738
日本の政治家みたいなﾔｼだな（藁

**名前は開発中のものです。** · 02/03/09 01:26

ポインタ間違えた・・・
×>357
○>735

**名前は開発中のものです。** · 02/03/09 01:55

がんばれよ（藁

**名前は開発中のものです。** · 02/03/09 02:50

やだ（ｗ

**名前は開発中のものです。** · 02/03/17 02:50

age

**名前は開発中のものです。** · 02/03/17 03:13

XPなんてｶﾞｷのｼｮﾝﾍﾞﾝ臭いものを勝手に作っておいて
勉強しろなんてひどいな

**719** · 02/03/17 07:42

（多分ここで）UPされたOOPSTGに、簡単なタスク管理追加、DIRECTX化、
したものをUPしようかと思います。
（環境、Ein98SE,P31G,GForce3）
著作権法違反は、特に記述がなかったのでOKだと思います。

当り判定（タスク間のやりとり）をまだ入れてないんです。
各（自機の）弾タスクが、（敵の数分の）タスクを総ナメしないと
いけないんですかね？やっぱ。判定に段階を設けるとしても。

**名前は開発中のものです。** · 02/03/17 11:29

>著作権法違反は、特に記述がなかったのでOKだと思います。
　
お～い、はに丸。著作権は何もしなくても自動的に発生しますよ。
改変と再配布の許可が明示されているのでなければ、
一応作者に問い合わせるしか。

**名前は開発中のものです。** · 02/03/17 13:38

>>747
同意。

明示的に再配布可能とか記述がない限りは、勝手に使うとまずいぞ。

っつか C++ で書いたシューティングゲームの雛型なら MIT ライセンス
で公開されてるものがあるぞ。

**719** · 02/03/18 00:39

>>747
はにゃ？そうスか、、。無知を晒してしまったですな。
ソース自体は、殆ど書き換えちゃったんですがね。実は。
やめといた方がよさそうですね。
作者の方へコンタクト取れそうにないし。

>>748
出来れば、詳細を教えて下さい。どんな設計か興味あります。
（特にクラス間の情報のやり取り等）
シューティング　C++　で検索しても見つけられなかったです。

**名前は開発中のものです。** · 02/03/18 02:40

ximpactもC++で書いてあった気が

**名前は開発中のものです。** · 02/03/18 04:31

>OOPSTG
開発状況報告スレのここらへんじゃない？
http://game.2ch.net/test/read.cgi/gamedev/1005143186/212-

あとここ。
http://www.sm.rim.or.jp/~shishido/gamedev.html

**名前は開発中のものです。** · 02/03/18 19:05

>>749
これ。

http://www.issei.org/programming/Windows/DxApp

ただしソースはあるけど操作に必要なリソースファイルは置いてないし、
当たり判定もまだのようだが。

**719** · 02/03/19 01:30

>>751
おお！THX!ビンゴです。早速問い合わせてみます。

>>752
THX!です。見てみます。
でも、本業の方が押してきてるので、作業進まないかも。
（でも、やりたいのはSTGｗ）

今、某CUBEやってるんですが、コールバック関数のラッピングに手間取ってます。
(static)関数内でクラスにアクセスのに、とりあえず、グローバルポインタ渡すしか
思いつかない、、。

**名前は開発中のものです。** · 02/03/19 01:56

>>746
　当たり判定は当たり判定管理クラスにタスクを登録して結果を
コールバックで取得＆反映って感じでしょ。

　後は判定管理クラス内をレイヤー化して置く事で様々な状況に
対応できるようにすると。

**719** · 02/03/19 04:05

>>754
すいません。良く解らないです。

コールバックって、キリの良い所で処理を返す必要がないものに
対して使うものだと認識してます。
（メモカ、CDの裏読み等）当り判定って、フレームごとに全て完了
させないとイケナイ気がするんですが・・。

**名前は開発中のものです。** · 02/03/19 04:17

>>755
> コールバックって、キリの良い所で処理を返す必要がないものに
> 対して使うものだと認識してます。
認識が間違ってます。

**名前は開発中のものです。** · 02/03/19 05:05

>>755
ウンウン、コンシューマな人だねぇ…。
別にハードウェア割り込みから呼ばれる関数をコールバックと限定
するワケじゃないハズだよ。

当たり判定管理クラスを１つのデヴァイスと見なして、そこからの
情報伝達をコールバックという形で見れば大体言いたい事は解って
もらえるかな？

　だから１タスクは他のヒット効果をもつタスク全てを知らなくても
自分と判定管理クラスとの相互関係のみで当たり判定を管理できるよ
うになる訳。719氏のタスクシステムの全貌は知らないけど、
HitMe( Task& enemytask , int layer );
Hit時にこーゆー関数がコールバックされば大体の処理は管理しきれる
し、パワーアップアイテムとかとの住み分けの汎用性も高いっしょ？

　次にレイヤー化する事によるメリットって？みたいな質問がくると
更に嬉しいんだけど。

**名前は開発中のものです。** · 02/03/19 11:42

レイヤー化する事によるメリットって？

**名前は開発中のものです。** · 02/03/19 11:53

>758
ｵﾏｴ755じゃないだろ

**名前は開発中のものです。** · 02/03/19 12:07

うん

**名前は開発中のものです。** · 02/03/20 01:06

>>757
　それより先に、コールバックで結果を通知することのメリットの方が聞きたい。
（レイヤー化のメリットは、わかる。俺もそうしよ（ｗ）
　当たり判定管理クラスにAddHitData(Task &, int) IsHit(Task &, int) ってなメソッド
を用意して、前者で当たりの登録（これはTaskスタート時１回でいい）、でIsHitで結果
を知るってな方が自然だと思う。
　コールバック方式って、やっぱ、HitMeの時には登録が行われるだけで、タスク処理
が全部終わったあと、当たり判定管理クラスの実際に判定を行うメソッドを呼んでやる
と、その中でコールバックが呼ばれる感じだよね？となるとコールバックの中で進入禁
止の処理やら、アイテム拾ったときの処理やら、攻撃受けたときの処理やら全部やら
なきゃいけないわけで、そういう処理はタスク処理の中に書けた方がわかりやすいので
は？

**名前は開発中のものです。** · 02/03/20 01:11

>>761
本筋からずれるが、なんでもかんでも Task クラスに突っ込まずに、

- 当たり判定関係のメソッドだけ抽出したインターフェースを用意
　（純粋仮想関数だけ定義したクラスを容易）
- タスク実装クラスに、そのインターフェースを多重継承

の方が、柔軟性が増すぞ。

**761** · 02/03/20 01:15

あ、わかった。タスク処理の中であたり判定処理しちゃうとタスクの実行順で
当たり判定データが現フレームの物だったり前フレームの物だったりしちゃう
からか。

**名前は開発中のものです。** · 02/03/20 01:20

>>761
757 じゃないが、メリットは

1 当たり判定順序をタスク実行順序と切り離せる

2 タスクの状態変化のタイミングと、タスク実行のタイミングを分離できる
　タスクを順次読んでる途中で、タスクの状態が変わって、タスク管理クラス側
　にも影響を与える（たとえばタスクを殺して管理クラスから削除）場合には、
　よくよく考えないと dangling pointer を参照するバグが出る

3 特殊な判定（特定のキャラクタにのみ当たり判定があるとか）を付け加える
　ときに、その処理が各タスクに分離せずに、管理クラスで一括して処理でき
　る

っつーあたりじゃないか。

当たり判定はともかく、タスク実行と描画は実行順序を独立に定義するために、
分離するのが普通だよな。

**名前は開発中のものです。** · 02/03/20 01:21

>>762
多重継承より、オブジェクトコンポジションの方が良いと思われ。

**名前は開発中のものです。** · 02/03/20 01:27

>>765
インターフェースの多重継承と、実装の多重継承を勘違いしてないか？

コンポジションだと、タスク内部の情報にアクセスするのが難しくなるぞ。

**761** · 02/03/20 01:33

>>764
>当たり判定はともかく、タスク実行と描画は実行順序を独立に定義するために、
>分離するのが普通だよな。
うい、そうですな。

　俺のタスクシステムの場合、タスク処理本体を二つの関数に分けてあって、基本
的な処理は１番目の関数をオーバーライドして定義し、実行順の問題がある処理
は２番目の関数をオーバーライドして、ってな感じでやってるんですが、これだと、
２つじゃたんない、３つ必要！ってな事になったらおいそれと足せない。
　なんかもっといい実装例ないかなぁ。それか、実行順に依存させたくない処理は
ぜんぶコールバックでやるべきなんだろうか？（この方式にこだわるのは、処理の
流れがソースからわかりやすい、から）

＃ちなみにその二つのメソッドはanimate、renderという名前。renderといいつつ、
当たり判定とそれによる位置変更もやる……名前と内容が一致してない……。

**766** · 02/03/20 01:38

実例を挙げた方が良いか。

struct hittable {
　 virtual void get_hit_rect(rect&, hit_type&) = 0;
};

class player_task : public hittable
{
　　bool invisiable_;
public:
　　void get_hit_rect(rect& rc, hit_type& htype)
　　{
　　　　if (invisible_)
　　　　　　rc = INVALID_RECT;　　// 不可視状態の時には、当たり判定なし
　　　　else
　　　　　　...
　　}
};

インターフェースの多重継承を利用すれば、こんな感じでタスクの内部状態
を利用して当たり判定を変更することが、容易に可能になる。コンポジション
で同じ事をやろうとしたら、思い切り不自然なコードを書くことになるぞ。

**名前は開発中のものです。** · 02/03/20 01:40

>>766
ん、勘違いしてた。
ああ、762が言っている方式では、タスクマネージャーの方から当たり判定用の
メソッドを呼び出して当たり判定を実現するって事なのかな？（柔軟、か？）

**719** · 02/03/20 01:52

winのような、イベント駆動型とかをイメージすればいいのかな？
いやー。正直、よくわからんスｗ避けてました。
勉強してきます。

＞719氏のタスクシステムの全貌は知らないけど、
HitMe( Task& enemytask , int layer );
Hit時にこーゆー関数がコールバックされば大体の処理は管理しきれる
し、パワーアップアイテムとかとの住み分けの汎用性も高いっしょ？

自分が今実装してる方法は、
UpdateFrame()、（全タスクに対するAI処理等)
EndScene()、（全タスクのキルスク、チェンジタスク要求チェック、実行）
Draw()、全描画
てな感じです。
判定は、キルタスク同様、大まかな範囲チェックに引っ掛かったものを、
EndScene()内でさらに判定、て感じで考えてました。

で、判定関数は、矩形,球ぐらいを用意しといて、タスククラスに
持たせようと思ってました。

＞次にレイヤー化する事によるメリットって？みたいな質問がくると
更に嬉しいんだけど。

それじゃ、
次にレイヤー化する事によるメリットって？

**名前は開発中のものです。** · 02/03/20 01:54

>>767
> 実行順に依存させたくない処理はぜんぶコールバックでやるべきなんだ
> ろうか？
そう思う。

上のほうで挙がってた DxApp だけど、あれは描画とタスク実行を切り離して
別々の優先順位で処理するようになってる。

　タスク関係　　ITask, CTaskManager
　描画関係　IObject, CObjectManager

が対応するクラスなんで、読むと参考にはなるかも。

（あと優先順位無し、登録順で処理する IObjectCommand っつーのもある）

**名前は開発中のものです。** · 02/03/20 01:56

　>>768 の方式だと、オブジェクトごとに当たり判定の実装が必ず
違うのであれば問題ないけど、このオブジェクトとこのオブジェクトは
実装一緒ってな事が多いとコピペが氾濫したり、もう一個クラス作って
へんちくりんなメッセージングすることになったりしない？

　俺は757のいう当たり判定管理クラスってのを導入した方が
スマートだと思うから。
　メンバとして持ったhittableのインスタンスの参照を当たり判定
管理クラスに丸投げしてやるだけでいいと思うので、複雑にはな
らないと思う。

**名前は開発中のものです。** · 02/03/20 02:05

>>772
> このオブジェクトとこのオブジェクトは実装一緒ってな事が多いと
そのときには template を使って Mixin すれば OK。

っつか 768 も

- 当たり判定管理クラスを作り
- そこに当たり判定チェックを行うインスタンスを登録
- 管理クラスから、各インスタンスをコールバック的に呼び出す

のは同じだけど。設計方針は変わらず、たんに C++ で都合がいい実装方法を
紹介しただけ。（コールバックの代わりに多重継承を使うと this の受け渡しが楽
だぜ、という程度の話）