ゲームにおけるデータ構造・クラス設計・パターン

**名前は開発中のものです。** · 2006/08/10(木) 20:27:06

具体的なゲーム名を挙げて、
どのようにクラス設計をすればよいか、
継承・委譲関係はどのようにすればよいか、
使えそうなパターンは何かなど語るのもよし。
自作ゲームの内容とクラス図を書いて
改善案を聞くもよし。
設計に関して困ったことを質問するもよし。

関数の具体的な実装内容やゲーム内容に関しては他スレに譲る。
大いに語れ。

**名前は開発中のものです。** · 2007/09/16(日) 12:12:44

>>571
Google は給与水準公開してないから情報限られるけど、俺が中の人から
聞いた話だと十分高いと思った。

それより株式公開前にストックオプション貰ってた連中は、上場と同時に
億万長者の仲間入りしちゃってるから、それと比べると給与はどうでも
良いっつー話らしいが。

**名前は開発中のものです。** · 2007/09/16(日) 19:28:45

絶望した。上場したてのGoogle株を買って、任天堂に乗り換えれば
たった3年で20倍になってる事実に絶望した。
絶対うまいこと乗れたギーク系投機家がどこかにいるはず。

**名前は開発中のものです。** · 2007/09/16(日) 20:24:04

お前ら良いなgoogleが上場とか、俺の頃はまだyahooすらなかった。
CEREN vs NCSAのhttpd戦争終結後くらいか・・・。

**名前は開発中のものです。** · 2007/09/16(日) 20:58:05

みんな、UMLとかdoxygenとか使ってる？

**名前は開発中のものです。** · 2007/09/16(日) 23:32:07

どっちもつかってます

**名前は開発中のものです。** · 2007/09/17(月) 01:15:23

javaだからdoc toolはデフォだな。

**名前は開発中のものです。** · 2007/09/17(月) 01:50:53

色気出してプリプロセッサ・テンプレートメタプログラミングしてると
doxygenが酔ってくれるから困る

**名前は開発中のものです。** · 2007/09/17(月) 10:46:54

doxygenはマニュアル作ってくれる事もいいんだけど、コメントの規格を統一できるのもいいよな

でも、心がけてくれないチーム員もいるんだよなあ

**名前は開発中のものです。** · 2007/09/17(月) 11:33:01

■□■□■□■□■□■□■□■□■□■□■□■□■□■ □■□■
　　　　　　　　――――Click Click Click――――
それは、一番クリックした国が優勝するバカバカしくも熱いゲーム！
2ch全板から力を結集して日本を１位にしよう！日本は過去に8勝（世界最多）しています。
めざすは、台湾の6連勝記録を打ち破ること！
現在日本は３連勝中だけど、猛加速のハンガリーに昨夜逆転されてしまいました。
日本のツールはとても優秀ですが、参加人数が足りません！！
逆転するには、最低でもあと100台のPCが必要です。
専用ツールを落として、ブラウザを起動しておいてくれるだけでOKです！
放置できるので、寝ながら日本の戦力になることができます！
どうか力を貸してください！

【日本２位】一番クリックした国が優勝【版画ｋｓk】
http://wwwww.2ch.net/test/read.cgi/news4vip/1189932725/l50

※オリジナルのゲーム制作チームがあります。ぜひ力を貸してください。

**名前は開発中のものです。** · 2007/09/17(月) 11:46:33

doxygen で生成したドキュメントは使ってないが、doxygen 用にコメントは
書いてる。(javadoc 形式というべきか)

> コメントの規格を統一できるのもいいよな
目的はこっち。

**名前は開発中のものです。** · 2007/09/17(月) 12:30:12

実際のチーム開発の現場って、
コメントだけでなく、ファイル名とかクラス名とか変数名とかのコンベンションも
やっぱ決められてるもんなの？

**名前は開発中のものです。** · 2007/09/17(月) 12:33:20

>>582
当然。

ただ汎用ライブラリを持ってくることもあるから、そっちとこっちで
規約が違って一部混在することはある。たとえば STL と DirectX
だと名づけ方大分違うしな。

**名前は開発中のものです。** · 2007/09/17(月) 15:33:27

>>575
Delphi使いなんで、Togetherで UMLはコードから自動生成だぜ～（嘘、使いません

ドキュメント生成ツールは、日本語対応したものがなくて、使ってない orz

**名前は開発中のものです。** · 2007/09/17(月) 19:51:10

doxgenは日本語出せたよ、Delphiに対応してない気が下が

**名前は開発中のものです。** · 2007/09/17(月) 23:45:15

>UMLはコードから自動生成だぜ
普通設計してからコード書かないか？
UMLの仕様上は確かにcode2UMLもUML2codeも相互運用可能だけど・・・。

**名前は開発中のものです。** · 2007/09/17(月) 23:57:57

>>586
ネタにマジ(ry

> UMLの仕様上は確かにcode2UMLもUML2codeも相互運用可能だけど・・・。
C++ は code generation に向かない言語だなぁとおもうよ。

集約・コンポジション・関連の区別とかつけにくいし、boost::scoped_ptr で pimpl イディオム
使ってる場合とか、マジメに piml クラスもクラス図に入れると煩雑になりすぎ。

私は設計段階で主要クラスだけ図に書き出して、あとはコードでって感じ。
クラス図は必要があれば更新するけど、あくまでコードが第一の文書に
しちゃってる。

**名前は開発中のものです。** · 2007/09/18(火) 00:16:16

UMLはドキュメントとしてはいいが、コードにそのまま適用されるものではない
というのは比較的お堅い業務アプリでの常識なんだが
柔軟性が求められるゲーム開発ならなおのことじゃね？

組込み系が今突撃中

**名前は開発中のものです。** · 2007/09/18(火) 00:22:12

そこでinterface definition languageですよ

**名前は開発中のものです。** · 2007/09/18(火) 01:16:19

IDLでも結局は各言語に落とさなきゃ使えないからやる事はUMLとかわらなくない？

**名前は開発中のものです。** · 2007/09/18(火) 08:32:52

UMLってやっぱEAでやってるの？
eclipseでNECのプラグインのを最近使ったんだが

**名前は開発中のものです。** · 2007/09/18(火) 19:37:18

個人的には MagicDraw とホワイトボード。

**名前は開発中のものです。** · 2007/09/19(水) 06:01:52

まず、マインドマップで手書きして頭の中整理してからUML使うな。

**名前は開発中のものです。** · 2007/09/19(水) 07:15:57

紙と鉛筆最強

**名前は開発中のものです。** · 2007/09/19(水) 08:22:34

同意。小型ホワイトボードもいい。

**名前は開発中のものです。** · 2007/09/19(水) 21:49:02

Eclipseのプラグインなんて使うのは、UMLドキュメントも成果物として要求されるような
ソフトウェア製作現場くらいじゃないか

**名前は開発中のものです。** · 2007/09/19(水) 22:07:56

そうなんだ・・・eclipseのプラグインでしか良いのないなーって思ってた

**名前は開発中のものです。** · 2007/09/19(水) 22:43:10

それよりeclipseのプラグイン=UMLツールって図なのはどうなのよ？

スタンドアローンなUMLツールもちゃんとあるんだからね！？

**名前は開発中のものです。** · 2007/09/19(水) 22:49:24

>>598
> スタンドアローンなUMLツールもちゃんとあるんだからね！？
俺が使ったことあるのは、こんな感じ。結局 MagicDraw の Standard Edition 買って
使ってる。

Visio
・汎用お絵かきツールなので UML 専用ツールとしてみると、かなりイマイチ…

Together 試用版
・ソースコードに特定の形式でコメント埋め込む必要あり。ソースコードと UML の
　同期は完璧だが、C++ だとマクロやらテンプレートやらあって逆に足枷に。

Enterprise Architect
・細かいことは忘れたが、値段の割りによくできてた気がする。

Jude竹
・使いづらかった記憶が。Java 前提で C++ だとイマイチ。

MagicDraw
・それなりに自由に図がかけつつ、UML 固有のサポートも十分している（基底クラスの
　メソッドをコピーしてくるとか）。サポートしている図の種類も豊富で、開発も順調に
　継続中。Pure Java アプリなのでメモリは多めに。

　ただ C++ だとソースコードと同期する reverse engeneering, forward engeneering は
　制約ありすぎで使い物にならない。

**名前は開発中のものです。** · 2007/09/21(金) 00:31:32

C++ …

**名前は開発中のものです。** · 2007/09/21(金) 16:35:38

なんかC++のマクロが元凶なだけじゃ・・・。
javaにマクロないし。

**名前は開発中のものです。** · 2007/09/21(金) 22:17:12

>>601
スマートポインタ・pimplイディオムあたりも、そのまま図にすると冗長で
ワケわかめ。

**名前は開発中のものです。** · 2007/09/23(日) 23:05:37

javaにスマートポインタなんてないし世代別GCという逸材が組み込まれてる。
とか言ってみて良い？

実際javaでGCが必要になるケースって言語実装する場合だけど、javaのGCに投げれば良いだけだし。

**名前は開発中のものです。** · 2007/09/23(日) 23:32:34

え、いや、だから何？としか･･･

**名前は開発中のものです。** · 2007/09/24(月) 00:13:37

>>603
文面見るだけだと、集約とコンポジションの区別がつかんけどな。関連との区別も
つかないし。

**名前は開発中のものです。** · 2007/09/24(月) 00:36:17

>>603
CでもC++でもライブラリでGC使えるようになるよ
とか言ってみて良い？

デストラクタのタイミングがJavaだと曖昧だから、
確実に呼ぶためには明示的に呼び出す必要あるよね
とか言ってみて良い？

**名前は開発中のものです。** · 2007/09/24(月) 00:38:43

Dispose論争がやりたいなら他でやってくれ

**名前は開発中のものです。** · 2007/09/25(火) 01:43:17

共同開発で、Bohemなんか使ったら（ｒｙ

**名前は開発中のものです。** · 2007/09/25(火) 01:59:20

>>608
アーーーー！！

**名前は開発中のものです。** · 2007/09/25(火) 02:50:51

Bohemと言えば、吉里吉里３の開発で使っていたような。
と思って調べてみたら、やはりけっこう面倒になことなっているようですね。
ttp://kikyou.info/diary/?200603

C++でGCをするのは、やはりリスクは大きいんでしょうかね。
挙動をきちんと把握していないと、余計なバグを出しまくると。

**名前は開発中のものです。** · 2007/09/25(火) 07:15:30

まさにそれで右往左往してるじゃん。吉里吉里３は。
というか誰のコードが入るか分からんOSSにはBohemGCは向いてないと思う。

**名前は開発中のものです。** · 2007/09/25(火) 14:42:50

> とくにファイナライザ(デストラクタ)が呼ばれるタイミングや、
> そもそも呼ばれるか呼ばれないかすら信用できなくなるというのは痛いです。

これってBohemGCというか、
JavaでもC#でも似たような問題抱えてるような気が。
C#はusingでだいぶ良くなる（というか必須）けどね。

**名前は開発中のものです。** · 2007/09/25(火) 15:49:03

C#でusingを使えるような状況なら、C++でも
std::auto_ptrやboost::scoped_ptrが使えるのでは。
まあこの当たりのスコープによる廃棄を使えるのは、データ構造でなくその
呼び出し側のほうになるとは思いますが。

データ構造の内側たるメンバ変数では、結局いポインタwをを使おうとすると、
やはりGCかスマートポインタが(r

**名前は開発中のものです。** · 2007/09/25(火) 19:45:25

ヒープの解放と後片付けは違うぞ

**名前は開発中のものです。** · 2007/09/25(火) 23:37:49

>>611
全然右往左往はしてないので、BohemGCは向いていると思うよ

**名前は開発中のものです。** · 2007/09/26(水) 02:49:14

>>614
java6からはそこらへんもVMの仕事だな。

>>615
一時期、他のコードとの相性で苦戦してただろ。
というか吉里吉里は実質一人開発なのでバザールモデル開発時の問題は無縁かも知れん、
がソースを公開してるので誰がどう使うか分からないのでBohemGCは向いてないだろ。

**名前は開発中のものです。** · 2007/09/26(水) 04:16:25

>java6からはそこらへんもVMの仕事だな。
？

**名前は開発中のものです。** · 2007/09/26(水) 07:07:41

>>616
よく知らないんだけど、BohemGC特有の問題ってなんなの？
>>812はBohemGCだけの問題では無いよ。

**名前は開発中のものです。** · 2007/09/26(水) 08:13:44

>>616
w3m も BohemGC 使ってなかったっけ？

俺は C++ だとスマートポインタで十分なケースが多いので、BohemGC は
まず使わないけど。

**名前は開発中のものです。** · 2007/09/27(木) 02:23:21

>>616
ほら、言い直した。
「一時期問題があった」だろ？
それなのに>>610-611で2006年から今もずっと右往左往してるかのような印象操作をして、
BohemGCがOSSに向いてないとか、そんな詭弁はやめろ。
お前が古い人間で、よく理解出来ていないガベージコレクションが嫌いなだけなんだろ？

>ソースを公開してるので誰がどう使うか分からないのでBohemGCは向いてない
これとかまったく意味不明。
boostのshared_ptrでも、まったく理解しないで使うと罠がある。
そういう仕組みをまったく使わないで、手作業で開放しても罠がある。
お前の論では、ナニをやろうが向いていないんだよ。

>>619
スクリプト言語の作成は、スマートポインタだけだとしんどいと思う。
var a = [0];
a[0] = a;
これだけでメモリリーク起きるなんて、危なくて使えん。

**名前は開発中のものです。** · 2007/09/27(木) 02:44:05

ＧＣは魅力的だと思うが、まだ”枯れてないから”じぶんは好きくない
技術は何かを実現する手段であって目的ではない

**名前は開発中のものです。** · 2007/09/27(木) 07:51:02

枯れぬなら　枯らしてしまえ　ほととぎす

**名前は開発中のものです。** · 2007/09/27(木) 08:18:58

>>620
> スクリプト言語の作成は、スマートポインタだけだとしんどいと思う。
スクリプト言語の仕様にもよるな。

PCのギャルゲーだとスクリプト言語自体をリッチな仕様にして、動的な
メモリ確保なども可能にする（文字列連結とか）場合もあるみたいだけど、
俺はスクリプトでは完全にコンパイル時にメモリ割り当てが確定しちゃう
ようにして、メモリやリソース管理は C/C++ 側のコードでプログラマが
責任を持って行うようにしてる。

スクリプタとプログラマの役割分担どうするかだが、スクリプタ大量投入
するタイプのプロジェクトだと、スクリプトの自由度を下げた方がバグの
発生頻度が小さくなって、結果的にｳﾏｰなことが多いと思う。

**名前は開発中のものです。** · 2007/09/27(木) 10:54:43

なんで>>620はエスパーレッテル張りまでして必死なの？
吉里吉里信者？

**名前は開発中のものです。** · 2007/09/27(木) 11:00:37

確かに必死さが伝わってくるな

**名前は開発中のものです。** · 2007/09/27(木) 11:33:55

nanndeこんんあに必至なの？

**名前は開発中のものです。** · 2007/09/27(木) 12:37:22

池沼だから

**名前は開発中のものです。** · 2007/09/27(木) 13:19:16

荒れていても技術的な話題が堪えることのない名スレ
でも最近少々荒れ気味だから皆落ち着け

**名前は開発中のものです。** · 2007/09/27(木) 14:40:58

落ち着いてないのは>>620くらいじゃ？
元々隔離板の過疎スレだから少数が騒ぐと目立つだけ。
またーりログ読んでるか、生温かい目で見守ってるのが大半じゃない？

**名前は開発中のものです。** · 2007/09/27(木) 23:24:46

言うに事欠いて「必死だな」で切り抜けようと試みる
古典的バカが未だに生き残ってるとは驚きだな

**名前は開発中のものです。** · 2007/09/27(木) 23:31:57

煽っても必死さが正当化されるわけじゃないよ

**名前は開発中のものです。** · 2007/09/27(木) 23:38:28

BohemGCｻｲｺｰ

**名前は開発中のものです。** · 2007/09/27(木) 23:47:44

「必死さが正当化される」ってのはよく分からないけど・・・
とりあえず、「必死だな」とか言う前に>>620を論破してみれば？
例えば、
１，BohemGCだけにある、もしくはJavaやC#のGCでは解決された重要な問題を列挙する
　　（数値とアドレス値が識別できないという問題はあるけど、確率的にそれが不都合になることはほとんどない）
２，吉里吉里にはBohemGCが向いていないことを示す他のソースを提示する
とかね。

個人的に１はとても興味があるので、問題があるなら教えて欲しかったりする。

**名前は開発中のものです。** · 2007/09/27(木) 23:48:30

>>620
本題からそれるけど、
> スクリプト言語の作成は、スマートポインタだけだとしんどいと思う。
> var a = [0];
> a[0] = a;
> これだけでメモリリーク起きるなんて、危なくて使えん。
スクリプト言語におけるインスタンスの寿命管理と、C++ インスタンスの寿命管理は
別の話だよね。

俺は VM のスタックは C++ のスタックを使わず、C++ で std::vector<> 使って確保した
記憶域を使ってる。でないとスクリプト一時中断する (co-routine 実装) のが難しい
からさ。

当然スタック上にあるスクリプト言語のインスタンスは全部 VM でトラッキングできる
ので、ガベコレできる。C++ 側のメモリ管理が GC 使ってるかどうかとは無関係に。

**名前は開発中のものです。** · 2007/09/28(金) 00:02:16

>>634
ようするに実装がスタックレスってことだな。
つかスタックレスでないVMにコルーチンを実装するのは不可能じゃないか？

**名前は開発中のものです。** · 2007/09/28(金) 00:23:32

>>635
多少制約がつくけど、Cスタックを保存・切り替えできればスタックフル VM でも
コルーチンは実装できます。

ただ、どうやってもポータブルなコードにはならないし、C++ 例外の実装方法に
よっては問題出るから、お勧めしないけど。

**名前は開発中のものです。** · 2007/09/28(金) 01:10:11

>>636
スタック切り替えてまでやるかｗ
猛烈に処理系依存なコードになりそうだな

**名前は開発中のものです。** · 2007/11/17(土) 17:10:37

戦闘シーンの進行管理をするクラスって、どういう名前にしたらいいんだろう？
BattleManagerかな…でもManagerは使うなって話もあるし。

**名前は開発中のものです。** · 2007/11/17(土) 17:27:39

>>638
Manager 使うなって話は、つまり「管理」というあいまいな言葉を使うなって話。
「戦闘シーンの進行管理をするクラス」の役割を見直さずに名前付けだけ考えてても
無意味。

**名前は開発中のものです。** · 2007/11/17(土) 17:45:31

>>639
レスありがとう

そう、今プログラム素人の子と話してたんだけど、
漠然と「場」みたいなもので考えるから名づけに迷うんであって、
相撲の行司みたいなのがいると仮定して、
そいつに戦闘の進行管理をさせればいいんじゃない？
という意見をもらった。

そこでまた、「戦闘の進行」っていう、時間を伴ったものを、
その「行司」の中に持たせちゃっていいのかなと迷うんだけど、
その辺りは割り切っちゃったほうがいいの？

OOPド素人丸出しでごめん

**名前は開発中のものです。** · 2007/11/17(土) 17:53:06

戦闘シーン関連の処理に関して、俺が抱いてるイメージとしての「管理」から考えると
そのManagerが関連する他のクラスに処理を分配して、それを仲介するようなクラスだとMediatorあたりになるんじゃなかろうか
俺が作ってた「Manager」は上記のものがさらにFacadeの役割も果たすってのが多かった
デザパタから借りてるだけで正解とはとても言えんけど、「Manager」よりはマシかな…と

**名前は開発中のものです。** · 2007/11/17(土) 18:09:05

>>640
> そいつに戦闘の進行管理をさせればいいんじゃない？

それじゃ何も解決しないでしょ。「管理」という役割が同じなままなんだから。

「管理って、実際のところ何するの？」と問い、「あれして、これする」っていう
もっと具体的な単位に分解できれば、「あれするクラス」「これするクラス」に分割する
ことが考えられる。それらを組み合わせたものを「戦闘シーン」というクラスにすることも
考えられる。

どうしても「管理」としか呼べないんなら、それを Manager と名付けること自体には
何の問題も無い。

「戦闘の進行」と「行司」という切り分けができるなら、前者を Advance() なんていう
関数、後者を Rule とかいうクラスにすることが考えられる。 Advance() は Rule に
従って処理をする、って感じね。具体的な状況がわからないんで、全然ダメかも
しれないけど。

**名前は開発中のものです。** · 2007/11/17(土) 18:34:11

SceneManagerとか定番だな

**名前は開発中のものです。** · 2007/11/17(土) 18:35:34

javaの立場が・・・

**名前は開発中のものです。** · 2007/11/17(土) 20:30:54

class Referee
{
public:
　　Referee(const class Rule& current_rule);

　　const bool judge(const class Battle& current_battle);
　　void bribe(const int price);

　　inline void win(void) { http://youtube.com/watch?v=ubhW9R-F7cM }
};

**名前は開発中のものです。** · 2007/11/17(土) 21:45:56

>>644
？

**名前は開発中のものです。** · 2007/11/18(日) 06:00:26

使うなとは誰もいってないよ

**名前は開発中のものです。** · 2007/11/18(日) 07:27:13

>>642
俺の場合、Manager って名前は使っちゃうな。ただし Manager クラスで
何でもかんでも処理せずに、分割できるところは別のクラスに切り出して
Manager クラスに集約する。

Facade やね。

**名前は開発中のものです。** · 2007/11/20(火) 01:41:42

さっきからしょぼいＢＧＭのループがひどいな
２ループもすりゃ十分だろ

**名前は開発中のものです。** · 2007/11/20(火) 02:00:34

>>649
何に対して言ってるのか

**名前は開発中のものです。** · 2007/11/20(火) 06:51:02

B・・・・・GM・・？

**名前は開発中のものです。** · 2007/11/24(土) 17:27:35

シューティング作ってて、敵のクラスと自機のクラスを分けちゃったけど、わけない方がスマートだったかなあ

**名前は開発中のものです。** · 2007/11/24(土) 17:36:40

>>652
一部同じインターフェースを持つことはあるだろうけど、普通に考えてまったく同じクラスに
なるとは思えない。

**名前は開発中のものです。** · 2007/11/24(土) 19:10:43

自分は敵１と敵２とかでもわけてる

**名前は開発中のものです。** · 2007/11/24(土) 21:09:45

>>654
そりゃ、作るゲームにもよるな。キャラクター数少なくて差異が大きい場合には
クラス分けるが、RPG のように数が多いと基本1クラスでデータ駆動にする。

**名前は開発中のものです。** · 2007/11/24(土) 22:25:37

>>652
何シューティングか知らないが、
よくある２Dのシューティングなら自機と敵機で違う処理したほうが、
当たり判定の最適化しやすそうだな。
（同じ基底クラスから派生させるとかいう話はおいといて、

**名前は開発中のものです。** · 2007/12/23(日) 16:09:31

シューティングでも、データ駆動（簡易スクリプトもしくは、相当するもの）
がお勧め。

俺は、クラス志向でやってたら、敵、弾のクラスが200超えたあたりで、死んだ

**名前は開発中のものです。** · 2007/12/23(日) 17:43:24

もっと詳しく。
数の多さからの管理の複雑化という問題だとしたら、
データでもクラスでも一緒だと思うんだが。

**名前は開発中のものです。** · 2007/12/23(日) 17:48:27

、>>657は敵の動きや弾の速度やダメージなんかを全部
コード中に書いてたんじゃね

**名前は開発中のものです。** · 2007/12/23(日) 18:00:13

DIO「所詮OOPはゲームプログラミングの亜流！データドリブンに敗北する定めよおおおぉっ！！」

**名前は開発中のものです。** · 2007/12/23(日) 18:27:09

実際に完成したゲームのデータj構造・クラス設計が王道。

**名前は開発中のものです。** · 2007/12/23(日) 20:45:04

ＲＰＧゲームのクラスを作ろうとしているのですが・・・
http://www.kent-web.com/pubc/book/test/uploader/uploader.cgi?mode=downld&no=530
キャラクタークラスや技エフェクトクラスにも画像データを持たせたいのですが、描画処理クラスの下に
キャラクタークラスを置くべきでしょうか？それとも多重継承で描画処理クラスのデータを継承させたほうが良いでしょうか？
描画処理クラスでは画像のデータや実際に描画する関数など描画データを統合して持っています。

他にもこうした方がいいというところがあればお教え下さい。
よろしくお願いしますm(_ _)m

**名前は開発中のものです。** · 2007/12/23(日) 21:13:08

２Ｄゲームだと仮定すると
キャラクタークラスがコピーする画像の種類、座標と大きさをパラメで持ってればいい
変数５個ぐらいだからあとはそれを描画クラスに渡して描画されるしくみがあればおｋ

エフェクト関係の位置が微妙に変だと思う
あれは継承？それとも集約（コンポジション）？

あと図の矢印が継承と集約混ざっててわかりにくす
あれが全部継承なら最初から作り直し

**名前は開発中のものです。** · 2007/12/23(日) 21:20:38

>>659
そのとおり
で、途中からやばいことに気づいて（そら100もクラス作ってたら、気づくわｗ）
スクリプトで外に出したりしてたら、
かなーりカオスに・・・

**名前は開発中のものです。** · 2007/12/23(日) 21:22:59

>>662
矢印の関係、向きがグチャグチャだなおいｗ
UML関連の入門記事をさらっと読んだ方が、いいよ

本まで買って厳密にやることはないが

**名前は開発中のものです。** · 2007/12/23(日) 21:35:43

>>659
それのどこがやばいのかよく分からないなぁ。

>>664
本当に必要なものならクラス数は増えても良い気がするけど。

**名前は開発中のものです。** · 2007/12/23(日) 21:38:17

.NETだったらコンパイルも早いし、dllに分けてスクリプト言語で書いたりもできるから
派生クラスで全部書いちゃってもいけそうだな

**名前は開発中のものです。** · 2007/12/23(日) 21:39:00

>>664
ふつーは、プレイヤー弾クラス、敵弾クラスとか作って、そいつがパラメタを
ファイルから読み込む or スクリプト駆動にするわな。パラメタ変更では手に
負えないような差異がある場合（バラバラの弾とレーザーとか）は、そこを
クラスに切り出す。

どこまでプログラムで書いて、どこからスクリプト or データ駆動にするかは
センスの問題。何でもかんでもスクリプトで書くと、結局 C++ で書くより手間
かかるだけだしなｗ

**名前は開発中のものです。** · 2007/12/23(日) 21:41:05

>>663
描画処理にキャラクターのデータを渡すだけでいいのですね。
図は全て継承の意で矢印を書いてしまいました。
継承と集約の相違点と関係を見直してもう一度はじめから考え直してみます。
>>665
確かに書き方が全く成っていませんね・・
ネットでＵＭＬを説明してる所へ行ってみます！

ご指摘ありがとうございました。
大変ためになりました＞＜

**名前は開発中のものです。** · 2007/12/23(日) 21:42:05

このキーワードを出すと荒れそうだけど、やっぱりデザインパターンは
一通りかじった方が良いと思うよ。そうしたら、何が悪いか見えてくる。

あと、基本的に継承しまくるのは良くない。継承よりも委譲で処理した方が
スッキリする場面が多い。

**名前は開発中のものです。** · 2007/12/23(日) 21:44:24

>>662
まずゲーム上の意味を持たず、単純に描画関連の処理だけ行うクラスを作る。
3Dモデル、2Dスプライトとかな。

その上で、次に、3Dならモデルのモーション制御用のクラスと、2Dスプライトなら
テクスチャアニメーションや拡大縮小アニメーションなどを行うクラスを用意する。

最後に、ゲーム的に意味があるクラス（技エフェクトクラスとか）は、上記クラスの
インスタンスをメンバ変数に持たせて使う。間違っても継承するなよ。