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

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

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

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

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

お久しぶりです。 なんかこのシリーズ更新されるの数ヶ月ぶりな気がする。大丈夫だろうか。
実は前回の日記の後にzxcさんが随分と書き換えてくれて、ファイル分割まで行ってくださいました。 が、それを理解する頭が無かったようで、放棄していました
zxcさん申し訳ないです。

で、だ。 先ほど20分ほどコードを見返して当時自分が何してたか思い出してみて、とりあえずゲーム自体(実際に遊ぶ所)ってのはそれらしく見えていたので、タイトル、オプション、等の
画面「遷移」をさせなければいけません、ISLeさんの指摘は「個々を抽象化し、独立させること」です。
ISLe さんが書きました:一例としては、Ball_tの中で世界の端を判定しているので、ステージの大きさや形がBall_tに依存しています。
反射するかどうかも含めてボールの挙動を決めるのはボール自身。
外部から与えるのは挙動を決めるヒントのみであるべき。
ということを考えるのが抽象化です。

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

フローチャートは全体としての状態の変化を表すもので、オブジェクトの構造を表すものではありません。
カタログから想像でモノを作るのは容易ではありませんから、きちんと設計図(に相当するもの)を準備しましょう。
 つまりコレは何を意味するんだ、と 。。。相変わらず分からん^^; と言うか抽象化するためにどのようにコーティングすればいいか分からない所理解出来ていないということでしょう
ただ行動せにゃ何も始まらんので、とりあえずこの一例に習い、Ball_tで判定していた世界の端をField_tで判定させてみました。



Ball_t Update

CODE:

void Ball_t::Update()
{
     //壁際では跳ね返るよね
	if (x[0] get_x(), ball->get_y(), ball->get_r(), bar->get_x(), bar->get_y(), bar->get_rect_x(), bar->get_rect_y());
    for (int i = 0; i get_flag(i, k))
            {
                ball_block[i][k] = HitTest(ball->get_x(), ball->get_y(), ball->get_r(), blocks->get_x(i, k), blocks->get_y(i, k), blocks->get_rect_x(), blocks->get_rect_y());
                if (ball_block[i][k]) blocks->isnotthere(i, k);
                if (ball_bar == STRIPE || ball_block[i][k] == STRIPE) hit_ball = STRIPE;
                if (ball_bar == HORIZON || ball_block[i][k] == HORIZON) hit_ball = HORIZON;
                if (ball_bar == BOTH || ball_block[i][k] == BOTH) hit_ball = BOTH;
                if (ball_block[i][k] != 0)break;
            }
        }
 
        //ボールが何かにぶつかっていればボールをぶつかってるよと教える
    if (hit_ball == STRIPE) ball->isHitted_Stripe();
    if (hit_ball == HORIZON) ball->isHitted_Horizon();
    //if (hit_ball == BOTH) ball->isHitted_Lean();
 
        //デバッグ用
    DrawFormatString(0, 420, GetColor(255, 0, 0), "State:%d", hit_ball);
 
        //そして更新
    ball->Update();
    blocks->Update();
    bar->Update();
}


Ball_t Update()

CODE:

void Ball_t::Update()
{

        //各状態が有効なら:水平方向の接触時はy座標の速度を反転、垂直方向はx座標の速度を反転
    if (Horizon){v_y[0] = -v_y[0], Horizon = false;}
    if (Stripe){ v_x[0] = -v_x[0], Stripe = false; }
 
    //if (Lean){ v_x[0] = -v_x[0], v_y[0] = -v_y[0], Lean = false; } 保留です。
 
        //座標に対し移動させる
    x[0] += v_x[0];
    y[0] += v_y[0];
}
Field_t Update

CODE:

void Field_t::Update()
{
    int ball_bar = NO,
         ball_block[8][8];
 
    int hit_ball = NO;
 
        //各ブロックに対してあたり判定を行う
    ball_bar = HitTest(ball->get_x(), ball->get_y(), ball->get_r(), bar->get_x(), bar->get_y(), bar->get_rect_x(), bar->get_rect_y());
    for (int i = 0; i get_flag(i, k))
            {
                ball_block[i][k] = HitTest(ball->get_x(), ball->get_y(), ball->get_r(), blocks->get_x(i, k), blocks->get_y(i, k), blocks->get_rect_x(), blocks->get_rect_y());
                if (ball_block[i][k]) blocks->isnotthere(i, k);
                if (ball_bar == STRIPE || ball_block[i][k] == STRIPE) hit_ball = STRIPE;
                if (ball_bar == HORIZON || ball_block[i][k] == HORIZON) hit_ball = HORIZON;
                if (ball_bar == BOTH || ball_block[i][k] == BOTH) hit_ball = BOTH;
                if (ball_block[i][k] != 0)break;
            }
        }

		//世界の端との判定
	if (ball->get_x() get_r() || zxc::GetWinSizeX() get_x() + ball->get_r())hit_ball = STRIPE;
	if (ball->get_y() get_r())hit_ball = HORIZON;
 
        //ボールが何かにぶつかっていればボールをぶつかってるよと教える
    if (hit_ball == STRIPE) ball->isHitted_Stripe();
    if (hit_ball == HORIZON) ball->isHitted_Horizon();
    //if (hit_ball == BOTH) ball->isHitted_Lean();
 
        //デバッグ用
    DrawFormatString(0, 420, GetColor(255, 0, 0), "State:%d", hit_ball);
 
        //そして更新
    ball->Update();
    blocks->Update();
    bar->Update();
}
うむ、言われたとおりにしか出来ん、ただわかったことはBall_tはボールが何かに接触しているか否かしか知らないようすることがに出来た、ということです。コレによりもしFieldの大きさが変わったとしてもBall_tには何も変更を
加えずに実行することが出来ました、 ただコレがどう画面遷移に繋がるのかは未だわからないです。
ただFieldの4行目あたり
ball_block[8][8];
の部分がマズいと思います。Fieldでボール対ブロックの縦横の個数を決定してしまっている。
というか判定部分も整数値8をそのまま使用してる、この場合Block_tの縦横のブロック個数が変更された場合正常に当たり判定が行えない気がする...
というわけでBlock_tに縦横の個数を返すゲッターを作ってFieldで判定するように変更するのであった...(ただしできなかった)
#当たり判定の時に使う配列の要素数の指定の時に定数値を与えないとダメだけどゲッターで取得する変数が定数値だと断定できないため要素数を指定出来ない


と、今回は実質的に何も進展しない回でした。

高2前期も終わるところなのでもうそろそろプログラミングを本気でやりたい(勉強しろ)

添付されたファイルですが、ソースコードと同じ階層にDxLibという名前のフォルダでDXライブラリ突っ込めば
動くと思います(多分...)
添付ファイル

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

最後に編集したユーザー Hiragi(GKUTH) on 2015年9月21日(月) 22:05 [ 編集 1 回目 ]

アバター
softya(ソフト屋)
副管理人
記事: 11677
登録日時: 14年前

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

投稿記事 by softya(ソフト屋) » 9年前

完成させないと意味が無いんで、オブジェクト指向やら良いプログラミングに拘り過ぎるのも害なんですよね。
少しづつ良いプログラムが書けるようになれば良い程度で考えましょう。
よく概念がつかめないままプログラムをいじり倒すと、決して触りたくないプログラムが出来ます。これが一番たちが悪い。

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

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

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

softya(ソフト屋) さんが書きました:完成させないと意味が無いんで、オブジェクト指向やら良いプログラミングに拘り過ぎるのも害なんですよね。
少しづつ良いプログラムが書けるようになれば良い程度で考えましょう。
よく概念がつかめないままプログラムをいじり倒すと、決して触りたくないプログラムが出来ます。これが一番たちが悪い。
うーむ、難しいものです。とりあえず動けばいいやってのでいいんですかねぇ、数を重ねればそりゃ洗練されて行くでしょうし理解も深まると思いますが...
少し上達することに焦りすぎているのかもしれないです、とりあえず今回はクラスの「継承」の使い方がよく分からんので「ちょっとすごい構造体」としてクラスを扱いつつ
ゲームを完成させていきましょうかね、小規模(?)なゲームをいっぱい作ればいずれ(ゲームの設計やオブジェクト指向の概念を)理解していくのだろうか...?

というか別にゲームでなくても良くね? っていう。

アバター
softya(ソフト屋)
副管理人
記事: 11677
登録日時: 14年前

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

投稿記事 by softya(ソフト屋) » 9年前

正解はないですよ。人により意見も違います。
ただ、直しやすくバグの少ないプログラムを作ることを常に考えていれば、良くなっては行きます。
出来る範囲でめげない程度のリファクタリングもマメに行います。
その過程で良い仕組み・テクニックを分かる範囲で導入していけば、前の自分よりは見違えて良くなるはずです。
少しづつ良い物を目指しましょう。
最後に編集したユーザー softya(ソフト屋) on 2015年9月21日(月) 22:47 [ 編集 1 回目 ]

アバター
usao
記事: 1889
登録日時: 12年前

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

投稿記事 by usao » 9年前

>「ちょっとすごい構造体」としてクラスを扱いつつ

いいんじゃないでしょうか.
わたしが最初にクラスを使った時は「構造体 + コンストラクタ」状態でした.
「初期化が自動的とかSUGEEEEE!!」って.
そういう状態の過渡期(?)を経ずにいきなり「(何らかの基準による)C++的な(?)満足の行く書き方」の達成を目指すのは
大変に難しいように思います.


>というか別にゲームでなくても良くね? っていう。

どうなんでしょう?
何を達成すべきで,何はどうでもいいのか.平和とは何か.
>(ゲームの設計やオブジェクト指向の概念を)理解
というのが目的ならば題材がゲームで有る方が都合がよいような気がしますが,
「ゲームの設計」の部分が特に欲しいわけでもない要素ならば
(個人的に,ゲームってかなり難しい部類だと思ので)他の題材の方が良いのかも.

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

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

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

>>usaoさん
そうなんですよねー ゲームの設計はしたいとは思っては居るんですが、それが職業のためになるかというとそれはまた違う。
ただプログラミングのスキルを上げたいってことです。 漠然としすぎて具体的に何をすればいいか分からんので、とりあえず現時点で一番やる気が出る
ゲーム制作ということになってます。 かなり難しい部類だとは私も思うんですが...