C/C++ゲーム製作総合スレッド Part5

**名前は開発中のものです。** · 2014/01/16(木) 00:00:31.27

ゲーム製作におけるC/C++全般に関するスレです。

元スレ
DXライブラリ総合スレッドその17
http://toro.2ch.net/test/read.cgi/gamedev/1383795645/

前スレ
C/C++ゲーム製作総合スレッド Part1
http://toro.2ch.net/test/read.cgi/gamedev/1337516528/
C/C++ゲーム製作総合スレッド Part2
http://toro.2ch.net/test/read.cgi/gamedev/1351015269/
C/C++ゲーム製作総合スレッド Part3
http://toro.2ch.net/test/read.cgi/gamedev/1357899040/
C/C++ゲーム製作総合スレッド Part4
http://toro.2ch.net/test/read.cgi/gamedev/1376262450/

**名前は開発中のものです。** · 2014/03/27(木) 12:56:33.60

>>436

まじか。
想定されるオブジェクトの個数というのは重要な情報だと思ってるんだが、他の人はそうじゃないのか。
1個でも42億個でも対応できるようなやり方を毎回してるの？
100個って書いてあったらだいたい100個くらいを想定してるんだと思うのが普通だと思うが、そうでもないんだなぁ。

**名前は開発中のものです。** · 2014/03/27(木) 12:59:39.14

そもそもプログラム組める奴が434みたいな的はずれなこと言い出す訳がないわけで…
つまり、相手するなカス荒れるから

**名前は開発中のものです。** · 2014/03/27(木) 13:17:49.49

膨大な数のループを使う判定は書けるんだからさらに増えたらどうすんのって質問でしょ

**名前は開発中のものです。** · 2014/03/27(木) 14:43:18.93

>ここを10000個とでも書かないと分からんの？アホだろｗ

２Ｄの当たり判定の処理は軽いから、マンコでも同じ事。　やってみ

**名前は開発中のものです。** · 2014/03/27(木) 15:10:53.94

話変わって悪いけど、レースゲームで車が高速移動しすぎて当たり判定が出来ない場合ってどうすればいいの？

**名前は開発中のものです。** · 2014/03/27(木) 15:51:52.80

>>441
1ループあたりの移動速度を半分にして、ループ数を2倍回す。

**名前は開発中のものです。** · 2014/03/27(木) 19:51:32.13

>>441
現在フレームをnとした場合、n-1フレームの情報を保持しておいて、nフレームとの線分を引く。
あるいは現在の位置と速度から予測されるn+1の未来予測位置とnフレームとの線分を引く。
この線分が障害物と接触していたら接触した際の処理へ移行するように書いておく。

**名前は開発中のものです。** · 2014/03/27(木) 20:07:57.55

>>440

PCスペックを限定してないのにその回答は無意味だってば。

**名前は開発中のものです。** · 2014/03/27(木) 21:19:31.28

たとえ、 2MHz Z80であっても、ディスプレイは40x25のキャラクタ画面だから大丈夫だよ

**名前は開発中のものです。** · 2014/03/27(木) 22:05:12.78

40*25のテキストエリアで10000個のキャラクター動かすのかｗ

**名前は開発中のものです。** · 2014/03/28(金) 00:17:11.93

>>442
大丈夫かよ…

**名前は開発中のものです。** · 2014/03/28(金) 00:45:18.83

>>447
俺は>>442じゃないけど大丈夫だと思う、むしろよくある手法じゃない？
アクションの通信対戦で処理落ちする時の同期なんかで使われるのも似たようなやり方あるし

**名前は開発中のものです。** · 2014/03/28(金) 00:52:56.05

一時期の同人げーって処理落ちしまくりで
「こいつら良いマシンで開発してるんだな…」って嫉妬してたｗ

最近はPCの性能頭打ちでそういうのなくなったからいいよねｗｗ

**名前は開発中のものです。** · 2014/03/28(金) 00:56:09.52

>>447
スレチかもしれんがUnityの物理演算部分の判定は秒間1000ループが推奨されてるんだからわりと平気なんじゃね？

**名前は開発中のものです。** · 2014/03/28(金) 12:11:43.53

>>441
Point before, after; // 前回の座標、今回の座標
int count = 8;
int ix = (after.x - before.x) / count;
int iy = (after.y - before.y) / count;

Point pos;
pos.x = before.x;
pos.y = before.y;

for(int i=0; i<=count; i++){
bool is = collision(pos.x, pos.y); // 当たり判定
if(is) break;
pos.x += ix;
pos.y += iy;
}

count, ix, iyの値をもう少しきちんと平方根使って計ったほうがいいけど

**名前は開発中のものです。** · 2014/03/28(金) 12:15:19.93

>>451はお絵描きソフトなんかでよく使うんじゃないかな
60fpsでマウス判定じゃ全然足りなくて線が破線になるし

**名前は開発中のものです。** · 2014/03/28(金) 13:16:45.63

お絵かきならスプライン補間とかだろ2次元だとカクカクの直線になるぞ
あとそれバグ持ちだな

**名前は開発中のものです。** · 2014/03/28(金) 22:13:02.97

Windows APIにDirectXが搭載されたならいい加減にウィンドウ生成とかDirectXの初期化とかどんなジャンルでも必要なゲームエンジンの要素とか短縮しねえかな
コピペとはいえ毎回見るのが嫌になってくるよな
ライブラリとかラッパー使えば済むんだろうけど理解するのは面倒だし

**名前は開発中のものです。** · 2014/03/28(金) 22:28:44.11

>>454
会社では無理だけど自分で作るようなら短縮用のヘッダーと関数とか自作しない
理解すればいろいろと便利だし

**名前は開発中のものです。** · 2014/03/29(土) 09:51:35.35

ウィンドウ周りは自分で適当にラッパー作ったな
都度調べてコピペするより精神衛生的に良い

**名前は開発中のものです。** · 2014/03/29(土) 13:22:18.51

さもありなん。
老害にはコードスニペットの概念がないからなぁ。

**名前は開発中のものです。** · 2014/03/29(土) 21:21:25.19

毎回書くような所だけ書いたプロジェクト作ってテンプレートとして登録しとけばいいんじゃないの

**名前は開発中のものです。** · 2014/03/29(土) 21:48:25.68

そしてそのテンプレートが、ゲームを作るたびに更新されていく

**名前は開発中のものです。** · 2014/03/30(日) 00:08:10.54

win32APIで別のプログラムを呼び出したいです
system関数は使ってみたんですがdos窓も一緒に出てきてしまいます

**名前は開発中のものです。** · 2014/03/30(日) 00:14:44.76

>>460
CreateProcessだとDOS窓出なかった気がする

**460** · 2014/03/30(日) 01:27:38.78

ドンピシャでした
ありがとうございます

**名前は開発中のものです。** · 2014/04/01(火) 17:00:08.51

>459
これありすぎて吹く

**名前は開発中のものです。** · 2014/04/01(火) 17:13:22.13

俺もテンプレートってほどいいものじゃないけど
「今回作ったシステム流用すればいくらでもゲーム作れるぜ！：
と毎回思うんだけど、毎回まるまる作り直してるという……。

**名前は開発中のものです。** · 2014/04/02(水) 10:41:39.05

自分で作った3Dゲームにめちゃくちゃ酔うんだけど、比較的酔いにくくする方法ってある？

**名前は開発中のものです。** · 2014/04/02(水) 11:13:17.38

>>465 ちょっと、見せてみ

**名前は開発中のものです。** · 2014/04/02(水) 12:36:37.68

>>465
別にそういう専門知識もってないから経験則になるけど。

酔いやすい人と酔いにくい人がいるけど、酔いやすい人は三次元把握能力の高い人だと思う。これはどうしようもない。
俺は酔いにくい側の人間なんだけど、それでもあるゲームではめちゃくちゃ酔った事がある。
そのゲームはTPSなんだけど「キャラの背後に壁などの障害物があると、それが邪魔にならないよう自動でアングルが変わる」というものだった。
「背後の障害物が透明になる」なら酔わないのに「勝手にアングルが変わる」だと凄まじく酔う事がわかった。
車の運転でも、「運転してる人は酔わない」と言われてる。つ
まり「プレイヤー本人の意思とは関係なくアングルが変わる」と酔う事になる。
他にも、急激にアングルが変わる（目の処理が追いつかない）でも酔うと思われるので、ゆっくり視点を動かす工夫をすればいいのではないだろうか。
あと視点の方向を変えると遠景ほど早く動いて見えるから、遠景はあまり注視できないようにぼかすとか彩度を落とすとかするといいかもしれない。

**名前は開発中のものです。** · 2014/04/02(水) 16:48:09.93

ソニックアドベンチャーDXは何故かすごい酔った

**名前は開発中のものです。** · 2014/04/02(水) 17:07:31.12

モニタを「風景の映ってる窓」として捉えると酔いにくい、なんて話も聞いたことがあるね。

**名前は開発中のものです。** · 2014/04/02(水) 20:57:32.09

FOVの設定が悪いとか

**名前は開発中のものです。** · 2014/04/02(水) 21:38:55.24

>>469
上でも言ったが俺は酔いにくい人間で、モニタに映る映像を「一枚の絵」としか認識してないんだよな。
頭のなかで３次元空間を構築しながら見ていない。

ガンブレードNYの動画を見てた時、ぐりんぐりん視界が動くのにまったく酔わなかったんだが、
ふと「一枚の絵としてしか認識してない自分」に気づいて、
頭のなかで方位を意識しながら（３次元空間を意識しながら）見なおしてみると、あっという間に気分が悪くなったｗ

でもこれは個人の話であってゲームをどうやれば酔いにくくできるかって技術とは別の話だよね。

**名前は開発中のものです。** · 2014/04/02(水) 22:03:56.84

3次元で意識してるけど酔ったことないな
酔うのが不思議でならない

**名前は開発中のものです。** · 2014/04/02(水) 22:29:30.77

３Ｄ酔い
カメラの位置と回転中心位置の関係が悪い
カメラ視野角の調整が悪い
カメラ回転の応答速度が遅い

**名前は開発中のものです。** · 2014/04/02(水) 22:32:07.27

>>465
FoVが狭すぎてゲロゲロ
カメラの動きでゲロゲロ

この辺りは既に言われてるようなので、あとはレベルデザインかな。
ぐぐったら自レスが引っかかったのでリンクを貼っとく
http://unkar.org/r/gamedev/1223550808/423-452

> 452 : 名前は開発中のものです。[sage] : 2008/12/27(土) 00:34:33 ID:quq8i6DN
> >>423
> 遅レスで更に>>425、>>426と微妙にかぶる内容だが
>
> (1)FOVの問題
> 酔いの原因は様々だが、FOVの調整で改善される場合は多い
> プレイヤーの視野角を考えずに3D画面の投影変換行列を設定すると酔いやすい
>
> 　・プレーヤー視点とディスプレイ間の距離
> 　・ディスプレイの寸法
>
> 以上のパラメータから違和感の少ないFOVを探ることができる
> まぁ、既存FPSのFOV値を参考にするほうが手っ取り早いかもな
>
> (2)レベルデザインの問題
> 閉鎖空間を多用するマップは酔いやすい。これは(1)の問題との組み合わせでより悪化する
> FOVをどんなに調整しても吐く奴は吐く。対策としては開放空間（屋外）を多用する方法がある
> ただし、閉鎖空間の戦いをウリにするゲームではこの対策はとれない
>
> BFシリーズはオーケーだけどDOOM3とかHLシリーズは駄目、みたいな人に対処するのは困難
> 狭くて暗い閉鎖空間のスポーツFPSを作るつもりなら酔いやすいユーザーは切り捨てたほうが楽

**名前は開発中のものです。** · 2014/04/02(水) 23:05:42.17

>>473
＞カメラ回転の応答速度が遅い

これ、見落とされがちだけどあるよね

ARMAでマウススムージングがデフォルトでONだったので視線の動きに
遅延が生じて気分悪かった。スムージングを切ったら何ともなかった

**名前は開発中のものです。** · 2014/04/03(木) 00:12:27.55

動き回る飛行船の上でアクションシーンを展開したゲームを作って見たいんだけど
着地判定というか、移動する床みたいなのってどうやってるんだ？

飛行船が上に進んでる時に急制動で下向いたら飛行船に乗ってたキャラクターが跳ねるチンフワ現象を取り入れたいんだけど

素直に物理エンジンに託した方がいい？

**名前は開発中のものです。** · 2014/04/03(木) 00:41:04.11

物理エンジンが一番楽

正確じゃなくてもいいなら
飛行船が上に進んでいるときにキャラクターの下と飛行船の着地できる部分が接触してるか判定して
接触してるなら飛行船の上の移動量とキャラクターの上の移動量を比べて飛行船の移動量の方が大きいなら
キャラクターの上の移動量を飛行船の上の移動量に書き換える

こうすれば飛行船がいきなり止まったりしたときにふわって感じで浮くことは可能
ただ、違和感はある落ち方になると思うから物理エンジンをお勧めしとく

**名前は開発中のものです。** · 2014/04/03(木) 01:07:35.19

>>477
わかったありがとう

**名前は開発中のものです。** · 2014/04/04(金) 02:07:12.66

詳しいね
さすがチンフワ総合スレッド

**名前は開発中のものです。** · 2014/04/05(土) 17:41:08.13

クラス分けって具体的にどんな感じでやっていけばいいの？
関数分けまでは普通に出来るんだけど、メンバ変数がある以上クラス分けしたくても出来ないし・・・

**名前は開発中のものです。** · 2014/04/05(土) 18:16:26.54

「// ○○を△△する」ってなコメントが書けそうな関数が複数あったら
○○をメンバ変数に置いて、○○を操作する関数をメンバ関数にしたクラスにする

ツッコミどころ多そうだけど大雑把にこんな原則で大体どうにかなるんじゃないかな

**名前は開発中のものです。** · 2014/04/05(土) 20:43:25.01

例えばC言語みたいな手続き型の言語で攻撃の判定処理を作ったとする
1.判定対象を選択
2.判定対象の座標と大きさ、形を取得する
3.大きさや形に合わせて判定する
4.当たってたらhpをダメージ分引いたりノックバックさせたり双方の属性に合わせていくつかの処理に分岐する
5.繰り返し

クラスを使ってオブジェクト指向的に処理する
1.対象を選択
2.対象に「お前この判定対象と当たってなる？」と確認する
3.繰り返し

ここまで書いて何を言いたかったか忘れたのでこのまま投稿する

**名前は開発中のものです。** · 2014/04/05(土) 20:58:16.49

関数を実行するのに必要な変数をまとめたのが最小単位かな
変数として持つデータに依存する部分はメンバ関数にしたいけど
std::stringみたいになんでも入れちゃうのと
マイナーな機能は引数を取る静的関数や別クラスに分けるかはまた悩む

**名前は開発中のものです。** · 2014/04/05(土) 21:40:17.97

オブジェクト指向を完全に突き詰めると動詞の関数しかなくなるような気がしないでもない
ゲームなら特に

**名前は開発中のものです。** · 2014/04/05(土) 22:14:07.33

>>482

ええー、そんな感じなの。想像してたのと違うなぁ。

あ、俺は480じゃないけど似たような問題に詰まってる者です。

**名前は開発中のものです。** · 2014/04/06(日) 01:53:43.72

まあオブジェクト指向の作法については
それだけで厚めの本が出るぐらいだし・・・

**名前は開発中のものです。** · 2014/04/06(日) 12:16:47.72

自分のことは自分でやれってことだよ

**名前は開発中のものです。** · 2014/04/06(日) 16:07:09.03

だねぇ

>>480,>>485
完成させてからのリファクタリングの段階ということなら具体的に説明
できるだろうしコード片をうｐってもいいだろうし、お話になるのでは

話の振り方次第ですお

**名前は開発中のものです。** · 2014/04/06(日) 16:50:44.66

例えばだけど、こういう場合はどうした方がいい？

class Player
{
public:
　Player();
　void update()
　{
　　aClass_.update();
　　bClass_.update();
　}
private:
　A aClass_;
　B bClass_;
};

**名前は開発中のものです。** · 2014/04/06(日) 16:51:17.53

class A
{
public:
　A();
　void update()
　{
　　//メンバ変数とBクラスのx_が必要
　}
private:
　int a_;
　int b_;
　int c_;
};

class B
{
public:
　B();
　void update()
　{
　　//メンバ変数とAクラスのa_が必要
　}
private:
　int x_;
　int y_;
　int z_;
};

**名前は開発中のものです。** · 2014/04/06(日) 17:03:11.51

>>490
class Aの前にclass B;を書けば良いんじゃね？

**名前は開発中のものです。** · 2014/04/06(日) 17:10:52.22

横からだけど
とりあえず動作すれば良いってだけならクソ回答としてupdateの引数にそれぞれ渡してあげる
渡し方はゲッターとかクソだけど

**名前は開発中のものです。** · 2014/04/06(日) 17:34:28.11

素人意見だがPlayerにabcxyz持たせて引数付きupdate作るとか
PlayerのupdateかprivateにupdateA,updateB作ってべた書きとか
AとBくっつけるとか
俺はどうしても他で必要にならない限り分けない、
enemyで必要とかになればそもそも一つ前にcharacterとか作って両方に持たせるとか

**名前は開発中のものです。** · 2014/04/06(日) 19:31:11.73

>>489
クラスAとBが相互依存してるから設計しなおす

**名前は開発中のものです。** · 2014/04/06(日) 20:11:48.21

言いたい事は全部言われてた

①AとBは合体だ！フュージョン！
②AとBで壁パスだ！ダブルディスパッチ！
③Playerが面倒見ろ！メディエーター！

AとBが具体的に何なのか分からないとアレだよな
プレイヤーの所有物で、相互作用(値のやり取り)がある二つのもの。
しかし、プレイヤーとの間に作用はない。

ダウジングのアレとか？

**名前は開発中のものです。** · 2014/04/06(日) 20:19:27.91

合体魔法をプレイヤー複数人で打つとする
トリガーとなるプレイヤー一人が発動したら周囲のプレイヤーの合体魔法用のメソッドを呼ぶ
メソッドの中ではそのプレイヤーのmpを減らしたりクールタイムを追加したり硬直したりする
トリガープレイヤーはそのメソッド呼ぶだけだから、もしかしたらプレイヤーによって処理は違うかもしれないが、とにかくそのプレイヤーは合体魔法に参加した
メソッドの返り値で成否を確認してもいい
その複数のプレイヤーの中心の座標に合体魔法を発動するなら、その計算処理はトリガープレイヤーがやる

**名前は開発中のものです。** · 2014/04/06(日) 20:22:50.98

>>490
AとBの使用用途を書け
シチュエーションによって考え方が変わり、考え方に依存するからオブジェクト指向が最も効率いいとされて普及してる

**489** · 2014/04/07(月) 10:11:55.44

>>497
Aクラスはキー入力の処理
Bクラスはキー入力後の移動処理と当たり判定

**名前は開発中のものです。** · 2014/04/07(月) 12:25:22.90

最近は全部hppで書くのか？
ちゃんと.hと.cpp分けろよ

**名前は開発中のものです。** · 2014/04/07(月) 20:27:14.10

>>498
A…キー入力の処理
　　↑B.x_　↓A.a_
B …キー入力後の移動処理と当たり判定

A→Bのデータの流れは分かるが、B→Aのデータの流れは何だ？
フォースフィードバック？

俺はこういう小出しの後出しジャンケンは別に気にしないけど
完成後のリファクタリングの段階なら「具体的に」書けるっしょ？

そろそろ誰かがキレると思うよ

**489** · 2014/04/08(火) 07:12:29.49

>>500
なんかごめん・・・
とりあえずこの質問はスルーってことでorz

**名前は開発中のものです。** · 2014/04/09(水) 00:58:15.38

テンプレートのせいか全部ヘッダ(h, hpp)に全部書く奴いるけど
面倒くさくてもC++としてはちゃんとヘッダとソースは分けるべきだよ

**名前は開発中のものです。** · 2014/04/09(水) 01:28:10.85

>>502
あるべき論なんて一考にも値しない。
アホは、何故そう考えるのか理由を述べない。

**名前は開発中のものです。** · 2014/04/09(水) 08:02:26.21

煽るだけで何も説明しない人による華麗なる自虐芸

**名前は開発中のものです。** · 2014/04/09(水) 10:52:16.89

レースゲームのAIってどうやってるの？
経路探索だけで市販のゲーム風に出来るの？

**名前は開発中のものです。** · 2014/04/09(水) 12:11:54.87

幾つか方法はあるが、コース上に複数の「点」を作っておいて
順番にそれを通過するように組む……というのが単純かな？

**名前は開発中のものです。** · 2014/04/09(水) 12:53:17.52

多数の車が走ってて接触しないようにコース補正とか大変そうだな。

**名前は開発中のものです。** · 2014/04/09(水) 13:04:35.78

リアル思考でない限り見えないところは適当だろ
多少ぶつかってもペナルティがほとんどないとか
ありえない速度でカーブ曲がってたりとか

**名前は開発中のものです。** · 2014/04/09(水) 13:16:31.51

カービィのウエライドのデバッグモードを録画した動画がニコニコにあるからそれを見るといい少しはマシになるだろう！

**名前は開発中のものです。** · 2014/04/11(金) 00:20:28.36

　　　　　　　　　　　決められたパスをヘ(^o^)ヘ
　　　　　　　　　　　　　　　　　　　　　　　　　|∧
　　　　　　　　　　　　　　　　　　　　　　　　 /

　　　　　　　　　　　　　　　　　　　／
　　　ただなぞるよりも　 (^o^)／
　　　　　　　　　　　　　　／(　)
　　　　　　　　　　　　／／＞

　　　　　　(^o^) 三　選んだ自由に
　　　　　　(＼＼　三
　　　　　＜　＼　三
..＼
(／∀・) 　傷付くほうがｲｲ！
( ／　
／く　

**名前は開発中のものです。** · 2014/04/12(土) 22:13:32.52

ちょっとわかんないからサッカーで説明して

**名前は開発中のものです。** · 2014/04/12(土) 23:44:55.21

初めて作ったゲームは目標に向かって一直線に飛ぶ意味わからんハエみたいなシューティングゲームだった

**名前は開発中のものです。** · 2014/04/13(日) 10:10:40.70

プログラム全く関係なくて物理の話で悪いんだけど、戦車が止まってる時と高速で動いてる時に大砲を撃った場合の大砲の速度って違うよね？
ググってもそれらしき情報が出てこないんだけど、具体的に方程式的なのってあるの？

**名前は開発中のものです。** · 2014/04/13(日) 10:15:03.46

戦車の速度＋大砲の初速
これじゃないの？

**名前は開発中のものです。** · 2014/04/13(日) 10:22:56.57

ベクトル合わせるだけじゃん

**名前は開発中のものです。** · 2014/04/13(日) 14:11:27.24

もちろん空気抵抗やらゲームバランスやら考慮するなら変わってくるけどな

**名前は開発中のものです。** · 2014/04/20(日) 07:06:07.84

前から気になってたんだけど、3Dの矩形と矩形の当たり判定って出来るの？
出来るならどんな感じのソースになるのか教えてくれるとかなり助かる

**名前は開発中のものです。** · 2014/04/20(日) 10:51:05.10

矩形判定を3次元に拡張したのがAABB判定だと思う

**名前は開発中のものです。** · 2014/04/20(日) 14:59:59.27

各辺が軸に平行、という前提でいいの？

**名前は開発中のものです。** · 2014/04/20(日) 16:02:57.62

>>519
それで大丈夫
まあさすがに回転してるのは無理だし・・・

**名前は開発中のものです。** · 2014/04/20(日) 16:18:17.37

それは簡単なんでないの
上辺が相手の下辺をより上&&下辺が相手の上辺より下
を3軸分やればいいだけなのでは？

回転する直方体の衝突判定ってまるぺけになかったっけ？

**名前は開発中のものです。** · 2014/04/20(日) 17:29:26.22

最初から「平面上での矩形同士の当たり判定」と考えるから、そこから応用しにくいんじゃないか？

直線上で線分同士が重なってるかどうか？という判定があって
単位、それを2回やったのが矩形同士の当たり判定だと考えれば良い。

そうすると、3次元や4次元（？）も、そのまま使えそうだろ？

**名前は開発中のものです。** · 2014/04/22(火) 06:39:03.06

スーパーマリオ64風のゲームを作ってるんだけど、ステージとプレイヤーの当たり判定ってどうすればいいの？
一応球体の当たり判定と線分の当たり判定でやってるんだけど、坂を下ろうとするとジャンプするように落ちていくっていう・・・

**名前は開発中のものです。** · 2014/04/22(火) 07:04:26.37

ゲームエンジン、物理エンジンの吟味から。
いいやつ教えてくれ。

**名前は開発中のものです。** · 2014/04/22(火) 07:13:32.39

>>523
斜めに移動させる

**名前は開発中のものです。** · 2014/04/23(水) 20:54:31.77

DXライブラリを使っているのですがタイトル画面やゲーム画面でループを変えるべきでしょうか
一つのループでswitchを使ってシーンを変えているのをいろんなサイトで見ますがこういう処理が当たり前なのでしょうか

**名前は開発中のものです。** · 2014/04/23(水) 20:58:04.86

stateパターンｵﾇﾇﾒ

**名前は開発中のものです。** · 2014/04/23(水) 21:00:21.88

俺も最初は画面ごとにループ変えてたけど、ループはひとつにまとめるようになったな。
理由は、ループは違っても共通のやること（キー入力とか画面出力処理）があって
そういうのを画面のループごとに別々に処理させてると管理が面倒だから。
（もちろん共通処理として関数化してはいたが、それでも面倒だった）

**名前は開発中のものです。** · 2014/04/23(水) 21:36:36.02

>>527
なんですかそれ

>.528
なるほど

**名前は開発中のものです。** · 2014/04/23(水) 21:48:10.54

>>526
ループ自体は1つにして、そこから何らかの方法で振り分けるのが定番。
複数ループは即「やめとけ」って言われるレベル。
そこだけ守れば、あとはifで関数に投げるなり、switchで分けるなり、好きなようにすればいいと思うよ。

stateパターンについては、処理を振り分けるアルゴリズムの1つだけど
まあ、別にいいんじゃないかな。

**名前は開発中のものです。** · 2014/04/23(水) 23:54:04.86

>>529
ググれ

**名前は開発中のものです。** · 2014/04/24(木) 08:45:54.28

>>526
Yes
というか、君にループを分けるという発想を持たせた本かサイトか分からんが著者を呼んでこいぶっ飛ばしてやんよ

**名前は開発中のものです。** · 2014/04/24(木) 09:15:53.69

データベースといい会社組織図といいマトリクス型はなぜ好まれないのか

**名前は開発中のものです。** · 2014/04/24(木) 09:46:36.37

>>532
参考資料などがなかった場合、半分くらいは、
真っ先に思いつくのがループを個々に用意する方法のような気もする

**名前は開発中のものです。** · 2014/04/24(木) 10:21:00.95

オブジェクト指向的に考えるとオブジェクトごとに独立したループが存在してるのもあり得るしな
OSのフレームワーク含めてスレッドセーフな実装があまりない事にがっかりしたり

**名前は開発中のものです。** · 2014/04/24(木) 11:59:52.01

そのループ(というか一連の処理)の意味合いを無視して設計空論しても意味ねー
たかがシーン遷移でぶん回すループを、複数個所にコピペベースでおく意味がねー