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

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

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

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

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

**名前は開発中のものです。** · 2014/04/29(火) 17:12:12.68

ビギナーコラムでオブジェクト指向の哲学とか語られてもな
とりあえず作ってみよう系のほうが理解しやすい
ここを弄ったらこう変わるみたいな

**名前は開発中のものです。** · 2014/04/29(火) 17:21:14.92

c++だけがoopじゃないっすから…

**名前は開発中のものです。** · 2014/04/29(火) 17:40:38.04

>>628
だいぶ使いこなせるようになっても読めない初心者向けの本とかあるから性質が悪い
ゲーム用だけじゃないが初心者の頃はコードがのっててサンプルが作りたい物に近いから買ってみるけど…
Cマガも半分ぐらいしか理解できなかったがいま読み返すと消えてる技術も多くて笑える

**名前は開発中のものです。** · 2014/04/29(火) 17:48:57.10

ゲーム系の学生なんだけど、ゲーム会社ってどのくらいのレベルのオブジェクト指向まで要求されるの？
あと、AIとかそういうアルゴリズムも重視される？

**名前は開発中のものです。** · 2014/04/29(火) 18:14:47.39

>>632
ぶっちゃけ会社によって様々だからうちの会社で書くけど
新卒には特別な期待はしない
とりあえず、プログラムを作れれば良いや、ゲームまで作れたら儲け物って感じだな
後はただ、人間として基本的なことはできてればそれだけで良い
俺は現場だからこういうのを求めてるけど、人事は即戦力のゲームプログラマーとしてプログラムを作れないやつを入れてくるから何を見てるか同じ会社なのにわからん
とりあえず残業させてないのに毎年1ヶ月以内に1人、3ヶ月以内に半分になる新卒はゲーム作る気がないよね

**名前は開発中のものです。** · 2014/04/29(火) 18:23:27.78

マ板でやれ。な

**名前は開発中のものです。** · 2014/04/29(火) 18:25:53.36

>>621
スーパープログラマさんかな？ｗ
他の配信者も有名な人だよって言ってたし、多分在京で働いてる業界人なら知ってる人ですよ。

ちなみに、よくプログラマになるにはどうしたらいい？という初見リスナーのレスあるけど
「C++とDirectX(ライブラリ自作)で『完成した』作品を持ってこい」と言ってますね。
本人もデザインパターンを配信中にググって知ったみたいだし
オブジェクト指向とか関係ないんじゃないかと。とにかく完成品をよこせと。

**名前は開発中のものです。** · 2014/04/29(火) 18:34:29.77

Q 漫画家になるにはどうしたらいいですが？
A 漫画を描けば漫画家です
　プロになりたければ作った作品を持ち込んでください

Q ゲームプログラマになるにはどうしたらいいですか？
A ゲームを作ればゲームプログラマです
　プロになりたければ作品を持ち込んでください

**名前は開発中のものです。** · 2014/04/29(火) 18:38:17.18

>>636
これ
でも、自分じゃなくて友人が作ったやつを持ち込むクソも居る

**名前は開発中のものです。** · 2014/04/29(火) 19:08:58.63

スレ違いの話題振る質問者は不採用です

**名前は開発中のものです。** · 2014/04/29(火) 19:14:20.55

くだらないループ話を延々続けてる馬鹿に飽きていたからいい暇つぶしになったw

**名前は開発中のものです。** · 2014/04/29(火) 20:34:32.58

>>609
＞制御構文使ってたら死ぬ時に使う物
>>615
＞実際switchの方がよく使われるものなの？
>>619
＞シーン遷移の実装はシーン側は知る必要ないから、
＞その時の気分とかシーンの数とかで好きにやりゃいいと思うけどね。
＞
＞Task的に入り組んだ作りしてないのなら、どれでもすぐ遷移図を思い描けるっしょ。

同意です。実装の選択肢は色々あり、個々の状況に応じて選べば良い事かと。
>>602-603の例で言えば、振る舞い的に拡張する予定がなく、実際しなかった
部分なので別に問題なかったですね

元々HSP上がりの人間(周りも同様)だったので手続き型の記述のほうが平易
というのもありました

>>617

State Pattern
switch-case構文

**名前は開発中のものです。** · 2014/04/29(火) 20:35:52.86

>>640訂正
末尾の三行は消し忘れです。>>617さんごめんなさい

**名前は開発中のものです。** · 2014/04/29(火) 20:52:06.90

>>635
何年か前に、画像表示、パッド入力、音声出力くらいまでは何とか作ったけど
途中で面倒くさくなって、結局DXライブラリに戻ってしまったという残念な経験しかないやｗ

**名前は開発中のものです。** · 2014/04/29(火) 20:55:41.83

>>619
会社帰りにたまにボー●ーブ●イクでチャリンチャリンしてたんですが
転勤先にそれ置いてるゲーセンがなくて悲しみのあまり余暇にパチモン
作りで自分を慰めてるんですが、火器とかAIの部分はStateというかStrategy
というかそんな感じのコードはありますね。条件分岐でダラダラ書いてたら
流石に眩暈がしてきたので

**名前は開発中のものです。** · 2014/04/30(水) 00:47:22.57

何を言いたいのかサッパリ分からん

**名前は開発中のものです。** · 2014/04/30(水) 01:21:27.75

>>643
パーツとか持ち替えの武器とか大量にあると面倒くさいことになるよね
あの手のアセンゲーっぽいのは俺も好きだが作りたいとは思わないな

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

つまらない流れなので誰かネタ振りお願いします><

**名前は開発中のものです。** · 2014/04/30(水) 10:28:13.43

初心者な質問ですみません。
クラスからクラスを呼ぶときってどういう書き方が普通なんですかね？

class A {
public :
static A* me ;
int a ;
A() ;
}
A* A::me ;

A::A() {
me = this ;
}

ってやって A::me->a とかやってるけど、なんかスマートじゃなくて……。

**名前は開発中のものです。** · 2014/04/30(水) 11:46:43.01

なにがしたいのかさっぱりわからんけど、それmeにインスタンス入れてるだけであんまり意味なくない？
クラスからメソッド直接使いたいとかなら、メソッドをstaticで定義してクラス名::メソッド名()だけど

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

グローバル変数みたいなことがしたいのかな
アクセス可能なオブジェクトを限定するのがオブジェクト指向の組み方だから
アクセスする必要があるクラスにポインタなり参照なり持たせたほうが良いんじゃない

**名前は開発中のものです。** · 2014/04/30(水) 12:58:15.72

日本語不自由で変な質問するやつはほっといたほうがいいよ

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

staticメンバの初期化の仕方の話でねーのん。
最近c++触ってないから間違ってたらすまんけど。

// A.h
class A {
public:
　　static int a;
}

// A.cpp
int A::a = 10; // 初期化

// main.cpp
void main() {
　　A::a;　　　　// 利用
}

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

3Dゲームで経路探索をやってみようと思うんだけど、3Dの位置情報ってどうやって調べればいいの？

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

具体的には？

基本的に平面で移動するゲームなら2Dと大して変わらんしだろうし
キューブ状の座標（2Dで言うところのマス目）を移動するだけなら、移動方向に上下という選択肢が増えただけと考えられるし
ビルの中を探索するようなゲームなら、階段やエレベータでエリアを区切ればいい気がする。

**名前は開発中のものです。** · 2014/04/30(水) 14:32:28.53

何が聞きたいのかさっぱりわからんけど、普通に変数参照すればいいんじゃない？
複雑な地形での経路探索がわからんって話なら、地形の要点にポイント作ってダイクストラ法でいいんじゃないの

**名前は開発中のものです。** · 2014/04/30(水) 14:35:02.75

ごめんダイクストラ法じゃなくてA*か

**名前は開発中のものです。** · 2014/04/30(水) 14:50:11.17

経路探索
http://samples.jbpub.com/9781556220784/Buckland_AIExecutables.zip

Chapter 5　にあるように経路探索する。
Chapter 8\Raven_CoarseGraph　のようにグラフとして探索する。

**名前は開発中のものです。** · 2014/04/30(水) 16:08:24.08

>>655
A*はダイクストラの拡張版で、基本アルゴリズムは重複する部分が大きいから、
大筋外してはいないよ
ゲーム用途の経路探索性能は、A*の方がより最適化されるみたいだけど

**名前は開発中のものです。** · 2014/04/30(水) 16:47:29.58

>>647
http://ideone.com/gt21RS
そのコードが何か不明だがこういう振る舞いをするという事がわかってれば好きにしろ

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

647です。皆さん色々すみません。
やりたかったのは、例えばコンフィグデータを一括管理するクラスを作って
他のクラスでそれを使う、ような事です。
例として挙げたソースは簡単に書いただけで直接書き換えたいというわけではありませんでした。

関係ない愚痴ですが、こうやれば動くからこれでいいのかな、と作り進めてても
やっぱりおかしいよな、とまた一から作り直す、を繰り返してて制作が全く進みません……。

**名前は開発中のものです。** · 2014/05/01(木) 03:51:25.76

http://anago.2ch.net/test/read.cgi/ghard/1387003319/235
　　↑　↑　　　↑　↑　　　↑　↑

**名前は開発中のものです。** · 2014/05/01(木) 05:10:34.61

唯一のインスタンスを保証するシングルトンではなく、
インスタンスは複数作れるけど、実体は同じものを作っている……っていうアルゴリズムあったよね。

>659の場合だと、その方法使えそうな気がするものの……名前が分からんので教えられん

**名前は開発中のものです。** · 2014/05/01(木) 08:21:56.84

>>659
そんなのグローバル変数でいいだろ
つまんないとこで止まってないで先進めよ

**名前は開発中のものです。** · 2014/05/01(木) 09:19:18.98

インクルードガードとexternでおk

**名前は開発中のものです。** · 2014/05/01(木) 11:26:20.56

http://ja.wikipedia.org/wiki/%E3%83%80%E3%82%A4%E3%82%AF%E3%82%B9%E3%83%88%E3%83%A9%E6%B3%95
これをプログラムに直すとどうなるの？
大学数学はさっぱり分からないから誰か教えて

**名前は開発中のものです。** · 2014/05/01(木) 12:30:19.75

>>664
ダイクストラ法は大学数学関係ないぞ
Game Coding Gemsの1か2に解説とソースコードがある

**名前は開発中のものです。** · 2014/05/01(木) 12:35:48.55

>>664
図のアニメーションと解説を読めば分かると思うが…
難解な数学計算無し。少なくとも高校数学の域は逸脱してない。
記号の意味分からない子向けに手続きを文章で丁寧に解説してる。
下手すりゃ厨房でも「コンピュータってバカ正直な事なんだね…」
と感想を述べながら呆れ顔をしてくるレベル

**名前は開発中のものです。** · 2014/05/01(木) 12:37:56.10

×「コンピュータってバカ正直な事なんだね…」
○「コンピュータってバカ正直な事をやるんだね…」

**名前は開発中のものです。** · 2014/05/01(木) 13:21:29.38

>>662-663
同意

**名前は開発中のものです。** · 2014/05/01(木) 13:56:28.60

「馬鹿正直」って感想はさ、たぶんコンピュータへの理解の第一歩だよね？

**名前は開発中のものです。** · 2014/05/01(木) 14:18:18.47

そうなんじゃない？学園祭でマイクロマウスの実演と解説をしてた時の消防や
厨房の反応は楽しかったよ。「かあいい」「頭悪過ぎうー」「きゃはは」
「がんばれー」とかが大半だったけど、眼鏡っ子の厨房が模造紙の解説を
一所懸命に読んでて、繰り出す質問がなかなか賢すぎてこっちが呆れた

**名前は開発中のものです。** · 2014/05/01(木) 14:26:30.17

メンバ変数が全部staticのパターンの名前が思い出せない
モノトーンだかそんなような名前だった覚えがあるけど

**名前は開発中のものです。** · 2014/05/01(木) 14:27:47.22

monostateじゃね
使ったことないが

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

シングルトンモノステート

**名前は開発中のものです。** · 2014/05/02(金) 00:13:50.98

皆さんは描画リストに登録して、Zソートやらしてからとめて描画などしてますか？
2Dで同じようなことを考えてるのですが、描画管理クラスにリストを持たせ、
その管理クラスのメソッドを通してリストへ登録しようとしてます
XNAのSpriteBatchの形が近いです

しかしこの方法だと管理クラスを引数でどんどん渡していかなければいけなく、良い方法がないか探してます
2Dオブジェクトにstaticで管理クラス、または描画リストを持たせた方がいいのでしょうか

設計の話なので明確な答えがないのはわかってます
皆さんの考えを参考程度に聞きたいです

**名前は開発中のものです。** · 2014/05/02(金) 00:48:59.22

スプライト的な「2Dオブジェクト」を作って、
そこにパラメータ与えて、あとは自動的に描画されるような組み方してるん？

**名前は開発中のものです。** · 2014/05/02(金) 01:19:41.25

>>674
＞しかしこの方法だと管理クラスを引数でどんどん渡していかなければいけなく、良い方法がないか探してます

依存性があるなら明示する(例えばSetterやコンストラクタで注入するだとか)
というのはOO的には無難なお作法だと思うけど。なんか不都合あるの？
(いちいち記述するのがかったるい、だとか)

まぁ、あまりに広範に渡ってその依存性が確認されるなら、グローバルな
存在、グローバルなサービス、として提供してもいいのでは。尤も、描画
モジュールに依存するモジュールってゲームの中では限定的だと思うけどね

**名前は開発中のものです。** · 2014/05/02(金) 01:31:13.85

表示するもの {
private IDrawable model;
private Vector2 pos;
private 表示するもの[] children;
public void Draw(描画管理クラス){
描画管理クラス.add(model,pos);
for child in child {
child.draw(管理クラス);
}
}
}

**名前は開発中のものです。** · 2014/05/02(金) 06:36:13.80

ダイクストラ法ってゴールをコロコロ変える(プレイヤーを追いかける)ことって出来る？

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

たとえば屋内を探索するゲームの場合、
ある部屋から別のある部屋へ行く方法ってのは基本的に固定なので、最初に各パターンを計算しておけばいい。

上手く追いかけるように動かしたいってことなら、
有名なところで、パックマンの敵アルゴリズムの話がシンプルでわかりやすいと思う。

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

自キャラの範囲と、敵の範囲と、とりあえず目指すポイント
みたいな表を作っておけば良いのか

**名前は開発中のものです。** · 2014/05/02(金) 09:29:13.26

>>675
2Dオブジェクトは座標、テクスチャを持ち、描画関数内で管理クラスのリストへ登録
という流れを考えてますので、自動的な描画はしません

>>676
やはりプログラムの最初にsetterで登録が一番無難ですよね
不都合はないのですが、2Dオブジェクト全てが
管理クラスのsetterを持つのが気持ち悪く思えてしまい・・・

描画モジュールに依存するものが限定的とは...ゲーム内では殆どのものが
描画されるものだと思ってましたが違うのでしょうか
オブジェクトを管理したりするものは別だと思いますが・・・

>>677
これは結局引数でどんどん渡していくのでは・・・？

**名前は開発中のものです。** · 2014/05/02(金) 09:52:01.66

>>681
引数で渡していっていいと思う
常に同じ描画管理クラス使うとは限らないし

**名前は開発中のものです。** · 2014/05/02(金) 13:12:16.23

>>681
何故「気持ち悪い」のか言葉で説明できるようにしてみれば
どうすればいいのかわかるんじゃない？

**名前は開発中のものです。** · 2014/05/02(金) 13:23:32.11

リストへの登録を描画関数と分ければ？
登録するデータを戻り値にして呼び出し側で登録するとか

**名前は開発中のものです。** · 2014/05/02(金) 19:21:58.74

>>682
レンダーターゲットを変えた時などでしょうか

>>683
2Dオブジェクトは例えばスコアや、メニューなどに使用するのに
管理クラスのsetterを常に持ち続けてるから・・・？

>>684
list.add(pObj->draw()); という感じですか？
この場合複数のオブジェクトを描画する時はどうなるんでしょう
スコアクラスは1桁描画を複数回呼ぶと思います
そういう時は戻り値でデータを返せないのでは

結局引数で渡してリストへ登録
または2DObject自身がリストを保持し、そこへ各派生クラスが登録する
という形になってしまうのでしょうか

**名前は開発中のものです。** · 2014/05/02(金) 20:24:35.53

ゲームで2つのプレイヤーの画面を並べる時ってどうしてる？
プレイヤーの状態とかエフェクトとかシングルトンで管理していて今まではどこかのクラスから
Game::instance()->registerEffect(new Effect())
みたいにできたんだけどプレイヤーごとにGameを作るようにしたらこれができなくなって
ゲームのインスタンスをあちこちに渡さなきゃならなくなったんだけどこんなことしないでもできる方法ない？

**名前は開発中のものです。** · 2014/05/02(金) 20:30:31.53

話の流れがよくわからないんだけど、

renderer.add(PlayerObject);　　//プレイヤーキャラクターのオブジェクトを登録
renderer.add(EnemyObject);　　//敵キャラクターのオブジェクトを登録

…みたいなのとは全く別の話？

**名前は開発中のものです。** · 2014/05/02(金) 20:32:36.22

>>686
Gameクラスってなんじゃらほい？
いわゆるシーンとかシーケンスってやつ？

**名前は開発中のものです。** · 2014/05/02(金) 20:37:30.44

>686
シングルトンが用を足さない状態だからやめるのが手っ取り早いけど
とりあえずシングルトンインスタンスの取得にID等の引数もたせれば?
引数違いなら違うオブジェクトを返すてのは実装は容易でしょ

こういうどこでも使えるグローバル変数的な状況で使うシングルトンは嫌いだけどな

**名前は開発中のものです。** · 2014/05/02(金) 20:42:33.50

>>685
レンダリングターゲットを変えたときもあるかもしれないけど、
マルチスレッドで分割してトラバースするこもとあるし。
Direct3D11でコンテキストを複数作れるようになったしね

**名前は開発中のものです。** · 2014/05/02(金) 20:45:40.07

>>685
戻り値をVectorかなんかにしたら

>>686
instance()に引数渡して特定のインスタンス取得出来るようにする
これまでシングルトンだったのが複数必要になった時点で設計見直した方がいいような気もするけど

**名前は開発中のものです。** · 2014/05/02(金) 20:54:53.01

情報不足すぎたうえに色々酷いごめんよ
Effectは別で管理している
シングルトンをやめるからどうするのが良いのかと思って聞いたんだ
ダブルディスパッチで敵の当たった処理とかしているんだけど
class Game {
　Enemy enemy[];
}
class Enemy {
　void hit() {
　　if( 死んだ ) { Effect::addEffect(new Effect()); }
　}
}
みたいにしててどのエフェクトを使うかはEnemy側で決めるようにしたいからこうなったんだけど
GameにEffectのインスタンス持たせてEnemyにそのインスタンスの参照なりなんなり渡して
if( 死んだ ) { effect->addEffect(new Effect()); }
とかしても良いんだけどなんかしっくりこないんで気になったのよ
>>688
そうなんだけど実際あんまり関係なかった・・・

>>689
うまい設計思いつかなかったんよね
その方法手っ取り早いし良さそうです

**名前は開発中のものです。** · 2014/05/02(金) 21:46:30.08

>>692
EnemyはどうしたってEffectへのポインタが欲しいわけで描画の関係からか複数存在してるとなると
初期化などでずっと持たせるのが嫌ならhitかそれ以上に位置するGameから呼ぶ関数に引数として渡すか
EnemyはGameクラスのポインタ位持ってるならGameのほうにAddEffect関数もたせてEnemyはそれを呼ぶか

スレッドセーフでない設計ならEffectポインタのグローバルか静的関数なGetterとSetter用意して
GameオブジェクトごとにEnemy更新前にSetterでGetterの戻り値となるポインタを入れ替え…止めた方がいいな

**名前は開発中のものです。** · 2014/05/02(金) 22:17:39.20

実際のコードでは、Effectクラスから派生した HitEffect とか DeadEffect とかを
Enemy内から呼んでるんだよね？

**名前は開発中のものです。** · 2014/05/02(金) 22:41:54.83

GameがEnemyを管理するんだったらEnemyに
エフェクト番号とフラグを持たせれば良いんじゃない

**名前は開発中のものです。** · 2014/05/03(土) 02:03:51.33

>>687
そんな感じです
ですがそのrendererを渡そうか悩んでます
引数ですとかなり深い(？)ところまで渡す必要があるのではないかという感じです

>>690
引数で渡した方が自由が利きますね
めんどくささと柔軟性のどっちをとるかみたいな感じでしょうか

>>691
座標、テクスチャ、UV、色などのことを考えるとVectorかなんかだときつそうです

とりあえず引数で渡す方向で作ってみたいと思います
オブジェクト指向難しいです...

**名前は開発中のものです。** · 2014/05/03(土) 06:24:50.92

ああ、文章にミスが
>>696
rendererを渡そうか×
rendererをどう渡そうか○
です

**名前は開発中のものです。** · 2014/05/03(土) 14:23:28.87

ヒープ領域のオブジェクトを参照で引数で渡したい時ってどういう風に書けばいいの？

**名前は開発中のものです。** · 2014/05/03(土) 16:01:04.13

普通に参照渡しするだけだよ

**名前は開発中のものです。** · 2014/05/03(土) 18:27:55.89

void f(A &a);

A *a = new A();

f(*a);

こんな感じゃない

参照って殆ど使った事ないからあってるかどうかわからんけど

**名前は開発中のものです。** · 2014/05/03(土) 19:07:15.30

「ゲームプログラマになる前に覚えておきたい技術」
という本がオススメと言われたんですが、これ持ってる人いませんか？
役に立つ度合いとかアドバイスしてもらえたら嬉しいです

**名前は開発中のものです。** · 2014/05/03(土) 19:31:10.25

ゲームプログラマになる前に覚えておきたい技術
01 この本はどんな本か
http://www.shuwasystem.co.jp/gpro-sp/

これを読みましたか？

**名前は開発中のものです。** · 2014/05/03(土) 20:46:14.95

>>693
やっぱりそれぞれが持つしかありませんかねえ
呼び出し元をparentとかして持たせておくのって普通にやっていることなんですか？
この場合だとEnemy::parentにGameへの参照か何かを持たせるとか

>>694
はいそうです

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

重いので持ち運びには向かない、かな

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

>>703
各クラスがどのエフェクトを使うのか？というのをハッキリさせておいて
必要なものだけインクルードするようにすれば、そこまで気持ち悪いことにはならないんじゃないだろうか。
たとえばEnemyクラスは、Effect::GettingItem（アイテム獲得）とかEffect::PlayerDead（プレイヤー死亡）は不要だろう。

それすら気持ち悪いと思うなら（分からんでもない）、
ObserverとかListenerとかCallbackとかその辺に頼るとかでも良いんじゃない？

**名前は開発中のものです。** · 2014/05/03(土) 22:35:18.25

>>700
参照引数は「読むだけ」を意図してる場合が多いからconst付きが多いかな

>>703
＞呼び出し元をparentとかして持たせておくのって普通にやっていることなんですか？
＞この場合だとEnemy::parentにGameへの参照か何かを持たせるとか

その疑問は>>674-696のやり取りと同じ話っぽいね、俺も>>704-705に同意かな。
依存関係を明示すると違和感を覚えたり気持ち悪くなるのは、大抵の場合

依存関係の認識(or分析)が大雑把。依存関係を明示するとそれが露見しちゃう。
機能分割が大雑把。依存関係を詳細に分析すると広範に絡み合ってて一体でした。

とか。Gameへの参照は、恐らく要らん情報にアクセスする権利も与えてるから
依存関係の明示というより、広範に渡る権力へのアクセス権の譲渡なのかな？

君はこの世界に神になる。俺はいいと思うけどね。というか、はなっから
グローバルなサービスとして提供してしてもいいかもね。完成させてから
リファクタリングしたほうがいい

個人的な短期小規模開発(作り捨て)なら別に問題ない。完成と反省のサイクルよ

**名前は開発中のものです。** · 2014/05/03(土) 23:45:58.24

具体的なEnemyなんてアプリ層なんだから泥臭くていいと思うのだが。

**名前は開発中のものです。** · 2014/05/04(日) 00:03:34.32

すまん、>704はセガ本が物理的に重いって話のつもりだったんだ

**名前は開発中のものです。** · 2014/05/04(日) 00:09:25.10

まあ大概のゲームプログラミング本は重いよね
電子版あるならそっちの方が捗りそうだ

**名前は開発中のものです。** · 2014/05/04(日) 07:21:43.07

描画クラスを作って描画用のインターフェイスを作る
描画されるクラスはインターフェイスを実装
描画クラスはそのインターフェイスをリスト管理し順番に描画
ゲームクラスはデータクラスと描画クラスを管理し
必要に応じてデータクラスを作り、描画クラスに登録
ゲームクラスが当たり判定をして、エフェクトクラスをnew、描画クラスに登録

て感じじゃ駄目なの

**名前は開発中のものです。** · 2014/05/04(日) 18:09:40.60

>>701
サンプルプログラムの修正版があるからそれ見て決めたら？
ちなみに独自のライブラリを使ってる

**名前は開発中のものです。** · 2014/05/04(日) 21:44:57.67

もし、新幹線できたらな
飛行機乗客が減り、飛行場が苦労する
バス乗客が減り、高速道路が苦労する

結果的に、四国地方の経営破たん

**名前は開発中のものです。** · 2014/05/06(火) 09:11:34.47

ポインタに構造体を持たせる場合ってきちんとスマートポインタを使った方がいいの？

**名前は開発中のものです。** · 2014/05/06(火) 10:42:16.25

>>711
独自ライブラリですかー・・・
ありがとう。ちょっとどっかで立ち読み出来るまでは買い控えます。

**名前は開発中のものです。** · 2014/05/06(火) 14:47:05.12

>>713
本来スマートポインタはラクをするために使う。あとは好きにしろ
あと言語の使い方一般についての質問はプログラム板のほうがいい
【初心者歓迎】C/C++室 Ver.90【環境依存OK】
http://toro.2ch.net/test/read.cgi/tech/1395675954/

はい、次の方どうぞ

**名前は開発中のものです。** · 2014/05/06(火) 15:47:49.53

そのスレ、ちょっと見たけど罵りばっかじゃないかｗ

**名前は開発中のものです。** · 2014/05/06(火) 16:22:09.99

x64の64bitビルドでのループ変数とかメンバ変数てint,unsigned intとsize_tどっちが最適なの?
DirectXのAPIが32bit幅なのにSTLは64bitみたいに混在してて決め打ちしにくいんだけど
インデックスとして毎回32bitを64bit拡張と変数を32bitにstatic_castと
タイプ量はともかく実行時に効率いいほうにしたい

**名前は開発中のものです。** · 2014/05/06(火) 16:27:40.04

>>716
報告しなくていい。そういう感想は彼らに直に言ってあげな。陰口より建設的だろ

はい、次の方どうぞ

**名前は開発中のものです。** · 2014/05/06(火) 16:28:53.69

>>717
かぶったすまん

**名前は開発中のものです。** · 2014/05/06(火) 16:44:38.90

>>718
そんな非建設的な事実上機能していないスレに誘導してどうするんだって事だよ。

はい、次の方どうぞ。

**名前は開発中のものです。** · 2014/05/06(火) 17:21:27.34

>>717
例えばループ変数については普通にint使ってるな
参考までに、科学計算系のライブラリでもそんな感じだったと思うよ
計算速度云々が問題になる場合、気にかける場所はもっと別の所かと

**名前は開発中のものです。** · 2014/05/06(火) 20:22:43.10

32bit環境でもint iをbyte iとかshort iにはしない
あとむやみにunsignedにするとsignedにunsigned加算して警告でたり面倒のもと

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

ローカル変数がautoばかりになってしまうんだけど意図的な型だけ除外しておけば問題ないよね?
constもメンバ関数含めて相当あるけど

**名前は開発中のものです。** · 2014/05/08(木) 22:48:55.29

人間がソースコードを読んだときに
「型が明らかである場合か、あるいは逆に全く意識してほしくない場合にのみ使う……とかにしておけば？

**名前は開発中のものです。** · 2014/05/09(金) 09:00:26.26

ローカル変数にauto使うメリットってある？
イテレータの型書くの面倒くさい、位しか思いつかない

**名前は開発中のものです。** · 2014/05/09(金) 09:04:31.69

十分じゃないか

**名前は開発中のものです。** · 2014/05/09(金) 13:56:58.03

型推論って引数に使ったら勝手にオーバーロードしてくれるんだと思ってたんだが、引数とか戻り値には使えないんだな
iteratorの記述を省略するための機能か

**名前は開発中のものです。** · 2014/05/09(金) 17:15:23.11

そういう用途にはテンプレート関数があるしね