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

がんばりましょう。

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

>>1
乙

>>1
(・ω・ )乙　これはポニテうんたら

立てようと思ったら立ってた
前スレって2001年からあったんだな

レイアウト情報の手打ちがしんどいのでinkscapeで作れるようにした。
アニメーションデータは結局手打ちなんで、それほど効率的にはならないんだけど
レイアウトだけでもwysiwygができると違う。

ステータス画面を作ろうと思いステータスを考えていた。
他のゲームを調べてみるとFFTとか女神転生3とかは防御力がなかったり
物理攻撃も斬り・打撃・突きみたいなものに別れていたり色々と奥が深い。
もうそろそろ戦闘システムを考えないといけない時期に来た。

名前が887だとスレが変わったからまぎらわしいなぁ…
どうしよう。

>>1
乙〜！！

思いつく方法は、やっぱり名前付けるかコテハンにするかといったところでしょうか。

進捗はプログラムのファイルをコピーして、名前のバージョンの数字を１つ上げて保存のみ…orz
が…頑張ります〜。

俺もつい最近ゲーム作りを始めた

>>6
お互い頑張りましょ〜！
自分は進捗止まりそうですが、細々とでもやっていくつもりです。

前スレで書いてた小目標、「選手の守備範囲にボールが入ったときにだけ選手がボールを追うようにする」は
ちょっと止めておいて、この前実装した、「前半から結果表示までの流れ」を遷移図のような感じで表現できないかを
試してみる予定。大雑把な遷移図は以前書いてアップした事があったけど、その後の実装は全く別な感じになったので
一度見直してみて、今後の作業の参考になればと思ったから。

ゲ製板の過疎は洒落にならないね
最近製作スレはＶＩＰに移動したりしてるし・・・

スレが簡単に落ちないのはいいことだけど

ローカルルール的に、何もない０の状態からスレ建てして新規企画を立ち上げるわけにはいかないからね、この板
そのせいもあるかと。

>>1
乙です。

前のスレでクォータービューは描画だけで重いと言っていました。どうも僕です。

ＤＸライブラリの仕様を調べていると描画範囲の外はクリッピングとか言う処理がなされて描画自体されないと聞いていて
確かに画像を描画範囲から出すとＦＰＳは安定したので、納得していたんですが
ＣＰＵはあんまり減りませんでした。気づきませんでした。

そこで画面の表示範囲外はDrawGraphを行わないような処理を加えると、かなりぬるぬる動きました。
色々遠回りしたけど結局これだけでそこそこ実用に耐えられそうな性能を発揮したのでこれでなんとかなりそうです。

また、チップを組み合わせたブロックを生成して一つの画像として表示するような仕組みを作って利用すればさらに軽量化できそうです。

外部から参照するファイルというか、文字列って何かと難しそうですけどマップエディタを作れたら作ります。

せっかくなんで今回のテストプログラムを置いておきます。
ゲ製板のアップローダが過疎でなんか逆に恥ずかしいんですけど
ttp://gamdev4.hp.infoseek.co.jp/cgi-bin/up/No_0101zip.html
迷ったあげくおソースもついてます。これでもまじめに書いたんです。

ＦＰＳがふらふらするのは仕様です。けどこのままでいいのかなぁ・・・

俺もＣとＤＸライブラリ使ってる
横スクアクション作ってるけど、重力設定とかややこしいな

OpenOffice.org CalcのExcel 2003 XMLでのエクスポートがバグってる。
しかも結構重要な機能。=1+2が保存できない。
あきらめるかと思って、データ打ち込むのにフリーで楽そうなのないかなあと探していたら
Google Docsを見つけた。しかも、どんなファイルでもアップロードできるみたい。
ソースコードは今 http://github.com/happana/srpg で管理してるけど
データ管理をどうしようかと思っていたので丁度いいかもしれない。
ただ、google アカウント作るのが面倒だなあ。

>>8
同意です。数か月書きこまなくてもスレが落ちないのが救いです。
>>9
確かに。新企画ってなんだか難しそうなイメージあります。
>>10
動き見れました。チップがスムーズにスクロール出来てました〜。
>>11
自分もＤＸライブラリです。重力っぽい動きにはサッカーゲームでもいつか挑戦してみたいです。

今日は>7での作業を少しだけ。持続力が無くて少しずつの作業になってしまってます。
ソースもちょっと考えてみます。

一人でがんばるならスレたてないでずっとひとりでやれよ

積読してたGame Programming Gemsを久々に見てみたら結構役立つ情報があった。
１だけ持ってるんだけど、今はいくつまで出てるんだろう。7？
参考になるけど全部買うのは無理だ…

>>15
洋書でもいいなら
Best of Game Programming Gems

>>12
Google Docs、ググってみました。エクセルで書いた遷移図を共有するような使い方も出来るような雰囲気。
>>14
アンカー付全レスでプログラムが進んでないと、そう思われてしまうかもしれないけど、やる気維持に役立てています〜。
>>15、16
Gems、難しそうで立ち読みすらしなかったけど今度見てみようかな…。

ソースの件、以前は付けてたけど過去に指摘があって付けなくなってました。
でもたまにはという事で先日ｕｐしたＳＧＧＫ０１９のときのソースを載せておきます。
清書しようかと思ったけど、そのままの状態でアップしてます…。
ttp://gamdev4.hp.infoseek.co.jp/cgi-bin/up/No_0102zip.html

…という事で自分もちょっと考え直して、プログラムに少し進捗があったら書きこむみたいな感じで
不定期登場、レスもその時のタイミングに応じて書いたり書かなかったり…みたいになるかもしれないです。
でももちろん全部見てますのでよろしくです〜。では…。

>7の作業は今日も終わらず…。

やばい、完全に行き詰った。
戦闘時のコマンド実行の実装の仕方が思いつかない…
色々とごちゃごちゃになってきたんで、戦闘部分だけCUI版とかで別プログラムを一から書いてみようかな。
一番大事な部分なのに…振り出しに戻った…

ttp://github.com/happana/tatara
戦闘システム実装練習用に新たにプロジェクトを作った。
こっちはグラフィックは文字だけになる予定。
ある程度目処が立ったらSRPGと統合する。

皆さんは今のプログラミングレベルに到達するまでどれくらいの時間かかりましたか？

どうも、クォータビューのマップエディタを作ろうにも何から手をつけていいかわからない僕です。

887先生とSGGK先生のおソースを拝見しました。

あらゆる書籍を持たず完全独学なんで非常に参考になります。
僕がやたらレベルが低いので理解にまでは至りませんけども

別のスクリプト組み込んだりとかクラスオブジェクトを使いこなしたりとかは雲の上の話です。


書籍とか形のある知識を持ってないとこういう得た情報をどこにしまったか忘れてしまうんで
サーバを使わないローカルで動く超個人的wikiみたいなのがあったらいいな

と思ってたらありますね。世界は広いっす。
たくさんあったけれど「ひとりwiki」がまさしくこのスレにぴったりな名前なんで
これで最終的にはゲーム製作の虎の穴として書籍になってウハウハ


マップチップのひし形部分とマウスの当たり判定をとりあえず実装するために
クリックボタンのクラスを作りました。
これを継承して例えばスタートボタンにしたり
マップエディタでクリックでチップを置いたり
そういう方法で正解なのかしら？クラスはよくわかりません。

>>21
ロベールのＣ＋＋教室という有名なサイトを見ながら
１週間でＣ言語のポインタまで理解したつもりでしたが半年たっても使いこなせないです。

>>21
Cから始めて大体分かったなと思うまで1年
その後C++に移行しつつ
- STL, template 周り
- Windows API
- オブジェクト指向
同時並行な感じで1,2年。
これから後はあんまり成長してない気がする。
プログラム勉強しだして8年くらい。

何歳ですか？

アラサー。
多分このスレ一番の年寄りだろう。

>>21
・最初にRPGツクール5を高校時代に
・社会に出てからRPGツクール2000へ
・ツクール投げてHSPを半年使う
・HSP投げてC++を勉強〜二年で今に至る

ポインタやクラスあたりはもう無くてはならない存在。STLも超基本にだけ触れた程度かな
クラスは構造体の延長みたいな感じで使ってる。

連投になるけど21歳

本も買わずに他人のソース参考とか思いっきり他者依存じゃねえかｗ

>>16
そんな本が出てたんですね。調べてみます。

>>22
先生とかめっそうも無い。
ポインタは最初の1歩で1ヶ月くらい悩んだような気がする。
1. 値渡しとポインタ渡しの使い分け。(これが分かるまで1ヶ月くらいかかった)
2. 配列&ポインタ、構造体&ポインタの理解。
3. 双方向リンクが作れるようになる。
くらいの段階を踏んでだんだんと理解していったような気がする。

2とか分かってくると a[1] は *(a + 1) のシンタックスシュガーみたいなもんだから
a[1] == *(a + 1) == *(1 + a) == 1[a] で 1[a] とかでもコンパイルできることが面白かったりするんですよね。

>>28
個人的には意見交換とか参考にするのはOKだと思うんですけどね。
一緒に作りませんか？みたいなのはスレ違いな気がしますけど。

ソースのＵＰもこのスレでは意見交換みたいな雰囲気だし、同じくＯＫ〜！と思います。
それにソースを解読できるのって凄いと思います。（自分は解読とか全然出来ないし）

時間については２００７年の８月頃にこの板の某スレに書き込んだのをきっかけに開始。
１４歳のＣ＋＋本のサンプルを改造するために最低限の知識をＣとＣ＋＋の文法書で調べただけで、
プログラミングにあまり詳しくないので、いつどうなるかわからない状況でバグを取ってます。

ソースコードの整理とか設計をするついでに Google Docs でドキュメントを書いている。
武器やアイテムの仕様やプログラムの設計ことも書いている。
なかなか使いやすくていい感じ。

エクスポートも出来るので PDF でアクター周りの設計を書いたものをアップしてみる。

ttp://gamdev4.hp.infoseek.co.jp/cgi-bin/up/No_0103pdf.html

ここらへんの設計。
ttp://github.com/happana/srpg/tree/master/srpg/

プログラムが進まなくてもドキュメントを書いていると進んだ気になる！不思議！

工学図書（株）の「これでわかった　C言語ポインタの活用」
という本がポインタ理解に役立った
書籍や技術サイトじゃ個別の疑問は解決し切れないので
直接指導してくれる人がいるのが最善だけれども

おはようございます。クォータービューに対応したマップエディタを作ってます。僕です。

>>29
1はそこそこ程度に使えるようになりましたけど
2. 配列&ポインタ、構造体&ポインタの理解。
3. 双方向リンクが作れるようになる。
ここからですね。
構造体は毎回エラーの壁を越えられないんで避けてます。さらにポインタまで考えるともう・・・


すでにＤ＆Ｄが出来るクラスを作ってしまいましたが、
思い切って１度構造体でデータを作って動作を妄想しながらクラスにすべき物としない物とに分ける手法を考えて実践してみました。
データ主体という言葉を愚直に捉えた発想なんですけど悩みすぎて気づいたら朝チュンです。

当たり前ですが座標を持つものは座標をデータとして持っていないといけないわけで座標を構造体にして
そこから肉付けして画像データ構造体や範囲データ構造体を追加して
それらを用途別に組み合わせた物が「実体を得し者」、オブジェクトとして活躍する仕組みなんですけど

妄想しながらデータを作っている段階で
別のオブジェクトの座標や種類みたいなのを取得するような動作や
オブジェクトを動的に配列に格納できないとうまく動かないみたいで
どうやらここで高レベルなポインタの出番のようです。さらに多分コンテナみたいなのも使わないとダメっぽいです。
でもこれで思い通りの操作になればマップエディタどころかちょっとしたファイラすら作れそうな勢いです。嘘です。

朝チュンまでして詰むのは悔しいので一旦開発はストップしてポインタのおさらいとＳＴＬをまじめに学ぶことにします。

簡単な状態遷移って switch でやることが多いと思うんだけど
決まった順序で遷移する状態を switch でやると流れが分かりにくい。

int state;
switch(state) {
case IN: in(); break;
case LOOP: loop(); break;
case OUT: out(); break;
}

IN->LOOP->OUT の順番は決まってる。

in();
while(is_loop()) {
　　loop();
}
out();

みたいに書けないかなと思っていたらこんなの見つけた。
ttp://f3.aaa.livedoor.jp/~gsyoku/index.php?[[Fiber]]#content:3

機能をゴリゴリ削って使うところだけ自分なりに実装してみた。
ttp://github.com/happana/srpg/blob/master/srpg/base/flow.hpp
ttp://github.com/happana/srpg/blob/master/srpg/scene/battlescene.cpp#L36

C言語習いたての俺がSRPG制作に挑戦してみる。

・・・って企画たててよかったのか？

>>35
企画ってのが何のことを言ってるのか分かりませんが、
がんばりましょう！

うん。なんか勘違いしてたorz

さて、AVD×SRPGな感じで作っていきますよっと。
何すればいいかよくわからんがスクリプトエンジンを作ればいいのかね？

ちびちび作っていくのでよろしく。

>>16さんが教えてくれた本が届いた。

プレイヤーと敵のダメージ、死にモーションを作った。
あと1ヶ月くらいで「たたかう」を選んで殴りあえる位までは出来そうな気がしてきた。

P0がE0に攻撃。P1がE1にスキルAで攻撃。みたいな各コマンドを
貯めて後で順番に実行するって仕組みを作っているんだけど
実行する段階で対象がすでに死んでいた場合の対象の再検索とか結構面倒。
後、敵のAIをどうしよう・・・Luaとかのスクリプトを使うのが一般的なんだろうか。

ttp://github.com/happana/srpg/downloads
SRPG version 0.0.12

戦闘のコマンド実行とダメージ処理の追加。
全員、自動で「たたかう」を選んで実行するだけです。
細々としたところでモーションの追加とか武器の追加とか。

これから、コマンド選択UI、ゲームオーバー処理とかを作る。

>>34,>>40
戦闘シーン確認出来ました〜。
サッカーゲームの遷移も前半→ハーフタイム→後半は一方通行で似ているかもしれないので、参考にしてみようと思います。
>>35
ど〜ぞよろしく〜！

こちらは進捗が思い通りにならなくて、これはもしかするとソースをＵｐして
なんとなくホッとしてしまったからかもしれない…と自己分析していた矢先に来月の１５日頃予定で転勤が決まりそうな感じ。
もしかすると最低でもこの前後１カ月ぐらいは落ち着かないと思うので進捗が無いかもしれない予感。

次の日になって自分の書き込みを見るとなんだか赤面な感じ。
別にフェードアウトするフラグでは無いので…（汗）。
一応>>7をやって頭の整理をするところまではやらねば〜！。

ttp://github.com/happana/srpg/downloads
SRPG version 0.0.13

バトル時のコマンド選択など追加。後ダメージも武器の値を使うようにした。
カメラの制御が難しい。

なんかモチベーションが下がってきて駄目な感じになってきた。

>>43
RPGな気もするが、動作はちゃんとできている。
まだ製作序盤だと思うが、クリア、全滅があると面白いと思う。
洞窟にゴール地点を作ったり、敵を強くしたり。

>>44
ごめん。SRPGって書いてるけどRPGなんだ。
SimpleなRPGってことでSRPGにしたら、シミュレーションRPGとかぶっちゃったんだ。

分かった。全滅とか作ってみる。
ちょっと敵も増やしてみようかな。
意見もらえてモチベーション上がった。ありがとう。

久しぶりに書き込み。
887氏、もしかして開発中止だろうか。
再開して戻って来れるように、こちらの進捗０でも何か書いてみる。
自分の方は２か月の空白を作ってしまい、>>42で辞めないと言ったものの、開発続行はやはり怪しい。
とりあえず、>>42、>>7で言った頭の整理は時間が掛かりすぎるので中止。
ゲームのメインの部分で前半、後半で同じような内容が書かれてあり、
長すぎてわかりにくい感じがするので、少し改善できないか考えてみる予定。

や…やめた。>>46で言ったソース改善も中止〜！
バグが出てるわけでもないし、わかりにくくてもなんとかソースを読むこともできるから、
整理に時間をかける程でもないなと思った。
とりあえずこのままにして、前スレで言っていた以下の目標をやってみる。

>967 ：SGGK ◆6pZCoAtaxk [sage]：2010/04/27(火) 23:03:19 ID:puWvjObW
>次の小目標は、
>今まですべての選手が一斉にボールを追いかけていたのをやめて、
>ＦＷは前１／３、ＭＦは中１／３、ＤＦは後ろ１／３の範囲にボールがある時だけ
>ボールを追いかけるようにプログラムを直す。
>…にしてみる予定。

ということで、取り組んでみたものの案の定うまくいかない…orz
まず、メインループの中にある選手の移動関数について。
移動関数の中で今が前半か後半かを判断する変数を使えるようにしたいけど、
いまのままではおそらく使えないと予想。
現在のプログラムは、選手関係の変数や関数をひとまとめにしたクラスの
オブジェクトをゲーム処理を主とした関数内に作ってあり、そのオブジェクトのメンバ関数で選手移動処理をするようになってるので、
ゲーム処理を主とした関数で定義した変数を認識させるにはたぶんその変数のアドレスを渡さなければいけないと思い、
とりあえず、
１．選手関係の変数や関数をひとまとめにしたクラスを宣言してるヘッダファイルに「前半か後半かを判断する変数」を
定義してる別のヘッダファイルを加える。
２．選手関係の変数や関数をひとまとめにしたクラスを宣言してるヘッダファイルの中の
選手移動処理の関数の引数に「前半か後半かを判断する変数」を追加する。
３．選手移動処理の関数の定義がfieldplayercontrol.cppの中にあるので、
これにも同様に「前半か後半かを判断する変数」を追加する。

ここまで書けば関数の中身を後回しにしてもコンパイラは通るはずだと思い、
コンパイルするとエラー。

error C2146: 構文エラー : ';' が、識別子 'fieldplayercnt' の前に必要です。

運よくバグは取れたけど、詳細は進まない作業の代わりにネタおよび自分の作業メモとして少しずつ書く予定。
てっきり、また全角の空白をどこかに入れてしまったのかと思ったが、そうではなかった。
知ってれば一瞬なのに何時間か掛かってしまい、これがプログラムのしんどいところ。

もうサッカーの人しかいないのかな(ヽ´ω｀)

ゲーム仕様でどうしても2Dでは実現しづらい部分が出てきたので3Dに移行。
サンプルプログラムで大体どんな感じに組めばいいかはわかったのでモデル製作の勉強開始。
モデリングソフト高すぎワロタ…のでBlenderを使うことに。

>>49
こんばんは！。見ている人がいるからには、諦めずにもう少し頑張ってみようと思います。
自分もいつかは３Ｄをやりたいと思っているので、Blenderの事は記憶に留めておきます。

>48のバグは、最初「error C2146: 構文エラー : ';' が、識別子 の前に必要です。」で検索したところ、
その中で、「変数宣言の位置によってエラーになったりならなかったり ...」という言葉が目に付き、
ソースを見たところ、ヘッダファイルの左端の縦棒が太く表示されていて何かここに問題のあるしるしなのかと思い、
考えてみると、今回、選手の移動関数の引数として読み込ませたいと思っている変数は、

enum MATCHSTATE{
FIRST_HALF=1,HALF_TIME,SECOND_HALF,RESULT_DISPLAY
};

で、これはsoccergame.hで宣言されてて、しかし、選手の移動関数は
fieldplayercontrol.hで宣言されているので、ならば、fieldplayercontrol.hの上の行に
#include "soccergame.h"をいれてやればいいのではと思ってそうした。
しかし、先ほどのMATCHSTATEはクラスなどの外側に記述してあるので、コンパイルしたら、
soccergame.hと#include "soccergame.h"したfieldplayercontrol.hとで重複してしまうのではと思い、
#include "soccergame.h"を消したら、コンパイルできた！…という話。

>>47（前スレ>967)の目標完了。珍しく予想以上に早く出来た。
ソースはifとswitchの組み合わせなので長文になってしまっているのが相変わらずの難点。

次の目標は、出来れば走ったり、ジャンプをさせたりとかいろいろ思いつくけど、

選手それぞれの近くにライフゲージを表示させて、ライフが少しずつ減り、０になったら
選手が停止する

に挑戦。

>>50
つまり・・・どういうことだってばよ

いやすまん、偶然スレ覗いたら気になったんでちょっと質問させて欲しい
enum A{};
enum A{};

void main{}

例えばこう書くと、VisualC++では「error C2011: 'A' : 'enum' 型の再定義」っていうエラーになるんだけど
>>50の下6行で言いたいのは、こういう事とは違うの？

> >>50の下6行で言いたいのは、こういう事とは違うの？
そうです。その通りです。
「選手移動処理の関数」に「前半か後半かを判断する変数」つまり
enum MATCHSTATE{
FIRST_HALF=1,HALF_TIME,SECOND_HALF,RESULT_DISPLAY
};
を引数として持たせたい。
でも、この「前半か後半かを判断する変数」の宣言は、soccergame.hにあり、「選手移動処理の関数」の宣言はfieldplayercontrol.hにあるので、
fieldplayercontrol.hの中でsoccergame.hを#includeしなければ、引数として認識できないかなと思った。
でもそうするとfieldplayercontrol.hとsoccergame.hの両方に
enum MATCHSTATE{
FIRST_HALF=1,HALF_TIME,SECOND_HALF,RESULT_DISPLAY
};
があるので、コンパイルしたときに
enum MATCHSTATE{
FIRST_HALF=1,HALF_TIME,SECOND_HALF,RESULT_DISPLAY
};
enum MATCHSTATE{
FIRST_HALF=1,HALF_TIME,SECOND_HALF,RESULT_DISPLAY
};
void main{}
と２重になるので、
C2146: 構文エラー : ';' が、識別子 'fieldplayercnt' の前に必要です。
というエラーが出てるのかと思った。

しかし、>>52氏の指摘が気になり、試しにfieldplayercontrol.hに
enum MATCHSTATE{
FIRST_HALF=1,HALF_TIME,SECOND_HALF,RESULT_DISPLAY
};
だけを直接書きこんでみると、
error C2011: 'MATCHSTATE' : 'enum' 型の再定義
というエラーが出た。
自分が思っていたバグの原因は間違いで、
>>50で
>#include "soccergame.h"を消したら、コンパイルできた！
ときのコンパイルできた理由はほかにあるらしく、
しかもenum MATCHSTATE{略};は問題なく認識されていたらしい…orz
（>>52←指摘ありがとうございます！）

「error C2146: 構文エラー : ';' が、識別子 'fieldplayercnt' の前に必要です。」というエラーメッセージが出る原因について調査。
#include "soccergame.h"で発生したバグだから、そのsoccergame.hの中に';' が抜けてるところがあるのかと思ったが、良く見たけど見つからない。
他のヘッダーファイルに#include "soccergame.h"をやってコンパイルすると、
「error C2146: 構文エラー : ';' が、識別子 'fieldplayercnt' の前に必要です。」
が出る。"soccergame.h"に何かあるのか…。
もしかするとヘッダーファイル2重読み込み防止（いわゆるインクルードガード）の書き方が
"soccergame.h"だけ何かの作業でずれたか消えたかしてたか？と見てみたがなんともない。
ためしに「ヘッダファイル 2重読み込み」で検索するとやっぱりこれといったのが無く、しかし、
その中に「ヘッダーファイルは慎重に扱わないと危険です」という言葉が目に付き、
クリックすると内容が難しすぎて解らなかったけど、雰囲気的に「循環参照」というのが気になる。

自分のソースを見てみる。
fieldplayercontrol.h　に　soccergame.h　をインクルードしたときを考えてみる。
soccergame.h　は　#include "fieldplayercontrol.h"　してるので、
お互いがお互いをインクルードしあってる。
念のため、soccergame.h　がインクルードしてないヘッダーファイルにsoccergame.hをインクルードしてみる。
これなら循環じゃないから、バグが出ないはずだと思ったが、
バグが出る場合と出ない場合がある。
バグが出ないと予想したのにバグが出たヘッダーファイルは、もしかするとsoccergame.hのインクルードしたヘッダーファイルからまたヘッダーファイルが呼ばれてて…のような感じで呼ばれていたのかもしれないが、調べきれず。
さらに
error C2146: 構文エラー : ';' が、識別子 の前に必要です。 　ヘッダーファイル　循環参照
で検索してみると、掲示板関係ばかり引っかかるけど、どうも循環参照が原因の可能性が高い。
「ヘッダーファイル内でのインクルードはできるだけ避けたい。」という書き込みもあるし。
仮に循環参照が原因として何故、「error C2146: 構文エラー : ';' が、識別子 'fieldplayercnt' の前に必要です。」というメッセージになるのかわからないけど、
とりあえずヘッダーファイルをインクルードしているうちに循環参照になっていたのが原因の可能性が一番高いと考えて、
>>51の課題挑戦を再開。

('A`)

ふむふむ


まずヘッダーの重複読み込みを気にしているようだけど、「#pragma once」は記述している？
ちなみにマクロを使って同じ事も出来る
ttp://www.geocities.co.jp/SiliconValley/6071/technic/16.html


そして「error C2146: 構文エラー : ';' が、識別子〜」は、行数を特定しにくいエラーの一つだけど
これを発見するには、デバッグの基本技の一つ「コメントアウト」が有効

例えば、以下のように４つの関数があったとする
void A(){}
void B(){}
void C(){}
void D(){}

このCとDをコメントアウトしてコンパイル
void A(){}
void B(){}
/*
void C(){}
void D(){}
*/
これでC2146エラーが消えたようならCかD、残るようならAかBに絞り込める
消えた場合Cだけコメントアウトすれば、特定の関数まで絞り込める

この方法を使えば、例えば５００行のソースが書かれている場合
その約半分２５０行くらいから下をコメントアウト、さらにその半分、さらにその半分・・・と機械的に絞り込む事が出来る

インクルードガードでｇｇｒｋｓ

>>59
>>52
インクルードガード関係ない可能性が高い

>>57>>58>>59>>60
たぶんまだ正解ではないんだろうなという雰囲気が伝わってきたので、再考。
まず、>>58氏の#pragma onceを試して、もう一度soccergame.hをfieldplayercontrol.hにインクルードしてみたがやはり同じバグが発生。
でも、#pragma onceなら1行で、しかも同じ書き方でインクルードガードできるから便利。（感謝！、絞り込みも活用します。）
次に昨日書いた循環参照について。
soccergame.hをfieldplayercontrol.hにインクルードした時、soccergame.hの中では、FieldPlayerControlクラス型の実体を定義してるけど、
fieldplayercontrol.hの中でSoccerGameクラス型の実体を定義してはいないから、循環参照ではなかったかもしれないという気がしてきた。
お互いをインクルードしあってるだけでは循環参照に必ずしもなるとはいえないかもしれない。自信はないけど。
そこで、soccergame.hをfieldplayercontrol.hにインクルードした時のfieldplayercontrol.hの中身はどうなっているのかソースにして追いかけてみようとふと思った。
ひとつ気になった。
soccergame.hはその中で#include"fieldplayercontrol.h" してるので、soccergame.hをfieldplayercontrol.hにインクルードしたら、
fieldplayercontrol.h　の中で　#include"fieldplayercontrol.h"されるのだろうか？
なぜなら、もともとのfieldplayercontrol.hは、#include"fieldplayercontrol.h"なんてしてないから、インクルードガードされないんじゃないかなと思ったので。

そこで、「ヘッダファイルに同じヘッダファイルをインクルードできるか」のようなキーワードで何度か検索。

「ヘッダファイルは、自分とは別のヘッダファイルを #include でインクルードできるので、（略）」　という記述があったので、

それ前提でソースをエクセルに張って考えてみたら、自分としては今までで一番正解に近そうな答えが出た。
soccergame.hをfieldplayercontrol.hにインクルードしたときにsoccergame.hの中にある#include"fieldplayercontrol.h"がキャンセルされていたら、
soccergame.hからインクルードした部分の処理を進めているときは、まだFieldPlayerControlクラス型が宣言されてないから、
soccergame.hからインクルードした部分にFieldPlayerControl fieldplayercnt;
と書いても、
「error C2146: 構文エラー : ';' が、識別子 'fieldplayercnt' の前に必要です。」
というエラーが出る…というのが答えかもしれない。

一応、エクセル→jpgでうｐ
ttp://gamdev4.hp.infoseek.co.jp/cgi-bin/up/No_0129.jpg

3Dの勉強が楽しい
忘れていたわくわく感があふれてくるっ
知らない用語がどんどん出てくるこの冒険感っ

練習ソフトクリーム
http://www.dotup.org/uploda/www.dotup.org1057678.jpg

３Ｄ、色々な事が出来そうですね。
自分もサッカーゲームの３Ｄ化を目指して開発を急ぎたいです。

>>51の課題に挑戦。
ソースはまだ書いてないけど、選手クラスにライフ値を記録するためのメンバ変数を追加して、
選手の描画関数を実行するときに選手の座標を基準にＤＸライブラリの四角形描画関数を２回使重ね書きして実現できないかなと脳内設計。
ライフ値をソースのどこでどのくらい減らせばいいのかを検討中。

>>51の課題が終了。
ライフ値は、各選手が移動関数を実行した直後に少しずつ減らすようにしておき、
「　現時点のライフ値／最大ライフ値ｘライフゲージ最大長さ　」を計算して長方形をその長さで描画する。
減り具合は完全ではないけど、今は調整する予定なし。

次の目標

●共通（ゴールキーパー以外）
（実装済）歩く　Z＋マウス操作
　　　１　走る　X＋マウス操作
　　　２　進行方向固定　Shiftキー
　　　３　特殊技術（ボールが頭上ならヘディング、足元ならダイビングヘッド）　Spaceバー
●ボールキープ時
　　　４　ジャンプ（タックル避けにもなる)　C
　　　５　ロングパス　左クリック
　　　６　ショートパス　右クリック
　　　７　シュート　左右同時クリック
　　　８　パス/シュートは，押す長さで強さを調整
●非ボールキープ時
　　　９　タックル　左クリック
　　１０　カット　右クリック

これらの内６個でも実装できれば上出来と考えて挑戦する予定。
期限を決めてやるのは無理そうな感じ…orz

そして誰もいなくなった

Blenderの仕様でいろいろ不都合が出てきたのでメタセコイアにのりかえ中

>>66
アクセス規制が続いていて、実は現在も書き込めない状態でご無沙汰してました。
メタセコイアはフリー版あるらしいので、ドットが不得意な自分もいつかは触ってみたいソフトです。


３〜４週間の2chアクセス規制が頻繁にあり過ぎて製作活動ペースが落ちてくるので（言い訳）、
運営の思う壷かもしれないけど、試しにｐ２とやらで今日から１年間だけ書き込めるようにしてみた。

肝心の進捗の方は思わしくなく、>65の目標をみると、今のゲーム画面は視点がおかしいので悩む。
フィールドは真上から見てるのに、選手は真横から見た絵になっている。
蹴ったボールをいずれは曲線を描くようにしたいけど、この画面ではそれを表現するのが難しい事に気づく。
そしてボールの座標は（ｘ，ｙ）だけでは足りなくて（ｘ、ｙ、ｚ）にしておかなければな後々不便な事になるような気がしてきた。

これはベクトルの表現を取り入れたプログラムに書き直しておいた方がいいかなと思い始めたところ、
偶然手元に「１４歳からはじめるわくわくＣ言語プログラミング教室ＶＳ２００８編」という本があり、
運よくこれの第３章がベクトルの説明をしていたので、読んでみることにした。
もう少しで読み終わるけど、解り辛い…。

昨日の書き込みを見て、思う壺という言い方が紛らわしい表現になりそうなので消したくなってきた。（赤面）
書き込み規制の原因は荒らしをする人にあるわけだから。

とりあえず３章だけを読み終えた。
明日も時間が出来ればベクトルを取り入れたプログラムに書きなおしてみる予定。

ソースをコピーして数字を一個上げた名前に変更してから作業を始めようとしたけど早速悩む。
参考にした本はＣで書いてるので、Ｃ＋＋でオブジェクトを複数種類作っているようなプログラムにどうすれば使えるか思いつかない。
とりあえず、「Ｃ＋＋、移動、クラス、ベクトル」で検索してみたけど、いまひとつ。
Ｃ＋＋には、例えば　ベクトル＋ベクトルの結果がベクトルになるような意味を持てるように
　＋　の意味を定義しなおす機能があるようなので、これかなと思ったけど、あまりにも内容が難しいので、諦める。
次に考えたのは、例えば　vector3.h　のような名前でヘッダーファイルを作り、その中に

struct Vector3{
float x,y; //とりあえずｚ無し
};

と書いておいて、ベクトルの必要なクラスの定義があるヘッダーファイルに　#include "vector3.h"　すれば外部の関数扱いになってすべてのクラスから使えるんじゃないかなと思った。
確認のために#include "vector3.h"したあるクラスの定義の中で、
Vector3 POSITION_XY={1,1};
としてみたらエラーになるので真っ青になる。（他にもう方法が思いつかないから）
しかし、
Vector3 POSITION_XY;
と書き直したら、コンパイラが通った。
クラスの定義の中では初期値を書けないのをすっかり忘れていた。
思い出せたのは運が良かった。

とりあえずベクトル関係の変数と関数を宣言したヘッダーファイル、vector3.hと
それらの変数や関数を定義したファイル、vector3.cppを作成してみた。
とは言うものの、中身は変数を３つ持つ構造体とその構造体の型を持つ変数を引数にもつ関数で
関数は、

ベクトル＝ベクトル＋ベクトル
微小時間後の位置を示すベクトル＝現在の位置を示すベクトル＋微小時間ｘその時点での速度を表すベクトル

の２式だけ。
この微小時間がいわゆるフレームタイムであり、今までのプログラムだと
メインループ関数の中で、ＤＸライブラリのScreenFlip()関数を３０回ループしてその平均を
フレームタイムとしてる。ScreenFlip()関数は画面のリフレッシュレートとやらと同期して動くらしいので
そういうやり方でフレームタイムが計算できるらしい。
でも、これだとメインループ関数の外側で宣言・定義されてる微小時間後の位置を示すベクトルを計算するための
関数に必要な微小時間（フレームタイム）が読み取れないと予想。
とりあえず、３０回ループする部分を関数にして、vector3.h、vector3.cppで宣言・定義して、
その３０回ループする部分を関数にしたのをメインループで呼び出してなんとかできないかと思ったところで終了。

>>69
>　＋　の意味を定義しなおす機能があるようなので、これかなと思ったけど、あまりにも内容が難しいので、諦める。

class Vector3{
public:
float x;

Vector3(){}
Vector3(float x_) : x(x_){}
Vector3 operator+(Vector3 &obj){
return Vector3(x + obj.x);
}
};

class A{
public:
A(float x) : vec(x){}
Vector3 vec;
};

void main(){
A a(1),b(2);
a.vec = a.vec + b.vec;
cout << a.vec.x << endl;
}

こういう事？
operator+はその性質上、returnで新しいクラスを作る必要があるから処理速度の面で微妙
俺だったら使わない

>>71
す…凄いです。そうです！そのoperatorがなんとかというそれでした。
まだ自分は答えを見ても何がわからないかもわからない初心レベルですが感謝します。
処理速度が微妙であるとのコメントを参考にして、なんとか>70のやり方（Ｃ言語風？）でやれるよう頑張ってみます。

>>70の下から４行に書いたやり方は諦める事にした。
vector3.hにfloat frametime=0;と書いてコンパイルすると
frametimeは既に定義されてると言う内容のエラーが続々発生。
これは、vector3.hがいろんなcppファイルのヘッダーファイルにインクルードされてるからだろうと予想。
float frametime;と書き直しても同じ結果。初期化の有無は関係なかった様子。
vector3.hの中でfloat frametime;と書いておき、他のcppファイルでframetimeを使いたい場合には、
そのcppファイルのヘッダーファイルでなく、cppファイルの上の方の行でextern float frametime;と書いたら直った。
たぶんこれでframetimeは外部変数扱いになってどこからでも使える変数になったかなと思うけど、
ベクトル計算の関数定義の中で使おうと考えているframetimeの値が外部変数として渡すやり方だと
なんとなく後々の問題になりそうなので、ベクトル計算用関数の引数を増やして、その引数に値経由でframetimeを渡せないかと考えて終了。
そして、frametimeの外部変数化も中止。（あまり進まず。）

・Vector3.hのクラス定義内にて、 static float frametime;
・適当なcppにて、float Vector3::frametime=初期値;
ということがしたいのかな？

>>74
その通りです。
ただVector3.hでは、クラスの宣言や定義はしていなくて、ベクトルを表す構造体などを引数にしてベクトルを表す構造体をreturnする関数を宣言するのみ。
そうすればベクトル関係の関数は外部関数になってどのcppファイルからでも使えるかなというのを期待して書いてます。
そしてVector3.cppでその関数の定義をしようとすると関数内のframetimeという変数がメインループで計算するframetimeと名前を同じにしても
このままでは中身が別物なはずなので、Vector3.hかframetimeを使うcppファイルのどこかで1度だけ
frametimeを定義して、他の残りについては、extern float frametime;とすれば動きそうだと思ったわけです。
externにしたのは、cppファイルが複数あるからstaticよりこちらがいいかなと思っただけであまり自信無し。
「extern　static　違い　Ｃ言語」で検索するとろいろ出てきて読むと自信無くなってきたけど
なんとかトライしてみます。

いままでのプログラムをベクトルを表す構造体で表現する変更作業の開始。
とりえあず先にヘッダーファイルだけを変更する予定。
しかし、ヘッダーファイルを変えただけでコンパイルすればcppファイルの方でエラーが出るはずなので、
ヘッダーファイルを全部コピーしてファイル名の前の方にv_を付けてファイル名を変えた方で変更作業する。
そうすれば、cppファイルと矛盾してエラーが出るという状態を避けられるはず。
そしてヘッダーファイルの変更が終われば、古いヘッダーファイルを削除して、新しいヘッダーファイルのファイル名からv_を取り除いて、
今度はcppファイルを直す。
変なやり方かもしれないけど、やってみる。

ヘッダファイルを４個書き直した。
あと12個残ってる。

今日も４個しか出来なかった。
cppファイルを直す時に泥沼状態になる事を予想して、
変更箇所を表計算ソフト（エクセルのこと）にメモしながら進めてるから作業が遅いのかもしれない。

ヘッダファイルあと残り１つ。
これは選手の移動関数を定義してるファイルだけど、気になる箇所があった。
今のプログラムは、どのような速度のパソコンでも６０Ｈｚで１フレーム時間あたりの移動量を１〜２０ドットにしたい場合の移動量を
２０個の配列を用意して入れてるんだけど、これが外部の移動関数から読めてる。
…というのは知ってたけどそういえばextern使ってないのに何故だろうと思い、１４歳わくわくＣ＋＋を調べてみると、
メンバ関数やメンバ変数にstaticを付けるとグローバルな関数、変数扱いに出来るとのこと。
そして呼び出すときには、クラス名：：変数または関数とすればよいらしい。
さらに変数の場合は、外部に実体の定義が必要。
忘れてた…。
これは>>74氏のそのままでＯＫではないか〜！ということでextern無しで書くことにした。
よって>>73で言ってた
＞ベクトル計算用関数の引数を増やして、その引数に値経由でframetimeを渡せないかと
も中止。
とりあえず、最後に残ったヘッダファイルにある移動関数の一つを書き直してコンパイルしてみたら通った。
移動関数はあと３つ残ってる。

ヘッダファイルの書き直しが完了。
何もヘッダファイルを読み込んでないヘッダファイルを先に直して、
ヘッダファイルの読み込みの少ないヘッダファイルを先に直すような順番で書き直していったからかどうかはわからないけど、
あまりバグが出なかった。次はcppファイルの書き直しに挑戦。たぶんもっと時間がかかるはず。

とりあえず修正対象にするcppファイルを１つ選び、
そのcppファイルがインクルードしてるヘッダファイルのファイル名の頭に付けてたv_（←修正中のヘッダファイルに付けてたやつ）をはずして、
そのままでは古いヘッダファイルと同じ名前になってしまうので、先に古いヘッダファイルは別のフォルダに移動しておく。
そしてコンパイルしてみる。
一個ずつ直してみたがバグがなかなか減らないし、ヘッダファイルもコンパイルの画面に新旧入り混じっている状態では
かえってややこしくなってくる。
cppファイルも一個ずつ順番に直してバグが無くなったら次に…と思っていたが、
うまく説明できないが、そうはならないはずとの考えに至る。
cppファイル単位できれいに独立してるわけではなくて、あるcppファイルのオブジェクトが呼ぶオブジェクトは別のｃｐｐファイルで定義されてて
そこからまた他のところへ…、するとそのcppファイルでインクルードしてるヘッダファイルも直した方のヘッダファイルに入れ替えなければならない。
結局、全部のヘッダファイルを新しい方だけ残して全部一気にコンパイルしてしまった。
エラーの総数が今現在３４９個。
ヘッダファイルの修正箇所をエクセルにメモする作業が無駄になってしまったかもしれない。

昨日は一気に全部まとめてコンパイルしたけど、描画関係をまとめたcppファイルはその時点で修正済。
そうした上でのバグ３４９個。
その後の修正で何故かバグが３５８個まで増えたけど、なんとかして３４４個に減ったところで終了。（今日はちょっと疲労気味なので…）

コツコツ頑張ってて偉いなぁ…本気で尊敬する。

俺はずっとモデリング勉強＆練習…

>>84
ｶﾞﾝｶﾞﾚ超ｶﾞﾝｶﾞﾚ
俺もそろそろ頑張ってみるか…

>>83
自分はこの板のおかげでゲーム作りへの挑戦は約３年１ヶ月程続いているけど、あまり進んでいないかもしれません。が…頑張ります！。
>>84>>85
お互い頑張りましょ〜！期待してます。

ベクトルの構造体を宣言・定義したから、ボールや選手などのオブジェクトの
座標その他のメンバ変数を初期化するときには、例えば初期化関数の内部で
オブジェクト．ｘ＝８４８；
オブジェクト．y＝５４４；
オブジェクト．z＝０；
としていたのを
オブジェクト．構造体変数名　＝　｛８４８、５４４、０｝；
にできるのではと期待して書いてみるとエラーになる。
略）\source\ballcontrol.cpp(45) : error C2059: 構文エラー : '{'
略）\source\ballcontrol.cpp(45) : error C2143: 構文エラー : ';' が '{' の前にありません。
略）\source\ballcontrol.cpp(45) : error C2143: 構文エラー : ';' が '}' の前にありません。

これと同じようなエラーをクラスのオブジェクトでやった経験を思い出し、
オブジェクト．構造体変数名．ｘ＝８４８；
オブジェクト．構造体変数名．y＝５４４；
オブジェクト．構造体変数名．z＝０；
と書いたらエラーは出なくなった。
これだけならまだしも関数の引数にも構造体を使おうとしているので、
これもエラーになったらどうしようかと思いつつ、動作している事を優先して作業を進め、 現在のバグは２７４個。
ネットで調べると自分では構造体を書いたつもりでいても、Ｃの構造体とＣ＋＋の構造体には違いがあるらしくて、
自分が見たサイトの説明によれば、

実は、構造体はメンバがデフォルトで公開されているクラスである。
つまり、
"stuct X{" = "class X{ public :"
となる。クラスと構造体の差異はそれだけである。

との事。
Ｃで書いたベクトルの記事を本で見て、それを今まで書いてたＣ++のソースに
使おうとしたから、自分の気付かない理由で上手くいってない感じ。
まずは今のままで進めてみて関数にベクトル構造体を引数にしたところでも
問題が出るようなら、また考え直すつもり。

>>87
見方を変えると「Cの構造体に関数も書けるようにしたものがC++の構造体」とも言えると思う
Cの構造体で出来ることはC++でもそっくりそのまま書けると思うんだけどね

>自分の気付かない理由で上手くいってない感じ。
バグに関して絶対こうだとは言えないが、CとC++の違いが原因ではないような気がするなー

>>87

ｘ、ｙ、ｚを初期化するコンストラクタを定義されていれば
オブジェクト．構造体変数名　= クラス名(848,544,0);
のような代入ができる。

もしくは、構造体変数をセットするメンバ関数を定義してもいいかも。

上の補足

コンストラクタを定義していなければ、
オブジェクト．構造体変数名　= {848,544,0};
のような代入もできる。

>>90
それは初期化時のみじゃない？

struct vector{
int x,y,z;
};

void main(){
vector a = { 1,2,3 }; //ok
a = { 4,5,6 }; //エラー
}

ありがとうございます。今日は調べるだけで終了でした…。
>>88
たしかにバグの原因がCとC++の違いだと思い込んでしまうと他の原因の可能性を見落としやすくなりそうなので気をつけます。
>>89
今のソースではベクトル関係がクラスでなく構造体で表現されていてコンストラクタについてはまだ考えてませんでした。
バグが結局取り切れなかった場合、勉強しなおしてベクトル関係もクラス化する最終手段に挑戦してみようと思います。
>>90
コンストラクタの定義はしてないのですが、何故かエラーになってしまうので、
今は以下に書くとりあえず的なやり方でエラーを回避してます。
>>91
「構造体の初期化」で検索したところ、とあるサイトにそのような感じの
「構造体変数の初期化は、変数の宣言時には常に行うことが出来る点に注意しよう。」とあり、これを参考に以下のようにしてます。

ベクトル関係のヘッダファイルで
struct Vector3{float x,y,z;};

あるオブジェクトの初期化用関数の内部では昨日のやり方から少し変更して、

Vector3 a1={848,544,0};
fp.xy（←これは昨日書いていたオブジェクト．構造体変数名の事）=a1;

と書いてもバグが出ないのでこれでやってみようと思います。
今日は調べただけなので、バグは減ってないけど、全部取れるまで頑張ってみます。

>>92
>ベクトル関係もクラス化する最終手段に挑戦してみようと思います。
>>87は自分で書いててよく分かってないみたいだけど、classとstructは根本的には同じもの

struct Vector3{
Vector3(float x_, float y_, float z_): x(x_), y(y_), z(z_){}
float x,y,z;
};

void main(){
Vector3 a(1,2,3);
cout << a.x << " : " << a.y << " : " << a.z << endl;
a = Vector3(4,5,6);
cout << a.x << " : " << a.y << " : " << a.z << endl;
}

>>92
>Vector3 a1={848,544,0};
>fp.xy（←これは昨日書いていたオブジェクト．構造体変数名の事）=a1;
ちょっとこのレスで、代入のコストが気になったんで検証してみた

struct A{
A(){}
A(int x_, int y_, int z_): x(x_), y(y_), z(z_){}
int x,y,z;
};
struct B{
B(){}
B(int x_, int y_, int z_): x(x_), y(y_), z(z_){}
int x,y,z;
void operator=(B &val){
x=val.x; y=val.y; z=val.z;
}
};

AとBの違いはoperator=を使用してるかどうかだけ
A a,b;
a = b;
こんな感じでただ代入するだけの式を、それぞれ１００万回ずつ実行
結果は予想外にもBの方が７倍も遅かった（単位はミリ秒）
A　5
B　35

そこで試しに、構造体に「double a[256];」を追加して実行
今度はBは変わらず、Aが極端に遅くなった
A　255
B　36

最初Bの方が遅かったのは、operator=のオーバーロード
つまり関数オーバーヘッド分の差が出たのだろう

変数を増やすとAが遅くなるのは、ほぼ間違いなくコピーコンストラクタが発生してるからだろう
ここら辺は言語仕様のレベルでBのような代入にしてくれてもいいような気がするなー

ま、結論としてはoperator=は弄らない方が速い

>>93、>>94、>>95
詳細な解説に感謝します。
自分にはまだ難しすぎるのですが、「c++ 　構造体の代入　問題点」で検索してみたところ、
以下のＨＰがこれらを理解するのに参考になり（理解は出来ず雰囲気だけなんとなく自分に伝わったような感じ。）、
リンク先はpdfなので要注意かもしれませんが、
ttp://ist.ksc.kwansei.ac.jp/~ishiura/xcpl/note/cpp3.pdf
の１２〜１３ページあたりで、C＋＋にはいろいろな種類のコンストラクタがあり、
結果は同じようでもその書き方によっては、コンストラクタが多く呼び出されて処理に時間がかかるらしい。
あと>>94のコンストラクタの書き方が見たことない書き方だったけど、
ちょうど１７ページにある説明と似てるので、これかな？と思ってみたりで勉強になりました。

バグの方は、１２６個まで減少。

今日もあまり作業出来てないけど、バグの残り３６個。

やっとバグが０個になった。エラーメッセージが０個になったと言う方が正しい表現に近いかもしれない。
しかし、画面でスタート直後にボールに近い選手が通常よりも早いスピードで画面外に出ていくような動きをして、
画面端に到達してそこから動かなくなる問題が出た。
やっぱり出た。エラーメッセージの出ないバグが…。
もしも、>>96のようなコンストラクタがどうのこうのが理由で動かないとなるとやっかいな予感。
自分は>>96はもちろんのこと今までに難しいといったところはなかなか理解が出来てないから…。

バグはまだ取れない。
選手が画面やレーダーに表示されてるという事は、画面の表示範囲を決めてるカメラ関係のところに原因があるという可能性はなさそう。
選手の座標を計算してる箇所を調べる。今書いてる計算式は、説明を省くのでわかりにくいけど、以下のような内容。

fp->xy = AddVector(fp->xy,MulVector(sv,Application::frametime/sq));

Application::frametimeの中身が気になったので、printfDx( " frametime = %f \n" , frametime ) ;で調べると、
15.100000と表示された。もう一回やり直すと15.633333と出た。
このframetimeは、ｄｘライブラリのGetNowCount()を毎ループに1回計算し、
ループ前後の差を３０回足して、それを３０で割った平均値を意味してる。
調べるまで忘れてたけど、GetNowCount()の単位はミリ秒なので、先ほどの式では、1フレームで１５ドット近い移動量になっているだろうから、
１秒が約６０ｈｚのパソコンだと１秒で１０００ドット近く移動するはずなので、昨日の早すぎる移動スピードの原因だけはわかった。
とりあえず、
fp->xy = AddVector(fp->xy,MulVector(sv,Application::frametime/sq/1000));
のように書き直したら、選手がほとんど動かないけど、単位の間違いが原因だとわかった。
選手がボールに向かってくれない原因は未解決。

選手がボールに向かわないバグが解決した。
選手とボールの距離とそのｘ、ｙ成分を計算するために座標の引き算をしたが、
選手座標　−　ボール座標としてたのが間違い。
ボール座標　−　選手座標が正解。
でも何故かこれでもバグは解消されなかった。
本当の原因は、

違う場所を直していた。

という事だった。
自分のプログラムは移動関数を４種類用意してあり、
１．その場停止
２．マウスに向かう
３．ボールに向かう
４．指定したＸ、Ｙ座標の位置に向かう
なんだけど、いつからか４番の関数だけ使えば十分だろうと思い、
４の関数にマウス座標やボール座標を渡していた。
でも、そのことを忘れていて、ボールに向かわないバグだから
ボールに向かう関数を直さねばと思い、その関数だけを直していた。
昨日スピードのバグが直ったのは、その時だけたまたまＰＣ画面が小さくてプログラム行が下がっていたのに気付かず４番の関数を書き直していたのだろうと思われる。
ある意味１日で気付けたのは運が良かったのかもしれない…。

プログラムにベクトルの表現を取り入れる作業は一区切り付いたけど、
これはあくまで>>65の目標に取り組めるようにするための準備段階なので、
次は画面関係の修正に挑戦する予定。
まだ方法を考えてる段階なので簡単には進みそうにない予感。
少し斜めから見たフィールド画像でプレイできるようにするのが目標だけど、
ネットではパースというキーワードで検索するものの即取り入れ可能な事を書いてるホームページにはまだ出会えていない。
他には動画サイトで昔のサッカーゲームの画像を見て、参考に出来るところが無いか調査中。

パース、その他いろいろなキーワードで検索したが見つからず。
いますぐどこかの３Ｄライブラリを理解できるレベルではないのでかなり困った状況。
大体イラスト関係のホームページがよくヒットして消失点という言葉が出てきて、
これを考えればフィールドの形を遠近法的な台形形状に書くことは出来るだろうけど、
例えばその台形のフィールドに奥行きと高さ方向にメッシュを入れる時、何を基準にすればよいのかを詳しく説明してるところを見つけられず、
結局参考にならなかった。奥行きのメッシュは遠くになるにつれて間隔が狭くなると思うけど、それを決定する基準がわからないという意味。
そしてしばらくまた探していると、とあるホームページで人間の目は並行ではなく放射状にものを見ているとの記述があり、
これが参考になりそうなので、方法を考えているところ。

>>102
3Dライブラリを使うのが結局は楽だよ
（描画効率を無視するとして）
フィールドのモデルとプレイヤーのモデルを配置
カメラ位置・方向を決定したら draw 一発
難しい事を考えなくて済む

>>102
確かに3Dライブラリを教科書どおりに使えば簡単にできることだけど
敢えて自力で計算してみようというなら
「透視投影変換」、「同次座標表現」で検索するといいかも。

ありがとうございます。ちょっと考えてみます。
>>103
３Ｄの勉強を全くしていない状態なので、知識のない自分には３Ｄライブラリを使うのは無理かと思ってたけど、
すぐに諦める前にもう少しだけ調べてみようと思います。
>>104
「透視投影変換」、「同次座標表現」のキーワード、感謝します。パース等ではなかなか役立つホームページがヒットしなかったので…。
すぐには理解できないけど、検索結果のホームページの内容の方が自分の思いつきより洗練されてるので、３Ｄライブラリ使用が無理な場合、次の手段として挑戦しようと思います。

とりあえずＤＸライブラリで出来ないか考えてみる事にした。
ホームぺージから最新版をダウンロードしたら、3.04だった。
いままでのは2.25、リファレンスの球を表示する部分を丸ごとコピペしてコンパイルしたら
球が表示されたので、もし２Ｄとソースが共存できるなら今までのプログラムを３Ｄライブラリで丸ごと書き直さなくてもすむかもしれないと思って終了。

ＤＸライブラリ３Ｄでプログラムを組むための参考になりそうなホームページがどうも無さそうなので、
ＤＸライブラリ置き場ホームページに行き、サンプルプログラムの

３２．３Ｄアクション基本　　を見るが複雑すぎて今は無理と判断。
３１．迷路を３Ｄで表示　　　も難しいが、プログラムのソースにあるカメラの命令のリファレンスを見てみるもののやっぱりよくわからない。

>>102で言ってた２Ｄだけで自分で計算するか悩んだが、その前にあと一つ試せる方法があったのでやってみた。
今まで書いてたプログラムの状態や画面の遷移、得点、時間表示などを削除し、
３Ｄ円錐の描画命令をコピペし、上記で言ってたカメラの命令をコピペしてみたら描画された。
最初からプログラムを作り直さなくても３Ｄ命令のテストが出来たのは運が良かったかもしれない。
カメラの関数の引数を変えると円錐の向き大きさも変化したが、座標系がよくわからないので、
何故このように見えるのかが今はまだわからない。
カメラ関数の引数を変えても２Ｄの選手やフィールドの絵には変化が無かった。
もしかすると結局はすべて３Ｄのライブラリ関数で書き直すしかないのかもしれないと思って終了。

>>106
２Dの絵がすでにあるならビルボードでググってみるとよろしかろう

>>107
ありがとうございます。３Ｄを不勉強なので、ビルボードも知りませんでした。
フィールドを３Ｄで表示して選手を２Ｄにして遠くにいる選手の画像は２Ｄのライブラリ関数で縮小表示できれば３Ｄらしくなるのではと自分はいままで思っていて、
しかしその縮小比率をどのように計算すれば良いのかが悩みどころでしたが、ビルボード関係を調べて何ができるのか読んでみると、
厚みのない画像でも３Ｄ空間の物体扱いにできてカメラ関数があればフィールドと一緒に選手も３Ｄ視できそうな気がしてきたので作業が進んだら挑戦してみたいと思います。

今日はホームページで３Ｄ関係を巡回したのみ。
３Ｄ空間からＰＣ上のゲーム画面への座標変換を行うには、いろいろな行列を何度か掛ける必要があるとか、座標系の種類の説明がいろいろ。
これを理解してプログラムを書けるようになるにはどう考えても数カ月から…いや下手すれば数年かかるんじゃないかと感じた。
しかし、一方で昨日のＤＸライブラリのサンプル　３２．３Ｄアクション基本　のソースを見る限りでは、行列を何回も掛けているような処理の記述は見当たらない。（探し下手で自分が見つけられていないだけかもしれないが…）
もしかすると、３Ｄ空間内にモデルを配置してカメラ関数の引数をセットすれば３Ｄ視できるその中に既にそういった計算が見えないところで行われてるのかもしれない。（これが>>103氏、>>104氏の言っていた事かもしれない）
とりあえずなんだかわからない状態だけど、なんらかのモデルを用意して、それを読み込んで画面に表示することに挑戦してみたい。

ＤＸライブラリのサンプルプログラムで拡張子mqoというのがあり、メタセコイアのファイルのことだとわかったので、
金曜日の夜にメタセコイアＲ２．４（フリーの方）をインストールした。
モデルをつくる技術が無いので、面→基本図形で面を生成し、材質設定で緑色を指定するにたどりつくまででもかなりの時間がかかった。
サンプルプログラムのやり方を真似してこの平面モデルのmqoファイルを読み込み、表示させようとしたが、
最初は全く表示されず、表示されても白黒だったりしたが、ファイル作るところからやり直してみたら今度は表示された。
結局原因は不明。次は今までの選手の２Ｄ画像を平面モデルに張り付けられるのかに挑戦。

>>109
頑張れ！

>>110
今は全ての作業が試行錯誤なので遅くなっているけど頑張ります！

選手の画像を１コマ切り取り、同じサイズの平面をメタセコイアで作成して
その平面に選手の画像を貼ろうとしたが失敗。
この処理はＵＶマップと呼ばれてるらしいが、とりあえず貼り付けをやめてｘｚ面に垂直なただの平面を作り、
フィールドの次に描画させようとしたら表示されず。
何回かやり直していたら、フィールドと小さな平面が表示されたところで終了。（原因不明）

フィールドの平面モデルにネットのフリー素材のフィールド画像を張り付けてみようとしたら何故か出来た。
ＵＶマッピングとかいまだに解ってないので偶然できただけ。
ビルボードで選手を描画するのは難しい事がわかってきた。
DrawBillboard3D関数が使えるかなと思ってリファレンスを見たら、画像のサイズは自分で入力しなければならないので、
この関数仕様だと、いろんな位置や角度で見たときの選手がどの程度の大きさで見えてるかを自分で計算出来る必要があり、これを実現するのは難しいと思った。
すぐ諦めるのはどうかと思いつつも、最初に諦めてたモデルを配置してカメラ関数で見てもらうやり方を検討することにして今日は終了。
とりあえずは、選手を円筒か何か簡単なモデルで表現して配置してどのように見えるかを目標にする。

>いろんな位置や角度で見たときの選手がどの程度の大きさで見えてるかを自分で計算出来る必要があり
DXライブラリ使った事ないので的外れかもしれないけど
こういうのって普通ビュー変換で処理されるんじゃないのか

>>113
実は自分は変換関係についてネットで調べて言葉を知ったところまでで、それ以上の探求をちょっと怠ってしまっている状況です…orz
でもそう言われて気になったのでビルボードの関数を試してみたら遠くのものが小さくでてました。やってみるきっかけになり、感謝します。

int DrawBillboard3D( VECTOR Pos, float cx, float cy, float Size, float Angle, int GrHandle, int TransFlag ) ;
の引数、float Size ： 描画する画像のサイズ…の意味を間違えて解釈していた。
縦横=Sizeの２Ｄ画像が３Ｄ空間のどこにあってもこのSizeを保って描画されるのかと思ってた。
もしそうならば、３Ｄ空間で遠くにある画像はその分小さく描画したいから自分でその大きさを計算していちいち引数Sizeの値を入力し直す必要があるのかと勘違いしてしまってた。

Sizeはあくまでもロードした画像の大きさであって、あとは座標を指定すればその位置に応じて大きさを変換してくれることが確認できた。

一応結果画像をうｐしてみます。
ttp://gamdev4.hp.infoseek.co.jp/cgi-bin/up/No_0132jpg.html

今日は進捗なし…orz
毎日何か進捗のある状態に持っていくことの難しさを痛感。
とりあえず次にやろうとしているのは、マウスでフィールド上の一点を指定できるようにすること。
今まで書いてた2D平面版ではマウスカーソルの位置に選手が向かうようにしていたので同じ操作方法を使えるようにしたいのが理由。
２Ｄ版では、ゲーム画面（６４０Ｘ４８０）の左上角の座標がゲームのフィールド全体の座標でみたとき（ＷＸ、ＷＹ）という座標で、
マウスカーソルの画面での座標が（Ｘ、Ｙ）としたとき、マウスカーソルのフィールド上での座標値は（ＷＸ＋Ｘ、ＷＹ＋Ｙ）になる。
３Ｄでもこれに相当する処理をしたいけど、３Ｄになるとカメラの位置が立体的に変化するからどうすればよいか想像が付かない。
このスレで教わった用語からいもづる的に出てきた用語を駆使して、
「ビュー座標からワールド座標を算出」というそのままなキーワードで検索してみたらたくさん出てきた。
どうすれば出来るのかある程度調べたら、使えそうなライブラリ関数を探す予定。
ライブラリで出来なければ、何も出来ない自分なので…orz　←まぁ、これはあまり気にしないでこれからも行き詰まるまで頑張るつもり。

一般的な方法としては、
・E=視点座標、つまりカメラの位置をあらわす位置ベクトル
・L=投影面における視点からマウスカーソルまでの半直線ベクトル
から、仮想空間内の任意の物体との交差判定、交差位置特定がきる。

Eは、普通、プログラム上で管理されている。

Lは、FOV（視野錘台)を自分で管理されているなら容易に計算できるが、
投影変換行列の逆行列を使っても計算できると思う（そういう便利な関数があるかもしれない）。
L = Mproj.inv x (mouseX,mouseY,1)T
　　Mprij.inv = 投影変換行列の逆行列
　(mouseX,mouseY,1) = マウスの座標（正規化装置座標系、同次座標表現)

特に、フィールドのような単一平面との交点計算は、
・O=原点（フィールド面上にあること）
・N=フィールドの法線ベクトル(正規化ベクトル)
に対して、Eがフィールドの表面にあると限定した場合、
LとNの内積が０以上の場合、交差しない（マウスカーソルは天空を指している）

さもなければ、
・h= フィールド面からEまでの高さ((E-O)とNの内積)
から、
・t= -h/(LとNの内積)
を求めれば、目的とするフィールド上の点Fは、
・F= E+L*t
のような手順で計算できるはず。

あとは、(F-O)をフィールドの座標軸(X-O)(Y-O)で分解すれば、２次元座標に戻せる。

うろ覚えで書いているので細かい間違いがあるかも知れないが（違ってたら乞指摘）、
ゆっくりでいいんで、参考にしてもらえれば嬉しい。
頑張れ！　

詳細な説明をありがとうございます。
やっぱり自分にはまだ難しすぎたようです…。
しかし、これが解らなければ>>115でやろうとしていることもライブラリ関数だけでは結局出来なさそうなので、
もう少し頑張ってみようと思います。１日の作業時間が短いので、何週間か掛かるかも…。

ま…まだ無理な感じ。何週間じゃなくて何カ月と書いておけばよかった…。
やっぱりある程度の知識が無いと理解が進まないような気がしてきた。
ある程度知識を持ってる前提でちょっとわからない用語を調べるのにはネットは役立つけど、
今の自分は３Ｄに関しほとんどが知らない用語ばかりで思考が進まないので勉強が足りないと感じた、
遠回りだろうけど、本屋に行きそこに置いてあった中から１冊選んで来た。
「実例で学ぶ３Ｄ数学」←生き物を表紙に多用しているオライリーシリーズのひとつで、前スレでもこの本を紹介してくれていた人がいた。
今は第７章で１０８ページまで読んだけど、自分には難しい内容。
式の証明があまり無い様で、わからない箇所については「そういうものなんだ」ということにして先に読み進めているところ。
９章（〜１９４ページ）まで読み終わったら、もう一度上記について考える予定。

ConvScreenPosToWorldPosのサンプル内でMV1CollCheck_Lineを使って
ポリゴン上のマウス座標を出してるっぽいのがあるよ

>>119
こ…、これは気付きませんでした。ありがとうございます。
試しにサンプルで使えそうな部分をコピーしてプログラムソースに貼り付けてまさかのコンパイル。
これではおそらくバグが山積みだろうと思ったら、予想外に通った。画像の文字の意味についてはまだ理解出来てません。
サンプルでは、スクリーン上のマウス座標から直線が延びているイメージで、ワールド座標内のポリゴンに当たったらそこが黄色になるという内容だろうと解釈。
マウスを左上に持っていくとフィールドの左上が黄色、右下にもっていくと右下が黄色、フィールド外だと変化なし。
とにかく反応していることが確かめられたので、このサンプルコードを自分がやろうとしていることを実現できるように
書き変えられるか考えてみようと思います。

参考画像をうｐ
ttp://gamdev4.hp.infoseek.co.jp/cgi-bin/up/No_0134jpg.html

もちろん>>116〜118についても継続するので、並行作業で行く予定。

カキコがなくて心配してたよー

>>121
>118の本の学習がなかなか進まなかったため、ご無沙汰してしまいました。（汗；
ときどき停止するかもしれませんが頑張ります。

本の方は８章（〜１４４ページ）で一区切り。とりあえず８章まで読めればなんとかなりそうなので９章までの予定は中止。
１４章も一部分だけ読んでみた。残りは必要なときが来たら挑戦するつもり。
>>116氏のをもう一度読んでみたところあともう少しでわかりそうな気がしてきたので、
あとはネット検索で投影変換行列を調べてみる予定。

>>116氏のアドバイスについて今の自分に出来るところまで図示で理解しようとしてみたのでＵＰ。
視野錘台がうまく斜めに書けていないとかいろいろあるけど、
この状態からさらに理解が進めばＤＸライブラリを使って自分なりの関数をどのように作ればよいのかがわかるかも…、
そんな時が来るかもしれないと期待してここでいったん区切ることにしてみます。（感謝！）

いつも使わせてもらってたアップローダがサービス停止のようなので、いろいろ探して以下のところにしてみた。
（アップローダを使ってるスレを探してたらＮＥ○Ｔスレを偶然見てこのアップローダの存在を知った。）
他にお勧めのアップローダがあれば、柔軟に対応します。

ttp://ux.getuploader.com/sggk/

次は>>119氏のヒントを元に次の行動を決める予定

>>116　の　Ｌは、
GetMousePoint( &Mx, &My ) ;
ConvScreenPosToWorldPos( VGet( Mx, My, 0.0f ) ) - E ;
で求まるんじゃないだろうか。

そこで詰まったんじゃないの？

>>124
アドバイス、ありがとうございます。
今度は練習プログラムの修正で確認してみようと思っています。
>>119と>>124の両方でやってみるつもり。
マウスが指し示すフィールド上の位置に何かオブジェクト（球体とか）を
表示出来れば上手くいったと考え、この前ベクトル化したプログラムの続きに入る予定。

作業時間１０分なので何も出来ず…。
とりあえず半径10の球体を（100,0,0)、(0，100,0)、(0,0,100）の順番に表示させてみた。
これによれば、Ｘ軸は左方向がプラス、Ｙ軸は上方向がプラス、Ｚ軸は手前方向がプラスになっていたので、
ＤＸライブラリは左手座標系なんだな〜と思ったところで終了。

カメラの向きによるでしょ

あ、座標系か。ゴメン

>>127,128
Ｘ軸は右方向がプラスの方が確かに分かりやすいのでカメラの位置と向きは変えようと思います。
いろいろ理由があり作業が止まったりしていますが、まだ諦めてはいません。（仮眠しようとしたら朝になってしまったとか…）
今のモデルは、フィールドが511ｘ341（何故この数字にしたか忘れてしまった…）でその中心が原点(0,0,0)、
カメラの位置は(0,340,340)でカメラの注視点が原点(0,0,0)になっています。
作業の前にやっぱり簡単な例を用意して自分で（手作業で）変換行列を考えてみるところまで
やってみた方がいいかもしれないと思い始めてきたので、その作業分だけ進捗が遅れる可能性ありです。

今日はエクセルで準備的な作図を途中まで進めて終了。
書いた図が結局役に立たずに時間を無駄にする可能性もあるけどやってみる。

む…無駄になってしまった感じ。
図は書いてみたけど、座標変換について結局あまり理解出来てない事がわかった。
悩んだ結果、恥ずかしいほどに簡単な例を用意し、それを図にして考えてみた。
オブジェクト座標からワールド座標への変換はなんとなく分かったような気がしてきた。
カメラ座標への変換（ビュー変換？）については、オブジェクト座標からワールド座標への変換と同じやり方でたぶん出来るだろうということにして省略し、
今は透視変換について考えているところ。

やっぱりやめることにした。
わずか一日で目標変更…。
昨日の続きをやるとなれば、また数週間経過しそうでそれでいいのだろうかという不安が急に出てきた。
透視変換についても>108の頃の自分よりは理解してるつもりなので、とりあえずプログラムに戻り、それでダメならまた別の方法を考えよう。

変換についてやっぱりやめないで最後まで調べてＵｐするに方針変更。（葛藤し過ぎ）
できなければ出来たところまでをＵｐするつもり。
仕事じゃないんだし…、もう少し調べてみても無駄にはならないはず…。
趣味なんだからあまり無駄とか気にしないようにしよう！

今日は>>119氏のアドバイスのテストプログラムの動きの問題について考えてた。
>>120でプログラムが動いていたのは間違いないけど、画面左上に表示される
マウスでポイントした点が画面中のポリゴンと交差したところの点座標や他の情報を
表示している画面の文字がどんどん重なっていき見えなくなる問題が出ていた。
自分のプログラムでは、ClsDrawScreen　と　ScreenFlip()　の間にゲームの中身の処理を
書いてループするようにしなければならないんだけど、テストプログラム用に無駄な箇所を消したり、注釈化していたときに
間違えてClsDrawScreenの行を　//ClsDrawScreen　のように注釈行化してしまっていたのが原因だとわかる。
気付くのに3日以上かかった（汗；）
ちなみにＤＸライブラリではClsDrawScreenは今でも使えるけれど、
公式のリファレンスからは削除されていて、代わりにClearDrawScreen()になっているという事をその時知った。

年末休みだからとはいえさすがにもう寝なくては…。
>>131のカメラ座標への変換がなんとなくやっと理解出来たような感じ。
次は透視変換に挑戦。
ライブラリが無ければ自分は何も出来ないんだから座標変換勉強しても時間の無駄じゃないのか？
…という迷いはあるけど、あともう少しなのでこのまま進めてみるつもり…orz

やっと出来た。
間違いや内容不足はあるかもしれないけど、>>129の11月１５日頃からの作業がやっと終了…。
１ページ目は結局使わなかった図。
２ページ目以降の８枚が勉強メモ。

ttp://ux.getuploader.com/sggk/
に
オブジェクト座標系からスクリーン座標系まで勉強.zip
という名前でＵＰ。

P2_page001〜004を見た。

そもそも何をしたいのか読み取れなかったけれども、
最初の赤枠の大前提については、ボールの位置はワールド座標系で管理して、
必要に応じて選手目線の相対座標（オブジェクト座標）を求める方が簡単じゃないかな。

見てくれてありがとうございます。

自分はＤＸライブラリが無ければ何もプログラムできないので、
プログラムに直接影響しない事を調べてもあまり意味が無いのではないかと思う一方で
座標変換には３Ｄ入門の基本のような印象を持っていたので、
もし出来るならちょっと調べてみたいと思ったのが原因で１か月以上経過してしまいました…。

赤枠については今見ると自分もそう思います。
ボールに一番近い選手を知りたいなら選手の座標とボールの座標を
フィールド基準の座標系（ワールド座標系）で表して単純に距離計算した方がよさそうです。

次にやろうとしていることは、選手のデータ作り。
ビルボードの関数で選手を表示するので、メタセコイアで板（面？）のモデルを作り
テクスチャ？を貼りつける作業。２次元のデータのときには選手のアニメパターンを１枚の画像にしていたけど、
今度はそれを切り出して面のモデルに張り付けた３Ｄデータを何枚か用意する必要があるので、
メタセコイアの使い方を思いだしているところ。（忘れるのがものすごく早いので我ながらつらいｗ）

データはなんとか用意出来た。３２ドット四方の面に選手移動アニメの一コマを貼り、
左歩行に２枚、右歩行に２枚、赤選手と青選手があるから（２＋２）ｘ２＝８個のテクスチャ付き面モデルを作成。
上と下の歩行描写は省くことにした。
テクスチャの貼り方はなんとか分かったけど、今まで使っていた１６コマを１枚にしていた２Ｄデータから
１コマずつ切り出すのに手間取った。
EDGEというソフトを使ってみたが、マウスできちんと３２ｘ３２で選べない。
なんとなく「edge グリッド表示」でネット検索してみると、「ツクールの素材を作る」という名前で以下がヒット。
ttp://tanktown.web.infoseek.co.jp/tt/g_creat/g_creat/g_creat_graphic01contents.0104.htm
まさにこれが知りたかった事なので作業できた。
余談だけどEDGEは２００９年で更新が止まってるようで、競合も多いだろうしフリーだから
モチベーションを保てずにつぶれたのかな？と思ったらなんとｉPhoneに場所を移して活動してるらしい事がわかった。
才能ある人はいろいろ出来てうらやましいと思った。

>>115で言った
>とりあえず次にやろうとしているのは、マウスでフィールド上の一点を指定できるようにすること。
については、どうやら出来そうな感じ。

それを表す図やテストプログラムの実行ファイルをＵＰしようかと思ったけど、
テストプログラムでは、試したいＤＸライブラリの関数をメインループにそのまま書き込んだだけなので、
今までのクラスを使ったやり方に比べ単純な例で試して上手くいったと自分が思っているだけなのかもしれないので、
今度は、今までの２Ｄで動かしていたプログラムの中身を少しずつ３Ｄのライブラリ関数に置き換えて
動作を確認していき、これでうまくいくようならＵＰする予定。

フィールド上の一点を指定する方法については、
>>116氏の7行目の投影変換行列の逆行列を使う方法では、
自分の力不足のため投影変換行列を作れないので断念。
座標変換、結構勉強してみたつもりだけど、さすがに投影変換行列を作るのは無理だった。
ライブラリを作れる人はすごいと思った。
>>119氏のConvScreenPosToWorldPosのサンプル内を使う案については、可能であることを>>120で確認済。
>>124氏の案についても昨日テストプログラムで試した結果、可能であることがわかった。

これでやっと>>65に取り掛かる直前の状況になってきた感じ。（感謝！）
もしうっかりスルーしてしまった項目があった場合、指摘あれば対応します。

いざソースを書き直そうとするもののどこから手を付ければ良いのか見当がつかない。（いまさら何を言ってるのかと思われそうだけど…）
今出てる問題は、今までのプログラムにベクトルが使えるようにするために追加したクラス、関数（ベクトル同士の加算、減算とか）が
既にＤＸライブラリに用意されていて、当然ＤＸライブラリの方が関数の種類も多い。
かといって今まで書いた自分のベクトル用関数もソースのあちこちに散っているので、
これをいますぐＤＸライブラリの関数に置き換えるのは数カ月単位の時間を要するのは確実。

とりあえず、
自分の書いたクラスVector3　←中身はx,y,zだけ
ＤＸライブラリの構造体VECTOR　←中身は不明だけど、リファレンスを見てるとx,y,zが含まれているようだ。
の型を持つ変数同士を変換する事が出来れば、自分の書いた関数、ＤＸライブラリの関数のどちらでも使えるのではないかと予想。

一応、以下のような感じで書いてみた。まだ書いただけなので使えるかどうかは今後の進捗次第。

//Vector3型変数をVECTOR型に変換する関数。
VECTOR Vector3_To_VECTOR(Vector3 a){
VECTOR result;
result.x = a.x;
result.y = a.y;
result.z = a.z;
return result;
}
//VECTOR型変数をVector3型に変換する関数。
Vector3 VECTOR_To_Vector3(VECTOR a){
Vector3 result;
result.x = a.x;
result.y = a.y;
result.z = a.z;
return result;
}

念の為もうひとつ確認しておこうと思い、テストプログラムでメインループの中に
Ｚキーを押したら選手のｘ座標を少しずつ増やしていく処理を追加してみた。
コンパイルして実行してみたら選手の絵がｘ方向に動いた。
３Ｄのビルボードの命令で描画した選手でもいままでの２Ｄ命令でやったとき同様に動く事が確認できた。

これで多少は安心してソースの書き直しに着手できる…と思う。

C#囓った俺だったら、Vecrot3にToVECTOR()関数を追加するかな
Vector3 a;
VECTOR b = a.ToVECTOR();
って書けるようにする

普段はVector3を使って、必要に応じてVECTORを吐き出すというイメージ
VECTORからVector3への変換はしない、という仕様にした方が多分デバッグは楽になると思う

アドバイス、ありがとうございます。
確かに変数の型はどちらかに統一しておいた方が良さそうなので注意します。
変数はVector3に統一し、ＤＸライブラリの関数の引数と出力の型がVECTORだった場合には、
引数に関しては、Vector3型をVECTOR型に変換した値を入力して、
VECTOR型出力に関しては、そのつど出力のx,y,z値をVector3型変数に入力すれば、>>140で言った
VECTOR型変数をVector3型に変換する関数は使わなくて済むので、これでやってみます。

今日のプログラム修正は、データのロード部分のみ。少しずつ進めていく予定。

修正が思い通りに進まないので悩む。
また以前のようにクラス図の様な図を書いて整理してからソースを修正した方がいいのだろうかと思ったが、
エクセルで書こうとするととても時間が掛かるので、クラス図を書くためのフリーソフトが無いか探してみた。

UMLdraw　フリー版とシェア版があり、フリーでは印刷できないので不可。
UMLmemo 　フリー、印刷無し、ビットマップ出力ありだけど、書いたテキストの空白が改行マークで埋め尽くされて見づらいので不可。
astah* community　無償版、印刷あるけど大きさの調整不可、使い方が難しいので不可。

無理してastah* communityでクラス図もどきを途中まで書いてなんとなく思い始める。

「頑張ってプログラムソースを書き直した方がいいような気がする。」

この状況になるまで約２週間経過。無駄な事をしてしまったのかも・・・。

今は選手のデータ関係を修正中。
前スレ>>885で選手のデータを入力しやすくするために考えた関数を使わずに
テキストファイルからデータ（初期位置座標など）を読み込めるように出来ないか考えているところ。
１４歳シリーズのＣ（VS2008編）に使えそうな例が載ってたので参考にしてみるつもり。

テキストファイルからの読み込みをやると言ってすぐ壁に突き当たる。
選手のポジション（ＦＷなど）を列挙型定数にしているけど、これは読み込めないらしい。
全てのデータをテキストファイルから読み込む方法に変える必要はないと思うので、
これについては、選手のゲームスタート直後の座標だけをテキストから読み込めるようにすればいいかなと考えた。

選手のデータ関係の修正作業は途中だけど、ちょっと中止。（方針変更しすぎ・・・）

クラス図を途中まで書いたときに感じた事だけど、状態を表す定数の追加やそれを使った分岐が
ソースを見づらくしており、他にも理由がいろいろあって、このまま気になったところから直してコンパイルしてもたぶん地獄の修正作業になると思った。

全部直してからでないと修正途中でコンパイルしたところでバグしかでないぞと思っていたが、
最低限のファイルだけ残して、残りはとりあえずコンパイルの対象となるフォルダの外に場所を移しておき、
残したファイルだけでコンパイルし動作確認出来たら、移動したファイルをいくつか戻して修正して・・・を繰り返していけばよいのではと思った。

ということで、メインループ関係とフィールド画像関係だけ残して、
メインループ関係のソース内のフィールド以外（選手、ボールなど）に関する記述は//を付けてコメント化してコンパイルされないようにしてみる。

その状態でフィールドが画面に表示されるまでを目標にしてみる。

11,12,13日の3連休では無理だった。（作業時間もすごく短いので・・・）
エラーの数は、２０個→８個→３０個と変わり、結局増えてしまった。
ゲームのループとそこから呼び出す関数はそんなに変更ないけど、
そこから先は思った以上に作り直しに近い感じなってしまった。
まだ先だけど、状態管理の定数を使った分岐処理もできればメインループの外に出したい。

一つの値があったとして、その値が自作のVector3型だったり、
ある時はＤＸライブラリのVECTOR型だったりするため、変換の方向を
Vector3　→　VECTOR　のみにしてソースを直すつもりだったのが想像以上に難しそうで、
プログラムソースもほとんど書き直しに近い感じになりそうなので、
この際思い切ってVECTOR型に統一して、ベクトル関係演算用関数については、
自作ではなくＤＸライブラリの関数を使って書き直していくやり方にしてみる・・・に方向修正。

やっとフィールドの表示が出来た。
今まではソースを書きかえる時に元のソースの先頭に//を付けてコメント化して、
いざという時に前の状態に戻しやすくできるようにしていたけど、これをやめて
コメントを減らしてソースを見やすくするようにした。
戻りたいときにはバックアップのソースを見ればいいのだから。
バックアップはコンパイルした時に出来るファイルを含め全部保存していたが、
考えてみるとプログラムソース（ヘッダファイルとCPPファイル）だけを保存しておけばよかった。
数年やってて気付かなかった・・・。

パージョン管理ツールを使うと躊躇なく修正できるよ
subversionがおすすめ

>>148
パージョン管理ツールの存在を知りませんでしたので勉強になりました。
「subversion ゲームプログラム」で検索してみるとかなり難しいツールのようです。
難しくてもインストールして触るところまではネットで調べて試してみようと思います。
ありがとうございました。

現在の進捗は、選手関係のファイルをコンパイル対象の場所に戻して、
>145でやりかけてた選手の初期化関係を修正中。

ふと、このスレのこと思い出して帰ってきたけど
まだSGGK氏が頑張っててちょっと感動した

当分書き込んでないけど俺もいるぜー。3Dモデル全般の勉強でなかなか進まない
SGGK氏がんばってるなー

>>150
思い出して戻ってきてくれる人がいる事に感動です！
まだまだ頑張ります！
>>151
お久しぶりです！
お互い目標目指して頑張っていきましょう〜！！

subversionの件、自分には難しすぎた感じ・・・。
でも、インストールして触るところまではなんとか出来た。

subversionで検索するとapachをＰＣにインストールして色々と準備設定が必要らしく、
これの設定の意味が全くわからず断念しかける。apachはサーバーのプログラムらしい。
VisualSVN-Serverというのも出てきて試そうとしたらポートの設定を求める項目があり、
理解せずに設定してパソコンを壊してしまうと大変なので断念。
「subversion　apadh無し」とか「subversion　サーバー無し」で検索するが、自分に分かりそうなページはヒットしない。
２、３日諦めてて、ふと「subversion　ローカル」でやってみた。
TortoiseSVNというのがあるらしい。これはサーバに対するクライアント？のソフトらしく（←自信無し）、
これ単体でも自分のＰＣでバージョン管理が出来るらしい。
とりあえずホームページを探してTortoiseSVN本体（種類がいくつかありどれにすればよいのか迷ったがなんとか見つけた。）と日本語化ツールをダウンロードしてインストールした。
あとは説明ホームページを探して、リポジトリの作成、バージョン管理したいファイルのあるフォルダをリポジトリにインポートして、実際の作業を行いたいフォルダへ
リポジトリの内容をＳＶＮチェックアウトする。
そして作業が終わったらＳＶＮコミットするとリポジトリで変更が反映されてバージョン管理される・・・ところまで理解（自信無し）。

しかし、このようなツールに即適応出来ないとなると、自分の目標である
オンライン３Ｄ対戦サッカーゲームの完成はいつになるのだろうかとふと思った。
バージョン管理ツールはサーバーに関する知識がある程度なければ操作の意味が理解できない感じ。
いまはこういうツールの存在を認識するに留め、出来る範囲で対応するしかなさそう・・・。
でも、ツールの難しさ→サーバーの勉強も早めに始める必要ありそう→急がないと１０年頑張っても出来ないかもしれない
という危機感につながったので、とにかく諦めないようにしたい・・・。

ソースを修正していて思ったが、C++で書いたプログラムは保守性が良くて再利用性にも優れてるような事を
どこかで聞いた記憶があるけど、そうなっている感じがしない。
たぶん自分の書き方に問題があるので、この機会に少しでも変えてみようと思った。

１．クラスのメンバ変数をpublicにして直接読み書きしていた。（変数毎に関数を書くのが大変だし、いちいち関数を使っていたら、その分処理速度が遅くなるのではと思った。）
　　これを次のようにする。
　　privateのメンバ変数にして変数毎にget関数、set関数を作ってこの関数を経由してアクセスする方法にする。
　　そうすれば、例えば、座標系をx,y,zで管理していたのをVECTOR構造体に変更した場合でも
　　get関数、set関数の修正で済む場合もあるので、修正に有利だし、
　　get関数、set関数が書かれている場所を見れば、クラスのつながりも見えやすくなりそう。

２．get関数、set関数のような変数の取得、設定しかしない関数は行数が短いので、
　　定義をヘッダファイルに書いていたが、定義はすべてcppファイルにまとめて見やすくする。
　　それが出来ない例外もあった記憶があるけど、その場合は仕方ないのでヘッダファイルに書く。

３．変数の命名規則を考え、それに従った変数名を付ける。
　　但し、最低限の規則にしておき、不完全でもあまり気にしないようにする。
　　プログラムの修正が今より少しでもやりやすくなればいいのだから。
　　今考えてるのは、メンバ変数は単語の区切りだけ大文字にして書く。
　　メンバ関数も同じだけど、最初の文字だけは小文字にする。
　　そして、メンバ変数の先頭には、m_　を付ける。
　　メンバ変数で静的変数なら、ms_　を付ける。
　　メンバ変数でポインタなら、mp_　を付ける。

これでやってみる。

メンバ変数をクラス外から頻繁にアクセスしなければいけないというのなら、
クラスの設計自体を見直すべきかもしれないよ。
もちろんケースバイケースだけど。

今回のプログラム修正は前回と違って、warningが出ないようにしたい。（前回あまりにもたくさん出てきたので諦めてしまった。）

warning C4290: C++ の例外の指定は無視されます。関数が __declspec(nothrow) でないことのみ表示されます。

上記のwarningメッセージは、プログラムソースの例えば、void loadFiles()throw(int);と書いた行のような場所で多数出た。
エラー処理の命令でtry{この中でエラー出たら何かをthrowする。}catch(){左の()内とthrowされた値が同じ時に処理する内容をここに書く}というのがあって、
その最初の{}の中には関数を入れる事も出来て、その関数の中からエラー時にthrowすることも出来る。
つまり外に向けてthrow出来る関数を宣言するときにthrow(int);（注：この例ではthrowされる値の型はint型になる）を横に付けるらしい。
でも、VS2008では、この仕様をフォローしてないので、throwされる型は指定できない。
warning C4290：　はそういう事を言っているらしい。

このwarningが出ないようにするには、
#pragma warning( disable : 4290 )
を書いてやればよいとの事。

たしかに出なくなった！

>>156
偶然同じ時間帯に書き込みしてた様です。指摘ありがとうございます。
今のプログラムはかなりごちゃごちゃして修正するたびに時間が掛かるようになってきたので、
もう少しクラス分けしてプログラムを見やすくしたいけど、どう分けるかは実はやってみないと分からないという状態ですが頑張ります！

なんか切磋琢磨な感じがいいね。
影ながら応援してます(`・ω・´)ノ

>>159
しばらくの間は今までのプログラムの書き換え作業のような感じになるけど、
やれるところまでは頑張ってみようと思ってます！

今までは１つのファイルに複数のクラスの宣言を書いていたのを、
1クラスにつき1ファイルに変えようとしたためか、ファイルがどんどん増え、
しかもほぼ全てのメンバ変数にget、set関数を用意するので作業量が膨大になりそうな感じ・・・。

class FieldControl
{
（略）
FieldData m_Field;//クラスFieldDataの型を持つオブジェクトm_Field
AnimDraw m_FieldAnim;//クラスAnimDrawの型を持つオブジェクトm_FieldAnim
（略）
};

のようなクラスがあり、m_Fieldの中にm_FieldAnimのアドレスを記憶しているポインタmp_Animがあり、
m_FieldAnimの中にはdraw()関数があるとしたら、

m_FieldAnim.draw();//方法１
m_Field.mp_Anim->draw();//方法２

は同じ事をしているらしい。
方法２のように書くべきところを方法１のような書き方をしていたのがわかって気になったので自分用メモ。

>>155の書き換えを進めていてフィールド表示は出来た。
今は選手関係の処理に着手中だけど、ここからは選手人数分のループや選手の移動関数などが絡んできて時間がかかりそうな予感。
一日の作業時間はとても短いので・・・。

>>155や>>160の変更を同時にやろうとして収拾がつかなくなってきた。
>>160の＞1クラスにつき1ファイルに変えようとした・・・のが良くなかったかもしれない。
クラスにあるメンバ関数をcppファイルの中で定義しようとしたときに、そのクラスのヘッダファイルに無い他のクラスのメンバ変数が含まれていたら
その含まれていないクラスのヘッダファイルをインクルードしたり、または前方宣言とかいうのを書いたりするんだけど、いまいちよく理解しないでやってるからなのか
どうもその辺が原因になってるような気がする。
それと移動処理のクラスは外部変数的な感じで外部に実体を定義するんだけど、
これも思い通りに出来ていないような気がする。ちゃんと書いたつもりなのに定義が無いといった意味合いのエラーが出る。
しかもアサーションがどうのこうのというエラーまで出てしまった（たしか1年ほど前にも似たエラーが出て大変だった）ので、
ここはいったん選手関係のファイルをひっこめて、もう一度フィールドの表示をさせるところまで戻して、
次に選手の画像データロード、選手の初期値テキストファイル読み込みの部分だけをコンパイル対象に戻して
動作が確認できるまでを頑張ってみる。

エラーメッセージが出なくなった。
問題となっていた部分はいわゆるクラス同士が相互参照していて、どちらかのクラスが宣言や定義されていないと矛盾してしまうんだけど、
先に宣言するべきクラスもその後に宣言されるクラスが宣言されていないと宣言できないという問題。
これがよくわからなくて後宣言のクラスがクラス名くらいの簡単な場合は前方宣言を使い、
後宣言のクラスの関数まで記述されているときは、前に宣言しておくべきクラスのヘッダファイルを置けばいいような感じで理解してみるものの自信無し。
結局、処理を順番に見ていきこの行では何が決まっていないと不具合になるか考えて順番に設定していき、
なんとかクリアできた。（自信無し）
そのかわり、cppファイルは両方のクラスを一緒にせざるを得なかった。
でもこれでは将来、あのクラスの定義はどのファイルに書いたのか分からなくなるので、
空のcppファイルをつくり、その中に注釈行で、ここに書くべきcppファイルの中身はどこのcppファイルに書かれたのかを記述しておいた。

それにしてもエラーが出ないのも変なので、メインループの選手画像データロード、選手の初期化あたりを調べてみる予定。

今見たら、先頭に//が付いて注釈行になっていた。
画像データロードの注釈化を解除してコンパイルしたらエラー無し。
だからといって安心とは限らないけど次にいく。
選手の初期化でエラー、アサーションとかイテレータがどうのこうのというメッセージ。
明日はここからということで・・・（寝）

>あのクラスの定義はどのファイルに書いたのか分からなくなるので

クラスビュー(ソリューションエクスプローラのタブを切り替える)を使えば、
関数、変数の宣言箇所もしくは定義箇所が引き出せるよ。

>>165
クラスビュー、使えました。クラスが一覧されて、ソース内の関数名をマウス右クリックメニューで定義を書いた場所に移動してくれるので便利です。
これがあれば、空のｃｐｐファイルを用意して定義先を書くような事をしなくて済みます。ありがとうございました！

今日は選手の初期化でエラーの件がまだ上手くいかず、選手２２人分のデータ読み込みで
while文を使う時の条件文にファイルリードの成否判定を入れていたのを試しにはずしてみたら
エラーは出なくなったけど、選手の表示は無し。
試しに選手初期化処理直後にブレークポイントを置いて処理を停止させてからデバッガ（使い方自信無し）で見ると、
どうやら２２人分のデータの読み込みがされていない様子。

>>163についてちょっと気になったので質問させて下さい
クラス同士が相互参照という事ですが、なぜそんな構造になってしまったんですか？

>>167
これは書籍（１４歳シリーズ）を参考に書いた処理で、
今も自信ないけど、以下の様な感じで相互参照のクラスが出来てしまってます。

選手２２人分の移動関数をループから同じ書き方で呼び出しても、
異なる移動関数を選択できるようにしたいという目的があり、まず移動関数を持つ基底クラスを作成。
その基底クラスの継承クラス内で移動関数をオーバーライドしてその関数を呼び出せれば様々な移動関数を使えるはず。
継承クラスのオブジェクトのポインタを格納するための「　基底クラスのポインタ型を持つメンバ変数を選手のデータ内に持たせ　」て、
そのポインタから移動関数を呼べば良い。
選手のオブジェクトからそのポインタを使って移動関数を呼ぶ時に選手のアドレス（thisポインタ？）を引数に持たせてやり、「　移動関数はそのthisポインタから選手の座標などのデータを呼び出し、更新する」。

上記の「」のところで、
選手のクラスは移動関数のクラスのポインタをデータに持つためには、選手のクラスが宣言される前に移動関数のクラスが定義されてなくてはならないし、
移動関数のクラスが選手のオブジェクトのポインタを通して選手のデータを使うには、移動関数の宣言より先に、選手のクラスが宣言されていないと選手の座標データを使った関数の中身が書けない。

・・・というのが相互参照になった理由です。

宣言前のクラスのポインタをメンバ変数として宣言したければ、

class CclassA{
　　class CclassB *pB;
};

class CclassB{
;
};

というように、クラス名の前に class と書きます。
ポインタにしか通用しませんが。

クラスを前方宣言してみては？

>>168
なるほど意図が分かり納得しました
相互参照は何だか卵が先か鶏が先かみたいで何となく嫌な感じがしたんですが、それが必要な場合もあるんですね

読み間違えていたので>170は無視してください…

このようなやり方があるとは知りませんでした。
自分の技術不足のため直接的な解決には至りませんでしたが、この方法を試す過程でｃｐｐファイルもほぼ別々に分ける事が出来るようになりました。
残っているのは、移動関数クラスの継承クラスの実体を選手関係処理を集めたクラスのcppファイルの中で定義しなければ
エラーになってしまうという点だけ（一行しかない処理なので今は問題視しないつもりです。）なのでソースがすっきりしました！
ありがとうございました！
>>170、172
実は前方宣言もちょっと使っています。今回のプログラム修正は自分にはかなり複雑な内容でした…
>>171
ソースを読もうとすると複数のファイルを行ったり来たりしなくてはならないややこしい構造なのでかなり苦労しました。
これからも頑張ります！

東北地方太平洋沖地震発生から約一週間。
亡くなられた方々のご冥福を祈ると共に被災地の早期復旧復興を願いながら書き込み再開。

>>166の
>while文を使う時の条件文にファイルリードの成否判定を入れていたのを試しにはずしてみたら
>エラーは出なくなったけど、選手の表示は無し。
>試しに選手初期化処理直後にブレークポイントを置いて処理を停止させてからデバッガ（使い方自信無し）で見ると、
>どうやら２２人分のデータの読み込みがされていない様子。

これは、
while(it!=m_FieldPlayerList.end()　||　FileRead_eof(f)==0){データ初期値入力}
を
while(it!=m_FieldPlayerList.end()){データ初期値入力}
にとりあえず変えてみたという意味。
データ初期値入力は、
(*it).setpAnim(&m_FieldPlayerAnim);
のようなやりかたで入力しようとした。
itはイテレータの事で、上記のwhileが真の間は、１ループ毎にitが１ずつ増えて
このitが選手２２人分のデータを指し示すような感じだけど上手くいかなかった。

おお、ご無事で何より

ＳＴＧ氏もご無事で何よりです。
災害関係で協力できる事をやりつつ、自分はプログラムをいままで通り続けていくつもりです！

これから初期化するということはまだデータを入れるコンテナクラス（配列みたいなもの？自信無しで使ってる）が
２２人分用意されてないはずなので、
while(it!=m_FieldPlayerList.end()){データ初期値入力}
では、条件が満たされず、データ初期値入力に進まないような気がした。
試しに
if(it==m_FieldPlayerList.end()){printfDx( "リストが最後 \n") ;}
を
while文より前の行に入れてみると、画面に「リストが最後」と表示されたので、
そもそもデータが入力されていないとこまでわかり、ふと以前のバックアップを見ると
foｒ文のループ２２回指定で入力していた。
間違えた方のやり方は既にデータが２２人分あり、選手移動処理するときに
２２回繰り返す場合に使うやり方だった。

forループでどうやら問題無さそうな感じ。
選手の移動処理も最初何も表示されず悩んだが、どうやら直った感じ。
原因は、ビルボードに使うデータをロードする関数にメタセコイアのデータをロードする関数を
使おうとしていたことと、ビルボードに使うデータはBMPデータなのにそれを忘れてて
メタセコイアで作った平面にBMPデータを張り付けたメタセコイアデータをロードさせようとしていたという
２重の間違いをしてしまっていた事。

gh3d[0] = MV1LoadModel("media\\player11.mqo");　　←１回目の間違い

gh3d[0] = LoadGraph("media\\player11.mqo");　　←２回目の間違い

gh3d[0] = LoadGraph("media\\player11.bmp");　　←正解

現在は、選手画像がマウスカーソルに付いたまま描画される状態なので、
なぜフィールドの初期位置に散らばった状態からマウスカーソルを
追いかける動きにならないのか調べているところ。

久々にまたがんばろうかな　っと思ったけど
この板すんげぇ過疎ってんのね・・・
このスレにちょいとお邪魔してもいいかな

とりあえず2DでSLGぽいのを目指して。

>>179
よろしくおねがいします。
お互い頑張りましょ〜！

>>178の問題は解決。
選手の現在位置を表すベクトルに１ループあたりの移動距離分の大きさを持つベクトルを足すべきところを
間違えて、選手の移動目標となるマウスカーソルの位置を表すベクトルに足していたのが原因。

そして現在の問題点は、フィールドと選手の座標にずれがある事。
カメラの注視点を変えて向きを変えるとフィールドはそれに応じて画像が変化するけど、
何故か選手の出てくる場所はフィールドに関係なく毎回同じで変化していない感じ。
しかもマウスの指し示す位置座標もフィールドの変化と連動していないようで毎回同じ状態。
カメラの関数はループ処理の最初に書いてあるのでそのあと描画されるものはすべて
カメラの状態に合わせて描画されると思っていたけど、何か勘違いをしている感じ。

>>180
いつまで続くか分かりませんがヨロシクお願いします

とりあえずVC++2010Expressインストして
昔の何かのつくりかけのソースをこねくり回してます。。。

このスレは次の書き込みが数か月後になっても全然ＯＫなので自分はマイペースでやってます。
進捗が０になると突然書き込み０になったりしますので、その時はスミマセン・・・。

昨日の問題は解決。
原因は、選手の移動関数の最初の行にカメラ関係の関数、
SetCameraPositionAndTarget_UpVecY( VGet(0,680,340), VGet(0.0f,-100.0f,0.0f));
を書いてあったため、これがループの最初に書いてあったSetCameraPositionAndTarget_UpVecY(略)と重複してしまい、
両関数の注視点が異なっていたのでズレが生じた事。

こっちの場合熱が冷めるとマズイ事になる予感ｗ
なので、その前にある程度作れれば・・・と思ったり。

こねくり回したソースはミートソースになってしまった。
食わせたらウィンドウは一応出た。
これでようやく次の作業へ…。

こちらは、balldata.h　を作成。
２次元でやってた時のヘッダファイルに修正を加えて作成。
メンバ変数をプライベート変数にしてget関数、set関数の宣言まで。
このような修正をボール、ゴール、レーダー関係のファイルに行わなければならず、
残りは全部で８ファイル。

なんという手間のかかる作業を。。。
グローバルで適当に書いて放置してる誰かさんとはえらい違いだなぁ
ぃゃ直しますよ…後で…ｲﾂｶ,ﾀﾌﾞﾝ。

今日の作業：マウスアイコン作って動かせるようにした。
なんかsprintfとかの警告でまくってるけど気にしない。
ユニットとマップの大きさどうしよかな…。

ファイルを分けているのは14歳シリーズＣ＋＋本の影響でたまたまこのやり方しか知らないのが理由。
このやり方だとオブジェクトを増やす毎に新しいファイルを増やさなければいけないので大変だけど頑張ってみます。

今日は進捗なし。自信ないけど土日で>>185のファイルを片づけたい。もう4月…。

オブジェクト毎に1ファイルというのはこちらも似たような感じなんですが、
その…GET、SET関数書くのがメンドくてそのままパブリックで書いて直接・・・
なんてダメな事をやってる所を放置したままで・・・ｗ

以下日記：中身の何も無い板ポリユニット表示した。
ちょっとソースを綺麗にしようと思ったら
同じようなクラスが2個出来上がって汚くなった。
どうしてこうなったorz

メンバ変数を読み書きして外で処理するのではなく、
メンバ関数にハンドルを渡して中で処理させる設計に変えるといいんじゃないかな。

class HUMAN_UNIT
{
public:
void Damage(int point);
　　void Heal(int point);
private:
int hp;
};
void HUMAN_UNIT::Damage(int point)
{
hp -= point;
return;
}
void HUMAN_UNIT::Heal(int point)
{
hp += point;
return;
}

ハンドルとか良く分かって無いですが、こういう事？
んでも↓みたいな事やるときにhp取り出すのがめんどくて
ついpublicに置いてしまう…ｗ

HUMAN_UNIT yuusya , souryo;
if(yuusya.hp > souryo.hp)souryo.Heal();
if(yuusya.hp < souryo.hp)yuusya.Heal();

Get、Setはほとんど使ってないなぁ
大抵>>189の人のようにメンバ関数からのみアクセスするだけで済むようにしてる
クラスが何をしているかと再利用性と扱いと管理が楽になってよい

自分は>>155からget、set関数方式への書き直しを進行中だけど、書き直しにものすごい時間がかかってます。
そして今更ながらそのように直すメリットを見つけられないような気がしてきて不安だけど、
もうほとんど書き直してしまったし、ソースも多少見やすくなったような感じはするので、このまま頑張ってみます！。

今日は、ボール関係をなんとか実装したけど、ボールはフィールド中央に表示され続けるのみとし、まだ蹴れないようにしておく。
レーダー関係は何故かレーダーが表示されないので、原因を調べているところ。

昨日はget、set関数方式のメリットを見つける自信が無いような事を書いてしまったけど、
ネットで検索してみると、異常な数値がセットされないようにset関数の中でチェックしたり、
get、set関数のどちらかをあえて書かない事でプライベート変数を書き込み専用、読み込み専用にすることも可能といったメリットがあるとの話。
自分の場合、今までｘ、ｙ座標を別々の変数にしてたときは、（オブジェクト）.x　のようにしてたのが、途中でＶＥＣＴＯＲ構造体を使おうということになって、
そうなると今までのソースを（オブジェクト）.x　から（オブジェクト）.（構造体変数）.x　に全部書き変えなければならなくて面倒だったので、
これが、（オブジェクト）.getX()　にしてあったら、getX()の中身を　return　x　から　return（構造体変数）.ｘ　にするだけで済んだのでは？との思いがあって、
同じような事がそう何度も出てくるとは思わないけど、get、set関数に変えてみたという話。
完全に直しきれたかどうかは自信なし。

なんとか>>185の修正が終わった。
但し、ボールは中央表示のみで蹴れない。
選手もマウスカーソルを追うのみ。
画面は固定。
レーダーが最初画面に表示されなかった原因は分からなかった。
レーダーの座標はベクトルのx,yだけを変数記憶用に使おうとしていたけど、
あえてやめて、以前のｘ、ｙの２変数を用意して、そこに記憶させた。なんとなくだけど。
とりあえず、いろいろな条件分岐というか状態遷移のようなプログラムを書く直前の状態までを書いたような感じ。
ここまでを一区切りにするつもり。

最近、処理してから数値返したりする場面が出てきたような気がする
が、無駄な関数ががんがん増えてる気がしないでもない。
ソースを綺麗にする作業は挫折しました。。。

>>193
表示したら動かしたくなりませんか…？ｗ
テンション上がって強引に動作実装、
→バグだらけ→バグ取りでテンションダウン→汚いソースの出来上がり
なんてやってしまうんですが。

日記の(ry
ユニットをマウスで移動できるようにした。
マップの大きさをとりあえず適当な数値で仮定して
ミニマップレーダーを作ろう…。

やっぱりこのスレがいちばん居心地いいなあ
月曜火曜休みなので、この連休は本気出す！
寝て起きたら、もやもやしながらゲームや２ｃｈに明け暮れずVisualStudio立ち上げて何か事を起こす！

小難しい本読んでたら、ホントに小難しすぎておもろうてやがて悲し
教科書を超えて念仏レベルで、ただ文字を追いかけてるだけ


すべてのメンバ変数privateにして無条件ゲトセトは俺も馬鹿だなと思う。
そんなことするくらいならpublicでいい
利点なんて、挙動不審なときに一括検索で代入してるところ洗い出せるぐらいかなと思ってる

>>194
以前、動くところまで書いたのですが、試合前半後半で選手の向きを入れ替えたりとか
いろいろ条件を加えていくうちにソースがわかりにくくなってきた事があったので、
もしまたそうなっても、今の状態からならやり直しやすいだろうと思い、ここを区切りにして保存しておこうと思ってます。
>>195
ともに頑張りましょう！

get、set関数の件、たしかにそのとおりで、直すときは検索つかえばいいんだし、これから書く部分はpublicにしてみます。

今日は、プログラムをリリースモードでコンパイルしようとしてバグ。
どうもユニコードとかの文字コードの何かが原因らしいけど、ネット検索で見つけたコンパイラの設定画面が表示されず、
しようがないので、ソース内の”文字”をTEXT(”文字”)にしたという例を真似してみたり、
他にもいろいろやってみた結果、コンパイルは通ったけど、デバッグモードでは２２人の選手が表示されるのに、
リリースモードでは２人しか表示されない…。解決には時間かかる予感。

あーそういえばC++は文字列が鬼門だよな
UNICODEかSHIFT-JISかっていうのは、要はwcharかcharかって事だ
だからwchar〜charを変換する関数作っておくといいかもしれない

ちなみに俺は基本的に文字列はstringで扱って
wcharとかcharを要求する関数を使う時にstringから渡せるような作りにしてる
もうしばらく使ってないから、マクロで組んだか関数だったかは忘れたけど

あー
使ってないっていうのは、C++触ってないっていう意味ね

な…なるほど、変換する関数が必要となると、それは自分には難易度の高い対策方法なので、もうしばらく考えてみます。
もしかするとコンパイラがこわれてしまったかもしれない様子。

>>199
MultiByteToWideChar とか WideCharToMultiByte とかいう WindowsAPI を呼べば
SJIS ←→ UNICODE 相互変換はできる

VC++のデバック関数でなんか開放忘れのメモリリークを簡単に見つけられるとか
WEBに乗ってたのを試したら余裕でリークしてた。。。
直してたら今度はdeleteがエラー出す、なにこのスパイラル
本体が進まない罠

やっぱり自分は永遠に初心者のようです…。

>>200　MultiByteToWideChar、調べてみました。
引数にコードページというのがあって、いきなりここから躓いてしまうレベルなので、ＡＰＩの難しさがよくわかりました。
感謝します。いつかもっと勉強してＡＰＩの領域まで入っていけるようになってみたいです。

まず、ＤＸライブラリを疑ってみる。
ＤＸライブラリのホームページを見ると更新履歴に何箇所かユニコードがどうのこうののバグを解決みたいな事が
書いてあったので期待して最新のバージョンにしたけど、こちらのバグは解決できなかった。
文字コード関係とは別に気になっていた現象があったので、今日はこれの解決を試みる。
コンパイラの下の画面にいつごろからか、「コマンド プロンプトで 'VCExpress / resetskippkgs' と入力してください」という文字が表示されるようになって、
でも２Ｄ座標系のプログラム書いていた時にはデバッグ、リリースモードどちらもコンパイル出来ていたので気にしていなかった。
でも、もしやと思い、コマンドプロンプトで試したが、VCExpressは外部コマンドでも内部でも無い…みたいなメッセージが出てうまくいかない。
resetskippkgsを検索してもハードディスク内には無い様子。
昨日、コンパイラがこわれてしまったかもしれないと書いたのはこの事。
やむを得ず、VC++2008をアンインストールして、もう一度インストールしてみることにした。
「'VCExpress / resetskippkgs' と入力してください」のメッセージは出なくなった。
コンパイルしてみると今度は、「error LNK2001: 外部シンボル "_main" は未解決です」というエラーメッセージが出た。
これも苦しんだけど、なんとか運よく今日中にクリア出来た。
でも、今度は画面がおかしくなってしまったので、明日頑張ります。

>>201
メモリリークは難しくてわかりませんが、バグの為に本体を進められない気持ちは自分にもよくわかります。
１日ソースから離れてもう一度見るとふと原因が分かったりすることもあるので、お互い頑張っていきましょう！

>>201
さあ早くスマートポインタに移行するんだ

昨日は説明が不足していたので補足。
コンパイラがこわれたのではと思ったのは他にも理由があり、プロジェクトのプロパティ画面が出てこなかった事。
画面を出そうとすると、共通言語ランタイムに問題があるといった感じのメッセージや.NETがどうのこうのというメッセージが出てどうにもならなかったので、
コンパイラのアンインストール、インストールに踏み切った訳。
その結果、プロパティ画面を出せるようになり、１４歳シリーズVC++2008編にあるやり方で再設定できるようになった。
設定は文字セットとランタイムライブラリのところ。
文字セットはマルチバイトセットを使用する。
ランタイムライブラリは、Debug構成ではマルチスレッドデバッグ、Release構成ではマルチスレッドにすればＯＫ。本にやり方が書いてなかったら自分は何も出来ない…。

たぶんなんらかの原因で文字セットの設定がユニコードに変えられてしまったのがバグの原因だったのかなと思う。

そして、「error LNK2001: 外部シンボル "_main" は未解決です」が出る件。
これは、プロジェクトを作成するときに設定画面でＷｉｎ３２プロジェクトを選択すべきところを間違えてwin32コンソールアプリケーションを選択したから。
コンソールアプリケーションだとプログラムの始まりはmain関数である必要があるのに自分のソースはWinMainだから、それがエラーになった原因だった。
１４歳シリーズの最初の方のページ見て設定したのが間違えた原因。
本の最初の方はコンソールアプリケーションで解説しようとしてたから。そのとおり設定すれば当然間違える。

最後に画面がおかしい件、おかしいというのはフィールド画面に貼ったはずのＢＭＰ画像が表示されずに灰色になってしまう状態になってしまってること。
これは、フィールドモデルをメタセコイアで表示させて運よく気が付いた。
原因はフィールドモデルに貼るテクスチャ用ＢＭＰファイルの置き場所が実際の場所と異なっていたこと。
何故そうなったかというと、コンパイラをインストールしなおしたときにゲーム作成関係フォルダをどうせだからと思って、
もう少し上の階層に移してしまったから。

これですっきり。

>>204
スマートポインターもString系も便利そうだなぁ
次回ソース再構築するときに移行しようと思う
今はちょっとやる気がﾃﾞﾅｲ…とりあえずメモリリーク直ったぽいし（ぇ

>>205
バグ取れるとすっきりするよね
こっちもすっきりしたよ。


とりあえずミニマップレーダー表示した。
次は自分の手持ちのユニットリスト作るかな−。
あれ？なんかまわりばっかり作ってる気がするな・・・。

>>206
お互いバグとれて良かったですね。
プログラムはバグ取れなければ先に進まなくなってしまうのでいつも冷汗です。

今日はファイルをまとめてＵＰ
前から見てる人は知ってるので大丈夫だけど、最近見た人がすごいの作ってると誤解されてると心配なので昔ＵＰしたのもＵＰしてます。
間違えて変なファイルとか書き込みとかしてるかもしれない…

SGGK019　：　２Ｄで書いていた時の最終版
SGGK020　：　019に体力ゲージ付けた
3D_TEST　：　>>139で言っていた　>それを表す図やテストプログラムの実行ファイルをＵＰしようかと思ったけど　←のテストプログラムの実行ファイル　
3D_TEST説明　：　>>139で言っていた　>それを表す図やテストプログラムの実行ファイルをＵＰしようかと思ったけど　←のそれを表す図
SGGK024　：　今書いてる最新版、選手がマウスカーソルを追いかけるだけ

置き場所
ttp://ux.getuploader.com/sggk/

今日は進捗無し。来週は現実の方がいろいろあり、作業が進まない予感。
とりあえずの目標は、２Ｄ座標系でやったのと同じ事が３Ｄ座標系でも出来るようにしたい。
時間、得点表示、前半、ハーフ、後半の切り替え関係などの実装を予定。
２Ｄの時はメインループの中にそのまま処理を書いてしまったため、メインがすごい長文になり読みにくかったので、
メインからは関数が呼ばれて、その関数の中に色々処理を書くようにしたい。
それと昨年末に読みかけだった３Ｄの本をもう少し読んでみたい。
今のままだと当たり判定をどうすればよいのかわからないのでそのヒントを探すのが目的。

動かしてみました。普通にもりもり動きましたよ〜
2D版でボール蹴ってゴールまで持っていこうと思ったけど体力切れて動けなくなったｗ
説明JPGは良く理解できなかったぜ…


日記の裏：
前回ユニットリストを表示させようとかなんとか言ってたけど
気がついたらWINDOWシステムを作っていた
何を言ってるか分からないと思うｇ（ｒｙ

なんか難しい…最初から固定表示にしとけば良かったんだ。。。

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

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

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

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


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

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

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

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

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

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

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

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にすれば良い…と。

あ、初期化ミス…↓こうでした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;

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

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

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

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

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

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

昨日は起きていたのがいつもより遅かったので書けなかったけど、
昨日の間違いというのは、メインループ内のゲーム処理関数の最初の行に書いた２行の順序が逆だったこと。
（間違い）
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となっている理由がわからなくて全部０にしてしまったので、
そこに何か関係があるのかと思ったりもしたけど、上記の方法でバグが出なくなったのでたぶん大丈夫。

最初の初期化で　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が固定されてるなら問題は出ないので余り気にする事も無いｶﾓ…。

あれ？
式間違ってるじゃん・・・／(＾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ぽいのはなんとか形になった気がする
ので次の作業へー
フィールドの資源地とか基地ぽいの作るｶﾅｰ

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

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

状態遷移は以下のような感じで実装。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;
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次回ソースＵＰの時に同じソースが残ってる自信がないので、簡単に説明。
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++;
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

良いと思うよ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（３）←まだ原因不明。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

失礼ながら、無駄に複雑にしすぎてるような気がするね。
基本的にボールの状態変数は、(x,y,z)、(vx,vy,vz)だけあればいい。
それと便宜的に(接地 or浮いている)フラグをつけてもいい。

初期値はそれぞれ、ボールの初期位置、速度は０、フラグは'接地'状態。

ボールのループごとの処理はこんな感じ。

　　if(浮いている){
　　　垂直方向の重力加速度を速度に加算
　　　速度を位置に加算
　　　if(速度が下向きで垂直座標が地面より下){
　　　　　位置を地表に補正
　　　　　垂直方向の速度に　-0.9とか反発係数を配慮した値を掛ける
　　　　　垂直速度が小さくなったら、'接地'状態とする
　　　}
　　}else{
　　　水平方向の速度に0.99など転がり摩擦係数を意識した値を掛ける
　　}
　　水平方向の速度を水平位置に加算

蹴った瞬間、(vx,vy,vz)に初速度を与え、'浮いている'状態にするだけ。

直観的に勢いでなんとか運よく直せた感じ。

1.ボールが一度しか蹴れない。
ボールと選手が当たってPRE_KEEP→KEEPの間は、その選手とボールのあたり判定をキャンセルするフラグを立てていたが、
　ボールを蹴った後、そのフラグを戻していなかったので、当たり判定が無効になり、ボールに触れても
　状態を変更する命令を実行しなかったから。
２．蹴ったボールを拾いにいってもボールが付いてこなくなった。
　１．の理由と同じ。
３．ボールがラインをはみ出したら試合経過時間が停止し、ボールをフィールドに投げ込むまでの経過時間表示はされるが、ボールが復帰位置に表示されない。
　ラインのはみ出し判定処理の内部でボールの復帰位置をセットしていたが、
　セットするだけではその位置に表示されるわけではない。
　enum MOVE_STATE{STOP=1,FREE,PRE_KEEP,KEEP};という４つの状態をボールに設定していたけど、
　これらは同時には存在しない状態なのでswitch〜case文にしておいて、
　それぞれのcaseの最後でその時点のボール位置を確定して、switch文を抜けてから
　描画関数にボール位置を渡していた。ちなみに変数はstaticにしたらswitchを抜けても保持されているみたいな感じ。（自信なし）
　ところが何故かcase　STOPのところだけ、位置を確定する命令を書き忘れていたので、
　case　FREEの時の確定位置が変数に残っていて、こちらの位置で表示されてしまったのが理由。

ラインを割ったときには、その時点での(x,y,z)を控えておき、３秒間のカウンタを開始する。
その３秒間も、ボールのループごとの処理は継続する。

３秒たったら、控えておいた位置を復元するとともに、速度はゼロ、フラグは'接地'にセット
スローインしたときは、初速度は違うかもしれないが蹴ったときと同様。

(x,y,z)の控えや３秒カウンタは、ボールとは別のメインのクラスなどで管理するといいと思う。

>>310,312
アドバイス、ありがとうございます。
書き込む前にリロードし忘れてしまい、すれ違ってしまいました。（汗；

自分のソースも似た感じの処理になってるようなのですが、
何故か原因不明でどんどん複雑化しているようです。
例えば、切り替えた状態が、知らない間に別のところで切り替えられてしまう…というような感じ。
ここから崩して作り直すのは厳しいので逆にこのまま>>252の

６．ＣＰＵ選手をまずは１人登場させ、動くようにする。
７．ポジション別にＣＰＵ選手のＡＩを調整する。
８．タイム、スコア、勝敗、タイトル画面などの装飾要素を実装する。

を目指してソースをｕｐできるようにして、そこからソースの見直しをしてみたいと思います。

その残り３つ、急に段差がきつくなってると思う。
無理に進めずに、今までのところをきっちり固めてから進むべきじゃないかな。

>>314
書き込みありがとうございます。
ＡＩについては何も勉強してない状態なので、ボール持ってる選手に他の選手が
近づいていくだけで、これがＡＩという事にしようと考えていましたが、これだけでは物足りないかもしれません。
もう少しＡＩっぽくしようとすると確かにきついです。
昨日は、崩して作り直すのは難しいと言ったけど、無理せず、部分的でもいいので
ソースを見直して、ＡＩも少し調べてみようと思います。

現時点では、直したばかりのボール移動部分をさらに見直すつもり。
今の段階でも、選手が停止した状態ではボールが蹴れないとか、
ボールがマウス方向に飛ばないとか、クリックしてもすぐに蹴れないなどの不具合が出ているので、
ここはもう一度作り直した方がよさそうな気がした。

コーディングする気はないけれど>>252を解釈してみる。
まずは「１．グラウンドとゴールを描画する。カメラを動かしたいのならその動かし方も決めて調整しておく」から。

グラウンドは大きな板ポリゴンにテクスチャを張る方法でも、自分で芝目や白線のポリゴンを描く方法でも
どっちても良いが、ポイントは「ゴールラインの中心に適切な高さのゴールを描いているかに懸かっている。
これは、基本的な座標系の方向とスケールを正しく理解してプログラミングしているかの試金石になる。

グラウンドとゴール一式を３Ｄモデルとして外部からインポートするという方法も有ると思うが、
その場合でも試験的にゴール枠、ゴールライン、タッチラインにプログラムで赤線を引くなどして、
平面の座方形の向きと、プログラム内でのフィールドのスケールを視覚的に確認しておくことは必須。

また、当然その様子は透視投影画像で自由にカメラ位置を変えて確認すべきなのだが、
そんなことはライブラリに専用関数が用意されているので、むしろ０番目的な段階の話だと言える。
数字キーを押したら例えばコーナーポストの外からゴール上空を注視する景色になるとか、
いつでも任意のカメラ位置から任意の地点を注視できるように、フレームワークに組み込んでおきたい。

おそらく３Ｄのサッカーゲームでユーザがプレイヤーに指示を与えながら
マウスでカメラも操作しろというのは無理だと思うので、完成度が上がってきたころには
自動カメラワークのアルゴリズムを検討することいなる。
ただし、現時点では切り替え式で十分。

引き続き「２．ボールを配置し、試験的にマウスでクリックすると蹴ったように動くようにする」について。
ボールクラスの実装は>>310のとおりで、メソッドは、
(1) ボールの現在位置をセットし、速度は０にする：セットプレイ専用
(2) ループごとに実行する運動方程式の処理
(3) ボールの現在位置を求める
(4) ボールが接触した面があった場合、法線ベクトルを引数に速度を反転させ、反発面上に位置補正する処理
(5) ボールの現在速度を求める
(6) ボールに初速度を与える：キック時専用
(7) 現在位置にボールを描画する
とする。(4)の反発は、まずは地面で、次にゴールポストとクロスバーにも反応するようにしておきたい。

とりあえずテスト用には、右クリックでセンターマークに(1)ボールをセット、
左クリックで最初は固定方向でも良いので(6)ボールに初期値を与える機能を呼び出す。

ポイントは、キックによる初速度、重力加速度定数、転がり減衰係数、反発係数などの物理パラメータを
しっかりチューニングし、気持ちよくプレイできるバランスを見つけることに尽きる。

ちなみにメンバ変数はprivateにし、不用意に外部からフラグ操作しないこと。今後もおそらくその必要はないはず。
>>311によると「当たり判定をキャンセルするフラグ」のような意味不明なフラグを導入しているようだが、
物理的にナンセンスで実際バグの元にもなっている。発想を切り替えなければならない。

連投大丈夫かな？「３．ラインを割った状態(スローイン、コーナーキック、ゴールキック、得点)を判定し、復帰処理をつくる」

日本サッカー協会の競技規定によると、ボールがラインを完全に割ったらアウトオブプレーとのことなので、
段階１で確認したプログラム上のフィールドサイズと、段階２のメソッド(3)によるボールの(中心の)現在位置と、
おそらく定数となるボールの半径から、インプレーかアウトオブプレーか判定ができる。
アウトの場合、タッチラインを割ったのか、ゴールラインを割ったのか、
またゴールラインの場合は、かごの内か外かまで判定できる。

しかし現時点ではコーナーキック、ゴールキックの区別はできない。

アウトオブプレーを検出したらフレームワーク側でホイッスルを鳴らすなり何か表示するなどの演出を始めても良いが、
ボールの物理シミュレーションメソッド(2)は呼び続けておくのが好ましい。

演出が終わったら復帰処理となるが、タッチラインを割ったときなら飛び出た位置あたりからスローインだし、
コーナーキック、ゴールキック、あるいは得点後はセットプレー扱いなので再開位置は自動的に決まるはず。

「４．選手をまず１人表示し、動かせるようにする」

選手の３Ｄモデルデータが必要となるが、とりあえず雪だるまか、こけしか、冷蔵庫で代用することにし、
ここで本質的に重要なのは操作方法の決定とパラメータ調整ではないかと思う。

しかも、単に選手の２次元移動とはいいつつも、実際にはカメラの方向によってプレイヤーが混乱しない
ような工夫が必要なため、快適なプレイ環境を実現する操作方法というのは、実に奥が深いと思われる。
ここの作りこみ次第で、ゲームの面白さが左右されるはず。

しかしとりあえず暫定的なものにしておいて先の段階へ進みたいのであれば、
カメラ位置をセンターラインの延長上空、注視点をセンターマークにし、フィールド全体が見渡せる画面とし、
選手はカーソルキーかゲームパッドで移動するようなオーソドックスな方法で構わない。

この段階において、プレイヤーはフィールドの中だけ移動できるように境界条件処理をしておくと良い。
また、ボールとの関わりについては、少なくともこの段階では相互にまったく干渉しないことも確認しておく。

>>316,317,318
ありがとうございます。
これから始めようとしているボール関係処理作り直しの参考にさせてもらいます。

「１．グラウンドとゴールを描画する。カメラを動かしたいのならその動かし方も決めて調整しておく」
いまはメタセコイアっぽい操作でカメラを動かせる段階で止まっていますが、
作業が進めば、自動も考えてみたいです。

「２．ボールを配置し、試験的にマウスでクリックすると蹴ったように動くようにする」
基本的には>>310氏の案の様にいこうと今考え始めてたところで、法線による反発は将来の課題にしようと思います。
自分はZEROCUPの操作にこだわりすぎてたようで、ZEROCUPは選手がボールにあたると
ボールが選手に対してシューティングゲームのオプションのように動くので、
このボールキープ時のボールの動きは別のアルゴリズムに切り替えないと自分には無理で、
キープ中は当たり判定をＯＦＦにしないと毎ループキープ状態への切り替え初期化がされてしまうといった事情が重なり、
だんだん複雑になっていったのだと思います。
ただ、ボールの移動処理をシンプル化しようとした時、選手がボールに当たった時に
選手の移動方向にボールが蹴られる方式では、ドリブルしながら選手の移動方向を変えようとすると、
選手がボールに当たる瞬間に方向を変えなければ、今のマウスカーソルに選手が向かう方式では
方向変更ができないと思い、これが悩みになってました。

一応、ZEROCUPにこだわらない案も考えてみたので戻ってきたら続きを書いてみたいと思います。

「５．選手とボールの接触判定をし、マウスクリックの代わりに選手が蹴るようにする」

先の段階で放置しておいた選手とボールの作用条件について実装する。

選手もボールもともに運動する物体であることから、まずは、
段階２の(3)および(5)で得られるボールの位置および速度を、
判定対象選手のローカル座標系における相対位置、相対速度に変換する。

その上で下記の順に判定、処理を行う
(1) ボールの相対位置が選手に十分近い（距離＜ボール半径＋体格半径）かつ
　　相対速度ベクトルが選手側に向かってきている場合、
　　ボールがコントロールできない位置で単純に当たったものとみなし、
　　メソッド２の(4)による反射処理を行う。法線はワールド座標系に逆変換すること。
　　その際、選手自身の移動速度の法線方向成分を加味するため、
　　反発係数は1.0を超えることも有り得る。

(2) ボールの相対位置が選手正面の特定領域内にあり、
　　かつ選手がコントロールする意思を持った状態の場合、
　　その意思に従いトラップするなりキックするなりでボールの相対速度を決め、
　　ボールメソッド２(6)を呼び出す。
　　その際も、選手ローカル座標からワールド座標系に戻してから渡す。

いずれでもなければ、選手はボールに干渉しない。

>>320
ボールをトラップするも、ドリブルも、パスもシュートも、本質的には
「選手がボールをコントロールできる相対位置・速度条件にいるとき、どのようなコントロールの意思を示すか」
によって、ボールに新しい運動速度を与えるという処理に統一できる。
つまり、選手はボールに対しては速度にしか干渉できないように制限している。

これによって、もし多数の選手が団子状になったとしても、どう転がるかわからなけれど
試合自体は進行可能になると思う。

先着選手にボールが帰属（優先キープ）してしまうようなルールだと、ゲーム性が変わってくると思うけれど、
格闘よりもフィールド戦略を主にするなら、それもありかと思う。

「６．ＣＰＵ選手をまずは１人登場させ、動くようにする」

４で書き忘れたけれど選手クラスの定義には、
・現在位置(x,yz)
・向いている方向
・移動速度
・チームの識別符号
など、描画やボールへの干渉判定に必要な状態変数を持たせる。

それを少し拡張して、
・目標位置
・目標方向
をメンバに加え、
「現在位置が目標位置から遠ければ、
　向いている方向を目標位置の方向に１フレーム期間で回れる角度だけ補正し、
　移動速度も制限速度内で目標位置の方向に加速する。
　目標位置い近くなったら、
　向いている方向を目標方向に近づけるとともに、
　目的地で静止できるように減速する」
というような処理関数を作ってみる。

すると、ＣＰＵ選手には「ボールを相手ゴールに向かってコントロールできる位置と方向」を与えれば、
毎フレームごとにボールに向かって突進するはず。

ボールがコントロール可能な状態（５の(2)）になったなら、敵ゴールに向かってボールを蹴り出すが、
小さくければおそらくドリブルっぽくなるだろうし、ゴールに十分近づいたら強く蹴ってシュートにすればいい。

「７．ポジション別にＣＰＵ選手のＡＩを調整する」
ここまでくると脳内プログラミングでは難しくなってくるが敢えて思考実験を続けてみる。

６での拡張で、個々の選手に対して、
・ボールをコントロールできない状態なら、目的地と方向を指示する
・ボールをコントロールできる状態なら、ボールのキック方向と強さを指示する
の２パターンだけ考えればよくなった。

目的地については、チームで戦うときは必ずしもボールに向かう必要はなく、
むしろパス回しを活用していかに早く安全に敵陣深く攻め込めるかを考えた配置に
なるよう、監督になった気分でそれぞれの選手に指示するべきである。

具体的には、選手間の位置関係から、ボールをコントロールできる（可能性が最も高い）選手から、
最前線の選手までの経路探索アルゴリズムを応用しつつ、個々の選手がより有利な位置に
移動するような評価関数などを駆使して、ということになりそうだが、脳内シミュレーションでは無理っぽい。

なお、選手への指示に上の２パターンを出せば、あとは自動で動いてくれるようにしたので、
ゲームパッドで選手ひとりを直接動かす操作方法は、この段階でデバッグ機能として卒業したい。

その代わりに、プレイヤーもマウスなどを使って、「どのプレイヤーをどこへ動かす」という指示を
リアルタイムに出せるインタフェースを作っておく。
こうなると完全にサッカーチームの監督ごっこというゲームシステムが固まってくる。

もしくは、ジョイパッド操作は、チーム内で一人だけ動きが違う「キーパー」操作に割り当てても良いかも。

このあと>>252では仕上げに入っているけれど、補足すべき要素としては、
Ａ．選手同士の接触判定と解決処理
Ｂ．最後にボールに触れた選手によるスローイン、ゴール・コーナーキックの判別
Ｃ．オフサイドの判定
Ｄ．ＡＩ実装のための評価関数の充実
などが必要じゃないかと思う。

「８．タイム、スコア、勝敗、タイトル画面などの装飾要素を実装する」については、
まあ、そのまんま好きなように作りこめば良い。

長々書いたけれど一応これで脳内では完成したつもり。
本当に実装できるか確かめていないので何の保証もないけれど、
なにか一部でも参考になれば嬉しいので自由に使ってくださいな。

戻ってきたので>>320の続きです。
「３．ラインを割った状態(スローイン、コーナーキック、ゴールキック、得点)を判定し、復帰処理をつくる」
「４．選手をまず１人表示し、動かせるようにする」
どちらも一応大体は組み込めたような感じです。修正は今後もあると思います。
まだポリゴンキャラはやったことなく、ここで教わったビルボードというのでやってます。
いまの自分のレベルだとポリゴンキャラ実装はかなり先になりそうです…。

「５．選手とボールの接触判定をし、マウスクリックの代わりに選手が蹴るようにする」
しばらくの間は、この段階で頑張る事になると思います。
選手自身のボール反射は全く考えてなかったので、それ以外のキック、ドリブルなどの書き直しが
上手く出来たら、挑戦してみます。

「６．ＣＰＵ選手をまずは１人登場させ、動くようにする」
方向をメンバに持たすのを考えてませんでした。
ポリゴンキャラじゃないので、絵的に表現させるのはまだまだ無理なので、
足元に矢印を表す直線を書いて向きを表現しようと思います。

「７．ポジション別にＣＰＵ選手のＡＩを調整する」
ここは未知の領域なのでまだ先ですが、この段階までこれたら参考にしたいと思います。

>>325も含めて多くの助言、ありがとうございました。
回答できなかった部分も今後の進捗に合わせて細部に取り込んでいこうと思います！

それと、ZEROCUPにこだわらない案
ドリブルキーを押すと選手とボールの位置関係と、蹴りたい方向を考慮して
選手があるていどオートで動く。
例えば、まっすぐドリブル中に９０度右に動くようにマウスカーソルを動かした時に
丁度ボールを蹴りだしてしまったら、そのボールまで選手が動き、そこでマウスカーソル方向に蹴って、
選手もマウスカーソル方向に動くようになるという感じ。

選手がボールと当たってたらボールを蹴れるようになるなどの処理を消して、
ボールの移動処理を簡素化してバグが出なくなるまで出来た。
しかし、ボールが表示されない。
とりあえず、マウスクリックでボールを蹴れるところまで戻せるよう頑張るつもり。

ちょっと停滞している状況にあるけど、まだ諦めてはいない（汗；
ボールが描画されなかった理由は、ボールの座標値に異常な大きさの数値が設定されていた為と思われる。
ソースを目で追うと、座標値計算の途中で０で割ろうとしている箇所があり、そこを直したらボールが表示された。
kick関数は選手のメンバ関数だったのをボールのメンバ関数に移し、左マウスクリックでkick関数を実行するようにしたら、
ボールは動くけどまだおかしい。
ボールは浮かずに常に右側にまっすぐ移動し、ラインを出てもラインアウトの判定がされなくなっている。
直接の原因はまだ不明だけど、ボールのメンバ変数にＹ軸回転角度と射出角度と速度の絶対値を持たせるように変えたことで、
まだ気付いていない未修正のところがあるからだと考えてる。

あれこれ書き直している内にラインアウトの判定がいつの間にか直っていた。
ボールの軌跡がプログラムの意図と無関係な動きをする問題でつまづく。
左マウスをクリックしたときにボールの速度初期値に変更を加える方式だけど、
変更を単純にしてみたり、ボールの状態を一定にしてみてもダメ。
ふと、マウスの状態を決める箇所のプログラムを目で追っていると、
マウスを左クリックした場合、他のマウス操作をするまでずっとその状態がクリックしたままで
プログラム内で保持されている事に気づく。
そこを直したら、ボールの軌跡が直った。
前バージョンのプログラムでは何故問題なかったのか不思議だが、時間も無いのでこのまますすめることにした。
ボールの動きをバグ探しの為にかなり単純化してしまったので、
これを戻す過程でまた別のバグが出るかもしれない。

次に出た問題はボールを例えば傾斜６０度で動かそうとしても動かない問題。
やり方はボールからマウスに向かうベクトルをＹ軸中心で９０度回転する行列で回転させて、
そのベクトルを軸にしてボールからマウスに向かうベクトル（大きさは速度と一致させておく）を６０度回転させる。

−６０度にしてみたら放物線のように動いた。

なので、上記のやり方の中で、Ｙ軸中心で−９０度回転させてから、
そのベクトルを軸にして６０度回転させるようにして解決。

マウスクリックでボールを動かせるようになったので、やっと選手で蹴れるかどうかというところまで戻った。

原因がジンバルロックなら一旦クォータニオンを経由させれば回避できるよ

見てくれてありがとうございます！
プログラムの方はたぶんその可能性は無さそうな感じです。
プログラムはワールド座標系だけで書いてあり、選手から見た座標系をフィールド基準の座標系に行列一回で変換するような書き方はまだ出来てません。
ジンバルロックとクォータニオンについては難解なので、キーワードとして覚え、プログラムのレベルが上がってきたら挑戦してみたいと思います。

昨日の動作の件は、ＤＸライブラリでの回転の正負方向が分からず、
６０度で空中に向かってると思ったら、地中に６０度で向かっているようで、
何故かボールが地面で反射せず、地面上を這うような動きになっていたのが原因です。

次の予定はドリブル実装に挑戦！

気付けば今年ももう終わり…。
実はまた転勤の話が出て、その準備の所為で>>332から進んでないけど、それは言い訳だと思い反省…。
本当に無理だと思う状況にならない限りは諦めないでゆっくり細々でも続けるつもり！

見てるぞ、がんばれ〜。

ありがとうございます！
まだドリブル実装で止まってますが諦めずに頑張ります。

>>65のキー割り当てと異なってくるかもしれないけど、

マウスカーソルに向かって歩く　Zキー押し続ける
マウスカーソルに向かって走る　Xキー押し続ける
選手の進行方向固定　　　　　　Shiftキー押し続ける
ドリブル（選手はボールに向かって移動し、ボールに近づくと
　　　　　ボールをマウスカーソルに向かって蹴る。
　　　　　これを繰り返す）　　Ｄキーを押し続ける
ロングパス　　　　ドリブル中にマウス左クリック

これだと、選手の進行方向を固定して進行方向以外に向けて
ノールックっぽくロングパスを出そうとすると、
Ｚ、Ｄを押しながらマウスを操作しなければならず、操作性が良くないような気がしてきた…。
深夜になってしまった。（汗；

しばらくプログラムから離れててソースの中身を忘れてるかもしれないのでリハビリ的に短時間作業。
選手の移動関数内には選手がボールを蹴れる当たり判定範囲を円で示す処理があるんだけど、
その処理部分を別の関数を作ってそちらに移して、選手の移動関数内には
その別に作った関数を書けばいいようにした。
これから先、選手の移動関数内にはいろいろな状態を表すフラグが増えてきて
ソースが見づらくなる事が予想されるので、ちょっと整理してみようと思った。

次は>>116を参考にした処理がプログラム内に散らばっているので、これも整理しようと思う。
昨日と違い面倒なところがあるので時間かかるかもしれない。
昨日のはひとつのクラス内での話なので、一部分の処理を関数として書き直したい場合、
そのクラス内のメンバ関数として定義して使えば動くけど、
今回やろうとしているのは、処理がいろいろなクラスで使われているので、
今考えられるやり方としては、その処理を行う関数をメンバ関数にもつ新しいクラスを作って、
その新しいクラスのオブジェクトを>>116の処理を使っているいろいろなクラス内で定義する。
あとはその新しいクラスのオブジェクト経由？で>>116の処理を行うメンバ関数を呼び出せばなんとかできるのではと期待。

下から２行目は、「定義する」ではなくて「実体化する」と書いた方が良かったかもしれない。
自信ないけど、なんとなく気になったので訂正。（汗；）

>>338で言った関数を作成。
プログラムの一か所を試しにこの関数で置き換えたところ動いた。
他のところの置き換えはその都度やることにして、>>336に戻る。

あれこれ考えたけど良いのが思い浮かばない。
ドリブルの移動関数を別に用意して、選手がボールに当たったらその選手がドリブル権を持っていることにして、
その間はドリブル関数で動くようにして、他の選手がボールに触れたらドリブル権がその選手に移り、
以下同様に繰り返す…というのを考えたが、なんだか以前に失敗したときと同じことになりそうな感じがした。
そこで別の案を偶然思いついた。
２２人の選手が一つの変数を共有して、ボールに当たった選手はその変数を自分のＩＤに書き換えて
移動処理にきたときにその共有変数を見て、自分のＩＤと一致した場合、移動関数をドリブル関数にする。
そんな変数できるかと思ったがこれも偶然思い出した。
自信は無いけど、静的メンバ変数を宣言して、この変数を外部定義すればよいというところまで調べて思い出した。
なので、今日は
選手クラスにＩＤ（←いままで無かった）と静的メンバ変数とそのメンバ変数に読み書きできるように
get、set関数を用意した（メンバ変数がstaticだからこれらの関数が必要だった。）。
上手くいくかどうかは全く未知な状態。

上の文の下から２行目のは「staticでprivateだから」の間違いのような気がしてきたけど自信なし。
今は作業を続ける前にボール関係のクラスをプリントアウトして
寝る時にこれを見ながらプログラムの中身を思い出そうとしている最中。

何故、そんな事してるかというと単純に中身を忘れたので思い出す必要があるというのと、
現在マウス左クリックでボールを蹴りだせるようにしている箇所を関数として
ボールのクラスに移して残しておきたいと思ったから。

ボールクラスの宣言内にボールを蹴ったときの処理をするメンバ関数の名前だけ書き、
その定義をcppファイルに書いた。でも、中身はまだ空の状態。
>>342の「現在マウス左クリックでボールを蹴りだせるようにしている箇所を関数」にしようとすると、
ボールを蹴る関数が、マウスと選手の位置情報を持つ必要があり、ボールを蹴る関数が複雑になるので、
現在マウス左クリックでボールを蹴りだせるようにしている箇所でボールを蹴ろうとする方向とその大きさを計算して、
それをボールを蹴る関数に引数として渡すようにしようと思ったところで終了。
いろいろあってなかなか進まない…orz

>>341の
>２２人の選手が一つの変数を共有して、ボールに当たった選手はその変数を自分のＩＤに書き換えて

のプログラムを書き、コンパイラが通るところまで出来た。
ドリブルの関数をどうするかについてまだちょっとはっきりしてない感じ。

>>341の
>移動処理にきたときにその共有変数を見て、自分のＩＤと一致した場合、移動関数をドリブル関数にする。

のプログラムを書いた。
選手の移動関数の目標座標がいままではマウスカーソルだったのを選手がボールにタッチした時に目標をボール座標に切り替わるようにしただけ。
ある程度の距離分ボールを蹴りだす処理を書いていないので、ボールにタッチすると同時に選手の動きがその位置で止まってしまう。

しかし、良く見ると自分の選手がボールにタッチする前から選手全員がボールに向かおうとしてることに気付く。
移動出来る選手は自分が動かす1人だけだけで他選手は足元から移動方向に短い線を引くようにしていたので気付いた。
原因はボールにタッチした場合にボールに向かい、タッチしてない場にマウスカーソルに向かうのを
反対にプログラムしていたから。

次は、それでもボールが蹴れない問題。

it=(*listfp).begin();
while(it!=(*listfp).end()){
　　　　　　押してるキーで移動関数（歩く・走る）を切り替える
}
++it;
}
この１行を忘れてた　→　it=(*listfp).begin();
while(it!=(*listfp).end()){
　　　　　　ボールにタッチすると判定用変数を選手ＩＤに上書きして、選手の移動目標をボールにして、ボールを蹴る。
}
++it;
}

しかし、ボールの動きが良くない。
最初は選手がボールを押してるような感じでずるずる動いたかと思うと
次の瞬間、勢いよく蹴ってしまう。

ボールが当たり判定に入り、計算されたボール速度がまだ遅いために当たり判定からボールが出ないことによって
速度がどんどん加算されてしまい、当たり判定から出れる速度になる時には大きな速度になっている…などという想像をしてみたが、
確かめる方法が思いつかなかった。
今のプログラムはボールをキックやドリブルするときには、その瞬間のボールの速度に
キックやドリブルの速度を合計するやり方だが、これをやめて、キックやドリブルの瞬間、
つまり当たり判定に触れた時にボールの速度を０にしてからキックやドリブルで設定していた速度で
蹴るようにしたら上手く動いた。
これだと神がかりなトラップになるけど、ゲームなのでとりあえず今はこれでよしとした。
でも、選手にボールがぶつかった時のはねかえり表現ができなくなるので、いつかプログラムを書き直す可能性もある。

しばらくの間、進まなくなるかもしれないので、ＵＰ。

ttp://ux.getuploader.com/sggk/　のsggk028です。

例えば、shiftキーを押すと選手の移動方向が一定になるようにしてあるけど、
これをドリブル中にやるとドリブルを放棄して選手が一定方向に進んでしまう。

何か新要素をプログラムに加えるたびにあちこち不具合が出てしまい、直すのにものすごく時間がかかってしまう。
あちこちにif文を使ってるので難しい。
まだどちらかといえば初期の段階なのにこれだけ難しくなるということは
何かテクニックが必要なのかもしれないので、ちょっと調べてみるつもり。
以前このスレで紹介してもらったゲームＡＩプログラミングの最初の方だけ読んでみようと思うけど、
前読んだ時もあまりよくわからなかったので、もし駄目だったら、このＵＰがラストの可能性あり…orz

一ヶ月少々経過。時間過ぎるの早すぎる。
読んでいる本の最初の方というのは、第２章だけの４４ページ程度のこと。
たぶん８回ぐらいは読んだと思うが、前半がぼんやりと解ったような気持ちになるだけで、後半はまだまだだな〜という感じ。
サンプルソースをダウンロードしておかないと分からない個所がところどころにあり、幸いダウンロードは出来た。
趣味なので諦めずできるときに少しずつゆっくりと…orz

http://ux.getuploader.com/sggk/index/1/date/desc に>>348でUPしたSGGK028のクラス図をUP。（正確さに自信は無いけど、ソースを読む参考用）
また１カ月経過しようとしている。
>>349の後、同じ個所を２回読み、合計１０回程度は読んだはずなのに駄目そうな感じ。
でも、そう言いつつもさらにもう少し頑張れば分かるかもという気も何故かしている。

ここは気持ちを切り替えて、いったん今やれそうな範囲で進めてみようと思う。
クラス図のＵＰはその気持ちの表れ。
今、改めてソースを見ると、soccergame.cppの中の処理で
選手のメンバ変数　m_MouseTargetが　shiftキーを押したらfalse　、
押さなければ　true　になるようにし、選手移動関数では、m_MouseTargetを見て、
falseならば、その時点の選手移動方向をマウスカーソルに向かって更新しないことで一定方向に進み、
その間はフリーになったマウスカーソルに向かってボールを蹴れるようにしてある。

そこで考えたのは、
１．ボールの移動目標、
２．選手の移動目標
という２つの変数を用意し、これを状態を表す変数だと考える。
ボールや選手の移動関数はこの２つの中身を見て移動先を知るようにプログラムをもっとわかりやすく書けるのではと思った。

そのための次の作業は、ボールの移動目標、選手の移動目標の状態遷移図を書くこと。

説明不足だったかもしれないので…、
>>350のプログラムの場合、ある場所でフラグをセットして、
そのフラグを別な場所のif文で利用して処理を進めるやり方になり、
これは後々ソースが分かりにくくなるような気がしたので、>>351のようにしてみようと思ったという事。

>>350のリンクで最初のhを取り忘れてしまった。
もしかすると直接クリックしてもアプロダのページにいかないかもしれないので、
アドレスをコピペすればページが見れると思います。

生存報告。なかなか作業進まず。
選手の移動目標の状態遷移図は書いてみた。
この遷移を本で見たステートデザインパターンを使ってFieldPlayerクラスの中に実装できないかを思い、
FieldPlayerクラスがPlayerDataクラスを継承しているところにPlayerDataクラスがBaseGameEntityクラスを継承、
つまり継承の継承のように3段階にしたら、
「　クラス、構造体、共用体に既定のコンストラクタがありません　」というエラーが出た。
とりあえず、デフォルトコンストラクタを書いてないクラスがあったので書いてみたらコンパイラを通ったけど、
選手が真っ直ぐ動くだけでマウスについて行かなくなった。そろそろ限界かもしれない…。

ちょっと難しくやろうとしすぎてるのでは？
BetterCな感じで関数型な組み方してとりあえず完成に持っていった方がモチベ維持できるかも

見たところオブジェクト指向に移行しきれてないみたいな感じもあるから継承とか使ってても余計ややこしくなってるだけかも

影ながら応援していたけど
初めから難しい物を作りすぎてるって感じがするなぁ

今までの経験を生かして新たに１から出来るだけシンプルに
ファミコンレベルのサッカーとして動くものを作ってみて
それを改造していく方がいいんじゃないかなと

>>354,>>355
アドバイス、ありがとうございます！
１人でやってると気付かなくて、言われてみると確かにそうだな〜と思える…、ような感じです。
数年やってもこんな状況なんだから、きっとこの先も完成は難しい。

まずは第一段階として、今までの経験上作業に詰まる原因になりやすかったところ、
例えば、継承やコンテナ、デザインパターンを無くすか減らす事を考え、
クラスの組み方も見直して、選手の可能な操作も減らして、それでも先に進めそうになかったら、
第二段階として、さらに簡略化して１から組み直していこうと思います。

>>353でやろうとしていたステートパターンを中止。
FieldPlayerクラスがPlayerDataクラスを継承していたのをやめて、FieldPlayerクラスに一体化した。
そして選手移動関数の切り替えに使っていたストラテジーパターンの処理も外して、速度一定で歩く関数ひとつにした。

Application基底クラスとSoccerGame継承クラスの継承関係もなくして、
SoccerGameクラスに統一。基底クラスの変数があちこちで使われてて、直すのに苦労した。
SoccerGameクラスは印刷するとＡ４、１０ページの分量なので、頭の中を整理中。

SoccerGameクラスのソースが長すぎるので、GameTitleクラス、GamePlayクラス、GameOverクラスを作り、
SoccerGameクラスのソースをこの３つのクラスに振り分けてみた。
この３つのクラスをSoccerGameクラスの中でオブジェクト化すればなんとか出来るかもしれないので、試すつもり。
失敗してもこの直前まではバックアップあるので戻れるから大丈夫ｗ

最初から作り直した方が早いかもね

>>360
>>356では２段階でやるような気持ちでいたけど、いざやってみると、
クラスのつながりの一番根っこを分解したので結局全部書き直し同然の状態です。（汗）
とりあえず、スタート画面を出す為に、関係ないヘッダファイルやcppファイルはコンパイラから外して作業中…orz

デザインパターン使わないと言ったけど、ちょっとだけ試してみたかった。
本に書いてたステートパターンの中で最初の１番簡単な例を使ってスタート画面を出せた。
でも実はバグの行を//付けて注釈行化して強引に表示させただけなのでまだなんとも言えない。
残りのゲームプレイとゲーム終了画面表示の遷移が出来なければswitch文使った方法に戻る。
あまり時間が無いのでゆっくり作業…。

スタート画面とゲームオーバー画面をキー押しで表示切り替えできた。
ステートパターンの１番簡単な例と言いながらも苦戦した。
以前苦しんだ相互参照、前方宣言が関係してくるパターンだった。
本はその部分は知ってる前提で書いてあるので説明が無かった…orz
ネットも調べて知識を得てから考えた実装が動かず、結局試行錯誤で
インクルードと前方宣言を入れたり消したりして奇跡的に運よく動いた感じ。
せっかく書いたので、もし問題なく動くならこの部分だけはそのままにしておいて、
またバグ出たら、ifかswitchでやるしかない…orz
これ以降、遷移をさせたい処理が出てきたら、それはもちろんifかswitchでやるつもり（苦笑）

数年続けてきて自分には無理だという事がやっとわかった感じ。
やらないで諦めるよりは、やってみて気付いたんだから、よしとしよう！

とりあえずはファミコンサッカーを目標にしよう！（これすら出来るか怪しいかもしれない…）
空き時間ができたら作業を少しでも続ける気はあるので、がんばろう〜！…orz

昨日のプログラムを少し変えた。
１つの状態について１ヘッダーファイル、１cppファイルというのはファイル数が多すぎて分かりずらいのでやめて、
複数の状態を１ヘッダーファイル、１cppファイルにまとめた。
ステートパターンの参考にした本、オライリーのゲームＡＩプログラミングもそうなっていたし…。
一応、インクルードファイルや前方宣言も本に合わせてみた。
しかし、１か所だけSoccerGameクラスのヘッダーファイルのコンストラクタの行でエラーが出た。
コンストラクタだけ実装（というか定義？）がヘッダーに書いてあったので、
この定義部分だけをcppファイルに移したらコンパイル出来た。
とりあえず、この書き方で進めよう。
タイトル、ゲームオーバー画面が出せたので、次はメインのゲーム部分を書く予定。

SGGK氏には「まとめサイト」を作ることを提案します。
これまでに考えて行ってきたことと、それに対するコメントを対応付けると、
現在のご自身のポテンシャルが見えてくると思います。

また、まとめサイトを持っていたほうが、建設的なコメントが得られるように
なると思いますよ。

>>365
な…なるほど！、ありがとうございます。
ゲームが完成するか自信がないため、まとめサイトについては考えてませんでした。
去年9月頃に受けたアドバイスの後半から追いつけなくなってしまってたので、
そういうのもまとめられたらと思います。

ホームページは初めてだけど、頑張ってみます。

できるだけ簡略化した状態で作ろうと思い、
今まで使っていたフリー素材はやめて（ラインの座標が正確にわかっていたわけでは無かったから）、
フィールドは緑の板一枚にして、ゴールの絵は無し、ラインを毎ループプログラムで書き、
そのラインも外枠だけにすることを考えた。
緑色のポリゴンの板をとりあえず作成したが、メタセコイアの使い方をすっかり忘れてて苦労した。
今度はこれを画面に表示しようとしたら画面が真っ黒。
フィールドを原点（０，０，０）において、カメラは（０，１００、０）で（０，０，０）注視にしたから見えるはずなのに…。
ふと、カメラ座標を（１００、１００、０）にしてみたら一部が見えた。一応データは読めてるようだ。
メタセコイアで作った時の座標系やＤＸライブラリの座標系についていろいろ忘れてしまってるようだ…orz

ホームページは作業始めるまでにはかなり時間かかりそうだけど、あきらめずにやるつもり。
ＦＣ２で練習する計画。一応グーグルにホームページの登録はしてみた。

３Ｄで真上から見れば２Ｄになるかなという考えがあったから昨日のような事をしてたんだけど、
いろいろ悩んだ結果、２Ｄに戻ってやり直してみようと思った。
３Ｄについては、今までいろいろアドバイスもらっているのに止めるのはなんだか申し訳ない気持ちもあるけど、
今年の８月末で５年経つはずだし、まずは形に出来る可能性が少しでも高い方法を選ぼうと思う。
３Ｄでいろいろ学んだり考えたりした経験もきっと役立つだろうし…。
当時作った２Ｄスクロールはがくがく振動してたけど、それでも良しとするつもり。

フィールドの画像データ作成に時間がかかってしまった。
最初はファミコンサッカーのフィールドを意識して奥行を考慮したフィールドにしようと思ったが、これはやめた。
真上から見たフィールドにしたが、ドット絵なので、例えばある点と点を結ぶ直線の太さを４ドットにした時、
どのように書けば良いのかといった事にまで悩んでしまい、一度書きあげたが、なんとなく１〜２ドットずれてるような気がした。
そこで思いついたのが、真上からの絵なのだから１／４だけ書いて、これを３枚コピーして上下左右反転してから結合するというやり方。
幸いそのような機能がついていたので、ようやくフィールドの絵が完成した。

選手の絵を書き直した。
１チーム分の４コマｘ８方向分、キックの絵を１コマｘ８枚方向分まで完了。
これがもう１チーム分（色変えるだけでも結構手間な感じ）と
ゴールキーパー２人の移動も今日書いた絵を色変えるだけにして、ボールに飛びつく絵を１コマｘ８方向分欲しいとして…。
（３２＋８）ｘ３＋８ｘ２＝１３６枚書かなければならない…orz
絵の経験は全く無いので今まで使っていた影絵レベルに色を付けた程度のものになった。
ちなみに使用ツールはフリーソフトのＥＤＧＥ。

自分に負けて今週末は残りの絵を用意出来なかった。
それでも何かしようと考え、この前書いたフィールド（今回のは、1280ｘ420ドット）を座標(-320,60）に書いてみたら一応表示できた。
もしかすると(-319,59)かもしれないが、追及はしない…orz
グラフィックデータをロードするときのエラー関係の処理で書いてたC++の文法、throwやcatchの文も思い切ってカットした。
今度は思いつく限りの状態遷移をノートにでも書いてみようかと思う。
例えば、得点表示、時間表示、ボールがラインアウトしたとき、得点時、前半・後半・ハーフタイムの切り替わりの時どうなるかなどの遷移を整理して、それらをどうやってプログラムにまとめるかといった事を考える予定。
ゲームの設計図というものを知らないので、結局我流。

ゲームが１ループする毎に１ずつ増える変数を宣言・定義した。
この変数は、選手のアニメパターンの何コマ目を表示するかを判断するのに使われる。
「１４歳から（略）Ｃ＋＋（略）」に書いてあった手法なので特に新しいことはしてない。
つまり、自分はこの方法しか知らない…orz

まだクラスを増やさないでテスト的にプログラム中。（作業時間をなかなか確保出来ないので…）
選手の画像データを読み込むところまで書き、バグも出なくなった。
次は、選手をキーボードで８方向移動出来るようにする予定。
今までのマウスカーソルに選手が向かう仕様はやめることにした。

完全0の状態から小規模の3DMMORPGを作ろうとしてるんだが、勉強とトライアンドエラー続けて10年で稼働まで持っていけるだろうか。
とりあえずC言語の基礎本買ってきた。

努力の仕方次第で１０年かからずとも勿論可能だろうけれど、
そのゲームシステムやデザインが１０年後通用するものかどうかは解らない。

>>376
レスありがとう。
たしかに。進歩するの早いからな…。
最新情報つねに仕入れつつ、とにかく始めてみる。

>>375
自分は今年の8月末で５年経過。まだ１本も作ったことが無いのであと５年で出来るかわかりません。
今思えば、平均して1日どの程度の時間やっていたのか、集中力、やり方とかの管理や工夫が足りてなかったかもしれない。
5年やって実際何時間作業したかとか記録してなかったし…orz（今後は時間だけでもメモ！）
平均的にある程度時間を確保して継続して１０年やれればなんとかなりそうに思います。
ゲーム用ライブラリは、既存のものが使えれば時間の節約になってさらに良いと思います。

>>378
アドバイスありがとうございます。
作業工程管理って大事なのですね。
基礎を勉強しつつ、完成までに何が必要かを調べて、いつまでにこれができるようにするみたいな逆算は必要かもですね。
ライブラリもちと調べてみます！

確認し忘れてしまいましたが、
もしも学生で、しかも受験生だったりする場合は、勉強に１００％専念した方がいいです。

約１ヶ月経ってしまってるけど、ちょっと気になったので…（汗；）

>>374から進まず…orz
選手の８方向移動を通常ならifかswitch文で条件分岐して、
押したキーに応じて選手の座標に数値を足し引きするだけなんだけど、
そこを関数にして、その関数を関数ポインタとかいうのを使ってうまくまとめられないかと思ってしまった。
しかし、ネットで書き方を調べてるとＣ言語でいう関数とＣ＋＋のメンバ関数でのやり方に違いがあるようで、
なんとか空のメンバ関数を定義して関数ポインタを用意するところまでコンパイラが通るようにはなったけど、
結局、ifやswitch文が無くなるような書き方には出来なかったので、ここまでやって断念してしまった。
この作業にかなりタイムロスした。（汗；）

そして今度は選手のクラス、FieldPlayerクラスを作ってから作業した方がやりやすそうだと思い、以下のエラーが発生。

（略）
#include "fieldplayer.h"
class SoccerGame;
（略）で、
error C2236: 予期しない 'class' 'SoccerGame' です。';' が入力されていることを確認してください。

これは、fieldplayer.hの中に書いてあるFieldPlayerクラスの宣言の最後の｝の次に；を付け忘れたのが原因だと分かった。。
しかし、修正しても同じエラーメッセージが出続けて先に進まなくなった。
数日悩み、ＶＣ＋＋の画面での修正内容が実際のfieldplayer.h内部には書き込まれていなかったのが原因だとわかった。
fieldplayer.hをメモ帳で開いてみて気がついた。

何故そうなったかは分からないが、VC++で書いたプログラムが保存されるsourceフォルダがあり、
自分はfieldplayer.hをVC++画面メニューから作ってソリューションエクスプローラに登録した後、
fieldplayer.hが何故かsourceフォルダの外に作られていた事に後で気づき、fieldplayer.hをドラッグ＆ドロップして
sourceフォルダにいれようとしたら、偶然前のプログラムの同じ名前のfieldplayer.hが残っていたので上書きした事を思い出した。

この作業が何らかの影響を与えていたのかもしれない。

ソリューションエクスプローラからfieldplayer.hを外して、追加→既存の項目で再度sourceフォルダ内のfieldplayer.hを登録したら
プログラムのエラーが出なくなり動くようになった。

これだけで約一カ月経過…orz

頑張れ〜
おれもほぼ一人でRPGっぽいの作ってる。
いまマップエディタってくらい初歩的なとこ。

SGGK氏のレス全部読んでないしどんな感じかわからないけど、
サッカーだったかAIのサンプルで実例で学ぶAI入門みたいな本がある。既出だったらごめん
サンプルが↓のurlの一番下にあるファイルの4章にサッカーのボール追いかけるのがあるよ。
http://www.jblearning.com/Catalog/9781556220784/student/

>>383
リンク紹介ありがとうございます。お互い頑張りましょ〜！
実はこれの２章だけを以前に読んでみたことがあり、その時は１／３〜１／２位しか分からなかったので、
現在停止中ですが、今のプログラムが出来たら、また頑張って読んでみようと思っています。
リンクの方もダウンロードしてみました。
早く４章のサンプルのように画面を動かせるところまで行きたいです。

訳あって作業中断してるけど、時間が出来たらまた戻ってきます…。

乗っ取り

ドキュ読む気力はあるがコード書く気力なし

>>386-387
将来コードを自分で書きたくなった時に読んだ経験を活かせると思うし、
共にがんばりましょ〜！（＾＾

約1年5カ月経過。いろいろあって結局何も進められなかったけど、

１．>>365「まとめサイト」を作る
２．やってきたことを忘れてるので復習する

が出来たら、次をどうするか決めようと思ってます。

ホームページを初めて作ったのでまだ練習用だけど「まとめサイト」を作ってみた。
自分のコメントを残して、いままで何やってきたのかを振り返りやすくする程度には使えるけど、まとめとしては物足りないかもしれない。
でも時間がないので、これで発進！

http://gameprogram10.web.fc2.com/

復習するといったけど、もし再開するなら復習しないで全く０からまたやりなおすのが濃厚な感じ・・・。

やり方自体を見直さないと、０からやり直しても、同じ失敗を繰り返しますよ。

過去ログを一通り眺めましがが、前スレ778氏の指摘が実に的確だと思いました。
そのほかにも、すでに十分な技術的アドバイスも出ているような気がしますが、
おそらくほとんどが消化不良になっているように読めます。

ちょうど長期間のブランクがあったところですし、とりあえずプログラミングからは一旦離れて、
作ろうとしているゲームの設計書を丁寧に書きなおすことからやり直してみてはいかがですか？

>>390
見てくれてありがとうございます。
14歳からのＣ＋＋本のソースを理解し、それを改造してサッカーゲームを作ってみようと言う思いで始め、
本のソースを理解するためにクラス図なども書いてみたりして数年間やったけど、結局こうなってしまった。・・・orz
このスレの後半ではマイルストーンの提案もあってそれに沿う考えでいたけど、まずは設計書を書く方針でいっていみようと思います。
マイルストーン案も設計後に改めてやることになると思うのでスルーするわけではないです。

作業が中断しがちなので、ファミコンサッカーレベルでやると言っておいて申し訳ないけど
さらに簡略化した画像構成でつくる計画です。>>370、371で自作した絵も結局使わなかったし、
絵の経験もなく素材を自分で用意しようとすると時間が掛かりモチベーションが下がりやすくなることが分かったから。

スクロールもなし、３Ｄもなし、グラフィック素材の類は一切なしで、
ＤＸライブラリの線画で代用し、その代わりにゲームの流れとか遷移のようなものを
作れ無さそうでもいいから設計図に書いてみる予定。

ActionScript3.0でゲームを作ろうと１から勉強しているのですが、ポインターが無いの不自由でーす

画像が表示できた。
ただそれだけなのに、今日は何か嬉しいでーす

こんばんは。ActionScriptに関して知識・経験がないのでお役に立てませんが、作業が進んでいるようでなによりです。（＾＾）
こちらはいろいろ事情があって、また作業が止まってるけど、なんとか8月までには再開して、できれば作業を習慣化したいな〜と思っています。

>>394
こんばんは、はじままして。
mp3を鳴らせるようになりましたが、リピートの瞬間に一瞬無音の時間があってガクッっときまーす

文字も出せればもう何かが作れそうですね（＾＾
自分はホームページもソースもちょっと離れただけですぐ忘れてしまうので、思い出すところからの再開です。＾＾

今、自分の書き込みを見直すと少し言い間違えてた（＾＾；
まず最初にやるのは設計図からということで現在はゲーム製作に関する作業は停止中。
目標は８月の連休前後ごろから出来るだけ習慣的に（趣味的に）製作作業を続けられるようになること。

停止してるならその事をここに書いておいた方がいいかなと思ったので・・・

今度こそもっと作業が続けられるようにするために今は部屋を片付けたりして
身のまわりを整理しているところ。

あるときはis-a、そしてあるときはhas-a。
小手先のクラス構造を変えるだけの日々で、まったく前に進まないでーす。

部屋の片付けはやっぱり８月まで掛かりそう。汚部屋レベルまではちらかってないと思うけど、置く場所がなくて・・・orz
クラスについては中断後長くて忘れてるけどまた頑張って思い出そうと思っていて、
設計はファミコンが出る前のピンポンやホッケーのレベルまで下げる予定だから、今度こそ形にしたいです。

ActionScript、１割５分ぐらいは分かって来た！
ダラダラとしたこの勢いで、STGに挑戦してみまーす

８月が近づいてきて、片付けもある程度で済ませて設計を考える時期になってきました。
１年以上前のあの頃のプログラムの書き方、今の自分に思い出せるか不安・・・

>>401
＞思い出せるか不安

分かる！
その瞬間だけは、コメントやデバック文の重要性に気がつくｗ
引数の範囲チェックとか、本当、後で読み返すと本当に助かる。

でも、結局コメントやデバック文は手抜きになりまーす

たぶんコンパイラの使い方や言語も忘れてるので頑張って思い出さねばならなくなる予感。
後で中身を思い出せるようにコメントも書いていく予定です。

つ　「サッカーゲームの作り方教えろ」
　　　 ttp://peace.2ch.net/test/read.cgi/gamedev/1024411633/l50

ありがとうございます。ヾ(｡･ω･)ﾉ
これを２ヶ月で完成させるとは凄いです。プロかもしれませんね。

ActionScriptにも随分と慣れて、一般化・再利用可能な部分はライブラリ（.swc）に切り出し始めー。
も、色々いじっていると、ライブラリ部分を大幅に変更したくなり・・・。
大作業になってまーす。

こちらはホームページの練習を少しやってみた程度で、
インターネットが始まったころによく見かけた単純そうに見えてたホームページでも
自分で書こうとするとかなり苦戦しそうな感じ。
夏の暑さの所為であまり進んでないかもです。

>>407
暑さもストレスなので、それに打ち勝ち気分を乗せて継続するのが大変。

私も、ホームページの領域を用意して、単純なページを作り始めー。
たった、２〜３ページの.htmlを作るだけなのに凄い時間が掛かる。
今風のお洒落なページを作れる人を、純粋に尊敬するわ。

ただ、こういう色々な事をしてる時間が、楽しいでーす

今作ろうとしてるホームページは本の作例そのままのヘッダ２段＋コラムｘ３＋フッタ１段タイプ。
説明を見ながら真似してるけど、自分がやろうとしてる画面切り替えの部分が本と異なるので、そこは自分で考えなければならなくて、
これがうまく言ったらアップの予定。

>>409
言葉で見ると、なにやら難しそうな事をしてますね。

私は、ゲーム内の画面遷移の一般化や、ゲームがフォーカスを失ったときの一時中断画面に手を出し中ー。
ゲームの状態を保ちつつ、動きを全部止める。
まだ、ゲーム部分は全く出来ていないので余計な事を見なくて良いけれども、色々考えるのがメンドクサイでーす。

もう遷移まで進んでるとなるとゲーム部分もすぐ来そうですね。自分もがんばります(｀･ω･)

ホームページ作成は慣れればなんとかなるのかもしれないけど、いろいろ出てくる言葉を忘れない程度に少しずつ作業をしてます。
真ん中に３つ並ぶはずの文章を書くための領域がずれるので直すのにちょっと時間がかかりそうです。

ホームページは作りこむのが大変なので、ブログも併用してお手軽に行こうと思っていますー。

画面遷移に来て、立ち往生。
ActionScriptは、Windowの概念がないらしく（私が、知らないだけかも・・・）、擬似的なWindowを自分で実装しないといけないみたい。
画面遷移を実装する前に、Windowクラスを作っておかないと大変な事になりそうで、ちょっとクラクラ来ていまーす。

表示のずれが直った。練習はもう少し続きそうだけど、これが長引きそうだとブログに挑戦する可能性もありそうです。

自分が当時使っていた環境はＣとＣ＋＋でたしかＶＳ２００８用のＤＸライブラリで、
いまだに１本も完成できてないレベルなので、自分はプログラミングにあまり詳しくないです。
Windowクラスとかちょっと難しくてイメージができないです・・・orz
でも出来ればこの連休にこれらの環境を復活させて記憶を戻す作業にも入りたいです。
設計図はほとんどフィールドの絵が１枚とルールを数行書く程度を予定しています。

順調に進んでいるようですね。

私は、画面遷移で絶賛立ち往生中ー。
無理に汎用的にしないで、ある程度クラス内を汚す方向で行こうかなと。
とりあえず、簡単なゲームを１つ作り上げてみて、使い勝手とか不具合とかを実際に見てみない事には、私の脳みそでは着いていけないでーす orz

自分も今回は出来るだけ簡単なゲームにして最後まで出来るか試してみようと思ってます。

久しぶりにＤＸライブラリのページを見るとVS2008もあることにはあるけど、
VS2013版があるそうなので、どうせやるならと気が変わってvs2013EXPRESSをインストールしてみたところまで。

開発環境が整いつつあるのですね。

私は、Webで先駆者の方々の文章を色々読んで、自分なりに消化しているところー。
様々な考え方、見かた、捕らえ方があって、面白いと思いつつ読んでいまーす

自分も出来る限りネットで情報収集していこうと思っています。
ＤＸライブラリもパソコンに入ったので、設計図とホームページが用意できたら時間は掛かると思うけど、
少しずつ以前の記憶を取り戻していきたいです。

旅行に行ってて、２，３日製作から離れていたら、色々大変な事に。
作業はしないでも、毎日５分とか短い時間で良いから、製作のことも考えないとなー。
なんて、思っていまーす

人それぞれのペースでオッケーだと思います。
自分は趣味で作ろうとしていて、その都度実生活を優先しているので数年経過してるけど、
設計を小規模なものにして、その実装をするところまではなんとか実現したいです。（＾＾

仕事を始めたら、ゲーム製作をする時間と体力が無くなってしまった。
業務に慣れるまで、封印でーす

生活があっての趣味なので落ち着いたらまたいつでもどーぞ^^
自分も作業が止まっているけど、気長にやって行きます。

(アクセス禁止中なのでp2で書いたら2chscなのか不明なサイトに飛ばされてた...
アク禁のときは練習中のホームページに書いておくので、
そちらを見てもらえると安心です。^^)

書けるかな？

書けた。
簡単な説明用の絵を書こうとしても絵書き用ソフトが使えそうにないので、エクセルで書くことにした。（過去と同じ流れ）

Azpainter2などの手ぶれ補正(max40で使え)はいいぞー
大きめのキャンバスを設定して、
描いた後で縮小すれば、がたがたな線でも綺麗に見える。
アドバイスがもらえるので　お絵描きpink版をお薦め
（ただし、嵐等が常駐していて精神攻撃も強烈なので、タフな人向け）

遅レスになってしまいましたが、ありがとうございます。今後の参考にします。
今も作業は止まってて、やっぱり自分にはゲーム製作は難易度が高過ぎたかなーと今更思ったりするけど、
時間が出来てあと少しだけ進められたら、その先どうするか考えてみようと思ってます。