基準座標を中心にスクロールするカメラオブジェクト

[土門]

ISLeさん
自分の現在のカメラclassですが、

コード:

class Camera
{
public:
	static int getValue(void);
	static void setValue(int);
private:
	static int ScrollValue;
};

といったシンプルなものとなっております（このシンプルさが利点かな、とも思っております。
どこでも呼べるようにstaticとしてます（そのうちシングルトンにするつもりです）
定義の方で初期化したスクロール量に対して、セッターを利用して
playerの移動量とリンクさせる感じで作っております（そのリンク開始位置でスクロールの開始、停止を決めている）
あと、そのスクロールする移動量をplayer以外のすべてのオブジェクトの描画処理に与えて
player以外のオブジェクトのみカメラに合わせた移動を実現している、という感じです。

しかし、確かに、
ご指摘通りこれではplayerの動きを前提としたカメラclassとなっております。
（その他の処理はscrollを実装するにあたり、どこも同じ処理で問題ないですよね？）

そこでISLeさんのおっしゃった下記を備えたカメラオブジェクトを作りたいです。

〇スクロール処理は他の処理と一切関係を持たず、
　基準座標を中心にスクロールする
〇現在のスクロールオフセットを持ち、与えられた基準座標に対して近づくように
　スクロールオフセットを変化させるだけ

playerの前提無しというのが初めてで、想像できないのですが、
カメラオブジェクトの中ですでにスクロール、開始、停止値などすべての設定が書かれてある感じですよね？
ご教示よろしくお願い致します。

[ISLe]

playerの前提無しというのが初めてで、想像できないのですが、
カメラオブジェクトの中ですでにスクロール、開始、停止値などすべての設定が書かれてある感じですよね？

まずスクロールがどういうふうに発生するのかを定義しなくてはいけません。
今回はプレイヤーを画面内に収めることが目的です。
ここから前提を排除して抽象化します。

• スクロールを扱うのですから、スクロール座標(オフセット)を保持する必要があります。
• 画面内に収めるということは、画面座標が特定の範囲内に入っている必要があるということです。
  画面内の特定の領域を表す情報が必要です。

カメラオブジェクトが必要とする情報はこれだけです。
あとはメソッドで与えられた基準座標に対して、計算を行い、スクロール座標(オフセット)を更新します。


カメラオブジェクトはプレイヤーを前提としません。
プレイヤーの情報をカメラオブジェクトに与えるのはさらに上位のオブジェクトが担うからです。
オブジェクトの関係において横の直接参照はご法度だということは前スレでも繰り返し書きました。

設計でオブジェクトが理想的な関係になっていれば、特定のオブジェクトをどこからでも呼び出せるということにメリットはありません。
必要な場所に元からメンバとして存在するわけですから。
一箇所に定まらない場合はたいてい設計に問題があると認識してください。

[土門]

レスありがとうございます、、
しかし、自分がやろうとしていたカメラと
ISLeさんのいうカメラの相違部分についてまだハッキリ理解していないので
作るといっても目標が定まっていないのでイメージが掴めず、困っております。
プレイヤーの前提が必要無くなるのはわかりましたが、
ソレ以外については、自分のカメラクラスと同じままでいけるんでしょうか？

例えば、自分の実装したカメラという概念は、
副管理人さんのお言葉を借りますが、
＞横長い舞台があると考えてみてください。それを撮影しているカメラがあります。
＞このカメラはレールの上に載っていて左右にしか動きませんしカメラの首も触れません。
＞舞台の端から主人公が登場し、カメラは横に移動して主人公を画面中央に据えます。
＞そして敵の皆さんが舞台のそれぞれの場所で配置につきました。
＞この舞台で主人公は右に左にと動きまわります。カメラはそれに合わせて付いて行くだけです。
＞これがよく使われるマップスクロールの仕組みを説明したものです。
と、これだと思うのです。
ISLeさんのいうカメラオブジェクトも概念は同じ、ということの理解で大丈夫でしょうか？
それとも、もっと違う見方をしなければなりませんか？
自分の作ったカメラクラスと、ISLeさんのいうカメラクラスとが
どこまでが同じで、どこから違うのかがまだ掴めないので
自分のカメラクラスを少し直す感じなのか、
まるっきり考えから直して、作り上げていかなければならないのか、わかりません。

＞まずスクロールがどういうふうに発生するのかを定義しなくてはいけません。
＞今回はプレイヤーを画面内に収めることが目的です。

プレイヤーを常に画面内に収めるためには
プレイヤーの座標を取得し続ける変数が必要だと思うのですが、違いますか？
それか、メソッド内でプレイヤーの座標(ゲッター)を利用するとか、、いや、
ゲッターで見ると前提になるんですよね？、、じゃあ取得し、格納する変数が必要ですよね？

＞画面内に収めるということは、
＞画面座標が特定の範囲内に入っている必要があるということです。
＞画面内の特定の領域を表す情報が必要です。

「画面座標が特定の範囲内に入っている」がわかりません。
特定の範囲内ってなんでしょうか
その特定の範囲というのを決めてやる、ということでしょうか？

＞スクロールを扱うのですから、スクロール座標(オフセット)を保持する必要があります。

移動量ですね。移動量を算出する方法はまだ想像つきませんが、
移動量を確保する変数が必要だということですよね。

＞カメラオブジェクトが必要とする情報はこれだけです。
＞あとはメソッドで与えられた基準座標に対して、
＞計算を行い、スクロール座標(オフセット)を更新します。

基準座標ってなんでしょうか、、。

＞プレイヤーの情報をカメラオブジェクトに与えるのはさらに上位のオブジェクトが担うからです。

え、プレイヤーの情報(座標)が要らない、ということですか？
座標情報を格納しないのでしょうか？？

＞オブジェクトの関係において横の直接参照はご法度だということは前スレでも繰り返し書きました。

はい、理解しております。
しかし、今回は上位が確保している下位の情報はすべて？二次元配列内、にあるんですけど、、
それはカメラオブジェクトが覗くものでは無い気がするのです。

当たり判定や移動などで利用している二次元配列情報は
スクロール云々に関しては無関係でいいんですよね？

＞特定のオブジェクトをどこからでも呼び出せるということにメリットはありません。
＞必要な場所に元からメンバとして存在するわけですから。

はい。オブジェクトすべてに移動量を反映させる必要がありましたが、
確かにそれを直接各オブジェクトに書いていました。
では、すべてのオブジェクトに移動量を反映させる方法、、
例えば、すべてのオブジェクトで共通するスクロール移動量格納変数を
作るということでしょうか。

とりあえず、作るカメラのイメージをもう少し理解したい(現在頭では得体の知れないオブジェクトとなってます)ので
上の副管理人さんの例えみたいな解説、もしくは疑似言語みたいな解説をお願い出来ませんでしょうか、すみません、、、。

＜カメラクラス＞
画面内の特定の領域を表す情報←これが一番わかりません。
特定の領域を表すために利用するのがプレイヤーの位置を格納する変数でしょうか？
スクロール移動量格納変数
スクロール移動量算出メソッド
各オブジェクトに直接与える情報は無いのでゲッターもセッターも要らない

必要なのはこんな感じでしょうか。

[ISLe]

説明が面倒くさいのでサンプルコードを書きました。
オブジェクトとしてのまとまりはほとんどありませんが、意味は分かってもらえるのではないかと思います。
旧ゲームプログラミングの館のchar.png画像を使ってます。

コード:

#include "DxLib.h"

class Scroll {
	int ofs_x;
	int left;
	int right;
	int left_end;
	int right_end;
public:
	Scroll(int l, int r) : left(l), left_end(l), right(r), right_end(r), ofs_x(0) {}
	void setBorder(int l, int r) { left = l; right = r; }
	void scroll(int ref_x) {
		int x = ref_x - ofs_x;
		if (x < left) {
			int d = (left - x)/3;
			if (d <= 0) d = 1;
			ofs_x -= d;
			if (ofs_x < left_end) ofs_x = left_end;
		}
		if (x > right) {
			int d = (x - right)/3;
			if (d <= 0) d = 1;
			ofs_x += d;
			if (ofs_x > right_end) ofs_x = right_end;
		}
	}
	int getOffsetX() { return ofs_x; }
};

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
	int image[16];
    char key[256];
	struct Player {
		int x;
		int dir;
	} player = { 0, 3 };
	ChangeWindowMode(TRUE);
	if (DxLib_Init() != 0) return 0;
	SetDrawScreen(DX_SCREEN_BACK);
	LoadDivGraph("char.png", 16, 4, 4, 32, 32, image);

	Scroll scroll(0, 640); // スクロールを停止する左右のオフセット
	scroll.setBorder(32*6, 640-32*6); // 基準座標を収める範囲

	while (ProcessMessage() == 0 && ScreenFlip() == 0 && ClearDrawScreen() == 0 && GetHitKeyStateAll(key) == 0) {
		if (key[KEY_INPUT_LEFT] == 1) {
			player.dir = 1;
			player.x-=2;
			if (player.x < 0) {
				player.x = 0;
			}
		}
		if (key[KEY_INPUT_RIGHT] == 1) {
			player.dir = 3;
			player.x+=2;
			if (player.x >= 1280-32) {
				player.x = 1280-32-1;
			}
		}
		int ofs_x = 0;
		if (key[KEY_INPUT_Z] == 0) {
			// Zキーを押していないときはキャラの中心が基準
			// ふつうに画面の端に行くとスクロールする
			scroll.scroll(player.x+16);
		} else {
			// Zキーを押しているときはキャラの進行方向へ一定の距離が基準
			// キャラの前方を広く取ったままスクロールし振り返ると…
			if (player.dir == 1) {
				scroll.scroll(player.x+16-32*8);
			}
			if (player.dir == 3) {
				scroll.scroll(player.x+16+32*8);
			}
		}
		ofs_x = -scroll.getOffsetX();

		for (int x=0; x<1280; x+=32) {
			DrawBox(ofs_x+x, (480-32)/2, ofs_x+x+32, (480-32)/2+32, GetColor(255,255,255), FALSE);
		}
		DrawGraph(ofs_x+player.x, (480-32)/2, image[(player.dir)*4+((player.x/2)%4)], TRUE);
	}
	
	DxLib_End();
	return 0;
}

[土門]

サンプルコードをありがとうございます。
実際に実行してトレースしてみて、大体の仕組みはわかったつもりですが、、
いざクラスとして実装しようとすると、ビルドは成功と出ますが窓が出た途端に
「動作を停止しました」のエラーが出てしまいます。
大抵これは、値が入ってこない、見る場所に値が入っていない等のエラーですが
このカメラオブジェクトclassは単体で存在出来、
他のクラスの存在を気にしなくともインスタンス化して
実行出来るのですよね？
ということは、考えられるのは、スクロール量を割り出すメソッドの位置？な気がするんです。

とりあえず、実装する流れですが、カメラオブジェクトクラス作ったとして、
それをゲームstageのコンストラクタで
インスタンス化→スクロールを停止する左右のオフセットメソッド
→基準座標を収める範囲のメソッドを記載。
そのあとに、スクロールの基準を決めるメソッド
（つまりはスクロール量を割り出すメソッド）scroll.scroll(player.x+16);を
記載するわけですが
その場所があやふやで悩んでいます。
プレイヤーを基準にするので引数でplayerの位置を取らねばなりませんが
playerの上位クラスの中で、引数にはゲッターを用いてやる感じでしょうか？

を置くべき、場所がわかりません。
stageクラス？playerクラス？それとも
playerクラスの上位クラス(オブジェクトのlistを持つオブジェクトマネージャークラス）？
しかも、player.xに欲しいのがプレイヤーの描画座標(ワールド座標)だとして、
今回の自分の組み立てた描画座標をはじき出すアニメフェーズというややこしい
this->anim_X = posX*16+(prevposX*16-posX*16)*anim_count/30;の処理に対して、
単純にscroll.scroll(anim_X+16);としたのではダメみたいなんです。。。

61行目のint ofs_x;は、カメラオブジェクトのメンバ変数のofs_x;と違って、
player描画用の為のスクロール量ですよね？
プレイヤーのDrawGraphの引数にて(ofs_x+player.x）と利用してますし。。

スクロール量を割り出すscroll.scroll(player.x+16);の置き場所、
記載方法でつまずいてます。
ビルド後、停止するエラーなので、なにが原因かわからず、、、

ちなみに、カメラオブジェクトclass、シングルトンで作っても大丈夫ですよね？

[ISLe]

あくまで考え方を示すだけのサンプルコードで、設計としてはあちこち矛盾していますから理解して流用してください。

カメラに基準座標としてプレイヤー座標を渡すのは、カメラとプレイヤーのどちらよりも上位にあるオブジェクトです。

Scroll::scroll関数は、
基準座標をセットする関数
スクロール位置を計算する更新関数
と分けても良いでしょう。

this->anim_X = posX*16+(prevposX*16-posX*16)*anim_count/30;の処理に対して、
単純にscroll.scroll(anim_X+16);としたのではダメみたいなんです。。。

anim_Xにプレイヤーの描画座標が常に入っているなら問題無いと思いますが。

ちなみに、カメラオブジェクトclass、シングルトンで作っても大丈夫ですよね？

動作には影響ないと思います。

[土門]

ありがとうございます。
トレースしまくっていたら、だんだんわかってきました。
スクロールさせるという概念も。

自分はこのカメラオブジェクトclassが
スクロール量を算出出来るようにするためには
これらメンバ関数をステージclassやらプレイヤーclassやら
どこに置けばいいのか、などとごちゃごちゃ考えていましたが、
もしかして、カメラオブジェクトclassを作るとして、
スクロールするのに必要なその処理を
このオブジェクトclassの中ですべてさせることが出来る、
ということじゃないですか？
要は、スクロール量を算出するscroll(player_X+8);の引数に、
中心にもってくる対象であるplayerの座標さえ常に取り込んでいれば
このカメラオブジェクトはスクロール量を保持し続けてくれている、と。

あとは、そのスクロール量をゲーム内のオブジェクト達の描画に反映させれば
それでスクロールさせているように見せられる、そういうことですよね？？？？？

[ISLe]

要は、スクロール量を算出するscroll(player_X+8);の引数に、
中心にもってくる対象であるplayerの座標さえ常に取り込んでいれば
このカメラオブジェクトはスクロール量を保持し続けてくれている、と。

プレイヤー座標ではなくあくまでも基準座標、と書いたのはそういうことです。
どういう実装にすべきかこのトピックの最初に土門さん自身で引用しているではないですか。

前のスレに書いたことですが、マップの先を見るのも基準座標次第で可能です。

サンプルコードも基準座標の違いでスクロールの仕方が変わるのを見て欲しいところですが。
Zキーを押しているあいだスクロールの仕方が変わることに気付いてなくはないですよね。

[土門]

＞Zキーを押しているあいだスクロールの仕方が変わることに気付いてなくはないですよね。

もちろんです。
スクロールする仕組みをトレースすることで手一杯になっていたので
触れませんでしたが、Zキーを押している間は前方のマップを確認することが出来ますね。
これはマップの先を確認する、というだけでなく、スクロールだけを先に進めたい、など、
イベントなどでも重宝しそうな処理だと思いました。
今、カメラオブジェクトを実装している途中です。
うまくいきそうです。
うまく実装出来ましたら、解決としたいと思います。

[土門]

ISLeさん
すみません、質問させて下さい。
スクロールさせる上で、マップのオブジェクトたちの描画も
「カメラからはみ出た位置なら描画しない」という処理を施すことになると思うのですが
今回のカメラの構造だとどういう風にすればいいのでしょうか？
scroll.setBorder(int,int)で決めた基準座標を収める範囲で
描画、非描画の判定をさせたらいいですか？

[ISLe]

スクロール開始位置やスクロール停止位置と、画面内かどうかはまったく別のものです。
スクロール処理は他の処理と一切関係を持ちません。これ何回目ですかね。

特定領域内のみ描画する処理をクリッピングと言います。
クリッピングを話題にするのであれば新たにトピックを立ててください。

クリッピングはクリッピング対象領域(多くは矩形)の指定を行い、描画処理内で対応します。
基本的には画面から完全に外れていれば描画しないようにするだけです。
画面の一部でも全部でも矩形と考えれば同じ処理になります。
タイルマップで矩形内の最低限だけ描画するコードをウチのブログで公開してますがいまのところJavaのコードしかありません。

[土門]

＞特定領域内のみ描画する処理をクリッピングと言います。
＞クリッピングを話題にするのであれば新たにトピックを立ててください。

わかりました、まずはクリッピングについて自分で調べてチャレンジしてみます。
教えてくださってありがとうございます。

あと、スクロールのことなのですが無事に実装出来て、
目的を成すために数値をいじっているのですが
まだ掴めないメソッドがありまして、そのメソッドの説明をお願い出来ませんか？
ISLeさんから教えて頂いたソースについてです。
scrollのコンストラクタの引数は最初に表示するマップの座標(左端から右端の幅)と認識しています。
でも、setBorderメソッドについてちょっとわからなくて。
コンストラクタの数値と、このsetBorderの数値がうまいことハマらないと
スクロールの動作がおかしくなります。そのおかしくなる理由がトレース出来ず
うまくこれらのメソッドを操ることが出来ません。
例えば、基準座標をマップの右端に設定して、基準座標であるplayerを左にどんどん移動させても
左にはスクロールしてくれない状態だったり、
scrollのright_endの制止する式を無視してplayerに合わせてスクロールしてしまったり、、
void scroll(int ref_x)メソッドの定義内のint d = (left - x)/3;とか、なぜ３で割るのかがわかりません。
特にif (ofs_x > right_end) ofs_x = right_end;}これはスクロールを止めるものなのに
right_endにはマップの端の座標が入っているのにも関わらず
playerに合わせてマップの端の向こうまでスクロールしてしまうのが悔しくてたまりません。
考えられる原因とか推測出来たりしますか？

[土門]

例えば、具体的に言いますと
幅1024のマップの「右端」にプレイヤーを配置し、
scroll(0,512);
setBorder(16*16,512-16*16);
でビルドしますと、当然ながらマップの左端から開始されてplayerは映っていません。
でも移動ボタンを押すと右端のplayerまでスクロールがすぐさま移動しまして
(scrollが基準座標であるplayerの座標を認識するので当然ですよね)、
そこからはplayerに合わせて左にスクロールしてくれるようになります。
が、同じ配置のままで今度はコンストラクタの引数だけを
scroll(512,1024);
setBorder(16*16,512-16*16);
と変えて、ビルドした場合、playerのいるマップの右端から始まるわけですが
なぜかplayerに合わせて左スクロールしてくれない状態となります。

このscrollのコンストラクタ内の数値だけで、
なぜここまで処理が変わってしまうのかがわかりません。
なにが原因なのでしょう？

[ISLe]

Scrollのコンストラクタで指定するのは、マップ(ワールド)座標で、スクロールを止めたい左端の座標と右端の座標です。
左端を起点にしているので、右端は画面に表示される幅を考慮する必要があります。
マップや画面の幅がころころ変わることはまず無いと思います。
ゆえにコンストラクタで指定します。

setBorderで指定するのは、スクリーン座標です。
画面に表示したとき、基準座標が、画面上で指定した範囲内に入るようにオフセットが調整されます。
ようするにどのくらい画面の端に近付いたらスクロールするかです。
どのくらいマップの先が見えるかはゲームバランスに直結しますから調整対象です。
ゆえにメソッドで指定します。

void scroll(int ref_x)メソッドの定義内のint d = (left - x)/3;とか、なぜ３で割るのかがわかりません。

Zキーを押しながら振り向いたときシュパッとスクロールするのがカッコ良いからです。
滑らかに変化させるにはN次方程式とか組み合わせて使ったりするのですが、サンプルなので適当です。
離れた場所にスクロールする機会がなければ常に1ピクセルずつとかでもかまいません。
スクロールの仕方はscrollメソッドの実装次第です。
いくつもパターンを実装しておいて切り替えることもできます。

scrollメソッドはオフセットをフレーム毎に変化させるいわゆるアニメーション処理です。
初期設定のためにスクロール座標をそのままセットするメソッドも必要でしょう。

[土門]

現在自分は基準座標をplayerとしていますが、
開始直後のカメラの位置はplayerの位置を意識したものでは無く
コンストラクタで入力した座標位置からカメラが始まります。

これは、

＞初期設定のためにスクロール座標をそのままセットするメソッドも必要でしょう。

を自分が満たしていないせい、ですよね？

[ISLe]

サンプルコードではスクロールオフセットを単に0で初期化しています。
コンストラクタで指定する引数は影響しません。

[土門]

＞Scrollのコンストラクタで指定するのは、スクロールを止めたい左端の座標と右端の座標です。
＞左端を起点にしているので、右端は画面に表示される幅を考慮する必要があります

なるほど、わかりました。ということは、基本的に左端は”０”が入ることになります。
左端を起点にしている、とありますが、ではこれはマップの右端から始める、なんてことが
出来ないんじゃないんじゃないでしょうか？

[土門]

すみません、やっとわかりました。
ofs_xを０で初期化しているから、
最初、必ず左端から始まるんですね。

要はあらかじめ、移動させた部分から開始したいときは
ofs_xにその値を入れてはじめろと。
そういうことですね。
、、しかし、今度は左から始まっても１フレームで
すぐさま右端、０の位置ですね、に飛ばされるんです。
はあ、、、。どういう状況なんでしょうか。。。

[土門]

間違えました。

オフセットをあらかじめ大目にいれてみて
右端から始まってくれてもそれは一瞬で、
１フレームですぐさま左端、０の位置ですね、にカメラは飛びます。

どうしてもマップの右端に置いたplayerから始められません
なにが間違っているのか、ご指摘下さいませんか？
右端から始めたいんです。ボコスカウォーズがそうであるように。

コンストラクタにはマップの端から端を引数で。
セットボーダーの引数では基準座標からスクロール開始までの左右の幅。
それはある程度わかってました。
で、オフセットがスクロール量ということで、最初は０を入れていたから
左端から始まっていた。そうですよね？
そこの数値を大きく変えれば、右端から始まると私は思いました。
でも、違った！
一瞬だけ、右端が表示され、すぐに左端になるんです。
で、playerを動かせば、playerの位置まで画面がすっとんでいくんです。

一体どうすれば、右端のプレイヤーに合わせたところから始まってくれるんですか？
私のことを考えて、ストレートに答えを教えてくれないのだと思いますが
何度も質問することになりますし、もうトレースチャレンジトレースチャレンジで
ヘトヘトです。自分がどう間違っているのか、なぜ右端から素直に始まってくれないのか、
教えて下さいませんか？

[土門]

ISLeさん
サンプルでは問題なく右端から始めることに成功しました。
引数に与える数値は自分のものと同じものを渡してみての成功なので
どうやらこれは自分のカメラオブジェクトclassの内容？で
ミスをおかしているようです。
ただ、変えているとすればシングルトンにするので、コンストラクタでは無く
初期化関数を作り、そこで初期化をさせていること。
ステージclassのコンストラクタででそのカメラの初期化を行っていること。
あとは、今は移植テスト中ということで
カメラclassにプレイヤーの座標をもらう変数をつくり
プレイヤーは移動とともにその変数へ値を送っていること。
（もちろん、ふさわしくないつながりなのは承知してます）
これくらいです。

とりあえず、初期化のスクロール量を０からいくらに変更しようが
画面がまず、左端を表示させてしまうのです。
そのあと、playerのいる場所に飛ぶ、という感じです。
ISLeさんのサンプルでは、スクロール量の初期化を変更することによって
表示開始の画面の場所を任意に決められますが
自分のでは、それが出来ない状態、だということです。
移植が出来ていない、いや、理解してないから移植に失敗するんですよね。
ほんと自分の理解の無さ、頭の悪さが悔しいです。
ここまで近づければ、なんとかやれそうです。
これさえクリアすれば、今回のゲームはもう手間を残すだけです。
なので質問はいい加減にします。ありがとうございました。

ここから余談で申し訳ありませんが
ISLeさんとのやり取りでよく思い出すことがあります。
十代の頃、車の免許を取りにいったときのことです。
実技の教習中、まだ仮免すら受けてない状態でしたが、
私の運転技術がままならないのかなんなのか
自分よりも小さな爺さんの教官に
「お前は下手くそすぎる、センスが無い。マニュアル辞めて、オートマにしろ」と
冷たく言われました。
初対面では笑顔を見せていた爺さんでしたが、
何度かかかわるうちに笑顔は消えてしまっていました。
その時、まだ運転というものがよくわからないガキでしたので
自分は向いてないのだとてもショックを受け、悔しかったことを覚えています。
何の因果か、その爺さんが担当になってしまい、
来る日も来る日も愚痴を言われることとなりました。
ミスをしてふいにちょっとブレーキを踏もうものなら
体を大げさに揺らし、「なんて運転してんだ、この下手くそ」と私をにらむんです。
そんなある日、ついに私の相手に疲れたのか
爺さんは私の担当を外れてしまいました。
私はその日から空きのある教官に教わるようになりました。
いろんな教官に教わる中で、自分の運転技術は向上していき、
仮免の試験はヒヤっとしたりもしましたが無事に合格、結局最終試験も一回で合格しました。
あれから７年は過ぎ、私も車を所持し、マニュアルもオートマも乗る機会がありますが
無事故でやって来ています。性格のおかげもあり、安全運転です。
わざわざ言うことでも無いですが、駐車も問題ありません。
ついでに自動二輪の免許も持っています。

なにが言いたいのかというと、私はあの時、あの教官にボロカスに言われて
そうとう凹みましたが、その時マニュアルからオートマに逃げなくてよかった、
強いては、教習所通うことから逃げなくてよかったと今でも思っています。
（振り返れば、自分がやろうとすることを否定されることは
生きていれば、たまにあることでその否定される理由も様々ですが、
それでも突き進んだ場合、結構良い結果を出すことが多かったです）

私は典型な右脳型の絵描きで頭も悪いんで
プログラマには向いてないと心底自覚しています。
プログラムは車の運転と比べようにならないくらい
難しいものだとわかってもいます。
飯食おうなどと考えているわけでなく、あくまで趣味でやろうとしている分際ですが、
プログラムを覚えようと決めた時から自分が苦しむことになるのも
覚悟しておりました。独学ですし、、、。
（それでも、やらねばならぬ理由が自分にはあるのです）

で、ISLeさんとのやり取りで悔しい思いを何度もしたせいか、
その教習所のことを思い出していました。
ISLeさんがその教官と同じだと言いたいわけではありません、
多分、何度も何度も尋ね、理解が出来ない自分は
その教官が思っているようなことをISLeさんに思わせてしまっているのだろうとは
思っていますが。
言いたいことは、自分はここで凹んで投げるようなこと無く、
それでも頑張るしかないと思っています、ということです。
ISLeさんに教わったことは逃げずに血や肉にしてみせます。
ありがとうございました。

副管理人さんへ
ISLeさん以外のレスが無いところを見るに
他の皆さんにも気を遣わせてしまっているので
（ISLeさんばかりにレス頂くのも悪いですし）
またこちらで相談したいときは心機一転
名前を変えて投稿したいと思います。
あと、アドバイスもありがとうございました。

[土門]

あ、一応解決ということにしときます。

[ISLe]

現状を具体的に教えてもらわないと回答のしようがありません。
わたしは推理ゲームを楽しみたいわけではないのです。

コード:

#include "DxLib.h"
 
class Scroll {
    int ofs_x;
    int left;
    int right;
    int left_end;
    int right_end;
public:
    Scroll(int l, int r) : left(l), left_end(l), right(r), right_end(r), ofs_x(0) {}
    void setBorder(int l, int r) { left = l; right = r; }
    void scroll(int ref_x) {
        int x = ref_x - ofs_x;
        if (x < left) {
            int d = (left - x)/3;
            if (d <= 0) d = 1;
            ofs_x -= d;
            if (ofs_x < left_end) ofs_x = left_end;
        }
        if (x > right) {
            int d = (x - right)/3;
            if (d <= 0) d = 1;
            ofs_x += d;
            if (ofs_x > right_end) ofs_x = right_end;
        }
    }
    int getOffsetX() { return ofs_x; }
    void setOffsetX(int x) { ofs_x = x; } // ※追加
};
 
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
    int image[16];
    char key[256];
    struct Player {
        int x;
        int dir;
    } player = { 0, 3 };
    ChangeWindowMode(TRUE);
    if (DxLib_Init() != 0) return 0;
    SetDrawScreen(DX_SCREEN_BACK);
    LoadDivGraph("char.png", 16, 4, 4, 32, 32, image);
 
    Scroll scroll(0, 640); // スクロールを停止する左右のオフセット
    scroll.setBorder(32*6, 640-32*6); // 基準座標を収める範囲

	// ※左端から始める
    player.x = 1280-32;
    player.dir = 1;
    scroll.setOffsetX(1280-640);
 
    while (ProcessMessage() == 0 && ScreenFlip() == 0 && ClearDrawScreen() == 0 && GetHitKeyStateAll(key) == 0) {
        if (key[KEY_INPUT_LEFT] == 1) {
            player.dir = 1;
            player.x-=2;
            if (player.x < 0) {
                player.x = 0;
            }
        }
        if (key[KEY_INPUT_RIGHT] == 1) {
            player.dir = 3;
            player.x+=2;
            if (player.x > 1280-32) {
                player.x = 1280-32;
            }
        }
        int ofs_x = 0;
        if (key[KEY_INPUT_Z] == 0) {
            // Zキーを押していないときはキャラの中心が基準
            // ふつうに画面の端に行くとスクロールする
            scroll.scroll(player.x+16);
        } else {
            // Zキーを押しているときはキャラの進行方向へ一定の距離が基準
            // キャラの前方を広く取ったままスクロールし振り返ると…
            if (player.dir == 1) {
                scroll.scroll(player.x+16-32*8);
            }
            if (player.dir == 3) {
                scroll.scroll(player.x+16+32*8);
            }
        }
        ofs_x = -scroll.getOffsetX();
 
        for (int x=0; x<1280; x+=32) {
            DrawBox(ofs_x+x, (480-32)/2, ofs_x+x+32, (480-32)/2+32, GetColor(255,255,255), FALSE);
        }
        DrawGraph(ofs_x+player.x, (480-32)/2, image[(player.dir)*4+((player.x/2)%4)], TRUE);
    }
    
    DxLib_End();
    return 0;
}

[ISLe]

ブレークポイントを張るなどして、設定した初期値がリセットされてしまう箇所を特定すれば良いと思いますが。


わたしも右脳人間だと思います。
プログラムを作る前はメモ用紙やノートにたくさん図を書いてイメージしますしね。
コードを書くのが嫌いなのでギリギリまでコードを書かないです。
いつもできるだけコードを書かないで済ますことばかり考えています。
わたしの書くコードはほとんどパターン化されたコードの使い回しです。

独学なのも同じです。
わたしはプログラミングに関連する教育は一切受けていません。


ひとつやふたつ交通ルールを知らなくても免許は取れます。
極端な話、赤信号は停止だと知らないひとでも公道を走っている可能性があるわけです。
わたしは自動車運転免許を持っていますができれば公道を車で走ることは避けたいと思っていますし、実際そうしています。
そういった割り切り方の違いが出るのかもしれませんね。

割り切りができるかどうかの問題なので、センスとか性格を言い訳にして逃げてはいけません。
余計に自分を追い詰めるだけです。
実際わたしは細かいところにこだわって先へ進めない性格ですが、プログラミングに関しては割り切り方を覚えて改善しました。
他のことに関してはあいかわらずですが。
改善しないまま規模の大きいプログラムを作るようになるとあちこち気になって仕方が無くなって精神にきますよ。

[softya（ソフト屋)]

何度が書かせてもらいましたが、こちらの提案が受け入れられる気配（図を書いたほうが良いとか、クラス設計をしてから組んだほうが良いとか）が無いので、ISLeさんの指導が受けたいのかと思って見るだけとさせていただいていました。ISLeさんの内容と混乱させてもマズイと思いましたので。

今までのやり取りの感想から言えば、基礎的な所を飛ばしていきなり本物の実装に手をつけてはバグにはまっている印象が有るので、もっと組み込みの仕方を考えたほうが良いと思いますが如何でしょうか？　スクロール実験プログラムとか、小型のもので完成させてから本物に組み込んでも遅くないと思います。　回り道に見えるでしょうが、そのほうがずっと早くケリがつくことが多いです。
小型のプログラムなら、実物を見せやすいのでアドバイスももらいやすいです。ISLeさんも、かなり想像を働かせて苦労して回答されていたと思います。
※　この想像の部分が個人事に違う可能性が高いのでうっかり口を挟めないのです。つまり、簡単なソースコードがあれば他の人も口が出せた可能性が高いと私は思います。
掲示板の意思疎通は難しいですが簡単にする方法はあります。それが図やコードの実物だと私は思うわけです。それも土門さん自身が提示しないと意味が無いのです。

あと名前を変えても文体や内容などで大体は同じ人だと分かりますので、同じ名前のままで質問された方が良いと思います。

[usao]

あ，解決チェックついてる！　ってことで覗いてみたのですが
なんか解決したのかどうかよくわからない雰囲気…？

この件については口を挟まないと決めた以上，私からは今も今後も何も言いませんが
ひそかに応援はしています．頑張ってください．

[土門]

ISLeさん
>割り切りができるかどうかの問題なので、
>センスとか性格を言い訳にして逃げてはいけません。
>改善しないまま規模の大きいプログラムを作るようになると
>あちこち気になって仕方が無くなって精神にきますよ。

本当に自分は向いてないと思っていますので
ダメな時の言い訳にしないのも難しい話なのですが
でもそうですね、今後は
その辺を改善するように意識していくことにします。
色々勉強になりました、ありがとうございます。
今回は若輩者でかなりご迷惑をかけてしましたが、
また質問をさせて頂いたときには
ISLeさんからもぜひご教示頂ければと
自分は願っておりますので、お手間でなければ
よろしくお願い致します。
あとスクロールの問題はちゃんと解決致しました。
（自分のしょーもないミスでした）
ありがとうございました。

softya（ソフト屋)さん
>何度が書かせてもらいましたが、

はい、副管理人さんのアドバイスを
ちょっとスルーする形になってしまい、すみませんでした。
が、無視では無く、頭の中で保留させて頂いておりました。

>図を書いたほうが良いとか、クラス設計をしてから組んだほうが良いとか

なぜなら、実は正直そのようなものを
相手に伝えられるレベルで書く術をまだ持っておりません。
仮にそれをしようと思ったら勉強が必要になるでしょう。
今、同時にやることをいくつも抱えると自分のキャパでは
パンクしてしまうので保留してしまいました、すみません。
あと本意では無いのですが、ひとつひとつのゲーム制作において
自分の中で期限を設けていますので
基本であるはずのその辺のこともどうしても生半可なところで
前に進めています。よくないとわかっております。
しかし実際「ゲーム制作」においての
その基本(class設計や図の書き方？)をわかりやすく解説、
または叩き込んでくれるサイトって見たこと無く、
やはりどこもプログラムソースありきですので
自分もこんな感じで進めてしまっている感じですね。
でも一応目指すにあたり、プログラム関連の資格をいくつか取りましたので
一般人よりは基本知識は入っていますが、、、
でも所詮は資格のための勉強だったな、と
もうほとんどを忘れちゃいますね、
やっぱプログラムは打ってなんぼ、だなと
今は実感しております。

あと、プログラムにおいては
今のところきれいごとにしか聞こえませんが、
本来プログラム設計に着手するときには
決めなければならないもののすべてはすでに決まり終えている、
というのが理想なんですよね？
しかし特にゲームプログラムにおいてはそう簡単にはいかない。
ファミコンゲームが流行っていた当時の制作現場の
人間からしたら完璧な仕様書なんて無くて当たり前、くらいの状態だとか。
ある程度までのイメージでスタートするのもザラ、
より面白くするために途中仕様がコロコロ変わるのもザラ、だと。
あくまでその人の現場がそうだっただけなのかもしりませんが
これは自分も想像に難しくありません。
なので自分の中ではまだ紙に書き出すための知識、技術に対して
必要に迫られている感じがありません。
でももちろん効率面でないがしろには出来ないと理解していますので
いずれはちゃんと勉強していきたいと思っております。
(とても勉強になるサイトをご存じでありましたらぜひ教えて頂ければ嬉しいです)

＞基礎的な所を飛ばしていきなり本物の実装に手をつけてはバグにはまっている印象が有るので

まったくその通りですね、、、でも
自分は資格試験用の小さなプログラムを作って学んでいた時期より
ゲームをドカンと作ったほうが理解し、楽しめ、成長出来たのも事実です
(ちなみに今回取りかかっているのは三作目になります）。
もちろん、今なら小さなプログラムも楽しめそうだし、
本来ならばそちらのほうが効率的なはずですし、
初心に戻り、次回からは副管理人さんの言う通り、
まず、小さなプログラムから進めるつもりです。

＞小型のプログラムなら、実物を見せやすいのでアドバイスももらいやすいです

はい、そういうことですよね。

＞あと名前を変えても文体や内容などで大体は同じ人だと分かりますので、
＞同じ名前のままで質問された方が良いと思います。

そうですね、副管理人さんにはその辺筒抜けだと思いますし
込み入った質問のやりとりをすれば関わった方々にも自分だとわかるとも思いますので
ご迷惑にならなそうであれば自分のままで今後も質問させて頂ければと思いますが
まあ同じ質問を何度もする問題児っぽいレッテルも貼られてしまったでしょうし
「またお前かよ、関わりたくないよ」と質問をスルーされてもあまりに悲しいので
得に２、３レスで終わるであろう些細な質問は無機質に捨て名のがいいかもと思っています。
まあその時その時で自分なりに周りに迷惑の掛からないよう考慮したいと思います。

usaoさん
最後まで気にかけて頂きありがとうございます。
そして色々ご迷惑をおかけしてすみませんでした。
今後もプログラムはがんばっていきますので、
またこちらで相談させて頂いたときは
お手間でなければ遠慮なくご教示ください。

[softya（ソフト屋)]

今回の場合だとクラス図他は、他の人にイメージを伝えるために描きます。
つまり、質問でイメージを伝えやすくするために必要です。
面倒に思えるかもしれませんが、これまでの質問と回答のやり取りの大半はイメージが伝わっていない故に勘違いしていることさえ伝わっていないと言うのが大半だった思います。　それを解消する為の手段です。　言葉を１００書くよりも図一つのほうが伝わるものがあります。
あと、はじめないと何時まで経っても上達しないので、うまく書けないからを理由にしていると何時までも出来ません。下手でもいいです。ご自身のイメージの整理にもなるので損はありません。

[土門]

＞質問でイメージを伝えやすくするために必要です。
＞言葉を１００書くよりも図一つのほうが伝わるものがあります。

はい、その通りだと思います。
どういう風に書けばいいのかまだちょっとよくわかりませんが
避けていても話にならないので
今後はその辺も意識して
図を用いたほうが効率良い場合は
下手でも図で説明するように努めてみます。
ありがとうございます。

[ISLe]

しかし特にゲームプログラムにおいてはそう簡単にはいかない。
ファミコンゲームが流行っていた当時の制作現場の
人間からしたら完璧な仕様書なんて無くて当たり前、くらいの状態だとか。
ある程度までのイメージでスタートするのもザラ、
より面白くするために途中仕様がコロコロ変わるのもザラ、だと。
あくまでその人の現場がそうだっただけなのかもしりませんが
これは自分も想像に難しくありません。
なので自分の中ではまだ紙に書き出すための知識、技術に対して
必要に迫られている感じがありません。

そういうのは必要ないからやらなかったのではなく、時間的余裕が無いとかの外部要因です。
著名なゲームでは全体の仕様書はなくてもプログラマがイメージボード的な資料をたくさん作っていたりします。
やらなくて良い理由にはなりません。

当たり前に当たり前のことができたとき、多くのひとはわざわざ誰かに伝えようとはしません。
当たり前に当たり前のことができなかったとき、多くのひとが誰かに伝えようとします。
この掲示板にはプログラムの質問をするひとばかりいます(当然)が、世の中自力でプログラムできないひとばかりではありません。

まったくその通りですね、、、でも
自分は資格試験用の小さなプログラムを作って学んでいた時期より
ゲームをドカンと作ったほうが理解し、楽しめ、成長出来たのも事実です
(ちなみに今回取りかかっているのは三作目になります）。
もちろん、今なら小さなプログラムも楽しめそうだし、
本来ならばそちらのほうが効率的なはずですし、
初心に戻り、次回からは副管理人さんの言う通り、
まず、小さなプログラムから進めるつもりです。

softyaさんがおっしゃっているのはそういうことではないと思います。
小さいプログラムというのは、プログラムを細かく分解してモジュール化するのが主目的のはずです。
同じ内容のことはわたしも繰り返し書いてますよ。
前提を無くせ、と。

小規模のモジュールごとにテストを行って組み立てていくのはいわゆるアジャイル開発手法です。
「ゲーム制作」における特別な開発手法なんてものは存在しません。
わたしはエンタープライズ系のニュースサイトや技術サイトを巡って知識を得ています。
ちなみにエンタープライズ系サイトにゲーム開発の情報が掲載されることも少なくないです。

いまの世の中の開発者の多くがそれを必要だと思っていますから、探せば図を描くツールはいくらでも見付かります。
Gliffy

[softya（ソフト屋)]

まったくその通りですね、、、でも
自分は資格試験用の小さなプログラムを作って学んでいた時期より
ゲームをドカンと作ったほうが理解し、楽しめ、成長出来たのも事実です
(ちなみに今回取りかかっているのは三作目になります）。
もちろん、今なら小さなプログラムも楽しめそうだし、
本来ならばそちらのほうが効率的なはずですし、
初心に戻り、次回からは副管理人さんの言う通り、
まず、小さなプログラムから進めるつもりです。

【コピペ間違ったので修正】

あっと、土門さんに勘違いされていたんですね。
大きなプログラムは小さなプログラムの寄せ集まったもので、小さな単位で動作確認できいないものを大きなものに組み込んでも混乱し、確認が大変になると言いたかった訳です。逆に小さな単位ではテストは容易です。
小さいな単位で動作確認したものを大きな単位に組み込めば、より容易に開発ができるようになります。問題点の切り分けが簡単になりますから。
つまり、今の開発方法は非常に効率が悪いと言いたいんです。
時間がない時間がないと書かれていますが、開発方針自体が時間を食いつぶしていると思います。

[ISLe]

そもそもゲーム制作というゴールもコースも明確で無いものに純粋なウォーターフォール型の勉強法は通用しないですよね。
例えば警察官になるための勉強と警察官が職務を全うするための勉強は違いますよね。
プログラミングというのはプログラマが職務を全うすることですよね。
じゃあプログラミングができるようになるための勉強ってなんでしょうね。

どこもプログラムソースありきとおっしゃいますが、ソースコードから設計意図を想像することはできます。
機能の持たせ方や名前の付け方などを想像して当たったり外れたり理由を考えてみたりを繰り返して的中率を上げていくと、いろんなことを効率良くできるようになります。
設計にもコーディングにも影響しますがどちらともそのものではない。
着眼点とでも言うのでしょうか。
これこそが基本ではないかと思います。

わたしがサンプルコードを提示すると土門さんは常に「自分のコードに組み込むと期待通りに動かないのはどうしてか」と返信されました。
「(サンプルコードで)この引数はどういう値を設定しているのか」というふうに尋ねられることはありませんでした。
これは、設計意図には考えが及ばず実装しか見えていないことのあらわれだと思います。

[ISLe]

すみません。もう一つ気になった点。

あと、プログラムにおいては
今のところきれいごとにしか聞こえませんが、
本来プログラム設計に着手するときには
決めなければならないもののすべてはすでに決まり終えている、
というのが理想なんですよね？

そもそも『決めなければならないもののすべて』が表す範囲がこちらと土門さんで異なっていると思います。

例えばシューティングゲームのユーザー入力モジュールを作るとき、
・ボタンの押下状態は、第0ビットから第3ビットまでを上下左右、第4ビットをショット、第5ビットをボム、を反映したint値にて
・それを取得するメソッドを用意する
といった程度が『決めなければならないもののすべて』です。
あとは自由に、です。

前スレのマップのときも、アイテムもトラップもダメージとして統一すれば同じインターフェースにできるということを書きましたよね。
キャラが移動するときに必要なマップの情報は、移動できるかどうか、だと書きましたよね。

[土門]

＞小さいプログラムというのは、
＞プログラムを細かく分解してモジュール化するのが主目的のはずです。

＞小さな単位で動作確認できいないものを大きなものに組み込んでも混乱し、
＞確認が大変になると言いたかった訳です。

そういうことですね
お二人のおっしゃる通りだと思います。

＞小さいな単位で動作確認したものを大きな単位に組み込めば、
＞より容易に開発ができるようになります。
＞問題点の切り分けが簡単になりますから。
＞つまり、今の開発方法は非常に効率が悪いと言いたいんです。
＞開発方針自体が時間を食いつぶしていると思います。

その通りです、
その辺はほんと自分でも
わかっております。
次は細分化させ、ひとつひとつを小さなプログラムで作り
理解してから合わせようと思います。

＞前提を無くせ、

これ、もう耳にタコが出来るくらい
言われてしまっています。
これだけ言われていますので
今でこそ毎日頭で意識するようになっていますが
そういった概念？を解説した「ゲームプログラム」の書籍やサイトを
自分はまだ見た事がなかったので、結構悩ませる種となってます。
要は、完全オブジェクト指向、個々の独立性を上げろ、
ということだと思うのですが
すべてのクラスに前提がいらない状態とかあり得るのかな、とか
まだまだ疑問に思うことはあります。
が、以前よりも前提を無くすことは出来ましたし、
そうしようとする思考になりましたので
きっと今後制作を重ねるごとに成長出来ると思っています。

[土門]

＞ソースコードから設計意図を想像することはできます。

はい、自分はそういうところに意識がいってなかったので
今後は意識するようにしたいと思います。

ただ、効率は悪かったですが、ゲームを完成させるたびに
制作するための知識や技術力が上がっているのは
実感出来ていますので

＞機能の持たせ方や名前の付け方などを想像して当たったり外れたり
＞理由を考えてみたりを繰り返して的中率を上げていくと、
＞いろんなことを効率良くできるようになります。

に近いような経験は、一応出来ていると思っています。

＞わたしがサンプルコードを提示すると土門さんは常に
＞「自分のコードに組み込むと期待通りに動かないのはどうしてか」と返信されました。
＞「(サンプルコードで)この引数はどういう値を設定しているのか」
＞というふうに尋ねられることはありませんでした。
＞これは、設計意図には考えが及ばず実装しか見えていないことのあらわれだと思います。

確かに、設計意図までを意識するには及んでいませんが、
ここは引数になにを持って来ているのか、くらいはその都度
考えたりしてました。それくらいはさすがに。
ただ、部分部分で見て全体の流れを見れなかったというか、
つまり、木を見て森を見ることはしてなかったように思います。

＞例えばシューティングゲームのユーザー入力モジュールを作るとき、
＞・ボタンの押下状態は、第0ビットから第3ビットまでを上下左右、第4ビットをショット、第5ビットをボム、を反映したint値にて
＞・それを取得するメソッドを用意する
＞といった程度が『決めなければならないもののすべて』です。

平たくいうと各クラスのメンバ変数にメンバ関数、
そしてその役割ってことですよね？
正直、まだそれも難しいです、作る前にそれらをすべて決めてかかるのも。
頭にはある程度描いてますが、やはり変わってくるものですし、
打ちながらに「こっちのがいいかも」とかすぐ思いつきますし。
要は、練りに練ってない状態で発進してるってことなんですけど。。。
まあまったくなにもなく、進めているわけではありません。
こんな感じで動かそう、それには変数はこれと、関数がこれだけいるかな、
といったアバウトな状態でクラスを作り始めたりはします。
つたない部分はほんといくらでもありますが、
まだプログラムに関わって１年と３ヶ月くらい、
最初の８ヶ月ほどは資格試験のための勉強でしたから
ゲームプログラムを打ち始めては一年も経っていませんので
熟練の方々の言葉の中には
ほんとわけわからないものがまだまだあります。
ほんと頭抱えてます。
（まあ熟練の方々のいうことをすぐ理解し実行出来たら苦労しません）
副管理人さんの言葉を借りるなら、
わかりやすく図で説明して頂けないでしょうか？です。
（もちろん、そんな立場では無いので言いません）

とにかく今回は皆様のおかげで本当にいろいろ勉強になりました。
今後の制作においては今回言われるようなことに目を向けながら
取り組んでみたいと思います。
そういう意味で、今のゲームが完成し、
次のゲームに取りかかるのが楽しみになりました。
ありがとうございます。

[ISLe]

＞例えばシューティングゲームのユーザー入力モジュールを作るとき、
＞・ボタンの押下状態は、第0ビットから第3ビットまでを上下左右、第4ビットをショット、第5ビットをボム、を反映したint値にて
＞・それを取得するメソッドを用意する
＞といった程度が『決めなければならないもののすべて』です。

平たくいうと各クラスのメンバ変数にメンバ関数、
そしてその役割ってことですよね？

違います。
設計時にクラスの中身を気にかける必要はまったくありません。

わたしが書いたのは、例えば
int InputModule::getInputStates();
というふうなメソッドをを用意することと、戻り値の内容です。

あらかじめ決めておかないといけないのは、他のモジュールとやりとりする部分です。
影響範囲が違いますから。

正直、まだそれも難しいです、作る前にそれらをすべて決めてかかるのも。
頭にはある程度描いてますが、やはり変わってくるものですし、
打ちながらに「こっちのがいいかも」とかすぐ思いつきますし。
要は、練りに練ってない状態で発進してるってことなんですけど。。。

外部とやりとりする部分を絞ってあらかじめ決めてしまうことで内部は隠蔽されます。
隠蔽されたクラスの中身は後からいくらでも好きなだけいじくり回せます。

設計において、クラスの中身は、練ってる練ってないなど関係なく、考慮する必要がまったくありません。
実装を同時に考えることは多いですが、設計と実装は互いに干渉しません。

まあまったくなにもなく、進めているわけではありません。
こんな感じで動かそう、それには変数はこれと、関数がこれだけいるかな、
といったアバウトな状態でクラスを作り始めたりはします。

わたしも作り始めは同じようなものです。
ですが、作り始めでも完成間近でもクラスの中身をいくらいじり返そうが他のソースコードを変更する必要はありません。

わかりやすく図で説明して頂けないでしょうか？です。
（もちろん、そんな立場では無いので言いません）

何を図で表すかという段階なので図を見たところでピンとこないと思いますけど。
またもや前のスレの話で申し訳無いですが、移動できるかどうか判断する処理で必要なのは、そのマスに移動できるどうかを返すメソッドです。
どうやってそのマスに移動できるかどうかを判断するかなんてことは設計段階で考える必要ありません。
前のスレに「移動できるかどうか分かれば良いので2次元配列である必要はない」ということを後から書きました。
2次元配列の実装が先にあったので設計と実装の順序が逆になってしまったのですが。

移動できるかどうか判断するために必要なのは移動できるどうかを返すメソッドだとだけ考えることは難しいことでしょうか。

[ISLe]

今回のスクロール関係はシンプル過ぎるので、前スレの移動処理関係を図にしてみました。

CharacterManagerが下位のクラスに委譲する形になります。
マップに配置するオブジェクトは全部ひとつのクラスにまとめて継承できると思います。
まとめられなかったとしても若干派生が増えるだけなはずなのでたいして複雑にはならないでしょう。

classes.png (10.94 KiB) 閲覧数: 10174 回

#綴り間違えました。すみません。

[土門]

ISLeさん

回答と画像まで用意してくださってありがとうございます。
ここずっと制作中のゲームの肉付けに取り掛かっているのですが
内容が増すごとにISLeさんのいうことが理解出来ているように思います。
というのも、ゲームにおいて、今までのイメージでは
シーンの中やシーンの転換には
常に様々なオブジェクトの状況が影響を及ぼし、
また、オブジェクト同士も常にお互いの状況を意識しあっていたりしてて
それをそのままプログラムに落として考えていたんですが、
今回のことで、プログラムを考える上では
それらオブジェクトたちを直接絡み合わせるんじゃなくて、
すべてのオブジェクトの状況を把握しているclassを作り、
皆がそのclassに自分の情報を与えながら動いている。
そして、そのclassからの指示で、自分がどうすべきかを判断していく。
つまり、オブジェクトたちはお互いの存在すら知らない状態で個々の目的を遂行し続けるだけ。
そういう状態にしてやるわけですよね？
その方が作るにも、考えるにも、とてもラクであることが
理解出来、付け足すものは勝手に頭がそうするようになってきました。

＞あらかじめ決めておかないといけないのは、他のモジュールとやりとりする部分です。

つまりこれですよね。
最初にそれら軸をシッカリ決めておくことが大事、ということですよね？
（「いえ、そう言いたいわけでは無く～」とか、また言われたらどうしよう＾＾；）
これもISLeさんのおかげです。

＞移動処理関係を図にしてみました。

あー、なるほどです。
これは、単純に言えば、各classの繫がりを書けということですか？
なんとなくイメージが出来ました、ありがとうございます。

[ISLe]

つまり、オブジェクトたちはお互いの存在すら知らない状態で個々の目的を遂行し続けるだけ。
そういう状態にしてやるわけですよね？
その方が作るにも、考えるにも、とてもラクであることが
理解出来、付け足すものは勝手に頭がそうするようになってきました。

素晴らしいですね。
しっかり身に染み付いたようで。

全体も細かいところも同じように見ることができるようになっているはずなので、規模の大きいプログラムでも開発効率が飛躍的に上がっていくと思います。
よりコンテンツの中身に注力できるようになります。

〇〇するために〇〇できるか判断するメソッド～のように当たり前に持っていくのは、抽象化にあたります。
いろんなことを当たり前にしていくといちいち考える必要がなくなるので設計も楽になります。

ゲーム制作頑張ってください。
いっぱい楽して中身の濃いものにしてください。