2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

ゲームプログラマーの人に聞きたい 6問目

1 :仕様書無しさん:04/11/17 13:30:06
あーちみちみ
ゲームプログラマーに質問はないかね

ゲームプログラマーの人に聞きたい 2問目
http://pc3.2ch.net/test/read.cgi/prog/1078293745/
ゲームプログラマーの人に聞きたい 3問目
http://pc5.2ch.net/test/read.cgi/prog/1080491019/
ゲームプログラマーの人に聞きたい 4問目
http://pc5.2ch.net/test/read.cgi/prog/1086890676/
ゲームプログラマーの人に聞きたい 5問目
http://pc5.2ch.net/test/read.cgi/prog/1093629292/


2 :仕様書無しさん:04/11/17 13:42:43
2げっと したカナ?

3 :仕様書無しさん:04/11/17 14:14:09
       。 ◇◎。o.:O☆οo.
       。:゜ ◎::O☆∧_∧☆。∂:o゜
       /。○。 ∂(*゚ー゚ )O◇。☆
     /  ◎| ̄ ̄∪ ̄∪ ̄ ̄ ̄|:◎:
    /    ☆。|..  新スレおめ  .|☆
  ▼       。○..io.。◇.☆____| 。.:
∠▲―――――☆ :∂io☆ ゜◎∂:.


4 :仕様書無しさん:04/11/17 15:02:17
4様

5 :仕様書無しさん:04/11/17 15:05:52
5.5

6 :仕様書無しさん:04/11/17 15:41:21
6


7 :仕様書無しさん:04/11/17 15:56:58
7

8 :仕様書無しさん:04/11/17 17:57:56
プログラマーを目指すのは負けですか

9 :仕様書無しさん:04/11/17 22:24:08
自殺したら負けかな
と思ってる

10 :仕様書無しさん:04/11/17 23:41:02
いや勝ち組だろ。永遠の安らぎが保証されてるわけで。

11 :仕様書無しさん:04/11/17 23:47:49
自殺に失敗したら負けかな 
と思ってる 

12 :仕様書無しさん:04/11/18 00:49:31
俺がゲームプログラマーならHalfLife2とか見せ付けられたら
己の無能さを恥じて今すぐ自殺するね。

13 :仕様書無しさん:04/11/18 01:34:02
>>12
これだから素人は…
ゲームは個人の才能で作り上げるものじゃあないんだよ、坊や

14 :仕様書無しさん:04/11/18 01:34:27
一から十まで一人のプログラマが作ってるわけでなし、気にスンナ
QUAKEのソースとか見たら目ン玉飛び出るぞ。

超汚くて。

15 :仕様書無しさん:04/11/18 01:54:38
ソースの質とゲームの質の関連性はないしね。
ただ、ソースの質を高くすれば開発効率アップにつながり、ひいては期間短縮
コスト削減で利益率アップに繋がるとは思うが。
HL2も開発コストがすさまじそうだからなぁ。HL1の稼ぎをほとんどつぎ込んだ
という話もあるし。
HL2を10人チームで一年で作ったとか言われたら今すぐ出家する。

16 :仕様書無しさん:04/11/18 01:55:54
俺はゲームプログラマーなんだけどHalfLife2とか見せ付けられても
企画の奴らの無能さと会社の金の無さと社長の人の見る目の無さを
恥じながらもとりあえず今は目の前の仕事をやっつけるだけだな。・・・orz


17 :仕様書無しさん:04/11/18 02:16:52
>>16
もれなんぞはゲーム性に関係ないのわかってて、目先の仕事を片付けるので一杯一杯になってたら、
いつのまにやらソースコードの質ばっかり追いかける様になっちまったよ。
気がつきゃ専業ゲームライブラリ書きで、およそゲームプログラマとは言えない生き物になっちまった。
こういう役割の奴がいくらかでも居ないと仕事が立ち行かないのはわかっちゃいるんだが、
道を間違えた気もそこはかとなくしないでもない虚しさを感じる午前二時。

18 :仕様書無しさん:04/11/18 08:13:55
というかHL2なんてマシンパワーという制限を無視してやりたい(やれる)ことをただ詰め込んだだけじゃん。

奴らにとって現実っぽさ(リアル)=価値なんだろうけど、
かってに改蔵風に言えば、
「リアル、リアルって、シミュレートするのは現実だけですか?」
「非現実(非日常)のシミュレーションしてますか?」
ってところだな。



19 :仕様書無しさん:04/11/18 09:42:25
マシンパワーが上昇して、物理演算エンジンとか、環境光エンジンとか。どれだけ近づいても等しくはならんと思うがなぁ。
現実に絶対値で近づけ、越せるように、嘘世界に突き進むほうが全然ありだと思うが。

20 :仕様書無しさん:04/11/18 13:07:06
いや、あれは凄い。
あれだけのものを作るには、かなり最適化を施してるはず。
マシンパワーを無視してるとは思わん。

21 :仕様書無しさん:04/11/18 13:09:19
つーか、ここの自称ゲームプログラマって
エロゲーのプログラマだろ?

22 :仕様書無しさん:04/11/18 13:29:01
超リアルに床や壁が壊れる3Dのドラゴンボールの格ゲー作ってよ。

23 :仕様書無しさん:04/11/18 13:34:17
ちょっとはHL2でも見習って、ましな物作れよ
能無しどもがwwwwwwwwwwwwwwwwwwwwwwww


24 :仕様書無しさん:04/11/18 14:40:58
こ、この俺様が・・そんな釣り・・・に・・・・
   ∩___∩         |
   | ノ\     ヽ        |
  /  ●゛  ● |        |
  | ∪  ( _●_) ミ       j
 彡、   |∪|   |        J
/     ∩ノ ⊃  ヽ     >>23
(  \ / _ノ |  |
 \ “  /__|  |
  \ /___ /

25 :仕様書無しさん:04/11/18 14:57:42

>>「非現実(非日常)のシミュレーションしてますか?」


エロゲーの事かァァァァァァ



26 :仕様書無しさん:04/11/18 15:03:07
>18 名前:仕様書無しさん[sage] 投稿日:04/11/18 08:13:55
>というかHL2なんてマシンパワーという制限を無視してやりたい(やれる)ことをただ詰め込んだだけじゃん。
>奴らにとって現実っぽさ(リアル)=価値なんだろうけど、
>かってに改蔵風に言えば、
>「リアル、リアルって、シミュレートするのは現実だけですか?」
>「非現実(非日常)のシミュレーションしてますか?」
>ってところだな。

ワラタw思考停止も甚だしいな。
そういう事を目指してた時期はもうとっくに過ぎてる。
マシンパワーという制限を無視してやりたい(やれる)ことをただ詰め込んだだけでは
ユーザー確保が厳しくなるので、HL2はわざわざ1世代前のPCでも動かせるような設定に
してあるし、現実っぽさ(リアル)=価値とか言ってゲームが破綻するよりは、
ハボックを使ってなにか新しい遊びが出来ないか?という試みが随所の物理エンジン
パズルであり、非現実(非日常)のシミュレーションはCity17丸ごとシミュしてる。

国内ゲームが、既成のループの中で育ちすぎた結果
新しい遊びをクリエイトできなくなった感があるな。これはw

27 :仕様書無しさん:04/11/18 15:15:02
新スレになってからワナビーくさい書き込みが増えたなあ……。

28 :仕様書無しさん:04/11/18 15:22:27
>>27
このスレはある意味それをニヤニヤするところですよ

29 :仕様書無しさん:04/11/18 15:30:52
で、そのHL2を正しく動作させられるマシン環境はどんなのなんですか?
わざわざ1世代前のPCで動かしたって意味ないでしょ?

30 :仕様書無しさん:04/11/18 15:50:51
HL2が凄いのは、みりゃわかるよ。
HL2どころか、国内のFFだって凄いわな。
大きな会社で、結構優秀な奴が、金と人手かけて作ってる
もんな。
で、それが何?

31 :仕様書無しさん:04/11/18 16:08:14
作る側の自己満足だよな

32 :仕様書無しさん:04/11/18 17:33:39
だめな奴は何をやっても駄目

33 :仕様書無しさん:04/11/18 18:53:37
FF10はPS2用HDDに最適化された素晴らしいソフトだったしね☆
('A`)

34 :957:04/11/18 19:45:03
テスト

35 :仕様書無しさん:04/11/18 21:10:37
俺的に気になるのは
「オレタチSUGEEEEEEEEEEEEEEEEEEE!!」
って作ったHL2はまぁ良いとして、
これからもずっと自己顕示欲のために既存のCG技術をリアルタイムで出来るように
追っかけていくだけを続けていくんだろうか?

36 :仕様書無しさん:04/11/18 21:25:58
少年少女が剣と楯もってお花畑を駆け回るゲームにももう飽き飽きだけどな。

37 :仕様書無しさん:04/11/18 22:04:00
いや、いくらリアル指向が終わったろうとなんだろうと一番になれば別だよ。
物作りってのはそういうものだろ。
HL2を作る体力すらない日本のゲーム業界はそれはそれで「負けた」でいいだろ。
実際勝てねぇし。会社で自分がどれほどの技術もってたって、
そういうのがたくさんいなきゃHL2は作れねぇんだから。
金と人手にしたってあったところで使い方がうまくなきゃうまくまわらねぇよ。
向こうは環境整備から力入れてるってことだろ。

38 :仕様書無しさん:04/11/18 22:55:56
非リアルに走るのは、リアルを一通りこなせるようになってからだろ? ピカソみたいに。

日本には言い訳ばっかしてるヤツ多すぎ。
フェードアウトどころかフェードインすらしてねえだろお前らって感じ。
そうでないヤツももちろんいるけどさ。

39 :仕様書無しさん:04/11/18 23:24:26
HL2おもしれええええええええええエええ!!
お前ら一生エロゲでもつくってろよwwwwwwwwwwwwwwww

40 :仕様書無しさん:04/11/18 23:32:28
エロゲはゲームの中でも最も簡単に作れるゴミだろ。

41 :仕様書無しさん:04/11/18 23:32:41
おちつけ子供

42 :仕様書無しさん:04/11/18 23:33:18
プログラマの皆さん、HL2用FPS酔い止めMOD作ってください。

43 :仕様書無しさん:04/11/18 23:37:18
>>38
そもそもマシンスペックがあがって物理エンジンを使ってリアルタイムで処理できるようになったから
リアル路線を走れるようになったからなんだが。
ぶっちゃけ面白ければメーカーの規制以外何でもありの世界なんだからさ

昔企画と酒飲みながらそんな話やってたな…
はやいとこ今のプロジェクト上げてゲーム事業部もどりてぇ、パチンコはつまらん・・・

44 :仕様書無しさん:04/11/19 00:38:16
客が求めてるのは「映画」じゃなくてゲームなんだよ。
絵だけすごくて遊びとしておもしろくないものばかり。
すごいCG技術ですごいムービー作ったからみんな見て見て〜的な。

45 :仕様書無しさん:04/11/19 01:16:48
ゲームに何を求めるかはその人次第だろ。
でもゲーム内の世界を歩き回ってるだけで
楽しいってゲームは国産物では久しく見てないな。
最後に出会ったのはJSR(F)かな。
# 音楽も糞つまらんゲーム音楽とは一線を画す出来だったし。
HL2も単純に歩いてるだけで楽しい。

46 :仕様書無しさん:04/11/19 03:47:16
日本の業界の技術レベルを底上げする必要があるってのは感じてるんだけど
それを育てる土壌が無いよな・・・

数年前は清水や狩野や47氏の中の人の周辺(いわゆる3D野郎会)とBBXなんてサイト
が熱かった記憶があるんだけど、なんか清水本出た辺りから微妙な失速感が・・・
ちょい前だと2chのゲ術板あたりも荒らしが来るまでは割りと役に立ってたし。

今、アマレベルで3D関連技術の交流が一番活発なコミュニティ(サイト・BBS・ブログ・ML問わず)ってどこよ?

47 :仕様書無しさん:04/11/19 11:09:19
虫姫やってくる。

48 :仕様書無しさん:04/11/19 15:14:10
>>46
デジタルトキワ荘でどうかな。

49 :仕様書無しさん:04/11/19 16:37:17
ベーマガ

50 :仕様書無しさん:04/11/19 17:47:49
ゲーム業界にも残業代支払いのビッグウェーブ(屮゚Д゚)屮カモーン ...

「サービス残業代」2年分、東電が14億円全額支給
http://www.yomiuri.co.jp/national/news/20041118i314.htm


51 :仕様書無しさん:04/11/19 20:26:10
たいした仕事も出来ないお前らボンクラどもに払う金なんて
あるわけねえだろ ボケ

52 :仕様書無しさん:04/11/19 21:38:34
>>46
おまいは古いな。
いろんな意味で古いよ。
3D技術?(プゲラ って感じだな。
お前の周りだけ時間の流れが遅いんと違うか?

53 :46:04/11/20 02:50:16
>>52 まぁな。確かに俺はロートルだしそれは認めるよ。
でも、これから学んで業界入ってくる奴のために有益なコミュニティがあれば
技術力の底上げができるんじゃないのかなぁ。
アマチュアレベルからプロまで一緒に切磋琢磨できる場がなければ
いつまでたっても国内のゲ業界は技術レベルもそれ以外も斜陽なままなんじゃないのか?
みたいな事を新人教育しながら痛切に感じてるんだよね・・・
#特にゲー専卒の奴ら・・・何もしらな杉・・・orz

もいっかい>>52氏含めてみんなに聞くけど、3Dに限定しなくてもいいから
今一番活発なゲーム開発者コミュニティってどこだと思う?

54 :仕様書無しさん:04/11/20 03:04:57
>>53
どこも終わった感はあるなw

55 :仕様書無しさん:04/11/20 06:30:41
有名大学のサークルとかどうだろう
…アマチュアは加われないか

56 :仕様書無しさん:04/11/20 07:44:45
コミュニティって言うからにはそれ相当の程度の奴が集まるってことだろう?

だったら2chなんかでいんじゃね?
仮に最高水準のネタを扱うような場所があるとして、どれだけの人間が集まれるんだって話もある。


あといまさら技術話をアレコレするような程度かね?
ゲームにおいてはCGにしろなんにしろ、既成技術の後追いだけでいいみたいなもんだし、
それこそ"ゲームの技術"としてなんか新しいの発見しちゃったら人に教えたくは無いでしょ?

人に教えてもいい程度の話なんてのはゲ板でやってりゃいいんじゃねぇか?とは思う。

昔は俺も技術だのなんだの追ってた時期もあるけど、
むしろそんなこと追ったりする必要ないんじゃないかと思うにようになった。

>アマチュアレベルからプロまで一緒に切磋琢磨できる場がなければ
>いつまでたっても国内のゲ業界は技術レベルもそれ以外も斜陽なままなんじゃないのか?
敢えて言おう。90%以上プログラマのせいじゃねーだろ!

57 :仕様書無しさん:04/11/20 11:40:29
まあたしかにプログラマの技術力が足りない、と思えば今はRenderWareとか解決策はあるしなあ。
あとはそれを調達できるかどうか、だが。

58 :仕様書無しさん:04/11/20 13:10:39
最近ム板もゲ作板もきっかけなしに常時荒れてるよな。
ガキの頃に2chがあったらRUBY最強!!とか
嬉々として書き込んでたのかと思うとぞっとするよ。

59 :仕様書無しさん:04/11/20 16:05:06
タスクシステムとオブジェクト指向は相性が良さそうなのに
オブジェクト指向で実装している例を見たことがない件について

60 :仕様書無しさん:04/11/20 16:32:10
>>46
昔と違って3D技術の書籍や情報なんて巷に溢れているし、
nVIDIAとかATIが最新の技術情報は提供しているし、
コミュニティの必然性が薄れているんだよね。

だからBBSとかは、読んでも理解できません系の初心者質問が多くなる。


61 :仕様書無しさん:04/11/20 16:36:37
>>59
1.C++を理解できないプログラマが多い
2.仮想関数テーブルでは関数ポインタを動的に置き換えたりできない。
3.これからは見かけるようになると思うよ。


62 :仕様書無しさん:04/11/20 17:22:06
クラスにしちゃうと動作速度が落ちるような気が

63 :仕様書無しさん:04/11/20 19:09:30
>>62
なんで測らないの?

64 :仕様書無しさん:04/11/20 19:15:26
みんな>>62を注目ー


って言ってほしいのか?

65 :仕様書無しさん:04/11/20 20:17:15
漏れの経験上、純粋なオブジェクト指向設計とスピードは背反する。
落し所が何処かの問題だが、今のところスピード優先。
スピードや資源を気にしないのであれば、フルにオブジェクト指向でもいい。

66 :仕様書無しさん:04/11/20 20:19:35
>>63
測らなきゃわからんのか、おまえは

67 :仕様書無しさん:04/11/20 20:37:40
>>66
俺の経験ではオブジェクト指向が速度のネックになったことは一度も無い。
お前のプログラムはなるのか?この下手糞w

68 :仕様書無しさん:04/11/20 23:59:24
クラスにすると実行速度が遅くなるって、どういう理由で?
ソースコードレベルで余計(?)な手続きが増えるから?
>純粋なオブジェクト指向設計とスピードは背反する?
"純粋な"オブジェクト指向で設計したら、そりゃたぶんムダな処理が増えるよね。
それは"純粋なオブジェクト指向"が"遅い"んじゃなくて、
ゲームのメインシステムの設計に"純粋なオブジェクト指向"を取り入れた"奴"が悪いだけだよね?

スピードや資源を気にしないのであれば、どうして"フルにオブジェクト指向でもいい"のかもわからんのぅ。
世の中わからんことばっかりじゃ。

69 :仕様書無しさん:04/11/21 00:37:00
OOすると遅くなるのは
・virtualメソッドの呼び出し
・委譲による制御のたらいまわし
・オブジェクトの動的な生成・廃棄
・高級感漂うコーディングw
あたりのオーバーヘッドってことでしょ。
C++使う限りはOOのメリットを享受しつつも工夫次第で
上のオーバーヘッドはかなり避けられるとは思うけど。

70 :仕様書無しさん:04/11/21 00:45:06
>>69
で、それってα物の2度描きのコストと比べてどのくらい遅いの?

71 :仕様書無しさん:04/11/21 01:09:48
オブジェクト指向=C++だと思ってる世界の狭い香具師ら

72 :仕様書無しさん:04/11/21 01:12:07
>>67
経験がないだけだろ?

>>68
オブジェクト指向を理解してないチンカス乙

73 :仕様書無しさん:04/11/21 02:00:05
>>70
わけわからん。いったいどういう答えを期待してるんだ・・・

74 :仕様書無しさん:04/11/21 02:35:17
「そんなの無視できる範囲だろ」と言いたいんだろう

75 :仕様書無しさん:04/11/21 03:29:29
>>72
おまいはどっちの味方をしたいんだ。

76 :仕様書無しさん:04/11/21 03:36:14
>>69
工夫次第というか、既に作法の問題だよな。
Cだとマクロや関数ポインタって俺様ルールに頼るしかない部分が
言語仕様に組み込まれた時点で、後はコンパイラの成熟を待つだけの問題だった。
で、現在C++が性能面において純粋な意味でCに劣るのはRVOが利かない
返り値直渡しを深く深ーくやってるところくらいのもんだな。
メモリ面での無駄はいかんともしがたいものがあるが。

ていうか、オブジェクト指向が速度のネックになるって、未だにそんな原理主義者
生き残ってたんだな。オラ本気でびっくりだよ。
普通OOPって、結局のところデータに対する操作の形を規定することで
論理レベルのオーバーヘッドを最小に抑えることが可能な構築アプローチなんだから
OOP使用のオーバーヘッドが利益を上回っていたのはコンパイラなりの能力が追いついて
なかっただけの話しだし。

大体、それ以前にそもそも理論上最大限に最適化されたプログラムなんてこの世に存在し得ない。
ひとつのソフトの開発に無限の作業リソースをつぎ込めない以上は、単位時間あたりの
生産効率の高さこそが、最終的に最適化作業の時間を確保できる量を決めることになる。
つまり、限られた時間の中で最大の利益を上げたいなら、効率最優先でがっちりした
プログラムを短時間で書き上げて、残りの時間を最適化に回す、これしかない。

OOP使って生産性あがるわけねえだろこのハゲってんなら、もう語ることなんて何もないし。
好きにしろって感じだ。

77 :おまいら給料貰ってますか?:04/11/21 07:37:23
EA、残業代不払いで提訴に--ゲーム業界の労働条件に高まる批判 - CNET Japan
http://japan.cnet.com/news/biz/story/0,2000050156,20075773,00.htm


78 :仕様書無しさん:04/11/21 08:12:56
>>72はマジで低脳らしい

79 :仕様書無しさん:04/11/21 08:45:45
くやしそうだな

80 :仕様書無しさん:04/11/21 09:00:40
>>79
勉強しろよw
無知に講釈たれても意味がないから書く気もないけど、
馬鹿を馬鹿と指摘するくらいいいんじゃない?

81 :仕様書無しさん:04/11/21 11:17:30
喪前ら、OOP上でスピードを優先したプログラムを書くことは何ら問題ない。
が、それが純粋にオブジェクト指向に沿ったプログラムなのかどうかは気にしてないだろ。w

82 :仕様書無しさん:04/11/21 11:56:37
いつも思うんだがOOを声高々にいう奴は必ずといっていいほど、仕事遅いし出来が悪いと思ふ。
OOする事に問題があるとは思えないのだが(藁

83 :仕様書無しさん:04/11/21 13:03:13
ゲームのときはどんなアセンブラコードになるかイメージしながらクラスを
書いてるから、クラス化で必要なパフォーマンス出せない個所はベタ書き
する。それだけなんじゃないの?

84 :仕様書無しさん:04/11/21 13:08:02
Cの場合でも速度が欲しい時はアセンブラだったりするんでしょ
だったらC+/OOPでやってても速度が欲しいなら、そこは非OOPでしなさいよ

85 :仕様書無しさん:04/11/21 13:16:54
ここにいるやつらってダイナミックバインディグとか知らないんだろうなあ

86 :仕様書無しさん:04/11/21 13:18:29

"ダイナミックバインディグ"に該当するページが見つかりませんでした。

検索のヒント
- キーワードに誤字・脱字がないか確かめてください。
- 違うキーワードを使ってみてください。
- より一般的な言葉を使ってみてください。


87 :仕様書無しさん:04/11/21 13:20:49
>>76
一人で勝手に話を進めて勝手に結論を出すタイプ

>>78,79
負け惜しみはみっともないですよ

>>80
そのレス自体、意味がないから書かないでほしかった

>>81,83,84
正論

>>82
的外れなことを言って自己満足にひたるタイプ

>>85
ゲームでそんなの使うなと言いたい

88 :仕様書無しさん:04/11/21 13:22:02
86はホントに知らなかったみたいですねw

>>85
最適化すれ

89 :仕様書無しさん:04/11/21 13:25:36
>>87
友達いないタイプ

90 :仕様書無しさん:04/11/21 13:28:41
ダイナミックバインディングってdll使用みたいなもん?
そういうシステムを実装する?OOと関連した話?
ちょっと詳しく教えてくれ。


91 :仕様書無しさん:04/11/21 13:29:38
バカにされたのが悔しいからって
脊髄反射で関係ないこと書いちゃうヒトってキモ-

92 :仕様書無しさん:04/11/21 13:31:08
late bindingのことだろ

93 :仕様書無しさん:04/11/21 13:34:30
>>90
ttp://developer.apple.com/ja/documentation/cocoa/Conceptual/ObjectiveC/3objc_language_overview/chapter_7_section_3.html#//apple_ref/doc/uid/20001424/TPXREF107
↑こんなの。
なんか柔軟すぎてインチキくさいけど、そこがまたステキ。
でもゲームで使うなんてもってのほか。

94 :仕様書無しさん:04/11/21 13:35:48
メソッド呼ぶたびに検索するんだもんなあ。
そりゃ遅くもなるわ。

95 :仕様書無しさん:04/11/21 13:43:09
けっきょく、適材適所ってことでFA?

96 :仕様書無しさん:04/11/21 13:58:19
FAだが、今のところオブジェクト指向設計がゲームプログラミングに最適とは言えない。
使用できるリソースが多くなれば最適になる可能性もある。

97 :仕様書無しさん:04/11/21 15:10:18
>>96
じゃ、お前んところはそれでいいよw

98 :仕様書無しさん:04/11/21 15:32:09
>>97は、オブジェクト指向設計の真意を知らないと見た。
まあ自分に都合よく考えてもオブジェクト指向だからな。w

99 :仕様書無しさん:04/11/21 15:47:24
みんなあいまい論が好きだねぇ

100 :仕様書無しさん:04/11/21 15:48:19
保守フェイズが無い上に新規案件もタイトル名はともかく内容は0から書き直し
開発が長期化してるとはいえOOPが役に立つとは思えん

101 :仕様書無しさん:04/11/21 15:52:27
>>98
アホか。
オブジェクト指向にそんな深い概念なんかねぇよ。
あんなの10分で覚えろって感じw
まあ、覚えられない人にとっちゃ一生かかっても無理らしいけどねw
お前は勘違いしてるみたいだから不適合者だった性質だろ?wカワイソウに・・・w

102 :仕様書無しさん:04/11/21 16:00:35
>>101、10分か・・・・・・喪前のアホさ加減がばれたな。w

103 :仕様書無しさん:04/11/21 16:09:50
>>102
うほw
マジで不適合者だ。
これからツライナw

104 :仕様書無しさん:04/11/21 16:14:28
煽り合いはこれで終わる、「最後ペ」↓ど〜〜ぞ。w

105 :仕様書無しさん:04/11/21 16:16:18
>78-104
自演乙

106 :仕様書無しさん:04/11/21 16:23:47
>>105が最ごっぺかよ。物事見え無すぎ。w

107 :仕様書無しさん:04/11/21 16:29:45
10分とか言ってる香具師は明らかに釣りだろ。反応しすぎ。

108 :仕様書無しさん:04/11/21 16:37:20
w多用している釣り師が釣れる釣堀はココですか?

109 :仕様書無しさん:04/11/21 16:37:25
お前らさっきから言ってることが難しすぎる。

これにて煽り合い終了。

110 :仕様書無しさん:04/11/21 16:38:35
ここです。w

111 :仕様書無しさん:04/11/21 16:49:00
タスクでは「自由に使っていい領域」ってのを用意するみたいだけど
たとえばJavaでタスクをクラスにするときはどうやるの?
変なキャストはできないから無理なんじゃ?

112 :仕様書無しさん:04/11/21 16:50:43
タスクっていうぐらいだから
デッドラインとかの設定ってあるの?

113 :仕様書無しさん:04/11/21 16:53:17
ちょっとウンコタスクと食事タスク実行してきまつ

114 :仕様書無しさん:04/11/21 17:01:18
>>113
プライオリティは低いな。

115 :仕様書無しさん:04/11/21 17:44:59
さてこのへんで、まずは「タスクとは何か」を厳密に規定するところから議論を始めようじゃないか。

116 :仕様書無しさん:04/11/21 17:56:17
>>115
http://e-words.jp/w/E382BFE382B9E382AF.html
つまり、そいつがその作業を1つのまとまりと認識できたら、
それをタスクと読んじゃっていいわけだな。

117 :仕様書無しさん:04/11/21 17:59:58
それはOSから見たタスク

118 :仕様書無しさん:04/11/21 18:20:09
やりたい事を小分けに出来て、尚且つあまり同期が必要としない仕事の単位を
タスクと読んでもいいんじゃないかな。
まあ、ゲームの場合自由に定義してもいい。

119 :仕様書無しさん:04/11/21 18:23:58
ゲームシステムでいうタスクとOSのタスクと一般的なタスクは別物。

120 :仕様書無しさん:04/11/21 18:24:50
>>111
Javaではできないが、C++なら継承すればよい。
struct TASK{
void* pfunc;
int common;
};
struct TASK_A : public TASK{
int param; //固有のパラメータ
};
struct TASK_B : public TASK{
int state; //固有のパラメータ
};

で、タスク作るときは固定長のメモリから割り当てるようにoperator newをオーバーロードね。


121 :仕様書無しさん:04/11/21 18:45:07
メモリがからむとムズイ

122 :仕様書無しさん:04/11/21 19:10:28
チンコに毛がからむとムズカユイ

123 :仕様書無しさん:04/11/21 19:17:54
プリエンプティブな処理のまとまり = スレッド
ノンプリエンプティブな処理のまとまり = ゲームプログラミングにおけるタスク

でいいのかな

124 :仕様書無しさん:04/11/22 00:57:52
>>123でいいんじゃないかな。スレッドと目的は同じだけど、CPUの
コンテキストチェンジを使わずにコードレベルで似たような機能を実現するのがタスク。
設計上の概念だから、技術的な定義はむつかしい。

125 :仕様書無しさん:04/11/22 01:06:34
fiber

126 :仕様書無しさん:04/11/22 11:10:10
メモリ配置まで気にしないなぁ…… と、内部ライブラリべったりの俺様ですよ。

127 :仕様書無しさん:04/11/22 11:38:29
スレッドにはスタックを与える.
スレッドの切り替えは,スタック(& レジスタ + PC)の切り替え.
プリエンプティブうんぬんは関係無し,,,だと思う

128 :仕様書無しさん:04/11/22 13:23:21
処理のつながりを表現できる点がタスクの特徴では?
スレッドだとたくさんループ作らなきゃいけないのに対して。

129 :仕様書無しさん:04/11/22 14:48:26
……テレビを見ていたら、Uが。ワロタ

130 :仕様書無しさん:04/11/22 19:09:37
Cマガ立ち読みしたけどさあ、タスクの解説って、ウェブでも本でも
処理順序とか相互干渉とか泥くせーところが必ずスルーされる希ガス。
そりゃギャラクシアンみたいなの作るぶんには何も考える必要ないけどさあ。

131 :仕様書無しさん:04/11/22 19:20:47
書いてる奴もよくわかってないから避けたいとこなんだよ。

132 :仕様書無しさん:04/11/22 22:43:16
よくわかってるこのスレの住人がサイトを開設してくれ

133 :仕様書無しさん:04/11/22 23:10:19
>>128
そうかい?
なんか使いかた間違ってない?
タスクはあくまでも1つの処理を独立させるためのものだと思うよ。

ゲームに向いてるとかいう人いるけどどうかなぁ。
自分のやり方曲げたくないだけで思考停止してない?
俺はぶっちゃけ向いてないと思うよ。
タスクほどタスク同士の関連や状態遷移が多くなればなるほど複雑な構造って無いと思うよ。

134 :仕様書無しさん:04/11/22 23:14:17
ゲームのタスクシステムってただ関数ポインタを線形リストで繋いだだけなんでしょ?

135 :仕様書無しさん:04/11/22 23:33:23
>>134
そうなんだよな。
まったく意味が無い。
別に処理順序なんて変えないし。
なんでわざわざタスクにしたがる奴がこう増えたんだろうな。
処理順序なんて固定じゃなきゃバグるだろ?

136 :仕様書無しさん:04/11/23 01:05:48
なんかコマンド入力の1文字ずつを関数にして
なんたらとかいう記事を読んだ。
タスクって便利そうだと思った。

137 :仕様書無しさん:04/11/23 01:51:16
>>135
古式ゆかしいタスクの利点は処理が軽い、これにつきる。
今でも十分に使い出のあるテクには違いない。
安全性は、C++の型チェックだのテンプレートだのに活躍してもらうことで
コンパイルの時点かなりのレベルまで確保できる。

複数の状態をまたぐ処理なんぞは、
生まれから死亡してリソースの後片付けさせるまでタスク単位で区切って
あとはルータに回させれば、さっくり並列処理のできあがり。

必要な時に必要なタスクを起動して、必要なくなくなったら死んでもらう。
で、タスク同士は無駄に干渉せず、通信は間接的に行う程度にとどめる。
タスクの調停役が必要なら、上位にルータタスクなり監視タスクなりを設ける。

ぱっと見に何やってんだかわかりづらくなるのは当たり前だし、
前もってタスク間の現在状態やらなにやらをダンプする仕掛けとか用意しとかないと
いざデバッグの段になって酷い目見るのも当然だが、否定されるようなもんじゃない。

状態マシンが過剰に複雑になりすぎる前に、まとまった処理単位でボコボコ
タスクに切っちまえば保守も楽。
すこぶるOOP。

138 :仕様書無しさん:04/11/23 03:06:51
タスクって、スレッドみたいに複数の処理を1フレームに一度ずつ
平行して呼び出す仕組みを言語ロジックだけで実現する仕組みだと
思ってたんだが、みんなが言ってるタスクとは違うものなのか・・・

139 :仕様書無しさん:04/11/23 03:19:08
処理が軽い以外に何かメリットないの?


140 :仕様書無しさん:04/11/23 03:30:31
>>139
保守が楽。
いやマジで。

>>138
それにはある程度歴史的な事情もあると思う。
ゲームは長いこと1アプリ1プラットホームでやってきてて、概念からして
プリエンプティブなマルチタスクなんて代物自体が無いも同然だった。
やりたきゃ勝手にスライシングでもなんでもしてくれと。

狭義でのマルチプロセス(タスクも含んどくか)は、OSなり上位のマネージャーが
リソースの競合を解決しつつ、公平に資源を分配してくれる単位。
スレッドは通常メモリ空間を共有してる処理の単位で、OSの保護がない分、
重いシステムコールを仲介せずにオブジェクト間でのやりとりができるので高速。

で、ゲーム機に紛いなりにでもOSが乗っかり、スッドレだの同期オブジェクトだのを
意識できるようになったのは比較的最近のこと。

タスクって言葉が世間様のそれと乖離しちまうには十分な時間があったってことじゃ
ないだろか。


いや、俺妄想だけどね。

141 :仕様書無しさん:04/11/23 04:15:48
だからさ、関数ポインタでアクセスするのを軽いっていいはるのは
別にいいけどさ、タスクである必要は無いんだよ。

タスクってさ、要するにウィンドウズの下っちょにあるタスクよw
まあ、メモ帳とか、VCとか、ギコナビとかIEとか実行されてるもんがおさまってるわけじゃん?

これらのものってさ、互いに干渉しあわないじゃん。
んで、「実行されるものにフォーカスを移す」って動作が
タスクの醍醐味じゃん。
こういう構造ならタスクはわかるよ。
でもさ、互いに干渉しあって尚且つフォーカス云々じゃなくてすべてが
平行動作してるって状況でなんでタスク?w
タスクスイッチとかクリティカルセクションとかプライオリティとかいらないだろw
そもそもタスクじゃなくていいからw

俺、絶対、選択間違ってると思うんだけど。

142 :仕様書無しさん:04/11/23 04:35:03
言葉遊びだが、それは「プリエンプティブ・マルチタスク」。
タスク実装の一形態に過ぎないぞ。

別段メモリ保護もなんにもなしに関数ポインタ受け渡しまくって
ぽこぽこ状態を遷移してく狭義のタスクをどう呼びたいのか知らんが、
関数自身が次に呼び出される関数を知っていて、状態遷移を繋いでいく仕組みには、
ロボット式なんて呼びもがあるそうだ。

こと遷移対象となるオブジェクト(つーか状態マシン)の実装のことを
タスクと呼びたくないなら、そう呼べば。

143 :仕様書無しさん:04/11/23 05:11:02
正直お前らが何の話をしたがっているのかサパーリわからん

144 :仕様書無しさん:04/11/23 08:25:47
俺も論点がワカンネ
ていうか、「タスク」よりも英語圏のGameObjectとかの考え方のほうが
すっきりするけどなあ。OO的にも。

145 :仕様書無しさん:04/11/23 10:29:36
状態を表すのに、変数使うか、関数使うかだけの話じゃないの?

今週のCマガジンに書かれてないような便利な仕組みを教えて欲しいな。
開発現場ではどんなコードがかかれてるんだろ?

あと、同じくCマガジンでゲーム用スクリプトをつくる記事があって、
なるほどなぁって思ってるんだけど、
FFとかで使われてるスクリプトってどんな仕様なんだろうか?
ジャンルごとにいろいろあるんだろうけど、ゲーム用スクリプトに特有のアイデアを
知りたい。

146 :仕様書無しさん:04/11/23 10:45:53
>>145
ツクールでもやってろ

147 :仕様書無しさん:04/11/23 14:08:44
>>141
ゲームじゃあ、独立性はないに等しいっすね。おっしゃるとおりで。
OSというか、ユーザー(?)から考えるとタスクなんてものは、同時に実行しているアプリの数、との指摘は正解、というか大多数のタスクの定義ですな。
と言っておきながら、線形ポインタによる関数羅列を順次実行するだけでもタスクと呼称するのは、旧いタームでしょ。
新しいプログラマと旧いプログラマの認識の違いが露出していると思う。

>>146
そういうことを言いなさんな。みんな、サバイバル仲間なんだからさ。

148 :仕様書無しさん:04/11/23 17:59:05
FFとかドラクエのソース見たいなぁ

149 :仕様書無しさん:04/11/23 18:12:33
コンシューマゲームってC++で書かれてるの?

150 :仕様書無しさん:04/11/23 20:00:51
うん。

151 :仕様書無しさん:04/11/23 20:13:40
アーケードもC++だよ

152 :仕様書無しさん:04/11/23 20:56:10
Windows上のゲームもC++が多い。

153 :仕様書無しさん:04/11/23 22:22:04
結論から言うと、ゲームプログラミングにおけるタスクの定義は、
そのゲームプログラミング上必要な形で使用され定義されるで良いかな。
一意に決めることが無理と。

154 :仕様書無しさん:04/11/23 22:37:28
正直なところそのタスク議論とやらに参加してた奴はみんなアレな気もするが

155 :仕様書無しさん:04/11/23 22:44:21
実装テクの1つということで…。

156 :仕様書無しさん:04/11/23 22:50:14
>>153
なんでそこまでタスクがいいのかとw
すでにタスクじゃねぇのにタスクタスクうるせーってのw

157 :仕様書無しさん:04/11/23 23:16:07
>>156
単に言いやすいだけだろ。言いたくないやつは言うな。
漏れは彼女に「愛している」て言うのと一緒だ。

158 :仕様書無しさん:04/11/23 23:17:12
ギャラクシアン時代のテクニックをいまだにありがたがっている連中がいるのは笑える。

159 :仕様書無しさん:04/11/23 23:19:01
>>158
藻前の中は何も成長が無いのだな。 あ・わ・れ・よ。

160 :仕様書無しさん:04/11/23 23:26:50
ギャラクシアン時代のテクニックが今どのあたりで駆使されてるのかが気になる

161 :仕様書無しさん:04/11/23 23:41:58
HL2, OO, taskと今スレは上々の立ち上がりですな。

162 :仕様書無しさん:04/11/23 23:56:23
たんにナムコがやってるから凄いことだろうってことで俺もやりたいってだけでしょ。
有名人がマックつかってるから俺もマック買うってのと同じレベル

163 :仕様書無しさん:04/11/24 07:13:59
ていうかごく普通に洗練された当たり前の実装テクだと思うんだが。

いまの時代にわざわざそのままを使うほどのものかは別にして。
有難がるもへったくれも、普通だろ。

164 :仕様書無しさん:04/11/24 08:53:51
タスクって、コールバックとかと違うの?

165 :仕様書無しさん:04/11/24 09:21:59
タスク -> ワーカースレッド
タスク -> メソッドコールスタック
タスク -> ゲームシステムレベルでの処理の最小単位
タスク -> ○○輔って名前の奴がいつだったか同級生でいたなぁ

166 :仕様書無しさん:04/11/24 09:26:50
話題になっているゲームタスクの代替としては(色々あるだろうけど)どんな実装があるの?

167 :仕様書無しさん:04/11/24 09:43:31
つか、オープンソースになってて参考になりそうな
ゲームタスクのソースってないかな

168 :仕様書無しさん:04/11/24 09:51:16
>>167
おまえはパゲか?

169 :仕様書無しさん:04/11/24 10:35:20
>>149-153
GBAもC++ですよ。

うーん、GBA屋って少ないのね……

170 :仕様書無しさん:04/11/24 10:43:16
>>166 fiber

171 :仕様書無しさん:04/11/24 10:52:20
タスク管理をC++でシャープにまとめてる
サンプルだせよ

172 :仕様書無しさん:04/11/24 11:08:46



答 え は 君 た ち の 胸 の 奥 に あ る




173 :仕様書無しさん:04/11/24 16:24:26
>>171
LINUXのソースでも読め。シャープかはしらん。
ゲームプログラムなら、ゲームおきにあるから一意には無いと言っとろうが!

174 :仕様書無しさん:04/11/24 16:26:29
オブジェクトがわらわら出てくるようなアクションゲームやシューティングを
作ってたら、普通にタスクシステムに行き着かないか
漏れは上手いシステムを考案したぞと思ったら既に何十年も前から実現されてたわけだが

175 :仕様書無しさん:04/11/24 17:28:56
単にタスクという呼び方が嫌なら

stateパターン
strategyパターン
flyweightパターン

あたりで説明すればおkでわ?

176 :仕様書無しさん:04/11/24 18:07:56
単にタスクという呼び方が嫌なら

クラス

あたりで説明すればおkでわ?


177 :仕様書無しさん:04/11/24 18:14:59
クラスは異質すぎるぞ、OOから文句が山ほど出てくる。

178 :仕様書無しさん:04/11/24 18:16:54
所で、このスレにタスクを有りがたがってる香具師はいるのか?

179 :仕様書無しさん:04/11/24 19:12:36
>>178
お前の言うタスクがなんなのかわからんと何とも言えんだろうに

180 :仕様書無しさん:04/11/24 19:50:49
さてこのへんで、まずは「タスクとは何か」を厳密に規定するところから議論を始めようじゃないか。


181 :仕様書無しさん:04/11/24 20:30:37
さてこのへんで、まずは「>>180は健忘症か」を厳密に規定するところから議論を始めようじゃないか。

182 :仕様書無しさん:04/11/24 20:32:25
あーうるせーw
タスクやデザインパターンなんて使ってねぇよ。

逆に聞くけど、タスクやデザインパターン使わないで
一辺でもゲーム作って見たの?

俺、ゲーム会社もう3つ目(業界8年目)になるけど、
タスクとかデザパタとかって言葉、現場できいたことないんだよね。
ネットのソース公開ゲームとかではよくみるっちゃあみるけど(でもほとんどSTGw)
不安定な実装だなぁって思うよ。
これ、普通に動いてるうちはいいけどバグったらどうしようもないね。
一番複雑になるオブジェクト同士の関連に関する解決策がはいってないしね。
なんでこんなの使うんだろ?

183 :仕様書無しさん:04/11/24 20:40:18
>>182
お前の言うタスクやデザインパターンがなんなのかわからんと何とも言えんだろうに

184 :仕様書無しさん:04/11/24 20:47:49
>>182は自分がタスクやデザインパターンが無くても>>182の知識だけで
ゲームが作れるほど優秀だと言いたいだけだろ。ほっとけ。

185 :仕様書無しさん:04/11/24 20:52:35
>>184
ちがうな。
ぶっちゃけ、お前等の話てるもんを現場で見た事が無い。

186 :仕様書無しさん:04/11/24 20:56:16
>>185
経験豊富なプログラマーは、普通にプログラミングをしてても、デザインパターン
になっているもんなんだよ。デザインパターンはその知識を解かる様にまとめて
名前を付けただけさ。それも知らないのか?

187 :仕様書無しさん:04/11/24 20:56:50
とりあえず>182がどんなゲームを開発してきたか、
それがどんな環境で動くものであったかを聞こうじゃないか

188 :仕様書無しさん:04/11/24 21:08:23
>>187
大手だ大手(自慢)
1回だけ100万越えあるよ。
10万未満も1回だけあるけど。
もうね、俺の実力っていうか。
どのプロジェクトに入れたかっつー運だけだなw

189 :仕様書無しさん:04/11/24 21:11:58
>>188
そんな情報ではどんなゲームの開発かまったくわからん。

190 :仕様書無しさん:04/11/24 21:12:57
>>188
わかったわかった、藻前はコダーだな。上から落ちてきた仕様のプログラムを書くだけ。
わからないのも無理は無い。

191 :仕様書無しさん:04/11/24 21:14:05
そもそもデザインパターンは現場でよく使われている設計テクニックを
概念として理解しやすいように整理して命名したものだぞ。
と書こうと思ったらすでに書かれていた・・・

まぁ、なので普通に設計してたら大抵デザパタのいくつかは
使ってる。

192 :仕様書無しさん:04/11/24 21:14:11
>>189
PS2だ!

193 :仕様書無しさん:04/11/24 21:15:07
まちがえ
>>189
>>187

194 :仕様書無しさん:04/11/24 21:27:18
おれんとこの現場じゃデザインパターンという言葉使ってる奴いないけど、
休み時間とかにデザインパターンの本読んでる奴は普通にいたな。



195 :仕様書無しさん:04/11/24 21:27:35
末席

196 :仕様書無しさん:04/11/24 21:33:52
普通、作ってるところでXXXデザインパターンとはほとんど言わないぞ。
教育時ぐらいは使うか。とにかくだ、>>193は根本的にデザインパターンを
思い違いしている。そのまま好きなように生きて行けばいい。

197 :196:04/11/24 21:34:36
×>>193
>>194

198 :仕様書無しさん:04/11/24 21:37:15
>>196
現状保持ということで

199 :仕様書無しさん:04/11/24 21:47:14
>>198
維持だろw

200 :仕様書無しさん:04/11/24 21:52:41
つまりスレを総合すると言語に不自由な奴が多いということですね。

201 :仕様書無しさん:04/11/24 21:57:52
2ちゃんのお約束とはいえ、馬鹿がいるほど伸びるスレだな

202 :仕様書無しさん:04/11/24 22:04:37
なあ、中小ゲーム会社に転職して半年ぐらいたつんだけど
ずっと土祝祭日休みなし、終電帰りが殆どデフォなんだけど
これってゲ業界では普通なのか?

203 :仕様書無しさん:04/11/24 22:07:18
>>202
まあ、一年ずっとその調子ってときもあったことあるから
たまたまそういう時期に入ったのかもわからんよ。

2〜3年もその状態が続いてたらもう駄目だろ。その会社。

204 :仕様書無しさん:04/11/24 22:23:01
前いた会社で200日以上土日祝祭日完全に休みなしの経験したとかいう奴いたけどな。
中小系は基本的に人で足りないからしょっちゅうプロジェクト間の人の行き来があるから、
スケジュール前倒しで進めていって、土曜日に休みもらおうと思っても(←この辺で何か間違ってるかもしれない)
何かあれば「手の空いてる奴」ってことで引っ張られていくんだよな…


205 :仕様書無しさん:04/11/24 22:39:28
どうしてそんな悲惨なことになるのですか?

206 :仕様書無しさん:04/11/24 22:50:47
1.企画もしくはクライアントが馬鹿で、練りこみにグダグダ時間かけたり、途中で仕様が変わったりするから
2.そもそも最初の納期見積もりが間違ってる
3.人手が足りない
4.会社としては使える人間遊ばせておく余裕がないから、手が空き次第、別プロジェクトへ放り込まれるから

207 :仕様書無しさん:04/11/24 23:41:25
タスクシステムってコンテナにクラス突っ込んでぐるぐる回すのと何が違うん?
ループの処理がないぶんタスクシステムのほうが若干軽いのはわかるんやけど一緒やろ?

208 :仕様書無しさん:04/11/24 23:43:41
一緒、関数ポインタが書き換えれんとかのたまう阿呆がいるが
んなもんメンバ関数ポインタをもう一段噛ませば同じやし

209 :仕様書無しさん:04/11/25 01:45:47
>>206 追加してくれ。
5.プログラマが疲弊しているので遅刻の常習犯。
会社に来ても午後まではボーっと2chで時間を潰し、夕方からやっと手を動かし始める。
夜中までそのまま仕事して終電で帰るので、次の日は眠くて起きられない。で、また遅刻の繰り返し

で、プロジェクトが遅れると。

6.そういう勤務が普通なので周りのモチベーションも下がりまくり、
「ちょっとぐらい遅れててもいいや」的考え方が蔓延する。


210 :仕様書無しさん:04/11/25 02:10:18
耳が痛い…

211 :仕様書無しさん:04/11/25 02:40:47
さらにこんなんもある
7. 勤務がしんどいから転職を考え、そのネタを仕込む為に勤務時間にせっせと内職するようになる。


212 :仕様書無しさん:04/11/25 07:23:36
8.なんか最近チンコがやたらとカユイ。

213 :仕様書無しさん:04/11/25 08:23:26
9.一部を除いてほとんどの人が人生を悲観してる

214 :仕様書無しさん:04/11/25 09:09:55
10.マンコは臭いほうが好きだ

215 :仕様書無しさん:04/11/25 10:52:58
>206>209
当たってんなー
特にうちだと、人が足りないって事で進行中のプロジェクトから
人を回したりするもんだから、初期と末期だと一部以外は一新って事もあるし

で、俺は5番そのもの… orz
遅刻は…あまり無いと思いたい

216 :仕様書無しさん:04/11/25 13:21:20
>>207
> ループの処理がないぶんタスクシステムのほうが若干軽いのはわかるんやけど

軽いっつーてもタスク1つあたりせいぜい数〜数十ステート、
ギャラクシアン時代の8bitハードならともかく、今なら完全に問題外の差じゃろう。

まあ、少なくとも俺は、Cマガに載ってたような仕掛けをそのまま使ってくるヤツがいたら
どういう考えでそうしたのか小一時間問い詰めるからそのつもりで。
C++で自然に組んでくるやつのほうがよほど心証がいい。

217 :仕様書無しさん:04/11/25 13:29:13
Cmaga読んでなんだけどそのライターって何者なの?

218 :仕様書無しさん:04/11/25 13:33:14
やはりループだと柔軟性ではタスク(処理の線形リスト)に負けてると思った。
ループで何か特別なことをやろうとするとすぐコードが汚くなる気がする。
タスクならもとから構造なんてないに等しいからなあ。

219 :仕様書無しさん:04/11/25 13:48:56
タスクってことは、

scenestart(){
 task.add(titledraw);
 task.add(menudraw);
 task.add(input);
 task.add(syncwait);
}
scenemain(){
 while(loop()) task.execute();
}
sceneend(){
 task.releaceall();
}
こんなかんじか?

たしかにメインはすっきりするけどなぁ…

220 :仕様書無しさん:04/11/25 15:39:17
ぶっちゃけ、ポインタしらんでもいける。

221 :仕様書無しさん:04/11/25 16:37:13
>Cマガに載ってたような

これってどういうの?
Cマガなんかよまねーっつの

222 :仕様書無しさん:04/11/25 16:43:23
チェーンリストに処理タスクをつなぐ方法だと、
メインループに手を入れなくても個別の処理タスクを
追加できるからエンバグを抑えることができる・・って
理由と考察。

223 :仕様書無しさん:04/11/25 17:16:11
>>218
そのかわりタスク間の依存関係に注意しないとならん。
安定で堅牢に動作させるためには、ある程度抽象化した通信層が必要になる。
ゲームプログラム的には、その層が厚すぎると「まだるっこし杉」だったり
「処理オーバーヘッドでか杉(てほどじゃないけどもう少しダイエットしたいの)」とかだったりで
設計にバランス感覚の求められる部分とかになることもあるかもしれん。

実際には言うほど難しいもんじゃないし、言うほど重たい代物にもならないのが普通だと思うけど。

224 :仕様書無しさん:04/11/25 17:33:45
>>215
自覚してるならせめて深夜か早朝にレスしてくれ…
見てて哀れだorz

225 :仕様書無しさん:04/11/25 17:36:24
このスレに来ている人たちなら一人でこれを軽く超えるゲームを作れたりするんですか?

ttp://homepage2.nifty.com/isshiki/

226 :仕様書無しさん:04/11/25 18:02:01
>>225
北米産のゲームスクリプトやゲームエンジンのサンプルによくあるタイプのゲームだよね。

227 :仕様書無しさん:04/11/25 18:03:47
タスクシステムを作る人ってなんでコンテナを使わないんですか?

228 :仕様書無しさん:04/11/25 18:20:00
>>227
仮に作るとしてもコンテナなんてまだるこしいのは使わん。

229 :仕様書無しさん:04/11/25 18:35:02
コンテナって何の用語ですかと聞いたら叩かれますか?

230 :仕様書無しさん:04/11/25 18:36:28
>>209
お前、うちの会社の人間だな!!

231 :仕様書無しさん:04/11/25 18:42:18
>>229藻前はプログラマーか?バシバシ!>>229

232 :仕様書無しさん:04/11/25 18:47:56
>>229
S・T・L!S・T・L!

233 :仕様書無しさん:04/11/25 19:10:06
>>225
お前ナメてんのかコラ?

234 :仕様書無しさん:04/11/25 19:10:50
このスレでオープンソースをやったらどんなソフトが出来るんだろう

235 :仕様書無しさん:04/11/25 20:57:06
オープンソースって呼ぶより、単にソース公開即終了になりそうな悪寒

236 :仕様書無しさん:04/11/25 21:21:05
遅刻しても評価とか下がったりしないのか?

237 :仕様書無しさん:04/11/25 21:46:07
C++は使えないと言ったら叩かれますか?

238 :仕様書無しさん:04/11/25 22:43:22
使えない理由を述べよ。

239 :仕様書無しさん:04/11/25 22:46:31
>>237はC++が使えない。 ○

240 :仕様書無しさん:04/11/25 22:48:35
今時C++が出来ない人間ってなんなの?って感じ。もう袋叩き。

241 :仕様書無しさん:04/11/25 22:51:13
やったことが無いから使えないのならともかく一通り勉強してまだ使えないのは問題。

242 :仕様書無しさん:04/11/25 23:12:04
ちょっと待て
C++が使えないってことはゲーム系の人じゃないのでは?

243 :仕様書無しさん:04/11/25 23:17:36
WEB系かCOBOL系か、VBも有る。
しかしだ、どの系をやっててもC++ぐらい余裕でやらないと先が無いと思うぞ。
(年寄りのCOBOL系は除く)

244 :仕様書無しさん:04/11/25 23:53:44
A. 日曜プログラマなうえにMac使いだから

245 :仕様書無しさん:04/11/26 00:44:40
Ans. 携帯ゲームプログラマだから。
 JavaとPHPなら分かるんだよぅ・・・orz

246 :仕様書無しさん:04/11/26 01:48:46
死んで詫びろ

247 :仕様書無しさん:04/11/26 02:46:30


   ?



248 :仕様書無しさん:04/11/26 02:46:50


  ?



249 :仕様書無しさん:04/11/26 02:47:24
誤爆スマソ

250 :仕様書無しさん:04/11/26 08:23:54
ゲーム系でもメインにはC++使わんって奴は多い希ガス
いや、すげえ困りもんなんだけどね
今更こ汚いCのソース読まされてもみたいな

251 :仕様書無しさん:04/11/26 10:26:42
C++ならソースは綺麗なんかー!!(AA略

まあ、あれだ。年末は抜けた。だからここにもこられた。だれか俺を誉めてくれ。

252 :仕様書無しさん:04/11/26 11:18:29
>>251 忙しいのにここに常駐しる香具師に比べれば賞賛に値する


253 :仕様書無しさん:04/11/26 14:40:00
ゲーム開発者残酷物語――EA提訴で明るみに出た業界の実情
http://www.itmedia.co.jp/news/articles/0411/26/news021.html

254 :仕様書無しさん:04/11/26 16:26:16
>>251
乙。でもさぁ、他からひっぱられない?
早く終わらせても、作業時間は変わらないんだよね。
4、6と似てるけど、
頑張って早く終わらせても報われないってのがあるな。

255 :仕様書無しさん:04/11/26 17:02:12
>>254
まぁ、クリティカルパス上にいる奴は後れる事はあっても早まる事は絶対にないからな
そして、そこに来る奴って大体決まっているし

256 :仕様書無しさん:04/11/26 17:19:36
>>253
プログラマーの方々おつかれさま。
私がプログラマーをやめて10年くらい経ちましたが、
労働条件は多少は良くなったんですか?
私の時代には、納期前は週100時間労働は当たり前でしたが
現在もあまり変わってないのですか?
何となく気になったモノで...。

257 :仕様書無しさん:04/11/26 17:23:26
あー、256ゲトしそこなったorz

258 :仕様書無しさん:04/11/26 17:25:03
なんで職業プログラマってそんなに大変なの?
というか、なんでいつまでたっても改善されないの?

259 :仕様書無しさん:04/11/26 17:25:45
>>257はめでたく−1をGETしたではないか。(おめ

260 :仕様書無しさん:04/11/26 17:47:49
>>258
どいつもこいつも"死にたがり"なのさ

261 :仕様書無しさん:04/11/26 18:11:58
漢ッスね

262 :仕様書無しさん:04/11/26 18:14:18
>>257
何処も改善したいと思っているのが本音なのだろうが、なかなか難しい。
作業量が定量的に判断できないのが一番の問題かな。

263 :仕様書無しさん:04/11/26 18:43:09
三大長時間労働職
プログラマ
量販店
トラック運転手

こうして並べてみるとプログラマって迷惑かける相手が素人じゃないって事だけが救いだな。
計算間違えてもコンピュータに怒られるだけだし居眠りしても死ぬのは自分だしな。

264 :仕様書無しさん:04/11/26 19:02:48
死ぬのかよw

265 :仕様書無しさん:04/11/26 19:39:48
ぼうや…プログラマってのは男が命をかけられる数少ない職業なんだよ

266 :仕様書無しさん:04/11/26 19:54:06
会社が利益と社員の命を天秤にかけてるわけですね

267 :仕様書無しさん:04/11/26 19:56:34
正確に言うと、利益より過労死で死んだ方会社にはマイナスなわけだが。

268 :仕様書無しさん:04/11/26 20:30:39
過労死じゃなくて、「自分の才能に悲観して自殺したんですよ彼は」と言われて終わる罠

269 :仕様書無しさん:04/11/26 20:38:17
「プログラマじゃなくてコーダだろ」

270 :仕様書無しさん:04/11/26 20:40:36
コーダさんはかわいそうだったね

271 :仕様書無しさん:04/11/26 20:41:07
また、分けの分らない香具師が・・・・

272 :仕様書無しさん:04/11/26 20:49:17
「休みたければ時間内に終わらせろよ」

273 :仕様書無しさん:04/11/26 20:50:51
ゲームコーダっていう言葉はあるのですか?

274 :仕様書無しさん:04/11/26 21:12:41
>>272
俺「やた!終わった!帰るよ!」
糞「まてよ!」
俺「なんだよ、動作確認はそっちの仕事でしょ?」
糞「また、バグってたらどうするのよ?」
俺「はぁ?バグレポート出しとけよ。後で直すよ。
  だいたい来週でいいじゃん。なんで今日直そうとするの?
  いきなり変な仕様変更するからバグるんじゃん。
  あと、俺の範囲外の部分もあやしいから、多分、休暇中の○○君とも
  話合わないと直らないよ。今回俺がいじった部分だってトリアエズ動くようにしたってだけだかんね。
  つまり、○○君の休暇が終わる三日後ってことですよ。」
糞「それじゃ、期限(俺の)に間に合わない。」
俺「そりゃそうだろう、仕様変更したんだから。」
糞「それじゃ、元に戻してよ。」
俺「(なにいってんだこの馬鹿w)それも無理でしょ○○君いないんだから」
糞「それじゃ、期限(俺の)に間に合わない。」
俺「それさっき聞いたよ。」
以下ループw

275 :仕様書無しさん:04/11/26 21:59:04
つまりプログラマにはバカが多いってこと?
つーかバカな同僚の被害を受けやすいってことか

276 :仕様書無しさん:04/11/27 00:51:52
>>274
俺「やた!終わった!帰るよ!」
糞「まてよ!」
俺「(無視)お疲れさま〜」

相手が糞野郎とわかってるのなら、普通はこうだろw

277 :仕様書無しさん:04/11/27 08:31:30
>>273
名刺に入れかけた。ウケ取ろうと思って。
額面どおりに取られるのがオチだと思って即ヤメにしたが。

278 :仕様書無しさん:04/11/27 10:20:09
元のままのリビジョン渡せばいいじゃん

279 :仕様書無しさん:04/11/27 11:29:49
炎が噴出すエフェクトを作れって指示があったのね
まぁ、見上げないとわからない場所だから、気合入れる必要もないなと思って
指示書も特にないから自分で適当に作ったのね

そしたら、そこのデザイン担当という人から猛抗議が入って、
じゃ、指示書出せといったら、ムービーと写真数点が送られてきただけ
現実のムービーじゃ意味ないだろ…俺の作ったのが似てない訳じゃないし

その後、
「プログラムがおかしい、思っているものと違う」
「指示書に書いてある事を誤解か誤記しているという意味?」
「ベースプログラムがおかしいと思う」
「ベースプログラムの意味、わかってる?」
「とにかくどうにかして、良くないので」

良くないって言われてもなぁ…俺の価値観では悪いとは思わないし
どうにか、ってあんたが全然駄目といい始めたわけだし…
挙句の果てには、書いてある数値は表示して確かめてないと言い出すし…

どうにかしてくれ ('A`)

280 :仕様書無しさん:04/11/27 12:16:20
パラメータ操作する機能つけて満足いくまでいじらせてやれ('A`)

281 :仕様書無しさん:04/11/27 12:44:16
>>280  (279ではない)
いい案では有ると思うが。しかしだ!(強調したい)
このような奴に限って、ツールを2〜3時間使って、そのままで良いとのたまう事は間違いない。
「ツールを作った時間は何だったんだ!」と激しく思う。

282 :仕様書無しさん:04/11/27 13:17:18
C++でポインタの管理、どうしてますか?

1.スマートポインタテンプレート(boost or 自前)

2.COMインターフェース風に AddRef(), Release()
(デストラクタを隠して、クラスに自前で参照カウンタを管理する機能を付加など)

3.生ポインタ

4.その他(ハンドルの類)


自分はとりあえず生ポインタを使ってますが、

AがBを半永久的に参照(ポインタか参照)していて、Bが delete されたとき、
Aはそれに気づかず不正アクセスしてしまうような状況をどのように回避すべきでしょうか。
(そのような状況を回避するような設計方法など)

とくにタスクや GameObject, Actor などの類の、
複数のオブジェクトが相互参照(メッセージのやりとり)するような状況での
常套手段などをお聞かせください。


283 :仕様書無しさん:04/11/27 13:37:20
>>282
毎回、管理クラスにキーを突っ込んでオブジェクトを取ってくるか
オブジェクトをラップして生存チェックを追加するかが多いな

でも、俺自身やっぱりDOSの時代の印象があって、
deleteを頻繁に行う、って事があまりないんだよな
シーンの初めにまとめて確保して、開放する時はシーンの最後のみ、が多い

284 :仕様書無しさん:04/11/27 13:57:02
>>282
俺のところは、寿命管理は侵入型参照カウントを利用。

ただし外部に公開する場合にはポインタを生で公開せず、ポインタから生成した
整数値(ハンドル)を渡すようにしてる。

285 :仕様書無しさん:04/11/27 16:08:06
>>282
ぶっちゃけ、ポインタ(自体)に管理が必要になってしまうような構造自体がすでに駄目。

基本的にポインタってのは言語の機能であって設計ではない。
>AがBを半永久的に参照(ポインタか参照)していて、Bが delete されたとき、
>Aはそれに気づかず不正アクセスしてしまうような状況をどのように回避すべきでしょうか。
ポインタを使うということはこういう問題が発生してしまうということであって
この問題がおきるような設計にした時点ですでに設計ミスといって間違いない。

よく、DirectXでデバイス初期化してLPD3DDEVICEを各クラスで保持してて
Alt+TabされるとLPD3DDEVICEが無効化しててアボーンってなるプログラムを
みかけるけど、アレがポインタの一番まずい死に方w
何が駄目だったのかというとLPD3DDEVICEを保持するとかいう奇行が駄目だったわけよ。
似たようなことしてプログラム組んでない?

286 :仕様書無しさん:04/11/27 16:38:08
>>285
> ぶっちゃけ、ポインタ(自体)に管理が必要になってしまうような構造自体がすでに駄目。
> 基本的にポインタってのは言語の機能であって設計ではない。
> ポインタを使うということはこういう問題が発生してしまうということであって
> この問題がおきるような設計にした時点ですでに設計ミスといって間違いない。

そうならない良い設計方法を聞かせてくれませんか?



> よく、DirectXでデバイス初期化してLPD3DDEVICEを各クラスで保持してて
> Alt+TabされるとLPD3DDEVICEが無効化しててアボーンってなるプログラムを
> みかけるけど、アレがポインタの一番まずい死に方w
> 何が駄目だったのかというとLPD3DDEVICEを保持するとかいう奇行が駄目だったわけよ。

いや、LPD3DDEVICE 自体は機能として無効化するだけで、
そのポインタをアクセスしても問題ないです。(参照カウンタがあるので保持しても問題ないはず)
無効化したときにはどこかでリセットすればいいですし。(再作成した場合は問題あり)


> 似たようなことしてプログラム組んでない?

まさしく 282 の最後の文章にあることで悩んでいるので。

287 :仕様書無しさん:04/11/27 16:54:15
>>282
規模によって変わるんじゃないかね。今のコンシューマゲームは、
不正アクセスをバグと割り切って、コードロジックの見直しで対応できるぎりぎり
の規模だと思う。
ただ、これ以上ソフトの規模がふくれあがって、動作時のオブジェクトの
ライフサイクルが把握できない状態になれば、スマートポインタなりを
使わざるをえなくなってくる。
べたに書くほどスピードとコーディング効率があがり、間をかますほど安定性と
デバッグ効率があがるので、適応個所にもよるなぁ。

288 :仕様書無しさん:04/11/27 17:52:58
>>285に同意
基本的に消滅する可能性のあるポインタはコピーしない
仮にコピーしても、コピー先ポインタのライフサイクルが、
コピー元より長くなるような設計を避ける

もしくは、決められたポイントになるまでdeleteしない

これさえ守ってればそこそこいけない?

289 :仕様書無しさん:04/11/27 18:11:05
>よく、DirectXでデバイス初期化してLPD3DDEVICEを各クラスで保持してて
>Alt+TabされるとLPD3DDEVICEが無効化しててアボーンってなるプログラムを
>みかけるけど、アレがポインタの一番まずい死に方w

これって確かフォーカス失った時に、別のアプリがDXにアクセスするかして、
DXへのアクセス権がロストした時に、そのまま続行しようとするとなるんじゃなかったっけ?
DXGraphicsはフォーカス外れてWindowsになんか描画処理されるとVRAMとかロストするでしょ。
再取得するイベント用意すればいいのに、
昔ながらの一直線コードで書いてるから最初に初期化するだけで、
「フルスクリーンで動作させてるんだからフォーカス変えるんじゃねヴォケ!そんな真似する奴の事なんか知らんわ!」
って発想でなぜかWindowモード用とFullScreen用二つの実行ファイルがある同人ゲームを見たことがあるなぁ。

ぶっちゃけDX1からずっと見てる者としては、DX開発チームの奴をグーで張っ倒したくなるのは俺だけですか?
仕様変更云々じゃなくて、「公開するんだったら全部公開しろ! 隠すんなら責任もって処理しろ!」って言いたいトコたくさんあるんだが。


>>282
まずポインタ参照で相互操作なんて処理はさせない。
ハンドル(ID)使って外部で処理。
どうしても必要ならもう一個上位のクラス作って管理させるか。
そもそも実行時に消滅する可能性のあるポインタへのアクセスはよろしくないだろう。
消滅プロセスの時になんか処理するような設計しちゃだめなんじゃないかな?

290 :仕様書無しさん:04/11/27 18:23:37
>>285
それを設計レベルで回避するのはいまどきじゃないよ
設計が関わってくると変更が難しくなる、ポインタの実装で回避できるので実装で回避すべき。
そうしないと、仕様変更の激しい開発ではボロボロになってしまうよ。

291 :仕様書無しさん:04/11/27 19:15:44
>よく、DirectXでデバイス初期化してLPD3DDEVICEを各クラスで保持してて
>Alt+TabされるとLPD3DDEVICEが無効化しててアボーンってなるプログラムを
>みかけるけど、アレがポインタの一番まずい死に方w
>何が駄目だったのかというとLPD3DDEVICEを保持するとかいう奇行が駄目だったわけよ。
>似たようなことしてプログラム組んでない?

アホ発言過ぎてワリタw

292 :仕様書無しさん:04/11/27 20:01:49
LPD3DDEVICEを保持しないって、まさか使うときにいちいち再取得するのか?
LPD3DDEVICEが無効化する可能性って、極めて致命的なエラー出るような状況でないとありえなくないか?
もしかしてD3DX使いまくりメンなのかな?

293 :仕様書無しさん:04/11/27 20:17:34
Alt+Tabされた時に復活させりゃ良いだけの話だと思うが・・・


294 :仕様書無しさん:04/11/27 20:50:06
上げ足取りしか出来ないのかよ(w

295 :仕様書無しさん:04/11/27 21:38:41
で、ドラクエは買った?
今回はちょっとやってみたい衝動に駆られたが買わなかった。

296 :仕様書無しさん:04/11/27 21:51:24
>>294
揚げ足を取って欲しいのか?

297 :仕様書無しさん:04/11/27 22:05:38
揚げ足とられたくなかったらアホなこというなよ

298 :仕様書無しさん:04/11/27 22:42:44
良い設計って難しいよね。

C++の高度な機能やSTL/Boostを駆使した設計が良いとは限らない。
なぜなら使う側のプログラマの理解が追いつかないから。
理解が曖昧なまま使うと余計なバグを生みやすくなるし、学習コストもかかる。

結局ハンドルで抽象化した複雑なライブラリより、関数一発で値が取ってこれる設計が好まれるわけよ。


299 :仕様書無しさん:04/11/27 22:49:01
それを設計の問題とはいわないw

300 :仕様書無しさん:04/11/27 23:52:30
>>292
Alt+Tabや解像度変更で無効化は簡単におこりますが何か?

301 :仕様書無しさん:04/11/28 00:05:23
>>286
>いや、LPD3DDEVICE 自体は機能として無効化するだけで、
>そのポインタをアクセスしても問題ないです
そういうプログラム組んでると伸びないよ。
「そのポインタをアクセスしても問題ないです」とか言ってるけど、
これは「プログラムは落ちないです」って言ってるようにしか聞こえないんだけど。
実際、その無効化したポインタをアクセスしたときにアクセスしたクラスの動作はどうしてるの?
アクセスしたクラスにはLPD3DDEVICEが無効化されたときにする動作を定義してあるの?

これはさ、何処でも起きる問題なんだよ。
例えばホーミングミサイルなんか作ってターゲットをポインタで保持してて、
敵の存在の有無をポインタの無効化で判断してるような設計でしょ?

302 :仕様書無しさん:04/11/28 00:18:01
>>298
> なぜなら使う側のプログラマの理解が追いつかないから。
底辺に合わせていたら、先がありませんぜ。教育しましょう。

303 :仕様書無しさん:04/11/28 00:19:34
>>302
高所に合わせすぎたらコストがかかるからバランスを考えましょう、という意味だ

304 :仕様書無しさん:04/11/28 00:20:47
>>301
デバイス(あるいはハンドル)が無効になるのと、ポインタが無効になるのは
全く別の話だと思うが。

後者だと不正なメモリアクセスが発生してプログラムが死ぬ可能性があるが、
前者だと想定通りのエラー処理をしておしまい。

305 :仕様書無しさん:04/11/28 00:29:43
ただまあ、逆に言えば寿命の保証さえクラスのコンストラクト順ででもなんでも
保証されてりゃ一向に構わないわけでもあるわけで、あんま拘泥しても
大して益のある話じゃない。
スタックで済ませられるところはスタックで書く様にする程度のことで、
上の生ポインタとその管理寿命云々の話は、少なくとも問題の顕在化は
ほとんど避けることができてしまう。

SmartPtrの類も使ってりゃいいってもんでもなく、今度はリソースが残り続けて
メモリたんねえよ処分のタイミングどうしましょみたいな間抜けな事態招く
素敵なプログラムはいくらでも書き得るわけだし。


最近のHDD搭載ゲームプログラム的には美味しいネタとしては、この手の関節参照の手段として、
参照カウンタつきの配列インデクスを「ハンドラ」に固めて、リソースマネージャ
(シングルトン化しとく)に一々問い合わせに行く方法がある。

これの美味しいところは、テクスチャマネージャの状態さえ丸々復元可能
(管理IDの何番目に何のテクスチャが入ってるか控えておく)になってれば、
テクスチャハンドラ自体は例え再起動なりなんなりでメモリ内容変わっても
変わらず復元可能なこと。

FPSみたいに、死亡〜即復活みたいなスナップショット型のセーブデータ形式
考えたりする時には常套の古典的手法。
アホみたいに単純だけど利益は絶大。
ゲームキャラの座標とかHPとか保存するのと同じように、構造体丸々控えるだけで
シーンで何のテクスチャ使ってんのかとかまで復元できるようになる、

つまりまあ、適材適所で色々考えて使えや、でもあんまし無駄にこだわりすぎても
窮屈なだけですよー、てとこだろか。

306 :仕様書無しさん:04/11/28 10:02:09
つまりまとめるとDirectX作った奴は屑、と

307 :仕様書無しさん:04/11/28 12:06:17
>>306
あんなもんだと思うぞ。

308 :仕様書無しさん:04/11/28 12:09:56
俺はクズだといいたいがな。
いつだったかのバージョンでは定数だか構造体だか誤字のままリリースされてたし…

309 :仕様書無しさん:04/11/28 12:10:03
>>306 いや、そうじゃないだろ。
まとめると、ポインタ管理の実装にはいろんな手段があって、それぞれに目的や前提条件も違うので
ポインタの管理はこうすべきなんですよね??などと聞いてもしょうがないし、この手法がまずいよなんてことも言えない。
つまり、ぶっちゃけて言うと

 ま ぁ 、 好 き に や れ や

てことかとw。

310 :仕様書無しさん:04/11/28 15:42:20
いろいろ参考になりました。(LPD3DDEVICEは置いといて)

結局適材適所ってことになりそうなんで、改めて具体的に聞かせてください。

同系統のオブジェクトの集まりの中にAとBがあり、そのどちらもいつ死ぬかわからないとする。
(したがって生ポインタやリファレンスを直接保持することはできない)

このときAがBを参照する必要がある場合(その逆や相互参照も考えられる)、
不正アクセスを起こさないためにどのような手法が考えられるか?
(寿命がわかっていて順番付けできるのであればこのような心配は無いはず)

1.ハンドル(数値、クラスなど)からポインタ(NULL可)に変換し、
 必要であればキャストして使用する。ハンドルは唯一無二とする。
 管理できる数に制限がある?

2.仲介クラスのようなものを用意し、参照元と参照先を管理させる。
 参照元は自分と参照先を仲介クラスに登録し、返されたIDを使って参照先のポインタを必要なときに取得する。
 (結局ハンドルと一緒?)
 仲介クラスも登録されたオブジェクトを不正アクセスしないように注意する必要があり、
 登録されたオブジェクトは仲介クラスに自分が死ぬことを伝えなければならないなど面倒。

3.参照カウンタを導入する。
 相互参照している場合、解放されない事態に陥る。
 一箇所でも解放し忘れると芋づる式に解放されず、管理が難しい。

4.オブジェクトの集まりから、参照先を逐一取得する。
 オブジェクト一個ごとに固有のID付けが必要、条件検索ができるようにする。
 基本的に毎フレーム取得(検索)する必要があるのでコストがかかるが、
 数が少なければ気にするほどでもない?

自分が思いつくのはこんなところで、1か4あたりが有効だと思いますが、
ほかにはどのような手法があるでしょうか?

311 :仕様書無しさん:04/11/28 16:08:43
>>310
検索のコストは std::hash_map とか使っておけば、あまり気にしなくて OK。

2, 4 いずれにせよ、オブジェクト死んだときに管理クラス側に通知して、
対応する ハンドル (ID) を無効化する手続きが必要になる。やりかたとして

1. オブジェクトから管理クラス側のメソッドを呼び出して無効化する
2. 管理クラス側からオブジェクトに問い合わせて、無効になっているか
 確認する

と二通り考えられる。

インターフェースと実装の分離を徹底すると、同一のオブジェクトを複数の
管理クラスに登録する機会が出てくるので、俺は後者にしてる。寿命管理は
参照カウントをオブジェクト側に持たせて、管理クラス側から削除するときに
参照カウントを減らす (Win32 の COM と同じ方式)

312 :仕様書無しさん:04/11/28 16:09:33
>>310
>同系統のオブジェクトの集まりの中にAとBがあり、そのどちらもいつ死ぬかわからないとする。
そもそもこの前提がありえない。

解決策としては1か2になるが、文章を読む限りド級の馬鹿のようなのでツッコミはしないw
もはや一生てめぇ1人で悩んでろよアフォっつった感じw

オブジェクトの生存期間はプログラムを動かす前(組む前)に必ず決まる。
片方が消失して片方がその消失した事実を知らないなんて構造は設計が間違ってる。

ていうか、設計でこれを解決しないで何を設計しとるのかと。
ごちゃごちゃ悩む前にLPD3DDEVICEをグローバル変数やらポインタ保持しないで管理してみろよ。
Alt+Tab押しても平気なようによw

313 :仕様書無しさん:04/11/28 16:11:02
>>310
だから好きにやれよ。

>不正アクセスを起こさないためにどのような手法が考えられるか?
"そのどちらもいつ死ぬかわからないように"するな。
そんなやつにアクセスさせるな。

答えなんか基本的に一つしか出せないだろう。
どこが具体的? そんな抽象的な説明じゃなんともいえないと思うが。

314 :仕様書無しさん:04/11/28 16:28:49
>>310
おれっち流の解は、A B を強参照でコンテナに入れておく。
A から B または B から A は弱参照で参照。
オブジェクトの破壊はコンテナ中の強参照をnullクリアして破壊、
もしくはデストラクタで強参照をクリア
ってな感じかな?

>>312
そーんな事いってるとどんどんロートル化すんよ〜
知る必要が発生したときに知る事ができるというのは楽なんです。
組む前に決めると完成する前に疲れ果ててしまいます。


315 :仕様書無しさん:04/11/28 16:33:21
>>314
こいつは駄目な例だなw

316 :仕様書無しさん:04/11/28 16:34:44
はいはい、こまりましたね〜

317 :仕様書無しさん:04/11/28 16:45:53
リリースが少ないんだったら、全検索して自分の参照を切る、ってのもありだし、
自分が複数から参照される事がないんだったら双方向にして、
自分自身が消滅する前に消滅通知を出すとか・・・

いずれにせよ、そんなもん組めよ、四の五の言わずに

318 :仕様書無しさん:04/11/28 16:49:50
>>314が言うほど駄目とは思わないが、
そのまえにいつ死ぬかわからないのにAからBを直接参照する可能性がある設計自体に問題があるということを310は理解しろな。
前提条件が駄目なことを要求してるから、回答も駄目な物になるのは仕方ないとは思う。

319 :仕様書無しさん:04/11/28 16:56:21
元々の要求仕様がどんな物かによるだろうが。
大元の設計がそのような現象を発生しないように設計するに賛成。
試しに上の仕様を出してみないか?
相互参照の内容により1〜4も有りえるし違う解決策も有ると思う。

320 :仕様書無しさん:04/11/28 16:58:29
こんなくだらない事を設計でやるなんて……
悲しくなってきます

321 :仕様書無しさん:04/11/28 17:00:54
>>318
いつ死ぬか分からんというのは設計としてダメだろう、というのは同意。

でも、同一インター内で死ぬことは確定しているんだが、その順序を
確定したくない(仕様変更が入ったときに面倒なことになるのが目に
見えてるから)ってのはあるな。

俺の場合、ホントに汎用的なものなら抽象度が高いメッセージ通信
システムを作り、必ずそれを介して情報をやりとりするように書くが、
特殊なモノだとスマートポインタでよろしくやって終わりってことも多い。

322 :仕様書無しさん:04/11/28 17:03:12
>>321
逆だよぉ、特殊なものはスマートポインタ使わんほうがいいよ
どうでもいいもんに使っとけぇ

323 :仕様書無しさん:04/11/28 17:10:37
単に親子関係で済むことを、わざわざ同列に扱おうとしてはまってる気がしないでもない。

324 :仕様書無しさん:04/11/28 17:16:52
>>311
いいヒントになりました。

「いつ死ぬかわからない」という言い方が誤解を招いたかもしれません。
→どのタイミングでオブジェクトが無効化するのかが不定

オブジェクトが直接deleteされるのではなく、一旦無効化フラグを立て、
オブジェクト管理クラスでそのフラグが立ったオブジェクトを
毎フレーム一括deleteするという仕様です。

なので、実際には無効化するきっかけが必ずどこかにあるので、
まったく不明ということはないです。


325 :仕様書無しさん:04/11/28 17:26:56
>>324
その答えと、相互参照している場合の不正アクセス対策とどう関係が有るか分らないな。
一体何が聞きたかったのだろう?それともあんたバカな展開か。w

326 :仕様書無しさん:04/11/28 17:28:36
結局さ、判定入れる場所は2箇所しかないでしょ

・オブジェクトが死んだ瞬間に判定、自分自身を保持しているクラスに終了通知
・オブジェクトを使う瞬間に判定、そのポインタが有効かチェック

あとは、設計や処理速度、メモリと相談だろ

327 :仕様書無しさん:04/11/28 17:53:40
>>325
答え?

その文章は単に「いつ死ぬかわからない」に対しての説明であって、
「相互参照している場合の不正アクセス対策」とは直接関係ないですよ。


>>326
そうでしょうね。


結局、考え方はみんな同じで、実装方法が違うだけなんでしょうな。
間接的にアクセスするってことで。


328 :仕様書無しさん:04/11/28 18:14:23
旅行にいく目的地は決まっていて、
車で行くか電車で行くか飛行機で行くか船で行くか、どのルートがいいんですか?
と聞いたわりには、そのレスなのか

329 :仕様書無しさん:04/11/28 18:19:41
>>328
ルートなんか聞いてないし、どのルートが最善なのかなんで聞いてない。
>282 をよく読め。



330 :仕様書無しさん:04/11/28 18:25:57
だから好きにやれよw


331 :仕様書無しさん:04/11/28 18:37:40
>>327
326の最初の方法は直接アクセスしているわけだが

332 :仕様書無しさん:04/11/28 18:45:54
よく見たらこのおばかちゃんのネタで50レス進んだんでつね

333 :仕様書無しさん:04/11/28 18:47:42
>>331
間接的にアクセスしているともとれるよ。


334 :仕様書無しさん:04/11/28 18:51:13
>>332
進んでよかったな。
もうこれで終いにするよ。


まぁある程度回避策はわかってるんだけど、
みんなどんな風にやってるか聞きたかったわけ。
ただそれだけ。

別に議論する気も無いし、手法に優劣つける気はさらさらない。
出てきた使えそうな情報をチョイスしていくだけ。

まともに答えてくれた人ありがとね。参考になったよ。


変なイチャモンつけてくる奴は不思議だよなぁw
まったく質問の意図がわかってない。


335 :仕様書無しさん:04/11/28 18:54:06
>>334
コイツが俺の同僚なら殴る!

336 :仕様書無しさん:04/11/28 18:55:50
まぁゲームプログラマーやってる奴は全員「俺の人生はこうなるはずではなかった」
っていう思いをもっているからこういう場所で発散する必要があるんだよ。

337 :仕様書無しさん:04/11/28 18:58:10











ツレタ

338 :仕様書無しさん:04/11/28 19:32:41
しかしほんと真面目に答えてる人がいるならすげぇと思うなぁ。
利根川先生のAAキボン

大 人 は 質 問 に 何 一 つ 答 え た り し な い

俺的には上のレス見てみんな上っ面しか答えてないように見えるが、
>>334には答えになったらしい。


339 :仕様書無しさん:04/11/28 20:06:09
まあABが相互参照していて、どちらか片方が死ぬなんていうシチュエーションはゲームならよくある。
敵A,敵Bが相互に相手を見ながら動いていて、片方がプレイヤーに殺されるとかね。

まあ、そういう時は死亡通知期間を設けることが多い気がする。
つまりAが死んだ後、deleteは次の次のフレームの先頭でマネージャーがする。
1フレーム間はBはAが死んだことを確実に知ることができる。

まあハンドル使ってもいいんだけど、手間とメモリとオーバーヘッドがかかるからね。


340 :仕様書無しさん:04/11/28 20:13:18
タスクシステムだと相互参照解決できねーな

341 :仕様書無しさん:04/11/28 20:18:10
>>339
>まあABが相互参照していて、どちらか片方が死ぬなんていうシチュエーションはゲームならよくある。
>敵A,敵Bが相互に相手を見ながら動いていて、片方がプレイヤーに殺されるとかね。
そんな簡単な処理に相互参照なんかするのか、頭悪いな。

342 :仕様書無しさん:04/11/28 20:22:29
するだろ。
だが片方が居なくても差し支えないように作る、それだけだ。

343 :仕様書無しさん:04/11/28 20:24:58
>>341
簡単な例を上げただけ。
実際はもっと複雑に絡み合う。
それがゲームプログラミングというもの。


344 :仕様書無しさん:04/11/28 20:28:58
>>342>>343
>実際はもっと複雑に絡み合う。
そんな事は、藻前らの考える相互参照の方がよほど複雑になるんだがな。
そんな設計しか出来ないから、あんな質問があるんだろ。
マジ勝手に悩め。

345 :仕様書無しさん:04/11/28 20:34:38
>>344
はいはい。
本当にちゃんとしたゲーム作ったことある人?
あーんなゲームや、こーんなゲームもそんな設計になってるんだけどね(ワラ

まあ理想論だけじゃゲームは作れんってこと。



346 :仕様書無しさん:04/11/28 20:37:20
今までの話を総合すると。
・シューティングゲームで
・単純タスクシステムで総てをやろうとして。
・敵機が相互に動いてるので、相互参照してコントロールしようとして。
・泥沼にはまっている素人。

以上!

347 :仕様書無しさん:04/11/28 20:39:47
>>344
第三者だが、複雑になんかならんよ
ちょこっとスマートポインタの知識があれば考える必要すらない本当にばかばかしい話。
多分はまっているのはこういった細かい所まで設計に凝ろうする貴方のほう。
ちなみに昔自分もそんな風に考えていた頃があったので、なんとも見てて痛い気分。

348 :仕様書無しさん:04/11/28 20:41:47
>>346
そういう時は、複数の敵を見て制御するコントロールタスクを作ると良いよ。


349 :仕様書無しさん:04/11/28 20:47:41
やさしい>>348が出たな、藻前ら勉強しろよ。

350 :仕様書無しさん:04/11/28 20:50:00
C++を覚えたてのころは、設計に凝りたい時期って誰にでもあるよね。
敵はクラスで仮想関数にして、状態ごとにステートクラスを作って、大量にマネージャー作ってとか。

ま、結局ガチガチに固めると仕様変更に直面するたびに破綻していく現実に直面するわけだけど。
なんで、洗練されたゲームほど基本部分はシンプルな設計になっていることが多いね。

まあ、一度は通らなきゃらなない道だとは思う。


351 :仕様書無しさん:04/11/28 20:52:35
バカに付ける薬は無いな。

352 :仕様書無しさん:04/11/28 20:53:42
と、井の中で申しております。

353 :仕様書無しさん:04/11/28 23:25:19
>>350
> ま、結局ガチガチに固めると仕様変更に直面するたびに破綻していく現実に直面するわけだけど。
がちがちに固めないために、インターフェースと実装を分離して
それぞれにインターフェースを管理するマネージャクラス作る
のだと思うが。

何でもかんでも単一のマネージャクラスに突っ込むと、それこそ
後で辛くなる。

……って、そういう話じゃないのかなぁ。みんな書いてることが
断片的なんで、何を話してるのか良く分からんが。

354 :仕様書無しさん:04/11/28 23:33:53
なんかプロジェクト移動して
前のプロジェクトとオブジェクトの意味を全く違う意味で使ってる状態に似ているな

355 :仕様書無しさん:04/11/28 23:36:10
オマエの設計が悪い、と決め付けるヤツはすごいな。
なんで自分が間違ってるのかもしれない、とは露ほども思わないの?

今までの自分の知識は絶対、とか思わない方がいいよ。
年取ると思考が硬直化するもんだけど、そのままじゃ置いてかれるよ。

356 :仕様書無しさん:04/11/28 23:59:30
設計や言語仕様に五月蝿い奴に限って、生産性低いんだよなぁ。

C++知らない人が多いからって理由で未だC言語でやってるチームもあるけど、
それも一概には誤った選択とは言えないところがまた。
C++を導入したがいいが、収拾つかなくなって失敗したプロジェクトとかあるし。

まあ、メンテナンスなんてしねーし、移植は外注に投げるし、
設計の美学なんかより、動いてなんぼってぐらいが実はうまくいったりする。


357 :仕様書無しさん:04/11/28 23:59:56
>>355
同意

物事は、柔軟に考えなくては。。。

トレンドだからといって最新の技術ばかり追って、
どれも身になっていない奴がうちの社内にいる。
そういう奴に限って、
「○○さん!そんな手法は古いっすよ」なんて吐きやがる。

うんじゃ、その新しい手法使って書いて見れといいたい


358 :仕様書無しさん:04/11/29 00:12:26
以前、PS1の仕事を下請けに出した事があるのだが、
その会社は、そのプロジェクトで C++つかっていて、
new、delete 使いまくりだった・・・
てっきり、独自にメモリ管理の処理を作成したのかと思って
いたのだが、仕様の変更や、追加をお願いする度に、
「メモリ足りないのでこれ以上仕様追加できません」
なんて言われてさ、
そんなまだ開発の序盤じゃん!何で?って思っていたのさ。

で、そのプロジェクトが1年延び、2年延び
(延びたのは開発会社だけの責任ではないのだが・・・)、
いよいよクライアントから怒られちゃって、
あと数ヶ月で完成させないと、賠償問題ですよ
なんていわれて。。。

で、そのプロジェクトをうちの会社で引き受けたのだが、
new、delete は、虫食いの事も考えず使っていようで、
ガックリきたよ・・・
そりゃ、メモリ足りないはずだよって・・・



359 :仕様書無しさん:04/11/29 00:14:03
C++の問題じゃないじゃん

360 :仕様書無しさん:04/11/29 00:23:37
>>359 上の文章読んで、なんでC++の問題だって思うんだ??
使えもしない新技術に飛びつきたがるヘボPGがいたって話だろ?

361 :仕様書無しさん:04/11/29 00:26:40
>>360
何がいいたいのかさっぱりわかんね

362 :仕様書無しさん:04/11/29 00:32:22
>>360
C++じゃなくてC言語使ってても同じ結果になるだろ…

363 :仕様書無しさん:04/11/29 00:34:40
なんかもう痛すぎ

364 :仕様書無しさん:04/11/29 00:41:48
>C++を導入したがいいが、収拾つかなくなって失敗したプロジェクト
WindowsNTのことかぁッッッッッッッッ!!!

365 :仕様書無しさん:04/11/29 00:45:38
http://www5e.biglobe.ne.jp/~hiro-har/seed8.htm
>「ああっ!」
>
>「や〜い、5文字〜」

>「今週は出番ねえし、ドラクエでもやるか」
>
>「うむ」
>・・・・・・

ウケタw
プログラマ的にどうよ?
この制限w

366 :仕様書無しさん:04/11/29 00:47:19
>>362
昔ながらに固定長配列+関数ポインタでやってりゃ大丈夫っしょ。
仮想関数使ったはよいが、operator newをオーバーロードするのを知らなかったとかそんな落ちでしょうが。



367 :仕様書無しさん:04/11/29 01:04:03
358 ですが、

仕事中に書いていたのもで、あまり考えず書いてしまいました。
詳しく書くと、関係した方々(とクライアント)にばれてしまうので
かけないのですが・・・

もともと、そこの開発会社は、ウィンドウズしかやった事無い会社で、
あまり、メモリとかの事を考えず作っていたようで、引継ぎをした
ソースはそりゃ物凄いものでした・・・

1から作り直しました。

っていうか、スレ違いな話に・・・・

まぁ、そこで、プログラマ諸氏に質問!!
というわけで、実は、この2年以上かかったプロジェクト
実は4ヶ月で作り直したのは、ゲームを買ってくれたお客様には
内緒なんですが、そんな感じの体験をした方いますか?


368 :仕様書無しさん:04/11/29 02:08:50
いるかいないかつったら、いるよ、ここに。
4年かかって作ったものを手渡されて半年でゼロから作り直した香具師らの一人が。

まあなんつーか、最初ッから作るものわかってて迷走する余地がなければ
実際の作業量はそんなもんなんじゃねーの?って感じで面白かった。

369 :仕様書無しさん:04/11/29 02:26:04
1年かけて2Dで作ってたマップを3ヶ月で3Dに組み直したことはある。
つっても死んでたのはデザイナの方だったがな。

370 :仕様書無しさん:04/11/29 03:04:16
358 です

>>368

確かに面白くはあったけどね・・・
迷走の余地がなかったから、
俺を含めたプログラマ達は、コード
打ちマシーンと化してましたね・・・

あれで、かなりスキルがあがったと思うけど、
みんな燃え尽きました・・・


371 :仕様書無しさん:04/11/29 03:45:30
>>370
とりあえずもつかれと言っておく。

372 :仕様書無しさん:04/11/29 03:48:17
ドラクエ8ってプログラム的にはすごいんじゃないの?
ダンジョン内なら戦闘で読み込みまったく感じないし
メッセージスピードが変えられないのも理由があるんだろうなぁ
こういう話しが知りたいけど、ゲーム雑誌とかじゃ絶対に載らないよね
企業秘密とかかな

やっぱプログラマーの人ってゲーム遊んでても、ここどうやってんだ?
とか思ったりするんでしょうか
ストーリーとかより気になっちゃったりして

373 :仕様書無しさん:04/11/29 03:58:55
Professional Game Programmingとかって本でもだしゃいいのに。
まともな技術と文章力もった人材が日本にはいないだろうけどさ。
各社技術的蛸壺に引き篭もってて生産性が悪いったらありゃしない。

374 :仕様書無しさん:04/11/29 04:22:11
>>372
そりゃすごいけど。
部分部分をとってすごいだのどうやんだろうなどとは思わないな。
全体の構成やら、安定したシステムやら、ボリュームとか
すごいってのは総合的に出てくるもんだしゲームなんかやっても
勉強になんかならないよw

375 :仕様書無しさん:04/11/29 07:41:58
>>372
> ダンジョン内なら戦闘で読み込みまったく感じないし
シンボルエンカウントじゃないからねぇ。

あれは「敵と出会ったら読み込み開始」ではなく「読み込みが終わった
時点で戦闘開始」にしてる予感。

376 :仕様書無しさん:04/11/29 10:25:06
うちのPS2は初期型だから、動作音が戦闘開始の合図。
それよりも、戦闘終了から戻るときがどんくさいのですが、新しい型番ではさくさくなんでしょうか?

詳しくないのですが、あの遠くのものがやがて近くなるってマップはミップマップの延長に近いのでしょうか?

377 :仕様書無しさん:04/11/29 11:55:33
LPD3DDEVICEが、ポインタとして無効になってるのか、
デバイスが無効になっているのか、はっきりさせろ。


378 :仕様書無しさん:04/11/29 13:01:31
>>375
なるほど、ちょっと目から鱗

379 :仕様書無しさん:04/11/29 13:07:00
ポポロクロイス?

380 :仕様書無しさん:04/11/29 13:09:06
>>376 DQ8は会話ウィンドウが1フレ遅れて消えるのが気になる。

381 :仕様書無しさん:04/11/29 13:42:45
DQ8は、奥のキャラクタが突然現れるので違和感がある。
離れたところから見て「店に誰もいねえな」と思いながら
近づいたら突然キャラが出てきた。
LODしてないのかな。

プログラム的にはDQ8は「すごい!」ってとこはない。
よく作ったよなあ、と思うだけ。デバッグ苦労したんだろうなあ。

382 :仕様書無しさん:04/11/29 13:59:33
>>よく作ったよなあ、と思うだけ。デバッグ苦労したんだろうなあ。
んー。それは「すごい!」には当たらないの?

383 :仕様書無しさん:04/11/29 14:01:25
歴代のDQ総じて1、2くらいしか「すげぇ!」って思えるような要素無くない?

384 :仕様書無しさん:04/11/29 14:34:45
DQ8はやっぱあのグラフィックをそのまま3Dで作ったのに感動したな
ゼルダなんかは最初違和感ありまくりだったけど(で、慣れたけど)
DQはSSみてああ、DQだ、って感じの印象をそのまま保っているし

385 :仕様書無しさん:04/11/29 14:43:20
>>383
1、2に触れたときの手前の年齢と職業を求む。

386 :仕様書無しさん:04/11/29 16:07:24
HLは中身がない
DQは技術がない
喪前らどっちにしても褒めないのなw

387 :仕様書無しさん:04/11/29 19:15:11
開発期間があれだけ長いと技術的に遅れたものになるのは仕方ないだろう。
おまいら有名なデモと比べてるんだろうし

388 :仕様書無しさん:04/11/29 19:20:18
尖った技術的 (デモ系) には DQ はたいした事ないんだろうけど、
バックグラウンドで読み込んで読み込み終わったら敵とエンカウントとか
やってるのは (>>375 が言っているのが正しければ) 技術的にすごい事だと
おもうけどねぇ。

より多くのポリゴン出すとかじゃなくて、そういうところに
気がついて作り込めるプログラマになりたいなぁ。私は。


389 :仕様書無しさん:04/11/29 19:22:20
>>372
ところで、一昔前のゲーム雑誌には結構「プログラムで
こんなところ苦労しました」みたいな話をしている
プログラマが記事になっていたような気がするんだけど
最近はそうでもないのかな。

大昔に雑誌に載った時にそのへんをうきうきと話そうとしたら
どうも、そんな空気では無かったので別の話をしていたけど…。


390 :仕様書無しさん:04/11/29 19:26:43
>>382
ゲームのデバッグは外注やボランティアの人の方が頑張ってるからなあ…

391 :仕様書無しさん:04/11/29 20:59:07
>>383
DQ の凄いところは、技術じゃないからなぁ。一つのことが片づくと
すぐ目の前にもう一つ片づきそうな課題が出てくる、ついつい手が
離せなくなってしまうイベントの配置とかバランスが素晴らしい。

でも俺なら 5 年も同じプロジェクトに関わりたくないが。

392 :仕様書無しさん:04/11/29 22:35:25
8の開発は実質3年ぐらいじゃね?

393 :仕様書無しさん:04/11/29 22:40:52
ドラクエなんて正直どうでもいいよ。
もっと綺麗なドラクエがみれると思ったら
予想の範囲内だし。

394 :仕様書無しさん:04/11/29 22:49:26
別にゲームでもなんでもそうだけど、考えた人が凄いのであって、
プログラム作った人なんでカスだろ。
誰でもいいんだよ。どうせ外注に出すだけだからな。


395 :仕様書無しさん:04/11/29 22:57:07
じゃあゲームプログラマ的に凄いゲームって例えばどれ?

396 :仕様書無しさん:04/11/29 23:00:02
フランツーリスト

397 :仕様書無しさん:04/11/29 23:09:24
>>394
外注は難しいぞ。マジで。

398 :仕様書無しさん:04/11/29 23:33:03
ドラクエのグラフィックって既存のゲームと同程度なの?
PS2のゲームって最近みてないけどレベルあがってるんだな。
一応、影もそれなりのがついてるし。

399 :仕様書無しさん:04/11/29 23:36:27
PS2はICO以降進化が止まってるな

400 :仕様書無しさん:04/11/29 23:46:19
ドラクエ8は輪郭のぼやけた影がバリバリ動いてるみたいだけどどうなってんの?
買った人教えておくれ。

401 :仕様書無しさん:04/11/30 00:19:16
へー、ソフトシャドウやってるんだ。
PS2のフィルレートに任せて半透明重ねまくりで書いてるわけじゃなくって?

402 :仕様書無しさん:04/11/30 01:09:25
>>399
そりゃ、技術的に頑張れば製品が差別化できる時代は終わったから。
見た目に関してはもはやプログラマより、デザイナさんのがんばりに
掛かってる。


403 :仕様書無しさん:04/11/30 01:15:38
まさにドカタ

404 :仕様書無しさん:04/11/30 01:17:13
>>400
ドラクエ8の影は、シャドウボリュームで影領域を算出した後、
ポストプロセスでブラー処理して輪郭をソフトにしている様子。

カメラ手前に来ると影がパキッと消えるし、真下に近い位置に落としているので、
ラバストなシャドウボリュームではなく単純に視錐台カリングっぽい。


405 :仕様書無しさん:04/11/30 07:36:02
階段に落ちる影を見て一瞬吐きそうになった。w

>>394
かくいう手前もPGじゃねーの?

406 :仕様書無しさん:04/11/30 09:19:20
プログラマなんてもともと縁の下の力持ち。日陰者。
コンピュータゲーム黎明期が異常だっただけ。

407 :仕様書無しさん:04/11/30 11:50:41
DQ8のフレームあたりポリゴン数はFFと比べて多少少ないのでは?
奥のキャラがおきなり登場するのもそうだが、店員との会話時の
キャラ配置が悪いと(奥まで視界が開いている状態)、文字描画が
遅くなる。
あるいは、あの絵柄を実現するために結構なポリゴン数が使われてるのかな。

408 :仕様書無しさん:04/11/30 14:57:41
情報学科の学生でこれから就職活動なんですが、コンピュータがすごい好きって感じではありません。
コンピュータがそんなに好きではない人がプログラマーになってもやっていけないでしょうか?
僕みたいな人がIT関係の仕事に就こうと思うと営業になってしまいますか?
教えてください。


409 :仕様書無しさん:04/11/30 15:07:27
>>408
その前に好きなものを教えてくれないか。

410 :仕様書無しさん:04/11/30 16:01:23
スカトロ

411 :仕様書無しさん:04/11/30 16:56:04
好きとか嫌いとか最初に言い出したのは誰なのかしら?

412 :仕様書無しさん:04/11/30 17:05:26
好きとか嫌いとかはいい。
う○こを食べるんだ。

413 :仕様書無しさん:04/11/30 17:10:50
大手のSEとかならなれるんじゃないの。

414 :仕様書無しさん:04/11/30 18:11:46
スカトロジストに?

415 :仕様書無しさん:04/11/30 18:17:56
>>408
好きでもないけどやってる奴なんて山ほどいるよ。
オタ的なくだらないこだわりがない分良い仕事する人もたくさんいる。

ただ、それとは関係なく大きいところに入ると故人の遺志が
無視されて営業に回されることもあるらしいね。

416 :仕様書無しさん:04/11/30 18:26:57
やっぱりただの七光りだけじゃ親が死んだらそれまでだよね

417 :仕様書無しさん:04/11/30 19:44:31
>>480
仕事として選ぶのならゲーム業界はやめといたほうがいい。
最初の職場は大事だよ。多かれ少なかれ、その職場の雰囲気に
染まってしまうからね。

418 :仕様書無しさん:04/11/30 20:35:51
預言者キター

419 :仕様書無しさん:04/11/30 21:27:40
予言してほしいのか?
だったら言ってやるが
あと5年もするとプログラマなんかよほど優秀な奴以外みんなリストラ

420 :仕様書無しさん:04/11/30 21:54:15
ソフトウェアクライシスはどこへ行った


421 :仕様書無しさん:04/11/30 22:04:16
>>419
5年じゃ無理だよ。藻前、IT業界の惨状を知らんだろ。
あと、10年以上はかかる。下手すると、もっと必要になる
とさえ言われているぐらいなんだが・・・


422 :仕様書無しさん:04/11/30 22:24:29
日本の場合、不況だ不況だなんて言われていても、
一般人が簡単に、パソコンや携帯電話が買える国だからな。
こんな国、他には無いぞ。


423 :仕様書無しさん:04/12/01 00:03:18
物体の衝突が関係するゲームやシミュレーションを作るとき
いわゆる「めり込み衝突」が厄介すぎて困っちゃう件について。

1)イベントドリブン方式:
衝突発生時間を計算してそこまで移動→衝突処理→残り時間まで繰り返す
(参照 http://www.se.cs.titech.ac.jp/~oda/tips/billiard.html#eventdriven

2)時間巻き戻し方式:
めり込んだら時間を巻き戻す→時間刻みを小さくして再試行→
めり込まなくなったらそこまで移動→衝突処理→残り時間まで繰り返す

3)お気軽方式:
ループ終了時にめり込んでたら強制的に位置を補正→衝突処理
(ループ中の衝突は無視するので「すり抜け」が起こる)


衝突処理は漏れの手に負えない・・・orz

424 :仕様書無しさん:04/12/01 00:09:51
4.めり込まないくらい時間刻みを小さくする(or速さを小さくする)ってのは?

425 :仕様書無しさん:04/12/01 00:11:13
3

426 :仕様書無しさん:04/12/01 00:22:27
>>424
お前はゼノンか

427 :仕様書無しさん:04/12/01 00:32:50
壁との衝突ならともかく、
相手も動いてると(そして反射すると)もはや・・・

428 :仕様書無しさん:04/12/01 00:45:01
>>423
優先順位を付けて適当に押し戻す程度で良いって。

厳密にはおかしな挙動になるんだが、十分にそれっぽい振る舞いには
なる。シミュレータ作ってるワケじゃないので、そこにこだわる暇と CPU
時間があるなら、他に回した方が良いぞ。

まぁ、物理エンジンを売りにしているゲームを作ってる場合は別だが……。

429 :仕様書無しさん:04/12/01 01:09:11
>>423 制限付バネ&ダンパー処理でだいたいなんとかなる。
個人的には1の方法かなぁとは思うんだけど、ビリヤードの初期状態見たく
まったく同時に複数の物体にぶつかった場合なんかの処理が面倒なので適当にやってる。

#とかいいつつ、1)のサイト見てみたけど・・・もしかして計算式の妄想だけで実装してないのかよ!!!!!
#Javaアプレットもあの程度だし、本当にあのアルゴリズムを実装できてるのかはなはだ疑問。
#つーか、球同士の判定なら適当計算でもそれっぽくできるんじゃ!こんなの参考にもなるか!ぼけぇ!!!!

430 :仕様書無しさん:04/12/01 01:18:13
>>423
適当な処理だったら、3とかでもいいと思うけど、
相手も自分もかなりな速度で移動していた場合、
いろいろと厄介だから、1が良いと思う。

どんなものを作っているか次第だな・・・





431 :仕様書無しさん:04/12/01 01:23:13
>>423
1は、平たく言えば
全物体の移動ベクトルの交点を求めて、
一番近いオブジェクトの交点にぶつかっている地点を採用して、
あとは、同じ事を全オブジェクトに対して行ってやるって感じでしょ。



432 :仕様書無しさん:04/12/01 01:23:55
一番下のリンク先ワロタ

433 :仕様書無しさん:04/12/01 01:25:00
>>429
つうか、お前がはなはだ疑問。

あのページの内容たいした処理じゃないよ。


434 :仕様書無しさん:04/12/01 01:32:16
4)軌跡交差方式
移動の軌跡を線分として、他物体の軌跡との交差を判定。
ループ中は等速運動で近似してるので交点がわかれば衝突時刻もわかる。
線分が短いときの扱いに難あり。

5)斥力方式
一定距離内の物体には距離の2乗に反比例する斥力が働く(静電気力の公式)。
斥力にもめげずにめり込んだ場合、距離が近いため斥力が非常に大きくなり、
ものすごい速度ですっ飛んでいく罠。

435 :仕様書無しさん:04/12/01 01:35:56
距離が物凄く短くなると浮動小数点の精度や計算誤差が大きく影響してきません?
みなさん、そのへんってどうやって処理してます?

436 :仕様書無しさん:04/12/01 01:42:38
>>429
>制限付バネ&ダンパー処理

詳細きぼんぬ


437 :仕様書無しさん:04/12/01 01:45:22
世界の果てとの衝突なら3で決まりですな。
問題は大きな速度で小さな物体と衝突するとき。
無限精度の計算機があれば4でFAなんだが・・・。


438 :仕様書無しさん:04/12/01 01:52:15

どんだけの、小さいもんと衝突させて来たのか聞きたい


439 :仕様書無しさん:04/12/01 01:57:01
>>438
移動速度の絶対値が物体の直径より大きければ余裕ですり抜けるべ

440 :仕様書無しさん:04/12/01 01:57:40
>>436 基本的にめりこみをゆるしつつ、めり込んだ分はバネの処理ではねかえす。
めり込み量が大きくなると吹っ飛ぶのでダンパーとして適当に摩擦係数をかけて抑制。
あとは動きを見ながら発生する力や速度の最大値とかに制限を加える。

いわゆる、テキトーな俺様物理計算処理でつ・・・orz

441 :仕様書無しさん:04/12/01 02:06:03
典型的かつ現実的だと思うがなあ。
利点はいらんエネルギーを与えさえしなければ最終的に動きが勝手に収束すること。
動きの破綻も少ないし、位置関係の解決もそれなりにまとまるしで極めてゲーム向きだと思う。
メインで使わなくても、賑やかしの背景オブジェクトの動きとかに適用するだけでも
画面の動きの現実感は随分増すしねえ。

442 :仕様書無しさん:04/12/01 02:15:57
>>440
「すり抜け」対策はどのようにしてるの?

443 :仕様書無しさん:04/12/01 02:20:25
>>442
めり込み量としては検出できているのだから、すり抜けはしないよ?

444 :仕様書無しさん:04/12/01 02:20:46
改めて良スレだと思った

445 :仕様書無しさん:04/12/01 02:23:12
>>443
Σ(゚д゚) ハッ

446 :仕様書無しさん:04/12/01 02:25:12
>>439

移動ベクトルの交点を求めれば、すり抜けることは無いべ

447 :仕様書無しさん:04/12/01 02:25:43
>>446
つまり4の方式?

448 :仕様書無しさん:04/12/01 02:26:22
>>443
442じゃないけど、どういうことかわからん。
バカな私にどうかご説明くだされ orz

449 :仕様書無しさん:04/12/01 02:26:55
>>444
土日に雰囲気が一変するがな(w
前々から思ってたんだが、スレが時々異常に伸びるときって、方法論を戦わせてるだけか、
厨房が妙な煽りをかまして粘着してるときのどっちかなんだが、その厨房側って
お休みの現役プログラマなのか、学生さんなのか、どっちなのか判断に苦しむものがあるんだよな。

いや、別にどっちでもいいんだけどさ。

450 :仕様書無しさん:04/12/01 02:31:01
>>446 そこで浮動小数点の精度が問題になる。
交点を求めたはいいが精度のせいで微妙に重なっていたりするので
超低速での衝突だとか、複数の物体同士が極めて近い位置にいる状態で
玉突き状態の衝突が発生すると、突然へんな方向に跳ね返ったり、めり込み始めたり・・・

結局、適当なところで衝突判定をやめたり、切り替えていかないとしょうがないような気が。

451 :仕様書無しさん:04/12/01 02:43:37
>>450
なるほどね・・・

そういう時は、限りなく0に近い値は0と見なすとか、
やってたな、オレ


452 :仕様書無しさん:04/12/01 02:44:06
>>448 まず衝突判定って物体の位置を比べるだけじゃだめで、移動をベクトルとして判定するんだけど、その部分はOKだよね?

物体AとBがあるとして、あるフレームでAがA1からA2へ動き、BがB1からB2へ動いたとする。
ベクトルA1->A2とベクトルB1->B2の交点を求め、交差してれば交点をCとする。
物体の移動ベクトルが交差している=めりこみが発生したってことにして
ベクトルC->A2がAのめり込み、C->B2がBのめり込み量になる。
んで、めり込み量に応じてテキトーに反発処理を行う。

・・・単純に言うとこういうことかと。
#すりぬけもめりこみとして処理する訳です。

実際には点、線分、面など相互に衝突判定を行う要があったり、
空間を区切って絞り込んだりと色々面倒なのでつが・・・

453 :448:04/12/01 03:08:54
>>452
にゃるほど。ちゃんと交差の判定もするのね。ありがォ

454 :仕様書無しさん:04/12/01 03:16:53
>>453
何があったスネーク!スネー(ry

455 :仕様書無しさん:04/12/01 03:26:55
ありがてん?


456 :仕様書無しさん:04/12/01 07:53:12
>>434
すまん。4では間に合わなかったよ。w

>>449
「ききたい」だから、まぁ、それもよしでは、とおもってみたり。
つーか、盛り上がっているのが2:30スレと大して(ry

457 :仕様書無しさん:04/12/01 07:53:22
性欲を持て余す

458 :仕様書無しさん:04/12/01 08:07:20
>>442
速度に上限を設ける。1 インターでコリジョンサイズより大きな移動を
するのを禁止。

いや、そんなもんだって。

459 :仕様書無しさん:04/12/01 09:16:55
>>458
今の世の中、それは現実的じゃないなぁー

っていうか、あんたいつの人?

SFCとかの時は、そんな事やってたけど。

あー、あのころが懐かしい

460 :仕様書無しさん:04/12/01 10:46:05
>>459 安心しる。携帯アプリは今でもそんなもんだ。
とかいいつつ最近機種だとついに浮動小数に対応してきやがった。
3D化&大容量化の波がこっちまで来るのか・・・

ヽ(`Д´)ノ 1カ月ジャ作レネェシ モト トレネェヨ! ウワァァン!

461 :仕様書無しさん:04/12/01 11:54:40
>>458
そのゲーム斜め方向には√2倍速く移動できそうだなw

462 :仕様書無しさん:04/12/01 14:04:34
>>461
大多数の2Dシューティングはそうだね。

463 :仕様書無しさん:04/12/01 17:18:09
物理に忠実か忠実でないかがゲームの面白さに結びつかないからね。
3Dになっても、擬似物理でも見た目面白ければいい。

464 :仕様書無しさん:04/12/01 22:23:26
>>463
な、ここまで計算式を複雑にしてしまうと(加速度とか摩擦とか)
バグったときやゲーム的にもっと細かい動きを付けたいときとか
できるのか疑問だよな。

465 :仕様書無しさん:04/12/01 22:30:32
>>464 そういう計算ってサブルーチン化して組み合わせて使うのが普通だろ?
「できるのか疑問」っていったいどういうコードの書き方してるんだ??
いや、まさかとはおもうけど・・・・・

466 :仕様書無しさん:04/12/01 22:48:05
Havokは「4+衝突とみなす範囲を広げる」ですね。

467 :仕様書無しさん:04/12/01 22:50:55
グラVのジャガイモごろごろとかはどうやってるんだろ。
場面によっては同時に何個もの岩同士がぶつかってるんだけど・・・

468 :仕様書無しさん:04/12/01 23:11:53
>>465
>サブルーチン化して組み合わせて使ったところで
違うよ。
そういう問題を言ってるわけじゃない。
その動きをしたまま、ちょっとアレンジを加えてくれと注文を付けられたときの
ことを言っている。理解できた?

469 :仕様書無しさん:04/12/01 23:13:42
>>464-465
このスレこういった曖昧なレスのまま罵り愛が始まると長くなるんだよな・・・

470 :仕様書無しさん:04/12/01 23:43:49
>>459
作ってるゲームによるでしょ。RPG とかバイオハザードのようなスローペースの
アクションなら(弾丸は別として)問題ない。

471 :仕様書無しさん:04/12/02 00:18:30
>>467
移動距離が小さければたいした問題はないと思われ。

472 :仕様書無しさん:04/12/02 01:05:53
すりぬけUzeeeeeee!!

473 :仕様書無しさん:04/12/02 02:07:53
衝突のテストに作ったプログラムがジャガイモごろごろっぽくなって楽しい

474 :仕様書無しさん:04/12/02 04:34:36
>>462
ここ数年ではバトルガレッガか、ヘタレ同人シューくらいしかねーぞ(w

475 :仕様書無しさん:04/12/02 07:42:57
斜めの方が早いとちょっと不自然に見えるぞ
俺は、真横3斜め2、減速時2斜め1って感じでやってた

476 :仕様書無しさん:04/12/02 10:24:48
>>472
そういうゲームだと思え! 思い込め!

477 :仕様書無しさん:04/12/02 13:19:20
>>468
正確に物理計算した結果に対して「アレンジしてくれ」とか
いわれた時点で拒否権を発動するのが正解w

478 :仕様書無しさん:04/12/02 16:27:17
>>477
物理正確さより面白さ優先の漏れん所では不可!

479 :仕様書無しさん:04/12/02 17:30:11
>>477 はゲーム屋には向いてないポ


480 :仕様書無しさん:04/12/02 17:34:04
>>477
お前、融通きかないなぁー

うちの会社では、
そういうプログラマ干されてるよ

まぁ、拒否権発動してろや

481 :仕様書無しさん:04/12/02 17:41:15
めっちゃ叩かれてるなあ

482 :仕様書無しさん:04/12/02 17:58:27
叩かれる以前に>>477は釣りだろ。

483 :仕様書無しさん:04/12/02 21:29:01
というか叩いてるのはプログラマじゃないと思うのだが。

484 :仕様書無しさん:04/12/02 22:02:22
>>483
なぜそう思うのか理由が聞きたい。

485 :仕様書無しさん:04/12/02 22:21:41
>>483 も干されそうだな。orz

コードの美しさや単純さを優先するあまり、
例外処理的なことを排除するようなプログラマは
少なくともゲームプログラミングには向いてないよ。
絶対に面白いゲームにはならないから。経験者談 orz

486 :仕様書無しさん:04/12/02 23:59:41
ところで藻前ら、当たり判定ってのはどのタイミングで行ってるよ?
それぞれのオブジェクトが1回分移動した後?それとも全オブジェクトの動作終わってからまとめて判定?
それともその他?

前に一回メチャメチャ悩んだことあるんで他の人がどう考えてるか聞いてみたいのだが…。

487 :仕様書無しさん:04/12/03 00:08:27
プログラマが干されるより先に、ゲーム業界自体が社会から干されそうな予感

488 :仕様書無しさん:04/12/03 00:11:16
>>486
>全オブジェクトの動作終わってからまとめて
これやっちゃ駄目。
壁とキャラの当りはキャラを動かすごとに判定しなきゃ壁の向こうにいるキャラに当たるぞw
1キャラ動かすごとに少なくとも壁当りだけはチェック&補正しなきゃだめ。

489 :仕様書無しさん:04/12/03 00:12:03
>>486
全オブジェクトの動作が終わってからにしてる。そうしないと、オブジェクトの
動作の順番によって判定結果が変わることもあるし。
オブジェクトの動作の中で判定するのがクラス設計的にはきれいなんだけどね。

490 :仕様書無しさん:04/12/03 00:44:36
>>489
>>488さんと対になる意見ですが、
補正前の壁を超えてのキャラ同士の当り判定はどうやって回避しているのでしょうか?

491 :仕様書無しさん:04/12/03 00:58:32
そういうのは衝撃波とみなす

492 :仕様書無しさん:04/12/03 02:05:11
企画としてゲーム会社に就職する予定です。

その際に、COBOL検定の資格は
ゲーム会社の就職に、履歴書としての武器に成り得ますか?
「無いよりマシ」、「基本程度」、「書いたら恥」・・・等
COBOLがゲーム製作で、どんなポジションなのか分かりません。

プログラマーさんたちの意見を聞かせてください。

493 :仕様書無しさん:04/12/03 02:13:11
>>492
眉毛を0.1ミリ動かすくらいの威力だ。
ひのきのぼう 程度の威力も無い。
書いておいても毒にも薬にもならないが、
もっと他の君の強さをアピールしよう。

494 :仕様書無しさん:04/12/03 02:13:53
面接官「特技はイオナズンとありますが?」
学生 「はい。イオナズンです。」
面接官「イオナズンとは何のことですか?」
学生 「魔法です。」
面接官「え、魔法?」
学生 「はい。魔法です。敵全員に大ダメージを与えます。」
面接官「・・・で、そのイオナズンは当社において働くうえで何のメリットがあるとお考えですか?」
学生 「はい。敵が襲って来ても守れます。」
面接官「いや、当社には襲ってくるような輩はいません。それに人に危害を加えるのは犯罪ですよね。」
学生 「でも、警察にも勝てますよ。」
面接官「いや、勝つとかそういう問題じゃなくてですね・・・」
学生 「敵全員に100以上与えるんですよ。」
面接官「ふざけないでください。それに100って何ですか。だいたい・・・」
学生 「100ヒットポイントです。HPとも書きます。ヒットポイントというのは・・・」
面接官「聞いてません。帰って下さい。」
学生 「あれあれ?怒らせていいんですか?使いますよ。イオナズン。」
面接官「いいですよ。使って下さい。イオナズンとやらを。それで満足したら帰って下さい。」
学生 「運がよかったな。今日はMPが足りないみたいだ。」
面接官「帰れよ。」

495 :仕様書無しさん:04/12/03 02:21:10
COBOL固有の知識は置いといてプログラミングの基礎は
わかってるんだろうなという印象を与えられるかもね。
うまくいけば開発部隊にまわされるかもよw

496 :492:04/12/03 02:26:47
>>493>>495
意見ありがとうございます。
はぐれメタルも1ポイント差で逃げたりもしますから
一応書いておいてみます。

497 :仕様書無しさん:04/12/03 02:32:48
面接官「COBOL検定の資格とありますが?」
>492 「はい。COBOLです。」
面接官「・・・で、そのCOBOL検定は当社において働くうえで何のメリットがあるとお考えですか?」
>492 「はい。プログラムの基礎がわかっています。」
面接官「では開発部隊にすぐ入れますね。」
>492 「はい。がんばります。」

いや、そうじゃなくて・・・
492氏はその会社に受かる気があるのだろうか。
面接のHowTo本でも読んだほうが・・・

498 :仕様書無しさん:04/12/03 04:43:28
専門学校生ですが、学校での成績(出席率等含む)は
就職のときに武器になりえますか?

あと、VC++でのプログラミングしか経験がないのですが、
現場でも(VC++のような)IDEを使ってるんでしょうか?

499 :仕様書無しさん:04/12/03 04:45:11
( ´_ゝ`)

500 :仕様書無しさん:04/12/03 09:07:22
おまいはどこの専門学校に通ってるのかと問いたい

釣りじゃないなら学校の先生に聞け

501 :仕様書無しさん:04/12/03 09:23:18
んー。漏れから質問。
専門学校って、コードウォリアーとか使ってないのけ?

502 :仕様書無しさん:04/12/03 11:05:13
>>498
悪いよりは良いほうがいいだろうけど、あまり当てにならないし。
人間性と提出作品から総合的に判断して、全く同じレベルの人が複数
いる場合に悪すぎたら、落とす理由にする。作品が駄目なのに成績が
優秀だから取る、ってことは(ウチは)あまりない。

大手ならいろんな部署があるし、成績重視の所もあるだろうけど
でも成績で勝負するなら、少なくとも大卒じゃないとなぁ…。

503 :仕様書無しさん:04/12/03 11:23:29
面接官「COBOL検定の資格とありますが?」
>492 「はい。COBOLです。」
面接官「・・・で、そのCOBOL検定は当社において働くうえで何のメリットがあるとお考えですか?」
>492 「はい。プログラムの基礎がわかっています。」
面接官「ふざけないでください。なぜ今更COBOLなんですか?他の言語を勉強した方がよっぽど使えますよ?
初級シスアドや基本情報検定はうけましたか?オブジェクト指向についてどの程度理解していますか?
”プログラムの基礎がわかっています”というからには現場でプログラマの専門用語を理解できるということですよね?
本当にプログラムの基礎がわかっていますか??」
>492 「運がよかったな。今日は知識が足りないみたいだ。」
面接官「帰れよ。」


504 :仕様書無しさん:04/12/03 11:30:03
コボラー学生にむかって一人で熱くなってる面接官も痛いなw

そのコピペ改変するときは面接官はいじっちゃダメだよ・・・

505 :仕様書無しさん:04/12/03 11:32:57
まぁ、あれだ。
COBOLの経験なぞあっても無視されるし、現在のゲーム開発とは
あまりにかけ離れているのでかえって知らない方が良いぐらい。
COBOL検定持ってますと言うのは別にかまわないが、間違っても
それでプログラムの基礎がわかったなどと口走ってはいけないってこった。

これがJavaやCプログラミング能力検定だったらもうちっと評価があがるんだがなぁ。
実際に動くコードがあればさらに良いんだが。。。

506 :仕様書無しさん:04/12/03 14:47:13
>>501
専門なんてフリーなのしか使わないだろ。
秀丸+コマンドラインとかじゃないの。
だいたい学習用にはCW高杉。

かつてLSI-C使ってたという奴もいたな。

507 :仕様書無しさん:04/12/03 14:49:45
>>505
論点ずれてるぞ。元ネタは企画。
面接官だってそっち系の人間だろ。

508 :仕様書無しさん:04/12/03 15:15:56
専門はVC++使ってるよ。だってMFC使わないとGUIの一つも作れないからね。
ちょっと腕のいい講師が作ったDirectXラッパーライブラリを使ってゲーム制作。
生のDirectXなんて使えない。VSYNC同期?なにそれ、みたいな。
フルスクリーンモードでCPU100%占有するのも当然という感覚ですよ。
コマンドライン? 使えるわけないじゃないの。

509 :仕様書無しさん:04/12/03 15:23:23
目糞鼻糞を笑うってのはこのスレのことだなと一瞬オモタ




510 :仕様書無しさん:04/12/03 15:28:53
いや、鼻糞食べると糞になるんだよ。
出口は一緒。

511 :仕様書無しさん:04/12/03 15:36:08
>>508
最初はMFCでもラッパーでもいいと思うが。
当然、平行して言語自体の勉強もしてんだろうし。

512 :仕様書無しさん:04/12/03 16:52:42
>>506
んー。何のために金払ってまでフリーソフトをつかわにゃならんのだー。

513 :仕様書無しさん:04/12/03 16:59:55
>>512
どれの事?

514 :仕様書無しさん:04/12/03 17:27:31
教材がフリーソフトじゃあ、高い授業料分の価値は無いわな。
インターネットと独学で十分じゃん。

515 :仕様書無しさん:04/12/03 17:33:40
>>514
インターネットと独学でできない人が行くんじゃん
その人たちには価値あんだろ
余計な事まで口はさむなや

516 :仕様書無しさん:04/12/03 17:35:44
(プ

517 :仕様書無しさん:04/12/03 17:37:13
515=糞ゲー専講師

518 :仕様書無しさん:04/12/03 17:41:24
>>517
反論は無いわけだな

519 :仕様書無しさん:04/12/03 17:45:45
必死すぎて哂える

520 :仕様書無しさん:04/12/03 17:48:09
>>519
現実逃避か
それもよかろう

521 :仕様書無しさん:04/12/03 17:49:58
CSの開発機で教えてるとこってあるのか?

522 :仕様書無しさん:04/12/03 18:03:16
晒しage

523 :仕様書無しさん:04/12/03 18:09:36
>>515
おまえ何様?2chで口はさむなって馬鹿じゃねーの。

524 :仕様書無しさん:04/12/03 18:21:06
>>523
馬鹿は>>523
社会の底辺ゲームプログラマーは哀れだな
明日はリストラか?自殺するなら止めはしないぞ

525 :仕様書無しさん:04/12/03 18:22:51

なんですか、この人?

526 :仕様書無しさん:04/12/03 18:24:44
スレが上がると、途端にくそレスの嵐だな。w

527 :仕様書無しさん:04/12/03 18:26:11
逝ってよし

528 :仕様書無しさん:04/12/03 18:26:34
>>527
オマエモナー

529 :219.163.50.41:04/12/03 18:27:28
(^^)

530 :仕様書無しさん:04/12/03 18:34:35
>>492
COBOL検定か、漏れが査定人ならそれだけしかないと少し引くかな。
他の経験があれば良し。
>>498
VC++なら妥当だと思うぞ。
CWなんかやった日には、そのまま業界に就職できれば良いが、
独学も出来ないだろうし(CW環境が買えないだろ)
独学できる言語を勉強するのが潰しも効いて良いと思われ。
LSI-Cはちょっと思うが、実力があれば良し。

531 :仕様書無しさん:04/12/03 23:43:48
はっきりいってコンシューマ開発でもないのに
初心者にVC+DirectX以外のもの進める奴はかなりの馬鹿。
プログラマに向いてない。いますぐやめて実家帰れ。
俺の職場にいる余計なことして仕事増やす馬鹿と同じレベル。
何か調べさせても、いっつも劣悪な選択肢しか見つけられない奴っているよね。
ほんと何やらせても足でまとい、この上無い。

532 :仕様書無しさん:04/12/03 23:46:17
喪前はいったい誰にブチきれてるんだYO

533 :仕様書無しさん:04/12/03 23:52:25
面接官にじゃないのか。

534 :仕様書無しさん:04/12/04 00:35:19
>>531
お前、俺の職場にいるバカと同レベルだな。

535 :仕様書無しさん:04/12/04 00:55:18
ほんとに週末になるとレベルが地底を這いずるね

536 :仕様書無しさん:04/12/04 05:53:51
就職準備の奴にはVC++よりLinuxで環境構築からはじめろって薦めたほうがよくない?

537 :仕様書無しさん:04/12/04 08:11:53
http://www.geocities.jp/syakarikisony/manko.html
今更この記事を知ったのだが、遊びでやるにしても当り障りの無いものにしないと怖いな


538 :仕様書無しさん:04/12/04 09:00:40
>>537
それ、たしかユーザーの名前がそのままトラックにでるんじゃなかった?
で、ショーでその名前で入力したやつがいて、
そんな変な名前になってるとは知らずに写真を撮ったと

539 :仕様書無しさん:04/12/04 09:09:29
スコアランキングとかのNGワードリスト保守してると悲しくなってくる。

540 :仕様書無しさん:04/12/04 09:29:36
>>537 バカ!バカ!マンコ不動産!

541 :仕様書無しさん:04/12/04 10:07:58
携帯のゲーム開発してるとfloatが懐かしくて私・・・お国がわからなくなっちゃうっ!

542 :仕様書無しさん:04/12/04 11:45:38
>>541
PS1も懐かしくなるな。
12Bit固定少数懐かすぃ…。

543 :仕様書無しさん:04/12/05 16:08:51
>>541 喜べ。ボーダの新機種はfloat使えるぞ。どうせ使わんけどな・・・

544 :仕様書無しさん:04/12/05 16:09:49
日曜丸々放置されてると、皆仕事してるんだなあという気になる。
お前らせいぜいガンガレ(pgr

545 :仕様書無しさん:04/12/05 18:39:40
>>544
意味わかんない

546 :仕様書無しさん:04/12/05 19:54:25
『ガンガレ(pgr』?

ああ、そうか、『ガンガレprogrammer』の略だな、ありがとう

547 :仕様書無しさん:04/12/05 20:56:05
最近気付いたんだが
俺は
もしかしたら


548 :仕様書無しさん:04/12/05 21:40:32
X星人かも知れない

549 :仕様書無しさん:04/12/05 22:08:12
スケジュール再調整の名目で遅れている奴の作業が俺に回ってきた。
さようなら俺の年末年始休暇…

550 :仕様書無しさん:04/12/05 22:19:34
>>549
これ最悪だよな。
仕事が間に合わなくなってからまわってくるのって。
俺、その作業をどういう風にやろうか作業期間までに計画立てるほうだから
いきなりこういう風にまわってきて「はい、あと2週間で作ってね」とか
言われると、会社辞めるきっかけに十分なっちゃう。(俺の場合ね)

551 :仕様書無しさん:04/12/05 22:35:00
2週間分の仕事を片付けるとき
最初の一週間は何もしない。やってるフリだけする。
月、火、に仕様眺めてだらだら考え始める。
水、木、金で一気に作り上げる。

552 :仕様書無しさん:04/12/05 23:22:30
テスト勉強と同じパターンですな

553 :仕様書無しさん:04/12/06 08:11:14
それが分かってるからこそ、俗に経験則でマイルストーンは2週間ごと、2ヶ月刻みと言われてるわけだ。

554 :仕様書無しさん:04/12/06 13:22:03
毎週末にその時点で動くものを成果として確認する。最強。

555 :仕様書無しさん:04/12/06 13:24:30
延期延期の癖に偉そうなことぬかすなボケ

556 :仕様書無しさん:04/12/06 16:39:46
ボケ 出ました!


557 :仕様書無しさん:04/12/06 20:08:46
>>556
了解。
こちらも ボケ 目視で確認しました。
引き続き ボケ の警戒を続けます。

558 :仕様書無しさん:04/12/06 22:54:07
報ステでゲーム脳特集放送中・・・

559 :仕様書無しさん:04/12/06 22:54:52
ゲームやると脳が退化していくことになってます・・・

560 :仕様書無しさん:04/12/06 22:56:02
エロゲーでオナニーしすぎてチンコが右寄りになってしまいましたが

  こ れ は ゲ ー ム チ ン コ で す か ?

561 :仕様書無しさん:04/12/06 22:57:13
暗算するとゲーム脳が回復することになってます・・・

562 :仕様書無しさん:04/12/06 23:18:26
おいおい、まだゲーム脳なんて論理的に否定されたもの
信じている奴がいるのか?

確か体育教師か何かがお手玉普及させようとして
詭弁を展開していたんだっけ?
リラックスしたときに出る良いα派が
ボケ老人も出してるから悪い物だとかw

563 :仕様書無しさん:04/12/06 23:23:53
論理的に否定できるのか

564 :仕様書無しさん:04/12/06 23:28:10
>>563
そもそも脳波なんてもの自体が胡散臭いからどうにもならんですな。

565 :仕様書無しさん:04/12/07 00:43:29
暇つぶしに二桁暗算ツール作ってみたけど
20問解いて1問あたりの時間:3.1921秒だった。
眠いのもあるけど時間かかりすぎ・・・orz
しばらく続けてみるかな。

566 :仕様書無しさん:04/12/07 02:23:47
頭悪い奴がゲームばっかりやるっていうだけで
ゲームのせいで悪くなったんじゃねーよ!!
同じゲームばっかやってないでしっかり勉強して褒美にガンガン買ってもらえ
ダラダラプレイがゲームデフレの原因なんだよ

567 :仕様書無しさん:04/12/07 03:54:03
連中が何をもって頭の良し悪しを決めているのかは知らんが
例えば東大生でもゲームばっかりやってる香具師は多いぞ

568 :仕様書無しさん:04/12/07 04:05:54
頭が悪くなるとはあのアホ教授もいってない
コミュニケーション能力に乏しく切れやすくなるらしい。

569 :仕様書無しさん:04/12/07 04:28:22
久しぶりにモノポリー遊んだら、お釣りの計算ができない自分に呆然。
俺もリハビリ用のiアプリか何か作ろ。

570 :仕様書無しさん:04/12/07 05:41:41
>>568
ゲーマーというより最近の若(ry全般の傾向じゃないか。
親の教育に最大の原因があるのは明らか。

571 :仕様書無しさん:04/12/07 05:43:46
おまいらもそろそろ最大の原因になるわけだが(とっくにか?)
何歳ぐらいから子供にゲームをやらせますか?

572 :仕様書無しさん:04/12/07 06:03:20
>570
>最近の若(ry全般の傾向
そうなの?ソースは?

573 :仕様書無しさん:04/12/07 06:50:39
デスマのあとに休暇とかってある?
昔FFかなんかは、開発後に長期休暇をとれるって聞いたけど。

574 :仕様書無しさん:04/12/07 07:37:35
俺は3歳の頃からカセットビジョンやってたので物心つく前からやらしても問題なし。


575 :仕様書無しさん:04/12/07 09:43:24
「子供のコミュニケーション能力の減退と、ゲームの普及は同時期に進行している。
 ゆえに子供のコミュニケーション能力の減退はゲームである」
「子供への携帯電話の普及と、子供の平均身長の増加は同時期に進行している。
 ゆえに携帯電話の普及の原因は子供の平均身長の増加である」

前者は正しくて後者は正しくないと思った人がいるかもしれないけど、
論拠としては「同時期に進行してる」ことだけを根拠にしてるのであって
原因と結果を結びつけるには不十分

他には、脳波を使ったよくわからん実験をしてたり
「残酷なゲームをプレイした子供は残酷になる」って本人の主観が堂々と語られてたり
とにかく学者としてはうさんくさい筆者

576 :仕様書無しさん:04/12/07 10:16:18
でもなぁ、この前も近所の小学校で講演会やってたし(行けなかったけど)
親たちの間でも普通に
「ゲームやるとゲーム脳になるからやらせられないよねぇ」
見たいな会話が飛び交っているぞ。
うちは1年生だけど1日1時間と決めてやらせてる。

やっぱ、子供がゲーム脳になるのは嫌だしw

577 :仕様書無しさん:04/12/07 10:21:56
ママさんがとび付いたことが
ここまで生き残ってる理由なんだろうね・・・
お勉強の障害を排除する理由になるし

578 :仕様書無しさん:04/12/07 11:32:46
あと、マスコミにとってもテレビを占有するコンピュータゲームは敵。

579 :仕様書無しさん:04/12/07 11:38:16
皇太子殿下がファミコン好きなのは有名ですが
ゲーム脳になるとあのようになられてしまうのでしょうか。


580 :仕様書無しさん:04/12/07 12:21:31
ばばあどもが何の疑いも無くボーっとみてるワイドショーのほうが1000倍害があるぞ。
他人の思想と自分の考えの区別すらつかない。テロップで笑いどころを教えられないと笑えない。

581 :仕様書無しさん:04/12/07 13:22:08
ゲームばかりやっていると馬鹿になる

高1学力世界トップレベルから脱落
http://www.mainichi-msn.co.jp/today/news/20041207k0000e040031000c.html

582 :仕様書無しさん:04/12/07 13:32:59
>>581
「ゲーム」という単語が一度も出てきてない訳だが


まぁ一行目は同意
勉強は勉強でちゃんとやらなきゃね・・・

583 :仕様書無しさん:04/12/07 13:51:11
>>573オメ
それはさておき、それなりの大型プロジェクトなら貰えたことがある。
1〜2週間。休出残業の振り替えって形に近いし、それで数えると勘定に合わんくらいだが。

それ以前に、プロジェクト終了と同時に辞める人も多い。
彼らの休日については推して知るべし、つーか俺も辞めたことあるけど、
2ヶ月くらい仕事もなんもせんでぼへーっとしてた。

584 :仕様書無しさん:04/12/07 19:39:28
>>576
> やっぱ、子供がゲーム脳になるのは嫌だしw
子供の脳の前に、自分の判断力の低下を嘆いた方が良いと思われ。

585 :仕様書無しさん:04/12/07 19:54:31
もうさ

 ゲーム脳=ゲームのやりすぎによる諸々の弊害の総称

でいいんじゃないの。森某はどうでもいいよ。

586 :仕様書無しさん:04/12/07 21:03:16
ゲーム脳にさせたくないからゲームをさせない



おまいさんたちは子供を何脳にしたいんだ?

587 :仕様書無しさん:04/12/07 22:22:09
放置してお花畑脳に

588 :仕様書無しさん:04/12/08 00:23:09
無脳

589 :仕様書無しさん:04/12/08 01:28:11
ていうかおまいら自分のお仕事に誇りはありませんかそうですか。

590 :仕様書無しさん:04/12/08 01:30:17
実はまだ学生の漏れ

591 :576:04/12/08 01:34:23
>>584 >>586 俺はゲPGやってて子供もいるんだけど、確かに自分の判断力の無さは認めるよ。
だがな、子育てやったことある奴いるか?
一人の人間を全く未経験のところから初めてまともな大人にまで責任を持って育てなきゃならない。
しかも、途中でやり直しはきかないし、こっちの思い通りにも動いてくれない。
目隠しでヨチヨチ歩きの子供を連れて地雷源歩いてるようなもんだぞ?

俺が過剰に心配性なだけかもしれないが、親としてはちょっとでも不安があったらなるべく距離を置きたいもんなんだよ。
昔ほど周りに大人の目が行き届いてるでもないし、ニュースでは毎日、基地外や炉利痕が起こした犯罪がバンバン放送されてる。
しかもそれに触発された模倣犯がさらにそこらじゅうに潜んでるときた。
そりゃぁ、過保護になるってもんだろ。

俺もゲーム屋だし、ゲーム脳なんて信じちゃいねぇよ。
だがな、俺らが作っているテレビゲームって奴はな、常に刺激を与え続けプレイヤーを没頭させる方向で進化してきたんだよ。
それをおまいらは完璧に無害だと断言できるか?できないだろ?
確かに俺らは自分の手でゲームを作ってはいるけど、子供の成長に及ぼす影響が0%だと断言できない限り、
まだ精神が未発達な子供に無闇にゲームを与えたくは無い。

ゲームはガキがやるには早すぎる。

592 :仕様書無しさん:04/12/08 01:51:04
オレの場合
RPGで雑魚と戦ってレベル上げしてるときなんて
完全に思考が停止してるな。

完全パターン化したシューティングの序盤面やってるときも
絶対止まってるな。

しかし何もせずにボーっとしてるときよりはマシだとは思うがねぇ

593 :仕様書無しさん:04/12/08 01:59:27
シューティングとかはまだいいんだけどさあ。

ゲームやる奴同士にしか通用しないコミュニケーション言語化してるゲームが
幅を利かせてる点については言及する奴すくねえなあ。

端的にはエロゲとかギャルゲとかの類なんだけど、萌えとかがどうこう以前に、
あれ同好の士を囲い込んで、それ以外の人間にはまったく通用しない言語に
なったりするわけで、作る側もやる側もそれで良しとしてしまってるところがあるっぽい。

そりゃ無関係な第三者が叩く口実にはなる罠。

594 :仕様書無しさん:04/12/08 02:58:35
どんな領域にもそういう内輪はあると思うけどなあ。
だが、テレビゲームと同じで生産性ゼロの一人遊びでも、トランプとかは叩かれない。
なんでテレビゲームだけ叩かれるのかってーと、古い世代は「実体がないモノ」への不安が大きいんじゃなかろうか。
トランプとは中毒性がケタ違いってのもあるが。

595 :仕様書無しさん:04/12/08 03:26:36
多分にそれはある。
お年寄りの携帯電話恐怖症って、あれが複雑なデバイスだから受け付けないんじゃなくって、
簡単だろうとなんだろうと未知のパラダイムの担い手であり、かつ、最も身近で未知であるところの
子供たちの象徴であるからであって、仮に誰でも使える優しい携帯電話とかがあったところで、
それまで携帯電話に拒絶反応示してたじい様ばあ様が、コロリと宗旨替えするってことは
(少しはあるだろうが)大多数においては、まあ有り得ない話。

よって漏れらに出来ることはといえば、誰もに胸張ってエヘンと威張れるゲームを作ることだけですよ。

胸のゆれとかは関係なくな、とりあえず。

596 :仕様書無しさん:04/12/08 03:58:01
たとえば携帯電話がコードでどっかとつなげて使うようなものなら老人でも抵抗が少なくなるんだろう。
自分の理解できない映像と向かい合っている姿や小さな箱と会話してる姿の
「得体が知れない・原理がわからない」ことに対する拒否反応のようなものだと思う。

597 :仕様書無しさん:04/12/08 07:29:24
>591
> 子供の成長に及ぼす影響が0%だと断言できない限り、
> まだ精神が未発達な子供に無闇にゲームを与えたくは無い。
じゃあ、小学校に通わせるのはやめた方がいいな。
子供の成長に及ぼす影響が大きすぎる。

598 :仕様書無しさん:04/12/08 08:11:30
亜大「ゲーム脳だから痴漢した」ラサール石井発言
http://ex7.2ch.net/test/read.cgi/news4vip/1102457781/

599 :仕様書無しさん:04/12/08 11:10:38
ホント?それはまた狂言だな。
充分なサンプルと相関関係を統計的に証明してれば別だけど。

600 :仕様書無しさん:04/12/08 19:53:59
>>591
> 昔ほど周りに大人の目が行き届いてるでもないし、ニュースでは毎日、基地外や炉利痕が起こした犯罪がバンバン放送されてる。
統計的に見る限り、昔と比べて犯罪が増えてる&深刻化してるという結果は
出てないぞ。マスコミの取り上げ方がセンセーショナルになってるだけだよ。

> それをおまいらは完璧に無害だと断言できるか?できないだろ?
まずは空気が汚れてる都会に住むのをやめるべきだな。

601 :仕様書無しさん:04/12/08 21:42:13
> それをおまいらは完璧に無害だと断言できるか?できないだろ?
コンピュータの発している電磁波が完全に無害だと断言できるか?できないだろ?

602 :仕様書無しさん:04/12/08 22:03:42
他人様の子供にはさんざんっぱらゲーム売っといて
自分の子供にだけはやらせたくないなんてふざけるなと。
まずはお前ら自身の倫理観を何とかしろ。

603 :仕様書無しさん:04/12/08 22:38:21
> それをおまいらは完璧に無害だと断言できるか?できないだろ?

悪魔の証明 - Wikipedia
http://ja.wikipedia.org/wiki/%E6%82%AA%E9%AD%94%E3%81%AE%E8%A8%BC%E6%98%8E

まあ、俺自身はゲームを有害だと確信していて
社会をかき乱すことに喜びを覚えるクチだが。

604 :仕様書無しさん:04/12/08 22:56:04
俺の場合はヤクを作ってる感覚はないが酒・タバコぐらいの害あるかな〜と頭の隅っこにおいてある。
あと、この業界で数年やってると毎朝ヒゲそって、ネクタイ締めてないと怒られるってのは想像の範囲外にいっちゃてるのよ。
正直、世間様でいうところのちゃんとした会社ってのは一ヶ月耐えれるか怪しいのね。
まあ入社そうそうデスマ体験して死ぬかと思ったが一週間程度で結構適応できたから何とかなるかもしれないけど。

605 :486:04/12/08 23:45:10
>>488-489

亀レススマソ。
基本的には、壁との判定は移動時、その他の判定は最後、って感じなのかな?

ちなみに、以前迷ったのは「動く壁」とか「壁判定を持った敵(グラ5のじゃがいもなど)」とか出てきた場合。
整理の仕方に問題があったのか、考えれば考えるほどドツボにはまった記憶がある。
なんか「鶏が先か卵が先か?」をまじめに考察したような気分になった。

606 :仕様書無しさん:04/12/09 00:02:32
>>605
ちがう。
良く考えろスケベ。

壁判定は動くたびにやらなきゃいけないんだよ。

敵との判定は一発だけにあきらめ、敵と自機のめり込みを許す。
敵と自機との衝突後の移動で壁判定をしなければならない。

敵との判定を一発だけにあきらめるのは永久ループを回避するため。

要は敵とのめり込みはある程度あきらめて、
絶対にぬけちゃいけない壁の判定だけ確実にするっていうこと。

なのでワンフレームで壁判定は何回も発生し、
かつ、高速化はできない。

処理的には動く物体が動いたら、即、壁判定でいい。

607 :仕様書無しさん:04/12/09 00:09:00
別に、子供に対して有害なのはゲームに限らないしな。
酒にタバコにギャンブルに、環境フォルモン、電磁波、
放射線、子供の教育も満足にできない親、過保護な親、
学級崩壊を発生させるアフォ、etc


608 :仕様書無しさん:04/12/09 00:21:13
今の時代、ゲームどころか、漫画すら読んだことのないガキが、
珍しくないらしいけどな。


609 :仕様書無しさん:04/12/09 00:42:40
正直なところ俺が死ぬ頃社会がどうなっていようと知ったことではない。
それに内戦だの銃乱射だのやってる国よりは
2chに入り浸ってたまに一人二人カッターで切り殺していた方ががまだましだ。

610 :仕様書無しさん:04/12/09 03:20:00
俺は
ゲームは子供にとって1日1時間程度なら
テクノロジーへの知的好奇心を刺戟してくれるいいものだと
信じてるよ。もちろん息子にもプログラマになってほしい。

611 :仕様書無しさん:04/12/09 04:20:34
子供のころに親が教育してくれたら…と思うときあるな
まぁ俺の親はドカタだったからそこまで期待しちゃいけないけど

でも小学校のころから触ってたけど、ゲームしたり年賀状作っただけ、
っていうやつだとそれほどアドバンテージは無いと思う

じゃあどういう勉強をさせればいいんだ、って言われると困るけど…

612 :仕様書無しさん:04/12/09 07:55:28
親が子供にできる事は、しつけをする事と、飯を食わせる事、
様々な物に興味を向けさせる事、顔を合わせた時に話をする事、
ぐらいしかないだろ。勉強なんてモノは自発的にやる事で、
押し付けられてやる事ではないと思うけどな。
そりゃ、教えてもらう方が楽なのは認めるが・・・

つーか、飯の時間に顔を合わせてもTVに夢中で、
話すらできない親が、世の中には珍しくないからな。


613 :仕様書無しさん:04/12/09 09:08:54
>>608
なにやって遊んでるのかな。
普通に外で友達と野山をかけまわってるでもあるまいし。

614 :仕様書無しさん:04/12/09 11:52:58
親に飯くわせて貰っただけでも感謝だぜっと

当たり前の事だが、当たり前の事に感謝せにゃな

615 :仕様書無しさん:04/12/09 16:51:21
ぶっちゃけ、ゲームが無害と力説してるやつって
そんなに人畜無害な空気みたいなもの作ってて楽しいのかと思うわけよ。
裏を返せば社会的影響力ゼロってこったろ?

想像してみろよ。俺のゲームに影響されて銃乱射とか、発売日に強盗とか、
教室で必殺技の真似していじめとか、実に心躍る話だと思わんのか。

そこまで行かんにしても、ゲームに溺れて成績落としたり
会社休んで怒られるダメ人間を量産できれば俺は「成功」だと見るね。

616 :仕様書無しさん:04/12/09 17:08:07
オレが作ったゲームをプレイするとモテモテになります。間違いない!

617 :仕様書無しさん:04/12/09 17:17:01
なんか邪悪な人が紛れ込んでいますね

618 :仕様書無しさん:04/12/09 17:26:38
俺は任天堂系のゲームなら一日1時間でガキにやらせても良いと思っている。


619 :仕様書無しさん:04/12/09 17:38:20
なんだかんだで任天堂はめっさ優秀だと思う。

620 :仕様書無しさん:04/12/09 18:38:58
>615
ttp://www008.upp.so-net.ne.jp/zaruo/zaru/backnumber/oh/oh02.html

621 :仕様書無しさん:04/12/10 11:08:46
それにつけても嫁の欲しさよ。

622 :仕様書無しさん:04/12/10 11:31:08
給料いくらですか?

623 :仕様書無しさん:04/12/10 11:37:08
他業種に比べれば安いよ。
月15〜20万ぐらいがいいとこで、まぁ年齢×1万円の月収があれば勝ち組。
具体的には転職系サイトでゲームPGのとこを見れ。


624 :仕様書無しさん:04/12/10 11:46:49
30〜40歳になったときどうなってるの?
有能な人と並な人それぞれで。

625 :仕様書無しさん:04/12/10 12:07:55
30〜40になるまでに大体辞めてr(ry

626 :仕様書無しさん:04/12/10 12:25:46
ゲームプログラマ辞めた人はどうしてるの?

627 :仕様書無しさん:04/12/10 13:25:36
ゲームショップを開いているか、テクニカルライター、ゲー専講師とか。いろいろ。
ゲームそのもの以外を作るほうへ回るのが大多数では。

628 :仕様書無しさん:04/12/10 13:58:23
技能は並以下だが、とりあえず手取りで年齢*1万貰ってるもう直ぐ33歳。
職種そのものをやめる気は無いが、会社は辞めたがりになってて、次で10社目。
いい加減腰を落ち着けたいと思うがどうも上手く行かない。脳の病気かも知れん…


629 :仕様書無しさん:04/12/10 22:15:05
>>628
医者行ってらっさい。
きょうび珍しくも無いよ。

630 :仕様書無しさん:04/12/11 11:15:03
趣味でゲームプログラミングしようと思って
いろいろ調べた結果、
C→C++(かじる程度)→VC+かVC#
という順で勉強しようと思いますが無難でしょうか。
プログラミング歴はVB1年(データベース)・C言語1ヶ月です。

最終レベル目標は「いたスト(SFC版)」です。
C#かC++かで迷っているのですが、
上のレベルの作品を作るのにC++は必要でしょうか。
現職のPGではないので言語の将来性は重要視していません。


631 :仕様書無しさん:04/12/11 11:21:57
VBでつくればいいだろ

632 :仕様書無しさん:04/12/11 12:21:38
マシンのスペックを気にしないならVB、
数多くの人に遊んでほしいならVCかな?


633 :仕様書無しさん:04/12/11 12:44:42
>>630
趣味ならいっそスーファミで動くように組めば?

スーファミのプログラム
http://pc5.2ch.net/test/read.cgi/gamedev/1095063252/

634 :630:04/12/11 13:11:17
いろいろな回答ありがとうございます。

みなさんの回答を読んだところ、上に挙げたレベルの作品なら
言語はそれほど関係ないと捕らえてよいのでしょうか。

経験のあるVBの使用も考えましたが、画像を
操作するようなプログラムを組んだことがないので、
果たしてVBで組めるのかどうか想像がつきませんでした。

>>633
いたスト(SFC)と書いたのは「3Dではないボードゲーム」を
想定していたからです。2人〜4人のオンライン対戦も
考えているので特にスーファミに拘るつもりはありません。


635 :仕様書無しさん:04/12/11 13:13:27
スーファミでもオンライン対戦できるよん

636 :仕様書無しさん:04/12/11 13:20:47
VBでも組めるよ、ただフリーソフトで広めようとするならランタイムが邪魔かもな。











その前に、魅力ある絵が描けるがどうかが疑問である。

637 :仕様書無しさん:04/12/11 13:30:40
オンラインならC++でやると色々ややこしそうだな。
いたスト程度ならVBでやってもスペック的な問題が出るとは考えづらい。

638 :仕様書無しさん:04/12/11 13:42:56
VBでつくったプログラムって臭いで判るんだよね。中身見なくても。
なんでだろうな?
VB使いに厨房が多いのが一つの理由かもしれん。

639 :仕様書無しさん:04/12/11 13:47:45
>>638
ウィンドウのあるアプリならGUI一つ一つの詳細な設定ができないためだと思われ。
細かい動作をVBで設定するためには、APIコールをしなくてはならない。
そうするとVCのン十倍の手間がかかる。

640 :仕様書無しさん:04/12/11 14:27:38
ん?VB6の話なのか。

641 :仕様書無しさん:04/12/11 15:13:15
まぁ、ゲームだったらDirectX系じゃないの?
VBだろうがVCだろうが作れるもんは作れる

そもそも、ゲームを仕上げる技能があれば、言語を理解するのは余裕
VBをマスターした、っていえるレベルまで使いこなせば、
VCでも1週間もあれば使いこなせるはず

構造化BASIC以上ならCでもJavaでもPascalでも骨格は同じ

642 :仕様書無しさん:04/12/11 15:26:20
だな。GUIの場合、言語が理解出来るかどうかよりも、
イベントトリブンが理解出来るかどうか、だからな。
あと、状態変位か・・・管理が面倒なんだよな、コレ。

643 :仕様書無しさん:04/12/11 15:33:37
そこでタスクシステムですよ

644 :630:04/12/11 15:53:15
>スーファミでもオンライン対戦できるよん
おそらくエミュレータやKailleraのことと思いますが、
どうもスーファミにする利点がなさそうです・・・

>その前に、魅力ある絵が描けるがどうかが疑問である。
たしかに難しい問題ですが、今の段階ではまだまだ先の話です。
とりあえず製作中は既存のゲーム画像を使用することになると思います。

>細かい動作をVBで設定するためには、APIコールをしなくてはならない。
私が使っているのはVB.NETですが、このへんのことは
VB6と変わってないようですね。
そのためか多くのウェブサイトでVB経験者はVC#に乗り換えろという
記述をよく目にします。

いろいろなご意見ありがとうございます。
私としてはC#がよさそうだという結論になったのですが、どうでしょうか。

VB.NET = APIが面倒
VC++ = オンラインがややこしい
VC# = VB経験者に推奨らしい

645 :仕様書無しさん:04/12/11 16:03:02
VC#か・・・MSの意向としては、Windowsアプリは
これ一本に絞って欲しいのかもしれんケド・・・
まあ、MS-Officeがこれで作られるようになったら、考えるかな?


646 :仕様書無しさん:04/12/11 16:08:50
>>644
ははは・・・w
VB6からVB.NETであれだけ酷い目にあって、
まだ、MS言語手放せないんだw
君はずっとツールを探し続ける類の人だよ。
会社にいたらちょっと笑えない。

647 :仕様書無しさん:04/12/11 16:40:47
今からC,C++覚えるぐらいなら C# でもいんでない?

648 :仕様書無しさん:04/12/11 16:48:02
>>647
なんでわざわざMS言語覚えさせるの?
C#はMS言語だよ。
そこらへんわかってるの?

649 :仕様書無しさん:04/12/11 16:50:42
.NETでグラフィックだとDirectXを使わないとゲームにならんよ。
まったくアニメーションさせないならいいけど。

ところで宣言が必要+API=???
やってることがおかしいと思うんだが。

650 :仕様書無しさん:04/12/11 16:55:25
>>648
JavaもC#も事情は似たようなもの
C/C++だって基本文法の枠を超えたらどこかのベンダーにおんぶに抱っこだ

651 :仕様書無しさん:04/12/11 16:55:28
>>648
VC++でもMS言語みたいなもんだろ。

652 :仕様書無しさん:04/12/11 17:05:21
>>651
え?そういうあいまいな表現やめてくれない?
@C++ + Win32API
AMFC
ってあるけど@は旨く作ればWin32APIだけ切り離すことは比較的容易。
Aはどうしようもない。MS言語でいいと思う。

653 :仕様書無しさん:04/12/11 17:06:44
まだMS嫌いとかって存在したんだ!?ダッセーw

654 :仕様書無しさん:04/12/11 17:09:07
MS嫌いって共産党支持者っぽいよね。

655 :仕様書無しさん:04/12/11 17:09:18
どうでもいい話が続いているな。

656 :仕様書無しさん:04/12/11 17:09:55
MS言語を定義せよ

657 :仕様書無しさん:04/12/11 17:13:30
>>656
先に言語の定義をしろ、定義に問題が無いならMS言語の定義をしてもいい。

658 :仕様書無しさん:04/12/11 17:13:54
たまーに「ボク、MS嫌いですから」とか言う奴っているけど、恥ずかしいからやめておけよ。

659 :仕様書無しさん:04/12/11 17:14:59
>>657
言語の定義も好きにしていいから

660 :仕様書無しさん:04/12/11 17:17:24
>>656
まあ、定義はあいまいだけど。
これは使ってみた感覚でうなづいてくれると思うな。
VC++でMS言語っていうのは俺はMFCのことだと思ったけど。
(俺の定義ではMFCはMS言語じゃない)

C#とVBはもうどっぷりMSが仕様を変えちゃうことによってコンパイルできなくなっちゃうよね。
バージョン定義でわけることも不可能だし。

661 :仕様書無しさん:04/12/11 17:17:36
>>659 
笑止!!!!無能に答える必要は無い。

662 :仕様書無しさん:04/12/11 17:22:45
バージョンの移り変わりに対応していくのがオマエラの仕事だろ。
ついて来れない奴は辞めろ。

663 :仕様書無しさん:04/12/11 17:28:10
つか、VB6で組んだプログラムはVB.NETに修正できなければソースを捨てるしかない。
VB6を使い続けて組み続けるという手もあるが、今度はWindowsのバージョンアップで動かなくなったらアウト。
#ちなみにVC6とWindowsXPの相性は最悪。
#実行時にハングアップするといじってたソースが真っ白けになるw
で、開発者の人数が増えてもVB6を購入する手段がヤフーオークションしかない。

まとめると
MS言語の怖い話一覧
・MSのサポートが切れてWindowsのバージョンがあがったとき
 動かなくなったときが本当の最後。(これがランタイムまわりのバグだと致命的)
・バージョンアップによる仕様変更。
 システムがC++などのメジャー言語の上に載ってるようなものなら変更はAPIの使用箇所のみで済むが
 言語自体がMS仕様だと最悪。(今回のVB6→VB.NET等)

664 :仕様書無しさん:04/12/11 17:28:59
>>662
だから、なるべく負荷を減らす話をしてるんですけど。
あなたアホみたいなので、あっちいっててもらえます?

665 :仕様書無しさん:04/12/11 17:30:01
C#はIETFで標準化されたから他の言語より条件が悪いということはない。

666 :仕様書無しさん:04/12/11 17:32:47
>>664
甘えんなよ。負荷の軽減に配慮してばっかりいたら進化しねーんだよ。
この時代までVB6が生き残ってしまったのは、配慮の結果だよな。
おかげでそのへんクズPGばっかりだwww

667 :仕様書無しさん:04/12/11 17:37:21
>>664
javaでもやってろ。クズ

668 :仕様書無しさん:04/12/11 17:39:10
ボク、MS嫌いですから

669 :仕様書無しさん:04/12/11 17:39:50
>>666
目先の仕事こなすことしか頭に無いくせに
進化なんて口に出しちゃうところが君の駄目なところだと思う。

670 :仕様書無しさん:04/12/11 17:41:34
>>668
てゆうか俺はMS嫌いでこんなこと話してるわけじゃないんだけどw
君はレスをよく読もう。

671 :仕様書無しさん:04/12/11 17:45:14
>>652
条件付けでいいのならVBでも可能だが。

672 :仕様書無しさん:04/12/11 17:46:48
>>669
目先の仕事もこなせない馬鹿がよくいうぜw
くだらねえ議論してねーでさっさと仕事しろよ。

673 :仕様書無しさん:04/12/11 17:50:17
>>670
Windowsアプリの話してるんだろ?MSに従ってるのが一番いいんだよ。
って書くと、おまえら末端PGは「一番いい」をもっと定量的に示せとかごちゃごちゃ言うんだろうが。

674 :仕様書無しさん:04/12/11 17:57:16
>>673
>Windowsアプリの話してるんだろ?MSに従ってるのが一番いいんだよ。
議論部外者だが、↑の考え方だけでは身を滅ぼすよ。

675 :仕様書無しさん:04/12/11 18:04:41
少なくとも数年先のWindowsと.NET構想のロードマップが発表されてるからな。
C#を憶えることに多少安心はある。
つうか互換性うんぬん言ってる人。先のバージョンの情報くらい仕入れろや

676 :仕様書無しさん:04/12/11 18:32:58
>>675
その前になんでそんなの信じちゃうのかわからない。

677 :仕様書無しさん:04/12/11 18:42:06
>>676
あなたどっちの事言ってんの?

どちらにせよ自分がこれだ、と思った発表情報を信じなくて何を信じるのさ?
出てきてから文句たれながら対応すんの?
その歯車プログラマすするんならそれでもいいと思うけどね。

678 :仕様書無しさん:04/12/11 18:45:09
>>677
MSの大本営発表しかあんたは見てないのか?
C#は例の件でおしゃか決定なんだよ。
例の件自体を知らんから、んな間抜けなことを言ってるんだろうが。

679 :仕様書無しさん:04/12/11 18:50:20
>>678
例の件って何?

680 :仕様書無しさん:04/12/11 19:01:40
>>678
間抜け?
そのC#の気になる例の件とかは確かに俺は知らんけれど、問題があると思うなら今からでも対策を考えれるだろう。
俺はWindowsと.NETに対して言ったんだが、C#ボツネタを持ち出してきて間抜け扱いは酷いな。

C#言語がボツになっても.NETもボツなのか?
C#がボツっても皆がいうように、新しい言語はすぐに憶えなおせるだろう。
.NETフレームワークが無くなったとしても今から対策を考えることが出来るだろう。
そんなにMSが信用できないなら、おとなしく自分で全部作りなよ

681 :仕様書無しさん:04/12/11 19:02:24
急に死滅スレ化してきたな・・・

682 :仕様書無しさん:04/12/11 19:06:56
>>680
つか、一連の書き込みは別に1人の人間が書き込んでるわけじゃないぞ。
>>660,663,670は俺だけど後は全部他の人だよ。
>>678の人はなんかC#は終わりってことを言いたいだけで書き込んだっぽいぞ。

ちなみに俺はC#とVB.NETはなんか嫌な匂いがするね。

683 :仕様書無しさん:04/12/11 19:13:59
久しぶりに来てみたら何でWindowsオンリーのC#で揉めてるんだ。
将来コンシューマにC#が使えるのかと言う論議ならともかく。

684 :仕様書無しさん:04/12/11 19:23:49
そういや、PS2の出だしのときはLinuxと仲良しっぷりをアピールしてたが、
あれはその後どうなったんだ?

685 :仕様書無しさん:04/12/11 19:33:46
>>681、682
スマンカッタ
C#は俺も嫌な雰囲気を最近は感じるが、別にC#が無くなるのはかまわないと思うのよ。
散々既出なように言語なんてすぐ憶えれるんだから(今の俺に辛いのは.NET自体が無くなること)

でさ、一度作ったツール類の開発ってWindowsの寿命以上に生涯使われていく事ってそうないよな?
ゲームエンジンとデータ構造だって数年おきに新しい技術を吸収して(1からでは無いにせよ)作り直してない?
その時に製品寿命を考えて、期間内ら動作する言語とバージョンを選んでいるんじゃないの?

>>683
一応Linux用のC#コンパイラも出てるよ。

686 :仕様書無しさん:04/12/11 19:36:40
>>683
(´-`).。oO(XBox・・・・・・)

687 :630:04/12/11 19:41:04
( ゚д゚)ポカーン

688 :仕様書無しさん:04/12/11 19:50:23
>>685
Win32APIは95の時代から長続きしてるがな。

689 :仕様書無しさん:04/12/11 19:51:20
>>678
例の件って何ですか?

690 :仕様書無しさん:04/12/11 20:09:25
MS言語だと何かマズいのか?
何十年も使い続けられる業務システムでもあるまいし。
630自身が趣味で作ると言っているのだから問題ないだろう。
CやC++だと、言語そのものとWindowsのAPIが分離されてるから
具体的なゲーム制作に入る前に力尽きてしまうのではないか
(挫折ではなくモチベーションがなくなる)と思うんだが。

別にVBでも構わんと思うが、質問が
>C#かC++かで迷っているのですが
ということだったので。


691 :630:04/12/11 20:10:47
>VB6からVB.NETであれだけ酷い目にあって、まだMS言語手放せないんだw
あまり奥深いものを作成しなかったのでまだ酷い目に遭ったことがありません。

>今からC,C++覚えるぐらいなら C# でもいんでない?
それほどCとC#は別物なんでしょうか。
現在Cを勉強中ですが、どうもVBはプログラミングというより
アプリケーションの使い方を勉強しているような気がして、
今ではGUIよりコマンドラインに新鮮味を感じます。
(所詮その程度しか使いこなせていなかったということですが)

>>皆さん
貴重な書き込みありがとうございました。
皆さんの書き込みを見てC→VC#と勉強することにしました。
ここでも議論されている通り、言語の優劣は付け難いものだと思いますが、
ここで挙がるような言語なら最低でも5年は持つと思います。
5年あれば私はゲームはあきらめて今までどおりデータベースオンリーに
なるか、他の言語に移るにしてもさほど苦にならない程度の実力は
ついているでしょう。



692 :仕様書無しさん:04/12/11 20:12:15
>>688
NT3.1 は95より前だったけどな。
しかもWin3.1にWIN32APIを実装するWIN32sってのもあった。

693 :仕様書無しさん:04/12/11 20:14:29
>>691
賢明だな。MSだから〜とかガキみたいなこと言ってる馬鹿どもに尻穴のシワに付着したカスを煎じて飲ませてやりたい。

694 :仕様書無しさん:04/12/11 20:18:06
ま、痛い目みればいーんじゃないの?
俺は別にMSが嫌いってわけでいってたわけじゃないんだけど
そこのへんが理解できない馬鹿がいるみたいだし、
説明するのも面倒だからこの辺でやめよう。

695 :仕様書無しさん:04/12/11 20:24:54
>>694
プ。痛い目痛い目って、どれだけ低スキルなんだよ。
おまえはいつまでも環境選びしてろよww

696 :仕様書無しさん:04/12/11 20:28:50
低脳は言い訳だけは一人前ですから


697 :仕様書無しさん:04/12/11 20:33:17
>>685
あ、Monoは知ってる。
PCオンリーって言うべきだったな。

698 :仕様書無しさん:04/12/11 20:40:00
>>678
例の件って何ですか?

699 :仕様書無しさん:04/12/11 20:57:03
俺も、MS言語で痛い目、って意味が良くわからん
今のところ、バグだからけで困った、という自体にも遭遇してないし…

700 :仕様書無しさん:04/12/11 20:58:27
多少のバグは別の方法で解決できるケースが多いしな

701 :仕様書無しさん:04/12/11 21:27:41
量子コンピュータができたら電子コンピュータ産業が痛い目
Windowsの新バージョンが出たら直前に旧バージョンを買っちまったユーザーが痛い目

って言うのと同じ理屈だな。
C++以前にC言語やってたやつが他の言語に移行していないとでも考えてるんだろうか。

702 :仕様書無しさん:04/12/11 21:40:40
>>699
それは>>663じゃないのか?

俺は>>678の「例の件」が知りたい。

703 :仕様書無しさん:04/12/11 21:50:20
  ☆ チン

        ☆ チン  〃  ∧_∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ヽ ___\(\・∀・)<  「例の件」マダー?
             \_/⊂ ⊂_)_ \_______
           / ̄ ̄ ̄ ̄ ̄ ̄ ̄/|
        |  ̄  ̄ ̄ ̄ ̄ ̄ ̄:| :|
        |           .|/

704 :仕様書無しさん:04/12/11 22:01:46
「例の件」 「例の件」 とうるせーな!この低脳が!










と、他人が煽ってみるテスト。

705 :仕様書無しさん:04/12/12 00:16:47
つうかコンシューマの話をしようぜ。XBOXとPCは就業人数少ないでしょ。
PSPの開発環境っていまだstableじゃないって聞くけど、実際どうすか?
CEDEC2004のPSP講義では他人事ながらヤバそうだなと思ったけど。

706 :仕様書無しさん:04/12/12 00:19:08
>>678
例の件って何ですか?















逃げモードですか?

707 :仕様書無しさん:04/12/12 01:03:22
例の件を知らないって、素人かよww

708 :仕様書無しさん:04/12/12 01:38:22
趣味の問題なのにいちいち下らん宗教戦争に持ちこむなよ。

709 :仕様書無しさん:04/12/12 02:51:06
>>705
XboxとPCって一緒くたに扱われるほど少ないのか?
漏れん所はむしろXboxの話ばっかし来てるんだが。
真面目に3Dに投資してきた会社は今更後に引けないものがあるし
Xboxも悪いことはないつーか、あの開発環境の優秀さ考えれば
むしろ大歓迎。

出資元外資ばっかし、海外向けタイトルばっかりだけどorz
血湧き肉塊踊るFPSとかスポーツゲーとかプロレスとか…

まあ、割り切ればそれもまた楽し。

710 :仕様書無しさん:04/12/12 03:20:02
で・・・



>>678
例の件って何ですか?

711 :仕様書無しさん:04/12/12 03:25:58
本当にプログラマーなら例の件というのがなんのことか考えるまでもなく
わかる。わからないやつは(ry

712 :仕様書無しさん:04/12/12 03:29:03
リアル学生なんで説明キボンヌ

713 :仕様書無しさん:04/12/12 10:26:28
これだけ引っ張ってるんだから、さぞ血湧き肉塊踊る
オチがあるんだろうね>例の件

714 :仕様書無しさん:04/12/12 10:56:17
>>709
日本はゲーム界のガラパゴス諸島だから
全世界で流行りまくりのXboxが普及しないんだよね。

715 :仕様書無しさん:04/12/12 11:05:10
>>714
そのガラパゴスが世界の市場を作り上げた。( ゚∀゚)アヒャ
日本で売れない理由は研究対象となるべき事項ですよ。

716 :仕様書無しさん:04/12/12 11:14:20
国産ゲームですら売れてないのに海外ゲームが売れる理由ないよね。

717 :仕様書無しさん:04/12/12 11:14:40
>>715
まるでイースター島の人口増加→人口過疎化現象の研究だなw
日本のXBOXはやっぱ同発ソフトで損したと思うよ、うん。

718 :仕様書無しさん:04/12/12 11:18:43
あと、初期のディスクに傷が付く問題とか、
他のゲーム機に比べてやたらでかいとか、
導入部分での失敗は多かったね。

719 :仕様書無しさん:04/12/12 11:24:19
ttp://202.222.30.100/prog/logo.gif


720 :仕様書無しさん:04/12/12 11:37:48
人間がアフリカ発祥だからといって先進国がアフリカで商売するのは難しいっしょ。

721 :仕様書無しさん:04/12/12 12:01:28
国内の囲い込みたがり企業のせいで結果的に将来
技術の遅れを取るパターンは何度みたことか


722 :仕様書無しさん:04/12/12 12:28:27
企業の囲い込みもあるけれど、技術者の風土として情報共有の空気がないでしょ。
gems を読んでいても Nintendo Of America の人が執筆していたりするしね。
そういう意味では CEDEC や IGDA には少し期待している。

723 :仕様書無しさん:04/12/12 12:57:17
人を重視する国か、技術を重視する国かの違いだよ。

日本は、技術が企業の存続を決めると言いかねんぐらいに、
技術者よりも技術を重視する国だからな。だから、
技術流出に対しては異常なまでに慎重になる。

米国は、技術よりもむしろ、技術者を重視する国だからね。
だから、オープンソースが普及しやすい。


724 :仕様書無しさん:04/12/12 13:03:10
利いた風なことを…

725 :仕様書無しさん:04/12/12 13:17:26
青色ダイオードの件だけでも、
723の説を肯定するには十分な話だぞ。
そりゃ、そーゆー企業ばかりではないという事実を、
知っている人は知ってるかもしれんが、知らない人も大勢いる。
それだけこの国が病んでるって事だろ。


726 :仕様書無しさん:04/12/12 13:28:16
日本はボトムアップの文化だからな
細かい所は技術力があっても抽象的な話ができない
米が低性能バグだらけのフレームワーク、日本が使い道のないラッパーライブラリだらけ
なのが象徴してると思うYO!

727 :仕様書無しさん:04/12/12 14:31:36
>>726
>>米が低性能バグだらけのフレームワーク、日本が使い道のないラッパーライブラリだらけ
設計できるステイツのほうが全然上だと思うが。w
PCは異様に寡占というか、選択肢がないのにゲームではまったく逆ってところがスゴイ。
PSPの開発は愉しいのかなぁ。同じ携帯機なのにっ……w

728 :仕様書無しさん:04/12/12 14:45:05
>>711
誰にも分らんぞー、オラオラとっとと書け「例の件」とやらを

729 :仕様書無しさん:04/12/12 15:26:35
「例の件」って、イオナズンよりつおいかな

730 :仕様書無しさん:04/12/12 15:48:01
>>729
ギガディンより強いよ

731 :仕様書無しさん:04/12/12 16:20:38
で・・・



>>678
例の件って何ですか?

732 :仕様書無しさん:04/12/12 16:33:19
>>723
日本のゲーム企業が技術流出に慎重ってのは、何かの冗談にしか
聞こえない……。

技術は人と一緒に巡り巡ってる。ただ、外に発表する機会もなければ
メリットもないから、業界の外に出てこないだけで。

733 :仕様書無しさん:04/12/12 16:45:52
仕事忙しいからあまり2chもしないみたいだしね

734 :仕様書無しさん:04/12/12 17:02:02
それはつまりここにいる人たちは仕事がないってことですか

735 :仕様書無しさん:04/12/12 21:26:10
>>725
それは米的な見方でしょ。

736 :仕様書無しさん:04/12/12 21:35:36
で・・・



>>678
例の件って何ですか?

737 :仕様書無しさん:04/12/12 22:03:28
おい、768よ。
藻前が答えないと、多分、このスレを使い切るまで、
例の件って何ですか?と聞かれるぞ、それでも良いのか?


738 :仕様書無しさん:04/12/12 22:09:50
じゃ、768頼むな

739 :仕様書無しさん:04/12/12 22:10:22
しつこく聞いてるフリして荒らしてんのは一人だけだろ

740 :仕様書無しさん:04/12/12 22:12:23
いっぱい居ると思う、オレもオチが気になるし(笑

741 :仕様書無しさん:04/12/12 22:13:10
下手すりゃC#死滅だもんなw

742 :仕様書無しさん:04/12/12 22:14:46
こんな所に具体的に書けるわけないだろ。
例の件でわかる奴だけわかればいいよ。

743 :仕様書無しさん:04/12/12 22:17:42
で・・・



>>678
例の件って何ですか?

744 :仕様書無しさん:04/12/12 22:37:39
例の件…
まさかD言語がC++の後継言語に認定された事とかじゃねーだろーなw

745 :仕様書無しさん:04/12/12 22:40:38
なんだそりゃ? ソースは?

746 :仕様書無しさん:04/12/12 22:49:15
例の件?
次期OfficeはCOBOL.netで開発されることか?
確かにMSの今後の主流はCOBOL.netに移行するだろうがC#が消滅するわけじゃねえよ。
知ったかぶりするなバカ

747 :仕様書無しさん:04/12/12 22:52:42
↑その落ちは寒すぎ。

748 :仕様書無しさん:04/12/12 23:05:33
漏れん所は力ないから出来ないが、藻前らの会社はMMORPGやらんのか?
日本製が無さ過ぎで韓国に市場取られるぞ。

749 :仕様書無しさん:04/12/12 23:14:58
まだ市場が小さいしなぁ > オンラインゲーム
やるにしてもコンソールのオマケみたいな感じでしょ。

750 :仕様書無しさん:04/12/12 23:18:58
>>748
なぜ全力を尽くさないのか?

751 :仕様書無しさん:04/12/12 23:23:38
>>750
全力を尽くしても、出来ることと出来ないことの判断はつく大人なんだが何か?
>>750は全力を尽せば何でも出来ると思っている消防か?

752 :仕様書無しさん:04/12/12 23:26:52
>>750は日本に追いつくとか言ってる韓国人並のアホ

753 :仕様書無しさん:04/12/12 23:27:45
見事なまでに休日モードだな

754 :仕様書無しさん:04/12/12 23:29:13
>>749
■eの11が結構な利益上げてても市場小さいのか?

755 :仕様書無しさん:04/12/12 23:32:02
そんなに儲かるなら、任天堂がとっくに進出してるでしょ。
任天堂に比べたら、スクエニなんぞ取るに足らん。

756 :仕様書無しさん:04/12/12 23:34:20
MMORPGの客層と任天堂の客層は違いすぎるだろ。

757 :仕様書無しさん:04/12/12 23:45:00
751「おまえらMMORPG作んないと韓国に負けるだろコラ。おれは努力しねーけどなw」

758 :仕様書無しさん:04/12/12 23:45:26
>>750が漏れに20億円ぐらい出資してくれればMMORPGリリースに全力を尽くすぞ。
だから750は全力を尽くして20億円用意してくれ。

759 :仕様書無しさん:04/12/12 23:46:36
>>754
合併前のエニが失敗してる。
結構やってた所は多いぞ。

760 :仕様書無しさん:04/12/12 23:49:09
>>759
日本のPC市場は難しいと思うぞ、ゲーム機でよろ。

761 :仕様書無しさん:04/12/12 23:50:07
資金を集めることは『全力』には含みません。
なぜならただのコーダに過ぎないからです。

762 :仕様書無しさん:04/12/12 23:51:48
仕事の都合で、あんまり有名じゃない映画をDVDで山ほど見たんです。
そこで見たうちの一つが韓国映画「リザレクション」。

世の中韓流だの韓国ブームだの、日本は韓国映画やドラマを
見習うべきだとかよく言われてるけど、そういうことかぁ、ってオレ、わかっちゃったんだなあ。
「このオリジナリティはすごいよ! 主役はさえない韓国男性なんだけど、
仮想現実の世界でヒーローになって、拳銃とか拳法とか使えるようになるわけ!
仮想現実の世界を表現するのに、
黒ににグリーンのハングル文字がランダムに雨のように降ってくる斬新な映像もすごい! 
仮想現実の世界を彼から守るため、システムが主役を殺そうとするんだけど
至近距離から銃で撃たれて、その瞬間に弾丸がハッキリ見えるくらいのスローモーションになるのね、
撃たないでーって思って見てた僕らの心の声が、そこで 避けないでー、に変わるわけなんだけど
もちろんえびぞりでブリッジで弾丸を避けますよ!」
「一緒に見たほかの国の映画に比べれば、この韓国映画は非常にストーリーがよくできてるんですよね、
元本があるから!(大爆笑

いやあ、これは皆さん絶対見てくださいよ、おすすめする人はね、マトリックスを見てない人ね(大笑
これいいの? これが許されるなら俺とタシロ(若手芸人)が青と赤のジャージ着てホワイ♪とか
踊りながら歌っても許されるんじゃないの?
で、ネットでこの映画調べてみたら、韓国のアカデミー賞に相当する映画賞で、映像技術賞とか
いろいろもらってるんだよねこの映画! 賞はダメだろ? 
見てない作品がひとつ、ありますよね選考委員」
「こんな作品に賞まで出してる韓国なのに、冬のソナタの音楽はテレビやラジオで使っちゃダメとか
すっげー細かい権利とか言ってくんの。オカシイだろオマエそれ、と!」


763 :仕様書無しさん:04/12/12 23:52:38
>>761はただのコーダか!、口達者だけの愚か者か。

764 :仕様書無しさん:04/12/12 23:53:46
>>763
なんか日本語が不自由になってるぞ。
動揺してるのか?w

765 :仕様書無しさん:04/12/12 23:55:14
つーか、>>750を受けて>>751でいきなり青スジ立てて噛み付くあたり、
神経質なキモグラマの匂いがプンプンする。

766 :仕様書無しさん:04/12/13 00:00:46
キモグラマw

767 :仕様書無しさん:04/12/13 00:04:01
>>755
任天堂がポケモンオンライン出したら他のメーカー死滅だろw

768 :仕様書無しさん:04/12/13 00:07:07
お前らこれでも見て落ち着け
http://jessica.x0.com/picture/a14.jpg

769 :仕様書無しさん:04/12/13 00:12:13
>>754
この業界に入ってみれば分ったんだろうけどね、作ってた所は結構あったのさ、
問題は死屍累々というだけ。

770 :仕様書無しさん:04/12/13 00:17:31
エクスリュージョン思い出したw

771 :仕様書無しさん:04/12/13 00:25:27
蒸し返しすまんが、どうにも気になるんだ「例の件」
というわけで、答えてくれ>>678

772 :仕様書無しさん:04/12/13 00:41:23
>>771
あのサイトに詳しく書いてあるよ

773 :仕様書無しさん:04/12/13 01:12:28
どのサイトだよ。

774 :仕様書無しさん:04/12/13 01:19:10
それより、プレステ3はOpenGLってホント?
開発がムチャクチャ楽になるんだけどw

775 :仕様書無しさん:04/12/13 01:19:15
こんな所に具体的に書けるわけないだろ。
あのサイトでわかる奴だけわかればいいよ。


776 :仕様書無しさん:04/12/13 01:24:01
>>774
ああ、プログラマが減らせるな。

777 :仕様書無しさん:04/12/13 01:34:25
VGAもCPUも別物だし、メモリもPS2より大幅増でしょ?
グラフィックもだいぶ綺麗になりそうw
つーより、PS2のライブラリがウンコ過ぎた。

778 :仕様書無しさん:04/12/13 01:40:26
>VGAもCPUも別物だし、メモリもPS2より大幅増でしょ?
SCEにへんな期待しない
絶対またギリギリに決まってる

779 :仕様書無しさん:04/12/13 01:58:25
http://www.itmedia.co.jp/lifestyle/articles/0412/09/news002_5.html
PS3はこれくらいのグラフィックも可能になるらしい。
OpenGLが確定なら神。

780 :仕様書無しさん:04/12/13 02:13:15
ヘタレデザイナーしかいない俺んとこには関係ねーや。

781 :仕様書無しさん:04/12/13 06:10:08
TVに出力する時点であの映像は無理、
D3、D4とか対応してくれるのかな?

782 :仕様書無しさん:04/12/13 06:16:07
>>779
なんだよ。
GPUはnVidia製使うんだ。
もう、PCでいいだろw

783 :仕様書無しさん:04/12/13 06:17:13
いやまったく

784 :仕様書無しさん:04/12/13 06:26:36
>>762
冬のソナタの曲もパクリだったって話だったと思ったが・・・
紅白出るとかで問題になってなかったっけ?

785 :仕様書無しさん:04/12/13 06:32:15
今のPS2の開発環境から、OpenGLに移れるならそれだけで満足だw

786 :仕様書無しさん:04/12/13 06:32:36
ネットワーク対応がどうのこうの言われてもこまるよな。
PCもってない家庭が茶の間まで電話線ひっぱってこれるとは思えない。
据え置機に変な幻想抱いてる開発者逝って良し。

787 :仕様書無しさん:04/12/13 06:37:09
次世代機が出るまでにモデリングソフト作ってる会社からリアルタイム用のシェーダエンジンが配布されて(DX用GL用)
開発者はモデルまわりはモデルロードしてシェーダロードしてアニメーションゲットして
終わりってところまでいっててほしかったが無理だったか。

788 :仕様書無しさん:04/12/13 06:37:52
つーことは、地道にこっから作るっきゃねーなw
まあ、いくらかましか。

789 :仕様書無しさん:04/12/13 06:37:53
>>779
正直、凄いと思った。
これ、PS3発売開始までキープだな。

790 :仕様書無しさん:04/12/13 06:41:17
>>789
>正直、凄いと思った。
なにが?
Unreal Engine3.0が?
そりゃすごいよ。
でもPS3にのるかどうかはただの記者の妄想だろw
変な夢もつなよw

791 :仕様書無しさん:04/12/13 06:42:05
UnrealEngineは開発ツールだろ、PS3に載らなくても
ライブラリを購入すれば
使えるんでねぇの?

792 :仕様書無しさん:04/12/13 06:43:53
つーか、ハードの性能差はソフトじゃ超えられないんだな。

793 :仕様書無しさん:04/12/13 06:46:34
「PSPじゃない」 父親殴った息子を逮捕
http://www.f7.dion.ne.jp/%7Emoorend/news/2004121201.html

794 :仕様書無しさん:04/12/13 06:52:23
>>793
笑って済ませて金もらって自分で買いに行けよ…

795 :仕様書無しさん:04/12/13 06:52:34
次あたりになると、ドッターだけでなくローポリ職人も氏にそうな予感。

796 :仕様書無しさん:04/12/13 06:55:13
最後の砦かとおもわれる遠景ローポリなんぞ
もはやライブラリ任せになりつつあるからな

797 :794:04/12/13 06:55:39
って果物ナイフ全然関係ねえじゃん。刺したと思い込んで暗い気分に
なったじゃん。

798 :794:04/12/13 06:57:54
しかも新聞社のサイトじゃないじゃん。ネタサイトじゃん…。

799 :仕様書無しさん:04/12/13 07:37:23
うむ、なぜ唐突にアレが張られたのが理解できんが

800 :仕様書無しさん:04/12/13 09:08:07
>鈍器のようなもの
めっさワロタ

しかし父親に並ばせといてあまつさえキレ出すとは・・・(#´,_ゝ`)

801 :仕様書無しさん:04/12/13 09:11:47
>>795
その頃にはローポリ職人は携帯系へ完全移行してくる予感

802 :仕様書無しさん:04/12/13 10:27:02
SCEにしてみりゃ自分が苦労してサードパーティー楽させる義理はないからな。
生かさず殺さずの手の抜き加減がいいのさ。

803 :仕様書無しさん:04/12/13 11:11:40
ドラクエ8をやって、ローポリはまだまだいけるな、むしろ、と思った次第。

804 :仕様書無しさん:04/12/13 11:33:29
>>802
そんな高度なことは考えてないよ、単にSCEの内部組織がハチャメチャなだけ。

805 :仕様書無しさん:04/12/13 12:06:49
>>678
で、例の件って何ですか?

806 :仕様書無しさん:04/12/13 12:14:13
面接官「特技は例の件とありますが?」
>>678 「はい。例の件です。」
面接官「例の件とは何のことですか?」
学生 「MSです。」
面接官「え、MS?」
学生 「はい。MSです。例の件でC#に大ダメージを与えます。」
面接官「・・・で、その例の件は当社において働くうえで何のメリットがあるとお考えですか?」
学生 「はい。それを知っていれば言語で痛い目を見なくて済みます。」
面接官「いや、当社にはたかだか開発言語の事で痛い目みるとかぬかすような輩はいません。それにそもそもコンシューマだとC#なんて使いませんよね。」
学生 「でも、MSの大本営発表にも勝てますよ。」
面接官「いや、勝つとかそういう問題じゃなくてですね・・・」
学生 「C#がおしゃか決定なんですよ。」
面接官「ふざけないでください。それにおしゃかって何ですか。だいたい・・・」
学生 「おしゃかです。死滅とも書きます。おしゃかというのは・・・」
面接官「聞いてません。帰って下さい。」
学生 「あれあれ?怒らせていいんですか?言いますよ。例の件。」
面接官「いいですよ。言って下さい。例の件とやらを。それで満足したら帰って下さい。」
学生 「運がよかったな。今日は宿題が忙しくて時間が足りないみたいだ。」
面接官「ワナビーは帰れよ。」

807 :仕様書無しさん:04/12/13 12:15:05
そんな長文を打ち込んでるヒマがあったら、一行でもコード書けと

808 :仕様書無しさん:04/12/13 14:35:15
>>779
Half Life2が一気にショボゲーの部類に入りそうだなw

809 :仕様書無しさん:04/12/13 14:59:02
そうかなぁ・・・
個人的にはDOOM3みたいなテカテカのマネキン系のCGは好きじゃないな。
かといってドラクエみたいなのもあまり量産されて欲しくない。


810 :仕様書無しさん:04/12/13 15:01:47
DQ8は草木と衣装にポリゴン当てすぎ。

811 :仕様書無しさん:04/12/13 19:13:25
トゥーンシェーダのこと?>ドラクエ
元ネタが漫画のゲームはトゥーンシェーダのほうがいいな。
とりあえずハードの性能が上がってOpenGLも使えるなら満足だよ。

812 :仕様書無しさん:04/12/13 19:27:14
Ninja最高Ninja

813 :仕様書無しさん:04/12/13 21:13:17
トゥーン?ただ、テクスチャをそういうふうに書いてるだけだろ

814 :仕様書無しさん:04/12/13 21:55:59
学校の本屋のDirectXの入門書でも解説されてたw>トゥーンシェーダ
なんか2通りのやり方があるらしいけど、入門書で扱ってるモン。

815 :仕様書無しさん:04/12/13 21:59:43
>>813
違います。

816 :仕様書無しさん:04/12/13 22:00:30
予備知識のない俺様が今即座に3通り思いついたわけだが。

817 :仕様書無しさん:04/12/13 22:00:58
トゥーン=段階的な陰影+輪郭描画
DQ8はあそらく後者だけ。

818 :仕様書無しさん:04/12/13 22:12:37
光を発する敵と並べてみたけど
トゥーンレンダしてるようには見えんが・・・・

819 :仕様書無しさん:04/12/13 23:28:47
つか、リアルタイム処理のトゥーンシェーダなんて誰も望んでないよ。
どうしたってモデリングソフトでレンダリングしたトゥーンシェーダみたいには
綺麗にはならない。ジャギってて汚いし見るに耐えない。
それでも使うのは開発者の自己満足、勘違い。

ゆめりあってゲームあったじゃん?
アレってトゥーンシェーダじゃないけど、
モデリングソフトでレンダリングしたトゥーンシェーダみたいに
綺麗にできてたじゃん。
これは開発者のセンスがよかった。

820 :仕様書無しさん:04/12/14 00:32:50
「見つからなければ死ね」
http://www.nintendo-inside.jp/news/152/15273.html

PS3もいいけど、DSもいいかな orz

821 :仕様書無しさん:04/12/14 00:38:24
そういや、DSの開発環境ってどうですか?>すでにやってる人

822 :仕様書無しさん:04/12/14 00:55:30
守秘義務

823 :仕様書無しさん:04/12/14 01:11:31
すくなくとも前のよりまし
でもあの動作はないよな 任天にしては珍しい

824 :仕様書無しさん:04/12/14 03:07:03
ところで、ゲームPGはあまり詳しくないんだが
コンシューマとネトゲはどちらもCかC++で組まれているのか?

825 :仕様書無しさん:04/12/14 03:13:24
昔はそうだったが最近だとHSPが多い、あとはDelphi

826 :仕様書無しさん:04/12/14 03:40:20
HSPって面白いよなーいろんな意味で。

827 :仕様書無しさん:04/12/14 03:45:19
あとはlisp、fortranも増えつつある

828 :仕様書無しさん:04/12/14 06:40:47
COBOLだよ! COBOLしかないって!

829 :仕様書無しさん:04/12/14 09:44:03
もじぴったんの辞書なんかはPrologで実装されてるよ。

830 :仕様書無しさん:04/12/14 09:55:05
人間の優しさの80%はHSPで出来ています。

831 :仕様書無しさん:04/12/14 14:14:00
たまに気分転換にBrainfuckやwhitespaceかな。

832 :仕様書無しさん:04/12/14 16:47:35
>>824
可哀想だから一応マジレスしておいてやるC++だよ。
というか今の所はそれ以外に選択肢がない。

833 :仕様書無しさん:04/12/14 16:51:16
ていうか、C++以外いらねw

834 :824:04/12/14 17:28:56
>>832
ありがとう

835 :仕様書無しさん:04/12/15 00:35:29
コンシューマプラットフォームでCodeWarriorを使用しているのですが、
プロジェクトが大規模化してくるにつれリンク時間が無視できなくなってきました。
現状でリンクに3分くらいかかります。なんかいい方法ないかと探しているのですが、
有効な解が見つかりません。いい事例があったら紹介きぼんぬ。

836 :仕様書無しさん:04/12/15 00:51:59
地球シミュレータを借りる

837 :仕様書無しさん:04/12/15 00:57:59
フルコンパイルはしかたないとして。
肝になるヘッダ(更新するとかなりのソースをコンパイルしてしまうようなの)は腫れ物を触るように扱うことだろうなぁ
C++だったらかなりの確立で設計ミスだと思うが。オブジェクトそれぞれが一蓮托生になってたりしない?

838 :仕様書無しさん:04/12/15 01:09:28
コンパイル時間かかり過ぎならまだわかるが、
リンクでかかりすぎるのは単にシンボル数多すぎなんじゃなかろうか。
とりあえず普段の作業ではリンク時最適化切っとけば?
数%しかかわらんし。

839 :仕様書無しさん:04/12/15 01:10:00
>>835
オーバーレイ?
リンクで3分なんて信じられん。
RAMディスク作って、Temp をそこにしてみたら?

840 :仕様書無しさん:04/12/15 01:11:16
>>837
えーと、コンパイル時間は問題ではないのです。問題はリンク時間なのです。
ちなみにコンパイル時間は、

・プリコンパイルヘッダ
・ブリッジパターン
・Pimplイディオム
・先行宣言

等々を駆使し、依存性の排除によってかなり高速化されています。
いま問題になっているのは、リンクが長いことによって実行までのターンアラウンドが長く、
効率が落ちているといことなのです。リンクテクニックはあまり文献がなく、
正直どうすれば良いかがわからない、というのが実情です。

841 :仕様書無しさん:04/12/15 01:13:57
速いパソコンを買うのが一番低いコストで大きい効果を得られる。

842 :仕様書無しさん:04/12/15 01:17:10
>>835==>>840です。

>>838
そうなんです。シンボル数が多いのはその通りです。
通常作業時はすぐにデバッガで追うことができるようにデバッグビルドしています。
なので、シンボルはアホみたいに多いです。
ですが、デバッグビルドは開発の上で必須です。(経験上)

>>839
RAMディスク! すばらしいです。その案を検討してみます。

>>841
痛いほどその重要性を上司が理解しているので、
現状で手に入りうる最高性能のPCを使っています。

843 :仕様書無しさん:04/12/15 01:19:02
dll使う。

844 :仕様書無しさん:04/12/15 01:25:29
よほどの特殊事情が無い限り、RAMディスクでは多分何も変わらんぞ。
だってOSがほっといても使える限りのキャッシュ利かせてるのが普通だもの。

845 :仕様書無しさん:04/12/15 01:25:43
erxどうよ。

846 :仕様書無しさん:04/12/15 06:07:06
保守

847 :仕様書無しさん:04/12/15 08:00:04
>>842
> ですが、デバッグビルドは開発の上で必須です。(経験上)
俺のところは、デバッグシンボルは出力してない。デバッガもソースコード
デバッガは使わず、マシン語レベルで追えれば良いや、で済ませてる。
どうせ C++ で最適化すると、ソースコードとマシン語の対応とれないんで。

代わりにソースコード中に assert() ばらまいて、そこでバグをひっかける
ようにしてる。

CodeWarrior ではなく gcc 使ってるが、リンクは数秒だよ。

848 :仕様書無しさん:04/12/15 08:59:24
>>678
で、例の件って何ですか?


849 :仕様書無しさん:04/12/15 09:42:18
>>844
キャッシュしても書き込み速度分の向上はあるよ。
しかし微々たるものなのは同意。

デバッグビルドでそんなにリンク時間かかるの? > CodeWarrior
何MBくらいのオブジェクト吐き出してるんだろう。

850 :仕様書無しさん:04/12/15 10:16:15
Pimplイディオムを駆使した結果クラス数が増えて大量のシンボルができた、
それで、コンパイル時間がリンク時間に転嫁されたとか?
と想像してみる。


851 :仕様書無しさん:04/12/15 11:42:20
3分は長すぎるね、大規模とはいえ。
ライブラリ間の循環参照みたいな無茶なことはしてないよね。

852 :仕様書無しさん:04/12/15 12:31:30
>>850
そういうのはあるだろうね

853 :仕様書無しさん:04/12/15 20:24:59
3分て長いの?

854 :仕様書無しさん:04/12/15 21:13:17
フルビルドに一時間とか掛かるから相対的にどうでもいいかも。
グリッドコンピュータで分散コンパイルとかやらないのかね。
その前にマルチコア対応コンパイラが先か?

855 :仕様書無しさん:04/12/15 22:37:37
>>854
グリッドなんて待たなくても、分散コンパイルなら rsh でネットワーク上の
ホストにプロセスばらまくだけで OK じゃん。

あとマルチプロセッサのマシン使ってるなら GNU make の -j オプション
調べとくとよろし。

856 :仕様書無しさん:04/12/15 22:41:50
インクリメンタルリンクってなにげに重要なのかしら。

857 :仕様書無しさん:04/12/15 22:54:54
>>855
IDEがシームレスにサポートしないと使ってあげない。

858 :仕様書無しさん:04/12/15 23:05:09
おまいら、そうやって俺に残された貴重な言い訳(「あ、今リンク中なんで、ちょっとタバコいってきまつ♪」)を潰そうとしてるな?

いいか?フルコンパイルってのはなぁ、プログラマに残された最後のオアシスなんだよ!
仕事中でありながらPCの前に座ってなにもしなくても許される。そんな至福の時間。
ゲームで遊んでても「今コンパイル中で他にやること無いんですよ」と切り返せる。まさに最後の切り札。
バグの原因がつかめず思い当たるフシも無い。そんなときの一縷の希望。
 そ れ が フ ル コ ン パ イ ル な ん だ よ
それを、それを、、高速化だ? RAMディスクだ!? 3分が待ちきれないだ!!??




ごめんなさい、ボクが悪ぅございました・・・orz

859 :仕様書無しさん:04/12/15 23:20:25
>>858
俺も同意。
フルコンパイルに20分(最近じゃ25分ちかくなってる)近くかかるから
そのおかげでちょっとゆっくりできる。
あんまりいそいで仕事やる必要ないって。
この業界の他の業種と比較したら俺等がダントツで
働いてる時間多いんだからちょっとゆっくりしようや。
あんまりイスに座りっきりだと痔になるぞ(実際なったし日帰り手術代5万円ふっとんだ)
何?3分まちきれないって、馬鹿じゃねぇの。
イスたって柔軟体操でもやってろって。

860 :仕様書無しさん:04/12/15 23:25:41
うちの会社は仕事中に離席しても何も言われないから

861 :仕様書無しさん:04/12/15 23:26:13
>>859
> この業界の他の業種と比較したら俺等がダントツで
> 働いてる時間多いんだから
なんつーか、自業自得という単語が脳裏に浮かんだ。


862 :仕様書無しさん:04/12/15 23:43:11
>>860
連絡係以外なら
キッチリスケジュール通り進めていたら10分ぐらい姿消していても何も言われんのが普通じゃないか?

863 :仕様書無しさん:04/12/16 00:12:18
>>858
心の底から同意

864 :仕様書無しさん:04/12/16 01:11:50
うちはプロジェクト末期でもCWでフルコンパイル5分程度だけどな。
P43GHzでデバッグビルドでオーバーレイもそれなりに使ってる。

なんか別の原因な気がするな。


865 :仕様書無しさん:04/12/16 01:13:38
>858
俺も同意。


866 :仕様書無しさん:04/12/16 01:43:19
>>835
リリース用のビルド(デバッグ情報なし)でも同じリンク時間?

867 :仕様書無しさん:04/12/16 02:02:55
バイナリデータを配列で持ってて、それをコンパイラが
ご丁寧にリストファイルに書き出したものだから、
ディスクアクセスが大変なことになったことがある。

868 :860:04/12/16 02:05:02
>>862
ウチは、10分どころか、半日いなくても平気。
外出してても。

869 :仕様書無しさん:04/12/16 04:19:03
>>868
それは単に居ても居なくてもいい存在だと(略

それはさておき、
デバッグシンボルが多くてリンクに時間がかかりすぎる、てのは正直納得遺憾。
CWは漏れ自身は嫌いだが、奴のビルド性能は決して悪くない、つーか優秀なはず。
仮にシンボル数が多くても、そんなに時間食うのは別の理由がありそな気がする。


870 :仕様書無しさん:04/12/16 07:55:39
>>866
リリース用ビルドのほうが時間が早いとか言ってる?

自分は
デバッグ版はオプティマイズ off
リリース版はオプティマイズ on
で圧倒的にデバッグ版のほうがビルド早いんだが…

871 :仕様書無しさん:04/12/16 09:40:29
>>870
コンパイル時間とリンク時間の区別がつかない奴は黙ってろよ。

872 :仕様書無しさん:04/12/16 11:22:46
速いマシン、速い回線があなたから休憩時間を取り上げる。
遅いマシン、遅い回線があなたから休憩時間を取り上げる。

とマーフィーを思い明日。

873 :仕様書無しさん:04/12/16 12:17:28
コンパイル時間は短いほうがいいに決まってる。
「貴重な休憩時間が〜」とかって理解できない。
早く仕事終らせて早く帰ったほうが休めるのに。

874 :仕様書無しさん:04/12/16 12:40:49
>>873が理論上良いこと言った。

875 :仕様書無しさん:04/12/16 12:52:00
ごめん、ホント理想を語っちゃった

876 :仕様書無しさん:04/12/16 12:54:56
コンパイルが速くなるほど、生産性があがるほどおまいらは安くなっていく・・・・。

877 :仕様書無しさん:04/12/16 13:05:27
理想:>>873
現実:早く仕事終らせると仕事を振られる。

878 :仕様書無しさん:04/12/16 13:25:20
>>678
で、例の件って何ですか?


879 :仕様書無しさん:04/12/16 14:40:43
厚生労働省の通達に、会社は従業員が一時間につき10分は画面見ないように
仕事させること、ってのがあるから、ちょうどいいんだよ。

880 :仕様書無しさん:04/12/16 15:26:13
>>835 です。仕事中こっそり。

>>866
いろいろと試したところ、リリースビルドだと圧倒的にリンク時間は早くなりますね。
やはり、C++のシンボルがあふれてる感じです。デバッグビルドで実行ファイルが
300MB近くになってます。(リリースだと数MB)

>>870
コンパイル時間ではおっしゃるとおりです。デバッグビルドのオプティマイズoffの
コンパイル時間は速いですね。

881 :仕様書無しさん:04/12/16 17:39:44
コンパイルが中途半端な時間だとやる気しなくなるというか、ストレスたまるなぁ・・・。

激しく長いか、一瞬じゃないと嫌だ。

882 :仕様書無しさん:04/12/16 18:20:23
コンパイル開始と同時にうちわを手にしていたあの夏。
当然、網蛾をあおいだわけですが。

883 :仕様書無しさん:04/12/16 18:20:57
理想:>>873
現実:早く仕事終らせると追加仕様がくる。


884 :仕様書無しさん:04/12/16 20:01:49
>>870
俺のところは optimize off だと、すでにがメモリ足りない今日この頃。

885 :仕様書無しさん:04/12/16 20:39:11
どんな環境でもプログラマの仕事量は一定である。

886 :仕様書無しさん:04/12/16 20:44:06
                       | //ヽ/i
      !!                   、ヽヽ//ノ
ヾ、        〃      iヽ  _/  /i    ヽ
                   | ヽr', ヽ/ i     }
      街          |  ヽ  /  i    }
    に の          |二二二二二}   イ
    お 中         6――□ ,□/―――ヾ
=  う 心  =       \    /´_..、--―┴ヘ        !!
    だ で           r'〃 ̄ ̄ ̄    __.-<\} ヾ、          〃
    ち              {:.|l  _....--―T ̄ .._   |
    は          ハ:.ゞ_、´ソ:!   |     `T "j      ハ   や
    !             r、:.:.:.:.:.:.:.:j   |/   ノ !  /      ッ   め
〃        ヾ、      {三:::::.:.:.:.イ    j     ! /=    サ    て   =
     !!         _.ノ´:.:.:::::::/    /     ! /        ン    く
              r':.:..:.:.:.:.:.;r' `ニ´ /     '/_      !   れ
            /ゝ、_/!{   ∠     { \ `ヽ    
             ! : : : /  ヾ /  \ヽ二二ン ト、 / 〃         ヾ、
             ! : r'´   /      ヾ\  \ \      !!
            r┤  _イ    _.\    |. \   ヽ \
            ヘ_ゝ∠:_ノー<´:::::::::\  |:.  \   !   ヽ
                 l::::::::::::::::::::::::ノ`7|    \ !  ハ 
                 l::::::::::::::::::;:イ、_/:::|       〉|!    |
                    l:::::::::::::::f|≡!|::::::|    / !|    j

887 :仕様書無しさん:04/12/16 21:24:46
いやぁ、久々につまらないバグ埋め込んじまったよ

int Dat[2] = { 1, 2 };
int Pt = 0;

int GetDat() { return Dat[Pt++]; }
main() { printf("%d,%d\n", GetDat(), GetDat()); }

1,2を期待してたのに、ひっくり返るんだもんな。
アセンブラジジィにはC言語は高度すぎるぜ。

888 :仕様書無しさん:04/12/16 21:27:19
ひっくり返る保障もないんじゃなかったけ?3になる可能性も。

889 :仕様書無しさん:04/12/16 21:29:29
>>835 です。まだ仕事中です。

>>880
ごめん。書き間違えました。300MB近くメモリ使用量が増えて、生成された実行ファイルは
16MBぐらいでした。ほとんどメモリ上でリンク処理をしているらしく、RAMディスクはあまり
効果がありませんでした。残念!

890 :仕様書無しさん:04/12/16 21:31:41
>>887
引数の評価順序は不定ですよ。
http://www.bohyoh.com/CandCPP/FAQ/FAQ00089.html

891 :仕様書無しさん:04/12/16 21:52:17
なぜまずいのかすぐに分からなかった。_| ̄|○

892 :仕様書無しさん:04/12/16 22:04:49
>>871
少なくとも洩れの Visual C++ にはリンク時のオプティマイズもあるんだが?
だからコンパイル/リンクといわずにビルドといってるんだが?

>>889
300MBの実行ファイルは想像を絶してしまったが、16MBと聞いて一安心(^_^;
にしてもCWのビルド時間ってこんなに遅いものなの?

893 :仕様書無しさん:04/12/16 22:55:30
>>892
CodeWarriorの話してるのに・・・・

894 :仕様書無しさん:04/12/16 23:15:33
プログラマーになるにはどの学科に行けばいいんですか?


895 :仕様書無しさん:04/12/16 23:20:50
京都コンピューター学院

896 :仕様書無しさん:04/12/16 23:58:12
>>893
コンパイル時間とリンク時間とビルド時間の区別がつかない奴は黙ってろよ。

897 :仕様書無しさん:04/12/17 00:13:09
ビルド時間=ンパイル時間+リンク時間で良いか?

898 :仕様書無しさん:04/12/17 00:14:23
>>894
数学科もしくは物理科

899 :仕様書無しさん:04/12/17 00:16:57
ンパイル!ンパイル!バイン!バイン!

900 :仕様書無しさん:04/12/17 00:37:45
スレが盛り上がっているところ、申し訳ありません。

ドラクエ8にキラーパンサーという乗り物がありますが、これを呼び出すときのムービーついて
お聞きしたい。開発者の説明によれば、このムービーの役割はロード時の暗転を防ぐためと
いうことですが、町からフィールド上に出たときや、鳥になって空を飛ぶときのロード時間に
比べて長く感じます。それに素人目にはキラーパンサーのデータを読み出すだけでよいような
感じがします。

本当に開発者がいうように、ロードするのに時間がかかりすぎてこのムービーが必要になって
いるのか、ゲームプログラマの目から見てどう予想されますか?

901 :仕様書無しさん:04/12/17 00:51:28
ageるな

902 :仕様書無しさん:04/12/17 02:14:13
>>889
リンクに3分なんて信じられんから貧相なマシンを使ってると思ってRAMディスクと書いたまでで、まともなマシン使ってたら効果なんて無いだろうな。
オーバーレイのターゲットはいくつくらいあるの? 1つ当たりどの程度リンク時間かかる?
誰かが言ったようにerx試してみたら?

>>900
演出が長すぎるという話でいいのかな?
・演出として意味のあるカットの長さ
・DVD読み込みのリトライがおきても十分な長さ
という理由だろう。

903 :仕様書無しさん:04/12/17 02:42:20
単に演出としての長さの問題でしか無い気がするなあ。
>>902でFAなんじゃないだろか。

904 :仕様書無しさん:04/12/17 02:47:23
>>880
それ、リンク時最適化の影響だよ、やっぱり。
具体的にはデッドコードストリップと、関数呼び出しプロトコル類の調整による最適化。
で、疑問なんだけど、デバッグ用のシンボルが多いと言うが、そのデバッグ用のシンボルって奴、
大半はリリースビルド時にははずしておけるものじゃない?
ちょっとした関数や定数類はインライン化される様に組んじまえば、リンク時に
直接相手にしなければならないシンボル数は事前に相当減ってるはずなんだけど…

905 :仕様書無しさん:04/12/17 07:39:10
>>894

プログラマーなんか高卒でもなれる。
とりあえず東大行っとけ。

906 :仕様書無しさん:04/12/17 07:46:40
>>904
おかしいだろ。
「リリースビルドだと圧倒的にリンク時間は早く」なるんだぞ。

907 :仕様書無しさん:04/12/17 07:52:33
>>904
CodeWarrior ではなく gcc だと、マップファイル書き出すと動作がきわめて
遅くなるコトがあったなぁ。

908 :仕様書無しさん:04/12/17 08:06:25
>>894
プログラマーは、プログラムを作る人だから、
プログラムを作ればいい。プログラムを作る事に対して、
特別な許可も必要ない。開発環境は金を出せばそろう。


909 :仕様書無しさん:04/12/17 08:07:32
>>894
情報とつく学科を選択すれば大丈夫。

910 :仕様書無しさん:04/12/17 13:06:46
>>894
SFC

911 :仕様書無しさん:04/12/17 13:27:53
>>889
>300MB
メモリースワップしていないですか?
あれが起こると極端に遅くなるよ、解決策はメインメモリーの追加、RAMディスクは削除がいいと思われ。


912 :仕様書無しさん:04/12/17 18:15:38
>>911
いくらなんでも、それでご飯食べてるやつに言うレスじゃないだろ。

913 :仕様書無しさん:04/12/17 21:40:13
ゲーム方面行くなら数学とか物理とか工学とかのほうがいいんじゃねーの。
プログラミング自体は独学で十分だし。

914 :仕様書無しさん:04/12/17 22:28:32
>>913
>ゲーム方面行くなら数学とか物理とか工学とかのほうがいいんじゃねーの。
いらないいらないいらないいらないいらないいらないいらないいらない
いらないいらないいらないいらないいらないいらないいらないいらない
いらないいらないいらないいらないいらないいらないいらないいらない
いらないいらないいらないいらないいらないいらないいらないいらない
いらないいらないいらないいらないいらないいらないいらないいらない
いらないいらないいらないいらないいらないいらないいらないいらない

915 :仕様書無しさん:04/12/17 23:46:20
>>913
会社によって違う
某社では物理ができない奴は開発部隊になれないといってました
某社では入社してから覚えればいいといってました
某社ではそんなものよりワードやエクセルの資格を取りなさいといってました。

とりあえずゲーム系は提出物が勝負だから気合入れて作っておけ
大手ならSPIとか筆記(PC系)で大半が死滅するけど

916 :仕様書無しさん:04/12/18 02:41:43
>>678
例の件って何ですか?

917 :仕様書無しさん:04/12/18 03:00:13
>>某社ではそんなものよりワードやエクセルの資格を取りなさいといってました。
プログラマに必要か?


918 :仕様書無しさん:04/12/18 03:35:55
>>917
意志疎通を行うために必要なツールとしている会社も、
1%ぐらいはある。その程度の常識。

っていうか、あんな、バグをユーザーに回避させる
ようなソフトよりも、日本人なら一太郎だろ!(藁)


919 :仕様書無しさん:04/12/18 03:42:20
>バグをユーザーに回避させるようなソフト
???

920 :仕様書無しさん:04/12/18 03:42:43
>>918
どっちもバグで蹴られますが、何か?まあ、
あんなモノの検定がある事自体が信じられんのだが・・・


921 :仕様書無しさん:04/12/18 03:44:21
ゲームと関係ない会社だろw
偽装派遣とかw

922 :仕様書無しさん:04/12/18 03:46:37








>>678
例の件って何ですか?











923 :仕様書無しさん:04/12/18 03:53:17
>>919
下手に削除機能を用いると、罫線があちこちにうごきまくって、復帰困難に陥る。
そもそも、罫線機能が非常に扱いづらい。インデントが簡単に狂う。
タブのシート名を少しでも長い名前に変更すると落ちる。・・・・・・etc


924 :仕様書無しさん:04/12/18 04:17:39
>大手ならSPIとか筆記(PC系)で大半が死滅するけど
SPIはともかく、筆記ってどんなんでるんでしょ?(難易度とか)

当方、田舎なもんで試しにうけることも辛いので情報あったら教えてほしいです。

925 :仕様書無しさん:04/12/18 04:34:14
>>924
数年前のN社で数学とLinuxとプログラムの問題がでた
どれも基本的なのばっかりだったよ
基本情報やLPIと大差ない程度

926 :仕様書無しさん:04/12/18 04:38:21
>>925
ありがとうございます。
なるほどぉ、でもそれって新卒用ですかねぇ。
中途の技術も同じようなもんなんですかねぇ。

とりあえず、今日は寝ます。

つか、LINUXは死ねるなぁ。
DOSプロンプトならかろうじて覚えてるがorz

927 :仕様書無しさん:04/12/18 05:03:05
そもそもプログラミングできてワードやエクセル使えないヤツなんて存在するのか?
チャッとF1キーでも押してその場で使っちまうだろふつー。

928 :仕様書無しさん:04/12/18 05:33:16
>>927
ただ文章を打つだけでは使えるっていうレベルじゃない

929 :仕様書無しさん:04/12/18 07:32:21
>>928
ただ文章を打つだけのレベルで留まるようなヘタレプログラマがいるのか?

930 :仕様書無しさん:04/12/18 08:07:21
>>928
段組して文章を打つ以上のことをするには、
大抵のプログラマはデザインセンスが足りない



ところで、エクセルだとVBAは良く使うが、
ワードでVBA使うのってどんな時?

931 :仕様書無しさん:04/12/18 08:32:10
MS Accessとか使うんじゃない
顧客への年賀状トカ (藁

932 :仕様書無しさん:04/12/18 08:58:37
>894
重要なのはどの学科に行くかではなく、そこに行って自分が何をするかだ。

933 :仕様書無しさん:04/12/18 09:16:30
その方向に専門的じゃない学科を選んだ方が有利、とか聴いたことがある
全て自分で勉強しなければならないから向上心がある、とか

934 :仕様書無しさん:04/12/18 09:24:13
>>923
最近罫線が消えないようにする技覚えたよ。
エクセルって意外と難しいぜ。
ゲームのデータをエクセルで管理してんだけど
罫線もしっかりつけないとデータずれちゃうから意外と手間。

あと、仕様書かくのに社内の共通フォーマットにワードの
アウトライン機能が使われてるから、はじめはわけわからんかった。
こっちはなれるまで一ヶ月近くかかった。

935 :仕様書無しさん:04/12/18 09:38:28
>>934 ↓ゲーム系業界で「エクセルを使いこなす」ってのはこういうことか?
http://www1.plala.or.jp/chikada/

936 :仕様書無しさん:04/12/18 11:13:13
>>935
問題は本職でもねぇのに意外と手間って部分だと思う。
個々の問題に目を向ければ簡単だけど全部知ってるのは難しいってそんなとこだろ。
要は覚えるのがダルイw

937 :仕様書無しさん:04/12/18 11:41:37
>>934
>最近罫線が消えないようにする技覚えたよ。
教えちくり、どうやってやるんだ?


938 :仕様書無しさん:04/12/18 12:20:12
Excelの最大の欠点はバグトラッキングがむちゃくちゃ不得手だと言うことだな。

939 :仕様書無しさん:04/12/18 12:24:17
Gem3 の日本語版出てたんだね。買ってきますた。

940 :仕様書無しさん:04/12/18 13:07:34
>>939
どうだった?

941 :仕様書無しさん:04/12/18 13:10:28
なんか理由があって3は出せないんじゃなかった?
気になるな。

942 :仕様書無しさん:04/12/18 13:28:14
>>914
新人の皆さんは「使い捨て」にならないように、
数学と物理を勉強した方が良いですよ。

943 :仕様書無しさん:04/12/18 13:36:24
学校を卒業したら三角関数なんて使わない
そんなふうに考えていた時期が俺にもありました(AA略

944 :仕様書無しさん:04/12/18 14:18:31
>>942
そう?技術で給料上がった例があるならお目にかかりたいねw

945 :仕様書無しさん:04/12/18 14:24:52
>>935
ローカライズの講演で「台詞の管理にはエクセルが最適」と述べられていましたよ。

946 :仕様書無しさん:04/12/18 14:27:30
>>945
つか、データ全般でエクセルは使えるだろ。
カンマ付きCSVで吐き出せ!

もちろん直接ゲームでCSVファイルを使うんではなくて
変換をかけてからって・・・いわんでもわかるかw

947 :仕様書無しさん:04/12/18 14:30:40
>>946
直でカンマ区切りテキストを拡張子だけ変えて使っているのをみましたね。特定はしませんが。w

>>つか、データ全般でエクセルは使えるだろ。
適当にハードつなげてマクロ組んでデータ収集しますね。……うちだけ?

948 :仕様書無しさん:04/12/18 14:31:51
>946
VBAつかって変換すれ

949 :仕様書無しさん:04/12/18 14:49:30
というか、データ打ち自体はプログラマの仕事ではないわけだし、
仮に.xls から直接エクスプートするツール作るにしても
内部フォーマットまでは資格の勉強ではわからんわな。
進行状況をOpenOfficeで書いてる自分は負け組。

950 :仕様書無しさん:04/12/18 14:54:42
>>944
技術は利用するもの
持ってるだけじゃ意味がない
査定に影響するように利用汁

951 :仕様書無しさん:04/12/18 14:58:14
某社でデータフォーマットの設計までプログラマの仕事じゃないらしい。
ゲームデザイン担当の奴が一所懸命VBAのお勉強してたよ。

952 :仕様書無しさん:04/12/18 15:07:24
外部仕様を平プログラマに任せる会社はないと思われ

953 :仕様書無しさん:04/12/18 15:24:50
>>951
>>ゲームデザイン担当の奴が一所懸命VBAのお勉強してたよ。
ぶっちゃけ、ゲームデザインはPGのスーパーセットだとおもうのだが?

954 :仕様書無しさん:04/12/18 15:56:33
>>953
世の中そんなに甘くない。

955 :仕様書無しさん:04/12/18 16:28:28
>>951
こういうのちゃんとできてればいいけど
中途半端な知識で中途半端にやられるのが一番頭に来る。

956 :仕様書無しさん:04/12/18 16:33:06
もちっというとエクセルを使うことによってお手軽にデータを整理できるのが
一番のみそなのにVBAのデバッグまで必要になったら本末転倒にもほどがある。
いまのところエクセルで変換や計算の類をするのは開発者(誰かの)自己満足意外なにものでもないと思う。

957 :仕様書無しさん:04/12/18 17:33:36
>>956
>>いまのところエクセルで変換や計算の類をするのは開発者(誰かの)自己満足意外なにものでもないと思う。
そうかなぁ。

958 :仕様書無しさん:04/12/18 17:36:41
簡単な関数を10〜20個くらい使うくらいならそうでもないと思うが、
プログラマーとしての素人さんがせっせとマクロ書いてる所を目撃すると・・・

959 :仕様書無しさん:04/12/18 17:41:00
素人つっても学生時代に何年もやってるだろ?

960 :仕様書無しさん:04/12/18 19:07:30
ゲームには決まった作り方が無いからね。
規模とか内容とかによっても一番良いやり方は違ってくるし、
それぞれの経験でやり方が変わってくるのは仕方ないかも。

製作終了と同時に辞める奴も多いからノウハウも
なかなか蓄積されていかないしね。

961 :仕様書無しさん:04/12/18 22:21:49
>>960
> 製作終了と同時に辞める奴も多いからノウハウも
> なかなか蓄積されていかないしね。
人が辞めるってのが、会社によってどれだけの損失になるかを
分かってない人多いんだよねぇ。

同じ一人月でも、チーム組んでしばらくたって円滑に仕事が
進むようになった人と、来たばかりで右も左も……って状況
だと、生産性が全く違う。

人件費抑制に神経使う前に、離職率押さえる方法を考えて
クレ>人事

962 :仕様書無しさん:04/12/18 22:29:14
>>961
>人が辞めるってのが、会社によってどれだけの損失になるかを
>分かってない人多いんだよねぇ。

分かっているからこそ辞めるわけですよ。

963 :仕様書無しさん:04/12/18 22:55:30
>>961
順序が逆です。
まずはヒット作連発してからでかい口を叩いてください。

964 :仕様書無しさん:04/12/18 23:03:35
>そう?技術で給料上がった例があるならお目にかかりたいねw
>
バーチャ・グラツー・無双の開発チーム

965 :仕様書無しさん:04/12/19 00:29:14
ゲームプログラマのレベルは低いよ。
GameProgrammingGemsレベルのことすら実践できない奴らがほとんど。


966 :仕様書無しさん:04/12/19 00:30:33
>>965
そんな、自分で言ってて悲しくないのか?

967 :仕様書無しさん:04/12/19 01:31:11
悲しい。

968 :仕様書無しさん:04/12/19 01:31:13
プログラマは、仕事でやってる連中よりも趣味でやってる
連中の方が腕が上がるのは常識だからなぁ・・・
まあ、プログラムの腕に限った話だが。仕事の手腕を考えると・・・


969 :仕様書無しさん:04/12/19 02:08:22
XPの40時間労働なんてものがある癖に現実は何処も↓だからな…
ttp://www.fromsoftware.jp/main/employ/workstyle/interview/01.html

970 :仕様書無しさん:04/12/19 02:18:15
週40時間労働を取り入れてる会社なんて実際にあるのか?
長時間労働が単位時間当たりの生産性を落とすのはわからないでもないけど
週40時間で納期厳守なんて物理的に無理な場合が…

971 :仕様書無しさん:04/12/19 02:33:42
>>963
ヒットを出したチームの人間が、ごっそり他社に移るという罠。デキるヤツから
辞めてくのね。

972 :仕様書無しさん:04/12/19 02:36:15
>>970
発想を逆転させようぜ!

973 :仕様書無しさん:04/12/19 10:53:38
>>971
デキる奴は、環境が良いのに辞めるわけがない。
環境が悪いから辞めていく。で、出来ない奴が残るという悪循環。


974 :仕様書無しさん:04/12/19 12:57:22
隣の芝生は青く見えるもんだよ。

975 :仕様書無しさん:04/12/19 12:59:47
樽(=業界)一杯の泥水をいくら一生懸命かき混ぜても水がきれいになるわけでもなし。

976 :仕様書無しさん:04/12/19 14:18:16
>>961
スズキ君が新人だったりすると、
「2ヤマダ人月」の仕事に「5スズキ人月」計上してみたり。

977 :仕様書無しさん:04/12/19 14:54:39
>>969
もうこいつと同じ考え方は出来ないな
仕事意識をもつことは大切だけど、それが終電で帰ることか?

残業、休出続きで10万売れる物を作るより
定時定時で5万本売れるものを作ることが真のプロの仕事だと思う

経験曲線効果が半端じゃなく高い職種だぞ
過度な労働で人材潰せばそっちの方が損失でかいって理解してないのか?

978 :仕様書無しさん:04/12/19 15:06:02
>>965
あの本読んで、ソース解析すりゃ、実践くらいできるだろ・・・。

と思うのだが、そうでもない奴ら多いの?

979 :仕様書無しさん:04/12/19 16:53:44
>>977
昔いた会社で、「だり〜」みたいな事吐いた時たまたま総務の人間に近くにいて
こう言いました「人間そんなに簡単に壊れないから、大丈夫」
完全に壊れてないだけで精神的・肉体的にも常人から見たら危険領域にとっくに入ってるじゃボケ
と叫びたいのをグッと堪えて仕事を進めましたよ。
ええ、プロジェクト空けに転職しましたよ。しかし労働環境は全然変わってないけど…

980 :仕様書無しさん:04/12/19 17:05:18
>>978
本を持ってるだけで満足したり、流し読みしただけでわかった気になってる奴が多いんだよ。
で、実際は何も実践せずに昔ながらの非効率なコードを組み続けてる奴ばかりよ。

まあ根本的に向上心がないんだろな。
約90%がそんなの。


981 :仕様書無しさん:04/12/19 17:07:32
じゃあニートの僕でもがんばれば上位10%に入れるということですね!

982 :仕様書無しさん:04/12/19 17:09:11
てかあの本って小ネタ集だから
新しいコトやるときに「もしかして載ってたかも」って感じで
読めばよいかと。

983 :仕様書無しさん:04/12/19 17:10:25
ニートの時点で駄目人間の上位10%に入れてます

984 :978:04/12/19 18:37:51
A、GEMS級のことを、持っている持っていないに関わらず必要に応じて実践できる。
B、GEMSを持っていても、実践できない。
C、GEMSを持っていないし、実践もできない。

この場合わけの場合、Aが10%になるってこと?
BとC合わせたら、90%?

そんな馬鹿な・・・。

985 :ニート:04/12/19 18:47:37
GEMSが高くて買えません。

986 :仕様書無しさん:04/12/19 18:51:20
>>985
ニートはゲームプログラマじゃない。

987 :仕様書無しさん:04/12/19 18:55:43
>>984
おっ!結構現実的な予測だと思うぞ。
俺のまわりではそんなんだ。

988 :仕様書無しさん:04/12/19 20:09:02
D、GEMS? 重いから開きたくない


989 :仕様書無しさん:04/12/19 20:34:34
E.そもそもGEMSって何ですか

990 :仕様書無しさん:04/12/19 20:41:22
発売日いつ?

Game Programming Gems 3 日本語版
http://www.gogo3d.com/products/gems3/

991 :仕様書無しさん:04/12/19 20:52:41
英語が読めて原書持ってる俺は勝ち組

992 :仕様書無しさん:04/12/19 20:53:09
         ☆ チン     マチクタビレタ〜
                         マチクタビレタ〜
        ☆ チン  〃  Λ_Λ   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ヽ ___\(\・∀・) < 次スレまだ〜?
             \_/⊂ ⊂_ )   \_____________
           / ̄ ̄ ̄ ̄ ̄ ̄ /|
        | ̄ ̄ ̄ ̄ ̄ ̄ ̄|  |
        |  愛媛みかん  |/


993 :仕様書無しさん:04/12/19 21:13:16
ゲームプログラマーの人に聞きたい 7問目
http://pc5.2ch.net/test/read.cgi/prog/1103458370/

994 :仕様書無しさん:04/12/19 21:20:49
>>991=インド人のダメプログラマ


995 :仕様書無しさん:04/12/19 22:14:11
>>994
釣らないでくれw
腹が痛いw

つうか金持ちで羨ましいよ本当にwww

996 :仕様書無しさん:04/12/19 23:38:07
F.GEMSで出てくるような内容を仕事では使わない

いやマジでorz

997 :仕様書無しさん:04/12/20 00:05:24
>>996
あー、やらないやらない。
何やってるかっていうと、もうホントモデリングツールから読み込んで自動化しとけよ
みたいなもんとか、くっだらねぇ仕様の実現とかそんなん。
はっきりいって残業なんてする価値ないような要素の作りこみ。とかそんなんだよな。
だからプログラマは糞仕様考えた企画をぶっころしたいと思ってる人多いよね。
だいたい売り上げに直結しないような仕様ばっかりだし。

ところで、次スレだってさ
http://pc5.2ch.net/test/read.cgi/prog/1103458370/l50

998 :仕様書無しさん:04/12/20 01:45:55
ヒロシです。
DSとPSPとDQ8が出て、来年はゲ業界もだいぶ盛り返すかもしれんとです。
今後は中国や海外に目を向けたゲーム開発が重要になるとです。
携帯端末もどんどん高性能化しとるとです。
さぁ、これからゲPGも面白くなってくるぞ!!



・・・などと、パチンコ液晶画面作りながら考えとるとです。
ヒロシです・・・
 ヒロシです・・・
  ヒロシです・・・

999 :仕様書無しさん:04/12/20 01:48:02
1000000000000000000000000000000000000000000000000000000000000

1000 :仕様書無しさん:04/12/20 01:48:27
0000000000000000000000000000000000000000000000001

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

227 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)