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

**名前は開発中のものです。** · 2013/08/12(月) NY:AN:NY.AN

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

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

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

**名前は開発中のものです。** · 2013/09/29(日) 21:07:58.43

>>214-215
数に関してはそんな感じです
なるほど、テーブル使ったほうが確かにイイですね
そしてそのテーブルを扱うためだけの関数を作ろうと思います。

>>220
ふむ・・・少し難しいですね
その方法だとどこでモンスターを指定できるのかが良く分かりません
CBattleにコンストラクタでモンスター種別（ID)を引数にして、
IDによって持たせるポインタを変える…というのは出来ないですよね？

**名前は開発中のものです。** · 2013/09/29(日) 21:31:00.15

>>220
モンスタークラスのコンストラクタにモンスターデータクラスのインスタンス渡して、
モンスターデータクラスのコンストラクタにはプライマリキー渡して外部ファイルの読み込みとか

**209** · 2013/09/29(日) 22:34:23.36

>>221
モンスターの指定はCMonsterのコンストラクタか初期化関数で
CMonsterDataのポインタを渡せばよい。
イメージとしてはCMonsterDataの統轄クラスがCMonsterを吐き出す工場メソッドを作る感じ。
敵の種類のランダム指定もそのメソッドでやらせればよい。

CBattleについては設計思想にもよると思うが、個人的にはstateパターンを薦めたい。
例えばこんな感じ。
class CState
{
protected:
CMonsterData統轄クラス *monsterdatamanager; //参照するのみ
public:
virtual int OnClick(int x,int y){return 0;} //マウス操作はあまりしないと思うが
};
class CBattle : public CState
{
CMonster *monsters[敵の数];
};
class CFieldMap : public CState
{
};

**名前は開発中のものです。** · 2013/09/29(日) 23:46:36.57

>>205
実家で技術評論社の「はじめてのC」読んでたらオカンと姉ちゃんがすげー剣幕で本をぶんどって行ったことがあったなー。
中身を確認した後顔真っ赤にして戻っていったが。
セックスの教本を居間で読むような度胸が俺にあるわけないでしょう？

**名前は開発中のものです。** · 2013/09/29(日) 23:55:55.73

ﾜﾗﾀ

**名前は開発中のものです。** · 2013/09/30(月) 20:56:01.83

>>203
ゲームによる。アーケードなんかはチート不能だから瞬着の当たり判定とか普通にあるよ
参考になるかどうか分からないけど、ボーダーブレイクの主武器は発砲時にレティクルが
敵に重なってれば「当たり」。クライアント側(プレイヤーの筐体側)で判定してる
わかりやすい例かと

**名前は開発中のものです。** · 2013/10/01(火) 18:12:36.03

アクションのネトゲってのも１つの夢ではあるけど
逆に非同期で実現できる面白い仕掛けのゲームも考えてみたいもんだね

**名前は開発中のものです。** · 2013/10/01(火) 21:39:39.78

面白いフリーソフトレビュー＆攻略質問スレPart220
ID:l+J8o0sa
http://engawa.2ch.net/test/read.cgi/gameama/1374691097/141
http://engawa.2ch.net/test/read.cgi/gameama/1374691097/144
http://engawa.2ch.net/test/read.cgi/gameama/1374691097/146

**名前は開発中のものです。** · 2013/10/02(水) 10:08:22.51

報告乙です
素直に巣に帰ったようで。ありがたい

**名前は開発中のものです。** · 2013/10/02(水) 18:28:05.54

テンプレートメタプログラミングとかいう言葉を最近知ったんだけどさ
コンパイル時に外部リソースを実行ファイルに取り込むのって外部リソースのメリットを潰しちゃうかな？

具体的には、箱庭ゲーとかでのイベント発生時刻(タイムラインっていうの？)とか。

逆に、ユーザーにいじって欲しくないデータは隠せそうだけど、それはそれでプログラムに直書きした定数とどう違うのという疑問もある。

みんなconstexprとか使ってんの？

**名前は開発中のものです。** · 2013/10/02(水) 18:29:13.84

我ながら意味深な文章になってしまった

**名前は開発中のものです。** · 2013/10/02(水) 19:25:27.70

真ん中らへんがメタプロの要素なくて文章が繋がってなくて意味がわからんのだが、
それはコピペミスか何かで本当は

＞テンプレートメタプログラミングとかいう言葉を最近知ったんだけどさ
＞みんなconstexprとか使ってんの？

っていうレスだったのかな？

それなら別に、C++11になるって制約以外には付け得なキーワードだから
付けられるとこには付けとくといいんでないかな

**名前は開発中のものです。** · 2013/10/02(水) 20:18:22.46

もっぱら面倒臭いかどうかだけで判断してる。
バランス調整でコンパイルがメンドかったら外部ファイル化。
バイナリファイル解析する奴なんてそうザラにいないし、
いざとなれば暗号化すればいいし。

**名前は開発中のものです。** · 2013/10/02(水) 22:39:00.42

C++はネイティブコードを生成するからか
コンパイルが長杉

**名前は開発中のものです。** · 2013/10/03(木) 00:06:52.85

ビルドじゃなくてコンパイルが？
includeが深いとか翻訳単位が多くてコンパイルとリンクが多いと長い事はあるけど

**名前は開発中のものです。** · 2013/10/03(木) 01:34:00.02

TMPをゲーム製作で使うことってほとんどなくね

**名前は開発中のものです。** · 2013/10/03(木) 02:02:11.52

STLならよく使うが？

**名前は開発中のものです。** · 2013/10/03(木) 06:56:22.10

ビルドとコンパイルってどう違うんだ

ビルド∋コンパイルってことか？

**名前は開発中のものです。** · 2013/10/03(木) 07:33:06.73

コンパイル＝.objファイルの生成
リンク＝出来た.objから実行ファイルの生成
ビルド＝それらの総称
って事だろ？
今日日、一々使い分ける事もないだろ。メンドくせぇな(^p^)

**名前は開発中のものです。** · 2013/10/03(木) 07:44:02.31

>>234
個人レベルの開発規模なら、昨今ではわりと珍しい言い分だと思うかな

普及価格帯のPCの性能、SSDの普及率、こうした背景の中でPCHを使ってれば
設計が多少ゴチャってても、コードを一部修正した後のビルドは大抵一瞬で終わる

それでも遅いなら、ファイル(ソースやヘッダ)間の依存関係がスパゲッティ状態で
一部の修正が「不必要に」多数のファイルに影響を及ぼしてるとか、ビルド設定が
腐ってるとか、その辺に原因がありそう

**名前は開発中のものです。** · 2013/10/03(木) 08:36:21.26

複数プロセッサのコンパイルが有効になってないとか。

**名前は開発中のものです。** · 2013/10/03(木) 08:42:00.57

ビルドが速い言語の場合、ビルドから実行まで１秒もかからん
C++はまだ数秒かかるでしょ(Hello, Worldであっても）
多少は高性能な環境だと仮定しても一瞬は盛りすぎ
（そもそも開発環境は一般的な最新PCより劣る場合が多い）

**名前は開発中のものです。** · 2013/10/03(木) 08:56:12.82

バランス調整関係の定数を一つのヘッダファイルに纏めると
加速度的にコンパイル時間は長くなる。
逆に、そうならないように各ヘッダで宣言すると
今度は一目で見通せなくなるから面倒臭い。
定数名で検索かければいいじゃねーかと思っても、
定数名なんて覚えてない。
そもそも、バランス調整ごときでIDE立ち上げるのも面倒臭い。
何十回もリトライするケースもあるしね。

**名前は開発中のものです。** · 2013/10/03(木) 09:22:37.44

定数ならextern使えばいいんじゃね？

**名前は開発中のものです。** · 2013/10/03(木) 09:32:31.11

変数考えるのも面倒だしコンパイル時間かかるしで
よく使う変数をまとめた初期化込みGet関数込みのクラスを継承させて
よほど特殊,重要な値じゃないかぎりそこでやりくりしてる

余分な変数大量に宣言&どこのクラスかで同じ変数でも意味が変わって
他人が見てもよくわからんから設計上よろしくないと思うが
普通はいちいちヘッダわけていろんな変数つけんの？

変数格納クラスに変数追加しないかぎりコンパイル時間は気にならない

副作用で変数の節約と機能ごとのカプセル化がうまくなった気がする

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

>>239
"総称"じゃないよ。コンパイルとリンクのステップを順に実行して、最終アウトプットに組み上げるのが、言葉通りビルド。
総称って言っちゃうと語弊がある。

あと今日日分けないって意味だと、コンパイルじゃなくてビルドって言う。
当たり前の事なのでめんどくさい話じゃない。ちゃんと正確に理解しなさい。

**名前は開発中のものです。** · 2013/10/03(木) 20:24:47.60

>>242
・ビルドが速い言語
・ハロワのビルドに数秒かかるC++

これらについての具体的な言語処理系(の製品名)を挙げてくれるとありがたいです。
ハロワ数秒を叩き出すPC環境についても差し支えない範囲でお願いします
あとmakefileかプロジェクトファイル、コンパイルオプションもあると助かります

一応、一般的な最新PCより劣る環境として
CPU：Core i7-860(Lynnfield世代)
MEM：PC3-12800 2GBx2
HDD：1TB 7200rpm
VGA：GTX260(216SP) GDDR3 896MB 2-way
SND：SB X-Fi XtremeGamer
OS：Win7 Pro 64bit (現在はSP1)

4年前にバイトして買ったパーツがこんな感じで、今は押入れの中で
眠ってるんですが、寄せ集めて検証用に一台組んで試してみようかと

SSDNow V100 SV100S2/64Gという3000円程度のローエンドなSSDも
たまたまあるので、これも使ってみようかなと

**名前は開発中のものです。** · 2013/10/03(木) 22:00:56.49

>>247
安価見逃した上にハロワのビルドが速い言語と空目してしまったのでHQ9+と上げておくｗ

**名前は開発中のものです。** · 2013/10/03(木) 22:33:47.68

大体それ前後のPCで書いてるが、数秒かかるぞ？VC++2008。

**名前は開発中のものです。** · 2013/10/03(木) 23:13:17.00

ハロワ？無職なの？

**名前は開発中のものです。** · 2013/10/03(木) 23:42:09.30

数秒でハローワークを建設するスレですが何か？

**名前は開発中のものです。** · 2013/10/04(金) 00:23:20.56

どうせモジュールの概念もオブジェクト指向も理解せず、一つのファイルに
延々と全プログラムを書き出しているとかいうオチじゃね～の？
そりゃ重いよ。

**名前は開発中のものです。** · 2013/10/04(金) 00:26:55.32

ここゲームプログラミングスレじゃなくなってるよな
DXスレのがよっぽどゲーム的

**名前は開発中のものです。** · 2013/10/04(金) 00:55:47.13

オレオレライブラリのファイルサイズが200kbyteを超えてるとか、
そーゆーよっぽどな理由がない限りは、DXライブラリ使った方が
良いとは俺も思う

**名前は開発中のものです。** · 2013/10/04(金) 01:11:50.59

あとグローバル変数もローカル変数も一緒くたにしてねーか？
これやられっと処理速度がやたらと遅くなるんだが･･････

**名前は開発中のものです。** · 2013/10/04(金) 01:25:42.28

そういや、メンバー変数とローカル変数でも処理速度は変わるよな？

**名前は開発中のものです。** · 2013/10/04(金) 01:32:27.72

雑談？
チャット？

**名前は開発中のものです。** · 2013/10/04(金) 01:32:40.31

変わるだろうけど今日び気にするだけ無駄じゃね

**名前は開発中のものです。** · 2013/10/04(金) 02:03:50.60

速度を求めないなら何のためにC/C++を選んでいるんだ？C#の方がよっぽど楽だろうに･･････

**名前は開発中のものです。** · 2013/10/04(金) 02:13:07.11

>>247
i5に16GB積んでVC2012でハロワをビルドしても数秒かかるよ
I/Oの強化が効果的だけど、例えばFC接続したRAID5構成(HDD24台)でRHELのGCCでビルドしたって一瞬じゃ終わらん

やっぱ、Delphiが最強だな

**名前は開発中のものです。** · 2013/10/04(金) 02:29:42.32

メンバ変数とローカル変数の差も気になるくらい速度を求めてるならアセンブリでも書けば

**名前は開発中のものです。** · 2013/10/04(金) 02:33:31.45

下手糞なアセンブラよりもCのが速いんだが

**名前は開発中のものです。** · 2013/10/04(金) 02:34:54.05

じゃあCで速度を追求したらいいんじゃね

**名前は開発中のものです。** · 2013/10/04(金) 02:46:28.17

C++使うとメモリー管理が楽なんだ。
あと、オブジェクト指向にも向いてるし、モジュール設計も楽。

**名前は開発中のものです。** · 2013/10/04(金) 03:03:29.50

お休みして

**名前は開発中のものです。** · 2013/10/04(金) 03:05:51.85

しかもC++使うと変数間の速度差とか気にかけられるぞ
良かったな

**名前は開発中のものです。** · 2013/10/04(金) 03:31:25.01

コンパイル速度の話がズレてきたぞ
C++が圧倒的に遅いのは最強！　無敵！

**名前は開発中のものです。** · 2013/10/04(金) 05:40:39.74

メモリー管理できますって言った時に
別にスマートポインタ使える必要ないよな
アロケータも別に

**名前は開発中のものです。** · 2013/10/04(金) 08:53:12.46

>>268
スマポ普通に使うが、なんで名前を出した？
boost::shared_ptr も、都合によって自前も。「ひらがな書けます」くらいのレベルの話だ。

**名前は開発中のものです。** · 2013/10/04(金) 08:55:12.20

>>254
自前ライブラリとかlibにしとかないか普通。
それでも遅いって話ならいいけど

**名前は開発中のものです。** · 2013/10/04(金) 11:53:46.23

自分で解放しないとなんか不安だから、スマートポインタって使う気にならないんだけど、
構造が複雑になった場合、どのタイミングで解放されているのかよくわからなくなる
みたいなことってないの？

**名前は開発中のものです。** · 2013/10/04(金) 11:59:28.70

解放忘れがないならいつ解放されてもどうでもよくね？

**名前は開発中のものです。** · 2013/10/04(金) 12:06:41.37

解放忘れよりつかんでいるつもりがいなくなってる方が怖い
オーナー管理で罠にハマるとつらい

**名前は開発中のものです。** · 2013/10/04(金) 12:23:47.55

>>272
なんらかのインスタンスを参照している場合、
先にインスタンスを解放してしまったら、
参照している方で不具合が起こるじゃないか。

**名前は開発中のものです。** · 2013/10/04(金) 13:38:33.03

>>271
考え方的に逆。って言うかちょっと違う。
「いつ解放されるかわからない」って状況はスマポ使う使わない以前の自分が動作を認識してるかって話であって、
ライフサイクルは自分がわかった上で利用するんだよ。
つまりそのデストラクタはいつ呼ばれるかってのを自分がわかってて書いてるのが前提。
スマポはその上の保険と省力。

**名前は開発中のものです。** · 2013/10/04(金) 13:41:02.20

>>274
それはスマポに限らず設計の問題。
JavaやC#にあるGCと混同してないか？
全く別物で、スマポは単純だぞ

**名前は開発中のものです。** · 2013/10/04(金) 14:30:37.37

C++でもインクルードするファイルの数を少なくしたりすると早くはなるけど限界あるだろ
だからコンパイルの高速なスクリプト言語を組み合わせるんだ

**名前は開発中のものです。** · 2013/10/04(金) 15:16:13.30

そういうからboostのPythonいれたら、コンパイルがかなり長くなったんだが

**名前は開発中のものです。** · 2013/10/04(金) 15:17:40.69

スマポってdeleteみたいなことは原則行うの？
たまたま解放忘れてても拾ってくれる保険なら労力増やしてまでやる必要が感じられない
原則delete行わずデストラクタで自動解放が主流なら今すぐ書き換えてくる

**名前は開発中のものです。** · 2013/10/04(金) 15:31:33.71

>>279
原則っていうかザックリ言うと、スコープから外れたときにdeleteを自動でやってくれる。

func(){

}

**名前は開発中のものです。** · 2013/10/04(金) 15:38:32.32

>>280 ごめん途中で送信してしまった
func(){
smart_ptr<foo> bar(new foo);
なんかごにょごにょ
} <- barだけしか使ってないならここで解放

これが基本だが、スマポ同士で代入ができるやつは関数の戻り値に渡したりするとスコープを超えられるのもある。
なので、いろいろな場所で使っていても、結果的にすべて共有しなくなった時にdeleteしてくれたりする。

**名前は開発中のものです。** · 2013/10/04(金) 15:57:27.76

なるほど、スコープはずれたら&他に参照とかなかったらデストラクタが起動してデリートするのか
ちょっと勉強と動作チェックしてくる

**名前は開発中のものです。** · 2013/10/04(金) 16:17:23.72

>>281
マジかよ
スマポってそんな凄いやつだったのか！
でもそもそもnewとかdeleteしないプログラムしか書いたこと無いから意味無いような気がする・・・

**名前は開発中のものです。** · 2013/10/04(金) 16:23:01.59

>>280 >>282
なんか気になったので補足しておくと、

> デストラクタが起動してデリートするのか

delete された時、解放時の処理の為にデストラクタが呼ばれるんだぞ？
意味わかってるのか不安になった。

**名前は開発中のものです。** · 2013/10/04(金) 16:23:58.50

>>279 と >>282 。安価みす

**名前は開発中のものです。** · 2013/10/04(金) 16:31:39.55

ああちゃんとレス読んでなかった。
スマポクラス側のデストラクタが呼ばれたら、スマポクラスが保持しているポインタをdeleteするって意味ならその通り。
ただそれだけの仕掛け。

>>284-285 はスルーで。てかクラスの入れ子関係で、デストラクタの中で、
子要素のデストラクタ呼ぶような処理普段書いてたら簡単にわかる話だ。

boost::shared_ptr はそれプラス、コピコンやコピーオペレータを持ってるだけ。だから単純な仕掛け。

**ID:17B7kATN** · 2013/10/04(金) 16:41:09.39

>>280
それは単純な例だけど、
構造が複雑になった場合、例えば複数のヒープ変数が必要で、一方が他方を参照している場合とか、
＞どのタイミングで解放されているのかよくわからなくなる
ってならない？

>>281
これまさに
＞どのタイミングで解放されているのかよくわからなくなる
ってならない？

**名前は開発中のものです。** · 2013/10/04(金) 16:42:12.87

単純な仕掛けだけど、これ考えたやつ頭いいよな。

解放忘れがないか、二重デリートがないか、インスタンスが生きているか、適切なライフサイクルか、、、、
などと複雑になりやすいコードに神経を使うよりも、
スマポを持ってたら生きているのが保障されるからコードが見やすくバグも少なくなるし。

たとえば、ＳＴＧなんかで親子関係を持った敵がいたとして
親が破壊されたとき、子は生きていて親を参照している場合、
スマポなら親を生存リストから外すだけでおｋで、子が全滅した時点で勝手にdeleteされるなーんて。

生ポならずっと子が生きているか監視しなければならないし。
この部分のコードが減るだけでバグが少なくなるよね。

ほんとスマートだわ。

**名前は開発中のものです。** · 2013/10/04(金) 16:48:05.11

>>287
基本的にどのタイミングで解放されてもいいんだよ。むしろ気にするような組み方はよろしくない。
アクセスしたときに必ず生存していることが重要。
循環参照には気を付けないといけないけど。

**名前は開発中のものです。** · 2013/10/04(金) 16:53:36.47

＞基本的にどのタイミングで解放されてもいいんだよ。むしろ気にするような組み方はよろしくない。
メモリをケチろうとして重複を無くそうとすると、
参照関係が複雑にならないか？

**名前は開発中のものです。** · 2013/10/04(金) 17:00:08.29

>>290
そんなギチギチの環境で組んでるの？
たぶん、そんな複雑な参照してる場合は設計を一度見直したほうがいい場合があるよ。

**名前は開発中のものです。** · 2013/10/04(金) 17:53:17.80

循環参照になるような時は弱参照

**名前は開発中のものです。** · 2013/10/04(金) 19:27:18.60

>>277
実行中に書き換えられるようにすると凄く便利らしいね、ああいうの

**名前は開発中のものです。** · 2013/10/04(金) 19:32:50.22

コンストラクタでエラーを出す方法は例外だけ。
例外使う場合、正しく確実にファイナライズ処理を実行する方法は事実上スマポだけ。
なので細かい事を言えば、スマポを一切使わない場合、例外禁止＆2段階初期化必須＆コンストラクタ内では代入くらいしかしてはいけない、みたいな設計上の制約も出てくる。
スマポは超便利ってのもあるけど、こういうC++の暗黒面を補う事情もあったりする。

**名前は開発中のものです。** · 2013/10/04(金) 20:21:48.75

関連記事として…
More C++ Idioms
http://ja.wikibooks.org/wiki/More_C%2B%2B_Idioms

**名前は開発中のものです。** · 2013/10/04(金) 21:39:25.40

今ネット通信ゲーム作ってるんだけど
SOCKETの変数をいろんなところでメッチャ使うんだけど
これを引数で持ってきてたんだけど、グローバル変数にしてやった方が圧倒的に楽だよな
でもグローバル変数って使わないべきだし、シングルトンも同じだから使わないべきなんだけど
こういうときってどうすりゃいいの

**名前は開発中のものです。** · 2013/10/04(金) 21:46:22.36

グローバル変数を使うなというのは全体構造を分かり難くするから
使わない方が無難というだけ
必要があるなら遠慮なく使えばいい

**名前は開発中のものです。** · 2013/10/04(金) 21:49:17.96

>>297
ありがとうございます

**名前は開発中のものです。** · 2013/10/04(金) 21:59:15.94

そもそもnamespaceとかexternってグローバル変数を活用するための機能だからな

**名前は開発中のものです。** · 2013/10/05(土) 06:58:26.67

>>288
子の参照を持ってるのは親だけなのでは

**名前は開発中のものです。** · 2013/10/05(土) 08:55:09.52

>>296
グローバル変数を使うなと言われる理由はいくつかあるけど、その一つに変数は関数より柔軟性が低いってのがある。
メンバ変数をプライベートにしてsetter/getterを作れっていうのと事情は大体同じ。

例えば、4人対戦ゲーの場合、プレイヤーIDを表す変数は0～3までの値しかとって欲しくないとする。
変数に直接代入する場合、いざ使う時になってIDが正しいかチェックする必要があって、プレイヤーIDが0～3になっているかチェックするコードが全体にばらまかれる。
関数経由で代入する場合、引数の値をチェックしてエラーを投げることができるので、値の範囲をチェックするコードは最初のsetterだけで済む。

変数は代入しか出来ないけど、関数は付随する処理（引数チェック、ログの記録）が出来るし、仕様の変更にもある程度柔軟に対応できる。
（プレイヤー人数を6人に増やしたいと思ったときに修正しなければならい箇所の違いを考えると…）

理想的には、Socket自体は通信関係のコード以外に触れられないようにして、

SendAttack(OBJECT_ID target);
SendMove(OBJECT_ID id, Position pos);
SendChat(PLAYER_GROUP_ID groupId, const char* msg);

みたなゲームの仕様に合わせたパケット送受信関数を作って、それをゲームロジック全体で使う。

この手の送受信関数を纏めたクラスのオブジェクトが、シングルトンやグローバル変数になるのは仕方ないんだけど、
Socketが丸出しのグローバル変数ってのはあんまりよくはないな。

まぁ小規模なゲームを一人で書いてる内は、そこまで致命的でもなかったりするが。
まだ仕様がハッキリと見えてない段階でプロトタイプを書いてるときは、何も考えずグローバル変数の方が手早い事も多いし。
長文でスマン。

**名前は開発中のものです。** · 2013/10/05(土) 09:16:22.33

どっちかって言うと実際に使った時直面する問題って、グローバルに複数置いてる物があって、それらが相互に関わってるような時、
開放順が保証されないからデストラクタで何か処理するような場合困るかもしれないって事と、

namespaceも分けて無いグローバル変数でかつexternだらけとかになると迷子になる上、別の翻訳単位にもしも同名があった時面倒な事になる、ってのが

大昔に経験したリアルな問題

**名前は開発中のものです。** · 2013/10/05(土) 09:18:23.46

ちなみに、「翻訳単位内でのローカルな範囲で良いグローバル変数」には、
普通 static キーワード付けて、externさせないってのが常套手段だよな。

**名前は開発中のものです。** · 2013/10/05(土) 09:31:57.77

static = private
extern = public

**名前は開発中のものです。** · 2013/10/05(土) 12:18:22.70

>>300
そうは限らないよ。
親から一定間隔離れて行動したり、親の状況で振る舞いを変えることがあるから。
どちらの場合もある。

**名前は開発中のものです。** · 2013/10/05(土) 12:29:05.40

extern Kelsi Olesya_Rulin;
そう、グローバルを遠慮する必要なんてない、ってのは合意事項だよな

**名前は開発中のものです。** · 2013/10/05(土) 13:13:45.24

あれ、コンパイル通らなかったか。
そうか参照が抜けてたか。
http://images2.fanpop.com/image/photos/9400000/kelsi-high-school-musical-9487566-333-500.jpg
http://img.photobucket.com/albums/v515/bloodylamer/bastardly-photos/0505/album102/olesya-rulin-09040702.jpg
これでどうだ。

**名前は開発中のものです。** · 2013/10/05(土) 15:33:55.63

>>305
親から全ての子に指示するべきじゃない？
子供が親の参照はよくないと思う

**名前は開発中のものです。** · 2013/10/05(土) 16:02:12.04

>>308
Ogre3Dは親子それぞれ参照をもってるんだがな

**名前は開発中のものです。** · 2013/10/05(土) 16:25:59.47

>>308
それも場合によると思うなぁ。親を辿りたい時があるし、
親が子に干渉しすぎるのはちょっと、という考え方もあるだろうし。

**名前は開発中のものです。** · 2013/10/05(土) 17:01:45.43

親子の捉え方が違うとなんともいえんような

例えばシューティングでの位置関係なら
親の移動が子全体に影響するなら、親が子の参照を持っているのが便利だよな
これはシーングラフみたいなやつか、スプライトとかはコッチだろうな

逆に子が親の行動をトレースするタイプだと参照の持ち方は逆になる
こっちはカメラのスナップかな、親が持つんじゃなくて、子が勝手にぶらさがる

**名前は開発中のものです。** · 2013/10/05(土) 18:02:50.50

親ノードは子ノードの配列を持ち
子ノードは親ノードの弱参照を持つという形にしている

**名前は開発中のものです。** · 2013/10/06(日) 12:59:02.01

親子関係といっても様々な層にあるからねぇ
例えばゲーム設定上の関係性(物理、組織、通信回線、人間模様、etc)は色々だし
これらの関係性も、実装上は、制御(操作)の流れ、データの流れ、色々だし

話の前提条件が何かを伏せてる限り、問題の所在も実装の最適解も本人にしかわからん
説明が面倒なら、頑張れとしか言えん

**名前は開発中のものです。** · 2013/10/06(日) 19:46:28.52

アクションなんかで敵キャラクターの種類によって戦闘ロジックを変える場合って、種類ごとに継承するのが普通?
それとも、戦闘ロジックの部分だけ無名関数で差し替えるとか?

**名前は開発中のものです。** · 2013/10/06(日) 19:56:21.47

戦闘ロジックには関数ポインタを使った事と、スクリプト言語を使った事がある
処理速度では前者、汎用性では後者だな

**名前は開発中のものです。** · 2013/10/06(日) 22:48:36.24

>>314
前者が、敵1体を1単位とするような粗い粒度の処理の差し替えの話で
後者が、無名関数でもおｋな程度に細かな粒度の処理の差し替えの話なら

場合に応じてそうした実装の使い分けをするというのは普通にアリなのでは

**名前は開発中のものです。** · 2013/10/07(月) 00:06:33.12

分解能について教えて欲しいんだけど
timeBeginPeriodとtimeEndPeriodはプログラム全体で同じ分解能なら開始時と終了時に1回呼ぶだけで合ってる？
それともタイムを使うごとに毎回呼ばないといけない？

**名前は開発中のものです。** · 2013/10/07(月) 00:19:23.88

毎回呼ぶのは無駄ぽいんだが
1回だけだと他のプロセスで精度を悪いほうに変えられたら駄目だろうな

**名前は開発中のものです。** · 2013/10/07(月) 00:33:00.85

>>318
ありがとうございます
そうか他のプロセスで弄られる可能性が有るから毎回呼ぶほうがいいのか・・・
1回呼べば固定されるはずなのにサンプルコードで何で毎回呼ぶのかわからなかったけどようやくわかった

**名前は開発中のものです。** · 2013/10/07(月) 10:34:56.91

>>317
一回でいい。
ただtimeBeginPeriodとかはOS共有だから
他のアプリで操作されたらどうしようもない。