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

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

2

掃除機、OOは素人にはお勧めできない。

むう、正直、こっちを使って欲しひ。
http://game.2ch.net/test/read.cgi/gamedev/1005040025/

まずは、データ構造とモジュールについて、しっかり勉強して下さい。
でなければ挫折します。

PS2のコンパイラ、クソすぎて複雑なクラス構造理解してくれないYO!

YO! とか使う奴多いよね。開発者に。いまだに

>>6
PS2ってgccでないの？

>>7
そういうのを突っ込むのは板違い

＞6
OO的思考はイイんだけど
いざ実装するときにC++とかだと
コンパイラ腐っててできねえ！とかあるわよねえ。
コンパイラ特有の変な制限あったり。
マニュアル見たらテンプレートクラスはファイル1つにブチ込めゴルア！
・・・だそうな。鬱死

そうだね。テンプレートはOOとはあまり関係ないにしてもだ(コンパイルタイムポリモーフィズムって言われることもあるけど)。

ループを回して、その中でゲームの状態により
switch文とかで分けて処理するとかしたらなーんかいつもながーい
ループが出来上がっちゃうんですが、
みなさんどうされてるんですか？

>>11
この辺とか
ttp://www.hh.iij4u.or.jp/~peto/Games/games_top.html

タスクシステムって、原始的なOOかも。

>>11
状態をオブジェクトにする。
そうすると、ゲームのメインループは有限状態マシンとしてモデル化できて
ゲームに依存しないフレームワークを作ることができる。

有限状態マシンのモデル化は、ちょっとしたオブジェクト指向入門書になら
書いてあるでしょう。

>>13 に加えて、デザインパターンのStateパターンとか
その辺を参考にするといいかもです、はい。

今までは 12 のサイトに書かれていた処理が多かった。
アマプログラマと名乗っているなら似非タスク処理を作るのが良いと思う。

OOを使えばタスクは使わなくなるの？

ふーむ、なるほど。>>12-15ありがとです。
ぜんっぜん思いも寄らなかったけど
>>15読むと時代の流れは先に行ってるようですが、
どないなんでしょう？

まあ、最初は古典的？っていうか原始的？っていうか
自分なりに力技な方法でやってもいいんじゃないでしょうか。
あまり考えすぎると、理屈倒れのなんとやらになるかもです。

最近WinSDKプログラミングをはじめたんですが、
WndProcでコールバックされた後やるswich文をMessageHandle用クラスに
持たせて多態化させて、デザパタのStateパターンっぽくやろうと試みてます。
Menu選択とか、ダイアログとかのMessageHandle関係全般につかえるよう
ある程度汎用的に・・・と構想してます。

とりあえずの目標はシンプルである程度汎用的なフレームワークを作って、
DirectXやOpenGLをいじくろうと思っているんですが・・・・

こういうことって、既にみんなやってるモンでしょうか？

>19

やってると思いますよ。
ゲーム作るのなら必須でしょう。

いま>>12のリンク先のタスクシステムを見てます。
面白いです。確かに原始的なＯＯＰという感じです。
ＴＣＢを見てるとクラス化したくなってしまいますが、
長年培われてきた（？）型だけに、下手な設計ではＯＯ化は
逆効果になりそうですね。

デザパタではState,Strategy,Flyweightあたりがまず不可欠
でしょうねー。

ところで実際のところゲーム開発の現場ってＣとＣ＋＋の比率はどのくらい
なのでしょうか？
C++でやってるのは余裕のある大手くらいってかんじですか？

C++は遅くて使い物にならんと思うが

>>23
マジ？
XboxはVC++がデフォだって聞いたけど。

>>23
こういうことを言う奴はｼｯﾀｶ君

てことは>>23は C++でゲーム開発してるって話は見たことも聞いたことも無い？

>>25
そうか？
継承するとパフォーマンスが悲惨なんだが
そんな事はないか？

VTBLのオーバーヘッドなんかもう無視できるっしょ。

スターオーシャン2ndストーリーのトライエースのロゴの下に
try-Ace PlayStation Foundation Class Library
とかなんか誇らしげに表示されてるのは見たですが。

そりゃぁXboxはそうかも知れんが、
我がマシンでは数倍違う

C++が遅いのではなくて、Classライブラリに問題があるのでは？
私もＯＯやC++崇拝者なわけではないんだけど。
C++がCと比べてオーバヘッドあるのは事実だと思うけど、Cの手法だって
インライン関数だってインラインアセンブラだって使えるわけだし。
深すぎる継承を使わないとかクリティカルなところでは伝統的な手法を
使ってゆけば、使い物にならん、ってことはないいんじゃないかと。

>>27
まさにｼｯﾀｶ君
全然何も分かってないらしいな
プラットフォームとは関係ない

しょうがないから本を一冊薦めといてやる
「C++/C プログラム改善法」
ただしトッパンはもうつぶれてしまった

仕方ないので
「Efficient C++」
で代用
こちらはピアソン・エデュケーションだからまだ
売ってるだろう

そうかプラットフォームとは関係ないのか。
そうだとすればC++は使い物にならないという事だな。

かたくなだな。

>>31
同じ会社の(クラス)ライブラリが
CとC++でそう違うものなのか？

なんとなくだけど、Ｃ＋＋のようなＯＯと、ゲームのプログラミングって
相性良くないような気がしています…。
昔はいいと思ったんだけどね…。

つうかCオンリーで組むのも相当キツイと思うけど。
延々とグローバル関数作りまくり・・
STL無いし・・

継承のコストって x86 でいえば
call [v_table+n]
程度じゃない？

どちらかといえば、インスタンスの生成破棄を
無頓着に行うと効率さがるよね。そんなことは
Effecient C++ レベルにでも書いて有るようなことだし。

Ｃ＋＋をＣと比較した場合、クラスの使い方を間違えると、
コード量が約２倍になる。コードの書き方を間違えなければ、
Ｃと等速のコードも書ける。

オブジェクト指向が本領発揮するのってやっぱ共同開発において、でしょ
一人でシコシコ作る分には無理に移行する必要無しと思われ。

もうOO抜きで組めない俺は就職不可能ですか？（´д｀；）

>>41
ＯＯを完全にマスターしているか、必要以上に使わないなら、
大丈夫かと。中途半端に使うと非効率なんで。

>>36
なんとなくって書いてるところにつっこむのはｱﾚだけど、
どのへんが相性よくないと思ってる?

>>42
オレはむしろＯＯは中途半端がいいと思う。
業務アプリみたいに、完璧なＯＯＰではやはり速度的に厳しいんじゃないか？
ＯＯは中途半端にいいとこだけ使って、古いやり方をラッピング＋部品化ってのが
いいじゃないか。
効果的にやるのにＯＯの理解は中途半端じゃ困るが。

C、C++、さらにObjective C。
最後のはなんじゃい、ってのはナシね。アポーに言ってくれ

>>43
難しいなあ…。本当に感覚的な問題なんだけども…。

私は、ＯＯＰは何かを分散的に処理するのに向いているような気が
している。分散的ってのは、例えばＷｉｎｄｏｗｓのように、多数のタスク
を同時に動かしたりするようなものね。
で、ゲームもまさにそういう分散的なアプリケーションで、確かにそう
いう面ではＯＯＰと良く親和する部分もあると思います。でも、ゲーム
の場合突如として様々なタスクを一元的に管理する（つまり分散的の
逆）必要が出てくる場合があります。このような時、Ｃのような単純な
言語に比べてちょっとめんどくさいような気がするのですよ。ほんとに
なんとなくなんだけど。

ま、Ｃ＋＋は言語仕様上ＯＯＰというスタイルが可能になっているだけ
で、Ｃと全く同じスタイルで組む事は出来ますし、逆にＣでもある程度
まではオブジェクト指向なスタイルで組む事も可能は可能ですから、
要は組み方の問題なんですけどね。

単に私の腕がヘボだからそう思うのかも知れません。クラスのスコー
プを考えて、何をどのファイルに入れるかで死ぬほど悩みますから（笑）。
Ｃの時はここまで悩まなかったのに…って。

速度に関して経験がないので分かりませんが、
正直、私もＣでゴーリゴリやっていた（今でもそう）んで、
ＯＯ的設計に馴染めない自分ってのが居る（笑）
ＯＯに限らず、場合によっては中身が見えないハコって
不安でしょうがない（笑）

>>46
＞でも、ゲーム
＞の場合突如として様々なタスクを一元的に管理する（つまり分散的の
＞逆）必要が出てくる場合があります。
いや、俺は逆にこの辺のことをスマートにできるからOOPLがいいと思ってるんだが。
タスクって要するに抽象クラスなわけで、そういうことをするのに言語の支援が受け
られるなら、そっちのほうがいいと思うし。
まぁ、もちろん、OOは概念なんだから、実装は一番やりやすいのでやればいいんだけどね。
(Cでも、ゲーム作ってるとOOに近くならない？

＞クラスのスコー
＞プを考えて、何をどのファイルに入れるかで死ぬほど悩みますから（笑）。
＞Ｃの時はここまで悩まなかったのに…って。
これは激しく同意。
宣言の順序とか考えなきゃならないときもあって激しく萎える。
C++はこれだから…。

>>47
中身が見えないのはＯＯとは関係ないなぁ。
C++だってソース公開すればブラックボックスじゃないし、
システムが複雑になってくるとクラス図にしやすい分C++の方がよさげ。

うーん、恐らく私が言っているめんどくささというのは、基本的に私が
まだＣ等の非オブジェクト志向言語での制作スタイルから脱しきれて
いないからでしょう。これらの言語を何と呼ぶのかな？　良くわからな
いけど、とりあえず私は「処理志向」なんだよね。

本来、ＯＯＰというのは、オブジェクトが先にあって、それが動作すべき
処理が従になるのが正しいのだと思います。
しかし、私は頭が古いから、実現したい処理の方ばかりに考えが行って
しまうのですね。で、例えば今動作しているオブジェクト（ここで言うオブ
ジェクトは、ゲームにおけるオブジェクトね）全てに影響する処理、など
というものを考えた時に、処理が主で、クラスが従という考え方をしてし
まうのです。ある処理のためにクラスを使おう、などと思ってしまうと、
処理がプログラム全体のあちこちに散らばっていると、問題とするクラス
をどこにインクルードするかというスコープの問題で頭を抱えてしまう
のです…。

ああ、なんか自分で書いてて良くわからなくなってしまった（笑）。
ヘボコテハンの独り言だと思って下され。

中身が見えない、というのは私も感じるよ。

Ｃで遊んでた時は、書いたコードが、アセンブラで言うところのどんな
コードに直されるか、うっすら予測しながら書いてたよ。もちろん完璧
じゃないけどね。大体どう書けばどういうループが組まれるか、とかそん
な感じでなんとなーく考えながらコードを組んでた。提供されるライブラ
リも、何がどう処理されるかとか半分くらい予測つくしね。

でもＣ＋＋の場合、パッと見で「現実にはどういう処理がなされるか」と
いうのが分かりづらいんだよね。パッと見っつーか、良く見てもさっぱり
わからない。あるコードを書いた時、どこをどう参照してどういうコード
にコンパイルされるのか、ほとんど予測つかない。
「別にアセンブラのコードを予測しなくていいよ」というのが正解なんで
しょうが、例えばハードにちょっと近い処理をしたい時に、書かれるコード
の応答性がどうかとか、メモリ管理がクリティカルになる可能性があるの
かどうか、ワイルドな入力に対して堅牢なのかどうかとか、予測つかない
と不安なんだよね…。古い人だから（笑）。

>>50
はは。
俺も、まだメインループ等全体にかかわることは、OOの外だよ。
どこまでをOOにするのかは意見の分かれる処なのかもしれん。
コリジョンの処理とかどこでやろう？とか、いまだに悩むよ。

>>50
たぶんそれはオブジェクト指向の「すべての対象はオブジェクトです」みたいな
理想論を見てひいてしまってる感じじゃない？
そういう理想論は結局理想であって、ＯＯＰでやっても「全てに影響する」なん
てのは「処理ルーチンをクラス化して順番に解決する」という結局本質的には
>>50のやり方と大差ないものだったりするよ。

>>52
>>53

そうだね、現実的に考えれば、そういった広範囲に及ぶ処理はＯＯ
の外に追い出すのが普通だね。

でも私は理想主義者なのかな？（笑）　例えば設計時に、色んな
物を美しくクラス化して、完全なヘッダを設計したりするでしょ。
けど、結局上記のような問題にぶち当たり、仕方なくそれらのクラス
を呼び出す関数を作り、広範囲な処理時にはその関数を更に呼び
出すような仕掛けにしてしまい、「これじゃＣ＋＋の意味ないじゃん！」
と机を叩くわけです（笑）。

>>53
「すべてがオブジェクト」ってのはOOPL自身の設計の話なので、
(しかも言語の効率とか、複雑性とかの話なので)ちょっとちがうかも。
>>54
「すべてに影響する」ってのを実現するにはVisitorパターンを使うわけだけども、
あれは、諸刃の剣だからあぁ。
どっちにしろ、「処理」だってオブジェクトなわけで、そのように設計するかしないかは
あとは慣れだろうな。

C++が遅いって言っている人がいるよー。
そら、Cよりもオーバーヘッドがあるかもしれないけど、そんなに問題にならんでしょうに。
もしなるとしたら、それは実装に問題ありと思うが。

それに、無理して全部C++で書く必要もないでしょう。
最下位レベルだけアセンブラでかけばいいのでないのか。

…その書き込みを読んだだけでも、「Ｃ＋＋は遅い」という事自体は
間違ってない気がするのですが…。

>>50 とむたん。
たぶんCなどの言語の総称は「構造化プログラミング言語」。

C++が、どんなマシン語のコードに変換されるかは、
いちどCでオブジェクト指向的なプログラムを組んでみると、
理解しやすいんじゃないでしょうか。

たしかプログラム板のどこかのスレに、そういう話題があったとおもいます。
virtual function tableとかで検索かければ見つかるかも。

あとオブジェクト指向の内部よりな話なら下の本が、おすすめ。
「 ゲーム&&オブジェクト指向プログラミング」塚越 一雄

>>27たん。
継承より問題は多態性じゃない？
それにしたって考慮するほどのものじゃないけれど。

// スレと関係ないけど、いま名前をいれて書き込んだら
// 「ＥＲＲＯＲ：名前いれてちょ。」って言われたよ。(TT

>>58
>たぶんCなどの言語の総称は「構造化プログラミング言語」。

あ、いや、「オブジェクト志向」に対する言葉として何か適当な言葉が
あるのかな、と。「構造化〜」は対義語というより、C++の土台になって
る概念でしょう。

>>51
> でもＣ＋＋の場合、パッと見で「現実にはどういう処理がなされるか」
> というのが分かりづらいんだよね。

具体例を挙げてみてください。
分かりづらい部分が想像できないんです。

>>60
いや、私は頭が悪いので、ちょっといくつかのクラスを継承してると
「？」になるよ。もう中で何が行われてるかわかんない（笑）。

いや、分かる人も多いとは思うんだけどね。

>>60
例外処理とRTTI

friendでみんな友達（鬱

多重継承で（以下略

>>61
それはソースだけ見てるから。
クラス図を横に置いておけば吉。

47だけど、アタシもとむさんと同じで、想像できない方のタイプ。
ＯＯって、メモリ上がどのように書き換えられつつ走っているのか
想像しにくい。
なんで？とかどこが？と言われても困る（笑）
一度抽象化された、オブジェクトの意味合い的なイメージでは
もちろん流れが掴めるけど、その具体的な処理の中身の話。
とむさんも同じではないかしら？

だからどっちがどうした、っていう話ではないので誤解なきよう。

>>61
>ちょっといくつかのクラスを継承してると
>「？」になるよ。もう中で何が行われてるかわかんない（笑）。

継承したことによって、どのメソッドが呼ばれているか
ぱっと見わからないと、そうおっしゃる
その分かりづらさは、C++だからってわけじゃないですね

#include <stdio.h>
void test0() {printf("0\n");}
void test1() {printf("1\n");}
int main() {
struct {void (*method0)(); void (*method1)();} T;
T.method0 = test1;
T.method1 = test0;
(T.method0)();
(T.method1)();
return 0;
}

こういうことでしょ？

いや、パッと見でわからないというのは、処理の流れ自体ではなくて
（むしろ処理自体はブラックボックス化されて考えなくて良い分わか
りやすいところもある）、「実際にどういう命令になって、ＣＰＵがどういう
動作をしているか」がわかりづらい、って事を言いたいのよ。

例外処理はもちろん分かりづらいけど、それはＣの頃からちょっとわ
かりづらかった（笑）。アセンブラが一番わかりやすい。

>>67
まぁ、そんなに問い詰めることもなかろ。
文化の違いに戸惑ってる程度の話でしょ。
ﾏﾀｰﾘいぐべや。

>>62
例外処理はCに比べてC++の方が
むしろ見た目わかりやすくなってると思うけど

>>59 とむたん。
んじゃ「手続き型プログラミング」
http://yougo.ascii24.com/gh/21/002131.html

>>68
> 「実際にどういう命令になって、ＣＰＵがどういう動作をしているか」がわかりづらい

class B : public A;
class C : public A;
B.virtual_method() -> (*(vtbl + 0x50))();
C.virtual_method() -> (*(vtbl + 0x70))();

こんなもんですが

>>69
ﾏﾀｰﾘとこりかたまった頭をほぐしてさしあげましょう

>>71
うーん…「手続き型」が「オブジェクト志向」に対立する言葉かどうか
は微妙だなあ…。

何か私および47さんと、60さんとの間で考えのズレが起きている
気がしないでもない…。

何度やっても遅いって

それはそうと他人の作ったクラスを利用するのは気持ち悪い

Cでこう書くとこういう命令になるだろう
C++ではこう書いてあるけどどういう命令になるかわからん

それがどのようなソースコードなのかをすごく知りたいんです。

そうそうCはアセンブラの代わりという感覚で使えたけど
C++はそうは行かないんだよね。
名前が似ているだけのまったく違う言語になってしまっている。
Cの単純さを備えて欲しかった

うーん、だからさ…。
Ｃの場合は、ちょっとしたプログラムなら、向こうにアセンブラのソース
が透けて見えるでしょ。ローカルで作った変数なら、きっとこのへんの
レジスタに割り当てられるな、とか。こういう条件式を書くと、こんな形
のループにコンパイルされるな、とか。主にシングルタスクＯＳの場合。
多少関数を呼んだって、順次スタックに積んで下ろして、という感じじゃ
ない。
ところがC++の場合、ちょっといくつかの親クラスを継承したクラスの
場合、「どの時点で実体が確保されるか」つまり、メモリが割り当てられ、
あるいはレジスタが割り当てられたのかとかが良くわからなくなるのよ。

Ｃってのは、ある意味ＣＰＵが順次実行している命令のプロセスをほとん
どそのまま追っている言語だと思う。だから、実際のＣＰＵの動作がわか
る。
ところが、C++ってのは実際に実行される順番に命令を並べているのと
はちょっと違うスタイルのプログラミングを（基本的には）する言語でしょ。
だから向こうに実際のコードが見えない、という事なのよ。

最下位まで気にしなくていいのが良い点なのだと思うが。
ボトルネックになっている部分をインラインアセンブラで書けばいいじゃん。

> Ｃの場合は、ちょっとしたプログラムなら、
> 向こうにアセンブラのソースが透けて見えるでしょ。

本当にわかってますか？ 小一時間問い詰めていいですか？

> メモリが割り当てられ、
> あるいはレジスタが割り当てられたのかとかが良くわからなくなるのよ。

int a; はレジスタに割り当てられてー
char b[25]; はスタックでー とか？
Cでstruct {int a; char b[25];} t;はどう配置されるの？

> C++ってのは実際に実行される順番に命令を並べているのと
> はちょっと違うスタイルのプログラミングを（基本的には）する言語でしょ。
> だから向こうに実際のコードが見えない、という事なのよ。

Cでもコンパイラによるリオーダリングはありえると思いますが
それは除いたとして
C++で実際に実行される順番が異なってしまう状態例を
あげてくれると非常にうれしいです。感激しちゃう。

>>73 とむたん。
うーん>>50で、とむたん自身が言ってた「処理指向」と
手続き型っていうのは、まさに同じものだと、おもうんだけど。

いかなる言語にしても過去の有効な手法は取り入れているわけだから、
C++や、ほかのオブジェクト指向型の言語が、まったく土台に取り入れていないもので、
純粋にオブジェクト指向と対になるパラダイムなんて、ないんじゃない？

ちょうどエージェント指向に
オブジェクト指向の考え方が取り入れられているようなもので。

// 手続き型プログラミングについては、こっちのほうがわかりやすかも。
// http://www.e-words.ne.jp/view.asp?ID=2397


>>75 23たん。
実行のたびにネイティブコードにコンパイルしているJavaよりは、
C++のほうが、はるかにましだよ。(TT

// あ。ただJITやHotSpotなどでネイティブコードにコンパイルされたあとなら
// JavaはC++よりも高速という話はあるけど、ほんとかな。

>>80
>本当にわかってますか？ 小一時間問い詰めていいですか？

　まあ前にも書いたけど、完全に頭でコンパイルできてるわけでは
なくて、なんとなくだってば。小一時間問い詰められたらボロが出るよ。

　あと構造体だけど、それは別にそのまんまメモリに配置されるだけ
では…。構造体の直接読み取りとかやったことない？
　コンパイラによっては間にパディング入れたりするけど…。

８１を読むと、やっぱり私と60さんの間で話がきちんと通じてないと
思った…。うーむ。ジェネレーションの差かなあ（笑）。

>>83
そこまでわかってればC++でもおんなじだと思うんですよ

メモリだけ考えると
structとclassの違いは virtual method がある場合に
vtblへのポインタが入るかどうかだけなんだから

で逐次実行ってのはCでもC++でもかわらないので
classのコンストラクタが呼ばれるタイミングは
Cでstructを使うのとかわらない
Cにはnewがないけどmallocしたあとコンストラクタが呼ばれるだけ

>>85
じゃあじゃあ
> C++ってのは実際に実行される順番に命令を並べているのと
> はちょっと違うスタイルのプログラミング
ってどんなのか聞かせてほしいですー

ちゃい >>84 の間違い

まあちょっとＰＣの前を離れるんで、色々お答えはできませんが、
多分私の言いたい事をわかってくれた人も何人かはいたようなので、
きっと誰かが代弁してくれるでしょう。すまそ＞60さん。

Cは書いた通りに処理されるけど、
C++ではソースコードでは明示されないポインタのやり取りとか、
プロセスの移行とかがあって気持ち悪い。

> C++ではソースコードでは明示されないポインタのやり取りとか、

一番簡単な例はメソッド呼び出しで
インスタンスのポインタが this が行きますね
これは納得

> プロセスの移行とかがあって気持ち悪い。

これはﾅﾝｿﾞ??

コンストラクタとか
オペレーターとか

ボーランドC++のプロパティとかは末期的

じゃ。まとはずれかもしれないけど代弁してみよう。

>>86 60たん。
とむたんの言う「ちょっと違うスタイルのプログラミング」とは、
たぶんオブジェクトどうしがメッセージをやり取りして物事を処理していく
アクターモデル的プログラミングスタイルのことじゃない？

// おれドキュソだから、そこまで複雑に、ものごと考えたことないけど。

＞Cにはnewがないけどmallocしたあとコンストラクタが呼ばれるだけ
なんか誤解を招きそうだな。
まるで、mallocでインスタンスを作成してもコンストラクタが実行されるみたいだ。
こんな誤解をする人間はここにはいないか…。

結局、どこまでブラックボックスを許容するかで、すれ違っているような
気がする。
「Cでアセンブラソースが透けて見えないと気持ち悪い」って人も、CPUの
内部動作自体は気にしないでしょ？トランジスタ１つ１つの働きとか、実際に
は気にしないし、そこまで考えたらやってられない。
OOの場合、プログラムの抽象化のレベルが上がるので、その分ブラック
ボックスとして扱わないとやってられない敷居が上がって、アセンブラレベル
の動作まで考えたらやってられないので、気にしないのが一番って事に
なるのでは？
（ちょっと例えが極端かも。ま、意味は判るのね？）

http://life.2ch.net/test/read.cgi/psy/991265343/518

> まるで、mallocでインスタンスを作成しても
それはインスタンスと言っていいものなのか聞いていいですか

vtblなしのclassなら実害なし？

ブラックボックスのレベルをどこまで許せるかということですな。
アセンブラ上がりの人で、勝手にナニやってるかわからないってC言語嫌がる人だっているわけだし。
俺は、まあオブジェクト指向レベルは許せるかなって感じで。
当然ピンポイントでインラインアセンブラは使うけどさ。

まあ、言語のメタ化が進んできてるっとことなんでしょう。
新しいメタ化の手法が普及し始めたら、OOは許容できた俺でもキモチ悪がるかもしれない。

オブジェクト指向ってのは開発方法論であって
使用する言語は関係ないと思うがどうか。
オブジェクト指向方法論に基づいてアセンブラでコーディングってのは
いまどき特別なことじゃないでしょ。

>>96たん。
全部たどっていったら下のレスからのリンクで
ウイルスがみつかったよ。
// もしかして全板にリンクはりまわってるの？

Ｊｒ．ファンのみなさんへお願い
http://music.2ch.net/test/read.cgi/jr/994988000/264

モジュールを少しでも勉強した事があるなら、
どの部分をブラックボックス化すればいいか？
なんて事は、そこそこ分かる事なんだが・・・

なんでモジュールやデータ構造を勉強せずに、
ＯＯＰに手を出すかな？

>>93

それが
> C++ってのは実際に実行される順番に命令を並べているのと
> はちょっと違うスタイルのプログラミング
なの？

順番に命令をならべてそれがそのとおりに実行されるのは
変わってないと思うんだけど

それともあれか、C++でクラス作ってインスタンス作ると
それが勝手に並列実行されるのか？

とりあえず http://www.njk.co.jp/otg/Study/　を読みなはれ >> 93

みんな中途半端な知識しか持ってないから
こんな中途半端な議論になっちゃうんだよね
意味無し

>>103
そう思うんなら君も中途半端に煽らずにもっと突っ込みをいれなさい

>>101
「モジュールの勉強」とは何ですか？
この業界では一般的な用語？

>>99
それは解るし正論だけど、だからといってC++でのゲーム開発の有効性
の議論が無意味ってわけじゃないでしょう。
今ここでは、だれも概念レベルと実装レベルのＯＯを混同している人は
いない。誰が見ても明らかに実装レベルの議論でしょ。
オブジェクト指向言語についての議論だよ。

C++でも十分に出力されるアセンブラコードが透けて見えるよん。
ちょっと複雑なだけで。

ていうか、私がC++に移行したのは、
Ｃで自己流似非OOPモドキ（ていうかモジュール化の延長線上か）やってて
ある日C++の仕組みについてあれこれ読んで
これ俺がやってることとまったく同じじゃ〜ん、
しかも遥かにシンプルに書ける！ マンセー！って動機だったですが。

>>90

>> C++ではソースコードでは明示されないポインタのやり取りとか、
>一番簡単な例はメソッド呼び出しで
>インスタンスのポインタが this が行きますね
>これは納得

それ納得しちゃうの？
ソースで明示的に書かれていなくても、言語仕様を知っていれば
自明なことでしょう。
裏で何をやっているか本当にわからないような言語でプログラミン
グなんて不可能だと思うけど。

亀質問だけど。
>>23==>>75 さん。

遅い遅いというけれど、何を実行しての感想なの？

>>108
>それ納得しちゃうの？
んー
「C++のメソッドってソースコードに書いてないのに、
　本当は引数１個多いんだよねー気持ち悪いよねー」
「うん、そーだね　C言語だけの知識では想像できないね」
だしょ

> 言語仕様を知っていれば自明なことでしょう。
そりゃそのとおり

>>102 60たん。
とりあえず「オブジェクト指向入門」まで読み終わったよ。

並列実行といえば話の流れは、かわるけど、
むかしJavaでゲームに登場させるすべてのキャラに
ひとつひとつスレッドをわりふって、いっせいに動かしてみたよ。
こういう時こそオブジェクト指向は、べんりかも。

オブジェクト自身が自分の状態を保存してくれるし、
ことなるクラスのオブジェクトを同一のメッセージで処理できるし。

// ただ、それでも「順番に命令をならべてそれがそのとおりに実行される」
// というのは、おれも基本的に変わってないとおもう。

// ところで>>102のリンク。60たんのおすすめのページは、どこ？
// たくさんありすぎて、つぎなに読めばいいのか、わかんないや。(TT

>>105
・モジュール
構造化プログラミングで、ある機能を有する小部分をモジュールという。
容易に交換し得るような機能単位のプログラムを指す。プログラムを
モジュール化して作れば、次のような利点があり開発効率の向上が期待できる。
１）開発時に分業化できる
２）誤りの部分発生を特定できる
３）機能改善に部分変更で対応しやすい

入り口までは案内した 扉は自分で開け

って感じ
自分が興味を感じたタイトルから読んでくのが吉と思われます

明日の自分は今の自分より強いですか？

>>111
Ｃ++のページで半年ほど独学すれば？

>>109
何をって何？

C++は仕様が汚くて後々再利用するものをC++で書く気にはなれない。

＞言語仕様を知っていれば自明なことでしょう。
もちろん自分で作ったものに関しては自明で大変便利な機能だが
他人のものを読む時にはくだらない労力が増える。
裏で行われているかどうかではなくて、
行われている事を調べるのが大変
継承を繰り返しているともはやあほくさくてやってらんない。

＞裏で何をやっているか本当にわからないような
＞言語でプログラミングなんて不可能
そんなことはない

>>112
サンクスです。
要するに構造化プログラミングを勉強しろということですね。

>>105
モジュールの概念は、開発時にバグを減らすための技法
覚えておけば、かなりバグを減らせる

一応、情報処理技術者試験で出るんだが・・・

>>115
＞継承を繰り返しているともはやあほくさくてやってらんない。

藁。もうプログラミングやめた方がいいんじゃない？

たぶん最初からやってないと思われ。

だから、C++使うな！

>>116
ま、そーゆー事やね。

>>120
・・・それでも使っちゃう・・・♪

こういう本筋とは関係無いどうでもいいスレッドばっかり育ってるなここ

ゲーム機などのリソースが限られていたときの
伝統が残っていて，どのようにソースを書けば
最適コードになるか意識するという強迫観念が
あるからコードの吐き方がイメージできないと
怖いのではないのでしょうか？

>>124
でも思ってるほど、最適なコードなんて書けてないのがゲームプログラマ

アセンブラで最適化って最高に楽しいよね。
浮動小数点演算のあの糞なスタックをやりくりする
楽しさといったら！

>>124
単に、プログラムの設計を勉強してないだけの話
そりゃ、命令を適当に組み合わせるだけでも、
プログラムを作る事は出来るケドね

つーか、プログラムの設計を理解してない人に
ＯＯＰなんぞを使わせても、猫に小判。

Ｃなら向こうにアセンブラソースが透けて見える？？
cpuが違っただけで、例えばペンティアム�Uと�Vの違い
で全く別言語のような環境と化してしまうアセンブラを
どうやって”透かして見る”んだ？教えて！！

>>127
いや、そういう人が使うためのＯＯＰでしょ。
汗職人には汗職人のための職場がありますよ。
多分。（藁

>>129
ライブラリが充実しているなら、同意するケドね・・・

>>128
78はプログラミング経験が皆無か、
超環境依存型のクソプログラム書いてるんでしょ。
なんに使うのか謎だけど。気にしないでいいよ。

ここはアホぷるぐらまのスレか？

＞ペンティアム�Uと�Vの違い
＞で全く別言語のような環境と化してしまう
オイオイ、
そんなに最適化されたコードはくコンパイラあるのかYO！

128と131はアセンブラで組んだ経験が皆無

高級言語ってアセンブラを意識しなくて良いように作られたんちゃうの？
生成されるバイドコードが想像出来ないからダメって、そりゃお門違いも甚だしい。
コンパイラに頼りきりになるであろう、IA64のようなアーキテキチャの場合どうすんの？
俺に言わせればわかろうとする方がおかしい。

>>133
だからアセンブリ言語の事言ってるんだよ。
コンパイラとアセンブラの違いは分かるかい？

>＞ペンティアム�Uと�Vの違い
>＞で全く別言語のような環境と化してしまう
>オイオイ、
>そんなに最適化されたコードはくコンパイラあるのかYO！

IntelCは吐き分けてくれると思ったけど、どうでもいい話題なのでsage

>>136
78はコンパイラについてだよ。分かるかい？

＞IntelCは吐き分けてくれると思ったけど、
吐き分けてどうしようって言うんだ、一体？

>>138
コンパイラなのにアセンブラソースが見えると書いてるよ。
分かるかね？
＞吐き分けてどうしようって言うんだ、一体？
どうするのか分からんなら聞かなくていいよ。（藁

ふう。このスレも某3Dプログラミング系ページに晒されそうだな。

>>139
それは実際の実行プロセスに非常に近いという事だろう。

>>141
・・・ハァ？
＞それは実際の実行プロセスに非常に近いという事だろう。
言ってることが（危）レベルに達してますな。

もー全然OOとゲームプログラミングぢゃねーよ
Game Programming Gems並みのネタをｷﾎﾞﾝﾇ

>>142
ハァ？
分からんの？

うう良いスレだったのに

とりあえずアセンブラソースを実行なんたらと
勘違いしている>>144を放置してＯＯＰに関する
話題で再開しましょうか。

貴方がなぜC++を使わないゲームプログラミングをしているのか
理由を書いてくれる人　他にはいないの？

>>147
あなたって？

貴方って誰？

>>146
実行なんたらってなんだ？
あほか？

「ゲームプログラミングをする時にC++を選択しませんでした。」
という人がいるなら、その理由を聞きたいわけですよ
非常に興味深い

まぁ、「対象となるターゲット用C++コンパイラがありません」つーのは
ご愁傷様としか言えませんが
コンパイラ移植するって手もあるけどね

やあ、今ログ読んでました。
すみませんね、荒れる原因みたいになっちゃって。

でも全体的に停滞気味の板だから、たまにはいいかな？（笑）

私、ゲーム専用機対象にプログラミングしたこと無い門外漢ですからサパーリで
興味本位に質問ですけど、C++コンパイラ使えるようになったのって
どのあたりからですか？
　　+->PCE　　 +->DC
FC->SFC->PS->PS2
　　　　　　　　　 +->64->GQ
見たいな流れの中で

3DO,PSあたり?

>>151
C++コンパイラの最適化性能が低くて、糞なコードを量産する
そもそも、まともにC++の言語仕様が実装できていない

なんて理由もあるかもね。

>60
該当者なんで、私もレス書きまーす。
前もって書きますが、私自身、流行の思想については使いこなせれば
良いなーと羨ましいですし、ＯＯについて偏見もありません。

私はＣのみでゴリゴリのヒトです。
理由ですが、必要ないから（必要性を感じる局面に遭遇してない）
という事と、やはり
「始めに物ありき」の考え方よりも、
「始めに物事の振る舞いの、法則ありき」の方が、私自身、
皮膚感覚的に馴染めるからです。これは、食わず嫌いではなく、
プログラムに限らず、何かを考える際、「物」（主語、目的語）
ではなく「事」（動詞）から先だって考えてしまう癖が
あるからのようです。

おそらく、このような思考方法の人間が、無理やり似非ＯＯ的
プログラムをしたところで、欠陥のある設計しかできないに
違いありません（笑）
そんなわけで、私は大人しくＯＯには触れずにおります。

>おそらく、このような思考方法の人間が、無理やり似非ＯＯ的
>プログラムをしたところで、欠陥のある設計しかできないに
>違いありません（笑）
>そんなわけで、私は大人しくＯＯには触れずにおります
　押しつけるつもりはないけど、一通り勉強してから
結論出しても遅くないと思うけど・・・。
なんかもったいない

いやいや、現状で「そうだ」というだけで、決して結論を出した
わけではありません（笑）

さらには、まったく勉強してないわけでもありません。
勉強不足の度合いと、それが原因か否かはさておき、
現状では私の仕事に役立っていないというだけの話でして、
今でも関連書籍を読んだり、テストプログラムは書いて
みたりはしております。

>>158
大規模なものを組み始めるとOOな手法が管理しやすいのだけど
もともとOOはSAと対立する技術ではないので、SAの技法もきちんと
勉強するのも大切なことだと思いますよ。
地盤が脆い状態で高層ビルを立てるのが不可能なように
コードを何十万行も書いて、経験を積んでSAもOOD/OOAも実装も
コストも利点も理解したうえでターゲットに最善な手法を
選べるようになれば結構いい感じになるんじゃないでしょうかね。

ぶっちゃけた話、木造二階建てを作るのにツーバーフォーな手法よりも
大工職人がトンカンやったほうが、ツーバイフォーな会社を作るより
小回りが効くし、でも出来てしまえばツーバイフォーは早い納期で
高層ビルだって立てられる。でもそれを設計するには習熟と経験が
必要不可欠なわけで。

うーん。私も勉強しなくては…。
勉強不足な自分への自戒の意味もこめて。

今の会社はCマンセー。

Cを使うにしても、使いまわされることを前提に作られているなら
まだいいが、プロジェクト毎にソースコピペかＹＯ！

３年以内に効率の悪い開発体制を変えられなかったら、
会社辞めることになるな。

ま、Cしか使えない厨房は家でおとなしくしてないさい、ってこった。

プロジェクト毎にソースコピペかＹＯ！

ソースコピペかＹＯ

ＹＯ

160
(･∀･)ｶｺｲｲ! ｹﾞﾗｹﾞﾗ

>>113-114 60たん。114たん。

とりあえず分散オブジェクトと
デザインパターンのとこから読み進めてみる。

ふたりのおかげで気力が、わいてきたよ。
ありがとう。☆⌒(*＾-°)v Thanks！！
// こんど開発状況報告スレにも、いってみようかな。

>>50 とむたん。>>156たん。

いっそ、その「物事の振る舞い」だけを集めたクラスを作って
オブジェクト指向してみるって、どうかしら。

つまり仮想関数だけで構成される
通常のメンバ関数もメンバ変数も持たないクラス。

で、その「物事の振る舞い」が、
なにかのデータ群(つまりクラス)で必要になったら、

そのデータ群に仮想関数だけのクラスを継承させて、
そのデータ群に特化した処理を実装するの。

Javaにおけるインターフェイス的な考え方だけど、べんりだよ。
このクラスは、いっさいデータをふくまないから、
多重継承になっても、ややこしさが発生しないし。
// ただ問題は処理速度かも。。。

ところでJavaでゲームを作ろうとしてるおれは、
もしかして、ここではスレ違いで逝ってよしなのでしょうか。

// いや、それ以前にJavaの処理速度で逝ってよしという気もする。
// 鬱朶思王。。。でも氏なないで、がんばる。
// でも、おれが逝くまえにJavaが先に逝きそうな気もするよ。(TT

インラインアセンブラを多用したプログラムを組みたい
ヘッダをインラインまみれにしても極限まで自分でチューニングしたい
いわゆる汚い泥作業も厭わない任侠気あふれるOOなら C++

>>163
複数の人が別々にコーディングする場合はその方が吉だろうね。
一人でやる場合はＯＯＰにこだわる必要はあまり無いとは思うけど。
関数の集合クラスを作ったり継承したりっていう余分な作業は一人で
やる時は得るものが少ないんじゃないかな。
ＪＡＶＡはアメリカでは終わりだとか言われてるけど（ＭＳがサポートを辞めた）
日本ではまだ元気があるみたいだし、しばらくは大丈夫かも。
速度は問題だよね。技術が足りないからだとか言われるけどそこそこの
技術力でももう少し速くなればいいのに思うよ。

Cでゴリゴリやってる人にはC++はかなり泥臭くて似合ってると思うのだが。
C言語が好きじゃない俺は、C++はいくらOO言語だからっていやだけど

先生！とりあえずC++が遅いって言うのは論外だと思うＹＯ！
どうしても速度的に問題ある部分は、モジュール分けてCで書くっていうのじゃまずいの？
俺はそんなことはしませんが。使える環境なら必ずC++を選択するよ。

っていうかC++ワカランってところってまだ結構あるよね。
この前もローカライズ担当してる下請けがC++解りませんって泣きついてきたよ。（ﾜﾗ
C++駄目って奴はとりあえずC++で一本作ってから
反論した方が恥をかかないで済むと思われ。

>>166
プロのゲーム開発の現場に限ったらASM,C,C++以外に選択肢は無いのでは？
C/C++に負けない実効速度を出せるＯＯＰＬってあるのだそうか？
純粋な質問。

>167

どうも、このスレの流れとして
一部をCとかアセンブラで書くと良いじゃないの? -> やっぱり遅いってことじゃない。ｱﾋｬﾋｬﾋｬ
って流れらしい。

おれは楽できるところは楽すれば良いと思うけどな。

一部をCとかアセンブラで書くと良い ＝ 最適化して書く
が前提。

>>168
コンシューマだとないだろうな。そもそも処理系がない。

>>60
>C++で実際に実行される順番が異なってしまう状態例を
>あげてくれると非常にうれしいです。感激しちゃう。

グローバル変数のコンストラクタ／デストラクタ。

それは最初から不定なので問題なし。

>>169
C++が遅いと言われても、そんなことは絶対にないと断言は出来ない。
もしかしたら自分の知らないケースで、めちゃ遅くなるかもしれないし。
そういうことで、逃げうってるだけだと思われ。

C++がCより遅くなる、具体的なコード例を挙げられる人居る?
仮想関数によるポリモーフィズムは遅いと言われがちだけど、
同じ事をCでやるとif文やら関数ポインタやら使うわけで、少なくともC++より高速に動かせるという保証はないと思われる。

どっち派でもいいんだけどさ、互いにコッチだ！って啓蒙しあう
必要ないでしょう。（そーいうのはヨソでやろう）
このスレは、前提としてＯＯで、どの様に良い設計をしていくか
がテーマなんだから、そういう話をしないと
「まったく意味がない」

確かにCで一つ一つ全て別々に作っていたものを
C++で基本部分からの継承で作ると結構遅くなる。

深い継承は、その時点で設計が間違ってることが多い(MFCとか)。
デザインパターンを勉強するよろし。

多少遅くなったぐらいで実際に影響が出る環境で作ってる人が多いみたいですね。
コンシューマの方ばかりなのかな？

業界人手あげてー！

現場ではCとC++の使用比率どれくらいですか？
て前にきいたけど、だれも答えてくれない（泣

ところで、以前「モジュールの勉強って何？」ときいて恥をかいた漏れです。
結構Ｃは書いてきたので、処理とデータをまとめてドメインの独立性を高める
努力は必然としてやっていたんですが「構造化プログラミンの勉強」っていうのを
真正面からやったことは確かにない。
で「構造化プログラミング」の参考書を探しに本屋にいったんだけど無いですね、
全然。オブジェクト指向ばっかり。
ためしにオライリーの「Ｃ言語実践プログラミング」をぱらぱらと見たら、一応
モジュールとかデータ構造とか書いてあったけどなんか、いまさらなことばかり。
今までやってきた文法以上のＣの訓練が実は構造化プログラミングだったてこと
でしょうか。
構造化プログラミングを極めるための本とか、構造化デザインパターンみたいな
ものってあるのでしょうか？
スレ違いでスマソ。

・・・何も買わないのは癪だったので「Game Programing Games」かってしまった。

>>181
構造化定理って調べてみ

ageるっちゃ。

>>182
サンクス、ザクザク出てきた。
この世界も奥深いね。べんきょー！べんきょー！

仮想関数には関数ポインタのような柔軟性がないのが嫌。
以前、
CTask{
virtual void Update();
};
CEnemy extends CTask
CEnemy1 extends CEnemy
CEnemy2 extends CEnemy
CEnemy3 extends CEnemy
みたいな設計をして失敗した。

やっぱりコアは構造体と関数ポインタに限るよ。

>>185
それがどういう不都合があったのか教えてもらえれば、
解決方法を提示できるかも風来のシレン。

>>186
・コーディング量が増え、生産性が落ちる。
関数ポインタの場合、関数を作ってアドレスを渡すだけだが、
仮想関数の場合、最低限classの定義、仮想関数の定義、コンストラクタの定義が入るため
余計なコーディングが必要になる。
ましてやクラスごとにcppとhを作っていた場合ファイル数がたいへんなことになる。

・動的なメモリ確保を強制される
関数ポインタの場合、関数アドレスを変更するだけで動作を変更できるが、
仮想関数の場合delete,newを呼び出す必要がある。
オーバーヘッドとメモリの断片化が問題となる。

・他クラスを参照している場合の解放タイミングの問題
参照先のタスクが解放済みか否かの判断が複雑になる。
静的に確保された構造体では、消去済みフラグを立てておけば
参照先が消去済みかはその参照先のフラグを調べることで判断できるが、
deleteされたクラスにこれをやると、不正なメモリアクセスになり落ちる。
もちろん解決方法はあるが、そのオーバーヘッドがばかにならない。

他にもいろいろあるがとりあえず代表的なものを。

ム板のゲーム開発スレでも出てたけど、
オブジェクトは必ずしも不要に成ったらdeleteしなければ成らないわけではない。
まとめてワーク用オブジェクトのプールを作っておいて、フラグ、ID管理をする
こともやろうと思えばできる。
これを実現すれば>>187の２，３番目の問題はある程度解消できるよね。

この変が、ゲーム開発的ＯＯＰの特徴にになってｋるんじゃないかと、
素人ながらに思っています。

後重要なものを忘れていた。
・動的な型情報の取得が簡単にできない。
関数ポインタの場合、function_address == Enemy1?で判断できるが、
クラスの場合CEnemy1クラスであるかどうかの判断が大変面倒になる。

>>187
どういう場合に型情報が必要ですか？
基本的には抽象化された型情報の実際の型
を知らなくても、振る舞いをさせることが出来るのが
理想な気がしますが…。

>>190
特定のタスクを消したい、特定のタスクのみ更新したい。
こうした要求は少なからずある。
MFCでも、IsKindOf(RUNTIME_CLASS())という動的に型情報を取得するための
メソッドが用意されているでしょ？

>180
んー、ツールではC++使うけど、製品には使わないねぇ。
基本的にCでなんでも出来ちゃうわけだから、「圧倒的に開発効率が良くなる」
とかいうシチュエーションにならない限り使わないと思うなぁ。
出来あがったソースコードはC++の方が綺麗だけど、
他の開発メンバーの書いたコードを理解するのはCの方が
しやすかったり、ヤバめのバグをアセンブラソースレベル
で追跡したりするハメになった時Cの方が楽だったり・・・

ちなみに、スレの本題の「ＯＯ」については、言語に
関わらず自然とそうなってる気がしますが。

完全なOOなんて相当な大規模プロジェクトでない限り、
馬鹿げている。

>>192
ありがとうございます・・・
やっぱりまだこの業界では「これから」の技術なのでしょうか。
Ｃ＋＋に移行してゆく保証もありませんけど。

>>188でもちょっと書きましたが、ゲーム開発にはゲーム開発の独特の
ＯＯＰが必要なのは間違いないはずです。
ＯＯではデザインパターンというものが重要な地位を占めてますが、
ゲーム開発的デザインパターンがまとめられて、それに基づいた設計・実装
ができるようなクラスライブラリが整えばＣ＋＋への移行もあるかも知れない
というところでしょうか。

>>191
では、そのIsKindOf(RUNTIME_CLASS())（のようなもの）であるとか、
Updateのメソッド自体に更新の判断をさせるほうが良い気がするのですが…。
それではデメリットがあるのですか？

>>195
IsKindOfを実装するには、これまたクラスごとに面倒なコーディングが増えるわけよ。
関数を作って、SetTask(Function)を呼び出すだけとい
お手軽さとは雲泥の差があるわけ。

Updateに判断させる場合、すべてのクラスにその判断処理を実装する必要があるわけでしょ？
それまた面倒でパフォーマンスも悪いわけ。

一応、現在の実装例を書いておこう
CTaskManager{
public:
TASK* SetTask(void* function_ptr);
void Update();
private:
TASK mTask[MAX_TASK];
};

CEnemy{
public:
static void Enemy1(TASK*);
static void Enemy2(TASK*);
static void Enemy3(TASK*);
};

>>192
俺もC++の可読性については、ちょっと同意かなあ。
ちらっと読んでもわからないんだよね、他人のソースが。
継承ツリーの根元にあるメンバなんか、いきなり出されても
作った本人しかわからないよねえ。
グローバル変数使いまくりのCでも、そっちの方が読みやすいというのはあるよねえ。

C++(OO)は圧倒的にデバッグが楽。って思うのは俺だけ？
特に多人数での開発になると顕著だと思うんだけど。
他のプログラマによる不正な操作を制限しやすいのはかなりメリットだと思う。

Cでもキチンと書けば問題無いんだけど、
なんか致命的かつ再現率の低いバグが出やすい気がする。
↑これは自分がへぼいのは自覚してます。

あとまともに動けば例外処理もかなり強力だと思うざんす。

圧倒的ってほどでもないですね。誇大表現でした。

>>196
>Updateに判断させる場合、すべてのクラスにその判断処理を実装する必要があるわけでしょ？
こういう場合、むしろ管理する側がチェックするよりも自分自身が判断する方が
むしろ軽くできそうなすみそうな気がしますけど…（適当でスマソ）
＃もちろんこの程度ならC++使わなくても、Cだけでも出来ますけど。
class ab
{
virtual void update(const status& a)=0;
};
class con0 : public ab
{
virtual void update(const status& a){ do_update(); } // これはいつでも更新するクラス
}
class con1 : public ab
{
virtual void update(const status& a){ if(!a->pause){ do_update(); }} // pauseしてないときだけupdate
}

...
for(vector<ab*>::iterator i=obj.begin(); i!=obj.end(); i++){(*i)->update(current_status);}

>>201
いや、
if (pause){
　for (;;){
　　if (task[i]->update == PauseTask){
　　　　(*task[i]->update)(&task[i]);
　　}
　}
}else{
　for (;;) (*task[i]->update)(&task[i]);
}

条件分岐をループの外に持っていけるし、妙な引数も必要ない分、
圧倒的に有利だよ。
まあPauseの用途に限定するならタスク構造体に属性を持たしておいた方が便利だけど。

>>199
なんとなく同意です。
自分自身のヘボさを知るものとしてはCよりもデータへの不正な制限を掛けやすい
C++の方がいいかなぁ…と思ってます。

>>199
俺も楽だと思うよ。
問題が局所化されるから見る範囲がかなり限定されてくる。
まー、何にせよ慣れでしょうね。
Cべったりな人たちには無理せず使い慣れたCがよござんしょ。

>>194
ツールではバリバリ使うんで業界的に（というか、うちの会社的に）
「これから」っていうわけでもないんですけどね。なんでツールで
使うかといえば、クラスライブラリが用意されてたりして「圧倒的
に効率が上がる」から。

ツールとか実用ソフトの場合、インターフェイスの統一性
が重要ですが、ゲームの場合は寧ろゲーム毎の独自性や面白さ
の方が優先されるわけで、その辺も難しいですね。

あと、コンシューマーの場合リソースの管理をかなり見通しが
効くようにしておかないといけないのが、楽に組めない要因で
すね。快適にプレイさせる為には必要になった時にリソース
確保じゃ遅い（先読み対応）とか・・・
メモリも、「メモリ１２８ＭＢ以上推奨」で済まないし、
「最悪仮想記憶で・・・」というわけにもいかない。
Ｃ＋＋でやるにしても、メモリ管理は全部自前でしょうね。
まぁこれは、ＰＣでもそうなんでしょうけど。

なんか、愚痴っぽいな。

>>202
う〜ん、このあたりは判断すべき条件の場合分けの数であるとか、どこの
オブジェクトがその判断に責任を持つかっていう所で実装を分けるかも
しれないっすね。（そういう意味ではpauseは不適当だったか？）

私が>>202のようなソースを見たときに一番危惧するのは、条件分けが
多岐にわたったときに（pauseだけではなく、アドバタイズであるとか、
デバッグ用のモード(?)であるとか）updateの呼び出しが多個所になって
しまい、たとえばupdateメソッドの呼び出し方が変わった場合、変更が多岐
にわたってしまうんでないかい？とか思ってしまうのです。

＃このあたりの考え方は好みに近いところだと思うので、なにが正解とも
＃思いませんけど…。

>>206
CTaskManager::Update()
{
　switch(mode){
　case UPDAETMODE_DEFAULT:
　　for (;;) (*task[i]->update)(&task[i]);
　　break;
　case UPDATEMODE_PAUSE:
　　for (;;) (*task[i]->update)(&task[i]);
　　break;
　case UPDATEMODE_DEBUG:
　　for (;;) (*task[i]->update)(&task[i]);
　　break;
　}
}

多岐にわたる理由などありませんが。

>>207
ヲイヲイ・・・

>>208
何か問題でも？

>>207
208の煽りは私ではないですよ〜。誤解しないでね。（ﾆｺ

＃以下は好みの話し程度に読んでください。
いや、>>202のpauseの時にその呼び出し側に関係ない処理は（OOP抜きとは関係ないですけど）
呼び出し側で制御すべきでないと思うんですよ。（それは例え>>207のような形であっても、結局
caseの数だけupdateメソッドを呼び出す個所が出来るわけで。）
もし一つ一つのオブジェクトで処理を判断するのが重いぜ、やってられないぜというのであれば、

// >>201からのつづきと考えてくださいね
// 文法的に嘘があっても無視の方向で（自虐藁
class ab_collection
{
vector<ab*> abc;
void add_ab(ab* _o){ abc.push_back(_o); }
virtual void update(const status& _stat) = 0;
};
// 見たいな形でオブジェクトをまとめるクラスを一段「かませ」て、
class free_ab_collection : public ab_collection // 判断のひつようなしクラス
{
virtual void update(const status& _stat){
for(vector<ab*>::iterator i=abc.begin(); i!=abc.end(); i++){ (*i)->update(_stat); }
}

class test_ab_collection : public ab_collection // pauseフラグをチェック
{
virtual void update(const status _stat){
if(stat->pause){ return; } // ここでチェックすることで、以下のabの各クラスではチェックする必要が無くなる
for(vector<ab*>::iterator i=abc.begin(); i!=abc.end(); i++){ (*i)->update(_stat);
}

みたいにしてやれば、見通しも良いまま、効率を保つことも可能ではないかと。
（親クラスはab_collectionの塊を持ってupdateを呼び出すだけ。）

実際にプログラムで重いところって大量のメモリのキャッシュミスと回数の非常に多い単純計算
だと思ってるんで、そこさえ気をつければ、見通しよくプログラムするためのコストって許されるんじゃ
ないかと思ってます。
＃もちろん、見易さは人によってそれぞれだとおもうんで、>>207さんの方法も尊重します。

>>210間違い
それぞれのab_collectionから継承させたオブジェクトで
>for(vector<ab*>::iterator i=abc.begin(); i!=abc.end(); i++){ (*i)->update(_stat); }
を呼ぶのは愚の骨頂ですね。ab_collectionに置くべき処理でした。
失礼…。

少なくともＰＣゲームのプログラムを組む場合、
Ｃ＋＋を利用したことによるオーバーヘッドはほとんど
気にしなくていいような気がします。

PC(Windows)のゲームでメモリの断片化気にして組まれてるのはどのくらいあるんだろ…。

というか断片化の話はoperator newのオーバーロードで対処。
CTaskの継承クラスのサイズに最大128バイトとか制限かけて、
メモリプールから確保するようにする。

＞というか断片化の話はoperator newのオーバーロードで対処。
オーバーライドだと思うが…。
細かい突っ込みかな。

malloc自体が仮想メモリを利用することが前提の関数だし、おそらくnewもそうだろうと思います。
仮想メモリがある環境だと、あまりメモリの分断化は気にしないかも。
コンシューマだとガベージコレクトやメモリコンパクションやらを考えないと
いけないでしょうね。
メモリマップを始めにきっちりと作るというのも手だと思いますけど。

>>215
オーバーロードでも対処できるよ。
newに特殊なパラメータ(フラグ)を取らせてそれによって、デフォルトのnewとは
動作を変える。
この場合、newの動作が暗黙のうちに最適化されるのではなく、プログラマが必要
に応じてメモリ割り当ての方法を選択できる。
うまくやれば、こっちの方が便利かもしれないよ。

昔、擬似タスク処理をC++で実現しようとしたとき、処理とその処理で使う
メモリ領域をどうすり合わせるかで挫折した。

Cの場合は、構造体内部に関数へのポインタがあればそれを切りかえることで
簡単に実現できた。
C++の場合、上記メソッドのオーバーロードで簡単に実現できるのはひとつの
メソッドだけ。
無理やりやろうとすると、オーバーロードするメソッドの中で
処理するメソッドへのポインタを利用して処理を飛ばすという、
なんとも汚いものになった。
こんなことするくらいなら、構造体+関数へのポインタで処理させたほうがまし
だと思った。

>>217
ごめん、ちょっとわかりにくい。
「オーバーロードで簡単に実現できるのは１つだけ」というのは
operator newのオーバーロードが１つだけってこと？

>処理するメソッドへのポインタを利用して処理を飛ばすという、
>なんとも汚いものになった。

あまり解釈に自信がないんだけど、例えばこういうの？ 汚いかなあ。

typedef void(Task::*TaskFunc)();

class Task {
public:
　　void SetMethod(TaskFunc updateFunc) { m_updateFunc = updateFunc; }
　　void Update() { (this->*m_updateFunc)(); }
private:
　　TaskFunc m_updateFunc;
};

class HogeTask : public Task {
public:
　　HogeTask() {
　　　　SetFunc((TaskFunc) Func1);
　　}
　　void Func1() {
　　　　...
　　　　SetFunc((TaskFunc) Func2);
　　}
　　void Func2() { ... }
　　void Func3() { ... }
};

こうやってTaskManagerから直接呼び出してもいいか。

class Task {
　　friend class TaskManager;
public:
　　void SetMethod(TaskFunc updateFunc) { m_updateFunc = updateFunc; }
private:
　　TaskFunc m_updateFunc;
};

ｷﾞｬｰｽ
s/Method/Func/g

C++のソースはなぜこうも美しく無いのだろうか？

>>222 Cで同じもん書いてみてみそ。

Cの人はなぜ、継承だけで解決しようとしたり、
C++で関数ポインタ使うのはイヤみたいに言うのかわからん。

とりあえず、タスクを１ステップ進行させるメソッドの名前は
みんなUpdateですか。

もうvirtual関数無しではプログラム組めないっす。

ゲーム系だと特に期限ギリギりでの仕様変更が多いので（仕様書な
んてものが存在しない場合も多いけど）、パッチ当てる感覚でその場
がしのげて良いです。

その後の事はしらん（藁。

>>219
Func1 は
typedef void (HogeTask::*FuncType)();
であって、
typedef void(Task::*TaskFunc)();
ではない。
メンバ関数へのポインタはクラスによってサイズが違うという話を聞いたんだが、
SetFunc((TaskFunc) Func1);
このキャストは安全なのか？
を

典型的なC++のタスクと、Game Programming Gemsの3.0みたいな
マクロ使った状態マシン組みあわせてみない？
オレは今から試すにょ。

>>227
安全じゃないからキャストしてると思われ（ｗ
仕様上は安全じゃない（プログラミング言語C++第３版15.5.1）が、
C++の実装上は上手くいくのではないか。
ちとキモチワルイ感はある。

ありゃ、キャストしたからってうまくいくのか?
エラーが出そうなものだが。

g++でコンパイルしてみたけど、駄目だった。
コンパイラの問題かな。

こんなのどう？

#define DECLARE_TASK(TypeName) \
void (TypeName::*m_updateFunc)();\
public:\
virtual void Update(){(this->*m_updateFunc)();}\
private:\

#define SET_TASK_FUNC(FuncName) {m_updateFunc = FuncName;}

class Task
{
public:
　　virtual void Update() = 0;
};

class HogeTask : public Task
{
　　DECLARE_TASK(HogeTask)
public:
　　HogeTask(){
　　　SET_TASK_FUNC(Func1);
　　}

　　void Func1(){
　　　…
　　　SET_TASK_FUNC(Func2);
　　}
　　void Func2(){};
};

わたしが昔、書いたのは大体こんな感じでした。
219さんのソースを利用させてもらいます。

extern "C" {
#include <stdio.h>
}

//-----------------------------------------------------------
// 基本擬似タスク
//-----------------------------------------------------------
class Task {
public:
　Task() {};
　virtual ~Task() {};
　virtual void SetFunc(void) {}
　virtual void Update(void) {}
};

//-----------------------------------------------------------
// 擬似タスク定義部
//-----------------------------------------------------------
class HogeTask;

typedef void(HogeTask::*TaskFunc)(void);

class HogeTask : public Task {
public:
　HogeTask() { SetFunc(&HogeTask::Func1); }
　~HogeTask() {};

　void SetFunc(TaskFunc updateFunc) { m_updateFunc = updateFunc; }
　void Update() { (this->*m_updateFunc)(); };

　void Func1() { printf("Func 1\n"); SetFunc(&HogeTask::Func2); }
　void Func2() { printf("Func 2\n"); SetFunc(&HogeTask::Func3); }
　void Func3() { printf("Func 3\n"); SetFunc(&HogeTask::Func1); }
private:
　TaskFunc m_updateFunc;
};

続き
//-----------------------------------------------------------
// 擬似タスク実行部
//-----------------------------------------------------------
class ExecuteTask {
　Task *taskArray[100];
　int iTaskPoint;
public:
　ExecuteTask() { iTaskPoint = 0; }
　void SetTask(Task* prtTask) { taskArray[iTaskPoint++] = prtTask; }
　void execute(void) {
　　{for(int i = 0; i < iTaskPoint; i++) {
　　　taskArray[i]->Update(); }
　　}
　}
};

最後

//-----------------------------------------------------------
// メイン
//-----------------------------------------------------------
int main(int argc, char** argv) {
　HogeTask hogeTask;
　HogeTask hogeTask2;
　ExecuteTask executeTask;

　printf("<<1st>>\n");
　executeTask.SetTask(&hogeTask); // タスク1セット
　executeTask.execute(); // タスク実行

　printf("<<2nd>>\n");
　executeTask.execute(); // タスク実行

　printf("<<3rd>>\n");
　executeTask.SetTask(&hogeTask2); // タスク2セット
　executeTask.execute(); // タスク実行

　return 0;
}

実際は、タスク実行終了時の資源の解放とか、タスク実行順序とか
いろいろ機能がありました。
ともあれ、結局構造体+関数へのポインタで実装したほうが
分かりやすい上に、パフォーマンスの上という理由で捨てました。

>>230
VC だとメンバ関数のアドレスはその名前だけでよいが、
C++ の仕様だと &クラス名::関数名 でないとダメ
そこ以外でエラーはでないと思われ

>236
うむ確かに、うまくいった。
つうか、なぜ気がつかない、俺。

こうなると、219のコードが一番スマートなのかな?
キャストが嫌ってことなら、231になるか。

試しにこんな感じにモデル化してみたんですが、どんなもんですかねえ。
これをいかに楽に記述する方法を考えるかみたいなー。
何かタスク記述言語でも作って、
C/C++ソースに変換するフィルタでも用意するのがええかのう。

タスク {
　　タスク変数
　　タスクの状態

　　タスク作成時の処理
　　タスク破棄時の処理
　　汎用イベント処理

　　状態１ {
　　　　状態の初期化
　　　　更新処理
　　　　状態の後始末
　　　　汎用イベント処理
　　}
　　状態２ {
　　　　状態の初期化
　　　　更新処理
　　　　状態の後始末
　　　　汎用イベント処理
　　}
　　...
}

なんかここまで来ると、クラスの必要ないじゃないか
って感じもするな…。

#include <iostream>

class Task;
class TaskManager;

typedef void(Task::*TaskFunc)();

class Task {
　friend class TaskManager;
public:
　void SetFunc(TaskFunc updateFunc) { m_updateFunc = updateFunc; }
　//　void Update() { (this->*m_updateFunc)(); }
private:
　TaskFunc m_updateFunc;
};

class HogeTask : public Task {
public:
　HogeTask() {
　　SetFunc(static_cast <TaskFunc> (&HogeTask::Func1));
　}
　void Func1() {
　　cout << "Func 1\n";
　　SetFunc(static_cast <TaskFunc> (&HogeTask::Func2));
　}
　void Func2() { cout << "Func 2\n"; }
　void Func3() { cout << "Func 3\n"; }
};

class TaskManager {
　Task *taskArray[100];
　int iPoint;
public:
　TaskManager() { iPoint = 0; }
　~TaskManager() {}
　void setTask(Task* task) { taskArray[iPoint++] = task; }
　void execute(void) {
　　{for(int i = 0; i < iPoint; i++) {
　　　(taskArray[i]->*(taskArray[i]->m_updateFunc))();
　　}}
　}
};

でも、Ｃで書いてUpdate関数にp->xとかp->vxとか並びまくったり、さらに
#define VX　(p->vx)
みたいな真似をしたりするのもどうも気が引けるとゆーか・・・。

オブジェクトの挙動のパフォーマンスなんて
多少高かろうが低かろうが屁みたいなもんじゃん。
描画エンジンの都合で……ならわかるけど。

>>241
文句言っている人は、たぶんコストが無視できないプラットフォームで作ってるんですよ・・・。

age

>>241
んなことはない。
オブジェクト指向ヲタはSetPixel,GetPixelとかまで仮想関数
にしたがるから。
それにパフォーマンスが問題にならないような上位層はスクリプトにするのが普通だし。

>>244
それ描画まわりじゃねえか

>>241
そういう簡単な挙動しか実装しない場合は
オブジェクト指向化の恩恵も少ないと思われ。

>>239
たぶんサンプルコードだからだと思うけど、
Task *taskArray[100];　とかがいや。std::list使おうよぅ

>>247
禿同｡

皆さんどうしても関数ポインタ使わないと気が済まないの？
なんで？
パフォーマンスのため？
タスクシステムを忠実にC++で再現したいから？

CSomeTask::update ()
{
　switch(this->mode){
　case UPDAETMODE_DEFAULT:
　　this->do_default ();
　　break;
　case UPDATEMODE_PAUSE:
　　this->do_pause ();
　　break;
　case UPDATEMODE_DEBUG:
　　this->do_debug ();
　　break;
　}
}

実際これでほぼ十分でしょ。

まあ、実用上はそういうコードでほぼ大丈夫なんだけども。

＞タスクシステムを忠実にC++で再現したいから？
それに加えて、激しく状態遷移するタスクのデバッグは
もうこりごりってのもあるです。

>249
ゲーム全体で擬似的なスレッド処理を実現させたいからだと思われ。
背景をスクロールさせながら、ウィンドウをアニメショーンさせつつ移動させたり
するのをスレッドで実装すると分かりやすいからでしょう。
普通に、ループのなかでやるとifの連発になりそうだし。

＞std::list使おうよぅ
STLを使うとついてこれない人がいるから…。
という冗談はさておき、サンプルだからでしょう。

>>249はその「擬似的なスレッド処理」の中身だと思うですが。

>>249
汎用性の問題。
関数ポインタの場合はswitchと違って、
機能を増やしても書き直す必要がない。

ついでに
C++のメンバ関数へのポインタでやると
関数1つ追加ごとにヘッダーへの変更が発生するのも問題。
privateな関数をどうしてヘッダーに書かねばならん！

>>251
listは遅いのでvector使おう。

あんまり関数ポインタを多用するのは
オブジェクト志向っぽくない気がする。

>254
C++は、クラス定義を見ただけで、だいたい何をやってるか分かって
便利だと思っていた俺は厨なのかしらん。

っていうか、みんなVC++のClassViewを使いませんか？

>>241
何言ってるのよ
市販品かいとりますがな

>257
MFCに不満が山ほどあるから、使ってない。

>>255
あのコードだとタスクは死なないみたいだけど、
ふつー死ぬでしょ　順番かんけーなく
eraseのコスト考えたらlist

ClassViewマンセー

>>259
SDKベースでもClassViewは使えるよ。コード補完も。

>>261
あ、ClassViewか
スマソ、ClassWizardと勘違い

ちなみに、タスク間のデータの受け渡しって、みなさんどうやってます？

enum{
WORK1,
WORK2,

WORK_MAX,
};
DWORD Work[WORK_MAX];
をグローバルで宣言して共用してます。

もっとスマートで近代的なやり方を教えてプリーズ。

ＯＯと関係無い可能性があるので、sage

ソケット

>>257
べつにヘッダーに書く手間が面倒なわけじゃない。
外部が使用するインターフェースに変更があるわけじゃないのに
内部に機能を追加するだけで、インターフェースを使用している
モジュールに再コンパイルがかかるのが嫌なだけ。

しまった、俺もClassWizardと勘違い

>>265 Bridgeパターン

結局、派生先を生成してるファイルは再コンパイルせないかん。
まぁそのくらいはどうでもいいが、いちいち基底クラス作って
どうたらこうたらなんてやってられんと思うのだが…

>>268
VC++使ってると全然気にならないんだけどな。

Delphi使ってると再コンパイルの手間すら気にならんけどな。

仕様がしっかりしている場合に限るけれど、
こーゆー書き方なら、たまぁにする。
class CMain;
class CSub
{
public:
CSub(){}
virtual ~CSub(){}
virtual void FunkA(CMain*pMain) = 0;
virtual void FunkB(CMain*pMain) = 0;
};
class CSubNull : public CSub
{
public:
void FunkA(CMain*){}
void FunkB(CMain*){}
};
class CMain
{
CSub*m_pSub;
static CSubNull m_SubNull;
public:
CMain(){ m_pSub = &m_SubNull; }
virtual ~CMain(){}
void FunkA(){ m_pSub -> FunkA(this); }
void FunkB(){ m_pSub -> FunkB(this); }
void SetSub(CSub*pSub)
{
if(pSub == NULL)pSub = &m_SubNull;
m_pSub = pSub;
}
CSub*GetSub(){ return m_pSub; }
};

それは立派なStateパターンでんな。

C使いでC++がダメ!って言う人は、実装継承とか深い継承とかを試してみてダメって言ってる気がする。
デザインパターン勉強すれば便利に使えるんだけど、使えるかどうか試してみるだけの人にデザパタ勉強しろとは言えないからなぁ。

OOの真髄はデザインパターンによるコーディングのパターン、及びテンプレート化だからなぁ･･･
ボトルネックとか、無駄な継承等を最適化していったら、どっかで既に使われていたパタｰンの
亜流だったなんての事は、実際かなりあったよ･･･

>>273
意味不明

>>275
デザパタの学習をやり出せば解る｡
デザパタはOOを十分理解してる事が前提で話を進めてるので｡

ageるっちゃ。

>>276
違う、そういう意味じゃない。デザインパターンまで実務に使ってる。
キミの言ってることのつながりが全然わからないと言っている。

ゲ技版にもデザパタ馬鹿が出るのか・・・・。

別になあ、今更デザパタでもなかろうに。
つかっててあたりまえだといいたいんだろう？ >>279

Design Pattern for Computer Games
http://www.totempole.net/patterns/gamepatterns.html
こんな試みもあるがね。

とてもヨワヨワな質問でスマソ。
カードゲームを作ろうとしたときカード１枚１枚をクラスとして扱う？
カードの枚数だけクラスが出来るんかな…

>>282
MT:G 系のカードごとにルールがあるカードゲーム？
カードクラスとルールクラスで構成するか、それぞれをクラスにするかだね。
Prototype や Flyweight パターンを参照してみて。
↓だけじゃ分からないと思うけど、参考までに。
http://www.ff.iij4u.or.jp/~ahirusan/Java/patterns/prototype.html
http://www.ff.iij4u.or.jp/~ahirusan/Java/patterns/flyweight.html

さっそくのお答えありがとです。
Flyweight パターンが近そうなので
もうちょっと勉強してみます。

太閤立志伝Iは、オールアセンブラと思われる古いゲームだが
オブジェクト志向してたんじゃないだろうか。
基底クラス武将を継承するプレイヤー武将クラス、大名武将クラス、一般武将クラス。
それらのオブジェクトが家臣団ツリー構造で管理され、
マルチスレッド処理で並列で動いてる。
当時これをつくったひとは本当に天才だとおもう。
ずっと後に出た、これと似たシステムのガンパレードマーチはさんざん自慢しまくってたが。

大抵のゲームプログラマーはとっくの昔に自分でＯＯＰやデザパタ発見してるよ。
本に出てるのは他人に教えても良いゴミテクと知れや。

>>99

例えば、ゲームボーイとか、タイトなパフォーマンスが要求されるとことか、
まぁあったでしょうけど、やっぱ今後は開発効率の向上が必須項目。

例えば、全部組み込みJavaでゲームが書かれるようなことにも数年後にはなり
かねないしさ。

>101
モジュールやデータ構想の勉強っって何ですか？

タイトなパフォーマンスが要求されないゲームってＰＣぐらいしかないんじゃ？
アマですか＞287

>>286
こういうやつよくいるわ。

ま、とりあえず>>286がデザインパターンの存在意義を
理解してないのは分かるわねー。

個人的にはパフォーマンスよりも
開発効率のほうが今後のネックだと思うが。
納期に追われたこと無いの？>288

＋→描画デバイス
＋→シーン＋→キャラクタ→モーション
　　　　　＋→キャラクタ→モーション
なんて風にオブジェクトを階層構造にしてるとき
キャラクタの描画メッセージは、どいつがどのように送りますか？
それとも、こんな構造にはしませんか。

>>286
確かにデザパタ厨房は、
今は物理シミュレーションの時代だとか言ってるゲーハー厨並に痛いけど
（そんなのファミコン時代からやってるって…）

デザインパターン自体には、
昔からの手法に共通の名前を与えるという意義はあると思う。

>>271-272みたいな感じでんな。
プログラマ間の意思疎通がシャア並みに速くなる。

>>293
逆に名前がついてないと頑なに認めないのが一杯居て困る事多し。
１）マルチスレッド的プログラム構造の実際。
２）外部からの通信でどのような状態にも自由に遷移できる構造
３）どのような状態でもメッセージを受け取れる構造
４）正規の処理以外のエラー処理への随時対応可能構造
といった事を教えても「スタイルの違い」と理解せず変更せず、
挙句の果てに人のバグだと言い始める逐次プログラマーの多いこと
多いこと。

それは、貴殿が新しいパターンを作って文書化すればいいのでわ。
GoFとかに載ってるのだけがすべてじゃないよ。

> http://www1.linkclub.or.jp/~zhidao/zlab/
> オブジェクト指向を用いてぷよぷよを作る記事がある。

ウェブページだけ見ていて、ソースはそんなに真剣には見てはいなんだけど・・・。

これはこれで、イイっていえばイイのかもしれないんですけども。
オブジェクト指向の例題とするには納得しかねるなぁ〜。

1)
連鎖発生時の「ファイヤ〜」「ばよえ〜ん」とか、ここはキャラクター
が変わることによってメッセージが変わるわけだから、ここでこそ、
Character クラスでも作るのがイイのでは。

2)
Puyo クラスの中に座標を持っているんですけど、これは
明らかに無意味なような気が。

まぁもし、ぷよ一つ一つが、特別な性質を持っていて（例えば、
赤ぷよだけ５つ繋がらないと消えないとか、黄色ぷよを消すと
回りのぷよも変色するとか）そういうことなら、Puyo クラス
でも作って、自分が存在する座標とゲームフィールドの参照を
持って設計するのが、正しいと思うんですけど・・・、うーん、
ぷよぷよっていうゲームの場合、ルールは完全にゲームフィー
ルド毎に決められてるんだから、べつにint型の二次元配列
でやっても、一向にかまわないと思いますよ。

後は、MVC の分離をきっちりやるといいのかなぁ〜。でもこれも
単純なゲームにおいてはほとんど無意味だからやらなくていいか。

まぁ、ぷよぷよというゲームの本質とＯＯＰはあまり関係ないやね。

Model（ゲームデザインの部分）のコト書いたんですけども、

View（表示する部分）の話でしたら、Puyo クラス書く意味は
大いにありますよね。消すときのエフェクトは、ぷよの色ごと
に違ったりしますから、その Puyo クラスごとに絵画方法を
定義すればラクチン。

ごめん、↑の２つ、ミス

どうでもいいけど語尾の『なぁ〜。』って口癖？

age

んー、ぷよぷよをＯＯ学習のサンプル題材として議論しているのは
分かるんだけど、ベーシックでもできるものなので、題材として
適切かどうかはちょっと疑問だと思うー

「再帰呼び出し学習材料」としてなら、ぷよぷよは好材料だと思うけど。

age
結局、タスクマネージャC++版は、デキなんですかね？

＞デキなんですかね？

どう言う意味ですか？

salvAGE

OOやるならレミングスとかが良いんじゃないかなー。
正直ぷよぷよはOO向きではないよね。

下がってる…。

やっぱり RPG 系こそOOの真価が発揮されると思うんだけど。

というか日常的に考えてシナリオとかプロジェクトというものをOO的に変換して
うまくいかないんだから
プログラムを全部OOでやろうってのがどだい間違いでは？

>>308
じゃあ何ならうまくできるの？
構造化言語？アセンブラ？

速度的な問題点っていうのは別として、
組み方としてうまくいかないって言う人は絶対 OO 解っていない人だよ。

全部OOでやろうってのは非効率的（になることが多い）。

デザイナが書くためのスクリプトがオブジェクト指向だった日には
そりゃもう大変。

>>309
もうアフォかヴァカかと。

とにかく、ゲームプログラミングには適してない。

で、OO否定派で、ゲーム以外の物はOOで作ってるって人はいないの？
そういう人のゲームにOOは(どういう理由で)向いてないっていう意見キボーン。

そうじゃないやつはOO理解できてないだけでしょ？
つまり銀行でCOBOL書いてるやつらと一緒。
やつらでさえ最近はJavaにお熱みたいだから、あと数年でCOBOLer以下になるね、君ら。

>>314
Ｃ言語はそこまでダメじゃないと思うよ。
単純に乗り換えるコストが見合わないってだけだろうね。
その人にとって。ボクにとって。（ぉ

そのうちやるさｗ

>>315
(私以外の)OO派もきっとCとかアセンブラが駄目とは思っていないと思う。実際今までCでたくさんの名作が作られてきているから。

でも、そこには血もにじむような努力があったわけでしょう？
それこそ場合によっては発狂する人が出るくらいの。

そういうの、終わりにしませんか？っていう事です。
OOが解決策になりませんか？って言いたいんです。

みんなが幸せになる技術だと思うから、気づいて欲しい。
一番幸せになるのはプログラマーなのに、そのプログラマーに
「OO使えねぇ」とか、本当に使っても無いのに言われるのは悲しいんです。

でも、たしかに色々な意味で初期コストは高くつきますね…。

OO使いたい奴は使えばいいし、使いたくない奴は使わなければ良いじゃん

ＯＯはプログラム構造の一部しか記述できないんだよ。
＞絶対 OO 解っていない人だよ。
なんて書いてる君こそ判っていない。

Ｃ言語にかけたコストは伊達じゃないので、そんなにＣ＋＋にすぐに
移行したいとは思わない。必要な規模の仕事もあんまりないし・・・。
ウチでは使ってるヤツと使ってないやつが混在してるよ。

根本的に設計が間違っている場合、OOで記述できない構造もあるわな　(藁

プログラム板追い出されたからってこんなとこで吼えるなや。

>>318
煽り…ですか？マジで言ってるの？
OO向きじゃない部分があるのは認めるけど…。

＞ＯＯはプログラム構造の一部しか記述できないんだよ。
これOOをC言語に置き換えて、アセンブラマンセーな人の発言だと思って読んでみるといいですよ。

>>318
そうそうアセンブラじゃないと記述できない部分があるよね。
フルアセンブラまんせー。

そういう意味じゃない。
アセンブラでもＯＯは出来るし。

ああ、言うの忘れてたけど>>316はＯＯ対Ｃみたいに書いてるけど
判ってない証拠だね。
ＯＯは言語によらず使える。
戦略ゲームなんかはＣでＯＯ使ったけど？１０年くらい前か　藁
あと、スプライトはＯＯだな。
でも全部をＯＯ化するのはアフォです。

OO に対する認識が個々違いすぎる

OO 言語派: C++ など OO をサポートした言語を使えば OO である
OO 戦術 派: オブジェクト（敵データ）管理などに OO の考えを使う
一般的 OO 派: OO サポート言語を使用。設計はどうあれ全面的にクラス/継承を使う
OOD 派: UML、デザパタ、RUP や XP の使用が前提

俺は OO をサポートしてない言語でわざわざ OOP する気にはならない。
けど速度がクリティカルじゃなきゃ VC++ で全部 OOP するよ。
その方が楽だからね。

俺は純ＯＯＰＬよりＣ＋＋でファイル分けする方が好きだな。
クラス化するかグローバルで行くかは使い勝手しだい。

＞全部ＯＯＰするよ。

無理。全部クラス化なら可能かもしれないが。

OO 反対派はゲームクリエイターズバイブル読んだ？
ちなみにゲームクリエイターズバイブルは
Game Architecture and Desing の日本語訳本ね。

ようするに漏れのいいたいことは…
・monostate の化け物みたいなクラスしか書いたことないのに「 OO 駄目」とか言わないように。
・80:20 の法則に基づいて、速度にクリティカルな所以外では関数呼び出しのコストを気にしすぎない。
って事かな？

まぁ、一番惜しいのは >> 326 の分類でいう「 OO 戦術派」の人達。
OO のよさが少しはわかっているのに OOPL による強力なサポートをパフォーマンスを理由に拒んでいる気がする。
反対に早く目を覚ませっ！って言いたいのは「 OO 言語派」だね、
漏れも始めはこのグループだったので、あんまり偉そうな事言えないけど、
OOPL 使うのと OOP するのは違うからね。

OOP のよさが始めに解ってくるのは 「インターフェイスに対するプログラミング」が理解できた所あたりかな？
このあたりからポリモーフィズムとか、有用な所が一気に身についてくると思うから。
そこらへんまでたどり着く前に OO 否定に回っちゃ駄目だと思うなぁ。

もうちょっと一派的な方で用語の統一を…

OO　… オブジェクト指向
OOP … オブジェクト指向プログラミング
OOPL… オブジェクト指向プログラミング言語

単にOOするのとOOPLでOOPするのとは格段に違うぞ。と言いたい。

とうとうageちゃったか・・・。
>>328
現場の人間はそんな素人向けの本なぞ読まない。
それ以下の文章は意味不明だ。病院行け。

>>330
あなた >>327 ？
>>327 の発言のがよっぽど意味不明なんだけど。

あなたは素人向けの本だと思ったのかもしれないけど、
本当はあなたみたいな頭の固い人の為の本だと思うよ。

と思ったけど、あんたはまずはじめに「達人プログラマー」から読みなさい。

つーかそれ以前に読んでもない本を初心者向けと言い切るあたりが
やってもない「本当の OOP 」を否定してるって態度をあらわしてるね。

初期コストが問題なだけですよ。コストってお金だけじゃないからね。
最終的にはお金になるんだけどもｗ

やれやれ、ヲタク本列挙して何のつもりなのやら。

諸君、ソフトウエア業界は危機に瀕している。
業界は頭の固い旧世代プログラマーに占拠され、発展の可能性を
失っている。
これら旧世代を駆逐し、ＯＯＰＬを世に広めなければソフトウエア業界
に未来は無い。
立て。若者達よ。
立って諸君らの力でこれら旧世代を駆逐し、明るい未来を切り開くのだ。
日本の未来は諸君の双肩に掛かっている。

みたいなー。
まあ、判りやすくデフォルメするとこんな煽動が
ＯＯＰＬやＯＯの解説で行われているわけだ。
んでもってアフォが飛びついて洗脳される。と。

ＯＯＰＬ登場の理由はたった一つ、旧世代ＰＧの排除であるってことは
みんな分かってるよね？ね？なら若い奴は必至こいて勉強しろって事だよ。
ただそれだけの事にこんなに議論しちゃって・・・。恥ずかしくない？

>>335 さんの発言を見て、なんでゲームプログラマが
OOを嫌うのかわかったよ。

簡単になったら低脳なやつらはクビ切られるからね。
OOが普及するのが怖いんでしょ？

結局ＯＯはインネンつける手段かい！

>>336
低脳かどうかはどうやって判断するの？

ＯＯの理解度で判断します！

自己完結哲学というか、オウムそっくりというべきか・・・。
救いようがないですな。

単純に C より C++ の方が組みやすいじゃん。

　　　　　　ﾋﾞﾋﾞﾋﾞﾋﾞ
　 ∧＿∧　　。））））））））　　∧＿∧　　／￣￣￣￣￣￣￣￣￣
　（　`∀´）／　　　　　　　　（　@∀@）＜　ＯＯマンセー
　（Ｓつ二/)　　　　　　　　　(　　　　）　｜　旧世代を打倒せよ
　｜ ｜　| 　　　　　　　　　　｜ ｜　|　　＼＿＿＿＿＿＿＿＿＿
　（_＿）＿）　　　　　　　　　 〈＿フ__フ

こうしてアンチOO派は論理的反論ができなくなったので
コピペ荒らしに転向しましたとさ。

　　　　　　　　　　　　　　　めでたし、めでたし。

めでたしめでたし

＊＊＊＊＊＊＊＊＊＊＊＊＊　終了　＊＊＊＊＊＊＊＊＊＊＊＊＊＊

レースゲーとかだったら、ＯＯ不要なんだけど。

そうだね。
ゲームを完全ＯＯで組めるとか言ってる人は実際に組んでみればいいじゃんか。
さらに、それで効率上がるなら自分だけ効率上げて待遇良くなればいいじゃんか。
（やったら自滅するけど）
なんで布教活動するのかなあ。

バカのためにわざわざ非OOで組まなければならない
苦労を察してください。

>>345
ＯＯが絶対必要だっていう事は(レースゲーに限らず)多分ないよ。
でもレースゲーだってＯＯならもっと簡単になる可能性がある。

>>346
いいかげんウザすぎる。
本当に頼むから理解してないくせに批判するのやめて欲しい。
というか、逆にきくけどＯＯの何が不満さ？
「ぼくがりかいできないからです」以外の理由をちゃんと言ってよ。

何が効率よくて、何が良くないかが、理解出来てない。俺は。
上手く比較デキンというか、理想系がわからんというか。

メンバアクセス関数を用意するのは、面倒かな？
記述量も増えるし。
設計で余計に悩まされるとも思う。

どのぐらいの納期かで使い分けるのがいいのかな。

>>349
ＯＯの良さって、なかなか文章にするのは難しいです。
肌で感じてもらうのが一番いいと思うんですけど…。
もしあなたがすごく頭がいい人なら、もしかしたらＯＯの良さを
肌で感じてもらうには、途方も無く難しい(複雑な)問題に対面して
もらわなければいけないかも知れません。
私はあんまり頭が良くないので、ＯＯを知ってよかった。と日々痛感していますけど。

うーんアクセッサを書くのが面倒っていう心情はわからなくはないけど、カプセル化は必要だから、これは慣れてもらうしかないです。

設計についてはＯＯが解っていれば逆に簡単になると思います。
ただし一番酷い状態はＯＯがわかっていない人がＯＯの設計をしたときかな？
記述量は…たしかに増えているかもしれませんけど、何度も書き直すのに比べれば確実に生産性はいいはずです。
それに本来混みあって見難くなる部分が逆にすっきりしたりする場合が多いので、単純にキーボードを叩く数では決められない生産性があると思います(まともなプログラマーなら多少鍵打数が増えるくらいはたいした負担ではないでしょう？)。

納期での使い分け…、というのはちょっと違うかな…。
もし納期の単位が一週間から一ヶ月とかいうのでもない限りは。
そんなに納期が短いスパンの仕事なら、わざわざＯＯしなくても
(むしろしない方が)いいでしょう。
すごく小さいプログラム(複雑度が低い)ならばＯＯはそれほど必要じゃありません。
私の心情的には「本当に速度にクリティカルな部分」はＯＯの冗長性が邪魔なので、そういう部分は非ＯＯでもかまわないけれど、
それ以外の全てのコードはＯＯでやって欲しい。と思います。

>>350
禿同
アクセッサを書くのは確かに面倒かもしれないけど、カプセル化の恩恵は
それ以上の物がある。

>>350
そうスか。
ゲームって、そんなに複雑なものでもないと思ってるけどね。
（後、規模的にも）

＞もし納期の単位が一週間から一ヶ月とかいうのでもない限りは。

因みに今やってるのは２日です。（１つの目標に割ける時間）
全体で３週間かな？で、C++で書いてる。

そもそもC++ぐらいしか、現状で実用的な環境にない。てのが
問題なのかもね。

>>351
重要なものに関してはCの頃からやってた。
（「マクロ定義関数用意してるから、それ使え」とコメント付けてるだけだが）
テンプレートもマクロ定義のようなものだよね？
コンパイラが型チェックしてくれるようになった。と。

ＯＯＰは、コピペＰＧの天敵かもしれんな。
漏れの場合、似たようなコードを何度も書きたくない
という理由でコードを共通化してる部分が山ほどあるケド、
そのために、継承をさかのぼって読まないと、
どんな作業をしているかが分かりづらい所があるんよ。

だから、自分に理解できても、他人には理解出来んコードが
少なくないかもしれん。

関数呼び出しを遡っていくのと大して変わらないと思ったり。

ライブラリが複数ファイルにまたがっている事に対して、
文句を言ってる厨房がいたような・・・・

>>343
泣ける…
モナジェクトXとかにして。

OOで効率が悪くなるとか全部組めないとか言ってる人は、どういう部分が出来ないと思ってるんだろう？
>>355は、だしかにそう思う。
ユースケースごとくらいにシーケンス図があったりすると嬉しいんだけどね。
あと、JavaDocみたいなドキュメントをちょこっと書いておくのも重要だ。
C++はDoxygenだっけ？

なお、継承は悪(ただし必要悪)だという事に決まりましたので、
あんまり継承に頼らないようにしましょう。
Template Method とかは別として。

ライブラリ的な部分と利用者部分を分けて考えるのが良いと思います。
ライブラリの中身が実は OO じゃなくても、外っツラがちゃんとした OO っぽく
なっていれば結構ハッピーです。でも意味不明な static 変数やめてね。
(クラスのメンバって意味じゃなくて、関数の中とかのね)

それじゃ！グッドモーニング!!

ポリモーフィズムがOOのキモなのに…

必要悪だから頼り過ぎないように、という話だろう。
経験的にインターフェースと実装の分離の為の継承では
ほとんど問題起きないね。

>>358
あぁ、言葉が足りなかった！
Java 用語で言う interface を継承するのはちっとも悪くないよ。
実装継承を繰り返すのが悪なの。

むしろインターフェイスだけの継承はバリバリ行うべし。
まさしくポリモーフィズムは OO の華。

まぁ漏れはアクセッサくらいはベースクラスに含めてもいいと思ってるけど。
(まともなロジックは入れない)

共通の基本の振る舞いが欲しければアグリゲートする方向で。

まあ、コーダーレベルのＰＧには全てＯＯで行けると思えるだろうね。

じゃぁ、どこが行けないの？

実際に作ってみれば？
ＯＯは
１）処理とオブジェクトをごちゃ混ぜにしている
２）規模が大きくなり、オブジェクト間の処理が多くなってくると
　　クラスが邪魔になる。（ＯＯＰＬ）
３）オブジェクトの無い処理に不向き
４）メモリ上のインスタンス以外をオブジェクトにしようとすると
　たちまち非効率になる。
５）処理だけでオブジェクトが無い場合は無意味。

あ、３）と５）被ってるｗ
５）境界のあいまいな処理に不向き。

例：
Stringクラスは何故Charクラスを継承してないか？

はぁ…。
別にすべてクラス(のメソッド)にしなくても、OOはOOだと思うんだけど…。
(「処理」もオブジェクトであるという見方をしてもいいし)
「全て」の定義を聞きたいところ。
全てのコードをクラス内に入れること？
OOPの話だよね？

あと、>>365はネタですか？
文字と文字列は(国際化とか考え出すと)深すぎるのであまり足を突っ込みたくないけど、
それは違うでしょ。
あぁ、でも、言いたい事はだいたい分かった。曖昧なのはあなたの頭です。

１）処理はメッセージパッシングの流れであらわすのが基本。できなそうなら、全体を制御するオブジェクトを作るのが普通かな？
２）異なる種類の複数のオブジェクトを処理する場合は、STLばりに「処理をする」オブジェクトを作ろう。
３）意味不明。整数オブジェクトは使いませんか？
４）VRAM上のメモリとかに直接アクセスできない場合とかの事を言っている？非効率なのは単純に設計が悪いだけでしょう。
５）曖昧でなくなるまで設計を見直しましょう。

>>361での発言を見ると、チーフか何かなのかも知れないが、
そうだとしたら、こいつの下の人は本当にかわいそうだ。

つーか何だ>>363は？
意味不明。
＞実際に作ってみれば？
これはそっくりそのまま返したい。

それでは問題です。
ライフゲームをＯＯで組んでください。

>>365
あなたの作るプログラムの中で
プログラマクラスが人間クラスを継承する必要性が出たらそうしましょう。
そうでないならやめましょう。
真に汎用的なクラスを作るのは無理なのだから設計者の裁量に任せるべし。

ＯＯ＝クラスと思っている時点でかなり理解が危いのだけど。
ＯＯを貶すなら、少なくともＯＯを極めてからにしましょう。

> Stringクラスは何故Charクラスを継承してないか？

こんなバカ見たことねえ。
くくくくく。
下につく人がいたら本当にかわいそうだな。

じゃ、ブラックジャック。

なんかアンチ OO は反論できなくなったようなので、
そろそろまじめに OO によるゲームプログラミングを語ろうか？

じゃオセロ。

>>375
Chain of Responsibility でどうぞ。

すごい！英語だ！
じゃ三目並べ

こっちに来てくれ給え

じゃテキストアドベンチャー

>>377
まず三目並べのルールをキボンヌ!!
いや、マジで知らん。五目並べの３つ版？

　　○
Ｘ○
○　Ｘ
名前ちがうかもしれん・・・。

>>378
求人票キボンヌ!!
この世ならどこへでも伺います!!

>>381
マルバツゲームじゃん。
つーか、これくらい単純になると、さすがに OO じゃなくても十分でしょ？

>>383
うん。実際に作らなくてもいい。頭の中で組み立てるだけでもＯＫ。
じゃ将棋。

将棋もなー、みたまんまクラス化すればいい気がする。

abstract な chip (駒って英語でなんていうんだ？わからないのでとりあえず chip で)
とその派生クラス群で…。云々。

駒（piece）はＯＯ化できてもゲームはＯＯ化できません。
思考ルーチンは？
判定ルーチンは？
無理すれば出来るけど、決して効率的ではないでしょう。

思考ルーチンは Strategy にすると
プレイヤーからの入力と Com の思考ルーチンを透過的に扱えて素敵だよね？＞ OO 解ってる人

将棋の判定ルーチンって？

>>387
Strategyなぞで問題を先送りにしてどうする？
思考ルーチンこそ将棋のメイン。

判定　勝敗判定

勝敗判定って？王将が取られたかどうか？
Observer で一発じゃん？？

問題を難しいことをする所一箇所にまとめやすくするのも OO の得意技だよん。
正直言うと将棋の思考ルーチンについて詳しく考えた事がないけど
先読みは Memento の変形がいいかな。

あんまり GoF パターン内だけで応答するとデザパタ厨だとばれるね^^;
GoF 以外のパターンを調べに逝ってきます。

ＯＯ厨を叩こうと思ったのにデザパタ厨が引っかかってしまったＹＯ！

>>391
いいんじゃないの？
デザパタ厨 inherits OO厨. じゃない？

つーか叩こうと思った割にはていよく返り討ちにあってる気がThru.

へえー。
思考ルーチンをＯＯで組めないのを示したのにねえ。

>>393

＞ 思考ルーチンをＯＯで組めないのを示した
示して無いじゃん？
どこらへんで示したの？
>>389 への否定意見も出てないし。

つーか
＞無理すれば出来るけど、決して効率的ではないでしょう。
に矛盾してるよ？

なんだかんだ言っても反論がないと寂しいと感じてしまう漏れって一体…。

つーかここ粘着の巣窟だな(藁
ここにいる奴らの誰とも組みたくないと思うのはおれだけか？

まぁOOは気張らず自然に使ってください。

まあ、勝敗判定は良いとして、>>389の後半は反論するような内容か？

>>386
別にルーチンを要素分解してオブジェクト化しなくてもいい。
C++ にせよ Java にせよ C の派生言語なのだから
メソッドの中はある程度手続き的になる。
その辺の匙加減はお好きなように。

複数のルーチンを管理するときに C では関数ポインタを使うが、
たとえば Strategy パターンを使えば言語の機能に依存せずに
同じことを実現できる。

うむ。
９５％はＯＯ使えないと言う結論。

いや、
OOPL は 手続き型言語の 95% くらいは内包しているという結論。

怖がらなくてもいいよ、 今まで手続き型言語で頑張ってきた君達なら、
必ず OOPL も使いこなせるから。

氏ね！>>401

>>401-402
雨の中ぬれている子犬(402)に手をさしのべたら、怯えた目をしたあと噛まれてしまった401。
ここで怒ったりせずに、そのままもう片方の手でなでてやると懐くぞ>>401

>>402
ごめんよ、怒らせる気はなかったんだよ。
漏れはクソ兄弟のおかげで口喧嘩がうまいだけ。
正直いえば、漏れは「使い分け」派。
どっちかについちゃったら、負けず嫌いの性格がでちゃっただけ。

つーか、漏れ本当は 3D 技術とか知らないし、必死に勉強中の未熟者よ。
結構論争楽しかった。ありがとう。

でも、口喧嘩のうまさなら絶対負けないから!!

…唖然…。
冬休みっていつまでだっけ？

そろそろ終わりじゃない？

唖然って、デザパタ用語を適当に並べてる時点で煽りだと判りましたが
なにか？

デザパタ中毒はしばらくはまってると自然治癒するのでもう少し温かく見守ってあげてください。

>>408
先生…。僕、あとどれくらいで治るんでしょうか…？
この症状が成長の途中の、さなぎの時期だってのは聞きました…。

でも、でも！

こんな症状を発症している所を人に見られたら……(*∀*)ﾊｽﾞｶｼｲ

せめてお薬を処方して下さいっ!!

>>409
粘着は個性だから直りません

>>410
冬休みだから暇なだけです。

冬眠は動物の基本。
体と心を休めなさい。
2chから24時間離れると、少しだけ休まった自分を感じる筈。

>>412
2ch を半日以上見ないと禁断症状が出ますがなにか？

余興も終わったみたいですし、仕事始めですし、
そろそろまじめに OO の話をしませんか？

再発したか・・・。
治療法は上のレスで上げたゲームをＯＯで組んで見る事。
細部はいらない。
１）何をオブジェクトとして
２）どんな処理がどのオブジェクトに属するか
３）オブジェクト間でやり取りされるデータはなにか
を書け。

405までずっとロムってました。

冬厨の言葉を使うのは嫌だが、俺も「使い分け派」。
OOの理論だけ振りかざして「素晴らしい！みんな使えYO！」と
布教するやつは愚か。
OOを理解できなくて（というか勉強しないで）「OOは非効率的。
使えねー！」という奴もまた愚か。
ここをロムってた普通の人たちはみんなそう思っているはず。

というわけで、このスレは「ゲームプログラミングにOOは必要かどうか」
ではなくて「どのようにOOを使えば効率的なゲームプログラミングができ
るか」もしくは「OOでどのように構築するか」という風に変更したほうがよい
思うんだけど、どうでしょう？

OOが良い・悪いという議論は不毛。なぜなら良くもあり、悪くもあるから。

長文ｽﾏｿ

とにかく415を実行してみなさい。
話はそれからだ。

どっかに　OOなライブラリつくってる人いる？
いままでC++で作ると、速度度外視の厨房みたいな扱い受けたからなぁ
ベターCとしてのC++程度の物しか見たことない

まぁそもそも公開されてるものなんて初心者向けライブラリだから
簡単なものしかないかな？

>>418
俺作ってるよ。
I/OはTemplate Method StreamにReader/WriterをDecorate
Saver/LoaderはChain of Responsibirity
DeviceはAdapter、ResourceはSingleton
TaskはState,ControlはInterpriter
Vector/Matrix等のPrimitiveはinlineでoperator overwride

業務連絡。
重症患者が搬入されました。
救急担当のドクターはＩＣＵへ。

419見て、まあそんなもんだろと思った俺は一体（；´д｀）

完全に一緒に仕事をすることがない相手に対して、布教活動をお互いに（？）
行っていてもしかたないと思ったり。利用しない人はこのスレを見ないだろう
という前提で、どう利用すべきかに集中した方が意義がありそうだね。
まあ、２ちゃん的にはお祭りの方が楽しいかな？

人は皆罪人です。
悔い改めなさい。

下がり始めてるので誰かネタ振りをお願いします......って言ってもな。

というワケで私がネタ振りを
ライブラリ以外で OO をこんな風にゲームプログラミングに有効活用した！
という自慢話を聞かせてください。

GUIは全部成功（効率↑）。
それ以外は全然駄目！ＯＯ氏ね！

>>425
どういう風にして、どんな失敗をしたの？

1000ゲッドォォｫｫ！！
￣￣￣￣￣∨￣￣￣　　　　　　　(´´
　　　　 ∧∧　　　）　　　　　　(´⌒(´
　　⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
　　　　　　 ￣￣　 (´⌒(´⌒;;
　　　　　　ｽﾞｻﾞｰｰｰｰｰｯ

・・・・・・・・・
￣￣￣￣￣∨￣￣￣
　　　　 ∧∧　　　　　 　　(´;;
　　⊂（ﾟДﾟ⊂⌒｀つ (´⌒(´

ん？・・・・・・・・・
￣￣￣￣￣∨￣￣￣
　　　　 ∧∧
　　⊂（　 ﾟДﾟ⊂⌒｀つ;　(´⌒(´

ﾄﾞｯｺｲｼｮと、・・・・・・・・・
￣￣￣￣￣∨￣￣￣
　　　　 ∧∧
　　　 （ﾟДﾟ ,）⌒ヽ
　　　　 U‐U^(,,⊃'〜... (´⌒;;

任務失敗と・・・・
￣￣￣￣￣∨￣￣￣
　 ﾎﾟ　　∧∧　　ﾎﾟ
　 ﾝ　 （ﾟДﾟ ,） .　ﾝ
　　 (´;) U,U ）〜 (;;).
(´)〜(⌒;;UU (´ )...〜⌒(｀)

↑のように映像のパーツ化は巧く行くけど、他の部分は
パーツ化できるほど仕様が固定してないってこと。
ＧＵＩ以外はサブルーチン群が最強。

>>428
仕様っていうのは？
メソッドのシグネチャさえ固定できれば OO の方が変更は容易だと思うのですが…。
メソッドのシグネチャさえ変更しなければいけないような根本的な部分が変わってしまうのだったらグローバル関数でも全て書き直しだと思うのですが、違うのですか？

>>428
ライブラリ全般はOOの方がいいと思うけど。
I/Oとかデバイスとか抽象化しておくと便利だし。

結論： 慣れている方法を使え

OOPLとOOを混同しとるらしい>>430

>>429
変更したら部品にならん。

>>432
いや、だからすげ替えるんでしょう？
「抽象的部品」を定義して、
「具体的部品 : 抽象的部品」を作る。
この「具象的部品」を「抽象的部品」として扱っていれば、
「別の具体的部品 : 抽象的部品」に置き換える事ができる。

しかも「サブルーチン群」だったら仕様が変わっても対処できる
という発言の理由は言ってないですよね？

愚推しますが、「サブルーチン群」を使っても、仕様に変更が
あった場合はコードを大量に書き直さないといけないと思いますが、
違いますか？

私が言いたいのは上記のような場合、OOPL ならば
作成するインスタンスを変更するだけで済む場合がほとんどだ。
という事です。
どうでしょうか？

部品は小さければ小さい程、変更の可能性は小さくなります。
機械の仕様が変わってもネジを手直ししなくて良いのと同じです。
メソッドをバラしたような、部品化されたサブルーチン群は変更の可能性が
大変小さいです。
それに変更はモジュールに有るのではなく、モジュール間の関係や操作、初期値
などが多いのです。
結果として、ＯＯＰＬでは再利用率が下がります。
Ｃだと７０％−９０％の再利用率を保っていましたが、ＯＯＰＬに切り替えてから
２０％を切っています。

>>434
Ｃ言語のスキルが高いが、ＯＯＰＬはそれほどでもないってことだね。
Ｃで続けた方がいいんじゃない？

煽ってんのか？

コピペ再利用なら、CもC++も関係なく高い再利用率を達成できそうだね。

>>434
> メソッドをバラしたような、部品化されたサブルーチン群は変更の可能性が
大変小さいです。
小さな部品は、対象が基本的な変数型じゃなければ(インスタンスではなく)クラスのメソッドに。
クラス名が明示される状況なら inline が有効なので呼び出しのコストもかかりません。(そのかわり多態性もない)
もっと局所的な場合には private/protected なメソッドという方法もあります。
これも呼び出しのパフォーマンスが気になる場合は inline するようにできますし、
気にならない状況であれば virtual にしておけば Template Method パターン
等を使ってトリッキーな処理ができる場合があります。

> 変更はモジュールに有るのではなく、モジュール間の関係や操作、初期値
などが多いのです。
434さんのおっしゃる「モジュール」の定義がよく理解できないので、
ちゃんとしたレスは書けないのですが、要するに根本を揺るがすような
変更がままある。という事でしょうか？
あと初期値に関しては埋め込まずに外部リースにしましょう。
これは OO かどうかとか関係なく、当たり前の事だと思うのですが…。

> Ｃだと７０％−９０％の再利用率を保っていましたが、ＯＯＰＬに切り替えてから２０％を切っています。

この数字はどういった計算で出されたものでしょうか？
ちゃんとした数字だとしたら、 >>435 さんの言う事も、あながちただの煽りとは
言えないかと思います。

煽ってはいないよ。オレもＣ言語のが得意なのでＣ＋＋を使いたいやつが
チームにいるときでもＣで頑張ってたよ。頑張りどころが違うのかもしれないけど。
ギリギリの納期だったりするので、Ｃ＋＋に進むタイミングがなかなか。
次回のプロジェクトか、ターゲットハードが新しいものになったときでも挑戦しよう
かと思っているけどね。便利だろうなぁとは思うよ。
あと、ＯＯＰＬとＣ＋＋って一緒でいいんだよね・・・？（ぉ

>>439
> あと、ＯＯＰＬとＣ＋＋って一緒でいいんだよね・・・？（ぉ
ゲーム業界では一緒でいい気もしますけど...一般的には違う気がします。
私的には OOP に慣れてないうちは C++ よりも Java とか C# みたいな
単一継承で複数インターフェイス実装の OOPL をオススメしますね。

>>434
＞Ｃだと７０％−９０％の再利用率を保っていましたが、ＯＯＰＬに切り替えてから２０％を切っています。

熟練度90の構造化言語での開発技能の成果と
熟練度 5のオブジェクト指向開発技能の成果を比較しても
意味があるとは思えません。
まぁ、熟練度が本当に数値にできない以上は明確な事は言えませんがね。

熟練度が低い＞経験が浅い＞そんなにコード書いてない＞再利用しようがない
て事？

実相継承を使ってみる。Cの遺産が使いにくくなる。
STLを覚える。Cの遺産を使わなくなる。
インタフェース継承とデザインパターンを覚える。それまでのコードを使わなくなる。
templateを使ったGenericProgramingを覚える。それまでのコードを使わなくなる。

燃やすまい、日本の遺産、地球の遺産。

>>443
熟練者ですか？（自分が経験激浅）
ぶっちゃけた話、どういう構造がベストなんですかね？

今のメイン組んでる人は、あるシーン用素材を元に、
必要なオブジェクトをどんどんnewしていって、
ヒープへのポインタをオブジェを管理するクラスが持つvectorに
pushしてく。
アニメーション関係はコンテナ化されています。
プリミティブ、モデル等はベースクラスから派生してて、
Render等のvirtual関数でそれぞれのCpu処理,描画処理をする。
て感じです。

難点は、殆どの処理が自動化されてて、テスト的な処理をしたくても、
シーンの素材ファイルを読まないと何も出来ない。
シーンはストリームで読み込んでて、手動で自分が作ったオブジェクトを
作る時等、初期化手続きが凄い面倒。等

STLはlist,vectorぐらいしかつかってないなあ。

・・・・・・・・・だから、資源は大切に。

PC 向けだったら資源は浪費できるでしょ

わかってそうでわかってない人が夢見がちな幻想として
「ＯＯＰ＝即座に開発効率が上がると思い込む」
というのがあるのだけど。

ＯＯＰはその前に痛みを伴う。初期の設計に欠点があれば
設計が見なおされるまでその禍根は残る。
設計が完璧になればその再利用性は飛躍的に向上するけど
問題はそのコストを支払い、堪えられるかということ。
それでもかまわないという男気あふれる者にこそＯＯＰは
ふさわしい。
（Template Method で実装を切り離せば良いって
いう話ではなくて、より構造的な問題。）

GenericProgramingのいい資料ってない？

>>449
Ｍｏｄｅｒｎ　Ｃ＋＋　ｄｅｓｉｇｎ／アンドレイ・アレキサンドレスク
今この本を注文しているんだけど、変態っぽくてなかなか良いらしいぞ。

でも、普通にプログラミングやってれば、3割〜5割(場合によっては祖霊所)は無意識にOOしてるよね？
だから、べつにOOが良いか悪いかとか言う必要も無いと思う今日この頃。

認めたら最後、言語変更が行われてしまうという罠。

>>451
単純にオブジェクトの寿命と接続の関係が整理されるだけでも、
確実にプログラムの堅牢さも作業効率も上がる。
職業プログラマは大抵経験則的にそれを分かってるし、OOP言語を用いなくとも
自前のルールでそれを実装してすらいる。
通常、OOP的アプローチが足を引っ張る状況の全ては「学習不足」に起因する。

ただ、実際の開発行為は、ほとんどの場合常に自身の学習不足と向き合わなければならないわけで…。
既に分かりきったハードで慣れ親しんだ機能を実装する「答えが見えてる」場合はともかく、
学習を伴う開発行為（出たばっかの新ハードを扱うとか）で、アプローチの仕方がわかんにゃい場合、
出だしがやたら遅くなったり、一日紙の上だけで悶々としたり、傍から見てると遊んでるようにしか
（本人苦しんでても）見えないという罠や、最初のアプローチの仕方を間違えると、その遺恨を
いつまでたっても残してしまうという罠も。

>>445
STL は俺も普段は vector と list だけだ。
ツール類なら、string iostream なんかにも出番が回ってくる。
一時期 map も使ってたが、この連想マップがベタな比較コードに勝る
速度を出したことが（経験上）ないので、最近は出番なし。

一度Ｊａｖａで組んでみろ。
話はそれからだ。

>>453
罠んところ読んでると泣けてきた。

>>454
GCのふん詰まりを恐れて
オブジェクトがnewできない＆クラス分けできない罠に陥ります。

>>456
インクリメンタルGCと言うものがあるのだよ

>>457
なんだよそれ。参照カウンタＧＣのこと？

>>458
ちょっとづつ断続的にGCしていくやつのことでは。
まとめてGCするのと違って長時間のふん詰まりがない

世代別GCも注目できる技術か？

タスク処理って結局、C++で再現出来るんでしょうか？
考えてみたんですが、やっぱり、関数ポインタ＋（実体）ワークでないと駄目な気がする。

理由としては、
関数の切り替えがクラスのポインタだと、別途newしておく必要がある。
てことは、１００個のタスクの中身が、全部A、全部Bという状況だと、
A,Bともに１００個ずつクラスをnewする必要がある。
て所で詰まりました。

俺の知らない良い、解決方法があるんですかね？やっぱ。

>>461
デザインパターンマンセー的にはflyweightパターンが適用できると思われ

ＡＢ行き来するときに、delete、newすればいいんじゃないの？

>>462
デザパタはまだ調べてないです。
どういったものなんでしょうか？部分的にでも教えてくだせい。

>>463
それって、OKなんですかね？CPU負荷とか。
自分はやったことがないです。（ゲーム中にnew/delete）

>>461
それならメンバー関数を関数ポインタを登録しようよ・・・。
つか、Aクラス、Bクラスをメンバに持つCクラスを作って
Cクラスで切り替え管理とか。そゆいみじゃない？

　詳しくは割愛するけど、テンプレートを利用するとCに戻れな
くなるぐらい完璧なタスク処理が実現できるよー。

>>445
それ今うちで作っているライブラリの仕様と全く同じだよ。
その難点はそういう仕様がそのライブラリに無いのが原因だから、
つけてもらえばよいさ。

>>465
>Cクラスで切り替え管理とか。
うーん、具体的には、どうやって切り替えをするのかわからないです。

テンプレートですか、、。
あれって、大雑把に言うと、引数の型チェックしてくれるマクロ関数
ですよね？
taskクラスをテンプレートで作って、taskが使用するリソース
（GraphAPI,SoundAPI,,,等）クラスを引数で渡す。て感じですかね？
ヒント下さい。

>>466
そうすか、、。
ウチは、安くてプラグイン書きやすい３Dツールで吐き出すのを
前提にしたライブラリだと思います。多分

タスク処理って
A)優先順位をつけて、処理を割り振る機構
と
B)処理を割り振られた方が状態を遷移させながら仕事をこなす
のと二つがセットなんですね。
私は、A)だけがタスク処理だと思っていた。

で、B)の書き方ですが、以前のC++で書いていたプロジェクトでは
状態を整数で持っていて、switch文で切り換えていたね。
#全然、オブジェクト指向じゃないな。

>>467
　うんと、テンプレートの方はとりあえず忘れて。きちんと理解
できた時に必然的に解るとおもう。

　で、下のモデルみたいな感じにすればいいとおもうんだけど。

taskC
{
public:
void changeA(){ pTask = &m_TA; }
void changeB(){ pTask = &m_TB; }
private:
void Exec(){ pTask->Exec(); }

task* pTask;
taskA m_TA;
taskB m_TB;
}

まぁ、これでもいーんだけど

void Exec(){
switch(m_Mode){
case 0: m_TaskA.Exec();break;
case 1: m_TaskB.Exec();break;
}

恰好良く書くなら、
一つの抽象クラス(A)を継承して、関数に相当するクラスを書く。
一つの抽象クラス(B)を継承して、実体ワークに相当するクラスを書く。
Aに、Bへのポインタを引数にとるapply()関数を実装。
Bに、Aへのポインタとexecute()関数と、change_state()関数を実装。
# あっ、ややこしいね。確かに。

あぁ、そういえば、メンバ関数への関数ポインタを使えば
楽なのか。
#おすすめしないけど。

なんか話が思いっきりループしてるよーな気がする。
スレの最初のほうをご覧ありたし。

俺、仮想関数テーブルのポインタ直接書き換えてるよ。
インターフェイスクラスを多重継承して、
自前の仮想関数テーブルへのアドレスを上書きする。
C++の仮想関数と、Cの関数ポインタをオーバーヘッドなしに両立できる。

プロファイルしろｳﾞｫｹども

>>474
メンバ関数ポインタを使えばいいだけ、という気がするが。

>>474
実装継承が絡んだ場合、this にオフセットをかまし忘れて死にそうな予感。

>>476
関数呼び出し方法はあくまで、C++的にしたいんですわ。
メンバ関数ポインタコールをインライン関数でラップする方法もあるけど、
仮想関数としてはつかえんでしょ。

>>477
だから多重継承を使うの。
最初の４バイトは実装継承用の仮想関数テーブルアドレス、
次の４バイトにオーバーライドするアドレスをマッピングする。
スーパークラスの仮想関数の数に影響されずに上書きできる。

>>478
仮想関数へのポインタを取ることは可能だけど、そういう話じゃなくて?

実装継承の話は、

class Deriv : public A, public B
{};

と定義されていた場合、Deriv 経由で B のメソッドを呼び出すときにはメソッドに渡す this ポインタは
Deriv::this では NG だって話と思われ。コンパイラの実装によるけど、たとえば Deriv に A, B のサブ
オブジェクトが順番に並んでる場合には

　reinterpret_cast<char*>(Deriv::this) + sizeof(A)

を this として渡す必要があるよね。

>>479
まあコンパイラの実装依存ですが、

class Deriv : public A, public B
{
int a;
};
の場合、

virtual table address A
virtual table address B
int a

とマッピングされるので、
virtual table address B
の部分を独自の関数テーブルへのアドレスに書き換えてやれば可能かと。

Bのインターフェイスを渡すときは、
this + 4とされているので、Aのサイズに依存はしないはず。

>>478
ハックくせー…つうか、明らかにC++の言語仕様上でやる意味ないぞ？そんなの。
単にシンボル解決の問題みたいだし、やはり>>476が順当だろう。
スレの主旨的には邪道の極みだと思うが、どーさ。
煽るつもりじゃないのでsage

>>481
趣味でやるなら止めないが、仕事でそんなコード出してきたら肩を叩かせていただく、ってところだな。
ま、コンパイラの吐くコードを探りつつ、いろいろやるのは面白いことは面白いよな。

参考文献
Inside the C++ Object Model

>>482
ゲームプログラムでは必須のテクだと思うぞ。
関数ポインタの使い勝手と、Ｃ++の便利さの両方を享受できる
画期的な手法。

もし移植性を高めたいなら、
仮想関数テーブルのアドレスをインスタンスメモリ内から検索してやればいい。

class B;
int adr = *((int*)&B);
int* src = ((int*)this);
for (int i=0;i<sizeof(this_class);i++){
if (adr == src[i]) src[i] = overwride_address;
}

んー、なんかオレ的にC++で安全面、速度面、使い易さ全てで
不満の無いタスクシステムは完成しているのだが、どーも、生成
時の記述だけ異常に複雑になるんだよなー。

　なんかよさげな方法で実装している人いる？

>>483
画期的っていうかswitch分で処理分岐するのじゃダメなの？
コンパイラのコード的には似たようなもんだと思うけど。

>>485
まぁ、人間たまに「俺は天才なんじゃないか」って思うことがあるから、落ち着くまではそのままに
しておいてあげるのが良いかと。

>>485
switch分岐はオーバーヘッドが大きいでしょ。
１、ステートのフェッチ、
２、範囲チェック×２、
３、ジャンプテーブルのフェッチ、
４、ジャンプ

仮想関数テーブルのオーバーライドなら、
コストは仮想関数を直接呼び出すのと変わらない。

コンパイラのコード的には別物です。

>>486
おいおい、折角貴重なノウハウを享受してやっているのに。
お前もちょっとは有益なことを書き込めよ。

>>487
つか、ワークシステムにおいてそのオーバヘッドがどれぐらいの
ネックになるのん？１Sync内に１０００個もワークは生成しない
しょ？まぁ技術論的には面白いが。

>>487
default文の無いswitchは単純なJumpTableにコンパイルされるけど。

>>489
まあワークシステムのUpdate程度の用途であれば
オーバーヘッドの差は微々たる物でしょうね。
どちらかというと、new/deleteなしに、
Stateパターンを適応するのが本来の目的なのです。

>>491
前にも誰か書いてたが、なぜ関数ポインタを使わないんだ？　C++ だと仮想関数へのポインタも取得
できるから、それで何ら問題ないと思うんだが。

>>490
それは有り得ません。
なぜなら、例えdefaultがなくとも、
変数が必ずcase内の値を取ることが保証されない限り
範囲チェックは必須だからです。
switch(a){
case 0:break;
case 1:break;
};
という構文において、aが0と1の値以外を取らないことは、
静的に保証できません。
まあ、
switch(a&1){}
とすれば最近の最適化コンパイラならdefaultを省略してくれるかもしれませんが。

>>486
ハイハイ。ＰＳ２だかＰＣは偉いね。

>>492
外部からクラスメンバを呼び出すとき、
unknown->Method()
としたいからです。

switch使ったらライブラリ化できないでしょうが。

>>495
それは、単純な転送関数を書けば良い気がするけど。たとえば、下のようなコードと比較して得失は
何なんでしょ？

> 仮想関数としてはつかえんでしょ。
これなのかなぁ。

struct State
{
　　void exec1() {}
　　void exec2() {}
};

class Foo
　　: private State
{
　　void (Foo::*pMethod)();

public:
　　Foo() : pMethod(&State::exec1) {}
　　void method() { (this->*pMethod)(); }
};

int
main(void)
{
　　Foo foo;
　　foo.method();
　　return 0;
}

>>478でも書いてるけど、ようはmethodを仮想関数にしたいわけです。
methodを仮想関数にすると、インライン展開できないので、
関数コール分のオーバーヘッドが増える。
この両者を解決するのが仮想関数テーブルアドレスの上書きであるということ。

もはや日本語じゃなくてC++で話した方がいいような気がしてきた。

ジャンプテーブルの参照なんて、どう組み込んでもおんなじじゃん…
直接vtable書き換えるようなオバカな真似してどうするのさ。
それはコンパイラ提供側の仕様に依存しているという最悪の選択肢。
正直、仮想関数のオーバーヘッドが気になるレベルの性能が必要なら、
もっと別の解決法を考えた方がいい。

仮想関数の機構は、基底を同じくするクラスの多態性を実装するためのものなんだから、
状態別でアッパーキャストするならまだしも（これだってクラスの内容によっては
何が起きるか分からなくなるので、実装依存もいいとこなんだが）、正直その使い方は
およそ賛成しかねるなあ…。


あと、直接関係ないネタだけど。

>methodを仮想関数にすると、インライン展開できないので、

これは多くの人が誤解していることだけど、実際に仮想関数がvtable経由で
コールされるのは、アッパーキャストが絡むときのみ。
わざわざ vtable を辿らなくてもコール先が自明な場合、コンパイラは直接
関数を呼び出すコードを生成する。
inline virtual なんて、珍しくないよ？

煽るつもりじゃないのでsage

sage忘れた。
500ゲットに免じてご勘弁。

>>500

＞実際に仮想関数がvtable経由でコールされるのは、アッパーキャストが絡むときのみ。

まともに OOP してるなら、ベースクラス通して使う事がほとんどだと思うのですが…。

書いた後に誤解を受ける文章だと気づいた。

私も vtable 書き換えなんて、よっぽどの事でもないかぎり反対です。
というかゲーム業界のプログラマって、過酷なターゲットいじり過ぎて
「まず速度ありき」なのはちょっとマズイ状況だと思う。

最適化は最後の作業ってのはソフトウェア業界の常識だと思いますけど、
そこらへんは皆さんどうお考えですか？

まず速度ありき
速度の前にコード無く、コードの後に速度無し。

速度を考えるなら、まずはアルゴリズムの最適化

>>503
まず、モジュール化ありき。

ボトルネックになる部分はほんの一部に過ぎない。システムを詳細な、依存関係が少ない部分にばらして
おけば、ボトルネックを見つけて改良するもの楽。（後からアルゴリズム差し替えようなんて話は、それこそ
クラスをきっちり分けてモジュール化してないと、危なくて出来ない）

>>504
確かに、コードを一行も書かなければ最速だわな。（違う?）

>>503
まともなゲームプログラマは、
Ｃ++のコードみた瞬間にアセンブリコードが浮かぶので
無駄だらけに感じるのだろう。そっとしておいてやれ。

「最も速いプログラムは何もしないプログラム」ってやつか？

バグのないプログラムもね（ｗ
しかし、vtable書き換え……俺もやめようよそれは派だな。
Cみたく完全に枯れた言語ならともかく。

>>508
その無駄ってのも顕微鏡で覗いてやっと分かる、みたいな
もんだしな。これからの時代はそういう人達をいかにｼｶﾄして
作業するかが問題になってくる。ん、時間が経てばいなくなるか（ｗ

>>511
ウイルスも何十万集まれば風邪になるってね。

ネタとしては面白くないし、比喩としては本質を掴んでない。

あのー。ム板ではＣ＋＋なぞＯＯＰＬとは認められて無いようなんですが・・・。

>>514
どこでそういう結論になっているのか教えてちょ
SmallTalk以外は認めない、とかかな?

俺に聞かれてもわからん。

>>516
おいおい（ｗ　少なくとも C++ 相談室スレでは C++ 使って OO な設計する話で盛り上がってたぞ。

C++相談室 Part4
http://pc.2ch.net/test/read.cgi/tech/1009071535/

最近は
http://www.amazon.co.jp/exec/obidos/ASIN/4894714353/ref%3Dsr%5Faps%5Fd%5F1%5F1/249-8109842-4582733
こんな本も話題だったような

>>511
禿同。

>>515
514じゃないけど、Ruby関係のスレとかでは名文句「C++なぞ問題外」
って言われるね。漏れも(万が一)環境が許すならば C++ よりも Java や C# で逝きたい派だけど。

再利用の極意はクラスにあらず。
ファイル分けに有り。

>>519
Rubyの煽りは敵を増やしただけだな。
RubyもOOPとしての完成度は低い。たかが一言語としての立場を
わきまえるべきなのだが。作者がそんな厨だからスレが荒れるんだよ。

ていうか、rubyをゲーム制作に利用しようとしているドキュソな
言語ヲタな時点で激しく逝ってると思われ

>>514-517
Stroustrup先生自身がOO言語じゃないって言ってなかったっけか？
俺的にはOOも可能なてんこもり言語。

>>521
>RubyもOOPとしての完成度は低い。

どのへんが？

Rubyは結構いけてる言語で、プログラムの側からスクリプトとして呼ぶこともできるのでゲームに応用できなくもない。
しかし、以下の欠点からRubyが使われることは将来にわたっても無いだろうと考えられる。

1:UNIX系生まれなので、@や$みたいな記号に重要な意味を持たせている(Win育ちには読みにくい)
2:実績がない。Python使ったスクリプトや大規模プログラムはいくつか例が見られるが、RubyではせいぜいがCGIで、後は誰も使わないライブラリや技術的テスト物ばかりが大量生産されている。
3:コミュニティがC++を蛇蝎のごとく嫌っている。PythonはC++とのブリッジとなるライブラリがいくつか存在している。

OO的にはどうなんかな? 上記2のように大規模プログラムが全然存在していないので、あまりありがたみを感じられる事例が存在していないだけのようにも思う。

Rubyの話は終了しましょう。（；´Д｀）

コンソール機用の C++ コンパイラって、どの程度の物なの？
PS2 とかは GCC って聞いたけど、それ以外は？

そっち系の方教えて下さい。

gcc以外？
ゲームでは見た事ないなあ。
ＰＣならＭＳ−Ｃか。

CodeWarrior

>>523
C++ は

- 手続き型プログラミング
- データ抽象
- オブジェクト指向プログラミング
- 汎用プログラミング

など、複数のパラダイムを支援する言語。OOPL としてみればメタクラスが無いとかクラスが FCO では
ないなど「中途半端」な面もあるが、現実の要求に則してうまく仕様を取捨選択してある。使いこなせば
強力な言語。

っつーことで。

>>528
VC じゃなくて MS-C なのか?

いや、俺は XBOX は触ってないから知らないんだが。

コンソール機用＝CUIだと解釈したが？違う？

>>532
その昔、VB1.0という恐ろしいソフトが存在したそうな

>>532
ああ、それは勘違い。

ゲーム関係でコンソール／コンソールボックスといったら、いわゆるゲーム専用機のこと。汎用
の PC や Mac なんかとと対比しての呼称ね。

ヲタ用語なぞ知らんな。

>>533
そのソフトはどんな悪さをしたの？おじいちゃん。

>>535
ヲタ用語か?　海の向こうだと割と使われてる気がするが。

っつか、話が OO と関係ないな。終わらそう。

OO の冗長性がどこらへんでボトルネックになるかっていうのが
判断できないと、勇気をもって OO できないね。

で、結局パフォーマンスを気にしすぎてセコセコした設計をすると
OO のよさが活かされずに「 ゲームは特殊なんだよ。」みたいな
結論に達する厨がいる。と。

>>538
だからＣ＋＋以外で組んでから言えつうの！
死ね！

＞結局パフォーマンスを気にしすぎて

死ね！

>>538
> で、結局パフォーマンスを気にしすぎてセコセコした設計
設計段階からパフォーマンスを意識する必要は、最近はない気がするなぁ。とりあえずプロファイラ
かけてからモノをいえ、に一票。

>>538
少なくともPS2の場合だったら、
クラスのサイズが大きくなりすぎない事に注意すればいいだけ
だよ。

はいはい、ＰＳ２以外のプログラマ―はセコセコした設計をする厨房
だと言う事だね。

死ね

これはもう、ＯＯの布教というよりＯＯヲタが周りを見下しに
来てるだけですね。

＊＊＊＊＊＊＊＊　終了　＊＊＊＊＊＊＊＊

で、結局、ゲーム業界での、C vs C++ の割合ってどの程度なの？
自分はps2でC++使ってる。
未だにC使ってるところが信じられない。Cを使う理由ってなによ？
C++に反対しているオヤジってさ、PS1の時も、Cに反対していなかったっけ。
要は向上心が欠けているだけの人間なんだろ。（当時のオヤジどもが
今ではCにゾッコンで、C++移行へあれこれイーワケつけてる。まぁ
既に引退してイーワケすら聞こえないケースもあるだろうがﾜﾗ）

チーム内にC++知らねーヤツいると、足引っ張るんだよね。
よりによって、年上なセンパイだったりするから扱いにくくてよぉ

あ、そうか、ゲームにはps2以外のもあったね、そういえば。
まあps2以外のゲームプログラマーなんて糞だし問題外でしょ。

出川さんご苦労様です

>>543
XBOX, GC あたりも、何ら問題ないと思われ。

i-mode は厳しいな。GBA とかは使ったこと無いから知らん。

>>543
ターゲットは何でもいいけど、プロファイルは取りましたか?

>>544
少し、実のありそうな話を。

C++ が C より遅いって話に関しては、多くの場合「間違い」。非仮想関数の呼び出しに関しては、
それがメンバ関数だろうがリンク時に静的に解決されるから

　C の関数と同じ

だし、仮想関数も C で同等なことをやろうと思ったら

　コールバック関数を使う
　switch - case で分岐

どちらかになるので、パフォーマンスは変わらん（ただし ADT を使うのか、仮想関数を使うかとい
う設計の選択はある）。


このあたり、実際に C++ がどういうコードを吐くのかを知れば雲散霧消する誤解だと思うな。C++
が裏で何をやってるか分からないから不安だって人は

　Inside the C++ Object Model
　Stanley B. Lippman
　Addison Wesley

を読んでみることを薦めとく。

>>549
死ね！

「Ｃ＋＋は何かと遅い」というのは迷信ではない。
Ｃ＋＋に移行できない不勉強なやつらが適当な理由材料をでっち上げたもの。
だから、相手にするな >>549

あ、ちなみに、俺は551の「死ね」と書いた短小野郎ではない。

　　　　　　　　　　　　 , -‐､　　　, -.､
　　　　　　　　　　　／ 　 ﾉ　　ノ 　 ﾉ
　　　　　　　　　　/　､_.ノ　.／ ､_.ノ´
　　　 　 　 　 　 /　　ﾉ　／ 　 .ﾉ　　,,-‐'⌒i
.　　 　 　 　 　 /　__ノ / /⌒ｉi´　／､_　 .ノ´.
　　　　　 　 　 l. 　 `ｉﾉ /　 / |／　　,.'~´　　.
　　 　 　 　 　 | 　 ,,,|./ ｀`´.丿　､_ノ ,-‐'´⌒)
.　　　　　　 　 l.　 　 |｀`'''　/　　.ﾉ ./ 丶,-‐'´
　　　　　　　　|　 ,___l　　 　|､.　/ /　､,,/
.　　　　　　 　 |　　 ﾉ 　 　 | ｀` '´-､ ,ﾉ
　　　　　　　　 |　_/　　　　|` ‐､__ 　 ）　　　　>>Ｃ言語信者を軽く流さないでぇー
　 　 　 　 　 　 | /　　　　　ヽ-､ _￣`|
　　　　　　　　　| .　　　　　　ヽ::::.｀ ､,|
　　　 　 　 　 　 | :.　　　　　　 |::::　　|
　　 　 　 　 　 　 | :: 　　　　　　|::::　 |.
　　　　　　　　　 λ:::　　　　　 ﾉ::　丿
　　　　　　　　　/　　　　　　,　::::::'/　　　　　　 　　　　　　　　　＿＿
　　　　　　　　/　　　　　　:/:::::::::/　　　　　　　　 　　　　　　／ヽ　　ヽ―― ､
　　　　　　　/　　　　　　::/:::::::::/ 　　　　　　　　　　　　　　/　　|　　　|　　　　＼
　　　　 ＿/　　　　　　 :::::::::::::/＿＿＿＿＿＿＿＿＿＿/ 　　|　　　|　　　　　　ヽ
　, -‐´　/　　　　　　 ::::::::::::::/　　　　　　　　　　　　　　　　　　/　　 /　　　　　　　 ヽ
（,　 　 /　　　　　　　:::::::::::::/ 　　　　　　　　　　　　　　　　　　/　　/　　　　　　　　　｜＼
　` ‐- ＿＿＿＿＿＿＿ /＿＿＿＿＿＿＿＿＿＿＿＿／＿＿＿＿＿＿＿＿＿）　 ）
＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

なんかPS2とC++しか世の中に存在しないと思ってる人がおられるようで
・・・。

>>554
XBOX, GC, PC もあるけど。っつか実際に C++ だと困るプラットホームがあるなら、実例挙げて反論して
おけばいいじゃない。

iアプリは Java だし、メモリ厳しいからバリバリに OO ってわけには行かないのかも知れんが、俺はその
辺は知らないのでパス。

煽りなのかマジなのか判らん・・・。
マジレスすると、世の中にはgcc以外しか使えないゲーム開発環境が
一杯あるし、また、C++以外のOOPLも一杯有る。
さらにOOPLでないとオブジェクト指向が出来ないかのように
書いてる（ネタ？）けどもちろん違う。基礎の基礎だな。
そんな基本的な知識も無くOOを語ってるのはなんなんだろうか・・・。
ネタとしては面白くないし、天然だったら痛すぎるし・・・。

>>556
> OOPLでないとオブジェクト指向が出来ないかのように書いてる（ネタ？）けどもちろん違う。
不可能ではないが、現実的にはメリットが無い、で結論でしょ。

インターフェースを多重継承したときに、手作業で this ポインタ相当のデータのオフセットを
計算したりするのは現実的には無理だって。（そんな汚れ仕事はコンパイラにやらせておけ
ば良い）

ps2 gc x-box どれもCを使う理由ない思われ。
i-mode？そんなの知らん。新人研修の餌には丁度いいかもね。

> また、C++以外のOOPLも一杯有る。
ゲームプログラミングに限定すると、実際に使える言語は限られると思う。SmallTalk とか Eiffel
でゲームを書ける環境って、そうそうないと思うぞ。

>>558
あとは携帯ゲーム機かねぇ。俺は関わったことないから知らないど。

（スペックだけ見るに、初代ゲームボーイあたりだと辛そうだということは想像がつく）

お疲れ様です、豊島です。
その後、多少の差し替えが発生いたしましたので
ご連絡さしあげます。

--- cut here ---
dfjdsjfjsdjodsfjpodsjfosjdopjopsfjgosjogprloijfdopgpo
uigdfsgdfhjewudsglkrsisroigthlfglgjklfgfjgkrlhrjkrgdf
ihsifghdifdfhwpwer64i4lvfkfsl;mfldwormldsg:e[rpri03df
sdgf]erlkelkrekgf@gf[:adfnkei458932743kj;lgf;f^fg04kd
ksdfhrriouhtriuiufdifir9r094oka:fglkjflkjasgpoijhjrtg
oirihigfohfoigitfofpofggklreht4340afdkojfj040-ikgflkj
dfoehrkekhfg9404-dflmlgf90gufnoihfkngiohoidioroijt000
0000000000000000000000000000000000000000000000000000e
--- cut end ---
となりました。添付にしたかったのですが、サイズが小さかったという
ことでご勘弁 (^^;

とりえあず、初期化変数のクリアタイミングを若干調整しました。
以上の件、よろしくお願いいたします。

＞（スペックだけ見るに、初代ゲームボーイあたりだと辛そうだということは想像がつく）
初代ゲームボーイをアセンブラで開発しているメーカは
皆無で今はＣ言語が主流。
アクションなどが主流なＰＳ２とは違って、データベースアクセスが
頻繁なRPG,SLGなどのジャンルが多いゲームボーイの方がむしろ
ＯＯＰの必要性が叫ばれているが、C++の気配は流石にないままGBAへ
世代交代。

もっともＣ言語でやれなくもないんだけどね。規模的には

＞初代ゲームボーイをアセンブラで開発しているメーカは
＞皆無で今はＣ言語が主流。

出鱈目だな。

なんか新米PGか同人ヲタが粋がって、電波知識を披露してるみたい・・・。

>>563-564
実例を挙げろとは言わんが、も少し具体的に書きなよ。

＞なんか新米PGか同人ヲタが粋がって、電波知識を披露してるみたい・・・。
あれ、君はＧＢ未経験？
↓ここにフリーなGBDKの日本語ページがあるよ。
http://www.geocities.co.jp/Playtown/2004/gbdk_j.htm
GameBoy用のＣコンパイラの原作者は、当時、高校生。
GNU-Cベースではないので、完全にANSI-C準拠というわけでは
ないけど、有志の手によって、int型が32Bitになるパッチや
floatが扱えるものも出ている。公認のSDKではないのだけど
任天堂は黙認。ROMアクセスもバンク自動切り替えで、64kb問題を
意識しなくても使えるパッチも後に登場。

これとは別に任天堂公認のＣコンパイラもミドルウェアメーカから
発売されています。メーカ名、その他詳しいことは守秘義務のため
言えませんが、Ｃ＋＋も発売するというアナウンスも2年ほど前に
一度出ていました。

>>566
だからどうした？

ああ、そうか、
アセンブラ→Ｃ→Ｃ＋＋と
「発展」的に進化するもんだと思いこんでるのか・・・。
違う？

進歩的史観そのものだな・・・。
救い難い・・・。

ＧＢでＣ言語開発して、既に５年の月日が流れましたが、
感想としては、規模が小さいだけに、高級言語の恩恵をモロに受けることができました。
int型が32bitになり、またポインタアクセスも64kbの壁がなくなると
本当に汎用コンピュータになります >>GB
もちろん、8bitマシンで32Bit演算をやらせると当然、重くなるわけ
ですが、10倍遅くなる程度。市場がRPG、SLGだったこともあり、
求められる演算量が電卓レベルで済んだこともあり、処理は常に余ってました。

願わくばC++の登場に期待していたところですが･･･

>>545
事実は全然逆だ。
むしろ只のＣプログラムソースに「.cpp」なんて拡張子付けて
ハッタリかましてるアフォを俺の周りだけでも二人みたぞｗ

んー本当かねー。
ラインスクロールやＸＸＸＸをやろうとするとＣじゃおっつかないんだが
・・・。
ＧＢのＣは知らないけどバンク制限を完全に解決できるとは思えない
んだが？

>>570
変な話だね。
ＧＢの問題はバンクであって演算ワード長ではないんだが？

＞求められる演算量が電卓レベル

すげー変だ・・・ＣＰＵは負荷のメインは演算なのか・・・。

>>571
類が友を…

っつーのは単なる煽りだが、現実にどのぐらい「周囲」の話を知ってる?　俺は視界が
狭いから、他の企業の様子なんかはサッパリなんだが。

>>572-574
ここ、任意 ID だから自作自演するなら sage た方が良いぞ。

自作自演する気がなければ、とりあえず考えまとめてから一気に書いてくれ。

>ＧＢの問題はバンクであって演算ワード長ではないんだが？
大昔にＧＢいじってたオヤジか？
Ｃ言語時代になってからＧＢの開発環境は様変わりしたのよ。
ポインタも演算ワード長も32Bit。
バンク切り替えもＣコンパイラが面倒見てくれる時代に。
Ｃソースレベルではリニアなアドレスがある。

カートリッジがMBC4移行の話だけどね。

>>577
今やってる奴だアフォ。

異バンク呼んだ時のオーバーヘッドの問題にきまってるだろ。
ジャンルによらず、ＧＢでＣ使おうとするのは、いいかげんな
仕事しかしてない奴だと思うよ。

>異バンク呼んだ時のオーバーヘッドの問題にきまってるだろ。
本当に現役な人？
H-Blank中にVDC参照バンクを切り替えて、パターンテーブルを
増やしているMBC2以降のメカニズムは知ってるよね？
異バンク切り替えのコストが高かったのはMBC1のみだよ。

プログラムバンクじゃボケ！
なんつうか。すげー才能のないＰＧか、妄想ヲタだな。

＞ジャンルによらず、ＧＢでＣ使おうとするのは、いいかげんな
＞仕事しかしてない奴だと思うよ。
孟宗大学生、はやく寝ろ。

>プログラムバンクじゃボケ！
バンクにデータもプログラムもないよ。
切り替えが重荷にならないし、仮に重かったとしても
Ｃ言語による記述が原因じゃないし。（アセンブラでバンク切り替えても一緒）

>ジャンルによらず、ＧＢでＣ使おうとするのは、いいかげんな
>仕事しかしてない奴だと思うよ。
漏れの推測分析によれば、こいつは厨房ではなくただの真正オヤジだと思う。
長年、マジでasmで開発してて、566がGBDKのページを紹介。
もう何年も前にフリーなＣコンパイラの存在を知って、己のアンテナの低さに
面食らって愕然としたと見たね。
プログラムのバンク切り替えが遅いだの、言語非依存の欠点を指摘するあたり
自己矛盾自爆がその慌てぶりを露呈する結果に・・・あわれ、オヤジ。

って、折れもオヤジやんけ！漠

あのー、そのフリーコンパイラの遥か以前からＧＢ用のＣコンパイラ出ているんですが
・・・

　　　　　　　　　　　　　　　　　　　　　　　　　　　ヘ ヘ
　　　　　　　　　　　　　　　　　　　　　　　　　　ミ．"．ミ
　　　　　　　　　　　　　　　　　　　　　　　　　　ι ~ι )〜
┌────────────────────┐
│　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 　 │
│OOと関係ない話題はやめまちょうよ。 　 　 　 　 │
└────────────────────┘

スゲーな、、漏れコンパイラなんか使ったことないよ。でもＧＢってアセンブラ
レベルで制御しなきゃいけない部分が多いからＣで書いてもコード量は
ちょっとしか減らなさそう。でもコンパイラって言うからには最適化とか
がんばってくれてイイかも。まぁもうＧＢの仕事なんかしねーからどうでも
いいけど、、。けど、ＧＢにはなんか愛着あるのな。

http://game.2ch.net/test/read.cgi/gamedev/1005161570/

Ｃ＋＋はＯＯ取り入れるのに最高の言語だとは思う。
けどＣＧＢでＣ＋＋はやりたくないな。

このまえＣＧＢ開発したんですＣＧＢ。
そしたらＰＧが一杯いて入れないんです。
良く見たら張り紙がしてあって「ＣＧＢ用フリーコンパイラ」とか
書いてあるんです。もう、アホかと。馬鹿かと。
お前らな、Ｃコンパイラごときで普段開発してないＧＢに来てどーするん
だよ。ゲームボーイだよゲームボーイ。
なんか家族連れで来てるのも居るし、親子四人でＧＢ開発か。おめでてーな。
「よーし、お父さんリニアアドレスしちゃうぞ」とか
言ってんの、もうみてられない。
おまえらな、俺のドリキャスの仕事振ってやるからその席空けろと。
ＧＢ開発ってのはもっと殺伐としているべきなんだよ。
無理に高速化し、無いＲＡＭに詰めこんだ設計がいつ破綻しても
おかしくない、そんな雰囲気がいいんじゃね−か。
素人はすっこんでろ。

やっと席が開いたと思ったら隣の席の奴が、んじゃオブジェクト指向で組みたい
とか言ってるんです。そこでまたぶち切れですよ。
あのな、オブジェクト指向なんてきょうび流行んねーんだよ。ボケが。
得意げな顔して何が、んじゃオブジェクト指向、だ。
お前は本当にＯＯＰＬでプログラム組みたいのかと問いたい。問い詰めたい。小１時間問い詰めたい。
お前、オブジェクト指向にはメタ構造が含まれてないんじゃないかと。

ＧＢ通の俺から言わせてもらえば今、ＧＢ通の間での最新流行はラインパレット、これだね。
本来４色しか表示できないのを制限付きで多色表示。これが通のＧＢの作り方。
ラインパレットっての色が多めに入ってる。そん代わりマージン少な目。これ。
で、渋いカラー画面。これ最強。

しかしこれは処理が間に合わないと、どうにも対処出来ないという危険も伴う、諸刃の剣。
素人にはお薦め出来ない。
まあお前、584は、Ｃで４色アプリでもつくってなさいってことだ。

>>589
一行目だけ、読んだ。

＞GameBoy用のＣコンパイラの原作者は、当時、高校生。
一応、それ以前からＣコンパイラはあったんだけど
既存のz80コンパイラにパッチを当てた程度のものだったんだよね。
任天堂もその高校生に直接打診したけど、断られたというのは有名な話。
本人も商売っ気もまるでないし、高級言語がＧＢの開発言語として
普及してくれさえすればいい任天堂としては、それでも願ったりかなったりなわけで
丸く納まったと。

クリティカルな部分をアセンブラで組まなければならないのは当然として、
携帯機でも高級言語が普及してから久しい。

へー、既存のz80コンパイラにパッチを当てた程度でコンパイラになるんだ。
多分高級言語の「高級」を「高級な技術が要求される言語」とか
「高級なプログラマーが使う言語」とかに勘違いしてる君だろうな。

>z80コンパイラ

ぷ>>591

＞GameBoy用のＣコンパイラの原作者は、当時、高校生。
10年ほど前、GBのワイヤーフレーム３ＤゲーのＸ（任天堂発売）を
作った高校生とは別の人だよね？
その後、sonyに行って、今はGCCベースのEE-GCCを開発中とマ板で
聞いたことあるけど。

任天がカスタマイズしたのは 「Z80/64180コンパイラ」だったと
思う・・・確か。旧ライフボートのね。
http://www.softboat.co.jp/product/iar/ewz80.htm

でも、こっちはセグメント概念とかウザい。
両替機、組み込み系で使ったことあるけど、疲れて欝になった。

現在だとz80も160MHz相当で動くので（Z80S190だとか）
高級言語の需要も高まってるね。ま、素直に他のＣＰＵで
高級言語使えや、とそこで言ってしまうのは素人。
z80は他チップとの相性や基盤の量産効果によるコスト削減が見込める・

Z80をコンパイルしてどうすんだろ？

CGBスレッド（真性オヤジPGが立てたらしい(藁))
http://game.2ch.net/test/read.cgi/gamedev/1005161570/l50

このスレはＡＳＭ派とＣ派の討論スレとして認知されました。

ともに傷付け合いながら滅び消え去る運命なのか・・・泣ける（和良

プログラマは職人気質で頑固ところがあるからな。しかもプライドが高い。
だから、自分の開発手法以外は認めたくないというのがあるんだろう。
自分がある特定の開発手法に忠誠を誓っていることを自覚したら、
頭を柔らかくする方策を練っても良いかもしれない。

プログラマは頭が硬い。これ名言。

GB開発論は別のスレでスレ！

>>601
俺は頭が固くならないように、言語関係とは別にソフトウェア開発がらみの書籍は年に 5 冊ぐらいは
読むようにしてるよ。去年だと達人プログラマ、リファクタリング、プログラミング作法、コードコンプリー
ト、ライティングソリッドコードってな感じ。

次は XP かねぇ。

ふ。本に書いてある固定観念に囚われるだけさ。

頭を柔らかくするんだったら、こんなの
「ファインマン物理学」「ＧＳ美神極楽大作戦」「日露戦争」
「競馬名人読本」「国際経済学」「超人ロック」「日本書紀解説」
「聖なる侵入」（ディック）

>>605
そうなんだけどね。
だから全然本を読んだり他人のソース読んだり開発手法を学んだりせず、
自分の信ずる道をうじうじと追求するというスタイルはあまり健康的ではないような気がする。僕はね。

>>604
"毎年"開発手法の本5冊というのが無理があるような
本が列挙されていますが・・・
読むのが無理と言うより、毎年読んでる割には
不自然な古典が含まれているという・・・。まぁどうでも良いんですけど、
頭堅くしたくないなら全然違うジャンル読んだ方が良くない？

>>608
わりと昔の本でも読んでないものはあるのよ。

> 頭堅くしたくないなら全然違うジャンル読んだ方が良くない？
板違いになりそうなんで、プログラミングから遠く隔たったやつは書かなかったんだけど、
この一ヶ月以内に読んだプログラミングに絡まない本だと

　論理哲学論考
　ローマ人の物語 X
　同時代史
　死刑囚　最後の瞬間
　日出処の天子
　秋吉家シリーズ

とか。プログラミングがらみだと

　Effective STL
　Inside the C++ Object Model

あたり。（年末は暇だったので読書がはかどったんで。普段はこんなに早いペースでは読めません）

>>609
UML関係は読まないの？

>>609
「論考」かぁ。読んだけど全部は理解できませんでした。
今はデリダの「言葉にのせて」を読んでますが、なかなかいいです。

プログラミング関連は「Objective-C」(荻原剛志) が面白かった。

ﾜﾗﾜﾗ>>Z80をコンパイルしてどうすんだろ？

>>610
そういや「リアルタイムUML」って本が出てるけど、誰か読んだ人いる?　タイトルだけ見ると「OOと
ゲームプログラミング」にそのまま使えそうな気もするんだが。

このスレはプログラマが読むオススメの本を紹介するスレとなりました。

>>613
面白そうかもね。
クリーム色の本「UMLユーザーガイド」(だっけ?)はリファレンス的色彩が強くて、
わかりにくかったからこれ買っても良いかも。

関係ないけど、オージス総研って大阪ガスの子会社?だったんだね。
知らなかった。大阪ガスマンセー。

いまだに導入コストについての理解がないようなんだけど・・・。
ここはなんのスレだっけ？

導入したその日から効率ＵＰ！
効率が上がらなかった場合はそのＰＧは、時代遅れの過去の知識にしがみついている
頭の固い、新しい知識を受け付けない、向上心の無い、廃品、真性、
理解力、好奇心といった健全な精神活動を持たない、怠け者、負け組み、落伍者
のロートルオヤジの烙印を押されます。

>>615
> いまだに導入コストについての理解がないようなんだけど・・・。
せっかくなんで、具体的な見解を頼む。

>>617
>>616のようなローカルオヤジを首にするコスト。
あるいは>>616のようなローカルオヤジに無理やりOOPやらせて破綻するリスク

>>618
さえない突込みでスマンが、ローカルじゃなくてロートルかと。

>>619
すまん（死

視野とスコープかけてんのかと思ったｗ

導入コスト気は確かに気になる。
気づいたら使っていたのでその辺わからねーんだわ。
他人に勧めるときに参考にしたい。

>>622
時間的コスト : 小一時間

問いつめたい？

ローカル親父あげ

string abc( const string& in ){
char* pOut = (char *)in;
return pOut;
}

　このコードを実際に書く人が存在する事を覚えておいた方がいい。

>>626
テンプレぐらい使え。な。

>>626
ネタ？

>>626
俺の自作のstringクラスはoperatorオーバーロードしてるから
そのコードでも問題なく動くけど何か？

>>629
そういう問題か？

>>629
　あー、こーゆー人が一番困るかも。
機能が違うならstring2とかにするだろうにね。
ま、ウチもstringは置き換えだけど。

>>631
ネームスペースを切ってあれば許せる。

正解者未だに現れず。

>>626
速攻構文エラーでません？これ。
そういうすぐ分かる間違いはミスに入らないよ。
ミスってのはオブジェクト始末した後外部にあるポインタ
で参照するカスコードを言うの。

>>634
dangling pointerか。

C++ だと、たまに構築が完了していないオブジェクトを触って死ぬことがあるな。
あまりコンストラクタに機能を詰め込まないようにして、まじめにシーケンス図を
書いて考えれば防げるけど。

昨日、久しぶりに pure virtual function で怒られたよ。

折れに言わせればOOをするにあたってC++じゃ退屈な役不足。
C++使えたくらいで優越感に浸って満足できてしまうキミら庶民が
初々しくて眩しいぜ。俺なんか、九九覚えるよりもオナニーを覚えたし、
オナニー覚えるよりもC++を先に覚えたもんだぜ。

>637
それはどこで笑えばいいんですか？

>>638
縦読みするんじゃないのか。

>>639
サンクス！縦読みしたら、ナメック語で神のコードが現れたYO!!

ったくよぉ、オマエら、もうちっとはオレのアソビにはっついてくるかと
思ってたのによぉ。638の639二人。ちっとは、オレの目にオモロいギャグの
一つや二つ、飛ばしてみろや。

>>637
もう来るな。

つまらん

>>642 647

「しね」だの「くるな」だの「つまらねー」だのしか遠吼えしかできねー
単細胞野郎は、おおかた女日照りと見たね。がっかりさせやがって。
なんていうかさぁ、こう、気の利いたディスカッションできるイけてる
プログラマーっていねーの？

>644
ｵﾏｴが一番イケてねー事に早く気付いてくれ

釣り師とお魚

>>637=644
正直、２ちゃんねる広しと言えども、こんな寒いヤツ数ヶ月ぶりに見た。

>>644
はやく OO 語れよ。待ってるんだから。

>>637
私は生まれる前から自分の this ポインタを弄ってましたが何か？

http://www.alien-factory.co.uk/main.html
ここのソースを見ろ。
ＯＯなぞとっくに廃れてるＹＯ！

やっぱ、Rubyだよな、みんな！

そうそう、なんといってもRubyだよな！
Ruby知らないプログラマーは、だいぶ損してるぞ！

ム板に帰ってください。

＞ｵﾏｴが一番イケてねー事に早く気付いてくれ
なんか図星されて釣られた雑魚が。
釣り人644の舌打ちが聞こえてきそうー

>>654
つまらなすぎ。ネタ職人を目指すなら、精進して出直すように。

>655
654をネタ崩れと誤認識するシロい男、ﾊｹｰﾝ

>>637
「役不足」の用法が違うよ。辞書で調べるべし。
それだとＣ＋＋はＯＯなどやるのには勿体無いような高機能言語となる。

というかOOがゲーム制作にとって必須かと言われるとそれはNO。
だから役不足なC++ぐらいが丁度いいと思う。簡単だしね。

>>637
オナニーを小学校高学年あたりで覚えたと仮定すると、九九を覚えたのは中学校あたりですか？
それで役不足の意味もわからないのですね。

>>658
>>657の言ってることわかってる？

>>660
657に返したレスじゃないんだけど…。

>>661
役不足の使い方間違えてるのでもう一度辞書で調べましょう。

　
　さて、　今日もシコシコオナニー議論

C++で作るのにゲームなんかじゃ役不足なんだよ！

いいじゃん、みんな好きなように作れば。

九九とＯＯ。

こんなゲーム、折れには役不足だ！と言って会社辞めたい。

アンチOOな奴が使えるとか使えないとか理解してるかどうかとかどうでもいいよね。
そういう次元の話をしはじめたら面白いゲームつくれよｳﾞｧｶでおしまいになるから。
面白くて売れるゲームつくれる奴が使える奴。それ以外は使えねぇというのが社会。

面白くするのはプランナーとか、ディレクターの仕事じゃないのかなぁ。
と、最近思うようになったが、そうもいっていられない現状。

>>668
> 面白くて売れるゲームつくれる奴が使える奴
そりゃそうだが、プログラムに関しては広い意味での「技術力」がモノを言う場面も
多い。

いくらアイデアが良くても、バグバグでしょっちゅう異常終了するようだと論外だし、
新しいアイデアを盛り込もうとしたときに「設計からやり直さないと無理」だと、時間
的に余裕がなくなって、実現可能なことが制約されてしまう。

ここまでは前提で「で、OO はどうなんだい」っつー話をしてるんじゃなかったのか。

OOはもう前提として、今はジェネリックなプログラムへとパラダイムが進化しつつあるようです。

>>671
OO と Generic Programming の関係は、進化というよりは相補的だが。最近の
流行りだと AOP (アスペクト指向プログラミング) なんつーのもあるやね。

>>672
AOPは理念は解るが、具体的に何をするものなのかよく解らん。

やっと C が根付いた所のゲーム業界が新しいパラダイムを先取りするとは思えん。

まずはちゃんと OO を当たり前にすることからだ。

おまへ、そんな理想を持ってゲーム業界入ったらすぐ潰れるぞ。
設計ねえ・・・・。デザインねえ・・・。遠い他所の世界の話だ。

OOってのはまず設計ありきだから仕様が二転三転するゲームのお仕事
じゃ結構つらいトキもあるのよね。あとC++プロジェクトはメンバーに
一人でもC++を理解していない奴がいると破綻するから要注意。

OOとは関係ないが、XPはどうなんだろうか

>>676
大抵の会社ではチームを仕切ってるのは企画屋。
＞一人でもC++を理解していない奴がいると・・・・・
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
・連中がやるのは・・・・変更の前のＰＧ以外への根回し、・・・・・
多数派工作・・・・・・圧力・・・・・追い落とし・・・・・宣伝・・
・・・・・・・とても理解どころの話じゃ・・・・・・・・・・

>>673
うまくやると Croscutting を局所化できるらしいけど、俺もイマイチ具体的な
イメージが湧かなかったり。キャッシュとかは確かに綺麗に書けそうだけど。

>>676
設計じゅーよーなのは確かだが、いきなりシステム全体を作らずにスパイラル的に
開発するのも可能ですわな。モジュール間のインターフェースを明確にしておけば、
あとで仕様変更が入ったときに、モジュールをゴッソリ入れ替えるのも可能だし。

とはいえ、あまりに仕様変更が大きいとやっぱり作り直しだけど。

>>680
　まぁ、ゲーム作成においては設計よりはノリで作ったほうが有利
な事が多いのは確かだよね。どーせ１本上げたらスタッフが半分は
減るのが業界の常なのでC++の再利用性なんてのは業界の体制が変わ
らない限りは全然意味がないよねー（トカ

　ゲームエンジンの切り売りが商売として成り立ってる海外がちょ
っと羨ましいデス。

>>681
バイオハザードのシリーズとか、PS 版のドラクエ 4, 7 なんかは、思い切り
使いまわしっつー気がするが。

OO のが変更楽じゃん。
変更して問題が発生した時に、変更したモジュールに問題があることが
はっきりするから。

ベタ書きだと 変更した時に他のモジュールに付け焼刃の修正がかかるから
最終的に複雑になりすぎて手におえない。

それぞれの認識している「変更」に大きな隔たりがあると思われ…

で、みんなどんな所に OO 使ってるの？

>>685
ペニス

自分でゼロから作ったフレームなら
たとえOOを多用していても理解もきいてとっても便利なんだけど
他人が作ったものだと途端にわかりづらくなるよね。
クラスのネストが3つ以上だと、もう読むのもイヤって感じ。
メンバを外部に公開するのは絶対禁止、COMインターフェイスみたいなのだけで
継承をサポートするって形にしないとダメだと思うなあ。
作るのは大変だろうけど。

>>687
いきなりソースを読む前に、ふつうはクラス図やシーケンス図を眺めないか？

>>688
多分、そんな物なかったんじゃない？(ハウスライブラリでは十分ありうるでしょ)

>>683
こいつ本当に開発の経験あんのかよ

>>689

クラス図やシーケンス図を補完している開発会社があるなら、それこそ
無駄だと思う。仕様は日々変わるんだから、そんなものとっておいても
意味がない。

常識的でシンプルな設計すれば、何となく分かってくるものだと思うよ。

>>691
> 仕様は日々変わるんだから、そんなものとっておいても意味がない。
…そいつは凄いな。ふつー（非ゲーム業界）は仕様が変わるからこそ、開発資料を
残しておくんだが。

>>692
パッケージ売り切りだと日々のメンテがないから、そういう風になるのかな？
まだ普通？(情シス)しか知らないから、パッケージ開発がどういう世界かしらない。

しまった、ワナビ〜暴露しちゃった。

>>691
で、そういう会社に限ってスタッフに逃げられると、そのままポシャルんだよなぁ･･･
そいつ等の開発水準すら維持できなくて｡

>>694
実際、それでポシャる、もしくは瀕死になったメーカーは相当あるぞ｡

>>691
クラス図やシーケンス図を補完するのは開発者の為ではくて、開発会社の為
なのに、それを否定するって、それでメシ食ってけるのか？
そういうヤシは、すぐ仕事ホサれると思うんだが｡

>>696

開発会社が（経営陣の方々か）欲しいというなら、完成した動くコード
とセットで UML図 （といっても、Rose とか自動作成ツールで出力する
ものの可能性が高い）を仕様書と報告書とともに差し上げます。

けど、デザイナーとゲーム開発者と間で、システムの中核の開発が終わってない
ってのに、のんびりと UML図を作っては書き直し、作っては書き直し、なんてマ
ヌケなことはしないでしょう。

開発＝コーディング　なの？

UML で図を書くというのは、何もお絵かきして遊んでるわけじゃなくて、問題の
分析／設計をやってるんだけど。

あ、話の流れを見てみると、
「完成し終わったライブラリのUML図を開発会社が保管」という意味での
UML 図の保管ということみたいですな。

それなら、保管するのは大いにありうることだと思います。
ごめん。


>>698

もちろん、UML図を書くのはいいんですけども、（Extreme Programming 的には）
仕様が変わる可能性を残しているのに、図はとっておくのはムダということでございます。

（なぜなら、どうせすぐに古くなってしまうから・・・）


UML図は紙に描いて意思疎通が終わったら丸めて捨てるのがベストだと思います。

>>699
俺は、仕様が変わるからこそ開発資料を作るけどなぁ。

もちろん全部のクラスやシーケンスについて詳細な図を書くことはなくて、中核と
なる部分と例外的な処理をしている部分だけまじめに書いて、後は適当に書くか
まったく書かないけど。

そうでないと、仕様変更が出てきたときに

- その仕様変更によって、どこがどの程度の影響を受けるのか（インパクト分析）
- 作業工程にどのような影響が出るか
　並行して進めてる作業をとめて、こちらを先に進める必要があるのか
- 結果として、スケジュールにどのような影響が出るか

なんてのを、その場で大雑把にでも見積もるのが難しくない？

追記

> （なぜなら、どうせすぐに古くなってしまうから・・・）
up to date に保てないような図なら、まるてて捨ててしまえ、というのは同意。
だから何でもかんでも図にしろっつーのは俺も反対。

>>700

いやいや、それが「罠」なんですよ。
また、Extreme Programming を引き合いに出すけど、
未来を予測するのは不可能なのです。

もし、仕様変更が無かったらどうしましょう。
仕様変更のために資料を作ったのがムダになってしまいます。

>>702
仕様変更に備えるのは、理由の一つで

- 設計を OO でやってる場合、頭の中に最初に出来るイメージはコードよりは
　UML の図に近い。設計段階で UML の図は自然に出来る。（設計をすっとば
　していきなりコーディングしちゃうヤツを除く）
- コーディングした本人も、数日経つと詳細は忘れる。そのときにコードを追っ
　て理解しなおすよりは、図を見て思い出した方が効率が良い。まして本人で
　はなく、他人がメインで保守しているコードに関してはなおさら。

というのもあるけど。

結局売りきりだからね。開発会社も開発ノウハウを蓄積するためのプロジェクト
運営なんて考えないし。（考えているところもあるんだろうけど。）
だいたい、３〜４年たつと新ハードがでて、作ったものがかなり陳腐化するのが
どうしようもない原因であるよ。３ＤといってもＸ−ＢＯＸとＰＳ２とＰＳ１で
も別世界だし。　もうしばらくはその場しのぎを続けるしかないだろうな。

むろんＤＱくらい売れるなら使いまわし前提にプログラムを組む余裕はあるだろう。
シナリオ、バランス調整のほうが時間かかってるだろうし。

>>704
陳腐化が速くて再利用が厳しいのは確かだが、それでも昔の

　プログラマ一人
　開発期間は数ヶ月

という古き良き（？）世界から、

　プログラマは最低数人
　開発期間は 18 ヶ月

という状況になってしまったわけで、「設計は俺の頭の中にあるよ」では通用しな
くなりつつあるのは確か。

開発期間が伸びた場合に嵩むコストも昔の比じゃないし、外から資金を調達し
てる場合にはスケジュールに関して「プログラマは８割方できてると言ってます」
では済ませてくれないしね。

それに自分達がその資料や資産をもう必要としなくても、ほぼ同時並行
で進行中の別チームがソレを切実に必要とするケースは結構あるよ｡

だから「設計は俺の頭の中にある」っていうのは、ソイツの独り善がりの
台詞としか思われなくなってる｡　たとえ腕が確かでも｡

注意すべきなのは、ドキュメント使ってる人がいるかどうか、だよね。

もし、見る人がいなければ、そんなものは作っちゃだめ。

見る人がいれば、できるだけ短い分かりやすい文章で解説して、そして
やっぱ一番効率がいいのは面と向かってのやりとりだね。2ch で設計の
議論やろうとしたら全く非効率極まりない。

>>707
だから使ってる人がいるかどうかってのは、製作者自身が決める事じゃない
ってーの｡
たとえ実際に必要とされなくとも、自分達が作った物に対する詳細な資料を
作製、添付するのは、その完成品で金を貰う人間としては当然の義務だぞ｡

ソレを口で説明するのが一番効率がいいとは、何たる言い草だよ･･･
口で説明する｡で済むなら、同人とかでやってくれ｡

仕事で、そんな事されたら俺は上司にそいつを更迭するよう強く迫るけどな｡
第一、ドキュメントもロクに作れん様な奴が人に判りやすく説明できるわけ
無いだろうが｡

>>708
ドキュメント書かないヤツは論外だが、ドキュメント過剰も良くないとは思う。プロ
ジェクトの規模が大きくなって、それこそ業務用システムのような

　数千人月

みたいな世界になると開発者間で直接コミュニケーションなんてのは不可能だか
ら、細部までドキュメント化してないと話にならないけど、

　開発者数人

という規模だと、コア部分関してはきっちりドキュメント化するのは当然としても、
細部の頻繁に変更される部分までドキュメント化しても無駄になる可能性が高
い。

細部は doxygen あたりのドキュメント作成ツールで済ませることにして、コア部
分だけきっちり資料を作るってのも、現実的な選択肢だと思うよ。

>>707
資料って OO だと UML で大雑把に書いて、そこにノートでコメントを書き込む方
が、文章で書くより分かりやすくないか？

＞だいたい、３〜４年たつと新ハードがでて、作ったものがかなり陳腐化するのが
＞どうしようもない原因であるよ。３ＤといってもＸ−ＢＯＸとＰＳ２とＰＳ１で
＞も別世界だし。　もうしばらくはその場しのぎを続けるしかないだろうな。
いっちゃ悪いけど、「描画系」と「アプリ系」をきっちり分別して開発する
ことに困難を感じている君は修行不足だと思う。

特に、PS2 -> X-Box への移植に困難を感じているのならば
開発時の整理整頓を真剣に考えた方がいいと思う。

OO ってプログラムの複雑度を下げるよなぁ…って思ったんだけど、
これについての意見プリーズ。

思いつきだから自分でも確証ないんだよね。どうなんだろう？

>712
構造的にはそうかもしらんが
ソースコードは長くなるぞ

というよりアンチOOから怒濤の煽りが来そうなﾖｶﾝ

スパゲッティがほどけて独立性が上がっても、
その独立したものどうしを繋ぐのに複雑性が上がる罠。

>>713
ソースコードの長さって問題なのかな？たいした問題じゃないと思うんだけど。
みんなそんなにキーボード打つの遅いの？

>>714
なるほど、だから UML とか デザインパターンズ とかが重要になるんだね。

ズ

そうズら

複雑度を下げるというより上げると思うんだが
複雑なことが安全にできるようになるって感じ。
ソースコード対効果比（Ｓ／Ｎ比）は高い。
掛ける時間は設計９０％、コード１０％くらいになった。

たしかここだったと思うけど、OOPでSTG（凄く簡単な雛型）作った人が、
ソースUPしてたと思うけど、勝手に弄らせて貰ってます。

何か形になりそうだったら、UPします。

Effective STL買ってきて読んでるけど
shared_ptr（・∀・）ｲｲ!! 怪しい自作スマートポインタとはお別れだな。

>>720
weak_ptr も調べると幸せになれる。(boost 1.27 以降だったかな)

>>719
ライセンス条件は確認した？　BSD ライセンスとかならともかく、そうでないと
「参考にするのは OK だが、コピペで使うと著作権法違反」とかの可能性もあ
るから注意ね。

>>718

設計に時間をかけるのはよい心がけ。

ただ、大抵、設計にかける時間というのは言うなれば「どうすれば簡単になるか」
ということを考える勉強の時間なのよ。

OO に慣れた人なら、ちょっとしたディスカッシヨンですぐに設計は完成しちゃう（・・・と思うんだけど、どうかな）

設計に時間費やすのはいいけど、それでデザイナが求めていないところまで
柔軟性を持たせる意味もないし。

だれもが 3分 で内容が理解できるくらい単純な設計でないといけない。
そういう意味じゃ本来は設計には時間を費やさないのが、OO をマスターしてからは
重要なんだと思う。

>>723
> OO に慣れた人なら、ちょっとしたディスカッシヨンですぐに設計は完成しちゃう
気のせい。

>723
その３分程度でできるのはモデリングだけだろ・・・

ありがとうございます。
往々にしてあほ(笑)なので私はまだすぐに設計が完成…という境地には
至ってないですね。がんばりたい。

先のことを考えて作らないこと。自分が設計にこもりはじめたり、
一般化をはじめたりしているのに気がついたら、ストップ。動作す
るもっとも単純なことを実装して、今しなくてはいけないことをす
るのだ。「あとで必要になるはずだ」と言っている自分に気がつい
たら、あなたは貴重な時間を無駄にしているということだし、顧客
からプライオリティを設定する権利を奪い取っているということだ。

>>727
正直、リファクタリングは

　ちゃんと設計できる能力がある人

前提の話だと思う。いい加減な設計しか出来ない／設計しない人が言い訳に
使うのは許さん。

もとの設計がダメでそれから派生した多種のクラスもダメだった
その修正がいい加減嫌になって全部捨てて結果
全世界の開発者の貴重な時間を無駄にした例がＭＦＣだよね

>>729
MFC 叩きはよそでやれ。

>>729-730
秀同（ｗ

良スレ期待age

設計のベストなあり方としては、以下のページによいものがあった。

設計の終焉?
http://objectclub.esm.co.jp/eXtremeProgramming/IsDesignDead.html


設計はやっぱしなきゃだめ。
でもそれは複雑になりすぎちゃだめ。
時間をかけすぎてもだめ。
しっかりできても他人に説明できなきゃだめ。

>>733
読んでみたけど、妥当な意見に思えるな。

>>733
どうでもいいが、こうあるべきという主張はやめたほうがいいよ。
XPかぶれてるのはわかるけど。

>>735
> XPかぶれてるのはわかるけど。
リンク先のドキュメントも >>733 の文章（設計の終焉? の要約だと思うが）も、
むしろ XP の中では穏健派の書いた文章だぞ。

XP について賛成するにせよ反対するにせよ、とりあえず XP について調べて
理解しとけ。話はそれからだ。

XPを実践できるのは天才だけ？

>>736
んー？ベストなものなんて世の中には無いって言ってるのさ〜。
XPについては何も言ってないぞ。

>>738
> XPについては何も言ってないぞ。

XP について何も知らないのに
> XPかぶれてるのはわかるけど。
と言うの？　ダメじゃん。

>357
＞XPかぶれてるのはわかるけど。
>738
日本の政治家みたいなﾔｼだな（藁

ポインタ間違えた・・・
×>357
○>735

がんばれよ（藁

やだ（ｗ

age

XPなんてｶﾞｷのｼｮﾝﾍﾞﾝ臭いものを勝手に作っておいて
勉強しろなんてひどいな

（多分ここで）UPされたOOPSTGに、簡単なタスク管理追加、DIRECTX化、
したものをUPしようかと思います。
（環境、Ein98SE,P31G,GForce3）
著作権法違反は、特に記述がなかったのでOKだと思います。

当り判定（タスク間のやりとり）をまだ入れてないんです。
各（自機の）弾タスクが、（敵の数分の）タスクを総ナメしないと
いけないんですかね？やっぱ。判定に段階を設けるとしても。

>著作権法違反は、特に記述がなかったのでOKだと思います。
　
お〜い、はに丸。著作権は何もしなくても自動的に発生しますよ。
改変と再配布の許可が明示されているのでなければ、
一応作者に問い合わせるしか。

>>747
同意。

明示的に再配布可能とか記述がない限りは、勝手に使うとまずいぞ。

っつか C++ で書いたシューティングゲームの雛型なら MIT ライセンス
で公開されてるものがあるぞ。

>>747
はにゃ？そうスか、、。無知を晒してしまったですな。
ソース自体は、殆ど書き換えちゃったんですがね。実は。
やめといた方がよさそうですね。
作者の方へコンタクト取れそうにないし。

>>748
出来れば、詳細を教えて下さい。どんな設計か興味あります。
（特にクラス間の情報のやり取り等）
シューティング　C++　で検索しても見つけられなかったです。

ximpactもC++で書いてあった気が

>OOPSTG
開発状況報告スレのここらへんじゃない？
http://game.2ch.net/test/read.cgi/gamedev/1005143186/212-

あとここ。
http://www.sm.rim.or.jp/~shishido/gamedev.html

>>749
これ。

http://www.issei.org/programming/Windows/DxApp

ただしソースはあるけど操作に必要なリソースファイルは置いてないし、
当たり判定もまだのようだが。

>>751
おお！THX!ビンゴです。早速問い合わせてみます。

>>752
THX!です。見てみます。
でも、本業の方が押してきてるので、作業進まないかも。
（でも、やりたいのはSTGｗ）

今、某CUBEやってるんですが、コールバック関数のラッピングに手間取ってます。
(static)関数内でクラスにアクセスのに、とりあえず、グローバルポインタ渡すしか
思いつかない、、。

>>746
　当たり判定は当たり判定管理クラスにタスクを登録して結果を
コールバックで取得＆反映って感じでしょ。

　後は判定管理クラス内をレイヤー化して置く事で様々な状況に
対応できるようにすると。

>>754
すいません。良く解らないです。

コールバックって、キリの良い所で処理を返す必要がないものに
対して使うものだと認識してます。
（メモカ、CDの裏読み等）当り判定って、フレームごとに全て完了
させないとイケナイ気がするんですが・・。

>>755
> コールバックって、キリの良い所で処理を返す必要がないものに
> 対して使うものだと認識してます。
認識が間違ってます。

>>755
ウンウン、コンシューマな人だねぇ…。
別にハードウェア割り込みから呼ばれる関数をコールバックと限定
するワケじゃないハズだよ。

当たり判定管理クラスを１つのデヴァイスと見なして、そこからの
情報伝達をコールバックという形で見れば大体言いたい事は解って
もらえるかな？

　だから１タスクは他のヒット効果をもつタスク全てを知らなくても
自分と判定管理クラスとの相互関係のみで当たり判定を管理できるよ
うになる訳。719氏のタスクシステムの全貌は知らないけど、
HitMe( Task& enemytask , int layer );
Hit時にこーゆー関数がコールバックされば大体の処理は管理しきれる
し、パワーアップアイテムとかとの住み分けの汎用性も高いっしょ？

　次にレイヤー化する事によるメリットって？みたいな質問がくると
更に嬉しいんだけど。

レイヤー化する事によるメリットって？

>758
ｵﾏｴ755じゃないだろ

うん

>>757
　それより先に、コールバックで結果を通知することのメリットの方が聞きたい。
（レイヤー化のメリットは、わかる。俺もそうしよ（ｗ ）
　当たり判定管理クラスにAddHitData(Task &, int) IsHit(Task &, int) ってなメソッド
を用意して、前者で当たりの登録（これはTaskスタート時１回でいい）、でIsHitで結果
を知るってな方が自然だと思う。
　コールバック方式って、やっぱ、HitMeの時には登録が行われるだけで、タスク処理
が全部終わったあと、当たり判定管理クラスの実際に判定を行うメソッドを呼んでやる
と、その中でコールバックが呼ばれる感じだよね？となるとコールバックの中で進入禁
止の処理やら、アイテム拾ったときの処理やら、攻撃受けたときの処理やら全部やら
なきゃいけないわけで、そういう処理はタスク処理の中に書けた方がわかりやすいので
は？

>>761
本筋からずれるが、なんでもかんでも Task クラスに突っ込まずに、

- 当たり判定関係のメソッドだけ抽出したインターフェースを用意
　（純粋仮想関数だけ定義したクラスを容易）
- タスク実装クラスに、そのインターフェースを多重継承

の方が、柔軟性が増すぞ。

あ、わかった。タスク処理の中であたり判定処理しちゃうとタスクの実行順で
当たり判定データが現フレームの物だったり前フレームの物だったりしちゃう
からか。

>>761
757 じゃないが、メリットは

1 当たり判定順序をタスク実行順序と切り離せる

2 タスクの状態変化のタイミングと、タスク実行のタイミングを分離できる
　タスクを順次読んでる途中で、タスクの状態が変わって、タスク管理クラス側
　にも影響を与える（たとえばタスクを殺して管理クラスから削除）場合には、
　よくよく考えないと dangling pointer を参照するバグが出る

3 特殊な判定（特定のキャラクタにのみ当たり判定があるとか）を付け加える
　ときに、その処理が各タスクに分離せずに、管理クラスで一括して処理でき
　る

っつーあたりじゃないか。

当たり判定はともかく、タスク実行と描画は実行順序を独立に定義するために、
分離するのが普通だよな。

>>762
多重継承より、オブジェクトコンポジションの方が良いと思われ。

>>765
インターフェースの多重継承と、実装の多重継承を勘違いしてないか？

コンポジションだと、タスク内部の情報にアクセスするのが難しくなるぞ。

>>764
>当たり判定はともかく、タスク実行と描画は実行順序を独立に定義するために、
>分離するのが普通だよな。
うい、そうですな。

　俺のタスクシステムの場合、タスク処理本体を二つの関数に分けてあって、基本
的な処理は１番目の関数をオーバーライドして定義し、実行順の問題がある処理
は２番目の関数をオーバーライドして、ってな感じでやってるんですが、これだと、
２つじゃたんない、３つ必要！ってな事になったらおいそれと足せない。
　なんかもっといい実装例ないかなぁ。それか、実行順に依存させたくない処理は
ぜんぶコールバックでやるべきなんだろうか？（この方式にこだわるのは、処理の
流れがソースからわかりやすい、から）

＃ちなみにその二つのメソッドはanimate、renderという名前。renderといいつつ、
当たり判定とそれによる位置変更もやる……名前と内容が一致してない……。

実例を挙げた方が良いか。

struct hittable {
　 virtual void get_hit_rect(rect&, hit_type&) = 0;
};

class player_task : public hittable
{
　　bool invisiable_;
public:
　　void get_hit_rect(rect& rc, hit_type& htype)
　　{
　　　　if (invisible_)
　　　　　　rc = INVALID_RECT;　　// 不可視状態の時には、当たり判定なし
　　　　else
　　　　　　...
　　}
};

インターフェースの多重継承を利用すれば、こんな感じでタスクの内部状態
を利用して当たり判定を変更することが、容易に可能になる。コンポジション
で同じ事をやろうとしたら、思い切り不自然なコードを書くことになるぞ。

>>766
ん、勘違いしてた。
ああ、762が言っている方式では、タスクマネージャーの方から当たり判定用の
メソッドを呼び出して当たり判定を実現するって事なのかな？（柔軟、か？）

winのような、イベント駆動型とかをイメージすればいいのかな？
いやー。正直、よくわからんスｗ避けてました。
勉強してきます。

＞719氏のタスクシステムの全貌は知らないけど、
HitMe( Task& enemytask , int layer );
Hit時にこーゆー関数がコールバックされば大体の処理は管理しきれる
し、パワーアップアイテムとかとの住み分けの汎用性も高いっしょ？

自分が今実装してる方法は、
UpdateFrame()、（全タスクに対するAI処理等)
EndScene()、（全タスクのキルスク、チェンジタスク要求チェック、実行）
Draw()、全描画
てな感じです。
判定は、キルタスク同様、大まかな範囲チェックに引っ掛かったものを、
EndScene()内でさらに判定、て感じで考えてました。

で、判定関数は、矩形,球ぐらいを用意しといて、タスククラスに
持たせようと思ってました。

＞次にレイヤー化する事によるメリットって？みたいな質問がくると
更に嬉しいんだけど。

それじゃ、
次にレイヤー化する事によるメリットって？

>>767
> 実行順に依存させたくない処理は ぜんぶコールバックでやるべきなんだ
> ろうか？
そう思う。

上のほうで挙がってた DxApp だけど、あれは描画とタスク実行を切り離して
別々の優先順位で処理するようになってる。

　タスク関係　　ITask, CTaskManager
　描画関係　IObject, CObjectManager

が対応するクラスなんで、読むと参考にはなるかも。

（あと優先順位無し、登録順で処理する IObjectCommand っつーのもある）

　>>768 の方式だと、オブジェクトごとに当たり判定の実装が必ず
違うのであれば問題ないけど、このオブジェクトとこのオブジェクトは
実装一緒ってな事が多いとコピペが氾濫したり、もう一個クラス作って
へんちくりんなメッセージングすることになったりしない？

　俺は757のいう当たり判定管理クラスってのを導入した方が
スマートだと思うから。
　メンバとして持ったhittableのインスタンスの参照を当たり判定
管理クラスに丸投げしてやるだけでいいと思うので、複雑にはな
らないと思う。

>>772
> このオブジェクトとこのオブジェクトは実装一緒ってな事が多いと
そのときには template を使って Mixin すれば OK。

っつか 768 も

- 当たり判定管理クラスを作り
- そこに当たり判定チェックを行うインスタンスを登録
- 管理クラスから、各インスタンスをコールバック的に呼び出す

のは同じだけど。設計方針は変わらず、たんに C++ で都合がいい実装方法を
紹介しただけ。（コールバックの代わりに多重継承を使うと this の受け渡しが楽
だぜ、という程度の話）

　俺のは２つだけど、>>770 のは３つに別れている、って事なのね（w
　こうなるとじゃぁ４つに分割、５つに分割と仕様要求次第じゃきりがない
って話になるな。
　タスク処理メソッドを可変長リストで持って、とかすると無駄に複雑に
なりそうだから、>>771 の言う通り、「実行順に依存させたくない処理は
ぜんぶコールバックでやるべき」なのかも。

>上のほうで挙がってた DxApp だけど、あれは描画とタスク実行を切り離して
>別々の優先順位で処理するようになってる。
　フロー制御はタスク機構だけで十分、というのは強引かな、やっぱ。（あ、俺
のシステムだとanimate、renderメソッドの呼び出しそれぞれに別々の実行順を
設定できるから、同じ事が実現できてはいる）

>>773
>> このオブジェクトとこのオブジェクトは実装一緒ってな事が多いと
>そのときには template を使って Mixin すれば OK。
あ、なるほど（ｗ

>>773
>（コールバックの代わりに多重継承を使うと this の受け渡しが楽
だぜ、という程度の話）
たしかに、関数のポインタを渡すより、オブジェクトのインスタンス
渡した方がいいですな。

　つまり、基本はタスクでフロー制御して、その実行順に依存したく
ない物は全部GoFの言うところのCommandパターンでやるのが吉、
ってことかな？

>>772
C++ 限定の手法だが、template を使った Mixin の例。

template <class T>
struct hittable_invisible : public hittable
　　void get_hit_rect(rect& rc, hit_type& htype)
　　{
　　　　T& obj = static_cast<T&>(*this);
　　　　if (obj.invisible_)
　　　　　　rc = INVALID_RECT;
　　　　else
　　　　　　...
　　}
};

class player : public hittable_invisible<player>
{
　　bool invisible_;
public:
　　...
};

効率と汎用性、そして型安全性を全て損なわずに実現してる。ペナルティは
コードサイズの増大。

>>774
３つ？ですか？

大まかな流れはさっき書いたものなんですが、言葉足らずだったかも。
ちょっと細かく言うと、
UpdateFrame()は,ゲームアプリ、タスクマネージャ、
描画エンジン、vプリミティブ（描画）、v各TCB、v各タスククラスが持ってて、
vがついてる奴が仮想関数です。

EndScene()は今の所、託すマネージャのみのメンバ間数です。

Draw()はタスク処理とは関係ないです。
こちらは描画エンジン、各（と言っても今実装してるのはスプライトのみ）
プリミティブクラスで使ってます。

タスククラスは、
tcbBase<-tcbSprite(今これだけ)
tskBase<-各キャラタスク　となってて、
tcbSpriteのメンバにVectorでtskを保持して、チェンジタスクで
切り替えています。

tcbSpriteが、（スプライト）プリミティブからリソースを貰って
UpdateFrameで更新してます。

描画エンジンの方にも、UpdateFrameはあって、アニメ処理、タスクが
弄った頂点データをビデオボードに転送したりしてます。

>>757
話が落ち着いたところで、そろそろ「レイヤー化する事によるメリット」を
語ってくれると嬉しいトコロだが。

そもそも「レイヤー化」を、どういう意味で使ってるのか分かってなかったり
するので、単語の定義からお願いします。

>>777
　ああ、タスク毎の処理は１種類で、当たり判定の処理（タスク実行順に
依存したくない処理）はタスクマネージャーがグローバルに行う、ってわ
けですね。
（´ー｀）。oO（ 本当、人それぞれだなぁ ）　

このスレの最初のほうにCとC++ではCの方がC++で作ったときよりも
実行速度が速い、もしくは同等と書かれていたんだけど、
ヘボプログラマはCで作っておいたほうが無難ということなの？
そこで言われているCとC++との違いはクラスの使用から来るもの？

>>780
実際にわずかなオーバーヘッドがあるし、まずい設計では
暗黙のコンストラクタ/デストラクタによって積み重なって遅くなる。
C++についてよく理解してないと、ただ遅いだけの道具になるよ。

C と C++ の違いは主にクラスによる。
同一な C プログラムなら C++ でコンパイルしても
速度はほぼ同一なはず。ライブラリとか最適化の具合にももちろんよるけど。

>>780
書籍「Inside the C++ Object Model」で詳細に解析してるから、それを
読むのがいいと思うが。

メンバ関数（メソッド）を呼び出す場合に this が暗黙のうちに渡されたり、
仮想関数を呼び出すと間接参照が何度か（一般には 2 回）入ったりす
る。ただ、このあたりのことは C でも同じ処理をやろうと思ったら、

　関数の引数として、構造体へのポインタを渡す
　関数ポインタを使う

必要があるから、ホントは変わらないんだけど。

> 暗黙のコンストラクタ/デストラクタによって積み重なって遅くなる。
synthesize constructor / destructor のことを言ってるんだと思うが、
それなら C だって「初期化処理を入れたら遅くなる」というのと同じ。
trivial constructor / destructor で済むクラスなら、初期化・終了処
理を省くことも出来るし。

C でも C++ でも「同じ処理をさせよう」と思うと、実際には「同じだけの
コストがかかる」ことになる。ただ C++ では、synthesize constructor/
destrurctor や temporary object のように

　コンパイラが、見えないところでコードを付け加える

ことがあるから、そこを意識していないと、たった数行のコードなのに
コンパイルすると数千命令に展開されていた、ということが有りうるの
で注意が必要。

>>778
　フォトショップのレイヤーを思い浮かべると良いと思われ。
　当たり判定を取る当たり同士をグループ化して、グループに番号を付けておく。

　進入禁止系のあたりをレイヤー０番に置くとして、壁、NPC、敵キャラのあたりは
HitMe( ???, 0)と呼び出してやる。プレイヤーオブジェクトはそれが壁なのかNPCな
のか区別せずにすむ。
　で、レイヤー１番はアイテム系の判定として、アイテムオブジェクトとプレイヤー
オブジェクトだけが所属する。そうすればNPCオブジェクトの方で接触のあった
オブジェクトがアイテムだったら何もしない、なんてコードを書かなくて済む、と。

　こんな感じ？

すげぇ、この板に役に立つスレがあったのか。

>>784
なるほど。参考になったよ。

レイヤー化って、OS−ミドルウェア−アプリケーションみたいなプログラムの階層化と思ってたけど、違ったのね

>>784
　すまそん。マスター入れてやっと家に帰って来れました。

　レイヤー化のメリットはまさに784さんの言うとおり。汎用的な当たり判定管理クラスを
１つ作ってあとはゲームデザイン次第でプログラマが自由にレイヤーを利用みたいな感じね。

　更なるメリットとしてヒットアルゴリズムの分離ってのもありまして。
「矩形の重なりによるヒット判定」
「球形や線分との距離による判定」
「背景物のようなｎ次元マップデータとの判定」
「ランドスケープやポリゴン等のベクトルデータとの判定」
など、これまたゲームデザインの要求に応じて利用/拡張すればいいと。
はっきりいってこの機構自体は１個作っちゃえば３Dゲームにもバリバリ
に応用できるし、斑鳩みたいな２Dの３Dの混在なんかも結構簡単に出来
るよね？

　ただまぁ、C++としての実装は自分はヘタッピなのでだれか上手い実装例
をみせてくれないかなーと。テヘッ。

コールバック関数による当たり判定って

全キャラクタのタスク更新
↓
判定管理クラスの関数を呼び出し→各キャラクタのタスクのコールバック関数呼び出し
↓
描画

みたいな流れかと思ったんですが、
コールバック関数内でタスクの状態（位置など）を変化させられないと、
キャラクタ同士めり込んだ状態とかで描画されてしまいますよね？
その辺はどう処理されてるのでしょうか？

良スレなのでage

C++なんぞOOPLではないのでsage

>>788
なるほど、それは便利だ。
ちゅうか今、当たり判定で困ってるところなんだわ。

>>791
すでにそんなことはどうでもいい

>791
マ板で語り尽くされた事を隔離板で吠えられてもﾅｧ...
つーか、sagaってねぇし（藁

>>789
俺の場合、基本的にあたり判定の中では当たったかどうかの判定だけで
めり込んでも無視です。
当たり中に状態変化(移動、フラグ立てなど)を行うと実効順によってそれ
以降の判定が異なってしまうからです。
どうしてもやりたい場合、完全な例外処理ですね。
こいつはこういう処理だから気をつけるとかコメント書いてます。
つーか、うまい処理が思いつかん。

このスレに影響されて、当たり判定管理クラスを構築中age

頑張れー＆公開キボン。

当たり判定はその処理のタイミングも必要なので、
それ単体をクラスで定義しただけでは難しいと思うのだが
何かいい解決手段あったらよろしく

>>764
それだと、当たり判定の種類毎にレイヤー用意しなきゃいけなくなって面倒じゃない？

>>764
じゃなくて
>>784
でした。

800get

最近C++でゲーム開発しているんだが、ヘッダーファイルをincludeするだけで
最終コードのサイズが増えるという現象に遭遇して思いっきり萎え。
コンパイラのバグだがあまりにもひどいっす。
Cならこんなことはならないよなぁ・・

どのコンパイラ？

CWだな…。オレも経験済み。

参照してないシンボルもリンクしちゃうってこと？ >>801

g++なんだがCWでもあるんか・・。
classの中のstaticなinline関数が関数ローカルのstatic変数を持つコードが
あると、その関数を一度も使わなくともコード、データ領域ともその翻訳処理
単位で展開されてしまうんだよ。いわゆるシングルトンパターンの構造をもつ
ヘッダファイルをインクルードするだけで飛躍的にコード、データサイズが増加する
罠。
やっぱC++は組み込みには向いてないよな・・・。

組み込みだからって、そんな関数なんでinlineにすんだよ？>>801

>>805
ちなみに gcc のバージョンいくつ？

class foo {
static foo& Instance() {
static foo bar;
reurn bar;
}
}

これだけですが何か？

>>807
2.9-9911、2.96-1003、2.96-1003-1で確認したよ。

>>808
parse error だぞ（ｗ　まぁ、言いたい事は分かるから問題ないけど。

今、手元の gcc 2.95.3 (cygwin-special) で

class foo
{
public:
　　static foo& Instance()
　　{
　　　　static foo bar;
　　　　return bar;
　　}
};

void func() { foo s; }

だけのコードを g++ -S でコンパイルしてみたが、確かに .lcomm セクションに
変数 bar が確保されちゃうね。Borland C++ Compiler 5.5.1 や Visual C++
6.0 だと

警告 W8027 singleton.cpp 6: <静的変数>を含む関数はインライン展開できない(関数 fo
o::Instance() )
singleton.cpp(15) : warning C4514: 'Instance' : 参照されていないｲﾝﾗｲﾝ関数は削除
されました。

となって、いずれのケースでも出力されたアセンブリコードに bar は存在しない。

>>801
inlineにしなくてもまともな実現方法がいくらでもあるんだから、
> C++は組み込みには向いてない
なんてことにはならんだろ。

保守ageついでに。上っ面撫でてるだけの記事だけど。

GameDev.net - Object-Oriented Scene Management
http://www.gamedev.net/reference/articles/article1812.asp