ゲームプログラマーの技術レベルは高い。
今まで自分はPCのアプリ屋をやっておったのですが、
最近、訳あって3Dゲームの開発に携わるようになりました。
で、昔からゲーム作ってる人等を見ての正直な感想、
１・「お前等レベル高い！」
２・「なんでそんな事知ってるの？？」
って感じでした。今までゲームプログラマを馬鹿にしてたんですが、
撤回します。
特に２ですが、ゲームプログラマの人達は、僕が本やらWebやらで調べても
全然分らなかった事を知っていたりするので不思議です。
日本のソフトウェア開発レベルは低い、と言われていますが、そうでもない
かも、と思ったりしています。 逆にビジネス屋や組み込み屋やアプリ屋の技術ラベルが低すぎると
いう見方もあり。ただ、物事を１面から評価するのは不毛な論争の
原因となるので宜しくないかと。
んでも、面白いゲームを作るためならどんな苦労も厭わない人は多いね。 日本で一番多いプログラマ層は、VB、VBAオンリーのカスタムアプリ製作者？ >>3
個人的にあの辺がプログラマと呼べるのかは甚だ疑問。
ゲームの企画屋でもあの辺はサクーリと使いこなしたりするんだけお。 でもそのかわりドキュメント全然書けない＆書かない
ＤＢサパーリ
メンテナンス可能なコード書かない
といった傾向強い。まあゲーム屋に不要な技能は不得手って
だけなんだろうが。 プロの技術はすごいよ。
独学ではまず一生辿り着けない。 >>4
おそらく職業種別としては「プログラマー」と思われ！ >>6
給料もらってれば「プロ」と思われ！.....？ ゲーム系は一定の知識ないとまるで手も足も出ないけど、
一般系はそうでないから上下の差が激しい。
ヘボな人はどこまでもヘボイし、逆に凄い人はマジ凄いよ。
俺もこういう開発できるようになりたいYO!↓
http://www.atmarkit.co.jp/fjava/devs/redge03/redge03_1.html 3Dゲームは数学と物理の固まりだからゲームの部類では難しい方にはいるよ。
一番難しいのはリアルタイムネットワークゲームだけど。
もちろん、ＰＣアプリ方面の技術も必要。
デザインパターンやＳＴＬとか便利だし、ツール作りには欠かせない。 【もう】みずほ障害スレ＠マ板 その11【だめぽ】
http://pc.2ch.net/test/read.cgi/prog/1018506709/
あのプログラマ板でなんで11まで行くかな（ｗ 実際、ゲーム作りに要求される技術の高さが業界自体を疲弊させて
いるのも確かで。 そりゃそうだろうなぁ。
簡単なゲームでさえ一般のアプリでは使わない処理を要求されるから。
ゲーム以外ではほとんど三角関数とか使わないだろうし。 なんか怪しい方向へ、１の意図した方向へ？、話しは進みつつあるようだ・・・ >>10
そうか？数式や物理法則はプログラムに向いた領域。
両方やった経験から言うと
顧客の無理な要求仕様に応える受注型のアプリの方がよっぽど難しいよ。 >>10
Factory method とか、Singleton、Flyweightは、ゲーム作るのに使えるね。
というか、知らないときから似たような物を作ってたけれど、
文章におろされてすっきりした感じ ゲームプログラムは複雑すぎて、抽象化が難しいですね。
紙に書いて考える時間が凄い長い まぁ、ゲーム開発板でこんな話題、結論は見えているけど(藁、
一つ言えるのはスタンドアロンなPC/専用機の方が簡単。
あと、電文保証を真剣にやらなくて良い/トラブル発生時の
調査のことを考えなくて良い、って点がビジネス関連に
比べると非常に楽。
資源が限られてるって点が逆に難しい点ではあるが。 一般系って凄いじゃん。
銀行のシステムとかどういう風に取り掛かればいいのか見当もつかんよ。
みずほの件でSE100人待機とか、世界がちげーよ。 ゲームＰＧからＷｅｂＰＧに転身したが、
あまりに楽すぎて退屈だ。
最初は覚えることが多くてめんくらったけど。 リアルタイムではないターン制のネットゲームって
難度的にはどれ位？
ジャンル別のプログラム難易度なんかを作ってみたら面白いかも。 >>21
資源が限られてるから、それをどこまで限界まで使いこなすかが
ゲームプログラマの腕の見せ所。一般であるマシンに特化した移植性、
メンテナンス性ゼロのコード書いたらぶっ殺される（組み込み系除く）。
要求されてる技能が違うのに比べよう無いわな。 性能限界という目標しか持てないプログラマ.....なんていないよね >>24
ネット経由の対戦オセロ、対戦５目並べ程度なら差ほど難しくも無い、
というのは分かるとおもう。
商用ソフトで一番簡単なのは、恐らくビジュアルノベルタイプのエロゲー。
#でも一番バグが多いという謎の罠。 >>27
そうだな。エロゲは画像が命。
プログラムは極端な話どっちでも良い。(w 「Kanon」を作ったKeyっていうメーカーにはプログラマはいないそうだ。 >>1
必要な知識が違うのであって、どっちの技術が高いという事ではない。
プロならそのくらい分かるだろうに。 >>29
プログラマというより会社が請け負って
VisualArts全体のをカバーしてるから..
そもそも各ブランドにプログラマがいないのではないかと >>31
そうでもないと思いますが・・・
ゲームでは一般的なフレームワークも無いから、基本的に全部手作りでしょう。
アプリ屋が普段意識せずに使ってるような部品も自分で作る必要があって、
数学・物理の知識が要求され、しかもハードの知識も必要なんですよ？ >>34
大多数のゲームプログラマは用意された部品を使っている罠。 エロゲーはフレームワークでつくれそうだな
絵とイベントの流れを実装するだけでよさそう。 業務アプリでも一般フレームワークはほとんど適用できない罠。 >>1にマジレスすると
ゲーム開発と他の(例えばビジネスソフト)開発を比較するにしても
接点があまりに少ないというか。
例えば電機製品のファームウェアとかデバイスドライバの開発とか
建築用、機械用CADの開発と比較するというならまだとっかかりがあるかと。 ゲーム系で特に必要な数学・物理の知識って何？
たいがい大学の一般教養レベルで何とかなると思うが。
それくらいなら、一般業務アプリでも必要だし、
理系大学出てる人みんな持ってる知識だしなあ。 >>39
ずいぶんいい大学に通ってたんだね。
道を誤ったんじゃない？（藁 例えば、けっこう低レベルの部分にまでインハウスライブラリを使っている
という状態を、WEB関連のプログラマが見たとしたらどういう感想が来るか
とったら、おそらく「なんか不毛なことやってるな」という感じになるわけで。
で、こっちは「ほっとけ」としか言いようがないというか。 >>40
３流大卒のゲームプログラマだけど、
俺もゲームで使ってる数学・物理の知識は理系の一般教養レベルだと思うよ。
本当は複雑な物理モデルを高度な数学的解法で証明し、
そこから近似モデルを導出するのが正しい在り方なんだろうけど、
実際は論文から証明の結果だけを拾ってきて簡単な近似モデルを実装するだけ
ってのが殆どだと思う。
だから基本的な公式さえ理解できれば実務には問題ない。
むしろ洋書や最新の技術論文を読める英語力の方が重要かも。 ゲームプログラマーは旧帝院卒クラスがゴロゴロ受けに来るからな。
道を誤っているというか何というか。
しかも実力不足で大部分は落とされるわけだし、何を勉強してきたんだ
と思う。 >>42
一般教養レベルで動力学とかベクトルや空間の微積とかやるの？
おれの大学じゃ専門課程でしかやらなかったよ。 ベクトルは習った・・・
けどそういうの分からないがこれだけは言いたい。
ゲームに出てくる設備(配管、空調、電気）滅茶苦茶にも程があるぞ! 車輪の再発明をせざるを得ないゲームプログラマは
皮肉なことにその体力とスキルを養ってしまった感はある。 STL使用禁止で上司の作った双方向リスト使ってますが何か？ STLから使わない部分だけ切り取ったようなテンプレートライブラリーは
使ったりしてるけどなー。 STLの場合、オブジェクトの生成や破棄が不明瞭なので、
テンプレクラスを自作しましたが何か？ 漏れ、STLのソースはサラーとしか見てないからアレなんだけど
アレをそのまんまゲームに使うというのはチト難しいかなという印象。
単純にアロケータ自作して指定してやるだけでは全く問題の解決
にならないというか。結局、直にSTLのソースに手を加えるざるを
えない状況にぶちあたるのでわざわざ使うメリットが半減するというか。
ちょろっとしたツール作りには重宝しますが。 >>56
どこが気になるのか詳細キボン。
で、別にSTL自体のソースに手を加えてもイイじゃん。他のところに手を加える必要が無いなら。
STLを使わなくても>>49みたいにチーム単位で基本的なアルゴリズムが共通して使われていれば
いいけど、何のポリシーもなく個人それぞれが好き勝手に組んでると最悪。
多くのゲームプログラマは、質の悪い車輪の再発明をしていることに気づいていない
というのがのが現実。かな？ >>57
なんというか、わけの分かんない話を始める人だなぁ。
感覚のズレを肌で感じるよ。（学生さんということなら別に構わないよ）
＞何のポリシーもなく個人それぞれが好き勝手に組んでると最悪。
例えばこの辺の話ね、何時の時代の何処の四流ソフトハウスの話を
してるのかは聞かんけど、もし誰かの受け売りで書いてるんだとしたら
もう忘れたほうがいい。大小にかかわらず「いまどきのまっとうに
生き延びている所」はどこもそんなことをやっていないのだから。
絶滅寸前の珍開発スタイルを例に持ち出したところで、大半の人間は
「へ？」としか返事できんと思うよ。
ただ、三流のエロゲ屋とかの事情は流石に知らんので、もしそうなら
そんなことをやっている寒い所は今でもあるんかもしれない。 >>1はアレだ、「公務員」ってだけで警官と技官を一括りにするタイプだな(藁。
求められる能力が全然違う。 えぇと、自分もついでにSTL云々の話にもコメントさせてもらおっかな。
あれを『改造してまで』ゲームそのものに使う魅力は少ないよ。
例えばの話、それによって「信頼性を維持しつつ保守の手間を減らせる」
という人間がいるとしたら、それは弄くるのが好きな個人であったり、整備された
リソースがよほど乏しい小規模で新興の(PCゲー)ソフトハウスのスタッフであったり
そういうマイナーな存在になるはずだよ。
他の選択肢(例えば社内リソース)のほうがよく整備され信頼できるという
事情があれば、当然(STLを改造してまで)わざわざ使わせるわけないわけで
実際そういうケースのほうが遥かに多い。
活用するとしても、ソースを眺めていて良い所があれば参考にするとか。
あとは、ツール作成にBCBを使ってたりする場合には普通に(STLを)使うことも
あるだろうな。
PCゲー開発の事情はよく知りません。 ＞で、別にSTL自体のソースに手を加えてもイイじゃん。
＞他のところに手を加える必要が無いなら。
そう。それはおまえさんは趣味でやっているのだからそれで問題ないんだよ。
個人で好きなライブラリを好きな時に好きなように使おうと誰も困らない。
それだけのことさ。 ゲームプログラマっていつ勉強するんですか？
夜中に少ない睡眠時間をさらに削りながら勉強するんですか？ >>62
やったこともないような仕事を任され、
それを完成させる為にリアルタイムで、
勉強する。それを繰り返して成長していく。
こんな感じ。 新人社員で１ヶ月でコンパイラつくれとか言われるって本当ですか？ 勉強なんてしようと思わないからできないだけ。
どんなコードかいてても自分から勉強しようと思えばいつだって勉強になるよ。
たとえば、どうやったら生産性を高めれるか？とか
移植しやすくするにはどうかけばいいのか？って
常に考えながらコードかいてれば自然に勉強になる。
ツール作るときだってクラス図とかアーキテクチャを最初に全部設計して、
練りに練りまくってからコーディングしてるよ。
もちろん、コードかいてるうちに悪い部分が出てくるから、
なんで悪くなるんだろう？って考えてから修正を加えるし。
必要な機能を実装するためには一から勉強。
他人のふんどしを使うのは楽だけど、
いざとなったら応用が効かないから。
だから、全部自分で作ろうと思うし。
技術屋だから自分が理解していないことを理解していないままで
使うことが嫌だって言うほうが大きいかも（ｗ
もっとも、効率が悪いことは認めるよ。
納期が迫ってたりするとそんなこといってられないけどね（藁 基本を修得しておけばいくらでも応用が利くってことさ。
応用を丸暗記してるだけじゃテンプレートにしかならないってことさ。
あと、技術者なら厨房レベルの英語はできるようになっておけよ。
「資料が英語なんで読めません！」と真顔で返すなよ・・・ >>66
そんなあたりまえのことを張り切って言わなくても･･･ >>66
＞技術屋だから自分が理解していないことを理解していないままで
＞使うことが嫌だって言うほうが大きいかも（ｗ
禿同。で理解するとこんなことやあんなことにも使えるな
というのが思い浮かんで嬉しくなってくる。 ところでさ、じつはいまＤ３ＤＸ使わないで自分で数学の関数作って
バグ起こしてる上司がいるんだけど、うざくってかなわないんだよね。
そりゃそうだよね。だってあんた内積も外積も理解してないんだもん。
んで、自作メモリ管理クラスみたいなものなんか作ってマニュアルも書こうと
しない、わりにはソースコード解読して俺に使えってサ。死んでも嫌だよ。
んでさ、そいつエラーコードなんか大量に書くわけだけど、自分がつっかかってる
バグにはかすりもしないんだから、もうあきれるったらない。
んで、そいつのソースみるとオブジェクト指向すら理解してない感じ。
すべてのヘッダを一つにまとめてすべてのソースでインクルードしてるから
根がはっちゃって単体テストもできないでやんの。
んで、問題点をこっちから指摘しても聞く気も無し。
同じ日本語しゃべってんのに俺のいってることつうじないんだね。
なんでも自分でやるってのもどうかと思うよ。
はぁ。どうしよう。 >>72
どこの業界でもそうなんだが、経験を積んでくると失敗を回避するノウハウが
蓄積されてくるわけだ。
ただ、この「ノウハウ」というやつが玉石入り乱れていて、
例えばインクルードファイルの依存関係が上手くいかないときに
・全部インクルードする
・依存関係を整理する
みたいな玉と石があったりするわけだ。
こういう人々を見ていると、他人にコードや設計をレビューしてもらうとか、
人の話を聞くとかコード読むとか、そういう作業は大事なんだなと思うね。
特に、ゲーム関係なんかは俺様一番の職人肌の人が多いでしょ?
だから、自分で意識して軌道修正しないと、10年後にはその先輩みたく
なってしまうと思うな。日々是精進だよね。 つーか、このスレのアダルトな雰囲気は何?
てっきりマ板のスレかと思って書き込んでしまった。
もっと厨房ぽく書くんだった。 ・全部インクルードする
・依存関係を整理する
みたいな玉と石があったりするわけだ。
↓
・依存関係を整理する
・全部インクルードする
みたいな玉と石があったりするわけだ。
文章的にはこうだろ オブジェクト指向っていっても、本当に理解してる人はどのくらいいるんだろ？？
ただ単に、データとそれを操作する関数をクラスにをまとめてるだけでオブジェクト指向だ！
って言ってる人って結構多くない？ >76
かもね。
変な例えだけど、漏れ的に
プロパティはオブジェクト固有の情報を、
メソッドはオブジェクトの振る舞いを記述して欲しい。
かくいう漏れもオブジェクト指向の理解には自信なし。 >>72
グローバル変数使いまくりの習慣があるPC老舗の某F社? >>29
Ｋｅｙはビジュアルアーツ
あんなもんＨＴＭＬだけでも組める（藁
>>76
そのおかげではやくも破綻がみえてるわよ！
なんで奴はオブジェクト指向も理解しないのか、
俺のかわりに奴に聞いてきてくれ！ >>80
ほうーーーーHTMLだけで？HTML
だ け
でね。
もしかして俺もつられてるのか >>81
時代はマルチパラダイム
いや、最近「マルチパラダイムデザイン」読んでるんだが、なかなか難しくてさ。
学生時代のように人を集めて輪読したい。 ゲームプログラマーの（ｵﾅｰﾆの）技術レベルは高い。 ＞57
車輪の再発明・再生産が必要ないとしたら、
一体何人の首が飛ぶ事やら、、、
質の良い車輪を作る人がいそうな場所も、質の悪い車輪を
作る人がいそうな場所も、距離があってもそれなりに知れます。
//オープンソースどうこうの動きもところによりあるが、
//いつだって貴重なソースはいろんな思惑とかも有りで閉鎖的なので安泰。
ＳＴＬ等もなぁ・・・
static staticであったなら、書きなおす必要もないかもね。
＞何のポリシーもなく個人それぞれが好き勝手に組んでると最悪。
ポリシーを持ってチームがなるべく普遍かつ共通なコーディんグを模索。
それを仕事にしますな。
それと、改変するぐらいなら、0から書き上げる方が圧倒的に早い。
万一それっぽく似せて作るにしても上辺や使い方が似ていればそれで十分。
＞75
・全部インクルードする
こっちが玉と思う。 全部インクルードは言われないと気付かないが依存関係を整理するなんてレスは役にたたんだろ
なんつーか前者はうんこの拭き方おしえますみたいで大声では言えないけどな >>88
> ・全部インクルードする
> こっちが玉と思う。
まぢかよ…
それやると 1 つメンバ変数付け加えたら、全ソース再コンパイルに追い込まれるぞ。
いくらマシンが速くなったとはいえ、そりゃムチャだ。 全部インクルードすると解決したように錯覚する罠
本当に罠だな >>88
> ＳＴＬ等もなぁ・・・
> static staticであったなら、書きなおす必要もないかもね。
この文章、さっぱり意味が分からんのは俺だけか？ >>93
大丈夫だ、俺もわからん。
> 距離があってもそれなりに知れます。
これも。
> それを仕事にしますな。
これも。
> //オープンソースどうこうの動きもところによりあるが、
ここだけ"//"がついてるのも。
だれか、解説してくれ。
もぅ、ageちゃう。 >>94
//はコメントだとおもう。
ここにはレスすんなってこと。
# コメントはMLでよく見る作法だけど、「#」使うのが一般的だと思うが… パソ通時代からNiftyとかで # 見るとムカつくから
わざとそこにいちゃもんつけてるよ。 おぉ、>>88よ。夢の世界でゲーム会社で働いてないで
早くハローワークに駆け込むんだ。 http://www.watch.impress.co.jp/game/docs/20020813/cri.htm
ＳＴＬや再ﾘ用が、どうのこうのいっているより、
ここいら辺まで完成した品が普及した方が良いので無い？
外部への依存度がたかまっていくのか、共同開発が増えるのか、
その辺は分からないが、、、 そこまでいちいち考えて書かれた文章でないってことだろ
聞くだけ無駄 
