トップページ⇒gamedev
935コメント361KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。01/11/07 23:55ID:HnYWCQK1
OOをどのように用いれば美しくゲームプログラミングを
行うことが出来るのか語り合うスレです。
0686名前は開発中のものです。02/02/15 06:44ID:???
>>685
ペニス
0687名前は開発中のものです。02/02/15 07:23ID:AIw8xlxF
自分でゼロから作ったフレームなら
たとえOOを多用していても理解もきいてとっても便利なんだけど
他人が作ったものだと途端にわかりづらくなるよね。
クラスのネストが3つ以上だと、もう読むのもイヤって感じ。
メンバを外部に公開するのは絶対禁止、COMインターフェイスみたいなのだけで
継承をサポートするって形にしないとダメだと思うなあ。
作るのは大変だろうけど。
0688名前は開発中のものです。02/02/21 03:36ID:???
>>687
いきなりソースを読む前に、ふつうはクラス図やシーケンス図を眺めないか？
0689名前は開発中のものです。02/02/21 17:25ID:35NaRfFx
>>688
多分、そんな物なかったんじゃない？(ハウスライブラリでは十分ありうるでしょ)
0690名前は開発中のものです。02/02/21 17:32ID:???
>>683
こいつ本当に開発の経験あんのかよ
0691名前は開発中のものです。02/02/21 20:17ID:C9AJcEPn
>>689

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

常識的でシンプルな設計すれば、何となく分かってくるものだと思うよ。
0692名前は開発中のものです。02/02/21 22:30ID:???
>>691
> 仕様は日々変わるんだから、そんなものとっておいても意味がない。
…そいつは凄いな。ふつー（非ゲーム業界）は仕様が変わるからこそ、開発資料を
残しておくんだが。
0693名前は開発中のものです。02/02/22 00:27ID:A1Lm+ZAR
>>692
パッケージ売り切りだと日々のメンテがないから、そういう風になるのかな？
まだ普通？(情シス)しか知らないから、パッケージ開発がどういう世界かしらない。

しまった、ワナビ〜暴露しちゃった。
0694名無しさん＠お腹いっぱい。02/02/22 11:31ID:???
>>691
で、そういう会社に限ってスタッフに逃げられると、そのままポシャルんだよなぁ･･･
そいつ等の開発水準すら維持できなくて｡
0695名無しさん＠お腹いっぱい。02/02/22 11:33ID:???
>>694
実際、それでポシャる、もしくは瀕死になったメーカーは相当あるぞ｡
0696名無しさん＠お腹いっぱい。02/02/22 11:46ID:???
>>691
クラス図やシーケンス図を補完するのは開発者の為ではくて、開発会社の為
なのに、それを否定するって、それでメシ食ってけるのか？
そういうヤシは、すぐ仕事ホサれると思うんだが｡
0697名前は開発中のものです。02/02/22 17:13ID:gH0SaIAu
>>696

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

けど、デザイナーとゲーム開発者と間で、システムの中核の開発が終わってない
ってのに、のんびりと UML図を作っては書き直し、作っては書き直し、なんてマ
ヌケなことはしないでしょう。
0698名前は開発中のものです。02/02/22 17:16ID:???
開発＝コーディング　なの？

UML で図を書くというのは、何もお絵かきして遊んでるわけじゃなくて、問題の
分析／設計をやってるんだけど。
069969702/02/22 17:20ID:gH0SaIAu
あ、話の流れを見てみると、
「完成し終わったライブラリのUML図を開発会社が保管」という意味での
UML 図の保管ということみたいですな。

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


>>698

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

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


UML図は紙に描いて意思疎通が終わったら丸めて捨てるのがベストだと思います。
0700名前は開発中のものです。02/02/22 17:25ID:???
>>699
俺は、仕様が変わるからこそ開発資料を作るけどなぁ。

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

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

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

なんてのを、その場で大雑把にでも見積もるのが難しくない？
070170002/02/22 17:31ID:???
追記

> （なぜなら、どうせすぐに古くなってしまうから・・・）
up to date に保てないような図なら、まるてて捨ててしまえ、というのは同意。
だから何でもかんでも図にしろっつーのは俺も反対。
0702名前は開発中のものです。02/02/22 17:37ID:gH0SaIAu
>>700

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

もし、仕様変更が無かったらどうしましょう。
仕様変更のために資料を作ったのがムダになってしまいます。
0703名前は開発中のものです。02/02/22 18:27ID:???
>>702
仕様変更に備えるのは、理由の一つで

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

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

むろんＤＱくらい売れるなら使いまわし前提にプログラムを組む余裕はあるだろう。
シナリオ、バランス調整のほうが時間かかってるだろうし。
0705名前は開発中のものです。02/02/23 15:06ID:???
>>704
陳腐化が速くて再利用が厳しいのは確かだが、それでも昔の

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

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

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

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

開発期間が伸びた場合に嵩むコストも昔の比じゃないし、外から資金を調達し
てる場合にはスケジュールに関して「プログラマは８割方できてると言ってます」
では済ませてくれないしね。
0706名無しさん＠お腹いっぱい。02/02/25 14:03ID:???
それに自分達がその資料や資産をもう必要としなくても、ほぼ同時並行
で進行中の別チームがソレを切実に必要とするケースは結構あるよ｡

だから「設計は俺の頭の中にある」っていうのは、ソイツの独り善がりの
台詞としか思われなくなってる｡　たとえ腕が確かでも｡
0707名前は開発中のものです。02/02/25 19:43ID:JMhB1+u9
注意すべきなのは、ドキュメント使ってる人がいるかどうか、だよね。

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

見る人がいれば、できるだけ短い分かりやすい文章で解説して、そして
やっぱ一番効率がいいのは面と向かってのやりとりだね。2ch で設計の
議論やろうとしたら全く非効率極まりない。
0708名前は開発中のものです。02/02/25 20:27ID:???
>>707
だから使ってる人がいるかどうかってのは、製作者自身が決める事じゃない
ってーの｡
たとえ実際に必要とされなくとも、自分達が作った物に対する詳細な資料を
作製、添付するのは、その完成品で金を貰う人間としては当然の義務だぞ｡

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

仕事で、そんな事されたら俺は上司にそいつを更迭するよう強く迫るけどな｡
第一、ドキュメントもロクに作れん様な奴が人に判りやすく説明できるわけ
無いだろうが｡
0709名前は開発中のものです。02/02/25 20:42ID:???
>>708
ドキュメント書かないヤツは論外だが、ドキュメント過剰も良くないとは思う。プロ
ジェクトの規模が大きくなって、それこそ業務用システムのような

　数千人月

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

　開発者数人

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

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

>>707
資料って OO だと UML で大雑把に書いて、そこにノートでコメントを書き込む方
が、文章で書くより分かりやすくないか？
0710名前は開発中のものです。02/02/26 03:25ID:???
＞だいたい、３〜４年たつと新ハードがでて、作ったものがかなり陳腐化するのが
＞どうしようもない原因であるよ。３ＤといってもＸ−ＢＯＸとＰＳ２とＰＳ１で
＞も別世界だし。　もうしばらくはその場しのぎを続けるしかないだろうな。
いっちゃ悪いけど、「描画系」と「アプリ系」をきっちり分別して開発する
ことに困難を感じている君は修行不足だと思う。
071171002/02/26 03:28ID:???
特に、PS2 -> X-Box への移植に困難を感じているのならば
開発時の整理整頓を真剣に考えた方がいいと思う。
0712名前は開発中のものです。02/02/28 12:39ID:ssS9vuX/
OO ってプログラムの複雑度を下げるよなぁ…って思ったんだけど、
これについての意見プリーズ。

思いつきだから自分でも確証ないんだよね。どうなんだろう？
0713名前は開発中のものです。02/02/28 20:40ID:???
>712
構造的にはそうかもしらんが
ソースコードは長くなるぞ

というよりアンチOOから怒濤の煽りが来そうなﾖｶﾝ
0714名前は開発中のものです。02/02/28 21:31ID:???
スパゲッティがほどけて独立性が上がっても、
その独立したものどうしを繋ぐのに複雑性が上がる罠。
071571202/03/01 00:34ID:???
>>713
ソースコードの長さって問題なのかな？たいした問題じゃないと思うんだけど。
みんなそんなにキーボード打つの遅いの？

>>714
なるほど、だから UML とか デザインパターンズ とかが重要になるんだね。
0716名前は開発中のものです。02/03/01 01:55ID:???
ズ
0717名前は開発中のものです。02/03/01 02:27ID:???
そうズら
0718名前は開発中のものです。02/03/01 02:48ID:???
複雑度を下げるというより上げると思うんだが
複雑なことが安全にできるようになるって感じ。
ソースコード対効果比（Ｓ／Ｎ比）は高い。
掛ける時間は設計９０％、コード１０％くらいになった。
0719名前は開発中のものです。02/03/01 03:50ID:???
たしかここだったと思うけど、OOPでSTG（凄く簡単な雛型）作った人が、
ソースUPしてたと思うけど、勝手に弄らせて貰ってます。

何か形になりそうだったら、UPします。
0720名前は開発中のものです。02/03/01 09:01ID:2Wt9xxPq
Effective STL買ってきて読んでるけど
shared_ptr（・∀・）ｲｲ!! 怪しい自作スマートポインタとはお別れだな。
0721名前は開発中のものです。02/03/01 12:24ID:???
>>720
weak_ptr も調べると幸せになれる。(boost 1.27 以降だったかな)
0722名前は開発中のものです。02/03/01 12:28ID:???
>>719
ライセンス条件は確認した？　BSD ライセンスとかならともかく、そうでないと
「参考にするのは OK だが、コピペで使うと著作権法違反」とかの可能性もあ
るから注意ね。
0723narucy5602/03/01 23:18ID:06YWXjZs
>>718

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

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

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

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

だれもが 3分 で内容が理解できるくらい単純な設計でないといけない。
そういう意味じゃ本来は設計には時間を費やさないのが、OO をマスターしてからは
重要なんだと思う。
0724名前は開発中のものです。02/03/01 23:40ID:???
>>723
> OO に慣れた人なら、ちょっとしたディスカッシヨンですぐに設計は完成しちゃう
気のせい。
0725名前は開発中のものです。02/03/02 06:07ID:???
>723
その３分程度でできるのはモデリングだけだろ・・・
072671802/03/02 06:46ID:???
ありがとうございます。
往々にしてあほ(笑)なので私はまだすぐに設計が完成…という境地には
至ってないですね。がんばりたい。
0727XP02/03/04 04:33ID:fGL1MkkH
先のことを考えて作らないこと。自分が設計にこもりはじめたり、
一般化をはじめたりしているのに気がついたら、ストップ。動作す
るもっとも単純なことを実装して、今しなくてはいけないことをす
るのだ。「あとで必要になるはずだ」と言っている自分に気がつい
たら、あなたは貴重な時間を無駄にしているということだし、顧客
からプライオリティを設定する権利を奪い取っているということだ。
0728名前は開発中のものです。02/03/04 04:57ID:???
>>727
正直、リファクタリングは

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

前提の話だと思う。いい加減な設計しか出来ない／設計しない人が言い訳に
使うのは許さん。
0729名前は開発中のものです。02/03/04 06:18ID:???
もとの設計がダメでそれから派生した多種のクラスもダメだった
その修正がいい加減嫌になって全部捨てて結果
全世界の開発者の貴重な時間を無駄にした例がＭＦＣだよね
0730名前は開発中のものです。02/03/04 15:01ID:???
>>729
MFC 叩きはよそでやれ。
0731名前は開発中のものです。02/03/04 17:42ID:???
>>729-730
秀同（ｗ
0732名前は開発中のものです。02/03/06 03:48ID:d8OL+l1I
良スレ期待age
0733名前は開発中のものです。02/03/08 16:14ID:QLWVytdE
設計のベストなあり方としては、以下のページによいものがあった。

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


設計はやっぱしなきゃだめ。
でもそれは複雑になりすぎちゃだめ。
時間をかけすぎてもだめ。
しっかりできても他人に説明できなきゃだめ。
0734名前は開発中のものです。02/03/08 18:16ID:???
>>733
読んでみたけど、妥当な意見に思えるな。
0735名前は開発中のものです。02/03/08 23:38ID:???
>>733
どうでもいいが、こうあるべきという主張はやめたほうがいいよ。
XPかぶれてるのはわかるけど。
0736名前は開発中のものです。02/03/09 00:33ID:???
>>735
> XPかぶれてるのはわかるけど。
リンク先のドキュメントも >>733 の文章（設計の終焉? の要約だと思うが）も、
むしろ XP の中では穏健派の書いた文章だぞ。

XP について賛成するにせよ反対するにせよ、とりあえず XP について調べて
理解しとけ。話はそれからだ。
0737名前は開発中のものです。02/03/09 00:50ID:zvT+Hk0x
XPを実践できるのは天才だけ？
073873502/03/09 00:51ID:XwdiXSCe
>>736
んー？ベストなものなんて世の中には無いって言ってるのさ〜。
XPについては何も言ってないぞ。
0739名前は開発中のものです。02/03/09 01:23ID:???
>>738
> XPについては何も言ってないぞ。

XP について何も知らないのに
> XPかぶれてるのはわかるけど。
と言うの？　ダメじゃん。
0740名前は開発中のものです。02/03/09 01:25ID:???
>357
＞XPかぶれてるのはわかるけど。
>738
日本の政治家みたいなﾔｼだな（藁
0741名前は開発中のものです。02/03/09 01:26ID:???
ポインタ間違えた・・・
×>357
○>735
0742名前は開発中のものです。02/03/09 01:55ID:???
がんばれよ（藁
0743名前は開発中のものです。02/03/09 02:50ID:???
やだ（ｗ
0744名前は開発中のものです。02/03/17 02:50ID:62wXi74P
age
0745名前は開発中のものです。02/03/17 03:13ID:???
XPなんてｶﾞｷのｼｮﾝﾍﾞﾝ臭いものを勝手に作っておいて
勉強しろなんてひどいな
074671902/03/17 07:42ID:SG2XMPR0
（多分ここで）UPされたOOPSTGに、簡単なタスク管理追加、DIRECTX化、
したものをUPしようかと思います。
（環境、Ein98SE,P31G,GForce3）
著作権法違反は、特に記述がなかったのでOKだと思います。

当り判定（タスク間のやりとり）をまだ入れてないんです。
各（自機の）弾タスクが、（敵の数分の）タスクを総ナメしないと
いけないんですかね？やっぱ。判定に段階を設けるとしても。
0747名前は開発中のものです。02/03/17 11:29ID:mjqfxEH/
>著作権法違反は、特に記述がなかったのでOKだと思います。
　
お〜い、はに丸。著作権は何もしなくても自動的に発生しますよ。
改変と再配布の許可が明示されているのでなければ、
一応作者に問い合わせるしか。
0748名前は開発中のものです。02/03/17 13:38ID:???
>>747
同意。

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

っつか C++ で書いたシューティングゲームの雛型なら MIT ライセンス
で公開されてるものがあるぞ。
074971902/03/18 00:39ID:tIFzPCA5
>>747
はにゃ？そうスか、、。無知を晒してしまったですな。
ソース自体は、殆ど書き換えちゃったんですがね。実は。
やめといた方がよさそうですね。
作者の方へコンタクト取れそうにないし。

>>748
出来れば、詳細を教えて下さい。どんな設計か興味あります。
（特にクラス間の情報のやり取り等）
シューティング　C++　で検索しても見つけられなかったです。
0750名前は開発中のものです。02/03/18 02:40ID:VWHiZCDa
ximpactもC++で書いてあった気が
0751名前は開発中のものです。02/03/18 04:31ID:???
>OOPSTG
開発状況報告スレのここらへんじゃない？
http://game.2ch.net/test/read.cgi/gamedev/1005143186/212-

あとここ。
http://www.sm.rim.or.jp/~shishido/gamedev.html
0752名前は開発中のものです。02/03/18 19:05ID:???
>>749
これ。

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

ただしソースはあるけど操作に必要なリソースファイルは置いてないし、
当たり判定もまだのようだが。
075371902/03/19 01:30ID:9e3mOAQn
>>751
おお！THX!ビンゴです。早速問い合わせてみます。

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

今、某CUBEやってるんですが、コールバック関数のラッピングに手間取ってます。
(static)関数内でクラスにアクセスのに、とりあえず、グローバルポインタ渡すしか
思いつかない、、。
0754名前は開発中のものです。02/03/19 01:56ID:???
>>746
　当たり判定は当たり判定管理クラスにタスクを登録して結果を
コールバックで取得＆反映って感じでしょ。

　後は判定管理クラス内をレイヤー化して置く事で様々な状況に
対応できるようにすると。
075571902/03/19 04:05ID:9e3mOAQn
>>754
すいません。良く解らないです。

コールバックって、キリの良い所で処理を返す必要がないものに
対して使うものだと認識してます。
（メモカ、CDの裏読み等）当り判定って、フレームごとに全て完了
させないとイケナイ気がするんですが・・。
0756名前は開発中のものです。02/03/19 04:17ID:???
>>755
> コールバックって、キリの良い所で処理を返す必要がないものに
> 対して使うものだと認識してます。
認識が間違ってます。
0757名前は開発中のものです。02/03/19 05:05ID:???
>>755
ウンウン、コンシューマな人だねぇ…。
別にハードウェア割り込みから呼ばれる関数をコールバックと限定
するワケじゃないハズだよ。

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

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

　次にレイヤー化する事によるメリットって？みたいな質問がくると
更に嬉しいんだけど。
0758名前は開発中のものです。02/03/19 11:42ID:???
レイヤー化する事によるメリットって？
0759名前は開発中のものです。02/03/19 11:53ID:???
>758
ｵﾏｴ755じゃないだろ
0760名前は開発中のものです。02/03/19 12:07ID:???
うん
0761名前は開発中のものです。02/03/20 01:06ID:OKAtcaEA
>>757
　それより先に、コールバックで結果を通知することのメリットの方が聞きたい。
（レイヤー化のメリットは、わかる。俺もそうしよ（ｗ ）
　当たり判定管理クラスにAddHitData(Task &, int) IsHit(Task &, int) ってなメソッド
を用意して、前者で当たりの登録（これはTaskスタート時１回でいい）、でIsHitで結果
を知るってな方が自然だと思う。
　コールバック方式って、やっぱ、HitMeの時には登録が行われるだけで、タスク処理
が全部終わったあと、当たり判定管理クラスの実際に判定を行うメソッドを呼んでやる
と、その中でコールバックが呼ばれる感じだよね？となるとコールバックの中で進入禁
止の処理やら、アイテム拾ったときの処理やら、攻撃受けたときの処理やら全部やら
なきゃいけないわけで、そういう処理はタスク処理の中に書けた方がわかりやすいので
は？
0762名前は開発中のものです。02/03/20 01:11ID:???
>>761
本筋からずれるが、なんでもかんでも Task クラスに突っ込まずに、

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

の方が、柔軟性が増すぞ。
076376102/03/20 01:15ID:OKAtcaEA
あ、わかった。タスク処理の中であたり判定処理しちゃうとタスクの実行順で
当たり判定データが現フレームの物だったり前フレームの物だったりしちゃう
からか。
0764名前は開発中のものです。02/03/20 01:20ID:???
>>761
757 じゃないが、メリットは

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

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

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

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

当たり判定はともかく、タスク実行と描画は実行順序を独立に定義するために、
分離するのが普通だよな。
0765名前は開発中のものです。02/03/20 01:21ID:OKAtcaEA
>>762
多重継承より、オブジェクトコンポジションの方が良いと思われ。
0766名前は開発中のものです。02/03/20 01:27ID:???
>>765
インターフェースの多重継承と、実装の多重継承を勘違いしてないか？

コンポジションだと、タスク内部の情報にアクセスするのが難しくなるぞ。
076776102/03/20 01:33ID:OKAtcaEA
>>764
>当たり判定はともかく、タスク実行と描画は実行順序を独立に定義するために、
>分離するのが普通だよな。
うい、そうですな。

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

＃ちなみにその二つのメソッドはanimate、renderという名前。renderといいつつ、
当たり判定とそれによる位置変更もやる……名前と内容が一致してない……。
076876602/03/20 01:38ID:???
実例を挙げた方が良いか。

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
　　　　　　...
　　}
};

インターフェースの多重継承を利用すれば、こんな感じでタスクの内部状態
を利用して当たり判定を変更することが、容易に可能になる。コンポジション
で同じ事をやろうとしたら、思い切り不自然なコードを書くことになるぞ。
0769名前は開発中のものです。02/03/20 01:40ID:???
>>766
ん、勘違いしてた。
ああ、762が言っている方式では、タスクマネージャーの方から当たり判定用の
メソッドを呼び出して当たり判定を実現するって事なのかな？（柔軟、か？）
077071902/03/20 01:52ID:3YnMUW/P
winのような、イベント駆動型とかをイメージすればいいのかな？
いやー。正直、よくわからんスｗ避けてました。
勉強してきます。

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

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

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

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

それじゃ、
次にレイヤー化する事によるメリットって？
0771名前は開発中のものです。02/03/20 01:54ID:???
>>767
> 実行順に依存させたくない処理は ぜんぶコールバックでやるべきなんだ
> ろうか？
そう思う。

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

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

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

（あと優先順位無し、登録順で処理する IObjectCommand っつーのもある）
0772名前は開発中のものです。02/03/20 01:56ID:OKAtcaEA
　>>768 の方式だと、オブジェクトごとに当たり判定の実装が必ず
違うのであれば問題ないけど、このオブジェクトとこのオブジェクトは
実装一緒ってな事が多いとコピペが氾濫したり、もう一個クラス作って
へんちくりんなメッセージングすることになったりしない？

　俺は757のいう当たり判定管理クラスってのを導入した方が
スマートだと思うから。
　メンバとして持ったhittableのインスタンスの参照を当たり判定
管理クラスに丸投げしてやるだけでいいと思うので、複雑にはな
らないと思う。
0773名前は開発中のものです。02/03/20 02:05ID:???
>>772
> このオブジェクトとこのオブジェクトは実装一緒ってな事が多いと
そのときには template を使って Mixin すれば OK。

っつか 768 も

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

のは同じだけど。設計方針は変わらず、たんに C++ で都合がいい実装方法を
紹介しただけ。（コールバックの代わりに多重継承を使うと this の受け渡しが楽
だぜ、という程度の話）
077476702/03/20 02:11ID:OKAtcaEA
　俺のは２つだけど、>>770 のは３つに別れている、って事なのね（w
　こうなるとじゃぁ４つに分割、５つに分割と仕様要求次第じゃきりがない
って話になるな。
　タスク処理メソッドを可変長リストで持って、とかすると無駄に複雑に
なりそうだから、>>771 の言う通り、「実行順に依存させたくない処理は
ぜんぶコールバックでやるべき」なのかも。

>上のほうで挙がってた DxApp だけど、あれは描画とタスク実行を切り離して
>別々の優先順位で処理するようになってる。
　フロー制御はタスク機構だけで十分、というのは強引かな、やっぱ。（あ、俺
のシステムだとanimate、renderメソッドの呼び出しそれぞれに別々の実行順を
設定できるから、同じ事が実現できてはいる）

>>773
>> このオブジェクトとこのオブジェクトは実装一緒ってな事が多いと
>そのときには template を使って Mixin すれば OK。
あ、なるほど（ｗ
0775名前は開発中のものです。02/03/20 02:17ID:OKAtcaEA
>>773
>（コールバックの代わりに多重継承を使うと this の受け渡しが楽
だぜ、という程度の話）
たしかに、関数のポインタを渡すより、オブジェクトのインスタンス
渡した方がいいですな。

　つまり、基本はタスクでフロー制御して、その実行順に依存したく
ない物は全部GoFの言うところのCommandパターンでやるのが吉、
ってことかな？
0776名前は開発中のものです。02/03/20 02:29ID:???
>>772
C++ 限定の手法だが、template を使った Mixin の例。

template <class T>
struct hittable_invisible : public hittable
　　void get_hit_rect(rect& rc, hit_type& htype)
　　{
　　　　T& obj = static_cast<T&>(*this);
　　　　if (obj.invisible_)
　　　　　　rc = INVALID_RECT;
　　　　else
　　　　　　...
　　}
};

class player : public hittable_invisible<player>
{
　　bool invisible_;
public:
　　...
};

効率と汎用性、そして型安全性を全て損なわずに実現してる。ペナルティは
コードサイズの増大。
077771902/03/20 02:47ID:3YnMUW/P
>>774
３つ？ですか？

大まかな流れはさっき書いたものなんですが、言葉足らずだったかも。
ちょっと細かく言うと、
UpdateFrame()は,ゲームアプリ、タスクマネージャ、
描画エンジン、vプリミティブ（描画）、v各TCB、v各タスククラスが持ってて、
vがついてる奴が仮想関数です。

EndScene()は今の所、託すマネージャのみのメンバ間数です。

Draw()はタスク処理とは関係ないです。
こちらは描画エンジン、各（と言っても今実装してるのはスプライトのみ）
プリミティブクラスで使ってます。

タスククラスは、
tcbBase<-tcbSprite(今これだけ)
tskBase<-各キャラタスク　となってて、
tcbSpriteのメンバにVectorでtskを保持して、チェンジタスクで
切り替えています。

tcbSpriteが、（スプライト）プリミティブからリソースを貰って
UpdateFrameで更新してます。

描画エンジンの方にも、UpdateFrameはあって、アニメ処理、タスクが
弄った頂点データをビデオボードに転送したりしてます。
0778名前は開発中のものです。02/03/20 02:51ID:???
>>757
話が落ち着いたところで、そろそろ「レイヤー化する事によるメリット」を
語ってくれると嬉しいトコロだが。

そもそも「レイヤー化」を、どういう意味で使ってるのか分かってなかったり
するので、単語の定義からお願いします。
0779名前は開発中のものです。02/03/20 03:03ID:???
>>777
　ああ、タスク毎の処理は１種類で、当たり判定の処理（タスク実行順に
依存したくない処理）はタスクマネージャーがグローバルに行う、ってわ
けですね。
（´ー｀）。oO（ 本当、人それぞれだなぁ ）　
0780名前は開発中のものです。02/03/20 06:31ID:9RjuXxJB
このスレの最初のほうにCとC++ではCの方がC++で作ったときよりも
実行速度が速い、もしくは同等と書かれていたんだけど、
ヘボプログラマはCで作っておいたほうが無難ということなの？
そこで言われているCとC++との違いはクラスの使用から来るもの？
0781名前は開発中のものです。02/03/20 07:15ID:???
>>780
実際にわずかなオーバーヘッドがあるし、まずい設計では
暗黙のコンストラクタ/デストラクタによって積み重なって遅くなる。
C++についてよく理解してないと、ただ遅いだけの道具になるよ。
078278102/03/20 07:18ID:???
C と C++ の違いは主にクラスによる。
同一な C プログラムなら C++ でコンパイルしても
速度はほぼ同一なはず。ライブラリとか最適化の具合にももちろんよるけど。
0783名前は開発中のものです。02/03/20 11:13ID:???
>>780
書籍「Inside the C++ Object Model」で詳細に解析してるから、それを
読むのがいいと思うが。

メンバ関数（メソッド）を呼び出す場合に this が暗黙のうちに渡されたり、
仮想関数を呼び出すと間接参照が何度か（一般には 2 回）入ったりす
る。ただ、このあたりのことは C でも同じ処理をやろうと思ったら、

　関数の引数として、構造体へのポインタを渡す
　関数ポインタを使う

必要があるから、ホントは変わらないんだけど。

> 暗黙のコンストラクタ/デストラクタによって積み重なって遅くなる。
synthesize constructor / destructor のことを言ってるんだと思うが、
それなら C だって「初期化処理を入れたら遅くなる」というのと同じ。
trivial constructor / destructor で済むクラスなら、初期化・終了処
理を省くことも出来るし。

C でも C++ でも「同じ処理をさせよう」と思うと、実際には「同じだけの
コストがかかる」ことになる。ただ C++ では、synthesize constructor/
destrurctor や temporary object のように

　コンパイラが、見えないところでコードを付け加える

ことがあるから、そこを意識していないと、たった数行のコードなのに
コンパイルすると数千命令に展開されていた、ということが有りうるの
で注意が必要。
0784名前は開発中のものです。02/03/21 00:42ID:I/OXI3by
>>778
　フォトショップのレイヤーを思い浮かべると良いと思われ。
　当たり判定を取る当たり同士をグループ化して、グループに番号を付けておく。

　進入禁止系のあたりをレイヤー０番に置くとして、壁、NPC、敵キャラのあたりは
HitMe( ???, 0)と呼び出してやる。プレイヤーオブジェクトはそれが壁なのかNPCな
のか区別せずにすむ。
　で、レイヤー１番はアイテム系の判定として、アイテムオブジェクトとプレイヤー
オブジェクトだけが所属する。そうすればNPCオブジェクトの方で接触のあった
オブジェクトがアイテムだったら何もしない、なんてコードを書かなくて済む、と。

　こんな感じ？
0785名前は開発中のものです。02/03/21 11:11ID:???
すげぇ、この板に役に立つスレがあったのか。
■ このスレッドは過去ログ倉庫に格納されています