プログラマ専用SNS ミクプラ

毎回お世話になっております。


今回は、おそらく「ゲームを作る前の段階」についてのしつもんです。


私は、ＤＸライブラリを使ったり、Ｃ＃で簡単なゲームを作りながら勉強をしています。


そこで、ここの掲示板でトピックを立てた際に、皆様の回答で「先に考えて設計しておいた方がいいですよ」的な回答が時々きます。

例えば、少し規模が大きいゲームを作るときに、ただ単に思いついたままその場その場でコードを書いていったらマズイというのはわかります。
そこで「設計」しろと言われるのもわかります。


そこでなのですが、設計とは具体的にどのような事をするのですか？
また、皆様はどのような事をしていますか？


今の段階で私が思いつくのは、Ｅｘｃｅｌか何かで、クラスの相関図を作成することくらいなのですが・・・・このようなことを「設計」というのでしょうか？

今までは、思いついたまま書いて、詰まればここで質問してというようなやり方でした、作るものも規模は大きくなく、基礎を学んでいましたし・・

お願いします。

わたしは実際に動いているところを想像して、その内容をメモしたり資料にまとめたりします。
ソースファイルに直接コメントとして書いていくこともあります。
あとはそのとおりに作ります。

例えばゲームのプレイ実況などはプログラマでなくてもできます。
現実にあるものを実況するか自分の頭の中だけにあるものを実況するかの違いです。
モチベーションの問題だけです。

ある程度の完成形をイメージできないと、設計はできません。
完成形をイメージできないまま設計してもけっきょく行き当たりばったりになります。


設計が上手くなるには経験が必要です。
過去の経験を無駄にしないことが重要だと思います。

ソフトウェアを作るにあたってプログラムにはいくつかの階層があります。
（以下の用語は私が普段使っているもので他の方とはニュアンスが違うかもしれないと断りを入れておきます）

・Lib
・AppSys
・App
・Document
の４つです。
・Libはハードウェアの機能を使いやすく、汎用的にしたものです。
ハードの機能をできる限りラッピングします。

・AppSysはこのLibを更にラッピングしてアプリケーション開発に特化した機能です。
Libの上位層になります。
ここをガッチリつくる必要があります。

・AppはAppSysの上位層にあたる部分で、わかりやすい例だとゲームのUI全般です。
Appの制御やマネージはAppSysがやります。


・Documentはゲームそのものにおける神様的ポジションです。
どこからでもデータの内容を見ることができ、どこからでもデータの書き換えができます。

シューティングゲームにおける獲得スコア数や残機数、保存されたスコアリストのデータ、
オプションで設定された設定内容などはDocument層です。


というのは1例で他にもさまざまな方法論があるとは思いますが、
私は普段こんな感じでアプリそのものに担当部分毎の階層構造を作ります。
ハードの機能はゲームを作っているときに意識したくない部分ですし、
フロー遷移の制御に細かい分岐処理を入れるとバグが出たときの対応が難しくなりますので、
そういうのはすべて根元となるDocument、AppSys層ががっちりハンドリングしてあげます。

アプリ層はデータ処理とシステムへの命令だけで済んでいる状態が理想的な作りだと思います。

まず「UML」を勉強すると良いと思います。
オブジェクト指向における設計書には必ずと言っていいほどUMLが出てきます。
UMLで最低限、クラス図、シーケンス図、アクティビティ図を書いておけばあらかじめある程度設計したと言ってよいでしょう。
UMLを書くツールはastahを勧めます。

例えば私は東方風シーティングを作る時はこんなクラス図を作っていました。

Dixq (管理人) さんが書きました:例えば私は東方風シーティングを作る時はこんなクラス図を作っていました。

シーティングって（笑）

大きな意味での設計と、細かい意味での設計があると思います。
Dixq (管理人)さんの書かれたクラス図、シーケンス図、アクティビティ図とかは大きなレベルでの設計です。
細かい部分は、戻り値や引数をどうするのかとか、データをクラスでどういう形で保持するのか等の細かいレベルの設計です。
大きなプログラムでも小さなプログラムでも両方が必要なんですが、行き当たりばったりを止めるために今日からできるだけ考えてみてください。

この間から質問されている、背景スクロールだけでも設計してみて、ここで質問されることをオススメします。
※　Dixq (管理人)さんの図はあまりみずに独自設計にチャレンジしてみては？

設計をうまくしたいということであれば、縦の関係か横の関係かを意識するようにしたら良いと思います。
アクセスするのは縦の関係にあるオブジェクトのみで、横の関係にあるオブジェクトにはアクセスしないのが良い設計です。
オブジェクトの関連図を書いたら、ピラミッド型になります。
すべてのオブジェクトがピラミッドに収まるわけではありませんが。

例えばマップ上にキャラがいて移動する場合、キャラが他のキャラや障害物の座標をチェックして進めるかどうか判断するのではなく、キャラはマップ(あるいはさらに上の神の視点)に進めるかどうかを確認するようにします。

皆様、回答ありがとうございます。

設計の規模や、上達の手段（経験を積む）、考え方など、とても参考になります。

丁寧にありがとうございました。

とりあえず、今、作ろうとしているゲームがありますので、ためしに設計図（クラスの相関図だけでも）書いてみようと思います。