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

>>598
例えばどういう場合か具体的に言える？

>>601
参照するソースファイルが多い事が予想されるときとか
インクルードの参照順番が重要になるときとか

つーか、window.hみりゃわかるが
インクルードをまとめるのには
インクルードファイルの隠ぺいの意味もあるんだよ。

まあインクルードファイルだけに限らんが

>>602
>参照するソースファイルが多い事が予想されるときとか
は？なおさら個別にインクルードしろよ
何がダメかわかってるの？

>インクルードの参照順番が重要になるときとか
は？もはや意味不明
必要なヘッダはその都度インクルードしなきゃダメだぞ

>>602
アクセス方法や関連を限定することで余計なバグを生まないって視点がまるでないのなお前

>>604
windows.hやその他の総合ヘッダーを読んでから言えw

>>605
サンプルプログラムでも組んでろw

>>606
ダメの見本だしね

>>605
逆だろ
お前のやり方だとバグの桁が２つは上がりそうだ

頭が堅いとバグ件数が跳ね上がるのは真だな

プログラマに必要な7つの大罪のうちの３つだか４つだかって話を思いだした。
怠惰（同じことをやるなら楽にできるように、後からソースを見返すときに苦労しないように簡潔にしたりコメントを増やす。というか手を抜くための努力は惜しまない）以外はよく覚えてないけど。
傲慢と自尊だっけな。

>>602
>インクルードファイルの隠ぺいの意味もあるんだよ。
意味がわからない
なにか得あるの？

コメントを増やす？

聞いた事がないが脳内変換かかってないか、ソレw

>>611
ケースバイケースだが
例えばヘッダーファイルをまとめたヘッダーファイルを
インクルードする形でソースにヘッダーファイルがインクルードしてあれば
機能が追加された際に新たなヘッダーファイルが必要になったときに
ソースファイルの変更の必要はなくなる。

>>613
それが全然メリットに感じねーよｗ

>>614
ここでいろいろ説明するのも面倒くさいんで
デスマってから自分で考えろw

include するヘッダを必要最小限に抑えるのは、自分が何をしているか
把握していることを明らかにすることにつながる。
不要なヘッダを include したり、ヘッダの include 順によってエラーに
なったり挙動が変わったり、あるヘッダを include するときに一見無関係な
ヘッダを手前で include する必要があったりなどというのは、プロジェクトが
チームの手に余るほど複雑だったり巨大だったり腐敗してたりしている
可能性を示しているかも知れない。

個人的には、
// ↓不要なはずだが次の行を消すと何故か動かない
というコメントと同レベルだと感じる。

>>613
グローバル変数にしとけば処理に必要な情報が増えても引数は増やさなくていい、
ってのと同じだな。

void*にしとけば〜（略

>>616
もう面倒くさいから総合ヘッダーを書いたメーカーに
全てメールするといいと思うぞ？w

キチガイ扱いされてしまいだと思うがww

ここまで同義と書いている内容が
一つも同義でない件

>>620
企画乙ｗ

>>621
企画乙w

どうせなら pImpl vs ファクトリメソッドとかもやってよ

>>623
なにそれ？
知らない

>>624
http://ja.lmgtfy.com/?q=pImpl
http://ja.lmgtfy.com/?q=FactoryMethod
http://ja.lmgtfy.com/?q=pImpl+FactoryMethod

>>625
なんのためにそんなことするのかメリットがまったく見えないのでスルー

ヘッダファイルは必要なものを必要なだけ書こうぜ。それができないとか問題視するってことは
ヘッダファイルの内容そのものに問題があるんじゃないの？

それをしないでソースファイルに
必ず一つずつインクルードするって話なんだがw

別ファイルに全部インクルードしといて、それを指定すればいいんだよ。
間違える事無いから。

レベル低い

>>629
最悪だ

で何か変更するたびフルコンパイル。
信じられないビルド時間のあいだに２ちゃん三昧。

>>629
昔見た↓を思い出した。
#include "include/include.h"

>>632
頭堅いよ。

ケースバイケース出来ないとバグ件数が
跳ね上がるよ？w

そもそも重要なヘッダーファイルに更新が掛かったら
どっちにしろフルコンパイルに近い状態になる。
最悪のケースだけを判断基準にする人間は
頭が悪いと言わざるをえないな。

>>635
> そもそも重要なヘッダーファイルに更新が掛かったら
> どっちにしろフルコンパイルに近い状態になる。

ふむふむ。
まぁ最悪のケースではそういうこともあるな。

> 最悪のケースだけを判断基準にする人間は
> 頭が悪いと言わざるをえないな。

　　　､ミ川川川彡　　　　　　　　　　　　　　　　 ,ｨｒ彡'";;;;;;;;;;;;;;;
　　ミ　　　　　　　彡　　　　　　　　　　　　　 ,.ｨi彡',.=从i､;;;;;;;;;;;;
　三　　ギ 　そ 　三　　　　　　　　　　　　,ｨ/ｲ,r'"　.i!ｌi,il i､ﾐ',:;;;;
　三.　　ャ 　れ 　三　　　　,.　-‐==- ､, /!li/'/　　　l'' l', ',ヾ,ヽ;
　三　　グ 　は 　三　　,,__-＝ﾆ三三ﾆヾヽl!/,_ ,_i ､,,.ｨ'=-､_ヾヾ
　三　　で 　 　 　 三,. ‐ﾆ三＝,=＝‐ ''' `‐゛j,ｪﾂ''''ｰ=5ｒ‐ｫ､,　ヽ
　三. 　 言　 ひ 　三　　.,,__／　　　　　　.　,' ﾝ′　　　￣
　三 　　っ　　ょ 　三　　 /　　　　 　 　 　 ｉ l,
　三.　　て 　 っ 　三　　ﾉ ..::.:... ,_　　i　 　 !　 `´'　　　　　　J
　三　 　る　　と　 三　 iｪｧﾒ`'7rｪ､,ｰ'　 　 i　}ｴ=､
　 三 　 の 　 し　 三　ﾉ "'　　 ￣　　　　　! '';;;;;;;
　 三 　 か　 て　 三.　ｉヽ,_ﾝ　　　　 J　　　l
　　三　 !?　　　　三　　!し=､ ヽ　 　 　 　 　i　　　　　　　　　,.
　　 彡　　　　　　ミ　　 ! "''　`'′　　　　　　ヽ、,,__,,..,_ｨ,..ｒ,',",
　　　 彡川川川ミ.　　　l　　　　　　　 _,　,　　 | ` ｰ､≡＝,ﾝ _,,,
　　　　　　　　　　　　　 ヽ、 _,,,,,ィﾆ三"'"　　,,.'ヘ　rｰ‐ ''''''"
　　　　　　　　　　　　　　　 `, i'''ﾆ'" ,.　-‐'"　　　`/
　　　　　　　　　　　　　　　ヽ　!　 i´　　　　　　 ／
　　　　　　　　　　　　　　　ノレ'ー'!　　　　　 ／　O

ライブラリは面倒だからまとめてあるな
どうせめったに更新しないし更新したときはフルコンパイルだし

>>637
同意。

大体ライブラリのようなフレームワークやエンジン系の場合は
まとめられてる方がメリットが大きい。

バラバラがいいときはスクリプト系の場合だろうね。

>>638
> バラバラがいいときはスクリプト系の場合だろうね。
スクリプトこそフレームワークに閉じ込められている場合の最たるものだろう。

ミドルウェアとか使ったとして、どのソースを見ても
#include <allinc.h>
とかなってたら、気分悪くないか？

>>639
スクリプトからフレームワーク部分を読むときは
総合ヘッダーで
スクリプト特有の処理のヘッダーのときがバラバラがいいって話なんだけど
サラっと書きすぎて誤解したみたいだな。

つーか、そこら辺のさじ加減も含めてセンスだと思うので
バグだらけになって問題が出て自分に被害がない限りは
ほっとくレベルの話だけどな。

ただ頭が堅い奴はヤバいのはガチだ。

>>640
でさ、UE とか Havok とかのソースコード付きライセンス買ったとして、
どのソース見ても
#include <allinc.h>
なんてなってて平気なわけ？ むしろ感心したりするわけ？

>>641
バグだらけになる以前でさえもほっとくことのできない何かというのは
存在するのか？
存在するならそれらとの違いは何だ？

stdafx.h「ここは俺の出番だな」

>>642
面倒臭いので、とりあえずwindows.hやDirectXのヘッダーを嫁
としか言えんな。

あとは好きにしろw

あと、バグだらけも含まれるが自分の作業効率に
影響が出るか出ないかは他人の作業に
口を出す上での指標になるな。

逆にそれ以外は言いだすとキリがないだろw

依存関係を弱めるってソフトウェア工学の初期から今に至るまで重要な手法なのに

>>646
ヘッダーを一つインクルードしてるのと
たくさんインクルードしてる場合
合計の依存するヘッダーの数が等しい場合
ソースファイルで見た場合、依存関係は弱まってるけど？

面倒臭いからわからなかったら
レスしなくていいけど

いちばんしなくていいレスは >>647 だな

じゃあ、ずっとwindows.hやstdafx.hと
にらめっこしてろw

問題が出たらソースコードに手を加えて修正するのではなく
ヘッダファイルを修正する。

>>647
すごい馬鹿を見たｗ

やはり理解出来なかったようだなw

馬鹿にはまともなフレームワークを
作れないという事だなw

まあ俺が使うわけじゃないからいいけどwww

windows.hなんて今どき使わないよ。

今どきは何を使うの？

linux.h かな

>>655
せめてunistd.hって答えろよｗ

>>647
お前が他人のレスを理解できないのはわかった

>>657
紛らわしいレスにアンカーをつけないから
カオスになる。

お前のプロジェクトと一緒だよw

>>658
お前が他人のレスを理解できないのはわかった

よかった。ごちゃまぜヘッダを強固に擁護するようなやつがやっぱりアホで。

>>659
お前が他人のレスを理解出来ないのはわかった

>>660
sdkを提供してるところにメールでも送ってろ、低能
あとハード周りに弱いからって
ピーピー泣き付くのも金輪際やめろw

ほんとアホだなｗ

スレに参加したい小学生がなにかわめきちらしてるなぁ。
煽り合いはゲハにでもいってやれ。

同意

単文で煽るだけしか能がないから
面白くもないしな

お前のかーちゃんでべそｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

見たのかよ

書き換えのコストを主張してる時点で雑魚。

アルゴリズムの考え方がわからない

ソートアルゴリズムだの、データ型だの一連のものは読んだ

でも、データ型で配列だのハッシュだの、ツリーだの
そんなもんはプログラムする上で使うし

ソートアルゴリズムで、バブルソートだのクイックソートだのできるようになった
でもこれって、ただのFor文の組み合わせだよね。

極論言えば、1〜10まで足しこむのもアルゴリズムじゃね？

こんなのやっても、俺が求める
数式をプログラムに落とし込む能力なんかつかねぇし
スマートな実装方法なんてものの応えも出てこない。

結局、何かしたいときに
そのフロー図書いて落とし込むこと＝アルゴリズムでいいの？
誰か教えて。

つか、数式をスマートにプログラムに落としこむのに良い本とか教えて

> 結局、何かしたいときに
> そのフロー図書いて落とし込むこと＝アルゴリズムでいいの？
良いと思うよ。
スマートかどうかはアルゴリズムにとってはどうでも良いし。あくまで使う側の都合だし。

＞数式をスマートにプログラムに落としこむ
何が言いたいのかさっぱり不明
具体例を挙げよ

ゲーム業界も不景気なの？
正社員募集してる所が20社もないんだけど・・・

>>671
よく、学会お論文で数式とか出てくるじゃん
そういうのを、スラっと実装して、高速なフローで実装したいのよ

延々とソートプログラムなんか書いてもそんなんでいないじゃん

>>673
数式をそのままぶちこめばいいんじゃないの？

ナビエ-ストークス方程式とか
どうやってぶち込むの？
教えて。見せて

>>675
そういうことしたいのなら「数値計算」を勉強してみたら良いと思うよ。

SIGGRAPHでの初期の流体の論文はナビエ-ストークスを単純な差分化しただけ。
数値計算の入門書レベルの手法。入門書ではいきなり複雑な方程式ではやらないが。
で、数値計算の入門書にある熱伝導方程式や波動方程式ででもでてくる発散の問題がでてくる。
で次の重要なstamの論文となるわけ。今のレベルじゃまだまだ遠いな。

おお
キーワードありがとう。ググってみる。

論文が宝の山に見えるようになったらいいなぁ

>>670
> > 結局、何かしたいときに
> > そのフロー図書いて落とし込むこと＝アルゴリズムでいいの？
> 良いと思うよ。
> スマートかどうかはアルゴリズムにとってはどうでも良いし。あくまで使う側の都合だし。

話は戻るけど、そういうことなら
結局泥臭いソースコードでも、なんでもアルゴリズムでいいってわけね。
なーんだ。

>>669
>そのフロー図書いて落とし込むこと＝アルゴリズムでいいの？
フロー図を書いた時点でアルゴリズムになってるはず
プログラムに落とし込む必要は無い

数値計算のアルゴリズムって
ハードごとに得意なデータ構造とか
近似計算に落としこむだけじゃないのか？

勿論、精度が落ちにくい計算順序やらあるだろうが
汎用的なアルゴリズムとかはないんじゃないか？

工学系のシミュレーションじゃ近似手法だけで山のように教科書があります。

あー、あるね

でも大抵のゲームではそこまで
気を使ってないからいいんでないかとw

近々、うちの会社で大規模リストラがあるみたい…

はぁ、今から次探しておこう。

んじゃ
「これって、このフローでいけるんじゃね？」がアルゴリズムでいいわけね

納得だ

人気RPGの某ゲーム会社がスタッフ200人を大量解雇
http://tsushima.2ch.net/test/read.cgi/news/1256780141/1

>世界中で人気を博しているロールプレイングゲームシリーズを発売し、多くのファンが存在する大手ゲーム
>会社Xが、スタッフ約200人に対して解雇通告をしていることが判明した。

どこなんでしょうか？
|:::::::::::::::::::::::::::::::
|"￣￣ﾞﾞ`∩::::::::::::::::
|,ノ　　ヽ,　ヽ:::::::::::::::::::::::::
|●　　　● i'ﾞ￣ﾞﾞﾞ`''､::::::::::::::::
|　(_●_)　　ﾐノ　　ヽ ヾつ::::::::::
|　ヽノ　　ノ●　　 ● i::::::::::
｛ヽ,__　　 ）´(_●_)　｀,ﾐ:::::::
| ヽ　　　/　 ヽノ　 ,ノ::::::

カルチャーブレーン

カルチャーブレーンだな

カルチャーブレーンかも

>>686
■eでしょう。
開発終わってチーム解散→新タイトル開発で時期に応じて再募集。

スクエニは人数ばかり多くて生産性の低いスタッフが多いので
有名だからな

ぶっちゃけ外注で持ってる会社だろw

最近はカプの外注率もひどいな、看板タイトルも丸投げだし
あそこ1000人以上いるはずなのにな

>>692
スクエニは大手で物凄い数のスタッフがいるにも関わらずに
現世代機になってからまだラストレムナントくらいしか
据え置きゲームを発売出来てない会社なので、次元が違うなw

どうして移植って高確率で劣化するんですか？
SFC→PSやPS→PSP等明らかにスペックが上回るハードへの移植でも劣化してる場合が多々あるんですが…。

外注丸投げ発注だから

予算が少なすぎるから

>>693
プロジェクトの規模を考えれば別におかしくもなんともない。
有能な人間を必要最小限ギリギリだけ雇うよりも、いくらでも換えが効く人間を必要に応じて大量に使う方が効率良い。

ソースが残ってないから
ソースが残っててもグラフィックデータはコンバート後のものしか残ってないってのもよくある話で

>>697
規模っつってもスクエニくらい開発が遅い会社は
他にないしw

つーか、コアメンバーがJRPG以外まともに作れないんだから
元から内制のメリットなんかないだろww

規制で書き込めない人増えてそうだな。