ゲームプログラマーの技術レベルは高い。 (690ﾚｽ)
上下前次1-新
124(1): 02/09/01 18:15 ID:??? AAS
>123
制限少なくしようと思ったらかなり大変だし。
125(1): 02/09/01 19:12 ID:??? AAS
「定義ファイルはタブは使うなよ。
半角スぺースで桁をそろえろって言っただろう！ 」
ほんとのこと言えよ。
お前らはツールなんてやりたくない。手抜きたいんだろ。
126: 02/09/01 21:29 ID:??? AAS
>>118
大手だと、新卒採用の段階で研究系、ツール系、ゲーム系と間口を用意してる
企業もあるね。
>>124
> 制限少なくしようと思ったらかなり大変だし。
ハード上の制約はどうやっても越えられないし…。
127(1): 02/09/01 22:01 ID:??? AAS
>>123
時間が無制限にあるなら、それでもかまいませんよ。
その場合の責任は、当然あなたが取ってくれますよね？（藁
128: 02/09/01 22:20 ID:LpSDR9P0(1/2) AAS
>116
一番いいのは
while( true )
{
・ライブラリを特定のゲームに特化したカスタムバージョンのライブラリ
を作成して、それでゲームを作成
・プロジェクト終了後に汎用的に使えるもの、特定のジャンルなら流量できるもの、
そのゲーム特定で作られたものに整理する。
・汎用（基礎）ライブラリ、ジャンル特定のライブラリにフィードバックする
・次のプロジェクトへ
}
っていう流れが一番理想なんだけどね。
けど、
・整理と追加っていうのがやりたがる人がいない
・ライブラリ部門は直接的な利益を生み出さないから、
チーム単位（特に社内カンパニー制）ではやりたがるチームがない。
っていうのが問題なんだよね。
むしろこういう汎用ライブラリを使って作る方が断然スピードも速いんだけどね。
129: 02/09/01 22:20 ID:LpSDR9P0(2/2) AAS
>117
やっぱそうなんだね。
うちも全て買えばいいっていう考えが主流だよ。
高価なＣＧツールでゲームで使える部分なんて半分ぐらいしか無いのにね。
実際はツールプログラムのほうがプログラム的にもレベルを上げやすいと思うんだけど
（メモリーの制約とかがないからオブジェクト指向とかの色々なプログラミング技法で組める
最先端のＣＧ技術を試せる
ほとんどの場合一人で全部作ることになるから処理の流れを覚えれる）
なかなかやりたい人がみつからない。
人数が少ないくせにやる内容は重要だから余計仕事が集中する。
、、、、、、ほんと、誰かできるやつ入ってきて欲しいよ。
130: 02/09/01 22:23 ID:wTqfQ1+e(1) AAS
>>123
っていうかそれは常識だろ。
期限内にその仕様は無理だと決める権限はプログラマだろ。
何いってんだ。お前は。
若い時は、まぁ、やってやります！！って思っちゃうけど。
131: 02/09/02 00:24 ID:??? AAS
>>121
デザイナが楽をするためにプログラマにサービス残業させるのはやめよう。
本業がある上に、なんでデザイナのサポートまでしなきゃなんねえんだよ。
デザイナがプログラマのサポートするとこなんか見たことねえのによ。
まあ、１番の問題は、無理なスケジュールを押し付ける役職者にあることに早く気付け。
>>125
最初の取り決めを守れないDQNがいくら吠えても無駄。
周りから見ると滑稽なだけだということに早く気付け。
132(1): 02/09/02 00:35 ID:??? AAS
なにやら必死な人が多いな（藁
133: 02/09/02 01:03 ID:??? AAS
>>132
ゲームソフト産業は今や斜陽産業ですから。
みなさん生き残りに必死なのです。
134: 02/09/02 01:07 ID:??? AAS
みな、若き日の過ちを苦々しく思っているのだろう
135(1): 02/09/02 01:13 ID:??? AAS
企画がいなくて、
キャラ担当やマップ担当が、そのデータを作る直前に各自で内容も決める。
思いついたが吉日。スケジュールは伸び放題
って仕事もあったよ、昔はさあ・・・
あの頃は俺もまわりの雰囲気にのまれてホイホイ仕様変更したけど
結局責められるのは俺だったなあ･･･
136(1): 02/09/02 01:45 ID:??? AAS
>>135
身につまされるなぁ…
スケジュールが厳しくなると、今度はツール制作や
仕様変更なんかに対応していられなくなって、
>>117 みたいな奴に陰口たたかれるんだよな。
結局どっち転んでもプログラマのせいにされるんだよな。
137: 02/09/02 01:51 ID:??? AAS
毅然とした態度で理路整然と>>127みたいな事が言えたらなぁ・・・・
138(2): 02/09/02 02:57 ID:??? AAS
>>136
全くなぁ。
ツールが（技術的に）作れない奴なんてさすがに居ないだろ、とね。
作れないのは時間的に問題が有ったりするから．．．．。
139: 02/09/02 06:57 ID:OxVR3ylF(1) AAS
>>121
俺の方針としては、２Dの演出関係とかも、全部、３Dツール上で
デザイナーに編集してもらって、拡張アニメーションとして、出してもらってる。
これを、元同僚に話したら「デザイナーの負担がでか過ぎる」と反論された。
これについてはどう思う？
140: 02/09/02 07:14 ID:??? AAS
1.ハードウェア
2.開発環境+デバッグ環境(場当たり的)
3.ライブラリ(使い捨て)
4.ナンダ？
結局は常に1に立ち戻る必要性が有る事が、
業務用アプリとかとの最大の違いとして、
141: 02/09/02 07:27 ID:??? AAS
Xboxまんせー
142(29): 02/09/03 00:35 ID:ELMH1ABY(1) AAS
>>138
正確には「作りたくない」だろうね。
WindowsGUIやMFCなどの知識を習得するのが面倒なのだろう。
個人的に思うのは、ツールプログラムを軽く見ている奴が多すぎ。
ツールなんて誰でも作れると言いつつ、まともなツールを作ったことのない奴がほとんど。
いくら高度なシステムを作っても、インターフェイスがテキストベースで
デザイナーやプランナーに負荷かけて効率や品質落としているようでは意味無いし、
なんで昔からのゲームプログラマはプログラム内容にしか目を向けず、
開発プロセス全体の効率化を考えないのかな・・・。
これからの時代は、システムの実装（＝ライブラリ）から、インターフェイスの整備（＝ツール）までを
一貫して構築できるプログラマが求められると思うよ。
143(1): [???] 02/09/03 00:39 ID:??? AAS
ゲームプログラマーの技術は高いやつが多い。
が、それで面白いゲームが作れるようになるかどうかは
別の話のようだ。
144: 02/09/03 00:44 ID:??? AAS
■ 参考資料： >>143 の発言リスト
2chｽﾚ:gamedev
2chｽﾚ:gamedev
2chｽﾚ:gamedev
2chｽﾚ:gamedev
夏休みは終わったのにネ
145(1): 02/09/03 02:09 ID:??? AAS
>>142
> これからの時代は、システムの実装（＝ライブラリ）から、インターフェイスの整備（＝ツール）までを
> 一貫して構築できるプログラマが求められると思うよ。
分業。
146(1): 02/09/03 02:10 ID:??? AAS
>>142
んなもん一貫して求められネーって。アプリケーションプログラマと
組み込みプログラマの違いわかる？
MAXのプラグインぐらいなら書いてやるけどそれ以上を求められるなら
賃上げ交渉からお願いしたいわ。年齢×１万切ってる給料で求められて
も困りますわ。マジで。
147(3): 138 02/09/03 02:29 ID:??? AAS
>>142
不思議な事を言われているような。
GUIの知識なんて そんな勉強せずとも作れると思うけどなぁ。
>>145の言ってる通り、分業が普通だろうし、
ツール作るプログラマーが普通にいるだろう。
もしもそう言う人が居ないなら、速急に作るべきですな。
148(1): 02/09/03 02:46 ID:??? AAS
>>147
甘い。
DQN会社のDQN管理職どもは、まるでそんなことは分かってない。
ツール作成や社内ネットワーク管理を一生懸命やってると
「遊んでないで仕事しろ」
と言われて、給料下げられるのさ。
149: 02/09/03 03:14 ID:??? AAS
>>147
っていうかゲームそのものがGUIの塊なのにね。142はかなり意味不明。
150: 02/09/03 06:50 ID:??? AAS
一貫して開発しる！なんてのは
給料を年１億ほどもらわないとやってられん
ツールだって立派な売り物になるくらいだ
簡単に作れるわけないだろが…アホか(藁
151(2): 142 02/09/03 07:11 ID:b+KCxfGa(1) AAS
>>146
ツールとシステムを分離すると、物にもよるけど意思疎通が遅れるんだよね。
システムに変更や追加が入るたびにツール側に修正をお願いしなければならないし、
逆にツール使用者の意見をシステム側に反映させるにも時間がかかる。
変更や改良が頻繁におこるのがゲーム開発だから、そこで分業してしまうと非常に効率が悪くなる。
またGUIだけでなくプレビュー（エミュ）機能をつけようと思った場合、システム側と同等の実装が必要になる。
最近は、ＡＩ担当、エフェクト担当、オブジェクト担当、背景担当とパート単位にわけて、
それぞれがシステムの実装から、ツールやプラグインの整備までを行うのが主流になりつつあると思うけど。
>>147
大規模なWindowsアプリを作ろうと思うと、Win32APIの知識や複雑なメッセージのハンドリングとかノウハウはいるよ。
152(1): 02/09/03 13:44 ID:??? AAS
>>151
むにゃむにゃ。あなたの会社のメインプログラマさんは何をやっている
のですか？その意思疎通を一括して行うのがメインPGじゃないのれすか？
話だけ聞いていると相当無能なメインPGさんだと思います。
複数人が同じものを作る事ほど不効率な事はありませぬ。
153(1): 142 02/09/03 17:36 ID:n9Q0aUGU(1) AAS
>>152
複数人が同じ物を作る？？？意味不明。
メインプログラマは、リソースやタスク管理、低レベルIO、あとは各パートをまとめるのが仕事。
例えば、オブジェクト担当なら、実機でのオブジェクト表示やモーション再生を実装すると同時に、
市販ツールなどからデータをコンバートするプラグインも書く。
エフェクト担当は、実機でパーティクルシステムを実装すると同時に、
ジェネレータを組み合わせてエフェクトを構築するツールも作る。
それぞれがオブジェクトデザイナや、エフェクトデザイナと直接話し合って、フィードバックし合ってシステムとツールを構築していく。
これが、うちの開発体制。
だいたい最近はメインプログラマがすべてを把握できる規模じゃなくなっているのよ。
上下前次1-新書関写板覧索設栞歴
あと 537 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.021s