ゲームのクラス分けの練習方法について

Question

ゲームを作ろうと思いクラス分けしていますがどうしてもどう分けて良いのか分からず進みません。
良い練習方法やおすすめの書籍など教えて頂けますでしょうか？

ベストアンサーについて

回答者様からの回答を頂きましたが、質問から1週間経つまでは引き続き回答を募集し
その後ベストアンサーを決めたいと思います。

Comments

[K_3578]

正直質問内容がアバウトすぎて有効な回答が集まりづらい気がします。
どういうゲームの種類なのか？現在どういうような分け方をしているのか？
質問者氏自身の理解度はどれほどのものなのか？パッと考えただけでこれぐらい出てくるので
もう少し詳しく追記した方が回答する側もし易くなると思います。

Answer 1

良い練習方法

「良い」かどうかは主観的な部分が大きいと思うので，何とも言えませんが…

どう分けて良いのか分からず進みません

立ち止まって考えていても埒が明かないということであれば，まずはわからんところは分けずに進めてみてはどうでしょう．
すなわち，とりあえず最小の個数（現状で「ここは分けておこう」と自身で思える分割数だけ）のクラスで書いてみる．
実際にそれで実装してみる中で，

• 「こういうクラスがあればいいな」と思ったら追加してみる
• 「このデカいのをここで２つなり３つに分けた方がいいな」と思ったら分けてみる

…と，やってみれば良いでしょう．

「練習」という位置づけで，まずは気楽にやってみてはどうでしょうか．
そこで得た｛知見，反省点，etc...｝を次の練習に活かす，という感じで．

Comments

[JetMikan]

回答ありがとうございます。
確かに実際準備などはせずコードを書き始めると何が必要なのか、分けるべき点も見えてくるのですが
クラス分けを図で書こうと思うと何故か頭が止まってしまうのです。

やり方が悪いのでしょうか？
1.ゲームのイメージ図を見て要素分けする
2.要素ごとに必要な情報、動作を書く ←ここで何故か頭が止まります
3.もう少しオブジェクト指向なクラスに分けられるが再確認する

[fana]

「クラス分け」って言うけど，そもそもどうして分けるのか？
そこにあえて切れ目を入れた 理由/意義 とは何なのか？

理由なく「なんとなく」で分けるわけじゃないので，分けた時点において

> 要素ごとに必要な情報、動作

というのは　ほぼほぼ定まっている　のではないでしょうか．

[fana]

クラスを書く（書こうと決めた）時点で，それが｛何のための物で，どう使うのか｝という想定は定まっている．
そのクラスを設ける動機があるハズだから．

[JetMikan]

クラス分けをしたい理由としては綺麗なコードを書きたいからですね。
過去に設計など考えずその場その場でゲーム制作をして大変な目に合っています。
仕様書もあるので本来その要素がどんな事をするモノなのかわかるはずなのです。
処理は同じでも書き方によってコードの見やすさは大きく変わりますし、その辺りを意識しすぎる余り全く進まないのかもしれませんね。
(ぱっと考えるとゲーム内の色々なUIを1つのクラスで管理するのか、それとも複数に分けるのか、さらに各クラスが持つ最低限の関係性はどんな感じなのか、本当にそれで良いのか？)

もう自分でも良く分からないです...

[fana]

あとこれは，すっごく個人的な考えなんだけども，
「オブジェクト指向」とかいう言葉に過度にこだわったり捉われたりしない方がいいと思うの．
まずはあなた自身が最も｛やりやすい，良いと思える，しっくりくる，…｝形で考えるべき．

[JetMikan]

そうですね...
確かに組む前に永遠に悩むよりは汚いコードでも先に完成させてその後に改善する方が良いですね。
長々とありがとうございました。
(ですが実際のゲーム業界でのオブジェクト指向はどのような位置にあるかは気になりますが...)

[fana]

ある機能に関する実装を作り直す際に，プログラム全体を捨てなくても良い＝ある範囲だけを書き換えるが，それより外の範囲は１byteも変更しなくてよい
…という形になるような「分け方」を考えてみては？

UIの実装が丸ごと変更になろうとも，UI部 と それ以外の部分（UIを操作された結果して動くゲームのロジックやゲームのデータの部分）との間でのやりとりの仕様さえ同一であれば，「それ以外」の部分は一切影響を受けない（単に，これまで同様のやりとりをしたら，UI部がこれまで同様の結果を生じてくれればそれでいい），という．

[fana]

…っていう感じで，
後から作り直したくなるかもしれない（実装方法に迷うような）部分　と　それ以外　との間には
特にきっちりとインタフェースを定めて線引きしておくとよいのではないでしょうか．

インタフェースについては，これでもかと言うくらいにルールを定めておき（注釈か何かで必要なことを必要なだけ定めた内容を明記しておく），かならずそれに従う形で具体実装を書きましょう．
そうすれば，そのルールを完全に守ったある具体実装を，同じくルールを完全に守った全く別の具体実装に置き換えても問題が生じない，っていう話ですね．

[JetMikan]

さらに具体的にありがとうございます。
一度ルールを決め、もう一度見直してみたいと思います。