■自主製作ゲーム：開発状況報告スレ■

**名無しさん＠お腹いっぱい。** · 01/11/07 23:26

開発スタートしたはｲｲが、多くのゲーム（企画）は完成を見ることなく
消え去る自主制作ゲーム。
このスレでは自主制作ゲームの製作スタート告知をし、進行状況を逐一
報告するスレであります！デベロッパは製作スタートレスをしたら
以後、名前欄に製作中ゲームのタイトル（進行状況%）を入れてください。
例＞名前：ロリッ子天使ハニーバニー（5%）

一体幾つのプロジェクトが完成するやら見守りましょう。

**名前は開発中のものです。** · 02/05/18 02:00

>>754
タイニーが女っだったなんて知らなかった。
ありゃどうみても　男にしかみえん。

**リチャード堀井** · 02/05/18 19:12

久々のゲ製技。うまい具合にウチにツッコミが入ってる。

>>756
P3じゃ駄目かな？世のゲームユーザーってどれくらいのスペックのPC使ってるんだろう？
ちなみに CPU よりメモリを酷使するゲームになりそう(というかプログラムが手抜きなので)

**名前は開発中のものです。** · 02/05/18 19:27

全員うｐしろや！

**名前は開発中のものです。** · 02/05/18 21:13

半年で作る予定が、もうすでに１０ヶ月経過…
なのに６０％くらいしかできてない。
モチベーションもたないよ～！

**シューティング＠OpenGL(50%)** · 02/05/19 00:56

土台がほぼ完成。あとは敵や背景の種類を増やして配置していけば…
…と言いつつ、もの足りない部分が出てきて結局土台の変更をしてしまう人。
自分としては50%まで出来たと思うが、先は長そう。

**名前は開発中のものです。** · 02/05/19 04:18

久しぶりにagaってきたと思ったら、煽り厨房のせいか。
このスレ結構マターリしてて気に入ってたのに、もうだめだな。
所詮隔離板はこんな物か。

**名前は開発中のものです。** · 02/05/19 05:32

>所詮隔離板はこんな物か。
こんなことをいっているうちは君も煽り厨房と変わらないじゃないか

**754** · 02/05/20 18:31

メッシュコンバーターライブラリだが、
プロトタイプがあまりにも遅かった為、（Athlon900MHzで変換に1分ぐらいかかる。）
もう一度作り直して、基本部分はほぼ9割完成。
ボーンがいくつあろうが、無理矢理メッシュを再構成して
表示出来る形にまとめる。
最近は高性能なビデオカードが多いのでかなり存在意義は薄いが
それでも、GeForce256のHWTLが効いてる様を見ると嬉しいもんだぜ。

**名前は開発中のものです。** · 02/05/20 19:24

>1-764
みんな頑張れ

**751** · 02/05/21 01:47

http://blue.ribbon.to/~coffee/piyo/

**名前は開発中のものです。** · 02/05/21 10:01

>766
完成してるやん

**名前は開発中のものです。** · 02/05/22 20:21

リブルラブル 0% 現在どんなゲームなのか資料を読んでる途中

**『ジエンの無人島』@HSP (40%)** · 02/05/24 07:39

　UDPに対応、ホストCGIによりクライアントの接続がらくらくになってﾏﾝｾｰであります。

**（・∀・）さん** · 02/05/25 19:01

格げーツクールでだらだら作ってるんですが参加してもよろしいでしょうか

**剣振るｱｸｼｮﾝ(95%)** · 02/05/25 23:40

長かった。あと微調整で完成だ。

**名前は開発中のものです。** · 02/05/26 00:23

とりあえずゲームの形にはなってる（と思う）んだが、プロデューサ曰く
まだ２０％程度の完成度らしい（泣

現在、スキンメッシュのサンプルソースを必死こいて解析してます。

**やさしい** · 02/05/27 01:43

板で協力してゲームを作ろうと思ったので
プログラマを募集してます
われこそはと思うつわものは覗いてください

http://ex.2ch.net/test/read.cgi/shar/1022428219/

**名前は開発中のものです。** · 02/05/27 13:08

>>773
言わないと気付かないと思うので、マジレス返します。

本気でやるつもりなら、その前にやり方を検討し直した方がいい。
相手がどこの誰とも知らない人間（しかも２ｃｈ）と作業する以上、
相手がどのくらいのスキルを持ち、どのくらいやる気があるのか（それ以前に
プライベートの時間を削って納期に間に合わせる気はあるのか）分からなければ、
ネタ以外で組む気なんて絶対に起きません。

まず、自分のスキルと能力（できれば、同人でも何でもいいので過去に手がけたもの）を
公開してくらないと話にならない。
せめて、どういうゲームをどのくらいの期間で作ったかくらいは。
もちろん、連絡してきた人間には身元（コテハン）を伝えるべき。
もちろん２ｃｈでそれをやるのはかなりキケンだと思うが、かと言って身元も
明かせないような人間を信頼できるわけが無い。
（ゲーム製作は片手間でできるようなものではないという自覚、ありますか？）

また、企画を立ち上げるなら基本的な仕様書くらい作ってＨＰに載せるくらいはすべき。
仮に人数が集まった後で練っていくとしても、指針となる原案が無くてはまとまりようもないので。

**やさしい** · 02/05/27 23:46

>>774
素人発言で大変ご迷惑をおかけしました。
すんませんでした。

**（・∀・）さん＠格げーツクール** · 02/05/30 00:08

：ようやく技一個完成
：完成度１％前後
・・・いったいいつになることやら

**剣振るｱｸｼｮﾝ(100%)** · 02/05/30 01:27

完成～

次からはﾛｰﾗｰｱｸｼｮﾝ(5%)で

**754** · 02/05/30 04:43

メッシュ関係ばかりで飽きたので
Directionクラスを作る。
結構簡単に出来た。
XYZ軸、ヨーロールピッチ、クォータニオン、行列、ベクトル
全てサポートし、FPSに影響されない一定の量で回転させることができる。

**名前は開発中のものです。** · 02/05/30 07:28

>>778
％書いてくれ。気になるｗ

**774** · 02/05/30 09:58

>>775
分かってもらえて嬉しいです
（実際、こういう意見に一切耳を傾けない輩は多い…）。

おそらく他のスレに書いたものもいいレスはついてないと思うので、
775自身が呼びかけに答えたくなる呼び込みを考えてみるが吉かと。
ただし、個人的には顔見知りの知り合いを集めて作る方を推奨也。

**754** · 02/06/01 07:28

楽だったとほざいていたDirectionクラスだったが
やはり設計の不備やバグが多数あり、
その修正に凄い悩んだ。が、とりあえす完了。
動きを制御するPostionクラスも作る。
これでキャラクタの方向転換、前進後退等が可能になった訳だ。
タイニーたんを2体表示し、片方はジョイパッドでバイオハザードタイプの操作
もう片方はそのタイニーたんを常に凝視続ける。
こんな感じのテストプログラムもうまくいった。
こうなるともっと多くのモデルデータが欲しくなるところ。
とりあえずScaleクラスを作って、次何を作るか考えるとする。
(完成度10%ぐらい？)

タイニーたんを2体作るとDirectInputが動作しなくなるという
不具合発生した。1体だと大丈夫。コードの順番を変えるととりあえず
回避できた。こういう不可解な現象は勘弁して欲しいと思った。

**名前は開発中のものです。** · 02/06/01 10:13

>回避できた。こういう不可解な現象は勘弁して欲しいと思った。
どう考えてもあんたのポカミスだが

**名前は開発中のものです。** · 02/06/01 12:05

>>781
Directionクラスって、ようするにVectorの事？
Positionも同じクラスで代用できるんじゃない？
あとScaleはクラスじゃなくて関数なのでは？

**754** · 02/06/01 17:27

>>782
ソースの抜粋。
このままだとDirectInput使用不可。
m_pTiny1の部分を違う場所に移動してやると
なぜか大丈夫なんですよ。
DirectXラッパーは全部COMモジュールなんで
自分のコードミスでクラッシュする余地なんてないんですよ。

m_pTiny0 = new CTiny;
m_pTiny0->Initialize();

m_pTiny1 = new CTiny;
m_pTiny1->Initialize();

hr = ::CoCreateInstance( CLSID_DInputTPS, NULL, CLSCTX_INPROC_SERVER, IID_IDInputTPS, (void**)&m_pDInput);
ATLASSERT(SUCCEEDED(hr));
hr = m_pDInput->Initialize( m_hWnd);
ATLASSERT(SUCCEEDED(hr));

>>783
Directionは、クオータニオン1個です。
Positionは、ベクトル1個、
Scaleもベクトル1個。
これを最終的に合成してトランスフォーム行列を作成する訳です。
でもまあScaleは確かにデータを保持する必要はないですね。
クラスに統一性を持たせたかったんですね。

**名前は開発中のものです。** · 02/06/01 18:04

>>784
そのソースじゃ誰も判断できないよ

**名前は開発中のものです。** · 02/06/01 21:40

>>784
>Directionは、クオータニオン1個です。
>Positionは、ベクトル1個、
>Scaleもベクトル1個。
>これを最終的に合成してトランスフォーム行列を作成する訳です。

なんかﾋﾞﾐｮｳに違うような…
必要なのはQuaternionクラスとVectorクラス。
QuaternionとVectorは相互変換できるように関数を用意すればよい。
あとはMatrixクラスに行列を保持し、ModelクラスにMatrixを持たせて
そこにpitch、yaw、scaleなどのモデル表示用パラメーターを保持させる。
ってのが王道じゃないかと。

**754** · 02/06/01 23:06

今日はバウンディングボックスクラスを作った。
これは以前作っておいた試作品があったので
現在のプロジェクトにコンバートするだけですんだ。
画像として箱を出力すると、タイニーたんがロボットのようになるので
なかなか面白い。
衝突判定のテストはこれから。

>>786
ちょっとわかりづらかったですかね。
＞pitch、yaw、scaleなどのモデル表示用パラメーター
これを単に向きや位置など動作ごとにクラス分けしただけです。
実際には、DirectionとPositionとScaleから多重継承した
Modelクラスを使っています。
あとQuaternionとVectorは相互変換は出来ませんよ。
Vector1つのみでは、データが足りずQuaternionを作ることは出来ません。

**名前は開発中のものです。** · 02/06/01 23:07

ModelがPositionやDirection等を継承するの？
なんだｿﾘｬ

**名前は開発中のものです。** · 02/06/01 23:09

>>787
vectorもQuarternionも１次元のデータだから、
簡単に相互変換出来るが。たぶん、>>786が言ってるのは、
回転行列との相互変換と言いたかったんだと思うが。

**754** · 02/06/01 23:12

あ、Vectorってのは4次元じゃなくて4次元ですか？
それなら出来ない事もないですね。
でもその変換をする意味は殆どないですね。

**754** · 02/06/01 23:13

＞あ、Vectorってのは4次元じゃなくて4次元ですか？
間違えました。3次元じゃなくて4次元ですね。

**名前は開発中のものです。** · 02/06/01 23:17

>>790
vectorは常に1次元だが？
4つの要素で4次元を表すことは出来るが、
vector自体は常に１次元

**754** · 02/06/01 23:18

つーか、ここは単に日記スレでしょ。
いちいち見当違いなツッコミはうざいよ。
いいや、引っ越します。

>>788
Modelというのは、君たちがわかりやすいように合わせただけです。
3Dに存在するものなら、データとして向きや位置を持つでしょ。
概念さえわかれば何でも良いんですよ。

>>790
Quarternionは4次元です。

**754** · 02/06/01 23:25

>>792
あのね、ベクトルとスカラーについて
もう一度勉強してきてね。
ではさよなら。

**名前は開発中のものです。** · 02/06/01 23:26

>>793
vectorはどう考えても１次元のデータなんだが。

**名前は開発中のものです。** · 02/06/02 02:30

>>795
一次元配列ってことか？

表現方法：一次元配列
表現するもの：n次元のデータ

でよろしか？

**迷路(0%)** · 02/06/02 03:23

まだ人のソース読んでる段階。
Wiz系。移動はFPSとBUSINのいいとこどりみたいな感じで…

**754** · 02/06/02 03:36

なるほど、STLのvectorみたいなものと勘違いしていた訳か。
これでチグハグな話し合いも合点がいく。
俺が言っているのは、幾何学のVectorの方。
通常3Dではxyzの3次元のVectorを使う。
一方Quarternionは4つの値を持つ4元数ってやつ。
だから、Quarternionから単なる3次元のVectorへは変換できない訳。
変換するんなら、回転軸をVectorに入れて
回転角度をScalarなfloatにでも入れることになる。

**名前は開発中のものです。** · 02/06/02 06:37

4次元と4元数を勘違いされている方がいらっしゃいます

02/06/02 21:11

>793
>3Dに存在するものなら、データとして向きや位置を持つでしょ。

それは「属性」であって「本質」ではない。
今はよくても、開発が進むにつれ破綻する設計の典型例。

まぁ本人が良いと言うのだから良いのだろう。

**754** · 02/06/02 21:38

相変らずむかつくなあ。(笑

>>799
別にQuarternionが4次元とは言ってないだろ。
QuarternionをVectorに変換いう奇特なことをしたければ
4次元のVectorじゃなきゃ出来ないよと言ってるだけで。

>>800
何だよ本質って。
俺の作ろうとしているのは「ゲームキャラ」という存在だが
じゃあその「ゲームキャラ」としての「本質」ってのはいったい何よ？
位置や向き、モデルの形状データやアニメーションデータ、
衝突判定用のバウンディングボリューム、
「属性」なのかは知らないが、そういったさまざまなデータが付加されて
「ゲームキャラ」としてのアイデンティティが確立されるんじゃないの？
この方法論に何の問題があるのか？
てか妄想ばっか撒き散らすなよ。

**名前は開発中のものです。** · 02/06/02 22:19

>>801
まぁまぁ、そう怒らないで。他の人達の突っ込みはただ煽ってるのではなく
的を得た事を言っていますし。貴方は多分クラス設計の経験が少ないんだろうと
思われるので、ここは経験者の意見を素直に受けた方が得策ですよ。

>実際には、DirectionとPositionとScaleから多重継承した
>Modelクラスを使っています。

これは継承の使い方を間違っています。
Modelクラスというのを、ゲーム中のオブジェクトやキャラクターを表す
クラスだとすると、このModelクラスにDirectionクラスやPositionクラスを
メンバー変数として持たせるのが自然です。（Scaleはfloat値一つでいいです。）
そして敵キャラやアイテムをこのクラスから派生させましょう。

あと、このクラスはObjectクラスと呼んだ方がいいかもしれません。
Modelクラスという名前はメッシュ(ポリゴンの集合体)を想像させて
しまうので。メッシュのクラスは複数のObjectが共用できるように
しましょう。（同じ敵が１０匹いても、メッシュは一つでよい）

**名前は開発中のものです。** · 02/06/03 00:19

>>802
＞>実際には、DirectionとPositionとScaleから多重継承した
＞>Modelクラスを使っています。
＞これは継承の使い方を間違っています。
はぁ、それでDirectionクラスやPositionクラスを内包する
そのObjectクラスとは、どうやって向きを変えたり移動したりするんですか？
そういったことをする為には、それ用のメソッドを新たに作らにゃならんでしょう。
で、そのメソッドで改めてDirectionクラスやPositionクラスを呼ばなきゃいけない。
俺はそれをするのがイヤだから、こういった形にしてるんですよ。
つーかclassの扱い方としてはこっちの方が普通では？
そしてDirectionクラスやPositionクラスは単なる動作を定義しているだけであって
当然それを総括するクラスは作りますよ。当たり前です。
俺はThingクラスとしてます。ただこれでは命名的にわかりづらいかと思ったんで
>>786の言葉を引用してModelクラスと言ったんです。まあ余計だった訳ですけど。
つーか俺は何から何まで説明しなければならない義務もなければつもりもない。
だからアンタ達の講釈が見当違いになるのも当然。
俺のライブラリの実情なんて、わかりっこないんだから。
でもそれは聞いてないのにくだらないツッコミをする君らゆえにだ。
あとね、Scaleは1個じゃ駄目でしょ。少なくとも俺は駄目です。
なぜなら貴方と俺は同じじゃないからです。
そういうこと。

**名前は開発中のものです。** · 02/06/03 01:06

802じゃないけど

>つーかclassの扱い方としてはこっちの方が普通では？
普通じゃない
>それ用のメソッドを新たに作らにゃならんでしょう
作ります。

当然、階層を一つあげて、「配置可能オブジェクト」インターフェース等を作り、
そのメソッドで位置や角度情報を取得するクラスを作って、
そのインターフェースを実際のModelやCharacterが継承するのなら自然。

しかし、DirectionやPositionを多重継承、及び多重継承したクラスを継承するのは
とらえ方がおかしすぎる。

**名前は開発中のものです。** · 02/06/03 02:07

議論やめー。ここは夢を見たり現実にしたりそんな人達を応援するスレ…
だと思いたいのよね。すまん。

**754** · 02/06/03 02:40

>>804
あのさ、普通かどうかなんてどうでもいいよ。
君らはそれしか言えないんだね。その理由をおしえてよ。
なぜDirectionやPositionを継承してThingを作り出すのがおかしいのか、
なぜ「配置可能オブジェクトクラス」から「Characterクラス」を継承するのはOKなのに
「向きクラス」や「位置クラス」から「配置可能オブジェクトクラス」を継承するのは駄目なのか。
概念的に何が間違ってるのか教えてよ。
後、それによるデメリットも教えて。
俺の体験的には特にデメリットは無いんだが｡
それが出来ないんなら結局は君らの頭が固すぎるだけってことになるよ。

**754** · 02/06/03 02:55

訂正
＞普通かどうかなんてどうでもいいよ。
君らが普通と思うかなんてどうでもいいよ。

**799** · 02/06/03 06:29

>>801
あんたにいちゃもんつけたわけじゃねえのに・・・。被害妄想がつええなー。
もしかしてあんたどこぞのスレで煽られ妄想して非難されてた人？

**799** · 02/06/03 06:33

>>806
正直もうちとOOP勉強した方がいいかと。

> それが出来ないんなら結局は君らの頭が固すぎるだけってことになるよ。
何でもかんでも継承すればいいという考えの方が、頭が固いと思うのだが。

**名前は開発中のものです。** · 02/06/03 06:52

やっぱり、C++(Eiffelかもしれんけど)の多重継承は悪なのかなーとか。
Javaやその他の言語だと、単一継承基本で、
インターフェース(とインターフェース継承)を理解してからでないと
その手のは使い気が起きないんだよな。

**Wizもどき(2%)** · 02/06/03 09:50

なんかこの議論見て迷いっぱなしですわ。
バックボーンにならない、パラメータ的なクラスは継承するより委譲した方がいいってこと？
そのほうがPositionとかDirectionに大きく依存しない物クラスを作れる…のですか？

**754** · 02/06/03 10:32

結局は好みの問題でしょ。
上の方達は、駄目だ～、普通じゃない～、捉え方がおかしい～、
なんてそれしか言ってないし。
容認出来ないなら、その根拠を言うのがスジってもんだろうが。
んでOOP？それは何？水戸黄門の印籠の代わりですか？
つーか彼らはATLとか知ってるのか？
あれはヘタすると20ぐらい一気に多重継承するぞ。

**名前は開発中のものです。** · 02/06/03 11:08

>>754
>なぜDirectionやPositionを継承してThingを作り出すのがおかしいのか
　
is-a関係になっていない継承はやめましょう。
ThingはPositionですか？ ThingはDirectionですか？
けどまあ、仕事で書いているソースとかでないのであればどうでもいい。

**名前は開発中のものです。** · 02/06/03 12:11

>仕事で書いているソースとかでないのであればどうでもいい。

はげどー

**名前は開発中のものです。** · 02/06/03 12:39

>彼らはATLとか知ってるのか？
この人も名前とさわりだけしかATLを知らないようで。

**名前は開発中のものです。** · 02/06/03 12:46

>>806
たとえば、ウインドウクラスや、スプライトクラスがRectとかShapeを継承するべきか。
継承するのがあなたの言う普通だというなら、救いようがないのでもっと本を読むしか。
そうでないのなら、その理由を考えればPos/Dirを継承するのがどうしてダメなのか分かるはず。

>>806 君らが普通と思うかなんてどうでもいいよ。
ちなみに、普通と言い出したのは754が最初です。
>>803 つーかclassの扱い方としてはこっちの方が普通では？

ちなみに、あなたにしか通じない常識は、世間一般で言う「普通」とは違うと思います

**754** · 02/06/03 12:51

>>813
俺は「Thing」を「3D空間にある物体」として定義している。
そして「Position」を「位置」、「Direction」を「向き」とするなら
君の言う通り「3D空間にある物体」は「位置」ではないし
「3D空間にある物体」は「向き」ではない。
でもね、俺の定義では「位置」や「向き」ではないんだよ。
「位置」や「向き」というのは例えるなら、
struct VECTOR のインスタンス vPosition
struct QUATERNION のインスタンス vDirection
に他ならない。これなら君らが内包しなければならないという理屈もたつ。
俺は上でこれらのクラスはメンバを保持しており、動作を受け持っていると言った。
俺の定義では「Position」とは「3D空間において位置を有する存在」であり
「Direction」とは「3D空間において向きを有する存在」なんだよ。
ここまで説明してもわからないようでは、深刻な頭の硬さってことになるが、
まだ反論があるようなら受け付けてやるよ。

**名前は開発中のものです。** · 02/06/03 13:11

>>817
暇だな

**名前は開発中のものです。** · 02/06/03 13:13

向きを「有する」なら、なおのことコンポジションだよな

と言ってみるﾃｽﾄ

**754** · 02/06/03 13:18

ちなみに「3D空間において位置を有する存在」も「3D空間において向きを有する存在」も
それだけでちゃんと成り立つことが出来る。
例えば無限の3D空間に無尽蔵の水が詰まってるとしよう。
その水の名を仮にseaとするとして、seaは位置も向きも大きさも必要としないが
ちゃんと3D空間に存在している。もうこれは定義するなら class Sea
とでもするしかないだろう。
そして、ある日seaに水の流れ海流というべき現象が起こったとしよう。
するとseaは「3D空間において向きを有する存在」としての側面も有することになるのだ。
クラス定義としてはこんな感じか。class Sea : public Direction
俺が「Position」や「Direction」をひとつのクラスとして定義したのは
こういった可能性もあると思ったからだ。

**名前は開発中のものです。** · 02/06/03 13:40

流体と剛体を同じ物として扱うつもりなのかー
がんばれ（藁

**Wizもどき(10%)** · 02/06/03 13:59

something blueみたいですね。たまたま青いんじゃなくってスーパークラス
青い物を継承すべき理由がある・・・（メソッド「幸せな結婚()」？)

3D迷路そのものなソースを見つけて前進。するもどこから手を付けていいやら。
破綻の予感。

**名前は開発中のものです。** · 02/06/03 14:32

>「3D空間において位置を有する存在」
>「3D空間において向きを有する存在」
まさしくhas-a関係だよそれ・・・（´д｀；）

いや、俺も覚えたてはとにかく継承しまくりだったから、
そのうちわかってくるよ・・・。

**名前は開発中のものです。** · 02/06/03 14:38

なんとなく言いたいことがわかってきた。isでなくasか？
PositionableでかつDirectionableなオブジェクトっとして扱いたいということになるのか？
extendsでなくimplementsりたいてってことでよい？

**名前は開発中のものです。** · 02/06/03 16:13

晒しage

**754** · 02/06/03 20:47

>>824
だいたいそんな感じ。
俺のこのやり方は、増長と言われればその通りだと思う。
普通PositionやDirectionを単体で継承させることはないし、
殆どの場合、Thingを始めのひとつとすることで事足りるだろうとは
俺も思うな。
だが、ゼロから作るには、このやり方はなかなかわかりやすい。
確かに、俺は3D制御のライブラリを作るのは初めてなので
こういった方法をとる必要があった。
そしてデメリットらしいデメリットもないし。

>>823
君らが悪だと言うのが、必要以上に細かくクラス分けして継承しまくりの状態のことを
いうのなら俺はそうは思わない。
増長ではあるが間違いではない。
正しくクラス分けがされているのなら、親子関係を持つクラスどうしを
統合してひとつにすることは全然余裕だし。

**名前は開発中のものです。** · 02/06/03 21:13

増長ってなんだ？冗長のことか？
冗長つーんだったら、安易に継承するより所有にする方が冗長だが。

**名前は開発中のものです。** · 02/06/03 21:14

君がやりたいことは分かったが、自信を持って普通と言い切るのはやめた方が良いぞage

**名前は開発中のものです。** · 02/06/03 21:26

>>820
>するとseaは「3D空間において向きを有する存在」としての側面も有することになるのだ。
>クラス定義としてはこんな感じか。class Sea : public Direction

もうむちゃくちゃ（；´Д｀）
勝手にやってろ。

**名前は開発中のものです。** · 02/06/03 22:23

754はゲー専のかおりがするぞ。香ばし(・∀・)ｲｲ!

**754** · 02/06/03 22:47

結局はバカにするだけで終りか。
最初から最後まで、まともな理屈を言ってる奴は
ひとりもいなかったな。
まあ相手が1人か2人かは知らんが。
実際デメリットひとつすら指摘出来んくせに、
なぜ駄目だと言い切れるんだ？
君らが普通じゃないと思う理由はなんだ？
じゃあ普通のやり方とはなんだ？
何万もする参考書に載ってるから
それが普通のやり方となるのか？
もうちょっと自分で考えて生きるようにしろ。
>>829も理解出来ないからといって投げるなバカ。

**名前は開発中のものです。** · 02/06/03 22:56

ここまで来るとネタとしか思えないが。
99.99% 何万円もする参考書に載っている（＝先人達の偉大な知恵の集大成）
スタイルの方が、自分で考え出したスタイルより優れているし。

まぁ、ありきたりな主張をするなら
たとえば実装時の問題として菱形継承だけど、
そんなこと絶対にしないと言って切り捨てられそうだしな。

あとは、モデル＝位置や向きじゃないモデルは位置や向きを属性として「所有」すると言っても、
とらえ方の問題とか言って、とりつく島も無いからなー

**名前は開発中のものです。** · 02/06/03 23:11

なるほど、754はあーいえばこういうガキね。

**名前は開発中のものです。** · 02/06/03 23:42

>>831
救いようの無いバカだな…
実際Ｃ＋＋の文法だけ覚えてＯＯＰの概念を理解したつもりになる
ﾘｱ房は多いが、こいつは異常だ。参考書買う金がないなら図書館で
借りて来い。向上心の無い奴はプログラマには向いてね－よ。

**名前は開発中のものです。** · 02/06/03 23:44

>>831
もっと柔軟性をつけたほうがいいな

**754** · 02/06/04 00:14

>>832
＞たとえば実装時の問題として菱形継承だけど、
＞そんなこと絶対にしないと言って切り捨てられそうだしな。
そう菱形継承は絶対にない。
なぜなら3D空間において正面を2つ持つものは存在しないからだ。
頭が2つあるドラゴンなら、まずドラゴンとしての正面があり
それぞれ正面を持つ頭を所有する形になる。
菱形継承になるということは矛盾を含むことであり、
そうなるということは設計が間違っているということだ。
逆に言えば、君らの言うようなやり方だと矛盾を含む設計になる可能性になると言える。

＞あとは、モデル＝位置や向きじゃないモデルは位置や向きを属性として「所有」すると言っても、
＞とらえ方の問題とか言って、とりつく島も無いからなー
君は俺の説明の何を聞いていたんだ。
Directionは向きそのものじゃないし、
向きそのものはDirectionが属性として「所有」している。

**名前は開発中のものです。** · 02/06/04 00:20

まぁ考え方の問題ですからねぇ。
本人がいいって言うならそれでいいんじゃないですか。
ただし>>831よ。
｢他人に理解しやすいコード｣は、君が思っている以上に重要ですぞ。

**754** · 02/06/04 00:24

菱形継承が起こりそうな例としてこれ。
「ドラゴン」　　基本クラス
「ワイバーン」　　「ドラゴン」から派生
「シードラゴン」　　「ドラゴン」から派生
「シーワイバーン」　　「ワイバーン」と「シードラゴン」から派生

この設計が間違っているのは自明だ。正しいのはこれ。
「ドラゴン」　　基本クラス
「翼を持つ存在」　　基本クラス
「ヒレを持つ存在」　　基本クラス
「ワイバーン」　　「ドラゴン」と「翼を持つ存在」から派生
「シードラゴン」　　「ドラゴン」と「ヒレを持つ存在」から派生
「シーワイバーン」　　「ドラゴン」と「翼を持つ存在」と「ヒレを持つ存在」から派生

**名前は開発中のものです。** · 02/06/04 00:24

Directionクラスは向き（方向）クラスじゃないんですか？
あなたが言う（Directionが所有する）向きはQuarternionの事ですか？
もしそうなら実装に寄りすぎた考え方。
オブジェクトとしての向き（を意味する物）はDirectionクラスが担う物だから、
Direction=向きと理解するのが妥当だと思うがどうか。

**名前は開発中のものです。** · 02/06/04 00:26

>>838
そこまで考えられるんじゃ、
どうして位置や向きを継承しようなんて考えるのかわからん。

**754** · 02/06/04 00:30

>>839
単に向きだけを表現したいのなら
そもそもDirectionクラスを定義する必要がない。
struct QUATERNION のインスタンス qDirectionを保持すればいい。
向きという属性を持って、自分自身で向きを変える事が出来、
向きという概念を備えた存在であるからこそ
Directionがクラスとして定義される意味がある。

**名前は開発中のものです。** · 02/06/04 00:39

>>841
残念ながらあなたは命名センスに問題があるようです。
ふつー、Directionクラスと言ったら方向自体を表すクラスで、
たとえばQuarternionクラスのエイリアスだったりするわけで、
「方向を持つ物」と言う意味では使わない。

**754** · 02/06/04 01:14

つーかね、君らが釈然としないのもわかる。なぜなら俺の理論には大きな穴があるからだ。
Directionには設計上の誤りがあるのだ。ThingはDirectionなどから派生され生まれた訳だが
じゃあDirectionは何からも派生されないのか？
「向きを有する存在」だが、「向き」と「存在」etc.から派生されるべきではないのか？
じゃあその「向き」は「4元数」から派生されるべきだし、「4元数」は・・
（こっから先は俺もよくわからない。暇な方は考えてみてくれ）
という感じで継承のツリーは途切れることはないのだ。
いってみれば、全てのクラスは継承で表現出来る。
継承ツリーの頂点に立つ1番始めのクラスは何か？
それぞれのクラスの持つメンバは何を持つのか？
それはそれで世界を表現出来る。マントラだ。
言っとくけど俺はキチガイじゃない。
だから俺の理屈が間違っていたというのも気が付いた。ごめんね♪

**名前は開発中のものです。** · 02/06/04 01:22

>>843
不覚にもﾜﾗﾀ

**754** · 02/06/04 01:24

俺が仮定するに、
継承ツリーの頂点に立つ1番始めのクラスは「陰陽」であり
それぞれのクラスはメンバをひとつ持つ。それも「陰陽」だ。
なんつーか真理に辿り着いた感じだ。先人は偉大だ。
それではさよなら。

**754** · 02/06/04 01:31

さよならしようと思ったが、もう一言。
クラスで世界が表現出来るなら、
それを作る俺は神と同義ということになる。

結論　俺は神
　　　　　　　　　　　　　　　　　　　　　　　　完

**名前は開発中のものです。** · 02/06/04 02:17

**名前は開発中のものです。** · 02/06/04 04:07

>>846
ﾜﾗﾀ

**名前は開発中のものです。** · 02/06/04 08:56

>>754
君面白い

**名前は開発中のものです。** · 02/06/04 10:37

俺もなんだか笑いがこみあげてきた。

**名前は開発中のものです。** · 02/06/04 13:39

みんなやさしいのう

**名前は開発中のものです。** · 02/06/04 17:04

どうもあれだが

**名前は開発中のものです。** · 02/06/04 21:39

>754
最後の展開でﾜﾗてしまたよ

**名前は開発中のものです。** · 02/06/04 22:06

>754
ったく、散々荒らしやがって。
お前が出現するまでは良スレだったのに。

**名前は開発中のものです。** · 02/06/04 22:53

>754
コイツもしかして、Yahoo掲示板で暴れまわった、
「○梶」じゃねーの？
どうよ？

**名前は開発中のものです。** · 02/06/04 23:39

俺指向プログラミング OP。
OOPよりO一つ分保守性や生産性などに劣る