[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 2chのread.cgiへ]
Update time : 05/09 13:36 / Filesize : 193 KB / Number-of Response : 878
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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



1 名前:仕様書無しさん [2009/03/16(月) 00:02:18 ]
前スレ

ゲームプログラマの人に聞きたい 33問目
pc11.2ch.net/test/read.cgi/prog/1234083564/

まったりといきましょー

658 名前:仕様書無しさん mailto:sage [2009/04/03(金) 21:32:05 ]
Lunaは文法は(直せるし)どうでもいいんだけど、
あの文字列処理の貧弱さだけはなんとかしてほしい。

と、Perl使いがメモリの制約を忘れて愚痴ってみる。

659 名前:仕様書無しさん mailto:sage [2009/04/03(金) 21:43:36 ]
>>615
一通り読んだことあるよ。

でもこういう本を読むのは社内じゃ少数派かな。
とくにSICPは。


>>657
Cのマクロ。
いやまじで。
この決断を下したやつをぶっとばしたい。

660 名前:仕様書無しさん mailto:sage [2009/04/03(金) 22:00:51 ]
Cのマクロは手間かからないから小規模であまり変更ないものならかなり有効だと思うけど。

661 名前:仕様書無しさん mailto:sage [2009/04/03(金) 22:17:48 ]
>657
squirrelを使ってみようかと検討中。
バイトオーダーが違うのをナントカしたいところ。

662 名前:仕様書無しさん mailto:sage [2009/04/03(金) 23:39:47 ]
>>660
そういう用途ではコンパイルするのがやだ。

663 名前:仕様書無しさん mailto:sage [2009/04/04(土) 00:35:28 ]
勝手に組み込みスクリプトを入れると大本のメーカーに怒られます。

664 名前:仕様書無しさん mailto:sage [2009/04/04(土) 00:43:43 ]
C以下の記述性でC++を越えるコンパイル速度の遅さを誇り
グローバル変数しかなくメモリも自由に触れない
スクリプト(笑)と称する物を使わされている

見るだけで胃が痛くなるんだ

665 名前:仕様書無しさん mailto:sage [2009/04/04(土) 00:52:36 ]
本当はスクリプトを使いたいけど、上の人がガリガリ書くのが好きなんであきらめた
一部パラメータはCSVにまとめたけど役に立ってない

666 名前:仕様書無しさん mailto:sage [2009/04/04(土) 00:56:40 ]
Lua使えよ



667 名前:仕様書無しさん mailto:sage [2009/04/04(土) 00:57:13 ]
Luaは悪くはないんだけどね。
広く使われてライブラリや情報も多いし、だいぶ枯れてるし・・・
ただ後発でよいものがあると言われると、プログラマーの性としてそっち使いたくならない?

組み込みスクリプトの用途や目的を考えるとCマクロは、ちょっと不向きかもしれんね。
元々、ビルドレスで何か変更したいという欲求の答えのひとつがスクリプト化なわけだし。

Squirrelはちょこちょこ勉強兼ねて使ったりしてますが、PCもプラットフォームもエンディアンが同じなのでバイトオーダー気にしたことなかった・・・・
Wiiや360だと問題が出たりするのかな?
一応、バイトオーダーをなんとかするAPIはあるみたいだけど、ターゲットで条件分岐するのもけっこう面倒くさそう。

組み込みスクリプトで強力な文字列処理が欲しいと考えると、現状での選択肢としてはStackless Pythonという選択肢もありそうなんだが、いかせん身近で使っている人がいないので、あまり情報得られないんだよなぁ・・・・
英語で文献は読めても、フォーラムに参加できるほどの心臓がないオレ。

668 名前:仕様書無しさん mailto:sage [2009/04/04(土) 02:14:58 ]
AngelScript使うんだ。


669 名前:仕様書無しさん mailto:sage [2009/04/04(土) 02:28:31 ]
>>667
Python が組み込みで使えればそれが最高な気がするんだけど、
そもそも商用利用に合うライセンスなのか?

svn.python.org/projects/stackless/trunk/LICENSE
ざっと見た感じ、組み込んでの利用についてはっきりとは触れられていないし、
部品として利用されてるソフトのライセンスとか含んでるし、 Lua や Squirrel に
比べるとだいぶややこしそう。

670 名前:仕様書無しさん mailto:sage [2009/04/04(土) 05:45:28 ]
Lispが最も自然です。

671 名前:仕様書無しさん mailto:sage [2009/04/04(土) 09:10:07 ]
Lispなんか使ったらバイトにスクリプトを触らせられないよ。

672 名前:仕様書無しさん [2009/04/04(土) 10:20:37 ]
>>669
うちの会社はPythonだから、ライセンス的には大丈夫なはず。


673 名前:仕様書無しさん mailto:sage [2009/04/04(土) 12:02:51 ]
>>669
海外では商用ソフトでも使われている

674 名前:仕様書無しさん mailto:sage [2009/04/04(土) 13:20:17 ]
誰もライセンス内容に言及できないことについて

675 名前:仕様書無しさん [2009/04/04(土) 14:15:24 ]
だってそういうのは法務部担当だし。


676 名前:仕様書無しさん mailto:sage [2009/04/04(土) 15:01:04 ]
ださっ



677 名前:仕様書無しさん mailto:sage [2009/04/04(土) 15:08:58 ]
素人判断で勝手に組み込むほうが問題
後から大騒ぎになることがある
馬鹿はフリーだからーとかいって確認も取らずに組み込むから
IP amplifierとかその手のツールに頼らざるを得ない

678 名前:仕様書無しさん mailto:sage [2009/04/04(土) 15:28:34 ]
お前特定できるぞw。
判断決定と知識は別物だから。

679 名前:仕様書無しさん [2009/04/04(土) 15:41:20 ]
うちのチームもパフォーマンスいらないところはsquirrelで行くことにした。
パフォーマンスのいる所は専用バイトコード

680 名前:仕様書無しさん mailto:sage [2009/04/04(土) 16:08:38 ]
混在させるとロクなことにならん気がするが・・・

681 名前:仕様書無しさん mailto:sage [2009/04/04(土) 16:11:00 ]
スクリプトって何のために導入してるの?
コンパイルや再起動が邪魔な状況ってイメージなんだけど
そんなに必要な状況が思いつかない。

682 名前:仕様書無しさん mailto:sage [2009/04/04(土) 16:11:18 ]
>>678みたいな馬鹿にはプログラム書かせないことだね
どうしても仕事させたいなら、絶対に外に出さないどうでもいいツールとかやらせとけ

683 名前:仕様書無しさん mailto:sage [2009/04/04(土) 16:33:14 ]
なんか悔しかったみたいだねw

684 名前:仕様書無しさん [2009/04/04(土) 17:05:52 ]
>>681
RPGとかスクリプト無しでどうやって作れと。

685 名前:仕様書無しさん mailto:sage [2009/04/04(土) 17:13:38 ]
あ、ごめん、インタプリタ形式のスクリプトの話限定。

686 名前:仕様書無しさん [2009/04/04(土) 17:46:42 ]
ゲームデザイナーがゲーム作れるようにする為。




687 名前:仕様書無しさん mailto:sage [2009/04/04(土) 17:50:22 ]
ビルド環境なしにってこと?
ビルド環境あればできないことはないよね。
またはビルドをする時間がもったいないくらいトライ&エラーが必要なもの?

688 名前:仕様書無しさん mailto:sage [2009/04/04(土) 18:01:10 ]
全員分のビルド環境用意できるハードなんて限定されんだろ
あったとしてもいちいちビルドが必要とか時間の無駄

689 名前:仕様書無しさん mailto:sage [2009/04/04(土) 18:03:06 ]
デザインリソースすら再起動なしに読み込んで欲しいくらいなのに
スクリプト変えたくらいでビルドしてたらやってらんない

690 名前:仕様書無しさん mailto:sage [2009/04/04(土) 18:10:29 ]
でもデバッグ環境とかちゃんと整えないと返ってはまると思う。
簡単なスクリプトなら機能を限定してテキストファイルとかの方が安全じゃないか?

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
無いよ
本当は業務系みたいに全員PG作戦のがいいに決まってるだろ
少なくともスクリプトと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 ]
X68のアセンブラよりペンティアムマシンのBASICのが速いんじゃね?とか90年代に考えていたのからすると
もやはマッハすぎて目に見えないスピードだ。

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 ]
なんかあのスレから波及してるが
職場で俺々システム押し付けてくるおっさんでもいるのか?
はやめにはずしたほうがいいぞ
奴等は自分しか面倒みれないシステムをゲームに組み込んで
自分の居場所を作ろうとするからな

マジで邪魔でうぜぇ
俺のところでも去年大喧嘩になってやっと無意味である
という結論だしてタスク馬鹿にトドメさしてやった
あのシステムグローバル変数常用になるから
散々プロジェクトバグらせてまた同じこと繰り返そうとするから
みんなで集中砲火したらやっと諦めやがった
壷のあのスレ会社の延長になってたなw

明らかにプロジェクトでバグ数違う(桁がw)のに誰が使うかっての

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の限界にいどんだんだからいいじゃねぇーかw そこそこ売れてるし。

742 名前:仕様書無しさん mailto:sage [2009/04/07(火) 23:29:37 ]
メモリのコンパクションはやるやらないは別として理解できるんだが、
プログラムまで再配置の対象にするのってどういう状況?
プログラムは通常連続したアドレスに一気に配置されると思うんだけど、
メモリきついと細かくモジュールに分けて入れ替えたりするの?

743 名前:仕様書無しさん mailto:sage [2009/04/07(火) 23:49:50 ]
オーバーレイの話であれば、メモリ稼ぐための常套手段だな

ドラクエにたとえると、タイトル・ダンジョン・町・フィールド・バトル・エンディングといった大まかな区分において
そこでしか使わない処理があれば、それをモジュールにして
必要なときだけ展開するようにするわけだ

特別難しいこともないし、気軽に実装できる
まあ稀に、モジュール同士で呼び合うような処理作ってはまる奴は居るがw

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 ]
やっぱお前らの会社も脱箱化が進んでんの?






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<193KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef