1人でゲームが作れるように修行します。2

**名前は開発中のものです。** · 2010/05/04(火) 00:44:29

がんばりましょう。

前スレ
1人でゲームが作れるように修行します。
http://pc11.2ch.net/test/read.cgi/gamedev/1006284805/

**SGGK** ◆6pZCoAtaxk · 2011/04/13(水) 05:32:57.65

>>209
使ってみてくれてありがとうございます。
体力ゲージについては今度実装するときには修正してみます。
説明ＪＰＧについては今見直してみると説明というよりは説明図だけのような作りになってるので
また似た事をやるときがあればもう少し改善しようと思います。
関数はＤＸライブラリのものを使っていると注意書きしておけば良かったと今反省。

ユニットリストがマウスドラッグ出来るようになってるとか？
もしかして他者製ライブラリを使わないＡＰＩいろいろ使うＷＩＮＤＯＷＳプログラミングで組んでると想像。

>208の「２Ｄ座標系でやったのと同じ事が３Ｄ座標系でも出来るようにしたい」に向けてちょっと復習。
２Ｄでやってたプログラムソースは、時間、当たり判定、状態遷移の３つ（まだ他にもあるかもしれない）がソースのあちこちで絡み合いワケがわからなくなってきていたので見やすくしたい。
とりあえず、選手関係のソース見て、どんな位置関係にオブジェクトがあればお互いデータやりとり出来てるとか、関数使わないとアドレス渡せないのかとか、
そういったコピペでやり過ごしてきた部分を見直してみた。
なんとなくこういうのはノート＆手書きの方が頭に入りそうな感じがしたので今回はエクセル使わないでノートに手書きでやってみた。
ほんの少しだけ頭の中が整理されたような気がしたので、まず画面に試合経過時間を表示できるようにしたい。
時間は条件分岐に使うので、時間表示を優先したのが理由。

**179** · 2011/04/14(木) 01:35:15.18

ｱﾚﾀﾞﾃﾞｽﾖﾈ、カメラからマウスの座標にレイ飛ばしてYが0になる場所を求めどうのこうのってヤツ。
それが良く分からなかったらから2Dに逃げた(ぉぃ
ｲｴ､ﾊｲ､勉強するのが嫌だっただけですｺﾞﾒﾝﾅｻｲｗ

メニューバーをマウスドラッグで動かせるように～ってヤツですね
WIN APIにその変の便利なのあるかもしれないけどWIN API良く分からないので
自前でメニューバーのボックス（唯のポリゴンの板です）とマウスポインタと当たり判定して
マウスクリック中なら移動させるってのをやろうと思った。

一応移動させるのはできたのは出来たけど、
バーどうしが重なったりすると両方動いたり下に潜り込んだり…。
位置固定にして、表示と非表示の切り替えだけにすりゃ良かったﾅｧ、と。

**SGGK** ◆6pZCoAtaxk · 2011/04/14(木) 23:22:03.79

WINDOWは難しそうなテーマですね。
画面内のWINDOW全てが奥側から数えて何番目にあるかを記憶してその順番に描画してみるとか。
マウスでクリックしたら奥から一番最後の番号が付けられるとか。
でも複数のWINDOWが重なったらどうすればよいのかわからなくなってくる…。

今日は作業時間ほんのわずか。
２Ｄの最後のプログラムSGGK019（020はｿｰｽ見づらいので使わない)のdrawGameMain()関数から抜き出した時間関係の行を使って、
GameTimeクラスを宣言してみた。このクラスのヘッダファイル作成作業がまだまだ途中。

それと>>207でＵＰした理由の補足
完成度に対する誤解を最小限にしておきたかった他に
自分が何らかの理由により作成続行不可能になった時、たとえわずかでもここで得たものを残しておこうかな～と思ったこと。
作業を続けてソースが複雑化し、結局やり直すことになった場合、このSGGK024の段階が丁度良いので区切りとして残しておきたかったこと。

**SGGK** ◆6pZCoAtaxk · 2011/04/14(木) 23:30:34.53

最後から２行目は自分のプログラムの進捗的なものがわずかという意味であり、
ここで得たものがわずかという意味では無いので念の為。
ここではいろいろ多く学ばせてもらってますので…（汗；
読み直してあせった。言葉って難しい。

**SGGK** ◆6pZCoAtaxk · 2011/04/15(金) 23:10:40.56

>>210の試合経過時間は未だ実装出来ず。
結構難しいかもしれない。

**179** · 2011/04/16(土) 03:34:02.42

IF文とboolフラグのオンパレードになってきた…orz
とりあえずの×ボタンは簡単に実装できたけど、
消したのを表示するのは作ってない罠

経過時間は1フレーム毎の時間を求めてカウンタに足していくか引いてくか
するのがいいんじゃないカナー
gettimeとかの関数で取り出したのをそのまま使うと
ポーズとかややこしい事になりそうｗ

static int frame_time , time_know, time_back = GetNowCount(); //初期化

if(time_back != know_time;)time_back = time_know;
time_know = GetNowCount();
frame_time = time_back - time_know;

この3行を毎回回しとけばframe_time が求められるので、後は試合時間にframe_time を足してくだけ。
試合停止中は足さなければ良い。
リセットするときは試合時間を0にすれば良い…と。

**179** · 2011/04/16(土) 03:42:37.35

あ、初期化ミス…↓こうでしたorz

//初期化
static int frame_time = 0
static inttime_know = GetNowCount() - 1;
static inttime_back = GetNowCount() - 1;

//１フレームの時間を求める処理
if(time_back != know_time;)time_back = time_know;
time_know = GetNowCount();
frame_time = time_back - time_know;

**名前は開発中のものです。** · 2011/04/16(土) 15:03:11.50

サッカーゲームのような、フレームごとの計算を繰り返していくタイプのプログラムの場合、
経過時間の管理は、実際の(現実世界の)経過時間ではなく、
処理したフレーム数で管理するほうが、合理的な結果が得られると思います。

**SGGK** ◆6pZCoAtaxk · 2011/04/17(日) 00:44:52.38

>>215,216
ありがとうございます。
自分はいままでbackとknowに相当するコードをなぜかソース内の別々の場所に書いてあり、ソースが読みにくくなっていたけど、
これを見て３行続けて書ける事が分かりましたので、早速修正してみます。

今回はメインループ内に書かれるソースコードを減らしてみたくてこの３行に相当する機能をクラス化することに挑戦。
結果、クラス内の行数はかなり増えてしまうけどreleaseモードでは成功。
debugモードでは時間表示が正しくなく、プログラムを終了させると「ヒープが壊れていることが原因として考えられます。」のようなエラーメッセージ。
いちおう半分はうまくいってるので、ゆっくり考えるつもり。

>>217
アドバイスありがとうございます。現時点のプログラムソースでは、
１フレーム計算毎に１ずつ増えていく変数を用意し、これを使って選手のアニメパターンを決定したりしてますが、
上記のdebugモードでの不具合が取れなかった場合、フレームタイムｘループ回数を時間に単位変更して画面表示するようなやり方も検討してみます。

**SGGK** ◆6pZCoAtaxk · 2011/04/17(日) 01:48:23.54

そういえば以前にもdebugモードでダメでreleaseモードではＯＫというのは、
releaseモードではチェックがされていないだけなので、バグが無いという意味ではないとこのスレで教わったのを思い出す。

まだ、この前ＵＰしたバージョンにちょっと書き足しただけなんだから、
どこかに内容的な間違いがあるはずと思い良く見てみると１か所あったので直してコンパイルしてみたら直った！
これがなんでヒープ壊れる事につながっていたのかは結局わからずだけど、
とりあえずすっきり。（寝）

**SGGK** ◆6pZCoAtaxk · 2011/04/17(日) 23:21:42.93

昨日は起きていたのがいつもより遅かったので書けなかったけど、
昨日の間違いというのは、メインループ内のゲーム処理関数の最初の行に書いた２行の順序が逆だったこと。
（間違い）
m_Time.countGameTime();
if(m_Time.m_GameTimeState==CONTINUE){m_Time.displayGameTime();}
（正解）
if(m_Time.m_GameTimeState==CONTINUE){m_Time.displayGameTime();}
m_Time.countGameTime();

時間の測定はループ１回毎に時間を測定して、前回のループでの測定値との差を毎回足していくんだけど、
１回目のループでは前回のループの測定値がまだ存在しないので、差を計算しては困るので、
時間クラスに２つの状態STARTとCONTINUEという定数を定義しておいて、
初期値はSTARTにしておき、STARTの場合には差を計算しない。CONTINUEなら差を計算する。
１回目のループではSTARTなので時間の測定だけして、差は計算しない。そして状態をCONTINUEに変更する。
そしたら２回目のループ以降は差を計算してくれる。
間違いの例だと１行目で状態がCONTINUEに変更されてるので、まだ差を計算してないのに時間を画面に表示しようとしてしまう。
正解例の順にするとバグが出なくなった。
実は>>216で初期化値がGetNowCount() - 1となっている理由がわからなくて全部０にしてしまったので、
そこに何か関係があるのかと思ったりもしたけど、上記の方法でバグが出なくなったのでたぶん大丈夫。

**179** · 2011/04/18(月) 02:43:15.47

最初の初期化で　GetNowCount() - 1　を入れてるのは
最初のループ部分でバグった値を入れないようにするためですｗ
なのでGetNowCount()　を取っちゃうと当然バグります
-1　は入れなくてもいいのですが最初のループに最速で到達しても1msを返すように設定してあるだけです

初期値に0を入れてしまうと
if(time_back != know_time;)time_back = time_know;　//一回目は0　と　0　の比較になるので変化無し
time_know = GetNowCount();　　　　　　　　　　　　//know　が　xxxxxxxxxxくらい？の数値になる
frame_time = time_back - time_know;　　　　　　　　//一回目はbackは0のままなので　-xxxxxxxxxx桁くらいの数値が引かれてフレームタイムが-値でバグる

プログラム開始から終了までずっと測ってる前提で作ったので(タイトル画面等でも測定だけしてる）
ある部分だけ測るという場合はフラグ管理する、初期化を呼び出す等必要ですねぇ

ここまで書いてあれなんですが>>217さんの言う通り
経過時間 += 17ms 等で固定した方がいいかも知れないで
まぁFPSが固定されてるなら問題は出ないので余り気にする事も無いｶﾓ…。

**179** · 2011/04/18(月) 02:55:13.67

あれ？
式間違ってるじゃん・・・／(＾o＾)＼
ｺﾞﾒﾝﾅｻｲ3行目　backとknow逆ﾃﾞｼﾀ

f(time_back != know_time;)time_back = time_know;　//一回目は0　と　0　の比較になるので変化無し
time_know = GetNowCount();　　　　　　　　　　　　//know　が　xxxxxxxxxxくらい？の数値になる
frame_time = time_know - time_back;　　　　　　　　//一回目はbackは0のままなので　xxxxxxxxxx - 0 でxxxxxxxxxくらいの値がフレームタイムに入る

ついでにちら裏：
WINDOWぽいのはなんとか形になった気がする
ので次の作業へー
フィールドの資源地とか基地ぽいの作るｶﾅｰ

**SGGK** ◆6pZCoAtaxk · 2011/04/18(月) 23:13:36.71

>>221,222
ループが最速で到達した場合というのは想定してなかったので勉強になりました。
ありがとうございました。

今日は次の目標を考えて終了。
次の目標は、前半、ハーフタイム、後半、試合結果表示の４つの状態遷移実装。

**SGGK** ◆6pZCoAtaxk · 2011/04/19(火) 22:59:14.08

状態遷移は以下のような感じで実装。SGGK_019のソースの頃に比べれば短くなった感じ。
でも、これに選手の前半後半の攻撃方向入れ替えや得点表示などを組み込むとなると混乱しそうな予感。

switch (m_MatchState) {
case FIRST_HALF:
if(m_Time.m_TotalGameTime >= FIRST_HALF_GAME_TIME){
m_MatchState=HALF_TIME;
m_Time.resetGameTime();
}
break;
case HALF_TIME:
if(m_Time.m_TotalGameTime >= HALF_GAME_TIME){
m_MatchState=SECOND_HALF;
m_Time.resetGameTime();
}
break;
case SECOND_HALF:
if(m_Time.m_TotalGameTime >= SECOND_HALF_GAME_TIME){
m_MatchState=RESULT_DISPLAY;
m_Time.resetGameTime();
}
break;
case RESULT_DISPLAY:
if(m_Time.m_TotalGameTime >= RESULT_DISPLAY_TIME){
setGameState(GAME_OVER);
m_Time.resetGameTime();
}
break;
default:
break;
}

**SGGK** ◆6pZCoAtaxk · 2011/04/20(水) 22:43:09.69

でも、もっと良いやり方があるはずなので、
「ゲームプログラム　状態遷移」でネット検索。
以前も挫折したけど、また少しだけ調べてみるつもり。

**179@SLG?** · 2011/04/23(土) 00:02:41.30

うーん、基地というか資源地ぽいクラスを作ったけど
中身がユニットと変わらない罠･･･
後、マウスの座標をWINDOWSのアイコンの位置から取るようにしたら
なんかバグって座標がずれてたりしたけどなんとか直した。

手間食ったけど、やっとALT+TAB押さないと違うWINDOW行けない仕様から
普通にマウスでいけるようになった(ﾉ∀`)

**SGGK** ◆6pZCoAtaxk · 2011/04/24(日) 00:01:37.30

こちらの進捗は調べたり休んだりを繰り返しながら実質何も進まずな状態が続きそうな予感…（汗

**SGGK** ◆6pZCoAtaxk · 2011/04/25(月) 00:12:59.17

>>224でも短くなった方だけど、ゲームのメイン処理の先頭にこれを書くのは
まだ長いような感じがした。それと、ゲームの時間帯の状態を表す定数と時間のリセットの処理を一緒に書くのも
後々わかりにくくなるような気がした。今はたまたま、この定数の切り替わりが起きる条件と時間のリセットが起きる条件が一緒だから
このように書けているだけなので、将来の想定外の変更を考えて分ける事を考えた。
ゲーム時間帯の状態を表す定数を決める関数を>>224の改造で作成。
>>224から時間のリセットの行を削除しただけのもの。
calMatchState()という名前にでもしておく。
そして時間のリセットを行う関数をそのあとに書けばいい。
但し、calMatchState()で先にゲーム時間帯の状態を変更されてしまうので、
状態の切り替わりが検知できるように状態を表す変数をもう一つ用意して現時点のゲーム時間帯の状態を表す定数値を保持しておく。
そうしておけば、直前の関数でゲーム時間帯の状態を表す定数値が変わったら、その値と保持していた値が異なるので、
その時に時間をリセットして、現時点のゲーム時間帯の状態を表す定数値は更新する。
いちおうこれでプログラムは同じように動いてくれた。

時間リセットを判定する関数は以下の様な感じ。
void SoccerGame::calTimeResetState()
{
if(m_MatchState!=m_MatchState1){
m_Time.resetGameTime();
m_MatchState1=m_MatchState;
}
}

**SGGK** ◆6pZCoAtaxk · 2011/04/29(金) 23:24:14.14

今、自分に負け気味な感じなのでしばらくダメかもしれない予感…。
いろいろ考えがあり、次は当たり判定をクラスで実装しようとしたけれど、
本当にクラスにした方がいいのか迷う。
当たり判定の関数を持つクラスのオブジェクトを選手やボールのオブジェクトに
メンバとして持たせるつもりだけど、時間が掛かりそうな予感。（理由は１行目）

**179** ◆SLG//siTD6 · 2011/05/01(日) 01:09:31.11

トリップてすと。
プログラムの方はサボり気味で余りすすんでないけど
とりあえずユニットから弾撃てるようにしてみた。
実験的に実装したんで中身がスカスカだけどｗ

>>229
当たり判定はどうするか迷うねぇ
こっちも当たり判定はかなりややこしい事になってる･･･ｗ

**SGGK** ◆6pZCoAtaxk · 2011/05/02(月) 00:20:50.39

>>230
トリップの文字にＳＬＧが入ってる！

当たり判定のクラスは、当たり判定の範囲を示す四角の情報をメンバ変数に持ち、
そのメンバ変数を取り込んで番号を付けるメンバ関数、
当たり判定をしたいオブジェクトの四角情報を取り込み、その情報を基に判定する関数があればいいかなと考えてるけど、
まだ考えてるだけで実装が進んでない状況。ヘッダファイルだけは書いてみたけど、あまり自信無し。

**SGGK** ◆6pZCoAtaxk · 2011/05/08(日) 00:12:20.39

試行錯誤した挙句自分には>>231を実装するのは無理と判断…。
これをやりたかった理由は、選手のアニメパターンがジャンプしたりキックしたり変化した時にそれぞれに応じた
当たり判定を呼び出せるようなしくみがこの先必要なんじゃないかと思ったからだけど、とりあえず断念。

その他
今日は、ボールをメタセコイアモデルにしていたのをあえて以前の２Ｄに戻した。

当たり判定は、選手の足元ｘｚ平面上に３２ｘ３２の矩形があるとし、
ボールも同様に８ｘ８の矩形があるとし、これで書いてみる予定。
選手とボールが接触してなくても当たってしまうけど無視！
ジャンプしたら判定できなくなるけど、とりあえず最低限の実装を優先。
内容がかなり後退した感じ。

**SGGK** ◆6pZCoAtaxk · 2011/05/08(日) 22:55:14.85

今日もあまり進まず。
当たり判定クラスの中に作った矩形当たり判定用メンバ関数は最初は、
bool CollisionCheck::isHit(FieldPlayer *, BallData *);//選手とボールの当たり判定
のようなものを考えていたけど、
bool CollisionCheck::isHit(VECTOR,int,int,VECTOR,int,int);//引数：オブジェクト座標、当たり矩形縦、横、オブジェクト座標、当たり矩形縦、横
に変更してみた。１番目の方は選手とボールにしか使えないけど、２番目のようにすれば汎用性が高いのではと考えたのが理由。

ボールをけるボタンを押したときに選手とボールのあたりが真なら、ボールが一定の速度で移動するようにするつもり。
そのときに何回ループしたらボール停止というのではなく、ボールの速度が少しずつ０に近づき、０になったら停止するようにしたいけど、
物理を忘れてしまってるし、当時の記憶がよみがえったとしても問題は解けなかったと思うので、
紙に点と矢印を書いて、どうするか考えてるところ。

**名前は開発中のものです。** · 2011/05/08(日) 23:55:10.30

move += f;
x += move;
物理は基本的にこれ
力fで加速（減速）して、現在地xから速度move分だけ動く
>>233ならf=move/2とか、そんな感じで

**名前は開発中のものです。** · 2011/05/08(日) 23:58:57.92

すまん訂正、-moveにしないとダメだなｗ
f=-move/2
-moveを使うと常に移動方向と逆向きに力がかかる

**名前は開発中のものです。** · 2011/05/09(月) 00:20:15.21

F=ma
v+=aΔt
x+=vΔt
だろ

**名前は開発中のものです。** · 2011/05/09(月) 01:17:50.08

>>236
教科書を丸写しするとそうだな
それをプログラム用に単純化したのが>>234

**名前は開発中のものです。** · 2011/05/09(月) 03:49:37.28

>>231
ボールとの当たり判定をするなら矩形よりも円（球）の方が自然じゃないでしょうか。
プレイヤー側も球体の集合として定義しておき、
ボール中心とプレイヤー判定球の中心間の距離＜ボール半径＋プレイヤー判定球の半径
となったら、接触していることになります。
プレイヤー判定球に頭、足、手などの属性をつければ、どこに当たっているかも判定できると思います。

**名前は開発中のものです。** · 2011/05/09(月) 03:54:43.87

>>233
物理的には、
・重力
・跳ね返りによるロス…地面やゴールポストとのバウンドの際、運動エネルギーの一部が消失
・ころがり摩擦抵抗…ボールが着地しているときのみ
・空気抵抗…ボールの高度に関わらず場の空気の流れ(風)との速度差に応じて加速
風が無い環境なら、極端な例だと紙風船を思い切り投げたときのようになります。
・ボールのスピン…減速要因ではありませんが空気抵抗による曲げ加速の一種
　　　空気抵抗に配慮するなら合わせて検討してみてください。
などが考えられます。

ちなみに摩擦によるボールの減速については、ボールの速度ベクトル(の水平成分)に対して
1より小さい数(0.995とか)を毎フレームごとに掛けるという簡易な方法でも、それらしく見えると思います。

**SGGK** ◆6pZCoAtaxk · 2011/05/09(月) 23:53:46.13

>>234～>>239
多くのアドバイス、ありがとうございます。全部活用していきます。

>>234,>>235,>>236,>>237
なんとなく分かってきました。
昨日考えていた時は、等加速度αのｔ秒後の位置ｘの式が物理の本にあったとして、
これをゲームに応用するには、移動を始めた初期位置と初期速度に対してframetime後、2*frametime後、3*frametime後、…n*frametime後の位置を計算しなくてはと思い悩んでいたけど、
毎フレーム単位毎に常にその時の数値が初期値であると考えてframetime後の数値を計算するならば、公式がそのまま使えそうな感じ。
アドバイスのと同じ内容ですけど、たぶん、
frametime後の位置＝現在位置＋（現在速度　x　frametime）＋　（（加速度ｘframetime）ｘ　frametime／2　）
（注：加速度は実際の動きを見ながらマイナスの小さい値を設定）
を毎ループ繰り返していけば出来そうな予感。
>>238
前のプログラムが矩形当たり判定で他に判定方法を知らなかったのが理由ですが、
矩形だと斜め45度からボールに近づくと水平に近づくより有利になってしまうし、
円（球）形方式ならその問題もなくて良さそうなのでこれに挑戦してみます。
>>239
今回のプログラムでは、
・重力、・跳ね返りによるロス、・ころがり摩擦抵抗までを簡易な方法で実装していきたいと思ってます。
いずれは、スピンも表現できるようにして、レベルが上がると２回曲がるシュートが出せるようになる等やってみたいです！

**SGGK** ◆6pZCoAtaxk · 2011/05/11(水) 23:28:32.89

すぐには進まないけど、当たり判定用関数の実装終了。
宣言と定義しただけで、まだ実際には使っていないので、バグが出るかもしれない。
選手がボールを蹴れるようにする実装を検討中。
>>233で言ってた
＞ボールをけるボタンを押したときに選手とボールのあたりが真なら、ボールが一定の速度で移動するようにするつもり。
を実装するにはキック用キーを押した時に選手とボールの座標を取得して当たり判定をして、
当たりなら、例えばボールの状態の変数をセットしてそれに応じてボールの挙動が変化するみたいにすればよさそうだけど、
それをどこに書くかが悩むところで、選手のクラス内にも書けるし、ボールのクラス内でも書けそうな気がする。
でも、今回は選手やボールに関係するオブジェクト、その他のオブジェクトをメンバ変数に持っているSoccerGameクラスの中に
メンバ関数calVariousState()を定義して、その中でやってみるつもり。
SoccerGameクラス内のメンバ関数からなら他のメンバになってる選手やボールのオブジェクトとも情報のやりとりが
しやすそうだし、既に書いてあるcalMatchState()や calTimeResetState()と似た役割の関数になると思うので書きやすいかもしれない。
calVariousState()の中でいろいろなオブジェクトの状態を表す変数を更新して、その結果が他のオブジェクトに反映されるイメージ。
できるかどうか自信無し…。

**SGGK** ◆6pZCoAtaxk · 2011/05/17(火) 22:44:39.91

時間の流れが速すぎて生存報告のみな感じ。
ボールを蹴れるようにするにはあれが必要これが必要と考えていたら
何故かソートのプログラムで悩む。
ソートについては名前は聞いたことある位の認識なのでちょっと調べる必要があって時間かかった。
全部調べるのは無理なので最初に見たバブルソートを使う事にした。
これは時間のかかるソートだという事は調べているときに知ったけど、とりあえずこれでやることにした。
選手とボールの距離を計算してその数値が小さいものから順に並べ替えるんだけど、
選手の情報を格納しているリスト構造のコンテナクラス？の並びは変えないで、
もしソートしたらこの要素は何番目になるという情報を全ての選手のデータに格納できるようにしたかったので、てこずった。
今はやっと方法を思いついたところで、それで上手くいくかどうかによって今後の作業の進み具合も変わりそうな感じ。
やり方は２２人分のデータを３つの数値ａ，ｂ，ｃを持つ構造体型配列にもたせる。
aには、１、２、３、…、２２の数値、ｂにはボールｊとの距離、ｃの初期値は０にしておく。
ｂの値で構造体型配列をバブルソートして、隣同士の配列の順番入れ替えが起きたら、それぞれのｃの値をプラス１したら一方はマイナス１する。
ａの値は入れ替えを何度やってもソート終了まで変更なしのそのまま。
ソートが終わったら、例えばａ＝１の構造体配列のｃが５なら、１＋５＝６
なので、リスト構造１番目の選手データはボールとの距離でソートしたら、６番目になるというこの６だけを
リスト構造の１番目の選手のメンバ変数に保持させておくイメージ。
まだ上手くいくかわからないうちに書いてしまった…（汗；

**名前は開発中のものです。** · 2011/05/17(火) 23:03:28.52

そんなに難しいことしないで、「選手の情報を格納しているクラス」の”ポインタの配列”をソートすればいいんじゃない？

**179** ◆SLG//siTD6 · 2011/05/18(水) 12:20:58.07

難しすぎて理解できないぜ･･･ｗ
というか、最後３行あたりの用途ならソートしなくても
単純に自分よりボールに近い選手の数を数えればいいんじゃ..？

チラ裏:
ここ2週間ほど忙しくてプログラムから離れてたらクソースが読めなくなってしまったんだぜ･･･
誰だこんな汚いソース書いたのは。。

**SGGK** ◆6pZCoAtaxk · 2011/05/18(水) 23:50:48.43

>>243
アドバイス、ありがとうございます。
242での説明が不足していたせいもあり、実は自分のプログラムは「選手の情報を格納しているクラス」のオブジェクト２２個（選手２２人分）を
配列に入れているやり方でなくて、例えば、list<FieldPlayer>m_FieldPlayerList　のようにFieldPlayer型のオブジェクトをpush_back関数で次々に入れていけるメンバ、m_FieldPlayerListを定義して、
それらの要素にはイテレータ、list<FieldPlayer>::iterator it;のような命令を書いて、このitを＋＋したり、－－したりする方法でアクセスする感じの実装なので、ポインタでのアクセスが出来なさそうです。

でも、「ポインタの配列をソートする」でネット検索すると、「検索結果ロベールのC＋＋教室 - 第28章たのしいソート5」というページがヒットしたので、これの１から５までを読んで、実装はまだ理解できないけど考え方がなんとなくわかりました。
これと243氏の”ポインタの配列”をソートするやり方を合わせて
「選手の情報を格納しているクラス」内のメンバ変数で順番を知りたいデータ（距離とか）を構造体配列に移して、それにアクセスするポインタ配列を用意し、そのポインタ配列がソートされるといった仕組みを内部に持っている関数、
つまり、選手の番号を入れたらボールの近さが２２人中何番目かがリターンされる関数を作ってみようと思います。

>>244
実はまだ考えてないのですが、今わかってる距離の利用法として、ボールに近い選手を両チームから1人ずつ選び頭付近にマークを出すとか、
ボールから７番目以降の距離にいる選手は守りの動きをするなど、１ループで何度かボールとの距離情報が必要になると思われるので、
その都度同じソートをすると時間がかかりそうなので、一度計算したソート結果を選手のオブジェクトのメンバ変数に保持させておこうかなと思ったため>>242のようになってしまってます。

自分も作業からしばらく離れてて、あれッ？と思うほどに読めなくなった事がよくありましたので気持ちがよくわかります。（汗；

**179** ◆SLG//siTD6 · 2011/05/25(水) 02:34:04.49

チョイ調べたらイテレータからポインターにぶち込めるみたいだったけど
p = &*it みたいな感じで。

>>244　のは、選手数えて保持すればいいんじゃって事・・・ｗ
やってる事は選択ソートとあまり変わらないし、保持したところでアクセスにもループいるから微妙っちゃ微妙。
ポインタ配列ソートならp[7]　で7番目にアクセスできるから便利だね

チラ裏：
何をやろうとしてたか忘れたので
とりあえず資源関係を追加してみた。
TOPバーに数個のボタンと資源の残量表示するようにした。

次は資源基地の占領とか作ってみるかなぁ
あーでもユニットクラスの再設計もいるような･･･アニメーションクラスも作ってないし･･･orz

**SGGK** ◆6pZCoAtaxk · 2011/05/25(水) 23:02:14.26

>>246
ありがとうございます。今思うと自分のソースでも　(*it).メンバ関数　のように書いてるところもあり、
*it　がオブジェクトのような感じなので、それを考えれば　p = &*it でやれそうなのにこれは全然思いつかなかった。
ノートに書いて忘れないようにしておきます。
ソートが今丁度出来たところなので、イテレータへのポインタ方式のソースへの適用は次回かそれ以降のソース改良のときに挑戦してみたいと思います。

ソート書くのに時間が掛かってしまい、途中で作業ペースも落ち気味になる。
ゲームスタート直後は選手とボールの距離が同じデータが複数あるので、
例えば1,1,1,1,5,6,7…になるはずのが、4,4,4,4,5,6,7…になってしまい悩んだけど、
番号付けるループ内にbreak文を入れたら直った。
これだけだと説明不足だけど、今回のはものすごく長いので、ソースの次回ＵＰで見てもらえると助かります。

これで>>241まで戻ってボールを蹴る処理の実装に取り組めそうな予感。

**SGGK** ◆6pZCoAtaxk · 2011/05/25(水) 23:16:38.45

次回ソースＵＰの時に同じソースが残ってる自信がないので、簡単に説明。
d[i]がソート後の距離を指すポインタ配列
例えばd[1]には1番ボールと選手の距離が近い値へのポインタが入っていて、
*d[1]で距離を呼び出して、この距離と同じメンバ変数m_DistanceFromBallを持つ選手のオブジェクトがit++を繰り返して見つかったら、
その選手オブジェクトのソートした場合の順番を保持してるメンバ変数m_NumberFromBallにｉを入力するアルゴリズム。
breakが無かったら、4,4,4,4,5,6,7…みたいな感じになるけど、以下のソースのようにbreak入れたら
1,1,1,1,5,6,7…みたいになり直った。
なんとか説明できた！

it=(*fp).begin();
while(it!=(*fp).end()){
for(i=0;i<=21;i++){
if(*(d[i])==(*it).m_DistanceFromBall){
(*it).m_NumberFromBall=i+1;
break;
}
}
it++;
}

**SGGK** ◆6pZCoAtaxk · 2011/05/31(火) 23:13:10.10

1週間が早すぎるけどやっぱり進まず。（なかなか早く帰れないし、帰り遅いと疲れてしまって…と言い訳。）

選手がボールを蹴るキーを押したときに選手とボールのあたり判定が真ならボールの状態をKICKEDにして、（←ここまでは書けた。コンパイルは通るようになったけど、動かすと問題でるかもしれない。）
ボールの移動関数の方では、ボールの状態がKICKEDになったループの時だけ初速を計算し、状態をMOVINGにして、それ以降は速度０になるまで位置計算を繰り返すにしたいけど、この初速をプログラムのどこで計算するかに迷って時間かかってしまった。
ボールのクラスのメンバ関数でやろうとすると選手のデータを引数にしなければならず面倒に思ったから。
なぜなら初速を変える要因は選手だけでなく地面や壁やゴールバーなどもあるし、そのつどこれらを引数にすると処理が増えて複雑になりそう。

そこでボールデータクラスに初速をメンバ変数として持たせて、選手もボールも扱えるsoccergameクラス内で初速を計算してボールデータのメンバにセットして
ボール関数内ではその初速メンバにアクセスして位置を計算してみるようにしようと考えて今日は終了。

たしか今年の８月で４年が経つはずだけどなかなか進まない…。
いっそのことあと１年で完成させる！
という無理な目標でも立てて頑張った方がずるずるいかなくていいのかもしれないと変な事考えてしまったりして…。

**179** ◆SLG//siTD6 · 2011/06/02(木) 04:01:33.97

ずるずるでも続いてるならいつか出来上がるさ～

自分はあきっぽいからずるずる続けられないんだよなぁ
すでにちょっと２Dスクロールアクションみたいなの作ってみたいなとか思ったり。
が、とりあえずSLGをそれっぽく完成させてるまで我慢。
段々コードが荒っぽくなってるけどｗ

チラ裏：
中立資源地の占領実装した。敵の資源地とかはまだ。
けど占領しても何も変わらないので自分のものになったか分からない、っていう。
ついでにユニットクラスの再設計？ちょっとコード読みやすくした。
ら、FPSが200→100まで落ち込んだ、HAHAHAワロス･･･

**SGGK** ◆6pZCoAtaxk · 2011/06/02(木) 23:58:31.42

１年での完成はやっぱり無理だとしても諦める事だけは無いようにしたいな～と思ってます。
自分もコードが早くも分かりにくくなってきてるので、危険な状態かもしれない（汗

選手がボールを蹴れる処理を書き終えてコンパイルしてみたが、
コンパイルは通るようになったものの、選手もボールも画面に表示されずで今日は終了。

**名前は開発中のものです。** · 2011/06/07(火) 00:00:23.92

一気にゲームを完成させるのが難しいなら、要素ごとにマイルストーンを設定するのがいいですよ。

３Ｄ見下ろし型サッカーゲームだったら、
１．グラウンドとゴールを描画する。カメラを動かしたいのならその動かし方も決めて調整しておく。
２．ボールを配置し、試験的にマウスでクリックすると蹴ったように動くようにする（物理運動シミュレーション）。
３．ラインを割った状態(スローイン、コーナーキック、ゴールキック、得点)を判定し、復帰処理をつくる。
４．選手をまず１人表示し、動かせるようにする。
５．選手とボールの接触判定をし、マウスクリックの代わりに選手が蹴るようにする。
６．ＣＰＵ選手をまずは１人登場させ、動くようにする。
７．ポジション別にＣＰＵ選手のＡＩを調整する。
８．タイム、スコア、勝敗、タイトル画面などの装飾要素を実装する。
の順番がおすすめです。

**SGGK** ◆6pZCoAtaxk · 2011/06/07(火) 23:23:39.99

>>252
ありがとうございます。このように全体を先にイメージした方がいろいろ良さそうですね。
今出来てるのは１の一部、４、８の一部ぐらいなので、あまり進んでいない様です。
どのくらい遅れているのかということに気付けるのも大事なので、完成までにやることをイメージしておくことは有効だと思います。
先は長いけれど、ここから頑張ってみます。

ボールを蹴る実装が上手くいかず。
ボール移動関数実行直後にブレーク入れてボールの座標を見ると、（-1.#IND00、-1.#IND00、-1.#IND00）になってた。
ネットで調べたらどこかで０で割ってるところがあるという意味らしい。
最初は気付かなかったが、速度ベクトルの大きさを１にする必要があるためVNorm(速度ベクトル)という関数を使ってた箇所があり、
初期化したときの速度ベクトルは（０，０，０）にしてたので、VNorm(速度ベクトル)の中でたぶん、大きさを１にするためにベクトルをベクトルの大きさで割ってるはずで、
そのベクトルの大きさが０なので、ここが怪しいと思い、VNorm(速度ベクトル)の直後でブレークして、
ボールの座標を見たら、（-1.#IND00、-1.#IND00、-1.#IND00）だった。
ここを直そうと思ったところで終了。

**名前は開発中のものです。** · 2011/06/08(水) 00:39:22.18

>>253
>完成までにやることをイメージしておくことは有効だと思います。
全体の把握というか、パーツ毎に分けて作業化するという意味合いが強いと思う
簡単にいうと段階毎に締め切りを設けて、そのスケジュール通りにこなしていけばいつの間にか完成している、という方法
いつか完成すれば（あるいは完成しなくても）いいという人にはあまり効果はない

**SGGK** ◆6pZCoAtaxk · 2011/06/09(木) 00:10:01.09

>>254
自信が無くても締め切りを設けた方が良さそうな気がしてきました。
ありがとうございます。
>>252氏のマイルストーンを参考にして６月２３日を目標にしてみます。

**179** ◆SLG//siTD6 · 2011/06/09(木) 02:18:24.59

たしかに段階的学習スレのお題のはやりやすかった気がする･･･。
あの時は一週間くらいで一段階って自分ルール決めてたなぁ
今でも大体1週間くらいでなんか一つって感じだけど。

チラ裏：次の目標?
資源地とユニットに■マークに色つけて敵と見方分かるようにした。
敵の資源地に攻撃→HP０になったら→中立化→占領で自分の物になるようにした。

次は、弾が当たっても残りHPとか分からないのでそこらへんをなんとか
他ユニットのダメージ判定とか。プチAIとか。

**SGGK** ◆6pZCoAtaxk · 2011/06/09(木) 23:56:56.45

翌日になって確かに２３日は厳しすぎかもしれないと思えてきました。
一週間でひとつが丁度良さそうな感じ。
とりあえずは２３日目標で頑張ってみて、その結果を見て次の行動を考えてみようと思います。
ＡＩは難しそうですね。
自分も７番でやろうとしてるけど、選手中心半径何ドットにボールが入ったらボールに向かうような処理を書いて
とりあえずＡＩということにしてみる予定です。

カメラを動かすとフィールド上でマウスが示す座標が変わり、
これによるプログラム全体への影響箇所を短期間で直すのは無理なので、
今回はカメラ固定として、とりあえず１番は完了にする。
今は２番で、マウスがクリックされた瞬間のフィールド上でマウスが示す座標を取得する関数を
どうするか考えているところ。

**名前は開発中のものです。** · 2011/06/10(金) 19:38:35.81

期限を守ることよりも確実に仕上げていくことが大事ですよ。
それと、安易に妥協しないことも終盤でのモチベーション維持につながると思います。

1番2番に関係しますが、>>116 は理解できましたか？

**SGGK** ◆6pZCoAtaxk · 2011/06/11(土) 00:17:49.91

>>258
アドバイス、ありがとうございます。
そうですね。確かにそのような気もしてきました。（>>116の理解は一応大丈夫かなと思ってます。）
もう少し１番を頑張ってみてカメラを動かせるようになってから、>>257をやってみます。

**名前は開発中のものです。** · 2011/06/17(金) 23:39:19.78

イラストだけフリー素材を使うのはスレチかな？

**名前は開発中のものです。** · 2011/06/18(土) 11:32:10.91

良いと思うよ

**SGGK** ◆6pZCoAtaxk · 2011/06/19(日) 00:21:13.27

こ…これは誤爆レスなのでしょうか？

こちらは全然進まずで、マウスでカメラ動かす為の前準備としてマウスのクリックとドラッグの判定をする関数を書こうとしているところ。

**179** ◆SLG//siTD6 · 2011/06/19(日) 03:44:59.57

スレ名が「1人で～」だから･･･？
いいんじゃないの？
ダメだったら俺もスレチだぜorz
テクスチャは○とか×とかで済ませてるけど、効果音とか無理だしなぁ･･･まだそこまでいってないｹﾄﾞ。

チラ裏：
HPバーととかユニットの死亡処理（HP０で消す）とか作った。
次はユニット生産？とか。とりあえずボタン押したら基地からユニット出すように作ろう。。。
どっかにSLGの段階的LV表みたいなもの無いもんかな

**SGGK** ◆6pZCoAtaxk · 2011/06/19(日) 12:39:30.15

>>263
そう言われてみると、これは参加のレスですね。
昨日はうっかりして気が付きませんでした。ありがとうございます。
>>260
こちらの勘違いすみません。
自分も今使ってるサッカーフィールドはフリー素材。
参加者いつでもお待ちしてます！

**名前は開発中のものです。** · 2011/06/19(日) 14:11:27.41

260です。書きっぱで申し訳ないです。
私は恋愛ADVを作ろうとしています。
まだ企画段階で、吉里吉里もインストールしてない状態ですが、修行してがんばります。
イラストだけは描けません。
そういえば、効果音やボイスも1人だと厳しいですね。やろうとしてやれないことはないですが。。。

**名前は開発中のものです。** · 2011/06/19(日) 16:19:10.42

恋愛ADVを作るなら、ゲーム中のどんな要素（画像、テキストや台詞、イベント類…）を
重要視したいかポイントを定めて、まずその部分を徹底的に作りこむといいんじゃないかな？

仮にそれがもしイラストなのだとすれば、
他人の素材を借りて作ったのでは自分で作ったことにはならないので（つまりスレ違いなので）、
ゲームを作りながらでなくてもいいから、普通にイラストの修行をするといいと思う。

**名前は開発中のものです。** · 2011/06/19(日) 16:50:25.41

179氏のSLGに関しては、どのような内容か不明だけれど、
氏の発言を読み返した限りでは実装技術で困っている様子はなさそう。

しかし要素技術から行き当たりばったりにボトムアップで作ろうとしているらしい。
アクションゲーム向きな作り方だと思うけれど、SLGやRPGには不向きだと思う。

コーディングに入る前に、ゲームに登場させる要素
（キャラクター、ユーザインタフェース、状態遷移図、判定式…）の一覧表を作り、
個別の設計図と全体の工程表を作ってから作業するのがいいと思う。

あと、規模によっては要素設計用のエディタを先に作ったほうが効率的。

**名前は開発中のものです。** · 2011/06/19(日) 17:47:09.16

>>266
今のところ、一番こだわりたいのは、テキストです。
台詞とト書きだけみたいなテキストだとすごくさびしく感じていたので、
うざったくならない程度に、もうちょっと描写を入れてみたいと思っています。

現在、メインシナリオのプロット中。
がんばる。がんばる。

**名前は開発中のものです。** · 2011/06/19(日) 19:54:58.72

まだプロットが上がっていない段階ではアドバイスにならないかもしれないけれど、
テキストで勝負するなら次の2タイプのいずれかを目指すといいと思う。
(Ａ) テキスト中に巧妙に謎解き要素を含ませたフラグ立て謎解き形式
(Ｂ) テキスト自体が文学作品として成立するレベルのデジタルノベル形式
それによって、「こだわる」べき目標が見えてくるかも。

もちろん他のシステムでもいいと思うけれど、たとえば育成系ゲームだと
ゲームパラメータに直接関係しないテキストは追々読み飛ばされてしまうので、
こだわりの方向性が大きく違ってくる気がする。

**SGGK** ◆6pZCoAtaxk · 2011/06/19(日) 23:33:27.48

なんだかスレが伸びてる。
>>265
自分は、やる気の出たときに少しずつ続けるような感じでやっています。
お互い気楽にいきましょう。

今日は、マウス３ボタンについてクリックとドラッグの判定できるところまで進んだ。

**名前は開発中のものです。** · 2011/06/20(月) 12:39:53.64

>269
Ｂの方向を目指して頑張ります。

>270
はい。頑張りましょう！

メインシナリオのプロットが粗方できたのですが、全ルート作っちゃっといたほうがいいでしょうかね。
あんまり長いとダレるので、そこそこの長さに留めてみました。

**SGGK** ◆6pZCoAtaxk · 2011/06/20(月) 23:46:54.40

完成できる事を一度確認して、次から好みで長さを決めるというのもありな様な気がします。

こちらは、ホイール回転によるフィールドの拡大縮小機能の実装がうまくいかない状態…。

**名前は開発中のものです。** · 2011/06/21(火) 00:46:16.91

最初からあまり風呂敷広げすぎてもってやつですね。
とりあえずメインシナリオのテキスト作ってみて、早々にスクリプトの勉強はじめます。

**179** ◆SLG//siTD6 · 2011/06/21(火) 03:13:54.94

>>267
ttp://gmdev.xrea.jp/st/up/356.png

今こんな感じSLGってかRTSぽい･･･ｗ
提督の艦隊の宇宙版？　ホームワールド？みたな感じにできたらいいなぁと。
ターン製はあんまり好きじゃないんでリアルタイムで。
ｼｶｼ、自分でもアクション作るほうが向いてる気はする・・・。
設計図とか書いてないけど･･･やっぱいる？(x｀；

>>273
風呂敷広げすぎてヤバイのがここに！
あ、やべ、全然すすんでない／(＾o

**名前は開発中のものです。** · 2011/06/21(火) 04:50:18.50

>>271
過去に短編小説などを執筆し、他人に読んでもらった上で、
とりあえず作品としては成立しているレベル以上の評価を受けた経験があるなら、
バリエーションルートを含めて考えるのも自由じゃないかな。

そうでないなら、まず、メインシナリオだけに集中したほうがいいと思います。

**名前は開発中のものです。** · 2011/06/21(火) 05:07:11.26

>>272
マウスホイールの回転検出はできてる？
方法はいろいろあるけど、たとえばWM_MOUSEWHEELメッセージを処理する方法があるよ。

３Ｄゲームでパースペクティブビューを使用しているのであれば、
フィールドを拡大縮小するのではなく、カメラの座標を注視点に接近または離脱させればいい。
なお、その際には視点-注視点間の距離を一定値で増減するのではなく、一定率で乗算、除算してやると良い。
（カメラ位置をE、注視点をFとしたとき、E'= F+(E-F)*k or E'=F+(E-F)/k。 kは1.0前後の定数)

**名前は開発中のものです。** · 2011/06/21(火) 05:30:44.83

>>274
設計図については、他人に見せる必要はないので、しっかりしたものを作る必要はないけれど、
手書きメモ程度のもので良いのでノート上で整理してからコーディングに入ったほうが効率的だと思う。

全体的な工程の順序としては、
1.内部設計(ルール、パラメータ、バランスの調整）
2.各要素の実装
3.ユーザインタフェースの実装
4.システム統合
5.各種エフェクトの充実
のような感じ。

まあ179氏の場合、今の進め方でも、特に詰まっている様子はなさそうですが。

**260** · 2011/06/21(火) 13:01:25.60

とりあえずオープニングにあたるシナリオは出来ているので、
いったん吉里吉里/KAGで組んでみます。
いろいろアドバイスありがとうございますm(__)m

**SGGK** ◆6pZCoAtaxk · 2011/06/22(水) 00:06:09.17

>>274
既に色々な要素が画面に出てて進んでそうな感じ。期待してます！
>>278
ＵＰお待ちしてます。自分もＵＰできるように頑張ります！
>>276
自分はDirectXが理解出来なくてＤＸライブラリで頑張ってます。
回転検出は出来てるようで、昨日はGetMouseWheelRotVol()とSetupCamera_Perspective()を使い、視錐台の視野角を変更して拡大縮小するやり方を試みて悩んでました。（ホイール止めても限界まで拡大してしまう）
もう少し考えて無理な場合、カメラを移動する方法で頑張ってみます。ありがとうございます！

**260** · 2011/06/22(水) 00:08:48.05

スクリプトいきなりつまずきましたが、なんとかやってます。
演出も考えながらだと、スクリプト組むだけで、相当時間がかかりますね。
くじけず頑張ります。

**名前は開発中のものです。** · 2011/06/22(水) 12:00:12.23

吉里吉里か、あれは扱いが難しいよね
ちなみにデフォだとNスクリプタの方が高機能というのは知ってる？
だからNスクじゃ表現できないようなら吉里吉里に乗り換えるという順番の方が良いと思うけど

**名前は開発中のものです。** · 2011/06/22(水) 12:04:04.89

>>281
Nスクはライセンスがめんどい

**名前は開発中のものです。** · 2011/06/22(水) 12:11:30.60

>>282
・無料配布であれば企業／個人の区別や配布方法を問わず無料でお使いいただけます。
・雑誌付録にフリーウェア／シェアウェアとして収録する場合は無料でお使いいただけます。
・商業流通作品の販売の際には、使用料を一作につき４０万円いただきます。
・同人流通作品の販売に関しては無料とさせていただきます。
　特に作者（高橋直樹）への報告の義務はございません。

まとめると「商業以外なら無料で勝手に使える」
めんどいか？

**名前は開発中のものです。** · 2011/06/22(水) 12:28:18.65

>>283
使用条件.txt よく読んでみた
結論：めんどい

**260** · 2011/06/26(日) 23:51:24.50

吉里吉里やりはじめた状態でNスクに手を出すと、
いろいろごっちゃになりそうなので、とりあえず吉里吉里で進めてみます。

前回の書き込みから、実はあまり進んでいません。
よくわからないところは飛ばして、全体をとりあえず作ってみることにします。

**SGGK** ◆6pZCoAtaxk · 2011/06/27(月) 23:20:47.45

自分もどちらかといえば、全体を先につくってみたい方です。

拡大縮小の件、ホイール回した時のGetMouseWheelRotVol()の値をマウスのメンバ変数に保持して、
その保持した値を今度はカメラの移動関数でループ毎に足していたので、限界まで拡大縮小してしまっていた。
ホイールを回しているときだけ、足すようにしたら、上手く動いた。
次は、ホイールドラッグで画面を上下左右に動かせるようにしたいけど、最近なかなか作業時間が確保できない感じ。
確保できても動くプログラムが書けるかどうかわからないのが悩むところ。

**SGGK** ◆6pZCoAtaxk · 2011/06/28(火) 23:10:23.97

ホイールドラッグで画面を上下左右に動かせるようにする方法を考えるところまでで今日は終わり。
残り時間が少ないので、実装を後回しにして次の目標のマウス右ボタンドラッグでの回転の方法を考えてた。
ちなみに参考はメタセコイアの操作方法。右ボタンでぐるぐる回して、どういう法則で回してるのか考えてた。

**SGGK** ◆6pZCoAtaxk · 2011/06/28(火) 23:20:58.79

時間無い…と書くのはやめようとなんとなく思った。
もっとこう楽しくやるイメージでいかねば…（汗ｗ
回す法則もなんとなく見えてきた感じ。

**179** ◆SLG//siTD6 · 2011/06/29(水) 01:42:07.29

こっちは全体ってかとりあえず実行出来るもの（最初なら真っ黒のウインドウ表示）作って後はひたすら追加ってな感じかなぁ
やっぱ、動いてる物あると分かりやすいし。
そして良く分からんところはコピペでいいんだｙ（ぇ　初期化とか物理式とか･･･

>>277
なんというか、まさに１を練ってないせいで詰まった、みたいな？ｗ
生産用のウインドウ作ってボタン押したら自分の基地にユニット出すってのはできたんだけど
１　SLGみたいに　生産→プール→編成（グループ？）→出撃　にするべきか
２　このままRTSみたいにユニット選択→生産＝出撃　で1ユニットごとに動かすようにするべきか･･･

たぶん１のが作りたい。しかし、すんげぇ大掛かりになりそうな気がする／(＾

**名前は開発中のものです。** · 2011/06/29(水) 03:32:24.30

>>289
１の実装
class unit; //ユニット
vector<unit*> pool_list; //プール
class group{ //編成（グループ）
vector<unit*> group_list;
};
生産する時はpush_backして
pool_list.push_back(new unit());
編成画面でpool_listの内容を表示する

どういうゲームか知らずにレスしてるので的外れだったらすまんけど
単純に考えてこんな感じじゃいかんのかな？
プールは１つあれば充分、グループは何隊も作るというイメージ

**SGGK** ◆6pZCoAtaxk · 2011/06/29(水) 23:51:37.47

今思えば自分の場合、全体を先に作りたいと言っていたのは、自分自身未知の作業なので作れる自信が無かった為、
作れそうか見極めたいといった目的もあったと思っています。ちなみに全体と言ってるのは、最低限の処理の流れの実装みたいなものです。
全体とか関係なく作れる場合は、好み優先で進んだ方がモチベーションが続くかも。

ホイールドラッグで画面を上下左右に動かせるようになったけど、
メタセコイアみたいにマウスで画面をつかんで動くような感じになってないので、原因調査中。

**SGGK** ◆6pZCoAtaxk · 2011/07/02(土) 01:37:53.85

なんとか上下左右に動かせるようになった。（今日はたまたまこんな時間）
>291では、画面のフィールドが突然ロケットのような勢いで画面外に出て行ってしまったりして、
もうこれが自分の限界かと思った。

ディスプレイ画面上でマウスの示す位置がａからｂまで移動すれば、３Ｄ座標系内のフィールド上の投影位置も
ＡからＢに動くとして、そのベクトルＡＢを算出して、カメラの位置ベクトルと注視点ベクトルに－ＡＢしてやればうまくいくのではと思ってた。
これらの計算を始めた時の最初のカメラの位置をずっと初期値としてベクトルＡＢを計算してループすればＯＫと思っていたのが間違いだったようだ。
毎ループ毎に計算した新しいカメラの位置および注視点ベクトルを次のループでの初期値にするよう書き直したら、
フィールドが飛んでいく不具合が解決！

**179** ◆SLG//siTD6 · 2011/07/05(火) 05:05:11.63

>>290
単純だと･･･よろしいならば実装だ
ttp://gmdev.xrea.jp/st/up/380.png
って、勢いでプールだけ作ったけど、
グループクラス（＆編成画面）実装にはやっぱ色々変更しないとだめぽ。。
あ、VECTORとかよくわからんので適当に配列（POOL[X][Y][PAGE])で実装してます(ｘ｀;
強引にやりすぎて中身がかなり汚い･･･ｗ
どういうゲームか？自分でも良く分かってない／(＾

>>292
ま、まぁカメラ周りは一回作ればそんなに弄ることないから
出来てしまえばこっちのモノサ
行列計算とかもうやりたくないです。ﾊｲ

**SGGK** ◆6pZCoAtaxk · 2011/07/05(火) 23:43:42.69

>>293
カメラ周りはまだ時間かかりそうな感じだけど頑張ります。
実はまだメタセコイアを眺めてて回転の法則が見いだせない状態（汗
横の回転はたぶんこうプログラムすればいいだろうというイメージ出来たけど、
縦の回転はあともう少しで思いつきそうな感じ。

**名前は開発中のものです。** · 2011/07/07(木) 04:17:05.86

メタセコイアの視点操作って、注視点関係なしにワーク原点を基準に
ヨー角ピッチ角の回転と距離だけじゃないかな？

ＣＡＤには適しているけれど、ゲーム用のカメラとしては参考にならないよ。

**SGGK** ◆6pZCoAtaxk · 2011/07/07(木) 23:37:42.40

>>295
ゲームに不向とは気付かずに作業してました。ありがとうございます。
早目にこの段階を終わらせて次いきたいと思ってます。

今日は何も出来なかったけど、いちおう回転だけは土日になんとかしたい気持ち。
縦の回転方法も考えてみたので、今度こそプログラムを書いてみます。

**179** ◆SLG//siTD6 · 2011/07/08(金) 00:03:46.32

１、原点（0,0,0）でカメラの向き（角度X,角度Y,0)の回転行列を作る
２、１のマトリックスから　カメラから原点までの距離（0,0, - 距離）をトランスフォーム
３、マウスでのミドルボタン平行移動は(移動量X ,移動量 Y , 移動量Z（0）)で1のマトリックスからトランスフォーム
４、２と３を足す
５、カメラに各要素をセット（４のposition、角度X,角度Y,0）

３、の　移動量Zの部分はメタセコアではズーム代わりになってると思う。
多分メタセコアのはこんな感じだと思(・ｘ・｀)
色々違ってたらｺﾞﾒﾝﾅｻｲ、と･･･。

**SGGK** ◆6pZCoAtaxk · 2011/07/09(土) 00:04:38.56

>>297
ありがとうございます。昨年末頃３Ｄの本を途中まで読んでて、
それに載っていた座標変換のことを忘れてました。
なのですぐにこれをコードに落とすのはまだ難しいけど、
プログラムのどこかでまた座標変換が必要になる頃には出来るように本を読み直してみます。
座標変換でやる場合、移動量Zを変えた時に注視点をどう変えるとズームになるかがまだ自信ないけど、
本読み直す時に解決出来ればと思ってます。

今日は、マウスの右ボタンドラッグ移動量から画面で回転させたい角度を計算するとこまで出来た。

あとは横回転はＹ軸に対して行い、縦回転は、注視点位置ベクトル（ｘ、ｙ、０）から
カメラ位置ベクトルのＺ成分を０にしたベクトルをマイナスして出来たベクトルを９０度回転してできたベクトルに対して
回転すればいけるかもしれないというあやしい方法を考えてました。（汗

**SGGK** ◆6pZCoAtaxk · 2011/07/10(日) 22:33:55.13

昨日の書き込みで間違いがあった。

縦回転は、注視点位置ベクトル（ｘ、０、ｚ）から
カメラ位置ベクトルのＹ成分を０にした　（略）

が正解。自分のプログラムは垂直方向がＹ方向になってるのが理由。

メタセコイア風に画面内のフィールドを動かせるようになったような感じがする。
直接これをゲームに使う事はないかもしれないけど、いろいろ動かして、カメラの位置を検討するのに使えそう。
>>279でやった拡大方法だと、カメラの座標が変わらずに拡大縮小してしまうので、>>276氏の方法に変更。

次からはボールの動きに挑戦。179氏の>>297も意識して作業の予定。

**SGGK** ◆6pZCoAtaxk · 2011/07/17(日) 22:29:42.21

あまりの暑さなので今日はもう休もうみたいな感じ。
ボールの動きは、ゲーム開始直後に斜め４５°で動きだすようにしてみたら動いた。
次は数値は適当だが重力方向の加速度を考慮した式にしてみたところボールは４５°の角度で天井に向かってくだけで放物線にならず。
合計数時間は悩んだと思うけど、ループ毎にボール位置しか更新してなかったのが原因とわかる。
速度も加速度の影響で毎ループ変化してるので、速度も毎ループ毎に更新するようにしたら放物線のように動いた。
次は地面やフィールドの端でボールが跳ね返るようにすることに挑戦。

**SGGK** ◆6pZCoAtaxk · 2011/08/01(月) 00:12:25.80

時間かかってしまったけど、ボールの跳ね返り実装完了。
ボールの動きは月面歩行みたいなゆったりな動きだけど、これで良しとする。（数値の調整でなんとかできるかも）
179氏>>297のマトリックスを掛けていく方式を意識しつつも、今回も長文プログラムで対応。
（マトリックス作成がまだ自分には理解できてない様なので、勉強しないと無理そうだと今回実感した感じ。）
指定範囲外にボールが出そうになった時に跳ね返らずに壁に沿ってボールが動いたけど、
速度だけ反転して、位置を反転して範囲内に戻してなかったのが原因。
ボールが跳ね返り、跳ね返りの高さが少しずつ小さくなり、最後は転がって止まるようにするのに苦労。
はねてる時の加速度は下向きで、転がってる時の加速（摩擦による逆向きを表現したかった）は速度と逆向きにするというような
加速度の切り替えをどうするかに時間がかかった。
ボールの位置が低い時で判定しようとするとプログラム開始時点で条件を満たして止まってしまう。
放物線の最高点での速度は水平だと思うので、水平になった時のボールの高さがある低い数値より下の場合に、
ボール位置のｙ成分を０にして加速度を切り替えてみた。
水平になった時を知る方法は、速度ベクトル１と速度のｙ成分を０にしたベクトル２の角度がプラスマイナス１度以内ならほぼ水平と判断。
角度はベクトル１と２の内積というものからｃｏｓを計算して判定。
加速度が切り替わって速度が少しずつ小さくなるので、一定値より小さくなったら停止。
…という流れで実装出来て動いてるけど、今後も問題なく動作するかは未知な感じ。
次は>>252
＞３．ラインを割った状態(スローイン、コーナーキック、ゴールキック、得点)を判定し、復帰処理をつくる。
に挑戦の予定

**SGGK** ◆6pZCoAtaxk · 2011/08/06(土) 23:29:11.60

やっぱり、簡単にはいかない予感。問題は時間の管理。
ボールがサイドラインを割ったらスローインする場合、
割った瞬間にスローイン位置にボールを復帰させるのは超反応すぎる感じがするので、
スローイン判定が出て、ちょっとボールが転がって、その後スローイン位置にボールが出現するようにしてみたいと思った。
すると、ボールがラインを割ってから、復帰までのわずかな時間をカウントして、その中断時間中はプレイ時間をカウントしないようにするにはどうすればいいんだという悩みが残る。
対象別に専用の時間を用意しなければならないのかと考えてみたが、それは時間測定対象が増えると大変な作業になる。
結構悩んだけど、時間の処理関数をメンバ関数に持つクラスを作って、必要な関数の数だけそのクラスのオブジェクトを作ればいいかもしれないと思った。
実は３Ｄ座標系でやってる今のプログラムは上記とは異なる理由から運よく時間関係をクラス化してたのでなんとかなるかもしれない。
２Ｄの時はこのクラスが無かった…というか思いつかなくて、３Ｄにするときに色々考えて、ソースを短くしたいという理由から時間関係をクラスにしていた。
時間のクラスには、
void countGameTime();//時間をカウントする。
void resetGameTime();//カウントを０にリセットする
void displayGameTime();//時間を画面表示
のメンバ関数があるけど、新たに
void tempStopGameTime();//カウントを一時停止する
void restartGameTime();//一時停止からカウント再開
を書き加える予定。

上手くいくか確認してから書いた方がいいかもしれないけど、書いてみた。（後で作業を振り返れるし。）

**SGGK** ◆6pZCoAtaxk · 2011/08/17(水) 00:37:25.52

>>252
＞３．ラインを割った状態(スローイン、コーナーキック、ゴールキック、得点)を判定し、復帰処理をつくる。

１週間位で出来ないかなと思ったけど無理だった。
テクニックを持っていないので、if文と状態を表す変数で対応しようとしたらソースがぐちゃぐちゃになってしまった。
ノートに手書きで処理の流れを書いてからプログラムを書いてみたけど、多数の問題が発生。
一つずつ直していき、直してしまったらどんな問題だったのか思い出せないのもあったりする。
覚えている問題は、
（１）テキスト文字が表示されない。
（２）スローイン位置に復帰させたボールをけっても動かない。
（３）ボールを蹴れるようになったけど、その後再度ボールがラインを割っても何故か今度はスローインの処理に移らない。

原因と解決法
（１）原因：「ThrowIn！」のテキストがグラフィックの裏に表示されていた。（フィールドを回転できるようにしていなかったら気付かなかったかもしれない。）
　　　解決法：フィールドを書いてからテキストを表示すればいいけど、やり方を変えて、drawText()というメンバ関数を作り、これをメインループの最後の方に置く、
　　　　　　　元々テキスト描画命令を書いていたところではフラグをセットして、drawText()内に移したテキスト描画命令はフラグがセットなら命令実行するようにした。
（２）原因：３秒経過した？→ＹＥＳ→ボールをライン際にセット　→　ボール状態をＳＴＯＰ　→　ボール状態がKICKKEDか？　→ＹＥＳ　→　ボール移動
　　　　　　という処理にしていたが、これだと、マウスクリックでボールの状態がKICKKEDになっても直前でＳＴＯＰに状態が変わるので、ボール状態がKICKKEDか？　→　ＮＯ　となって動かない。
　　　解決法：かなり悩んだけど、３秒経過した？→ＹＥＳ→m_Set01==falseか？→ＹＥＳ→ボールをライン際にセット　→　ボール状態をＳＴＯＰ　→m_Set01=true;→　ボール状態がKICKKEDか？　→ＹＥＳ　→　ボール移動
　　　　　　にしたら動いた。

（３）←まだ原因不明。

**SGGK** ◆6pZCoAtaxk · 2011/08/17(水) 23:01:09.88

（３）については、ボールの移動はそもそもボールクラスのメンバ関数moveの方で計算されるので、
状態がKICKKEDなら動くようになっていて、状態がKICKKEDになってその時の速度を再計算して直後にMOVINGという状態に移ってしまうように書いていた。
つまり、昨日の「ボール状態がKICKKEDか？　→ＹＥＳ　→　ボール移動」とう処理にはいいつまでたっても進まない。
正解は、
ボール状態がMOVINGか？　→ＹＥＳ　→　ライン判定の状態をリセットする
だった。
コーナーキック、ゴールキックもスローインを参考にして実装した。
これで、
＞３．ラインを割った状態(スローイン、コーナーキック、ゴールキック、得点)を判定し、復帰処理をつくる。
得点以外は実装完了。

次は、
４．選手をまず１人表示し、動かせるようにする。
５．選手とボールの接触判定をし、マウスクリックの代わりに選手が蹴るようにする。
を一緒にやる時に得点実装する予定。

**SGGK** ◆6pZCoAtaxk · 2011/08/19(金) 23:52:19.80

選手を１人だけ移動できるようにした。
今までプログラム内で処理を飛ばしていた部分を飛ばさないようにしただけだけど、
その頃は固定カメラだったので、カメラ座標が変わっても対応できるように修正。
ボールの移動関数のソースをほぼ流用できたので、なんとか出来た。
マウスを選手１人が追いかけ続けるだけだけど、とりあえずはこれで
４番は終了！

**SGGK** ◆6pZCoAtaxk · 2011/09/03(土) 23:32:25.11

たまにしか作業してなかったけど、問題があって進まずの状態。
選手とボールの当たり判定があった時にマウスクリックすればボール蹴れるはずが出来ない。
ボールは選手にくっついた状態で選手と一緒に動く。
しかし、なんどもクリックすればボールも少しずつ動く（これも原因不明）。
選手の移動を止めてクリックし続け、当たり判定ゾーンからボールが出ても
何故かボールが選手と同じ速度と方向で動き続ける。

ソースを読んでも原因全く不明。幸いこのボールを蹴る処理を書く前のところまで
戻れたので、もう一度書き直してみる予定。

**SGGK** ◆6pZCoAtaxk · 2011/09/11(日) 22:22:25.77

自分は作り始めて先月末で４年が経過してしまった…。
スレタイ通りの状況だけど、きっと何処かで作ってると思いながら、
自分も作業継続！

>306を何とかするために実際は8月30日頃から設計図を書くことにした。
大げさなものではなくてノートに手書きの状態遷移図もどき。
これにより、ボールの状態を
enum BALLSTATE{STOP=1,KICKKED,MOVING}; から、
enum MOVE_STATE{STOP=1,FREE,PRE_KEEP,KEEP};に変更してみた。
kickは選手のメンバ関数にした。
なんとなくだけど、当たり判定関数の引数を増やして、そこにフラグ値を入れて
当たり判定の有効無効を切り替えるようにした。

ボールの移動関数はほとんど書き直しになってしまい、試行錯誤の結果、
ボールが選手に付いていくようにはなった。

まだキック関数はうまく動作してくれない。

**SGGK** ◆6pZCoAtaxk · 2011/09/11(日) 22:33:24.95

実はボールの動きはかなり不自然な動きになってしまった。
選手の周りを衛星のようになって動く感じ。
Youtu●eでいろんなゲームを参考にしたけど、早すぎて動きのパターンがつかめなかったけど、
最終的にZEROC●Pというゲームを参考にしてみた。

>307で継続と言ったものの、4年でこの進み具合だとあと何年かかるのだろうか？
それ以前に完成出来るのだろうかという不安もあるので、この先どうなるかはやっぱりわかりません！（汗；

**SGGK** ◆6pZCoAtaxk · 2011/09/11(日) 23:00:52.21

今日はこれでラスト。
別に伏字にする事もないような気がしてきたので、Youtube、ZEROCUP　が正解。

寝ようとしたけど、もう少しだけ作業したらボールをキックできた。

しかし、新しい問題が発生した。

ボールが一度しか蹴れない。
蹴ったボールを拾いにいってもボールが付いてこなくなった。
ボールがラインをはみ出したら試合経過時間が停止し、
ボールをフィールドに投げ込むまでの経過時間表示はされるが、
ボールが復帰位置に表示されない。