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/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共有だから
他のアプリで操作されたらどうしようもない。

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

なんでCとC++をごっちゃにしてんだよこのスレ
C++アンチはどこに行けばいいんだよ

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

C++アンチなんて意味のない行為はやめてしまえ

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

C++11は許せるがそれ以前はコードに吐き気を覚えるわ

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

オタク系の板みたいにプログラム板にＣ＋＋アンチスレって立ててみたら？

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

この板でもよくね？人が集まるかどうかは板の需要と1のカリスマ次第

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

それって「C++でゲームを『作らない』スレ」ってこと？
だとしたらゲ製でやることじゃないな

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

タダでさえ住人の少ないゲ製板の、タダでさえ住人の少ないC/C++スレを
さらに分割してどうするんだよ。

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

今時純粋にCのみてのは居ないだろ。Cのみと言ってて知らずにC++の機能つかってるやつおるし。

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

コードに吐き気覚えるとか言っちゃう人って、要は書けないし理解も出来ない人が自分を正当化するために言う台詞だから無視でおk

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

そうかな。重苦しいコードってあると思うよ

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

ほほほ。そんなのほっとけ

個人の趣味の時は人目を気にすることなくベターC留まりの
作り捨て上等のコードでいいのよ

家ではみんなパンツ一枚でしょ

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

△作り捨て上等のコードでいいのよ
○作り捨て上等のコードで“も”いいのよ

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

今はもうC++（とスクリプト言語）でしか書かない
もちろんオブジェクト指向

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

class myclass{
private:
int* p;
public:
void hoge();
}

void myclass::hoge()
{
p = new int[ sizeof( int) ];
}

void main()
{
myclass obj;

obj.hoge();
obj.hoge();
}

この場合初めにNewした領域はプログラムが完全に終了するまで消すことは出来ませんよね？

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

うん

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

一個目どころか二個目も駄目じゃね

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

>>335
>>336
ありがとうございます！！

2個目を消す場合、
クラスにDelete()関数を追加して、
void myclass::Delete()
{
delete[] p;
p = NULL;
}

void main()
{
myclass obj;

obj.hoge();
obj.hoge();

obj.Delete();
}

でも、ダメですか？

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

いいけど、そこはかとなくダメコードのにおいがする

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

>>338
実際にこれを使うわけではないので安心してください！
プログラムの勉強を始めたばかりで内部的にどうなってるか知りたかったんです。

答えてくださった方たちありがとうございました！

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

>>337
一回目のnewで確保した領域をメモリリークさせるコードを書きたいの？
よくわからんテストコードだな。

**名前は開発中のものです。** · 2013/10/08(火) 09:46:37.11

>>337
myclassのデストラクタで配列解放しない理由は？

**名前は開発中のものです。** · 2013/10/08(火) 09:56:41.94

>>339
普通と言うかよくやる考え方の順序で言うと、まず真っ先に一旦myclass側のデストラクタで、そのクラスの管理責任として、
自身がメンバとして持っている要素の解放処理書いとくってのをワンセットにしてそれを土台の考え方として、

その後、それじゃ困るようななんらか事情や実装都合、あるいは設計上の理由があった時、
実行時の動作パス踏まえて考えた上で、そこでやってるような開放専用関数追加するとかって順番で考えて。

**名前は開発中のものです。** · 2013/10/08(火) 16:01:33.64

まぁ奇怪なコードを書きたくなるという性癖は割とありがちなので
（じゃなきゃIOCCCなんて生まれない）
気持ちはわからないでも

**名前は開発中のものです。** · 2013/10/08(火) 22:12:57.72

たしか前スレだったか
シングルトン使いまくりという自由人がいたような記憶があるが
あーいうのもオブジェクト指向的には奇怪な部類に入るだろうか

**名前は開発中のものです。** · 2013/10/08(火) 23:19:06.01

ゲームなんざ細かいこと気にする必要なんかねえよ
どうせたかだが数万行の糞コードだろ
多少設計が糞でも力技でねじ伏せられるレベルだろ
少なくとも設計が悪いせいで開発が頓挫するほどのことじゃない
細かいこと気にしてる前にどんどん手を動かせ
ゲームなんかmain関数一本のグローバル変数使いまくりでも何の問題もない

**名前は開発中のものです。** · 2013/10/08(火) 23:25:16.39

>>345
個人レベルなら本当にこれだけど、チームでやってるときにそれやられると死ぬ
あと、キャラクタークラスとかは流石に分けないときつくないか

**名前は開発中のものです。** · 2013/10/09(水) 10:24:14.87

あまりクソ設計にするとバグだらけになったりコードに触る気が無くなって頓挫するぞ！！