オブジェクト指向に弊害はない。メリットのみ

反論したいなら
↓のスレでどうぞ。

ｵﾌﾞｼﾞｪｸﾄ指向は無駄なもの。俺が理解出来ないからね
http://kohada.2ch.net/test/read.cgi/prog/1332351520/

ここはちゃんと分かっている人のみのスレです。


前スレ
オブジェクト指向の弊害
http://toro.2ch.net/test/read.cgi/tech/1327414519/

ミサイルとホーミングミサイルの違いを
スマートに実装した
オブジェクト指向に感動した。

弊害はあるよ
コンパイラ作るのが面倒になった

ほらな

顔真っ赤にしてスレたてたんだろうなぁ
前スレで馬鹿にされたのがそんなに悔しかったの？

1000 名前：デフォルトの名無しさん[sage] 投稿日：2012/04/25(水) 22:37:37.60
以上、自己紹介でした

997 自分：デフォルトの名無しさん[sage] 投稿日：2012/04/25(水) 22:30:25.81
見積もりを工数でしっかりと出さなければならない仕事をやってはじめて
オブジェクト指向なんて無意味なものだと理解する

単純に、オブジェクト指向を適用したプロジェクトとそうでないプロジェクト
まったく同じ仕様を満たすものを作成するとしたらいくつ工数は変わるの？

って気軽に「〜ぐらいじゃないっすかねぇ・・・」なんて答えられる現場と
ちゃんと１Ｈまで根拠を求められる現場とでぬるさが違う

ヌルイ現場にいる奴に考えてほしいが
いま、てめぇがやってる仕事は非オブジェクト指向でやったときに
どのくらいの工数が増えるのか？それがちゃんと上司に報告できる形で仕事をしているか？

１つ１つきちんと積み上げていかんとなんも作れないＰＧになってしまうで
趣味でアプリを完成させられない人間とかじつは１人でプログラムを完成させる実力がなかった・・・って場合あるぜ
まず、なにやるにも見積もり・・・これが出せるＰＧとそうでないＰＧだんだん差が開いていくで

998 自分：デフォルトの名無しさん[sage] 投稿日：2012/04/25(水) 22:33:10.11
なーーーんでもおもいこみで
てーーーきとうに組んでるだけじゃ
いつまでたっても答えにたどり着けない

その思考回路のまま何年もＰＧを続けていってしまうと
過ぎてった年数分の実力を穴埋めするのは不可能になるぜ

その第一歩としてオブジェクト指向の否定があると思う
こいつをおかしいと思わないと・・・

999 自分：デフォルトの名無しさん[sage] 投稿日：2012/04/25(水) 22:34:44.91
何年ＰＧをやってても１人でなんにも作れない
そんな奴実は多いんだよね

1000 名前：デフォルトの名無しさん[sage] 投稿日：2012/04/25(水) 22:37:37.60
以上、自己紹介でした

1時間単位で求めてどのくらいの精度なの？

職業プログラマ歴20年でこの前初めてマインスイーパー書いた

まじか1時間で作る代物だぞそれは

工数の比較求めてくる人は、反論できないレスは見なかったことにして
同じ主張を繰り返してるだけだからね。

でも実際工数を根拠といっしょに出せたことないけどな
ミサイルとホーミングミサイルも結局多態のメリットは説明できず・・・って形だと思うけど？
その辺、負け犬のみなさんなにかコメントないですか？

>>12
前スレ読めばお前の言いたいこと(>>12)の
正反対が正しいってことが分かる。

正反対ってこと、勝ち組のみなさんってことかｗ

>>13
ミサイルとホーミングミサイルを多態で表現するメリットを説明できてないよね？
仮にメリットがあったとしてそれはどのくらいいいといえるの？
単純にミサイルとホーミングだけでもいいよ
たくさん必要ならそのときでもいいし
２０種類とか３０種類とか作るとメリットが見えてくるならそれを説明してくれればいいよ

ミサイルとホーミングミサイルは多態させずにそれぞれ別々に扱います。

>>15
前スレ読んだら？
俺はそれでメリットを理解した。

フログラマーならプログラムで実証しろ
誰もがうなるものを

プログラマーじゃないものを
プログラムでうならせることは出来ないだろうな。

将棋の実力がわかるのは
将棋が出来る人のみ。

馬鹿すか？

じゃあ、手始めに
オブジェクト指向じゃない方法で
誰もが唸るものを書いてみるわ。

できなければ俺の負けでいいよ。

あぁ、そうだな。
言い出しっぺがやるもんだな。

他人のプログラムとか読みたくないんですけど

俺のオナニーを見ろ！！

もうオブジェクト指向無いと他人のライブラリとか使えんしょ？

>>1
無理すんなヲタガキ

オレにしかわからない＝間違ってる

あとからどんどん違う話になっていくのに、丼じゃない工数なんて出るかアホ。
みたいな仕事しかやってないw

工数計算が精密にでると思ってる無能

まぁ綿密に工数を算出できるものが無いわけではない。

DBのフロントエンド作成作業とかだと、表示項目一つあたりの工数は既知
(基本は既存コードのコピペ)なので、あとはどれをいくつ表示するかで決まる。

帳票系の作業も似たような感じかな。

皆大好きCOBOL2002はもっと注目されていいよな
ttp://www.cobol.gr.jp/knowledge/next_standard/standard0002/cobol2002.pdf


俺は相手にしたくないが

ブルックス先生の必死の啓蒙活動もあまり周知されてないのか

こんなスレが立つのもメリットの一つ

１＋１は２ってスレ立てられてもどうしようもないだろ

オブジェクト指向の害<<<C++の害

これが問題

おまえの頭が問題

OOP厨が害悪そのもの
はい完全論破

完全論破 ♪
完全論破 ♪


完全論破 ♪



完全論破 ♪

おまえの頭が問題とか言ってる奴はおまえが全部コード書くのかといいたい

http://toro.2ch.net/test/read.cgi/tech/1327414519/
オブジェクト指向の弊害

1 ：デフォルトの名無しさん：2012/01/24(火) 23:15:19.23
非OOPでコーディングされたソースを見て発狂するアホを生み出したこと
そのくせOOPを十分に理解してないから痛々しい

---------------------------------------------------------------------------------


これ、

ようはさー、スクリプト言語みたいに手続き的に書いてると
なんかしらないけど、「汚い」とか「クラス使え」とかいってくるバカがいるって事だよね

で、挙句の果てに、OOにする必要ないのにOOに書き直したりしやがる

バカなんだよ

バカ

OOにする必要のないものをOOにして　整理整頓したつもりですか？

冗長させてることにも気づけない　＝　読みにくくなっていることにも気づけないってことは

多分もともと、ソースコードが読めていないから、それ以上ソースコードを読みにくくしてもカンケーねーよって事なんだろう



バカはしんで

2 名前：デフォルトの名無しさん[sage] 投稿日：2012/01/24(火) 23:20:49.82
と天才プログラマー「あい」は申しております。

<Sale>中国語版の書籍<文系・理系・ＩＴの諸分野>(格安)
ttp://lang-8.com/194279/journals/1457398/

>>1
PrologがRDBだとすると、OOはCODASYL方式だね。
CODASYL方式が悪いってことではないけど。

なんか、ミサイルとホーミングミサイルがどうたらとか言ってるのをみて、ちょっとクラス定義を書きたくなってきたので書いてくる。

ミサイル ＜|ー ホーミングミサイル

D言語で書いた。　え？そんな言語しらねえ？
http://ideone.com/FaXbJ

適当なので不備多し。
本当ならMissileクラスの前にもう一つクラス噛ませたほうが良いかもね。

>>46
Java出身のD使いとみた。
てのはおいといて

> public override void collideReaction(GameObject go)

これ後々嵌ると思う

>>47
うん、それだけだと絶対機能が足りないｗ
後で他のオブジェクトを追加しやすいようにそうしたけど、何か追加の機構が必要になるだろうな。

ちなみにJavaは使ったことありませんｗ

低レベルな子が
低レベルなソースを見せあいっ子して
低レベルな褒め合いをし続ける
まぁソースをアップする試みは良い

にしてもオブジェクト指向って、こんな何もない空っぽのソースコードで50行も消費するんだよな

uyは某スレでコテンパンにされライフがゼロになったコテハンなので
エサをやらず生暖かく見守ってあげてください

>>46
http://ideone.com/5mA20
Rubyで書き直してみた

ruby使いこなせてないｗ

使いこなすも･･･何も>>46ゴミカスD言語のソースコードを
まさに、そのままRubyで書き直すどうなるかって事だよ

>>46で問題になりそうな、衝突した相手に与えるリアクションの処理についての案を思いついたので書く。

単純な案ではあるけど、ありえるリアクションを種類別に関数を書いて、相手からは必要なリアクションの関数だけを実行して貰うと。
例えば、ダメージを与えるに対するリアクションの関数、吹っ飛ばすに対するリアクションの関数という様に。
http://ideone.com/ORAOw

もっといい方法があるかもしれないけど、クラスごとに自己完結する現実的な解だと思ってる。

>>51
なんの為に書きなおしたかさっぱり分からんｗ

書き直しになってないぞ
頭にバグがあるから仕方ないのかな

ん・・・　abstractされた関数がオーバーライドされてない不備発見ｗ　まあ、いいか。

>>54
俺の大嫌いな社畜設計だ

あとそれｗ　ミサイルとホーミングミサイルって
似ているものだからって継承するのはゲームじゃやめたほうが良い
完全に別物として考えて作らないと後で詰む

uyは痛い子。
仕事につくのは無理です。
放っておいてあげてください。

>>51
書き直しになってないぞ。設計かわってる。

>>57
ライフすら考慮できないのに上から目線かっけー

このD言語のソースあげてる奴って
メッセージがどうとかいってた奴でしょ
どんなゴミを作るのか見させてもらおうかな＾＾

uyって最低な奴だな
他所でいじめられたからって八つ当たりかよ

>>61
誰それ。
そもそもC++系のクラスを実装した言語で、メッセージがどうの言われてもちょっと困る。

>>54
それって何が多態になってるの？
結局ホーミング特有の関数呼ばないといけないのと違うの？

メッセージの意味理解してなさ杉

君がGameObjectを渡すようにかいているその引数のところにメッセージを送るって話だよ
それが100点の設計とは思っていないけど90点はとれる

え？これ多態の利点はどこに生きてるの？

Fieldの中身がもう少し詳しくないと伝わらないのかな

>>65
90点の根拠はいったいどこから？

>>64>>66
FieldクラスのgoにMissileもHomingMissileも突っ込める所とか、
GameObjectクラスに属するクラスのtimeForward()を呼び出せば、勝手にオブジェクト固有の処理をしてくれるとか。

>>65
それ・・　本当にC++系クラスの話だよな？ｗ

>>69
それは仕様の何を満たすために必要な機能だったの？
また、汎用性をみたなら今後どういう仕様変更に耐えられる構造になったの？

そのゲーム設計に言語関係ねーよ、初心者なの？

ミサイルでもホーミングミサイルでも何でもいいけど
オブジェクトに対しての操作を外部から行う為に
メッセージ受信、送信できるようにしておくって話
そうしないとオブジェクトの状態を表す為の変数がゲーム作っていくにつれてズラーって増えていくんだよ

そもそもミサイルとホーミングミサイルを共通に扱えると何がいいの？

>>71
それのメリットってなに？

またその話繰り返すの？あきないね

>>71
オブジェクトの状態とは？

>>72
そこだよねｗ

ミサイルクラスをホーミングミサイルクラスに継承しちゃいけない

オブジェクトが継承していいのはGameObjectクラスだけ

>>76
肝心の理由は？

>>76
ライフの想定を忘れてるぞ

>>70
例えば、レーザークラスなんかを簡単に追加できるように、という設計をしてる。
この設計だと、他の部分は変更せずに、レーザークラスに処理を書くだけでいいんだぜ！

まあ、新しく反射する、とかのリアクションを用意しないなら、だけども。
その時でも、GameObjectに対応する関数を書いておけば、全てのGameObjectを継承しているクラスは、基本的なリアクションが実装されるようにはなってる。

そもそもミサイルとホーミングミサイルを共通に扱えると
自機がミサイルにあたった時と
ホーミングサイルにあたった時の動きを
共通化出来る。

>>79
え、「反射する」っていう処理が必要になったら
GameObjectに対応する関数をかくの？

>>80
いや、違う処理だから別にいいよ

>>81
お前はシーンに書くって言ってたっけ？

>>82
> いや、違う処理だから別にいいよ
勝手に仕様を決めないで下さい。

同じ処理です。

>>84
仕様の勝利

>>82
同意、
最初は同じで作ってもいいけど後から違う処理になるんだよね

>>84
「同じ処理」しか出来ないから仕様変更に弱い設計って事ってダメだししてる

>>81
GameObjectに基本的な処理を書いておかないと、この設計は破錠するんだ。
もちろん、反射するに対するオブジェクト固有の処理は、そのオブジェクトに書くよ。

>>84
やだよ
だっせーもん

ホーミングミサイルは当たったら派手に爆発だけしてほしいけど
（相手を押してしまうと連発で出した他のホーミングが当たらない可能性が増すので）
ミサイルは威力があるのを見せるためにちょっとだけ相手を押してから爆発してほしい

ライフの想定を忘れてるぞ＝志村〜後ろ後ろ
の意味だからuyは気をつけた方がいいかもね

>>86
違う処理にしたくなったら変えればいいだけだろw

>>88
ホーミングなのに当たらないの？

>>90
その作り方だと、いつの間にか"簡単には"変えられなくなってるから

>>88
補足しておくと、相手を飛ばす力の処理（アクション）は、そのオブジェクトのcollideReaction（）に書く。
blownReaction()は、そのアクションに対するリアクションの処理（例えば、吹き飛びにくいとか）をする。

>>91
ホーミング性能をあんまり良くしちゃうとプレイヤーが避けられない
なので寸でで避けると（＝１発目が相手をズラしちゃうと）ホーミングだから高確率でスカる可能性がある

>>87
おおよそ君の考えを理解した
例えば、「A」の処理がミサイルと、ホーミングミサイルで必要であれば
その処理は、ミサイルクラスに書き
「B」の処理がミサイルと、その他プレイヤー等でも必要であれば、GameObjectクラスにかくわけか

60点かな

100点の設計を示してね

>>95
ちがうよ。
何かリアクションを追加したいと思ったら、固有の処理が必要なオブジェクトの関数の他に、必ずGameObjectに基本的な処理をする関数を定義（空でもいい）する必要があるんだ。
じゃないと、Fieldでそのリアクションの関数を呼び出せない。　
固有の処理をしてるオブジェクトに合わせてFieldにコードは書かない。

>>92
理縫は？

っていうか全オブジェクト共通処理ってどんぐらいあるの？
いらなくね？
ミサイルとホーミングミサイルだって同じ仕様ってゲームねーよ
みたことねーよ

補足のために、FieldクラスのtimeForward()に仮想コードを追加したよ。
どういう設計か少しは分かりやすくなるはず・・・
http://ideone.com/kfPq3

>>99
相手にダメージを与える、爆発する、燃料を消費する・・・　など。

>>97
は？ｗ
＞何かリアクションを追加したいと思ったら、固有の処理が必要なオブジェクトの関数の他に、必ずGameObjectに基本的な処理をする関数を定義（空でもいい）する必要があるんだ。
＞じゃないと、Fieldでそのリアクションの関数を呼び出せない。　

D使ってるから少しは出来るかと思ったら、思ってたよりもはるかに初心者だわ
マジでやり直せ　人生

いいから100点の設計なり実装なり出せよ

なんで1個の処理を追加する為に、2度手間が必要になるような設計にした？
言語に詳しくない？

>>101
ミサイルとホーミングミサイルの当たったときの処理が違う時点でどうでもいい気がすんだけっちょ？
なにかいいのそれ？

武器弾薬リアルタイム発注システムを採用したシューティング

戦闘中に使用し減少した弾薬や痛んだ機体の補修パーツを適宜発注依頼しておかないと、次ステージで修理補給なしで挑まなければならない
ミサイル的なものと、投下爆弾的なものと、機体的なものと、etcは、発注先が違う。ようはミサイル屋に発注するときの一覧にはミサイル的なものだけリストアップしたりする

ミサイルとホーミングミサイルは別クラスの人は
ミサイル的な一覧出すときどーすんの？

>>104
だからお前はどうやって実装すんだよ？

http://codepad.org/MKENerbj

>>104
１個じゃないよ。
GameObjectを継承してるオブジェクトでの基本的なリアクションと、オブジェクト固有のリアクション数個の、１〜ｎ個だよ。
てか、C++系クラスの仕様をちゃんと理解してないみたいだけど。

>>107
ミサイル的なものは全てミサイル継承クラスだから問題なし

>>109
もっとダメじゃねーか･･･
頭大丈夫？
なんで1個の処理を追加する為に１〜ｎ手間をかけなきゃいけないの
C++系のクラスの仕様がそうなっているならそこの仕様をよけて作れよｗ

>>105
実際当たった時の処理が違うとしても、ダメージを与えるの部分の処理とかは使いまわせるんだ。

オブジェクト指向の「オブジェクト」を、
ミサイルみたいな「物」の事と混同してるうちは、結論が出る訳が無い。

>>111
俺は別に、同じ処理を複数個書くとは言ってないぞ。
定義したcollideReaction()の中身は全部違うもの。

>>114
そうじゃなくてソースコード中の編集箇所の話だよ
何か処理追加する為には
GameObjectクラスに空でもいいからメソッド定義が必要なんだろ？
頭悪すぎるだろ

>>108
なんであっちこっちに当たり判定があるの？

>>116
そういう話題のときに提示したソースだから

>>115
例えば、新しく反射する、ってリアクションを追加したとして・・・
Missileクラスのインスタンスで、反射に対するリアクションの関数を呼び出した時に、GameObjectクラスの反射に対するリアクションの関数が呼び出されるとしても？

てか、まじめにC++系クラスの講座しないといけない系？
自分で調べてきて欲しいんだけど。

>>117
ぜんぜん関係ない話じゃん
ミサイルやらホーミングミサイルの扱いはどこいったんだよ

>>118
君は「C++でミサイル、ホーミングミサイルを実装」したいわけ？
それとも「ミサイル、ホーミングミサイルを実装」をしたいわけ？

後者だったら、わざわざC++やってるのが悪いんだから言語ごとの都合はどうにかしろよｗ
1個の処理追加のためにいくつもの手間をかけなくちゃいけないのがおかしいといっているんだよ

>>119
自機、自機ショット、敵、までは実装してあるけども
どこまで作ればいいわけ

ホーミング用のアルゴリズムのソースはどっかいったから正直実装面倒くさい

ミサイルとホーミングミサイルは継承すんな派のやつらは
>>106 は都合が悪いから無視？

>>121
自分で言ってることを全部きれいに解決できるようになってんの？

ためしにミサイルとホーミングを実装してみてよ
ホーミングのアルゴリズムは本質じゃないからどうでもいいからさ

>>121
それがお前の実力つーか限界だろw

そういう次元のところまでゲーム作ってから喋ろうね
君の設計じゃそこまで作る前に破綻するんだから･･･


また初心者を煽りすぎてしまった＾＾

uyよ。
参考までに聞きたいんだが
これ>>108 何点なの？

なあ、他の人に聞きたいんだけど、Rubyで同じ設計をしたとして、GameObjectクラスで反射に対するリアクションの関数は実装しなくていいの？

>>125
だからその破綻しない設計(or実装)を見せてくれって言ってるの
自分でも解決できないのに人にいちゃもんつけてんの？

そろそろUGLの時間か

UGL＝uyの自作してきたGameにはLifeはなかったから

>>126
最低限のセットだからそれ20点くらいだよ
100点にするには、あと1000行くらい色々と追加しないといけない
オブジェクト全体を木構造にして、木構造操作系のメソッドを用意して、
task.pushとかやってるそれを、まずyieldにしないといけないから面倒

>>127
思考してる箇所がもはや違うんだってば
何か本でも見ながらやってるわけ？破り捨てろ

誰もゲーム全体のデザインをしろとは言ってない

ミサイルとホーミングミサイルを自分が上げた問題点をクリアできるように
実装してくれよ

誰も答えないから自分で試しちゃったよｗ
http://ideone.com/km7BQ

なんだ、同じか。

Rubyってとんだ駄目言語だったんだな
たったそれだけの仕様を満たすのに1000行以上必要なのか

>>131
108でクリアしてるんだけどもｗ

すきじゃないけど一応OOでも書いたよ
http://ideone.com/Il5jC

>>132
rubyで書くならそもそも継承を使わない

106はー？

>>106って･･･設計じゃなくて
作っていく段階において、その場で書くアルゴリズムの分類だろ
区別しろよ

継承なんかでのインターエースの共通化はね、
いわゆるアプリケーションロジック(ゲームロジック)に
関わる部分では使わないほうが良いよ。
何でかって言うと、仕様変更が大いにありうるから。
もっと基本的な部分、たとえば描画ライブラリだとか、
サウンドライブラリだとかといった、
下位レベルの普遍的で仕様変更がなさそうなところで
ビシバシつかったほうが良いよ。
ミサイルクラスとホーミングミサイルクラスで、
どういったインターフェイスが共通と成りえるかは、
開発初期ではハッキリしないし、開発後期になってから
クラス階層が邪魔に成ったりする場合も大いにあるよ。
ホーミング機能付ミサイルクラスを作っといて、
ホーミングが必要ない場合はOFFにする、とかでも良いぐらい。

つうかミサイルと、ホーミングの話題って
def homing
#ホーミングしてもいいし、しなくてもいい
end

これですべて結論ついて終わった気がする

ミサイルクラスの中にTypeとかいう変数で属性もたせて終わりじゃね
つーか、ミサイルクラスじゃなくてｗ
ショット関係は
Shot　で1クラスで管理してTypeをもたせて終了

どこに悩む箇所あった

>>134
ミサイルがホーミングするかどうかはどこに書くの？
パラメータだけで設定できないようなホーミングをするミサイルを使いたい時はどうするの？

>>140
＞ミサイルがホーミングするかどうかはどこに書くの？
ホーミングミサイルだったら
オブジェクト生成のときに、追尾角度とか指定することになるだろ？そこ0にしとけばホーミングはしない


＞パラメータだけで設定できないようなホーミングをするミサイルを使いたい時はどうするの？
そもそもパラメータで設定しないんだよ
設定するのは、x,y座標とか、その他の最低限のみ
:functionって変数あるだろ
実際の動きは、動きを記述した関数やら（lambda）を、そこのfunction変数に入れて実行させる

>>137
都合悪かったんですねー

>>139
ネーミングセンス酷いな

>>141
ふむ・・・
と言う事は、基本的なホーミングをする関数と、変わったホーミングをする関数を個別に作るのね？

>>144
そうなるね
Rubyだったらlambdaで楽に渡せるけど
C++なら関数ポインタを渡す事になると思う

>>145
じゃあ、もうひとつ。
ミサイルに酸を掛ける、というアクションを追加したい時はどうする？　もちろん相手のリアクション含めて考えなきゃ駄目だよ。

・・・C++って最近ラムダ式追加されたんだよね。　Dにもごく最近。

やっぱりね
結局ミサイルとホーミングミサイルとを同一視してる

>>139
着弾なしに時限式で爆発して周囲の一定範囲を巻き込む時限ミサイル
そのホーミング版
追加してくや

追加してみてくれ

>>146
ミサイルのところに持たせたfunctionに、そういうものを追加すればいい

言い忘れたけど、ミサイルのところに持たせたfunctionからは
ゲーム中の全てのオブジェクトにはアクセス出来るようにしておく
そうすればどこからでも何でも出来るようになるから

なんていうか、オブジェクトごとにfunctionをくっつけて
余計なメソッドは定義せず
なるべくfunctionで全部やらせるんだよ

>>150
リアクションはどこへ？
受けた酸がどう効くのか、もしかしたらばら撒くのか、とかはどうするの。

>>150
ミサイルの保管状態によってホーミング精度が変わる場合は？

>>148,149
お前もわかってないの･･･？


えっとね、時限式で何かアクションするオブジェクトは、
オブジェクト生成時に、〜ｎ秒で爆発するよみたいなパラメータを渡さなければならないとか、思われがちだが
そうではない

オブジェクトごとに、オブジェクトの動作を記述する為に「自由に使ってよい状態メンバ変数」
ってのを用意するから
そこで悩むことないんだよ

>>153
煽りはいいからやってみてくれ
そのあと困ることになるから

>>152
それも>>153の
「自由に使ってよい状態メンバ変数」

C++だったらSTLのmapか何かを全オブジェクトに持たせたらいいよ

>>155
状態変数はいいから
処理はどーすんの？ってのが大事。
どこにかくの？

http://ideone.com/LyfeC

はい

>>156
状態変数いらんの？

処理を書く場所は、
オブジェクトの動きのパターンを集めたクラスを作るんだよ
Rubyだったらちょっとしたものなら直にかけるから直にかいてるが

C++ならそういうクラスを作り、そこのメソッドのポインタをもってきて
function変数に格納すべし

>>157
時限式ホーミングは？

>>159

>>157
これで理解しないならｗｗｗスレ閉じろｗ

>>158
へー。そのクラスには、ミサイル、ホーミングミサイルの動きが共に書かれてるんだ？

これはだるい
誰かにパスしたい

>>160
仕様>>148を満たせてないんだから

>>162
もうわかったか？おまえの構造の致命的な問題点が

俺は46しか相手する気ないぞ
ostructをメンバに入れた事がどういうことかわかってないなら
まずruby OpenStructでググレカス
それを入れた時点で通ってんだよ。全てが。
ostructがはいった事、そして全オブジェクトにアクセス可能な事、この2点でクリアしてんだよあほか。

大体のヒントは与えた
これ以上の面倒は見ない
あとは名無しにでもたよれよ

uyもまた昨日みたいになったら困るから
そろそろ退散か

初心者過ぎてやる気がしない

てか、もうよくね？
多態で縛ってしまうと汎用性がかなり低下してしまうってのはわかっただろう
書いてみた結果として同じだったらリファクタリング時に多態で表現するって方法でいいんじゃないか？

ゲーム作ってる途中にこんな仕組みいれないほうがいいよ
コピペしたほうが速い

uyって調子づいて荒ぶる割に
都合悪くなると言葉濁すよね

コピペした方が速い(ｷﾘｯ

>>168
ミサイルが1000種類あってもコピペ？
コピペ元にバグ発覚したら？

もうよくね？
無理だよこいつら

いまのところuyがこのスレ最低得点保持者です

ライフに続いてまた想定もれか

普段ゲームを作らない奴にゲームプログラムの話は無理だったな

アプリ開発はやったことあるから、ゲームだって同じように作れるんだ！
みたいに勘違いして、熟練者の意見を聞かない

そんで、実際にその洗練されたソースコードを知らないから、
｢こういうときどうするの？」っていちいち聞いてこなくちゃ次に進まないｗ

まるでサルに日本語教えてる気分になってバカらしゅうなった

いいじゃないか、大体さープログラミングやってて自力でゲーム開発して
ちゃんとした設計できるようになってないで2chで聞いてるようじゃセンスがないんだよ

ゲームエンジンや、ゲームライブラリ、ゲームの根幹設計、そういうのを作るのが、面白いと思う奴もいる
そういう奴はちゃんとした設計を知ってる
それらを面白いとは思わず、
ちょっとした気まぐれで「ゲームでも作ってみるかｗデュフフｗ」とかいいながらソースコード書いてる奴なんて
何を教えたってみにつかねーわ･･･

勝手に、OOでゲーム作ればいいし、
もう勝手にアプリケーションと同じ気分で作っていたらいいんじゃね
専門分野が違うところにきてるお客さんなんだよ、
今日1日しか、あるいはほんのわずかな期間しかゲームプログラムを行わない者に対して、何か教えようとか無理だった

ゲームで言うと、世界樹の迷宮と女神転生SJの関係は、上手い事オブジェクト指向を活かしてるなあと思った

>>175
ライフ君が吠えたw

>>175
自分より実力ない奴から教わるバカはいない

uyって既に底が割れてるからネタとしてみるには面白いな

それにコピペ　の意味もわかってねーし
コードの部分の話じゃねえよ
クラスの宣言部分の話だろうが
それにコピペでどっかバグってたんなら、5秒でスクリプトかいてバッチ処理ソースコードにやればいいんだよカスが
そのくらいはゲームPGだったらできんの。

ミサイル1000個ってなんだよ？
バカ？
オブジェクトの数じゃねーんだよ
ミサイルの種類が1000個もあるゲームてどんなミサイルゲーだ
ドッターの身にもなれ

----ここまで音にたいしての話題なし----

ハッァアアアアアアアアアアアアアアア？？？
ゲームで大事なのは　音　→　背景　の順番だろバカなのｗｗｗｗ
そもそもこんな板にいる社畜はまともにゲーム作る気もないし、
効率良くゲームを作る気もない、ただ、「僕の考えた設計ｗ」を見せびらかしたいだけ･･･

んで、同じようにレベルの低い奴が、ああああああああああ考え戻った>>49 これだよ。　俺は今ここの気持ちに戻った。終わり。

低レベルな子が
低レベルなソースを見せあいっ子して
低レベルな褒め合いをし続ける

>>180
クラスの宣言部分をコピペするバカは今時いない
アナクロにも程があるぞw

>>180
スレタイ読めば？ここゲームスレじゃないから
おまえはどうせ就職できないんだから
もう少し謙虚になった方がいいぞ

だから、

それ　やる　より　は　こう　した　ほう　が

　ま　だ　マ　シ　だ

って　いう　ある　種の　ネタ　反論


そんな、だるい方法で0点設計するくらいの思考しか出来ないなら、
バカでも出来る10点の設計があるよって言ってるだけだよｗ


誰もそれがいいとかいってねえ･･･

な、無理だろ

無理　不可能

はい無理

>>184
すまんかった。
やっとわかった。
バカのエースuyでもコード書けるよ！って主張だったのか。

46でもかけるよって事だよ
46みたいなコードかくならコピペのがマシだよって事だよ

つーか本当のこというと、継承してたってゲーム作れるよ　俺なら作れるよ
でも初心者には、そんなゲームプログラムの仕様変更の何手先も読みながら、
作れないだろって思ってるから
やめとけって言ってるだけ
終わり

----------- ここからOOの話に戻ります -------------

uyは出来てないだろw
ライフすら想定外だったんだからww

トリップつけろバカ

>>171
え？１０００種類もないよ。

ここの人は鱈と肝臓が大好きなんですよ

クラスの仕組みすら分からない奴が偉そうにｗ

Ｄ言語だと１０００種類できるらしい

は、そうだな

また俺の負けでいいよ
俺はもうC++を触る事ってないだろう
今はどうやってrubyで速度だすかしか考えてない

本家rubyでまともな並列化できりゃ楽なのに、どうしたものかね
rubyマルチプロセスプログラミングでゲーム作るしかないのか

>>195
１０００種類作りたいだけなら>>100のコードでも、>>157のコードでもできるけど。
まあ、実際に１０００種類考えるのはやりたくないがｗｗｗ

俺が>>157のコードに強いて言うなら、クラス機能の内部でやっている事を自分のコードで表現してるって事くらいか。

俺はクラス使わないからね
多分どんなゲーム作るとしても、最初から最後までclass O以外に宣言しないよ

ゲームじゃなくてアプリ作るんだったらクラスは使う

結局使うのか

> また俺の負けでいいよ
そりゃそうだろｗ

>>196
> 本家rubyでまともな並列化できりゃ楽なのに、どうしたものかね
> rubyマルチプロセスプログラミングでゲーム作るしかないのか

めちゃくちゃ重くなりそうだなｗ

ま、経験ないとわからないか。
Rubyがゲーム開発としては重いってことがさ。

>>199
アプリ側でもクラスを使わない設計案はある
でも俺はまだ上手くかけないので妥協してる
でも、そのうちクラスは完全に捨てたいと思っているよ

>>201
え？え？誰に言っちゃうのそれ

つうか独り言、
今、C++のソースが見たくてたまらなくてググってた
プログラミングって
int main(){
とかってエントリーポイントあったほうがしっかりした言語に見えて
心の中の何かが盛り上がる気がする
そんなint mainなんてないほうが効率いいのに、どうしたものか？

RubyからDXライブラリを何とかして使ったらいいんじゃないかと思ってる
dxrubyは確かに小さくまとまってて使いやすいでも、
それじゃ遅いんだ
できるかね

遅い　じゃない　機能が　無い　だ

http://d.hatena.ne.jp/kwatch/20100430/1272585083

これを見れば、最速な言語は C/C++ であり、Java や Haskell や OCaml
といった静的な言語は軒並み上位に登場する。これに対し、Ruby や
Python や PHP といったスクリプトは全部下のほう (つまり遅い)。

その速度差は非常に大きく、このベンチマークで見ると Python3 や
Ruby1.9 は C/C++ の約50倍から60倍遅く、Perl は約90倍、
PHP にいたっては約130倍遅いことになる。

そんなたいそうなもの作るわけじゃないし
速度はどうしても問題が起きてしまうときに考えればいいべ

問題が起きてから言語を変えるのか？

結局のところ、
ゲームの話で経験有るの？とか言っておきながら
Rubyでゲームとか、経験無いでしょｗって
笑うしかない。

>>208
ゲームなんてごまかしばかりじゃん

>>210
そりゃお前の人生だろｗ

>>207
たいそうなものではないが、弾幕ゲーまた作りたくなってきてるんだよ
速度が必要

ｐｓ：
RubyからDXライブラリ普通に動くｗｗｗ

3Dじゃないのなら速度はいらんなｗ

いらないな

>>209
Rubyでゲームライブラリはかなりあるぞ

弾幕ゲーってポリゴン数、多くても千程度だろ？

当たり判定の処理もあるから
マルチスレッドにしないと一般PCじゃ1000でもきついんじゃなかろうか

>>215
１．Rubyにはゲームライブラリがない
２．そんな世界なら俺でも有名になれるはず
３．みんなこぞってライブラリを作り始める　←　今ここ
４．優秀で企業サポートがあるものが生き残る　←　やっと実用レベル

>>217
Rubyだとその程度の感覚なのかｗ

ぼくのぱそこんせれろんでーだからよゆう

ぼくのはせれろんえむだからまるちすれっどにしてください

どこかの馬鹿がオブジェクトごとに当たり判定処理をするとか
言っていたが、そんなことをすると、効率が悪くなる。
（省くことが出来るはずの当たり判定処理をしないといけない）

当たり判定を行う専用スレッドを作るという発想なら
問題ないが、オブジェクト自身でやるとかアホの極みｗ

> どこかの馬鹿がオブジェクトごとに当たり判定処理をするとか

っていうのは、１オブジェクト＝１スレッドで、
スレッド自身が当たり判定処理をするという意味ね。

釣りレスが多くてこまる

>>222-223
一瞬納得しかけたけど
アホなのか釣りなのかどっちだよｗ

別にかわらんよ

firefoxとか巨大プロジェクトの、それもいろんな規格を無理矢理統合してるようなもんから
ソースコードひっぱってくるとか無茶すぎるだろｗｗ

Linuxからソース引っ張ってくるのと同じで手間ばっかりだわ。


せっかくライブラリがいっぱいあるんだからそっちから使えるもの探せよｗ

>>226
ここ数日のム板には俺よりヤバイのがいる
いずれコテハンに化けると思う

>>227
コテハンになるのは、ヤバイやつだけだｗ

あいあい

発言に意味がないからハンドル名に違いを入れないといけなくなる

あいあい

rubyが色々出来すぎてやばい

俺が今までC++でやってきた事は
全てRubyで出来るようになってしまった･･･
マジどうしよう　これやばい

どうしたらいいんだ･･･なんだこれ　なんぞ。
何･･･

Rubyは、おそいのだ。しろうとは、速度とか描画とかに注意が行くよ。ソースよまないよ

Rubyは器用貧乏だな。

組み込み全盛のこの時代に、「出来る」だけで言語選んでたら生き残れねーよ・・・
次の戦場は家電だろうに、rubyの出番はこの先もずっと無いよ

そもそもスクリプト言語って組み込みで使う用途ではないだろう
何をいっているんだ？
どんな言語でプログラミングするにしろ、
スクリプト言語のひとつも併用して使わない開発でどんな効率が出せるというんだ

mrubyとか一応でたみたいだけど、どうなるのあれ

Rubyって糞遅いからおもちゃだろ
バカの一つ覚えみたいなステマ飽きたから
OOの話しようぜ

ステマのほうが馬鹿のひとつ覚えに見える

馬鹿の一つ覚えの方が馬鹿の一つ覚えにみえる

OOの方がバカの一つ覚えにみえる

トンカチを持つ者には全てが釘にみえる

糞遅いRubyでゲームwww

OOの話しよーと思ったけどスレタイで結論でてた
〜終了〜

uyのアレって意味分からないよね。
座標系の親子関係と生存管理の親子関係で、
親が一致するとは限らないのにね。
擬似マルチスレッドで継続するのも意味分からない。
結局はプログラムカウンタで状態を保存するってアイデアなわけだけど、
プログラムカウンタは一個しかないんだから、
複数の状態が絡んだ時点で破綻するわけで。

変数のスコープがメンドクサイって奴の相手してもしょうがねぇだろ。

>>243
意味わかったら凄いから、誇っていいよ

親が一致するとは限らないのは確かにそう、でも別に1つのオブジェクトの中から
ゲーム中の全オブジェクトに辿れるからどうとでも都合は効く
けどそこは直すかもしれない、素で自分で木構造で管理するのはやはり、木構造操作系のメソッドが10,20と増えていってバカらしい
基本的に平坦な配列で管理をして、木構造が必要になったときに平坦な配列を木構造のように扱えればそれで良い気がしてきた

マルチスレッドかタスクかは作り方の問題、殆どのゲームはタスクだぞ
まぁ最近はゲームもオブジェクトごとにマルチスレッドの流れかもしれないけどな
俺としては、それやっちゃうと同期処理が無駄になると思うから、
プレイヤーオブジェクトやMAP等の主要オブジェクトのみをスレッド化する構想を考えてる
でも今の本家rubyだとマルチスレッドにしても速度上がらない

プログラムカウンタは一個しかない？　OpenStructの仕様を調べろ

>>241
あ、ごめんそれ
俺は昨日の段階でクリアしちゃった･･･

ベンチマーク測るのこれからだけど
多分行っちゃったな･･･

あいあい

>>245
みんなそんな事わかってるよ。

面倒になっただけじゃん
普通に組めばそんなことしなくていいのに

俺は自分が一番やりやすい方法で組んでいるだけ
お前らは使わなくていいよ

俺は自分以外も含めて、一番やりやすい方法で組む。
先人の知恵ってやつだｗ

自分で新しいもの見つける事をしないならそれでよい

Rubyしか使えないとかわいそうな人になります

>>252
ゲームで一番大事な音と背景は作れるようになったか？

↓これをよく読みましょう。

748 名前：デフォルトの名無しさん[sage] 投稿日：2012/05/04(金) 01:40:56.79
A または B と言ってるのに

uyはAだろ？
Aって言っただろ。
Aのみだろ？

って変な話をしてる。



自分以外も含めて、つまり、自分 または 他人 と言ってるのに
uy は他人のみだろって変な話をしている。
これがuyは読解力がないねって言われる所以でもある。

ゲームで一番大事なのは本を読むこと

違うと思うよ
ゲームで一番大事なのは、
自分の作ってるクソゲを面白いと錯覚し、完成まで持っていける能力だよ

完成させるのは最低条件
売れないだろｗ

>>250
お前の欲しいのは、ゲームオブジェクトデータベースだろ。
条件にマッチしたゲームオブジェクトを列挙するっていう。
単一の親子関係にこだわる必要は無いだろう。
もっと柔軟に考えてみては？

あと、継続は独立した処理に向いている。
ゲームなどの相互作用が多い処理には向いていない。
向いてるのは、サーバのセッションの実装とか。
道具は用途を見極めて使わないと悪用でしかなくなる。

>>257
やはり音と背景は作れないクズだったか

>>259
俺が作りやすい方法で作ってんだ。
口出すな。

OOスレ何だからOOと比べてどこが優位かくらい書けよ

>>250>>259>>261

名前欄つけ忘れちゃったのかな
自演おつかれさまでした！

>>261
涙を拭けよｗ

うｙ必死だな

>>259
俺はあれを、1年前の今日あたりに完成させ
それからずっとOOやクラス捨てて使ってきてるんだよ

別に君らは使わなくていいからほんと

一方俺は10年前に完成させていた。

>>266
何の自慢なのかさっぱりわかりませんｗ

>>266
一年前でそのレベルって自虐ネタ？

>>255
ひと目で、よくよくそれを理解出来るな？
>uyはAだろ？
これは、uy=Aと理解してしまうぞ。

本来なら
--------------------------------
uyは

Aだろ？
Aって言っただろ。
Aのみだろ？

って変な話をしてる。
--------------------------------
と書くべきだ。
まずは、自分の文書力からだな。

たかが改行に一つにｗ

>>270
uyの文章力を模倣してる部分だから、>>255そのままでいいんだよ

初心者つか、論外初心者が最近いるんだよね
このオブジェクトスレに

エサ与えてやってたけど、そろそろ飽きたな
もっと有意義なことをするがよい

>>273
たくさん教えてもらえて良かったね！

教えたのは俺の爪の垢レベルだけどな。

uyが凄いのは常軌を逸する斜め下をいく理解力

これだけ頭カッチカチな奴には普段なかなかお目にかかれない

お前らが何で盛り上がってるのか分からなくて少し寂しい

隔離スレ

aiai

道化師は聞かぬフリで おどけた･･･

オブジェクト指向スレなのに、ゲームオブジェクトの話を持ち出す時点で、
「言葉が似てるから意味も似てるんだろう」レベルの理解ってバレバレ。

何でいつもゲームの話になっちゃうのかと思うところだが、
ゲームは相互作用が多くてOOPをあまり生かせないからだろうか。

オブジェクト指向分析的な概念がまだ理解が進んでないからだろう。
そもそもSimulaはモデル群の相互作用を取り扱うために生まれてるのに
いまだに相互作用の取り扱いが理解されていない。

志村がどうした？

>>283
>何でいつもゲームの話になっちゃうのかと思うところだが、

ゲームくらいしかプログラミングの目的がないやつが語ってるからだろ

事務系ソフトみたいにＤＢの読み書きと加減乗除ぐらいの計算しかないのもでも
オブジェクト指向ってメリットあるの？

オブ脳にはなりたかねえよ

オナニー理論ばっかりごちゃごちゃうるせぇ
ミサイルとホーミングミサイルぐらい多態でまとめてみろよ
こんなのできないならもう多態なんて役に立たないと割り切れよ

誰がみてもできそうじゃん
でもできない
この時点でオブジェクト指向のなにかが崩れた気がしないか
なぜこれに対しては役に立たないのか？
どんな場合なら役に立つのか？
しっかり考えてみるのもいいと思う

>>287
カプセル化して凝集度上げるだけでテストしやすくなるし
処理を入れ替えるのも楽

GoF本でもトレードオフのことは書いてあるし
スレタイみたいにメリットのみとは言い切れんけどね

いまどきオブジェクト指向の是非を語る奴は、職業変えた方がいい。
空気みたいに当たり前のものだろ。

>>287
バッチ処理メインなら必須では無い。

ここ10年度位は、インタラクティブ性(インクリメント検索とか、数値バーを動かすとグラフ図形がリアルタイムで変化するなど)の要求が増えてるので、要件定義段階から、オブジェクト指向を使った方が楽。

オブジェクト指向は空気のような存在
アスペクト指向は水のような存在
UMLは電気のような存在
アジャイル開発はガスのような存在

>>287
> 事務系ソフトみたいにＤＢの読み書きと加減乗除ぐらいの計算しかないのもでも
> オブジェクト指向ってメリットあるの？

フレームワークってあるよね？
フレームワークってのはたいがいオブジェクト指向で作られてる。

もっとも他人が作っている部分ではあるが、
フレームワークを含んで事務ソフトだから、
使う意味有るの分かるでしょう？

>>289
ほれ。バカだなおまえ
class ホーミングミサイル extends ミサイル

>>290
カプセル化とか書いている時点でOOを理解出来ていないのが分かる。

>>291,293,294
業務系で大規模と言えばホストだが、ホストでOOが一般的か？

狭い知識と浅い技術力でしゃべるな、アホがばれるぞ。

>>296
釣りはもう少しうまくならないと。。、

>>296
大規模業務系の話はどこから出てきたのよ
…てか、今はCOBOLにもOOP機能が搭載される時代よ
使うか使わないかは別として、あって当たり前と考えられてる機能

>>295
話しかけるなよ雑魚が
早く死ね
ほら吹きＰＧ

>>299
頭悪くてかわいそう。。。

>>300
自分で頭いいと思ってるなら
さっさとミサイルとホーミングミサイルの多態でも表現してみせろよ
どーせできないんだろ？な？ｗ

>>301
おまえにだけ出来ない。諦めるんだな(´･_･`)

>>283
ネタバレするとそうだよｗｗｗｗｗｗｗｗｗｗｗｗ
ゲームの世界でOOPは必要ないから
絶対に勝てる話題を出して、
「ゲームをOOで作ろうとしてるアホ」を釣って論破するのがそもそもの目的

そこまで分かってる奴は面白いからまたやってみるのオススメ　

>>289
多態とかそんなところで使うなよ

ミサイル、
ホーミングミサイル
なんとかミサイル
なんとかミサイル
なんとかミサイル
なんとかミサイル
なんとかミサイル
なんとかミサイル

ってでてくる可能性もあるのに、多態はやめろ

>>298
>大規模業務系の話はどこから出てきたのよ
大規模開発にOOがむかないと認めたか。

>…てか、今はCOBOLにもOOP機能が搭載される時代よ
>使うか使わないかは別として、あって当たり前と考えられてる機能
"使うか使わないか"が大事なんだが、アホか？

日本のプログラマーの中では、
OOPを理解できただけで優秀な部類になってしまうから
自分が一生懸命理解したOOPのさらに
その上とか、存在しないことにしたいのですよ

上って？

一番上はアセンブリ。

アセンブリはOOと並べるもんじゃないよね

関数型って事でいいよ

46に教えててちょっと思ったけど
クラスを作らずに関数オブジェクトや関数ポインタを渡して
済ませるやり方って、どちらかといえばオブジェクト指向じゃなくて関数型だったは

OOで作るんだったら、
ミサイル、ホーミングミサイルも、継承とか色々やっていくのが「正しい」とされているんだろうな
つまりOOがカスなのだ

あいあい

アセンブリから適用範囲を絞ることで出来ることに制限を加えて
構造化言語→OOPと進化した。
uyの言う「上」ってのがどっちの方向かしらんが、
適応範囲を広げる方向だとアセンブリや機械語に行き着くし、
進化の方向だったらDSLに行き着く。
大事なのはバランス。
一般的に中途半端でバランスがいいといわれているのが、
C/C++系かねぇ。
OSが書けるぐらい何にでも使える程度の制限だし、
開発効率もそこそこある。汎用言語の王様だね。
でも今の時代は目的に応じて使い分けるのが主流かな。

uyって自演失敗してた奴だろ？

>>311
未熟なおまえにこのスレは10年くらい早い
巣に帰るんだ

>>303
> ゲームの世界でOOPは必要ないから

どの本見ました？

ゲームの世界はほぼすべて
オブジェクト指向ですよ。

>>316
(>>303が辛うじて書くことが出来る方法で作る) ゲームの世界で
(>>303に使いこなせない) OOPは必要ない

OOPでゲームを作る
→バカなので作れず挫折
→ 自分がバカだと認められない
→ OOPが悪いことにする
→必死でネガキャン ←今ココ

>>304
ミサイルは仮想クラスだろ？他は全部その派生クラス

>>306
いやOOPより上とか下とかって考え方自体がおかしいのだが…

しっかりカプセルかさえ出来てれば、OO機能のない構造化言語、
たとえばC言語でもゲーム作ることぐらいは出来るだろうよ。
しかし、フルアセンブリでかくのは、さすがに無理。
つまり、OOってその程度のものなのよ。
C言語が凄すぎたね。

OOPLで書かなきゃOOPにならないと思ってる人っているよね

その程度とかさっぱりわかりません。


良い物か悪いものかの二択だと、
良い物なんでしょう？

OOPで開発するときに
便利な機能を言語仕様レベルで持っているのが
OOPL

ようするに開発が楽になる。

沢山ある当たり前の技術のひとつでしかないのに
それを解らないからって無駄に高尚なモノと思い込んでるせいで
「OOP信者は自分を優秀だと思っている」
なんて勘違いした発想が出てくるんよね

>>324
これは言えてる
空気吸うような自然な関わりしてきた自分からすると
OO出来ない奴の被害妄想の強烈さにはいつも困惑する

>>325
では、今のOOに不満はないのか？

ゲームでもＣ＋＋使わないと大変すぎてしんじゃいます

>>326
今のOOとは？

>>326
おなしつ

>>328
お前が空気のような関わりをしているOOのことだよ。
空気のように感じるということは、
何も不満点が無かっんだと解釈した。

概念や考え方への不満ってのは何かピントズレてるような？
主体の姿勢として

どうして？
考え方に不満があったらおかしいの？

空気のように感じたら、不満点がないという
結論にどうしてなるんだろうね。

自分でもどうでもいい質問したってわかってるんだろ？
何か言い返したい気分だったのだろうが、
無理やりレスしなくていいぞｗ

OOに不満が無いのかどうなのか。

不満点、にはならんよね
「この場合はどう実装すべきなんだろう」と悩むことはあるけど
そんなのどんなパラダイムでも当たり前に起こることで
あらゆる場面で悩まず実装出来るパラダイムなんて無いワケで…
てかそんな万能パラダイムあったらプログラマ自体が滅びてるw

それプログラミング能力の問題じゃないか？

>>334
OOだけに限らずプログラム開発
全てに不満点はあるよ。
だからこれからも進化し続けてるのだろう。

この答えでいいかい？

お前は何も不満点ないの？

>>355
実装時の不満はどうでも良い。
そんなことより、OOの基本的な概念や考え方への不満が有るのか無いのか。

言語に対しては不満を感じることはあるけどOOの考え方自体には特にないなー
（>>355じゃないよ)

>>338
いや、不満も何も
単に沢山ある道具のひとつなんだから、適材適所で使うものだよ？

>>340
では、OOはどういう道具？

なんだろう？こいつ。

世の中不満点が全くないものなんてないだろ。
（不満点がなければ、進化が止まったことを意味する）

「OOに不満点がある」ということを
強調して、OOを叩くための根拠にしたいのかい？

>>341
様々な要素をオブジェクトという単位で扱うための道具。

>>341
多くの問題をスマートに解決してくれる道具。

ひとつ言っておくと、銀の弾丸はない。

>>342
不満点があるならどんどん書き込んでいけばよいと思うよ。
みんなそういう話題は好きだから議論に参加してくれると思う。

OOは手足の延長、頭の延長、ようは道具として使うもの
→ 不満って？？？

OOに逆に使われてる
→ 不満

こういう構造だろう。つまり踏み絵だな

>>346
だから無理して言わなくていいってｗ

手段と目的が入れ替わっている人が多いのは確か
そういうのに限って入門書レベルも身についていないのに
いきなりデザパタに凝りだし挫折し崩れていく

まあ、完璧じゃないのは当たり前なんだけど、
ここでこうして不満点がほとんどでないってことは
概ね満足ってことかね。

そう彼のように

>>348
「特定の人に限る」話はOOとは関係ない。

>>343
良い答えだ。
さまざまな要素を、オブジェクト「単位」で扱う。
俺はいつも思うのよ。別のオブジェクト「単位」である必要も無いかなって。
もっとタグのように扱えても良いのでは、と、ふと思うことがある。
特に動的言語では。

>>316
俺の書いた本にそう書いてある
本気でゲームがOOとか思ってる奴がすごい
また絶対に勝てない議論に突入されたいのか

Rubyにすればオブジェクト指向のことは意識しなくてもできる

世の中の全ての”物”は、使っていれば不満が出てくる。
それが無いと言う人間は、単にその”物”を使いこなしていないだけ。

ごめんタイプミス
別のオブジェクト「単位」　→　別にオブジェクト「単位」

>>352
OOで扱えないらしい
> タグ
って何のこと指してるんだろ
ブックマークやニコ動とかにつけるあのタグじゃないよね？

>>357
もぐりなの？

>>355
俺もそう思う。
だから「空気のように」って表現には何か引っかかった。
何かしら思うところがあって当然だと思う。

>>352
頑張って具体例を上げて下さい。

「思ってる」だけじゃなんにもなりません。

>>358
焦りなさんな。議論は意図を明確にしてからでも遅くない

>>359
ようするに、国語の問題？

どうでもいいや。

問題は言語のせいであってオブジェクト指向のせいではない
他言語での問題はRubyにすれば解決する

不満があるならどんどん書きゃいいじゃん

ほかの人はそれが当たり前だと思って不満に
感じてない可能性だってあるんだから

>>360
たとえば、
( obj1, obj2 ) . value = 1;
こう書けてもよいのでは？
その上で、オブジェクト単位に纏めるのも自由だってことで良いのでは？

それ言語に対する不満じゃね？

>>365
それは、OOに不満があるんではなく、
構文に不満があるだけですね。

ちょっと論点がずれてます。

>>363
>問題は言語のせいであってオブジェクト指向のせいではない
では何故Rubyが関数型プログラミング出来るように拡張されたんだ？

でも、オブジェクト単位に纏めるのがオブジェクト指向なんでしょ？
俺の書いたのはオブジェクト「単位」ではないよ？

関数型が便利だからでしょ
関数型とOOは排他的な関係じゃないし

>>365
　　ヽ(・ω・)/　　ｽﾞｺｰ
　＼(.＼ ノ

OOで話ふっといてソレか

オブジェクトってクラスのことでしょ？
これなしとか信じられなーい

>>365
つーかそれ出来るOO言語既にあるし
jQueryとか

Rubyの関数型って言えるのクロージャーぐらいじゃね？
それにRubyだけに限った話じゃないよね。

クロージャならJavaScriptだってそうだし、
C#やJavaも関数型が取り入れられてきている。

Scalaとか最初からオブジェクトと関数型のハイブリッドだし。

>>365
タグの方>>357は？

>>370
>関数型が便利だからでしょ
ほら、一部の実装にはOOが不便で
関数型が便利とかが出てくるだろう。

>>376
主要な実装系でら関数もオブジェクトですが何か？

また手段と目的が入れ替わっている人か

>>376
OOが不便だから関数型が出てきてるんじゃないぞ。

簡単にいえば鬼に金棒ということ。
便利なOOに関数型を加えれば更に便利。
別に関数型を使うときに、OOを捨てないといけないんじゃないんだからさｗ

>>376
なにが「ほら」なのかよくわからんけど

関数型とOOは排他的な関係じゃないよ(２回目)

もうそろそろ、相手の正体がわかってきたなｗ

jQueryマは許してやれよ。普段自分が何をしてるのかも分かってないんだから。

頭が硬い人は両方使うという
考えに至らない。

日本語で頼む

Rubyは関数型言語ではなくて
オブジェクト指向言語だと今知った。
恥ずかしい

はさまったか
>>384は>>382充てだ。ただの煽りだから無視してくれ

　 ,j;;;;;j,. ---一､ ｀ 　―--‐､_ l;;;;;; 　　　クラスを使わないで関数だけ使っていれば関数型言語
　｛;;;;;;ゝ T辷iﾌ i 　 　f'辷jァ　 !i;;;;;　　　C言語はクラスがなくて関数だけだから関数型言語
　 ヾ;;;ﾊ　　　　ﾉ　　　　　　　.::!lﾘ;;rﾞ 　　
　　 `Z;i　　　〈.,_..,.　　　　　　ﾉ;;;;;;;;>　　そんなふうに考えていた時期が
　 　,;ぇﾊ、　､_,.ｰ-､_',. 　 　,ｆﾞ: Y;;f.　　　俺にもありました
　　 ~''戈ヽ 　 ｀二´ 　　 r'´:::.　`!


※手続き型です。

なんつーか、構造化があればgotoやbreakは要らないみたいな、そんなレベルの話に聞こえる。

お、おう

Pascal は return は無いくせに break は有るんだよな。

あえて不満をあげるならインターフェースを継承したクラスを大量に定義して
あとからインターフェースに変更が入ったときめんどくさいってトコくらいかな

迂回する方法はあるんだろうし、OOじゃなくて設計の問題なんだろうけど

いんたーふぇーすをけいしょうってなあに？
むずかしくてわかんなあい

>>391
まあ、それは関数の引数の順番が
変わった時面倒だって話と大差ないよね。

>>391
すでにリファクタリング技術として
どうやって修正いけばいいか明確になってるよ。

>>374
なんで何もわかって無いのに知ったかぶるかね
Rubyで関数型っぽいのはイテレータだろバカ

ごめん

>>394
時代は進んでるんだな

>>377
>でら関数もオブジェクトですが何か？
名古屋じゃ関数を関数型というのかｗ

> Rubyで関数型っぽいのはイテレータだろバカ

関数型・・・イテレータ・・・？
デザインパターンにも乗ってるイテレータパターンが・・・？
Ruby以外のオブジェクト言語もほぼ搭載されているイテレータが・・・？

関数型とOOは排他的な関係だよｗ
OOで出来る事は関数型でも出来る
設計根幹部分を、OOで書くか関数型で書くかってだけの話で
ほとんどの奴はOOしか出来ないから、設計根幹部分はOOで書くしかなくて
その上でちょっと関数型できる奴が、オブジェクト指向で設計された各ロジックでほんの少し関数型を使う程度しか
今はやってない
それでも関数型は便利だなぁと気づく奴が出てきてる

>>399
ほら初心者ホイホイｗ
イテレータじゃなくて「Rubyのイテレータ」を調べろカス　Rubyの1.9以降のEnumerableをな

初心者なんてはやく死ねばいいのに

>>401
Rubyのイテレータが？

>>401
Rubyはオブジェクト指向な「手続き型」言語。
関数型言語では変数への「束縛」はあっても、副作用を伴う「代入」は（基本的には）ない。
Rubyは変数への代入をもろにつかって処理を行うから、関数型言語ではない。
lambda相当の機能を取り入れているから、関数型チックなプログラムはかけるが、だからといってRubyが関数型ということはない。

もちろんRubyで関数型チックなプログラムを書くのはおまえさんの自由。別にそれを否定するつもりはない。

>>400
二行目で一行目を否定してるよね

先ず日本語をってことか。これは恥ずかしくて出てこれないな。

Rubyのイテレータって
他の言語にない特徴何かありましたっけ？

値のリストをぐるぐる、コールバック関数（ブロック）に渡して
値を処理して、（必要なら）戻り値を返すだけでしょう？

コールバック関数じゃなくて、クロージャといったほうがいいか。

Rubyを認めていない奴が多いのと、
今日は機嫌が普通なので教えてあげない

オブジェクト指向（）

>>400
> 関数型とOOは排他的な関係だよｗ
> OOで出来る事は関数型でも出来る

┐(´ｰ｀)┌

>>400
どうして排他的だと思うの？

>>409
よく言った。


それは負け宣言だ。

バカに教わるとバカになりそうなので願い下げです

CになれてるとC++の描き方がおかしくなる。

はやくC++に慣れるんだ。

uyって、クラスを使わないで手続き型で書けば
関数型って思ってるでしょｗ

>>404
俺がいつRubyが関数型とか言ったのか？妄想もほどほどにしろ
それと、別にRubyが何の目的で作られたかなんていうのは関係ない
俺の目的の為に利用できるならばRubyを使うだけの話
それに自分で言ってて矛盾に気づいていないか？

それはつまり、RubyはOOとしても関数型としても使えるって事を言ってるわけで
そんなものは利用者次第なんだよ

> それはつまり、RubyはOOとしても関数型としても使えるって事を言ってるわけで
> そんなものは利用者次第なんだよ

はい、それは「C言語はOOとしても使える」という話で
よく知られたことです。

また話題戻るのか
俺が書いてるソースはOOでも関数型でも無いと
っほんと他人のレスを読まないから話題がループすんだよな

>>416
つまり排他的じゃないんだねw

>>417
そうだ>>404のバカ君は「よく知られたこと」をキリッとしながら書いていたのです

>>416
バカか

>>421は419へのレス

その程度ならRubyに限らずどの言語も関数型言語っぽく書けるだろうなぁ。

>>420
んー？ コピペだよ？

>>423
バカか
>>424
バカか
>>426-1000
バカか

Rubyのイテレータはこれだよ
each_with_index.map

終わり

OOは雑魚

>>418
> 俺が書いてるソースはOOでも関数型でも無いと
> っほんと他人のレスを読まないから話題がループすんだよな

手続き型、もしくは初心者が試行錯誤していて
コンセプトの全くないごちゃまぜになってる状態。だね。

>>425
> each_with_index.map

え？あー、うん。で？

uy
→頭の出来が残念な子
→一発言内にすら矛盾がある
→バカなので気づかない
→支離滅裂なので指摘される
→わめき散らす
→自分がバカだと発覚しないよう必死にわめに散らす
→支離滅裂なので理解されない
→捨て台詞を言い残して立ち去る ←もうすぐココ

なぜ、each_with_index.map のみをいきなり出してきたのかわからない。
あと、これは全然OOを否定してない。

副作用を許さない関数型と、副作用の固まりのOOが一緒だとｗ

はい、副作用がないメソッドはたくさんあります。

一人でやってる分には好きに書けばいいんでない
大人数で開発するのにそれ以前の手法で発生していた問題を解決するためのものなんだから

オブジェクト指向言語で提供されている
Mathオブジェクト、なんかはまず関数型だろうしね。

>>431
オブジェクトはフィールド＋メソッドだ。
お前が作っているのは関数ライブラリと一緒。

今日のまとめ

Rubyは「排他」という概念すらわからないバカちょんでも
使えてるような錯覚がえられる素人向け言語

>>434
つまり関数型言語ってのは関数ライブラリと一緒ですよね。

動的型付けだしなー。
個人でも作れる程度の規模なら上手くできるけど、それ以上になると保守が困難だったり、ツールの支援が得にくかったりと不利に。

>>418
誰もおまえなんかには興味ないんだよ(´･_･`)
あとスレタイを読めるようになった方がいいかもね
知性が少しでもあるなら、ね

>>435
その素人向け言語の機能さえ理解出来ないひとは？　素人以下なの？

>>439
アレを理解出来ない奴とかおまえのまわりにはいるのか？大変だな
興味がないから使わない奴ならゴロゴロいて当然だが

>>439
uyのことですねわかります

>>426-n
わからないわからないで質問ばっかじゃねーか

自分で考えろｋｓ

>>442
はいわかりました

>>442
なるほど。
つまり
手続き型、もしくは初心者が試行錯誤していて
コンセプトの全くないごちゃまぜになってる状態。だね。

スレ参加資格ないじゃんw

オブジェクト指向（笑）

OO信者は大変だと思うよ
俺はその理論の失策を知っているからこそ教えてやっているだけなのに

自分の信じていたものが無くなるのが怖いのか？

成長しろ

今使っているものに不満を感じ、文句垂れろ
不満と、文句は、この世界において「改善点」となる

それが無い奴っていうのは、ただ口だけで利点を理解などしていない
周りが使っているから使っているだけ
あるいは「それしか」分からないから「これが正しいんでしょ」とムキになって言う

まずさぁ>>46のミサイルとホーミングミサイルの設計でオブジェクト指向を基本通りに使って行ったら
ゴミカス設計になることの結論はでたじゃん
オブジェクト指向はゲームに向かないので、若干そこは崩して行かなければ使い物にならない
過去ログ読んでからこのスレに書き込めよ

オブジェクト指向が世界で広く使われているとか、そういう話じゃない
オブジェクト指向の欠点について話し合えば良い、その欠点の最初のソースは>>46ここにある
ゲームでOOは使えない　以上

>>46の致命的な欠点って、なんか言われたっけ？

>>446
はい
以上

使えないんじゃなくて、使う能力がないってだけだろｗ

boostとか普通に使われます

>>446
>OO信者は大変だと思うよ
お前の言うとおり、ここのほとんどがOO信者で
本当のOO使いがいないから、OOが駄目に見えるが
OOは悪くない手法だ。

>俺はその理論の失策を知っているからこそ教えてやっているだけなのに
「理論の失策」とは具体的になんだ？

オブジェクト指向、

このテーマで、ゲームの話
ホーミングミサイルとか出たけど
驚くほどシンプルな設計が出来上がった

なんだかんだいっても、オブジェクト指向は
よくできてるなと思った。

>>446
君には使うことが出来ないかもしれないな。
>>428とか>>438に役立つことが書いてあるよ。

よくできてるなてｗ

>>447
えｗｗｗｗｗｗｗ
本当に人の話を聞いてないゴミだな

お前のそこが成長限界か
ボケじゃなく素でそれならばもう良い
D,C++でゲームロジック考えてる時点で才能ないんだ

アドバンテージ

>>451
頭悪いんだね・・・


とにかくさぁ
クラス設計の部分で何時間も何日も悩むなよ

一回最後までゲーム作ってみたらいい
>>46の書き方で最後までいけば困ることになるから

俺は、その一回分のゲーム製作で失敗する分の時間浪費を
2ch程度の書き込みで回避できるならば、と教えてやったけど　（46-150くらいでな）
それが無理なら一度最後まで作って困る状況を自分で体験するしかない
賢い奴ならば、それで学習時間が短くなったはずだったが、そうじゃないんだろう46君は
最後まで作れないかもしれないけどな？
つーかいつまで46名乗っているつもりかね？

結局プログラマが作るゲームが完成しない理由って、絵でも音という理由もあるけど、初心者の頃はそれ以上に
プログラムが徐々に複雑になって管理するのが大変になって絵や音にさえ気が廻す余裕もなくなり、破綻するんだよ
ゲームをひとつさえ、（せめて1万行以上　←ちゃんとリファクタリングして1万以上）のものを作った事がなければ
分からない問題は多くある、ただOOだとソースコードは膨らみまくりだから、3〜5万行くらいか？
俺だともはや作りこんでも1万行行くことはほとんど無いし、
この差があるのに、なぜか名前欄にHNをつけているとその差に気づけない奴が多い
人は進化などしていない 　以上

その複雑になったときに管理し易いようにするための道具のひとつがOOPなんだがなあ

>>456
C++系クラスの仕様をちゃんと知らない人をどう信用しろと・・・

てか、そんな無駄な長文書けるなら、困る理由くらい書けそうな物だけど。

【うゆ】uyスレ6【クソコテホイホイ】
http://2chnull.info/r/prog/1316933376/1-1001

巣が落ちて出てきたクソコテですのでエサを与えないで下さい

長文なのに中身ないのな

46もお前のソース底辺だぞ
uyのこと言っていられない

46って、
自分が俺よりレベル高いとか勘違いして無いよね
勝てると思ってるなら>>46の設計で動くもの何か作ってみろよｗ

46の書き方で困る理由？
そんなものは、今後どういう仕様変更が来るかによって違うぞ

それを俺は>>456で＞俺は、その一回分のゲーム製作で失敗する分の時間浪費を
こう説明した
でも君はuyや>>46-150あたりで教えてくれている名無しの意見を無視する態度をとったため
そのショートカットには失敗した
一回作って一度派手に失敗してこいよｗｗｗｗｗｗ
体験しないと分からないのであれば仕方が無い

>>462
>>157のような、関数オブジェクトで処理を差し替える、なんてどこにでもある構造で勝ち誇ってる時点で、その程度のレベルなんだな・・・　としか思ってないけど。

>>464
そりゃ勝ち誇るよ？
ゲームプログラムにおいて「当たり前」のようにやってるそれを君が知らなかったんだから

はっきりいって君のゲームプログラムに対する理解は、ゲームスレに質問してくるような奴以下

>>465
クラスの基本構造がまさにそれなんだけど。
本当に知らないのね。

なんて低レベルな争い。誰か課題出してやれよ。

ヒント：徹底スルー

>>466
はあｗ？？ｗｗｗｗ
＞クラスの基本構造がまさにそれなんだけど。
＞クラスの基本構造がまさにそれなんだけど。


もう説明しねーわ理解力なさ杉わろ

いーからお前もう46ってはずしとけよ
こっちが恥ずかしい

uyにレスしても不毛だからいい加減放っておけって
こいつから具体的な返答なんて返ってこないから

そもそも俺がラムダって行った時にC++にもラムダが〜なんていう時点でにわか杉なんだよ

アホ？
C++のラムダとRubyのラムダがどれだけ違うか比べてから言えカス

初心者救済は俺の趣味でもあるが、
ここまで知ったかぶる初心者は救う気なし　以上

uy擁護するつもりじゃないけど、多分46はuyよりレベルが低いのは事実
まぁuyからまともな答えは返ってこないから初心者スレにでもいっておいで

あいあい

ゲーム作りに慣れてない奴は、今までアプリ作った事があるとしても
ゲームプログラミングでは初心者なんだよ･･･

そこら辺を理解しよう
そもそも俺がクラスやOOを知らない事になってるけど
俺はその話題を話すのも面倒くさいからスルーしてるだけであって
出来ないとか一言もいってないｗ
「俺の中では」それ以上の設計を見つけてるから俺はもう二度とゲームプログラムでOOは使わないだろうってだけの話
もう俺が二度と使わない「俺の中では」古い技術と化したものの話題とか、こっちから振らないからな？ｗ
相手の力量を測り違えるなよ？ 以上

あい

すみませんでした　消えます

こうして初心者が潰されていく

>>472
スレチな訳じゃないんだし、ここで教えてくれればいいのでは？

>>474
Minecraft(MCP)のソース(java)が>>46と同じくOOで作られてるから
マ板に自分でuyスレ7立ててそっちでコレをネタに講釈してくれよ
いいネタだろ？

public abstract class Entity {
　　public double posX;
　　public double posY;
　　public double posZ;
　　...
　　
　　public Entity(World world){...}
　　public void onUpdate(){...}
　　public void applyEntityCollision(Entity entity){...}
　　...
}

いやいい
俺はそろそろ自分の開発に入る
最近やけに初心者相手にソース2chにあげまくったりしていたのは少しプログラム離れていたから
感を取り戻す為にやっていた

46がここに駄レスを書いてる間にも俺はコードをかいている
46もがんばれよ

やっぱりオブジェクト指向でゲーム書きます　すみませんでした

気分はstatic!

何があったんだ
Minecraft出されてヘタれたのか

今後しばらくム板に出てこないようなら自分の開発に入ったんでしょう
他スレに出てくるようならヘタれたんでしょう

>>478
とりあえずdamegeじゃなくてdamageだと思うんだ

こういう好き勝手なスレが
徐々に日本のPGの質を下げていくのだと実感する

結局不満を書く人もいなかったし
このスレにはもうアンチOOはいないのかな？

こういう好き勝手なスレが
徐々に日本のPGの質を下げていくのだと実感する

>>487
46の設計には不満があるがね

OOに文句つける人はきちんと説明しなさすぎなんだよ

OOの定義があいまいだからでは？

より優れたものを提示せずに駄目出しするだけでは説得力が無いということを
分かってない人が多いんじゃないかな

それだな
OOに対する唯一の不満は「定義があいまい」
これは肯定派も認めざるを得ない

実用上は困らないけどね

この前発売されたカードゲームエロゲーのバグの話だけど

１）手持ちのカードに手持ちの装備カードを１枚装備させることができる
２）ただし装備条件がある
　たとえば人間には人間用装備、モンスターにはモンスター用装備としよう

で、本来装備できないはずの装備カードを装備できてしまうバグが出た
たぶんこんなコードを書いてたと想像するわけだが

struct カード状態{
　int カードID;
　int 装備カードID;
}

これじゃバグってくださいっていってるようなもんだ
オブジェクト指向なら装備するときに判定できるのに

>>490
理解できなかった腹いせなら必然だろう

全然OOと関係ないわアホ

>>494
装着出来る出来ないは、ゲームの実行時に判断する必要があるから、
dynamic_castの成功/失敗で判断することになるけど、それってきめぇ。
悪用だと思うね。
機能的な意味で装着できないのではなく、ゲームバランスの観点で禁止
したとかもありえるし。3回までは装着OKとかな。
なんつーか、プログラムの機能的観点ではなく、
ゲームルールをクラス階層で表現しようとするのはどうなのかと。

どうって言われても
ただの設計判断としか。。

そういう系のゲームってルールエンジンみたいなのでやってんじゃないの
知らんけど

>>497がif文で１０００行あるメソッド書くのが目に見えるようだ

>>500
属性与えりゃ良いだけ。
特定のビットが立ってるかどうかっていう、いつものやつ。

ゲームだからバグで済まされるけど
「書き換えようと思ったらどこからでも書き換えられる」なんて大失敗じゃね？

そんなんじゃ単体テストする意味すらない

だけど、ゲームなんだから仕方ないじゃない。
ゲームのルールはプログラムの機能の都合から
導き出されているわけではないし。
ゲームの価値は面白いか面白くないかで、
面白くなければ、随時ゲームバランスの調節が入る。
そんなころころ変わりえる部分を
クラス階層とdynamic_castで表現するとか、
俺からしたら狂気の沙汰だ。
ゲームルールの調節があるたびに
クラス階層の調節とかやってられん。
パラメータで済ませたい。

ふーん。
このスレには関係ない話題だね。。

まあ確かにキャストの成否で判定はどうかと思うな

CardクラスにCanEquipメソッドを作って、
HumanCardクラスでオーバーライドして
さらに特殊ルールの上書きするごとにオーバーライドすればいいんじゃないの

カードゲームのルールってのは
仕様が全部割れている訳で、
ちまちま差分プログラミングする必要ないだろ。

なんですぐオーバーライドとか使おうとするのｗ

そこにオーバーライドがあるからさ

>>508
クラスごとに全部書き直してたら絶対どっかでバグるじゃん
「ここちょっと変更して」って言われて
全クラス修正するとか嫌なんだぜ？

でも、カードゲームのゲームバランス調節のためのルール変更を
オーバーライドで実装するってのはどうなのかと。

この気配・・・課題・・・！？

どうなのか、と言われましても

結局のところデシジョンテーブルをちまちま書くのが一番楽なのか

弟子女んテーブルってOOっぽくないよね

でも人間には見やすいだろ。テーブル。
エクセルで編集してプログラムから読み込むなんてのもありだ。

文章でだらだら書かれるよりは見やすい。
だけど、それがOO的観点でわかりやすいか？は別な気がする。

あと、弟子女んテーブルなExcelをプログラムから読む案はないな。コードの断片がExcelに書かれるのを避けられないだろう。

>>510
その程度をオーバーライドする意味って？

>>517
なにいってんだこいつ

>>519
おまえこそ何言ってんだ

>>517
別にOO的観点だろうがどうだろうが、見やすけりゃそれでよいわけで。
あと、後半はマジで何言ってるのか分からん。頭打ったのか？

OOっぽさは処理の内容より構造に出るもんだしな

レベルが極端に低い奴が数人混ざってて会話にならない

>>521
条件Aなら1
条件Bなら2

みたいに単純ならデシジョンテーブルにまとめるまでもない

条件Aなら、あれやって
条件Bなら、これやって
あれやって、とは、あーしてこーしてこう！です。
これやっね、とは、こっちのデシジョンテーブルでさらに判定やってくれ

みたいに複雑だから、デシジョンテーブルに出番が回ってきてるんだろう。
その部分だけエクセルに書かれてたら、エクセルとプログラムに強い依存が出来て、メンテしずらいったらない。
だから
> エクセルで編集してプログラムから読み込むなんてのもありだ。
は、ない。

そもそも、デシジョンテーブルで捉え始めた時点でOOをなかば放棄してるようなものだろ。

デザイナー→仕様書変更→ＰＧ→コードとかめんどくせーから
デザイナーが勝手にデータ作れや後は読み込んで適当に処理してやんよ！
ってレベルの話なんじゃないの

仕事の送料は減るかもしれないけどコードの複雑性とバグ要因が大きくなるのは
防ぎようがないな

ステートマシン使えよ

JBoss RulesにExcelシートからDecision Tablesを読み込む機能があるっすよ
多分他のルールエンジンも持ってる機能だと思う

>>524
だから何言ってんだ？

>>529
壊れた機会みたいだな。日本語でいいぞ？

>>524
カードの名前や属性を表にしたものをエクセルで編集して
プログラムから読み込むってだけの話だろ。

なんだ。ただの設定値読みか。

デシジョンテーブルの規格は決まってんのに

　ざわ・・・

　　　ざわ・・・

「ざ」がYで「わ」がNですね。わかります

ゲーム開発にRubyとかBASICで開発してるようなもんだからな。
せめてカブくならアセンブラくらい使えよ

歌舞伎をやるにはアセンブラを習得しないといけないらしい

>>537はまず日本語を習得してからだな

>>538

簡単なゲーム開発にRubyはいいよ
ただ拘ったもん作ろうとするとRuby言語の仕様だけ
分かってる程度じゃどうにもならなくなる
当然のごとく、C,C++との連携が必要
どこをC++で書くかっていうのと、Rubyの構文で遅くなりやすい箇所を避けて書く能力が必要

スレタイ

オブジェクト指向でゲーム開発って、俺が10行程度でまとめてるものを
クラス定義から始めて100行まで引き伸ばして書く事になるんだけど

別にそれでもかまわない気がしてきた
俺は木構造ラムダでソースコードをかけば、変数宣言の一切をなくしてかけるけど
今速度のことを考えてみると
どうしても今の言語じゃ速度だせやしない

当たり判定の処理をオブジェクトごとに自立させてやってたりすると、Rubyじゃ遅いから
丸ごとC++でやらせるわけだけど、そうなると当たり判定の処理は
シーンとか、そういう場所でやらざるを得なくなる
その結果、無駄変数が増える

どうせ無駄変数が増えるなら、無駄クラスだって増えていい気がしてきた
しかしソースコードが気持ち悪い
オブジェクト指向気持ち悪すぎて吐いたわ
このゲロジェクト指向でゲームつくてる奴よく耐えられるな
完成までに何度嘔吐すれば関せいするかわｋらない
マジレスするとシスターアンジェレネちゃんがゲロを
吐くまでスイーツを無理やり食べさせて
アンジェレネちゃんが吐いた新鮮なゲロでもんじゃ焼きを作って
ゴハンの上に乗せて一緒にペロリと食べたい

>>484 だっか

>>542
頭悪くてOOで挫折した
まで読んだ

違う
ヘタレてない
LastProjectだから
全力

つうかRubyやC++みたいにOOの為に作られた言語で
OO以外でプログラミングすることがどれだけのハンディか分かってないだろ
確かにOOでかいたほうが楽だ、でも最初から何かをあきらめてる書き方は嫌だ
そんなゴミソースコードこれ以上量産しても意味が無い
俺は｢1｣と「再帰」で書きたい　でも、今ある言語じゃ｢1｣と「再帰」で書いたら速度で無い
言語とコンパイラとPCスペックが俺の理論に追いついて無い
速度をあきらめ完璧なソースを作るか
完璧をあきらめ速度をとって普通のソースを作るか

そうだ、俺はゲームプログラムの内容なんてものにさほど興味なんて無いんだよ
見せたいのは本当のところゲームじゃなく、そのソースコード
つまんねーソースコードでゲーム作る事が一番つまんね

ヘタれですみません、まで読んだ

どんどん中二病をごしらせていくな
ある日突然自殺してそう

OOやるのに一番適した言語は何か？
俺はScalaだと思う。
Javaよりも柔軟で、C++のようなクセがなく、Rubyのようにバグだらけではなく、、そして高速だ。

>>542
> オブジェクト指向でゲーム開発って、俺が10行程度でまとめてるものを
> クラス定義から始めて100行まで引き伸ばして書く事になるんだけど

オブジェクト指向すごいよね。
Scalaとかオブジェクト指向で、
静的言語でRubyを超える短さでコードを書ける。

本当に技術のないバカが暴れてるよね
どうしたんだこのスレ
高校生くらいが発狂してるんだろうか

小学生だよ

長い短いはどうでもいいんだよ。トータルで開発短縮に貢献してるかどうかだ。

このスレでまともな会話は不可能

わざと分かった上で逆理論唱えてる釣り師がいるから
レス釣られちゃいけない

あげ

ちゃんとしたプログラミングは難しい
しっかりと究極的にリファクタリングしたら、オブジェクト指向などいらない
でも、そこまでやっていられないからオブジェクト指向を使う
俺も年を追うごとに少しずつ頭の回転は鈍くなっている事を感じるよ
今は昔に書いたアルゴリズムについていけるかどうかが分からないんだ
こうやって衰えていくのならば、難しい設計ではなく出来る限り簡単なオブジェクト指向での設計を
心がけるべきかもしれない
人には扱いこなせない、俺は少しばかり扱いこなせるばかりに慢心していたが、やっぱりダメだ、扱えて無い
人は死んでいく、俺のソースコードの中にコメントは無い

コテハンやめろ
レスの内容で他の雑魚と差をつければいいだけだ
基本的にこのスレには雑魚しかいない

ここだけの話、ゲームなんかより便利なツールでも作ったほうが良いと思うよ。
なんていうかね、完成しない気がするんだよね、ゲーム。
そうだね、ムービーメーカーはどうかな。
マルチメディアって点ではゲームと共通してるし。

便利なツールがフリーで溢れてるから、今更作る気ないな
まじでpgなんてする意味ない

>>548
適材適所。
Javaは商業利用だから質実剛健。
C++はローレベルな部分を触る場合。
Rubyはおもちゃとして。

yu寝た

>>542
だいじょぶかこいつwww
ちゃんとコリジョンテーブル使ってるか？

>>557
また頓珍漢なことを言ってるなバカ君
実際ゲームなんて、設計方法に拘らず作ってれば
プログラムの作業なんて一瞬で終わる
拘らなくていい場所に拘り、不必要なまでに効率化をしているに過ぎない

それとゲーム開発において俺は「プログラマ」という立ち位置ではない
いくら拘ったゲームプログラムを作ろうと、それでは何も作れないから

>>561
で

さすがです

>>562
そろそろ自分の開発に入れよ

>>563
すみません。いいすぎましたwww

オブジェクトが１０個あったらコリジョンで総当たりするのに４５回計算する
オブジェクトが１０００個あったら５０万回計算する
オブジェクトが１万個あったら５千万回計算する

それ系のゲーム作ったことのある人間なら絶対素通りしない部分
レベルがわかる試金石

>>567
教えるなよ…w

で、で終わるのがおもしろい所なのに

ああ、何のこと言ってるのかとおもったら当たり判定のことまだ言ってんのか････

なんで、君らそのスタートライン前の準備を延々としてるわけ

そういう立場なんだったら動画でも作ってニコニコにでもアップしたら？
そうだね。
ゲームを実況プレイしている風に見える偽動画とか。
ゲーム映像からして自作の作り物でさ。
どこからどう見ても、ガチなゲームを実況プレーしているようにしか
見えないんだけど、実は全部真っ赤なウソで、そんなゲームは無いっていう。
ゲームで自己表現するのに、もはやゲームそのものから作る必要の無い時代に
突入したってトンチが効いてて面白いでしょ。
この頃はプレーせずに実況動画だけで済ませる人も多いわけで。

>>569
ですよね
すいませんしたっっっ（＞＿＜反省します

つーか、コリジョンチェックなどを状況状況で適応的に端折りたいから、
ガチのOO設計にはしないって意図なわけで。
本当に必要なものだけを書くって言う。
個人で書くなら俺でも当然そうするわ。

テーブルを作ったらオブジェクト指向じゃないとか
きみらの定義はどうなってるんだ

つうか、かかねーよｗ
あえて車輪の再発明で「作りたい」なら別だけど
ライブラリの機能使えと

「プログラムなんて無意味。unity使え」って結論なら第三世だな

三角形abcと、点pのあたり判定も、ライブラリーで一発ですよね！

おまえらもuyさんを見習えよ！車輪の再発明どもが！！

ゲーム系じゃない奴って作ったことあれば、そんなところで悩む事なんて二度とないような箇所で
いつまでも作らないから延々と話題ループするよね･･･
別にライブラリじゃなかろうと自分で書いた衝突判定クラスでもいいよ
一度ゲーム作ったことあれば作っているはずのものが、何故か君たちの話題には存在しない
もういいよ初心者共死ね

>>577
いくらuy先生が上級者だからって、ぼくら初心者に死ねと言うのはひどいとおもいます！
先生のスーパーテクニックをみてみたいです！

いまから時間限定でテトリスでも作りませんか？

だまれかす

دمشق

「○○の処理はどうすんだよ」
「おめーらには自分のライブラリってもんがねーのかよ！」

素晴らしいオブジェクト指向だ感動した

死ねとか書きこんで申し訳ありませんでした。
もう書きません。

コリジョン判定って、物理エンジンの無い疑似3D迄の話だろ？

しにます　すみませんでした

精神不安定すぎる

物理エンジン搭載2Dシューティングゲーム

はろー、おっぱいおっぱい

二度と話かけんなよ・・・

>>584 偽者だまれ

ここまで読んだ結論を要約すると、こんな感じ？
・OOは使える技術
・OOを使っている奴は、ほとんど使えない

結論はご自由にどうぞ

結論：uyは人間のくず

２ちゃんは、技術や知識で負けると
すぐ、主観的な人間性に対する誹謗中傷となる。
だから２ちゃんは、世間から嫌われる。

ここからの先、主観的な誹謗中傷は禁止。

凝り始めると収拾が・・・・

age

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
先月１位は非OOPLの言語、javaが下降ぎみだから当分は手続き型言語の天下が続くか？

Cの系統無双だな

俺がいない間に当たり判定の話していたのか。

ならこの本読めよ。

ゲームプログラミングのためのリアルタイム衝突判定
http://www.amazon.co.jp//dp/493900791X


ほとんどの人にとっては当たり前で、一部の人にとっては悔しい結果だろうけど、
言語は当然のごとくC++だ。

イントロダクションに書いてある通り、アルゴリズム主体の本なので
クラスも最小限しか使ってないけど、座標をObjectクラスが持っており、
明らかにこのクラスを継承して使うことを意図したコードになってる。

よくあるよね
クラスにクラス継承して使うタイプのライブラリって。
それマジやめて欲しいわ

そのよくあるライブラリの名前を教えて下さい。

actionmailerとかだろ

そんなことより就職しろ

誤爆

>>601
マイナーなものばかりと言いたいのかな？

>>603
勝手に誤爆にすんな。
>>601に言ったんだよ。

本当に誤爆です。信じてください。

しにます　ごめんなさい

おまえらの常識で俺を語るな
俺が就職なんかするわけないだろ
俺はオブジェクト指向でも関数型でもない独自のプログラミングやってんの
おまえらと一緒にコード書くとかありえねえわ
ね え わ

何俺の真似してんの？

>>600
ＭＦＣ

>>606-609
ウケタｗ

え？無職なん？

>>599
Railsも継承して使うタイプのライブラリ

.netFrameworkもまだ継承あんなー

ここまでやって力尽きた。
なんか、D言語紹介サンプルみたいになってるようなｗ
http://ideone.com/CmtU9

STGやめてテトリスになったのか
つか君テトリスすら作れないレベルだったのか

それにしてもすげーなD言語
そしてオブジェクト指向
200行も消費してまだ何もロジックらしきもの何もかかれてねーよ

普通は100行以内で収まるはずのゲームなのに
ここまで冗長させてまだ完成じゃないとか
読みにくい

Rubyが優れているだけの話

で、ここまで作るのに何分かかったの
俺初めてテトリス作った時40分で一応動くものは作れてたよ
そこから30分でリファクタリングしてアップロードに至ったよ
時間は大切にね

Tetris tetris = new Tetris();
tetris.Run();

質を落とせば誰でもできる。

隙間にねじこんだり意外と隠れたルール多いからな

口先だけ偉そうで未だ何ひとつまともなコードを晒すことができない
って批判する奴がいるから言っといてやる。

厨二病をこじらせて
妄想と現実の区別ができなくなっただけだから
心配しなくていいからな

ニートならもっとどんどん書き込めや
さぼってんじゃねーぞ

そもそもテトリスにおいて必要な処理は

MAPの生成（）

def FuncTiOn
　TMPｘｙ変数 ＝ xy座標
　TMPｘｙ変数 ＝ 移動関数（）
　IF 移動して大丈夫？関数（関数ブロック回転関数（＆TMPｘｙ変数）） ＝＝ TRUE ｛
　　xy座標 ＝ TMPｘｙ変数
　｝
end
def FiunTCioN2
　TMPｘｙ変数 ＝ xy座標
　TMPｘｙ変数 ＝ 移動関数（）

　IF 移動して大丈夫？関数（＆TMPｘｙ変数）＝＝ TRUE｛
　　xy座標 ＝ TMPｘｙ変数
　｝
　ブロックが一列揃ってますかー？関数（）
end
MainKAnsFucntion
　FOR
　　ブロックを表示
end
こんなレベル

複数の値を返したり、selfまたは変更されたx,y座標を返す関数を作るならIFさえいらないよね（´・ω・`）

全然だめだな

uyはあんまりゲームとか作ったことなさそうだな

中核ロジックより周り埋める方が大変なのさ
まあアプリはみんなそうだけどね

スピードが上がっていくのは当たり前として
例えば最速スピードだと1フレームで一番下まで落ちるが
すぐに固まるのではなく、硬直期間がある。

その間に横にずらせるが、クラシックルールやワールドルールによって
回転軸が違っているし、端に接触している場合のみ違っていたり、
ブロックが登っていくような動きをしたり、単純な計算では算出できない。

先行入力があったり、ホールド機能があったり、
最後には積んでるブロックが見えなくなったりする。

ちゃんとテストリス知っていれば、10分でブログ作りました
みたいなこと、恥ずかしくて言えないだろ。

>>626
テトリスなんだから周りはユーザが埋めろ

>>624
俺のフリして小汚ねえコード書くなよ

uyはテトリスが何たるかを知らない。
微妙なゲームバランスが肝なのだ。

そこが作りこまれてないテトリスなど
色もスピードも同じままのクソゲー

あんまり細かいところまでこだわることはないと思うけど
落ちた後に回すところは実装しておきたいよねぇ

>>627
俺さまレベルなら
それ全て実装しても5分で書けるんだよ
ゲームの基本がわかってねえならレスすんな

こんなテクニック知らないだろう？
http://www13.plala.or.jp/TETRiS_TGM/kouza/12.htm

>>632
作ってもないくせにエラソーにｗ

>>630
はあ？
落ちたあと回す機能なんかいらねーよ
どんだけセンスねえんだよ
これだからゲーム作っことがねえ奴は駄目なんだよ

でも結局、テトリスを構成する関数は
移動関数（）
と
移動して大丈夫？関数（）
しかないんだよ
オセロとかも、そうだよ、この2個の関数だけで作れる

テトリスの回転関数も本当はいらないし
Keyboard(VK_Z) && (v=(v+1)%4)
でかける

>>636
だからその関数の中が大変なんだろｗ

その中身の大変さを無視するなら、
関数一つでファイルダウンロードできるわｗ

>>637
全然むずかしくねーよｗｗｗｗｗｗｗｗｗｗ

テトリスとオセロってニコニコで１時間シリーズであったよねｗ

そもそもSTGに書けば
移動関数()
移動して大丈夫？関数()
すらいらなくなる

>>636
「溜め」というものがある。
回転する前に、数ミリ秒横にレバーを入れて
溜めておくかどうかで、下に落ちるか
横滑りするかの違いがある。

テトリス関数()

これだけで俺は作れる

>>639
まああれも昔作ったことあるものをタイピングしてペイントで書いただけだけどね
十分すごいけど

>>633がテトリスというのなら
それと同じ仕様にするのは
骨が折れるだろうな。

テストだけで相当時間がかかる。

ゲームってのは
むしろ細かい仕様が決まってるほうが楽だったりするからね

回したとき衝突したらどうするのかとか考え出したら決まらんよ

>>639
オセロはさらに簡単
石おきます関数（）
石おいて大丈夫？関数（）
石裏返します関数（）
だけ

AI機能をつけるのも簡単。

コンピュータが手を考えます関数()

ほらできたｗ

>>641
溜めた?関数()
だけで簡単に作れる

大方ニコニコで動画見て自分でやった気になってるだけ

天地創造関数() 笑

OOスレなんだから、テトリスのロジック部分じゃなくて、BlockMapとControlBlockの構造に注目して欲しい・・・

ビッグバン関数 (笑)

とってもエロい、エロゲーできたよ！



エロゲー関数()

uy関数()

↓ 実行結果

>>647
>>650
>>652
なんでもかんでも関数() つけてるうちは猿真似だわ
ゲーム作った奴なら誰でもわかってること

>>654
すげー、uyができたｗ

>>654
おめでとうｗ

>>651
オブジェクト指向にテトリス選んだ事が間違いだし
そもそも
class Tetris
{
private BlockMap fb;
private ControlBlock cb;
private size_t _cbx;
private size_t _cby;
private int fallCount;
public bool fastFall;
private Random r;
private bool _gameover;

なにこれ？ｗｗｗｗなめてんの？

ファイルの先頭でこれだけ無駄変数宣言するとか、はっきりいってC言語で書いてるのとかわんねーよ
private にすりゃいいってものじゃないし、変数をもっと隠蔽しろよカスが

>>654
GJ！

>>658
なんで、自分が書いたクラス定義に
自分でダメ出ししてるの？

>>658
これだけでマトモなゲームが書けないって分かるｗ

>>660
http://ideone.com/CmtU9

ようはこの程度で作った気になってるなら
アマチュアだってことさ。

>>653
エロゲはもっと簡単だ
エロ絵みせます関数()
喘ぎ声だします関数()
ストーリー生成関数()
萌えセリフ生成関数()
マルチエンディング関数()
クリア報酬関数()

>>662
お前が作ったんじゃないことは分かったわｗ

uy関数()

ワロタｗ

さらに
bmList[0] = new BlockMap(4, 4, [[0,0,1,0],[0,0,1,0],[0,0,1,0],[0,0,1,0]]);
bmList[1] = new BlockMap(4, 4, [[0,0,0,0],[1,1,1,1],[0,0,0,0],[0,0,0,0]]);

これ。
こういうデータはソースファイルの中盤に置くな
ソースコードの上のほうに置けカス

普段からテトリス語ってて他人のコードｗ

おまけ。(ActionScript)
回転法則の話が出たので・・・
http://ideone.com/bs80f

>>664

>>653は一行、
お前は六行。
明らかにお前の負け。

>>665
ごちゃごちゃうるせー奴だな
コピペで作ったんだよ
あまえらレベルに合わせてやってるの

コピペしかできないと白状ｗ

お前のコードでテトリス語れよ。

お前のコードの回転法則書いてみろ。

>>673
回転法則関数()
だけだ

>>669
switch(j)
{
case 0:
afcbxt += a;
break;
case 1:
afcbxt -= a;
break;
　以下略
ねえ、ねえ？　なめてんの？　なんで　
for (var j:int = 0; j < 8; j++)
ここのjが
switch(j)
ここのswitchでよまれて、下にcaseが7つも続いているの？？？？？ｗｗｗｗｗ

予備知識

回転法則
http://www10.plala.or.jp/code1484/game/tgmvs/tgm-w-kaiten.htm

回転法則関数()

よし、俺もかけた。
uyレベルに成長した！

>>675
指摘する点が違うだろ。

回転法則関数() 一行でいいんだろう？

>>669 >>676
Dってラムダとかあるんじゃありませんでしたっけ？>>146
そのswitch文をお得意のD言語のラムダでまとめてみてはいかがでしょうか？

あー、もうおまえら本当にバカばっかだな
教えてやってるんだから俺さまの発言ちゃんと読め
テトリスは
テトリス関数()
ってわかるだろ。これでわかんねえならさと市ねやゴミカス

>>676
これとかさっぱりだわｗ
http://www10.plala.or.jp/code1484/game/tgmvs/TGM-GIF/WSk3.gif

上の回転ルールをどう解釈すれば
こんな動きになるんだか？ｗ

>>680
今はテトリスの実装の話だ。

関数定義の話じゃねーよ。

ヘッダファイル書いてるってレベルじゃねーぞ

まず言わせてもらえばIFが多い
無意味なIF消せよ

http://www10.plala.or.jp/code1484/game/tgmvs/TGM-GIF/wsk2.gif

・・・誰か解説してくれｗ

構造的にいうなら
たとえば移動できるか関数（）はBlockMapのメソッドにすべきじゃない？
ControlBlockは内部にBlockMap持つなら派生したほうがベター

http://www10.plala.or.jp/code1484/game/tgmvs/TGM-GIF/SZT-3line.gif

ムリポ。ってかおもろいｗ

>>682
だーかーらー
>>624>>636>>640で書いただろ
中身とか猿でも書けるわ

パックマンはおそらくハンドアセンブルでつくられたと思うがOOでも書ける
パックマンをOOにしてもいまさらメリットもないが
ゲームでメリットのあるOOの書き方で書くことはできる

>>686
重なり判定する関数は、func(BlockMap, size_t, size_t)ってして、汎用的に使えるようにするんのはありかな。
今回は面倒だったので簡単に。

ControlBlockは複数のBlockMapから一つのBlockMapを返す、って構造なので派生するのむりぽ。

>>685
>>687
俺さまから言わせると
それはテトリスじゃない
ゲームですらないわ
ゲーム作った経験がないからわかんねーんだろーな
回転法則を自分で書いたことがあればそんなバグのあるコードはすぐわかる

コピペも経験ですかｗ

>>690
中のbool配列をプロパティにしてオーバーライドして実体を乗っ取っちゃえばいいじゃん

>>690
派生とかゲーム素人の発想だ
汎用性とか書けもしねーのに考えるだけ無駄
書き直しても5分もかからないコードなのに
素人ほど汎用性とかグダグダぬかしやがる
重なってる？関数()
でおわりだ

>>693
用途としては、単なるコンテナだからなあ。
そして、その手間を掛けたところで、何かメリットがあるか？　と考えると微妙か。

テトリスだからオブジェクトは絶対増えないけど、他のゲームだったらそうとは限らない
「場にコリジョンが発生する」という意味論的に考えればユニークなんだから
そこは処理を一元化しておいたほうが「オブジェクト指向らしい」書き方になるよ

別にそこをオブジェクト指向で書かなくても。
テトリスとかのパズル系のゲームはさ、
ルールの仕様が完全に割れてるんだから、
少なくともルール部に関してはOOで表現する必要ないよ。
描画周りをOOで実装するのは構わないと思うけどさ。

オブジェクト指向の設計見せたいならSTGでよかった

>>691
> 俺さまから言わせると
> それはテトリスじゃない

何を言ってるの？

これは実際のゲームで使われてる
回転法則を書いたものなんだけど？

ゲームのサンプルを書いただけのやつと
実際のゲームを書いた奴の違いだなｗ

テトリス
ttp://ja.wikipedia.org/wiki/%E3%83%86%E3%83%88%E3%83%AA%E3%82%B9
>テトリミノをそのまま落としただけでは入らないような隙間に、テトリミノを落としてから回転させ、うまくねじ込むテクニック（通称「回転入れ」）

これだな
で、ゲームを作った経験が何だって？

>>699それ俺じゃない

>>702
それは俺が決めること

ねみ

uy寝た？

コードかいてるに決まってるだろ

見ても理解できないだろうけどさ、
俺はこんな設計で行くことにしたよ
http://ideone.com/eTJ8W

このレベルの違い、分かるかな

def RadToDeg x
x*180/Math::PI
end

tmp = RadToDeg( Math.atan2( 300 - o.y , 200 - o.x ))
angle += 5 if angle < tmp
angle -= 5 if angle > tmp

ホーミングってこれでいいんだっけ？

もっと複雑だったような気がしたが･･･

５度ずつだとちょうどに収まらなくてサイドワインダーみたにふらふらしながら飛んでくな
まあフレーム増やしたときにそのマジックナンバーも小さくなるだろうけど
あと例外

マジックナンバーじゃなくてただの追尾性能

例外って何

コード読む方が「この５ってなんじゃ？」って思う、その５がマジックナンバーだよ

atan2はゼロ除算例外スローするだろ？　rubyだと握りつぶすのかは知らんけどな

マジックナンバーだろ

>>710

経験のないゴミカスに説明するのめんどいからthrowするね

ねむすぎ

またそのパターンかよｗ

atan2は
Ruby1.92では例外
Ruby1.93では平気
てかどうせRubyで書かない


だからそこは、あとでこうなる場所だっていう話
5とか1とか数字は残らんよ

def hommingg a x y
tmp = RadToDeg( Math.atan2( y - o.y , x - o.x ))
angle += a if angle < tmp
angle -= a if angle > tmp
end

ゼロ除算例外のときどうするかは大事だぞ
別にどうでもいいけどな

根本的な考え方的に合ってるのかっていうなら
ミサイルより速度が速い敵には運がよくないと当たらないだろうな

てか俺はこのスレのためにホーミングしてるわけじゃなく、
このスレとは関係なくゲーム作ってるだけ
このスレ用のは46が作るだろ
あとホーミング弾と呼ぶべき
ミサイルとか名称ダサすぎて死ねるわ誰が言い始めた

ホーミングミサイルと言えばジャイロダイン

uy寝た？

むしろおきた

本当のテトリスだと？
http://www.youtube.com/watch?v=jwC544Z37qo

ねーだろｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

とりあえず、こういうスレで議論するならたいした物の導入いらないC++/WinAPIが妥当だと思う

>>722
１フレ越える速さで横からくっつけるってどうやってるんだろ？

http://ideone.com/SNDC5

>>725
初心者なの？
１フレって何のこといってんの？
基本的に１フレームって60分の1秒のことだよ

>>725
接地から確定までにいくらかフレーム数もしくは時間が用意されてるってだけだろ

>>727
>60分の1秒のこと
端折りすぎだろ

http://nicoviewer.net/sm16231079

>>724 >>726
典型的なOOPなんて大部分は手続き型なんだから
手続き型のソース出しても大した反応無いと思うが・・・
特にDC関連のAPIとかOOと殆ど齟齬無いし

>>730
違うよ
すぐにコピペして実行できるかどうかって意味
相手を納得させたいなら動かしやすいソースを提示すべき

ぶっちゃけた話というかなんというか

新しい技巧使ってないなら
おれらが２０年以上前に書いてたコードと大差ないとしか言えん
やることの内容自体が同じなんだからな

「おまえらおっさんとはここが決定的に違う」というところをアピールすれ

プログラムのサイズを気にしないでよくなった

パソコンが一人１台で使える

しいて言えばGCの存在かなぁ。
あれのおかげでかなり出鱈目できるようになった。
良くも悪くも。

>>732
http://ideone.com/eTJ8W

全てのオブジェクトを木構造で管理してる

君たちはいつも具体的なソースあげると途端に無言になっちゃうよね
Rubyが読めないからかな？
それともアルゴリズムが読めないのかな？
どちらにせよ底辺スキルなのだろう

>>728
触った感じそんなプログラムじゃないんだけどな
回転してれば永久に地面につかないようなプログラムだった気がした

んでも自分で１フレで下まで持ってくるようなテトリス作ったことあるんだけど
そうすると今度下に下りてる途中で回転みたいなのがスムーズにいかないんだよね
そのテトリス、同じもん作ろうとすると意外とむずい

俺のプログラムが違うところで不具合でてて結果的にそうするのが難しくなっちゃってる可能性もあるんだけどね
そういうのも含めて昔チャレンジしたときは難しかった

全てのオブジェクトが木構造って時点で。
技術者は木構造がお嫌いなんです。
フラットモデルが大好きなんです。
その上で層化する。
ちょうどフォトショップのレイヤーのように。

>>738
回転の過程でブロックが床に当たって
中心座標が押し上げられる。
落下分がキャンセルされて永遠に床につかない。

>>740
知ってる
フラットなほうが理解しやすいもんね

でも俺は、気づいてる事が1個あるんだ
フラットな管理にしてると、フラットを"木構造に見せかける為の"無駄な変数が必要になることと、
1箇所の変更の為に数箇所変えなくちゃいけないことと、

あと、開発していく最中、オブジェクトやクラスを追加する時に、フラットな管理状態だと
その平面荒野のどこにオブジェクト・クラスを設置したらいいか？で毎回悩むことになること
俺はよく考えた結果、どこにおくのも間違いなんだと気づいたよ
あ、3つもでてしまいました

それが耐えられないからソースがこうなった

>>738
俺が持ってたテトリスは回転連打してても一定時間で固定されたよ
対戦で悪足掻きしても死ぬ感じで
実装毎に細部は違うだろうしね

>>738
いいから作れよ
むずくないから
その程度で「むずい」とか口にするな

別に木構造に見せかける必要はないよ。木構造じゃないんだから。
そりゃ中には木構造なのもあるから、そういう木構造なものは木構造で書くよ。
でもお前のは、全てのオブジェクトが木構造なんだろ。
木構造じゃないものまで木構造で書く必要はないし、
木構造に見せかける必要もないよね。

回転や移動をすると、遊び時間がリセットされたり、操作ミノをの回転でボトムの座標が変わらないように調整されたり、回転した時に壁や地面を蹴るような動作をしたり・・・

てかなにこのテトリススレ。

そうは言っても俺も昔誤ってuyみたいなプログラムの設計しちゃったことあるんだよな。
全てのオブジェクトが木構造になってて、
自分の目的のインターフェースが得られるまで、
木をたどりながらdynamic_castを繰り返すっていう。
たぶんプログラム習って一年目ぐらいだったと思う。
例によってゲーム作ろうとしてそういうわけ分からないことした。
若気の至り。

>>745
ゲームプログラムの場合は、ほぼ例外なく
スタート画面→ステージシーン
っていう具合に階層が必要になる（そこまで作らないとかいうのは無し）

この程度なら
switch(scene) { case :....}　とかやってもいいんだけど、
俺の場合はさらに
ステージシーンの下にゲームで使うゲームオブジェクトを置くから
例えばスタート画面に戻る事によって、ステージシーンを破棄した時は、
ステージシーンの中のオブジェクトも木構造辿って勝手に破棄される

ここをもしフラットな管理にしていると手動で
GameObject.delete　とか書かなくちゃいけない箇所になる


あとは、STGとかでいうと、ボスキャラが弾幕を展開していたとして、
ボスキャラを倒した時に、ボスキャラが既に出していた弾幕の画像を変えるなどの処理を行いたい時など
木構造で管理したほうがやりやすい
そうしないと、弾幕オブジェクトにボスキャラの状態を知らせる変数か何かが別途必要になってしまう
ステージに対してもそうだな、ステージの下にボスキャラオブジェクトを作っていないと、
ステージオブジェクトにボスキャラの状態も教える仕組みを作らなければいけなくなる
これらをはじめから木構造で管理して、データ参照可能にさせておくとかなり楽だよ

>>746
意図的か外し忘れか知らんがそろそろ数字コテ外しとけって
uy様は特別なんだよ、付けてない方が有害だから

>>747
C++で書いたのか？
動的言語じゃないと死ぬことは分かってる
静的言語みたいなlambdaじゃなくて
ローカル変数も参照可能な動的言語のlambdaがないと自由度低すぎてやっていられない
今一番のネックは速度

動的静的は関係ないだろ。
木構造に関しては、探索ができりゃ良いってだけの話だし。

>>751
関係あるんだよ
動的言語のlambdaはローカル変数がスコープ突っ切るから
木構造の一部にするほどでもないオブジェクトは
ローカル変数としてかけば下層オブジェクトから上位下層オブジェクトの変数に普通に参照できるから探索いらない
静的言語だと、いちいち木構造の一部にするか引数で渡さないとダメだろ

↓　これをフルに利用する事になる
x = 1
-> do
　p x #=> 1
end

上位下層オブジェクトてなんだｗ

上層オブジェクトｗ

つーか、木構造よりも単純なテーブルの方が合理的なのは、
オラクル見てても分かることだろ。
木構造は関係が視覚化しやすいってだけで、
プログラム的にはテーブルの方が管理も汎用性も上。
プログラミング言語が配列やリストを手厚くサポートする一方で、
木構造のサポートが御座なりなのはそういうこと。

単に木構造は配列よりも管理が難しいからだと思うよ
プログラマが木構造を管理できるならそっちほうがずっと良い

でも実際使ってて、できる事ならば言語処理系が
木構造を使いやすく実装されているべきだと思う
こんな使い方を想定されてない言語で誰にでもやれというのは無理がある
俺様が世界を変えてやろう

しかし、木ってのは基本的に親が一つだろ？

>>756
なんでそんなに木構造にこだわるんだよ。
オブジェクト間の参照、非参照関係を自動で管理、とかでよいだろ。

>>757
ひとつだよ

ライブラリや、プログラム中で使う準ライブラリ的なものは
木構造の外にある

>>758
変数が増える

uy著
http://www.geocities.jp/c_zelos/onruby/6.html

それはこっそりよめ

あとで色々公開してやるよ

後悔した

そりゃ更改しないといけないな

俺は公害

>>757
根がひとつだと思ってるとしたら大きな錯覚

はっきりいってrubyなんて潰しの効かんものは読めん
読めんし、ひとに読ますコードにマジックナンバー使ってコメントいれないなんて論外
C++かC#かjava使え

>>766
だったらグラフっつーんだよ。

小学生にマジレス良くない
いずれ2ch以外のどこかで正しい知識をつける場面はあるだろう

＞ はっきりいってrubyなんて潰しの効かんものは読めん
ぼくはRubyわかりませえええええええええええええええん

＞ 読めんし、ひとに読ますコードにマジックナンバー使ってコメントいれないなんて論外
読めないなら素直に読めないっていえばいいのにいいいいいいいいいいいいいいいいい

＞ C++かC#かjava使え
つかわねーよカス

本当のところ俺様の木構造ラムダのソースコードは全体がカオス過ぎて
本当は自分でも使いこなせてない
でも確かに完璧はここにあるのでかなりムキになって設計してるに至る

凡人どころか、世界中の優秀な技術者集めてもこんなの使わないし
だって普通にOOでかくよりも大変な上に開発速度は劣るし、
その見返りとしては、ほんの僅かに変数が減るだけ

でも俺様はなおこれでいく
今日は一晩かけての根幹部分のバグとり
何にせよ、木構造のネストが標準で4重、タスク1個作れば8重か？
そのあとにオブジェクト作れば10重になっているのだよ
理解できるわけねーだろカス死ね
これが木構造が使われない理由

http://www.youtube.com/watch?v=qAZAKpjARS8

lambdaのlambdaのlambdaのlambdaのlambdaの　lambdaのlambdaのlambdaのlambdaのlambda
を返す関数

uyがんばれ

もう一度、木構造ラムダをゼロから書けって言われても俺かけない
概要だけは分かってるけど、これをもう一回Rubyで実装しろとか無理
多分今の俺は世界の最先端にいる

組み込みなど実行速度やスタックサイズを気にするべき場合にあえてオブジェクト指向で
開発する理由はあるのでしょうか。

実行速度やスタックサイズとOOにどういう関連があるんだ？
仮想関数テーブル分のサイズとか？
OOPLのVMやGCとかの性質と混同してないか？

>>776無知は黙れ

OOで書く事による（僅かな）速度低下などと開発コストとで天秤にかけてんだろ

その速度低下の理由を書けよカスｗ

アセンブラレベルでの話だろ
関数コール（JMP命令）や
MOV命令

何らかの1000配列を何らかの関数に呑ませる時に、
もしその関数がオブジェクト指向によって作られた関数で
ネストにネストしまくりだったらどうなるだろうか？

1回の関数コールによって無駄な命令が20増ずつえたとすれば
*1000で OOで書いた事により、20000命令文の速度差がつく

>>778
オブジェクト指向の場合だと、
VTBLとそれ経由での関数呼び出しに時間が掛かる。

たったそれだけと思うかもしれないが、
組み込みでは重要。


さらに関数型言語になると
副作用がない＝値を書き換えずに新たに値を作る
ために、メモリコピーが頻発し更に遅くなる。

相変わらずバカっぷりで何よりです。
インライン指定もあるし、逆にサイズがシビアなら
インラインをしない手もある。

>>781
仮想関数使わなければ良いだろ

もちろん、動的型付け言語だと
静的型付け言語のオブジェクト指向よりも
さらに遅い。こんな感じ。

静的型付け手続き型言語　>　静的型付けオブジェクト指向言語　>　静的型付け関数型言語　>>>　動的型付け手続き型言語　> 動的型付けオブジェクト指向言語　>　動的型付け関数型言語

>>783
使わないならオブジェクト指向言語である理由がない。

　>　動的型付け関数型言語 >>>>超えられない壁>>>> 動的型付けオブジェクト指向型Rubyで意味不明な木構造

お前等が遊んでいる間に俺様はこんなにソースを書いてしまったよ
１８時間で消す
www.geocities.jp/c_zelos/last.rb

これは何指向？

nicoviewer.net/sm16231079

>>775
http://www.geocities.co.jp/SiliconValley-Sunnyvale/1968/coramu_8.htm

あのね
このスレに、技術ないのに頑張ってスレに食いついてる子

その努力は認める
ただし、ズレてる

ワロタｗｗｗｗｗｗｗｗｗｗ
DxRubyの衝突判定ライブラリ高速杉ワロタｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
速度でるなぁとは思ったけど
弾幕500個くらい出して当たり判定やっても全然大丈夫だった
Rubyで弾幕STG作れるじゃん

C++もういらないですねｗｗｗｗｗｗ

>>785
Cでも無意味に関数ポインタは使わんだろ
何でも使ってみたい初心者じゃあるまいし
必要性やコスト考えて不要なら使わねぇよ

>>789
んぅ？俺に言っている？実際に組込みをやっている人の意見は参考になると思うが。

>このスレに、技術ないのに頑張ってスレに食いついてる子
uyに付き合う気はないが、”技術ない”と書かれたので技術的なことをかく。

>>779
これが、どの手法・言語と比べて書いているか分からないがJMP命令やMOV命令は結果に過ぎない。

OO特有の設計（Chain of Responsibility パターンなど）や仮想関数テーブルなどを行うから
JMP命令などコストが増える。OOでの速度低下理由としては、まだ>>776が正解。

アセンブラ開発の経験があるのか？あればそんな事を書かないと思うが。

C++のクラスでのメゾットは、デフォルトだと仮想関数じゃ無いんだぜ！

>>784
ここで結論でてるだろーがカス

文盲か

>>790
ああ、そのままRuby＋木構造で書けよ
別に煽りでなく>>730で書いたとおり

世界動かしちゃっていいの？

いいよ

俺がこのまま歩き続けるだけで、世界乱されまくるけど、いいんだな　歩くぞ
寝る　明日はプログラマからドッターになる

好きにしろよ

最近俺のふりしてゴミコードをアップしてる奴なんなの？

俺をスレタイすら読めない文盲に見せたい奴がいるんだな

おまえらまだOOとか言ってんの？
OOでゲームは書けない
経験者なら誰でもしってる

さっそく世界を動かしてきた
今夜のニュースを楽しみにしとけ

iya

どうでもいいけど　風やべえ
なんかこれスーパーセルじゃねって思ったんだけど

最近でもおこｔ
2012年05月06日におこったっぽいじゃん
http://news.livedoor.com/article/detail/6532840/

マジやばいぞ
この季節に強い北風が吹いてる

http://monoist.atmarkit.co.jp/mn/articles/0703/22/news124.html

OOPで作ったらサイズが５倍くらいになった。キャッシュに収まらない。

ここのＯＯ厨が何とかしてくれるよ

inline + template + static linkのオンパレードであった

生活がおかしい
おきる→プログラミング（１２〜１８時間）→寝る（１０時間）

今4日目

毎日が楽しすぎる
寝ようとしたら明日が待ちどおし過ぎた
何が待ち遠しいか、自分の体力が回復して再びゲームプログラミングを再開出来る事
眠れなくておきた

3倍あいすくりーむｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

uyって少しはプログラム組めるようになったの？

>>759
>>761
>>769
>>777
>>794
>>809
どれが偽者だよ

>>811
高校生の時点で君より上だったと思うよ

Rubyがいくら速くなったとはいえ
まだ無茶なアルゴリズムをかくと遅くなるんだよなぁ

速度さえクリアしてれば書き直さなくていい場所を書き直してる
つまり、10年後なら書き直さなくていい場所を書き直してる

MU DA SU GI WAROTA

クッ…！こんな時にまで…！静まれッ…！
ぐおおおおお！！私から離れろおおおお！！
そもそもゲームをする時は、部屋を明るくして離れるんだああ！！
私は…私は…もう誰もきずつけたくないんべべぽ−−−！！
もうなにもかもがぐちゃどろー！

捧げろげろ血の雫！ ちゅるちゅるで！うまうまな！
じゅるじゅるじゅる吸い尽くす！お腹が空いたからーっ！
捧げろげろその体！ いろいろと！おいしそう！
あんなｺﾄやこんなｺﾄ！ ﾊｧﾊｧしやしゃんせー！！

(*ﾟ∀ﾟ)=3むっはーーーー！！
ガイアが私にもっと輝きまくれと囁きまくってる気がするじぇぇぇぇ！
しかし、このままでは私のゲシュタレイションが崩壊ングしてしまう！
ゆんゆん電波降り注ぎﾝｸﾞで、ｻﾃﾗﾋﾞｭｰ来ちゃいまひゅううう！！
なぬっ！ﾚｰｳﾞｧﾃｲﾝうめぇぇぇぇ！
おねぇさまぁぁ！そこのマヨネーズとってぇぇぇぇ！！！
Ｏｈ！Ｎｏ！塩じゃない！ 咲夜Ｎｏ！ペッパーじゃない！
ふしゅぅぅ･･･壁殴っちまったじぇぇぇぇい！！

てらてらぽんぽんのっぺらりー！
てってけぺっぺっぺ！ ぐちゅ！
とんでろでろでろもっへもへー！にへらにへらにょ！
てんぷらてんぷらからからりん！
さくさくふーふーふー！ はふっ！
わんわんにゃんにゃんにゃっふにゃふーぬこだぬこだぬ
さくやさくやさく、やくざやくざやく
ざやくざやくざや、あばばばば（^q^）!!!

朝も夜も無い螺旋の時間が 永劫に近い刻、繰り返す
「ねぇ、狂っていたのは誰？ 世界？それとも私？」
悲痛な叫びが木霊する檻の中 その終わり無い記憶━━━━。

手を伸べた黒ノ世界<Noir>には 果ても無く 何も無い
忘れかけたその歌を 儚く口ずさむ･･･

という夢を見たのだ――ヽ(･∀･)ﾉ――!!!

http://www.youtube.com/watch?v=_DFIOUJoj-0

はああああああああああああああすすみまくった寝る
23時間ｗｗｗｗっをきてるｗｗｗｗｗｗｗｗｗｗｗｗｗｗ23時間Programngungwwｗｗっうぇｗｗｗｗｗｗｗｗｗｗｗｗｗ
オブジェクト指向wwwwwwwwなみだ目wwwwwwwwwww

何だ全部偽者か

uyが盛んにプログラムいじってるってことは、絵とか他で負けてきたんだろ。

>>819
全部合わせてuy

>>790
> 弾幕500個くらい出して当たり判定やっても全然大丈夫だった


http://d.hatena.ne.jp/Longsword/20120312/1331561232
> 1万個の当たり判定矩形を描画しつつ当たり判定こなすと30fpsぐらい。5000コなら60fps。

http://marupeke296.com/COLSmp_2D_No9_QuadTree_Imp.html
> 　実行すると上のような円の衝突がリアルタイムの実行されます。
> 1500個の円を総当り法で判定すると約112万回必要になりますが、
> 上の時点ではこれを46,500回くらいに減らしています。

弾幕STGはせいぜい200描画できれば作れる

あぁ、当たり判定が必要なゲームで
最も遅くていいのが、2D STGだからね。

http://www.nicovideo.jp/watch/sm17616209

こういうゲームのほうが当たり判定少ないよ
しかもこれソースにCollisionクラス使ってないから当たり判定は直にRubyで書いて作ってる

そうだね。遅くてもいいゲームなら
Rubyでいいね。無駄に消費電力高いけど。

体感的にだけど
dxrubyのCollisionクラスで当たり判定かくのと

>>822こういう小細工なしで普通にrubyで総当りで当たり判定書くのとでは
5倍くらいの速度差があるからdxrubyの開発ではCollisionクラス使ってやるべき

Collisionクラスは、>>822ここでやってるレベルまで高速化に拘ってはいないと思うけどな
Rubyにしては十分というか、1000程度のオブジェクト出せれば十分すぎた
つうかRubyはオブジェクトの生成も遅いから
気をつけなくちゃいけないのは当たり判定だけじゃない
昨日エフェクト周りを死ぬほど改善してきた

dxrubyって何言語で作られてるの？

Cじゃね

俺のちらしの裏みたいなスレだな

http://s1.gazo.cc/up/s1_22779.jpg

これは、俺がこの一週間で漸く書けた成果な、
もちろんゲームだ。
遊び方は、眺める。
異常だ。

www.youtube.com/watch?v=_DFIOUJoj-0

らめええ！邪気眼出ちゃいまひゅううう！！ ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

無脳が認めてほしくて必死だな

http://www.youtube.com/watch?v=TJiHFgNFeGQ

ゆんゆん電波降り注ぎﾝｸﾞで、ｻﾃﾗﾋﾞｭｰ来ちゃいまひゅうううううううううううううううううううううううううううううううううううううううううううううううううう

ガンバレ、ガンバレuy
僕はuyを応援します

(*ﾟ∀ﾟ)=3むっはーーーー！！

http://www.youtube.com/watch?v=_DFIOUJoj-0

今日は当たり判定の日でしゅううううううううううううううううううううううううううううううううう
複雑な当たり判定をつくりましゅうううううううううううううううううううううううううううううううううううううううう
数学できないぼくはサンプルコードから数式わからないままにコピペするんでしゅうううううううううううううううううううううううううううううう

http://www.youtube.com/watch?v=TJiHFgNFeGQ

　 　,. -─- ､　　　　　　　 , '"´￣｀ヽ.
　 /　　　　 　｀ヽ.　　　　 /　　　　　　',
　,'　　　　 　 　 　',　　　.,' 　.!　　 　　 |
　!　　　　　,' 　 　 |　　　! 　 |.　　　　 ,'
　!　　　　 /. 　　　|-─‐|　　|　　　　/
　'､＿__／ ＞､　　!:::::::::::`::ｰﾍ.,＿.／、
　　　　 ／:::::::::`ｰ'::::;::::::::::::;::::::::::::::::::::::':,
　　 　/:::::::::::::::_」_:::/!::::::::/|ｰ‐-:/|:::::::::::!
　　_ノ::;'::::::/:::::/|:_/ |:::／ｧ‐‐-､|/::::::::::::|
　　 ￣!:::::;':::::/7´r,､ﾚ'　 　 l´'ﾊ〉|:::::/::八
　　　　',::::i::::ﾊ'!　j_ﾘ . 　　 └‐',, |／/:::::::ヽ.
　　　　 .）'＼7"　 　　 　___,　 　/:::::;'::::::::::::::〉
　　　　　／:::ゝ､　 　` ´　 　　ｲ:::::/:::::::|:::::/
　　　　〈／〉::::::/｀l7=‐--ｒｧ／ !／ヽ:::/|／
　　　　　　ﾚ'´ |／ヽ.／7ﾚ'　 /　　　 '､
　　　　　　　　　　./　/ﾚ'＼// 　 　 　 〉
　　　　　 　　　　〈　､! |／　〈　　_　　/
　　　　　　　　　　ヽ /〈〉　　 ﾄ'"´ヽr'
　　　　　　　　　 　|/　 　　　.!　　/
　　　　 　 　　　　/　 　　 　 .!　 ∧'"ﾞ':,
　　　　　　　　r／　/　　　　 |　 l.　＼ '
　　　　　　　／　　/　 　 i 　 し-'　　　＼
　　　　　ｒイ　　　/　　　 .|　　　 ',　　　　,＞､
　　　　　＼＞､_/　　　　 |　　　　　　　./__／
　　　　　　 `ｰｒﾍｰ‐ｧ-､＿」＿ｧ─-/￣／
　　　　　　　　|　￣/`ー--‐''^Y ￣「￣
　　　　　　　　|　 ./　　　　　 　', 　 |
　　　　　　　　|__/　　　　　 　　 '､__|

なんで荒らしになってしもたん？

今日は飲み会に誘われなかったので
ホーミングミサイルかいてた
まだ出来ない。。

目標地点へのベクトルと現在の進行ベクトルを適当な割合で合成してあげればいつかたどり着くよ

本物のuyは回転する三角形と円形の当たり判定をかこうとしてた
めんどくさいので投げた
2D当たり判定なんてGPUでやれっていう話

http://www.cave.co.jp/gameonline/deathsmiles/chara.html

http://www.youtube.com/watch?v=wG6KQtIFsps
デススマイルズ

確かデスマって呼ばれてたSTG

ドカタの休日にオススメ

http://www.youtube.com/watch?v=oXSTcaBUt_Q

貴様机に線引いて 「お前この線超えたら切れっからな」
とか言っちゃえよ ほらぁｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

荒らしてごめんなさいしにます

1個分かったけど
ゲームのシーン管理は木構造じゃダメだ
オブジェクト管理は木構造でいける

シーンはグラフだねこれ
そんでグラフは面倒だから並列でシーン管理

木構造で何とかならない事もないけどヤバイ事になるぞ

そういえばこれ実装した時に1個不安要素あったんだ
木構造じゃなくてグラフにする方法がないって
よく考えたら木構造で管理は無理かこれ･･･
木構造じゃダメだったごめんね、完璧をやるならグラフだ

え、でもオブジェクトは木構造でいいのに
どうしてシーンだけグラフになるんだろ？

オブジェクト同士がグラフっていう状態はありえないよね

でもシーンはどう考えてもグラフになる

どこか見落としがあるのか･･･

いやまて「グラフ分岐」とか「グラフIF」ってものが必要という結論に至った
現代の言語にそんなものねーよ
今の言語と上から下にしか書くことの出来ないエディタじゃどう考えても
完璧を作るには色々と厳しい、妥協ばかりだ　でも進む

グラフIFを　グラフIFなしでかくとこうなる↓
IF（　A　) ｛
　C
｝
IF（　B　）｛
　D
｝
IF（　A ｜｜　B　）｛　　
　E
｝

んで、グラフIFがあるとこうなる
GrahuIF（　A　) ｛
　C
　Grahu｛　E　｝
｝
GrahuIF（　B　）　｛
　D
　Grahu:E
｝

これは、つまりGOTOだ
GOTOを入れるか、あるいは動的言語だったらコンパイル時に
　Grahu｛　E　｝　を評価していないと　B　分岐に入った時に　E　が未定義となる
俺様の見ている完璧はこれがないと実装不可だった、別に100%の完璧とか今は無理だと知っているから目指していないから90%でも進むけど

そんで今の言語でこれは実装できないから仕方なく
GrahuIF（　A　) ｛
　C
　include "E"
｝
GrahuIF（　B　）　｛
　D
　include "E"
｝

function E　｛

｝

こんなことになってる　　以上が、グラフIFの発見と定義でした

グラフはGraphだろ……

は？

グラフIFは、C言語のswitch、caseと似てる

けどほとんどの言語でswiitch,cesuは勝手にbreakされるように修正されよった

だから今こそそれを復活させる為にグラフIFが必要なんだおｙ
わかるかね？

俺様はシーン木構造の設計の失敗を認めよう

シーン構造だけは木構造じゃなくてグラフだったｗｗｗｗｗｗｗｗ
そこは俺の失敗だ、そしてソースコードでかいてる木構造をグラフのように見せかける構文が世界中のどの言語にも
おそらく存在していない事実も･･････　俺の失敗だ

オブジェクトはなおも木構造でかいてても問題はおきてない
今回はシーン構造を木構造のまま無理にソースを進めたので
グラフになるはずだったノードはひとまとまりになった為、
わずかに柔軟性が落ちた

でも、元々普通のソースコードはノード（階層）が1個しかないんだ
俺様の木構造ラムダの世界では、3層にわけるはずだったノードが1層にまとまった程度で、case、whenと
なつかしの　ＰＨＡＳＥ変数 で処理わけしたので、プロジェクト進行にたいした影響はない
貴様らはよくゲームにおいてＰＨＡＳＥ変数（）を使いまくるんだろうけど、俺様はこのPHASE変数を作り
スウィッチ文だとかcase、whenで処理を分けて書くというのは、俺様の中で「何も考えてない証拠」だとしている

だって、結局、case、whenを出すって事は、
1 イテレータにもまとめられず、
2 IFだけで何とかする事も出来ず
ソースコードを汚しているんだ

ちょっと例題がわかりにくかったな、
俺様が今欲しいGrahuIFはこう。

これが出来ないとソースコード上にかかれた木構造はグラフになれない
全体をメタ ＆ evalしてしまえば、一応かけなくはないが、
あまりそれは好ましくないだろう

GrahuIF（　A　) ｛
　C
　GrahuIF（　F　）｛
　　Grahu｛　E　｝　　　　←　☆
　｝
｝
GrahuIF（　B　）　｛
　D
　Grahu:E　（　☆へ飛び、そしてここへ戻ってくる　）
｝
GrahuIF（　G　）　｛
　H
　Grahu:E（　☆へ飛び、そしてここへ戻ってくる　）
｝

新しい言語を創造して使っているので
Grahuで問題ない

東方アレンジ聞きまわってたらテンションあがってきたｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
創作意欲がヤバイｗｗｗｗｗｗｗｗｗWWWｗｗｗｗ
グラフIFとかなくても世界変えてくる

俺ほんというとしばらく東方はなれてた
まともに東方情報を調べるのは4年ぶりくらい
２００８年からの２年は東方の一部しか見てなかった
２０１０年からの２年はほとんどの情報シャットアウトされた状態だった

ニワカうぜーよ。お前が東方語るな。

STGの最高峰はアインハンダー
異論は認めない

にわかだよｗｗｗｗｗｗｗｗｗｗｗｗ
原作知らないでニコ動や二次で騒いでるだけのにわかだよｗｗｗｗｗｗｗｗ
ゆとり東方厨だよｗｗｗｗｗｗｗｗ
そもそも、最初に原作ちょっとプレイしただけでそのあとは二次同人しかほぼ見てないよｗｗｗｗｗｗｗｗｗ

にわかゆとりオブジェクト指向ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

そういえばマジックコードと呼ばれた
「５」については
35になってしまった

自機ショットのホーミングは、普通にかくと一周してからホーミングになってしまうから
せめてそれが半周で住むように
atan2で相手目標座標を見た時に1回だけ
angle += 180 if angle <= tmp
angle -= 180 if angle >= tmp
こんな処理を混ぜると良い

え？ 180 ってまさかお前・・・

さらに凄いことがわかった
GraphIfは車輪の再発名だった

>>867
やべえマジックコード４つも出してしまった

5
35
1
180

これはよめない
よくみるとatan2の2もマジックコードで5つつか

これはよめん

ああああやばい


これはやばい


まじやばい






ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

ニセモノに注意しろ
おれはOOが出来ないからこのスレを荒らしてるだけだ

http://www.youtube.com/watch?v=UR_pc-6T9sM&feature=relmfu

http://www.youtube.com/watch?v=mg4HmNrnU9E



もううううううううう
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｈｗｗｗｗｗｗｗｗｗｗｗ


わからないよな･･･････････

ｓｗｗｗｗｗｗｗｗｗｗｗｗｗ

ｗｗｗｗｗ

>>867
ひゃくはちじゅうwww

だいじょぶかこいつwww

初心者ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ホーミングっていうのは、完全追尾ではなく
性能をわざと落とすんだよ
で、性能をわざと落としているから

>>708
こういう処理が必要になるわけ、いいか初心者？

で、そういう処理があるせいで、性能が落ちすぎたから
今度は性能を上げる為に>>867
こういう処理が出てきたわけ


ここまではググれば良くあるホーミング弾の作り方だぞ初心者ググレカス

ほんとに、あっちのスレもこっちのスレも素人しかいない

同じ奴が俺についてきてるわけじゃないんだろ

どうなってんだこの板

ゲームの話はよそでやれよ

俺以外ほんと誰もかきこまないな
話についてこれないクズばっかだ

雑魚共が

雑魚とは違うのだよ雑魚とは

自分から話ふっといてまけたらそれ
ゲームの話はよそでやれとかｗｗｗｗｗｗｗｗｗｗｗｗ

ワンパすぎて飽きた

本当に板のレベルが低くなったと思う
このまま低くなっていってどうなるんだろう
ツーラーばかりになるのかな
1個の目的を果たせればいいし、広域の知識とか必要はないけどな

ツールさえあるなら
Rubyでプログラミングすることさえバカらしいか

ここまでで実装できたのは
めにゅー、せっていがめん、きゃらせれ、ぶきせれ、
弾幕管理、敵、自機、敵しょっと、じきしょっと、えんでぃんぐ画面、
自機用のオプション、で自機用のオプションにうたせるショットで苦戦中
ぼーっとしながらコードかいてたら無駄な階層作ってしまった

やっぱ平坦な管理のほうが、眠くなってきた頭にとっては楽だなとは思う
起きてる状態ならかけるけど眠くなったらもう絶対だめだ

全体ソースは2500行を越えた
まだ内容はほとんどない、ここから内容書き始めると数千行単位で増えていく

昔にC++で実装したことのある関数を
再びるｂｙで実装してるのがちょっとバカらしい
言語を変えるのはこれを最後にしたい

Rubyの欠点はバグだらけなことだな

結局作れればどうでもいい気がしてきた
ネームスペースがある時点で
$のグローバル変数使いまくるとかしない限りは
どんなにアホなソースかいても、はっきりいって破綻しない

そして思うことは
オブジェクト指向はゴミカスすぎる
OOなんかで作っていたら時間かかりすぎだろ

ゲームプログラムに必要なのはネームスペースとコピペ、あとは手続き型のソースで良いわ
だって9割くらいがソースコードの再利用しねーし、しねしね

ちょいとコンストラクタの使い方がおかしすぎてヤバイ
ていうか、コンストラクタって他のメソッドの呼び出しより確か遅いはずなんだよね
最初にnewして、create関数作ってそこでオブジェクト生成でもいい気がしてきた
newでオブジェクトは、なんか知らないけど好きになれない

ライブラリ側で使うオブジェクトはnewでいいんだけど、
複数個作る事が決定してるオブジェクトって、newじゃいほうが実は良いのではないかと

3倍あいすくりーむ

今回のProjectで木構造ラムダは、主要オブジェクトで無駄な階層を作ると命取りだから
階層関係だけは気をつけて書かなければならない
エフェクトのように短命のオブジェクトで当たり判定も必要としないものならいいんだけど

あとはシーン関係も、別に階層作りまくってかまわない
無駄に階層作っちゃいけないのは当たり判定をやってるオブジェクト

ただこれも別に俺、木構造の上下を検索して目的にオブジェクトを見つけ出すメソッドを
用意してることはしてるけど、今回は速度の為にあえて、そういうのやめている
それを使えばいくらでも階層作りまくっていいんだけど惜しいな
あと少し速くなるまで待とう

だから結局ソースコードは絶対パスで作っちゃってるから、再利用する気はあまりない
随時検索して相対パスで作れば再利用できまくりだけど、検索が必要になって速度が落ちる
ぬるｐ

がっ

グローバル変数のスタックというものを用意した
実際、スタックじゃないけどな
シーン間のデータのやり取りって、
一番いいのはファイル出力と、ファイル読み込みだと思われる
でもなんか今のWindowsだと問題起こりそうだからやめた
結局グローバル変数だ
引数にするのが良い設計に見える、が
引数指定だと、製作途中にも引数に気をつけなくちゃいけなくなってしんどい
めるめれｍっれむえｒむえｒむえｒむ

がt

Sound用意しないとしぬ

一番めんどいのがhash during iterationなんとかerror
木構造はハッシュではなくArrayで実装すべきだったとときより後悔する
内容は、ハッシュAのイテレーター廻してるときににハッシュAにstoreは出来ないよという事だ
Arrayだったらイテレーター中でもpushできるのに、あほなの

それにしても眠い頭にとって木構造はきつい

俺の朝方はいかに頭冴えていて、
今がどれほどアホになっていることか
だめだ

体力が、

ピザ籠りの俺の体力は限界だ

とりあえず名前をkardとかyuyuにしとけばいいんじゃないかな。

俺は基本的に変数宣言をしない

とりあえずオプション実装した眠い

次は当たり判定を何とかしないと死ぬ

ソースがやっばいｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
吹いたｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ


Shot.newとかかいてるのにinitialize空っぽだしｗｗｗｗｗｗｗｗｗｗｗ
ワロタｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
classとかかいてるのに、どう見てもただの高価な構造体
流石に眠すぎておかしなことやり始めてる

これは笑える　笑えるこのソース
かいてるクラスの半分以上のコンストラクタが機能してないｗｗｗｗｗｗｗｗｗｗｗｗｗ空っぽｗｗｗｗｗ
つうかコンストラクタにかかなくても良い処理ｗｗｗｗｗｗ
実際クラスの戻り値なんていらねーもんｗｗｗｗｗｗｗｗｗ
何ｗｗｗｗｗｗｗｗｗｗそんなにオブジェクト指向をやりたくないのか俺ｗｗｗｗｗｗｗｗｗｗｗｗｗ

クラス.newで　オブジェクトは作る　オブジェクトは作るが、Shotクラスのオブジェクトを作るわけじゃないものｗｗｗｗｗｗ
コンストラクタ内部で木構造のノードを作るんだものｗｗｗｗｗｗｗｗｗｗｗ
クラスｗｗｗｗｗｗｗほんとはいらないｗｗｗｗｗｗただのｗｗｗｗｗｗネームスペースｗｗｗｗｗｗ
クラス＝＝＝＝＝ネームスペースｗｗｗｗｗｗｗ

ほんとにこれクラスいらないな

@変数が欲しいからクラス使ってたけど、newが可読性下げるわ
ネームスペース欲しいだけだからmoduleの特異メソッドのほうが良い

クラスいらなくなった

return 0;

クラスって何

グラフって何

ググフっ で何

何

ガンバレ、ガンバレuy 
僕はuyを応援します 

三角形と円の判定は外積とかその辺使うと割と単純だったような。

ポリゴン同士のコリジョンの勉強するとすぐ判るようになるよ

当たり判定しないと地球崩壊するとか言うなら、本気だせば出来る
ただdxrubyのCollisionトライアングル.newの仕様にあわせなくちゃいけないから2倍面倒
別に円と矩形の当たり判定だけあればどうとでもなるから今回はスルーする

マジレスすると応援いらない
ただ何かがやりたいだけでしかない

なんていってみたけど
応援よろしく

wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
3倍アリスクリームｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

http://www.youtube.com/watch?v=MhoOlSGLcfw&feature=relmfu

マジレスすると俺が本当にやりたい事は>>916だった

プログラミング（）とか引きこもりすぎだろバカか
バカじゃねの

1000時間のプログラミングより1分の音楽演奏

http://www.youtube.com/watch?v=p6skE28zc_M

http://www.youtube.com/watch?v=_i4dUEcILhc&feature=relate

音楽や絵では若いうちから才能発揮する奴っているのに

プログラミングの世界ではそれ少ないんだよね

何故だろうか
ひとは数字に弱いのか
面白くないからか

プログラムは他人の資産の積み重ねだから。

すごい天才がいて、なんでもすぐにできたとしても、
0から作るのはそれなりに時間がかかる。

でも他人が作った資産があるから、uyみたいな初心者でも
それなりのものが簡単にできてしまう。

できたものでしか判断されないから。
天才であっても目立たない。

そんなことは聞いていないよバカ君
目立たない ＝ 天才ではない

そこも木琴の少女だって目立たないタイプの天才だ
それを俺は動画を見つけてきただけ

プログラミングの世界で、若年層の天才はほぼいない
Rubyの中学生以上の中学生って日本に何人いるのか？
俺としては20人程度はいてほしい
でも実際いないんだろうなぁ

多分、話題になった当初での年齢技術ランキングであいつは1位
高校生くらいの年齢になると、スロースターターも技術つけてくるからいつまでも1位じゃいられないだろうが

中学高校でプログラムなんて覚えてもなんの意味もないじゃん
プログラムだけやってきたって奴は古今東西使えたためしがない
ちゃんと数学や物理やってきた大学生に半年で負けるよ

プログラムなんて組めるようになったらそれで頭打ちなんだよ
そこに違いはない

>>922
プログラムできるからって職業にする必要はねーだろ？どんだけ社畜の発想だよ
負けるって何に？人生にか？収入か？
あと意味があるかどうかでいったら絵や音楽も何もかも同じだよ
何でもいいから1個のスキルを伸ばして力を提示することが娯楽だろ

つうか今の社会底辺と化してるIT業界に入ってくる大学生なんて
ロクなのいねーのは知ってるよ
過大評価をするな

>921
じゃあ聞くが、お前は何を見て
プログラミングの天才かどうかを判断するのだ？

ちゃんとやってれば、プログラミングなんて半年でサマになるものなんだよ
2年やれば一人前になっていなければおかしい

と、俺は思う

1年てなげーだろ････
1日3時間のプログラミングとしたって、
1年で1000時間以上やってるわけだ
2年で2000時間、

それだけやって、力がつかないというのは、まじめにやってない証拠
つまり、面白くないから本気じゃない

子供なのに大人と同じ程度のことが出来る。
それが子供レベルの天才というもの。

＞＞９２４
話をズラしてんじゃねえハゲ
天才じゃなくても力がある奴ならそれでいい

>>925
プログラミングの”勉強”だけしてれば
長いね。

実際は、勉強以外、物を作るという作業が多いんだけどね。

あぁ、勉強だけしていればよかった頃に戻りたい。

>>926
それでいいんだよ
成長がそれだけ速いって事なんだから
2000時間やらなければ覚えられないものを、既に覚えているのならば
2000時間を別のことに使える


つかもう答えでてる
プログラミングが、「子供の遊び道具」になってないから、全然できる奴がいないんだ
一言、言ってやる　　プログラミングはおもしろくない

力があっても、話題にならなければいないのと一緒。
本当はいるのだが、知らないだけなのだ。

>>929
> 成長がそれだけ速いって事なんだから

俺は成長が早かったよ。

小学校の時、背の順番で後ろのほうだった。
だが、今は小さいほうだ。

>>930
力のある奴の中から話題になるのが一部ってのはどの分野も一緒

相対的にみて少ないといってる

>>931
面白いと思ってそれかいた？
一言、言ってやる　　おまえはおもしろくない

> 2000時間やらなければ覚えられないものを、既に覚えているのならば
> 2000時間を別のことに使える

それだけの時間があれば、学校の成績も良かっただろうにｗ

>>932
なぜ少ないと思ってる？
お前が、知らないだけだろ。


そりゃ知らないわな。
人一人の時間じゃ、大したものは作れないから。

つうか「プログラミングが難しいものでした」なんてのは俺はイヤなんだよ
適正？知るかそんなもの
こんなもの音楽さえできなかった負け犬の俺でさえ出来るんだから
難しくないものであってほしい
でないと俺はやっている事がアホ過ぎる
自分の適性のなさと、ある種の適正を認めたことになる


他の事が何も出来ず、
人殺しの才能にのみ長けてしまった者がいたとしたら、
そいつはどんな気持ちなんだろうな

はっきりいって俺は形になるもので勝負をしようとしたときに
残念ながらプログラミング以外で他人に力を見せつけ勝つ事は不可能だ
どうしてこうなった？

プログラミング を 戦争だとすれば、
俺は戦争しか出来ない。
他の事で勝負したら、どうにもならない程に何も出来ない
それが怖くて、戦争をするしかない
負けることに耐えられる奴は多いと思うが、俺はそうじゃない

「勝てないこと」に耐えられないんだ
俺からプログラミングを取った場合、俺は他人と比べ、圧倒的に力で勝るカテゴリーをなくし
ただの凡人と化す

例えるなら俺は戦場で無茶な戦いを続け
自分を殺してくれる奴に出会えるまで戦い続けてるだけ

はじめはこれですぐに死ぬと思ってた　楽になれると思ってた
だがいつの間にか戦いになれ、殺しになれ、今の俺はまだここに立っている
死ねない　死ねない　死ねない　

もう見渡す限り、地平線の彼方まで探しても自分を殺してくれる者はいない

という夢だったのだ

つうかもう遅いな

難しいものだろうと、簡単なものだろうと、
出来るようになってしまったらもう関係ない

他人の成長の様子なんて気にしてられるか
全員死ぬが良い

何もかも遅い
手遅れだ


木構造について
やっぱ人には無理だろこれ
俺以外が触ったら1日で発狂する

他人が理解するしないは関係なしに
続けるけど

発狂するだろこれ
意識しなくちゃいけないネストは今6くらい
でも実際はもう裏方で20ネストくらいか
1度バグがでたとき、そのネスト構造を把握してなければバグは取れない
おそろしい設計だな

実際再帰なんだよこれ
平坦な管理じゃない管理方法は、概念的に再帰になる
楽しすぎてｻﾃﾗﾋﾞｭｰでちゃいまひゅうううｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

ほら、やっぱり絵か音で負けてきたんじゃねーか。

絵も音楽も俺は才能がない
だからゲームむりぽ

いまごろ気づくなんて、、、

プログラミングで負けたとuy自身が思えるようなことが、2chにはないのだとしても、
海外のコミュニティーや有名なOSSに参加すればいるかもよ。

それをしていないならば、それができないのか、本当は殺されたくないだけ。

俺はそんなの参加しねーよ

俺には無理だ

今日
俺にはマナーがないって言われた

バカが言ってることはわからないな

uyは知性だけじゃなくて
マナーもないのか。

いるかもよ　って稲ーんだよ
俺が何を見つけたかも知らずによく言う

そもそも俺はソースコードを1文字にするところまでのリファクタリングの道のりを知った
これから世界が数百万年かけてそれに向かっていく
その次は0
これが何を意味するかを知れ

俺様クラスの奴が、もし世界に貢献したら大幅にショートカットはされるだろうが
JAVA、PHPのような言語が広く使われている時点で、また世界は大きく遠回りしていく

今はオモチャみたいな現代の言語で
その思想に似せた設計をかいて
世界がいつ気づくかどうか、そのやり取りを楽しんでいるだけ

音楽というのは、音を鳴らした時にせいぜい数秒から数十秒で聞こえなくなる
まさに一瞬の出来事で、形に残らないものは無駄と思うかもしれない

しかしな、ソースコードをかいて
プログラムだったら形に残るなんていうのは思い違いだ
それさえも一瞬の出来事でしかない

たとえ100年、1000年使われたとしてもな
1、そして0のリファクタリングまでを見た時、

今まで書いた全てのプログラム、ソースコードは最高のリファクタリングによって無意味となる

音楽で言えば、楽譜がソースコードで演奏がインスタンスだから
その理屈はおかしい。
どちらにしても、お前はバッファになれない。

ちょっと言われたらムキになって妄想に逃げる。面白ぇ。

満足感が得られないのは
皆が凄いといえる成果が未だ出せないからだろ。
有無を言わさぬ凄い成果物を何故出さない。
それが出来ないといつまでたっても堂々巡りの
無限ループ再帰状態から抜け出せんとちゃう？

つか日本もプログラマーの歴史は十分に長い
優秀な理系の知識知能を持つプログラミングを生業とする父親を
持つ中学高校生も相当数いるはず。
子供のころから父親の誘導やプログラミング環境の中で
普通の家庭環境にいる子より圧倒的に早く能力を伸ばしてもいいわけだ。
父親が10年かかったことを一年でマスターするとか、
しかし、ただ目立たないだけなのか俺が知らないだけなのか
誰もが認める成果を出した有名中学高校生ってあまり聞いたことがない。
おそらく、そのような環境にある親も本人もプログラミングのみにうつつをぬかしていたら
将来いびつな生活を送ることになるのを常識として知っていて、
抑制的でバランスの取れた生活を送ってるのが普通なんだろう。
実際他にやるべきことが多いしね。