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年前

もうちょっと広い視点の流れを意識して、細かいのは後々に放り投げるのはどうでしょうか

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

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

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

zxc さんが書きました:もうちょっと広い視点の流れを意識して、細かいのは後々に放り投げるのはどうでしょうか
そこまで来るともう最初から書き直したくなる勢いだ...

Rittai_3D
記事: 525
登録日時: 12年前

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

投稿記事 by Rittai_3D » 10年前

画面遷移はシーン基底クラスのポインタ型のstd::vectorやらstd::listを用意して、遷移するときは遷移先のシーンをpushするようにすると楽だと思います。
ひとつ前に戻りたいなら一番上のシーンをpopすればよいですし。

・・・と思いつきで言ってみました。わたし自身は子のやり方で画面遷移を実装したこと無いです。申し訳ない。

アバター
せんちゃ
記事: 50
登録日時: 14年前

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

投稿記事 by せんちゃ » 10年前

各画面に遷移する際に遷移した履歴を持たせるようにするといいと思います。
最初はどの画面から開始するのか、などの設定などもできるといいですね。

各画面のパラメータは次の画面へ遷移する際に渡してやって次の画面に遷移した際に初めに呼ばれる初期化関数で受け取るように作るのが今まで自分の見てきたやり方の中ではメジャーな手法でしょうか。
遷移の際の移動演出は画面側で行う手法とトランジションという遷移ロジックをオブジェクト化したものを渡すかの手法を知っています。
前者は各画面に画面切り替わりのタイミングでコールバックさせるイベント(FadeIn、FadeOutなどと命名することが多い)を作りそこにロジックを書く方法、
後者は遷移に必要なオブジェクトの参照を渡してそこで処理してしまう感じです。

設計は「設計するぞ!」と思って設計するより、
最初に必要なものを作っていってから「こりゃあかんわ」ってなったときに逐次修正していくほうがスマートな作りになると思います。

アバター
Nao
記事: 24
登録日時: 12年前

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

投稿記事 by Nao » 10年前

多くは言わないのでせめてポーズ画面を実装して頂きたいです。

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

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

投稿記事 by ISLe » 10年前

久しぶりに来たので乗り遅れてしまいましたが。
『転移』とおっしゃっているのが考え方を表しているのかなと思いますね。

コメントしてるみなさんは『遷移』とおっしゃってますよね。
オブジェクトは動かないのです。

そしてオブジェクト(の役割)は変化しません。
そこは『遷移』という言葉と矛盾しますけどね。

大事なこととして、どの画面も、同時に並行して動くように作ることが基本です。
その上で、その中の1つだけが動く仕組みにするのです。
既にコメントされているのはその方法ですからいまのまま遷移だけうまくやろうとしてもできないと思います。
オブジェクトの関係が密すぎるのが問題だと思います。

動くのが1つだけでないと論理的に破綻するとしてもそれは別の問題なので切り離して考えてください。


余談ですが、1つ前の日記の共同開発が成功するかどうかもそこにかかってきます。
どこかが欠けていても動くプログラムであるということは、担当者に責任はあっても負担にはならない。
〇〇の作業が遅れているから他の作業が進められないといったことになりません。

問題は、ほとんどのひとは完成しないと動かせないと思っていることです。

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

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

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

Rittai_3D さんが書きました:画面遷移はシーン基底クラスのポインタ型のstd::vectorやらstd::listを用意して、遷移するときは遷移先のシーンをpushするようにすると楽だと思います。
ひとつ前に戻りたいなら一番上のシーンをpopすればよいですし。

・・・と思いつきで言ってみました。わたし自身は子のやり方で画面遷移を実装したこと無いです。申し訳ない。
std::vector? std::list???
なにそれ?といった感じです、まだ組むより覚えることのほうが先の様です...

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

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

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

せんちゃ さんが書きました:各画面に遷移する際に遷移した履歴を持たせるようにするといいと思います。
最初はどの画面から開始するのか、などの設定などもできるといいですね。

各画面のパラメータは次の画面へ遷移する際に渡してやって次の画面に遷移した際に初めに呼ばれる初期化関数で受け取るように作るのが今まで自分の見てきたやり方の中ではメジャーな手法でしょうか。
遷移の際の移動演出は画面側で行う手法とトランジションという遷移ロジックをオブジェクト化したものを渡すかの手法を知っています。
前者は各画面に画面切り替わりのタイミングでコールバックさせるイベント(FadeIn、FadeOutなどと命名することが多い)を作りそこにロジックを書く方法、
後者は遷移に必要なオブジェクトの参照を渡してそこで処理してしまう感じです。

設計は「設計するぞ!」と思って設計するより、
最初に必要なものを作っていってから「こりゃあかんわ」ってなったときに逐次修正していくほうがスマートな作りになると思います。
うーむ....難しい、各画面の初期化時にパラメータの受け渡しを行えばいいのですね、演出はまだ先になりそうですねぇ、その説明を読んでもイマイチピンと来ないもので、

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

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

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

Nao さんが書きました:多くは言わないのでせめてポーズ画面を実装して頂きたいです。
ですよね... 次の長期休みに実装しときます。

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

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

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

ISLe さんが書きました:久しぶりに来たので乗り遅れてしまいましたが。
『転移』とおっしゃっているのが考え方を表しているのかなと思いますね。

コメントしてるみなさんは『遷移』とおっしゃってますよね。
オブジェクトは動かないのです。

そしてオブジェクト(の役割)は変化しません。
そこは『遷移』という言葉と矛盾しますけどね。

大事なこととして、どの画面も、同時に並行して動くように作ることが基本です。
その上で、その中の1つだけが動く仕組みにするのです。
既にコメントされているのはその方法ですからいまのまま遷移だけうまくやろうとしてもできないと思います。
オブジェクトの関係が密すぎるのが問題だと思います。

動くのが1つだけでないと論理的に破綻するとしてもそれは別の問題なので切り離して考えてください。


余談ですが、1つ前の日記の共同開発が成功するかどうかもそこにかかってきます。
どこかが欠けていても動くプログラムであるということは、担当者に責任はあっても負担にはならない。
〇〇の作業が遅れているから他の作業が進められないといったことになりません。

問題は、ほとんどのひとは完成しないと動かせないと思っていることです。
・・・!?!?!?国語力がなさ過ぎるぜ、

同時に並行してすべての画面が進行している...? それなのにそのうえでどれか一つだけが動くようになる、とは...

まぁそれはいいとして、個々のオブジェクトが密接にかかわりすぎている、とは?これは各画面のオブジェクトであるということでしょうか、
いろいろと足りんものがあるなぁ