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

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

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

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

**名前は開発中のものです。** · 2007/03/28(水) 07:59:56

無限多倍長精度整数って書いてるんだよな。
long longより上だと3倍長で7.9x10の28乗とかになるけど……要るか？

**名前は開発中のものです。** · 2007/03/28(水) 11:11:39

>>249
んなーこたーない。
経営シミュレーションで多倍長な変数を使うことはあるよ。
キャッシュとか資産とかの額で。
まさか、浮動小数点使うわけにはいかんし。

**名前は開発中のものです。** · 2007/03/28(水) 12:08:50

ビルゲイツの資産とか32bitに収まりきらんもんな

**名前は開発中のものです。** · 2007/03/28(水) 12:54:06

そもそもビルゲイツの資産は、株価がちょっと変わるだけで
とんでもない額が変動するから、下の方の桁にあまり意味はない。

**名前は開発中のものです。** · 2007/03/28(水) 15:10:12

32bitどころじゃないだろ。

まあ、毎年訳分からん団体に１兆寄付してるおっさんだからな。

寄付してるのは妻の方だけ？

**名前は開発中のものです。** · 2007/03/28(水) 16:57:57

自分の設立した財団じゃないのあれ？

**名前は開発中のものです。** · 2007/03/30(金) 00:16:52

Delphiの日付用構造体TDateTimeを馬鹿にするなよ？
日付なのに、不動小数

**名前は開発中のものです。** · 2007/03/30(金) 01:10:16

不動ならいいや('ー`)

**名前は開発中のものです。** · 2007/03/30(金) 03:52:48

MSのAccessも日付はdoubleでもってたような・・・

**名前は開発中のものです。** · 2007/04/01(日) 02:13:01

いいシーン管理方法が思いつかない…。
「シーンはスタックに積む」って話をよく聞くけど、
積みっぱなしでメモリは大丈夫なのかとか、
タイトルシーンやメニューシーンはその都度生成した方が
再初期化の手間いらずで楽なんじゃないかとか、
ロードの際にスタックの中身をいちいち
再現しなきゃいけないんじゃないかとか、色々疑問が残る。

**名前は開発中のものです。** · 2007/04/01(日) 13:27:10

>>260
何が「いい」かは作るプログラムによって違うからな。
疑問に思うんならやってみろとしか言えない。

**名前は開発中のものです。** · 2007/04/01(日) 14:21:19

なるほどそういうときにシリアライズを使うのか

**名前は開発中のものです。** · 2007/04/01(日) 15:15:13

>>260
Gemsの５巻にスタックを使ったシーン管理が載っている。

試してみたら、なかなか使い易かったよ。

**名前は開発中のものです。** · 2007/04/01(日) 15:35:35

>>262
javaのシリアライズの話ならそういう時の為のものじゃないぞ

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

>>260
作ってるゲームによるでしょ。

シーン切り替えの度にブラックアウト & ロード処理が入るふつーの RPG だと、
シーンは必要な都度 new して作る（ただしテクスチャ・モデル等のリソース類は
事前に割り当て決めておく）、状態遷移はプログラム側でベタに行う…で十分に
管理できる程度だった。

**名前は開発中のものです。** · 2007/04/05(木) 20:02:57

>>263
Gemsうｐ！！
って、無理だｗ

ソースコードだけでも配ってないのか・・・

**名前は開発中のものです。** · 2007/04/06(金) 02:24:49

【警告】
日本はカルト教団に支配されてしまいます。
選挙に行きましょう。

**名前は開発中のものです。** · 2007/04/06(金) 16:07:18

スタックベースのシーン管理に参考になるページはないですか？

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

どっかのやねうの昔のサイトに解説がなかったか。

**名前は開発中のものです。** · 2007/04/07(土) 12:47:03

YaneSDK.Netのソース読め

**名前は開発中のものです。** · 2007/04/08(日) 01:31:41

本人がいらっしゃるようなので一言申し上げますが
yaneSDK3rdの更新してください＞＜
2ndからトランジエントビルトを移植しようとしたんですが正直無理です＞＜

**名前は開発中のものです。** · 2007/04/08(日) 01:42:46

無理とか言ってたらなんも成長しないがな。
つか本人が来たとか本気で思ってるのか。

**名前は開発中のものです。** · 2007/04/08(日) 02:50:06

皮肉にマジレスしてどーする

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

そういや、やねうらおの会社の社員が、やねうらおを訴えた件はどうなったんだろうな。

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

騙された馬鹿が、ギャーギャー文句言ってただけ

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

いい加減スレ違い。

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

スタックベースのシーン管理について質問

つくってみたけど、いまいち利点がわからん・・・
何が便利なんだろう・・・

**名前は開発中のものです。** · 2007/04/09(月) 15:13:20

スタックみたいな古臭いのじゃなくて
デザインパターンでオブジェクト指向的にスッキリと出来ないものなんだろうか

**名前は開発中のものです。** · 2007/04/09(月) 16:14:10

シーンをオブジェクトと見なしてスタックに積むんだから、
十分オブジェクト指向じゃないかと思うんだけど、そういうことではない？

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

>>277
利点かー。
末端のシーンがどこに戻るか把握しなくていいから、シーンを柔軟に組めるとか、シーンを再利用しやすいとか。
ごめん、思いつきで書いた。

**名前は開発中のものです。** · 2007/04/09(月) 20:46:27

>>279
うん。
それ自体が定型になるなら、スタックベースのシーン管理というのも
ゲームにおけるデザインパターンといっても過言ではないと思う。

**277** · 2007/04/09(月) 20:49:46

とりあえず、googleして、定番とおもわれる

・呼び出し（Call)
・移動(GoTo)
・呼び出し側に戻る（Return)

をシーン管理オブジェクトに、実装して、シーンを状態遷移してみたりしたんだけど、

これって、シーンを遷移するときって、前のシーンは開放しちゃっていいのか？
開放しちゃうと、
しなかったらしなかったで、リソース圧迫するし

クソー、Game Programing Gems 5がほしいZE

**277** · 2007/04/09(月) 20:54:13

> 開放しちゃうと、
開放しちゃうと、呼び出し(Call)の意味あんのかな？と思うし

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

ところでシーン間の関係はだれが持つの？

シーンクラス？シーン管理クラスとか他のクラス？

分岐のあるゲームだとこれ重要。
次に進めるべきシーンを決める奴が持てばいいのか・・・？

シーン遷移管理とシーン関係管理＋フラグ管理に分けるとか？

>シーンを遷移するときって、前のシーンは開放しちゃっていいのか？

javaだとこれ厄介なんだよね。何しようが使ってなかったら勝手に拾われるから。
一応クリーンアップなりシャットダウンなり処理して放置かな。

こういうときにファイナライザ使うもんじゃないしね。

**名前は開発中のものです。** · 2007/04/10(火) 00:13:19

>>277
シーンは最初に全部確保して
最後に全部解放してるよ。

シーンスタックそのものが「アクティブなシーン」のスタックであって、
今アクティブじゃないシーンは別のリストに保管してる。
でスタックに積まれてるものは一通り処理する。

こうすることで移動画面中にメニューも表示して移動もメニュー選択も可とか
裏画面でデモ（通常ゲーム処理）回しながら上にウィンドウ表示とか
出来ますよ　って趣旨だったと思う >Gems5

ただ、ウィンドウ関係以外には特に利点は無さそう。

**名前は開発中のものです。** · 2007/04/10(火) 01:08:35

マルチスレッドを実現する手段の一種ということ？

**名前は開発中のものです。** · 2007/04/10(火) 01:12:58

>>285
＞でスタックに積まれてるものは一通り処理する。
これ、厳密にはスタックって呼べなくね？
LIFO≠スタック

**名前は開発中のものです。** · 2007/04/10(火) 01:16:37

なんだ、シーンの遷移がスタック的なのかと思ってた。

**285** · 2007/04/10(火) 01:26:00

>>287
上にシーンを積んだときにサスペンド処理（シーンクラスのメソッド）を呼ぶようにして
サスペンド中も実行したいシーンはその処理でサスペンド時も実行してねフラグを立てる
とかそんな処理になっていたと思うから　一応一番上に積まれているのが
現在のシーンってことになる。
立ち読みだから細かいことは忘れたｗ

スタック全体をなめるんだからスタックとは言わないと俺も思う。

**277** · 2007/04/10(火) 01:59:26

わかった。
かなり勘違いしていた・・・。

>>288
俺もそう思ってたｗｗ

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

これ読んで、久々にパックマン作りたくなったな～。
アクションゲームは、作ってないけど、デザインパターンを、正しく使うと、プログラムがスッキリするし、大好き。
デザインパターンって、しらない人多いのかな？

**名前は開発中のものです。** · 2007/04/10(火) 09:47:11

Large-Scale Stack-Based State Machines
James Boer
Game Programming Gems 5, 2005.

**名前は開発中のものです。** · 2007/04/11(水) 01:26:38

>>291
> デザインパターンって、しらない人多いのかな？
んなわきゃない

**名前は開発中のものです。** · 2007/04/11(水) 05:40:08

スタックベースのシーン管理、結局、状態遷移をスタックベースに作ってしまったｗ

これで、

　タイトル画面→(呼び出し)→ゲーム処理→(戻る)→タイトル画面

とか、
　タイトル画面→(呼び出し)→リプレイのメニュー→(呼び出し)→ゲーム処理→(戻る)→
　リプレイメニュー→(戻る)→タイトル画面
とかできるようになったｗ

スタックベースといったらやっぱりこっちだろｗ

**名前は開発中のものです。** · 2007/04/11(水) 05:56:16

スタック的に自然な状態遷移しかしないのであれば役に立つだろうけど、
そうではない大部分のゲームにとっては役立たず以外の何物でもないと思う。

**名前は開発中のものです。** · 2007/04/11(水) 07:47:20

スタックというデータ構造を状態遷移を表現するために利用するからには
・次のシーンに移る＝push操作
・1つ前のシーンに戻る＝pop操作
という対応関係が常に成り立っていて、この操作のみで完結すべきなんだが、
これだけの操作でOKなゲームがどれだけあるかっていうと、ぶっちゃけほとんどない。
スタックにこだわるあまり、データ構造を破壊したり
オブジェクトの役割を破壊したりするような例が後を絶たないのだが、
>>279と>>281のようなやり取りが行われている現状では仕方がないか。

**名前は開発中のものです。** · 2007/04/12(木) 03:38:40

実質が状態遷移ならstateパターンでいいやんって事ですか？

**名前は開発中のものです。** · 2007/04/12(木) 04:43:05

>>297
Stateパターンとか全く関係ないよ。
シーンの遷移をうまく表現するためのデータ構造に関する話。

どこまで理解しているかわからないから基礎から説明する。
Stackというデータ構造は、
・オブジェクトを1つStackに積むpush操作
・最後にStackに入れたオブジェクトを1つ取り出して捨てるpop操作
・最後にStackに入れたオブジェクトを参照するtop操作
を持つ。ここで、
・push操作＝次のシーンに移る
・pop操作＝1つ前のシーンに戻る
・top操作＝現在のシーンを取得する
と対応付けると、これはシーン管理に使えそうだぞってことになる。
これが、今話題に上がっているStackベースのシーン管理。

これをStateパターンにしたところで、Stackの中に入るオブジェクトが
シーンオブジェクトから状態オブジェクトに変わるだけで、
シーン遷移のための操作やベースとなるデータ構造は変化しないってのはわかる？

**名前は開発中のものです。** · 2007/04/12(木) 05:16:23

(続き)
で、何故Stackベースのシーン管理に関して
>>295と>>296(俺)のような批判が出るかって言うと、
>>298で挙げた3つの操作だけでうまく管理できるような
状態遷移になっているゲームが少ないから。

例えば、Stackの状態が
タイトル <- メニュー <- ゲーム処理 <-
だとして、ゲームオーバーシーンに移りたいとする。そうするとpush操作で
タイトル <- メニュー <- ゲーム処理 <- ゲームオーバー <-
となるが、次にタイトルシーンに移りたくなったときに、
これに対応する操作がない。あくまで与えられている操作は、
次のシーンに移るか、1つ前のシーンに戻るかだけだから。

"ゲームオーバーシーンから戻るときだけは
topがタイトルシーンになるまでpopする"というような特例を
不都合が生じる度に設けると、Stackベースにした意味がなくなる。
これが>>296で言った『データ構造の破壊』に相当する。

"Chain of Responsibilityパターンを使ってシーンオブジェクト間で
データをリレーしていけば実現できるよ"って意見をどこかで
見たことがあるのだが、そもそもシーンオブジェクトには
状態遷移を正しく行う責任はないので、オブジェクトの動作的に不自然。
これが>>296で言った『オブジェクトの役割の破壊』に相当する。

ここまで神経使うかよって思うのが普通だとは思うけど、
せっかくのデータ構造スレなので色々グダグダと言ってみた。
よさげなデータ構造があれば是非ともそれを利用したいし。

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

Stackのシーン管理を、必要なところだけ使うようにすればいいんじゃないの。
セーブ画面とか、オプション画面とか。

**名前は開発中のものです。** · 2007/04/12(木) 11:44:45

>>185-
ちょっと参考になるよ

**名前は開発中のものです。** · 2007/04/12(木) 18:19:58

色々考えて、俺はスタック的な遷移も結構いいんじゃないかと思えてきた。

スタックだと、シーンの遷移の責任は全て親に任せることができる。
キャンペーンモードなのか、単独のマップを遊ぶだけのモードなのかは、自分は
知る必要もなく、遷移する理由（勝利、敗北、キャンセル…etc）だけを伝えれば
次にどのシーンになるかは親が決めてくれる。

各シーンが自分で次のシーンを選んでダイレクトに遷移していくよりは、
親に一任した方がすっきりするね。

スタックそのものでなくても、スタック的な遷移ができることは便利だと思う。

**名前は開発中のものです。** · 2007/04/12(木) 20:03:01

うむ、完全にpush/popに収める必要はないよな。

**名前は開発中のものです。** · 2007/04/12(木) 20:15:13

素直に多方向リンクリストでやれよ。

**名前は開発中のものです。** · 2007/04/12(木) 20:25:07

それは実装・データ構造の話じゃん。

**名前は開発中のものです。** · 2007/04/12(木) 21:46:48

>>302
遷移する理由を伝えることによるシーン遷移ってのはいいね。
が、これは別にスタックに限った恩恵ではない
(っていうのは>>302もわかってると思うけど)。
>>304の言う多方向リストでも可能(っていうか本来はこっち)だし、
イテレータが指すシーンを現在のシーンとする双方向リストでも可能。

多方向リストで工夫して実装すれば、
リソースを食うシーンに移ったときに
前のシーンをいくつか解放するといった処理が行えるし、
シーンを激しく前後するような操作をしても
オーバーヘッドがかからないのでいいかも。
もっとも、ゲーム起動時にリソースを全部先読みしても
全く問題ないようなゲームだったら、
積みっぱなしのスタックで全く問題ないし、
これが一番簡単だと思うけど。

**名前は開発中のものです。** · 2007/04/12(木) 22:34:50

"多方向リンクリスト"に該当するページが見つかりませんでした。

**名前は開発中のものです。** · 2007/04/13(金) 01:17:14

双方向リンクリストじゃない？

**名前は開発中のものです。** · 2007/04/13(金) 01:37:40

色んな方向につながってるってことは…
vectorじゃねぇの？

**名前は開発中のものです。** · 2007/04/13(金) 02:13:59

遷移元シーン番号と遷移事由コードで
テーブルから遷移先シーン番号（またはシーンオブジェクトの参照）を
引くだけというのはだめだろうか

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

ヒント：C言語などの関数

**名前は開発中のものです。** · 2007/04/13(金) 04:47:41

>>311
エレガントじゃない気がする

**名前は開発中のものです。** · 2007/04/14(土) 05:39:36

状態の保存方法なんて画面にあわせて stack なり queue なり
vector なり list なり、適当に作ったツリー構造なりを使えばいいよ。

コンテナ実装するのも一苦労だったアセンブラやCで組む時代じゃないんだから、
全体でどれに統一するか悩む必要なんて無いでしょ。

**名前は開発中のものです。** · 2007/04/15(日) 10:34:45

ログ

**名前は開発中のものです。** · 2007/04/15(日) 14:31:59

参照カウント付きスマートベクトルポインタ使ってシーンの遅延生成や破壊を自動管理したり
夢が広がりまくりんぐ

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

シーン間の遷移（例えばクロスフェード）とかどうやってる？

**名前は開発中のものです。** · 2007/04/19(木) 13:42:33

俺はシーン別に切り分けてバッファを持っている。

**名前は開発中のものです。** · 2007/04/19(木) 22:50:53

自分は、Viewで処理してて、Modelでのシーン自体は完全に移行済みにしとく。

あくまで、表示（演出）は表示（演出）ときりわけやったほうがいいと思うし、
また、切り分けとくと変更も楽だし、テスト時とか演出要らん場合はさっさと飛ばせるし。

**名前は開発中のものです。** · 2007/04/20(金) 18:21:55

やべ。意味が分からん^^
ちょっと確認させて欲しい。

class IScene {
　 virtual void update(ISceneContext& ctx);
　 virtual void draw(ISceneContext& ctx);
};
class SceneStack {
　 void push(IScene *scene);
　 void pop();
　 void call(IScene *scene);
　 void update(ISceneContext& ctx) { /*登録されたシーンの更新*/ }
　 void draw(ISceneContext& ctx) { /*登録されたシーンの描画*/ }
};

自分の理解では、こんなのがシーン処理の実装なんだけど、
まずこの解釈はあってる？
当然、シーン変更時はscenestack.call(new_scene)とかやるわけね。

>>317
シーン別にバッファを持ってるってことは、
シーン遷移時の処理はSceneクラスで遷移を行うか、
他の遷移専用クラスがあるってことですか？

>>318
↑の例でいうと、ISceneまたはSceneStackのdraw内のみで
遷移処理を実行するということですか？

全然分かってないかもです。
理解が足りなくて申し訳ない。

**316** · 2007/04/20(金) 18:22:39

>>319も316です^^

**名前は開発中のものです。** · 2007/04/20(金) 23:58:50

やねうら臭がする

**名前は開発中のものです。** · 2007/04/21(土) 04:53:19

>>319
俺もおおよそそんな感じ

**名前は開発中のものです。** · 2007/04/21(土) 09:13:46

沖縄県の方へ（命に関わる注意事項です）

沖縄県での選挙ですが、どうか民主党だけは避けてください。県民の生命に関わる可能性があります。
民主党の最大の公約は一国二制度（※）ですが、一度「一国二制度　沖縄　三千万」等で検索をお願いします。
この際、民主党のＨＰで調べても良いです。以下の注釈↓と矛盾することは書いてないはずですから…

※一国二制度
　簡単に言えば沖縄を中国と日本の共有物にし、そこに3000万人の中国人を入植させます。
　（つまり沖縄人口の 96% を中国人にして、実質、沖縄を中国人の居住地とします。）
　さらに「自主」の名の下、沖縄で有事が起きても自衛隊は干渉できません。
　3000万人の中国人が、少数派となった130万人の日本人に何をしても、です。
　そして反日教育を受けた中国人の反日感情の強さは、ほとんどの日本人の理解を超えるものです。

今回の選挙で民主党が勝った場合、「自主」「発展」を連呼しつつ段階的に進めていくことになります。
自主と言っても、自主を認めるのが「住人の96%が中国人となった」後だということに気をつけてください。
発展と言っても、新沖縄の少数派となった「少数民族日本人」の発展ではないことに気をつけてください。

**317** · 2007/04/23(月) 17:44:03

>>318とほぼ同じと思うけど
シーンに関してスタックは使ってないので、並列処理しているとき
それぞれのシーンが自分用の裏画面などを持ってないと都合が悪い

表示（演出）は別クラスにして任意シーンの裏画面を複数使って料理する
ぶっちゃけ、カメラを切り替えている感じ

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

>>324
なーる。表示用クラスが裏画面(テクスチャだよね？)
を複数使って演出してるわけね。
ありがとう^^

**名前は開発中のものです。** · 2007/04/30(月) 13:33:52

RPGでマップとかイベントはゲームスタート時に全部ファイルから読み込んでメモリに置いておくほうが普通でしょうか？
それともマップに入ったときにファイルからロードするほうがいいでしょうか？

**名前は開発中のものです。** · 2007/04/30(月) 13:38:16

普通なら、使いもしないデータを主記憶に展開しておくのは無駄としか思えないが・・・

**名前は開発中のものです。** · 2007/04/30(月) 14:13:55

環境とか開発の容易性とかいろいろ考えた上で全部入れるのはべつにかまわん
重いのは画像や音声だったりするわけでそれがないので別に大丈夫かと

規模によっちゃそれすらもまるごといれてもかまわんけどな
1MBもあればFF4がまるごとはいるわけで

**名前は開発中のものです。** · 2007/04/30(月) 14:36:40

動的に読み込むってなかなか難しくて・・・
FF4で1MBなら自分の程度なら全部読み込んでも大丈夫かも。

**名前は開発中のものです。** · 2007/04/30(月) 16:15:04

シームレスは少し難易度高いが、区画ごとに区切っていいなら難しくないんじゃ？
あっちこっちでグローバル変数使うような原人は知らん。

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

最初は難しいことに手を出すよりも、楽なほうでやったほうがいいよ。
後からだんだん発展させていけばいいと思う。
ぐちゃぐちゃになったらリファクタリングで。

**名前は開発中のものです。** · 2007/05/01(火) 07:32:01

クラスが多くなってぐちゃぐちゃになってきたorz
RPGって結構複雑ですぐ混乱してくる。
そろそろUMLとか勉強しないときついなと思ってきた。

**名前は開発中のものです。** · 2007/05/01(火) 10:50:48

UMLは構成を抽象化して理解するためのものであって
おぬしの想像しているものとは用途が違うぞ

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

システムの規模が肥大して、クラスを整理するのが大変になってきたら
UMLなり何なり書いて一からやり直してもいいんじゃねぇの

**名前は開発中のものです。** · 2007/05/01(火) 11:14:53

リファクタリングとデザインパターンおぼえておけばおけ
アクセサとしてpublicなメソッド用意してるだけだとあとでみなおすとききついから
フレームワークつくればよろしい

**名前は開発中のものです。** · 2007/05/01(火) 14:19:12

有名そうなライブラリをぱくるとかで

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

UMLからソースのスケルトンを自動生成する奴とか使って手抜きしたい
一応ヘッダから関数の定義のスケルトンや、標準関数やライブラリの関数のusing宣言を
自動化する程度のツールは自作して使ってるけど

**名前は開発中のものです。** · 2007/05/02(水) 23:15:54

今までいきなりコーディング始めてたんだけど大規模なゲーム作り始めて設計の重要性を痛感したorz
ただUML書いててもちっとも楽しくない。

**名前は開発中のものです。** · 2007/05/02(水) 23:53:12

>>338
おやこんな所に俺がいるじゃないか

早く新人研修のJava教本を読む作業に戻るんだ・・・

**名前は開発中のものです。** · 2007/05/03(木) 03:33:21

俺はUML書いてるだけで楽しいけどなあ

**名前は開発中のものです。** · 2007/05/03(木) 04:46:21

同意
コードに落とす方がかったるい

**名前は開発中のものです。** · 2007/05/03(木) 07:22:23

すげー、良く分かるｗ
コード打ってる時も、デバックしてる時はめんどい加減で止めたくなる。

**名前は開発中のものです。** · 2007/05/03(木) 10:26:46

俺は未だに、コーディングするときは脳内麻薬出まくり。

分かりきった定型的なコードを書いてるときは退屈で死にそうだけど。

**名前は開発中のものです。** · 2007/05/03(木) 17:19:41

人それぞれだなー
自分はキーボードかたかた叩いてちょっとずつ作っていく瞬間が楽しい

でも設計できないと先がなさそうorz
がんばってUML勉強しよう。

**名前は開発中のものです。** · 2007/05/03(木) 17:36:22

>>344
UMLはそういうものじゃないぞ。基本的にあれは知らなくても十分だし。
（あくまでも、設計の書き方・設計のための言語みたいなもん。
　個人か固定少人数でやるなら、適当でもなんとかなるし。）

設計を　と思ってるなら、普通にオブジェクト指向系の本がいい。
自分が買って読んだ本で、お勧めは
　憂鬱なプログラマのためのオブジェクト指向開発講座―C++による実践的ソフトウェア構築入門
まぁ、あと定番ながら
　オブジェクト指向プログラミング入門
　デザインパターンとともに学ぶオブジェクト指向のこころ
立ち読みで数ページしかみてないけど、入門の方はC++ 以外の言語（Object-C、Java、Delphi?）まで含めた本。

どれもこれも、値段も高いし・ページ数もやたらとあるしで
趣味でゲームを作るだけならちょっとオーバーワークっぽくも思えるけど、
Programmerとしての教養に読んでみては？

**名前は開発中のものです。** · 2007/05/03(木) 18:20:36

憂鬱本は読んでみたけれど全くオススメできない。
ゲームプログラマなら、遅くともインベーダゲームを例とした説明のところで
頓珍漢なことを言っているのに気づくべき。

**名前は開発中のものです。** · 2007/05/03(木) 18:36:59

JAVAでもいいなら「オブジェクト脳のつくり方」がお勧めだぞ。
ＵＭＬの超簡単解説もあるし。
例題が業務システムなのがアレだが、
本質的な部分はC++も同じだから大丈夫かと。

**名前は開発中のものです。** · 2007/05/03(木) 19:06:09

アレコレ言ってもしょうがないんでとりあえずUMLに触れてみて
どうやってコレを使ったら自分の助けになるのか
自分なりに理解するのが大切だと思いますよ

**名前は開発中のものです。** · 2007/05/03(木) 21:21:39

>>344
書籍で理論や共通知識を学ぶのも良いけど、ある程度コーディングできるように
なったら、「ホンモノ」のコードを読んでみるのも良い勉強になるよ。

個人的には UNIX V6 のソースコード読んで勉強したクチなんだが、いまどきの
人に薦められるかというと、ちょっと違う気がする。今だと Java, C++ あたりで
良い教材無いかねぇ…

**名前は開発中のものです。** · 2007/05/03(木) 21:26:04

UMLといってもクラス図くらいしか描かねぇ

**名前は開発中のものです。** · 2007/05/03(木) 21:47:30

色んな図あるけど業務でやらない限りは
クラス図、アクティビティ図、シーケンス図あたりが限度かねぇ