ゲームプログラミング相談室【Part6】

**名前は開発中のものです。** · 04/03/06 01:25

ゲームプログラミング全般の質問スレッド。
扱う話題のダイナミックレンジはやや広め。包容力高め。
他の初心者質問スレとの棲み分けを探りつつ
これからもマターリと活用しておくれ。
　
■過去スレ
【Part2】http://pc.2ch.net/tech/kako/985/985540361.html
【Part3】http://pc.2ch.net/tech/kako/1002/10028/1002894129.html
【Part4】http://game.2ch.net/gamedev/kako/1005/10050/1005040025.html
【Part5】http://pc2.2ch.net/test/read.cgi/gamedev/1036410116/
■関連スレなど
>>2-5

**名前は開発中のものです。** · 04/04/29 09:54

>>124
俺はちょっと違うなCharacter以外はCharacterのメンバにする。
ちょっと>>124は機能とオブジェクトをいっしょにしてるのがよくなさげ。
継承で考慮するのはオブジェクト指向の説明でよく出てくる
犬と猫は哺乳類で・・・云々の話だけでいい。
もしEnemyなんてのが出てきたら、Characterから継承するって感じの使い方かな。

EntityやRender、Collisionなんてのは明らかに
Characterが所有しちょるものなのでメンバでいいと思う。
Characterより上の方のクラスに入れるかもしれないものもあるね。描画とか。

まあ、クラスのまとめ方が、複数のクラスの処理を一括してやろうと頑張りすぎてて、
かつ、これから継承するものの違いまでカバーしようとしている感じがする。正直うまくない。
まあ、処理で考えるなら、
衝突の検出なんてのは関わるもの同士によって必要な情報が全然違うから
一括処理なんて必要ないならしないほうがいいと思うよ。（仕様変更あると思うしｗ）
逆に描画なんてのはどれも同じ処理になるはずじゃね？
Characterもしくはその基底クラスがRenderなんて関数をもってればそれでいいような気がする。

ＡＩクラスなんていったら、結構隔離できるクラスのような気がするが
実は他のクラスとの関連が一番多くなるクラス、また、他のクラスとの関連も一番特殊になるクラスだと思う。
何せＡＩの判断材料に他のクラスの情報が確実に必要になるからね。
ＡＩってのはCharacterそのものになると思うんだけどどうだろうか？
例えばCharacterから範囲１０以上に近づいたら、なんてやったらＡＩにCollisionのデータを使った衝突の検出が必要になるよね？
こういう処理自体をライブラリにするのはいいと思うけど、それに必要になる材料はもろにクラス同士の設計の関連になるわけで略ｗ

**124** · 04/04/29 13:08

>>126
CCollisionNodeをメンバにするのは考えましたが、
CRenderNodeをメンバにしてしまうと自身で描画コードを持てないので
描画情報を登録して後で一括描画してもらうって形ですよね。
この場合ちょっと複雑な事をやりたい場合にCRenderNodeに手を加えるハメになりそうですがどうでしょうか？
2Dなら描画形態は限られてくるのでメンバに持ってしまうかもしれませんが。

**124** · 04/04/29 13:09

>>127
～Node系は特定の機能を保有する事を保証するインターフェイスのような物なので今のところ名前の衝突はないですが、
拡張した場合に仰るとおりのぐちゃぐちゃなメソッドの群れになる可能性は大いにありますね。

**124** · 04/04/29 13:09

>>128
生成は各entityが任意にnewしてEntity管理クラスに突っ込み、
entityMgr.Add(new CEnemy); // class CEnemy : public CCharacter

各entityが初期化時に必要に応じて描画管理クラスやコリジョン管理クラスに自身を登録してます。
renderer.Add(this);
collisionMgr.Add(this);

各管理クラスが全登録インスタンスの仮想関数 Update(), Render(), Collide() を呼び出しており、
entity間のやりとりはentityMgr経由でメッセージを送受信して行ってます。

破棄は自分自身でentity管理クラスに破棄要求を出してentity管理クラスがインスタンスをdeleteします。
entityMgr.Remove(this);

なんだか鬱設計ですね。

**124** · 04/04/29 13:09

>>129
>>ちょっと>>124は機能とオブジェクトをいっしょにしてるのがよくなさげ。
>>EntityやRender、Collisionなんてのは明らかに
>>Characterが所有しちょるものなのでメンバでいいと思う
コリジョンや描画をメンバにするのはある程度納得出来るのですが、
自身の行動をメンバに委譲するってのはちょっとイメージが沸きません。
状態のみを委譲してそれを受けて自身の行動に変化をつけるのでしょうか？
たぶん違うぽ（つд｀）

ゲーム内に登場するオブジェクトの殆どはCCharacter派生クラスだと思うんです。
確かに画面には表示されないステージ管理クラスや当たり判定を行わないスコア表示部分などはありますが、
それらは本当に限られてくるんじゃないでしょうか。
共通のインターフェイスやリソースを含んだCCharacterを定義して全てのキャラクタをそこから派生させた方が、
より汎用性があるかなーと思った訳です。

**名前は開発中のものです。** · 04/04/29 15:51

>>132
管理クラスって作った奴が思うほど役に立たないことが多いから
もうちょっと設計考えて見た方がよくね？

>>133
>自身の行動をメンバに委譲するってのはちょっとイメージが沸きません。
どう組んでるのか詳細までは知らないけど、
結局、プロペラ付けたら空を飛んで欲しくて、車輪付けたら道を走ってほしいんでしょ？
ならそういう使い方でいいじゃない？

>共通のインターフェイスやリソースを含んだCCharacterを定義して全てのキャラクタをそこから派生させた方が、
>より汎用性があるかなーと思った訳です。
それはいいんだけど、継承を継承らしく使おうよって話なんだけど。
別にこう↓組んでも組めるっちゃあ組めると思うよ。
class CCharacter : public CEntity, public CRenderNode, public CCollisionNode {};
ただわかりづれぇって一点を除けばｗ

**名前は開発中のものです。** · 04/04/29 18:18

>>132
とりあえずそのノリなら漏れはついていけるから安心していいよ
邪道かどうかは別として、管理される側が自分を管理する側を知っているっていう
状態は改良できるとこだと思う

**名前は開発中のものです。** · 04/04/29 18:20

おまえらそんな議論は学校いってるうちにすませとけや

**名前は開発中のものです。** · 04/04/29 20:30

＞ゲームプログラミング相談室【Part6】
　　　　　　　　　　　　　　~~~~~~~~
問題は何もない。続けて良い。

**名前は開発中のものです。** · 04/04/29 21:45

邪道かどうかは別として、衝突判定が特別扱いされているのが気になる
なんでentity間のやりとりの一種として扱わないの？

**名前は開発中のものです。** · 04/04/30 02:06

>>130
スマン。やはり、CRenderNodeがどういったものか、理解せずに
答えたので、見当違いだったかも。

CRenderNodeは描画機能？をもっていて、描画する対象のインスタンスではない。
て事かな？
因みに俺はインスタンスを含むと思っていたので、あくまでも、メンバ（参照用のポインタ）という扱い。
（キャラと描画物が１対１ではないという事）

とあるミドルウェアでは、大概のクラスが、シーングラフノードの派生。という構造もあったし、
そういうのも面白いとは思うよ。

**名前は開発中のものです。** · 04/04/30 02:41

これっ

**124** · 04/04/30 04:19

>>134
>>管理クラスって作った奴が思うほど役に立たないことが多いから
全AI更新→全衝突判定→全描画
こんな感じにUpdate()やRender()ってのは一括して呼ばれるのが普通だと私は思ってます。
誰かが管理して順番に呼び出した方がスッキリしているような気がしますがどうでしょうか？

管理クラスがない場合って生成されたEntityのUpdate()はどうやって呼ばれるのだろう。
各Entityを木構造のノードにして子or兄弟のUpdate()を連鎖的に呼び出すのか、
それともリストをグローバルで持ってメインループか何処かで呼び出す？
誰かに管理させた方が不用意にノードにアクセスされないだろうしこれが普通かなーと
思ってたんですが一般的ではないんですかね。

>>結局、プロペラ付けたら空を飛んで欲しくて、車輪付けたら道を走ってほしいんでしょ？
この部分の話の流れとしてはCEntityから派生せずに
メンバとしてCEntityを持ったほうがいいよって解釈でよろしいでしょうか？
実際に移動を行う処理やアニメーションを行う処理なんかはAIと分離すべきだと思うのですが、
AIの部分をメンバに委譲して且つ自分ではUpdate()を持たないとなると
自分自身は何も行動を起こせないただの入れ物になりますよね？
うーん。

>>それはいいんだけど、継承を継承らしく使おうよって話なんだけど。
それが引っかかってたので質問した訳です。そしたらその他の部分でボロが出まくる出まくる(；´Д｀)
CRenderNodeやCCollisionNodeをメンバに持つってのはいいんですが
CEntityをメンバに持つメリットというか意味が理解できないのです。

**124** · 04/04/30 04:33

>>135
>>邪道かどうかは別として、管理される側が自分を管理する側を知っているっていう
>>状態は改良できるとこだと思う
でもリスト構造とかってそういう物ではないんですか？
ああ、ノード自身が管理クラスに登録するってのがマズイ訳ですね。
その点CEntity以外をメンバとして持った場合は
renderer.Add(this);
はアリですよね。

**124** · 04/04/30 04:35

>>135
>>邪道かどうかは別として、衝突判定が特別扱いされているのが気になる
自分の中では一括処理ってのが根底にあったので特別扱いになってます。
全ゲームオブジェクトの行動が終わってから衝突判定を一括で行うのでどうしても
管理クラスに自分を登録して後で判定を実行する必要があったんです。
Update()の中で衝突処理も行うとすればAI処理の一部として実装できますし、
自由度は増すと思いますがこれはゲームの規模や構造にもよりますよね。

**124** · 04/04/30 04:38

>>139
すみません、説明不足だったようですね。描画対象ではないです。
CRenderNodeはインターフェイスです。基本的にvirtual void Render() = 0;が定義してあるだけで、
レンダラがこれを任意のタイミングで呼び出します。
派生クラスはRender()を実装して1つもしくは複数のモデルをデバイスに対して描画してます。

**名前は開発中のものです。** · 04/04/30 05:47

>>141
>管理クラスがない場合って生成されたEntityのUpdate()はどうやって呼ばれるのだろう。
>各Entityを木構造のノードにして子or兄弟のUpdate()を連鎖的に呼び出すのか、
ん？処理の順番って基本的にこうやらないとまずくないか？
だって、親子関係では親から処理を実行していくようにしないと矛盾がおきないか？
子がワールド座標を欲しがるとき、親がすでに正しい位置に動いてくれていないと
子のワールド座標はバグるはずだけどどうよ？

>CEntityをメンバに持つメリットというか意味が理解できないのです。
俺はEntityクラスはキャラクタの行動を制御するものだと思ってたんだけど
実はただのＡＩクラスなの？

**１３５** · 04/04/30 12:37

>>142
管理される側が管理者のインスタンスを握っていて、
自分の登録と削除だけしかさせてもらえないならいいけど、
そうなってはいないでしょう？管理者を管理するクラスのために用意してある
メソッドにも自由にアクセスできるようになってしまっているはず。
インスタンスが無駄にグローバルになってるとか、
privateになっているべきメンバがpublicだったりするような程度でマズイです。
ヘッダのインクルードもクロスしてるでしょう。
そういうのはできるだけなくしていったほうがいいと思うよ。

>>143
シューティングゲームをつくってるのかな？
この衝突判定は「何に」当ったたのかみたいなことは分からなくてもいいの？
引数で衝突相手をもらうとしても、 Collide(const CollisionNode&) にならざるをえないし
これでは大抵は困ると思うけども

**124** · 04/04/30 19:52

>>145
管理クラス内にリストを持って実行順位毎に実行させるのと（現状はこれ）、
木構造にしてルートのUpdate()を呼んでやるのってのは実質的に同じだけど
木構造の方が何かと便利だよって事でしょうか。
何にせよルートノードは全ての子から見えるわけですよね？
インスタンスを晒さずに特別なアクセス関数を作るにしても
結局管理クラスと同じような存在になっていまうと思うんですがどうでしょうか？

>>実はただのＡＩクラスなの？
Entityは毎フレームUpdate()が呼ばれ続けるただのAIクラスって認識なので
EnemyはCEntityから派生させている訳です。
状態遷移や座標の更新、子entityの生成などをUpdate()内で行ってます。

**124** · 04/04/30 19:59

>>146
管理される側がインスタンスを握っているってイメージでは無いんですが、
管理クラスはシングルトンになっててほぼ全てのゲームクラスから見えてます。
単にリストのノードってのであればノードがリストのインスタンスを
知っている必要はまったく無いですが、
個が主体となるEntityでは知らないと何も出来ないですよね？
隠蔽さえ出来ればいいのであれば管理者のインスタンスを隠蔽して登録、削除は専用の
グローバルな関数経由で行うってのでも現状よりはマシなのでしょうか。

はい、シューティングです。
現状ではまさに Collide(const CollisionNode&) これですね。
CollisionNodeに相手のポインタを仕込ませているので
そのポインタ経由で相手の情報を得てますがやっぱりマズイでしょうか？

**名前は開発中のものです。** · 04/04/30 22:20

>>147
>管理クラス内にリストを持って実行順位毎に実行させるのと
この管理クラスって結局Updateを毎回読んでやるただそれだけのクラスなんだよね。
はっきりいっていらないんじゃないかなぁ。ってこと。
正直、完全自己完結処理な物体ぐらいしか恩恵が全くといっていいほどないじゃん。
一度管理クラスを捨てて１から考え直してみたらどうかな？

>Entityは毎フレームUpdate()が呼ばれ続けるただのAIクラスって認識なので
Entityクラスを継承してCharacterクラスができてるのはなんか
オブジェクト指向的にわかりにくくないか？（Ｃ＋＋の機能としてできるって意味とは別にして）
基本に戻って犬と猫は哺乳類でってところから考えると、
キャラクタはAI（脳みそ）でってなってちょっと変だ。
キャラクタは脳みそをもっていてって考えた方が綺麗に組めるんじゃないかな？

>>148
>管理クラスはシングルトンになっててほぼ全てのゲームクラスから見えてます。
こりゃグローバル変数と何も変わらないよ。
これが駄目だとわからないとなると、ちょっと修行が必要。
ちょっと面倒だけど、引数から渡すように改善できないかな？

**名前は開発中のものです。** · 04/04/30 23:35

前にも引数わたしの話がでてたけど、実際やってみるとかなりしんどかったぞ

例えば、引数を渡した関数から、他の関数を呼ぶときは同様に引数を渡さねばならない。
その関数から他の関数を呼ぶときも(以下略)
リファクタリングする度に、引数付き関数が増えていく。

さらに、引数がいらない関数から、引数がいる関数を呼ぶ必要がある時は、
呼び出し元を辿って全てを引数付き関数に変更せねばならない羽目に。
結局気づいてみると、ほとんどの関数が引数つきに。

一本の大きな関数で書ききるなら行けるが、
そうでない場合は、地獄を見ることに……

実際、引数わたしで上手く行っている人の話が聞きたい。

**名前は開発中のものです。** · 04/04/30 23:46

>>150
>例えば、引数を渡した関数から、他の関数を呼ぶときは同様に引数を渡さねばならない。
>その関数から他の関数を呼ぶときも(以下略)
>リファクタリングする度に、引数付き関数が増えていく。

漏れもハマったことあるな(w

**名前は開発中のものです。** · 04/05/01 00:08

まぁ、この辺はバランス感覚というか取捨選択になるでしょ。
何でもかんでもメッセージパッシングでやればパフォーマンス落ちるのと同じで。
　
膨大な数のインスタンスを高速処理せねばならないエンジン部に近いなら
美しさに伴う冗長性を嫌って汚いハックに走らざるを得ないし。

**名前は開発中のものです。** · 04/05/01 00:11

s/美しさ/OO的美しさ/

**名前は開発中のものです。** · 04/05/01 00:20

>>150
構造体で渡していくらか防げるかも。
でも、俺は引数増えても気にしないほうだなぁ。
DirectXがああだからしょうがないって言えばそうなんじゃない？

**名前は開発中のものです。** · 04/05/01 04:02

>>150
綺麗か汚いかじゃなくて、何を言いたいのかを考えてインターフェイスの仕様は決めるべき。
まして2chの名無しがうるさく言っていたからなんて理由では（ｒｙ

その参照の元が、そのインスタンスの一生のうちに変わる可能性があるということを示唆
するために、毎回参照を渡すようにしなさい。

その参照の元が、そのインスタンスの一生のうちに変わる可能性がないということを示唆
するために、コンストラクタで受け取り自分のメンバに格納しておくようにしなさい。

どちらが美しいとかどちらが汚いとかではない。

**名前は開発中のものです。** · 04/05/01 04:56

>>148
＞個が主体となるEntityでは知らないと何も出来ないですよね？
管理者のインスタンスで何をしたい？他entityの検索とかかな。

＞現状よりはマシなのでしょうか
インスタンスを生成した人がその人の好きな場所に登録できるのがいちばんよいよ。本当はね。

＞CollisionNodeに相手のポインタ
どういうクラスへのポインタ？

**124** · 04/05/01 06:39

>>149
そうですね。実際にコード化してみて比較しながら考えてみます。

>>キャラクタは脳みそをもっていてって考えた方が綺麗に組めるんじゃないかな？
理想はそうかもしれませんが実際キャラクタが自分の手足に命令を出したほうが
コード的に自然な作りになりませんか？
頭脳をメンバとして持った場合、親（キャラクタクラス）経由で手足クラスに命令を出す
となると複雑になりませんかね。

>こりゃグローバル変数と何も変わらないよ。
変わらないですね。
生成＆破棄が頻繁に行われるオブジェクトや状態が変化するものに関しては隠蔽すべき
だと思うんですがシステムで唯一無二の存在であろう管理クラスくらいはグローバルでも
いいと思うんですがどうでしょうか？
管理クラス的なものはそんなにポコポコ作らないでしょうし。

**124** · 04/05/01 06:42

>>150
実際それをやって幸せになりました？

**139** · 04/05/01 06:50

>>144
ああ、そんな気はしてたが、
virtual void Render() = 0;が定義してあるだけ。か。
俺ならCGameObjectてなクラス作って、メゾットにしちゃうか。
Update()も同様に。

CRenderNodeという名前は、紛らわしいね。tree構造を連想させられる。

管理クラスは、俺も用意してる。
シングルトンで、ファクトリパターンクラスの派生。

作ってるものも同じ。シューティング。
AIは用意してないけど、その辺りを用意すれば、アクションゲームもOK。
ただ、AIをハードコーディングしようとは思わないが。
ありものを作るなら、大抵、コリジョン判定、条件判定の組み合わせが違うだけだから。

**124** · 04/05/01 06:58

>>156
>>管理者のインスタンスで何をしたい？他entityの検索とかかな。
そうですね。
Entity間のやり取りでも管理者をかませた方が不正アクセスをチェック出来たり
デバッグ用のアクセスログ吐かせたり延滞メッセージ的な通知とかも出来そうだし。
仲介役が居ることのメリットはあるんじゃないかと思います。

>>どういうクラスへのポインタ？
ここで言うところのCCharacterですかね。
この部分は正直変な事になってると思います・・・。

**124** · 04/05/01 07:22

>>159
CGameObjectを管理するクラスがあってそのクラスがレンダラを持ってるんでしょうか？
例えば管理クラスが全ゲームオブジェクトのUpdate()を呼んでからレンダラの参照なんかを
Render()に渡してあげるとか。

AIはハードコーディングしてしまうかも。
部分的に再利用可能な形にする事もできるしちょっとした色付けは外部ファイルから
入力してあげれそれで十分かなーと。

**139** · 04/05/01 07:48

>>161
実際、今作ってるものには、CGameObjectというクラスはないんだけど、、。

CGameObjectもしくは、CGameObjectManagerが、必要なタイミングで
（生成時、初期化時、視界内に入ってきたとき等々）
に、描画エンジンのmanagerを使って、描画オブジェクトを生成。と。

で、擬似コード
app::Update(frame)
{
描画manager->Update( frame );
GameObjectManager->Update( frame );
}
と。
描画機能と、ゲーム（CPU）的な機能は分離してます。

**139** · 04/05/01 07:53

言葉足らずだったかな？
要するに、CGameObjectは、レンダラ機能はもたず、
レンダラがもつ描画ノードの参照を持ってるだけ。
update()時も、描画用のセットアップをしているだけ。

**名前は開発中のものです。** · 04/05/01 08:16

>>157
>頭脳をメンバとして持った場合、親（キャラクタクラス）経由で手足クラスに命令を出す
>となると複雑になりませんかね。
どうして？変わらないと思うけど。
手足クラスが何やるか知らないけど、頭脳と手足が認識できる構造なら
どういう処理にしろクラスにしちゃった方がわかりやすいじゃん。

>システムで唯一無二の存在であろう管理クラスくらいはグローバルでも
>いいと思うんですがどうでしょうか？
駄目だよ。グローバル変数が駄目な理由も理解してないな。
システムで唯一無二のものを直接コードに入れちゃうってことは
そのクラスはそこでもう身動きがとれなくなっちゃうってことだよ。
どこでもどんなタイミングでもアクセスできちゃうし、
一番怖いバグが出るパターンだよ。

**名前は開発中のものです。** · 04/05/01 10:28

>>158
なりませんでした
概念だけは美しいが、コードは美しくなく汚くなっただけ
なんだかC言語で、OOやったときのような気分

**名前は開発中のものです。** · 04/05/01 11:23

>>165
なんでそう見た目だけにかき回されるのか激しく疑問。
いくらコードが美しくたって概念が糞なら糞。
>>155のいう通りだろ。

**名前は開発中のものです。** · 04/05/01 11:31

むしろ、実装してみると、概念の方があなたの言う「見た目」に見えてくる
>>150みたになるのを防ぐ方法が挙げられなければ、
スパゲッティなコードになることを回避できない。

**名前は開発中のものです。** · 04/05/01 11:33

>むしろ、実装してみると、概念の方があなたの言う「見た目」に見えてくる
わかりにくいな

むしろ、実装してみると、概念にかき回される、と言いたい

**名前は開発中のものです。** · 04/05/01 11:42

>>167
じゃあ構造体でわたせば？（これで解決するよね？）

**名前は開発中のものです。** · 04/05/01 11:53

>>160
＞仲介役が居ることのメリットはあるんじゃないかと
なにもできないわけじゃないなら、管理される側からは管理している側が見えないように
しておいたほうがよい。管理する側の何かを変更をしたい時に、
管理される側にはその変更によって何も影響がないということを確信をもって取り組むことができる。
そのメリットの方が仲介役と管理者がいっしょにいることより大きいと思うよ。

もしも仲介役が必要ということなら仲介役クラス、というかインターフェイスをつくって
entity生成時に持たせてあげるようにしたらいい。

>>164
＞グローバル変数が駄目な理由も理解してないな。
グローバル変数は、そのクラスが変更されたとき、膨大なコードの全体に対して
影響が及んだかどうかチェックして問題がないことを確信がもてる精神力が
あるのなら使える。ぼくは精神力に自信がないのでシングル㌧をさらすことはせず
必要とされる単純な処理だけをstaticメソッドとして公開してるyo

**名前は開発中のものです。** · 04/05/01 12:28

まぁ最初はリソースやコンテクストをいちいち引数渡しする形でデザインしておいたほうがいいんじゃないか
そのクラスのそれ以外のメソッドがリソースやコンテクストなしでも動けるなら、そのほうが。
んでクラスの全部のメソッドがそのリソースやコンテクストなしでは動けないということが判明したら
コンストラクタでもらうようにしては。

**139** · 04/05/01 12:31

>>167
俺の場合、「やばい！」と感じたらｗ
とりあえず、クラスにして渡す。

作業してて「これやばいな」と感じたら、そのまま突き進まず、
別の回避策を考える事にしてる。絶対可笑しな部分があるから。

**152** · 04/05/01 13:27

>>166
というか155は抽象的極論なので一体何が言うとおりなのか理解不能です。
この際言葉遊びは捨てて（というか面倒くさいので）美しさ＝概念的合理性と
解釈てしまいますが・・・・確認なんですが
こういうものを追求することは当然なのでありますが、これらが常に計算機側の
特性とマッチするわけでない、ということはお互いの共通理解として宜しいですよね。

ゲームの場合、わりと頻繁に　この部分が絡むので論争に発展するのだと思います。
現実（ハード特性）との不整合を冷酷に示すパフォーマンスアナライザを恨めという
以外ありません。

**152** · 04/05/01 13:35

まぁ、ただ今読み返すと、ここで議論にあがってるのは
純粋に設計上の不備の部分の話なのかなぁ、とも思うので
173の内容は無粋だな。却下。

**名前は開発中のものです。** · 04/05/01 13:44

ロジックとハード特性の不整合というより、ロジックと言語仕様の不整合、かな。

**152** · 04/05/01 13:48

>>175
そんな感じですな。美しさ＝記述上の美しさ、という意味合いなら
やっぱ173は筋違いやね。

**名前は開発中のものです。** · 04/05/01 14:04

いや、俺は>>173の言ってることは当然のことなので悪いとは思わない。
ゲームにもよるが、ノードの数が物凄く多くなればキャッシュヒット
やら何やらの問題がボロボロと表出することがあるので、途中で
精度犠牲にして走査回数抑制する方向でロジックを修正することあるし。
最悪、内部データ構造から洗いなおすハメになることもあるし。

**名前は開発中のものです。** · 04/05/01 14:15

純粋にパフォーマンス上の話だと
手荷物にするか置き勉にするか、状況によっては相当違ってくるよね。

**名前は開発中のものです。** · 04/05/01 14:29

>>173
>美しさ＝概念的合理性
え？じゃあ、なんで俺にレスつけんの？
俺は
>>165の
>概念だけは美しいが、コードは美しくなく汚くなっただけ
っていう言葉に対してレスつけたんだけど。
引数で渡すことに関しては賛成ってことでいいんでしょ？

**173** · 04/05/01 14:50

概念＝抽象モデルという話なら、>>173は
抽象モデルが糞なら（結果としてそれは）糞という発想は極端だなぁ
という、やや無粋な話。

抽象モデルとして説得力のある・人の直感的に分かりやすい代物であっても
それが常にハードウェア特性との親和性を伴うわけではないならば
何が糞で何が糞でないのか、は一概には決め付けられないだろう、という話。

これは詭弁ガイドラインに抵触している気がするので、>>174で取り下げた。

**名前は開発中のものです。** · 04/05/02 00:05

スクロール処理に関して知恵をかしておくんなさい

１．２ＤのアクションＲＰＧをつくっています
２．プレイできる範囲全体を１００＊１００セルとして定義、後ろ（どっか）にもってます
３．プレイヤーの見える範囲を１０＊１０として定義、現在の座標位置より、２．でもってる内容から上下左右に１セル分多く取得してきます。
４．３．で１セル分多く取得してきているぶんをつかってプレイヤーが移動したときに、すこしずつずらしていきます
５．実際の画面への表示は、３．の内容にマスクして、１０セル分だけ表示し、スクロールにみせかけています

最初は２Ｄのスクロール処理のみを考えていたんで、この方法で、スクロール処理ができるようになってよかったんです。
が、他のプレイヤーや、キャラを追加して、そいつらの動きが入ると意味不明になってしまいました。

たとえば、プレイヤーが(x,y)=(10,10)の座標にいて、他のプレイヤーが(x,y)=(12,12)の座標にいて、
プレイヤーが(x,y)=(10,11)に移動、他のプレイヤーが(x,y)=(12,11）に移動すると
先の上で説明したような状況になったときに、どう他のプレイヤーを描画したらいいのか悩んでます

考えているつもりですが、意味不明になって悩んでしまいます

全体的な処理としては、メインのループがあって、そこで、くるくるまわして描画処理をしています。

キーボードのイベントや、マウスイベントや、ネットワークからのイベントは、別のスレッドでキューにいれて、
上のメインを回しているスレッドから読んで描画に関する処理に影響させています。

長くなってしまった上に、意味不明なことを書いているようなきがするんですが、
よかったら知恵を貸してください。

**名前は開発中のものです。** · 04/05/02 07:16

>>166みたいな、単なる貶し系の文章が書きたいだけのやつが一人いるんだよね。
それが気に入らないから俺しばらく常駐してみてるんだが。

**名前は開発中のものです。** · 04/05/02 11:23

>>181
>そいつらの動きが入ると意味不明になってしまいました。
どう上手くいかないのかわからないんだが、
とりあえず、スクロール処理の部分って
プレイヤーの現在位置から見える範囲を決めてるわけだから
他のプレイヤーってこの処理に関係ないんじゃないの？

>>182
>>182の内容が貶し系なわけだがｗ

**名前は開発中のものです。** · 04/05/02 14:39

>>181
　文章が長い割に、必要な情報が欠落している。
他のプレイヤーやキャラとはなんなのか、説明をちゃんとしろ。

**181** · 04/05/02 15:03

>>183
>>184

もうちょっとまとめてみました

プレイヤーと動かない対象（床と動いてないキャラなど）
にかんするスクロールは問題ないです

自分がスクロールしている最中に、
画面内に動く対象がいると、スクロールがうまくいかず、
飛んだみたいに見えるわけです
自分が(10,10)→(10,11)に移動し、
動く対象が(12,12)→(12,11)に移動したら、
2セルぐらい飛んだように見えるんです

また、自分が止まっている時に
画面内に動く対象がいても問題なく動いています

結果：
自分がスクロールしているときに
画面内の動く対象の描画位置を計算するルーチンがおかしい、
または、そんなルーチンが動いていないから、
飛んだように見える

あぁ、なんか解決したような兆しが見える・・・

**名前は開発中の者です。** · 04/05/02 16:53

背景に張り付いてるキャラクターが、主人公と逆に動いた場合、
倍の速度で離れていくのは、普通のことなのではないでしょうか。
ドラクエやイースもそうなってるはずですよ。

（あまり関係有りませんが）
セルという言葉を使ってるようですが、RPGツクールでいうところの
「チップ」のことでしょうか。小さい四角のことをセルというのは
PCエンジンぽいですね。でべろかなんかいじっていた人なのでしょうか。

**名前は開発中のものです。** · 04/05/02 17:07

>>185
「飛んだように見える」と言われても

**練習帳著者** · 04/05/02 17:21

>>185

スクロール時のキャラクタ描画を「現在のスクロール量（ずらして
描画しているピクセル数）を減じた座標」に対して行うようにすれ
ばよいのでは？　わかりにくければ、方眼紙に表示領域とスクロー
ル領域を描いてみて、１ピクセルずつスクロールさせるとどうなるか、
なぞってみてください。

**181** · 04/05/02 17:30

>>186
おっしゃるとおりですね。
倍速ではなれていくことを表現したいと思っています。
現状ではキャラがスクロールするというより、
飛んでるというかんじで、なんでかデバッグ中です

セルという言葉は、距離を表現するつもりでつかっています。
プログラム中では１セル中にはりつけるタイルを
チップという名前をつけています
ゲームプログラムは今回が初めてで、
詳しいこともわからず独善的に作っています
だから言葉も適当です
適切でなければ、以後、脳内で置換します

**181** · 04/05/02 17:35

>>187
そうですよね・・・。
適切な表現ができていないですよね。

>>188
すばらしいアイデアですね。
早速方眼紙にかいて試してみました。
なんか、自分のルーチンの間違いが見えてきた気がします。
サンクスです。

こーやって書いて実際に試してみるのがとても大切ですね

**181** · 04/05/02 17:55

自分の間違いがわかりました。

スクロール処理に問題があり、
>>188さんのアイデアで解決しました。
ありがとうございました。

次は、デバッグ中にわかった問題を解決していこうと思います。
自分が(10,10)にいて、動く対象が(12,12)にいて、一旦描画したとします。
その後、次の描画処理までに動く対象が(12,11)、(12,10)と移動した場合、
2セル動いているので、スクロール処理が想定している
ルーチン中で判断できず、飛んだようにみえていました。
自分の処理の中では必ず1セルしか動かないようになっていました。

これは現在作成しているプログラムで、ステップ実行などをしている際に、
動く対象が1セルずつ移動しているが、
実は2回移動して2セル動いてしまっている際に起こっているようです。

今はステップ実行などを行わない限り、こういった状況にはならないわけですが、
いずれさまざまな問題で発生する可能性があります。

で、解決案として以下を考えています。
①放置、トンでもいいじゃないか
②軌跡を事後に計算して描画処理をさせる

①でいこうと思っていますが、みなさんならどうされますか？

**名前は開発中のものです。** · 04/05/02 18:01

微分する

**181** · 04/05/02 18:07

微分して、軌跡に近いセルに描画ですか
いいアイデアですね

**名前は開発中のものです。** · 04/05/02 23:24

>>181
処理構造に問題があるんじゃないの？

移動は、そのセルとやらが何ピクセルの大きさか知らないが段階を踏んでるんだろうね？
つまり、32ピクセル x 32ピクセルの大きさなら
移動は、瞬間移動？
それとも8ピクセル程度づつスライドして滑らかに描画してる？
背景のスクロールもしかり、セル単位で瞬間移動描画してる？

というか、スクリーン描画座標と
背景セル上での座標がつじつま合ってれば、そんな問題は出ないでしょ？
どっかに構造的、発想的な問題があるんでしょ。

**181** · 04/05/02 23:43

>>194

スクロールは、1回の移動あたりが１セル（16ピクセル）
1セルあたりの移動時間を500m秒
描画時に16ピクセル＊（現在時間－移動開始時間）／1セルあたりの移動時間
としてスクロール表現のためのマージンを計算してずらす値にしています

>>どっかに構造的、発想的な問題があるんでしょ。
ありました。
自分がスクロールしている最中に、動く対象が動いた場合、
座標計算が元の位置のまま計算していたので、おかしかったです。
この問題は>>188さんのアイデアで解決しました。

**名前は開発中のものです。** · 04/05/03 00:42

＞自分がスクロールしている最中に
処理は人によって自由だけど、
普通は自分(主人公キャラでしょ？)は、MAP上を移動していて
スクロールは別処理でしょ。
つまり、スクロールがどうなってようと
キャラ(主人公だろうが、違う移動キャラだろうが)はMAP上を移動するって処理で問題でないと思うけど？
移動したMAPのセルの更にそのスクリーン座標でキャラ管理でもしてるの？

キャラのMAP上の座標(セル) ->(スクロールしてようが)-> その描画スクリーン座標って処理をかませれば？

**名前は開発中のものです。** · 04/05/03 02:17

ｃかｃ++でdirectx使ったシューティングゲームのプログラミングを
基礎から完成まで詳しく解説してたサイトがあったんですけどお気に入りを謝って消してしまって見つかりません
そこのサイトの手順にしたがって学習していくと初心者にもとてもわかりやすくかったのに…
ソースファイルをコモンファイルとかに分割する方法まで詳しく解説してくれてたサイトで
CとC++とdirectxの基礎をまなびながらシューティングゲームを作るサイトでした

gooで色々検索しましたがなにしろヒット数が多くて探しきれなかったです

もしこのようなサイトをご存知でしたらご一報お願いします

**名前は開発中のものです。** · 04/05/03 02:30

あきらめろ

**名前は開発中のものです。** · 04/05/03 07:03

Game Programming Gems 4 を読んだ人はいますか？
1とか2があればそれほど必要ではないですか？

**名前は開発中のものです。** · 04/05/03 07:52

>>198
まじでお願いします

**名前は開発中のものです。** · 04/05/03 07:59

>>200
そのサイトに書いてあった言葉思い出してgoogleに突っ込んで
検索かけてみるしかないでしょ？

それより、気にするべきは再発防止だね。
お気に入りを消してしまったから、わからなくなりましたなんて
２度もやったら恥ずかしすぎて俺なら死にたくなるね。
人に知られたら、もう、２度と社会に出れないね。
永遠の負け組確定。

お気に入りの保存の仕方は覚えた？

**名前は開発中のものです。** · 04/05/03 08:12

>>199
俺は注文したよ。まだ届いてないから何とも胃炎が。
原書のほうは（邦訳版よりは）安いんだし。買っとけ。

**名前は開発中のものです。** · 04/05/03 15:40

>>201
アドヴァイスありがとうございました
お陰で見つかりました

ちなみに探してたのは
http://rina.jpn.ph/~rance/index.html
このサイトです

**名前は開発中のものです。** · 04/05/03 16:03

ネットワークゲームを作りたいのですがお勧めの本を教えていただけませんか。
探したところネットワークゲームを作るための書籍が少ないように感じましたので
書き込みました。ちなみにDirectPlayを使おうと思っています。
やはりTCP/IPとかのゲーム以外でのネットワークプログラミングという形で探したほうがいいのでしょうか。
アドバイスお願いします。

**名前は開発中のものです。** · 04/05/03 19:38

資料はあるだろう
まともなサンプルは見たこと無いが

**名前は開発中のものです。** · 04/05/03 19:43

>>181
そもそも、根本的に位置の管理方法が間違っていると思う。

プレイヤーやその他の移動するキャラクターの位置は、
背景スクロールにかかわらず、背景全体が収まる座標で持てば良い。
もちろん背景は、動かないとして計算する。

そして、実際の画面に出す時に、プレイヤーや他のキャラクターの位置を
画面内の表示位置に変換する計算式、表示する背景の領域を求める計算式、
を用意して、それぞれの表示位置を決めれば良い。

**名前は開発中のものです。** · 04/05/04 03:34

JavaやC#に慣れていると、
C++での開発が効率悪くてかなわない。
DirectXを用いたゲーム開発では、
いまだにC++が主流だしやむをえず。

**名前は開発中のものです。** · 04/05/04 05:59

スーパーファミコン用シューティングゲームのプログラムに携わった人いる？

**名前は開発中のものです。** · 04/05/04 06:58

>>207
そんなに変わるか？
オブジェクト指向言語だし、たいしてかわんねーよ。
何やって使ってんだよ。

**名前は開発中のものです。** · 04/05/04 07:20

>>207
>>209
まぁまぁ

**名前は開発中のものです。** · 04/05/04 09:08

まぁ、結構変わるね

結局ゲームで多用するリスト系とかはこれら中間言語系は得意
ポインタでガシガシやりよりバグでないしね
コンパイル時でエラーだしてくれるのでＣより実行時でのチェックが少なくて負担は減る

ぶっちゃけＣ＋＋はオブジェクト指向風味を取り入れたＣでしかないと思われ

俺も深くjavaとかc#に触る前まではあんまり変わらんと思ってたけどね

**デフォルトの名無しさん** · 04/05/04 09:49

SSE がもうちょっとレジスタ本数増えて
ベクトルの基本演算くらいサポートしてくれたらなぁ・・・
頂点シェーダレベルのことができるサブプロセッサがＣＰＵ側についてくれたらよいのに

**名前は開発中のものです。** · 04/05/04 10:05

無駄に難しくてよいと思っている

何もかもアセンブラでもよろしい

怠け癖がつくと最終的には
「寝ッ転がりながら頭に概要を思い浮かべるだけで勝手にソース書き上がるようにしてほしい」

などと言い出しかねない

**名前は開発中のものです。** · 04/05/04 13:07

簡単、難しいていうより、注意力便りなのは嫌。
人間、ミスする生き物だし。
人的ミスが入らないように自動化出来る部分はすべき。

**名前は開発中のものです。** · 04/05/04 14:58

より具体的に言うなれば、
メモリ内のデータフロー、ロジックフローを
きちんと把握、利用できることが重要なのであって、
それに関わるコンピューター寄りの知識は
速度を重要視しない限りは必要無いんだよな。

環境に頼って手抜きしようとする人間は、
複雑化したデータフローなんて追えなくなってあぼーんするだけ。
でも環境に依存しようとしない人間は
脳内で可能な限り動きを構築してから実際にコードに落とすんで、
コンピューター寄りの本来の目的と直接関係しない部分は排除した方が都合がいい。

自分でデータを細かいところまで管理する環境を少しでいいから経験しないと、
メモリ上のデータをどう扱ったらいいのか学習しにくい。
学習初期に
「メモリ上のデータはライブラリが管理してくれるから俺はデータ突っ込むだけー」
なんて覚えたら洒落にならん。
確かにデータは突っ込むだけなんだが、
何も考えてないとすぐに商品が整頓されてないコンビニみたいになる。
学習初期に最も重要視すべきは管理能力だ。
結局、若いうちは無駄だと思うことも多少はやっといた方がいいってこった。

管理能力がしっかりしてきたら、最近の超高級言語に触れてもいいと思うな。
その方が開発効率いいもん。

**名前は開発中のものです。** · 04/05/04 15:50

>>215
いや、さすがにそんなところは
必要ないって言えばない部分だろ。
アセンブラ組んでた俺でも最近は絶対いらないって確信もって思うぞ。

**名前は開発中のものです。** · 04/05/04 16:39

>>216
現在は開発する上では必要ない事でも、知識としては知っておいた方が
良いことって、あるじゃない。

**215** · 04/05/04 22:27

>>216
俺もアセンブラほどの学習は要らないと思うよ。
C/C++ でそこらのアルゴリズム本の内容を自分で実装できる程度で充分。

> 必要ないって言えばない部分だろ。
言えばない部分だな。

**デフォルトの名無しさん** · 04/05/04 23:02

レイとトライアングルの交差判定ルーチン
ＳＳＥ化したら笑っちゃうくらい速くなった
アルゴリズム全く換えてないのにＣ＋ＦＰＵで書いたものより
２０倍平均速くなった

ＳＳＥで内積だすのいちいちマンドクサかったけど
当たり判定が２０倍速くなったっつーのはでかいので満足

**名前は開発中のものです。** · 04/05/06 06:47

何がひでえって、ライブラリ頼りな奴！
メーカーで言えばIO Interactiveみたいな

MFCで楽に組めるんだから最適化なんて面倒でしてらんないよーん

みたいな感じで思い浮かべてもらえると分かりやすい

だからっつってN64みたいな職人芸的コーディング必須！
んな環境はノーサンキューだが。

**名前は開発中のものです。** · 04/05/06 07:50

仕事干されたハゲが吠えてますが、そっとしてあげてください。

**名前は開発中のものです。** · 04/05/07 14:08

アセンブラでリバースエンジニアリングできる奴はとにかく食うに困らないな。

アンチウィルスで金を稼ぐ会社なら、これができるだけでOKだし
Winnyをイジッて暗号化を解いた奴もこれで金を得、
ウィルス作って人に迷惑かけるのにも役立つから、
まことにもって有用な言語だな

食うには困らんが時間は不自由するがね

**名前は開発中のものです。** · 04/05/07 15:15

＞アセンブラでリバースエンジニアリング

ﾊｧ…

**名前は開発中のものです。** · 04/05/07 15:39

2Dのアクションゲームを作っています。

　２つの長方形同士の衝突判定を行いたいのですが、それぞれが回転しているので
頂点のXY座標の大小で判断すると言う手法が使えません。

　法線の内角外角を使うとか、行列を使うとか、３D制御に近い手法が有ったような
気がするのですが、平面限定で高速化する手法はないでしょうか？

**名前は開発中のものです。** · 04/05/07 15:49

正確な判定方法と高速化は別問題。
高速化したければおおよその判定後、厳密な判定を行えばいいだけの話。

**名前は開発中のものです。** · 04/05/07 16:05

>>224
AABB、OBBをキーワードにgoogleで検索してみ。

ちなみに「頂点のXY座標の大小で判断すると言う手法」は
一言で言えば2DにおけるAABB同士の衝突判定だーね。
OOB同士の衝突判定の適用対象を絞り込むためにAABBを
使うのも当然可。

**名前は開発中のものです。** · 04/05/07 16:05

s/OOB/OBB/

追記 · 04/05/07 17:55

>>225
＞正確な判定方法と高速化は別問題。

正確かつ高速であればより良い場合が多いわけだが、別問題とはこれいかに。

＞高速化したければおおよその判定後、厳密な判定を行えばいいだけの話。

「だけ」か？高速化手法は何も一つではないんだが。