- 1 名前：仕様書無しさん [2009/03/16(月) 00:02:18 ]
- 前スレ
ゲームプログラマの人に聞きたい 33問目
pc11.2ch.net/test/read.cgi/prog/1234083564/
まったりといきましょー
- 691 名前：仕様書無しさん mailto:sage [2009/04/04(土) 18:12:12 ]
- >>689
> デザインリソースすら再起動なしに読み込んで欲しいくらいなのに
そりゃそうだがPCじゃないんだから作業量やメモリサイズとかの管理考えたらないと思うぞ
- 692 名前：仕様書無しさん mailto:sage [2009/04/04(土) 18:16:46 ]
- >>690
ターゲットはどうしたって必要だから用意するとして、
プログラム書かない人らにビルド環境まで用意するのはコストがかかりすぎるのよ
開発がgccオンリーでできるあれとか、CWが無料のそれとかくらいでしょそこまでできるのは
- 693 名前：仕様書無しさん mailto:sage [2009/04/04(土) 18:21:43 ]
- そんなにみんなでスクリプト書くの？
俺の感覚だと怖いから書くひと限定させるけどそうも言ってられないほど作業量が多いのかな？
- 694 名前：仕様書無しさん mailto:sage [2009/04/04(土) 18:40:53 ]
- >>693
その感覚は間違いではないな。
ただ組み込みスクリプトがもてはやされた理由としては・・・
1.欧米ではプログラミングできないレベルデザイナーなどいない。（スクリプトレベルならまず問題なし）
2.ビルド時間の増大。リンクだけで10〜15分ぐらいかかる場合もざら。（大規模だともっと長いかも・・・）
と、作業量が多いのも確かなんだけど、開発後半へ行くほど通常のやり方では作業効率が下がってくるので、
それを補う形でスクリプト化を進めるというのが一般的な考えじゃないかな。
こういう外部化を進めていかないと人増やしても生産効率はあがらないとかになりがちだし。
- 695 名前：仕様書無しさん mailto:sage [2009/04/04(土) 19:41:45 ]
- スクリプトで制御するって前提にしたほうがシステム全体の見通しが良くなる場合もある。
・・・と思う
- 696 名前：仕様書無しさん mailto:sage [2009/04/04(土) 20:32:14 ]
- >>695
無いよ
本当は業務系みたいに全員ＰＧ作戦のがいいに決まってるだろ
少なくともスクリプトとc/c++のやりとり部分が増える
それは一度作ってしまえば・・・という話じゃなくて
仕様ごとにそれが必要になると思う
- 697 名前：仕様書無しさん mailto:sage [2009/04/04(土) 20:33:03 ]
- うちは何ヶ国語にもローカライズされるの前提だから、
プログラムソース渡さずに済むようにスクリプト使ってる。
- 698 名前：仕様書無しさん mailto:sage [2009/04/04(土) 20:45:35 ]
- >>696
全員攻撃、全員守備
これからはトータルプログラミングの時代だな！
- 699 名前：仕様書無しさん mailto:sage [2009/04/04(土) 20:53:09 ]
- それリソースの問題じゃないか？
- 700 名前：仕様書無しさん mailto:sage [2009/04/04(土) 21:09:23 ]
- スクリプト部分の実行速度は糞遅いんだが
- 701 名前：仕様書無しさん mailto:sage [2009/04/04(土) 21:49:04 ]
- たしかにクソ遅いのは認めるが、使いどころだと思う。
毎フレーム実行するような箇所は極力使用を避けるとか、数フレームに一回実行とかそういう工夫はけっこう必要になってくる。
スクリプトを使って重くなってる箇所はネイティブに置き換えたりと、後で対処してもそんなもんだから、まずはトライファストという流れでもいいんじゃないかな。
- 702 名前：仕様書無しさん mailto:sage [2009/04/04(土) 22:42:00 ]
- 遅い場合はJITコンパイルすれば？
- 703 名前：仕様書無しさん mailto:sage [2009/04/04(土) 23:28:44 ]
- コンパイル中、じっと机に座って待ってますが全然速くなりません。
- 704 名前：仕様書無しさん mailto:sage [2009/04/05(日) 00:52:22 ]
- >>700
そういう時は専用命令をプログラマに作ってもらおう。
大抵遅い理由とか認識してたりする。一定の処理をまとめてやるとか、
機能を限定して高速とか、前処理として呼ぶと速くなる命令とか、なんか考えてくれるよ。
- 705 名前：仕様書無しさん mailto:sage [2009/04/05(日) 01:01:48 ]
- 汎用に過ぎるスクリプトシステムが遅いのはしょうがない
なんでもできるってことは無駄が多いわけだから
まあそれで結局、PJごとに簡易スクリプトを作ることになるわけだが
- 706 名前：仕様書無しさん mailto:sage [2009/04/05(日) 01:35:35 ]
- スクリプト自体の動作速度が気になる時代じゃない気はするな
Windows3.1の時代は苦労した覚えはあるが
- 707 名前：仕様書無しさん mailto:sage [2009/04/05(日) 02:07:30 ]
- Ｘ６８のアセンブラよりペンティアムマシンのBASICのが速いんじゃね？とか９０年代に考えていたのからすると
もやはマッハすぎて目に見えないスピードだ。
- 708 名前：仕様書無しさん mailto:sage [2009/04/05(日) 02:13:31 ]
- >>691
うち、デザインリソースも再起動なしに変更できるよ？
- 709 名前：仕様書無しさん mailto:sage [2009/04/05(日) 02:27:04 ]
- デザインリソースのツールとかPS1のころから出てたろ。
金か労力を裂いてるか裂いてないかだけの話だと思うが。
- 710 名前：仕様書無しさん mailto:sage [2009/04/05(日) 05:13:16 ]
- >>708
ルールがそりゃゆるけりゃ出来るよ。
- 711 名前：仕様書無しさん mailto:sage [2009/04/05(日) 05:22:10 ]
- デザインリソースって何？
- 712 名前：仕様書無しさん mailto:sage [2009/04/05(日) 13:08:52 ]
- >>711
モデルとかテクスチャとかあるいはシーンデータなど。
会社によって呼び名はまちまち。
- 713 名前：仕様書無しさん mailto:sage [2009/04/06(月) 06:48:02 ]
- 再起動なしって・・・ズボラな奴だな
- 714 名前：仕様書無しさん mailto:sage [2009/04/06(月) 10:19:08 ]
- ゲームの途中でもリソースの更新できると便利だよー。
- 715 名前：仕様書無しさん mailto:sage [2009/04/06(月) 12:22:26 ]
- 脱がせパッチ作者様ですね。わかります。
- 716 名前：仕様書無しさん [2009/04/06(月) 14:07:58 ]
- pc11.2ch.net/test/read.cgi/gamedev/1238725539/127
> このスレではなんかメモリのコンパクション不要論を唱えてる
> 馬鹿ばっかりなんだが
（中略）
> ある程度の規模のゲームなら、やらざるを得ないと思うんだが。
これ、ほんとですか？
- 717 名前：仕様書無しさん mailto:sage [2009/04/06(月) 14:10:23 ]
- ほんとですか、と聞くならここだろ？
> 実際「ワンダと巨像」でもメモリのコンパクションは、行なっている。
>
> しかも「ワンダと巨像」ではテクスチャ、地形データのみならず、
> プログラムコード自体も再配置の対象となっている。
ほんとかどうか俺は知らんが、肝を省略するなよw
- 718 名前：仕様書無しさん mailto:sage [2009/04/06(月) 14:16:13 ]
- >>717
いや、そこは、ほんとかどうかここで聞いてわかる話じゃないし。
うっかり口が滑った程度だと思って引用も控えました。
聞きたいのは「ある程度の規模のゲームなら、メモリコンパクションは
やらざるを得ない」というのがほんとか、ってことです。
むしろ、テクスチャとか地形データとか大きなデータならわからんでも
ないんですけど、どうも C++ オブジェクト単位でコンパクションをかける
って話みたいで。そんなのやったことないですし、やるとしても似たような
仕組みを局所的（アクセスの頻繁なところに）にかければいいだけだと
思うんですよ。
- 719 名前：仕様書無しさん mailto:sage [2009/04/06(月) 14:18:22 ]
- すいません。 >718 だとコンパクションとアクセスの頻度のつながりが意味不明ですね。
引用元のスレでは、コンパクションの目的としてキャッシュヒット率が挙げられていたもので。
その時点でちょっと信じ難いんですが。
- 720 名前：仕様書無しさん mailto:sage [2009/04/06(月) 14:55:47 ]
- インパクとかコムパックとかもうね
- 721 名前：仕様書無しさん mailto:sage [2009/04/06(月) 15:09:22 ]
- 工学社の代理部みたいなところか
- 722 名前：仕様書無しさん mailto:sage [2009/04/06(月) 19:15:04 ]
- >>718
> 聞きたいのは「ある程度の規模のゲームなら、メモリコンパクションは
> やらざるを得ない」というのがほんとか、ってことです。
嘘。
ゲームによる。
規模は必要性の理由ではない。
- 723 名前：仕様書無しさん mailto:sage [2009/04/06(月) 19:25:29 ]
- なんかあのスレから波及してるが
職場で俺々システム押し付けてくるおっさんでもいるのか？
はやめにはずしたほうがいいぞ
奴等は自分しか面倒みれないシステムをゲームに組み込んで
自分の居場所を作ろうとするからな
マジで邪魔でうぜぇ
俺のところでも去年大喧嘩になってやっと無意味である
という結論だしてタスク馬鹿にトドメさしてやった
あのシステムグローバル変数常用になるから
散々プロジェクトバグらせてまた同じこと繰り返そうとするから
みんなで集中砲火したらやっと諦めやがった
壷のあのスレ会社の延長になってたなｗ
明らかにプロジェクトでバグ数違う（桁がｗ）のに誰が使うかっての
- 724 名前：仕様書無しさん mailto:sage [2009/04/06(月) 19:41:46 ]
- >>723
>>2
- 725 名前：仕様書無しさん mailto:sage [2009/04/06(月) 21:18:17 ]
- >717
ps2にはoverlayしかなかったはずだがな。
再配置可能なリンカもそれに対応したローダもなかったはず。
- 726 名前：仕様書無しさん mailto:sage [2009/04/06(月) 21:30:48 ]
- オレが経験したプロジェクトはまた事情が違うだろうけど、メモリコンパクションが必要になったことってないなぁ・・・
CEDEC等でメモリコンパクションが必要だったというプロジェクトの講演を聴いたが、当の本人たちが結果的にそれがよかったどうかはわからないとか言ってたし、ゲームの種類にもよるのかな。
巨大なオブジェクト（天球など）の円滑なメモリ確保のためにプールした領域を使いまわしたり、逆に取得・解放頻度の高い細かいオブジェクト用にでかい領域を確保してそれを割いて利用するようなことはあったが、
それ以外はOSなり、メモリシステムに任せていた。
昔は事情が違うだろうけど、少なくとも今はOSにある程度まかせたほうがよい気がするなぁ。
ただし、デフォルトのnewはそのままでは使えんけどね。
- 727 名前：仕様書無しさん mailto:sage [2009/04/06(月) 21:34:51 ]
- フリーラン系だとコンパクション使ってるプロジェクトはあるらしいけどね。
昔携帯機で開発してた時、コンパクションするからメモリはハンドルを介して使えとか言われたことはある。
なんかPalmの開発環境思い出して噴いたよ。
- 728 名前：仕様書無しさん mailto:sage [2009/04/06(月) 22:26:01 ]
- メモリコンパクションはただの手段だからなぁ。
設計してみて必要なら使うけれど、必要でないなら使わない。
ただそれだけのことじゃね？
- 729 名前：仕様書無しさん mailto:sage [2009/04/06(月) 22:39:25 ]
- ﾒﾓﾘｺﾝﾁｸｼｮｳ！
- 730 名前：仕様書無しさん mailto:sage [2009/04/06(月) 23:18:58 ]
- ワンダと巨像のやつはどっかのインタビュー記事で読んだ気がするな。
そこまでやってるゲームはあんまないと思うが、あのゲームは全部シームレスでPS2の限界を
目指してたやつだし、そういう技術的なことが好きなやつがたくさん参加してたんだろう。
1度使えるレベルで作れば、いまどきのハードなら携帯からなにから流用できそうで、ショボゲーの量産には
便利そうだが、どうだろうね。
- 731 名前：仕様書無しさん mailto:sage [2009/04/07(火) 00:13:22 ]
- レベル低いなぁ。
- 732 名前：仕様書無しさん mailto:sage [2009/04/07(火) 00:19:21 ]
- >>731
雑談でレベルを測ろうとするお前の頭も相当な(ry
- 733 名前：仕様書無しさん mailto:sage [2009/04/07(火) 01:22:23 ]
- 以前同じことを言われたんだろう。オレに。
- 734 名前：仕様書無しさん mailto:sage [2009/04/07(火) 01:41:36 ]
- ワンダみたいにやるべきことが最初から明確になってて、その手段として使うならいいけど
手段ありきだと破綻するし、普通そんなことせんよな
メモリが足りないならまず削減する方法を考えるべきで
- 735 名前：仕様書無しさん mailto:sage [2009/04/07(火) 05:06:34 ]
- コンパクションの目的は主に断片化の解消で、
断片化して問題になるデータはアロケートブロックサイズより巨大なデータな訳で、
つまりはテクスチャやモデルデータや音声といったサイズを食うソースが大半な訳で、
それ削減しろって言うのはドーヨ？
プログラムコードや軽量オブジェクトのキャッシュヒット率目的の場合なら仕方ないが、
問題のある部分をプロファイリングしてそこだけ自前でキャッシュ向けに固めなおす実装の方が簡単確実の気もするな
- 736 名前：仕様書無しさん mailto:sage [2009/04/07(火) 05:36:17 ]
- 根本的に才能ないわお前
- 737 名前：仕様書無しさん mailto:sage [2009/04/07(火) 06:23:43 ]
- うるさいのう
- 738 名前：仕様書無しさん mailto:sage [2009/04/07(火) 07:29:42 ]
- >735
> そこだけ自前でキャッシュ向けに固めなおす実装の方が簡単確実の気もするな
二次キャッシュにプリフェッチしとけよ。一次キャッシュまで制御仕様とするな。
費用対効果って言葉もあるだろ。
そこまでやったって、10万売れればイイトコのゲームしか作ってないんだろ？
- 739 名前：仕様書無しさん mailto:sage [2009/04/07(火) 16:21:05 ]
- まぁ、メモリの断片化に関しては解決方法はコンパクションだけでもないし、ゲームの種類や規模にもよるよな。
734のいうようにリソースの削減を考えるのは普通。
デザイナーで無茶してるやつとかいるしな、たまに。
- 740 名前：仕様書無しさん mailto:sage [2009/04/07(火) 22:32:30 ]
- >>725
お前にだけ見つからないように配布された。
つーか elf なんだから自前で実装できるだろ。
- 741 名前：仕様書無しさん mailto:sage [2009/04/07(火) 23:11:17 ]
- PS2の限界にいどんだんだからいいじゃねぇーかｗ そこそこ売れてるし。
- 742 名前：仕様書無しさん mailto:sage [2009/04/07(火) 23:29:37 ]
- メモリのコンパクションはやるやらないは別として理解できるんだが、
プログラムまで再配置の対象にするのってどういう状況？
プログラムは通常連続したアドレスに一気に配置されると思うんだけど、
メモリきついと細かくモジュールに分けて入れ替えたりするの？
- 743 名前：仕様書無しさん mailto:sage [2009/04/07(火) 23:49:50 ]
- オーバーレイの話であれば、メモリ稼ぐための常套手段だな
ドラクエにたとえると、タイトル・ダンジョン・町・フィールド・バトル・エンディングといった大まかな区分において
そこでしか使わない処理があれば、それをモジュールにして
必要なときだけ展開するようにするわけだ
特別難しいこともないし、気軽に実装できる
まあ稀に、モジュール同士で呼び合うような処理作ってはまる奴は居るがｗ
- 744 名前：仕様書無しさん mailto:sage [2009/04/08(水) 00:06:09 ]
- やっぱゲームプログラマって技術力高いなあ
- 745 名前：仕様書無しさん mailto:sage [2009/04/08(水) 00:08:10 ]
- 普通だろ
- 746 名前：仕様書無しさん mailto:sage [2009/04/08(水) 00:44:17 ]
- 近年はクロス開発（PC&ターゲット）することが普通になっているから、
昔ほどターゲットに最適化したカリカリチューンをしないプロジェクトもけっこう増えてるな。
最近はi7とかでようやくPCも追いついてきたけど、
ちょっと前までターゲットと開発PCの性能差がありすぎて、
PC版じゃいろいろオミットしたり代替コード実装するケースがあったために、
なるべくそれぞれの差異を小さくするためにパフォーマンスを多少削ってでも無難なコードにするケースもけっこうあった（というか今もある）。
マルチプラットフォームになってくるとこういった部分がますます増えてくるので、
ライブラリを整備しているチーム以外はメモリまわりみたいな低レベルなレイヤーをいじる機会もだいぶ減ってるんじゃないか？
- 747 名前：仕様書無しさん mailto:sage [2009/04/08(水) 01:08:31 ]
- ターゲット以外で動くようになんかしてられない底辺です。
- 748 名前：仕様書無しさん mailto:sage [2009/04/08(水) 01:37:10 ]
- クロスが普通になってきたって、コンシューマはセルフなんかしないだろ。
海外のスタジオの人？
- 749 名前：仕様書無しさん mailto:sage [2009/04/08(水) 01:51:54 ]
- うんにゃ、国内。
ただ開発後期はターゲットばっかりになったけど、ある程度まではセルフでやってたよ。
とはいえ、オレ自身は現世代機のプロジェクトは先日終わったやつしか知らないので、今後はどうなるかわからんけど・・・
まぁ、あとは他社の話でもちらほら耳にするけどね。
Pixel Junk Edenとか。
- 750 名前：仕様書無しさん mailto:sage [2009/04/08(水) 03:12:01 ]
- お前ら実際今どの辺のレイヤーをいじってるんですか？
俺はコスプレイヤーとか
- 751 名前：仕様書無しさん mailto:sage [2009/04/08(水) 09:52:44 ]
- イベントシーンとか。
シナリオに合わせた動きを打ち込んだりする。
- 752 名前：仕様書無しさん mailto:sage [2009/04/08(水) 15:56:26 ]
- ウチのライブラリ班は、自分達は他のプログラマに比べ技術的に上である、
という雰囲気をかもし出してて好きになれない。
底辺何年もいじってりゃそれくらいできなきゃ困るっつーの。
そのくせ自分達は使わないからかなりオレルールの仕様。
ライブラリ班が仕様会議を開くっつーから、そこでゲーム開発側が
一丸となって仕様変更を提案したら全否定。
「今回集まってもらったのはライブラリの説明をするためです。それ以外の目的はありません。」
だと。それならヘルプテキストローカルフォルダに入れとけ。
- 753 名前：仕様書無しさん mailto:sage [2009/04/08(水) 16:14:50 ]
- uproda.2ch-library.com/117666O5T/lib117666.jpg
まぁ、パンツでもみて落ち着け
- 754 名前：仕様書無しさん mailto:sage [2009/04/08(水) 16:36:53 ]
- >>749
吐き気がするほど意味が分からない。
クロス開発とかググったほうがいいんじゃないのか。
- 755 名前：仕様書無しさん mailto:sage [2009/04/08(水) 17:36:08 ]
- FFの野村さんって年収一億くらいもらってるんですか？
- 756 名前：仕様書無しさん [2009/04/08(水) 17:54:33 ]
- >>752
悪いけど技術力は圧倒的に
エンジンチーム＞＞＞＞＞＞＞＞＞＞＞＞ゲームチーム＞ツールチーム
エンジンチームは社長の次くらいに権力持ってる。
- 757 名前：仕様書無しさん mailto:sage [2009/04/08(水) 18:08:48 ]
- それはある意味理想の形だけど、実際にはおごりだと思うよ。
>>756のエンジンチームがどこまでサポートしてるか解らないけど、
パーツを作るのとアプリケーションを作るのは違うスキルが必要。
まぁ、ツクールくらいまでライブラリ側がサポートしてるなら
ゲームチームは何も発言する権利はないけど。
- 758 名前：仕様書無しさん mailto:sage [2009/04/08(水) 19:01:01 ]
- やっぱお前らの会社も脱箱化が進んでんの？
- 759 名前：仕様書無しさん mailto:sage [2009/04/08(水) 20:40:09 ]
- だっぱこだっぱこ
一日でも早くだっぱこでっせ
- 760 名前：仕様書無しさん mailto:sage [2009/04/08(水) 21:13:03 ]
- >>752
俺のところもそうなったときあったけど、
要望受け入れリストを作成して達成率〜とか横につけてやったら
要望はどんどん上がってくるのに１つも達成項目なくて
「誰のためにライブラリ作ってるの？」って話になって
給与面談の減額材料に使われたらしく要望受け入れるようになったｗ
ざまぁｗｗｗｗ
- 761 名前：仕様書無しさん mailto:sage [2009/04/08(水) 21:15:14 ]
-
PHP社内技術ＨＰ作成チーム（俺だけ）＞エンジンチーム＞ゲームチーム＞ツールチーム
- 762 名前：仕様書無しさん [2009/04/08(水) 21:36:46 ]
- >>760
そうゆう事態に陥らないように、生意気なゲームプログラマは
徹底的にいじめて辞めさせま〜す♪
- 763 名前：仕様書無しさん mailto:sage [2009/04/08(水) 21:39:42 ]
- お前等のメンタリティってそこいらのヒステリックなOLと変わらんな…
- 764 名前：752 mailto:sage [2009/04/08(水) 22:09:46 ]
- まぁライブラリ班の言い分も解らなくはない。
ライブラリはシンプルで必要最小限なものが良い、とかそういうの。
ただ、特定の人間しか使わない社内ライブラリなら、
他のプロジェクトでも使う共通機能は全部ライブラリに含めたらいいじゃん、と思う。
ところがライブラリ班の言い分は、それはゲーム開発側で共通モジュールを使うフローを作れ、
みたいな感じだった。ライブラリ→ゲーム共通モジュール→ゲーム開発
こんな風に噛ませろと。まぁこんなことを言い出す背景にはライブラリのポリシー以前に
ライブラリ班の人員が少ないことも大きい。
そうなると人事の問題にまで上がって来るけど、ゲームタイトルと違ってライブラリは
それがいったいいくらの儲けに繋がるか、というのが見えにくい。
柔軟性のない中堅弊社では中々上が重要視しない。さてはてどうしたものか。
- 765 名前：仕様書無しさん mailto:sage [2009/04/08(水) 22:33:30 ]
- つーかピンキリでしょ
ライブラリを、と言うか
DXやGLのアーキテクチャと比べても、明らかに間違って使ってるのに
”ライブラリ班に要望、俺はこうやって使いたい”
って言う位に、本当にスクリプターと違うばかりのゲームプログラマが実際にいたしｗ
しかも、古参で、リーダークラスで、技術ディレクターとか自称しちゃって…
お前の言い分は、とんちレベルだっつーのｗ
プログラムしろよってのか
- 766 名前：仕様書無しさん [2009/04/08(水) 22:38:55 ]
- >>764
うちの会社のエンジンは当然全プロジェクト共通だし
マルチプラットフォームだぞ。
お前んとこがしょぼいだけ。
- 767 名前：仕様書無しさん mailto:sage [2009/04/08(水) 22:46:06 ]
- エンジンのソースを書き換えて
勝手にカスタマイズすりゃいいじゃん。
そんだけの話だろ？w
- 768 名前：仕様書無しさん mailto:sage [2009/04/08(水) 22:55:15 ]
- １０万本レベル程度のゲームだがメインプログラムをやってる身から言わせてもらえれば
ライブラリ班が優越感に浸れる理由がまったくわからん。
- 769 名前：仕様書無しさん mailto:sage [2009/04/08(水) 22:55:36 ]
- 自分でエンジン作れば効率がよいって話ですね。
- 770 名前：仕様書無しさん mailto:sage [2009/04/08(水) 23:01:05 ]
- ちげーよ無能
- 771 名前：仕様書無しさん mailto:sage [2009/04/08(水) 23:05:18 ]
- まあ、マジレスすると作業分担の垣根を取っ払った方が効率がよいというのは小さい会社で
個々人の効率が目に見えるカタチで結果につながっていないだけの話よ。
エンジンはエンジン担当がやれ。
- 772 名前：仕様書無しさん mailto:sage [2009/04/08(水) 23:06:27 ]
- 大きい会社の非効率な縦割り意識とかすごいけどな。
うちの会社だけか？
- 773 名前：仕様書無しさん mailto:sage [2009/04/08(水) 23:08:40 ]
- >768
本数は指標にならんでしょ。
プログラマの人数とかプロジェクトの規模で見ないと。
まぁ、この議論自体がどうでもいいわけだが。
- 774 名前：仕様書無しさん mailto:sage [2009/04/08(水) 23:12:16 ]
- 頭悪いでしょ。
- 775 名前：仕様書無しさん mailto:sage [2009/04/08(水) 23:13:19 ]
- お前がやれとか押し問答してるよりは
やっちまった方が早いと思うがな。
で、エンジンチームにフィードバックしてやれば
向こうからもなんかアクションがあるんじゃねーの。
- 776 名前：752 mailto:sage [2009/04/08(水) 23:16:33 ]
- >>766
まぁそうだ。オレが言っているライブラリ班というのは、
世間一般のゲームエンジン開発チームを指すのではなく、単にウチの会社の話ｗ
>>767>>769
集団で開発する時、スタンドプレイは最終的に効率を落とすと考えてる。
独自に書き換えた後、そのゲームの続編の保守やライブラリの更新とかね。
要はライブラリ班が少ないんだよなぁ。
３プロジェクトあったらプログラマの比率は２：２：２：で
後ライブラリで４くらいでいいと思う。
- 777 名前：仕様書無しさん mailto:sage [2009/04/08(水) 23:21:39 ]
- エンジンチームから情報引き出して
インターフェースだけ決めておいて
後で差し替えればいいじゃん。
- 778 名前：仕様書無しさん mailto:sage [2009/04/08(水) 23:29:48 ]
- うちの会社、プログラムの知識ないやつがその辺に注文つけてくるなー。
注文の内容より、それがどれだけ開発期間かかるか分かってないのがすげーウザイ。
「こんなの３日でできるでしょ？」
いやそれどう見ても１ヶ月かかるから。
- 779 名前：仕様書無しさん mailto:sage [2009/04/08(水) 23:33:30 ]
- ゲームやプログラムがわかってない人じゃないと新しいアイディアが出てこないんだよ
ほとんどが没だが
- 780 名前：仕様書無しさん mailto:sage [2009/04/08(水) 23:33:50 ]
- 3日で出来るって見積もりだしたら、そいつが責任もって3日で作る。
それができないなら無責任ってことなんだと言ってやれよ。
- 781 名前：仕様書無しさん mailto:sage [2009/04/08(水) 23:38:35 ]
- >>780
プログラムの知識が無さ過ぎて、「シンプルな物＝簡単に作れる」と思ってたりして。
- 782 名前：仕様書無しさん mailto:sage [2009/04/08(水) 23:50:16 ]
- ピンキリだな。
試作レベルの出来だったり例外的な処理を省けば
用意するのは結構早く済む。
逆にライブラリだけでも外に売りに出せるレベルとかになると
簡単そうな処理でもアホみたいに時間使うだろうし。
- 783 名前：仕様書無しさん mailto:sage [2009/04/09(木) 00:08:17 ]
- いや、3日で出来るだろって言ってるやつに作らせろって話。
- 784 名前：仕様書無しさん mailto:sage [2009/04/09(木) 00:13:25 ]
- ていうかDirectXとくりそつなもんしか作れないようならいらないよ
DirectXみて作ればいいんだし
あくまでゲームを作ってきた経験でよく使う機能を洗い出せるっていう
腕を見込んでのライブラリ班なんだから
出来なきゃテメー等は用済みなんだよボケが！
っていうだけは楽だったｗホント楽だったｗ言うだけはなｗ
- 785 名前：仕様書無しさん mailto:sage [2009/04/09(木) 00:16:50 ]
- >>783
プログラムの知識のないやつが３日で、って言ってるわけだから、さすがにそれは無理かと。
- 786 名前：仕様書無しさん mailto:sage [2009/04/09(木) 00:23:44 ]
- >745
PCじゃオーバーレイなんて使う理由が無いしなぁ。
って、そもそもVC++にオーバーレイの機能はあるのか？
- 787 名前：仕様書無しさん mailto:sage [2009/04/09(木) 00:34:24 ]
- >>784
ライブラリ化が必須のものってそうそうないんだよね
大手だと標準化することでリソースの使いまわしが効く、みたいなことをエライサンが言うけど
骨の数やポリゴン数の制限を全く考慮してないつーか・・・
ムービー作ってるんじゃないんだから、状況に応じてデータのスペックも細かく切ってるわけで
そんな都合よく行かない罠
デザインが使うビュアー込みで、軽くて使いやすいエフェクトシステムがあるなら欲しいかな、ってくらい
>>786
PCのこたぁ良く知らんが、DLLでいんじゃね？
- 788 名前：仕様書無しさん [2009/04/09(木) 00:44:39 ]
- Skypeしませんか？
- 789 名前：仕様書無しさん mailto:sage [2009/04/09(木) 00:48:42 ]
- >>754
そうだな、オレが思ってたのと意味が違ったようだ。
ただ部内で一般的にクロス開発っていってたけど、本当はなんて呼ぶんだろ？
まぁ、うちではPC版とターゲット版をそれぞれ作ってた。
基本的な確認はPC上でも見れるようにしてたし、フルスペックで動作させなければいけないような場合やデザインの最終アウトプットを確認したい場合のみ
ターゲット動作させてた。
プラットフォームごとの差異はライブラリ側で9割方吸収。（シェーダとかでけっこう差異はあったが）
今となっては特別なことでもなさそうだし、これが一般的だよな？
まぁ、かなり余裕を持たせた作りになるのでカリカリにハードの性能を搾り出すようなプロジェクトだと違うとは思うけど。
- 790 名前：仕様書無しさん mailto:sage [2009/04/09(木) 01:04:02 ]
- 脱線するが、ライブラリチームとゲームプロジェクトチームでの軋轢があるのはうちの部署ぐらい方思ってたけど、
どこでもそうなんだな。
双方の言い分もわかるんだけど、ガチガチのフレームワークにしてしまってライブラリ自身のほうでモジュール同士の依存度が高くなっているの状況はちょっと何とかして欲しい。
低レベルなAPIの機能拡張や、モジュールに問題を発見した際に修正依頼を出しても「他プロジェクトに影響するので」という理由で断られるのは相当ガッカリする。
あと静的解析にライブラリをかけたときに、ゲーム本体よりもはるかに問題報告があった件には驚いた。
こんなバグだらけのライブラリで一体何本リリースしたと思ってるんだ・・・・
回収騒ぎにならないこを祈ります。
- 791 名前：仕様書無しさん mailto:sage [2009/04/09(木) 01:06:51 ]
- 静的解析面白いよねー
なんかすげぇ怒られてる！と思ったらWindowsライブラリだったりしてｗ
お値段さえなんとかしてくれたら最高なんだけどなあ、静的解析
|
 |
