07/02/13 03:11:59
360のフリーの開発キットがC#ベースってなってるんですけども、
360の開発は現場の商用でもC#使ってらっしゃるのでしょうか？
101:仕様書無しさん
07/02/13 05:41:18
マッカーサー
102:仕様書無しさん
07/02/13 05:50:28
面白くねえオヤジギャグだな
103:仕様書無しさん
07/02/13 08:57:11
ツールくらいじゃね？
104:仕様書無しさん
07/02/13 15:04:19
>>100
C++だよ
105:仕様書無しさん
07/02/13 15:34:33
>>98
これは奇遇だな。俺も一緒に仕事をした事があるが、はっきりいって糞野郎だった。
二度と一緒に仕事をしたくない。技術は古いし、チーム開発不向きな性格。
ちなみに俺が一緒に仕事をしたのは俺が１０年目の頃ね。
技術的な面でかなりブチブチ文句いわれたもんだ。最終的には俺のコードが製品に組み込まれたがな。
たぶん未だにメインループからサブルーチンを呼び出すスタイルで、フラグ云々な遅い
やり方でやってるんじゃないのかなぁ・・・
もうとっくに昔の人。少人数でたこ部屋にこもって仕事をしていた過去の人。
106:仕様書無しさん
07/02/13 17:44:58
C++からは当分逃げられませんよ。
ム板でも、C++が許されるのはゲーム屋までよねーとか言ってるでしょ。
107:仕様書無しさん
07/02/13 19:23:17
>>105
>メインループからサブルーチンを呼び出すスタイル
多少違いはあれど、これ以外の方法ってなによ？
しかも、遅いのか？これ？
108:105
07/02/13 20:03:16
メインループにコードを全部書くんだよ。
呼び出しが無いから速いぞ。
109:仕様書無しさん
07/02/13 20:27:28
それは相当しっかり紙面で設計しとかないとコケそうだな。
というか、それほどの節約をしないといけないほど大変な処理をしてるのか？
バーチャファイター５みたいな画像を１ポリゴンごとに関数呼び出しして描画してたら
たしかに大変な負荷にはなりそうだが。
110:仕様書無しさん
07/02/13 20:30:39
大昔の低速CPU時代の携帯ゲーム（JAVA）ではそうしてた。
JAVAはCと違って翻訳をクライアント機で実行時にやるから
変数名も短くしたり（ファイルサイズ）関数も減らしたり（関数呼び出しのオーバーヘッド）、
全然JAVAらしくなかった。1人開発だからどうでもよかったけど。
それでも便利なサブルーチンはいくつかそのまま使ってた（文字数の都合もあったけど）。
あんな気持ち悪い仕事はもう堪忍どすえ。
111:仕様書無しさん
07/02/13 22:09:03
明日は待ちに待ったバレンタイン！
112:仕様書無しさん
07/02/13 22:16:38
悪しき習慣「義理チョコ」 「バレンタイン」もうやめろ
URLﾘﾝｸ(news.www.infoseek.co.jp)
恋人たちが愛を誓い合う―そんな2月14日の「バレンタインデー」の習慣に、なんだか今年は異変が起きそうだ。
渋谷では、「バレンタイン粉砕デモ」が起こり、海外でも「アンチバレンタイン」のTシャツやカードまでが
出回っている。好きな人だけやっていればいい、とも思えるバレンタインだが、急に風当たりが強まってきた。
世界各国で「アンチバレンタイン」の機運
「バレンタインに向け情勢が緊迫化する中、反動的カップル集団は非モテ・喪男（編注：モテない男）・童貞の
フラレタリア階級に対しさらなる弾圧を深めている。恋愛ブルジョワ階級は恋愛普遍/至上/資本主義によって
人々を搾取と収奪の限りを尽くし階級的な諸矛盾を爆発させる状況を示しているのだ」
「義理チョコに対する三倍返しといった明らかな収奪と言える行為を強要する連中に徹底的に
思い知らせなければならない。そう、我々はバレンタインを拒否すると非妥協的に闘わねばならない。
同志諸君、今こそ立ち上がる時が来たのだ！！万国のフラレタリアよ団結せよ！」
113:仕様書無しさん
07/02/13 23:02:28
どんな物を貰っても３００円に変換される俺は、別に３倍返しでもいいかなぁと思う。
114:仕様書無しさん
07/02/13 23:11:23
義理チョコすらもらえないから関係ない
115:仕様書無しさん
07/02/13 23:11:58
ソースｗ
URLﾘﾝｸ(www.geocities.jp)
116:仕様書無しさん
07/02/14 01:17:19
>>105
おまえ自身が昔の人に見えるがw
117:仕様書無しさん
07/02/14 02:08:22
最後に整形ツールで関数名を1文字にしろよ。
ログとっておいて復元もできるようにしとけ。
118:仕様書無しさん
07/02/14 02:46:30
>>108 メインループにコードをぜんぶって・・・
そんな奴に糞野郎呼ばわりされたんじゃ木屋たんは吊るしかないねｗ
119:仕様書無しさん
07/02/14 06:31:26
今日は待ちに待ったバレンタイン！
120:仕様書無しさん
07/02/14 10:42:56
>>105のイタさが際立つスレはここですか。
121:仕様書無しさん
07/02/14 11:22:16
ところで、リセットベクタから書かなきゃいけないハードの場合、タスク切り替えOSを実装して
レジスタの内容をPC込みで変更するようなコンテキスト切り替えロジックとかつかわないの？
まさか、最近の若い人はmainから全部サブルーチンコールとかして無駄な時間をかけているのか？
ちなみに108は105とは別人。俺が105。
122:仕様書無しさん
07/02/14 11:31:03
>>121 そもそもそんな古臭いハードで仕事しないからな。
今時リセットベクタから書くってどんな機種だよ。
アーケードの子供向け機とかか？
だいいちサブルーチンコールの時間が無駄っていうけど
メインループからスイッチ文で分岐したとしても、
各ループでサブルーチンコールとスイッチ文判定が一回増えるだけだろ
ボトルネックになる部分はいくらでもあるから、そんなところをケチって俺OS
作る暇があれば描画や衝突判定周りのロジックを見直した方が効果がある。
アセンブラが使えるところを誇示したいのか知らんけど
効果の薄い所にこだわるのはロートルのオナニーでしかないぜ。
123:仕様書無しさん
07/02/14 12:01:17
最近のコンパイラが吐き出すアセンブラが気にくわないなんてこと全然無いね。
どうしても高速化必要なら最下層ループのアセンブラを再配置するくらいでしょ。
最近の最下層は大抵GPU関係だからその必要すら無さそうだけど。
124:仕様書無しさん
07/02/14 12:08:24
>>122
マルチタスクのOSの上で、各タスクにキャラクタのコードが書かれる感じ。
毎フレーム必要な処理（描画や衝突判定等）
タスク切り替えの時間としてはレジスタとメモリの移動だけ。
mainループから各キャラクタがそのフレームで必要な処理にたどり着くまでの時間よりは
早くなるし、独立したプログラムになるので汎用性も高まる。
まぁたしかに俺はロートルで大昔からやってはいるが引退気味ではあるが現役だよ。
あまりコードいじる時間はないがな・・・・
最近じゃアセンブラまで使わなくてもなんとかなるとは思うけど、
ゲーム屋としてはアセンブラが使える事ぐらいは当然だともおもっている。
１フレーム内で動かすための努力は惜しまぬ方が良いと思う。
ハードが良くなっても手抜きコードじゃすくわれない。
125:仕様書無しさん
07/02/14 12:12:38
批判するより、持ち上げて情報を引き出した方が得だと思う次第です。
126:仕様書無しさん
07/02/14 12:17:41
for(i=Num-1;i>0;i--){
for(i=0;i<Num;i++){ ←なんと言われようがこっち派
127:仕様書無しさん
07/02/14 12:22:54
>126
なんか違いがあるの？
…… i>0 がゼロとの比較だから i<num より多少速いのかな？
128:仕様書無しさん
07/02/14 12:42:43
アセンブラのことを考えると、これが一番速いってことになるのかな？
int i = NUM;
do {
} while (--i);
129:仕様書無しさん
07/02/14 12:43:07
>>124 それってバグが出たときに追いかけるの大変じゃない？
切り替え部分はバグが無いの前提なんだろうけど
もっとシンプルな実装にした方が、複数名で開発するようなところでは安全だと思う。
あと機種依存が激しそうなので、それが使えない環境ではどうするんだよと。
そのやり方が社内では枯れてて、複数機種で実績もあるんなら問題は無いんだろうけど
新機種への移植とか考えると、あんまり採用したいやり方だとは思えないなぁ。
どうしても速度が出ないときに、最後の武器としてアセンブラを持ち出すのはありだけど。
>１フレーム内で動かすための努力は惜しまぬ方が良いと思う。
>ハードが良くなっても手抜きコードじゃすくわれない。
そら手抜きはイカンけど、シンプルさや分かりやすさの方を大切にするてのが最近の流れだしょ。
130:仕様書無しさん
07/02/14 12:43:50
>>125
情報提供。例；画面上に弾むボールが１００個あり、ボールは壁や他のボールにぶつかると動きが変わる。
--------------------
親プロセスは
ボールプロセスランダムな位置を指定して１００個作成。
衝突判定プロセス作成
描画プロセス作成
--------------------
ボールプロセス
INIT:
終了メッセージの受付登録
衝突メッセージの受付登録
衝突判定プロセスへ自プロセス登録
描画プロセスへ自プロセス登録
PROC:
永久ループ(ボールの移動、適当なフレーム眠る）
衝突メッセージ受信：
衝突したボールの位置等から移動ベクタ変更
PROCへ戻る
終了メッセージ受信：
衝突判定プロセスへ自プロセス削除要求
131:仕様書無しさん
07/02/14 12:44:34
--------------------
衝突判定プロセス
登録されたプロセスに対して毎フレーム処理。
衝突検知した場合は該当プロセスへメッセージ送信
--------------------
描画プロセス
登録されたプロセスに対して毎フレーム処理。
------------------------------------------------
こんな感じにすると、PROC内で必要なフレームだけ処理を行い、毎フレーム動く必要の無い処理は
タスク切り替えが発生しない状態になる。mainループから呼び出す方法にすると、呼び出した先で
結局無処理でメインループに戻らなければならない時が無駄になる。全てのオブジェクトが毎フレーム動作しなければならないようなゲーム（そんな物があるのかはわからないが）
では効果が薄いが、そうでない場合はサブルーチン呼び出しコストを最小限に抑えることができる。
132:仕様書無しさん
07/02/14 12:51:01
>>124
デバッグは同じ。
切り替え部分はすごく簡単。全てのレジスタとメモリの移動だけ。
複数名で開発しているし、当然機種依存なので機種単位でOSは作る。
枯れた技術だし、実績も大量にある。
mainループから呼び出す方法からマルチタスクに変更した時には確かに
プンスカ社内から文句が出たけど、一度導入して大量のキャラクタが１フレーム
で動作するデモ見せたたら、文句が出なくなったよ。
あと使いまわしが楽になった。描画部分とキャラロジックが分離してるから。
133:仕様書無しさん
07/02/14 13:05:24
>>130
えー、そんなのアセンブラレベルでやらなくてもいくらでもやりようがあるっしょ。
わざわざageてまで言うほどのもんじゃねーぞ
いわゆる古典タスク方式だと思うけど、最近はクラスでその辺を実装してるよ。
まず、全ての実行タスクはCTaskインターフェースを継承してて、
CTask型のリストなり配列なりのタスクバッファにインスタンスを登録。
メインループではタスクバッファに登録された処理を優先度にしたがって実行。
CTaskインタフェースにフラグを持たせれば、呼び出しをスキップもできるし
一時的に動作を保留するとか描画のみ行うとか衝突後再処理させるとか好きに制御できる。
あ、C++はそもそもオーバーヘッドが・・・とかの話題は勘弁な。無駄に荒れるからｗ
134:仕様書無しさん
07/02/14 13:13:02
>>129
fiberとかmicro threadとか言う人もいるやつかな
状態管理をステートパターンにする必要がないとか
利点はあるけど、それを使う必要性はそれほど感じないな
それ以上はあまり突っ込まないほうがいい気がする
>>3にあるタスクシステム方向に話が流れるおそれがある
135:仕様書無しさん
07/02/14 13:24:56
「タスクじゃ！タスクさまの祟りじゃぁ！！
その話題には深入りしてはならぬぞえ・・・・」
136:石田智史
07/02/14 13:32:45
呼んだ？
137:前田神
07/02/14 13:49:53
死ね
138:仕様書無しさん
07/02/14 13:53:12
やってる事は同じなのに「fiber（コルーチン)」なら最先端で「アセンブラによるタスク切り替え」だとロートル呼ばわりされる件
139:仕様書無しさん
07/02/14 14:26:48
まずコルーチンと書けば済むことを長々と説明するところがロートルだな
140:仕様書無しさん
07/02/14 14:36:23
ロートルは無駄にアセンブリャーで小技を駆使するからな。
C++で普通に書いてもかわらんちゅーに。
マルチコアでのパフォーマンス追及するならまた話が違ってくるけど。
141:仕様書無しさん
07/02/14 14:47:29
小技すら駆使しないロートルしか見たことがない。
142:仕様書無しさん
07/02/14 14:48:18
みなさーん！
C++でアセンブラを使わずに、fiberを「普通に」実現する方法を
スーパープログラマーの>>140氏が公開するそうです。
143:仕様書無しさん
07/02/14 14:52:51
おっさん「最近の若いもんはアセンブラも書けんのか」
若いもん「古株のおっさんはシェーダーも書けんのか」
144:仕様書無しさん
07/02/14 15:04:51
> mainループから各キャラクタがそのフレームで必要な処理にたどり着くまでの時間よりは早くなるし
今のハードや複雑なゲームロジックで一体どの程度の差があるというの。つーか昔のハードでも。
> 独立したプログラムになるので汎用性も高まる。
どう見ても低レベル層に依存して低下している。
> ゲーム屋としてはアセンブラが使える事ぐらいは当然だともおもっている。
そうですね。俺もZ80や68000やx86でバリバリ書いてましたよ。
昨日もWrite Great Code買おうとしたけどぬるぽすぎてやめた。
> １フレーム内で動かすための努力は惜しまぬ方が良いと思う。
fiberにしない人間が惜しんでいないとでも？？
> 一度導入して大量のキャラクタが１フレーム
> で動作するデモ見せたたら、文句が出なくなったよ。
fiberを使うとキャラが大量に出せるんですか。8ビット時代のハードですら誤差範囲内としか思えませんが。
まして今なら保守性やGPU資源について頭を悩ませたほうがよいかと。
> あと使いまわしが楽になった。描画部分とキャラロジックが分離してるから。
fiberとは無関係。
タスクを全部fiberにしてしまうような文化、あるところにはあるんだろうけど
俺はそんなコードに関わりたくないし、幸いにも関わったことがない。
こういう非標準的な我流殺法にこだわる人間が近くにいると大変だろうな。
まあ、世の中にはLispを採用するような突き抜けたのがいるみたいだから、まだ可愛いものかもしれない。
145:仕様書無しさん
07/02/14 16:32:02
ゲームロジックに関して言えば、今も昔も変わらないと思うよ。
146:仕様書無しさん
07/02/14 16:35:21
FiberってWindows以外のプラットフォームで実装されている？
俺、Win物ずーっと作るわけじゃないから、プラットホームに依存した考えしか受け付けないのはいやだな。
147:仕様書無しさん
07/02/14 16:41:24
>>138
スタック切り替え式のタスクで公開されたまともな実装というのは見たことがないし、
～社に入社しないと教えてもらえないような技法じゃ、そんなものは存在しないと言われても仕方ないんじゃ。
技法をオープンにしてこなかったロートルにも責任はあるんじゃないかと。
>>146
自分で実装するんだよ。
カーネルモードに依存するものじゃないから、WindowsでもCreateFiber等の
APIと同じものを自分で実装できる。
148:仕様書無しさん
07/02/14 18:04:10
>>144
Z80の頃を知っているのに、誤差範囲とか言える所に？
149:仕様書無しさん
07/02/14 20:04:09
一度だけタスクシステム（？）で開発してるところにいたことあるけど
とにかくバグが半端じゃなかった。
こらやめたほうがいいわ。
メインからサブルーチン呼び出す形が一番安定して動くしなによりバグら無い。
これがでかい。
150:仕様書無しさん
07/02/14 20:19:18
メインルーチンから呼び出すやりかたのうが単純だからな。
きにしなければいけない所もすくないしね。
少しでも処理を軽くしたい昔のハードには有効なのかもね。
今ならハードにおんぶにだっこでいくらでも楽に作れるし。
まぁ、昔の人乙。
151:仕様書無しさん
07/02/14 20:22:23
シェーダーも書けんのか。シェー
152:仕様書無しさん
07/02/14 20:23:36
V
＿＿＿＿
∧＿∧ ／＿＿＿／|
( ´･ω･`) .| ∧＿∧ !／!
／ ＼ |（´Д｀ ）|／|
.＿＿| |__＿＿| |______..| /／／ヽ|／|
||＼／＿＿＿／| ／| .| ／.／ | | ＿＿＿＿＿
||＼|..∧＿∧ .|/.| (⌒＼|_＿./ ./|／|／＿＿＿＿／.|
||. | （ ） |/.| ~＼___＿_ノ |.| || ∧＿∧ |／|
|/ ／／|/.| ＼|.!／!!（ ）... | /.|
|| ／／ ..|/.| ＼.!/ ／／ ヽl／|
|| ／／ | |二⌒) ／|.|...|／／ | ll／|
|.|／／ .| | ヽ＼∧＿∧ (⌒＼|_＿./ /.!
153:仕様書無しさん
07/02/14 20:52:34
「うちはオブジェクト指向のタスクシステム」とかいうところにヘルプにいったら、
無駄に仮想関数使いまくりだったりダイナミックキャストの嵐でパフォーマンスが
ぼろぼろ（ステージ途中でインスタンス作りまくりのおまけつき）、
しかもタスクシステムのリソース開放タイミング管理が甘くて、ぬるぽとメモリリークの嵐で後始末が大変でした。
154:仕様書無しさん
07/02/14 20:57:29
>>149
それは言い訳ジャマイカ。
システム組んだ奴や使ってる奴が糞ならどんなやり方でもバグは出るだろうに。
>>150
参考までに聞きたいんだが、そのメインルーチンから呼び出す単純な方式って奴で
複数のキャラが非同期に生まれたり死んだり、お互いに干渉するようなケースって
普通に多いと思うけど、そんな場合はどういう風に組むのが正解だと思う？
俺は昔の人なのでタスク風の書き方以外知らないんだよ。
つーかマジで教えてください、たのんます・・・
155:仕様書無しさん
07/02/14 21:03:05
>>153
馬鹿が使うとそうなる
156:仕様書無しさん
07/02/14 21:07:32
>>154
ゲームと関係無い。
普通にプログラムの能力が低いと思う。
157:仕様書無しさん
07/02/14 21:12:56
いまどきの組み込みはX68000よりはるかに速いから
サブルーチンコール程度でグダグダ言わない。
158:仕様書無しさん
07/02/14 21:23:14
>>154
普通はキャラクラスとか敵弾クラスとか地形処理クラスとか作ってメインループから呼び出すんじゃね？
タスクなんて処理作らなくてもいけると思う。キチンと設計すれ。
159:仕様書無しさん
07/02/14 21:44:04
CPUの仕組みを理解すればメインだけに全部いれようが
タスクにしようがサブルーチンにしようが違いはないということがわかると思うが。
人間のための仕組みですよ。
160:仕様書無しさん
07/02/14 22:26:17
>>154
>メインルーチンから呼び出す単純な方式
1.状態の数だけenumでswitch
2.状態の数だけ関数ポインタ
3.デザパタのステートパターン
4.有限状態遷移機械(FSM)でデータドリブン
161:仕様書無しさん
07/02/14 22:41:39
タスクシステムとかおなかいっぱい('A`)
別に好きなように組めばいいじゃん。
いい加減、細かい処理を自前でset→long jumpとかもうそんな時代じゃないの気づけよｗ
OpenMP でガシガシ書いたほうがはるかに効率いいっつーの。
162:仕様書無しさん
07/02/14 22:58:26
擬似タスクとマジタスクが混じってる予感。
163:仕様書無しさん
07/02/14 23:03:20
マジタスクってPCとスタックが復帰するやつのことですか？
164:仕様書無しさん
07/02/14 23:18:37
>>160
１．ありがちだが、これだとシーンの遷移程度にしか使えんだろ。複数キャラを効率よく動かすのには別の仕組みが必要では？
２．これもよく見るけど、微妙にデバッガで追いづらい。
あと、ポインタが破壊されたらあっという間に再現しづらいバグに変化するよな。
つーか、今時関数ポインタとか古臭いよ。
３．オサレに名前を変えただけで本質的には１と変わらんよなｗ
４．データによって変化するという事はコードだけでは処理の流れが追えなくなる。
元データをそのまま使う場合はまだマシだけど、データの内容によって流れが変化するような仕様にすると（そういうケースは多いが）とたんにバグだらけ。しかも再現させずらい最悪のパターンに陥りやすい。
なんかもっとこう、スマートでエレガントでオサレでぬるぽな実装は無いのか？
165:仕様書無しさん
07/02/14 23:23:59
関数ポインタは古いのか・・
166:仕様書無しさん
07/02/14 23:29:30
Gems3に関数ポインタをWrapしたtemplateクラス使った状態遷移マシンのネタがあったな。
なぜかツボにハマってそれ使わせてもらってる。
167:仕様書無しさん
07/02/14 23:48:02
個人的にhotateのページの擬似タスクのテンプレートクラス版使ってるけど
集団で作る時は、メインの人がC++好きか嫌いかで
クラスの擬似タスクか構造体の擬似タスクかのどちらかになってる。
どっちにしても関数ポインタとメモリ管理の安全がミソのコーディング手法だけど。
仕事で初めて見た時、C++の擬似タスクだったけど、これが有名な擬似タスクですね、って言っても
メインの人が「？」って感じの返答してたから。通称が無いのかもしれん。
自分は Hotate's Core とかいうホームページで実装方法知ってその人が”擬似タスク”と言ってたからそう覚えてる。
168:仕様書無しさん
07/02/14 23:58:54
>>164
１と３は全然違う。１だとメイン側が状態の数を全部知ってる必要があるんで、
状態が増えるたびにメイン側をいじる必要がある。
関数ポインタがデバッガで追いづらいって、仮想関数も同じ理由で使わなかったりするの？
169:仕様書無しさん
07/02/15 00:01:32
ぐぐってみたが、Hotate's Coreって無くなってるね。
170:仕様書無しさん
07/02/15 00:10:06
>>167
どうせ抽象クラス（へのポインタ）をコンテナに突っ込めばできあがりな構造だろ。
NGワードを持ち出してまでひとくくりにする必要は無いと思われ。
171:仕様書無しさん
07/02/15 00:13:34
>>167
５年以上前の過去ログにぴったりなレスを見つけて
面白いというか、悲しいというか変な気分になった。
URLﾘﾝｸ(pc.2ch.net)
ここの 150 ね。
172:仕様書無しさん
07/02/15 00:18:02
最近自分のwindowsはこんな↓
メッセージスレッド（メインループ）
計算スレッド（座標ヒットチェックとか入力判定とか）
描画スレッド
サウンドスレッド（DirectSoundのおかげでほされそう）
通信スレッド
各スレッドが擬似タスクにクリティカルセクションでアクセスする感じ。
173:仕様書無しさん
07/02/15 00:26:51
>>171 そのスレの65-68とか128-165とかのレスを読んでたら全米が泣（ｒｙ
2001年時点から全然進歩してねーのな、おまいら。
たぶんもっと前から同じ議論が繰り返されてるんだろうなぁ。
こりゃ日本のゲームが衰退するはずだわｗ
174:仕様書無しさん
07/02/15 00:27:55
トップクリエイターが福岡に集結！「Game for Future 2007」イベント開催！
URLﾘﾝｸ(www.gff.jp)
175:仕様書無しさん
07/02/15 00:54:44
まあカプコンがまだタスクとか言ってるんだから大丈夫だろ。
176:仕様書無しさん
07/02/15 01:03:10
>>164
> なんかもっとこう、スマートでエレガントでオサレでぬるぽな実装は無いのか？
>160とFiberで満足できなけりゃあとはSchemeの継続でもやってくれと言うしかないね。
ゲームの状態遷移なんてその場限りの使い捨てなんだからswitchかFiberの
汚くなりやすいが軽量な手法が向いてるんじゃないかと思うけど。
177:仕様書無しさん
07/02/15 01:05:42
>>165
時代はクロージャーだ関数オブジェクトまんせーデレゲートまんせーとかw
つか関数生ポインタはデータに対する生ポインタより障害は少ないと思うし、有効だと思うんだが駄目な理由はなんなんだろうな？
壊したら普通即飛びで、スタック追えは一発だと思うのだが。
178:仕様書無しさん
07/02/15 01:09:34
配列よりListやVectorがいいとかそういう程度の問題では。
初期化忘れや未定義変数へのアクセスが出来てれば
アホにもいじってもらえる。
179:仕様書無しさん
07/02/15 01:30:35
>>176
＞その場限りの使い捨て
だといいですねぇ、ほんとにまったく。
180:仕様書無しさん
07/02/15 05:42:52
>>177
実行するもんによって引数違うことのが多いから役にたたね。
関数ポインタ使う＝グローバルでアクセスできるなにかが必要になる。
だから、あんまりうまい設計にならないことに気がついて辞めた。
181:仕様書無しさん
07/02/15 06:50:53
稲葉敦志。神谷英樹。三上真司。そして、選りすぐりのスタッフ達。
新会社SEEDS。
URLﾘﾝｸ(www.seeds-inc.jp)
182:仕様書無しさん
07/02/15 06:53:09
SEEDSは社員を募集しています。
プログラマー
ゲームプログラム全般、
ツール及びライブラリ制作
CGツールプラグイン制作（XSI等)
サウンドドライバ制作
C/C++言語でのプログラミング経験
ゲーム作りに対する強い意志と忍耐力
183:仕様書無しさん
07/02/15 07:04:13
なんか話が食い違うと思っていたらやっと原因がつかめた。
オレは昔の人なんだけど、擬似マルチタスクとかを作って使っていた世代。
昔は機械の性能が低くて「開発のし易さ＜実行時のパフォーマンス」だったのね。
今は機械の性能が高いから適当にできる「開発のし易さ＞実行時のパフォーマンス」なのね。
だから、ソースも出てこないFiberとかデバッグがしずらいウンヌンとかいっているのか・・・
日本のゲームプログラマも落ちたもんだ。オレは日本のソフトウェア屋でゲーム屋が一番賢い
と思っているし、日本が海外へ輸出する数少ないソフトウェアだと思ってた。
ゲーム以外のソフト開発もしているからわかるが、ゲーム屋は間違えなく平均艇に賢いし、
手際もいい。土壇場で逃げ出さない根性もあるはず。だからハードに頼らずいいものを
作って欲しい。
Cコンパイラもなく、メーカーからライブラリが提供されなくて、あるものはハードの仕様書のみ。
って状態でコツコツ作っていた時代に戻れないのはわかっているが、もうすこし魂を入れて開発
してもらいたい。
184:仕様書無しさん
07/02/15 07:30:29
>なんか話が食い違うと思っていたらやっと原因がつかめた。
>>3を読めば原因は明らかだよなｗ
185:仕様書無しさん
07/02/15 07:34:10
ネタにしちゃ面白くないし、マジなら引退した方がいいんじゃね？
186:仕様書無しさん
07/02/15 07:38:17
>>183
俺も昔からやってるけど、擬似タスク使う奴は昔からバグ多かったよ。
１フレーム単位のキャラの動作からいって同期してねーようなもん作る奴ばっかりだった。
187:仕様書無しさん
07/02/15 08:05:14
>>186
1フレーム単位のキャラの動作の同期が気なるようなゲームの場合こそ、
擬似マルチの方が適切だと思うが・・・
各タスクの動作順番をリアルタイムで変更できるし、同じタスクを二度動くように
スケジューラーをいじる事もできるし・・・・
使い方を知らないだけだと思う。
188:仕様書無しさん
07/02/15 08:38:38
URLﾘﾝｸ(60.43.240.156)
↑DNSが反映されていない人向け
189:仕様書無しさん
07/02/15 09:22:13
>>183
>昔は機械の性能が低くて「開発のし易さ＜実行時のパフォーマンス」だったのね。
>今は機械の性能が高いから適当にできる「開発のし易さ＞実行時のパフォーマンス」なのね。
違うよ、昔は開発規模が小さかったから高速化をしようとプログラム全体をチューニングできたが
今は開発規模が大きくなって、全てをチューニングしていたら何年かかっても完成にこぎ着けない、いつの間にか途中で妥協する事になるんだよ。
だからポイントを絞って高速化する必要があるし、高速化のための作業時間を捻出する必要があるの。
パフォーマンスの事ばかりをやっているとかえってパフォーマンスが下がる事に気づけ。
190:仕様書無しさん
07/02/15 22:35:48
>>181>>188
こうだな
URLﾘﾝｸ(www.seeds-inc.jp)
URLﾘﾝｸ(60.43.240.156)
↑DNSが反映されていない人向け
191:仕様書無しさん
07/02/15 23:07:26
>>187
各タスクの動作順をいじる意味が全くわからない
長いことゲーＰＧやってるけどそんな需要は欠片もねぇ
192:仕様書無しさん
07/02/16 00:49:26
それより動作順でバグが出る方がおかしいと思うよ。
193:仕様書無しさん
07/02/16 01:05:33
まあ知能が低いみたいだからスルーで。
194:仕様書無しさん
07/02/16 01:19:11
擬似タスク＝クラス
擬似タスクは所詮クラスが無かった頃に、同じような機能をCで実現する為の仕組みでしかない。
ようは関数呼び出しの定型化と関数とデータのカプセル化、マルチプルインスタンスの実現を
Cでやる為に考え出されたテクニックに過ぎん。
いまさらタスクというやり方にこだわらなくても、各キャラごとのクラスを作って
シーンクラス内で処理すればまったく問題ない。
C++で組んでるくせにワザワザ、タスク処理を実装する奴がいまだにいるんだよな（激爆笑
そういう奴に限って枯れた技術マンセーとか慣れたやり方のがいいとか、ぬるい言い訳ばっかりしやがる。
…まぁ、俺のことなんだがな。
195:仕様書無しさん
07/02/16 01:27:43
この流れを見て改心してくれたんなら、それはとてもうれしいことだ。
何事も完全に無駄ではないと言うことだな。
196:仕様書無しさん
07/02/16 01:35:29
動的にタスクを増やしたり親子構造にしたりできるようにすれば
タスクを名乗っててもあんま恥ずかしくないんでは。
197:仕様書無しさん
07/02/16 01:45:30
動的にインスタンスを作るのは普通にできるし
親子構造もテンプレートなりでツリー構造を実装すれば良い。
そろそろゲーム屋は擬似タスク（又は古典タスクシステム）という言葉の呪縛から脱却した方がいいと思うぞ。
198:仕様書無しさん
07/02/16 01:50:17
親子構造やツリー構造に名前をつければ解決すると思われ。
199:仕様書無しさん
07/02/16 02:37:43
>>196 ダメ。ゼッタイ。
200:仕様書無しさん
07/02/16 03:19:21
魔流血多巣苦
201:仕様書無しさん
07/02/16 07:10:01
>>192
壁とキャラの判定順が変わるだけですり抜けバグが多くなると思う。
202:仕様書無しさん
07/02/16 11:03:18
親子構造ってのがそもそも直感的ではなく、バグの温床になる。
ここはぜひとも、お兄ちゃんと妹構造 にすべき。
203:仕様書無しさん
07/02/16 11:18:40
ワーク領域という発想の無かった俺には、天啓以外のなにものでもない。
204:仕様書無しさん
07/02/16 11:32:51
>>199
URLﾘﾝｸ(www.dapc.or.jp)
205:仕様書無しさん
07/02/16 13:09:09
ネタが無いな。
AIについてでも語ってくれ。
206:仕様書無しさん
07/02/16 13:25:31
>205
君のひとみに乾杯。
207:仕様書無しさん
07/02/16 13:49:40
タスクはおいといて、ゲームのメインループってやっぱりステータスみてswitch文てのが一般的なん？
状態を変数で持つんじゃなくて評価関数を持たせる事でもっと柔軟に実装できるような気がするんだが。
たとえば色んな条件が組み合わさって、キャラの移動60%＋ジャンプ15%＋攻撃25%みたいなパラメーターを渡すと
処理の方でも渡された行動比率に従って、それぞれの処理をキャラクタの行動にフィードバックするみたいな。
たとえば通常の移動でも速度100がMAXってことにしておけば、それこそ一度処理しておくだけであとは計算の必要が無く
次回以降は比率を掛けて返すだけ。攻撃も同じで動作のモーションに対してパラメーターが渡されれば
あとは比率に応じてアニメパターンを適当に変更したり速度を変えたりするだけ。
キャラ間の干渉も比率の操作だけで住むので処理順序などに依存する必要も無く強固な構造が可能になる。
個別の処理は極力単純化しつつ、オブジェクト間の干渉度をパラメーター操作するだけで複雑な結果を作成する事ができる。
こういう風にすればゲームはもっと柔軟にプログラムすることが可能になるはず。
・・・とか妄想してみたんだが、やっぱ意味わかんねえよな。
実は俺もだ。
すまん。
208:仕様書無しさん
07/02/16 14:11:32
>>207
最初の一行しか意味がわからんが、
> ゲームのメインループってやっぱりステータスみてswitch文てのが一般的なん？
C++ でそれは無い。 C でもやらない人が増えてるんじゃないの？
209:仕様書無しさん
07/02/16 15:05:12
＞C++でそれは無い。
そうか？stateパターンとか言いつつ実態はswitchで実装してるだけってのを見た事あるが・・・
＞最初の一行しか意味がわからんが、
なんか3Dでモーションをブレンドする時にパラメーターによって微妙に変化するじゃん。
そういうのを通常の処理に組み込めたら面白いなって思っただけなんだ。
キャラクタの行動やステータス変化など全てをパラメーターで操作できるようにしておいて、
外部からはパーセンテージのみでそれをいじくれて、ブレンドできたら面白いかなって。
たぶんデバッグで死ぬると思うが・・・
210:仕様書無しさん
07/02/16 15:38:25
別に長文で語るほどのことではないでしょ。
その程度のことはどこでも実装しているよ。
状態でswitchフラグだけのほうが不自然だわ。
211:仕様書無しさん
07/02/16 16:17:54
>>209
ゲームでは高速化のためにブレンド比率の固定値をまわしてるだけだし、
そういうことを動的にするアプリって、モデリングソフトとかじゃまいか？
そういうゲーム作ってるってんなら星飛雄馬の姉ちゃんなみに草葉の陰から応援するけど。
212:仕様書無しさん
07/02/16 16:40:35
＞その程度のことはどこでも実装しているよ。
そうか？俺の知る限り、>>209のアイデアを形にしてるのって、「Spore」ぐらいなんだがな。しかもまだ製作中のハズ。
URLﾘﾝｸ(video.google.com)
これをその程度とは・・・ハッ！？ウィルライト降臨か？
213:211
07/02/16 17:46:26
トゥイーニングがじゃなくって
その頂点がボーンマトリックスに対してどの程度ブレンドするか
を動的に設定できるようにするってんでしょ？
なんか仕事っぽいゲームしか想像できないｗ
214:仕様書無しさん
07/02/16 23:03:57
自分は、各処理毎にメイン(メッセージ)ループを持つかな。
各シーンで関係ない所を分岐チェックするのがじゃま。
215:仕様書無しさん
07/02/16 23:09:15
うーん・・・そういうのもたまに見るけど、シーンの分岐チェックが嫌だからって
ループのコードが分散するのも無駄にコードが増えて美しくないような希ガス
216:仕様書無しさん
07/02/16 23:39:24
確かに、コードはかなり増える。
ただ例えば、昔のドラクエなんかだと、
戦闘中は戦闘中の事だけできればいいから、
フィールドコマンドの事には触れたくない。
戦闘ループに入る時に、味方の能力、敵の能力などの
必要なデータだけを渡し、戻り値で勝ち負けを返す感じにする。
ただ逆に、戦闘中にフィールドの情報、
例えば、水に居る時は水属性が有利になるとか、
拡張させる時に、めんどくさくなる場合もある。
217:仕様書無しさん
07/02/16 23:52:20
俺は個別にループを作る方が好きだな。
フラグのon/offが分散する方が嫌だ。
といっても好きに組めることはほとんどないし、さすがに慣れたけど。
218:仕様書無しさん
07/02/17 00:12:36
おお、数少なき同士よ・・
自分は個人製作だから、共同の場合は、
switch型、個別loop型が向いているとかあるんかな。
219:仕様書無しさん
07/02/17 00:40:18
>>218
個人と法人(共同開発)は、その部分に限らず別物だわさ。
手間よりも品質と分業効率が優先される。
220:仕様書無しさん
07/02/17 00:59:33
誰かが使ってくれると信じて作ってはみたものの、使われないクラスたち・・・
221:仕様書無しさん
07/02/17 01:12:43
>>215
そういう時は関数の銘銘規則を見直して、関数の配置位置を整理してみるといいよ。
はー、最近自動リファクタになれてしまってリファクタつらい、自動リファクタツールが欲しい、C++のリファクタ面倒くせー
誰かー諸悪の根源プリプロセッサをぶっ潰してくれー
222:仕様書無しさん
07/02/17 01:43:44
必要のないものは親子構造から切り離す。
ツリー式のタスク作ればループ1個で必要なものだけを
処理できて幸せになるよ！
223:仕様書無しさん
07/02/17 02:07:07
またNGワード出たな。
Stateパターンでいいだろ。適当に入れ子にして。
224:仕様書無しさん
07/02/17 02:20:20
ループをいっぱい作ってるやつに言ってやれよ。
225:仕様書無しさん
07/02/17 03:58:07
これが秀逸だなｗ
URLﾘﾝｸ(www.youtube.com)
226:仕様書無しさん
07/02/17 04:24:44
お前ら海外のゲーム作りの修行に行ってこい！
今の日本発のゲームの臭い事ったらねーぞ！
恥ずかしくなるだろ！おまえらも洋ゲープレイしてるとわかるだろ？和ゲーの陳腐さが！
227:仕様書無しさん
07/02/17 04:48:40
実は日本人が流出している罠
228:仕様書無しさん
07/02/17 09:54:26
アメリカの大学でゲーム専攻の学位取りたいな。
どんな教育が受けれるのか見てみたい。
229:仕様書無しさん
07/02/17 12:01:10
>>228
アメリカの大学でビデオゲーム関連の学科を卒業した連中と仕事をしていたが、
各人が個別のタスクシステムを持っていたぞ。
タスク管理、メモリ管理、タスク間通信等。どのプラットフォームでも対応できるって。
メーカーが提供するコードは信用できなから可能な限り使わない方向がはやりらしい。
日本の昔の人達がやっていることを海外の連中が今やっている感じではあるわな。
230:仕様書無しさん
07/02/17 12:30:51
>>228
うわ、クセーなそれ。
ドロップアウトしたプログラマが教える側に立ってそう。
231:230
07/02/17 12:31:28
アンカー間違えた。 >>229 ね。
232:仕様書無しさん
07/02/17 12:55:44
>>230 そこだけ聞くと日本のゲーム専門学校も同じような状況な訳だがｗ
233:仕様書無しさん
07/02/17 14:01:52
どこかの記事に、ロクなこと教えてなくて無駄ってあった。
日本と変わらず。
234:仕様書無しさん
07/02/17 14:15:12
カリフォルニア大学やらワシントン大学など名門校がゲーム専攻を導入し始めたのは最近だから、まだ指導体制やらカリキュラムがうまく確立してないのかもな。
将来はどうなるかわからんけど。
235:仕様書無しさん
07/02/17 19:05:11
まあ、２プラットホーム以上経験すれば全部自前でそろえた方が
楽だと気がつくはず。
気がつかないのはそういう苦労をしてくれる神の元で楽に生きてるからだろう。
236:仕様書無しさん
07/02/17 19:16:54
ゲームプログラマなんて余裕だろｗ
コナミでウイイレ作るかｗｗ
バスケゲームもいいなｗ
237:仕様書無しさん
07/02/17 19:23:37
上の方で擬似タスク云々の話が出てるけど、
擬似タスクでバグってる奴の多くはワンフレーム単位での矛盾が解決できて無い奴が多い。
ＳＴＧなんかで敵に弾があたったとして敵と弾のステータスの遷移を
次のフレームに持ち越すような設計になってることが多い。
そういうことを一つ一つ解決していけば擬似タスクでも問題は無いかもしれない。
この問題はswitch文の連発で作った場合でも下手糞だと起こるが
switch文で作った方が楽という結論を出した奴の多くはこの問題の本質が見えている。
擬似タスクで作ったときに一番頭に入れて置かなきゃいけないのは複数の物が絡んだときの
状態遷移をどこで行うか？っていうところだ。
これを管理できてる奴とできてない奴でできるもんの質が全く違うものになる。
238:仕様書無しさん
07/02/17 19:40:37
だからそれは擬似タスクやswitch文とは関係のない話で
ちゃんと処理の流れを理解してて、バグになりそうな部分を意識しつつ
コードを設計していればどんな組み方だろうが何の問題もない。
それをタスクだとかswitch制御だとかコルーチンだとかの手法のせいにするのが
そもそもの間違い。自分がよく分からなくてメインプログラマやネットで拾った
やりかたをなんとなく使いまわしているからバグが頻発する。
キチンと設計し、コードの隅々まで目を通し、動作を理解しろ。
それをキッチリやった上で手法の良し悪しについて議論するのなら意味があるが。
239:仕様書無しさん
07/02/17 19:42:35
間違いを起こしにくい設計もあるんじゃないかと。
動きゃいいってのは、なにかとても素人くさい。
240:仕様書無しさん
07/02/17 19:48:48
>>239
だよな。
擬似タスク使う奴の多くってのは追加物増やしたときに
それをメインのループに組み込む＝メインのプログラムを変更するのを嫌って（どっちかというと面倒とかそういうの）
そういう設計にする奴が多いように見える。
しかし、この怠惰が状態管理も怠り、バグを生んでるように見える。
直接の原因は擬似タスクではないかもしれんが、引き金になってしまってる面はある。
特に擬似タスク以外の組み方を知らないって奴はまずいと思う。
一度switch文の連発で組んでみることをオススメする。
241:仕様書無しさん
07/02/17 19:56:33
>>240
君は知能が低い上に視野も狭い。中２病ってやつ？
242:仕様書無しさん
07/02/17 19:56:45
>>240
メインのプログラムを変更するのを嫌うのはただの怠惰じゃなくて、
単純に影響範囲が違うんだから当然だろう。
243:仕様書無しさん
07/02/17 20:12:18
>>242
でも、実際はする必要があるのにしないってのがまずいポイントじゃん。
明らかにする必要があるんだよ。
だって、敵と弾があたって出る爆発クラスのインスタンスやら衝突イベントは
敵クラスにも弾クラスにも属さない別のクラスにいるべきなんだから。
まあ、この問題について詳しく語りたいわけじゃないけど、
追加したタスク（クラス？）だけで解決しようってのがそもそもの間違いなのに
それを考えずに・・・って状況があると思うんだよね。
244:仕様書無しさん
07/02/17 20:13:44
誰か置いてけぼりの俺に"擬似タスク"ってなんなのか説明してくんない？何が擬似なんだ？
245:仕様書無しさん
07/02/17 20:16:27
>>244
スレをはじめから読むなりなんなりしてくれ。
いわゆる普通のタスクとはちょっと性質が違うので現場でぶち当たった奴にしかわからんと思う。
246:仕様書無しさん
07/02/17 20:32:39
ふと思ったんだが、擬似マルチタスクの擬似？
URLﾘﾝｸ(e-words.jp)
247:仕様書無しさん
07/02/17 20:41:04
>>243
アホなお前にも分るようにオレが作ってた例をあげてやろう。
自機管理タスク
敵管理タスク
敵弾管理タスク
爆発管理タスク
各種タスク生成タスク
各種タスク削除タスク
描画タスク
なんか処理を増やしたいならタスクを増やせばいいだけ。
アイテム制御タスクとかな。
あーくだらねぇ。知恵遅れは道具の使い方に工夫がない。
248:仕様書無しさん
07/02/17 20:52:43
おさらいだが、
コメントがある >>>> 越えられない壁 >> すごい処理 > しょぼい処理
ということだな。
249:仕様書無しさん
07/02/17 20:54:11
他人を知恵遅れとか罵倒しなきゃならない時点で説得力0。
250:仕様書無しさん
07/02/17 20:58:12
>>243
新しいクラスを作るのは必要に応じてやればいいが、それが
メイン（メインループ）のコードをいじるのと直結していると、
些細な変更でプログラム全体に影響が広がる可能性が高いので
バグを抑えるという観点からするととても良くない。
251:仕様書無しさん
07/02/17 21:09:15
>>247
え？俺の言ってることの１％も理解できてないじゃん。
タスクの生成はいいけどさ、それをどこでやるか？って話だよ。
敵と弾の当り処理をどこに書いてる？
252:仕様書無しさん
07/02/17 21:34:11
敵と弾の当たり処理タスク
253:仕様書無しさん
07/02/17 22:02:43
>>252
それだな。それが>>247には無い。
>>243の内容が理解できているなら真っ先に書いてしかるべきなのに無い。
こいつの組むプログラムには本当に無いんだろうな。
この辺の違いがバグを出す奴と出さない奴との差なんだろうな。
それと敵と弾の当り処理タスクなんて本当にこの形でもっといた方がいいもんなのか？
爆発タスクって当りタスクの後に動かさないとまずいよね？
それともその処理は次のフレームに持ち越すんだろうか？（俺はこれを許さないが）
俺には複雑過ぎて制御はできそうにないな。＞擬似タスク
254:仕様書無しさん
07/02/17 22:05:03
弾が持つに気まってんだら
255:仕様書無しさん
07/02/17 22:09:40
>>254
なんかおかしくね？
256:仕様書無しさん
07/02/17 23:27:48
おまいら>>3-4嫁。
そもそも「擬似タスク」への理解が統一されてないのに釣られすぎ。
これはもう、「疑似餌タスク」と呼んだ方がいいなｗ
257:仕様書無しさん
07/02/17 23:38:24
>>253
仮にSTGだとしてループでやるとしたら大まかに↓みたいな感じじゃないか？
仕事でSTG作った事無いから思いつきでしかないけど。
ループ{
キー入力
敵出現管理
自機移動＆弾発射 敵移動＆弾発射
弾移動
自機＆敵＆弾 相互の衝突突判定
自機＆敵＆弾位置補正
爆発
オブジェクト消滅管理
描画
}
258:仕様書無しさん
07/02/17 23:41:17
>>257
まあ、よくみとらんからそれが正しいかはわからんけど、順序は固定だよね。
擬似タスクな人はなんでタスクにすんだろね？
なんか実行順序変えることに意味があるのかな？
259:仕様書無しさん
07/02/17 23:49:00
タスクにすると順序が変わるとか言ってるのは釣り？
260:仕様書無しさん
07/02/17 23:51:34
>>258
一元管理できるからじゃないかな。
261:仕様書無しさん
07/02/17 23:53:23
関連が多くなればなるほどタスク作りまくるみたいだけど
やっぱりバグりそうだよな。
発生した爆発で特定の弾を消すなんてなったらまたタスク作るのか？
262:仕様書無しさん
07/02/17 23:54:56
>>259
絶対に固定なのに実行順序を変えることができる仕組みをわざわざ作ってることに意味が見出せ無いってだけ。
バグも多くなる部分だし、単純にやらないほうがいいじゃないか。
263:仕様書無しさん
07/02/17 23:56:11
>>260
どうやってだよ・・・。
もうこの時点で実行順序は固定だし一元管理できてる部分なんてないじゃんよ。
264:仕様書無しさん
07/02/18 00:04:57
そもそもなんでタスク分けするのか考えてないんだろ
265:仕様書無しさん
07/02/18 00:10:37
>>263
キー入力、敵１体ずつ、弾個ずつ、時機それぞれをタスクにすればおｋ。
266:仕様書無しさん
07/02/18 00:10:45
>>263 擬似タスクという枠に嵌め込む事で、生成と消滅を一箇所で行えるという利点はある。＞一元管理
ただ、擬似タスクという仕組みを今更作る必然性は全く無い。ゼロ。無駄。忘れて良し。
描画クラス用と実行用クラス用の中傷クラス作って紐付ければよいだけ。
267:仕様書無しさん
07/02/18 00:15:08
>>262
お前が３Ｄのゲーム作ると、処理が先に行われる、視界の奥にあるオブジェクトが手前に描画されそうだな。
268:仕様書無しさん
07/02/18 00:15:53
>266だが、スマン。一個だけ擬似タスクシステムを使う必然性というか利点があった。
「昔からのプログラマと話すときに共通言語として擬似タスクという言葉を使うと話が早い。」
これだけ。
なので、自分の場合は普通に作ってても、クラス名を○×Taskとするようにしてる。
269:仕様書無しさん
07/02/18 00:18:24
>>267
つ[Zバッファ]
270:仕様書無しさん
07/02/18 00:23:38
>>267
タスクの実行順序と描画の優先度は別じゃないか･･･
271:仕様書無しさん
07/02/18 00:40:20
ところでタスクってなに？
自分は各要素(自機、敵機など)をMainメソッド(更新処理)とDrawメソッド(描画処理)に
分けてそれぞれ処理してるけど、これじゃだめですか？
タイトルシーンやゲームシーンの分け方は、基底シーンクラスを継承したものをそれぞれ作ってる。
272:仕様書無しさん
07/02/18 00:49:22
>>271 気にするな。それでいい。
273:仕様書無しさん
07/02/18 00:58:35
>>271
それを体系化したものの通称がタスクシステム
274:仕様書無しさん
07/02/18 01:43:55
体系化というより会社ごとPGごとの方言が多すぎて収集つかなくなってるけどなｗ
275:247
07/02/18 01:51:18
衝突判定がないからダメときたか。
必要なら増やせばいいと書いてあるのに。
結論ありきで語ってるやつはすぐ論理が破綻するし
会話もなりたたねーからウザイ。
こういうやつの肩もってるやつは自演だと信じたいよまったく。
知能が低いにもほどがあるわ。
276:仕様書無しさん
07/02/18 02:06:27
スマン、誰に向かっての発言かわからんのでアンカー付けてくれ。
277:仕様書無しさん
07/02/18 02:35:25
>>275
だってお前のは必要なことが書いてなかったじゃないｗ
後だしジャンケンで正当化する前にやることしっかりやっときなよ。
プロの仕事じゃないね。バイバイ。用無しｗ
278:仕様書無しさん
07/02/18 02:38:38
PCゲーであるエロゲなどのプログラムを書き換えて
ディスクレス化や主人公の名前を書き換えたりとかしてみたいのですが
どこでどんな勉強をすればいいですか？
できたらネットで勉強したいのですが。
279:仕様書無しさん
07/02/18 02:44:36
次からタスクで議論する奴は↓のどれを指すか宣言してくんない？擬似タスクとか意味わかんねーし。
A. プロセス
B. プリエンプティブスレッド (非同期にコンテキストスイッチするもの)
C. ノンプリエンプティブスレッド (明示的にコンテストスイッチするもの) (==Fiber/コルーチン)
D. C++のクラスにupdate/draw関数を付けてリストで繋いだもの
280:仕様書無しさん
07/02/18 02:45:37
>>278
まずは対象のゲームのライセンスをよく読むこと。
そのうえで以下のような知識が必要になるだろう。
・バイナリエディタの使い方
・Visual Studio などに付属のデバッガの使い方
・Windows API
・使ってる CPU について
・アーキテクチャ
・マシンコード
・逆アセンブラの使い方
281:仕様書無しさん
07/02/18 02:46:56
>>279
それらのうちのどれを指すとしても、そもそも「タスク」なんて言葉を
使う必要が無いと思うんだが。
282:仕様書無しさん
07/02/18 02:52:31
>>280
ありがとうございました。
283:仕様書無しさん
07/02/18 02:54:01
歴史的経緯によりあえてタスクという名称を使用する事になっておりますｗ
284:仕様書無しさん
07/02/18 03:01:11
>>281
タスクって用語を使う人間に、じゃぁお前の言うタスクってどんなのなのさ？と
尋ねるよりは、この中のどれよ？と選ばせる方がまともな回答が得られるかと思ってね。
実際プロセスをタスクと呼ぶような組み込みもどきな人間ばかりじゃなくなってるし
そろそろなくしたほうがいい用語だと思うけど、なくならねーだろうなぁ・・・。
285:仕様書無しさん
07/02/18 03:08:42
だから、擬似タスクといわゆる普通のタスクは全然似てないんだってｗ
286:仕様書無しさん
07/02/18 03:10:00
インド人とインドネシア人みたいなもんだよｗ
287:仕様書無しさん
07/02/18 04:44:02
エヴァンゲリオンがリメイクされるみたいですね
288:仕様書無しさん
07/02/18 07:52:13
>>279
Ｂがスレッド、Ｃがタスク、Ｄが擬似タスクだと思ってた。
289:仕様書無しさん
07/02/18 11:26:36
Dのやり方なんて名前付けるほど大それたもんじゃねーと思うのだが
デザパタと一緒で名前をつけるのは意思疎通するために必要なんだなと
このスレ読んでて改めて感じた久々の休日
290:仕様書無しさん
07/02/18 11:35:41
意思疎通しようと思って擬似タスクを話題にした結果がこの有様ですよｗ
291:仕様書無しさん
07/02/18 11:44:26
俺もそれでいいと思うよ、いまさらタスク・タスク言い続けるのもどうかと思うし。
すでに分かりやすい概念が色々考えられているのだから、古いやり方に拘らずそちらにしてしまったほうが良いと思う。
ただ関数の銘銘に関しては Main より Update 等にしたほうが良いだろうな、Mainではどういう機能をもっているのかハッキリしない。
もう360のATGライブラリでもそういうタスククラス採用されていないだろ。
その内コンポーネントとか呼ばれるようになるんじゃないか。
292:仕様書無しさん
07/02/18 11:45:20
>>291
アンカー書き忘れ >>271
293:仕様書無しさん
07/02/18 15:30:00
意思疎通するのに名前付け重要だよな。
overlay とか、はじめ意味通じなかったｗ
294:仕様書無しさん
07/02/18 16:06:38
>>293
考え方が極端なんだよ。
そのままことあるごとに名前付けていったら辞典ができちまうわ。
しかも、大して便利じゃねーし。
ここ一年ぐらい擬似タスクなんて名前使ったこともなかった。
つーか、２ちゃんでくっだらねー議論するときぐらいしか使わない＞擬似タスク
なんでもそうだけど適材適所と知るべし。
あれば便利、でも、万人が知らないものを知っている前提として押し付けるのは不便でしかない。
295:仕様書無しさん
07/02/18 20:40:44
プログラマーがどれだけ周りの意見を聞かないかがよく分かるスレだｗ
テンプレを読まないじゃなくて、読んだ上で無視。もうスレタイに書くべき。
296:仕様書無しさん
07/02/18 20:44:45
+ . .. :.... .. .. .
∧＿∧ 月曜日？ぼこぼこにしてやんよ
( ･ω･)＝つ ..+
(っ ≡つ .. ,
+ .. . .. . +..
.. :.. __ ..
.|: |
.|: |
.(二二X二二Ｏ
|: | ..:+ ..
∧∧ |: |
/⌒ヽ),_|; |,_,,
_,_,_,_,,～（,, ）;;;;:;:;;;;:::ヽ,、
"" """""""",, ""/;
"" ,,, """ ""／:;;
"" ,,""""" /;;;::;;
297:仕様書無しさん
07/02/18 22:55:27
もう「ゲームプログラマ徹底議論！第２４回戦」
でいいんじゃね？
298:仕様書無しさん
07/02/18 23:36:48
GPK
299:仕様書無しさん
07/02/19 01:01:26
それでは次の議題に移ります。
テーマは「ゲーム開発におけるエクストリームプログラミングとテスト駆動開発の活用について」です。
では、皆さんよろしくお願いします。
↓
300:仕様書無しさん
07/02/19 01:03:37
作り直さない現場なんかあるのか？
テストに関してはまったくやってないところばかりだろうな。
301:仕様書無しさん
07/02/19 01:28:59
現状のゲームにおけるテスト駆動開発は自動化が大変難しい、以上。
マイクロソフトが良いツールを作ってくれる事を強く期待。(他力本願駄目グラマ)
302:仕様書無しさん
07/02/19 01:29:02
美少女ゲームプログラマ（眼鏡っ娘限定）となら
ペアプログラミングでエクストリームな事をしたいです。
303:仕様書無しさん
07/02/19 02:07:34
ビーチバレーエクストリームでもしてろ
304:仕様書無しさん
07/02/19 02:23:02
>>301
もし、UI部分も含めた自動化テストが可能になったとして、最早それは高機能BOTに他ならず、
ネットゲームあたりなら死活問題ですな。
XPは、ソフトウェア開発における小規模化、オープン化の流れの中で生まれてきたものであり、
年々肥大化する＆昔クローズド今もクローズドなゲーム開発には馴染まない、馴染むわけがない。
305:仕様書無しさん
07/02/19 07:48:10
GUI のテストが難しいから人手に頼るのはしょうがないとして、
テスト可能な部品について、部分的にテストをそろえていくという
方法は問題ないかな？
306:仕様書無しさん
07/02/19 07:50:14
>>305
意味がわからない。
全体をどうとらえてるとかそういう大まかなところから定義が見えない。
307:仕様書無しさん
07/02/19 07:55:32
>>306
意味がわからない。
全体をとらえることの意味がわからない。
308:仕様書無しさん
07/02/19 09:18:57
おい、ちょっと聞くが>>299 はネタだよな？
なんで普通に議論が始まってるんだ？
309:仕様書無しさん
07/02/19 09:51:17
テストしたい関数・クラスにマークを付けておけば
テスト項目がIDEに表示されてボタン一つでテスト可能になるようなツールが欲しいね。
ゲームパッドの入力の自動化程度があれば、それなりに使えるもんになるんじゃなかろうか。
画面キャプっての各種自動化とかは、考えるだけでも卒倒しそうだからとりあえず後回しでいいんじゃないか。
310:仕様書無しさん
07/02/19 10:06:22
>>309
ゲームパッドの入力の自動化とかがあれば、とかいう発想おかしくね？
簡単につくれるだろ。そんなものぐらいは。
311:仕様書無しさん
07/02/19 11:49:32
>>308
俺もそうだが、きっと君もプログラマに向いてないと思うんだ。
312:仕様書無しさん
07/02/19 12:31:57
>>310
ゲームに必要な「入力の自動化」ってのは
この場面で敵をジャンプしながらオプションボタンを押すとバグる
とか
敵が沢山いる位置で必殺技を使う
とか
攻撃エフェクトが消えないうちに次の敵に攻撃
とか、そういうのだろ。
単純に入力ON/OFFだけじゃテスト駆動の意味がない。
でもこういうテストデータを作る労力が割に合わない。
なのでTDDが導入される局面は限られると思う。
313:仕様書無しさん
07/02/19 12:36:45
>>312
テストデータを自動的に作るプログラムを作るっていうのはどうよ？
組み合わせ考え総当りでチェックさせるようなやつ
314:仕様書無しさん
07/02/19 12:42:34
どうやって自動で作るんだ？
例えばアクションゲームで「一定時間的から逃げ回れ」とか「敵にやられて吹っ飛びながら無敵アイテムを取れ」
なんていうデータを”自動で”作らせる方法は俺には思いつかないぞ。
ボタン連打とかコマンド入力程度なら自動作成も可能だけど、それじゃTDDとしてはあんまり意味がないでしょって話。
315:仕様書無しさん
07/02/19 13:22:56
>>314
ごめ。シューティングみたいなやつだったら、データを事前に作るのは無理だわ。
てっきり開始するときのゲームの状態と乱数の種仕込んで、同じ動作をするような環境の物
ならなんとかなるかもね。
シューティングとか開発したことないけど、自機をあたかも人が操作しているようなコードってつくれないの？
316:仕様書無しさん
07/02/19 15:36:28
>267の発言で気になったんだが、
ポリゴン描画はあらかじめすべてのポリゴンを視点から遠い順にならびかえて、
数値比較しないでぜんぶ描画するのが一般的なやりかたなのか？
Ｚバッファってやつは使わないほうがいいのか？
317:仕様書無しさん
07/02/19 15:50:38
Zバッファ使おうが半透明オブジェクトはソートが必要。
タスクの段階でソートしてもいいし、ソート可能な描画コマンドを生成してそれをソートしてもいい。
処理の順序に縛りが無くなる分後者のほうが自由度は高いが、その分仕掛けが大変なので
ケースバイケース。
318:316
07/02/19 16:13:17
ありがとう。
半透明はたしかに、透明じゃないものを描いてからにしないといけないね。
でそれって、
・半透明なものだけ抜き出して後から描画するようにして、
基本的にはならびかえなしでＺバッファに頼る
・あらゆるポリゴンを並び替えて、描画順によって奥・手前を書き分けて
Ｚバッファは数枚のポリゴンが交差してる時などを正確に描画するための手段として使う
だとどっちがいいのかな？
もちろんケースバイケースだとは思うけど、基本的なスタンスとしてさ。
書き込みが細かくて、全体的なポリゴン数が多い作品ほど、
並び替えよりＺバッファにたよるほうがいいんだよね？
319:仕様書無しさん
07/02/19 16:38:12
半透明じゃないオブジェクトは、Zバッファ使った上で手前のオブジェクトから描画、が基本なんじゃないの？
320:仕様書無しさん
07/02/19 16:40:54
基本はZバッファ。半透明オブジェクトのみをソートする。
フィルの節約のために手前から描画する場合もあるがその質問から察するに当分考えないでよいと思う。
321:仕様書無しさん
07/02/19 22:17:54
はじめまして。プログラマの方に質問です。
自分は、経験１年のまだまだ初心者です。
今日、会社のサーバーがちょっとおかしくなってしまいました。
それで、サーバーに一番詳しい人は今日休みを取っていました。
２番目に詳しそうな人が１人で直す作業をしていたのですが、
分からないことがあったらしく「休みを取っている１番詳しい人」に電話をかけながら作業していました。
会社には、１０人いました。ベテラン３人と、素人７人です。
そのとき自分も手伝いたかったのですが、言い出せませんでした。
足手まといになりそうだから。サーバのことはハードを見たことしかなかったから。
なにが何の装置なのか分からないから。
そんな時、どうすればよかったと思いますか？あなたが「１人で作業していた２番目に詳しい人」
だったとして、どうしてほしいですか？
322:仕様書無しさん
07/02/19 22:26:02
時と場合による
マジで忙しくて余裕がないときに「あのぉー・・・えっとぉー・・・手伝いまs(ry」
とか言われたらうるせー黙って待ってろハゲ！って思うかもしれん
自分の仕事も終わってないクセに手伝うだのなんだの言い出したら
なめとんのかこのハゲ！って思うかもしれん
全然サーバに関する知識がなくても
おまえさんの手が完全に空いて何もすることが無くて
担当者に考える余裕があるならば
このハゲに雑用を頼もう！と思うかもしれんな
ま空気嫁ってことです
あと担当者の性格も
323:仕様書無しさん
07/02/19 22:43:00
どうやって解決するかは、すごく勉強になるチャンス。
プログラムなんかでは、バグが出ました原因不明ですって時に、どうやって出来る人は原因箇所を絞っていくのか。
324:仕様書無しさん
07/02/19 23:06:11
>>321
ある程度難局を脱し、一番詳しい人のサポートが不要になったころを見計らってその人の後方5mに忍び寄る。
そして、しばらく作業の様子を覗き込んだあと、羨望の眼差しとともに
「サーバー解るなんてスゲーよ。流石だ」と小声で呟く。（ただし聞こえるように）
あとは、次の日から２～３日ぐらい、その人の事を尊敬の眼差しで見てあげれば、たいがいのPGは気分が良くなると思う。
健闘を祈るｗ
325:仕様書無しさん
07/02/19 23:17:19
>321
サーバーのことわからないなら、手伝わない方がいいんじゃない？
データベースもそうだけど、迂闊に手を出すと取り返しがつかないことになるしｗ
大体終わったあとに「今度手伝いたいのでいい資料あったら教えていただけませんか？」っていうのがいいとおもうよ。
326:仕様書無しさん
07/02/19 23:24:11
>318
>319 のが基本。
不透明を手前から書いて、その後、半透明を描画するのが一番早いよ
（オクルージョンポリゴンはピクセルシェーダーやラスタライズ処理が行われないから）
次世代機だと一番早いのはＺプレパスでＺバッファだけ先に描画して・・・かな。
カラーにまわす分のＲＰＵやＧＰＵもＺ描画にまわせるから。
・・・ものによるけどｗ
327:仕様書無しさん
07/02/20 00:19:09
描画オブジェクトの数が多い半透明以外は完全ソートをしようなどと考えると重くなったりして良くないので軽くソートをすれば良いよ。
バブルソートあたりで、完全ソートまではせずに1回2回程度なでて近くにいるオブジェクトを浮き上がらせればいい。
ちなみに自分の好みはオブジェクトの座標の計算時に、ついでに三次か四次程度のモーメント程度までのZの分布に関する統計と予想表示面積の統計を取っておいて、
スクリーン上に7割り程度占めるであろう最前面オブジェクトを推定して、表示リストを一回だけなでて浮き上がらせる方法。
>>312-315
もっと簡単なテストからやったほうが良いと思う、操作系や具体的な表示物のテストは駄目押しですよ。
それに、満たすべき仕様を列挙する事による、やるべきことの明確化や、設計ミスを防ぐ以外にもゲームならではの利点がある。
それはテストコードにより、遅くて安全なコードから際どく凶暴な高速化を図りたい時に命綱として機能する所、とても重要。
これ無しだと、ある程度本格的利用が始まったコードに対して、高速化が困難もしくは、製作ラインに大迷惑をかけての高速化しかできなくなる。
328:316
07/02/20 01:39:59
>319,320,326
ありがとう！
未熟な俺には>326の用語が初めて聞いたのでわかんないが。
文面から察して、オクルージョンポリゴンってのは他のポリゴンの裏にかくれてて、
最終的に画面に表示されないポリゴンのことかな？
で、あらかじめ並び替えで手前のポリゴンから描画するようにしといて、
各ポリゴンを描画するときに「このポリゴンは完全に隠れてるか、
一部分だけでも描画するべきか」を判定して、
完全に隠れちゃってるポリゴンであれば
光源による色変化の計算とかをはぶいちゃっていいってことかな。
329:仕様書無しさん
07/02/20 01:40:06
>>314
入力録画・再生ができれば、あとは1度手で再現すれば
何度でも見れるようになるですよ。
そこまで作ったことはないけどもｗ
330:仕様書無しさん
07/02/20 02:00:19
>>321
その人が見ていない時にこっそりと電源を落としてあげるといい。
PCの場合リセットするのもアリだ。
331:仕様書無しさん
07/02/20 02:04:51
______________
／ _____________＼へ
／ ／ ＼.＼
／ ／ .＼.＼
| ／ 売国連 会長 ヽ .|
|ﾉﾉ | / フフフ、正社員は無能で、低賃金
ヽﾉ ,,,,,,,,,,,,,,丶冫_ .,,,,,,,,, /ヽ | これから全国、使い捨て ピンハネ派遣社員の時代 ニートはいらね
/^ヽ- √￣￣ヽ^ ./￣￣ ヽ | | もちろん、賃金高い日本人は雇わない 中国、朝鮮人がお得
|∂/ . | -=･=- | | -=･=- .| く/ お金の為、自民党経団連により、日本を売り飛ばすのが目的
ヽ/ ヽ______丿 .ヽ ______. ﾉ ヽ
./ )（ ）( |
| ^ ||^ | ＿＿
| ノ-==-ヽ | ／ヽ ヽ― ､
丶 ／ / | | ＼
＿＿＿__ヽ ヽ / ／＿＿＿＿＿ / | | ヽ
, -‐´ ／ ヽ ＿-----＿ ／ ＼ / / ヽ
（, ／ ￣￣ ＼ / / 御手洗 ｜＼
` ‐- ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿／＿＿＿＿＿＿＿＿＿） ）
＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿／
政治献金（≒合法わいろ）外資規制撤廃を、経団連次期会長(キヤノン御手洗)が意向
ｽﾚﾘﾝｸ(newsplus板)
外資企業の献金緩和案了承 自民、今国会で改正
ｽﾚﾘﾝｸ(korea板)
【経済財政諮問会議とは】
政界や経団連や天下り官僚トップが日本の税金を勝手に決める巨大談合犯罪会場
↓危険なメンバー
URLﾘﾝｸ(www.keizai-shimon.go.jp)
332:仕様書無しさん
07/02/20 02:09:35
ゲーム屋なんか最初から底辺に近いからあんま関係ないかと。
333:仕様書無しさん
07/02/20 02:34:48
おい右を見ろ→ 下を見ろ↓
下を見ろ↓ ←左を見ろ
右を見ろ→ 下を見ろ↓
右を見ろ→ 下を見ろ↓
↓下を見ろ ←左を見ろ ↑上を見ろ ←左を見ろ
右を見ろ→ 下を見ろ↓
↑上を見ろ ←左を見ろ
↑上を見ろ ←左を見ろ
右を見ろ→ 下を見ろ↓
下を見ろ↓ ←左を見ろ
右を見ろ→ 下を見ろ↓
右を見ろ→ 下を見ろ↓
↓下を見ろ ←左を見ろ ↑上を見ろ ←左を見ろ
右を見ろ→ 下を見ろ↓
↑上を見ろ ←左を見ろ
↑上を見ろ ←左を見ろ
ばーか
334:仕様書無しさん
07/02/20 18:01:27
>>326
オクルージョンポリゴンって一般的？
多分全部隠れてるオブジェのことだとも思うんだけど
ググッても出てこない…
335:仕様書無しさん
07/02/20 19:14:59
一見、陰面消去とかラスタライズあたりの話かなぁと思ったら、そうでもないらすぃ。
336:321
07/02/20 21:05:02
>>322
>>323
>>324
>>325
返事ありがとうございます！
明日、自分のしていることが片付きそうなので、そしたらサーバの説明書見せてください！
ってお願いしてみます。
やっぱ人に相談するといいですねｗ
337:326
07/02/20 22:56:33
>334
いや、ぜんぜんｗ
頂点計算後にほかのポリゴンの裏に回ってるポリゴンっていうのが面倒だったからオクルージョン処理されたポリゴンって意味で使いました。
ニュアンスで伝わるかなぁと。
すいません orz
338:仕様書無しさん
07/02/21 00:44:30
URLﾘﾝｸ(rara.jp)
BBC TVによるXbox360の異常な故障率の高さの調査報告
・1年の保証期間を過ぎた途端に壊れる。
・壊れたときの電源のランプは「ring of death」といわれ恐れられている。
1年を過ぎてから発生し始める「ring of death」現象は
保証期間対象外であり、日本にいる約30万人の360ユーザーにとっても気になる話だ。
ゲームハードの故障率の高さが取材されるのは異例。
オーストラリアのSmarthouseにも360の苦情殺到
業界内の声を聞こうと接触したGameProの編集者も平均以上の故障率を
実感しているとのこと、MSのコメントは得られなかったがさらに追求する。
360のゲームプレイ時の騒音は酷く、55dB以上の音が出る
50dBを超えると、はっきりって“うるさい”デバイスということなる
Xboxの初期のコードネームは「Project Midway」だった。
日本への反攻(太平洋戦争ではミッドウエイ海戦が日本への反攻の転機だった)
という意味が込められている。
339:仕様書無しさん
07/02/21 00:49:42
よく使われるのはオクルージョンカリング(occlusion culling)。
日本語だとオクルージョンは「遮蔽」って訳されることが多い。
>>316
描画周りやってる(興味がある)ならGPU Gemsの2冊くらいは目を通して
おいた方がいいと思われ。
日本語版もあるし、敷居は低いでしょ。
340:仕様書無しさん
07/02/21 01:02:50
>339
GPU Gemsについて詳しく！
341:仕様書無しさん
07/02/21 01:17:06
>340
URLﾘﾝｸ(www.gogo3d.com)
URLﾘﾝｸ(www.gogo3d.com)
ここで少し立ち読みできる。
NVIDIAが主体になって、グラフィックス系の処理について解説が書いてある本。
シェーダを使った実装例が多い。Xbox360、PS3で開発するなら用意に応用可。
微妙な誤植があったりするから、原著の正誤表なんかを見ることがたまに必要かもしれん。
ちと高いが、仕事で使うなら投資して損はない。給料的に厳しいなら会社に出させるが吉。
342:仕様書無しさん
07/02/21 01:36:45
ほにゃららGEMS高すぎ･･･
一章ごとに文庫版で出してくれないかなぁ。
一冊500円くらいで全100巻までなら頑張って買うぞｗ
343:仕様書無しさん
07/02/21 01:55:11
5マンだせば3冊買えるだろ。
344:仕様書無しさん
07/02/21 01:59:40
GEMS1～4とGPU GEMS1～2だからなぁ。
総額7万以上はきついよ
345:仕様書無しさん
07/02/21 02:22:42
買って読んだら売れ。中身は暗記するか身につけろ。
346:仕様書無しさん
07/02/21 06:00:47
プログラマ志望で作品持ち込みする人って、やっぱりC言語系統がほとんどですか？
DelphiやJavaはいませんかね？
347:仕様書無しさん
07/02/21 06:19:10
うちはC++じゃ無いと意味が無いし、酷いと逆効果。
348:仕様書無しさん
07/02/21 06:38:12
割とメジャーなゲームでDelphiやJavaを使用している例は見たことないな
ツールやサーバを作るにはいいんだけど、メインではない
349:仕様書無しさん
07/02/21 07:09:56
>>347
>>348
やっぱそうですか。
C終わったら、C++がんばります・・・
350:仕様書無しさん
07/02/21 07:39:42
>>342
創刊号はバインダー付きで３９８円？
351:仕様書無しさん
07/02/21 07:51:55
ゲーム業界のみなさんご苦労様です
お蔭様で快適にゲームをしております
みなさんどれくらいC++の本読んでるんですか？
やはりゲーム業界では結構本を読まないと通用しませんか？
352:仕様書無しさん
07/02/21 08:06:09
本読んでもダメな奴はダメ
353:仕様書無しさん
07/02/21 08:08:54
貧乏学生だったけど、宇治社中とか今給黎さんとか
無料でノウハウ提供してくれる人が大勢居る業界だから何とかなった。
354:仕様書無しさん
07/02/21 11:18:57
GEMSは辞書みたいなもので、そういえばあったなぁ～って軽く概要を見る本だったような。。
だから、ふと知りたくなった時に持ってなくちゃ意味ﾅｻｽｗ
355:仕様書無しさん
07/02/21 11:51:09
Game Programing GEMSはテクニック紹介集みたいなものだから
実際に自作のゲームに組み込むとなると結構大変だけどな
356:仕様書無しさん
07/02/21 11:56:16
宇治社中ってもう閉鎖したよな
Fried Chickenもないよな
357:仕様書無しさん
07/02/21 13:09:54
>>344
5の日本語版まだだったっけ？
英語版は6まで出てるけど
358:仕様書無しさん
07/02/21 15:56:30
昔よく見てたってーと、こんなところかな。
ほとんど無くなってるけど。。。
宇治社中
FrideChickenPro
こってり屋
kaneko's Software Page
shi3z氏のとこ
狩野氏のとこ
なんだかんだで3D野郎会がらみのページにはおせわになった。
359:仕様書無しさん
07/02/21 16:01:36
URLﾘﾝｸ(www.gff.jp)
これに行く奴いるの?
360:仕様書無しさん
07/02/21 18:23:09
ゲームで使うファイルを圧縮して一まとめにしてそれを読み込むようにする場合、
展開部分を自分で作る？それともzlibとかの既存のライブラリ使う？
ちなみに自分は展開部分を自作してやってるんだが、既存ライブラリ使ったほうが色々できそうな気がするんだが・・・
361:仕様書無しさん
07/02/21 18:35:46
既存のライブラリってライセンス的に問題は無いの？
発売後にGPL違反だとかで騒がれるのが怖いんですが。
たとえばzlibの場合、以下のような制限があるんだけど。
1. 本ソフトウェアの出自について虚偽の表示をしてはなりません。あなたがオリジナルのソフトウェアを作成したと主張してはなりません。 あなたが本ソフトウェアを製品内で使用する場合、製品の文書に謝辞を入れていただければ幸いですが、必須ではありません。
2. ソースを変更した場合は、そのことを明示しなければなりません。オリジナルのソフトウェアであるという虚偽の表示をしてはなりません。
3. ソースの頒布物から、この表示を削除したり、表示の内容を変更したりしてはなりません。
疑問
A.出自の表示ってデータ中のテキストを突っ込んでおけば大丈夫？
B.ゲームにあわせて変更を加えた場合はどうなるの？
C.ゲームではバイナリのみ公開するわけだけど、ソースを頒布しなければこの制約に従う必要は無い？
などなど・・・この辺がクリアにならないんであれば色々と面倒なので
自分書いたしょっぼいランレングス圧縮でも使っててる方がましかなと。
362:仕様書無しさん
07/02/21 20:05:10
>>361
Ａって嘘を吐かなければいいよって話じゃん。
どこに出自の表示が必須って書いてあるの？
ＢとＣってソースを配る場合じゃね？
363:仕様書無しさん
07/02/21 20:36:15
てことはzlibのソースをそのまま（もしくは改変して）自分のコードに組み込んだ場合、
ソースを公開しなければ（普通しないが）ライセンスに関する表記は不要ってことか。
それなら安心して使えるな。
364:仕様書無しさん
07/02/21 20:50:39
2. Altered source versions must be plainly marked as such,
and must not be misrepresented as being the original software.
原文は、「ソースを変更した場合」じゃなくて、「変更されたソースの
バージョンは、変更されたということを明らかにすべき」という
意味なのよね。微妙に訳が違っているわけだが。
つーかつまらんね。
365:仕様書無しさん
07/02/21 23:17:01
圧縮展開は自分で起こすかな、著作権、特許、GPLといろんなモンが集っているから
366:仕様書無しさん
07/02/21 23:35:38
>>351
>みなさんどれくらいC++の本読んでるんですか？
横積みで１M位かな。
ただ、現場で経験してからじゃないと、知識は脳内素通りだとおもうw
367:仕様書無しさん
07/02/22 02:23:16
使わないで覚えられるやつはいないだろうな。聞いたことも見たこともない。
使ってるやつといっしょに仕事すればすぐ身につくよ。
368:仕様書無しさん
07/02/22 02:58:44
>>359
んなものに参加するような著名人はにちゃんには居ない
369:仕様書無しさん
07/02/22 10:11:26
おっと、遠藤ﾀﾝの悪口はそこまでだ。
370:仕様書無しさん
07/02/22 12:12:48
講演量メチャメチャいいらしいぜ。
371:仕様書無しさん
07/02/22 12:53:09
自分で書いて特許関係まで気を配る羽目になるより
有り物で済ます方がいいなぁ。
372:仕様書無しさん
07/02/23 22:06:02
イリュージョンの新作キタ
373:仕様書無しさん
07/02/24 14:48:04
このサイトは参考になりますか？
URLﾘﾝｸ(www.plustarnet.com)
374:仕様書無しさん
07/02/24 14:50:45
なりません
375:仕様書無しさん
07/02/24 14:52:57
ならないのかよ・・・orz
376:仕様書無しさん
07/02/24 16:57:31
>>373
既知の記事しかない、って印象は受けた
377:仕様書無しさん
07/02/24 17:01:06
>>373はゲームプログラマにとって参考になりますか？
って意味ではなく、ゲームプログラマになるための勉強として参考になりますか？
って意味で聞いたんじゃない？
378:仕様書無しさん
07/02/24 17:40:35
猫でもわかる～で勉強してWindowsプログラマになれますか？って聞いてるようなものだな。
379:仕様書無しさん
07/02/24 18:04:16
初心者の通過点としてはいいのではないか
この程度は出来なきゃ話にならないのだし
勿論これで通用すると勘違いされると困りものだけど
380:仕様書無しさん
07/02/24 20:40:50
あー♪私の、こーいわー♪
南のー風に乗ってはしーるわー♪
381:仕様書無しさん
07/02/24 20:53:00
>>377の意味で聞きたいなら、
「いいんじゃない。」と。
ただ、このサイトしかみないとか、学校の教科書的なものを求めてるのなら、
きっとこのサイトの作者の意図とも違うだろうからそれは止めておけといいたい。
義務教育式の１つの教科書を学び倒せ的なものは社会に出たら通用しない。
色んな考えがあって一つの物事を色んな角度から見れる能力を養わなければならない。
チャチな技術なんかよりそっちを身に付けることの方が実は大事。
「このサイトいいですか？」の問いに「いいんじゃない」と答えることのそこが一番心配。
382:仕様書無しさん
07/02/24 22:04:56
左のＣ言語講座良くね？C++少ないけど。JAVAとアセンブラもあると良いかも。2004.06.14で更新終わってるけど。
ランダムがrand()だけなのとコリジョンが二次元だけなのがちと心配。
Ｘファイル読み込みってあれだとロボット止まりだけど良いのだろうか。動的コリジョン生成とかあれだけでいけるかな。
インストーラー作成と動画再生とMIDIと簡単な符号化とハッシュと
マルチスレッドとwinsockと通信エラー検出とリアルタイムオンラインなら簡単なクラ側予測処理と
テンプレートクラスと簡単な物理演算とクォータニオンと色々補完とボーンアニメーションと
ピクセルシェーダー周辺の基礎テクあたりなら、あのノリでさくさくっと説明したら良いのに。高速化も少し欲しいかも。
Windowsで音はあんまやることなくなっちゃったけどリングバッファとフーリエくらいは実装してみると楽しい。
どんな仕事がくるかわからないし8x8でパレットなスプライト処理やアセンブラもやっておいた方がいいかも。
OSとの同期あたりをほっとくと「そんな無茶な操作をしたユーザーのせい系」の韓国ゲームが出来たりする。
鯖担ならスクリプトとかPerlとかJAVA○○とかSQLとか監視ソフトや社内のデータ管理の仕方くらい知ってないと、
開発機の自作は当然出来て欲しい（仕事でまずやらないけど）。あとは報告連絡相談が出来れば適当に使ってくれるよ。
オレはやらないけど。
383:仕様書無しさん
07/02/24 22:42:11
夕方にピンサロに行ったが、もう感覚を忘れてしまった。勿体無い。
384:仕様書無しさん
07/02/25 00:29:05
ゲームソフトを売っているわけで、ペットボトル入りの汗を売っているわけじゃないよね。
URLﾘﾝｸ(gamenokasabuta.blog86.fc2.com)
385:仕様書無しさん
07/02/25 00:44:57
心血注いでも駄作は駄作、鼻歌交じりでも傑作は傑作ってやつだな。
こんな当たり前のことをこんな長文で語られてもなぁ、お前の長文がそのペットボトルの汗だよ（汗
386:仕様書無しさん
07/02/25 00:53:16
>>385
お前さんが書いたその文も納得できる人間と出来ない人間がいる。
出来ない人間には>>384のリンク先のように長々と説明しないと納得できない。
まぁ、それでも納得できない人間もいるがな。
387:仕様書無しさん
07/02/25 01:02:13
つーかわざわざ開く気になるほうがすごい
タイトルからして読む気が全く起こらん
388:仕様書無しさん
07/02/25 02:30:50
人を育てようとすると給料が出なくなるんですが。
389:仕様書無しさん
07/02/25 11:35:59
そこの会社に長く勤めたいなら育てた方がいいが、いずれ辞める予定があるなら、しんどいだけだから必要なし。
390:仕様書無しさん
07/02/25 13:50:30
人を育てる気がなく、よく人が入れ替わる会社のくせに
「社風」とか「企業文化」とか「ウチのやり方」があったりする不思議。
391:仕様書無しさん
07/02/25 16:41:58
学校なんかもそうだな。
先生も生徒もすぐ入れ替わるのに校風なんやらがある。
392:仕様書無しさん
07/02/25 17:10:49
>>391
学校はまだマシだろ、中高なら3年も通い続けるんだから。
393:仕様書無しさん
07/02/25 17:40:51
（ ＾ω＾）たまの休日はプログラム組んでストレス発散するお
394:仕様書無しさん
07/02/25 19:44:23
.,､- ' `´ ￣￣` ''‐ ､
,r'´ .`ヽ､
／. -t‐'''l´ .`l'‐t､ .＼
/´. 'lliiiill lliiii!. ヽ,
./ ＿_ i,_,ﾉ .i, ,! ', な、なんなんですか…？
{ (´＿_,） ,..., ~ (`ヽ l
.l - ､..,_ .l_ i ,､-"'-､ l ここ、どこですか…？
.l `i .l,_ソ f´ .l
', ノ .l, ,' どうして私、こんなとこに貼られてるんですか…？
'､ ,.､-' .,'
'i､ ー一 '´ /':,
l ヽ, ノ }
.l `‐､,_ ._,.-.' ,'
l `‐- ､,........,..､-‐'` /
.＼_ ﾉ l ,/
｀'''ー‐ '´ ヽ､ _, -'
￣￣
395:仕様書無しさん
07/02/26 01:14:33
全員フリーにしてプロジェクトごとに人集めればいいのに。
そしたら糞企画には誰も集まらなくて自然と淘汰されるはず。
新人は育たないけどな。
396:仕様書無しさん
07/02/26 01:28:35
そもそも、金を握っている奴が糞企画を推進する奴のわけだが
397:仕様書無しさん
07/02/26 02:24:44
PGも金を持つと独立して糞企画会社になるけどな
398:仕様書無しさん
07/02/26 03:16:30
>>395
他の業界では、その考えに取り憑かれた人間が続出し
結果として派遣会社まるもうけ。
399:仕様書無しさん
07/02/26 06:39:52
>全員フリーにしてプロジェクトごとに人集めればいいのに。
どこにも属さずひたすら社内環境整備ばっかりしてる奴がうまくいく法則
400:仕様書無しさん
07/02/26 12:22:33
結局は需要と供給のバランスが取れればいいわけで
普通の正社員なら敬遠するようなつまんねー仕事にも
それなりにやりたいと手を上げる奴はいるんだろうな。
経歴やスキルに自信の無い奴→とりあえず移植で経験値稼ぎ
楽してお金がもらえれば良いって奴→脳トレやパズルなんかのお手軽系
新技術に触れたい奴、３Ｄバリバリな奴→次世代機でガチ開発
好きなジャンルばっかり選ぶもよし、なんでもできる奴目指していろんなゲームに手を出すもよし。
とりあえずWindowsプログラマならツール開発からゲ業界狙うもよし。
業界脱出の為にスキル身に付けたい奴はツールやＷｅｂやサーバーなんかの仕事を選べばよし。
会社の命令でイヤイヤやるよりよっぽど幸せな開発ライフを送れると思うんだが。
401:仕様書無しさん
07/02/26 12:44:43
キャノンに続きタイガー魔法瓶も偽装請負
ｽﾚﾘﾝｸ(news板)
402:仕様書無しさん
07/02/26 13:04:32
>>398
>結果として派遣会社まるもうけ。
別に良いんじゃね？
自分で営業かけて色んな会社に営業かけて周ったり
仕事でトラぶって途中で相手が金を払い渋ったりとか
納期が延びたときの金額交渉なんかの手間って結構大変だぜ。
そういうトラブルの時に会社VS個人じゃなくて会社VS会社で
キッチリ話つけてくれるんならマージンぐらいくれてやってもいいぞ。
403:仕様書無しさん
07/02/26 20:53:11
派遣の利点はいらなくなったらすぐ切れることだろ。アホかと。
まあゲーム会社は安定してないから派遣使うメリットはほとんどないけどなｗ
404:仕様書無しさん
07/02/26 21:00:34
おまいらは派遣ごときでも事足りるような存在なのか
405:仕様書無しさん
07/02/26 21:14:05
殆どのゲームプログラマーなんて大した技術持ってないし、派遣で十分だろ。
406:仕様書無しさん
07/02/26 21:53:32
派遣入れたいほどの規模の仕事はあんまないな。
407:仕様書無しさん
07/02/26 22:26:13
その前に派遣は根性無しばかりで単純作業以外には使えんだろ。
ゲより楽な仕事なら山ほどあるしな。
408:仕様書無しさん
07/02/26 22:48:40
ノウハウが溜まらないゲーム業界じゃ派遣成り立たないんじゃないか？
409:仕様書無しさん
07/02/26 23:11:58
ノウハウが個人にしか溜まらないからこそ修羅場くぐった派遣の方がいいんじゃない？
まぁそういう奴らは派遣じゃなくてフリーランスって言うんだろうけど。
腕がある奴の多くは仲間と会社起こすか、フリーになるか。
どっちにしろ、一つの会社に収まる連中じゃないよな。
410:仕様書無しさん
07/02/26 23:21:53
>>402
客とプログラマの間に入らず何もしないくせに、ピンハネだけはする請負会社にいたことがあるぞ俺。
411:仕様書無しさん
07/02/27 00:38:53
>>402
大人判断。正直なところゲーム開発のソフト屋なんて、対人とか苦手だし、
積極的に自分の売り込みできる奴すくないしね。
フリーで契約なんてある程度の規模になった会社はリスク多すぎでやらん罠。
ゲームの開発で派遣使うなんて、携帯ゲームぐらいしかないんじゃねーのか？
412:仕様書無しさん
07/02/27 07:02:59
>>411
それは現実とちがうなぁｗ
413:仕様書無しさん
07/02/27 09:11:23
大手なら、ある程度売上が見込めるタイトル（続編もの）の開発になると
労働者に最大還元したいから税控除目的でフリーになった方が良いよとオススメするでしょ。
月一ペースの携帯ゲームで、
タイトルの度に外部からプログラマー・デザイナー・音楽・プランナーを1人ずつ集める方が大変だと思う。
外部会社とのやりとりや諸々の交渉処理や契約処理やらを小刻みにこなさないといけないだろうし。
それに人間波があるし、調子の悪い時の数ヶ月を選んじゃったら、残念でした、なんて嫌だし（花粉の時期に募集減りそうだし）。
そもそも規格なんて無い一社一法の慣習世界で数ヶ月で完成まで持っていけるのかなぁとか。
414:仕様書無しさん
07/02/27 10:32:01
携帯どころか代表作・・・
415:仕様書無しさん
07/02/27 10:38:00
何を言いたいのかよくわからんが、フリーに懐疑的なのか？
>大手なら、ある程度売上が見込めるタイトル（続編もの）の開発になると
>労働者に最大還元したいから税控除目的でフリーになった方が良いよとオススメするでしょ。
なわきゃねーだろｗ
タテマエはそう言うかもしれんけど、本音は正社員より外注の方が経費を節減できるし、好きな時に切れるから。
>タイトルの度に外部からプログラマー・デザイナー・音楽・プランナーを1人ずつ集める方が大変だと思う。
請負と委託という契約方式の違いがあってだね…詳細はめんどくさいからぐぐれ。
ようは委託契約にして期間で雇えば問題なし。
>それに人間波があるし、調子の悪い時の数ヶ月を選んじゃったら、残念でした、なんて嫌だし（花粉の時期に募集減りそうだし）。
>そもそも規格なんて無い一社一法の慣習世界で数ヶ月で完成まで持っていけるのかなぁとか。
なに甘えてんだ？調子が悪ければ仕事しなくていいって考える方が非常識だろ。
社員でいるとそういう甘えが出るけど、フリーはその辺死活問題だからキッチリやるよ。
それができない奴は淘汰されるだけだ。
やれと言われて、出来ます！って請けたんなら、やれ。自分ができないんなら代役を立てろ。
それが契約を交わすってことだろ？
花粉症だから仕事が進みませんてｗ子供かよｗｗｗｗ
ようはお前らのいる会社の社長が仕事を取ってくるのと同じやり方で個人が働くってだけ。
ぶっちゃけスケールの違いにすぎん。
ある程度仕事の流れが見えてきた奴は、一度はフリーになるべきだと思うけどね。
416:仕様書無しさん
07/02/27 11:19:39
URLﾘﾝｸ(gigazine.net)
これでようやく64bitOSの普及か
これでPCゲーが再び流行るのかな
417:仕様書無しさん
07/02/27 11:39:10
長
418:仕様書無しさん
07/02/27 11:44:10
野
419:仕様書無しさん
07/02/27 13:55:14
長いって言いたかったんじゃーーーーーー
野って何？野って。
420:仕様書無しさん
07/02/27 14:00:14
縦読み続けるのかよ
421:仕様書無しさん
07/02/27 14:14:23
プログラムするのにはVC++使ってるんですか？
422:仕様書無しさん
07/02/27 14:44:56
VCdeOK
423:仕様書無しさん
07/02/27 15:22:10
>>416
64bit64bit言ってる人か。
さあどうでしょうね？あんまり流行る気がしないなあ。
ユーザーがPCとコンシューマに分散するってのが正しい気がする。
424:仕様書無しさん
07/02/27 16:07:02
>>416
URL間違えた？
俺にはどうしても業務用160GBフラッシュメモリの記事にしか見えないんだけど
425:仕様書無しさん
07/02/27 16:38:47
ゲーム業界の派遣の現状↓
安く上げようと数合わせに入れても、
能力低すぎてソースコードすら読めない始末。
最低レベルとしてゲー専新卒レベルを雇うと、
本物のゲー専新卒が2～3人雇える。
やる気があるし、残業付き合わせられるしね。
普通に使えるレベル、一般中途レベルはそれ以上コストが。
使ったら完全に赤字。
本当にヤバい時に3ヶ月だけとか、そんな次元。
ゲーム業界に派遣が居ないのは、こんなところが理由。
派遣のレベル低いんじゃなくて、レベルとコストが全く見合わないだけ。
426:仕様書無しさん
07/02/27 19:26:56
↓のとこから縦読みしたが意味がわからない
427:仕様書無しさん
07/02/27 19:46:22
携帯ゲームは１タイトルごとにやるんじゃなくて
似たようなタイトルをチームで１年でトータルでいくつって形のが多いと思うぞ
428:仕様書無しさん
07/02/27 20:04:15
派遣なんて恋のようなもの
429:仕様書無しさん
07/02/27 21:10:36
ゲーセン卒業したばかりの香具師を月45万とか要求するからなぁ＞派遣会社
この間面談した香具師は「プログラム組めません！」とか笑いながらのたまうし。
まぁフリーは別として、派遣はカスしかいないよ。マジで。
430:仕様書無しさん
07/02/27 21:19:32
大学やら専門学校の授業レベルの研修を受けさせた後、即派遣するからな。
本当に派遣はカスばかり。
431:仕様書無しさん
07/02/27 21:38:32
＜「プログラム組めません！」とか笑いながらのたまうし
それって一体どんな仕事をするつもりで面接にきたの？
グラフィックとかサウンドやりたいから
プログラムは全くしらなくてもいいってつもりだったのかな
432:仕様書無しさん
07/02/27 21:43:51
企画じゃないか
433:仕様書無しさん
07/02/27 21:53:23
いやプログラマー。
一緒に来たコーディネータも唖然としてたｗ
434:仕様書無しさん
07/02/27 21:55:07
すごすぎるｗｗ
435:仕様書無しさん
07/02/27 22:52:17
熱意だけは認めるよ！熱意だけはね
436:仕様書無しさん
07/02/27 23:22:27
コーディネーターは何をやっていたのだろう。
437:仕様書無しさん
07/02/27 23:26:44
移植コーディネーター
438:仕様書無しさん
07/02/28 02:16:36
チンコ怪我したorz
のも治ってきたのだが、なんか漫画に出てくるような顔に傷の跡がある男みたいになってる。
顔じゃなくてチンコだが。
439:仕様書無しさん
07/02/28 02:50:41
>>34
>>39
>>99
>>302
>>383
>>438
変態さん乙ｗ
440:仕様書無しさん
07/02/28 03:38:51
>>34でも傷を負ってた自分にﾜﾗﾀｗ
まぁなんつーか、ちょっと恥ずかしいね♪
441:仕様書無しさん
07/02/28 04:29:44
実際にゲームプログラマーになっても本とか買って言語の勉強するのでしょうか？
442:仕様書無しさん
07/02/28 04:54:21
全然読まない人もいたりするんだけど、７割方は読んでる。
443:仕様書無しさん
07/02/28 05:43:52
>>441
言語で言えば、Java,Cやアセンブラ系の人は読まないね。
C++系で能力高い人は、大抵いっぱい本を持っていて、
必要になるたびにひいてるな。
444:仕様書無しさん
07/02/28 06:03:53
「言語の勉強」はしないんじゃね？
３Ｄ演算の最適化とかは勉強するべきだと思うけど。
445:仕様書無しさん
07/02/28 07:39:56
>>444
そーゆーのは入社前に済んでいないと困るw
446:仕様書無しさん
07/02/28 07:43:40
>>444
いや、思い出してみるとはじめの頃はやってた気がする
初っ端たしかにやらない奴っているんだけどそういう育ち方すると
何をやるにも資料を調べようとしないし、作業のほとんどが大よそプロと呼びづらいぐらい
雑になる奴多いから、１つ１つキチンとこなす癖をつけたほうがいい
ゲームでは特にこの能力は大事だ（バグ出す奴って際限なく出し続けない？原因がほとんど「雑」だから、俺はこの辺に理由があるとオモ）
447:仕様書無しさん
07/02/28 09:20:25
>>442
いい会社にいるな。
俺はフリーであちこち行くが、読まない奴の方が多い。
読まない連中は、経験と過剰な自信だけで仕事してる感じ。
某大手に行った時は、新人以外は一人残らず机に技術書があって感心した。その時は、大手の技術力も大したこと無いな、とか思ったが、思い返してみると使えないレベルの奴はいなかった。凄いことだ。
周りの奴が勉強熱心かどうかという環境が大きいんだろうな。
448:仕様書無しさん
07/02/28 09:25:07
>>447
経験と知識が豊富な人ほど読んでる
自信が過剰な人は読んでない
449:仕様書無しさん
07/02/28 14:14:15
>（バグ出す奴って際限なく出し続けない？原因がほとんど「雑」だから、俺はこの辺に理由があるとオモ）
これは経験量が少ないからかなと思った、というのキチンとやれと指示をだすと全部に力いれちゃって全然終わらない。
これは丁寧にコードすべき所と、雑でも問題が発生しにくいところの区別ができていない事が多いと感じた。
初心者なのに高速化する新人と、周りのペースに合わせようとして自分のペースを失っている新人に多い気がする。
さらに、これがそのまま固定化してしまった人とかも。
450:仕様書無しさん
07/02/28 15:15:15
開発全般にしてもそうだよな。
全部自分で抱え込んじゃって、無意味に徹夜とかしてる奴。力みすぎだっつーの。
そのくせ昼間は集中できずに居眠り＆2chってあふぉかと。
451:仕様書無しさん
07/02/28 20:31:13
>>410
派遣じゃないならそれで普通
452:仕様書無しさん
07/02/28 21:25:56
ゲームプログラマーってやっぱオタク多いですか？
453:仕様書無しさん
07/03/01 00:30:36
>>450
こういうやつにかぎって自分から何か出来ないか聞きに来ないワナ。
454:仕様書無しさん
07/03/01 01:08:15
昼間は電話、会議、教えてクンの相手で忙しい
455:仕様書無しさん
07/03/02 07:33:11
>>452
オタクでない人間などそもそも地上には存在しませんが何か？
456:仕様書無しさん
07/03/02 10:13:11
>>452はこう言いたかったんだよ。
「ゲームプログラマーってやっぱきもい人多いですか？」
457:仕様書無しさん
07/03/02 10:50:31
>>456
キモくない人間などそもそも業界には存在しませんが何か？
458:仕様書無しさん
07/03/02 10:55:20
女PGはキモいよ
これはガチで
459:仕様書無しさん
07/03/02 12:30:52
( ´∀`)＜Null Pointer Exception
460:仕様書無しさん
07/03/03 06:44:30
ゲームタイトル募集中っておもしろいな
URLﾘﾝｸ(www.success-corp.co.jp)