Hiragi(GKUTH)の日常
理系大学生の日記

初のゲームを作成する日記:04

アバター
Hiragi(GKUTH)
記事: 167
登録日時: 14年前
住所: 大阪府
連絡を取る:

初のゲームを作成する日記:04

投稿記事 by Hiragi(GKUTH) » 10年前

お久しぶりです。 第四回目を迎えることができました。だた完全に行き詰ってます

設計が分からん...わからんぞー! というかそもそもゲーム自体の全体の流れを意識してから組むべきだったんだ!
ゲームのメイン即ち今回の場合実際にボールが跳ね返り、ブロックを崩していく場面から作っていったから画面転移とかの設計をどうすればいいのか分からなくなってきました。
小さなところから作り始めてあとからその周りの枠を後付けしていくって、わかりにくいに決まってんじゃないですか。 ミスったなぁ、
タイトル ⇒ ゲーム画面 ⇒ リザルト or ゲームオーバー画面
みたいな大まかな流れを最初から作っておいて、その中に処理を描くべきだったんだ...!なにを今更言っているのか。 何とかしないといかんなぁ

とりあえず、タイトル画面と終了画面 (ClearとGameOverを表示するの)を作って、それからどうやって画面転移、それと各シーンの情報を別のシーンに移すのか考えないと...
仕様としては(つか最初に仕様考えてからゲーム作れよ)

タイトル画面:
 ・マウスクリックでボタン選択、 ボタンの種類は GameStart GameExit Result Option ぐらいがあれば十分だろう。 各ボタンよりゲーム画面、ゲームの終了、リザルト画面、オプション画面への
  転移を行う
 
ゲーム画面:
 ・8x8のブロックが存在していて、プレイヤーはマウスによってバーを操作しつつブロックを崩していく、マウスをクリックするとボールが移動し始める。
 ・コンティニューは3回、4回目のミスでゲームオーバー画面へと転移
 ・スコアの計算式は適当に クリア時間とコンティニュー回数でスコアを決定することにする。
 ・全部のブロックが消されたら、ゲームクリアー画面へ転移

ゲームクリアー画面:
 ・ゲームクリアー時のスコアを表示する。
 ・背景はゲーム画面を残しておきたい。
 ・スコアを記録するかの選択をする はい⇒スコアの書き込み後、タイトル画面へ転移 いいえ⇒タイトル画面へ転移

ゲームオーバー画面:
 ・ゲームオーバー時点の消せたブロック数とスコアを表示。
 ・リトライかどうかのボタンを設置 はい⇒ゲーム画面へ転移 いいえ⇒タイトルへ転移。

リザルト画面:
 ・今までのスコアの表示する。それだけ
 ・Backボタン設置、押すことによってタイトル画面へ転移。

オプション画面:
 ・なんらかのパラメータをいじれるようにする。 おそらくSE音量
 ・Backボタンの設置、押すことによってタイトル画面へ転移。


と、頭の悪い私はいちいちこう書かないと分からなくなるのです。 さらに加えてこのような画面転移を実際にどうやって実装すればいいのやら...
とりあえず私の左上にあるA4用紙にフローチャート的なものを書いてみる、つかそもそもフローチャートの記法すらまともに覚えてないな俺。

ここにきったないメモ残しときますね。
画像

親クラスField_tを作ってソレを継承しつつ個々のシーンの処理を描いて、すべてのField_tを持つクラスをまた作って、そこで画面転移を処理するべきなのか。
でも個々のシーンに別のシーンの情報を渡さにゃならんし、それってどうやって書くの? 各シーンに対して情報の送受信を行うメンバ関数とか作ればいいの?

わ、わからん....もっと単純でスマートな考え方があるのかもしれませんが、思いつきません。


素直にゲームプログラミングの本を一冊買うかなぁ...

現時点でのソース(きったないしdeleteとか忘れてそう)
► スポイラーを表示

zxc
記事: 79
登録日時: 13年前

Re: 初のゲームを作成する日記:04

投稿記事 by zxc » 10年前

[拡張子 zip は無効化されているため、表示できません]

 とりあえず中途半端ですが、ファイルの分割と些細な部分だけ手を加えてみました。終了時にエラーが出たりしますが元々の使用だと思われます。

アバター
Hiragi(GKUTH)
記事: 167
登録日時: 14年前
住所: 大阪府
連絡を取る:

Re: 初のゲームを作成する日記:04

投稿記事 by Hiragi(GKUTH) » 10年前

>>zxc
わざわざ有難うございます。といってもまだそんな見てないのですが、 

ISLe
記事: 2650
登録日時: 14年前

Re: 初のゲームを作成する日記:04

投稿記事 by ISLe » 10年前

一例としては、Ball_tの中で世界の端を判定しているので、ステージの大きさや形がBall_tに依存しています。
反射するかどうかも含めてボールの挙動を決めるのはボール自身。
外部から与えるのは挙動を決めるヒントのみであるべき。
ということを考えるのが抽象化です。

そうやって抽象化を進めると、壁もブロックもそれ自身が独立して存在できるようになります。
あらゆるオブジェクトが同時に並行に存在することができるよう(な仕組み)になります。
#そうするとプログラムのどこからでも作っていけるようになるので開発がしやすくなります。

フローチャートは全体としての状態の変化を表すもので、オブジェクトの構造を表すものではありません。
カタログから想像でモノを作るのは容易ではありませんから、きちんと設計図(に相当するもの)を準備しましょう。
最後に編集したユーザー ISLe on 2015年4月27日(月) 18:30 [ 編集 1 回目 ]