OOとゲームプログラミング Role2

1 ：名前は開発中のものです。：03/10/30 05:07 ID:C9mKyhbZ

OOをどのように用いれば美しいゲームプログラミングを
行うことが出来るか語り合うスレです。

単なるC++でのクラスの書き方から設計やパターンまで
守備範囲広し

OOとゲームプログラミング
http://pc2.2ch.net/test/read.cgi/gamedev/1005144931/

参考スレ:
オブジェクト指向の説明について 2ループ目
http://pc2.2ch.net/test/read.cgi/tech/1064295567/
【OO?】オブジェクトオリエンテッド総合【非OO？】
http://pc2.2ch.net/test/read.cgi/tech/1041658161/
OOPの次はAOPだそうですね？
http://pc2.2ch.net/test/read.cgi/tech/1004962559/
【XP】 Agile Process 【UP】
http://pc2.2ch.net/test/read.cgi/tech/1032882847/

2 ：名前は開発中のものです。：03/10/30 05:12 ID:C9mKyhbZ

略語一覧
　OO オブジェクト指向
　OOP オブジェクト指向プログラミング
　OOPL オブジェクト指向プログラミング言語
　OOA オブジェクト指向分析
　OOD オブジェクト指向設計

別にOOPLでなくとも、OOPはできます

番外
　AOP アスペクト指向プログラミング
　　　平たく言うと継承よりも集約重視のプログラミング

3 ：名前は開発中のものです。：03/10/30 09:07 ID:rduyZy7M

>>1
ＯＯカレー

4 ：名前は開発中のものです。：03/10/30 14:41 ID:geh2FZdf

前スレ>>999
>実装とインターフェースをごっちゃにしちゃだめですよ。

しちゃいないって。

ファイルデスクリプタは、FILE*の「実装」ではない。
これらの関係は、「デリゲーション」で説明するのが普通だろうね。

あぁ、インタフェース的に多態でないなんて事言って無いからね。

5 ：名前は開発中のものです。：03/10/30 14:57 ID:iFPdCFqc

FILE *fp = fdopen (fd, "r");

6 ：前951：03/10/30 15:26 ID:jvy/MCcz

>>1乙！

>>（前スレ989）
http://pc2.2ch.net/test/read.cgi/gamedev/1005144931/989
> ゲームルールとして単純でも例えば思考ルーチンを作る事を考えると分析にも
> 意味はあると思うっす。

現実のゲームからオブジェクトをモデリングする際、コンピュータゲーム特有の要素
（思考ルーチン等）を織り込むために、やはり分析は必要ってことね。指摘サンクス！

> 検証の意味でも分析が不要ってことは無い、かな。
検証は簡単な実装で済まそうっていうのはやはり横着すぎたかな（ｗ
精進します……

7 ：名前は開発中のものです。：03/10/30 17:32 ID:HRKPXk9R

OOPLの発祥がシミュレーション言語だから、ゲームとは相性が
いいはずだ、ってのは色んなところでよく聞く。

でもイベントドリブンだと具合が悪いから、Taskシステムみたいな
自立行動のためのフレームワークがあるんだろうな。

とTaskシステムを見た感想。

8 ：名前は開発中のものです。：03/10/30 17:38 ID:C9mKyhbZ

> 前スレ997
http://pc2.2ch.net/test/read.cgi/gamedev/1005144931/997
ああ、そか、漏れは多態性＝同一のインターフェースで異なる挙動、だけでなく、
さらに挙動を変えるための仕組みも持つもの、と思ってたけど、よくよく考えたら
同一のインターフェースで異なる挙動さえすればそれは多態性だね
FILE*系は委譲の仕組みがiolib実装者次第で、ユーザーに公開されてないから、
あんまり多態というイメージがなかったけども

用語の定義を勘違いしていた

9 ：名前は開発中のものです。：03/10/30 18:00 ID:HRKPXk9R

>>前スレ989
ん？FILE*は継承の概念はふくんでんじゃね？fseekで、シークできないデバイスの
場合の動作は未定義なところとかさ。
まぁ分かりにくいから不適格、といわれればそれまでなんだが。

10 ：名前は開発中のものです。：03/10/30 18:01 ID:geh2FZdf

でも「格好のサンプル」では無いな…

11 ：名前は開発中のものです。：03/10/30 20:45 ID:C9mKyhbZ

>>9
単にfseekでシークできないデバイスの場合の動作は未定義というだけなら
それは多態性を示してはいても継承が使われているとはいえないんでは

でも、FILE構造体の中にvoid *baseなんてメンバが大抵どの実装でもあるね
多分、これ、実装詳細のための何らかのデータ構造をさしているんだとおもうけど
これも継承といえば、継承かｗ
標準出力とファイル入出力は、baseを挿げ替えることでインターフェース継承して
別クラスに派生したもの、といえるかも

12 ：名前は開発中のものです。：03/10/30 20:51 ID:geh2FZdf

まぁ、実際にはfdの番号が違うだけかもしれんけどな。
(少なくともUnix系はそうのはず。)

13 ：名前は開発中のものです。：03/10/30 21:03 ID:geh2FZdf

＞でも、FILE構造体の中にvoid *baseなんてメンバが大抵どの実装でもあるね
あと、たいていは↓なんて関数ポインタもあって、もうまったくの抽象クラス。
int (*_close)(void *);
int (*_read) (void *, char *, int);
fpos_t (*_seek) (void *, fpos_t, int);
int (*_write)(void *, const char *, int);

baseは、実装クラスの残りのメンバ(もしくはthis)かな。

14 ：名前は開発中のものです。：03/10/31 00:30 ID:e1sQ1Ihl

>>12 >>13
なるほど、そういう構造になってるのか～

OOPLでなくともOOPはできるといういい証左だけど、
やっぱOOPやるならOOPL使った方が楽だし安全と思う反面
使うOOPLの思想に縛られるのも確かなんだよな～

15 ：とむ ◆0MTMwDpCZo ：03/10/31 00:42 ID:PP3YY8Gp

ところで、C++とJAVA以外のOOPLを現場で使っているゲームプログラマはどれだけ
いるのでしょうか？

16 ：名前は開発中のものです。：03/10/31 07:58 ID:j0+9rBYe

MacOS XならObjectiveCが。。。？
いや、「現場」じゃないかもしれないが。

17 ：名前は開発中のものです。：03/10/31 20:12 ID:e1sQ1Ihl

Rubyは周辺ツール製作に活用してるよ。

18 ：とむ ◆0MTMwDpCZo ：03/11/01 04:14 ID:Se3pWJ82

そりゃまあ、サブツールならRubyはおろかPerl、VC+MFC、VB、シェルスクリプト、
Excelのスクリプト、その他なんでもかんでも使うでしょうけどね…。

19 ：名前は開発中のものです。：03/11/01 06:20 ID:L4Poshse

今までCで物理の数値計算しかやったことなかったけど、
C++の勉強がてら、前スレの最初の方で紹介されてたタスクシステムを書いてみた。
結構たのすぃかも…。食わず嫌いせずに、もうちょっとC++の勉強してみよっと。

20 ：名前は開発中のものです。：03/11/01 10:50 ID:G9FGjVhP

>>18
JavaScript系は結構使われてるんじゃないかな？OO的に使われているかどうかはともかく。
ブラウザのJavaScript、FLASHのアクションスクリプトもそうだよね。

というか他に有名な(使えそうな)OOPLってなによ？
・ObjectivePascal(Delphi)はいるかもしれん。
・C#は？MSのテラリウムがゲームといえるなら、使われてる。
・Smalltaklは使われて無さそうだな。
・Eiffelは？全然知らない。
・CLOSは？そもそもまともな実装あるのか？
・Satherは？いないだろう…
・D言語は？まだ出来たばかり。
・Dylanは？知ってる？
・OCamlは？ゲームに関数が多言語(+OO)を使おうというチャレンジャーは･･･いないか…
・LuaがOOPLだといえるなら、ゲーム内のスクリプト言語として使われてる。
・Pythonは、ゲーム内のスクリプト言語として(コンシューマでも)使用実績があるらしい。
・Simula、Modula-3。。。古すぎ？

21 ：とむ ◆0MTMwDpCZo ：03/11/01 11:10 ID:Se3pWJ82

>>20
JavaScriptってOOPLだっけ…？
と調べてみたら、「オブジェクトベース」とだけ書かれていて、OOPLじゃなさそうな雰囲気
ですね。
もし、「オブジェクトのプロパティなどを記述する」という意味でJavaScriptがOOPLならば、
DirectorのLingoなどもOOPLと言えるのでは（これなら現場で使われている）。

22 ：名前は開発中のものです。：03/11/01 11:31 ID:G9FGjVhP

>>21
いんや、クラスも作れるし、継承も(限定的だが)出来るんで、
立派なオブジェクト指向言語だよ。
Lingoは言語仕様を知らないのでなんともいえない。

23 ：とむ ◆0MTMwDpCZo ：03/11/01 15:34 ID:Se3pWJ82

>>22
そうなんだ。
私の手元にあるリファレンスだと、ホームページ作成用のちょっとした用途に使うような
事しか書いてなくて、クラス云々の説明はなかったから、知らなかった。立派なOOPL
なんだ。

24 ：名前は開発中のものです。：03/11/01 15:54 ID:G9FGjVhP

オブジェクト指向プログラム言語としてのJavaScript
http://www.tokumaru.org/JavaScript/

JavaScriptによるオブジェクト指向プログラミング
http://member.nifty.ne.jp/masarl/article/js-oop.html

この辺を参考にすべし。

25 ：名前は開発中のものです。：03/11/01 15:58 ID:G9FGjVhP

あとLingoについてもこんな記述がある。

lingo オブジェクト指向 1
http://www.idd.tamabi.ac.jp/studio5/media-art/prog_notes/lingo10.htm

26 ：とむ ◆0MTMwDpCZo ：03/11/05 06:38 ID:5i3oruPd

>>24
へええ…ほんとにnewでオブジェクト生成とか出来るんだね。
全然知らなかった。「前のページに戻る」とかに毛が生えたくらいの言語かと
思ってた（笑）。

27 ：名前は開発中のものです。：03/11/18 16:57 ID:LezQ0S5x

C++の文法や、DirectXなどの描画処理などはある程度できるようになったのですが、
いざ何か簡単なゲームを作ろうとして、問題領域クラスや描画クラス、入力クラス(MVC?)の関わりなんかを考えると、途端に手詰まりしてしまいます。
…かと言ってグローバルな領域にオブジェクトや関数を記述していくというのも、どうもスッキリしません。というか生理的に受け付けなくなってしまいました。
こういう問題領域の分析/設計というものには定石となるものがあるのでしょうか？（ゲームプログラミングに限って）
また、皆さんはどうやってこのような技術を身に付けてこられたのでしょうか。
何かシンプルなフレームワークなど、参考になる情報などがあればご教授願いたいのですが…。

早くゲームが作りたい…。

28 ：名前は開発中のものです。：03/11/18 17:12 ID:a6Vblm36

グローバルオブジェクト作れよ。
プラットフォームクラスとかゲームシステムクラスとか、シーンルートとか。

29 ：名前は開発中のものです。：03/11/18 17:15 ID:QThZQJ4r

>>27
とりあえずどう行き詰ったのさ？

「ゲーム作りで学ぶJavaクラス設計入門」なんていう本があるけど、
俺は読んだこと無いからどう書いてあるかは知らない。

30 ：名前は開発中のものです。：03/11/18 18:21 ID:f4lQn/J1

>>27
オレのレスかと思った。すんごいよく分かるわ、その気持ち。

MVCったって、結局WindowsだとVとCは
一緒にした方が分かりやすいんだよなぁ。
結局、メイン処理として、あまりにでかすぎる
Mediator見たいのができちまってる

31 ：名前は開発中のものです。：03/11/18 18:39 ID:QThZQJ4r

ゲームだと、UIライブラリ使わない限りVとCがほぼ完全に分離してるから楽だね。
そのかわり、VとMが密接に絡んでるからどの編までをMに含めるのかが難しいかも？

どっちにしろ、VもCも構造的にはそんなに複雑じゃないので、Mが巨大化するのは
当然かもね。一枚岩になっちゃうのは別問題だけど…

32 ：27：03/11/19 01:01 ID:J0Aubu2w

言語とかAPI覚えるために左脳使いすぎて、右脳を使って考える事ができなくなってしまった27です。

>>28
プラットフォームクラス→ウィンドウの生成、DirectXの初期化などで
ゲームシーンクラス、シーンルートというのがパッと思い浮かばないのですが、タスクシステムのようなものですか？（タスク書いた事ありませんけど）
それらのグローバルオブジェクトをエントリポイントから呼んであげる、という感じでしょうか？うーむ。

>>29
「自機を表示して入力によって上下左右に動かしなさい」と言われても
どうすればいいんだ　という状態です…。いや、つらつらと書いていくだけならできるんですけど
局所的にGetAsyncKeyState()なんかで判定して、staticなローカル変数を増減してあげて、
D3DXMatrixPerspectiveFovLHの第二引数(画角)に渡してズームイン/アウトとかしかできないのです(´・ω・`)

>>30
わかってもらえますか！嬉しいような、悲しいような。
Mediator……デザパタも勉強しなきゃ…。UMLもクラス図くらいしか読めないし…。あ、今からやるならUML2.0のほうがいいかな。
んー、自分はどうも何かがごっそり抜けている気がします。結局は、経験を積んで「自分でよく考えてみる」って事なんでしょうかね…。

皆さんレスありがとうございました。参考にさせてもらいます。
そして長文駄文失礼しました…寝る！ヽ(`Д´)ﾉ

33 ：名前は開発中のものです。：03/11/20 01:09 ID:+szHshA9

Boostいいよ。とだけ言っておく。

34 ：名前は開発中のものです。：03/11/20 05:23 ID:wJEEkq7n

この手の問題にboostだlokiだstlを持ち出すのはどうかと
あれらはオブジェクト指向しているといっても、
フレームワークではなくただの道具であって
プログラム自体ののOODやOOPに直接関係あるものではないし。

Javaを使っているからオブジェクト指向だと言っているのと変わらん。

35 ：名前は開発中のものです。：03/11/20 07:12 ID:eRddGNf2

そのうち「boost厨ウゼー」と言われるようになるに8G。ドラクエなら薬草だって買える。

36 ：名前は開発中のものです。：03/11/20 11:59 ID:qMcmZWw4

今ゲームにＭＶＣ的枠組みを適用してしまったが後悔している。
ゲームは一般的にはＶが最終的な出力となるシステムだから、ＭとＶの間に明確な線がひきにくい。
元来ゲームのＭはＶに癒着している。これを無理矢理引き剥がそうとすれば、無意味な努力を強いられる。

たとえば格闘ゲームの一つ一つの技という概念を考えてみるとする。
当り判定の範囲が何コマ目にどの位置に発生するかなどといった情報はＭの範疇だろう、
その時表示される画像、もしくはモデルのモーションデータなどはＶの範疇だろう
だが片方だけが独立して変更されることがあるだろうか？
このデータはお互いがお互いに依存している。ＭとＶとに分け隔てたところで意味がない。

多分ゲームシステムは、無理にＯＯ的なデザインに固執すること、
つまり、ゲームのルールそのものを静的なシステムのデザインとしてどう表現するか、
みたいな考えで進むのは間違いで、
まず、どこまでの独自スクリプトを用意するか、どういうデータをつくるか、
そのための解釈機構としてのシステムを設計していく、という進み方が良いのではないかと思う。
実践はしてないけど。

37 ：の：03/11/20 12:13 ID:dZfNDP9i

3Dテトリスを作りたいのですがDirectX8.0です。
どなたか知っておられる方がいれば教えてください

38 ：名前は開発中のものです。：03/11/20 13:22 ID:Ye+SEMtz

何を知っている人を探しているんだろう？

39 ：名前は開発中のものです。：03/11/20 15:30 ID:UU+R17Y2

テトリスのアイデアの作者はアメリカに移住したよ。

40 ：の：03/11/20 16:07 ID:KINLhsb5

ブロックの表示の仕方を教えていただきたいです

41 ：名前は開発中のものです。：03/11/20 16:25 ID:IUbBxp8Z

頂点と色を適当に設定してレンダリングすれば完了。

42 ：名前は開発中のものです。：03/11/20 17:07 ID:+ABtc8dV

OOじゃないし…

43 ：名前は開発中のものです。：03/11/20 17:16 ID:BfaFzNIy

初心者はOOと言われてパッと来ないよ。

44 ：名前は開発中のものです。：03/11/20 18:40 ID:+ABtc8dV

とか言いつつ誰もOOの意味を書かないのね…

45 ：名前は開発中のものです。：03/11/20 20:57 ID:l+8HMOyY

　(OO)　＜ OO星人登場！

46 ：名前は開発中のものです。：03/11/20 21:12 ID:ehwn2Wff

>>37
メンボスレで人材募集してた人？
テクノスジャパソにマークされないようにな。

47 ：名前は開発中のものです。：03/11/22 21:04 ID:A3t+9Ynx

>>45
やべっ、にげろっ

48 ：名前は開発中のものです。：03/11/23 21:28 ID:3izt0hD0

>>36
ゲームというプログラムをModelをViewに分けた場合、依存関係はModel->Viewだ。
Modelが自発的に動くのだから、Modelを観測するView(View->Model)という考
え方は不自然。
このあたりからゲームにMVCパターンを使うことに無理があることがわかる。
まぁここは、MVCパターンをを導入して痛い目にあった貴方は解っていることだろう。

しかしだ。

ゲームにMVCパターンが適用できないからといって、ModelをViewを分けること
の有用性を否定するのはおかしい。
ModelはたしかにViewに癒着している。しかし、ViewがModelに依存する必要は、必ず
しもないわけだ。（格闘ゲーム用のView、RPG用のView、といった感じにはなるだろう
が、それはModelに依存しているわけではない）

独自スクリプトを用意する等の記述から見るに（独自スクリプトを用意＝独自スクリプト
でModelを記述する）、貴方はそのことはわかっているはずなのだが…。
貴方がOOの外だと思っている場所は、まだOOの中だ。

49 ：名前は開発中のものです。：03/11/23 21:34 ID:FVc+pu0V

そうやね。どこまでをModelに含めるか、または、どこまでをViewに含めるかという
問題があるだけで、MVC構造が適用できないと言うわけではない。

「MVCが有効であるための条件」とかをOOの教科書でも見て再確認したほうがいいか。

50 ：名前は開発中のものです。：03/11/23 22:47 ID:UlGt3ZDM

＞ゲームというプログラムをModelをViewに分けた場合、依存関係はModel->Viewだ。
きめつけはよくないぞ。理由を。原因を。根拠を書け。

51 ：名前は開発中のものです。：03/11/23 22:59 ID:4fUeb/f0

>>50
いや、どっちかっていうとゲームのプログラムでは君の方が特殊だと思われるので
View->Modelになる理由を書いてくれ。

52 ：48：03/11/23 23:56 ID:MspClkU4

>>50

>>48
>Modelが自発的に動くのだから、Modelを観測するView(View->Model)という考
>え方は不自然。

文字が読めないか。そうか。

53 ：名前は開発中のものです。：03/11/24 01:17 ID:AkbqUxd1

「モデルが自発的に動く」とはどういう意味なのですか？

54 ：名前は開発中のものです。：03/11/24 01:27 ID:5Ww60Vn+

俺もわからんので説明きぼん。

55 ：とむ ◆0MTMwDpCZo ：03/11/24 01:35 ID:QL7TCmKC

というか…
これはゲームに限らないんだけど、MVCで分けたら、常にViewはModelに依存してる
けど、ModelはViewに依存してないわけだよね（ハードの制約とはともかく）。

そういう、もうゲームともOOとも関係ない話なんじゃないかなあ？

56 ：名前は開発中のものです。：03/11/24 01:41 ID:fe0QjvTd

んで、ゲームだとモデルだけ変更する、ビューだけ変更するってことはなくて、
大概両方の変更がセットになる。だから、モデルにビューの機能の大半を
入れてしまったほうが楽、とかじゃない？

ビューの機能は2Dで言えばプライオリティ制御くらい？
3Dでグラフィックエンジンとか作る場合にどうなるかは知らん。

57 ：名前は開発中のものです。：03/11/24 03:24 ID:pOV6lZsf

>>56
>んで、ゲームだとモデルだけ変更する、ビューだけ変更するってことはなくて、
思いついたもの。
フルスクリーンとウィンドウの切り替えとか、
roguelikeでASCIIとタイルの切り替えとか。

58 ：48：03/11/24 05:07 ID:J1gmJTJB

ようするにゲームの場合、Modelが自分の表示方法を知っていたほうが、都合がいい、
ということだ。オブジェクトが自己完結したモノとして動きえるという意味で、自発的に
動くと表現した。まぁいいたいことは>>56と同じなんだが。

>>55
MVCパターンを離れてくれ。MVCパターン上で考えたら、確かに貴方の言う通りだろうが、
私のいいたいことは違う。私はただ単に”見た目”と”中身”の分離の話をしている
だけだ。

ゲームの場合再利用するものが”中身”ではなく”見た目”であり、開発中”中身”の変更
をすることは多々有る。そのとき、”中身”の変更は”見た目”の変更につながり、”見た目”
が”中身”に依存している場合、変更箇所が増え、分散してしまう。一方、開発途中で複数
の”見た目”が必要になる場面はそうそうない。
だから私は”中身”が”見た目”に依存しているべきだと主張している。”見た目”が”中身”
に依存していると、ゲームにおいては疎結合性が低く、メリットよりもデメリットのほう
が大きいのだ。

ViewがModelに依存する意味も考えずに、
>そういう、もうゲームともOOとも関係ない話なんじゃないかなあ？
と断ずるのは、あまりにも軽率ではないか。

59 ：48：03/11/24 05:08 ID:J1gmJTJB

訂正

ViewがModelに依存する意味も考えずに、
↓
ModelがViewに依存する意味も考えずに、

寝起きはダメだな…

60 ：名前は開発中のものです。：03/11/24 08:32 ID:AkbqUxd1

>>48
とにかく、いちいち人を貶すのはよせや。

ところで>>58では何か多々有ったり、そうそうなかったりするらしいけれども、
例を挙げて説明したほうが皆分かりやすいと思う。挙げてもらえないだろうか。
例えばどういうことが多々有りそうだというのか。
どういうことはそうそうなさそうだというのか。

61 ：名前は開発中のものです。：03/11/24 09:55 ID:Isa4iBHT

別に貶してはいないと思うけど。
みんなコピペ荒らし時代の後遺症が残ってるのかな・・・。

viewがmodelに依存していると
「地面を歩いてくる踏みつけられる敵」インスタンスの見え方は「常にクリボー」なのに対し
modelがviewに依存していると
「地面を歩いてくる踏みつけられる敵」インスタンスはトゲゾーにもパタパタにも見せられる。

こういう事だろう。違うかな・・・？

62 ：48：03/11/24 10:11 ID:ebyA9A4u

>>60
>とにかく、いちいち人を貶すのはよせや。
貶す？どのレスで、誰を貶したのか。確かに>>50は貶したが。

>ところで>>58では何か多々有ったり、そうそうなかったりするらしいけれども、
>例を挙げて説明したほうが皆分かりやすいと思う。挙げてもらえないだろうか。
多々有る→ゲームの内容全般の変更。特に、新規に起こす場合は”作ってみないとわから
ない”状態なので、変更は更に激しくなる。

そうそうない→見た目の極端な変更。3Dアクション→斜め見下ろし型2Dアクション等。

言い忘れていたが、View->Modelの依存関係のほうがよい場合もあるし（ステータスウイン
ドウ等）、それは否定しないので、間違いの無き様。

63 ：名前は開発中のものです。：03/11/24 10:34 ID:AkbqUxd1

>>62
すると、キャラクターのグラフィックス、モデル、テクスチャ等は
藻舞さんの言うところの”見た目”には属さないんだね。

64 ：名前は開発中のものです。：03/11/24 10:54 ID:ebyA9A4u

>>61
不正確。依存関係の違いは、
enemy->render( renderer );　//Model->View
renderer->render( enemy ); //View->Model
という違いしかない。

実質的な違いは、前者は実装が容易に想像がつくことに対し、後者はどのよ
うな実装にするか悩んでしまうことにある。
RTTIを利用してswitchしてるのか、Bridgeパターンを利用して描画とAIを分離
しているのか、はたまた内部でenemy->renderをしているのか。
しかも、どんなスマートな実装をしても、前者に比べたら冗長になってしまう。
さらに、冗長性というデメリットを犯してまで獲得した拡張性は、ゲームという
特殊なプログラムでは無意味。

65 ：48：03/11/24 11:05 ID:ebyA9A4u

>>63
貴方は煽りなのか？さっきからずっとageてる上に的外れなレスをするとは。

なんで設計の話をしているのにリソースの話が出てくるんだ。頭が痛くなる。
貴方はリソースが少し変更されただけで、Viewの大部分を書き直すような
腐ったコードを書くのか？

頼むからもう少し考えて発言してくれ。疲れる。

66 ：名前は開発中のものです。：03/11/24 11:15 ID:0D7N+nPX

>>64
Visitor使うに決まってるだろ。ﾄｰｼﾛは帰れよ。

67 ：名前は開発中のものです。：03/11/24 11:20 ID:fe0QjvTd

MMORPGなんかは、MとVが完全に分かれてる例になるかな？
なんてったって、物理的に分かれてるし！

68 ：名前は開発中のものです。：03/11/24 11:40 ID:AkbqUxd1

>>65
とりあえず、漏れや他人のことをいちいち妄想して、
決め付けるような文を書かないでくれないか。
漏れは決して藻舞いが妄想するような人間ではないから。たのむよ。

設計の話をしてるのにリソースの話をしてはいけないかな？
つまりリソースをどこの配下に収めるかという設計の話だよ。

君の方針ではグラフィックなどのデータを”見た目”の管理下ではなく
”中身”の管理下に置くとするのだね、と確認をとりたいだけなんだけど…？

69 ：48：03/11/24 11:54 ID:ebyA9A4u

>>66
後者の実装方法はしたことないから、これに関して確かに私は素人だ。
RTTIVisitorを利用するのが普通なのか。

だが、描画に必要な情報はどうするのだろう。ｚオーダーや、アニメーションの際の
時間等だ。
Visitされる側のオブジェクトにそのままの情報を格納するのか？それともオブジェ
クトに汎用コンテナを用意するのか？

前者だとVisitorの利点がほぼスポイルされるされるし、後者を用いるのはあまり感心
できない。後者を用いるくらいなら、Bridgeを用いたほうがいくらかマシだろう。

有効な方法があるのだろうが、私には思いつかない…

70 ：48：03/11/24 12:07 ID:ebyA9A4u

>>68
すまない。あの文からは、私からリソースの管理はViewをいう発言を引き出して、リソース
は頻繁に変更されるから、Viewも頻繁に変更されるじゃないか、という詭弁に持っていこう
としか見えなかったのでね。

それと、少しでも煽りと思われる可能性を減らしたいならば、無意味なageはやめてくれ。

で、質問の答えなんだが、リソースの管理を”リソースを適切にメモリ上へロード、アンロー
ドすること”と定義するならば、それは”見た目”が行う。私はゲームを仮想世界の構築
とみているので、ゴーストたる”中身”が、”見た目”の実装事項であるリソースの管理を
行うのは不自然だろうから。

71 ：名前は開発中のものです。：03/11/24 12:36 ID:fe0QjvTd

ageること自体は別に悪いことじゃないと思うが…
荒れてる板じゃないんだし。

72 ：名前は開発中のものです。：03/11/24 12:46 ID:ebyA9A4u

>>71

>>70
>少しでも煽りと思われる可能性を減らしたいならば

73 ：名前は開発中のものです。：03/11/24 12:51 ID:fe0QjvTd

それが妄想って言われてるんでしょうな。まぁ、妄想するのも自由だけどさ・・・

74 ：名前は開発中のものです。：03/11/24 14:03 ID:AkbqUxd1

>>70
漏れは逆の答えがかえってくると思っていたよ。ますます混乱してしまった。

も一つ確認させておくれ。
キャラクタの座標データはゲームのルールを駆動するためにも、
レンダリングをするためにも必要な、見た目と中身の中間に位置するデータであり、
必然的に、このデータを管轄する側が、他方から依存される構造にならざるを得ない。

中身が見た目に依存するという方針をとる場合、
当然見た目が座標を管轄することになると予想するけど、
それでいいのか。

75 ：名前は開発中のものです。：03/11/24 14:22 ID:TnmocILl

48の意図って本人が自信満々なほどには全然伝わってないよな。
俺もはっきり言ってわからないんだが。

>>36とか>>56とかあたりでケリがついてるように思える。

76 ：48：03/11/24 15:28 ID:rm0Tz7BJ

>>74
否。座標を管理すべきは中身。

>必然的に、このデータを管轄する側が、他方から依存される構造にならざるを得ない。
依存しているのは座標情報だけであり、オブジェクトではない。オブジェクトへの依存とい
う強固な結合をしなくても、座標情報だけを渡せばすむ。よってこれはおかしい。

そして、座標情報を管理する責務が中身にあることは、火を見るより明らかだろう。
中身→見た目という依存関係では、見た目が座標情報の同期をとることはできないし、
操作による座標変更を受け付けるのは、中身だからだ。

ところで、これを聞いて何がしたいんだ？

>>75
そうだな。別に自信満々ではないんだが、私もそう思う。

ゲームにMVCパターンを適用するのは不自然なのは当然だが、ModelとViewを
分ける有用性を否定する理由にならない、ただそれだけを言いたかったんだけどな。

77 ：とむ ◆0MTMwDpCZo ：03/11/24 15:39 ID:QL7TCmKC

ローカル座標データやワールド座標データはモデルに属するが、透視変換のための
マトリクスはビューに属しているものと思われるので、「画面のどこに表示されるか」
という意味の座標はビューが管理していると思われます。
話が噛み合ってないのでは？

78 ：とむ ◆0MTMwDpCZo ：03/11/24 15:41 ID:QL7TCmKC

ああ、ビューが管理していると一元的な話になってしまうか。
とにかく、両方が決定する、と。

そもそも、元は設計の手法のためのMVCなのに、取り入れたばかりに無用な混乱を
招くような人（つまり最初の人）なら、使わなければいいのでは。
せいぜい操作部と表示部を個々のファクターに対して分離しておくくらいのことで十分
でしょ。

79 ：48：03/11/24 15:55 ID:rm0Tz7BJ

>>78

>話が噛み合ってないのでは？
噛み合ってないのか？
とりあえず大元のデータは中身が管理すべき。

>そもそも、元は設計の手法のためのMVCなのに、取り入れたばかりに無用な混乱を
多分反省点から見るに、MVCを導入したのは、プログラマなら少なからず経験のある
例の病気のせいだろう。

”新しいものが銀の弾丸に見える”

…耳が痛い。

#習作としてMVCを導入したのならｽﾏｿ

80 ：名前は開発中のものです。：03/11/24 16:24 ID:AkbqUxd1

>>76
これが依存じゃないっていうんなら藻舞いさんにとっての依存ってなんなの？
中身が見た目に依存する様子を具体的に挙げて解説してもらえないだろうか？

81 ：とむ ◆0MTMwDpCZo ：03/11/24 16:28 ID:WD4h+gBh

うん、やっばり>>48さんの考え方がおかしいよ。

これがMVCの話をしていないのならともかく、MVCの話であれば、Mというのは
「見た目に依存しない本質的な部分」を分離してモデルと呼んでいるわけで、そこで
見た目依存の部分を話し始めたら矛盾が起こる。定義からして違うからね。

もしそれが見た目に依存してるように見えるなら、それは設計段階で「ビュー」に
含めているのがおかしいので、やっぱりモデルの一部だよ。

大体お互い依存しあってるなら分離できないので、MVCなんてアプローチが意味を
持たなくなってしまう。これはゲーム以外でもそうだよ。

82 ：48：03/11/25 05:15 ID:NrgzVwPt

>>80
？私が逆に問いたいぐらいだ…あれを依存というならば、Observerパターンですら相互
依存、分解不可能なほどの強固な結合になるぞ？メッセージによって疎結合度を上げ
る技術、すべてがだ。
なんでview->set_position( pos );で呼び出された側が呼び出し元に依存してるんだ…

私が持っているゲームのメタファーは人形劇。人形使い（中身）が操る操り人形（見た目）
が、舞台（画面）で踊り、劇（ゲーム）を構成する。

人形は自由に操るに足る糸が繋がっているが、だがそれは人形が人形使いの意思を
汲み取って、ひとりでに動いているわけではない。

>>81
>うん、やっばり>>48さんの考え方がおかしいよ。
おかしいに決まっている。私はMVCアーキテクチャパターンの話をしているわけで
はないのに、それを前提に読まれれば、筋が通るものも通らない。
ゲームにMVCを導入するのはそもそもおかしいで終わってる。

>大体お互い依存しあってるなら分離できないので、
お互い依存しあっている、というのは私の発言なのか？これは私の考えに真っ向から
対立しているし、私はそのような発言をした覚えはないのだが、どのレスでそんな
間の抜けた発言をしたのか。

83 ：名前は開発中のものです。：03/11/25 08:05 ID:pJ/rVsUL

そろそろ>>48氏は自分の意思伝達能力を疑ったほうがいいと思うんだが。
理解してる人一人もいないみたいじゃん。私はもうあきらめたけど。

84 ：名前は開発中のものです。：03/11/25 08:12 ID:RzI5zXXR

>>82
これが依存じゃないっていうんなら藻舞いさんにとっての依存ってなんなの？
中身が見た目に依存する様子を具体的に挙げて解説してもらえないだろうか？
喩えじゃなくて。具体的なゲームシステムでの例を挙げて解説しておくれ。

85 ：名前は開発中のものです。：03/11/25 09:34 ID:F1nRu95Q

>>83
私の記述力が低いのか、貴方の理解力が足りないのか、その両方なのか、
誰が証明できる？
本気でそう思っているのならば、どこまで理解したのか、どこから理解で
きないのか、書かねば意味が無いだろう。

>>84

class View{
position _pos;
void set_position(position pos){ _pos=pos; }
};

class Model{
View _v;
position _pos;
void tick(){
/*なにやら処理*/
_v.set_position( _pos );
}
};

もう一度聞くが、これはViewがModelに依存していると、本気で思うのか？
どんな読み方をしても、ModelがViewに依存(Model uses View)しているよ
うにしか見えないが。

86 ：48：03/11/25 09:38 ID:F1nRu95Q

publicを忘れた。まぁそのあたりは頭の中で保管して欲しい…

87 ：名前は開発中のものです。：03/11/25 10:02 ID:u/hzCyCH

大切に保管します。

88 ：48：03/11/25 10:14 ID:F1nRu95Q

詳細な具体例が欲しいならRPGツクールでも触ってくれ…
いや私は触ったことは無いんだが、氾濫しているところを見るに、
Modelの極一部を独自スクリプトで記述するものなのだろう。
必然的に、見た目を操作する、すなわち見た目に依存した
スクリプトが記述されるはずだ。

89 ：48：03/11/25 10:19 ID:F1nRu95Q

大切に保管してくれ :-)

90 ：名前は開発中のものです。：03/11/25 13:31 ID:AqlN+FiO

ちょいまち。「依存」の意味がよくわからん。

>>85のコードだとViewはModelがセットした座標にただ表示されるだけで、
Viewが勝手に動き回った結果をModelが受け取り、処理（あたり判定等）を行うような
構造ではないんだよね？

つまり、48ﾀｿの言う「ModelがViewに依存する」という場合は、
「Modelの振る舞いはViewの振る舞いによって規定される」ということでおｋ？

非ＯＯなＰＧなんであまり高度な会話にはついていけん。
できるだけ口語調でたのむわｗｗｗ
あと、議論が錯綜してきたら言葉の定義も適宜よろｗｗｗｗ

91 ：名前は開発中のものです。：03/11/25 13:49 ID:AqlN+FiO

あと、ゲーム的に言えばModelってのは思考ルーチンや物理演算、当たり判定、ゲームロジック部分など。
Viewはグラフィックやサウンド、ファイルアクセスに関する部分だよね。
となるとControllerはタスクシステムのような処理と思っていいのかな？

ゲームでMVCなつくりをする場合、どうしてもModelとViewが複雑に絡み合うケースが多いので
Controllerの部分をいかに作るかがキモになってくるのかも。

って、なんか当然のこと言ってるな・・・俺

92 ：名前は開発中のものです。：03/11/25 14:18 ID:QjHC9KBW

いわゆるタスクシステムってのは
MとVとCと全部ひっくるめたようなもんじゃないの？
個々の役割はそれぞれ違うけど
表示用の座標や関数（テーブルへのポインタ）持ったり
子タスクを作り出したり、当たり判定に使ったり。

93 ：48：03/11/25 15:07 ID:eHxaMr9z

>>90
依存を一般の意味で捉えていたのか…眩暈がする。
専門用語だから意味くらいは調べてくれ。

>つまり、48ﾀｿの言う「ModelがViewに依存する」という場合は、
>「Modelの振る舞いはViewの振る舞いによって規定される」ということでおｋ？
違う、というより、カプセル化を崩してなにがオブジェクト指向なんだ？

まぁあのコードを見て貴方が納得できたのであれば、おそらくそれが正しいだろう。

>できるだけ口語調でたのむわｗｗｗ
>あと、議論が錯綜してきたら言葉の定義も適宜よろｗｗｗｗ
議論？何時した？今の今まで質疑応答しかしてないが。
それと、口語調とは語尾にｗを複数個つけることを差すのか？

>って、なんか当然のこと言ってるな・・・俺
そうか、>>36まで話を戻したいのか。で、貴方は一体何がしたいんだ？

いい加減MVCアーキテクチャパターンから離れてくれ。MVCパターンは開発の経
緯からしてそもそも、GUIアプリケーションを構築するためのアーキテクチャ
パターンだ。
ゲームに適用するのは不自然と、理由をつけて私は何度も書いた。

ゲームのアーキテクチャにあたるのは、オブジェクトが自立して行動するための
機構、タスクシステムだ。

94 ：名前は開発中のものです。：03/11/25 15:13 ID:eHxaMr9z

>>92
その認識で正しいと思う。ゲームはイベントドリブンではないのだから、
MとVとCに無理やり分けて、Cだと無理に割り当てる意味が無い。

95 ：名前は開発中のものです。：03/11/25 15:41 ID:vBYvQALs

>>94
いい加減に擬似タスク捨てろよ。
時代は変わったんだから。

96 ：名前は開発中のものです。：03/11/25 16:39 ID:h1gSW8KM

あれはあれで便利だよ。
状態遷移＋(擬似)並列処理ってとこかな。OOとは独立な概念かも。
使いすぎるとgotoみたいにﾜｹﾜｶﾗﾝくなるような気もするけどね。

97 ：名前は開発中のものです。：03/11/25 18:30 ID:vIxj3gI5

>>85
依存かどうかはpositionの定義による。
型がmodel::positionなら依存しているし、
独立した型であるのなら依存はしていない。
position型がそのアプリケーション（含ゲーム）において
どういうものかなんてプロジェクトごとに変わるんだし

98 ：48：03/11/25 19:09 ID:PryM6X6d

>>95
オブジェクトが自立駆動するためのシステムというつもりで、タスクシステムと呼んだ。
すべてを統括するオブジェクトが該当オブジェクトを逐次呼び出そうが、該当オブジェ
クトがタイマーイベントを受け取ろうが、同じ事だ。
そうカリカリするな。

まぁもし貴方が、ファイバーを気軽に使える環境に在るならば、上の意味でのタスクシ
ステムを、過去の遺物と一蹴するのも頷けるがな。

>>97
>依存かどうかはpositionの定義による。
そうだな。だが、Model→Viewという依存関係にしようとしているのに、型をmodel::position
にするような開発者は、三日で路頭に迷う事になるだろう:-p

型が絶対にmodel::positionではないことくらい、少し考えれば解るだろうに。
もう少し考えてから発言してくれ。

99 ：名前は開発中のものです。：03/11/25 19:41 ID:vIxj3gI5

>Model→Viewという依存関係にしようとしているのに
目的と手段が逆になってるな
ある現象を分析してModel->Viewにするか
View->Modelにするか決定するのに
Model->Viewという前提だとかいうんじゃあ話にならない。

100 ：名前は開発中のものです。：03/11/25 22:29 ID:RzI5zXXR

>>85
＞もう一度聞くが、これはViewがModelに依存していると、本気で思うのか？
漏れが何かを思ってるだかを勝手に妄想して、
妄想上の漏れを相手に話をするのはやめてくれよ。たのむよ。
漏れは君が勝手に仮定した人格では決してないのだから答えようがないんだよ。

結局ModelがViewに依存する構造（いったいどのようなものか見当もつかないけど）
を採用することが、いかにViewがModelに依存する構造よりも優れているかの主張はないの？
結局のところRPGツクールを触って、藻前様の深淵でエポックメーキングな
アーキテクチャの画期的な優位性を自分のセンスで感じ取ってくれという結論でいいのかよ？

101 ：名前は開発中のものです。：03/11/25 22:50 ID:p9PHIgDx

※ここでサンプルコードを投入してください

102 ：名前は開発中のものです。：03/11/25 22:57 ID:b47pLzot

結局、ここまでの話
＃>>36に>>48がレスしたことから始まる一連の議論（48的には議論ではないらしいが）のコトな。
が、一向に結論めいたことを出せない原因は、そもそも36＆48が
「ゲームにおけるModelとはなにか」、「Viewとは何か」を明確にしまいまま
ダラダラと言い争いだけが続いていることが問題なのだ。

自分の知ってることは相手も知ってるだろうという憶測から
重要な言葉の定義を省くのは怠慢でしかないと思うぞ。

103 ：名前は開発中のものです。：03/11/25 23:02 ID:RzI5zXXR

UMLとかの無理矢理日本語に訳した専門用語をいきなり使ってるのは
よくないんじゃないか？できれば英語かカタカナ英語か「」でくくって。
んでその程度の疎通の行き違いがあったくらいでいちいち目眩とかをおこさない方向で。
漏れはこれからも一般的で曖昧な意味として依存を使うよ。

104 ：名前は開発中のものです。：03/11/25 23:39 ID:RzI5zXXR

>>102
View
映像、画像、音声そのもの、それへの参照や操作そのもの
映像、画像、音声に関連するデバイスやコンテキストやそれへの参照や操作そのもの
映像、画像、音声の出力を目的とするクラス
テクスチャとかメッシュとかスプライトとかビットマップとか
アニメデータとかエフェクトとか

Model
ゲームモデル、ゲーム世界のデータ上での表現
ルール、物理演算、当り判定、セーブとロード、通信管理

（「関連」は一般的な意味でつかいますた）

ちなみに>>36で書いてるように、漏れはこういう境界線の引き方は
ゲームシステムにはそぐわないと考えている。

105 ：名前は開発中のものです。：03/11/25 23:42 ID:vBYvQALs

>>102
いや、ModelとかViewってのは結構みんなわかってると思うよ。
自分の説明が苦しくなると意味を無理やり捻じ曲げるのんだよ。

>>MVCにこだわってる人たち
だいたいこういう設計の話はちょっとでも知識を要求してしまうものを
採用していまう時点でそいつには設計のセンスがない。
ＭＶＣだっけ？これチームのメンバー全員に本気で理解してもらうつもりなの？
できないと思うよ。どんな説明が必要になる？大変な作業だよ。
ここで文章を使ってこれだけ延々と説明をしても誰も設計を統一できない。
もう、使えないっていいきれていいんじゃないの？>MVC

106 ：名前は開発中のものです。：03/11/26 00:00 ID:Hfp/lcva

まず勉強会から！

107 ：とむ ◆0MTMwDpCZo ：03/11/26 00:28 ID:o/89oTRn

>>82
やっぱりあなたがおかしい。

>>36の人が、ゲームにMVCを取り入れて…という話をして、>>48であなたがレスをしている
のに、「私はMVCの話をしているのではない」じゃ話が通らない。
もし最初からMVCの話をしたくないのであれば、>>36さんにレスをつけるべきではなかった。
つけておいて、「私はMVCの話はしていない」じゃおかしいよ。

108 ：名前は開発中のものです。：03/11/26 00:28 ID:zaiKmpRA

>>104の意見はわかる。ただ、自分の考えはこうでつ。

ゲーム画面（仮にアクションゲームを想定）では基本的にキャラ（主人公や敵、弾、障害物など）が独自に処理を行う方が都合が良い。
特に、ユーザーに直接操作されない敵キャラは基本的には自律しつつも、時には他キャラの行動に依存してみたり、時には管理プログラムからの命令に従って
一斉に動いたりしているわけで、しかもキャラの行動に伴ってサウンドを鳴らしたりゲームの進行にかかわるフラグを操作したりもする・・・。

ようはゲーム内のキャラクタなどのをViewやModelという境界で分けるのではなくて、各キャラごとに個別にMVCパターンを適用し、それらを別のパターンで
統一的に管理するという方法がゲームには向いているのではないか？

あまりOOには詳しくないんで自信なし。間違いはｽﾞﾋﾞｽﾞﾊﾞ指摘してくれいｗ

109 ：108：03/11/26 00:33 ID:zaiKmpRA

ちなみに、俺の言うMVCパターンは
http://www.fuka.info.waseda.ac.jp/~washi/m_html/node7.html
の説明を基にしてまつ。

110 ：名前は開発中のものです。：03/11/26 00:59 ID:ueZRq0X0

>>109
ああ、そもそもMVC自体そんな大したもんじゃねーんだな。
ゲームだと

Model : 内部処理（描画・キー入力以外の処理）
View : 描画処理
Controller : キー入力

だな、また、これ以上のこと（詳細）は表現していない（109のリンク先では）
根本からしてめちゃくちゃあいまいでどうでもいいものだな>MVC

さらに追い討ちをかけるとなんでこうやってわけちゃうのかなぁ。
Javaだからオブジェクト指向じゃないの？
間違いなく処理でわけちゃってるよね、これだと。
オブジェクト指向がわかってなさげな人間の考えた糞アーキテクチャに見えるのは俺だけかなぁ。
ﾏｯ､ﾎﾝﾆﾝ､ｿﾚﾃﾞｲｲﾅﾗｲｲﾝｼﾞｬﾈｰﾉ?
(　´∀｀)ｱﾊﾊﾊﾊ

111 ：とむ ◆0MTMwDpCZo ：03/11/26 01:04 ID:o/89oTRn

私もそう思います。
処理による区分は非OOの考えに属するものじゃないかな、と。
「処理そのものをオブジェクト化しているからOOだ！」と言い張るならそれも良し、ですが。

…というわけで、このスレでMVCパターンなどを延々語る価値があるのかどうか疑問です。

112 ：名前は開発中のものです。：03/11/26 01:07 ID:gp+Vdr2Y

十分ネタになったしなってるじゃないか！
いちいちジャッジしてんじゃねぇ

113 ：108：03/11/26 01:23 ID:zaiKmpRA

やっぱGUIって結構OOにとって鬼門なような気が。
GUIの塊であるゲームもやはり・・・
＃脱線するけど、XPの単体テストでもGUI部分に対するテストの自動化＆テストファーストについてはお手上げっぽいしね。

114 ：名前は開発中のものです。：03/11/26 02:12 ID:FDG9W9vy

結局何が争点なのかｻﾊﾟｰﾘわからんのが面白いというかなんというか。

まあ、Document-ViewアーキテクチャとかMVCとかって
イベントドリブンのGUIアプリケーションで内部処理と外観の処理は
まあ普通分けるでしょうってとこから生まれた妖怪みたいなものじゃないかね。
ごく自然に実践するもではあっても、教条主義的に守るべきものではないだろうな。

ゲームについては>>110程度で十分だと思ー。

115 ：名前は開発中のものです。：03/11/26 02:45 ID:dE1vbEz6

自分はViewのことをModelからの変更の通知を受けてそれを反映するオブジェクトの
ことだと思ってたんだけど、このスレ読んでみるとどうも勘違いしてたみたいだな

116 ：とむ ◆0MTMwDpCZo ：03/11/26 02:57 ID:o/89oTRn

そういう方向で突き詰めて考えちゃうと、それはModelとViewを独立して考えるというより、
単にViewがModelの下請けなだけで、分離されてないしねえ。

その意味で分離するなら、ViewはModelをポーリングした方がそれらしいよね。

これは、解像度・垂直帰線期間が固定されたコンシューマ機の開発ではあまり現実的
ではないけど（なぜならこれらはViewの要請に合わせ、Cの更新も同じ単位＝フレーム
で行う事が多いから）、ＰＣなどのレート非固定の環境の場合、意味のある考え方かもね。

117 ：名前は開発中のものです。：03/11/26 11:14 ID:gp+Vdr2Y

>>85のサンプルコードだけど、
これだと、単一のViewが複数のModelから参照されて、
それぞれのModelが好き勝手なタイミングと内容で単一のViewにset_positionするとか、
また逆にViewは存在してもset_positionしてくれるModelがいないとかいう状態も想定されてしまう。
それに、もしもpositionの値が原因でViewの中で不具合が起きた場合、
その時点で存在するModelのすべてに対してそのViewを参照しているか
調べなくてはならないし、もしも複数のModelが参照していた場合には
どちらが最後にset_positionしたかも調べなくてはならない。

オブジェクト自身の責任範囲の作業で必要になる値を外部からもらうとき、
外部の値を得る方法はあるにはあるが、
誰がいつ設定するか決められない、そもそもするかしないか知ることができない、
そんな無意味であやふやな設計みたことないよ。

だが、ViewがModelに依存しないということに、どうしてもしておかなくてはいけないし、
そういった諸々の不利益には目をつむるとしよう。

118 ：名前は開発中のものです。：03/11/26 11:56 ID:PfSyQyV9

>>117　いや、サンプルコードの設計をどうこう言っても・・・
あれは単にMとVの関係を示すためだけのコードでしょ？

119 ：とむ ◆0MTMwDpCZo ：03/11/26 12:39 ID:o/89oTRn

というか、コンポジションを「依存」と言ってる時点でおかしい気が。

120 ：とむ ◆0MTMwDpCZo ：03/11/26 12:50 ID:o/89oTRn

>>85のサンプルコードは、ModelがViewをコンポジションしてるだけで、Viewに依存してる
わけじゃないよね。つまり、そこでViewクラスが何をしてもModelクラスの振る舞いには
影響しないけど、Modelクラスが何かをすると、Viewクラスには影響がある。
だから、ViewがModelに依存しているとみんな言ってるんじゃないのかな。

以下Smalltalkのサイトより。

http://www.sra.co.jp/people/aoki/SmalltalkTextbookJ/textbook04.html

＞今回は、モデル・ビュー・コントローラのモデルについて説明したいと思います。
＞モデルというのは、複数の依存オブジェクトを保持できるものです。依存オブジェクト
＞とは、モデルのオブジェクトが変化をすると、自分も変化をよぎなくされるオブジェクトの
＞総称です。つまり、モデルに依存しているオブジェクトのことです。

＞　たとえば、ここに一つの変数オブジェクトがあったとしましょう。そして、
＞その変数の内容を画面に表示しているオブジェクトがあったとします。
＞変数オブジェクトの値が変化をしたら、その内容を表示しているオブジェクトも、
＞自分の表示を変えねばなりません。この時、変数オブジェクトをモデルと呼び、
＞その変数オブジェクトの値を表示しているオブジェクトを依存オブジェクトと呼ぶのです。

121 ：とむ ◆0MTMwDpCZo ：03/11/26 12:54 ID:o/89oTRn

とは言っても、>>93を読むと、「依存」の使い方が我々と違うらしいしな…。
どうも>>48氏は、オブジェクトコンポジションを「依存」と言ってるようだが。

私が間違ってるのかと思いきや、>>120のサイトを見ると別に間違ってないようだし。
ううむ。

122 ：とむ ◆0MTMwDpCZo ：03/11/26 12:57 ID:o/89oTRn

失礼、コンポジションじゃなくて集約か。

123 ：名前は開発中のものです。：03/11/26 13:10 ID:gp+Vdr2Y

つまり辻褄合わせのためにViewからModelへの依存を無思慮にとっぱらうことが
如何に害を生じるかということだよ。

Viewにとっての責任は描画を行うということだろう。
「描画する座標を特定する」ことは当然その果たすべき責任の範囲にある。
このサンプルではViewはその責任をModelにとりあげられてしまっていて
（どこかのだれかが自分のset_positionを呼ぶのをただ待つことしかできないわけだ）
負わされた責任を十分に果たすことができない。

そのひずみが、具体的には描画時に座標設定の部位で不具合があった場合に、
処理を行った部位を特定するのが異常に困難になるという点に顕れいる。

124 ：名前は開発中のものです。：03/11/26 13:24 ID:zIY1kHqT

先のサンプルコードは
M が V に座標を設定するという関連がある
ということしか示してないんじゃないかと思う。
依存というのとはちょっと違うのでは。

View::set_position に Model を渡してるならともかく
position を渡してるんだし。

125 ：名前は開発中のものです。：03/11/26 15:36 ID:dZQsSASl

ゲームなら、MVCよりFlyweight Flyweight描画メソッド Behavior っていう区分のほうがしっくりこない？
ま、大体MVC設計と一緒なんだけど

Flyweight 文脈に依存しないオブジェクト（Modelに相当）
　　３Dモデルデータ、テクスチャ、音声データ、テキスト、スクリプト…などなど。
　　(少なくとも)全Behaviorオブジェクト間で共有される。
　　変動するパラメータも、雛形･初期値はFlyweight
Flyweight描画メソッド文字通り(Viewに相当)
　　上記Flyweightの描画処理。大抵Flyweightをあらわすクラスにdrawメンバ関数を定義するなどして
　　実装される。パラメータや関数名を変えるなどしてシェーディング・ワイヤフレーム・あるいはテキスト
　　にダンプなど出力形態を変更できる。音声だったら再生
Behavior 振る舞い（Controlerlに相当）
　　キー入力に応答して、あるいはAIによって、あるいはスクリプトによって、自身の状態を変化させる
　　つまり自身の状態を所有していて、自身の状態の中には、座標なども含まれる

これは漏れの造語だけど
PresentMap オブジェクトの状態と見た目の対応付け機構
　　オブジェクトの状態とモデル・モーション・SEの対応表
　　Behaviorはこれを所有し、表引きして描画メソッドを呼び出すFlyweight群を決定する
　　これも（変動する場合その初期値・雛型は）Flyweight

126 ：名前は開発中のものです。：03/11/26 16:43 ID:TJpicHgi

ここの人たち、知識はあるのに話し合い方は他のとこと大して変わらないね
元々の内容そのものよりも、いかに言い負けないかみたいなとこにズレてきてる
少々の間違いは認めていった方が、有益な結果を生むはずなのに
全員がそうとは言わないけどね

127 ：名前は開発中のものです。：03/11/26 16:46 ID:ueZRq0X0

そもそもViewとかModelに分けた時点でオブジェクト指向じゃないしな。

128 ：名前は開発中のものです。：03/11/26 17:19 ID:PfSyQyV9

>>126
そう？今の流れを見ると勝ち負けとか関係なく、比較的建設的な議論になってきていると思うが。

129 ：名前は開発中のものです。：03/11/26 18:48 ID:Hfp/lcva

>>127
GUIは「Viewオブジェクト」があるからねぇ。
まぁ、そうすると、ゲームのViewオブジェクトはDirectXになるんだけど。

130 ：名前は開発中のものです。：03/11/26 22:39 ID:ueZRq0X0

>>129
設計ってのは悪い見本や状況の違うものの例を挙げて話すと
定義しなければならない言葉がたくさん出てきて結局それだけで終わっちゃうから
そういう形の考え方は俺はしない。

だって、ほら、>>129の文章だって[DirectX]とかあいまいな言葉がでちゃったでしょ？
もうこの時点で話すだけ無駄。
（おそらくDirectXのDirect3Dのデバイス作成、テクスチャ、ポリゴン描画辺りの機能を
言ったんだろうけど、それにしてもあまりにも雑だし、発言が不注意すぎるよね？）

ただでさえ社会学みたいなものなんだから気をつけなきゃ。
ちなみに社会学↓。
http://mazzan.at.infoseek.co.jp/

131 ：名前は開発中のものです。：03/11/26 22:46 ID:Hfp/lcva

＞（おそらくDirectXのDirect3Dのデバイス作成、テクスチャ、ポリゴン描画辺りの機能を
ていうか、他にどういう解釈できるよ？

132 ：名前は開発中のものです。：03/11/26 23:20 ID:ueZRq0X0

>>131
じゃあ、なんでDirectXって書いたの？

133 ：131：03/11/26 23:41 ID:Tq38HXMm

？？わけわからん。
用語を定義しないと議論が発散するよ、って一般的なこと言いたいだけなら、
他に行ってほしい。

134 ：名前は開発中のものです。：03/11/26 23:50 ID:mIue8e1k

　●／　＜えいえいOO
<｜
　/>

135 ：名前は開発中のものです。：03/11/27 00:01 ID:dGCilQTs

ＭＶＣじゃなくて、ＯＯでゲームプログラミングしてる何かためになるソースってない？
ネットで探せど探せどライブラリ使った奇怪難解なフレームワークしか見つからないんだけど
それは単に自分の技量が足らないわけだけだが
４８さんの人形劇メタファってどんな感じなのか見てみたい

136 ：名前は開発中のものです。：03/11/27 00:06 ID:pqwPw0f3

>>133
違うよ。何かに例えるとか機能や処理で考えるのをやめろって言うの。

>他に行ってほしい。
じゃあ煽りでもいれとくか。
いまどきゲームの設計をModelとかViewとか考えてるところがまずイモ。
そもそもゲームの設計以前にDirectXがあるとかGUIではこうだなんて
考えてるところもなんとも頭が固い。
オブジェクト指向でプログラムを組んだことがあるのか微妙だろ。

機能なんて考えるなよ。
まず、見た目にあるものを素直に実装しろって。
俺の場合、
ゲームのある場面をシーンと考えて、これをクラスにする　　シーンクラス追加
シーンには大地がある　グラウンドクラス追加
グラウンドには人間がたっている　人間クラス追加
光源がある　ライトクラス追加
カメラがある　カメラクラス追加
空がある　スカイボックスクラス追加
と作る。（もちろんゲームじゃもっと複雑にはなるが基本はこうだ）

後半に続く。

137 ：名前は開発中のものです。：03/11/27 00:19 ID:Bvr0Xdbc

>>136
マジで言ってるの？
＞オブジェクト指向でプログラムを組んだことがあるのか微妙だろ
全くもって君の事だと思うんだが？

その発想じゃ継承や共通する部分なんて皆無だろ。
コード書き連ねるのと何が違うって感じじゃん？

138 ：名前は開発中のものです。：03/11/27 00:21 ID:ghFgKWyL

オレはオブジェクトを単位に考えてるよ？
はやく>>131に答えてくれないかなぁ…

139 ：とむ ◆0MTMwDpCZo ：03/11/27 00:26 ID:dScikFo1

>>130さんがなぜ急にそんな話をしはじめたのか分からない…。

「DirectX」ですら曖昧と言われるなら、我々はどこから話を始めればいいのだろう。

140 ：136：03/11/27 00:27 ID:pqwPw0f3

>>137
>その発想じゃ継承や共通する部分なんて皆無だろ。
はぁ？そんな継承部分なんて抜き出すのはずっとあとの作業だよ。

141 ：名前は開発中のものです。：03/11/27 00:27 ID:dGCilQTs

ソースだ！ソースを出してくれ！

142 ：136：03/11/27 00:32 ID:pqwPw0f3

つーか後半書く前に
>>136の組み立て方に異論ある人っている？

もう議論も面倒臭いから俺のオブジェクト指向でのプログラムの組み方を書こうと思うが。

143 ：とむ ◆0MTMwDpCZo ：03/11/27 00:34 ID:dScikFo1

それより>>136さんは>>48の人と同一人物なのかどうか知りたい。

144 ：名前は開発中のものです。：03/11/27 00:37 ID:j94eY1vB

>>48氏が風向きが良くないことに気づいて名無しさんになったとエスパー。

145 ：名前は開発中のものです。：03/11/27 00:37 ID:Bvr0Xdbc

>>136
少なくとも、グランド、人間、スカイボックスは
objectクラスなんて物あたりから継承してきて作れば
座標があるのとかは共通じゃん。

そうやってパーツや部分単位で必要に応じて組み上げていくスタイルが普通かと？

146 ：名前は開発中のものです。：03/11/27 00:42 ID:ghFgKWyL

オレは>>136と>>130の関係がわからん。
それはともかく、名詞からオブジェクトを導出するってのは、OO方法論の教科書に書いてあることだね。

147 ：とむ ◆0MTMwDpCZo ：03/11/27 00:43 ID:dScikFo1

定義が曖昧になるから議論が出来ないと言うのなら、グランドクラスなどと書いても
議論にならないという気がする。

148 ：名前は開発中のものです。：03/11/27 00:44 ID:pqwPw0f3

>>143
違うよ。

>>145
なんで？座標クラスの有無をいってるなら、グラウンド、人間、ライト、カメラでしょう？
スカイボックスはカメラに追従する形にするし。ライトは平行光源ならいらないけど。
もう一度いっとくとこの辺の継承関係は別に考えなくてもいいんじゃない？
それでうまくいくとも思えないよ。共通部分もこの時点では座標しか無いんだから。

149 ：名前は開発中のものです。：03/11/27 00:46 ID:pqwPw0f3

>>147
定義やらなにやらはとりあえず考えなくてもいいようにする予定。

150 ：名前は開発中のものです。：03/11/27 00:54 ID:Bvr0Xdbc

>>148
…？
だから、共通する最低限を継承しつつ継承先の新しいクラスで必要なメンバやらを増やしていくんでしょ。
object(座標、名称等)-継承->キャラクラス(モデル情報、速度ベクトル、等々)
-継承->プレイヤークラス(key入力等)
|
-継承->敵キャラクラス(AI等)

ってな感じで私は構築してるが？これが普通だと思ってた。
皆さんは違うの？

151 ：136：03/11/27 01:03 ID:pqwPw0f3

>>150
この時点では継承は考えなくてもいいでしょ？
まずは必要なクラスを出してから継承関係はあとで抜き出すという方針です。
というわけで継承は気にしないでください。

152 ：名前は開発中のものです。：03/11/27 01:09 ID:Bvr0Xdbc

>>151
いやさ、C++の話で言うと継承元のメンバは継承先のクラスでも使えるんだよ？
そのやり方だと継承関係を抜き出した後にメンバとかを考えるの？
つまり、A-継承->B-継承->Cって関係の時に
A、B、Cの各々で共通するメンバはコレで…なんてやるの？

153 ：名前は開発中のものです。：03/11/27 01:19 ID:TFdGqod1

>>152
先に共通部分を洗い出したと思っても、
どうせ実装してる間に新しく見つかるだろうから、
まずは考えたとおりに切り分けていって、
実装の段階で共通部分が見つかったときに考えればいい話だと思う。

154 ：とむ ◆0MTMwDpCZo ：03/11/27 01:24 ID:dScikFo1

まあまあ、なんかこのスレはいつも良く分からない争点で争っているな。

まずMVCだけど、ゲームというアプリに対して、全体としてMとVとCに分けるというやり方
自体がもうOO的ではない、というのは共通見解だよね？　ていうか、そもそもMVCパターン
自体そういうものではないと思うけど。

もしMVCの枠組を考えるなら、オブジェクトを縦軸として、MVCを横軸とした直交的な概念
になるよね、ってのが>>108さんの考えで、それでいいと思う。

で、OOを教科書的に言うなら>>136さんの言うとおりでいいと思う。なぜそれを力説してる
のかは不明だけど、シーンクラスだの人間クラスだのは、別にそれでいいのでは。

ただ、機能を考えないというのは意味不明。あなたはレンダーをどこに実装するのかと。
オブジェクトごとに書くのか？

155 ：名前は開発中のものです。：03/11/27 01:25 ID:Bvr0Xdbc

>>153
それって最悪、最低の発想じゃない？
先にバグをなくした設計と思っても
どうせ実装してる間にバグはでるだろうから、
まずは思った通りに組んで
実装の段階でバグが見つかったら設計を考えればいい
ってのと同じレベルに聞える。

156 ：とむ ◆0MTMwDpCZo ：03/11/27 01:25 ID:dScikFo1

>>153
確かに設計時に100%の継承関係を定義するのは無理かも知れないけど、
実装しながら継承関係を考えるのは厳しいと思われ。
２度手間が発生しすぎる。

157 ：名前は開発中のものです。：03/11/27 01:38 ID:BoqYAr6p

GUIでMVCが云々ってのは、実際にV(&C)をオブジェクトとして捕らえるのが自然だから
だよね(その上で依存度が云々…)。実際に人間が触る部分だし。

ということで、>>129にループ！
(ゲームに例えると、V&CがDirectX部分ってのはちょっと無理あったかも。)

158 ：153：03/11/27 01:39 ID:TFdGqod1

ふむ。設計時にはまったく継承関係を考えない、とするわけにはいきませんね。
言いたかったことは、
　// forward declaration
　class ground;
　class human;
　class sky_box;
が頭に浮ぶのと、
　// definition
　class ground : public object { ... };
　class human : public object { ... };
　class sky_box : public object { ... };
が頭に浮ぶのとは、必ずしも同時ではない、
ということです。

>>136は forward declaration だけの話をしてるところに、
>>145が definition の話に勝手に引きずり込んだように見えたので、
反応してしまいました。

159 ：名前は開発中のものです。：03/11/27 01:41 ID:yBAkQ3zs

>>136 の後半ｷﾎﾞﾝﾇ
この段階で詳細について言っても仕方ないし。
組み立て方には今のところ異論ない。

160 ：136：03/11/27 01:43 ID:pqwPw0f3

>>154
>ただ、機能を考えないというのは意味不明。あなたはレンダーをどこに実装するのかと。
>オブジェクトごとに書くのか？
ん？そんなのは勝手にやりゃいいんじゃん。
あんまり変な組み方しなければどう組んでもいいと思うけど。
まあ、俺なら外に実装するかな？カメラやライトも関係するから
同列オブジェクトで関係を持たせると色々と面倒そうだしね。
描画が必要になるクラスから描画に必要な情報を受け取って描画をできるしくみを作る。
つまり、描画が必要なクラスから描画に必要な情報を取得できればそれでいい。
（座標、モデルなどのハンドル、etc）

161 ：名前は開発中のものです。：03/11/27 01:48 ID:Bvr0Xdbc

>>158
えっ？そうなの？
私は、
最少を構成するクラス、メンバにはこの情報って感じで頭に浮かんで
それに肉付けして、こう継承していけば、大きいオブジェクトのクラスは
こう継承されて行くって思い浮かべて行くよ。

いきなり人間クラス、グランドクラスなんて考えた事もない。
最少構成クラスが真っ先に頭に浮かんで、最低情報メンバも頭に浮かぶ。
そこから情報増やして行って大きくして、形にして行く。

162 ：名前は開発中のものです。：03/11/27 01:55 ID:mKPFQf5b

>>161
そうしていくとOO的に（いやな言葉だな）自然なツリーができるね
>>136のはトライ＆エラーで行き当たりばったりで
とりあえず組んでみるみたいな印象を受けた。

163 ：名前は開発中のものです。：03/11/27 01:59 ID:c0qe0rKM

>描画が必要になるクラスから描画に必要な情報を受け取って
描画をできるしくみを作る。

俺も同じ考えだな。

164 ：とむ ◆0MTMwDpCZo ：03/11/27 02:03 ID:dScikFo1

>>160
描画機能を外に持たせるなら、結局あなたが最初に言ってる事と違うと思うけど。
結局、個々のオブジェクトから描画を切り離して別の「機能」として持たせてるわけで。

165 ：とむ ◆0MTMwDpCZo ：03/11/27 02:05 ID:dScikFo1

>>158
別に>>136では前方宣言の話はしてないと思うけど…。
というか、ここで話題になってることと前方宣言にはあまり関係がないような。

166 ：136：03/11/27 02:07 ID:pqwPw0f3

>>161
なら、お勧め。
http://www.amazon.co.jp/exec/obidos/ASIN/4881356194/ref=sr_aps_b_/250-0323931-2989837
クレジットカードで払うのが嫌なら代金引換もＯＫ。
多分、俺の組み方がおそらく世のスタンダード。
（一応、色々研究したつもり。信じてこの本読んでみてくれ。）

>>159
いや、ここから
「MVCなんてでてこねーだろ。
オブジェクト指向で組んでるのかー。」
っていおうとしたんだけど>>154がいうにはもう解決したらしい。

なんか知りたかった部分の設計の詳細があったらいってくれ。

167 ：名前は開発中のものです。：03/11/27 02:11 ID:TFdGqod1

>>161
継承ツリーはなるべく膨らまない方がいい。
クラス間の依存関係は少ない方がいい。
というような観点から、 forward declaration から definition に至るまでに
個々のクラスごとでその継承が妥当かどうか、判断するべきだと考えます。

たとえば、地面が無限に広がる水平面だった場合、
人間が継承するような座標をもったオブジェクトから派生するかどうかには
判断の余地が生まれると思います。

天、地、人が、すべて同じものから派生しているのが当たり前、
なんてことは、特殊な環境や前提がないと言えないわけで。

168 ：とむ ◆0MTMwDpCZo ：03/11/27 02:13 ID:dScikFo1

確かに、ID:Bvr0Xdbcさんの言ってるような深い継承関係は普通あまり使わないですね。

169 ：名前は開発中のものです。：03/11/27 02:17 ID:Bvr0Xdbc

>>166
…いや、はっきり言うとさ
一応、PC(個人一人)コンシューマ(仕事)で一回づつ161の方法で組んでるけど
効率、設計、等々で一番良かった。

その手の本のやり方って絵空事って言うか、机上の空論っていうか、
初心者にオブジェクト指向とは何ぞや？って感じの説明の類にしか思えない。
考えは抽象的で良くても、設計やコーディングはそうはいかない。

つーかさ、Cとかの売ってる入門本系の手法なんて実際にゲーム、
3Dで速度やトリッキーな処理が求められる物で
本に書いてあるスタンダードだからって使う？

170 ：名前は開発中のものです。：03/11/27 02:18 ID:pqwPw0f3

>>164
ん？なんか違うことかいた？俺？
設計するときには考えなくていいところだと思ったんだけど。

171 ：名前は開発中のものです。：03/11/27 02:20 ID:pqwPw0f3

>>169
>一応、PC(個人一人)コンシューマ(仕事)で一回づつ161の方法で組んでるけど
>効率、設計、等々で一番良かった。
よかったじゃん。

172 ：名前は開発中のものです。：03/11/27 02:22 ID:Bvr0Xdbc

>>167
＞地面が無限に広がる水平面だった場合
これは概念の問題であって、実際にモデルなりデータで
無限の広さのモデルやデータなんてありえないでしょ？

ゲームの処理上は有限で座標のあるものに為るのが普通。
処理で無限の様に見せるだけじゃないの？

173 ：名前は開発中のものです。：03/11/27 02:36 ID:TFdGqod1

>>172
まず、
１．無限に広がる地面がある
というのが決まって、そのあとに、
２．無限の広さのモデルやデータなんてありえない
３．ゲームの処理上は有限で座標のあるものに為るのが普通
４．処理で無限の様に見せればよい
これだけの条件がそろったので、
座標を持ち、モデルの描画ができるクラスから派生して
無限のように見せる処理を追加するのが妥当である、という判断を下す。

そういう順序、思考の段階があるでしょう、という話です。

174 ：136：03/11/27 02:36 ID:pqwPw0f3

連投規制チェックしたつもりが送信してしまった・・・。

>>169
いや、煽りぬきにしてそれでよかったならそれでもいいと思う。
ただ、それだと何が必要なのかわからないな。（俺には）
どっから説明していくかというときに「座標があってな」ってところからいくわけだから。
はじめにおおまかに作るものが見えていたほうがいいと思うのよ。

175 ：159：03/11/27 02:48 ID:yBAkQ3zs

>>166
その教科書通りの方法で進めたらどんな感じになるのか
見てみたかったというだけ。

自分が作ると大体、特定のクラスだけぶくぶくと太ったり
ちょっと特殊なことやろうとするとうまく切り分けられなかったり
途中で行き詰まってしまう。
仕事だったら力技でそのまま進めて何とかなる
（なってないけど一応完成はする）とは思うけど
個人でやってるとどうにも、うまくまとまらないと
嫌になって最初からやり直してしまう。
仕事の方はＯＯなんてまるで別世界だし（恥ずかしながら）。

やっぱ自分で試行錯誤するしかないな（´・ω・｀）

176 ：とむ ◆0MTMwDpCZo ：03/11/27 03:00 ID:dScikFo1

>>170
まさか！
今時ゲーム開発の現場で、設計段階でレンダーを頭から外せるところなんかないっすよ！

あなたのところはあれですか、スパコンでインベーダー作ってるんですか？

177 ：136：03/11/27 03:03 ID:pqwPw0f3

>>176
いや、だから関係ないじゃん。
描画に必要な情報さえ受け取れればいいんだから。
どうしてそんなところが問題になっちゃうの？

178 ：とむ ◆0MTMwDpCZo ：03/11/27 03:04 ID:dScikFo1

ぐっ…

あなたは設計時に、描画機能についての制限とかは考えないの？
ターゲットのレンダリング能力から頭を切り離して設計できるの？

ていうかそもそも、あなたは本当にゲームを作ってるプログラマなの？
かなり疑問。

179 ：名前は開発中のものです。：03/11/27 03:05 ID:3iv4XS6o

>>175
>自分が作ると大体、特定のクラスだけぶくぶくと太ったり
>ちょっと特殊なことやろうとするとうまく切り分けられなかったり
>途中で行き詰まってしまう。
>嫌になって最初からやり直してしまう。

人、それをリファクタリングという。
むしろ最初に決めた設計を最後までまったく変えないなんて方がありえないかと。
ただ仕事だと期日があるから妥協せざるを得ないというだけで。

理想を追い求めて現実のものに出来ないのもダメだが、理想をさっさとあきらめて
低いレベルで現実に落としちゃうのもおんなじようにダメ。

180 ：名前は開発中のものです。：03/11/27 03:18 ID:3iv4XS6o

>>178
俺、>>125 を書いたものなんだけども、俺の場合125の内容どおり
描画はFlyweightが描画サブシステムとやり取りして解決するものなので、
たしかにBehaviorより上位のゲーム本体の部分（疑似タスク機構だとかいろいろ）
の設計では描画のことはまったく気にしない。（というかそうなるように考えた）

136氏は描画を完全に分離したシステムを前提にしていて、
とむ氏は（実装上の手間を省くためと、特殊エフェクトなどの実装の利便性のために）
分離しないシステムを前提にしているから、話がかみ合わないんじゃ？

181 ：とむ ◆0MTMwDpCZo ：03/11/27 03:26 ID:dScikFo1

うーん、「分離」という言葉の使い方が分かれちゃってるなあ。

そもそも、実装上は誰でも分離すると思いますよ。私だってそうです。むしろ私こそ、
「レンダーは分離しないのか？」という質問を発した方です。

ま、そこに私と>>136さんの間での齟齬があったわけですけどね。
私は、「レンダーの分離」というのは前提であり、その能力に設計が左右されるから、
「機能を考えないわけにはいかない」と発言したわけです。
>>136さんは恐らく、レンダーが分離されているのだから、「設計では描画のことは考え
なくていい」という発言をしたのではないかと思います。

しかし、先にレンダーの分離を前提にするなら、レンダーこそ「機能」そのものであり、
やっぱり「機能は考えなくて良い」という奇妙な考えは出てこないと思いますが。

182 ：名前は開発中のものです。：03/11/27 04:04 ID:3iv4XS6o

>>181
ああ、そういうことですか。流れが読めて無かったです。
僕は（多分、138氏も）描画処理の分離のための設計も
議論の範疇に入っているとは考えて無かったです。

分離のための設計は、私見だけど、「後からでも割と
どうにかなる」と感じてます。
ま、やっぱり不恰好にはなるんですけど、僕の感覚だと
そんなに力入れるところじゃない、と考えていて。

複数プラットフォームで同時リリース、なんてな要求が
あるとそうもいかないのかもしれませんが。

183 ：名前は開発中のものです。：03/11/27 05:29 ID:5WybXs6I

チクショーおまいら人が寝てる間にチャットしてんじゃねーよ（ ´･ω･）

184 ：名前は開発中のものです。：03/11/27 08:25 ID:K/zQLrjh

てか描画するためのインターフェース作って
各クラスに実装させればいいだけでしょ。
136が言ってるのは割りと普通に使う手法だとおもうが。

185 ：名前は開発中のものです。：03/11/27 09:29 ID:5WybXs6I

ところで、>>125あたりをもとに良いゲーム用のフレームワークを考えていきたいが、
オブジェクト自然主義派のﾔｼらもある程度満足するようなポエミーな部分も
取り入れる方向でいいかんじにまとまらないかなーとか思っています。

186 ：とむ ◆0MTMwDpCZo ：03/11/27 13:11 ID:dScikFo1

ところでさっきからレンダーレンダー言ってるけど、「レンダラ」の方がいいですかね。
それともレンダガにしますか…。

それはともかく。
>>182
まあ、「OO的な組み方」という意味でMVCへの反論（？）としては、>>136さんの考え方に
ほとんど異論はないわけですよ。

ただ、設計に関して「機能は考えなくていい」と言う部分に反論しただけで。
例えば>>136さんも「ライトクラス」なんてさらっと言ってますが、それは光源をレンダラが
処理してくれる事を前提にした考え方です。つまりそういう概念を持ち込むこと自体、
設計が機能に規定されているのですよ。
（スーパーマリオに光源の概念はないですよね？　あれはキャラクタに光源方向が描き
　こまれてしまっているので）

だから良く言う、「オブジェクト思考は直観的にオブジェクトで分ければいいんだ」なんて
理想的な考え方を持ち込んでも、結局はあまり直観的ではなく、すでに「機能」を前提に
オブジェクト分け、そして実装をしなければならない、とそういう話なのですよ。

以上、昨日連続投稿で書けなかった分…。

187 ：128：03/11/27 18:54 ID:3iv4XS6o

>>189
>だから良く言う、「オブジェクト思考は直観的にオブジェクトで分ければいいんだ」なんて
>理想的な考え方を持ち込んでも、結局はあまり直観的ではなく、すでに「機能」を前提に
>オブジェクト分け、そして実装をしなければならない、とそういう話なのですよ。

最近「オブジェクト思考は直観的にオブジェクトで分ければいい」という考え方は批判されてますね。
それができれば理想なんだけど、C++もJavaも既存のOOPLは全部、それが可能な言語機能を
提供できてないんで。

>>185
不完全な実装なら、某所に晒してあったりするんですが…ｳｰﾝ

188 ：名前は開発中のものです。：03/11/27 20:08 ID:wD8LR/s0

＞不完全な実装なら、某所に晒してあったりするんですが…ｳｰﾝ
お、いいじゃん。
それをベースによりよいシステムを考えるってのはどうよ？
サンプルはあったほうが話が早いしね。ぜひ晒してくだちい。

189 ：名前は開発中のものです。：03/11/27 20:31 ID:jJmYTBTh

yaneSDK

190 ：名前は開発中のものです。：03/11/27 21:39 ID:BoqYAr6p

まぁ、ナイープというかなんというか

＞「オブジェクト思考は直観的にオブジェクトで分ければいいんだ」
オブジェクト世界超自然主義とでも呼べばいいのかな…？

191 ：名前は開発中のものです。：03/11/27 22:08 ID:pqwPw0f3

>>186
>例えば>>136さんも「ライトクラス」なんてさらっと言ってますが、それは光源をレンダラが
>処理してくれる事を前提にした考え方です。
え？どうしてそうなるの？わけがわからない。
そういうつもりでいったんじゃないなぁ。
あの場合はシェーディングに使うこと前提で話してたけど訂正します。
加算半透明でグローを出してライトクラスとします。

192 ：191：03/11/27 22:08 ID:pqwPw0f3

訂正っていうか変更。

193 ：とむ ◆0MTMwDpCZo ：03/11/28 00:18 ID:L9LZ9Wkm

>>191
ですから、

＞あの場合はシェーディングに使うこと前提で話してたけど訂正します。
＞加算半透明でグローを出してライトクラスとします。

このようなクラスが必要という前提でオブジェクトをとらえている時点で、「機能を考えない」
というわけにはいかなでしょ、という話です。
いかにも描画機能について考えずに素直にオブジェクトを実装すればいいみたいな事を
言っておきながら、結局ライトクラスのようなものがレンダラの機能の要請に従って必要
になってるじゃないですか。ついでに言えば、カメラクラスも必要ですよね。

「素直なオブジェクト分け」の中に、ライトだのカメラだのが含まれますか？
それはまさに、レンダリングという「機能」に規定された設計とは言えませんか？

結果的に、描画機能を考えずにオブジェクト設計をするのは実質的に無理という事ですよ。

194 ：名前は開発中のものです。：03/11/28 00:36 ID:nd1zJQM4

>>193
>「素直なオブジェクト分け」の中に、ライトだのカメラだのが含まれますか？
含まれるでしょ？
だって俺はゲームのある場面を「シーン」としてとらえたんだよ。
ちなみにこのシーンは映画などを思わせるように「シーン」とかいたつもりだったんだけど。
なんでレンダリングの機能なの？それはそっちが勝手に思ってるだけ。
あと、この場合のカメラはレンダリングのカメラとかぶるようになっちゃったけど
べつにそうでなくてもいいと思ってるんだけど。
つまり「映画を撮るときみたく１カメ２カメ３カメと複数置いてそのうちのアクティブなカメラが現在のシーンを映す」
みたいな感じで考えてるんだけど。レンダリングのカメラとは違うよね。

つまり俺の脳内では映画の撮影現場の構築をクラスに反映させてみたんだけど。

195 ：とむ ◆0MTMwDpCZo ：03/11/28 00:47 ID:L9LZ9Wkm

>>194
＞つまり俺の脳内では映画の撮影現場の構築をクラスに反映させてみたんだけど。

しかし、あなたがそういう風に構築したくないと思っても、カメラクラスとライトクラスは
必要ですよね。
それって結局描画機能がそうなってるからで、「これは映画なんだ」と言い張っても、
結果的に描画機能を意識せずには設計できないんじゃないでしょうか。

196 ：名前は開発中のものです。：03/11/28 01:09 ID:eCESjMDg

>>194
こいつプログラム組んでゲームを完成させた事ないな。
映画のカメラだって？レンダリングのカメラとは違うよね。だって？
同じだろ、映画はカメラを通した場面しか見れない、
ゲームもレンダリングしないと画面に映らない。

どっかの入門本読んで、勘違いしちゃってるのか。

197 ：とむ ◆0MTMwDpCZo ：03/11/28 01:16 ID:L9LZ9Wkm

というか、前にも書いたのだけど、ゲームのプログラムを設計するのに描画を考えなくて
いいというのがもう現実離れしていて…。

そりゃ理想だよね。キャラクラスとか背景クラスを適当に並べたらなんとなくゲームに
なったりすると。

実際には描画機能との戦いです。ハイ。

198 ：名前は開発中のものです。：03/11/28 01:21 ID:HpWT7QQb

194の考えている「カメラ」と、とむの考えている「カメラ」が同じクラスである必要はないでしょう。

「194::カメラ」を実装するにあたって、
結果的に「とむ::カメラ」に描画用カメラクラスとしての機能を委譲する必要が、
（とむが思うには確実に）出てくるだろう、という話ではないでしょうか？

結果として機能が必要になるといっても、
概念と機能は不可分ではないはずです。

199 ：名前は開発中のものです。：03/11/28 01:29 ID:eCESjMDg

>>198
だから、そう言うのを含めてプログラム組んだ事ないだろ？為るんだよ。
オブジェクト指向は魔法の発想、手法で何でも出来るってか？

オブジェクト指向と言う、下らん呪いにかかってるとしか思えん。
実に下らない設計だな、おい。

200 ：とむ ◆0MTMwDpCZo ：03/11/28 01:32 ID:L9LZ9Wkm

>>198
じゃあ、「194::カメラ」という構成が要らなくなりました、という理由でカメラなしで
シーンが作れますか？

201 ：名前は開発中のものです。：03/11/28 01:37 ID:nd1zJQM4

>>195
>結果的に描画機能を意識せずには設計できないんじゃないでしょうか。
いや、そこまで厳密に考えることの意味がわからないけど。
なんでそんな微妙な部分にこだわるんだ？
「描画機能」なんてほとんど意識せずに設計することはできたよね？
少なくとも「描画機能」といえるまで「機能」の部分がしゃしゃりでてくる設計にはなってないでしょ？
それじゃ駄目なの？
俺は設計さえしっかりできれば機能なんてあとからついてきてくれるものだと思ってるんだけど。
こんなはじめの設計段階で機能なんて意識してないよ。

俺のこの↓発言にこだわってるみたいだけど
>機能なんて考えるなよ。
>まず、見た目にあるものを素直に実装しろって。
この主旨を大きくはずれるぐらいの設計をしたのか俺は。

>>196
そこから「プログラム組んでゲームを完成させた事ないな」まで飛ぶ？
無視しちゃうよ？いい？

202 ：名前は開発中のものです。：03/11/28 01:41 ID:p0iS/mJU

ゲームを人形劇の舞台やら映像の撮影現場に喩えたいのはよくわかるんだけど、
それは、実際にはユーザーに対してそう思わせたいというだけであって、
実際のゲームエンジンの機能を見てみれば、これは、グラフィッカさんとかスクリプト書きさんの
上げてきたデータを逐一解析して、画面に適切に構成する単純な一機能、一道具に過ぎないのです。
ゲームをプレイする人と、作る人との視点の違いに気付かなきゃいかんのです。
それに気付いておかないと、漏れのように突き進んでから後悔することになるのです（´･ω･｀）

203 ：とむ ◆0MTMwDpCZo ：03/11/28 01:44 ID:L9LZ9Wkm

>>201
＞「描画機能」なんてほとんど意識せずに設計することはできたよね？

これが無理だから言ってるんです。
設計というのは、オブジェクトの構成、内容を考えることですよね。
ライトクラスがあるのか、カメラクラスがあるのかはレンダリング機能によります。
完全３Ｄなら必要です。完全２Ｄならほぼ不要です。２Ｄによる擬似３Ｄなら、やはり
ほぼ不要です。これらは純粋に、ターゲットとレンダラの描画能力に規定されます。

オブジェクトは何を内包するのか。サーフェスだけなのかボーンも入れるのか、
モーションクラスを継承（包含）する必要はあるのか、ビルボードで済ますのか。
これらが可能かどうかは全て描画機能に依存します。

設計段階で描画機能を無視するわけにはいきません。
何度も言いますが、カメラクラスは３Ｄだとどうしても必要になりますが、それはあなたが
映画を作りたいからではなく、レンダラが必要とするからです。
例えば自分視点のゲームを作るとしたら、あなたの理屈から行けば「カメラ」クラスは必要
ないですよね。しかし現実にはカメラを実装することになるでしょう。描画機能がそれを必要
としているからです。

204 ：名前は開発中のものです。：03/11/28 01:47 ID:eCESjMDg

>>201
ゲームと言うプログラムの中で
オブジェクト指向だからってシーンを思い浮かべた、シーンクラス。
始めの設計が、シーンクラス？
それで”設計さえしっかりできれば機能なんてあとからついてきてくれるもの”？？

いきなり一部分のみしか見ないで、オブジェクト指向も設計もないな。
諸々の発言も含めて、ゲームプログラムを君が言ってる通りに作ってるとは到底思えない。

205 ：198：03/11/28 01:59 ID:HpWT7QQb

> オブジェクト指向は魔法の発想、手法で何でも出来るってか？

そんなこと言ってません。
どう読んだらそんな主張をしてるように見えるのかわかりません。

> じゃあ、「194::カメラ」という構成が要らなくなりました、という理由でカメラなしで
> シーンが作れますか？

何を以って「シーンが作れる」といえるのかが、おそらく合意できないでしょうが、
いちおう答えておきます。
カメラが要らないって事は、３Ｄグラフィックによる表示が要らなくなったって事ですかね？
かわりに２Ｄグラフィックで表示するか、
レーダーの受信データようなものに出力するか、
文章で表現するかは知らないですが、
捉えるべきものの存在を保持しているという意味でのシーン（とその中に保持されている個々のもの）は
カメラの有無にさほど（または、まったく）影響されずに存在する可能性はあると思います。

的外してるようなら無視していただければ、かってに消えます。

206 ：名前は開発中のものです。：03/11/28 02:00 ID:nd1zJQM4

>>203
>例えば自分視点のゲームを作るとしたら、あなたの理屈から行けば「カメラ」クラスは必要
>ないですよね。しかし現実にはカメラを実装することになるでしょう。描画機能がそれを必要
>としているからです。
「カメラクラス」はなくなるけど今度は「目クラス」ができるんじゃない？
ちなみにはじめの設計では「目クラス」なんておそらくでないね。
だから>>136に書いた設計を利用すると「カメラ」がちょうど消えた状態が
自分視点の場合じゃない？これでカメラを消すことができたね。
（もっとも今回は強引に消したけど映画の撮影現場をイメージしたんだからカメラがなくなるわけないけど）

オブジェクト指向で組むと機能なんて考えなくても
必要なものは必ずなんらかの形で出てくるんだよ。
描画機能を意識して設計をしたわけじゃない。

207 ：とむ ◆0MTMwDpCZo ：03/11/28 02:06 ID:WfC+lamV

>>205
＞カメラが要らないって事は、３Ｄグラフィックによる表示が要らなくなったって事ですかね？

違いますよ。それは、「とむ::カメラ」の話じゃないですか。つまり、レンダラに取ってのカメラの
話ですよね。そうじゃなくて、「194::カメラ」が必要なくなったらという意味ですよ。
映画撮影の舞台じゃないゲームを作りたくなったら、必然的にそうなるでしょ。そうしたら、
カメラはどうするの？　それでも実装せざるを得ないでしょう。なぜか？　それが描画機能の
要請だからではないですか。

>>206
その「必要なもの」の「必要な」の中に、「機能が必要としている」も含まれているのでは
ないですか？　また逆に、「機能的に無理なもの」に関しては、設計上必要としていても
作れないんじゃないですか。例えばあなたはＭＳＸで開発するのに、カメラクラスから実装
しますか？

208 ：名前は開発中のものです。：03/11/28 02:11 ID:eCESjMDg

>>206
完璧にアホ。
アホ丸出し。
目クラス？？？

3Dの処理ってのを全く理解出来てない。
挙句、同じ機能の物をクラス名を変えただけでオブジェクト指向気取りか。
目だろうが、映画のシーンのカメラだろうが、3Dゲームにおいては同じ機能になる。

209 ：136：03/11/28 02:21 ID:nd1zJQM4

>>207
いや、そもそも映画の撮影現場からカメラが消えたらおかしいじゃん。（てか、話ループする？）
まあ、この辺でやめよう。
あまりにも議論がくだらなくなってきた。
実用性もねーし。

このスレの>>130は俺なんだけどさぁ。
設計って社会学みたいなものなんだよね。
http://mazzan.at.infoseek.co.jp/
つまりこの議論に終結はないよ。おそらく。
また、数字に照らし合わせることもできないからどっちが正しいかなんてでないよ。
ＭＳＸなんて出てきた時点で俺らただのアホだって（他の奴からみれば）。
みんな（傍観者）笑ってるだろうし、もうやめよう。

210 ：198：03/11/28 02:22 ID:HpWT7QQb

> 「194::カメラ」が必要なくなったらという意味ですよ。
じゃぁ、映画撮影の舞台じゃなくて、テキストアドベンチャーになったとしたらいいんですか？
そうしたらカメラなんて実装からもすっぱり消えますよ。
そうじゃないっていうんなら、かわりに何が作りたくなった場合のことを考えたらいいのか、
とむが決めてよ。

> 例えばあなたはＭＳＸで開発するのに、カメラクラスから実装しますか？
シーンをカメラで捉えたいってんだから、そりゃそうするでしょ。
実装はじめたとたんにいろいろ妥協するか、行き詰まるだろうことは
早々に予測できますが。

その場合に、シーンとカメラの概念上の関係が、
ターゲットの描画機能と無関係に構築されていれば、
その概念上の関係はは要求を満たすターゲット上に引き継ぐことができるでしょう。

211 ：とむ ◆0MTMwDpCZo ：03/11/28 02:24 ID:WfC+lamV

「俺らアホ」に巻き込まれてしまった…仕方ないか。

言いたいことは、ID:eCESjMDgさんが大体言ってくれました。
結局クラス名を「カメラクラス」にしようが、「目クラス」にしようが、そんなのは名前が
変わっただけの話です。機能は一緒です。レンダーに取ってのカメラです。
そしてそれは、映画撮影の現場を考えようが、カメラの無い自分視点の世界を考えようが、
あるいはカメラも自分もない（心的イメージ世界の表現など）をしようが、結局絶対必要
なのです。

なぜかって？
それはそれが「機能」だからです。

212 ：とむ ◆0MTMwDpCZo ：03/11/28 02:26 ID:WfC+lamV

>>210
だから、自分視点のゲームを作る時ですよ。「194::カメラ」は必要ないですよね。
必要ないから、レンダラのカメラも要りませんか？
要りますよね。

＞実装はじめたとたんにいろいろ妥協するか、行き詰まるだろうことは
＞早々に予測できますが。

あなたは実装してから行き詰るのですか？
設計時にＭＳＸの描画機能について何も考えないのですか？

213 ：136：03/11/28 02:41 ID:nd1zJQM4

>>211
で、それを踏まえて設計すると何がどうよくなるの？

214 ：198：03/11/28 02:43 ID:HpWT7QQb

> だから、自分視点のゲームを作る時ですよ。「194::カメラ」は必要ないですよね。
そうですね。（「だから」って、もしかして、どっかに既に書いてありましたか？）
元の話に照らすと、
自分視点を実装するにあたって、
結果的に「とむ::カメラ」に描画用カメラクラスとしての機能を委譲する必要がある、
ということになりますね。

> あなたは実装してから行き詰るのですか？
「ＭＳＸで開発する」って前提でどうするかを質問されたのではないのですか？
開発するかしないか選べるんなら、しないと判断しますよ。

> 設計時にＭＳＸの描画機能について何も考えないのですか？
「シーンをカメラを通してうつす」っていうのも前提ですよね？
MSX上で実装する方法を一生懸命考えるでしょうね。
もしかして、「MSXでは無理だからカメラやめようぜ」っていうのを
「設計」と言うおつもりですか？

215 ：とむ ◆0MTMwDpCZo ：03/11/28 02:44 ID:WfC+lamV

>>213
何がどう良くなるとかじゃなくて、踏まえないとゲームが作れないというだけの話です。

というか、あなたは本当に描画機能を無視して設計してきたのですか？
そこが非常に疑問です。どんな現場がそんな設計を許すのでしょうか。
私の知る限り、描画機能を無視してゲームを設計した人はいません。

216 ：とむ ◆0MTMwDpCZo ：03/11/28 02:46 ID:WfC+lamV

>>214
＞結果的に「とむ::カメラ」に描画用カメラクラスとしての機能を委譲する必要がある、
＞ということになりますね。

じゃあ結局あなたも私の言ってる通り、「機能」としてのオブジェクトを必要とするという
意見じゃないですか。だったら私に反論する必要はないでしょう。

＞もしかして、「MSXでは無理だからカメラやめようぜ」っていうのを
＞「設計」と言うおつもりですか？

そ、それを設計と呼ばずしてなんと呼ぶのですか…。繰り返しますが、あなたは設計時
にはターゲットの能力を考えず、実装時にはじめて考えるのですか？

217 ：名前は開発中のものです。：03/11/28 02:56 ID:nd1zJQM4

>>215
>何がどう良くなるとかじゃなくて、
じゃあ、俺とあんたの作るものになんの違いもないじゃないか。馬鹿らしい。
つーか議論してる途中も思ってたんだけど、
描画機能が設計に影響してることを認識してるあんたと認識してない俺に
結果が変わらないならどっちだっていいじゃないか。あんたアホか。

218 ：198：03/11/28 02:56 ID:HpWT7QQb

> じゃあ結局あなたも私の言ってる通り、「機能」としてのオブジェクトを必要とするという
そりゃ、自分視点で3Dレンダリングするっていう状況に限定されたら、
レンダラでのカメラクラスが必要なのはあたりまえでしょうね。
くだらない問答でしたねぇ。

> そ、それを設計と呼ばずしてなんと呼ぶのですか…。
要求事項の変更とでも呼びましょうか。
断じて設計ではありません。
ユーザーが見る絵が変わるんですからね。

> 繰り返しますが、あなたは設計時にはターゲットの能力を考えず、
> 実装時にはじめて考えるのですか？
ターゲットが決まった時点で、ターゲットの能力を考えて設計することができます。
ターゲットが未決定でも要求が決まっていれば、概念上の設計をすることができます。

219 ：とむ ◆0MTMwDpCZo ：03/11/28 03:00 ID:WfC+lamV

>>218
というか、「要求事項の変更」とか言葉の遊びをされても…。結局実装前にターゲットの
機能を考えないといけないという話ですよね。

＞ターゲットが決まった時点で、ターゲットの能力を考えて設計することができます。
＞ターゲットが未決定でも要求が決まっていれば、概念上の設計をすることができます。

で、概念上の設計をしていても、それがそのターゲットで無理という事になれば、
設計を見直す羽目になるわけですよね。
それって機能に規定されてないですか？

というか、あなた本当に今までハードの機能を考えずにゲーム設計をしてきたの？
そこが本当に不思議です。参考までに、あなたが手がけた事のあるハードを教えて
くれないでしょうか。

220 ：名前は開発中のものです。：03/11/28 03:29 ID:eCESjMDg

ゲーム業界にいるし、業界の友人、知人も結構いる。

でだ、いきなりシーンクラスって言い出して、
カメラは映画のカメラ相当だから、レンダリングのカメラと違うやら言い出す輩は
知らない、聞かない、職業ゲームプログラマ？って感じだ。

机上の設計語ってる奴もいるし。
＞MSXでは無理だからカメラやめようぜ
設計以外の何物でもない。
設計では無いなら、”オブジェクト指向でシーンクラスを考えた”
これも設計じゃ無くなるのか？

＞ターゲットが未決定でも要求が決まっていれば、概念上の設計をすることができます。
無理に決まってるだろ。
では問う。PS2ではマルチテクスチャは無理です。CUBE、Xboxなら出来ます。
どれで行くか分って無い時点で、水面を表現したいって場合にどう設計するんだ？

221 ：名前は開発中のものです。：03/11/28 03:32 ID:zaH9w9Q9

要求定義を変えることで設計が変わることを
＞実装前にターゲットの機能を考えないといけないという話
だと言っても説得力がない

＞概念上の設計
をしているはずなのにDirectXは持ち出してみたり、概念の説明に対してそれじゃ実装できないだの
全然概念上の設計じゃない
カメラクラスがそのままclass cameraになるとでも思っているのだろうか
いや、結局そうなるんだがカメラクラスをDirectXのカメラと同一視している点から
勘違いしているのは間違いない
なにより2Dでカメラクラスが必要ないなどとチョンボをするなんて理解していない証拠だ

この調子でいくと勇者クラスには描画メソッドが必要などと言い出すんじゃないだろうか

222 ：名前は開発中のものです。：03/11/28 03:43 ID:eCESjMDg

>>221
概念上の設計とやらと
概念上だから実機上での実行速度や実装方法を無視できるってのは意味が違う。

概念上は、速度も保てて不具合無く実行出来るが実際に試さないとってのと
概念上なんだから実行環境や実行コスト無視出来るってのは違うだろ。

223 ：名前は開発中のものです。：03/11/28 03:48 ID:zaH9w9Q9

>>222
概念上の設計＝分析ぐらいに受け止めてたよ
過去ログみると分析と設計同時にやってるみたいだから

いいかげんなこと言うもんじゃないね
社会学とやらが身に付いてきたのかも
ｽﾏｿ

224 ：名前は開発中のものです。：03/11/28 04:00 ID:RZWRyVTn

ようするに、
特定のプラットフォームに限定された最適の設計をしようとしているやつと、
なるべくプラットフォーム非依存に設計しようとしているやつが
言い争ってるだけって事か？

225 ：とむ ◆0MTMwDpCZo ：03/11/28 04:05 ID:ycl3xZYL

いや、「機能非依存」らしいのですよ…。
問題はターゲットの能力だけでなく、レンダラの機能にも依存しないようなので、
そこがなんかおかしいんじゃないかな、と。
カメラだのライトだのは、レンダラがそういうものを必要としてるから設計に入るんじゃ
ないかと言っても、映画だからと言い張るし…。

第一、映画であったとしても、「カメラ」というオブジェクトを要するのはやはり機能
なのではないかと思うけど。カメラ自体は恐らく実体を持たないのだろうし。
ポリゴンで作ってたりして。

226 ：136：03/11/28 04:08 ID:nd1zJQM4

>>224
いや、ただの社会学だった。（わかっちゃいるんだけどやっちまうなぁ）
http://mazzan.at.infoseek.co.jp/
俺も自分の意見を正当化しようと数字もデータもとれないことにや躍起になりすぎた。

やっぱり設計の議論は実用性をもって話さなければ議論にならないな。
いままでしてきた議論の結論がどっちに転んでも何も変わらないことがすべての虚しさを語っているな。

227 ：128：03/11/28 04:15 ID:g3jRtGfp

うお、今日もスレが進んでるな…
もうこの機能非依存で設計できるかの議論からは一抜けた
レスを全部読む気力がない

>>188
自分がプライベートでちまちま作ってたソースを、仕事で使った後
他で使えなくなるのが嫌で、その予防線でネットに晒してるだけなんですが…

それでも見ますか。そうですか。ただ…会社では見ないほうが良いかも
http://www.water.sannet.ne.jp/sowwa/

228 ：198：03/11/28 04:26 ID:HpWT7QQb

これまで「概念上の設計」といっていたものは
より一般的に「分析」というものです。（要求→分析→設計→実装）
造語で要らぬ語弊を増やしてしまってすいませんでした。

言葉を変えてまとめさせていただきますと、
分析フェーズで現れたものをなるべくそのまま設計上にも表現しよう、
という主張でした。
そうすることによってできる抽象的な層があると、
実装を進めた後でも身動きが取りやすいですよ、
と。

設計と要求の区別を言葉遊びと言われるのであれば、
こちらの意図を伝えることはできないです。

> あなた本当に今までハードの機能を考えずにゲーム設計をしてきたの？

いいえ。設計を自分で決めることができるようになってからは、
「ゲーム」は設計していないです。
いまのところライブラリ、ツールまわりのほうが多いです。
抽象的な分析の恩恵を受けやすい立場といえると思います。

229 ：とむ ◆0MTMwDpCZo ：03/11/28 04:36 ID:ycl3xZYL

>>227
ほほーう…サンプルを一つもコンパイルできないのは残念でした…；
問題は、ここからゲームを作るのにどう実装するかだね。

>>228
なるほど、開発プロセスとして設計より前にあるから別、という事ですね。
しかし、それでは「設計段階では機能については考えない」という事にはならないと
思います。一つには、分析フェーズで機能について見当したのを設計に持ってくるだけ
なので、無視しているわけではないということ。
そしてここで言う機能とは、「画面描画」のようなことを指して言ってるので、結局それも
「設計」しなければいけない事には変わらないですよね？

そりゃ、Windows+VBで業務アプリ作るならまだわかりますよ。描画のほとんどの部分に
ついてＯＳがやってくれるから、（それでも描画機能について何も考えないで出来るわけ
ないですけど→ボタンなどがすでに描画機能に組み込まれているだけで）自分では描画
部分を設計しなくて済みますよね。
しかし、ゲームを作るとなると、描画部分もやはり設計しなければいけないわけです。
ライトとカメラを実現したいなら、そういうレンダラを書かないといけません。空はどうやって
描くのか、雲はどうやって描くのか、地面はどうやって描くのか、それは描画機能側で
考えてオブジェクト化しなければなりませんよね。あなたは雲を、そのへんの石や草と同じく
ポリゴンで表示→無数の微小パーティクルで表現しませんよね。あれは遠くにあるからそういう
モデリングをせずに済みます。これが「機能依存」じゃないですか？
本当にオブジェクト指向であれば、雲もそのへんの木や石と同じ仕組みで作る必要があります。
理想的にはね。それより、夜空の星なんかどうしますか。あれを点で表示できるという機能が
あれば、恒星クラスは要らないですよね。
そう言う事なんですよ。

230 ：とむ ◆0MTMwDpCZo ：03/11/28 04:47 ID:ycl3xZYL

あと、最近のdoxygenは女の子の絵も吐いてくれるんだね…。
ちょっとうちのソースコードかけてみようかな。どんな子が出るかな。ワクワク。

231 ：とむ ◆0MTMwDpCZo ：03/11/28 05:05 ID:ycl3xZYL

ちょっと雲や恒星は例えが極端すぎましたね。

例えば、３Ｄアクションゲームを作るとしましょう。見通しがいい場所では、遠くの山も
見えるでしょう。あなたは、この山を、今カメラの近くにある木や石や川などを備えた、
同じレベルのモデルで表現しますか？
普通はしませんよね。なぜか。それだけ描画やメインメモリが耐えられるほどのハードが
無いからです。あるのなら、概念的には山だって石や木や土の集まりですから、そう
表現したっていいはずです。しかし、これは設計段階ですでに「山」クラス、あるいはもう
「背景画像」クラスにしてしまいますよね。
カメラ近くの木や石は、それぞれ「木」「石」クラスにしても、遠くの山はそうはしません。
先ほどの雲だの恒星だのはその話の延長です。

ここのところに出てくる、クラス化の際の設計の段階で、機能がここまで影響してしまう
という意味が分かりますか？　描画機能が影響しないなら、「山」で一つのクラスは作り
ません（まあ普通背景のオブジェクトごとにクラスを作るかどうかは別問題ですが、それ
はさておくとして）。
同様に、地面のような「水平線でしかクリッピングされないオブジェクト」も、スカイドームも、
水という物を表現せずに「水面」だけを板で表したオブジェクトも、全て機能による要請です。
一見自然をそのままオブジェクト化しているように見えて、もうレンダリング機能に依存して
しまっているのですよ。それをずっと言ってるわけです。

232 ：名前は開発中のものです。：03/11/28 05:12 ID:zaH9w9Q9

(´-`).｡ｏＯ（この人はゲームではなく大自然でも分析/設計してるんだろうか・・・・・・？）

233 ：とむ ◆0MTMwDpCZo ：03/11/28 05:14 ID:ycl3xZYL

>>232
いやだから、ゲームを設計しているのだから、モデル化の際にある程度は
マシン・描画部の機能の影響を受けるという話ですよ。

234 ：198：03/11/28 05:15 ID:HpWT7QQb

> 本当にオブジェクト指向であれば、雲もそのへんの木や石と同じ仕組みで作る必要があります。
もうね、寝ます。

235 ：136：03/11/28 05:20 ID:nd1zJQM4

>>231
もう、胡散臭くなってきてるからその辺でやめときなよ。
機能に依存してるんじゃなくて自分が表現したいかどうかの問題だよそれは。
もう重箱の隅しかつつけないでしょ？お互いに。

236 ：名前は開発中のものです。：03/11/28 07:11 ID:a2uu49Jr

>>234
おはようございます、朝ですよ。
起きてください

237 ：名前は開発中のものです。：03/11/28 10:17 ID:CwuFN/pR

>>232
OO超自然主義？

ょうしぜん-しゅぎﾃｳ- [6] 【超自然主義】
〔supernaturalism〕
感覚的および知性的認識でとらえられる自然的存在を超えた，
何らかの存在を想定し，その認識は信仰・啓示・直覚などにより
得られるとする哲学上および信仰上の態度。

238 ：名前は開発中のものです。：03/11/28 11:03 ID:pquTMhsN

設計が機能に依存するというのは確かにそのとおりなんだが・・・
機能を考えないとOOに関する話ができない＝機種限定とされちゃうと
雑談のネタとしてはつらい部分が多いしなぁ。

もっと機能に限定されないメタな部分での話じゃないと
「いや、Ｄ３Ｄじゃそれは無理だからこうすべき」とか
「PS2ではこの部分はこうだから・・・」という実装面の話に終始して終了しまうと思うが。

239 ：とむ ◆0MTMwDpCZo ：03/11/28 13:00 ID:ycl3xZYL

おはようございます。

>>238
いや別にそんな細かい機能限定の話とかしようってことじゃないんですよ。
いくら設計段階で機能を無視しようと言っても、最低限どうやって描画するかくらいは
機能に依存するということと（３Ｄはポリゴンで表示する、とか）、描画そのものも設計
しなくてはならない、という話ですよ。

確かに機種限定してしまうと話のネタとして辛いというのはあるけど、全くハードの機能を
考えずに設計するというのも「OOとゲームプログラミング」という話の方向とはやはり
違う気がしますが。
概念上はどんなゲームでも作れちゃうしね。それが無理なのは、ハードの性能やプロ
グラミング技術による「機能」の制約が入るからであって。

240 ：名前は開発中のものです。：03/11/28 13:30 ID:p0iS/mJU

一段落したようなのでアイキャッチ置いときますね。

　 ( ´･ω･)
　 ( つ旦O
.　と＿)＿)

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　-　OOとゲームプログラミング Role2　-

241 ：名前は開発中のものです。：03/11/28 17:16 ID:U9R46wZq

たぶんずっと平行線だろうからその意欲をゲーム作成に向けたほうがいいと思うよ。

242 ：名前は開発中のものです。：03/11/29 01:38 ID:+yRGbKXp

グラフィックなんかをコンテクスト非依存と位置づけしてFlyweightのハンコにしちゃう
のってなんか気に入らないな。gemsの2でも似たようなデザインが載ってるけど。
なんかいいアイデアがないか。

243 ：名前は開発中のものです。：03/11/29 03:46 ID:5hWAbCc9

Flyweightのハンコ？

244 ：名前は開発中のものです。：03/11/29 04:00 ID:5hWAbCc9

>>229
>ほほーう…サンプルを一つもコンパイルできないのは残念でした…；
あー、VC6ならSTLport、あとWTL7、boostが必要…だとおもった
unittestはcppunitとluaがいる
どれもランタイムはﾏﾙﾁｽﾚｯﾄﾞ or ﾏﾙﾁｽﾚｯﾄﾞ(ﾃﾞﾊﾞｯｸﾞ)でＤＬＬじゃ
ないほうに合わさってる。boost::thread使ってるんで、それだけは
libファイルをメイクしてもらう必要あり。めんどくさかったらランタイムに
DLL版を指定したほうがトラブルなくて良いかも。（なんで非DLLに統一
したんだっけかな～なんか理由があったはずなんだけど）

gametestにはDirectX8のスキンメッシュサンプルで使われてる
skinmesh1.vsh～skinmesh4.vshと、なんか適当なモーション付き
Ｘファイルが必要。tinyタンでも動くはず。（なんでアーカイブに含め
なかったかというと、gradriel.xは他人のデータの流用だから、
skinmesh*.vshはDXSDK付属のものでライセンス良くわからんから)
testmain.cppの124行目と130行目の"gradriel.x"を"tiny.x"とか、
Xファイルのファイル名に変更すればOK

この辺もドキュメントにしないと、ほんとにただ晒してるだけだな～

245 ：名前は開発中のものです。：03/11/29 05:58 ID:+yRGbKXp

>>243
うん。Flyweightは言ってみればスタンプみたいなもんだろ。
黒子のあんちゃんたち（EntityとかStateとかBehavior)が
あらかじめいろんなキャラのいろんなポーズを彫っておいたハンコを
ぺたぺた一コマごと捺していく。おんなじ見た目の例えばザコキャラなんかを
担当してる黒子同士では同じハンコを共有するのだ。

劇場で人間が演技をするのや、操り人形の劇と違って、
この劇ではあらかじめハンコとして彫っておいた演技しかできない。
泣いてるハンコが用意されていなければ、キャラは泣くことができない。

だが、ゲームとは実際にはそういうもんだな。
どんなにリアルな格ゲーでだって実装されていない技はだすことができない。
今のところはハンコによる劇に見立てるのが限界のようだ。

246 ：名前は開発中のものです。：03/11/30 01:32 ID:N9tcc+S+

いわゆる古典タスクシステムの弊害ってなんだろう？
ゲームに関する限りタスクで書いちゃったほうが楽だと思うんですが。
あと、タスクシステムって単にStateパターンと言い切っちゃって問題ないよね？

なんかゲームシステム部分の設計で他に上手いやり方ってないのかなぁ。

247 ：とむ ◆0MTMwDpCZo ：03/11/30 01:44 ID:pLks8cTy

ええと、まず古典タスクシステムというのが、どういうのを想定して話しているのかにも
よるんじゃないかな。

例の、自機とか敵機とかでタスクを作って、関数ポインタやジャンプテーブルなどを
用いてそれぞれの処理に合わせて飛ぶ、という形なのかな？

248 ：とむ ◆0MTMwDpCZo ：03/11/30 01:45 ID:pLks8cTy

あと、もしそれだったら「Stateパターン」とはちょっと違う気がします。

249 ：名前は開発中のものです。：03/11/30 01:50 ID:N9tcc+S+

>>247
>例の、自機とか敵機とかでタスクを作って、関数ポインタやジャンプテーブルなどを
>用いてそれぞれの処理に合わせて飛ぶ、という形なのかな？
自分はそれに加えて、ゲーム内の場面ごとに「メニュー画面」「オプション画面」「ハイスコア画面」「ゲーム画面」みたいに
状態に合わせて実行するタスクを切り替えるという部分までを指して「(古典)タスクシステム」と呼んでます。

なのでStateパターンでいいのかな、なんて思ってたんですけど。

250 ：とむ ◆0MTMwDpCZo ：03/11/30 01:57 ID:pLks8cTy

>>249
ああ、なるほど、もっと大枠的なものね。
それなら、マネージャ自体はStateパターンだね。じゃあ、自機だの敵機だのの話は
とりあえず置いといた方がいいかな。

弊害ねえ…。そうやって切り分けること自体は、古典というより今でも普通に使われている
普遍的パターンだとは思うけど。

というか、あなた自身が「弊害」について何か思うことがあったから書いたんじゃないの
かな。まずそれを書いてもらえると進めやすいと思うけど。

251 ：名前は開発中のものです。：03/11/30 02:26 ID:N9tcc+S+

いや、>>90-100あたりでタスクに関する話が出てたんで、気になって。
自分がシステム部分を設計する時って、いつも「とりあえず慣れてるしタスクシステムでいいや」みたいな安直な設計になってるんだけど
実は自分が知らないだけで他の奴らはもっとｵｻﾚな組み方してるんじゃないのかと思ったんで。。。

自分では弊害というほどのものは思いつかないんですよ。
なんで、いつも「タスクでいいじゃん」となるｗ

252 ：とむ ◆0MTMwDpCZo ：03/11/30 02:35 ID:pLks8cTy

ふむ…確かに>>95で「擬似タスクはやめろ」と出ているけど、正直私はその時点で何を
指して「擬似タスク」と呼んでいるのかわかりませんでしたけどね。でもその下の人には
話が通じちゃってますねえ。

多分、あなたが言っているタスクシステム、つまり仮想関数か関数ポインタか、あるいは
実行アドレスを渡して処理する形（全部本質的には一緒）は、現在でもゲーム開発では
かなり使われていますよ。多分、ね。

それ以上オサレとなると…コルーチンの考え方を導入した言語等でプリエンプティブに
組んでいる人が世の中にはいるかも知れませんが、私はあまり知りません。

253 ：名前は開発中のものです。：03/11/30 03:21 ID:N9tcc+S+

うーむ（´・ω・｀）
やはりシステム部分はタスクで、みたいにやるのがよさげですかねぇ。

まぁタスクシステムといっても単純で、以下のような感じです。
・抽象タスククラス
　基本的なタスクの機能を記述。
　親、子タスク・実行状態フラグ・優先度などを持つ
　（親子関係は優先度を利用してハッシュで管理しても良いんだけど、無理やり優先度を替えたい場合があるので別パラメータに）

・タスククラス
　実際の処理を行う部分。

・タスク管理クラス
　タスククラスの登録･削除・実行等を行う。
　管理クラスはタスクをリストで管理。
　登録･削除時に必要があれば他のクラスへの通知なども行う

ゲーム開始時に初期タスクを起動、あとは必要に応じて順次タイトル画面タスクや
オプション画面タスクを起動していく。
画面の遷移は特にSwitch等でステータスを見て切り替えるというわけではなく、
例えばタイトル画面タスクが直接オプション画面タスクを起動後、タスクの終了を
タスク管理に通知。みたいな流れでやってます。

254 ：とむ ◆0MTMwDpCZo ：03/11/30 03:31 ID:pLks8cTy

あー、どちらかと言うとシーン管理ね。
私もそこで色々悩むけど…。

そういう風に、OO的にシーンを作って、シーンの連結をシーンクラスに持たせると、
確かに差し替えや組み換えが容易になるかも知れません。

しかし、シーンをスタック構造にしたい場合、そのスタックの条件が色々変わる場合など、
結構中の記述が汚くなることがあるんだよね。
ゲームなんてユーザのやりやすさ優先で、仕様の綺麗さよりも重要だったりするから。

それと、あるシーンとあるシーンに共通するデータを読み込むのはいつかとか、
あるシーンでは動いておいて欲しくないバックグラウンドプロセスとかがあったりすると、
やっぱり汚くなるんだよね。そこを上手く解決したい…と自分でも思います。

255 ：名前は開発中のものです。：03/11/30 03:54 ID:N9tcc+S+

>あー、どちらかと言うとシーン管理ね。
いや、シーン管理に限定はしてなくてシーンもゲーム中のキャラクタもレンダラもすべてタスクです。

>しかし、シーンをスタック構造にしたい場合、そのスタックの条件が色々変わる場合など、
>結構中の記述が汚くなることがあるんだよね。
自分の場合だと、そういう場合はシーン遷移を管理するタスクが別に走りますので、
各シーンはそのタスクに自分の終了を告げるだけで遷移自体はそっちにまかせます。
で、そういうスタック的なシーン管理がいらなくなればそのタスクごとあぼーん。

>それと、あるシーンとあるシーンに共通するデータを読み込むのはいつかとか、
>あるシーンでは動いておいて欲しくないバックグラウンドプロセスとかがあったりすると
これも基本的にはデータ管理用タスクを起動して管理しますが、確かに汚くなりやすい部分ですよね。

あと、欠点といえばやはりタスクの数がかなり増えてしまうのと、デバッグがやりにくいってことですか（ぉぃ
デバッグについては現在どんなタスクが走ってるかを常に見えるようにすることである程度解消されますが、結構面倒ですねー

256 ：とむ ◆0MTMwDpCZo ：03/11/30 04:05 ID:pLks8cTy

>>255
＞いや、シーン管理に限定はしてなくてシーンもゲーム中のキャラクタもレンダラもすべてタスクです。

なるほど。それは全部一つのクラスを継承してる？
私は継承が深くなるのを避けるため、ある程度分けた方がいいかなという気がしています。
私も以前、全て一つの仕組みでやろうとしたのですけどね。でもそんなに綺麗にいきません
でした。

＞自分の場合だと、そういう場合はシーン遷移を管理するタスクが別に走りますので、
＞各シーンはそのタスクに自分の終了を告げるだけで遷移自体はそっちにまかせます。

現実的な処理ですね。
私も（今なら）そうすると思うのですが、以前そんな仕組みにして、「デバッグ時に特定の
シーンだけ呼び出す」というのが異常なまでにやりづらくなり、開発効率を落としたことが
あります。次はもっと上手くやりたいな、と。

＞これも基本的にはデータ管理用タスクを起動して管理しますが、確かに汚くなりやすい部分ですよね。

そうなんですよねえ…。なんでもかんでもタスクという事にしてしまうと、ある程度の規模で
凄いメチャクチャになってしまう。あと、どうしても処理速度足りない時に何かの特殊化を
しようとすると、やっぱり酷いことになってしまう。
何かいい方法がないか今模索中です。

257 ：名前は開発中のものです。：03/11/30 05:56 ID:XmXQnHN/

>>255
俺の場合は、基底部分は同じでも、
シーン管理、キャラ管理、ぐらいに収めるな。
所謂、システムタスクてのは、好かん。（レンダラ、入力云々までタスク化すると、デバッグし難い）
順序固定で問題なしだし。（寧ろ可変だと困る。レンダ結果とか）

やね本に、ファイバとかいうのが説明されてるね。
手つけてないけど。

258 ：名前は開発中のものです。：03/11/30 09:27 ID:sVi25JdL

>>256-257
激しく同意。
規模がでかくなるとタスクはめちゃくちゃになる。
ちょっとアレな人が組んだ部分ってほぼデバッグ不可能になる。
あと、俺も順序固定で問題ない。

259 ：名前は開発中のものです。：03/11/30 18:21 ID:qm9hWOqD

デバッグ困難てのは具体的には？

260 ：とむ ◆0MTMwDpCZo ：03/11/30 18:25 ID:pLks8cTy

>>257
ファイバ、検索してみました。以前やね氏のページに「マイクロスレッド」というのがあり
ましたが、それと似たようなものらしいですね。
実質的にコルーチンだと思われます。>>252で私もコルーチンの話をしましたが、世の中
実戦投入している人もいるようだすね。ファイバクラスの実装を公開している人もいました。

個人的には非常に興味のある分野ですが、それこそ何かが上手く行かなかった時の
管理や、デバッグが異常に難しくなるので、現実的かどうかは…。

261 ：名前は開発中のものです。：03/11/30 21:25 ID:8v/2nacI

ファイバってスタック領域をどれくらい取ればいいのかで何時も悩む。

262 ：名前は開発中のものです。：03/11/30 22:47 ID:QCghdS9k

Windowsの場合は

DirectX　　　　　　→Veiw

Windows（API)　→System
File（API)　　　　→System

Data　　　　　　　→Document

GameMain　　　→System
GameSystem　→System

Net（Winsock）　→System

だな・・・・

263 ：名前は開発中のものです。：03/11/30 22:57 ID:sVi25JdL

>>262
DirectXがViewで
Win32APIがSystemって意味わかんない。

DirectSoundとかDirectInputとかDirectPlayとか脳内から消えちゃってるわけ？

DirectXもSystem（？）じゃない？

264 ：名前は開発中のものです。：03/12/01 12:11 ID:t2gG8J7V

ファイバ、なにげ良さそうなんだけど実戦にはむかなくない？

・ファイバ機構自体の信頼性
割り込みや例外、データの裏読みなどによる不具合はでないのか？

・複数環境での信頼性
PCゲーでの多様な環境（OS、ビデオカード、CPUの性能等）でも安定して動作するの？

・導入の難しさ
開発メンバー全員がマイクロスレッドでのプログラミングを理解してなきゃ意味がないような気がするが・・・

・・・といった点がいまいち解らん。
俺的にはやね氏、&o氏のテキストやstacklessPythonのコミュニティあたりから草の根で広まって
実戦での結果報告が増えるまでは怖くて手が出せんな。

265 ：264=255：03/12/01 12:16 ID:t2gG8J7V

>>259
自分の場合、タスクどうしの依存率が高かったり、順序固定でないと不具合が出るような場合です。
自分だけでやれれば良いんですが複数人での開発となるとどうしてもそういった
タスク同士の依存関係に悩まされることが多く、その部分でのバグを最後まで引きずることがあります。
それこそ「動いてるタスク達には触るな」みたいな状況に陥るという・・・

ダメな開発の見本ですな（＾＾；

266 ：258：03/12/01 13:21 ID:fWhoJRFl

>>265
俺のところもそれ。
いっそタスク使わないほうがいいと思ってタスク使わないで組むようにしたら
バグの数がかなり減りました。

＃もし、タスク同士の依存関係まできっちり管理できるような方法があるなら別にタスクでもいいのかな？
＃同時に依存関係を管理するタスクでも流すとか考えたけどさらにバグを被せることになりそうな予感。
＃だからといって、ただでさえ複雑なタスクにこれ以上複雑なシステムを入れるのは逆効果な予感。
＃結局、タスクやめちゃいました。

267 ：名前は開発中のものです。：03/12/01 14:08 ID:i2bY60WS

こんぷゆーたのような決定論的世界に関して「怖い」とか言い出すインチキ野郎が
俺は嫌いだ。

268 ：名前は開発中のものです。：03/12/01 14:54 ID:d3PGhkj9

タスクの状態遷移と依存関係のスパゲッティをすっきりと
解決できる技術があるなら喜んで導入したい。

漏れはタスクしか思いつかないへたれです。。

269 ：名前は開発中のものです。：03/12/01 16:05 ID:BBKzfG41

>>267
怖いのはミスをする人間の方ですな。

270 ：名前は開発中のものです。：03/12/01 19:52 ID:gEYe0MkS

タスクなりエンティティなり使えってところまでは誰でも言うし、実践するんだが、
問題はその後なんだよなあ。
みんな泥臭い実装になってしまってるので説明したがらないと見た。

271 ：258：03/12/01 23:36 ID:fWhoJRFl

>>268
タスクって状態遷移や依存関係なんかこれっぽっちも管理してくれないですよね。
かといってこれ以上複雑にもできない（する意味がわからない）というジレンマはあると思います。

駄目な技術（どうしても複雑になってしまうという意）とわかっていて使い続けるのも
なんか発展性がないので、一度タスクを使わずに組んでみてはいかがでしょうか？

なんていうか表現は難しいんですけどね普通に組むんです。普通に。
いままでタスクを使っていたけど使わないで組んでみたらどうだろうか
または使わないで組むにはどう組めばいいんだろうかと考えることも
大事なことだと思います。

＃タスクで上手くいっている人はそれでいいのではないでしょうか。

272 ：名前は開発中のものです。：03/12/01 23:56 ID:C/dZ3PnV

ゲーム内の平行な処理をOSにプリミティブな方法で処理してるの？
信じられん。どれくらいのオーバーヘッドと複雑性が生じるのか…。

タスク上で実行するスクリプトで結構処理できない？
(スクリプト？マクロ？シーケンス？呼び名は場所によりけり？)

273 ：名前は開発中のものです。：03/12/02 00:11 ID:9PwqRnuC

>>272
>ゲーム内の平行な処理をOSにプリミティブな方法で処理してるの？
もしかして本物の「タスク」のことをいってますでしょうか？
そっちじゃなくてここで話題になっているのは「擬似タスク」とかいうものです。
「タスクっぽい動作をする」ものです。
略して「タスク」とか呼ぶと確かに混乱します。
ググるとちょっとは当たりますので詳細はそちら↓で。

http://www.google.co.jp/search?q=%E6%93%AC%E4%BC%BC%E3%82%BF%E3%82%B9%E3%82%AF&ie=UTF-8&oe=UTF-8&hl=ja&lr=

274 ：名前は開発中のものです。：03/12/02 00:11 ID:IJLoSRTX

状態そのものが次の状態を決定するのはタスクならでは。斬新でよい。
見方によっては見やすいし便利。
でもどっちにしても状態遷移図は別に書いておいたほうがいいよね。

依存関係はタスクを全部一緒のコンテナに並べてしまわないで、
タスクの中のタスクみたいなものをつくって、再帰構造みたいな、
ツリー構造みたいな、Facadeみたいな風にしてやったらどう？

275 ：とむ ◆0MTMwDpCZo ：03/12/02 00:19 ID:LNpT/+Rj

>>273
もしかして>>272さんは、そのちょっと前に出てきていたファイバやコルーチンに対する
レスとして書いているのかも知れません。
これらのアイデアは、スレッド内スレッドを発生させて並行的に処理します。従って、擬似
タスクとは異なる仕組みです。
私は実装した事はないのですが、聞くところによるとコンテクストスイッチによるオーバー
ヘッドは、意外なほど小さいそうです（そりゃゼロじゃないでしょうが）。

276 ：名前は開発中のものです。：03/12/02 00:51 ID:hSDazT4V

＞スレッド内スレッド
擬似スレッドだね(Windows3.1時代の擬似マルチタスクと同じ意味での)。

全レジスタpush, popするくらいのオーバーヘッドで利用可能。
まぁ、関数呼び出しより遅いのは確かだけど。

277 ：とむ ◆0MTMwDpCZo ：03/12/02 00:57 ID:LNpT/+Rj

>>276
まあ理屈的にはそうなんですけど、実際には再入可能にするために内部的なワークを
必要としたり、もしプリエンプティブ（タイムスライス）な制御をした場合、ロックをどう
制御するかなどの問題がかなり発生しそうな雰囲気で、多分色々小細工をしないと
高速なスイッチは出来ない感じです。

278 ：名前は開発中のものです。：03/12/02 01:01 ID:KOFDJ5SB

>>276
それって噂に聞くマイクロスレッドとかいうのとは違うの？

279 ：名前は開発中のものです。：03/12/02 01:03 ID:hSDazT4V

＞必要としたり、もしプリエンプティブ（タイムスライス）な制御をした場合、ロックをどう
それがスレッドなんだって。ファイバをロックしたらその時点でデッドロックだよ…

280 ：名前は開発中のものです。：03/12/02 01:03 ID:KOFDJ5SB

と思ったら数レス前で話題になってるなぁ

281 ：名前は開発中のものです。：03/12/02 01:03 ID:hSDazT4V

>>278
同じです。多分。

282 ：とむ ◆0MTMwDpCZo ：03/12/02 01:08 ID:LNpT/+Rj

>>279
いや、ファイバのロックというより、ファイバが何かをロックした時の状況です。

でも、確かにそこまで考えるとなると、「マイクロスレッド」というよりただの「スレッド」
ですね。
結局、全てのプログラムをファイバ化して動かすわけじゃないんだから、そのへんは
柔軟にやればいいだけの話か…。

283 ：名前は開発中のものです。：03/12/02 02:13 ID:GpZaXC6b

>>271
>タスクって状態遷移や依存関係なんかこれっぽっちも管理してくれないですよね。
そこでマイクロスレッド、またはファイバ、またはスクリプトのコルーチンですよ
（依存関係の管理にはならないけど、状態遷移の扱いは遙に楽になる）

・状態遷移
switch(state) {
case NORMAL_STATE:
　　random_walk();
　　if(found_enemy()) state = CHASE_STATE;
　　break;
case CHASE_STATE:
　　chase();
　　if(distanve_to_enemy() < 1.0f) state = ATACK_STATE;
　　else if(distanve_to_enemy() < 10.0f) state = NORMAL_STATE;
　　break;
case ATTACK_STATE:
　　atack();
　　if(distanve_to_enemy() > 1.0f) state = CHASE_STATE;
　　break;
}
もちろん、switchでなく関数ポインタ、関数オブジェクトでもいい。

284 ：283の続き：03/12/02 02:16 ID:GpZaXC6b

おんなじことをファイバなら、state変数がいらない
while(1) {
　　random_walk();
　　while(found_enemy()) {
　　　　yield();
　　　　chase();
　　　　while(distanve_to_enemy() < 1.0f) {
　　　　　　yield();
　　　　　　atack();
　　　　}
　　　　if(distanve_to_enemy() < 10.0f) break;
　　}
}
スクリプト(lua)のコルーティン
function action(self)
　　while true do
　　　　self:random_walk()
　　　　while self:found_enemy() do
　　　　　　coroutin.yield()
　　　　　　self:chase()
　　　　　　while self:distanve_to_enemy() < 1.0 do
　　　　　　　　coroutin.yield()
　　　　　　　　self:atack()
　　　　　　end
　　　　　　if self:distanve_to_enemy() < 10.0 then break end
　　　　end
　　end
end

285 ：とむ ◆0MTMwDpCZo ：03/12/02 02:17 ID:LNpT/+Rj

ゲームでのタスク同士の状態遷移でめんどいのは、それを「いつどこで」処理するか
ですね。

つまり、そのフレーム内でスイッチしてしまうのか、次フレームの頭でスイッチするのか。
そのフレームの描画を行ってからスイッチするのか、その前なのか。
スイッチした後の処理を１ステップ行ってから描画するのか、それとも処理は次フレームに
回すのか。

リフレッシュレート固定のコンシューマなどの場合、必ずフレームを１単位にすることが
多いので、このへんの切り替えで少し悩みます。

286 ：283：03/12/02 02:27 ID:GpZaXC6b

この手の処理で馬鹿でかい有限状態マシンを書くのはバカらしい
から、ファイバ等を実践投入したいなぁ、と思ってたんだけど、
最近はコマンド類(この例でいえばrandom_walk、chase、distance_to_enemy…)
をC/C++ネイティブの関数なりにバインドするようにしておけば、luaコルーティン
で十分、という気がしてきた。

有限状態マシンのほうが望ましい場面もあるだろうけど、そのときはこれで。
http://www.s34.co.jp/cpptechdoc/misc/smc/smc_j.html

287 ：名前は開発中のものです。：03/12/02 02:36 ID:GpZaXC6b

>>282
私が知ってるファイバは協調型で、明示的に処理を明渡すタイプで、
多分このスレの流れからして、その協調型が望まれていると思うんですが、
このタイプだと、デッドロック回避策が難しい、と言うことはないかと
つか、わざとやらない限りデッドロックしないんでは

if(a = lock_rsrc() && yield() && b = lock_rsrc()) proc(a, b);
ついうっかりではこんなことしないと思う

288 ：とむ ◆0MTMwDpCZo ：03/12/02 02:40 ID:LNpT/+Rj

>>287
まあそうですね。実際ゲームにプリエンプティブな並行処理を導入している人がいるとは
思えませんし。
ただ、あそこで言いたかったのは、「デッドロック回避が難しい」ではなくて、コンテクスト
スイッチ時のオーバーヘッドにそこが含まれる可能性がある、です。
ま、大した話ではなかったので、さらっと流して下さい。

289 ：名前は開発中のものです。：03/12/02 02:48 ID:GpZaXC6b

>>285
>スイッチした後の処理を１ステップ行ってから描画するのか、それとも処理は次フレームに回すのか。
あー漏れもおんなじことで悩んだ気がするけど、あんまりにもこまごまとしたことだったんで忘れた。
誰か、スイッチングのタイミング差で困った！っていう具体的な思い出のある人いないかい？

290 ：名前は開発中のものです。：03/12/02 02:50 ID:ndLyPrRm

>>285,286
なるほどねー。
状態遷移表はメニュー処理なんかでよく使ってたけど、それをタスクの遷移に使うわけか。
ゲーム全体のシーン遷移のようなある程度決まった部分にはこの方法が使いやすそうだね。

で、もうちっと複雑な要素の入ってくるキャラクタの行動パターンのような部分には
スクリプトでのコルーチンを採用・・・ってのが現実味のある実装パターンかなぁ。

291 ：とむ ◆0MTMwDpCZo ：03/12/02 02:55 ID:LNpT/+Rj

>>289
結構色々ありましたよ。
例えば、定期処理→描画みたいな仕組みにしてあったとして、あるタスクがそこで終了
したとします。当然終了時には自分が使っていたデータは破棄するのですが、その後
そのタスクへの描画が発行されてしまうと、当然バイオレーションが起きます。
じゃあ描画しないようにするとなると、１フレ隙間が出来たりします。隙間が見えないよう
にするために継ぎ目なく次のタスクを起動したりすると、「前のタスクの終了」と「次の
タスクの起動」が描画直前のタイミングで両方発生し、処理がやたら重くなって下手する
と処理落ちします。これじゃ１フレの穴を防いだ意味がなかったりして（ヒープの破棄と
確保を同時にやると結構遅い）。

そんな苦労があちらこちらに…。

292 ：名前は開発中のものです。：03/12/02 02:59 ID:ndLyPrRm

ところで、タスクシステムだとかコルーチンだとか状態遷移表なんて話題は
このスレの守備範囲に入るのだろうか・・・(^-^;

まぁ、面白いし、役に立つし、その話題で別スレ立てるまでも無いからからいいけどねｗ

293 ：名前は開発中のものです。：03/12/02 03:02 ID:ndLyPrRm

>隙間が見えないようにするために継ぎ目なく次のタスクを起動したりすると、
>「前のタスクの終了」と「次のタスクの起動」が描画直前のタイミングで両方発生し、
ぐは。超ありがちｗ
つーか、涙でかすんでレスが読めなくなりますた（ぉぃ

294 ：とむ ◆0MTMwDpCZo ：03/12/02 03:08 ID:LNpT/+Rj

>>292
ええ、ここ数日はなんか中身が結構面白いですね。内容は確かにスレに沿っているのか
微妙かも知れませんが、OO的に組むとどうしてもこういう問題が出てくるので、ある意味
正しいんじゃないでしょうか。
前スレなんかは、ひたすらC++ vs Cみたいな戦いで、今スレと毛色が全然違ってて
面白いです。

>>293
ありがちですよね。
で、タスクの起動とか終了って、複数の奴が同フレで一気に起こりがちで、そのへんの
処理が重い奴が重なると目も当てられなくなる。
それを回避するために、タスクごとにグループ分けして、「Ａグループの終了処理が全て
終わったらあるメッセージを管理部に返す。それを受けると管理部は次フレからＢグルー
プ終了していいよというメッセージを出して…」みたいな作りになっちゃうんだよね。

そうなると、そもそもオブジェクト間の依存関係をなくして、積み木みたいに組みましょうよ
というのがOOの理想であるのに、何やってんだよオイみたいな…現実と理想の狭間みた
いな…やべ、涙出てきました（笑）

295 ：126：03/12/02 03:19 ID:4GzvbMkU

>>128
えっと、しばらく見てなかったんですが、話がかなり良い雰囲気で進んでますね
もう私は内容は理解してませんが、きっと良い結果を生むと思いますよ。がんばってくださいね

296 ：名前は開発中のものです。：03/12/02 03:33 ID:IJLoSRTX

>>295
わからないことがあったら聞いたほうがいいよ。

297 ：名前は開発中のものです。：03/12/02 04:04 ID:zLYrpNf9

>>291
>例えば、定期処理→描画みたいな仕組みにしてあったとして、あるタスクがそこで終了
>したとします。当然終了時には自分が使っていたデータは破棄するのですが、その後
>そのタスクへの描画が発行されてしまうと、当然バイオレーションが起きます。
漏れの場合、そういう悩みはないな。
各オブジェクトのアップデートではdrawなんてな名前のメソッド呼び出してても、実際は
描画実行チェーンに繋ぐだけで、描画は全オブジェクトのアップデートが終わってから
一ヶ所で行う構造になっていて、その描画チェーンに繋がれてるパケットはタスクの
ワークとは別物で、スマートポインタで保持している。タスクが死んでも描画チェーンが
保持している限り解放されず、描画終了後解放されるんで

298 ：とむ ◆0MTMwDpCZo ：03/12/02 04:09 ID:LNpT/+Rj

>>297
一般的にはそうしますよね。
だから私のその話は、実に簡単に防げる事態ですね。その後ろに書いてあることの
方が問題なわけで。

と言いつつそういう話を書いたのが、私が過去そういうミスをやらかしたことがあるって
だけの話なんですけどね（笑）。
あれはなんでだったんだろ…良く覚えてないけど…。普通はデータが破棄された
オブジェクトはデストラクトされているから、draw単独で呼ばれることはあり得ないです
よね。なんでやっちゃったんだろ。
なんか多分また泥臭い実装をしていて、だと思います。

299 ：名前は開発中のものです。：03/12/02 04:16 ID:zLYrpNf9

>>297
>その後ろに書いてあることの方が問題なわけで。
むう。これはメモリプールを導入、じゃダメ？
メモリの解放・確保じゃなくて、コンストラクト・デストラクトが
重いんだとしたら意味無しだけど。

300 ：名前は開発中のものです。：03/12/02 04:35 ID:zLYrpNf9

>>295
燃料投下はいつでも歓迎
なんせここは2chでも有数の過疎板だからな(´・ω・｀)

301 ：名前は開発中のものです。：03/12/02 05:13 ID:4GzvbMkU

>>296
いえ、今はそんなレベルではないので・・・将来何かあったら質問させてもらいます
>>300
すいません。燃料じゃなくて、本当にただの感想なんです。
前に見た時より話し方が建設的になっていたので、がんばってね～とｗ
あんまり書き込むと邪魔になるので、これで消えますね

302 ：名前は開発中のものです。：03/12/02 08:10 ID:9PwqRnuC

>>297
>タスクが死んでも描画チェーンが
>保持している限り解放されず、描画終了後解放されるんで
すでに死んでるオブジェクトが描画チェーンに入ってるってことですよね？
描画終了後で無いと死んでるオブジェクトがその場で「死んでる」と認識できないのは何故でしょうか？
「死んでる」状態が確認できた時点で描画チェーンから抜かなければなりませんよね。
また、このフレーム中にそのオブジェクトにアクセスしたオブジェクトはそのオブジェクトが「死んでる」と
いうことをどうやって認識しているのでしょうか？できないとバグりますよね？
この状態はうちではバグ扱いです。

こうなってしまう事情はなんとなくわかります。ただ、この状態って危険ですよね。

303 ：名前は開発中のものです。：03/12/02 10:58 ID:ECO0sl+K

>>302
いわゆる「参照カウンタ」って言う奴のおかげですね。
詳しい仕組みは「スマートポインタ」とかでぐぐって（俺も説明できるほどよくわかってないので)

304 ：とむ ◆0MTMwDpCZo ：03/12/02 12:59 ID:LNpT/+Rj

>>299
いや、メモリプールはかなりの効果のある手段ですよ。
私も最初は馬鹿正直にヒープ確保していて、「こりゃ駄目だ」と思いました。
しかしメモリプールであっても、それも馬鹿正直にOOに基づいて設計し、相互依存を
減らしながらと考えていると、やっぱどっかしらに問題出てきちゃうね。

あとはそう、問題がメモリの確保と解放だけじゃない場合とかね。
何かの関数発行が連続して続くとか、ヤバかったのが「ある小さな圧縮データを１フレで
展開してくれるといいな」って感じのコンストラクタ（笑）。コレはマジヤバイ。
でもそれをバックグラウンドでやらせるほど大げさにしたくなかったので仕方なく…。

まあ問題は色々ありましたわ…。繰り返すけど、メモリプールはかなり有効な技術。
しかしあれも根本的にはOO的思考から少しズレたところにある技術であるような気が
しないでもないです。

305 ：名前は開発中のものです。：03/12/02 16:56 ID:9PwqRnuC

>>303
わかっていっています。
ただその状態がすでにバグっている（もしくは危険）といいたいわけです。

306 ：297：03/12/02 19:56 ID:7ozFLNGq

いや、スマートポインタで管理している以上、その状況は折込済みの
正当なもの。

307 ：わむて ◆WAmuTEuQD. ：03/12/02 20:10 ID:+vX0Efcl

　　　　　　＿__　　　
　　　　＜_葱看＞ヽ
　　／　I ( Ｘ .)) i　＼
　　　　ﾉゝ｡∀ﾟﾉﾊ　　　　みるまらー
　　　　　ノ(::::::)っ　　　　
　　　　　　/::::ﾍ
　　　　　　しし
　　　　　　┃」|

308 ：名前は開発中のものです。：03/12/02 22:08 ID:9PwqRnuC

>>306
そんなものが免罪符になるわけがないです。

309 ：297：03/12/02 22:31 ID:7ozFLNGq

すまん、俺が上げちまったばっかりに…＿|￣|○

310 ：297：03/12/02 22:33 ID:7ozFLNGq

>>308
???
なんで？

311 ：名前は開発中のものです。：03/12/02 23:00 ID:9PwqRnuC

>>310
きちんと制御できてるプログラムなら>>302のような状態はおかしい。

312 ：名前は開発中のものです。：03/12/02 23:49 ID:IJLoSRTX

よくわからん。>>9PwqRnuCは主張を一回整理して示しておいておくれ。

313 ：名前は開発中のものです。：03/12/02 23:54 ID:y1Pa0X0F

>>305
>ただその状態がすでにバグっている（もしくは危険）といいたいわけです。
お前、多分「参照カウンタ」さえも理解できていないだろ？

314 ：名前は開発中のものです。：03/12/03 00:00 ID:bmqPDPad

>>313
？
>>302をもう一度読んでみてください。
正しく動いてるプログラムに見えますか？
正しく動いてるように見える、というなら議論の余地はないです。

315 ：名前は開発中のものです。：03/12/03 00:02 ID:i72BdtG3

>>314
一体どこが正しくないんだ？

316 ：名前は開発中のものです。：03/12/03 00:04 ID:a3mbT/7R

おれもダメな理由がわからん。
一度噛み砕いて説明して欲しいな（理解力に乏しい香具師なので）・・・。

>>302の状態がおかしいというのは、タスクが死んだ後も描画命令が残ってるという
現象そのものが起こってはならない(バグ)ってこと？

理想的にはそうなんだけど、現実は描画命令を発行した次のフレームで実際の描画が行われたりするわけじゃん。、
しかも、それを見越してタスク側で描画をスキップしたりオブジェクトの削除を遅らせるような泥臭いことはやりたくないわけよ。
そんで、スマートポインタにその辺の処理は任せたいと思ってるんだが。

スマートポインタ側で描画終了を待って描画オブジェクト（描画用データへのポインタ）を
キッチリ始末できるのなら、それは「きちんと制御できてる」ってことになるんじゃないのか？

317 ：名前は開発中のものです。：03/12/03 00:06 ID:i72BdtG3

>>314
本当に分からないなら教えてやる。

>また、このフレーム中にそのオブジェクトにアクセスしたオブジェクトはそのオブジェクトが「死んでる」と
>いうことをどうやって認識しているのでしょうか？

参照が切れた時点で。

318 ：名前は開発中のものです。：03/12/03 00:13 ID:fcFbp4q0

つまり、内部状態として「死んで」いても、さらに他のメソッドが呼ばれる可能性を
考慮して作らないといけないということですね。

319 ：名前は開発中のものです。：03/12/03 00:15 ID:1i0ywH0b

>>302
> すでに死んでるオブジェクトが描画チェーンに入ってるってことですよね？

「描画チェーンに繋がれてるパケットはタスクのワークとは別物」
って書いてあるのが見えてないのかな？

それとも、
本体の死んだオブジェクトに対応するモノが描画されてしまう
のがバグだっていうことかな？

320 ：302：03/12/03 00:21 ID:bmqPDPad

うーんレスを書いてくれた人に受け答えしちゃうと話がずれてきそうで面倒ですね。
（とはいえ、レスありがとうございます。>レスくれた人）

単純に>>302の状態って「バグってる」っていいませんか？
（後でどうつじつまを合わせようがどうだろうが）
直そうとか気持ち悪いとか思いませんか？
思わない？（もしかして時代はそうなの？）
(　´∀｀)ｱﾊﾊﾊﾊﾅﾗｲｲﾔﾎｯﾄｲﾃｸﾚｼﾞｬｰﾈｰ

321 ：名前は開発中のものです。：03/12/03 00:22 ID:i72BdtG3

>>318
たとえば、お前のおかあちゃんが生命保険に加入していて、
３０年もコツコツ支払いをしていたとする。
ある日、かあちゃんが死んでしまったので、お前が保険会社に
支払いの請求をしたところ、こう言われた。

「加入者は既に死んでいます。
当然死者との間の契約などは成立し得ません」

お前、こう言われたら頭にこないか？

322 ：名前は開発中のものです。：03/12/03 00:28 ID:1i0ywH0b

>>321
質の悪いたとえを持ち出さないで下さい。

323 ：名前は開発中のものです。：03/12/03 00:35 ID:kLXAiw8j

オブジェクトが死ぬのは、deleteされたとき
キャラが死ぬのは「死に」状態になったとき
いっしょにするのは良くない。

324 ：名前は開発中のものです。：03/12/03 00:35 ID:i72BdtG3

>>322
何か変？

描画命令を発行した後に描画対象が死んだから
その命令を取り除くってのは、そういう作業だろ？

325 ：297：03/12/03 00:45 ID:0IsBwYpG

>>321-322
流れるような突込みにﾜﾛﾀ

いや、321のたとえは俺も分かる。297で書いた俺の設計は
ゲームオブジェクトが描画パケットを発行して、描画サブ
システムは発行者の生死に関わらず描画を行うという
「契約」なんだから。

やっぱり俺には302氏のレスは「加入者は既に死んでいます。
当然死者との間の契約などは成立し得ません」と同じぐらいの
屁理屈に聞こえる。

なんか、根本的なところで思い違いしてない？

326 ：とむ ◆0MTMwDpCZo ：03/12/03 00:49 ID:9GJE+0AN

>>302
>>297さんのやり方では、それはバグではありませんよ。
完全にデストラクトされたオブジェクトは、>>297さんのやり方をもってしても描画はされ
ません。
>>297さんのやり方は、１フレーム内で（例えで言うなら）以下の作業を行うのですよ。

オブジェクトfoo
　　・処理中に、自分自身の役目が終わった事が判明すると、終了フラグを立てる。
　　・そのフレームの描画だけは行う。
　　・描画後に、本当のデストラクタを起動する。

　実際にはフラグではなく参照カウントで行っているとの事ですが、現実的には自分
自身がそこで破棄されなければいけない事を何かで通知する必要があるでしょう。
　重要なことは、自分自身を破棄しなければいけない事が判明したそのフレームでも、
いったん最後の描画は行ってから破棄するという事ですよ。
　全然バグではありません。

327 ：とむ ◆0MTMwDpCZo ：03/12/03 00:54 ID:9GJE+0AN

…と書いたものの、「パケット」と呼んでいるところを見ると、違うかも知れませんね。
実際にアップデート処理の時点でデストラクタは呼んでしまうのかも知れません。
　しかし描画手順、データ（あとは座標など）は形式化されたパケットデータとして、
参照カウンタ構造を持ったバッファへのリンクを含んだ状態で生成するのかも知れません。

描画メソッドはそのパケットを解析して表示するだけなので、元オブジェクトが完全に
メモリからなくなっていても問題がないのかも知れません。
そしてパケットに含まれたデータは必ず毎フレームReleaseするので、元オブジェクトからも
参照されてない状態では消滅する、と。

違いますかね？

328 ：名前は開発中のものです。：03/12/03 00:55 ID:1i0ywH0b

>>326
「描画チェーンに繋がれてるパケットはタスクのワークとは別物」
って書いてあるんだから、それはちがうんじゃない？

329 ：とむ ◆0MTMwDpCZo ：03/12/03 00:57 ID:9GJE+0AN

>>328
あっ、それを見落としていたので、>>327に別の予想を書いておきました。

330 ：328：03/12/03 00:57 ID:1i0ywH0b

ｱｧ､ﾂﾗﾚﾁｬｯﾀｼﾞｬﾅｲｶ｡

331 ：とむ ◆0MTMwDpCZo ：03/12/03 01:02 ID:9GJE+0AN

>>330
失礼しました。>>297さんが言っていた方式は、大体>>327で書いたようなやり方ですよね？
あなたはどう思います？

332 ：名前は開発中のものです。：03/12/03 01:14 ID:1i0ywH0b

描画処理と状態変化処理は完全に分けて、
描画処理は状態変化を起こさないという掟にしておけば、
このような泥臭い話もなくなるのではないか、
と思います。

333 ：名前は開発中のものです。：03/12/03 01:16 ID:kLXAiw8j

普通しないだろ！って思ったが、フレームスキップを行う環境で、
点滅をちゃんとさせるために、描画処理ないでカウント処理をしたのを思い出した。

334 ：297：03/12/03 01:17 ID:0IsBwYpG

>>331
えーと、補足すると「ゲームオブジェクトが発行する描画パケット」は高レベルなもので
（つまり、そこからさらにGPUに向けて発行される低レベル描画パケットはバッファ
に溜め込まれてから、毎フレームフラッシュされる、いってみれは毎フレーム破棄される
のかもしれませんが）、毎フレーム生成･破棄されるのではなく、領域は使いまわされます。
ただ描画チェーンは毎フレーム描画終了後クリアされるので、ゲームオブジェクトは毎フレーム
パケットをチェーンに登録する必要があります。
こうする事で、ゲームオブジェクトから描画発行（描画パケットはゲームオブジェクトと描画チェーン
の両方から参照されているので参照数２）→ゲームオブジェクト破棄（描画パケットは描画チェーン
のからのみ参照されているので参照数１）→描画終了（描画チェーンがクリアされ、描画パケットの
参照数は０。ここで解体される)という感じで、上手くいきます。

335 ：とむ ◆0MTMwDpCZo ：03/12/03 01:25 ID:9GJE+0AN

>>334
なるほど…。
あ、私が>>327で「毎フレームReleaseする」と書いたのは、「参照カウンタを減らす」の
意味です。言いたかった事は、>>334で書かれている事とほぼ一緒です。

しかし、描画パケットが頂点やテクスチャへのアドレスしか含まないのであれば、
タスク単位でそれらを消滅させる必要はなさそうですね。普通頂点やテクスチャなど
大きなデータは、もっと大きな単位で読み込んだり消したりしますからね。

高レベルパケットを定義してそれを受け渡す、というやり方はいいかも知れません。
私はそんな風にはしていませんでした。参考になります。

336 ：297：03/12/03 01:32 ID:0IsBwYpG

>>332 >>335
高レベル描画パケットをスマートポインタでやり取りするのは、状態変化のタイミングを
描画処理から切り離すための方策、ってとこですかね。
描画システムは描画に必要な情報が手に入れば描画できるんで、あらかじめ
その部分をゲームオブジェクトから切り離しておく、と。

337 ：名前は開発中のものです。：03/12/03 01:43 ID:lXdZiPyj

>316が言ってた
>>>302の状態がおかしいというのは、タスクが死んだ後も描画命令が残ってるという
のが、俺も気になるが、まあこれは好みの問題か。

338 ：とむ ◆0MTMwDpCZo ：03/12/03 01:46 ID:N/++X+5i

>>336
しかし、考え方としてはあまりOO的ではないかも知れませんね。
描画とゲームオブジェクトの切り離しはいいのですが、一般的なOO的手法である、
「描画部で一括して、そのクラスの描画メソッドを次々に呼び出す」というやり方
（多分>>302さんはこのやり方のみイメージしたのでしょう）に比べて、柔軟性が低い
ように感じます。

描画メソッドを呼び出してくれる分には、その内部では何でも好きな事が出来ますからね。
それこそ、ごくごく簡単な状態変化なら、描画メソッドにやらせてしまう事は私もあります。
それに比べ描画パケット生成方式だと、ある程度以上複雑な事は出来ませんね。
そもそも複雑なことをやらせようとするのが間違いかも知れませんが、「実質的な手続きが
外部に定義されている」という点でOO的ではないな、と。

>>337
最後のフレームで何も描画して欲しくないタスクなら、そのフレームはなんのパケットも
生成しなければいいだけの話なので、特に問題はないと思います。

339 ：297：03/12/03 02:02 ID:0IsBwYpG

>>338
>しかし、考え方としてはあまりOO的ではないかも知れませんね。
これに関しては俺は、前にも書いたけど「理想と現実のギャップ」の問題で、
妥協のしどころだと思ってます。
OOPLはどれも抽象概念で全部済ますだけの言語機能を提供できていないし、
ゲームにしろなんにしろ、いつかは｢ユーザーが遊んだりできるもの」として
現実のものにしなきゃ行けなから、おのずと妥協点はでてくる、と。
OO否定派の人は妥協する様を見て「やっぱりダメじゃないか」って笑うわけですが
理想を追わずして進歩があるのかと。逆に理想を求めるあまり現実に落とし込めない
のもバカらしい、と。

もっと上手いやりかたはあるだろうな～とは思うんですが

340 ：337：03/12/03 02:18 ID:lXdZiPyj

>338
別に描画パケットのクラスを継承したクラスのオブジェクトを生成するようにすれば、
独自の描画が出来るし、それを使い回すことも当然出来るわけで、
よりOO的に思えるのですが。

まあ俺もTCBと描画オブジェクトを多重継承してますけど。

>最後の部分
それはいいんです。そうでなくて、
描画という一部があるのに本体が無くなるのが気持ち悪いというか。

341 ：名前は開発中のものです。：03/12/03 02:22 ID:a3mbT/7R

所詮おれらのやってる事は、ブルックスの呪いの言葉
　「狼人間を撃つ銀の弾丸は無い」
を20年かけた今でも日々証明し続けているってだけですからねー（´・ω・｀）ー３

さてと、今日も今日とて呪いを解く呪文を探して彷徨い続けますかｗ。

342 ：とむ ◆0MTMwDpCZo ：03/12/03 02:30 ID:N/++X+5i

>>339
確かに、「OOとゲームプログラミング」という事柄に関しては、「理想と現実のギャップ」は
常につきまといますよね。

>>340
描画パケットを継承したオブジェクト…それの生成、破棄はかなり重い処理のように
思えます。確かに柔軟性は生まれると思いますが。

＞それはいいんです。そうでなくて、
＞描画という一部があるのに本体が無くなるのが気持ち悪いというか。

まあこれは…保険金の例えが悪いなら、手紙みたいなもんですから。ポストに入れちゃえ
ば、本人が死んだって相手には届くと。
確かに動作としては気持ち悪いかも知れませんが、もっと低レベルな話をすれば、描画
パケットの生成はどこかでやらなきゃいけないわけで、それはDMAしたらパスが空くか
どうか見たりとか色々非OO的な事をしなきゃいけないわけで…。
これから先どんどん処理が並列化していく傾向にはあると思うので、この手の問題は
いくらでも発生するかと。

343 ：297：03/12/03 03:01 ID:0IsBwYpG

>>341
「完璧なシステムはありえないが、より良いシステムは常にありえる」
ってのは誰の言葉だったかな…
ま、銀の弾丸がないように、漏れの例が誰にとっても最良じゃないのは確か。

使えるライブラリ･エンジンってのが競合分野でも3つ以上あるのが理想
（そのなからから一番好みなのを選ぶ）なんですが、現実にはすぐ淘汰
たされて選択肢がなくなっちゃいますな。
Alchemyが死に体で、RenderWareぐらいしか選択肢がない。

344 ：名前は開発中のものです。：03/12/03 05:02 ID:ipymgoqw

for( 全てのOBJ ) obj->update();
for( 全てのOBJ ) 死亡フラグがたってたら、デストラクタ呼び出し
/* もうこの時点で、不要なobjは抹消されている */
for( 全てのOBJ ) obj->draw()

ではダメなの？

objの削除は、死亡フラグを1Bitたてるだけ。
全てのupdate処理が終了したのち、そのチェックを検査し、
本当に死亡しているものに対してのみ、デストラクタ呼び出し＆登録抹消。
その後、残されたobj群のみdraw()

draw()の中で、objの状態にしたがって低レベルな描画プリミティブを
書き足していく。

345 ：とむ ◆0MTMwDpCZo ：03/12/03 05:07 ID:N/++X+5i

>>344
元の書き込みが私の>>291のレスから始まっているので、そこから参照して下さい。

別にそのプログラムは間違っていません。
ただ、描画前にデストラクトすると１フレーム空いてしまう事、それを防ぐために次に
来るタスクの生成と１ステップの処理をすると、そこだけ処理が重くなる可能性がある
ことなどが問題として挙げられています。

346 ：名前は開発中のものです。：03/12/03 05:16 ID:ipymgoqw

で、あれば、以下のような変更ではだめ？

for( 全てのOBJ ) obj->update();
for( 全てのOBJ ) obj->draw()
for( 全てのOBJ ) 死亡フラグがたってたら、デストラクタ呼び出し

これならば１フレ空きもないし、違法参照も起きないよ。
ちなみに生成したOBJが、初めて->update()だとか->draw()が
呼び出されるのは次フレームからというルールが前提。

こうすれば、二度書きも、隙間もなくなるかと

347 ：とむ ◆0MTMwDpCZo ：03/12/03 05:27 ID:N/++X+5i

>>346
ええ、私が>>326で書いた手法ですね。
もちろんそれも一つのやり方で、問題ありません。
次タスク生成も、「draw()後、次のループ前」というタイミングで呼ぶとベストですね。
必ずupdate()メソッドが先に呼ばれる事が保証されるので（私は何度か、update()側で
オブジェクト生成して、そのオブジェクトはいきなりdraw()が呼ばれてしまうというミスを
した事があります）。

ただし、あえて死亡時のそのフレームには描画しないが、隙間は欲しくない（つまり次の
タスクの生成をそのフレーム内でやりたい）という要求もありうると思うので、そのへんは
柔軟に出来るといいですね。

348 ：名前は開発中のものです。：03/12/03 05:27 ID:lXdZiPyj

>「前のタスクの終了」と「次のタスクの起動」が描画直前のタイミングで
>両方発生し、処理がやたら重くなって下手すると処理落ちします。

正直、どんなタスクでこんな状況が困るのか？が、ちと疑問。

349 ：とむ ◆0MTMwDpCZo ：03/12/03 05:31 ID:N/++X+5i

>>348
>>304で書きましたが、「小さな圧縮データを１フレーム内で展開する」というような動作を
するコンストラクタを持ったオブジェクトなどです。
そんな見るからに重そうなの入れるな、と言われればそれまでですが、メモリとのトレード
オフでどうしても仕方なく…。

しかも、細かいオブジェクトの集合が一気に破棄、そして次タスクが管理するオブジェクトを
一気に生成、などという形があると、そこでやはり重くなる可能性があります。
単なるヒープ確保だけでも結構重いですし←という問題に対し、メモリプールはどうか、という
提案も出ています。

350 ：名前は開発中のものです。：03/12/04 00:37 ID:XG0UYdym

とむ氏のいうヒープ確保が重いというのはどういうケース？

GBAくらいのCPUでも、ヒープ確保のコストよりも、
確保したヒープ（ワーク）への初期化（たとえ単純なコピーでも）の
ほうがよっぽど重いと思うのだが。

メモリプールの場合、
「確保サイズが固定になってしまうという」という犠牲を強いること
になってしまう。この犠牲に見合った速度向上も、あまり見込めないし。

351 ：とむ ◆0MTMwDpCZo ：03/12/04 01:39 ID:rICPaYPu

newがあまり速くないという事ですよ。
まー気にするほどでもないとは思いますけど…。

ていうかそんなの気にする人はアロケータ替えますよね…。

352 ：名前は開発中のものです。：03/12/04 03:54 ID:VV3ZNTuX

コンシューマのmallocは軽いけど、ＰＣとかまともなＯＳの載ってる
環境のmallocは案外重い。ヒープから切り出すだけじゃなくて
動的アドレス変換の設定とかしなきゃいけないから。

353 ：名前は開発中のものです。：03/12/04 05:56 ID:XG0UYdym

マリオのように回転する丸太だとか、移動リフトなどのような
変動移動処理と、その調停はどうやってます？みなさん

354 ：名前は開発中のものです。：03/12/04 09:25 ID:8Q0W9RgW

>>353
何作目のマリオですか？

355 ：名前は開発中のものです。：03/12/04 13:03 ID:hJloUIiW

>>353
スレ違いな気がするよ。
そういう質問はこっち↓の方が良くない？

ゲームプログラミング相談室【Part5】
http://pc2.2ch.net/test/read.cgi/gamedev/1036410116/l50

356 ：名前は開発中のものです。：03/12/04 13:30 ID:/bX+C4Ck

>>352
お前はいったい、いつの時代の人間だ？
動的確保が重いとかいちいち言っていたら、STLすら使えないだろ。
原始時代から書き込みをするのはやめて、自分の時代に帰れ。

357 ：名前は開発中のものです。：03/12/04 13:41 ID:UmiNa3KF

STLは独自のアロケータを持ってるよ

358 ：名前は開発中のものです。：03/12/04 13:57 ID:VV3ZNTuX

>>356
仮想記憶とかがない環境に比べたら、の話。
それにvectorとかは、pushされるたびにいちいちアロケートしてない。

359 ：名前は開発中のものです。：03/12/04 15:28 ID:ySgOC4Fe

＞それにvectorとかは、pushされるたびにいちいちアロケートしてない。
そのかわりサイズが変われば再確保と内容のコピーで最も遅くなる罠。

360 ：名前は開発中のものです。：03/12/04 18:16 ID:jIcCRDq/

>>356
動的確保のオーバーヘッドが問題にならないぐらいの
インスタンスしか扱った事のない人は羨ましいですな。

361 ：名前は開発中のものです。：03/12/04 20:47 ID:W0irtEIJ

こういう話題の時に問題になる具体例を挙げてみてと言うと、いつも何故だが沈黙が訪れる。

362 ：名前は開発中のものです。：03/12/04 21:22 ID:+BhjDE5e

具体例も何も、メモリ確保が遅いと思ってる奴は当然いるだろ。
いないと思う方がおかしい。

363 ：名前は開発中のものです。：03/12/04 21:30 ID:YI3oCGV2

何故かいつも具体例は返ってこないかわりに、歯に物が挟まったような曖昧な答えが返ってくる。

364 ：名前は開発中のものです。：03/12/04 21:35 ID:+BhjDE5e

だから具体例も何も、「mallocが遅い」と思ってる奴がいるんだろ。
それが具体例じゃないのか？
そんなの実際のソースをここに書き出したって、それで具体例になるわけじゃないだろ。

　A* a = new A;
　これが遅かったです。

　とでも書いてあれば満足するのか？

365 ：名前は開発中のものです。：03/12/04 21:46 ID:8Q0W9RgW

>>364
遅いというからにはベンチマークでもとってデータを出さないとね。
その値をみて、それが問題になるかどうかを議論したいね。

ちなみに俺はmallocの速度なんか気にしたことがない。

366 ：名前は開発中のものです。：03/12/04 21:49 ID:ib/9AVB1

>>361
理由１．検証ができる具体例を挙げるためにはソースの大部分を晒さなくてはいけない。
理由２．たとえソースを晒してもそのソースの正当性を主張するのは難しい。
    うｐ後1レス目：そもそもそれだけのオブジェクトの生成が必要か？
    うｐ後10レス目：そもそもそれだけの描画が必要か？
    うｐ後100レス目：そもそもゲーム自体は必要か？
理由３．上記の理由すらすぐに思いつかない相手には何をやっても無駄だから。

367 ：名前は開発中のものです。：03/12/04 21:50 ID:+BhjDE5e

>>365
だからベンチマーク取って、mallocが何回で何秒かかったとかいうデータだして、それが何かになるのか？
お前は気にした事ないけど、気にする奴もいる。それでいいだろ。
いちいちデータ出さないと話にならないのか？
だったら、「mallocは速い」というデータも出さないと反論にならないぞ。

368 ：名前は開発中のものです。：03/12/04 21:53 ID:8Q0W9RgW

>>367
それじゃおまいは何をもってmallocが遅いと判断したのか？
測ったわけじゃないのか？

369 ：名前は開発中のものです。：03/12/04 22:00 ID:ib/9AVB1

>>368
計るも何もないだろ。
大体、malloc と比較するべき「対象」って一体何さ？

370 ：名前は開発中のものです。：03/12/04 22:00 ID:+BhjDE5e

>>368
意味わからないな…。
測ってどうするんだよ？
mallocの実行速度が0.00001秒であっても、「それが遅い」と思う奴は思うだろ。
何秒だったら速い、何秒だったら遅い、などという尺度があるのか？
そんなのそいつの組んでいるプログラム次第だろ。なんでそんな簡単な事がわからないんだよ。

mallocは実際数百命令で構成される関数だから、それが遅いと思う人間は確実にいる。
なんでそれを否定するんだ？
遅いと感じてる奴がいるのがそんなにおかしいか？

371 ：名前は開発中のものです。：03/12/04 22:01 ID:YI3oCGV2

＞動的確保のオーバーヘッドが問題
によって動的確保を避けなければならないほど、
動的確保が全体に対する影響を与えるので、別の方法にロジックを変えたプログラムの具体例。
本当に動的確保が全体の足を引っ張っているか検証した具体例。

乗算は加算より遅いと言う理由で、利便性を損なってまで乗算を避けるのと同じ。
つまり全体の影響について具体的に調べない状態で、遅い遅いといっても仕方がないと言うこと。

372 ：名前は開発中のものです。：03/12/04 22:02 ID:+BhjDE5e

>>371
なんで
＞つまり全体の影響について具体的に調べない状態で
をいきなり仮定しちゃうわけ？

それを仮定しなければ、「乗算は遅い」（今時のCPUなら加算と変わらないかも知れないが）と
言う発言は別に間違いじゃないだろ。

373 ：名前は開発中のものです。：03/12/04 22:12 ID:ib/9AVB1

void dynamic(void) {int i; for(i=0;i<100000000;i++)free(malloc(1+i%12345));}
void static(void) {int i; for(i=0;i<100000000;i++){char tbl[12345];}/*静的確保*/}

コードは晒した。あとの評価よろ。

374 ：名前は開発中のものです。：03/12/04 22:13 ID:YI3oCGV2

＞乗算は加算より遅い
と
＞乗算は遅い
は、違う。
比較する物があっての話。
動的確保は何と比べて遅いのか、それを論じずにいきなり遅いと言われても、
＞新幹線よりも陸上の金メダリストは遅い
と
＞陸上の金メダリストは遅い
これが同一の話になってしまう。

375 ：名前は開発中のものです。：03/12/04 22:18 ID:/bX+C4Ck

>>373
＞void static(void) {int i; for(i=0;i<100000000;i++){char tbl[12345];}/*静的確保*/}
予約語で使えない上に、最適化で無かったことにされるぞ。
出直してこい。

376 ：名前は開発中のものです。：03/12/04 22:19 ID:hJloUIiW

あふぉか。ゲーム作ってるんだからＰＧがなんと言おうと
プレイヤーに「体感的に遅い」と感じさせたら負けなんだよ！！

逆にいえば、そう感じさせなければなんでもあり。(暴言なのはわかってるけどな）
malloc/配列にしても乗算/加算にしても、実装部分は好きにやれ。

377 ：名前は開発中のものです。：03/12/04 22:22 ID:ib/9AVB1

>>375
>予約語で使えない上に
うっ、ケアレスミス。

>最適化で無かったことにされるぞ
それはつまり、動的確保が「遅い」という結論と解釈してよいのか？

378 ：名前は開発中のものです。：03/12/04 22:24 ID:1bHbUW3F

システムやライブラリのallocが許せて自前のallocが許せないなんて、
自分コードが腐っていると自白してるだけでしょ。

もしかして１０年以上前のベンチマークを信じてる年寄りだったりして。

379 ：名前は開発中のものです。：03/12/04 22:26 ID:YI3oCGV2

>>377
不要な命令が最適化で削除されるのは、早いからとかそういう問題じゃないんだけど。

380 ：名前は開発中のものです。：03/12/04 22:33 ID:ib/9AVB1

>>379
あるプログラムでメモリが必要になったとする。
最初は malloc で確保していたが、データ構造とアルゴリズムの
検討によって、スタック上で済ませる事ができるようになった。
その後改良を加え、そもそもメモリ確保自体が必要なくなった。

結局こういう事だろ。
>>368
>計るも何もないだろ。
>大体、malloc と比較するべき「対象」って一体何さ？

381 ：名前は開発中のものです。：03/12/04 22:43 ID:/bX+C4Ck

>>380
スタック上で済ませてるんじゃなくて、そのコードじゃ確保するためのコードの存在そのものがかき消されるんだが、
ネタでも面白くないからマジで出直してこい。

382 ：名前は開発中のものです。：03/12/04 22:56 ID:Ao4uvBju

>>379
>そのコードじゃ確保するためのコードの存在そのものがかき消されるんだが、
？？？
だから何？　もしかして、最近知ったのか？

>>380
>その後改良を加え、そもそもメモリ確保自体が必要なくなった。

この後に「その後改良を加え、そもそもプログラム自体が必要なくなった」
と書いておかなければ、何を言いたいか理解できないのか？

383 ：名前は開発中のものです。：03/12/04 23:05 ID:hJloUIiW

・・・もうやめようよ。
そもそもスレ違いだし、ただの子供のケンカになってきてるよ。

384 ：名前は開発中のものです。：03/12/04 23:09 ID:8Q0W9RgW

>>383
同意。ooの話に戻そうぜ。

385 ：名前は開発中のものです。：03/12/04 23:10 ID:YI3oCGV2

>>380
＞大体、malloc と比較するべき「対象」って一体何さ？
自分で書いているのに気が付いてない？

＞最初は malloc で確保していたが、データ構造とアルゴリズムの
＞検討によって、スタック上で済ませる事ができるようになった。
動的確保よりも優位性があることを検証しない限り、
わざわざコードを直してそれを採用したりはしない。
つまり検証した上でアルゴリズムを直しているわけであって、
最初から遅いと言っていたわけではない。

比較対象物について論じずに、馬鹿の一つ覚えのように突然遅いと言い出す姿勢に問題がある。
＞検討によって、
コードを直したのであれば何の問題もないし、逆にそれは重要なこと。

386 ：名前は開発中のものです。：03/12/04 23:46 ID:De9braZE

どっちにしろ
「malloc(やOSのメモリ確保API)の実行時間」＞＞「問題領域に特化したアロケータの実行時間」
ってことは変わらんでしょ。
あとは、動的確保をする個所でどっちが言いか判断するだけだね。
その辺は経験的に分からないかな？

「mallocは遅いから絶対使ってはならない」とか勝手な命題を想定して反論してる奴はただのバカ。
だれもそんなことは言ってない。

387 ：名前は開発中のものです。：03/12/04 23:52 ID:Ao4uvBju

>「mallocは遅いから絶対使ってはならない」とか勝手な命題を想定して反論してる奴はただのバカ。
誰もそんな反論はしていないと思うが（ｗ

388 ：名前は開発中のものです。：03/12/05 00:02 ID:8cv7q9rv

たとえば>>365とか>>371とかねｗ

389 ：とむ ◆0MTMwDpCZo ：03/12/05 00:03 ID:48V+JRNz

盛り上がってますね。

問題は、mallocを遅いと感じるか速いと感じるかは、人それぞれというか、対象としている
処理それぞれという事ですね。

で、「俺はmallocの速度に問題は感じてない」という人が、感じているという人に対して
「いや、遅くない」だのなんだのと反論しても仕方ありません。現にそれが遅いので、回避
手段を取っている人もいるわけですから。

反論してる人は、「いやmallocは絶対速いんだ！」と主張してるのですか？
違いますよね。いちいち反論するような部分じゃないと思いますが。

390 ：名前は開発中のものです。：03/12/05 00:07 ID:8cv7q9rv

「遅い」というレスに反論してる人はなにに反論してるんだろうね？
なんか変な仮定をしてるんだと思うけど…

391 ：名前は開発中のものです。：03/12/05 00:12 ID:SVswwa14

http://www.pearsoned.co.jp/washo/prog/wa_pro27-j.html
これでも読め

392 ：とむ ◆0MTMwDpCZo ：03/12/05 00:15 ID:48V+JRNz

Efficient C++には、汎用アロケータと特化したアロケータの速度差などが、きちんと
グラフで表示されていますよね。

まあ、世の中汎用のメモリアロケータでは「遅い」と思う人がいるという事でどうか一つ
よろしくお願いできませんかね。

393 ：名前は開発中のものです。：03/12/05 00:24 ID:8cv7q9rv

でも、STLコンテナ内で確保されるメモリがちゃんと再利用されている事を知らなかったら
今みたいに気軽に使わなかっただろうなぁ。

394 ：名前は開発中のものです。：03/12/05 00:28 ID:iq2rJyYP

日付が変わった瞬間に暴れ出したのが一人

395 ：名前は開発中のものです。：03/12/05 00:36 ID:dsf7s8tB

落ち着いたのかな？
速度だけでなく断片化対策などの名目から独自のmallocを作って全部それで
運営しようと血道を上げる例を幾度か見てみたけど（自分でもやったことがある）、
あれですな、全然意味ないですな。
基本はmallocで十分、それ以外の選択肢としてはmallocで確保した領域を適時
払い出すメモリプール（一種の特化アロケータ）だけが唯一正当性があると思う。
mallocの代価コードとか書いちゃダメです、そんなことする手間で他の事しましょう。

396 ：名前は開発中のものです。：03/12/05 00:37 ID:dClMENVN

dlmallocでみんなシアワセ

397 ：名前は開発中のものです。：03/12/05 00:38 ID:dsf7s8tB

で、boost:::poolにはバグがある、という話なんだけど、どの変のことなんだか分かる人いる？
http://www.radiumsoftware.com/diary.html
ここの日記で以前とあるバグがずっと修正されないままでいる、ってな事書いてあったんだけど。

398 ：名前は開発中のものです。：03/12/05 00:38 ID:7RnAb5pe

>>392
この下手糞、そもそも根本的に失敗している設計に手を出さないで
mallocなんか話題にするあたりのうざさがたまらんのですよ。

そもそもあんたなんで
>newがあまり速くないという事ですよ。
>まー気にするほどでもないとは思いますけど…。
気にするほどのことでもないこと話題に出したんだ？
馬鹿だな。お前「透明あぼーん」追加決定。

399 ：とむ ◆0MTMwDpCZo ：03/12/05 00:48 ID:48V+JRNz

>>395
というかですね、元々の議論が、「mallocによるヒープ確保が、他の手段に比べて遅い」
という話ではなく、「ヒープ確保が集中する設計にすると、遅くなる」という話なのですよ。
だからそもそも、mallocごと避けられる手段の方がいいねって話で（それがメモリプール
とか）、その中で私が、「ヒープ確保自体にも時間がかかるし」と一つの例をあげて話した
だけのことなのです。

元々盛り上がるような話題でもないですし、malloc以外の方法でヒープ取得しましょうよっ
て話でもなかったんですよ。元々はね。

400 ：名前は開発中のものです。：03/12/05 00:50 ID:8cv7q9rv

そういうのをスルーできないのも結構大人げ無いがな。

401 ：名前は開発中のものです。：03/12/05 00:51 ID:dClMENVN

>>399
「ヒープ」の意味が微妙におかしいような気がする。

402 ：名前は開発中のものです。：03/12/05 00:55 ID:8cv7q9rv

重箱の隅ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!!!

403 ：名前は開発中のものです。：03/12/05 01:03 ID:dsf7s8tB

　　　　　　　　　　　　　　　　　　　　　　　　　　　ヽ
　　　　　　　　　　　　　　_,,.,､､,.ｨ-- ti- ､､､....,,,,_ 　 ',
　　　　　　　 ,,..､､ri':'ﾞ/~ 　ﾚ　　　 '　ﾞﾍ:l : : : :~,＞
　　 _,...r:::''"::／ l/ .l:/-=ニ二,'_ｰ- ､、　 !l!;: r '"
'''＜:::::::::::::;､r'　　　　　　　　　　`'' ‐-`.､ /
-、 l::::::::::::l　　　　　　　　＜"ﾞ'i;ｿ'　　 ',
~.ヽ l:::::::::::l　　　　　　　　　　　　 ~' 　　 '､
/ .） .l::::::::::!　　　　　　　　　　　　　　　 '､
　ヽ　.l:!l:::::l ヽ　　　　　　　　　　　　　　　　 '､
＼ '　 l! l::!l!　ヽ　　　　　　　　　　　　　　 ,'
　ﾞ　　ヾ　　　　　　　　　　　　　　　‐'" ,. r ﾞ
ｰ-‐i　　　　　　　　　　　　　 ,.r,,iilll鬚髯ｦ
.　　 l　　　　　　　　　　　　`''' ‐‐ ---t‐' 　　　　　　mallocのことはどうでもいい…
￣￣￣￣￣￣~"''､' ‐ ､　　　ー‐ノ　　　　　　
　　　　　　　　　　 ',　ヽ　　　　　 l
　　　　　　　　　ｌ　　 l　　　　 l
　　　　　　　　　　 l　　 l　　　　ﾉ

404 ：とむ ◆0MTMwDpCZo ：03/12/05 01:03 ID:48V+JRNz

ヒープ領域とかそんな風に言い直した方が良いのかな？

405 ：名前は開発中のものです。：03/12/05 01:09 ID:4jWhCXiS

なんか、やねうらおさん混じってなーい？

406 ：名前は開発中のものです。：03/12/05 01:11 ID:4utD+ul1

まー、メガドラ時代からヒープを実装して酷使してきた
俺のようなベテラン・オヤジには、今のゲーム機では
ヒープが重くてネックになることはありえないと断定するがな。

ヒープのブロック数が１０００個だったとして、
1int単位で、それだけの数の確保と解放を耐用実験で
くりかえしたことあるけど
誤差、誤差。というか、有意な変化すら観察できなかった。

407 ：名前は開発中のものです。：03/12/05 01:12 ID:ESH6Ysjo

>>398
>この下手糞、そもそも根本的に失敗している設計に手を出さないで
それは言いがかりだろう・・・

それを言い出したら、ファイルの入出力にバッファリングを
使用している事すら、糞設計と言うことになる。

408 ：名前は開発中のものです。：03/12/05 01:21 ID:ESH6Ysjo

>>406
おじさん。文が１つ抜けていたみたいなので修正しておきますね。

>今のゲーム機ではヒープが重くてネックになることは
>ありえないと断定するがな。

>昔のプログラムを走らせるだけならば
>今のゲーム機ではヒープが重くてネックになることは
>ありえないと断定するがな。

409 ：とむ ◆0MTMwDpCZo ：03/12/05 01:35 ID:48V+JRNz

>>406
確かに、今のゲーム機は、メガドライブよりもずっと高速になっていますよ。
しかし、ヒープメモリ確保にかかるコストがかからない、というわけでもないんですよ。
結局メモリの確保はシステムコールの呼び出しになりますし、それに今時のゲーム機は
マルチスレッドで動いています。メモリ確保の手法自体が複雑になっています。
いくら高速になっても、問題がゼロになったわけじゃないんですよ。

410 ：名前は開発中のものです。：03/12/05 03:52 ID:d6/7HR4r

＞結局メモリの確保はシステムコールの呼び出しになりますし

そんなバカな。malloc自分で実装してみたことある？

ていうか、malloc/newが実行時間不定の処理なのは間違いないけど、
昔の16bit機でもなければ、ゲームループ中に確保するオブジェクトの数ごときで
そのコストが問題になるなどまずありえないよ。
1VSYNCに何千回も実行するものでもなし、他のコストに完全にかき消されてしまう。

状況に応じてメモリプール使いましょうって程度ならまだしも、
数百MHzの時代に遅い遅いと声を高くするのってのはどうもね。オヤジ認定しちゃうぞ。

少し前にマ板のこのスレにも同じ話題があったので読んでちょ。

ゲームプログラマーの人に聞きたい
http://pc.2ch.net/test/read.cgi/prog/1062855581/

411 ：とむ ◆0MTMwDpCZo ：03/12/05 04:02 ID:48V+JRNz

だから状況に応じてメモリプールを使いましょうって程度の話ですし、
「malloc遅くて使えねえ」という話でもありませんよ。
そもそもこんな大騒ぎするほどの話でもないような…。

412 ：名前は開発中のものです。：03/12/05 04:26 ID:jrviUVjd

　　　　　　 , 　＿ﾉ）
　　　　　 γ∞γ~　＼
　　　　　　|　 /　从从) ）　　ﾌｧｻｧ
　　　　　ヽ　| |　l　 l |〃
　　　　　｀从ﾊ~ ーノ）　　　　）)
　　　　　　 /つ（￣｀ヽO_ノ⌒ヽ
　　　　　ノ　　）　　　　　　　　＼）)
　　　　　(__丿＼ヽ　::　　　　ノ::::　）
　　　　　　　　　丿　　　　　　　　,:' 　）)
　　　　　　 (（　（___,,.;:-－''"´｀`'‐'

　　　　　　　　, 　＿ﾉ）
　　　　　　　 γ∞γ~　＼　おやすみ！
　　　　　　　 |　 /　从从) ）
　　　　　　　ヽ　| |　l　 l |〃
　　　　　　　｀从ﾊ~ ワノ）
　　　　　　＿ ./　　　_ノ⌒⌒⌒`～、_
　　　　　　(.　⊂人　//⌒　　ノ　　ヽ）
　　　　　⊂ニニニニニニニニニニニニニニ⊃

413 ：名前は開発中のものです。：03/12/05 23:02 ID:2LgTIArx

new/malloc は断片化がやっぱ怖いよな、得にコンシューマー
エージングテストでの突然死するときの原因の候補の一つに最近なっている。
ガベコレが欲しい所。

414 ：名前は開発中のものです。：03/12/05 23:12 ID:KS/NGBG0

断片化が問題だと、ガベコレもコピーGCじゃないと意味なさげ？
C/C++にコピーGCは合うんだろうか？

415 ：名前は開発中のものです。：03/12/05 23:13 ID:2LgTIArx

>>410
スマートポインタとか使い始めると結構数千とかいかない？
あと100倍早くなけば確実に動的確保が有利になると思うけど、今はまだ微妙な時期だと思うけどね。

416 ：名前は開発中のものです。：03/12/05 23:18 ID:2LgTIArx

>>414
コピーにDMAとか使い始めるとむしろC++の方が有利かと・・・
問題はガベコレ機能をどう差し込むかというところ、
参照カウンタと違ってかなり難しい問題だと感じる。
色々ライブラリーを見て回ったけれどもgcまでやるスマートポインタの良いライブラリは無いです。

417 ：とむ ◆0MTMwDpCZo ：03/12/06 00:42 ID:ifAD99AG

ガベージコレクションより、メモリコンパクションをどう起こすかの方が問題ですね。
しかしメモリコンパクションを前提にすると、メモリをハンドルでしか保持できなくなり、
実行速度に影響が出てきます。そうなるとそれこそロック、アンロックがメモリ操作時
に必須になり、ちょっといやんな感じになります。

それでも、断片化は問題大きいですね。コンシューマの場合。

418 ：名前は開発中のものです。：03/12/06 00:49 ID:dLPIQNHS

>>new/malloc は断片化がやっぱ怖いよな、得にコンシューマー
2Mしかないヒープに一度に数百kbもmallocしてしまう厨がコンシューマに
いるからではなくて？

419 ：とむ ◆0MTMwDpCZo ：03/12/06 00:55 ID:ifAD99AG

問題は確保するメモリの大きさではないと思います。

420 ：名前は開発中のものです。：03/12/06 01:31 ID:Kmcc874+

>ガベージコレクションより、メモリコンパクションをどう起こすかの方が問題ですね。
それが、「コピーGCじゃないと…」ってことです。

421 ：名前は開発中のものです。：03/12/06 01:48 ID:74Qe9qPk

>>418
小さく切って使うとそれはそれでまた問題が起こりませんか？
ヘタすりゃ半分ぐらいしかメモリーが有効利用されていないとかないですか？

大きく取ったらそれはそれで、断片化が問題になるし・・・
とにかく嫌なのは、この種の断片化のトラブルが起こるのが非常に頻度が低いが
一週間程度動かしておくとキッチリ発生する程度の頻度だったりするものだから
調整がしらみつぶしになって開発が終わらなくなってしまうんですよね。

422 ：名前は開発中のものです。：03/12/06 02:04 ID:PFwMOJPX

> 問題は確保するメモリの大きさではないと思います。

断片化の発生には影響しないけど、断片化による被害を受けるのが
でかい連続領域を確保しようとしたときなので、確保サイズは問題になると思います。

423 ：とむ ◆0MTMwDpCZo ：03/12/06 02:43 ID:ifAD99AG

>>422
しかし、元々が「エイジングテストで落ちる」という話だったので、確かにでかい領域確保
をしなければ問題は先送りに出来るけど、結局断片化が起こっているのは間違いなく、
最終的には解放したメモリより大きな領域を確保しようとしたらできなくなるわけで。

確かに、必ず同じサイズのメモリしか取らないような仕組みにしていればこのような問題は
起こらないわけで、「確保するメモリサイズは一切関係ない」とは言い切れないけど。

ただ、>>418で言われているように、メモリをたくさん取るから、というのは関係ないと思います。
それ以前に断片化しているのがここでは問題なわけで。

424 ：名前は開発中のものです。：03/12/06 07:59 ID:dLPIQNHS

＞小さく切って使うとそれはそれでまた問題が起こりませんか？
＞ヘタすりゃ半分ぐらいしかメモリーが有効利用されていないとかないですか？
普通にclassを定義して、そのclassをnewするぶんには、
極端に小さくなることもないかと。

ヒープの用途によりけり？

一度、ヒープをｎ個用意して、それぞれの用途に応じて使い分けるという
ことをしてみようかと思ってる。が、経験なし。

425 ：名前は開発中のものです。：03/12/06 12:14 ID:lqb+WBrh

もうooと全然関係なくなってるからお前ら荒らしと変わらないんだけど。
スレ違いなのは認識してるよね？
メモリ管理スレでも作ってそっちでやってほしいんだけど。

426 ：名前は開発中のものです。：03/12/06 12:17 ID:Zo0FUzDb

>>425
俺も思った

427 ：名前は開発中のものです。：03/12/06 13:25 ID:fbe1z3uq

そうかな、OOやるならメモリー管理は重要な問題だと思うが・・・
メモリー管理の問題が上手く解決できないとOOは難しい。

428 ：とむ ◆0MTMwDpCZo ：03/12/06 16:00 ID:ifAD99AG

少し前までの、mallocの速度どうこうはあまりにも細かい話題でしたが、今のメモリ断片化
を含む話題は、OOとゲームプログラミングというスレには適した話題だと思いますけど。

ゲームのプログラムは特性上、オブジェクトがスタックよりもヒープに作られる傾向があり、
断片化に対する対策はOOでデザインする上での大きな問題だと思いますが。

429 ：名前は開発中のものです。：03/12/06 16:12 ID:lqb+WBrh

>>427-428
じゃあ、「ooとメモリ管理」みたいなスレ立ててそっちでやって、すごく邪魔。

430 ：とむ ◆0MTMwDpCZo ：03/12/06 16:15 ID:ifAD99AG

>>429
というか人に文句言うより、自分でネタ振りしてはどうでしょうか。
メモリ管理がゲームプログラムの重要な課題である以上、私はスレ違いだと思って
いません。
他人を追い出す努力より、自分が好む話をする努力をしてはどうでしょうか？

431 ：名前は開発中のものです。：03/12/06 16:36 ID:lqb+WBrh

>>430
はっきりいって「メモリ管理」の話はうんざり。
こんなくだらないことで口論するのも馬鹿らしいから別スレ立てたほうがいいでしょ。
そっちが出て行かないならこっちが出て行くけど。
その場合「ooとゲームプログラミング（メモリ管理以外）」とかいうスレ立てるけど需要ある？>ALL

432 ：とむ ◆0MTMwDpCZo ：03/12/06 16:37 ID:ifAD99AG

どうぞ。

433 ：名前は開発中のものです。：03/12/06 16:43 ID:9sqRMujt

「どうぞ」って…………ちょっと冷静さに欠けた発言だと思うぞ。

434 ：とむ ◆0MTMwDpCZo ：03/12/06 16:57 ID:ifAD99AG

うーん、どうしてもこの話を除いたスレが欲しいというのなら、仕方ないじゃないですか。
多分彼は、またそのスレで自分の気にいらない話題が出たら、
「OOとゲームプログラミング（メモリ管理とタスク間通信以外）」
とか言うスレを立てるでしょう。そこでもまた自分の気にいらない話題が出たら…。

やがて時間も経てば、彼は自分の好きに話題をコントロールできない事に気づくでしょう。

435 ：名前は開発中のものです。：03/12/06 17:41 ID:3yEEpbxE

さぁ、盛りあがってまいりますた

436 ：名前は開発中のものです。：03/12/06 18:05 ID:/TI1EXNx

なにがなんでも居座るつもりなのですか

437 ：とむ ◆0MTMwDpCZo ：03/12/06 18:34 ID:ifAD99AG

穏当な提案だと思いますけどね。

・メモリとゲームプログラムの間になんの関連もないと思っている。
　　→スレ違いを指摘する

・関連ないわけじゃないが、違う話題を話したい。
　　→その話題のネタ振りをする

・メモリ管理の話を一切しないプログラムのスレにしたい
　　→そういうスレを立てる

このどれかを選べばいいわけで。単に、話をしている人を追い出したいというだけでは
妥当とは言えませんので。

438 ：名前は開発中のものです。：03/12/06 18:51 ID:J6f/B0US

メモリー管理とOOは切っても切り離せないし、タイトルをよめば

>単なるC++でのクラスの書き方から設計やパターンまで
>守備範囲広し

と別に問題は無いと思うし
それよか純粋なOO話をしたけりゃグダグタ言ってないでその話題振れよ
とか思った

439 ：名前は開発中のものです。：03/12/06 21:08 ID:3yEEpbxE

で、結論はいつ出るの？
例えば、メモリ確保するならnew使うな、malloc使えとか。
初めにドバッと確保しといてそれを自分で管理しろとか。

永遠メモリの話しててもしょうがないだろうに。
500レスあたりで賢い方がまとめてくれないものか・・・。

440 ：名前は開発中のものです。：03/12/06 21:14 ID:J6f/B0US

だから意味の無い煽りみたいなグチ書かずに話題振れよバカ

441 ：名前は開発中のものです。：03/12/06 21:19 ID:PFwMOJPX

↓まとめ。
ttp://www.cs.umass.edu/~emery/pubs/berger-oopsla2002.pdf

442 ：名前は開発中のものです。：03/12/06 21:35 ID:Kmcc874+

>>439
というか、もともと結論の無い雑談なんだから、気にすんな。
なにか話題にしたいと思うならみんなそっちに移ると思うよ。

いや、もう、「メモリ管理はこのスレの範囲内か？」という話題に移ってるか…

443 ：名前は開発中のものです。：03/12/06 21:37 ID:GWiFfQcS

>>440
お前も下らない煽りしてるじゃん。
目障りだから消えていいよ。

444 ：とむ ◆0MTMwDpCZo ：03/12/06 22:17 ID:ifAD99AG

私の個人的な感想では、OO的手法でゲームを作る時、メモリ管理の問題は絶対に
避けられない議題なので、「ようやく核心的な話題にたどり着いてきた」という感じが
しているんですけどね。

しかし他の話題の方がいい、という人がいるなら、自分で振ってみてはどうでしょうか。

445 ：名前は開発中のものです。：03/12/06 22:21 ID:dLPIQNHS

＞＞というか、もともと結論の無い雑談なんだから、気にすんな。
俺的には結論が出てる。
俺以外にも分かってる奴は結論出てる。
あとは、啓蒙するだけ。

部下がついてこれないと、俺の足を引きずるので。

446 ：名前は開発中のものです。：03/12/06 22:21 ID:fL8ZYGfP

>メモリ管理はこのスレの範囲内
分離した所で、スレにするほどの独立性もないから別にいいよ。
意味無く作ってもスレの乱立にしかならんと思うし。
それより、このままもう少し深く探っていって、さらにスマートポインタの話に繋がるのを個人的には期待しているんだけど。

ガレージコレクションスマートポインタの研究やっている人誰か居ないかな・・・

447 ：とむ ◆0MTMwDpCZo ：03/12/06 22:23 ID:ifAD99AG

>>446
なんとなく、ゲームプログラムだと、スマートポインタの恩恵少なくない？

448 ：名前は開発中のものです。：03/12/06 22:25 ID:fL8ZYGfP

>>447
コード量産するときには便利だよ、食わず嫌いはもったいないです。
高速化が必要な所はやっぱスクラッチパット(←機種バレバレ)とスタックが基本になるけどね。
レジスター内で計算が収まるの強い。

449 ：とむ ◆0MTMwDpCZo ：03/12/06 22:30 ID:ifAD99AG

>>448
いや、食わず嫌いというわけでもなくて…。

ええと、スマートポインタというのは、どのへんまで「スマート」なポインタの話かな？
基本は、ポインタがスコープアウトすると同時に、指しているオブジェクトのデストラクタを
呼び出すという事だよね。

ゲームの場合、非常に短い関数を非常に短い時間走らせるという処理が多いので、
一つの変数のスコープアウトの時間が来るのが早く、あまり有利ではないかな、と。

例外をキャッチしてる？

450 ：名前は開発中のものです。：03/12/06 22:34 ID:PFwMOJPX

>>449
なんでスマートポインタと処理時間が関係してくるの？

451 ：名前は開発中のものです。：03/12/06 22:43 ID:fL8ZYGfP

>どのへんまで「スマート」なポインタ
boostのスマートポインタ程度のものを考えてます。
主たる目的は参照共有です、これがないとOOなんかやってられないので・・・
もう一つは、スマートポインタを考えているのは循環参照問題を解決したいのと、最近のガベコレは参照共有より高速にできる方法ができていて
安全性と高速性の両面を追えるようになっています。
これを使いたいのですが、それで実際に組んでみようとすると・・・ガベコレどころか自分のtemplateの知識ではガベコレ付スマートポインタは不可能かと思われたりするので悩んでいます。
これはアタックして挫折している人は多いのではと思っているのですが、仲間はいないかな？

452 ：とむ ◆0MTMwDpCZo ：03/12/06 22:45 ID:ifAD99AG

>>451
あー、ハイハイ。shared_ptrの効用の方は十分に分かります。

ところであなたの機種の場合、VRAMに対するガベコレやコンパクションを起こしたいと
お思いではないでしょうか？（笑）

これがまた線形ではなくて大変なんだけど…。

453 ：名前は開発中のものです。：03/12/06 22:47 ID:fL8ZYGfP

>>452
VRAMはサジ投げました(藁)

454 ：とむ ◆0MTMwDpCZo ：03/12/06 22:55 ID:ifAD99AG

>>453
だよねえ…。しかし、問題の深さは実はVRAMの方が大きいんだよね…。

ところで、「ガベコレ付きスマートポインタ」と書いてますけど、そもそもガーベジを
作らないのが目的のポインタなので、なんとなく変な気がしますが…。

あとshared_ptrですが、複数人開発をしていてそのスタイルが統一されていない場合、
なかなか導入が難しいですよね。
…こんな話はここでしても仕方ないのですが（笑）。

455 ：名前は開発中のものです。：03/12/06 23:01 ID:fL8ZYGfP

>>454
VRAMの深刻度は度が過ぎます、どうにもこうにもなりません、諦めました。(キッパリ)
ちなみにスマートポインタのスタイルバラバラ問題は、モダンC++デザインのポリシーの概念を使って回避しています。
これを使ってオーバーレイ問題も一緒に解決しています。(あらぬところにコードが生成される問題があったりするので)
そんな訳でスマートポインタはオリジナルのものです。

456 ：名前は開発中のものです。：03/12/06 23:12 ID:lqb+WBrh

みなさん今度はスマートポインタとガベージコレクタの話題らしいですよ。
どこらへんがooなんだか聞いてみたい限りです。

457 ：とむ ◆0MTMwDpCZo ：03/12/06 23:18 ID:b9R6GZ+9

>>455
そうなんだよねー、あのVRAM…。幸い転送は速いから、なんか上手い方法はありそう
だけど、かと言ってそこをなんかラッピングするシステム作っちゃうと、処理速度に大幅な
影響が出そうだしね。

あと、私の場合「スマートポインタのスタイルバラバラ」以前に、誰もスマートポインタを
導入してない段階なので…（笑）。頑張れって？

>>456
新スレでどうぞ。

458 ：名前は開発中のものです。：03/12/06 23:23 ID:EO4hEUp+

>新スレでどうぞ。

訳してみると、
｜このスレは先ほどから「とむと身内のプログラミング雑談」に変わったから、
｜OOとゲームプログラミングの話題は別スレでおながいします。
といったところ？

スレ違いが指摘されたなら、スレ違いでないことを証明もしくは説明しないと。

459 ：とむ ◆0MTMwDpCZo ：03/12/06 23:24 ID:b9R6GZ+9

>>458
違いますよ。
彼が自ら、「新スレ作ってそこでやります」と言っていたので（ログ参照）、その上で
話を続けているのに、まだ文句を言ってくるのでこういう言い方になったわけです。

メモリ管理等がスレ違いだと思っていないという説明は何度もしています。
少しログを読んで下さい。

460 ：名前は開発中のものです。：03/12/06 23:25 ID:W+uvCsQL

例えば２Ｄ縦シューティングを作るとき、
敵クラス作成-クラスと敵-クラスと自機-クラスと弾-クラスをつくって
各クラスに独自の当たり判定機能をつけて
完成だと思うんだけど
これであってる？

461 ：名前は開発中のものです。：03/12/06 23:28 ID:8K/99A1b

>>458
・・・莫迦。逆だろ。

スレ違いを指摘するなら、スレ違いであることを証明もしくは説明しないと。

462 ：名前は開発中のものです。：03/12/06 23:41 ID:e8jl6cKC

とむさま
どこかのＭＬ等と違い、こういう場所に於いてはコテハンというものはもう少し
アイドル的な振る舞いをしなくてはいけないものでございます。
自己像が名無しよりはっきりしていることから得られる利潤をただただ貪るのではなく、
それに見合うだけ、節制や施し、サービスを行う必要がありますよ。

名無しどもと同一の視点や認識に基づいて話がしたいというのであれば、
どうぞ名無しにお戻りください。

463 ：名前は開発中のものです。：03/12/06 23:46 ID:pargBxkp

＞…こんな話はここでしても仕方ないのですが（笑）。
じゃあするなよと思ったのは僕だけでしょうか（笑）。
何でもOOにひっくるめればいいんですよね。C vs C++だってスレ違いじゃあないさ。
結局自分だけが楽しけりゃいいんですよね。人間なんて綺麗事言ったってみんなそんなもんなんですよね。
・・・。

464 ：名前は開発中のものです。：03/12/06 23:47 ID:8K/99A1b

>>462
はいはい。もう十分。お腹一杯だよ。
そんな子供っぽい主張は。

465 ：名前は開発中のものです。：03/12/06 23:50 ID:pargBxkp

>>463
とむたんは許してやってくれ。代わりに俺が出て行く。
粘着厨になる前に俺にはやらんきゃならねえ事がある！
みんな、俺のに免じて仲良くしてくれ。頼む。

・・・アバヨ、OOスレ・・・。

466 ：名前は開発中のものです。：03/12/06 23:51 ID:pargBxkp

間違った>>462でした。ってはうあっ

467 ：名前は開発中のものです。：03/12/06 23:52 ID:fL8ZYGfP

IDさらして自作自演がいるな(汗

468 ：名前は開発中のものです。：03/12/06 23:56 ID:3yEEpbxE

さあ、ますます盛りあがってまいりますた

>>460
それだと沢山オブジェクト作成した時重くならなーい？
とりあえず細かく領域分け（128x128など）しよーよ

469 ：名前は開発中のものです。：03/12/06 23:59 ID:fL8ZYGfP

>>468
2D程度なら十分じゃないかな。
3Dなら、そういった処理は必要かと思うけど。

470 ：名前は開発中のものです。：03/12/07 00:43 ID:L75FVXqB

>>468
領域分けって当たり判定の？

471 ：名前は開発中のものです。：03/12/07 00:54 ID:S/xid620

>>470
そんなところだ。

472 ：とむ ◆0MTMwDpCZo ：03/12/07 00:56 ID:02nvUCd1

私が前にやった時は、総当り判定にしました。

473 ：名前は開発中のものです。：03/12/07 01:45 ID:Ro/4Ir+V

総当りでやっても高々数千回でしょ(そんな行かないかな？)。問題ないと思うな。
いや、MMOシューティング(？)作ってサーバで全部判定とかするなら別ですが。

474 ：名前は開発中のものです。：03/12/07 02:04 ID:S/xid620

>>473
それゆーたら先日のメモリなんて（ｒｙ

475 ：473：03/12/07 02:07 ID:Ro/4Ir+V

俺はいつでも標準のnew, delete, malloc, freeですよ？

476 ：名前は開発中のものです。：03/12/07 02:40 ID:hnfzKfKh

>>473
当たり判定やる場合、座標管理クラスみたいな物を作っておいて
そっちでまとめて判定やったりしません？

キャラ同士がぶつかって、跳ね返ってさらに他の物体に当たって・・・みたいな
ピンボール的状況になると、個別にやってると破綻しやすいし。

座標管理クラスから値をコピー
↓
移動処理（全部のキャラ）
↓
座標管理クラスで当たり判定
↓
移動確定処理（変化があったクラスにコールバックで通知)
↓
描画
↓
繰り返し

ってなかんじでやってます。
＃あ、これもスレ違いか？この場合は「OOとゲームプログラミング（当たり判定限定）」スレを立てたほうが良い？
＃・・・といっても激しく過疎なこの板でどの程度需要があるかは知らんが。

477 ：とむ ◆0MTMwDpCZo ：03/12/07 03:01 ID:02nvUCd1

コリジョン管理も重要な議題だと思うよ。

478 ：名前は開発中のものです。：03/12/07 03:28 ID:hnfzKfKh

いっそ次スレのテンプレはこんな感じで逝くかｗ
--------------------------------------------------
OOを肴に設計から実装まで幅広く雑談するためのスレです。

要するにプログラムに関する分野ならなんでも。
守備範囲広し

479 ：satomi：03/12/07 03:42 ID:UivqJ2O4

>>478

はじめまして、Ｃ＋＋でプログラム作成するのですが問題が解けません。
問題は、
入力された２つの整数の差の絶対値を出力するプログラムを作成しなさい。整数には、
負数を入力される場合も考慮する。
次のプロトタイプ宣言を持ち、変数n1とn2の差の絶対値を戻す関数を使用すること。
int Absolute(int n1,int n2)

入力は、キーボードから（getcharを使うこと）。
エラー仕様で、９桁以上の文字列が入力された場合、先頭から８桁のみを有効とし、９桁以降を無視する。
また。数値以外の文字が入力された場合、Enterキーのみ、または、'－'のみが入力された場合は、エラーメッセージを
表示して終了する。

この問題を解けるかたがいましたら、解答をお願いします。

480 ：名前は開発中のものです。：03/12/07 04:17 ID:hnfzKfKh

>>479
うーん、OOでも設計でも実装でもないし、そもそもゲーム関係ないし・・・。

↓こっちで聞いてみてください。
プログラム板：「C/C++の宿題を必殺仕事人始末人 17代目」スレ
http://pc2.2ch.net/test/read.cgi/tech/1070469896/l50

481 ：名前は開発中のものです。：03/12/07 04:35 ID:Ij7td4M3

>>478
せめてゲームプログラミングには限定しようぜ。
>>479 は「それだとこんなのも来るよ」っていうネタでしょう
このスレの現状の主旨は「ＯＯを肴にやや設計よりの
ゲームプログラミング実践論」ってとこじゃない？

482 ：名前は開発中のものです。：03/12/07 05:20 ID:3u/6oJmT

【あめぞう】２ちゃんねるに閉鎖要求！知的財産？【したらば】
http://jbbs.shitaraba.com/bbs/read.cgi/sports/10137/1066056813/

２ちゃんねるの生みの親でもある、老舗掲示板あめぞうと、したらばが
協力して２ちゃんねるに閉鎖要求！知的財産を盾に今後裁判も侍さない
構え。これに対しひろゆきは反発すると思いきや・・

225 ：ひろゆき＠どうやら管理人 ★ ：03/12/07 04:01 ID:???
どうでもいいことですがさすがに裁判にまで発展したら負けるかも。。
まぁその時はあっさりと閉鎖も考えられる訳で。。。生みの親なら親で
そっとしておいて欲しいし、まぁ子には子なりの考えがある訳で。。
今のところは閉鎖は考えては無いです。はい。。けれどもさすがに
判決には従わなければならないし・・・閉鎖するとしたら１２月３１日が
区切りが良くて良いかなと。。そうしたらごめんなさいです。。

483 ：名前は開発中のものです。：03/12/07 09:37 ID:kFli1UQz

>>476
>＃あ、これもスレ違いか？この場合は「OOとゲームプログラミング（当たり判定限定）」スレを立てたほうが良い？
>＃・・・といっても激しく過疎なこの板でどの程度需要があるかは知らんが。
その前に君はオブジェクト指向で考えることに全く向いてないみたいだから
そもそもこのスレにくる意味がないんじゃない？
>>476に書いてある内容だったらooとあんまり関係ないし、
ゲームプログラミング相談スレの方で当たり判定の話題がでたら改めてやってくれた方がいいと思うよ。
みたとこ２行目までだよooっぽいの。

484 ：名前は開発中のものです。：03/12/07 09:56 ID:9+0uEWEO

>>478
それでいいんじゃない、そもそも近頃のゲームのプログラムで重要な部分は
描画エンジン、物理エンジン、スクリプトエンジンの三つで残りはオマケだからね。
考えた所で殆どご利益ないです
OOも使うが、実際にはゲーム作成上の補助ツールが中心だしね。
DirectX とかは分かれていても価値はあるけど、ここはその他諸々で十分。

485 ：名前は開発中のものです。：03/12/07 09:59 ID:kFli1UQz

>>484
え？そりゃ君んとこ限定じゃないの？
少なくとも俺んところは違うよ。

486 ：名前は開発中のものです。：03/12/07 10:21 ID:Ro/4Ir+V

>>476
当たり判定の結果次第で移動処理の内容が変化する場合とか、
コールバックモデルだとフローが複雑になるんで、集中管理に
しない場合もある。俺の場合だけど。。。

487 ：名前は開発中のものです。：03/12/07 23:09 ID:3r7Ha8nk

>>481
だとしたらスレタイかえたほういいんじゃない？
プログラミング系のスレならどこでも、肴程度にはOOの話はするよ。

488 ：名前は開発中のものです。：03/12/07 23:22 ID:fcdwlAwb

>>487
そういう話は自治スレでやってくれない？
関係ない話にうんざりなら自分で話題振ればいいのに…と何回も言われてるのに…

489 ：名前は開発中のものです。：03/12/08 00:03 ID:FgfgXMYM

デザインてのは作るゲームが違っても使いまわせるもんですか？
ライブラリみたいな部品的な部分ではもちろん旧来同様の再利用ができるんでしょうけど、
デザインはどの程度まで使いまわせますか。

もしも、ゲームのジャンルの詳細までをも包括したレベルで
システム全体の捉えかたのパターンを見出してる人がいたらちょびっと披露してﾎｽｲ

490 ：名前は開発中のものです。：03/12/08 00:29 ID:Rc2apOdK

デザインパターンは使いまわすことを前提とした構造だね。
実装では、フレームワークがデザインを使いまわすいい例だと思う。3Dエンジンとか？
って、ゲームの話薄いな…

俺は、シーン管理とシーンベースクラス、キャラクタのベースクラス、
キャラクタ管理クラスは使いまわすことが多いな。あと初期化部分(デザインじゃないか)。
具体的なゲームのデザインを使いまわすことって、どれくらい可能なんだろ？

491 ：名前は開発中のものです。：03/12/08 01:02 ID:kC7SzB4C

>>489
結構、しっかり設計をすると案外違う場所を探した方が早いときもあるんだよね。
まあ、時間無くて汚く組んじゃって使いまわせなくなっちゃうこともあるけど。

ちょっとしたシステムでいうと
エフェクトなんかはもう垂れ流し系にしろ絡み系にしろもうだいたい決まってるからいじってないな。
（だいたいはアニメーションモデルやムービーを再生でしょ？特殊なことしても売れなきゃ損だし。）
キャラクタ制御・管理クラスも、もうだいたい決まってるからいじってない。
（あとはデザイナ次第だな。操作する必要があるものは別に分ける。）
当たり判定なんてのはできることが自分の実力でたかが知れてるからもういじってない。
（物理演算みたいなのやってもねぇ？まあ、やれる余地は残してあるけど。）
シーン管理もつかいまわしだけど、毎回新しいの思いつくから改善中。
モデルの動きなんか（光の点滅からカーソルの動きまで）はもうデザイナまかせ。
プログラムでは垂れ流し。

ゲームごとのシステムはとりあえず組むしかないな。（これが時間かかるんだけど）
あと、目指すはオーサリングツール？（スクウェアみたいなの？ﾜﾗ）
ＲＰＧ作ってみたいね。

492 ：名前は開発中のものです。：03/12/08 01:23 ID:FgfgXMYM

垂れ流し系とか絡み系って例えばどういうやつのことですか？
シーン管理というのは具体的にはどういう処理のことですか？

493 ：とむ ◆0MTMwDpCZo ：03/12/08 01:29 ID:4lAhWrrT

いやらしいなあ…。

494 ：名前は開発中のものです。：03/12/08 01:43 ID:m+V0WGeU

ココで外観(=view)と内部処理用データ(当たり判定など=model)の対応をどうしてるのか
という問題になるわけだ！両方デザイナ任せ？

495 ：>>491：03/12/08 03:54 ID:tcLSMpgX

　　　　　 _,,,...-――-,,.._ 　　　　（　き　　バ　　　　　　　　　　　　　　　　　　　　　　　
　　　／::::::::::;' "Y'"ヽ_;;::＼　　（　み　　カ
　　　 /::::::,. -‐i　・l・_,ﾉ　_,ヽ::i 　（　は　　か
　　　,|::::/ｰ-　 ` "●　　＿,,_`i 　（
　　　|:::|-‐　　　　　|_,-､　､_　 } 　ﾉノヽ人__丿
　　　|:::i,,,-'" 　　　 _,ノ　　｀ i
　　　 i::i､　　　　　､_,)　　 /
　　　ヾ >､＿＿＿＿＿,,,ｨ.
　　　　,i ::::￣￣,=（t）‐､'':::::i

496 ：名前は開発中のものです。：03/12/08 09:32 ID:kC7SzB4C

>>492
>垂れ流し系とか絡み系って例えばどういうやつのことですか？
垂れ流しってのは他の物体となんの関連もないもの（爆発とか（勝手に動いて勝手に消滅））
絡みってのは他の物体と関係のあるもの（ホーミングレーザーとか（ターゲットが別途必要、やや複雑になる））

>シーン管理というのは具体的にはどういう処理のことですか？
シーン管理は（俺は）画面の切り替え（この表現も変だけど）単位で管理している
まあ、ＲＰＧなら（ＲＰＧ作ったことないけど）フィールドマップシーン→戦闘シーンとか
いう部分を管理する。その際のフェードイン・アウトやクロスフェードのリクエストやら
次のシーンのリクエストやらシーンに必要なデータのロードやら、シーンをまたぐ処理はこの辺で管理する。
もちろんゲームの状態や進行状態によってリクエストするシーンは変わる。
（シーンって何？ってのは感覚でつかんでくれ。この辺いい加減だし。改善中だし。聞いてくれても詳細はだせない。）

同じシーンが同時に動作することもある。
（画面に映るものはアクティブなカメラにまかせる。ただしかなり稀。）

まあ、上の方でいってる「擬似タスク？」って思うかもしれないけどシーン管理は
シーンＡとシーンＢの関連の処理をするものでもあるのであんまり意味無く分けるのはｲｸﾅｲ。
作成するクラスはsceneクラス、sceneManageクラス。

>>495
でかいＡＡやめろ。↓このぐらいに抑えろ。
ｶｴﾚ!!ヽ( ･∀･)ﾉ┌┛Σ)Д｀)ノ･ﾟ･｡

497 ：名前は開発中のものです。：03/12/08 12:56 ID:yHskva/T

>>496
thanx
参考になりやす

シーンが同時に存在する必要がある場合(例えば、フィールドから戦闘への滑らかな移行)、
シーンを複数保持できるようにしてあるんでしょーか？
あ、そのためのsceneManageか

498 ：名前は開発中のものです。：03/12/08 13:27 ID:DOpR5iy3

ゲームの場合、使いまわしが聞かないのはしょうがない。
基本的に毎回”既存のゲームとは違う”物を求められるし、
その違う部分を作ることこそがゲームプログラミングの
本質であり、作業の８割近く（あくまで独断だけど）を占めると思ってる。

OO的に部品感覚で使いまわせる部分は（>>491の意見とダブるけど）
基本的なシーン管理、キー入力関連、キャラアニメ管理、パーティクルとかその程度。
まぁそれでも既存のコードを使いまわしたり、それ用のツールを作ってあったりすると
かなり効率は上がるけどね。

499 ：名前は開発中のものです。：03/12/08 13:35 ID:DOpR5iy3

プログラム開発の作業って、ウォーターフォールでやる場合、通常はクライアントからの要求があって、
それを実現するために外部仕様、内部仕様、コーディング、デバッグという流れになると思うんだけど
ゲームだとこの要求が曖昧な事が多いので統一的な手法が確立されない（できない）んだと思う。

なんせユーザーが要求するのものがそもそも”楽しい”とか”ドキドキする”という曖昧なものなので
それを満たす仕様を作成しようと思っても簡単には行かない。
で、企画者が仕様を考えても、その時点でユーザーの要求を満たしているかどうかの判断はつけられない。
結局は、全てが曖昧なままプログラム作成を行うしかないわけで、その曖昧な部分こそが作業の大半を占める、と・・・。

これじゃぁ常にデスマるわけだ（藁

500 ：名前は開発中のものです。：03/12/08 17:58 ID:FgfgXMYM

藁ってる場合じゃないだろ

501 ：名前は開発中のものです。：03/12/08 18:12 ID:kC7SzB4C

>>498-499
それはゲームのシステム
（システムってあいまいだなぁ。
　ここでシステムってのはカードゲームならカードゲームたる部分だとか、
　パズルゲームならパズルたる部分のプログラムのことね。まあ、感覚で頼む。）
の部分だけのことでしょ？
８割ってのもシステム部分の８割でしょ？全体じゃないよね？
これだけ「似たような」ゲームしか出ない、また、ユーザーも似たようなゲームを求めている中で
いまさらそのいいわけはできないでしょ。
（ここで、「え？ユーザーって似たようなゲームばかり求めてるの？」とか言っちゃってる人は
少しは市場を見たほうがいいと思われ。）

少なくとも「システム」（俺のいう）の部分は切り離して組めるわけだよね？
それにできないと考え続けるよりは少しでもできる部分を挙げていく方が発展性があると思うんですよね。
その分他のことをやる時間に使えたらいいですよね？
というわけでできること思いついたらあげていきましょう。

>>491,496に挙げたほかにも
ウィンドウ管理（ゲームでよくあるウィンドウ（ＦＦみたいなの想像してくれい）、本編よりデバッグに重宝します）
もすぐ使えるように作りました。
ウィンドウはWindowsのパクりです、アクティブがあって非アクティブがあって、リストウィンドウやらボタンウィンドウが
あってなどなど（Windowsプログラムを組んだことがある人ならわかってくれるか？）と似たようなものこさえた。
これも結構使いまわせる部分だと思います。

502 ：498：03/12/08 19:49 ID:DOpR5iy3

>>501
うーん・・・ごもっとも。
俺はゲーム全体（ゲーム作成に関する全てのコード)をさして８割近くと言ったんだけど、さすがに言い過ぎたかｗ

確かに現状を見ると似たようなゲームを作るケースのほうが多いので、
そういう意味では同ジャンルなら再利用できる部分は多いよなぁ。
たとえ別ジャンルでも、システムの根幹の部分は変わらない事が多いので
入出力や、ゲームの流れ（タイトル→ゲーム→エンディングみたいな）といった
基本的なシステム部分は一般化できそうだな。

あと、>>499で書いたWF的なアプローチによるデスマ対策としては
・システムの再利用
　→そもそもこのスレで話題になってる部分

・ツール作成＆そういう期間/人員をスケジュールに組み込む
　→企画＆上司の理解が得られれば、の話だけどｗ

・短期間でのリリース
　→WF的に最後にデバッグてのは辞める。XP的テストファーストも自動化しにくいので没。
やはり、　仕様作成→ざっくりコーディング→テスト→仕様変更→さらに作りこみつつコーディング→テスト（・・・繰り返し）
　　という風に漆を塗り重ねるようなイメージで、短いサイクルでの開発を進めていくのが向いてるんじゃないかと。　いわゆるスパイラル？）

あたりかなぁ。なんか良い開発手法を実践してる人いたら教えてﾎｽｨ・・・　　

503 ：名前は開発中のものです。：03/12/08 22:42 ID:ZwB5CqFN

>（ここで、「え？ユーザーって似たようなゲームばかり求めてるの？」とか言っちゃってる人は
>少しは市場を見たほうがいいと思われ。）
おれは遠慮するな、新しいものを作りたい。

504 ：名前は開発中のものです。：03/12/08 23:08 ID:m+V0WGeU

本当に同じだったら誰も買わないって。

505 ：名前は開発中のものです。：03/12/09 00:40 ID:2PY+YvDg

>>504
でも、ＲＰＧだとシナリオスクリプトと画像しか違わないようなのがあるよ。

506 ：名前は開発中のものです。：03/12/09 01:20 ID:K7p7a4LB

>>505ノベル系もな。

507 ：名前は開発中のものです。：03/12/09 07:51 ID:I9RIreYv

バイオハザード系アクションゲ(ry

508 ：名前は開発中のものです。：03/12/09 10:16 ID:JRA4VdQy

ええと、だから、同じようなゲームツクっても売れるから、プログラムもそうすべき
ってこと？>>505-507は、シナリオとスクリプトくらいしか違わなくても嬉々として
買っちゃうのか？

509 ：名前は開発中のものです。：03/12/09 13:35 ID:ZS8LDJqr

>>508
>シナリオとスクリプトくらいしか違わなくても嬉々として買っちゃうのか？
シナリオとか絵柄が気に入れば俺は買うけどね。
別にシステムまで新しくある必要ってあるのかなぁ。

【ここ重要です】｛
　まあ、それはおいといて斬新なシステムのゲームを作るにしても
　全てを全く新しく作り直さなければならないこともないだろう。
　違うなら違う部分だけ作り直せばいいわけだから
　パターンができていた方が違う部分が明確になるってのも利点じゃね？
｝

510 ：名前は開発中のものです。：03/12/09 16:33 ID:9UxSF+MU

>　まあ、それはおいといて斬新なシステムのゲームを作るにしても
>　全てを全く新しく作り直さなければならないこともないだろう。
>　違うなら違う部分だけ作り直せばいいわけだから
>　パターンができていた方が違う部分が明確になるってのも利点じゃね？
そうそう。
で、話は>>502にさかのぼる訳ですが。

511 ：名前は開発中のものです。：03/12/09 21:58 ID:JRA4VdQy

>>510
そんな事言って、
「その仕様は(過去のソースの拡張では)実現できません。」
とか、バカな言い訳はしてないだろうな？

512 ：名前は開発中のものです。：03/12/09 23:30 ID:ZS8LDJqr

>>511
>「その仕様は(過去のソースの拡張では)実現できません。」
それは伝えるべきだと思うよ。（もちろん「過去のソースの拡張では」というところまできちんと）
それを理解してもらった上でそれが新規に作るシステムであることと
それを作成するためにかかる時間の見積もりがしにくいことを踏まえて考えてもらうことができるから。（多分）

ゲーム開発でむちゃくちゃになりやすいところってのはなんでもかんでも新しく作ろうとするところが多い気がする。
（開発期間全体に渡って時間的な見積もりが全く出せないし、開発の終了が全く見えないときがある。
一体この開発でなんの技術が会社に残って、次の開発では何を目標にすればいいのかってのも全くわからない。）

513 ：名前は開発中のものです。：03/12/09 23:53 ID:JRA4VdQy

「ちゃんと再利用性のあるコードを書いている」という前提の元ではね。

514 ：名前は開発中のものです。：03/12/10 09:50 ID:iw8ce43o

>>512
ゲーム開発がデスマーチする理由はそんな所にはないと思うよ

515 ：名前は開発中のものです。：03/12/10 10:07 ID:TCTbyf5r

>>514
まあ、色んな理由があると思うけど。（実際色んな理由があるし）
あなたはどうお考えでしょうか？

ちなみにこんなの↓もあるようです。（１２月４日に書いてある内容）
http://d.hatena.ne.jp/fuck_off/
コレ系は私も味わいました。（エロゲーじゃないですけどね）

516 ：名前は開発中のものです。：03/12/10 10:40 ID:3Ko+mX/z

企画の段階
＃工程的には外部仕様？要求定義？とにかくプロジェクトのとっかかりね
でもたつくわけか・・・
で、企画の曖昧さを最後まで引きずることになると。（・∀・）ﾀﾞﾒｼﾞｬﾝ!

これをなんとかするのもゲＰＧの仕事のうちなのか？？

517 ：名前は開発中のものです。：03/12/10 10:57 ID:TCTbyf5r

>>516
>これをなんとかするのもゲＰＧの仕事のうちなのか？？
いや、そうはいうけど、企画も「何ができるのか」（時間的技術的にその他もろもろ）
って部分が全くわからねぇって部分もあると思うんだよね。
（まあ、根本はマーケティング的、または技術戦略的に会社をどうしていきたいってところまで
ビジョンが見えてない奴になにかを決めるなんてことはできやしねぇと思うんだけどね。ここではそれはおいておくとして）

だからある程度は蓄積があってこれこれ何々ならすぐにできますよって言ってもらえるのは
奴ら（企画）も助かると思うんだよね。（ああでも、こりゃ問題の解決にはならないなぁ。）

518 ：名前は開発中のものです。：03/12/10 11:11 ID:3Ko+mX/z

>（ああでも、こりゃ問題の解決にはならないなぁ。）
そしてこっちに続くとｗ

●●企画屋撲滅スレ●●PART2
http://pc2.2ch.net/test/read.cgi/gamedev/1023006112/l50

519 ：名前は開発中のものです。：03/12/10 19:00 ID:6FKLybEl

当たり前にライブラリつくっていって対応できる部分には別に興味はないです
そんなの当たり前のことだから。

そんなんよりなんかパターンめっけたとか、
とことんまで抽象化して全然関係ない部品を抽象レベルで統一化したので
そのインターフェイスを晒しますとか、そういう話がききたい。

520 ：名前は開発中のものです。：03/12/10 22:37 ID:TCTbyf5r

>>519
俺も長いことそういうの考えてたんだけど最近（つっても２年前ぐらい）そういうのって無駄かもって思うようになってきた。
当然そうあるべき構造を限りなくシンプルな形で表現できるのが一番いい設計だと思うようになってきた。
これがとても難しい。
ついつい処理や先入観でわけてしまって糞設計をしてしまう。
奇をてらったような設計は何かがおかしい。
全然関係ない部品はどんなレベルだろうと統一化はできない（っていうか、しないほうがいいと思われ。）

521 ：名前は開発中のものです。：03/12/10 23:26 ID:7tLBmj31

#たった今、>>520がこのスレの存在意義に関わる大変重大な発言をなさいました。

522 ：名前は開発中のものです。：03/12/10 23:55 ID:TCTbyf5r

>>521
何か勘違いして受け取ってない？

523 ：名前は開発中のものです。：03/12/11 01:34 ID:2EykAttU

プランナ人数：プログラマ人数

の比率にもよるなぁ。

524 ：名前は開発中のものです。：03/12/11 02:45 ID:B35M+i52

>>516 >>517
というか、ゲーム作る前から仕様を決めてしまう、ってのが現実的じゃないと思う。
よく「この企画使えね～、こんな仕様で作れるわけないだろ！」とか愚痴るのを
聞くけど、企画に仕様作らせるのがそもそもの間違いで、仕様はプログラマにしか
作れないし、プログラマ本人も最初からどんな仕様がベストかなんて分かるはずがない。

最近はプログラマの俺のほうから「仕様書はいらん。企画書だけ書いてくれ」と言ってる。
業務アプリのような実用物でも事前に仕様を固めるのが難しいのに >>499 の言うとおり、
ゲームに要求されることは感覚的なことばかりだからなおさら。
ただゲームをでっち上げるだけでなく、面白いものを作ろうと思ったら、トライ&エラーの
サイクルを可能な限り短くするしかない。トライ&エラーが３回行えたプロジェクトより、
１０回行えたプロジェクトのほうが面白いゲームになる可能性が高い。時間は有限だから、
このサイクルの回数を増やすには迅速にトライ&エラーができる環境を作るしかない。

迅速にトライ&エラーができるということは再利用性が高いコードを書く必要があるし、
柔軟性も高くなきゃいけないし、かつシンプルであるほうが望ましいし。
こう言う「“トライ&エラーを繰り返す”を支える部分」だけは手間を掛けて練りこむ価値が
あると思う。他はやっつけでも構わないけど。で、「“トライ&エラーを繰り返す”を支える部分」
てのはゲーム１本のコード量の２０％にも満たさずに実現できると思うんだよね。
具体的には
http://www.gamearchitect.net/Articles/GameObjectRoundtable.html
でやってるようなGameObjectの設計次第なのかな、と。

525 ：とむ ◆0MTMwDpCZo ：03/12/11 02:49 ID:lS65B8Ei

しかし…私もエロゲーは作った事はありませんが、>>515のリンク先に書いてあることは
非常に良く理解できますな。涙無しには読めませんよ、ほんと。

526 ：名前は開発中のものです。：03/12/11 03:56 ID:facpjHOw

>>524
なんか決定的に工程に勘違いや混同をしているかと…

企画が作るのはゲーム仕様、プログラマが作るのはコーディング仕様じゃないのか？
企画がゲームの動きを仕様化してないなんて状態でコーディングするのは
プロジェクトの上位の部分、ディレクションやらの工期の問題であって開発手法の問題じゃないと思うが。
違うなら、スゲーいい加減って言わざるを得ない。

でトライ＆エラーが多いのは、企画が自分のイメージを持っていない、
自分のイメージを上手く伝える事が出来てない証拠。
実行してみて、この方が良いって場合も無い訳じゃないと思うけが
それで仕上げていく前提なんてオカシイよ。

大方、企画の仕様がココで炎のエフェクトって程度しかなく
具体的な炎の内容を聞いてもロクに答えず、実行段階(画面を見て)で
アーだコーだ言い出すって感じじゃないの？

因みにうちのプログラマ上がりの企画は、
炎のエフェクト、3Dでパーティクルにビルボード(用意する指定の画像使用)でアルファ加算処理で表現
パーティクルは主人公の攻撃ヒット地点より実行に支障が出ない程度までで最大に放出
重力影響を受け(0.5程度:社内定数)上方(y方向)に円状(シータ:2pi)に半球状に放出(ファイ:pi*3/4)
って書いてあって、”ごめんね、曖昧な指定で…”ってくらいだよ。
以降は、数値の調整や画像の調整のみで実装方法は変わらない。

トライ＆エラーってこの実装方法がコロコロ変わるって意味に取れるんだけど…
違うの？

527 ：名前は開発中のものです。：03/12/11 04:52 ID:+yejcU5B

>炎のエフェクト、3Dでパーティクルにビルボード(用意する指定の画像使用)でアルファ加算処理で表現
>パーティクルは主人公の攻撃ヒット地点より実行に支障が出ない程度までで最大に放出
>重力影響を受け(0.5程度:社内定数)上方(y方向)に円状(シータ:2pi)に半球状に放出(ファイ:pi*3/4)
>って書いてあって、”ごめんね、曖昧な指定で…”ってくらいだよ。
その企画の人、うちに派遣してくだつぁぃ・・・

528 ：524：03/12/12 02:17 ID:ce4O4lD5

>>526
うーん、視座の違いだなぁ。
僕はもうゲーム仕様とコーディング仕様とに分けて考える考え方を捨てた。
この業界が企画職を設けた理由は「プログラミング能力と企画力･発想力は別物」
だから、昔はプログラマ１人でゲームの全てを決めていたのを分業することになった。
当然そうして設けられた企画職はプログラムの知識はないからプログラムに密着しない
部分だけ仕様を決めてもらうことにした。
でも、これがそもそもの間違いの元だと思う。分けられるはずがないのだ。

で、>>525氏のチームの企画さんはプログラマ上がりなんだから、そのくらいできて当然、
つまりゲーム仕様とコーディング仕様にわけて、なんかじゃなくて、単にその企画者は
“本物の”仕様を決め、プログラマには下位仕様だけ任せているだけ。

「プログラムが出来ない奴は企画やるな」といわれればそうなのかもしれないが、
プログラミング能力と企画力･発想力は別物なのは確かだし、
ほとんどの現場は>>525氏のチームのような状況にはない。
僕の視点のほうがより多くの現場で現実的だ、と思ってる。

529 ：524：03/12/12 02:30 ID:ce4O4lD5

あ、上の525は526の間違い。

>>526
>トライ＆エラーってこの実装方法がコロコロ変わるって意味に取れるんだけど…
うーん、多分、違う、かな……
少なくとも「炎のエフェクト、3Dでパーティクルにビルボード(用意……」なんてな指示は
企画に期待しない。３Ｄソフトのパーティクルエディターをオーサリングソフト代わりにして
必要パラメータをエキスポート、プログラマを介さずにグラフィッカーだけで炎のエフェクトを
インテグレートできる、って環境が前提。企画は「このドラゴンは炎を吐きます」ってだけでいい。
そういう部分は実装のトライ＆エラーの必要はない。
それにそんな見た目の部分はゲームの本質的な面白さには、あんまり関係ないし。

敵配置や属性、キャラ特性などなどの変更を迅速に、かつ直感的にできるようにする、ということ。
もちろんそれだけじゃないけど。

530 ：名前は開発中のものです。：03/12/12 02:39 ID:crSjrPei

>>528
>プログラミング能力と企画力･発想力は別物なのは確かだし
そうか？立証はできないけど、俺は関連があると思う。
自分の頭に描いた企画や仕様を検証するしないできるできないは
確実にでかい差を生むことになると思う。
また、この業界の企画はなぜ企画力・発想力だけを求めるようになっているのかも疑問が残る。
（実現不可能（もしくは困難）な内容を自分で検証する能力をつけるならプログラムが
うってつけのような気すらする。）

531 ：524：03/12/12 03:22 ID:ce4O4lD5

>>530
の割には、プログラマで自分で企画提案する奴って凄く少ない。とりあえず漏れの周りでは。
製作中なんか提案するにしても既存のゲームの要素を挙げるばかりで、とっぴなことは言わないし。

532 ：とむ ◆0MTMwDpCZo ：03/12/12 03:30 ID:iW8Bza97

両面的に必要だと思うんだよね。

企画者が、プログラム的な都合や仕様上の問題を何も理解できず、電波な企画ばかり
言ってきても問題だし、かと言ってプログラマなどの「詳しい」人間が案を出すと、基本的に
「出来そう」、そして「どこかの会社はすでにやってる」ような案ばかりになる傾向があるし。

ただ、企画側も、「プログラム的には無茶だけど、実現できたらかなり面白そう」という
企画を出すのなら、プログラマも無茶は承知で何とかやってみるか、と気合の入れようも
あるんだけど、問題は仕様上問題があるばかりか実現できても何も面白く無さそうな
アイデアばかり出してくる企画者。

仕様上無理、無理じゃないはともかく、「面白い」は最低限欲しいところ…。

533 ：524：03/12/12 03:42 ID:ce4O4lD5

>>532
>仕様上無理、無理じゃないはともかく、「面白い」は最低限欲しいところ…。
それは激しく同意。
漏れもプログラムの事分かってなくて無茶言う企画を「ダメだ」とは思わないけど
言ってることが少し無面白くない奴は絶対ダメだ。

534 ：名前は開発中のものです。：03/12/12 04:25 ID:crSjrPei

>>531-533
だからといって企画の人間にいいアイディアが出るって確証もないですよね？

私は企画といういい加減な線引きの職業が正直いって嫌いです。
シナリオ兼企画みたいな人じゃなくて企画だけで技術無しって人にプログラマやデザイナなどの
技術職と対等な給料払うだけの人間がいるかというといないもしくは限りなく０に近いと思います。
また、その他の仕事（主に雑用）を企画の人間にやらせてしまうことによっていつまでも
作業が分業化しないままだらだらと来てしまったという感じがあります。

プログラマはプログラムを組むだけ、デザイナは絵を描くだけ、サウンドは音を作るだけ
というのがそもそもまずかったのではないかと思うのですがみなさんはどうお考えでしょうか？
現行の企画のやっている仕事は確かに必要です。
しかし、それはほぼ素人の人間にふさわしい仕事とは思えないわけですよ。

私はマーケティングも考慮していない状態のただのとっぴなだけの売れないゲームを作るのが
嫌になってきた開発者のひとりです。

535 ：とむ ◆0MTMwDpCZo ：03/12/12 04:38 ID:iW8Bza97

>>534
それは言えてますね。

今の「企画者」がやっているような作業は、普通に考えるとかなり膨大な仕事で、絶対
必要なんですよね。しかも、「専門家」が。
ぶっちゃけ、プログラマだの絵描きだのって、レベルの高低はあれ、基本的には専門家
ですよね。そのへんの素人よりはよっぽど早く、正確な仕事ができる、と。
しかし企画の人は、ほんと素人の人が多いですね。プログラマや絵描きとして勉強したり
講習会に出かけたりする人はたくさんいるけど、企画者としての能力を高めるために何かを
しようとしている人はあまり見ませんし。
酷いのになると、「ゲームあんまりやらない」企画者もいるわけよ。だから、最近のゲーム
で普通に行われているような処理を全然知らない。

そもそも、企画こそ本当の意味での能力、頭の良さが必要な職業だと思うんですよね。
実際私の見た限り、どこの現場でも、企画者よりプログラマや絵描きの方が頭が切れ
ます。だから、実質的な中身をほとんどフォローでプログラマや絵描きが作っちゃってる
ところが多いです。だから、ここが大切なのですが、企画者が育ちません。プログラマは
自分のプログラムが間違ってたら一発で気づくし、絵描きなら下手なのも分かります。
企画者は、自分の企画がゲーム化するまでにいくつもの工程を通るので、そこまでに
他の人達が潰してきた問題に気づかず、また同じ問題を生産します。
まー現場の連中は常に「このまま作って、企画者にどこがおかしいか思い知らせてやり
たい」という欲求を抱えてますね。しかしそれやると作業が遅れるばかりか、クオリティも
落ちるので、仕方なく手を加える、みたいな…。

536 ：名前は開発中のものです。：03/12/12 05:23 ID:9usRcEJg

なんだかスレ違いな内容にはなってるけど、まぁ、俺的に興味ある
内容なので便乗質問させてもらうけど、みなさんとこの人員構成比率
ってどんな感じですか？

いや、うちのとこ、プランナーの数が、プログラマーの数の1.5倍なん
ですわ。これでは、プランナーの出す要求の実装が間に合うわけなくて
四苦八苦なんだが・・・

OOとゲームプログラミング Role2 というスレタイが、
プランナー排除フィルタリングとして機能してるようなんで、
ぜひ、ここで聞きたい。

537 ：名前は開発中のものです。：03/12/12 06:01 ID:1Z5H5sT5

>>534
良いモノを作るにはそのとおりかもしれないけど、
あまりスパイラルなスタイルで開発をすると
責任問題がややこしいことに。
やっぱり自分の領分以外には出ないのがいちばんでない？

538 ：とむ ◆0MTMwDpCZo ：03/12/12 06:02 ID:iW8Bza97

ﾜﾗﾀ
さすがに企画の数がプログラマの数を越えているという話は初めて聞きました。
しかし、プロジェクト単位で言うと、一時的に「横から口出す人」が増える場合は
ありますね。その時は当然のごとく収集がつかなくなります。

大体、これは企画者に限った話じゃないけど、「みんなでアイデア出せば面白い
ものが作れる」なんてあるわけないのにね。問題は、出たアイデアをどうゲーム
内に落とし込んでいくかが重要なわけで、本当は企画者にその仕事をやって欲しい
のに、結果的にそれを実際作る側の人があれこれ考えて、単にアイデア出した
だけの人が調子に乗ってまたアイデアを出してくる…という例は良くあります。

539 ：名前は開発中のものです。：03/12/12 06:22 ID:9usRcEJg

多人数企画者が、会議に会議を重ねて、企画スタートから1年近くが
経過しても、まだまともなものが動いてない状態。
それなりにセールス実績のあるRPGで、会社としても資金的に余裕のある
状況だからこそ許される怠慢なのだろうか？

既存ジャンルであるRPGに、いったい、なにを話し合ってるのか？

企画が未だに固まらないことに焦った上層部は、さらに
企画屋を投入するらしい。プログラマーの倍に相当する企画屋。
そして、その数はデザイナにせまる勢い。

なんだかなぁ。

「みんなでアイデア出そう！」って、まとまるわけないじゃん。

でも、業界、どこも似たようなこう着状態に直面してるっぽいことが
忘年会シーズンになると再確認してみたり。ため息の多い師走。

540 ：名前は開発中のものです。：03/12/12 06:52 ID:uOuWNHUT

船頭多くして船山に登る。

541 ：名前は開発中のものです。：03/12/12 11:54 ID:crSjrPei

>>536,539
俺のいたところも企画の人数が多くなってきました。
もう２倍ぐらいになったのではないでしょうか？
人数が多いのである部分の企画書を書く人間と仕様書を書く人間と管理責任者と担当者を別々にして
責任の所在をたらいまわしにするという知恵まで身に着けてきて非常にうざくなってきました。
社長が兼企画なんで誰も文句言えないです。
ｶﾞｸｶﾞｸ(((( ；ﾟДﾟ))))ﾌﾞﾙﾌﾞﾙ

>既存ジャンルであるRPGに、いったい、なにを話し合ってるのか？
俺のいたところでは研究と称して勤務中に他社のゲームで散々遊んでおいて研究なんて
全くしていない（既存のゲームをよくみない）人間ばかりでしたね。

>企画が未だに固まらないことに焦った上層部は、さらに
>企画屋を投入するらしい。
ｶﾞｸｶﾞｸ(((( ；ﾟДﾟ))))ﾌﾞﾙﾌﾞﾙ

542 ：名前は開発中のものです。：03/12/12 11:58 ID:crSjrPei

>>535
激しく同意。

543 ：名前は開発中のものです。：03/12/12 13:38 ID:JCbQJbgv

>>539
もうね、企画とか上の人間は「人月の神話」を読めと。
２０年も前にそのへんの指摘がなされてるのに・・・

曰く、
・システムの本質（外部仕様）を決める人間は少ないほうがいい
・遅れているプロジェクトに人員を投入すればさらに遅れる
ｴﾄｾﾄﾗｴﾄｾﾄﾗ･･･

544 ：とむ ◆0MTMwDpCZo ：03/12/12 14:20 ID:iW8Bza97

メインで企画を決める人間は少ない方がいいよね。少ないというか、一人がいい。二人
でも多すぎ。それ以上は論外。

企画者が悩んでいる部分についてアドバイスする程度の人はいいけど、「俺はこの方が
いい」という風に自分の考えをねじ込んでくる人がいると、絶対駄目企画になる。
例え個々のアイデアが正しく、光るものがあったとしても、土台を作った人の考えにない
ものを無理やり詰め込むと、全体としてボロボロになりますね。

上記の書き込みを見ると、そんな簡単な事に気づかない会社がたくさんあるという事です
よね…。そもそもこの業界、「何かを話し合って決める」能力に全然欠けていると思う。
苦手なんだから、やらなきゃいいのに…。

545 ：名前は開発中のものです。：03/12/12 15:56 ID:FUjSxLVp

リーダーシップと取れる人がいない＋とりたがる人がいない
という2重苦ですな(自戒自戒)。

546 ：名前は開発中のものです。：03/12/12 22:10 ID:9cAIl0B8

ブレーンストーミングも知らんのか
愚痴をこぼす前にできる事があるんじゃないの？
プログラマって弱っちい奴ばっかだよほんと

547 ：名前は開発中のものです。：03/12/12 22:19 ID:FUjSxLVp

>愚痴をこぼす前にできる事があるんじゃないの？
それをまとめる人が居ないって話さ。
いや、愚痴をこぼす前にリーダーシップを発揮してチームをまとめるんなら問題ないが。
(みんながそれをやると、ソレはそれで困ったことに…)

548 ：名前は開発中のものです。：03/12/13 00:13 ID:SkPxfghL

>>547
こういう発言（>>546）はスルーできるように成長してよ。

549 ：名前は開発中のものです。：03/12/13 02:24 ID:QNEM2G11

ブレーンストーミングをまとめられる人が少ないのは事実だし。。

550 ：名前は開発中のものです。：03/12/13 03:01 ID:SkPxfghL

>>549
ブレーンストーミングはアイディアを出すための方法だよ
ここで言ってることはアイディアなんてものじゃないんだけど。
見当はずれな発言をどうしてスルーできないの？

551 ：名前は開発中のものです。：03/12/13 03:27 ID:wgwjIfpR

業界10年目。まだ、道は半ばだけど
個人的には、ゲーム作りは「一人独裁制」が向いてると思う。
また、その総統となるプランナは、
デザイナ出身か、プログラマ出身であるべき。

ゲームのデザインの方向性だとか、仕様は全て、その独裁者が責任を持つ。
また、その下の人間は、多少不満があってもそれに従う。
下はゲームに関して、口を出さない。

下手に民主制を導入して、船頭集めてワイワイガヤガヤ会議を始めだすと
制作にとりかかる前の企画段階で1年以上かかることもあった。

この悲劇は避けるべき。

552 ：名前は開発中のものです。：03/12/13 04:33 ID:fFnXDDzH

>>551
> 下手に民主制を導入して、船頭集めてワイワイガヤガヤ会議を始めだすと
> 制作にとりかかる前の企画段階で1年以上かかることもあった。
この状況、よく分かる・・・

> また、その総統となるプランナは、
> デザイナ出身か、プログラマ出身であるべき。
これはよくわからん。経験則かもしれんけど、根拠はある？
あったら知りたい。

553 ：名前は開発中のものです。：03/12/13 04:50 ID:nqIm+14R

漏れんトコも企画の方が人数多いな。
まあいわゆるＲＰＧなわけだが。
リーダーの示した方向性の元で分権された部分の企画を立案し、
素材を発注し、プログラマとネゴして、
（ここまで共同作業スパイラルその１）
プログラマの用意したツール上にあがってきた素材を集約して、
元データを作成してコンバータ通してプログラマに渡して、
内製簡易言語でスクリプトを書いてコンバータ通してローカル環境でテストして、
（ここまでプログラム的仕様の修正を含むスパイラルその２）
企画意図が実現されてるかどうか確かめて、と。

ま、作業がまわりはじめたらそれなりに人数必要ではある。
その前段階は少人数で詰めるけどね。

「ひとり独裁」もいいけど、その場合はその独裁者の器の程度によるね。
アドバイスとかアイデアを取捨選択して消化できる人、
ときにはノイズをシャットアウトできるような人でないと。

ってスレタイから脱線してますな。プログラム的なＯＯの前にチームのＯＯ的リファクタリング？

>>552
「出身」である必要はないかもしれんが、
アイデアに、必要リソースとその成果の見積もりをつけられなきゃ、「プランナー」とは言いがたい。

554 ：名前は開発中のものです。：03/12/13 05:44 ID:828fva8H

じゃあ、スレ内容修正の議論を。
ゲーム、特にコンシューマでバリバリの3Dの場合ってさ
ハード直叩きしたりで速度重視の部分があると
OOなんて要らない、ガチガチのハードコーディングでってならない？
再利用より、速度、速度って。特にハードのリソースが厳しいと、そう思う。

趣味のPCでしかOOなんて使わないっすね。コンシューマで3D専門なもんで。

あ、後は設計の癖っていうか、
OOやる時でも最少部分から組んでくのが普通って思ってたが世の本やなんかじゃ違うのね。
例えば、タイヤクラス、エンジンクラス、ボディクラス、カークラスってやるんだけど(おおばっぱでスマンね)
逆が普通なのね、いきなりカークラスってやるのが本とかに載ってるの。
ビビッた。そんな後付けで各パーツのクラスを構築して行くなんて…アホアホな設計量産って思っちゃうよ…

555 ：とむ ◆0MTMwDpCZo ：03/12/13 06:56 ID:SHFlAG+F

>>554
エンジンから書くような人の場合、OOPLの機能、あるいはOOの考え方そのものが邪魔に
なる時はあるでしょう。前スレでそんな事を書いたっけ…。

後段の設計の癖ですが、それは場合によりけりじゃないですかね。
私もボトムアップで作るのが好きです。しかし、いきなりカークラスを作るのも、別段
おかしいとは思いません。内部的な実装がカークラスに任されるのであれば、下位の
クラスは仮に組んでおく、あるいは代替機能をカークラスにつけておくなどとすれば、
初期の段階で他の部分との実装のバランスがとりやすくなる、というのがあります。

例えば町中を銃持って走り回るゲームの場合、初期の段階では車が別にただの
四角ポリゴンで走り回ってても困らないわけですし。そこで仮の実装が済んでいれば、
複数人開発の時に回りが楽になるし、企画者も把握しやすくなります。

もちろん下から組むのも利点はあるので、つまり時と場合によりけりでしょう。

556 ：名前は開発中のものです。：03/12/13 11:22 ID:SkPxfghL

>>554
>逆が普通なのね、いきなりカークラスってやるのが本とかに載ってるの。
そんなの決まってないと思うよ。
例えば昔カークラスを作ったことがあってタイヤクラス、エンジンクラスなんかが
もう色々できあがってる状態ならNewカークラスを作るのはボトムアップになるじゃん。

べつにどうやるのが普通なんて決まっていないと思うけど。
そもそもooなんてあいまいなものなんだし。

それといくら３Ｄ専門だからってooが邪魔になったことなんてないなぁ。
クンフーが足りねんじゃね？
使わなきゃたまらないよ。

557 ：名前は開発中のものです。：03/12/13 21:22 ID:828fva8H

>>556
データ転送や描画の速度出す為に、専用のデータ形式を専用のコードでってのは
OOとは言わないでしょ？＊＊専用描画クラスって言う？

＞そもそもooなんてあいまいなものなんだし。
あいまいじゃ、極限までスペックを出せないかと…
数学、物理できます、OOプログラム出来ますじゃ、初歩の3Dゲーム程度の物しか作れないかと…
今時の求められるリアルタイム処理じゃ、ハードの仕様それに沿ったコーディングは必須
逆に言いたい、専門的な3Dの”クンフーが足りねんじゃね？ ”

558 ：名前は開発中のものです。：03/12/13 21:48 ID:SkPxfghL

>>557
(　´∀｀)ｱﾊﾊﾊﾊ､ﾏﾁｶﾞｲﾅｲ!

559 ：とむ ◆0MTMwDpCZo ：03/12/13 21:49 ID:SHFlAG+F

>>556
OOが邪魔になる事はあるよ。

そもそも、「OOとは何か」という事に対して私とあなたの考え方が違うかも知れないので、
そのへんで食い違ってたらごめんなさい。
OOの考え方を取り入れるとどうなるかと言うと、モジュールの独立性が上がり、バグを
生みづらかったり、後からの追加修正が容易になる、などが挙げられますよね。
具体的にそれを実現するために、各所で動的束縛を導入し、なんでも「ランタイムに解決
する」という形にしますよね（もちろんそれだけじゃないけど）。

それに対し、エンジンの深い所を書く人になると、そういう事を言ってられなくなる時も
あるでしょう。柔軟性やソースの見通しの良さなんかなくていいから、今ここでハード
コーディングする必要があるんだ、という人は必ずいます。動的束縛を取り入れて、将来の
変更に備えるよりも、アドレスがコンパイル時に決定し、それを見越した最適化をして
欲しい、というのもあるでしょう。継承などを用いた差分プログラムをするより、わざと似た
ものを２つまるまる作って差異だけ書き換えたり、などという事もするかも知れません。
OOの考え方に慣れた人は顔をしかめるかも知れないけど、そういう組み方が必要になる
時はありますよ。
ただ、実際クライアントがそれを使う時のために、C++ならC++風のクラスでラッピング
する、というだけの話で。

560 ：名前は開発中のものです。：03/12/13 22:15 ID:SkPxfghL

>>559
でもこの人
>数学、物理できます、OOプログラム出来ますじゃ、初歩の3Dゲーム程度の物しか作れないかと…
っていってるよね？
きっとあなたの言ってるようなことをいいたいんじゃないよ。
初歩の３Ｄゲーム程度の物しか作れないってさ。
作れない？

561 ：名前は開発中のものです。：03/12/13 22:42 ID:828fva8H

そのハードで、現時点で処理落ちする事なく実現出来る物(エンジン、データ形式含む)があり
その範囲内でやるならOOも有効だと思うが、
それだと、本当にただ3Dになってるだけの初歩の3D表現量でしか出来ないかと。

それは今の環境じゃ処理量が多すぎて実現不可、
しかしクライアントやデレクターがどうしてもって求めたら突っぱねるの？

うちは、データ形式や処理を含めて無駄を省き、専用の処理にして
ハードにその専用データが、決まって来る前提でアセンブリでコーディングなんてやるよ。
勿論、ゲームとしてのインタラクティブな処理結果としての場合は除くけど。
そうしたら、人のクラスだろうが、設計だろうが、データ構造だろうが、処理方法だろうが
関係無しに、そのハードコーディング部分に合わせてもらう。
つまり、オブジェクトとして捉える事は許しません、
コードの中での処理データとして全ての物を捕らえてねって強要。

これってOOと相反すると思うし、OOなんてレベルじゃソコソコの物しか出来無いかな…と。

562 ：名前は開発中のものです。：03/12/13 22:46 ID:SkPxfghL

>>561
(　´∀｀)ｱﾊﾊﾊﾊ

563 ：名前は開発中のものです。：03/12/13 23:37 ID:181hHKLI

適当に10分で書いたc++のソースをg++に通せば
おまえがしこしこ10時間くらいかけて書いたへたくそなアセンブリコードより
よっぽど高速で高品質なものを吐き出せるわ。

564 ：とむ ◆0MTMwDpCZo ：03/12/13 23:59 ID:SHFlAG+F

g++…っすか。

565 ：名前は開発中のものです。：03/12/14 00:44 ID:12MWAfre

>>563
えー、コンシューマのって言ってますよね。
例えば、PS2なんかのVU1のマイクロコードはコンパイラが吐いてくれるなんて有りませんよ。
直接メモリ上に展開して、DMA転送でVU1に送るんですよ。
勿論、インラインアセンブラなんて有りません。

566 ：とむ ◆0MTMwDpCZo ：03/12/14 00:46 ID:HPGm01N4

ところがビックリ、VUコンパイラなんてものが出来て私もビックリ。

567 ：名前は開発中のものです。：03/12/14 00:47 ID:4k8/S6aV

>>565
そんなところまでooに関係する部分なの？

568 ：名前は開発中のものです。：03/12/14 00:56 ID:a4G9S8Ia

>>565
http://www.codeplay.com/
これは違うの？
ずいぶん前からあるようだけど。

569 ：名前は開発中のものです。：03/12/14 00:59 ID:12MWAfre

>>566
ほう…、それってアセンブラってオチじゃ無いですよね？

>>567
例えば、そのVU1の処理で受け取るデータのサイズやアライメントに制限がある場合
勝手にオブジェクト化してクラス(データ構造)作るなって事とか
データ依存ってのは、車だろうが人間だろうが
モデルの頂点のフォーマットやtextureのフォーマットやらが同じ物で括って
機能オブジェクトとして見ないって事とか
そう言うのが、OO的じゃ無いって事じゃないの。

570 ：名前は開発中のものです。：03/12/14 01:00 ID:Fdkc0YxH

いまいち言ってることを理解できないんだけど、俺の理解力が足りんのか？

>それだと、本当にただ3Dになってるだけの初歩の3D表現量でしか出来ないかと。
ようはOO的なアプローチをしていくと無駄なオーバーヘッドが増えるので現状のハードでは
ゴリゴリに書いていくやり方じゃないと「初歩の３Ｄ表現」を超えることはできないってこと？
そもそもXBOXやPS2って、処理能力の限界まで引き出せないと初歩３Ｄレベル（どんなレベルか知らんけどｗ）
を超えられない程度の性能なのか?

>これってOOと相反すると思うし、OOなんてレベルじゃソコソコの物しか出来無いかな…と。
だからといってOO的なアプローチの排除を強要するってのはどうなんだろう。
あんたのところじゃコードの再利用はしないで、毎回書き直してるんだよね？
＃ゴリゴリに限界を引き出すんだから、ゲーム内容が変われば当然そうしてると思うけど。

それって物凄く間抜けだよな。
つーか、プログラマとして「美しくない」と感じたことはない？

俺ならそこまでゴリゴリ書くよりは、コードを再利用できたり
複数人での開発でも余計な領域をいじらせないで済むように
きちっとクラス分けして、お気楽にコード組みたいけどな。

571 ：とむ ◆0MTMwDpCZo ：03/12/14 01:04 ID:HPGm01N4

>>570
だから、それは前に書いた通り「時と場合によりけり」なんじゃない？
本当にゴリゴリが必要なところはそう書けばいいし、あなたみたいに美しく書きたいと
思うのなら、そう書けばいいし。

要は、「OOも使いどころ」って事をみんな言ってるんだと思うので、そうやって反論しても
仕方ないと思うけど。

572 ：名前は開発中のものです。：03/12/14 01:12 ID:5G8/o2fc

パフォーマンスとOOがあんまり関係有るとは思ってないんだけど、
C++において、OOに伴うパフォーマンスの劣化って具体的に何？

573 ：名前は開発中のものです。：03/12/14 01:15 ID:Fdkc0YxH

>>571
時と場合によりけりってのはまさしくそうなんだけど、
>>561があまりにもOOを毛嫌いしてるつーか食わず嫌いというか
決定的に誤解しているように読めたのであえて煽ってみた。

574 ：名前は開発中のものです。：03/12/14 01:16 ID:12MWAfre

>>570
貴方は、ゲームの評価は実行結果ではなくて
コードディングの方法や、開発手法で下すのですか？
それなりのレベルの物なら、時間やコストの問題でOOも有効だと思います。
でも、OO的な設計や手法じゃ処理が追いつかない場合、
ハードコーディングで出来るなら迷わず、それをするべきだと思う。

自分の為じゃなく、クライアントや会社の依頼で求められてるんだから
実行できるか、否かで判断すると吉。

575 ：名前は開発中のものです。：03/12/14 01:18 ID:12MWAfre

>>572
メインの意図しない、下らないインスタンス増産とか…ｗ

576 ：名前は開発中のものです。：03/12/14 01:28 ID:BYQB3yCd

OOすなわち"Object Oriented"はオブジェクト「指向」という
「概念」のことであって実装とは関係がない

オーバーヘッドを伴うとしてよく挙げられるのが
C++での仮想関数呼び出し時のオーバーヘッドだが
あれはC++におけるオブジェクト指向の実装上発生している
オーバーヘッドであり、OO＝パフォーマンスに影響する、
というのは一般論としては有効だが、厳密には間違い

あと、下らないインスタンス増産してるのは
OO云々以前の設計上のミス、もしくは実装者のレベルが低い

577 ：名前は開発中のものです。：03/12/14 01:32 ID:a4G9S8Ia

具体例をあげてない時点でどっちもどっちとしか思えないが、
具体例をあげずにOODでできるものを一概に稚拙なものと決め付けているあたり
食わず嫌いとしか見えないよね、傍目から見てると。

578 ：とむ ◆0MTMwDpCZo ：03/12/14 01:44 ID:HPGm01N4

>>572
だから前にも書いた通り、様々な形の動的束縛とか。

もっとも、私自身はそれほどOO否定派じゃないよ。
OOは一種の考え方であって、それはプログラムの隅々まで全部に通用するというもの
でもないから、使い分ければいいんじゃないの、と。

579 ：名前は開発中のものです。：03/12/14 02:03 ID:5G8/o2fc

「動的束縛」って、仮想関数や boost::function みたいなもんのこと？
動的束縛はOOの実装の一例でしかないので、
「OOに伴うパフォーマンスの劣化」には当たらないと思う。

たとえばC++なら、
template使って静的な実装を行うことも（現状かなり面倒なはずだけど）可能。
OOの考え方は適用できる。

580 ：とむ ◆0MTMwDpCZo ：03/12/14 02:25 ID:HPGm01N4

実装時の話してるんじゃないのかなあ…。

>>579さんの言いたい事もわかるけど、現実にOOPLでOOを利用したプログラムを
作ると、一般的にパフォーマンス落ちると言われているよね。
前スレでも全く同じ議論があったけど、OOの考え方を取り入れて、便利になるいくつか
の部分は、パフォーマンスを犠牲にする部分もあるでしょ。
あなたは、実際プログラムを組んでいて、「こういうやり方は非OOの考え方だけど、
でも今パフォーマンスを求めるためにはこう組んだ方がいい」という場面に出くわした
ことはない？

あなたが、パフォーマンス重視の描画エンジンを書いたりする時に、動的束縛の
オーバーヘッドを嫌ってtemplateてんこもりのプログラムを書くのは自由だけど、そう
したくない（そうしない方がいい）と思っている人もたくさんいるんだよ。

581 ：名前は開発中のものです。：03/12/14 04:33 ID:Z7qDHkCT

>templateてんこもりのプログラムを書くのは自由だけど、
そういうプログラムを書くのに物凄い労力が要るということですな。
しかも、それが本当に再利用性が高いのかということも保証できないわけだし。
一企業の一プログラマがやるようなことじゃないか。戦略的にやるなら別だが。

582 ：名前は開発中のものです。：03/12/14 08:28 ID:4k8/S6aV

毎度のことだけど君ら話がずれてきてるよ。
oo使えないとかいう人はまずこのスレに来ないことを前提にしたまえ。

っていうか

「正直にoo理解してません」

って言えよ

583 ：名前は開発中のものです。：03/12/14 15:41 ID:JuC3FeUd

正直にoo理解してません

584 ：とむ ◆0MTMwDpCZo ：03/12/14 16:26 ID:HPGm01N4

正直にoo理解してません

585 ：名前は開発中のものです。：03/12/14 17:57 ID:1sTSZvC4

ﾜﾗﾀ

586 ：名前は開発中のものです。：03/12/14 19:16 ID:+Qf6BLrD

ていうか、ooの実践によって、
観察しうるほど実行処理の足を引きずることってないよ。

とむ氏は、「場合によりけり」という意見だが
俺的には「場合によらずooしとけ」という意見。

だいたい「バリバリな高速３Ｄゲーム」ってゴロからして学生の妄想だろ？
そのあたりの性能なんて、OOうんぬんの問題ではないことを
まともなプロなら体験している。

587 ：出遅れ：03/12/14 20:00 ID:2LP6MXAF

正直に∞理解してません

588 ：名前は開発中のものです。：03/12/14 20:49 ID:Z/oJAi2+

>>587
それは理解できるわけねえYO

589 ：名前は開発中のものです。：03/12/14 21:19 ID:OJenilbD

バリバリな高速３Ｄゲーム

590 ：名前は開発中のものです。：03/12/14 23:30 ID:4k8/S6aV

>>583-584
やっぱり理解してねぇんだな。

591 ：名前は開発中のものです。：03/12/14 23:45 ID:gdMf3FhF

場合によらずooしとけ

592 ：名前は開発中のものです。：03/12/15 00:34 ID:Ru2IXIKC

>>586
PS2のハード仕様を知ってる？
フレームバッファ、Zバッファ、テクスチャバッファ、カラールックアップテーブル
この用途に使える領域は、全部合わせて4MBしか無いのを。
描画性能としてGSは優れているが、DRAM4MBじゃ
OO使って処理したデータなんかんじゃ、DRAMへのデータ再転送やらで
欲しいfpsが出ない場面が結構出るよ。
データ転送やデータの効率的処理を意識してやると、OOも問題になる場合もある。
なる場合もあるね、全部が全部問題になる訳じゃないけど。

大体、PC以外の大概のコンシューマ機じゃ何かしらの高速な処理や複雑な処理をしようとした場合
コーディングに規制が出るようなモンだと思うが？

593 ：名前は開発中のものです。：03/12/15 00:43 ID:gVuZsoC0

>>592
だからそれを考慮してoo使って組むこともできるんだって。（ＰＳ２ぐらい性能あれば）
ooがどういう概念か知っていていっているとは思えない発言だねこりゃ。

594 ：名前は開発中のものです。：03/12/15 00:57 ID:Ru2IXIKC

>>593
”ＰＳ２ぐらい性能あれば”…??
性能ってどう言う意味ですか？
PCで例えると、メモリー32MB、VRAM4MBしかなく
DMA転送とSIMDと独立プロセッサで性能を出してるマシンを理解しておられますか？

PC等でOOをする場合には意識しない、低レベルな部分、
データのアライメントやニアポインタ、ファーポインタ、キャッシュの制御
これらを意識してコーディングする場合、OO的手法じゃ解決できない場合もある。

＞だからそれを考慮してoo使って組むこともできるんだって
その場合、OO的な手法じゃなくなっていませんか？

595 ：名前は開発中のものです。：03/12/15 01:03 ID:MWq9j+oR

>>592
> OO使って処理したデータなんかんじゃ、DRAMへのデータ再転送やらで
> 欲しいfpsが出ない場面が結構出るよ。

OO使うとデータの再転送が必要で、
OO使わなければその必要が無くなる、
というわけか。
そんなわけないだろ。

596 ：名前は開発中のものです。：03/12/15 01:06 ID:MWq9j+oR

>>594
> OO的手法じゃ解決できない場合もある。

是非、そこをソースレベルで挙げてみて欲しい。

597 ：名前は開発中のものです。：03/12/15 01:11 ID:TQFlj3Po

>>594
覚えたての知識で自慢したいだけでしょう
相手にしなさんな

598 ：名前は開発中のものです。：03/12/15 01:17 ID:Ru2IXIKC

>>959
データを、只の連続したフォーマットのデータとして扱わず、オブジェクトデータとかで持ってる場合
キャッシュへのプリフェッチ処理とかが絡み、余計な構造を持ってるOO的データなんかだと
ストールを起こし、それがかさんでDMA転送に間に合わなくなるような場合すらもおしい時。

599 ：名前は開発中のものです。：03/12/15 01:18 ID:gKTo5NW5

>>594
データのアラインメント：普通のコンパイラならオプションで操作可能
ニア、ファーポインタ：正直分からん、コンパイラ任せになるだろ
キャッシュ制御：インラインアセンブラでどうとでも

OOは言語レベルとは独立した概念だっつーの。
OOD OOP OOPLそれぞれ別物。
OOだとインラインアセンブラ禁止、コンパイラ依存禁止、非ISO=悪とでも言うつもりか？

600 ：名前は開発中のものです。：03/12/15 01:23 ID:gKTo5NW5

ちなみにOO使って処理したデータってなに？
OO*な概念や技術を利用して作られたソフトによって吐き出されたデータと
そうではないデータってまったく別物になるのか？

ちなみに、まっとうな処理系なら
インスタンスのメモリレイアウトなんかに関する情報もドキュメント化されているもの。
別にそれに依存した実装は、移植性が落ちるかもしれないけど
保守性を上げることができる面もある。
美味いところだけ使えばいいじゃん。

あんたはsetterやgetterが無いクラスひとつ見つけただけで
「ほらOOして無いじゃん」とか言いそうだよな。

601 ：名前は開発中のものです。：03/12/15 01:35 ID:Ru2IXIKC

うちの場合、PS2、CUBE、XBOXのマルチプラットホーム戦略とかで
3機種同時で発売ってなる場合もある。
その場合にOO的な手法じゃ無理がある。
VU1のアセンブリはインラインアセンブラでは使用出来ません。
コンパイラ依存じゃ、3機種に跨るクラスはちと苦しい。

で最大の理由は、機種依存のデータをOO的だとは思ってなかった。

602 ：名前は開発中のものです。：03/12/15 01:44 ID:Ru2IXIKC

＞インスタンスのメモリレイアウトなんかに関する情報もドキュメント化されているもの。
＞別にそれに依存した実装は、移植性が落ちるかもしれないけど
＞保守性を上げることができる面もある。

後これも、移植性と保守性の両方を下げると思ってた。

603 ：名前は開発中のものです。：03/12/15 01:49 ID:gKTo5NW5

>後これも、移植性と保守性の両方を下げると思ってた。

移植性は下がる、これは否定し様も無い。

保守性が下がるかどうかはケースバイケースだろ？
処理系依存な書き方は確かに知識の共有がしづらいし、
それ単体で見れば非依存よりははるかに保守性も低いかもしれないけど、
だからといってすべてをアセンブリで記述するほうが保守性が高いともいえない。

604 ：名前は開発中のものです。：03/12/15 06:56 ID:bVVj3V6g

ニアポインタ、ファーポインタって何のことですか？
16ビットCPU(i8086/286)時代の NEAR * , FAR * のこと…？
ぐぐっても数件しか出てこない。

605 ：とむ ◆0MTMwDpCZo ：03/12/15 11:52 ID:GF20Hp3y

>>604
「nearポインタ」などでググれば結構出てきますよ。

要するに、アドレスレジスタ一つで全てのメモリを指定できるようになってないCPUの場合、
ポインタ自体にいくつか種類があって、それがnearとかfarとかだったりするようです。

606 ：クソゲー屋さん：03/12/15 11:58 ID:GqPPhcsq

すまん、正直いって「バリバリな高速３Ｄゲーム」なんて
作らせて貰った事ないよ・・・（´・ω・｀）

607 ：名前は開発中のものです。：03/12/15 12:05 ID:GqPPhcsq

OOは手段ではなく思想だと思うんだけど、このスレでOO否定してる人はどう思ってるんだろ？
クラスや継承やデザパタつかってる＝OO的　ってことか？
だとしたら、はっきり言う。

　ク　ン　フ　ー　が　足　り　ま　せ　ん　な。

608 ：とむ ◆0MTMwDpCZo ：03/12/15 12:10 ID:GF20Hp3y

というか別に思想を否定している人がいてもあまり問題はないと思いますが…。

609 ：とむ ◆0MTMwDpCZo ：03/12/15 12:16 ID:GF20Hp3y

というかですね。人それぞれプログラムの環境が違うので、私も大雑把にしか言えない
のですが、要するにインターフェイスになる上位のクラスではOO的に、オブジェクトの独立
性を保って書いていても、実装部にあたる下位クラスでは、ハードの制約などからあまり
独立性が保てず、OO以前の古い一括管理型のスタイルで書く、という場合があるわけ
ですよね。

それに対し、ある側の人は「それは実装側の問題なので、実際にはOOの手法だ」と
言ってるわけですよね。また別の人は、「それはOOと非OOの混合スタイルだ」というわけ
ですね。
別に後者の言い方をしたとしても、それはOOを否定した、というのとは違うと思いますが。

610 ：名前は開発中のものです。：03/12/15 12:24 ID:gVuZsoC0

>>609
584 名前：とむ ◆0MTMwDpCZo [sage] 投稿日： 03/12/14 16:26 ID:HPGm01N4
正直にoo理解してません

うるせーだまれ。
おまえは口をはさむなよ。
oo理解してませんっていったじゃん。

611 ：とむ ◆0MTMwDpCZo ：03/12/15 12:29 ID:GF20Hp3y

はあ。

612 ：名前は開発中のものです。：03/12/15 12:33 ID:oFhmW6Op

>611
放置してくだちい

613 ：名前は開発中のものです。：03/12/15 12:52 ID:GqPPhcsq

>>610さんへ。
そうですよね、彼には口をはさむ資格はないですよね！
（心の声：また電波小僧か。やれやれだな・・・）

614 ：名前は開発中のものです。：03/12/15 13:04 ID:gVuZsoC0

>>613
そうですよ。
（心の声：いいんじゃないの？コテハンのくせに掲示板でタイプミスまわり取り出したんだからこのぐらい食らわせても。
　　　　　　しかも、こいつ（とむ）oo理解できてるとは思えない。メモリ管理大好きみたいだし。
　　　　　　こいつが出てくると設計の話にならないでハード依存やメモリ管理まわりの話題になりやすい。
　　　　　　大抵、荒れる。（しかも何も有益な情報が無い。）頻繁にコテ＋名無しで串使って自演してると思われ。）

615 ：名前は開発中のものです。：03/12/15 14:44 ID:vKDiZ2A3

俺はとむより↑の方がうざい。

616 ：名前は開発中のものです。：03/12/15 17:36 ID:HrT+RU8H

>>614
ID 晒しておきながら、ここで「そうですよ」と書き込む意図は何？

できればついでに
「コテハンのくせに掲示板でタイプミスまわり取り出したんだから
このぐらい食らわせても」
が日本語に直すとどのような意味を持つのかも説明して欲しい。

617 ：名前は開発中のものです。：03/12/15 17:49 ID:gVuZsoC0

>>616
心の声に突っ込むなよ！

618 ：名前は開発中のものです。：03/12/15 18:14 ID:HrT+RU8H

>>617
もう今更だけどさ・・・
まだ分かっていないみたいだから指摘しておく。

普通の人が
"「正直にoo理解してません」って言えよ "
って言われた場合の反応：
->よく訳が分からんが、とりあえず「正直にoo理解してません」と言う。

普通の人が
"正直に「oo理解してません」って言えよ "
って言われた場合の反応：
->様々な議論・反論が巻きおこる。

正直、もうちょっといろんな文章に目を通して
文章のセンスを磨いた方がいいぞ。

619 ：名前は開発中のものです。：03/12/15 20:35 ID:70PIUBdp

> 普通の人が
> "「正直にoo理解してません」って言えよ "
> って言われた場合の反応：
> ->よく訳が分からんが、とりあえず「正直にoo理解してません」と言う。
言わないだろ。餓鬼じゃあるまいし。

620 ：名前は開発中のものです。：03/12/15 20:49 ID:vKDiZ2A3

「正直にoo理解してません」って返した奴はただのネタだろ

621 ：∞：03/12/15 21:02 ID:VzrqFd0g

普通の人はスルーします

622 ：名前は開発中のものです。：03/12/15 22:28 ID:6FhB98JV

ﾂﾏﾝﾈ（'A`）ﾉ

623 ：名前は開発中のものです。：03/12/16 00:14 ID:AmcLxn0j

つまりバリバリな高速３Ｄゲームはハードの制約のせいでOOなスタイルで開発することが出来ないというわけだな？

624 ：名前は開発中のものです。：03/12/16 00:28 ID:CJHzotFL

(OOはあんまり慣れていないので)従来のやり方で考えているんだけど、
それを「わざわざ」OOに直すと遅くなるし、そもそもそんな時間ない、
ってことじゃない？

625 ：名前は開発中のものです。：03/12/16 00:29 ID:Huz6FkNQ

>>623
(；´Д`)反例としてHalf-Lifeのソースじゃ駄目でつか？
一応ooだと思われるのですが・・・。

626 ：名前は開発中のものです。：03/12/16 00:38 ID:mmFAekCc

>>625
PCじゃん。

627 ：名前は開発中のものです。：03/12/16 00:45 ID:Huz6FkNQ

>>626
じゃ、とりあえずPCではバリバリな高速３ＤゲームはＯＯなスタイルで開発することが可能ということでＯＫでつか？

628 ：名前は開発中のものです。：03/12/16 00:52 ID:mmFAekCc

Pen4-3GにしてFX5900のウルトラでもつんで
メモリ2GBでもつんでハードディスクも1TBあってとかの環境なら
余裕。

論議の前提を良く読み返してみ。
コンシューマ機って固定のスペックで4年程度は引っぱられる現状を理解してる?

629 ：名前は開発中のものです。：03/12/16 00:58 ID:Huz6FkNQ

>>628
Half-Life2じゃなくてHalf-Lifeでつよ。
それでも駄目なんでつか？

630 ：名前は開発中のものです。：03/12/16 01:00 ID:AmcLxn0j

つまりPS2のバリバリな高速３Ｄゲームはハードの制約のせいでOOなスタイルで開発することが出来ないというわけだな？

631 ：名前は開発中のものです。：03/12/16 01:06 ID:Uo9/VOQt

アホくさ

632 ：名前は開発中のものです。：03/12/16 01:09 ID:b2wSUQbS

>>631
なんてこと言うんですか！
みんな真剣なのに・・・

633 ：名前は開発中のものです。：03/12/16 01:30 ID:Huz6FkNQ

反例としてhalflifeが駄目というならPS2の環境は
ＰＣのhalflifeのミニマムスペックである

WindowsR 95, Windows 98 or Windows NT 4.0
PentiumR 133
24 MB RAM
2X CD-ROM drive
Mouse and Keyboard
640x480 SVGA high color (16-bit) display
Windows-compatible sound device

この環境↑に負けてしまうんでつね・・・(つД`)

634 ：名前は開発中のものです。：03/12/16 02:59 ID:mmFAekCc

>>633
話の趣旨としては、PCとコンシューマでは細かいハードの構成やハードの販売戦略が違い
比べる時点で意味無いって事なんだが…

……halflifeの何処がバリバリ(この表現嫌だけど)の3Dゲームなんですか？
せめてグローシェーディングでライトも数個使って、ビルボードも目立たない物
程度から名前を挙げてくれよ…

635 ：名前は開発中のものです。：03/12/16 03:18 ID:Huz6FkNQ

>>634
(；´Д`)それはそうと日本のゲーム機ってとことん糞でつね。

636 ：名前は開発中のものです。：03/12/16 03:47 ID:f5yskM1V

>せめてグローシェーディングでライトも数個使って、ビルボードも目立たない物
>程度から名前を挙げてくれよ…

まあなんつーか。
たとえどんなものを上げてもケチつけるだけだろうよ、あんたは。

637 ：名前は開発中のものです。：03/12/16 03:51 ID:FudIEgl8

＞コンシューマ機って固定のスペックで4年程度は引っぱられる現状を理解してる?

現状のPS2で特に不満ないけどね。
逆に言えば、4年しかひっぱらねーのかよ！って人も多いでしょ？
馴れたと思えば、次世代。

638 ：名前は開発中のものです。：03/12/16 07:28 ID:ThVUHRA7

>せめてグローシェーディングでライトも数個使って、ビルボードも目立たない物
>程度から名前を挙げてくれよ…
これをするとOOで作れなくなるという主張？

639 ：名前は開発中のものです。：03/12/16 11:16 ID:Dm2m+BAd

こういう奴って、速度が犠牲になるので構造化プログラミングもできませんとか言いそうだなw

コンシューマでOOできないとか言ってる奴はとりあえずOOがどういうものか勉強して、
実装＆テストしてみてから言ってるんだろうな？
食わず嫌いで勉強もしてないくせに、ただ聞きかじった知識だけで遅いとか言ってるのなら氏ねと。

そもそも次元の違う話だということに気付けよ。

640 ：名前は開発中のものです。：03/12/16 13:12 ID:xmC7zEcr

俺もカリカリにチューニングする時はそこだけＯＯの手法を使わない事がある。
他人のスタイルにまでケチつける事ないだろ。
ＯＯでやりたい奴はやれよ。あえてやってない奴にまで押しつけるな。

641 ：名前は開発中のものです。：03/12/16 14:43 ID:Dm2m+BAd

>>640
じゃ聞くが、なんでこのスレであえて「OOやってません」と言う必要があるんだ？

642 ：名前は開発中のものです。：03/12/16 15:09 ID:o0KrzGlT

OOやってないじゃなくて、場合によって使い分けてるって話だろ。
問題ないんじゃねーの？

643 ：名前は開発中のものです。：03/12/16 16:13 ID:Dm2m+BAd

>>642
>>557や>>561あたりから今の流れになってるんだが、
これが「場合によって使い分ける」なんて穏やかな話なのか？

644 ：名前は開発中のものです。：03/12/16 16:17 ID:o0KrzGlT

だからハードに特化したカリカリの奴を書きたい時はOOを使わないって話だろ。
それを使い分けって言うんじゃないのか？

645 ：名前は開発中のものです。：03/12/16 16:27 ID:Dm2m+BAd

>>644　だからぁ・・・>>641（以下無限ループな。もう知らん。）

646 ：名前は開発中のものです。：03/12/16 16:30 ID:o0KrzGlT

>>645
だから>>641は「そこだけ」って限定してるだろ。それを使い分けって言うんじゃないのか？

647 ：名前は開発中のものです。：03/12/16 16:47 ID:o0KrzGlT

おっと、>>640だな。>>640が使い分けの話をしているのに、「OOを全く使わない」という風に
受け取ってる奴がいるからいちいちケンカになるんじゃないか？

648 ：名前は開発中のものです。：03/12/16 17:40 ID:sbMkjSta

おまえら子供かよ・・・

649 ：名前は開発中のものです。：03/12/16 18:23 ID:HSV7UzEe

どうでもいいけど、ここは「OOとゲームプログラミング」ってスレなんだろ？（>>1参照）

OOは使いません、とか、OOを押し付けるな！て人は
なんでここにいちいち書き込んでるだ？！

使い分けるなら、使わないパターンの話じゃなく、
使う場合、どう使うかって話をした方が建設的じゃないのか？

それともOOとゲームプログラミングがいかにマッチしないかを
語るスレになったのか？

そうですか。さいですか。

650 ：名前は開発中のものです。：03/12/16 19:02 ID:o0KrzGlT

だから使い分けの部分を語る分には問題ないだろ。

651 ：名前は開発中のものです。：03/12/16 20:27 ID:f5yskM1V

>>642
oo使ってる奴はとりあえず動くだけの初歩的な3Dしかできないと切って捨ててなかったか？
oo使うと～って書き方だとoo使ってる奴を全員否定してることになるんだが

652 ：名前は開発中のものです。：03/12/16 20:35 ID:o0KrzGlT

>>651
俺はそいつとは違う奴だけど、そいつだってOO使う奴は全部初歩的だと言ってるわけじゃないだろ。
OOが使えるってだけじゃ駄目だ、という事を言いたかったんじゃねーの？

653 ：名前は開発中のものです。：03/12/16 21:57 ID:zXGo5vmH

「カリカリにチューニングする」って口にするのも恥ずかしい死語。
ＯＯとは関係ないしな。

654 ：名前は開発中のものです。：03/12/16 22:53 ID:gEo9Va08

「バリバリに高速な３Ｄ」とか厨臭い言葉が出だしたあたりから空気が澱んできたなｗ

655 ：名前は開発中のものです。：03/12/16 23:38 ID:Mtx2gFve

部分的にOOじゃないということは
それ以外のほとんどの部分（全体的な設計は）OOの手法で
作ってるってことだな。

656 ：名前は開発中のものです。：03/12/16 23:42 ID:ThVUHRA7

OOといえば厳格なPure OO、構造化といえば、ダイクストラの構造化理論に
完全にのっとったコード、というのが「OOでは出来ない」の正体だろう。

657 ：名前は開発中のものです。：03/12/17 00:08 ID:0955yT2K

誰かＣ＃でOOなゲームライブラリ作ってくれないかな

658 ：名前は開発中のものです。：03/12/17 00:19 ID:vIjko+pl

MａｎａｇｅｄＤｉｒｅｘｔＸ

659 ：名前は開発中のものです。：03/12/17 01:06 ID:taNV/FmE

>>誰かＣ＃でOOなゲームライブラリ作ってくれないかな
現実的に、最も大きい市場を握ってるのがPS2である以上、
そんなもの役に立たん。
C++でも十分にOOを発揮できるので、それが我慢しろ。

660 ：名前は開発中のものです。：03/12/17 03:56 ID:jIuJooCH

>>529
オソレスなんだが、、企画が責任持ってオーサリング（実作業）する
って意味では、良いんじゃないかと思う。＞トライ＆エラー

ただし、モーションやモデル、エフェクトは、直ぐ作れるものでもない場合が
あるので、その絡みは何度も作り直すとキレる人が出るだろう。

そのドラゴンがどのぐらいの位置付け（強さ等）かしっかり考えてあれば、
攻撃方法がコロコロ変わる事はないはずだし。
逆に、細かい演出の話より、そういった情報を早期に、明確に伝えろよ。と

661 ：524：03/12/17 05:18 ID:WhY2w/49

>>660
>企画が責任持ってオーサリング（実作業）するって意味では、
>良いんじゃないかと思う。＞トライ＆エラー
ああ、僕の考えでは「企画の仕事＝オーサリング」って思って
そこを強調しなかったから「それじゃ企画の暴走を許すだけで、
デスマーチ直行じゃないのか？」って思われたのかな。

しっかりオーサリング環境作るから後は勝手にやって、の方が
企画のとの密なやり取りが開発前半に集中して
後半はプログラマはデバッグ＆アドバイス、特殊処理の追加
企画はオーサリングと調整に集中できて、お互いにいいと思う。

オーサリング環境がしっかりしてれば大概の事がプログラマの
手を借りずに実装できて、プログラマが「ここまでできるとは…」と
ビビるようなデータを上げてくることもあって、プログラマ冥利に尽きる。
そういう創発性がゲームのクォリティーを上げると思う。

662 ：名前は開発中のものです。：03/12/17 06:11 ID:AMf5ntWZ

しかし、それらは既存ジャンルで通用する工程手法。
枯れたジャンルでは存分に発揮できるケースかもしれない、が、

もし、もっと根本から試行錯誤を要する挑戦的なタイトルだったら
どうする？

企画が、上位レイヤのコーディングをできるくらいでないと
話にならないかと。

663 ：名前は開発中のものです。：03/12/17 11:15 ID:+mshrDBr

>>662
>もし、もっと根本から試行錯誤を要する挑戦的なタイトルだったら
>どうする？
どうするって・・・やった事ないんだろ？でも例によって納期は決まってるんだろ？
そんなのOO的開発とかスムーズな工程とか無視して「ひたすら試行錯誤」しかないのでわｗ

そもそも、そんな面白そうなプロジェクトに関われるのなら
工程とか手法とか無視して連徹してでも頑張るんだがｗ

664 ：名前は開発中のものです。：03/12/17 19:32 ID:1OhOd6Py

デスマーチ上等とか思えるほどの企画がくれば楽しいだけどな～

665 ：660：03/12/17 23:13 ID:jIuJooCH

>>661
初めて企画屋と意見が合ったよ。
みんなそういう考え方だとＰＧも楽出来るのに。
（楽なだけじゃなく、結果的にもクオリティ上がる）

紙に２、３行説明書いて終わったと思ってる糞企画も多いしね。
（で、大抵そういうのは、破綻してる。紙の時点で）
珍しい。

でも、なんでもやりたがるＰＧがいるのも事実。（なんでなん？）
演出的な部分はデザイナにやらすべきだと思うが。
メニュー関係とか、ＰＧがやってくれるんでしょ？てなデザイナもいるし。

でも、モーションの作り直しの発生は中々避けられないのが、３Ｄになってからの
キツイ所だと思うね。
（モーションを殆どプログラム制御してしまう（ＩＫ等で）なんて無理だろうし）

666 ：名前は開発中のものです。：03/12/18 00:15 ID:OYeR0wJ5

>>665
オーサリング環境作ってもなんとかして自分の作業を減らそうとする企画屋が実は多い罠。
やらしてみたらとても商品として出せないぐらいのレベルだったりすることもままあり。

前に企画書みてあんまり膨大な量だったんで、オーサリング環境作って「ほい、あとは頼むわ」って
投げたら、そいつ自分で書いた企画書変更して物量減らしてやがるし。
プログラマには平気でプロなら結果を出してくださいねとかいいやがるくせに
自分で書いた企画書変更ですか・・・そうですか・・・。

という状況を楽しむためだけにオーサリング環境はあるものだと思った。
技術にうとい企画があげてくるものに商品に値するものをみたことがない。
企画にやらせた部分はクオリティは下がるね。

と、話は長くなったけどなんでもやりたがるＰＧって俺と同じこと考えてる人間で
尚且つ、いいゲームを作ろうとしてるやる気のある人じゃないかな？
でも、それだったらデザイナにはまかせてもいいか・・・。

667 ：名前は開発中のものです。：03/12/18 01:04 ID:SxM0s57g

どこの職場も、プログラマとデザイナは、意気投合してるね。
職務的には、まるで違う方向なのに。不思議。そして、プランナだけが
目の敵にされがち。これも不思議。

668 ：524：03/12/18 01:51 ID:vqto5TtK

>>665
いや、俺はプログラマ。企画屋じゃないです。
目下この考え方（企画の仕事＝オーサリング）を企画に布教中。
一個前のプロジェクトで、食わすデータ次第でいろいろできる、というのを
痛感させたから、浸透させられるかな～と。
人が少ないんで、制作進行業務に配分取られがちなのが痛いが。

>>667
やっぱ彼ら企画者は、何らかの実作業のスキルってものを示さないと
信用されない、ってことを肝に銘じるべきかと。
信用されてる企画って、大概（言うことが面白い、というのも含め）何らかの
スキルを示せる人たちだし。
企画の登竜門＝制作進行っていうこの業界の採用の仕方がそもそも良くない。

669 ：名前は開発中のものです。：03/12/18 01:54 ID:vqto5TtK

いま、PS2で動的型情報を自前で作るかそれともtype_infoに頼るかで迷ってるんだけど、
だれかPS2でtype_infoに頼った設計をした人いない？
どれだけメモリを圧迫するものなのか知りたい。

670 ：名前は開発中のものです。：03/12/18 02:05 ID:OYeR0wJ5

>>669
その質問はどっちかっていうとこっち↓むきじゃないの？

ゲームプログラミング相談室【Part5】
http://pc2.2ch.net/test/read.cgi/gamedev/1036410116/l50

671 ：名前は開発中のものです。：03/12/18 19:26 ID:4pr+UY4P

>>668
僕もスクリプト・データドリブン式プログラムを中心にしています、
オーサリング環境を作るのに企画の大雑把な仕様がいりますが、
実際に作り始めると常にオーサリング環境の枠を超えざるを得ない問題が出てきます。
その辺りはどうしてます？

僕は、移植作品でもない限り、ゲームを完成するのに十分に強力なオーサリング環境の作成は非現実的と考えています。
それで、適当な所でプログラマーが関与できる余地を残して妥協してます。
最後は力ずくでプログラムですね。

672 ：名前は開発中のものです。：03/12/19 04:16 ID:VfGFpDIA

>>僕もスクリプト・データドリブン式プログラムを中心にしています、
(　´д)ﾋｿ(´д｀)ﾋｿ(д｀ )

673 ：名前は開発中のものです。：03/12/19 09:12 ID:Lx8rGMZA

スクリプト・データドリブン式って？

674 ：名前は開発中のものです。：03/12/19 13:30 ID:jxyh5RLW

>>673　今、>671が必死に考えてるところだからおとなしく待ってな。

675 ：名前は開発中のものです。：03/12/19 17:03 ID:46dcK3tk

つか言葉通りだと思うが。

676 ：名前は開発中のものです。：03/12/19 21:04 ID:6xun75BG

データドリブン？

イベントドリブンでは？
いや、ポーリングじゃないの？

677 ：名前は開発中のものです。：03/12/20 01:41 ID:fMOnX6G5

まだ分からない人がいるようです

678 ：名前は開発中のものです。：03/12/20 10:13 ID:vVhX2faS

吾輩も別におかしいところはないと思うが。

679 ：524：03/12/20 10:19 ID:rIwyOINw

スクリプト・データドリブン、の何がそんなにおかしいの？

>>671
> 実際に作り始めると常にオーサリング環境の枠を超えざるを得ない問題が出てきます。
企画・スクリプターから「今の機能じゃ出来ません！」ってあがってきた要求の８割は
ちょっと頭を捻れば既存の機能の組み合わせでいける、ってケースが多いような。
で、それがあんまりにもめんどい作業ならそれをサポートする機能をつけてあげて、
まったくの新機能を乗せなきゃいけない要求は、納期と必要性と実装難易度と相談で
組み込むものをいくつかピックアップ、て感じかな。

結局はいくつかあきらめなきゃいけないことがでてくるけど、ゲームを現実のものにする
には仕方がないかと。

>>676
データドリブンというのは、（理想的には）何もハードコーディングしないプログラミングスタイル。
イベントドリブンとは何の関係ないです。

680 ：名前は開発中のものです。：03/12/20 10:51 ID:jbY/JiT0

>>679
>データドリブンというのは、（理想的には）何もハードコーディングしないプログラミングスタイル。

データドリブンは珍しい言葉ではないけど、
(http://www.google.co.jp/search?q=%E3%83%87%E3%83%BC%E3%82%BF%E3%83%89%E3%83%AA%E3%83%96%E3%83%B3&ie=UTF-8&oe=UTF-8&hl=ja&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja)
>>524の認識は根本的に間違っていると思うが？

681 ：名前は開発中のものです。：03/12/20 11:17 ID:kVrm9apv

>データドリブンというのは、（理想的には）何もハードコーディングしないプログラミングスタイル。
モデリングとは違う？

ぐぐってもクエリ関連しかヒットしないけど・・・

682 ：名前は開発中のものです。：03/12/20 14:05 ID:QbvQdw7+

(　´д)ﾋｿ(´д｀)ﾋｿ(д｀ )

683 ：名前は開発中のものです。：03/12/20 14:46 ID:69JYnftb

http://www.google.co.jp/search?hl=ja&ie=UTF-8&oe=UTF-8&q=%22data-driven+programming%22
こんな風に検索するといろいろ出るよ。

684 ：名前は開発中のものです。：03/12/20 17:11 ID:kVrm9apv

ふ、完全英語か

685 ：524：03/12/20 23:48 ID:rIwyOINw

>>680
ああ、データドリブンってもともとデータベース関連の用語だったのか。
ゲーム開発独特の用語だと思ってた。

ゲーム開発でデータドリブンといったら
　　#define SCREEN_WIDTH　　640
　　#define SCREEN_HEIGHT　 480
　　setScreen(SCREEN_WIDTH, SCREEN_HEIGHT);
とかやらずに
ini.scr:（テキストファイル）
　　ini = { 640, 480 }
Cソース
Datum d = load_data("ini.scr");
INI_DAT ini = d.get("ini");
　　setScreen(ini.screen_width, ini.screen_height);
ってなことをあらゆるところでやる、って程度の事だと思ってたが。

686 ：名前は開発中のものです。：03/12/20 23:58 ID:Oe+zcBCM

>>685
あーそういう意味だったのか、やっぱ。

それは普通にやるなぁ…データドリブンって言うんだ…ふーむ。

687 ：名前は開発中のものです。：03/12/21 00:28 ID:NSfzzMMm

>>685
>ああ、データドリブンってもともとデータベース関連の用語だったのか。

それも勘違い。もしかして、ネタ？

688 ：名前は開発中のものです。：03/12/21 01:06 ID:KhQmPO5+

>>687
そういうなら、詳しく解説してみろよ。

689 ：名前は開発中のものです。：03/12/21 01:56 ID:JduXcNzT

>>688
どうして自分で調べられないのかなぁ。
http://www.info.kochi-tech.ac.jp/iwata/DDP/datadriven.html

690 ：名前は開発中のものです。：03/12/21 02:24 ID:67uLHsXR

>>685
俺も同じ認識です。
特に意見がわかれた事もない。普通に通じてた。

ＤＸのシェーダーもスクリプトも、バイナリ食わせる意味でそう認識してた。

691 ：524：03/12/21 03:20 ID:D51y0RxR

>>688
それはハードよりのお話ですね。
門外漢なんでよくわからんですが、それはデータを食わせてやれば
新しい命令が動的に生成されるチップ、ってな意味では？
とにかくコンピュータのいろいろな分野でデータドリブンという語は
使われていて、DBの用語が発祥ではないんですね。勉強になりました。

やっぱソフトウェアの、特にゲームにおける解釈では>>685 で書いた
程度の認識でも別に間違ってはいない気がする。（もちろん、あれが
全てじゃないけど）

モデルデータなどを外に置く、などはデータドリブンとは言わないとして、
（もちろんモデルを差し替えれば表示が変わるのだが、「プログラムの
挙動が変わった」とは普通言わないと思うので）
敵キャラの挙動とかは全種類分プログラムするのではなくプログラムは
共通でパラメータを変えてやればいろいろバリエーションが出せるよ、
という仕組みを、ゲーム作りに慣れてくると自然に採用するようになる。
これがデータドリブンの第一歩で、そのうち再ビルドの必要がないように
外部ファイルにパラメータを置くことになり、行き着く先は
「何もハードコーディングしない」という境地。

そんなものはデータドリブンとは言わん、って言われたらそれまでだけど、
ゲーム業界でのデータ駆動の定義ってこんなところだと思ってたんだけど…
どうなんでしょ？

692 ：名前は開発中のものです。：03/12/21 04:56 ID:67uLHsXR

>>691
いんでないの？
実際、そういう汎用ファイルを使うゲーム用ミドルウェアもあるし、
ＭＡＸのモデルデータだって、ジェネリックなデータを含ませる事も出来る
。

693 ：名前は開発中のものです。：03/12/21 07:43 ID:+N4aPlxT

なんでもかんでもを突き詰めて、ロジックまでも外部に追い出すと
それはもうインタプリタでそこにハードコーディングしたら同じ事だと思うが。
インタプリタからデータを切り分けていって、さらにインタプリタのようなものを作る？
いったいどこまで層を重ねれば満足なんだ？

694 ：名前は開発中のものです。：03/12/21 09:37 ID:QvgThfoX

>>693
極端だなあ。
どこまで層を重ねるかってのは、
それこそ俺たちプログラマの仕事じゃん。

695 ：688：03/12/21 10:41 ID:KhQmPO5+

>>689が話の流れも分かってないし、説明できる能力も無いことは分かった。

696 ：名前は開発中のものです。：03/12/21 12:28 ID:jOA8lZ+F

>>694
俺は>>693じゃないけどどうせインタプリタみたいなもの作るなら
コンパイラさえあれば普通にプログラム組んでもらったほうがはやいと思うんだけど。
（コンパイラさえあればね。スクリプタが２～３人程度ならもうプログラム組め。）
現状は個人のプログラマの好み（？）で何をデータとして出して何をプログラムで
組むかということが決まってしまっているけど、はっきりいってあんまり当てにできない。

つか、これって開発方法退化してるような気がするの俺だけでつか？
どうせならFlashみたいなタイムラインでビジュアル的に管理できないかなぁとか考えてるんだけど。
（ActionScriptをメインに使う人ってあんまりいないよね？）
で、ちょっと細かい設定や条件分岐なんかあるところはスクリプトで組んで。
（これもビジュアルで管理できるんじゃないかなぁと考えてる。）

この辺みんなどう思って組んでるの？

697 ：名前は開発中のものです。：03/12/21 12:40 ID:KhQmPO5+

まぁ、リコンパイルとかリンクとかが凄い時間かかる環境もあるみたいだから、
そういうところでは、すぐに試せるインタプリタって有効じゃない？

698 ：名前は開発中のものです。：03/12/21 15:05 ID:umho+FGH

>この辺みんなどう思って組んでるの？
天秤にかける

データドリブンの意味がいまだにわかってないが
まぁいいか

699 ：696：03/12/21 16:30 ID:jOA8lZ+F

>>698
いや、天秤にかけるとかそういう話じゃないんだけど。
ところで俺はデータドリブンの話は参加してないなぁ。

700 ：名前は開発中のものです。：03/12/21 17:03 ID:umho+FGH

思いっきりデータドリブンと話が絡んでいるように見えるが俺がバカなだけだろうか

701 ：名前は開発中のものです。：03/12/21 17:44 ID:67uLHsXR

>>696
はやいとか云々言ってるて事は、スクリプト化する目的わかってないんでわ？

702 ：名前は開発中のものです。：03/12/21 18:06 ID:JmRbG8Pk

あんまりドリブンドリブンって書いてあるのを見ると
「ダメダコリャ」って言いたくなってくるな。

703 ：名前は開発中のものです。：03/12/21 22:18 ID:jOA8lZ+F

>>701
正直わからないです。
説明おねがいしますです。

704 ：名前は開発中のものです。：03/12/21 22:20 ID:jOA8lZ+F

>>701
ちなみに私の言う「はやい」ってのは処理速度ではなくて手間の問題です。
てっとりばやいの「はやい」です。

705 ：名前は開発中のものです。：03/12/21 22:35 ID:6UVSE1+r

私のいう「やばい」は、そんじょそこらのものではなく絶体絶命に近いです。

706 ：名前は開発中のものです。：03/12/21 22:49 ID:X5QzV1YY

私のいう「やばい」は>>705のレスです。

707 ：俺は後者：03/12/21 23:09 ID:KhQmPO5+

ワケワカラン。
このスレには、はっきり説明できない知ったかと、無知のクレクレ君しか居ないのか？

708 ：とむ ◆0MTMwDpCZo ：03/12/22 00:40 ID:GsUvLAo2

ドリブン勘定。

709 ：名前は開発中のものです。：03/12/22 02:49 ID:a9pD1dqB

>>707
それと、名無しレベルの思いつきで名無しレベルの下らない半端な内容を
ご丁寧にトリップまでつけてレスするクソコテが約一名。

710 ：とむ ◆0MTMwDpCZo ：03/12/22 03:24 ID:GsUvLAo2

（やっぱりドリブン勘定は面白くなかったか…）

711 ：524：03/12/22 04:48 ID:BarbrQWt

>>697
まさにそれ。ついこないだ終了した途中参加のプロジェクトは、特にインクルードの依存性を
少なくする努力がまったくなかったから（main.hなんてのにに何でも突っ込んでて
ほとんどがそれを参照してるんだもんなぁ）誰かがコミットするとほぼリビルド状態、ビルドに
２０分近くかかる、ってな状況だったから。スクリプトはほんとにイベントの制御に使われるだけで、
ちょっとした内部パラメータなんかは全部ハードコーディングだったから、こうなる。

それにやっぱりC/C++のような静的な言語ではパワー不足だ、と思う。ラッチェット＆クラークス
なんかはC/C++でかかれたコードよりスクリプトのコード量のほうが圧倒的に多いらしいし。
もっとプログラマはC/C++でだけでなく、スクリプトによるプログラムもすべきだと思う。
ファイバやマイクロスレッドと呼ばれるような協調型スレッドよりもluaのcoroutinのようなスクリプト
が提供する疑似スレッドの方が手軽だし移植性も高い（ハードが変わっても書き直す必要なし）
オーバーレイでバイナリコードを動的にロードするよりも、スクリプトをロードするほうが安全で手軽

>>695
できればやっぱりビジュアルなほうが良いけど、ゲームの要素ってイベントシーン以外は時系列順に
並ばないわけだから、Flashのようなインターフェースでは適用できる個所が少なすぎる気がする。
有効グラフで状態遷移を組んで～なんてやれると良いけど、まだ誰も作って公開してないから
自分で作らなきゃいけない……テキストベースのスクリプトなら、luaという定番が既にあるのに。

712 ：524：03/12/22 04:50 ID:BarbrQWt

あ、上の>>695 は >>696の間違い

713 ：名前は開発中のものです。：03/12/22 05:52 ID:aqsRki1m

>>711
なんかなぁ。
main.hで全部が完結していてかつパラメータがヘッダで定数宣言せずにハードコーディングだとしたら
main.hなんかはプリコンパイルしておけば「コンパイル速度だけは」速いはずなんだが。

714 ：名前は開発中のものです。：03/12/22 06:02 ID:keFESsDj

プロジェクトメンバ全員がわかったふりしたド素人ですな。

715 ：524：03/12/22 06:05 ID:BarbrQWt

>>713
main.hをプリコンパイルしても意味なかったのよ。そのケースでは。
main.hでインクルードしてるヘッダファイルの内容がガリガリ変わるから。
頻繁にプリコンパイルした上でなおかつほぼリビルド、になってしまう。

プリコンパイルはライブラリのヘッダだとか滅多に変わらないものに
適用しないと意味ない。で、それらはプリコンパイル済みにしたんだけど、
ほぼリビルドという状況は変わらないもんだから、２０分かかるのは
変わらなかった。

716 ：名前は開発中のものです。：03/12/22 06:28 ID:pt4+Gqpg

>>524
もういいよ

717 ：名前は開発中のものです。：03/12/22 13:50 ID:7hb7s2VC

>>715
>main.hをプリコンパイルしても意味なかったのよ。そのケースでは。
>main.hでインクルードしてるヘッダファイルの内容がガリガリ変わるから。
いや、いくら途中参加でもリファクタリングすれば済むのでは・・・というかすべき。
どんなに長くても１日あればその辺の切り分けはできるっしょ？
つーか、そんな状態を許してるそこのメインプログラマに（ry

それはそれとして、スクリプトによるパラメータ定義は中規模以上だと必須な気がするよ。
PG全員に徹底するとなると、なかなか適用できないけど・・・
俺が関わってたプロジェクトだと、企画に調整させるパラメータだけiniファイルに書き出して
調整用はその範囲内でってお願いしてた。
（そうしないと、企画に無茶苦茶なパラメータ設定されて「うごかねぇぞ！」とか逆ギレされるんで・・・鬱）

718 ：名前は開発中のものです。：03/12/22 16:20 ID:Ksn6aYhp

>>717
>いや、いくら途中参加でもリファクタリングすれば済むのでは・・・というかすべき。
意地とか面子とか妙なものあるわけですよ古株には。
自分の組んだプログラムを他人に修正されるなんて嫌・・・みたいな。
レベル低いくせに自信だけはたっぷりぷりなのでどうしようもないんですよ。

719 ：名前は開発中のものです。：03/12/22 16:48 ID:aqsRki1m

そもそもそれなら自分の作業では変更が発生しないんだから問題ないじゃん

720 ：名前は開発中のものです。：03/12/22 23:46 ID:Ksn6aYhp

>>719
発生するでしょ？
ヘッダーをmain.hにほとんどまとめちゃってるスタイルなのよ？
（んで、cppにはmain.hのみをインクルードする。）
自分のも強制的にmain.hに加えないと文句が出るのよ。
「おまいのクラスが使えないぞごるぁ！」って。
ちょっとでもヘッダーファイルの内容書き換えたらリビルドじゃないの。

721 ：701：03/12/23 00:47 ID:l97wVPmD

>>704
伝わってますよ。
で、目的ですが、１つに、レイヤー分け。
システム管理とパラメータ（ゲーム仕様）の明示的な分離。
レイヤ分けする事で、保守がし易くなる。
後、一番重要なのが、調整、保守の責任を分散する事。

書いて動いて終わりじゃないのよ。
本人じゃなきゃ再調整出来ないて事は、その責任をずっと持つて事。
その「手間」に比べたら、はやいなんてなんのメリットにもならない。

722 ：名前は開発中のものです。：03/12/23 01:59 ID:E3QeV1IX

>>721
レイヤわけぐらいなら普通にＣ＋＋でもできますって。
理由にならないですよね。
調整や保守にしてもわざわざスクリプトでやる意味っておそらく薄いですよ。

まあ、でもどうせやるなら
この辺はMayaのMELなんかがおもしろいですよ。
普通のツールが
球の作成ボタンを押す->球を作成する->データができる
のに対して
Mayaは
球の作成ボタンを押す->球を作成するMELスクリプトを記述->書かれたスクリプトを実行->球を作成する->データができる
というようになっているようです。
もちろんMELを直接記述することもできます。
保存したファイルを開けてみるとユーザーがやった操作がびっしり記述されています。
つまりファイルフォーマットがMELスクリプトなんです。藁
すごいですねスクリプトもここまでくると極めに入りますね。
ただ１つ突っ込みどころがあるとすれば
「デザイナって誰もMELなんか使ってねーじゃん」
って部分でしょうか。
ま、たしかに、できればプログラム組みたくないですよねぇ。バグでるし。

723 ：名前は開発中のものです。：03/12/23 03:04 ID:MwsY7NVH

>>722
> 保存したファイルを開けてみるとユーザーがやった操作がびっしり記述されています。
ああ、Mayaってそういう構造してるのか。目から鱗だ。真似しよう。

データドリブン推進肯定派は「ハードコーディングしない、が理想」、と言っているだけで、
それが達成できなきゃダメ、とも言ってないし「データは全てスクリプトから」とも言っていない。
たとえばモデルデータの中身が実はスクリプト、なんてやり方が良いとは思っていない。
あと、722氏は「はやい」は実行速度ではなく手間がかからないの意味、と言って
「だから何でもスクリプトはダメ」と主張しているようだが、解せない話だ。
スクリプトのほうが手間がかからない、という実感があるのだが。
それは722氏が経験したスクリプト環境に問題があるのでは？
> レイヤわけぐらいなら普通にＣ＋＋でもできますって。
もちろんそうだけど、C/C++の言語機能は柔軟性に欠ける(実行時に新たな型を
生成できない）。スクリプトに頼らずデータだけでゲーム内容をドラスティックに
変更できるような機能をC/C++だけで実現しようと思ったら、スクリプトをバインド
するのに比べて何十倍もの手間がかかると思う。
おそらく722氏は「実行時に型の生成必要なし。型はハードコーディングで十分」と
考えているのかもしれないが、そうなると再び企画者はプログラマにお伺いを
立てなければゲームに本質的な影響も何も与えられない立場に逆戻りする。
それは一方で企画者に歯がゆい思いをさせ、一方で無茶な仕様を平然と
プログラマに押し付ける体質を助長することになる。

724 ：名前は開発中のものです。：03/12/23 03:05 ID:d2TpYCio

そういや、FFオンラインも殆どの操作がコマンド化されてるよね。
つーか、まずコマンドありき。で、GUIはそのコマンドを発行するだけってデザイン。
あのゲームデザインはいいなぁと思ったよ。追加が楽そう。

ｓ、スレとあんま関係なかったね。ｽﾏｿ。

725 ：続き：03/12/23 03:09 ID:MwsY7NVH

それに、こんな環境を明日始まるプロジェクトに適用して作り上げよう、とは言っていない。
いくつか実際のプロジェクトを仕上げながら、ちょっとづつ何年もかけて作り上げれば可能、ということ。
「企画者にスクリプトが書けるわけがない｣という主張も、ちょうど吉里吉里とKAGの関係のように
スクリプト上に簡易版インターフェースをこしらえてオーサリングはそれで、プログラミングは低レベル機能で、
とやればいい。
企画者→（指揮）→企画志望スクリプター→スクリプトでオーサリング
プログラマ→（指揮）→プログラマ志望スクリプター→スクリプトでプログラム
前回のプロジェクトはこんな構成だったけど、上手くいった。企画者は直接スクリプトがかけなくてもいい。
プログラマ志望スクリプター君全員に開発環境を用意するのは、とてもじゃないが出来ないけど、
スクリプティングならデバステとテキストエディタがあれば良い。

あと、縦読みでも斜め読みでもない（長文スマン）

726 ：名前は開発中のものです。：03/12/23 09:30 ID:n5YDokU7

だけど、スクリプト完全に仕上げてしまうと
悪意ある奴が社員にいたりすると裏で流したりはたまたそれで金を稼いだり
する奴がでてくるから完璧に仕上げず、必ず穴を作らざるをえないＰＧの
立場も分かっておくれよん

727 ：名前は開発中のものです。：03/12/23 09:51 ID:G68DNUQS

>>724
海外のFPSなんはかコンソールがついててそこでコマンドが入力できるように
なてるね。その辺→EverQuest→FF11ときてるのかな？
それとも元はIRCあたり？MUDかな？？

728 ：名前は開発中のものです。：03/12/23 14:56 ID:E3QeV1IX

>>725
いやもうそこまでくると
「一体どんな人数で作っとるっちゅーねん（ＦＦ？ＦＦ越える人数なのか？）」
っていう突っ込みを入れずにはいられない。

729 ：名前は開発中のものです。：03/12/23 20:02 ID:8yEP9euK

RPG だと、ちょっとしたプロジェクトでも軽く数十人規模になるぞ。

730 ：名前は開発中のものです。：03/12/23 22:30 ID:E3QeV1IX

>>729
ＰＧだけで？

731 ：名前は開発中のものです。：03/12/24 07:30 ID:AfYGS6+9

>>730
知ったかしかいねぇよここ

732 ：名前は開発中のものです。：03/12/24 10:49 ID:MQdqvAgE

>>730　は>>725をよく読め。
数十人ってデザイナとスクリプタは人海戦術でいいけど、PGのわきゃない。
いても4、5人でそ。

>>725のいう
＞スクリプト上に簡易版インターフェースをこしらえてオーサリングはそれで、プログラミングは低レベル機能で、
＞とやればいい。
＞企画者→（指揮）→企画志望スクリプター→スクリプトでオーサリング
はそういうことかと。

あ、そういやしぇ○むーはPGだけでも数十人規模だったらしいな。
当時派遣会社から「しぇん○ーやらない？」とかやたら声かかってたけど、
（このスレにもいそうだなｗ）結局関わってないので知らん。

733 ：名前は開発中のものです。：03/12/24 11:36 ID:AfYGS6+9

>>732
読んでも書いてねーよ
夢見るな

734 ：名前は開発中のものです。：03/12/24 23:26 ID:jri1zH28

Windows2K + DirectX9 + VCでゲーム作っている者です。
画面表示をObserverパターンで設計しようと思ったのですが、Subjectで
保持しているリスト要素の１つが消滅した場合どのように通知を受け取れば
いいのでしょうか。
（今はフラグで要素から消去するようにしようとしています。）
何か定石があれば教えてください。

735 ：723：03/12/25 01:20 ID:92zH4VkA

>>733
いや、>>732が言ってくれたとおりの意図ですよ。「スクリプタ全員に開発環境を用意できない」
って部分で文意を汲んでくれい。
前のプロジェクトはPG6名、スクリプター8名、企画3名、グラフィッカー10名って感じだった。
シンプルシリーズやギャルゲでもパズルでもないPS2タイトルだと、大抵このくらいまで膨れる
もんじゃないだろうか。

>>734
Subject側はshared_ptrでリソースを保持して、Observerにはそのweak_ptrを渡しては？
明示的に通知しなくてもweak_ptrをlockしてヌルポインタが返ってきたら、そのリソースは
消失したと判断できます。

736 ：名前は開発中のものです。：03/12/25 03:06 ID:U/ssXniS

>>734
observerにはsubjectのリストを検索する能力と、検索するためのidだけを与えておいて
実際の参照が必要な都度検索をするようにする

…ような形が頻出している漏れのプログラム。

737 ：名前は開発中のものです。：03/12/25 22:56 ID:ijIN5l/h

いままでノードとかメッシュってなんの疑いも無く
ツリー構造で持ってたんですけど、もしかして効率悪いんですかね？

738 ：名前は開発中のものです。：03/12/25 23:41 ID:qXSOwz4x

>>734
俺は

1. Subjetct は全て侵入型参照カウントで寿命管理する
2. Subject に「もう Observer から外して良いか」を返すメソッド、たとえば
　 virtual bool needToDelete()_ = 0;
　を追加
3. Observer は適当なタイミングで各 Subject の needToDelete() を呼んで、
　真を返してきたものをリストから外し、参照カウントを減らす。

としてる。

オブジェクトをデストラクトするタイミングが確定しづらくなるが、そういうもんだと
思って最初から設計しておけばわりと困らない。

>>732
俺のところは、ライブラリや Windows 系の plugin 書いてる人間は別として、
プロジェクト専属のプログラマが最終的に 7, 8 人ぐらいになりそう。多すぎ。

あと、昨今のコードだけで数 MB に達するプログラムだと、リンク時間が
バカにならない。リンクやリブート処理なしで、スクリプト読み直して試行錯誤
できる形にしておかないと、効率悪くてかなわんよ。

739 ：名前は開発中のものです。：03/12/26 00:10 ID:Ez56WOrj

ブート処理も無しにしてしまうのか！

740 ：738じゃないけど：03/12/26 02:05 ID:snUldEMq

>>739
もちろんもちろん

「気持ちの良い敵出現パターン」なんてのを調整してる時に、いちいちリブートして
調整中のステージにデバッグメニューから飛んで、なんてやってられない

741 ：名前は開発中のものです。：03/12/26 08:09 ID:tpdIeZRo

>>723
>ああ、Mayaってそういう構造してるのか。目から鱗だ。真似しよう。
つーかLuaはまさにその目的で作られた言語なんだが。

742 ：名前は開発中のものです。：03/12/26 11:29 ID:X+68PA/A

>>741　ほほー。Luaって説明見るとアプリケーションに組み込めるって書いてあるんだけど
たとえばPS2とかのコンシューマ環境でも可能なものなの？
スクリプトエンジンとしてターゲットを選ばず使えるんなら調査する価値があるんだが。

743 ：名前は開発中のものです。：03/12/26 11:33 ID:X+68PA/A

途中で送信しちまった
>>740
＞「気持ちの良い敵出現パターン」なんてのを調整してる時に、いちいちリブートして
＞調整中のステージにデバッグメニューから飛んで、なんてやってられない
これって敵パラメータ用のスクリプトとかシステムパラメータ用のスクリプト
見たいな感じで小分けで管理してるっとことだよね。でないとリブートが必要にならない？
それともスクリプト中の特定個所だけ読み込んでパラメータ適用、みたいにやってるの？

744 ：名前は開発中のものです。：03/12/26 12:09 ID:B/w5pXmm

Luaについてはム板にスレがあるにょ。

プログラミング言語 Lua 　その２
http://pc2.2ch.net/test/read.cgi/tech/1063711237/

745 ：名前は開発中のものです。：03/12/26 12:39 ID:I1g+4pH6

>>742
PS2は知らんけどgccが動くところならコンパイルできるんじゃないの？
一応クロスプラットーフォームってことになってる。

まぁとりあえず使って味噌。自分でスクリプト言語作るのがアホくさくなるくらいの完
成度はある。つーかTable萌え。
自分で作るにしても、こういうの叩き台にしたほうがいいんじゃないかなぁ。

ただ、Luaの生API叩くと、Javaのバイトコードアセンブラ書いてるような気分になって
きて鬱なので、一通り試したら、Luaのオフィシャルから辿れるライブラリ使うのが賢
明かも。

746 ：名前は開発中のものです。：03/12/26 13:06 ID:Gwc9nvik

> Lua
Tableの汎用さ加減は、いいね。
シンプルでいて強力。

仮想スタックマシン用の命令をアセンブラのように弄るのに疲れてたけど、
そっか、ライブラリあるんか・・・。

747 ：名前は開発中のものです。：03/12/26 13:40 ID:Ez56WOrj

Luaスレでも指摘されているけど、
・メモリ管理がどうなっているか不透明
・オブジェクトが増えれば増えるほど遅くなるGC
とか欠点もある。
後者は使い方しだいでどうにでもなるけど、コンシューマで使うとなると、
前者が…とかいう話だった。

Pythonは参照カウンタ(＋ループ参照検知)なので、こっちの方がゲーム向け
としてはいいのかな？たしか、PS2ゲームで採用された実績があったはず。

748 ：名前は開発中のものです。：03/12/26 14:02 ID:I1g+4pH6

やっぱコンシューマ屋さんは視点が違うのね。
洩れはPCにﾈｯﾄﾘﾍﾞｯﾄﾘ依存してるから、メモリなんて少々無駄使いしてもいいやー
みたいな考えがあるなぁ。

>Pythonは参照カウンタ(＋ループ参照検知)なので、こっちの方がゲーム向け
>としてはいいのかな？たしか、PS2ゲームで採用された実績があったはず。
ほーそれは初耳だ。ソースｷﾎﾞﾝﾇ。当然調味料以外で。

749 ：名前は開発中のものです。：03/12/26 16:11 ID:nVNXb8wq

>>742
CWだけど、PS2に移植できたよ、Lua。
Lua標準ライブラリにいくつかそのままじゃコンパイルやリンク通らないのがあって、
その機能を削除したりSCEのライブラリの関数に置き換えてやる必要があったけど。

750 ：名前は開発中のものです。：03/12/26 16:53 ID:Ez56WOrj

>>748
>ほーそれは初耳だ。ソースｷﾎﾞﾝﾇ。当然調味料以外で。
実績の方だよね？

http://www.cygnus-software.com/papers/gamescriptinginpython.html
のFrequency (PS2) これ。SCEAのやつらしい。

PlayStation.com - Games - Frequency?
http://www.scea.com/games/categories/stratpuzzle/frequency/

751 ：名前は開発中のものです。：03/12/26 17:43 ID:4SOAHJfh

>>750
へーGDCで発表されてたんだ…情報㌧クス

752 ：名前は開発中のものです。：03/12/28 15:51 ID:t5qbkYYi

おまえら次元の低い会話してんな。

Lua？Python？なんだよ、それ？
なんの制御するか知らんが、そんなもの、素直にC++で書けよ。
高級言語としての機能には大した差、ないだろ？

ヘッダファイルの#includeに気をつけろ？下手するとビルド時間増大？

どうせ、あれだろ？一枚岩の巨大実行ファイルをリンクしようと
してんだろ？それも10MBを超えるような、バカデカ・実行バイナリ。

あのな、OOの前に、「モジュール分割」ってソフトウェア工学の基礎
知ってるか？なぜ、MSが、OLEだのActiveXだの昔から手を変え品を変え
名を変えて、苦労してるか知ってるか？素直に動的リンカ使え。

スクリプトの出番もなくなる。

753 ：名前は開発中のものです。：03/12/28 16:50 ID:GLEmSz+p

>>752
先生のサンプルコード見せて下さい！

754 ：名前は開発中のものです。：03/12/28 16:54 ID:YNb2QVhn

C++のモジュール分割と
コンポーネントサービスは違うものだが

755 ：名前は開発中のものです。：03/12/28 17:27 ID:t6PLQRMS

えーと、えーと

ばーかばーか

や～いばーかばーか

756 ：名前は開発中のものです。：03/12/28 19:02 ID:GLEmSz+p

DLLならぼくも使ってます！
ゲーム制作エディタで画像を扱う部分、音楽を扱う部分などです！
こうして分けておくと大きくなってきたときでも対応しやすいですね！

[　　　ゲーム制作エディタ　　　　　]
　|　　　　　　　　　　　|
画像を扱うDLL　　音楽を扱うDLL

757 ：752：03/12/28 21:24 ID:t5qbkYYi

>C++のモジュール分割と
>コンポーネントサービスは違うものだが
指摘のとおり、戦術的には違うものだが、戦略的には同じもの。

なんでもかんでも単一のelf(or exe)に収めてしまえってのは、
どう考えても古代的な発想だろ？
単一の機能ごとに絞った各単機能コンポーネント群を用意し、
必要に応じて、LoadとUnload。
個々のコンポーネントの合計サイズは膨れ上がる傾向があるが、
この方がターゲット機でのメモリ効率は確実に改善されるのだ。

リードプログラマが大域的な戦略を誤ると、そのプロジェクトは
終盤でデスマーチに陥る。

758 ：名前は開発中のものです。：03/12/28 21:34 ID:CKqna0Y9

>>752
>なぜ、MSが、OLEだのActiveXだの昔から手を変え品を変え
>名を変えて、苦労してるか知ってるか？

単に「儲る為」ですが、何か？

759 ：名前は開発中のものです。：03/12/28 21:37 ID:CKqna0Y9

>>757 を読むと、まるで >>752 がマジレスで
あるかのように思えてくるのは実に面白いね。

760 ：名前は開発中のものです。：03/12/28 23:54 ID:THXtMYvG

>>748
今のハードは過渡期なんだよ、足りそうで足りない。
イケイケゴーゴーすると即死、使わなければ非効率ってね。

761 ：名前は開発中のものです。：03/12/29 00:10 ID:Qmt/+wHb

>>759
誰も話していないことを、あたかも反論であるかのように書くのは一種の才能かもね。

762 ：名前は開発中のものです。：03/12/29 02:50 ID:j/VTExgv

>>752&>>757
最初に馬鹿にしか見えない発言をしておいて、次に普通の話をすることが
これほどまでに効果的だとは知りませんでした。
勉強になります。

763 ：名前は開発中のものです。：03/12/29 03:21 ID:Qmt/+wHb

(都合いいように)話を誘導する時の常套手段だよ。

764 ：名前は開発中のものです。：03/12/29 16:22 ID:RTJQT/6M

>>757 はコンシューマの場合どう受け取ったら良いんだろうな。
オーバーレイを使いまくれ、ということなのか。
DCのときSN Systemsの環境でちょっと触って見て、
めんどくさすぎて嫌になった。それ以来鬼門。
スクリプトをロード・アンロードするほうが遙に手軽。
戦略的にはスクリプト派とおんなじことを言っているんだが、
あくまで実行バイナリの動的リンクにこだわる理由がわからん。

XBOXはDLL使えるんだっけ？

765 ：名前は開発中のものです。：03/12/30 00:00 ID:4HasNC+F

>>764
別にスクリプトじゃなくてもいいとは思うけどね。

766 ：名前は開発中のものです。：03/12/30 01:10 ID:L8Uqg9SL

>>764
> >>757 はコンシューマの場合どう受け取ったら良いんだろうな。
素直にスルーして良いと思われ。

だいたい、何でもかんでも C++ で書けってのも非現実的だって。
C++ は汎用言語だから気合入れれば何でもできるが、逆に定型的な
処理を書くには面倒が多すぎる。

そこはプログラマが CSV から作ったデータベースなり、処理内容に
特化した文法を備えたスクリプトなりを用意して、後は HTML 書け
ます程度の企画・スクリプタを大量投入してデータを大量生産。

システム内部まで把握したプログラマを 1 人用意するのと、定型
処理を大量生産するスクリプタ 1 人用意するのでは、かかる時間
も金も数倍は違ってくる。正直、プログラマを個々のデータ作成
仕事に回してる余裕はない。

767 ：名前は開発中のものです。：03/12/30 01:31 ID:4HasNC+F

>>766
僕プログラマですけどスクリプタと同じ給料ですよ！

768 ：名前は開発中のものです。：03/12/30 07:29 ID:cvv22gjd

まぁ実際にスクリプト言語を運用している人間からみたら、
C++があるからスクリプト言語が要らないってのは、
"機械語があるからC++いらないじゃん”って言ってるのと同じなんだよな。

スクリプト言語の利点は、記述の容易さと、メンテナンスの容易さ、トライ→エラー
のサイクルの短縮。
この利点が必要ない規模の開発じゃ、そりゃスクリプト言語はいらないさね。

>>752=>>755(?)は、少人数でシコシコ開発する分にはなにも問題はないけど、
規模が大きくなると泣きを見るよっと。

>>767
会社にとって、おまいさんの有用度がスクリプタと同程度ってことだろ。精進汁。
そうじゃないんなら会社かえれ。

769 ：名前は開発中のものです。：03/12/30 09:06 ID:4HasNC+F

>>768
>そうじゃないんなら会社かえれ。
了解！

770 ：名前は開発中のものです。：03/12/30 13:06 ID:L8Uqg9SL

>>757
> 指摘のとおり、戦術的には違うものだが、戦略的には同じもの。
戦略というか、目標もぜんぜん違うだろう。Microsoft の COM の主要な目標は

1. ソースコードではなく、バイナリの再利用
2. スケーラビリティ
　　プログラムをいじることなく分散処理などを可能に
3. 可用性
　　システムをとめずにダイナミックな更新を可能に

の 3 点。ハードウェアが固定されている環境では 2 は無意味だし、処理内容が
ゲームごとに特殊でコンポーネント流通市場がない環境では 1 も無意味。

3 に共通点がちょっと見られる程度だが、これも単なる DLL と COM だと、
サービス起動方式や名前検索などで要求される機能が大きく異なる。DLL
なら load, unload ですむが COM だと UUID ベースの重複しない ID 割り
当てやらモニカによる名前検索やら、かなり高機能なフレームワークが
必要。

Win32 使ってる分には Win32 API がよろしくやってくれるけど、自前で書くと
かなり大変だぞ。

771 ：名前は開発中のものです。：04/01/03 00:20 ID:YFxdCNxD

> DLLなら load, unload ですむが COM だと UUID ベースの重複しない
> ID 割り当てやらモニカによる名前検索やら、
> かなり高機能なフレームワークが必要。

Mozillaの人達はシコシコ作ってましたね！
合掌。

772 ：名前は開発中のものです。：04/01/03 11:56 ID:UZ7OEUkf

Mozillaの場合はブラウザというより
アプリケーションフレームワークの提供を目指してたっぽいし。
MSがCOMはWindows依存ではないと大口をたたきつづけながら
他への移植作業とか技術協力を一切しないから仕方なしに。

773 ：名前は開発中のものです。：04/01/03 12:12 ID:Tg/IXymq

MSが「Windows依存ではない」といった時は、多環境には移植しない。間違いない。

774 ：名前は開発中のものです。：04/01/06 00:13 ID:t8snih2K

車輪の再発明だからやめれって止めた人はたくさんいたのになあ＞Mozilla

775 ：名前は開発中のものです。：04/01/06 03:17 ID:GKhmJL5q

でもMozillaはWindows専用じゃないんだししゃーないんでは？

776 ：名前は開発中のものです。：04/01/06 07:18 ID:DJ0pCuU4

まーね

Redhatで使ったとき、Windows版とインターフェスが同じですぐ使えたのはよかったよ。
相変わらずフォントは来たなかったけど

777 ：名前は開発中のものです。：04/01/06 09:46 ID:MuiLM+vv

なんで、linuxのデスクトップで使われてるフォントって
あんなにきったないの？

778 ：名前は開発中のものです。：04/01/06 10:31 ID:GKhmJL5q

TrueTypeのビットマップを読んでないとかじゃないの、良くわかんないけど。
あと、標準のフォントが汚いという意味なら
フリーだから商用の（＝商品価値のある）フォントより品質が劣るのは
ある意味当然かと

779 ：名前は開発中のものです。：04/01/06 23:17 ID:HUeImtr2

Linuxって普段はシェルでしか使わないんだけど、
たまにGUI使うとWindowsと比べてむちゃくちゃ遅くていらいらする。

ﾔﾊﾟｰﾘMSの技術力というか、金の力って凄いんだなとしみじみ思うよｗ

780 ：名前は開発中のものです。：04/01/07 13:33 ID:uoWPrsQj

ソフトウェア工学とコンピュータゲーム
http://www.gogo3d.com/products/rudy/

こんな本出てたけどどない？誰か人柱よろ。

781 ：とむ ◆0MTMwDpCZo ：04/01/08 00:48 ID:p1nE8CaH

ルディ・ラッカーってこんな本書いてたのね…。
よろ。

782 ：名前は開発中のものです。：04/01/08 02:05 ID:Gium1yth

本の中でつかってるフレームワークのソース
ttp://www.rudyrucker.com/computergames/

783 ：名前は開発中のものです。：04/01/08 02:13 ID:ywMu1L2D

改訳だから仕方ないところもあるっしょ
本という形にも意味あるし。

しかし、初心者が読んでも分からんし \7,000 はちと無理あるっしょ

784 ：名前は開発中のものです。：04/01/09 18:25 ID:81gqAqxd

本屋回ったけどおいてなかった。
結局Amazonで狩っちまった

785 ：名前は開発中のものです。：04/01/09 19:33 ID:u3hDQyuD

リンク先見てないけど…7000円って骨の本？

786 ：名前は開発中のものです。：04/01/10 01:59 ID:MT7mfFdx

＞＞ソフトウェア工学とコンピュータゲーム
＞＞http://www.gogo3d.com/products/rudy/
たしか、やねうらお氏や、狩野氏が推薦してたような。。

787 ：名前は開発中のものです。：04/01/10 02:25 ID:KvHv5Qel

やねうら某

788 ：名前は開発中のものです。：04/01/10 02:38 ID:9eJXaItC

>>787
さすがにそのレスは気持ち悪すぎだろう

789 ：名前は開発中のものです。：04/01/10 04:09 ID:oQGJdAbL

えっ？
ルーディ・ラッカーって「あの」ルーディ・ラッカー？

ヘェヘェヘェヘェヘェヘェヘェヘェヘェヘェ

790 ：名前は開発中のものです。：04/01/10 11:31 ID:o/qraHww

誰なん？教えてちょんまげ。

791 ：名前は開発中のものです。：04/01/10 11:37 ID:vpEGsIB2

>>790
SF作家。「ウェットウェア」とか「ソフトウェア」とか。
今じゃすっかりALの人だな

792 ：名前は開発中のものです。：04/01/12 12:54 ID:osOacqjO

「ソフトウェア工学とコンピュータゲーム」今届いた。
でかい。CDROM付いてなくてハードカバーじゃないんだけど、
大体ＧＥＭＳといっしょ。

で、早速ぱらぱらっとみてみたけど、これようするに、
ルーディーラッカーが作ったPOPっていうフレームワークの
日本語マニュアル、かも。

物理シミュの本だと物理シミュだけだし、３Ｄグラフィックスの本だと
３Ｄグラフィックスだけで、それを使ってゲームを作る場合どうなるか、
みたいな事には触れないし、ＧＥＭＳは断片的な要素に触れるだけで
ゲームエンジンとして統合した場合どうなるか、みたいな事には
触れないわけだけど、この本はその間を埋めるもの、って感じ。

7000円はちょっと高いな、と思うけど、他人のエンジンに詳細な解説が
ついていると思えば、それなりの価値はあるかと。
アマチュアでもシンプルなシューティングは作ったことあるけど
次はもうちと規模のでかいゲームを造りたいと思ってる人には良いかも。

793 ：名前は開発中のものです。：04/01/12 14:12 ID:sPh/FG0m

>>792
中身も確かめずに高価な本買えるなんて羨ましいですな。
貧乏な俺にはこれは！！と思える本しか今は買えないね。

794 ：名前は開発中のものです。：04/01/12 14:17 ID:+EEkxeRC

なるほど、やねうらお氏や狩野氏が推薦するだけの本ではあるな。
惜しまずに買おう。

795 ：名前は開発中のものです。：04/01/12 14:28 ID:sPh/FG0m

そうか、「ソフトウェア工学とコンピュータゲーム」は俺にはまだ早いな。
とりあえず今作ってるゲームのプログラム完成させないと。

796 ：名前は開発中のものです。：04/01/12 14:31 ID:sPh/FG0m

786のリンク先に
　レベル：初級者、中級者
って書いてあるけど…中の上、上向きっぽい気もするんだが（笑

797 ：名前は開発中のものです。：04/01/12 17:15 ID:ZOUGXhI/

それだけ日本の（ｒｙ
ってことだろう、たぶん。

798 ：名前は開発中のものです。：04/01/12 23:53 ID:c+7H5rDr

ソフトウェア高額とコンピューターゲーム読んだけど
ちらほら自分にとっては納得のいかない設計してるところが…

まぁこれはこれでよい本である気はする。

799 ：名前は開発中のものです。：04/01/13 12:01 ID:ZV4Via/l

つか、まんま教科書だね、これは。＞ソフトウェア工学とコンピュータゲーム
ただし、ゲーム作りのための教科書、ではなく、あくまでゲーム作りを教材に
生徒に実践的なソフトウェアプロジェクトを体験させる、っていう主旨。

では、ゲーム作りが主目的という視点で見るとまったく無駄な本かというと
そうでもなくて、自分のエンジンの設計を見直す良い機会を与えてくれる。
POPでは何時でもどんな時でもゲーム内のオブジェクトなら何でも、
マウスでつまんで移動できて、ああ、この仕組みは自分のにも欲しいな、
と思ったし。

プログラミング自体の初心者には不向きだけど（実際この本の対象として
JavaかCがだいたい使えることを要求している）、ソフトウェア開発の、
という視点で見た場合、初級から中級、というレベル設定は妥当だと思う。
結構そんなんいらんわ、って項目も多いし（C++のクラスの書き方、とか、
MFCの使い方、とか）

書名から受けるイメージに反して、そんなに小難しいことは書いてないです。

800 ：名前は開発中のものです。：04/01/17 21:59 ID:57wT2R3z

ソフトウェア工学とコンピュータゲーム見てきた。
一部数学の知識必要とするところ（？）はよーわからんかったけど。
他は理解できそうだった。

買わなかったけどｗ

801 ：名前は開発中のものです。：04/01/22 10:45 ID:wo8e5Y4D

＃スレ違いは承知です、ここが一番濃い人達が集まってそうなので。

みなさんバージョン管理ってどうやってます？
最近話題のSubVersionがバイナリも正しく管理してくれるのでかなりよさげ。
ソース以外にもサウンドや画像も全部ひっくるめて
昔のバージョンに戻せたりするのでむちゃくちゃ便利。
あとは日本語＋GUIな環境が整備されればなぁ。

もう、CVSやVSSや手動バックアップな時代には戻れないっす。

＃ところで、テキストはExamDiff使ってるけどバイナリの差分ってどうやって見ればいいんだろ・・・

802 ：名前は開発中のものです。：04/01/22 13:52 ID:Z/gwtaal

＞＃スレ違いは承知です、ここが一番濃い人達が集まってそうなので。
凄まじく自分勝手な奴がいる。

803 ：名前は開発中のものです。：04/01/22 13:56 ID:zleiCkPC

>>801
経験上バージョン管理は「まるごとＣＤに焼いて日付書いておく」以外の方法は認めない。
容量がでかいときはUSBリムーバブルケースとHDDのタッグでHDDを切り替えて保存しておいて
ころあいをみてCDなりDVDなりに焼けばいい。
バージョン管理ツールは色々みてきたけど無駄に複雑なだけで全く意味がない。

804 ：名前は開発中のものです。：04/01/22 14:19 ID:DU+cCVWF

漏れも開発ディレクトリをまるごと保存する派ですね。
圧縮して日付を名前にして別のドライブにこまめに一時保管。
キリがいいところでCD-RW×3に焼いて保存。バージョン管理と
バックアップを兼ねてるといったところ…。

以前のソースを見たいときは圧縮ファイル開くだけでいいし
いまのところこのやり方で不満はないです…。

805 ：名前は開発中のものです。：04/01/22 16:58 ID:Pxj5iZvR

俺は両方かな。
バージョン管理ツールの方には、丸ごとバックアップより細かい粒度で行う。
変更メモも残して置けるし。

でも、バージョン管理ツール(特にCVS)は、複数人で使う場合、理解できてない
奴がいるとぐちゃぐちゃになるんだよね…。

806 ：名前は開発中のものです。：04/01/22 19:32 ID:cutdAgu4

丸ごとバックアップは変更履歴が残らないのでCVS。

807 ：名前は開発中のものです。：04/01/22 21:47 ID:IS3WpODp

「丸ごとバックアップ」という履歴が残るではないか！

808 ：名前は開発中のものです。：04/01/22 21:55 ID:zleiCkPC

つかファイル比較ツールで一発
ＣＶＳなんて使わない。

809 ：名前は開発中のものです。：04/01/22 22:04 ID:IS3WpODp

それは逆だって。
CVS使えば比較「も」一発。

810 ：名前は開発中のものです。：04/01/22 22:31 ID:zleiCkPC

>>809
たまたましか使わない機能使うために
ＣＶＳで管理し続けること自体がメンバーの苦痛になってしまう。
バージョン管理の機能が頻繁に必要になる場合って少ないでしょ。
だってファイル比較なんてそう頻繁にやるものなの？

811 ：名前は開発中のものです。：04/01/22 22:32 ID:zleiCkPC

×　たまたま
○　たまに

812 ：名前は開発中のものです。：04/01/22 22:38 ID:IS3WpODp

必要になるでしょ。
他人のソースは追わない人？

といかCVSで管理することって苦痛？(いや、VSSとかSubversionとかでも良いけど。)

813 ：名前は開発中のものです。：04/01/22 22:45 ID:zleiCkPC

>>812
>他人のソースは追わない人？
わざわざＣＶＳ使わないと追えない人？
俺は俺のやり方で追わせてもらうけど。

>管理することって苦痛？
俺じゃなくて他の人がね。
わけわかんないって。

814 ：名前は開発中のものです。：04/01/22 22:54 ID:g/kFbotf

まぁいらないと思ってて、特に困ってないんだったら別に使わなくてもいいんじゃないの？

815 ：名前は開発中のものです。：04/01/22 22:55 ID:RLcZRSbH

「あの時のにもどしてよ」って言葉が乱発されるようになってから、
いやおうなしにバージョン管理ソフトの導入を余儀なくされました。

816 ：名前は開発中のものです。：04/01/22 22:59 ID:Pxj5iZvR

＞わざわざＣＶＳ使わないと追えない人？
だから逆なんだって。

まぁ、CVSは確かに全機能使おうと思ったら結構複雑だけど、Eclipseから使って
みたり、VCならVSSなんかを使ってみると結構分かりやすいらしいですよ？

817 ：とむ ◆0MTMwDpCZo ：04/01/23 00:58 ID:86hZBPY7

CVSって、最初の導入はちょっとめんどいけど、その後は「管理」というほど大げさな
ものはしないと思うけどな。

なんかID:zleiCkPCさんの論調っておかしいな。例えば他人のソースを追う話だけど、
diffを使う話だよね。で、ID:zleiCkPCさんはdiff使えば一発とか言うけど、別にdiffと
CVSが二者択一になってるわけじゃなくて、普通の人はCVS+diffを使うわけで…。

そのへん、CVSの否定論としては弱いかな、と。
「同僚に嫌がってる人がいる」という程度の話だったら、このスレの人達に対して反発
するよりも、その同僚に反発した方がよろしいかと。

かくいう私は、CVS自体はリビジョンコントロールという役目としてはあまり使っていなくて、
バックアップ自体はローカル環境に必要な分だけコピーしてますね…。
ぎゃふん。

818 ：名前は開発中のものです。：04/01/23 01:13 ID:oMMJRyMP

>>817
別にファイル比較なんてやっても一ヶ月にいっぺんやるかやらないかでしょ？
頻繁にファイル比較なんてする必要があるならそりゃ管理の仕方が悪すぎる。
ＣＶＳを使う前に考えるべきことがある。
この問題は個人的にはどうでもいい。のでこれを話題にしたくはない。

バージョン管理なんてフォルダを１つコピーするだけで済むのになぜわざわざ
とくに恩恵も得られないＣＶＳなんて使いたがるのかわからない。

私がＣＶＳが嫌いなのはその操作と概念が直感的でないから、
普段使っているWindowsのファイル操作のそれとあきらかに違うし、
なによりコマンドとその実行結果がわかりずらいことが嫌なところですかね。

819 ：とむ ◆0MTMwDpCZo ：04/01/23 01:21 ID:86hZBPY7

>>818
>別にファイル比較なんてやっても一ヶ月にいっぺんやるかやらないかでしょ？

確かにそうたくさんはやりませんが、今話してるのは量の問題じゃないでしょ？
diff使えば一発という人がいたので、CVSでも一発という話になっただけで。

>バージョン管理なんてフォルダを１つコピーするだけで済むのになぜわざわざ
>とくに恩恵も得られないＣＶＳなんて使いたがるのかわからない。

複数人数で一つのプロジェクトを作る時に、衝突を解決する目的が一番だと思い
ます。それが最大の恩恵です。バージョン管理はその次の恩恵です。

820 ：名前は開発中のものです。：04/01/23 01:27 ID:oMMJRyMP

>>819
>複数人数で一つのプロジェクトを作る時に、衝突を解決する目的が一番だと思い
>ます。それが最大の恩恵です。バージョン管理はその次の恩恵です。
？衝突？どうして？
ソースファイルをわけない会社なんですか？
複数人数で何を共有してらっしゃるのですか？

821 ：とむ ◆0MTMwDpCZo ：04/01/23 01:36 ID:86hZBPY7

えっ…ていうか、あなたの会社はどういう管理をしているのですか？

まず直接ファイルが衝突するものとしては、メイクファイルです。あるいはその他設定
関係のファイルは全て衝突の可能性があります。
その他のファイルは、プログラマが異なれば直接衝突の危険はほぼありませんが、
しかし他人のファイルの依存関係に何かを挟んだりというくらいの事はします。

それ以上に大切なのが、「今最新のプロジェクト」を常に全員が動かせるというのが
メリットです。CVSのような管理ソフトを使わないとして、あなたの会社のプロジェクトは、
今最新のファイルとかをどうしているのですか？
「たった今、foo.cppというクラスを全員にメールしましたので、それを入れてコンパイル
してください」
とかいうメールが飛び交ってるとか？

822 ：名前は開発中のものです。：04/01/23 01:52 ID:HdDlN+Yo

＞「たった今、foo.cppというクラスを全員にメールしましたので、それを入れてコンパイルしてください」
＞とかいうメールが飛び交ってるとか？
CVS使ったとして、↑がなくなるわけでもないけどね。
ただ、ある程度は助けになってくれる。

>>バージョン管理なんてフォルダを１つコピーするだけで済むのになぜわざわざ
コレも逆なんだなぁ…。
なぜCVSで出来ることを「手動で」やってるのか？とか。

823 ：名前は開発中のものです。：04/01/23 02:04 ID:oMMJRyMP

>>819,821
>複数人数で一つのプロジェクトを作る時に、衝突を解決する目的が一番だと思い
>ます。それが最大の恩恵です。
>それ以上に大切なのが、「今最新のプロジェクト」を常に全員が動かせるというのが
>メリットです。
どっちが大事なんですか。

まあ、それはおいておいて・・・。

>CVSのような管理ソフトを使わないとして、あなたの会社のプロジェクトは、
>今最新のファイルとかをどうしているのですか？
日の初めに部署ごとのフォルダをコピーして終了。
インターフェースの変更（なかなかないですけど）は連絡掲示板およびマニュアルを参照。

>>822
>なぜCVSで出来ることを「手動で」やってるのか？とか。
単にフォルダのコピーですよ？ドラッグアンドドロップで一発ですよ。

824 ：名前は開発中のものです。：04/01/23 02:16 ID:IXE3U9bH

いや、自分でソース書く場合にも有効ですよ。
何かのテストである部分だけちょこっと修正したいけど、
ほかの人も使ってるので元のソースは変えたくない。
なんてときにいったんコミットしておいてからいじり、終わったら戻す。
というようなことも簡単ですし、
「やべぇ、修正したら動かなくなった。色々追加したからどれが原因かわからないYO!」
なんてときも、動いてたバージョンのソースとDiffすれば追跡もしやすいです。

単なるバックアップじゃ受けられないほどの恩恵があると思うんですが・・・
CVSでもVSSでもいいからまずは使ってみればどうでしょう。
CVSならWindows用クライアントも色々ありますし、まずはローカルにリポジトリ作って
自分専用でいじくるだけでも便利ですよ。

825 ：名前は開発中のものです。：04/01/23 02:16 ID:WNkQbem5

うちは１つのファイルを複数人が編集する可能性があるのでCVSがないと破綻する

826 ：名前は開発中のものです。：04/01/23 02:23 ID:HdDlN+Yo

あと手動でやるときは「ミス」が怖いね。
まぁ、工夫すればある程度提言できるだろうけど。

827 ：名前は開発中のものです。：04/01/23 02:42 ID:jAzTdmy4

CVSはディレクトリやファイル名の変更が簡単にできないとか
欠点はあるわけだし。複数で作業するときは良い選択肢の一つとは
思うけど、何事もマンセーしすぎはどうかと思うよ。
必要に応じたツールを使えば良い。

828 ：とむ ◆0MTMwDpCZo ：04/01/23 02:58 ID:86hZBPY7

というかね。今「CVS派」と「手動派」にわかれてるみたいなかっこになってるけど、
いわゆる私も含めたCVS派の人達は、手動派の手法も含んでるんですよね。否定
しているというか、内包している。

例えば、データの一部なんかはCVSを通さず、「手動派」と同じようにサーバにコピー
という手法を使いますし、それにフォルダ丸ごとバックアップという手段も使います。
その上で、ソースコードのような衝突の危険があり、そしてバージョン管理してほしい
ものについては、CVSを使います。Diffのところでも話したけど、要するに全部の手法を
使うんだよね。

で、確かにCVSに似た事は、手動でもできるんだけど、なんでわざわざ手でやるの、と。
「コンパイラなんかいらねーよ！　ハンドアセンブルで直接１６進数打ち込めよ」って人が
いたら、「ハァ？」って思うでしょ。そんな感じ。

829 ：名前は開発中のものです。：04/01/23 02:59 ID:IXE3U9bH

>>827　そんなあなたにSubVersion。
CVSの欠点を克服するために開発されたシステムです。

ディレクトリの変更もきちんと履歴とってくれるし、
バイナリも差分で保管するのでいい感じです。

まだベータなのとGUIクライアントが少ないので様子見ですが。

830 ：とむ ◆0MTMwDpCZo ：04/01/23 03:04 ID:86hZBPY7

そう、私も使った事ないけど、検索して調べて面白そうだなと思いました＞さぶVersion
バイナリも差分で保管するというのが結構あれだね。
バイナリのマージもしてくれるのかな？　それは無理かな？
されても困るかな？（笑）

831 ：とむ ◆0MTMwDpCZo ：04/01/23 03:13 ID:86hZBPY7

ああ、読み返すと>>828だけじゃ何が言いたいか伝わらないな。

要するに、適材適所で使えばいいでしょ、と。
手動で済むところであれば手動でやればいい。
時々こういうツール話であるのが、「ツールで半自動化するより、手動の方が手間はかかっても
きめこまかい制御ができるし、慣れててミスも少ないから、俺は手動でやってる」とかいう
人が出てくるよね。そういうのなら分かるのよ。
しかしこの場合、CVSの方が明らかの手間がかからず、きめ細かく、そしてミスの少ない
作業をしてくれるわけじゃん。「一日一回サーバからフォルダコピー、時々ＣＤに丸ごと焼く」
という処理よりも、手間・きめ細かさ・確実性に勝っている。

「手動でバージョン管理する方がこんな有利なことがあるんだ！」と主張しない限り、なんか
実のある議論にはならないと思うよ。「俺は嫌だ」くらいしか論拠がないじゃん…。

832 ：名前は開発中のものです。：04/01/23 07:21 ID:jAzTdmy4

>CVSの方が明らかの手間がかからず

最近のCVSはエクスプローラ並に手間がかからないの？
複数のフォルダを開いてファイルを移動して名前を変えてって
作業を数秒で行うんだけど、この作業がエクスプローラ並に
手間がかからなくて自動追跡してレポジトリ更新してくれる
なら導入してみたいかな。
cvsはコマンドをちんたら打つって段階で、ああもうパスって
感じだったから。w

833 ：名前は開発中のものです。：04/01/23 07:27 ID:FWJMP3Ls

>>832
亀CVS(SubVersion)使え

834 ：名前は開発中のものです。：04/01/23 07:36 ID:jAzTdmy4

>>833
ども。βがとれたら使ってみます。

835 ：名前は開発中のものです。：04/01/23 09:06 ID:HdDlN+Yo

>>827
いや、CVSに限定してないし、そもそも「覚えるのにコストがかかる」「手動でも出来る」
では、バージョン管理を否定する根拠としてはうすいなぁと言ってるだけだよ。
(導入したときのメリットとか手動での罠とくらべると、ね。)
CVSにもいろいろ欠点はあるわけで、だからCVSではやりたくないってなら、問題ない。

まぁ、議論してると全面肯定、全面否定に見えちゃうってのはBBSでの罠かもね！

836 ：名前は開発中のものです。：04/01/23 10:36 ID:cbL60K2M

藻前らスレ違いもたいがいにしろよ、と。

837 ：名前は開発中のものです。：04/01/23 11:39 ID:Wh5c4mCr

いつものことだよ。
周りの事なんか何も考えちゃいないんだね。きっと成人式のDQNと同じ人種だよ。
終いにゃ、だったらおまえがOOのネタ振れよとか言い出す始末。
荒らし風情が何を偉そうに、って感じですよね。
ネタがないなら何も書き込まなくていいのに、無理してCVSだの何だのってもうねｒｙ

838 ：とむ ◆0MTMwDpCZo ：04/01/23 12:48 ID:86hZBPY7

>>832
WinCVSなどのGUI環境でどうぞ。
導入時には少し手間がかかりますが、それ以外の手間はエクスプローラとかわらない
でしょう。

839 ：とむ ◆0MTMwDpCZo ：04/01/23 12:50 ID:86hZBPY7

ああ、「エクスプローラと変わらない」と書いたらまたつっこまれるか（笑）。
作業の容易さはエクスプローラと変わらず、全体的な手間で言えば「フォルダまるごと
コピー」「ＣＤに焼いてバックアップ」よりはるかに楽になります。

840 ：名前は開発中のものです。：04/01/23 13:52 ID:oMMJRyMP

>>839
発言はよく考えてしてください。
あなたの発言はとてもプログラマとは思えないぐらい矛盾に満ちていて全く信用できません。

841 ：名前は開発中のものです。：04/01/23 16:09 ID:CDrIG5aE

これはもう放置するどころのレベルじゃないな

　完　全　な　ス　レ　の　っ　と　り　だ

これ以上言ってもわからないなら通報します

842 ：名前は開発中のものです。：04/01/23 16:26 ID:TAX0e6Ic

( ´_ゝ`)

843 ：名前は開発中のものです。：04/01/23 19:32 ID:YbP/nYSm

まあ、とりあえずム板のスレを示しとくとして。

CVS導入スレ～ Rev.2
http://pc2.2ch.net/test/read.cgi/tech/1065829553/

CVSはEclipseからだと（機能は限定されるものの）革命的に楽に使えるんだけど、
WinCVSなんかｲﾗﾈ（ﾟ⊿ﾟ）コマンドラインのほうがマシなくらい。
誰かすげーフロントエンド作ってくれないかなあ。

844 ：名前は開発中のものです。：04/01/24 23:54 ID:w4RX1tGl

>>843
いい加減にしろ

845 ：名前は開発中のものです。：04/01/25 00:35 ID:fsm/Rrqt

自　分　で　ネ　タ　を　振　れ　。

846 ：名前は開発中のものです。：04/01/25 22:06 ID:F2qzoE13

そうだそうだ。

つーか、スレの守備範囲もっと広げてもいい気がするんだけどな。
「ソフトウェア工学とゲームプログラミング」くらい。
OOに限定したところでどうせ脱線するんだから。

847 ：名前は開発中のものです。：04/01/26 00:52 ID:hCNReS1Y

次スレはそういうタイトルにしてはいかがかね？

848 ：名前は開発中のものです。：04/01/26 02:58 ID:P2TCBGvb

そりゃいい案だ。
でもそのままだとあの本のスレと間違われるかもしらないから
「ゲームプログラミングとソフトウェア工学」はどうだろ。

849 ：名前は開発中のものです。：04/01/26 03:10 ID:KcPzAm5y

いっそのこと、
「スレッドを立てるまでもないゲームプログラミング雑談スレ」
にしてはどうか（ﾌﾟｹﾞﾗ

850 ：名前は開発中のものです。：04/01/26 12:02 ID:c5Qyoe4w

とむの(r

851 ：名前は開発中のものです。：04/01/27 00:28 ID:eZhCq5ox

>>845-846
ネタがなかったらちょっとくらいスレ違いな雑談も許されるんですね
これはいい事を聞いた
今度>>843のスレでネタがなくなったらOOとゲームプログラミングの話題振ってみます
もうローカルルールなんて要りませんね

852 ：名前は開発中のものです。：04/01/27 00:43 ID:0X8Eh9eq

何コイツ？

853 ：名前は開発中のものです。：04/01/27 01:08 ID:+Rx1AGN/

>>852
何か言いたいことがあるならきちんと反論すれば？
それじゃただ周りの同意を求めてるだけだな
自分一人じゃ怖くて何も言えないんだろ
もっともスレ違いな話題を延々と繰り返す荒らしの戯言など聞きたくもないが

854 ：名前は開発中のものです。：04/01/27 01:13 ID:5lRQnJLR

お前がスレ違いだ。帰れ。

855 ：名前は開発中のものです。：04/01/27 01:26 ID:2QJKbL2A

CVSの話(スレ違いの話題)は続くようならスレ立てるか雑談スレへ。
→総合発表＆雑談スレッド
　 http://pc2.2ch.net/test/read.cgi/gamedev/1033812109/

一般的なスレ自治の話は自治スレへ。
→【総合】自治スレッド＠ゲーム製作技術板【統合】
　 http://pc2.2ch.net/test/read.cgi/gamedev/1043703176/

856 ：名前は開発中のものです。：04/01/27 01:29 ID:5lRQnJLR

わざわざ>>1に守備範囲広しって書いてあるんだから、ゲームプログラミングに
対する様々な話題があってもいいだろ。困る奴は何が困るんだ？

857 ：名前は開発中のものです。：04/01/27 01:30 ID:5lRQnJLR

というか、「このスレでOOの話ができなくて困ってる」とか言う奴いるの？

858 ：名前は開発中のものです。：04/01/27 01:52 ID:lW7grJ3A

いや、CVSはやはりスレ違いだし。。。
OOの話がでできるきないとかいう問題じゃないと思うが。。。

859 ：名前は開発中のものです。：04/01/27 02:24 ID:5lRQnJLR

確かにOOとは関係ねえけどさ。
所詮2chなんだし、そこまで固っくるしく考えることねーんじゃねーの？
真面目にOOだけを語りたい奴はそれなりのMLとかあるだろ。
しかも文句だけ言っててめえから絶対に話題は振らない卑怯な奴。

860 ：名前は開発中のものです。：04/01/27 04:22 ID:qGxENPxx

>859
ﾊｲﾊｰｲ、言いたいこと言ってすっきりしましたか～
よかったでちゅね～

861 ：名前は開発中のものです。：04/01/27 04:38 ID:aBpG3ru+

キモ…

862 ：名前は開発中のものです。：04/01/27 12:50 ID:tfJgpzEA

おまいら、

ゲーム制作の現場におけるバージョン管理ツールを導入の効用と
複数メンバーでの効果的なオブジェクト指向開発手法について

議論してはどうでつか？

・・・と無理やり話をOO方向に持っていってみる。

863 ：名前は開発中のものです。：04/01/27 13:05 ID:YvlkwXDp

>>5lRQnJLR
なんつー自己厨だ・・・このスレこんな奴ばっかりなのか？

>>856-857
困る困らないじゃなくて、「ルール」ってもんがあるの。
困る人がいなければ公共の場で何したっていいのか？犯罪者の思考だな。
何のために「板」に「スレッド」があるのかよく考えろ馬鹿。

>>859
だからOO関係ないなら無理してレスしなくていいから。ていうかするな。
所詮2chだから・・・こういう奴に限って煽り荒らしに過剰反応したりする。某終了厨とかにな。所詮2chなんだからいいだろ？
話題振ってますが何か？それを毎度スレ違いな話題で押し潰してくれているのはどちら様で？

結論
>>854
お前がスレ違いだ。帰れ。つーか二度と来んな。

>>862
だから無理やり持っていかなくていいって。
常にスレにレスがないと怖いのか？
おまえらアレだろ、電話での沈黙が怖いタイプだろ？

864 ：名前は開発中のものです。：04/01/27 14:19 ID:i3J/7d0z

無理やりというより実際関係してくるだろＯＯとＣＶＳとか
オブジェクトのメソッド一度公開して、それが他の人が使ってて、
要望でいじくるときとかでてくるし、そんときＣＶＳ使う人もいるだろうし
ＯＯの１インターフェイスで済ませようとしてハナから作る人もいるだろうし

頭固すぎではないのか？

865 ：名前は開発中のものです。：04/01/27 15:32 ID:hIDh+Kni

なるほどー
gccのインストールの仕方とかコンパイルの仕方、
将来プログラマになる予定の子を作るために
セクースの仕方とかもありですか。
相当柔軟な頭脳をお持ちですね。

866 ：名前は開発中のものです。：04/01/27 17:59 ID:vkqmtR89

もうすぐこのスレも打ち止めだから
終了でいいんじゃない？

もっと間口の広い別スレ立てたほうがいいよ。

867 ：名前は開発中のものです。：04/01/27 18:18 ID:NQQcA0FO

>>863

868 ：名前は開発中のものです。：04/01/27 18:40 ID:i3J/7d0z

一方向的な物の見方しかできないとは不幸なことだな
レベルの差って残酷だな

869 ：名前は開発中のものです。：04/01/27 19:30 ID:Wo9aE4Ec

なんでそこでレベルの差が出て来るのか
コンプレックスでもあるのか？

いっそのこと「ゲーム製作関連技術スレッド」でも立ててそこでやってれば？
何でも好きな話ができるよ？

870 ：名前は開発中のものです。：04/01/27 20:07 ID:i3J/7d0z

では、ＯＯとＣＶＳが具体的にどういうふうにスレ違いなのか説明してくれ

>>864
で、ＯＯとＣＶＳは関連があると私は主張している
よってスレ違いではない

871 ：名前は開発中のものです。：04/01/27 20:09 ID:0RhsQYAd

関連があればいいというわけではないだろう。。。
なんでわからないんだろう。。。

872 ：名前は開発中のものです。：04/01/27 20:14 ID:i3J/7d0z

>単なるC++でのクラスの書き方から設計やパターンまで
これでもＣＶＳはスレ違いというのか？

具体的に説明してくれ話にならん。

873 ：名前は開発中のものです。：04/01/27 20:16 ID:hIDh+Kni

関連さえあればいいというのなら
この世に存在するあらゆる物体や現象にも
どこかで関連が存在するわけだから
カテゴリ分けそのものが無意味になるな

そもそもCVSの話題については
元質問者自身がスレ違いを認識している

874 ：名前は開発中のものです。：04/01/27 20:20 ID:hIDh+Kni

>>872
それは実装の手段で、CVSは運用の手段
関連が無いということもあるということも
理由のこじつけなら誰にでもできるだろうが
節度を持ってスレを利用しろってことだよ

ゲーム開発とグループウェア
http://pc2.2ch.net/test/read.cgi/gamedev/1034009197/
どちらかというと上のスレのほうが適切な話題だろうが。

ここを選んだ動機がOOに関連があるからではなく
人の質ってところからして図々しいんだ。

875 ：名前は開発中のものです。：04/01/27 20:31 ID:i3J/7d0z

スレ違いであることを説明しろと言っている。

節度とかいきなり出てきたが、はたして質問してから荒れているか？
途中で横槍が入ってから荒れ出したが、はたして節度を守るとは
誰にとっての節度であろうか？
節度を守ってないのは横槍を入れた者ではないか

876 ：名前は開発中のものです。：04/01/27 20:44 ID:hIDh+Kni

>OOをどのように用いれば美しいゲームプログラミングを
>行うことが出来るか語り合うスレです。

OOを用いて行うゲームプログラミングを語るスレだからだ
あくまでプログラミングの話であって管理の話ではない
それだけのことだ

874でも言ったが理由のこじつけなんていかようにもできる
だからスレ違いの説明なんてそれ自体何の意味も無い

>＃スレ違いは承知です、ここが一番濃い人達が集まってそうなので。
節度の話は元質問者自身が、自身の中での節度を犯しているという時点でお話にならない。

877 ：名前は開発中のものです。：04/01/27 20:57 ID:i3J/7d0z

ＯＯには多様性ということもあるように、
実践的なソースコードの管理も含まれている。
管理が関連してこないとはいえない。 >>864
その上プログラミングとはプログラムを行うということでいいのだろうか
ソースコードを管理せずしてどうやってプログラムを組むことができようか

スレ違いであることの説明の意味がないなら君の行っている行動自体も意味をなさない。

878 ：名前は開発中のものです。：04/01/27 21:41 ID:qK9OVpWQ

878

879 ：名前は開発中のものです。：04/01/27 22:07 ID:hIDh+Kni

>ソースコードを管理せずしてどうやってプログラムを組むことができようか

こういう論理の飛躍をする人間に反論の言葉を浴びせても
それはなしのつぶてだってのは理解できるだろ？
だから
>君の行っている行動自体も意味をなさない。

そういうこと、わかってんじゃん。
意味のあることしかやらない人間なんて存在しないだろ？

ってことでそろそろ次スレのタイトルとテンプレを考えようじゃないか。
このスレの中だけでOO限定によるいらぬトラブルがいくつかでているようだから
>>849で良いと思うがね。

まあ後50レスほど無駄に過ごしても良いとは思うが。

880 ：名前は開発中のものです。：04/01/27 22:39 ID:i3J/7d0z

何言ってんだ
>>846,848
しかねーだろ

坊主憎けりゃ袈裟まで憎い

というか、マジでＯＯとかソフトウェア工学とか意味分かってる？

881 ：名前は開発中のものです。：04/01/27 23:56 ID:EQzzCmcl

>>874
>ゲーム開発とグループウェア
>http://pc2.2ch.net/test/read.cgi/gamedev/1034009197/
↓ちなみにそのスレの状況なｗ　何の話をするんだか・・・

60 ：名前は開発中のものです。：03/05/31 05:32 ID:JwJB1iUi
現在、荒らしによってこの板の利用が困難になっているため、避難所を作成しています。
出来ればこちらに移動するのをお勧めします。
ゲ製作技術板(避難所)
http://bbs.gamdev.org/gamedev/
↓こんな感じにするのがお勧めです。
-----
9 名前：名無しさん＠ゲムデヴ[] 投稿日：2003/05/28 21:33
とりあえずOpenJaneに登録した
板一覧の上で右クリック→新規追加→板名とアドレス入れるだけ
61 ：あぼーん：あぼーん
あぼーん
62 ：あぼーん：あぼーん
あぼーん
63 ：あぼーん：あぼーん
あぼーん
64 ：あぼーん：あぼーん
あぼーん
65 ：あぼーん：あぼーん
あぼーん

882 ：名前は開発中のものです。：04/01/28 02:07 ID:J4LXWoCC

i3J/7d0zがなぜここまで必死になるのか分からん。
素直にスレ違いだったねって認められないのかねぇ。

883 ：名前は開発中のものです。：04/01/28 03:15 ID:9HBDaqO5

ここ一ヶ月ぐらいオブジェクト指向の話なんて全然してなかったんだから別にどうでもいいじゃん

884 ：名前は開発中のものです。：04/01/28 06:13 ID:wmuET8PO

だよな。
ＯＯの話で盛り上がってるところをスレ違いの話で潰してるならともかく、誰もそんな話を
してないところ閑古鳥スレで自治気取ってる奴が、いったい何考えてそんなことしてるのか
本気でわからん。何を守ってるんだ？

885 ：名前は開発中のものです。：04/01/28 06:14 ID:wmuET8PO

わけわからねえ日本語だな。閑古鳥の前のところとか適当に削ってくれ。

886 ：名前は開発中のものです。：04/01/28 08:30 ID:NHMF/MaT

議論(というか言い合い)してて、片方が劣勢になると何時も突然スレ違いの
指摘が出てくるような気がするな。前のメモリのときもそうだったような？

887 ：名前は開発中のものです。：04/01/28 09:16 ID:8pb99m2W

ということにしたいのですね:-)

888 ：名前は開発中のものです。：04/01/28 09:25 ID:o5oRYtcW

CVS話題が出た瞬間にスレ違いの指摘が出てるんだが、見たくない物は見ないのか。

889 ：i3J/7d0z：04/01/28 09:56 ID:pwaNY0Pz

別にいいだろ
ID変わってからまた否定しだしてるし
ついてこれないなら黙ってろよ
いちいち他人の足引っ張るな

890 ：名前は開発中のものです。：04/01/28 13:12 ID:wmuET8PO

もうほっといてやれよ。
こいつは自分の気にいらない話題に文句言いたいだけだろ。
自分でネタ振りは絶対しない。
何日間もスレほったらかしにしてるくせに、他の奴が何か話すとすぐ文句を言う。
そういう性格なんだろ。ほっとけほっとけ。

891 ：名前は開発中のものです。：04/01/28 15:33 ID:KC4j04LE

>>801-802

892 ：名前は開発中のものです。：04/01/28 17:41 ID:Ic2hyAOt

>>888,891
よーはスレ違いの話題が出た時点で
その話題にふさわしいスレのリンクを貼ってやればよかったかもね。

ループするが、
スレ廃れてるからスレ違いの話題でもイイじゃんというのは分からん。
そういうスレ立てるなり、そういうスレのリンク貼ってそっちでやればいいだけだと思うんだが（>>874のリンク先とか

893 ：名前は開発中のものです。：04/01/28 17:48 ID:Ic2hyAOt

900になったらタイトル変えたらどうかね？
「CVSとメモリとOOとゲームプログラミング」でもいいし、
「スレッドを立てるまでもないゲームプログラミング雑談スレ」でもいいし、
「ゲームプログラミングとソフトウェア工学」でもいいし。。。
その辺はスレ立てる人に任せるよ。

それなら異議はなくなるんじゃない？

894 ：名前は開発中のものです。：04/01/28 21:30 ID:gOU9NhII

別にどうでもいいよ('A`)
自分のフォルダを整理してるわけじゃなし
スレ違いの話題の一つや二つ適当にスルー汁

895 ：名前は開発中のものです。：04/01/28 23:45 ID:NHMF/MaT

どうも、全開のメモリのときから意固地になっている方が居るようです。

896 ：名前は開発中のものです。：04/01/29 00:16 ID:IkD1YAgt

>>894-895
同意。
2chなんてスレを肴にみんなでわいわいやるところなのに、こんな住人の少ないスレで
風紀委員やって話潰して、そいつは満足なのか？
とりあえず次スレは話題の幅を広げて語り合うことにして、例の粘着くんはそのスレには
絶対こないで下さい。お願いします。君が来ると単に場が白けるだけだし。

897 ：名前は開発中のものです。：04/01/29 00:44 ID:JhirhLNZ

まああれだ。つまり、

悪法に従って毒を飲む奴なんぞいないってこったな。

898 ：名前は開発中のものです。：04/01/29 01:12 ID:UFysFpeF

OO縛りはデメリットしかない毒であるというわけですね

899 ：名前は開発中のものです。：04/01/29 01:36 ID:B1Gm7thE

いっそのこと「ゲーム製作技術スレ」にしる！。。。って板とおんなじかw
どうせOO限定してもすぐにネタ切れになるし、俺的には興味のあるネタがでてくるんなら何でもいいや。
ま、タイトルにはPG召還の餌としてOOとか工学とかプロジェクト管理とかの文字が入ってた方がいいかも。

900 ：名前は開発中のものです。：04/01/29 06:16 ID:Cl1wOigi

今までの流れをまったく読んでなくて893-899くらいしか見てないのだが、
そういう流れになってるなら
「ゲームプログラミング技術スレ」でいいんじゃない？
でもこれじゃあ「C言語のポインタが…」みたいな人も来るよな。
うまくそのレベルを排除するスレタイを考えタイ。

901 ：名前は開発中のものです。：04/01/29 09:19 ID:+xaFqHQ1

どんなタイトルにしても、
＞＃スレ違いは承知です、ここが一番濃い人達が集まってそうなので。
Ｃ言語のポインタの話を始める奴は現れるであろう。

902 ：名前は開発中のものです。：04/01/29 10:04 ID:9HI+iNHu

＞Ｃ言語のポインタの話を始める奴は現れるであろう。
興味深い話題ならつきあえばええやん。
そうじゃないならスルー。

ていうか、何でそう極端な話をするかな…

903 ：名前は開発中のものです。：04/01/29 10:52 ID:DVVeiFcf

ポインタはおぶじぇくと指向と密接に関わってるからな。
じつに興味深い。

904 ：i3J/7d0z：04/01/29 12:15 ID:JfWR0Q8Z

自分で自分に反論

ＯＯとは知識であり、ＣＶＳは道具であり、これを同類と扱うのは誤りである。

実際にＯＯはソフトウェア工学の考え方のひとつであり、知識として蓄えられるものである。
が、ＣＶＳは道具であり、これはＯＯで作られたものではないもの
構造化分析で設計されたものを扱え、さらに画像データ、音楽データなども
管理することができる「道具」であり、
たまたまＯＯの考え方を用いて作られたソースコードを管理しているにすぎない。

つまり、ＣＶＳという道具を扱う技能と、ＯＯという知識を
ごっちゃにして考えるのは極めて危険なことである。

うはｗｗｗｗおけｗｗｗｗｗｗｗｗｗｗ
反ｗ論ｗでｗきｗねｗーｗよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

余談だがＯＯの本家Smalltalkの話をしてると必ずメモリモデルの話がでてくることもあるから
まぁ純粋にＯＯだけやりたかったらメーリングリストでも入ってろってこった
んでも、知識だけあっても道具をうまく使いこなせないと効果がないってこったろ

905 ：名前は開発中のものです。：04/01/29 14:29 ID:lhaq+dfi

>>894 >>902
そうなんだよ、スルーすればいいんだよ
ところがどうだ？このスレの対応ぶりは
興味ある話ならいつまでも引き摺ってやがる
結局自分のことしか見えていないんだよ

>>904
もちつけ

906 ：名前は開発中のものです。：04/01/29 14:34 ID:lhaq+dfi

それから、2ch云々言ってる奴
それならばこの争いも2chという場故起こるものだ、仕方ない、と諦めるんだな
それこそスルーしてな

907 ：名前は開発中のものです。：04/01/29 15:02 ID:9HI+iNHu

それよりも、前のメモリのときも今回のCVSの時も思ったんだが、
このスレではなぜか必ず言い合いになるところが気になってたヨ。
スレ違いの話が拗れるのもそういう気質のせいなのかも？

908 ：名前は開発中のものです。：04/01/29 15:25 ID:JhirhLNZ

>>907
ははは、レスが多いと気づかんかも知らんがな。

この板には人がいない。そういうことだ。

909 ：i3J/7d0z：04/01/29 15:50 ID:JfWR0Q8Z

私は
ﾆｯﾎﾟﾝの
なぁなぁ文化が
とても
大っ嫌い
です。

910 ：名前は開発中のものです。：04/01/29 19:11 ID:v4oLGMri

>>907
無駄に潔癖な人間が多そうだからな。
流通量が多くてトピックが混乱する板なら、厳格にスレ守れってのもわかるんだけど。

俺には手段が目的と化してしまってるように思えてならない。

911 ：名前は開発中のものです。：04/01/29 20:39 ID:hLBJbtpW

>>801とか>>843とか
スレ違いと自覚しているのに平然と話を始めるその態度に腹が立つ
後者に至っては、自分で移動先を提示しているにもかかわらず、だ

いくら屁理屈言おうが、内心は「ここが一番濃い人達が集まってそうなので」程度のものなんだろ？
実に不快だ

912 ：名前は開発中のものです。：04/01/29 20:48 ID:rSIvMvU0

前者はスルーすればすむが、後者はいただけないな。

913 ：名前は開発中のものです。：04/01/29 20:49 ID:XlkVjXef

聖地を巡る宗教戦争・・・か
双方の言い分はわからないでもないが、解決は極めて難しいだろうな
人間とは、美しくも儚く、醜い生き物だな

914 ：名前は開発中のものです。：04/01/29 20:58 ID:9HI+iNHu

ていうか、OOの話題があってもほとんど続かないというのもこのスレの終わりッぷりを
現しているというか。・・・要するにゲームにOOはいらない？

915 ：名前は開発中のものです。：04/01/29 21:01 ID:UFysFpeF

そういうわけでもないと思うが
各自それなりに自分なりの解答を持っていて
その流儀がまったく相容れないことが多く
会話にならないだけじゃないのか？

916 ：名前は開発中のものです。：04/01/29 21:11 ID:HgPHyG6r

みんなタスクシステムって使ってるの？概念的には１タスク＝１クラスだよね
この板見てると、今時そんな技術は使わないっていうのをよく見かけるんだけど
使う場合と使わない場合、それぞれのメリットとデメリットについて証言していただきましょう

　　　　証言開始
～　タスクシステム　～

917 ：名前は開発中のものです。：04/01/29 21:42 ID:+VRHlGcV

先に語るべきタスクシステムの定義からはじめてください。

あなたのいう「概念的」なものを指すのか、
「今時そんな技術」といわれるような特定の実装を指すのか、
意味が曖昧です。

918 ：名前は開発中のものです。：04/01/29 22:13 ID:9HI+iNHu

タスクといったらアレだろ？・・と有名なあのページを挙げようと思ったが、リンク失念。

919 ：名前は開発中のものです。：04/01/29 22:36 ID:o2xqz4Kx

>>918
http://i-debut.org/opinion/m_disp.asp?code=1138
これか？

920 ：名前は開発中のものです。：04/01/29 23:36 ID:MjenIosc

アーケード系の人の考えてるタスクの粒度が小さくて驚いた。
敵１個とかウィンドウ１個とかでタスク１個なのね。
しかも親タスク子タスクとか色々複雑。
こういうレベルでのタスクはもう使われなくなるんじゃないかな？
ポーリングよりイベントドリブンだろ？って事で。
俺の中でのタスクは「タイトル画面タスク」とか「メニュー画面タスク」とか
そういう粒度なので、これは残るでしょ？
メインループはアプリ中に１つにしたいもんね。

921 ：920：04/01/29 23:38 ID:MjenIosc

ところで>>916
そのノリは逆転裁判なのか？

922 ：とむ ◆0MTMwDpCZo ：04/01/30 00:15 ID:sDbad55u

>>920
それは、あなたが考えてるタスク処理と、その人（アーケード系の人？）が言ってる
タスク処理というのが、もう用語として違ってるだけじゃないでしょうか？

だって、あなたの言うタスク（タイトル画面、メニュー画面）って同時に動かないでしょ？
その相手の人は、同時に動く細かいものを指してタスクと呼んでる、というだけの話じゃ
ないかなあ。

923 ：名前は開発中のものです。：04/01/30 00:46 ID:RA4dqfAu

というよりタスクシステムとか言葉があるけど誰でも思いつかね？
めんどくさいから色々考えて関数へのポインタだけ管理すればいいように
作ってたら俺流のタスクシステムができたよ
わざわざ用語にするまでもないと思ってるほどだが・・・

昔はハードウェアの制限とか独特の仕様かなんかで
割りこみを手軽に入れれる組み方を模索してたんじゃね？

と、言ってみるテスト

924 ：920：04/01/30 02:22 ID:beApg1n9

>>922
> だって、あなたの言うタスク（タイトル画面、メニュー画面）って同時に動かないでしょ？
ノンノン。
RPGのフィールドタスクは戦闘タスクがフォアグラウンドの時も
バックグラウンドでフィールドの描画だけしてたりします。
その他諸々、CPU時間を共有するタスク群は大きな粒度でも色々ありますよ。
(入力なんかは実デバイスにアクセスするのは一回で後はその結果を何度も参照するでしょう？
そうしたらそれは最初の方に実行される「入力タスク」なんて形にしておくのが常道だと思われ。)

>>923
> わざわざ用語にするまでもないと思ってるほどだが・・・
デザパタの効用の一つと一緒ですね。
概念へのモニカとしての「名前」は結構重要ですよ。

925 ：とむ ◆0MTMwDpCZo ：04/01/30 02:28 ID:sDbad55u

なるほど、同時にも動くんだ。
例にあげたのが、タイトル画面とかメニュー画面だったので、それはログの前の方で
出てた「シーン」という用語に近い事を言ってるのかと思いました。

926 ：名前は開発中のものです。：04/01/30 03:54 ID:eX2Y5e2T

マイクロスレッドみたいな奴じゃないのかな？

927 ：名前は開発中のものです。：04/01/30 06:23 ID:4QVDHaxk

だからタスクの定義ってのを明確にしろっての。
語の定義が曖昧だと不毛な論争にしかならんのは自明。

おまえらこのスレを最初から読み直せ。

928 ：名前は開発中のものです。：04/01/30 10:31 ID:g+Z82H4r

いつも単純な関数ポインタ配列+インデックス変数でやってる漏れには関係のない話だな…

929 ：名前は開発中のものです。：04/01/30 13:06 ID:6yC1pPDZ

あったあった。あちこちで「タスク」の話題が出たとき紹介されるページ。
とりあえず「タスク」のベースはコレでいいんじゃない？
自分のと(大きく)違う場合は、コレとの差分を明示してから発言する、と。

コンピュータゲームのからくり
http://www.hh.iij4u.or.jp/~peto/Games/games_top.html

930 ：名前は開発中のものです。：04/01/30 15:26 ID:RA4dqfAu

>>920
なるほどね。
いつもながらこのタスクシステムという言葉自体に違和感を感じるから
タスクシステムパターンとして欲しい

まぁぶっちゃけこの手の人と開発したことあるんだが、
RELESE_ALL_TASK //　タスク全部一発解体！！
とかあって心底うぜーとか思ってたことがあっていらい
うぜーとしか思えなくなってしまったよ。

STL使ってlist使えば
list.clear();
これで終了
くだらねーコメント書いたり、マクロ定義してんじゃねーよと思う

すでに知ってる奴に対してはウゼーorハァ？で返ってくるだろうね
つーわけで

知ってれば有効
知っていなくてもプログラムは組める

931 ：名前は開発中のものです。：04/01/30 23:06 ID:EJsdAPeN

宗教戦争のもう一つの原因、プロとアマの違いを>>930のレスに垣間見た気がする。

932 ：名前は開発中のものです。：04/01/30 23:15 ID:aF8Z90tr

STL厨め…