タスクシステム総合スレ part4

タスクシステム総合スレ part4 at GAMEDEV

[前50を表示]
100:名前は開発中のものです。
09/02/06 01:17:02 ZPF/rc3n
引数君がアンチタスクだということは知っているが、前スレ終わりごろの
議論の内容がよくわからん
俺は>>2＝チンカスゴミカス　だと思ってるが引数君とは批判のベクトルが違うようだ
彼は数種類のクラスに共通のインターフェースを与え、共通のコードから呼び出す
というメカニズムを全否定してるのだろうか？だとしたらそれは仮想関数の全否定であり
わけわからん

引数君の主張内容がよく分かってない

101:名前は開発中のものです。
09/02/06 01:25:06 1vrKKSIM
>>100
>>12

102:名前は開発中のものです。
09/02/06 01:29:48 ZPF/rc3n
あぁ？

103:名前は開発中のものです。
09/02/06 01:34:39 1vrKKSIM
引数君の主張なら>>12のリンク先を見れば十分わかると思うんだが、わからないのか？

それとも、あんたも日本語の残念な人か？

104:名前は開発中のものです。
09/02/06 01:39:11 ZPF/rc3n
俺は前スレの>>823だ。何なら他の発言も発掘してこようか？

105:名前は開発中のものです。
09/02/06 01:43:50 OdnmQxD5
引数君の方がまだ技術に近い話をしてる分マシだな。
もしかして彼はひらしょー氏の言うデータと処理の分離を
超まわりくどく主張しているのかな。

106:名前は開発中のものです。
09/02/06 01:50:49 1vrKKSIM
>>104
前スレ823か。

引数君よりは能力的にマシだということはわかるが、説明がくどく、わかりにくい。

俺はこんな内容の薄い、回りくどい説明を読むのはまっぴらごめんなので、さいなら。

107:名前は開発中のものです。
09/02/06 02:08:15 EVIE955W
ESP能力に問題があるID:1vrKKSIM は
すべてのアンチタスクがスレ主に見える病気を克服するべき

108:名前は開発中のものです。
09/02/06 02:09:41 ZPF/rc3n
超能力能力か

109:名前は開発中のものです。
09/02/06 02:12:05 EVIE955W
くっ…。どうして「お前はバカを克服するべき」って言ってくれないの？
内容の薄い、回りくどい指摘を読むのはまっぴらごめんなので、さようなら

110:名前は開発中のものです。
09/02/06 07:38:45 RQ4iGJCo
お前等馬鹿は、プログラミングで一番時間がかかるのはどこですか？
と聞かれてコーディングとは絶対に答えないくせに
コーディングの手間ばかり減らすことに執着している
なかなか読めないプログラムってなんだ？
構造が複雑なプログラムじゃないの？
お前等馬鹿は全く逆のことを自己満足のためにやっているオナニストだ
プログラマならせめて理詰めで動けよ
お前等凡人から理性まで抜いたら猿と変わらないだろ

111:名前は開発中のものです。
09/02/06 09:47:48 SpEabv2C
>>32
えーと、この人ってイイ歳した何者なの？プロ？パソゲー専門なんじゃない？

＞ビデオゲーム黎明期においては、オールアセンブラで書くことが普通だったので、
＞std::listのような便利なコンテナがあるわけでもなく、技巧的な方法でstd::list
＞みたいなことを実現していただけ

えっえー？この人のいうビデオゲーム黎明期っていつごろのお話なのかな？
70年代？だったらまずZ80アセンブリで>>2を書いてみればいいのに。おかしな人だよ
16bit機時代？intrusiveなコンテナを使った理由がオールアセンブラだから？本当に？

最近は想像だけで昔話を書いても教科書になるのかしら？
どこのゲー専の子が犠牲になるのかしら。ちょっと可哀相ね
知らないことは知らないって言えばいいし、足を使って取材しに行けばいいと思う
んで、頭下げて監修してもらえばいいと思う。このままじゃあんまりだよ

＞古典的なタスクシステムにおいてはタスクに番号(プライオリティ)が振られており
＞番号を指定して特定のタスクのポインタを得ることが出来た

えっえー？つーか古典的タスクシステムってなんじゃい？ファンタジーゾーンなの？

112:名前は開発中のものです。
09/02/06 10:34:43 wGKtGJau
>>111
あんた、何かがしゃべり方がキモイんだけど。

それはそうと、相手は年収何千万もある凄腕のプログラマらしいので、
技術的な反論は是非どこかのブログでやっちゃってください。

113:名前は開発中のものです。
09/02/06 21:26:12 +KF0MHRv
タスクシステムでグローバル変数使うから駄目だって意見が多いけど、
でも見渡してみると、ウィンドウズのウィンドウだってそういうしくみだしなぁ。

114:名前は開発中のものです。
09/02/06 22:07:10 H/Ui7lv7
エロゲー製作は大変ナリよ
URLﾘﾝｸ(d.hatena.ne.jp)

115:名前は開発中のものです。
09/02/06 22:31:40 RQ4iGJCo
>>113
ウィンドウ同士であまりやりとりしなくてもあの複雑さだぞ
リストコントロール２つを連動させるだけでもやばいくらいの手間
基本的にウィンドウズの作り自体関連がたくさん生まれる処理に向いてない
あくまでも独立した動作が前提

116:名前は開発中のものです。
09/02/06 22:36:12 nWDkACnD
>>113
そう思ったのなら両方とも自分で実装してみて比較検討だ！

でも数千行レベルでは使いやすかったやり方が数万行レベルでも同じように使いやすいままかどうかはまた別問題だ！
そこは注意な！　王道はグローバル変数使わないことだぞ！

117:名前は開発中のものです。
09/02/06 23:12:31 ux7UjNgY
また引数クンの登場か。

>93について、具体例を挙げて答えてよ。

118:名前は開発中のものです。
09/02/06 23:44:30 H1z7Q+5u
>>117
はぁ？何言ってるのかわからない
俺が言いたいのは関数に引数つけろってそんだけだけど？
コンテキスト？は？
そんなもん使った時点で負けだ馬鹿
設計死んでるんだよ
俺の価値観ではそんなもん使った時点で負け
void*となにも変わらない

119:名前は開発中のものです。
09/02/06 23:45:58 H1z7Q+5u
まあ、用は固定でない引数に意味がないんだよね
俺の価値観からすると

120:名前は開発中のものです。
09/02/06 23:53:12 4xm8YBEc
>118
> はぁ？何言ってるのかわからない

じゃ、具体的に質問するけど、雑魚敵Aと雑魚敵Bに関係性が出てきたらどうするの？
例えば雑魚敵Aは雑魚敵Bを殺すことがある、となった場合に、雑魚敵Aのupdate関数の引数に
雑魚敵Bのリストを渡すの？

121:名前は開発中のものです。
09/02/07 00:21:27 lLkuERdr
>>120
>雑魚敵Aのupdate関数の引数に雑魚敵Bのリストを渡すの？
それをやってはダメ
哲学的になるけど
基本的に雑魚敵Ａが雑魚敵Ｂを殺す現象ってのは
雑魚敵Ａの中の処理でも雑魚敵Ｂの中の処理でもないでしょ？
つまり雑魚敵ＡＢに書くべき処理ではない

このアクションはあくまでも雑魚敵Ａと雑魚敵Ｂが存在する空間で起こったことであって
それをシーンクラスとしたらそこに書くべき処理じゃねぇかな？
オブジェクト指向的にはよ

俺はオブジェクト指向原理主義者（テロリストではないｗ）だけど
基本的にオブジェクト指向を変な解釈をしないとしたら
種類の異なる（＝クラスの違う）雑魚敵Ａ、雑魚敵Ｂ、雑魚敵Ｃ、雑魚敵Ｄといたとして
それらの関連、つまりＡｘＢ、ＡｘＣ、ＡｘＤ、ＢｘＣ、ＢｘＤ、ＣｘＤの関連は全部シーンクラスに書くべきじゃないのかな？
そこはオブジェクト指向は手伝ってくれないと思うんだけどね（原理主義者的には）
昔ながらのＣ言語風味に書いたほうがうまくいくと思うよ

122:名前は開発中のものです。
09/02/07 00:23:19 UFXAc++2
>121
> 種類の異なる（＝クラスの違う）雑魚敵Ａ、雑魚敵Ｂ、雑魚敵Ｃ、雑魚敵Ｄといたとして
> それらの関連、つまりＡｘＢ、ＡｘＣ、ＡｘＤ、ＢｘＣ、ＢｘＤ、ＣｘＤの関連は全部シーンクラスに書くべきじゃないのかな？
> そこはオブジェクト指向は手伝ってくれないと思うんだけどね（原理主義者的には）
> 昔ながらのＣ言語風味に書いたほうがうまくいくと思うよ

今はっきりわかった。キサマはクズだ。

123:名前は開発中のものです。
09/02/07 00:30:10 lLkuERdr
>>122
なんでだよ
いいこと教えてやったのに
何がどうダメなのか言ってみろ
勉強になるぞ
なにせ俺は１０年以上もやってんだからな

124:名前は開発中のものです。
09/02/07 00:32:45 NuBn44S3
10年以上ワナビー君ですかwww
ヒッキーニートで親のスネカジリ。楽しそうですねwww

125:名前は開発中のものです。
09/02/07 00:35:05 lLkuERdr
>>124
不毛な会話したくないんだ
どこがどうダメなのか思ったこと言ってみろ
なんとなく漠然とある自分にとっての常識なんて大抵間違ってる場合が多いぞ

126:名前は開発中のものです。
09/02/07 00:38:14 NuBn44S3
>125
雑魚敵が20種類くらいいるとして、それが相互に関係しあうことを考えてみろよwww
20種類くらいなら、RTSとかだと当たり前にいるぞ。

127:名前は開発中のものです。
09/02/07 00:38:49 XPRCk6pD
というか、どういえばいいんだろう。
あっちのスレでも書いたんだけど、どの処理を誰が担当するかが難しいわけであって、
タスクシステム云々、グローバル変数云々はあんま関係ないと思うんだが。
たとえば、石クラスと、マップクラスと、それらを管理するシーンクラスがあったとして、
・石に重力を働かせる処理
・石と石の衝突処理
・石とマップの衝突処理
は、それぞれどのクラスが担当すべきだろうか。

128:名前は開発中のものです。
09/02/07 00:39:00 qvO9PNvj
ヒッキーだが有能なゲームプログラマの発言＞＞＞＞＞＞＞＞＞＞＞＞＞＞
＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞
＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞
＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞
＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞
＞＞＞＞（越えられない壁）＞＞＞無能な社会人もどきヘタレグラマの妄言

それがここのルールだ。覚えておきな。

129:名前は開発中のものです。
09/02/07 00:39:49 lLkuERdr
>>126
そりゃ当然それだけの処理が必要になるだろうね
仮にプログラムの組み方が変わったところで
その数が少なくなることは絶対にないからね

それを踏まえて何が問題？

130:名前は開発中のものです。
09/02/07 00:40:05 qe8S2N76
>雑魚敵が20種類くらいいるとして、それが相互に関係しあうことを考えてみろよwww
>20種類くらいなら、RTSとかだと当たり前にいるぞ。
ダブルディスパッチ

131:名前は開発中のものです。
09/02/07 00:41:54 XPRCk6pD
>>126
その莫大な組み合わせを纏めるかどうかは書く人の力量次第だが、
書く場所としてはシーンクラスが良いのでは？ってはなしだろ。
お前が読解力ないだけ。

132:名前は開発中のものです。
09/02/07 00:42:20 lLkuERdr
>>127
全部シーンだろうな

133:名前は開発中のものです。
09/02/07 00:43:44 NuBn44S3
>128
ヒッキーで無能はどこにいるんだ？

134:名前は開発中のものです。
09/02/07 00:46:56 XPRCk6pD
>>132
となると、シーンクラスが肥え太って困る。
モジュール化する何かいい方法は無いですか？

オブジェクト指向ってのは、オブジェクト(リソース)の管理は上手いんだが、
オブジェクトとオブジェクトの関連の記述には向いていないんだよなぁ。

135:名前は開発中のものです。
09/02/07 00:48:05 qvO9PNvj
>>133
居たら教えてくれ。

136:名前は開発中のものです。
09/02/07 00:48:40 cn84NiHO
>>79
どうでもいいけど、やねうらおの文章の引用部分さ

> すべてのゲームにタスクシステムが必要なのではない。

これ文脈読めばわかると思うけど、規模じゃなくて種類の話だよね
あと、残念な○○っていう表現が大好きなブログがあるよね

137:名前は開発中のものです。
09/02/07 00:49:07 lLkuERdr
>>134
ないね
オブジェクト指向ではそこが限界
原理主義者の俺が言うんだから間違いない
後はＣ言語風味にうまく分離して書くしかない

138:名前は開発中のものです。
09/02/07 00:50:51 UFXAc++2
>137
> ないね

単にモノを知らないだけだな。

139:名前は開発中のものです。
09/02/07 00:51:10 e1gHG0fD
>>127
衝突したかの判定はシーンクラスで、衝突に伴う処理は
オブジェクト同士のメッセージ交換ってのが俺のやり方だな。

140:名前は開発中のものです。
09/02/07 00:55:40 UFXAc++2
>127
物理エンジンで本物っぽく動かすつもり？
それとも2Dのマリオやソニックみたいに、それっぽく動けばいいの？

141:名前は開発中のものです。
09/02/07 00:55:51 lLkuERdr
>>138
関連をオブジェクトに見立てて・・・とか馬鹿なこと始める気？
俺、そういうの読み手にわかりにくくなるだけであんまり意味ないと思うぜ
折角オブジェクトが誰にでもわかる表現にするためにオブジェクト指向を使ったのに
変にトリッキーな解釈（関連＝オブジェクトだ！）してわかりにくくしたら
本末転倒じゃね？

って勝手に関連＝オブジェクトの話するだけこいつ馬鹿だなー的
先読みをしてみたけど言いたいことあってる？

142:名前は開発中のものです。
09/02/07 00:56:33 XPRCk6pD
でもちょっとまって。
この流れでいくと、タスクシステムで行うべきことは、
・描画順序の管理
のみ、ということになるな。
その他の処理はすべてシーンクラスで行うと。
晴れて、タスクシステム＝グラフィックエンジン
ということになり、みんな幸せになると。

143:名前は開発中のものです。
09/02/07 00:56:47 hO/vsQBF
>>127
俺なら重力は重力クラスが担当、衝突は衝突クラスが担当するようにする。

重力に引かれたい奴は重力クラスに登録するように！

144:名前は開発中のものです。
09/02/07 00:56:49 vE7+xmqT
オブジェクト指向的には、当たり判定は関連をクラス化すればおｋ

145:名前は開発中のものです。
09/02/07 01:00:11 vE7+xmqT
>>127
石に重力が働くというのなら地面みたいなものがあるはずだから、
石ー重力ー地面としてこの重力をクラスにすれば使いまわしも出来ていい

146:名前は開発中のものです。
09/02/07 01:03:06 UFXAc++2
>143
つ【オールドタイプの魂】

147:名前は開発中のものです。
09/02/07 01:04:31 cn84NiHO
>>121
＞基本的に雑魚敵Ａが雑魚敵Ｂを殺す現象ってのは
＞雑魚敵Ａの中の処理でも雑魚敵Ｂの中の処理でもないでしょ？
＞つまり雑魚敵ＡＢに書くべき処理ではない

YES

＞それらの関連、つまりＡｘＢ、ＡｘＣ、ＡｘＤ、ＢｘＣ、ＢｘＤ、ＣｘＤの関連は全部シーンクラスに書くべきじゃないのかな？

シーンでも神でも何でもいいけど、ゲーム世界の物理現象の調停者ｗが
介在し、結果を双方（作用する２体）に通知するというのは全くもって普通
珍しくない

148:名前は開発中のものです。
09/02/07 01:06:44 lLkuERdr
ていうか目をさませ
もしオブジェクトが２０種類いてそれぞれが関連をもつとしたら
少なくとも
a=オブジェクトの状態の数の総和
aC2（aの中から２つ選んだときの重複のない組み合わせだっけ？）
の数だけ処理を書かなきゃいけないことには
どう組んであろうが変わりはないんだぞ

>>147
なんのメリットがあってそんなわかりにくい書き方をするんだ
無駄だろ

149:名前は開発中のものです。
09/02/07 01:09:32 lLkuERdr
あ、aC2じゃ同じオブジェクト同士が抜けてるなｗ

150:名前は開発中のものです。
09/02/07 01:10:08 XPRCk6pD
>>145
重力をクラス化するのは個人の趣味だろうが、
使いまわせるかどうかは怪しいな。

細切れの小さなクラスが1000個ぐらいあって、
それぞれにそれぞれが関係しあって一つの生態系をなし、
結果としてゲームになっている・・・とか。
そういうのって想定外の仕様変更には弱いからなぁ。
まぁゲームの方向性にも寄るのだろうが。

151:名前は開発中のものです。
09/02/07 01:13:32 cn84NiHO
>>148
ゲームワールドをゲームエンジン内部で時間発展させてるからさ
衝突イベントでユーザー定義のコールバック関数が呼ばれるやつだ

152:名前は開発中のものです。
09/02/07 01:14:32 UFXAc++2
>147
普通に考えてそれか。

じゃ俺も普通に考えてみるかな。

雑魚敵Aが雑魚敵Bを攻撃して殺す場合、Aは攻撃判定用不可視オブジェクトXを作成する。
BにはXに対する応答のみ、つまりXに当たったら死ぬ、という処理を書く。

攻撃判定用不可視オブジェクトを必要に応じて複数作り、それぞれ攻撃する側はそれを作成し、
攻撃を受ける側はそれに対する応答処理を書く。

シーンクラスには、雑魚敵コンテナと同じレベルで攻撃判定用オブジェクトのコンテナを追加して、
そこで相互の判定をする。

153:名前は開発中のものです。
09/02/07 01:22:50 lLkuERdr
>>151-152
いや、だから全然わかってねぇな
なんかお前等変な組み方してるけど
関連の処理を仕様である分、全部書かなきゃいけないことは変わらないんだろ

なんでわざわざ間になんか挟むの？
なんか得になんの？金もらえんの？
素直にシーンオブジェクトに必要な数だけ処理かけよｗ
何をどうしたくてそんな複雑な仕組みにするんだｗ

オブジェクトＸなんていきなり見てお前のそれ誰が理解してくれるんだよ>152
どうせドキュメントもかかねぇしよまねぇだろ
っていうか手間増やしてるしｗ

154:名前は開発中のものです。
09/02/07 01:26:57 XPRCk6pD
>>152
不可視オブジェクトXの受け渡しは誰が行うんだ？

155:名前は開発中のものです。
09/02/07 01:30:03 lLkuERdr
ちなみに俺はオブジェクト指向原理主義者であると同時に
Ｃ＋＋をはじめとするオブジェクト指向言語が大嫌いなんだ
だってなんのメリットもねぇよこの言語ども・・・ｗ
だってよ・・・処理が集中・複雑化するのってシーンクラスみたいなところであって
別に個々にオブジェクト単位にできる部分は誰も苦労してねぇよマジで

ってみんなにはないしょだよｗ

ってところで>>147につけたレスは内容まちがってたな俺
すまんこ

156:名前は開発中のものです。
09/02/07 01:30:17 NuBn44S3
>153
> なんでわざわざ間になんか挟むの？

雑魚敵が増えた時の修正が少なくてすむ。
攻撃判定オブジェクトを間に挟むことで、複数種の雑魚敵が同属性の攻撃だしても、一つの攻撃判定オブジェクトとの
関連処理に還元できる。

157:名前は開発中のものです。
09/02/07 01:32:09 vE7+xmqT
>>150
使いまわすってのはコード的にって事ね

数が多い場合は面倒くさいけど一個一個やっていくしかないなぁ
上位概念のオブジェクトを作れるんであればいいけど
STGでいうなら弾 - 衝突 - 敵では無くて自機 - 弾判定 - 敵みたいに

158:名前は開発中のものです。
09/02/07 01:36:16 cn84NiHO
>>152
＞Aは攻撃判定用不可視オブジェクトXを作成する。

そう。AABBとか、高速飛翔するならカプセル、線分を空間上に射出するわけだ
Xがそのうちどっかのバカに命中（得点ゲット）したときの通知が欲しけりゃ
おまえらの大好きなオブジャーバーパティャーンでXにAを登録するやつだ
subjectはX。observerはA

＞BにはXに対する応答のみ、つまりXに当たったら死ぬ、という処理を書く。

まぁ、何かが自分に衝突したら呼ばれるコールバック関数（オブジェクト）を
登録してるわけだから、その中でユーザー独自の死ぬ処理を入れるわけだ

炎を吹いて墜落するなり、爆発四散するなり好きに振舞え

159:名前は開発中のものです。
09/02/07 01:37:24 lLkuERdr
>>156-157
>雑魚敵が増えた時の修正が少なくてすむ。
だからならないって
必ず仕様の分だけ処理かかなきゃならないんだよ
（それが汎用デフォルト処理に挿げ替えられるかどうかは別として）

>使いまわすってのはコード的にって事ね
コード的なんて気にすんなマジで
関連がいっぱいになると無駄に共通化した処理が必ず邪魔になる
３０回コピペして終わる程度の使いまわしなら３０回コピペする気でいろ
そのぐらいでちょうどいい

160:名前は開発中のものです。
09/02/07 01:38:36 XPRCk6pD
>>155
いや確かにそのとおりだと思う。
ただ、シーンクラスみたいなところに処理が集中するのは、
ゲームにオブジェクトとオブジェクトの関係が多いからだと思う。
一般アプリやツールは、リソースの管理がメインなので、
オブジェクト指向も役に立つのだろう。

161:名前は開発中のものです。
09/02/07 01:39:17 dNGvkNLd
ID:lLkuERdrはド素人だろ。こんなクルクルパーは相手にするだけ無駄。

162:名前は開発中のものです。
09/02/07 01:43:47 NuBn44S3
>159
> >雑魚敵が増えた時の修正が少なくてすむ。
> だからならないって
> 必ず仕様の分だけ処理かかなきゃならないんだよ

新規雑魚敵が今までの他の雑魚敵と同じ攻撃を出すのなら、それと同種の攻撃判定オブジェクトを
作成するだけで終了。

オマエのやりかただと、新規雑魚敵と既存雑魚敵全ての関係について処理を全て一つ一つ書くまで終わらない。

163:名前は開発中のものです。
09/02/07 01:45:32 lLkuERdr
>>160
一般のアプリだって同じだよ～ｗ
絶対にボタンとかツールバーの処理なんてウンコぐれーだろ
メイン画面の処理の強烈さといったらない
メインに集中してなくても絶対にどっかに偏るｗ（ツールウィンドウとか・・・）
部品は平均２００行程度しかないのにメインで１０万越えで放置されてるソースとか多いぞｗ

164:名前は開発中のものです。
09/02/07 01:48:10 hO/vsQBF
>>146
もれなくリストに登録しておいた。

>>121
もしBがAに殺された時、「うわああああ！」って悲鳴を上げるなら、
その悲鳴を上げる動作はBでやるべきだと思う。
AがBを殺した時、「やっほお！！」って喚声を上げるとしたら、それはAが行うべき内容だろう。

シーン（あるいは調停者）がやるべきことと言ったら、Bに対して「お前はAに殺された」ってメッセージを送ることと
Aに対して「お前はBを殺した」ってメッセージを送ること。

なんかややこしくなってきた。
皆えらいわ。

165:名前は開発中のものです。
09/02/07 01:48:40 XPRCk6pD
>>158
今、攻撃判定用「不可視」オブジェクトXって言ってるのだから、
弾をXにしてしまうと、弾が不可視になって困る。
弾が飛ぶってのなら、弾は普通のクラスにすべきだろう。
で、弾と雑魚敵Bの間で攻撃判定用不可視オブジェクトXをやり取りする・・・と。

なぜインターフェイスでやらないのか。攻撃判定用オブジェクトとか馬鹿げてるよ。

166:名前は開発中のものです。
09/02/07 01:58:57 lLkuERdr
>>162
>オマエのやりかただと、新規雑魚敵と既存雑魚敵全ての関係について処理を全て一つ一つ書くまで終わらない。
基本的にはそうだと思ってるし、そうでなければおかしいと思ってる
第一、お前が書かない処理はどうなるんだ？
プログラマならこれが答えられなければダメだろ？

それとお前がしてるのはあくまで仕様の話であって設計の話ではない
決まっていない仕様をむりやりプログラムの仕組みで解決しようとしている
必ずすべての組み合わせ分の関連を把握するべき
その上で共通な処理を共通であるように書いたらいい
（デフォルトを「何もおきない」としたら何も書かなければいい）

ちなみに俺はオブジェクトごと必ず関連をすべて書き出している
雑魚敵Ａｘ雑魚敵ＢがいたとしてＡのステータスが３種類、Ｂのステータスが２種類だとしたら

　　　Ｂ１　Ｂ２
Ａ１　Ｓ１　Ｓ２
Ａ２　Ｘ　　Ｘ
Ａ３　Ｘ　　Ｘ

Ｘ　はなにもおきない
Ｓ１は爆発
Ｓ２は押される

とかねｗ地道にｗ実際はもっとでかくて多いぞｗゾッとするぐらいな
例えばステータス１から２にうつるときのステータス１－２が問題になったりねｗ
書き出してるっていってもそこまで明確でもないんだよね、それでも見える分ぐらいはやるべきだと思ってる

167:名前は開発中のものです。
09/02/07 02:00:43 NuBn44S3
>165
不可視ってつけたのはちょっと余分だったかもな。別に可視でもいいんだ。STGの場合は、
弾という可視の攻撃判定オブジェクトを介して敵と自機が攻撃しあってるわけだ。

例えば格闘ゲームでパンチなりキックなりするばあい、攻撃判定の瞬間だけ拳や足先に
不可視の攻撃判定オブジェクトを作るというのはよくやること。この場合は、その攻撃判定
オブジェクトに『威力』なり『方向』なりの属性を与える。攻撃を受ける側は、その『威力』なり
『方向』なりを攻撃判定オブジェクトが当たった位置と一緒に見て、それぞれのダメージモーションを
再生したりダメージ処理に移行する。

波動拳（のような何か飛び道具）なら、可視の攻撃判定オブジェクトになるだけ。

スクリューパイルドライバー（のような何か近接巻き込み方攻撃）なら、巻き込み範囲を持つ不可視の
攻撃判定オブジェを作って、それにそれぞれへのコールバックを持たせる。当たったらコールバックを
よんで攻撃側・被攻撃側それぞれに対してモーション発動なりなんなりをする。

168:名前は開発中のものです。
09/02/07 02:00:43 cn84NiHO
>>165
＞不可視

あ、この部分は見落としていた

>>152は「一瞬で目標に到達するレーザーみたいな攻撃（視覚効果なし）」
を想定してたのかな

169:名前は開発中のものです。
09/02/07 02:02:12 NuBn44S3
>166
ガンバレw
努力の人はさすがにすごいと思うよw

学習できない無能はもっとすごいと思うけどねw

170:名前は開発中のものです。
09/02/07 02:03:15 XPRCk6pD
>>162
だから処理纏めたいときは普通はインターフェイスとか使うの。
オブジェクトのやり取りなんかしない。

class X{ public: virtual void hoge()=0; };
class A : public X{ public: void hoge(){} };
class B : public X{ public: void hoge(){} };

for(int i=0; i<tasks.size(); ++i){
X *x = dynamic_cast<X *>(tasks[i]);
if(!x){ continue; }
x->hoge();
}

とかすれば処理は纏められるだろ。
で、どう纏めるかは問題ではなく、これをどこに書くかが問題なんだ。

171:名前は開発中のものです。
09/02/07 02:04:03 cn84NiHO
>>167
格ゲのAABB当たり判定か。把握

172:名前は開発中のものです。
09/02/07 02:06:52 NuBn44S3
>170
で、どこに書くの？

間にオブジェクトを介在させる場合は、書くべき場所はひとつしかないけどね。

173:名前は開発中のものです。
09/02/07 02:15:06 cn84NiHO
>>166
＞　　　Ｂ１　Ｂ２
＞Ａ１　Ｓ１　Ｓ２
＞Ａ２　Ｘ　　Ｘ
＞Ａ３　Ｘ　　Ｘ
＞
＞Ｘ　はなにもおきない
＞Ｓ１は爆発
＞Ｓ２は押される

あれ。当たり判定表はアリだと思うが…

174:名前は開発中のものです。
09/02/07 02:26:27 XPRCk6pD
>>172
シーンクラスが良いのではないかということになってる。

>>167
オブジェクトを作るのは、インスタンスを複数にするためであって、
処理を纏めるためではないと思うぞ。

175:名前は開発中のものです。
09/02/07 03:15:44 cn84NiHO
>>174
シーンが肥え太る？ゲームエンジン（神）が肥え太ってんだよ

肥え太ったゲームエンジン（神）が作りしシーン
その中での現象に関して肥えた神にお願い・お祈り・お伺いするためのインターフェース
これをシーンが提供してる。それだけのことだ

神と交信するためのインターフェース（シャーマン、イタコ）は色々ある
物理エンジンにしかアクセスできないインターフェースとか
どのインターフェースを使えるかはゲームオブジェクト（アクター）によりけり

あとおまえやねうらおじゃない？睡魔に耐えてたらESPが冴えてきたぞ
外れてたらごめんね。もし当たってたら一言言わせろ
あんたさー知りもしない昔の話を捏造してペラペラしゃべってる暇あんなら
一次情報にアクセスしてきっちり裏取れよな
あれじゃネット発のタスクシステム都市伝説の怪文書がまたひとつ増えただけじゃん
松○とドングリだろ。悔しくないのか？足使えよ足
ネットとか２ちゃんで怪情報かき集めて本書くな

176:名前は開発中のものです。
09/02/07 03:17:17 cn84NiHO
アンカーミスだ。>>134な
ばいばい

177:名前は開発中のものです。
09/02/07 03:31:08 dNGvkNLd
>>175
横レスですまんが、やねうらおに関しては、
遠藤さんとも面識があるみたいだし、
URLﾘﾝｸ(d.hatena.ne.jp)
吉村さんとも知り合いみたいだし、
URLﾘﾝｸ(d.hatena.ne.jp)
岩谷さんが取り上げるぐらいだし、
URLﾘﾝｸ(d.hatena.ne.jp)
彼は2chなんか端っから相手にもしてないだろう。

自分の説が正しいと思うなら是非どこかのブログで
今回の記事に反論してみてくれ。俺はそれを楽しみにしている。

178:名前は開発中のものです。
09/02/07 03:42:55 lLkuERdr
今回の記事は魅力ないでしょうよｗ
前スレでタスク信者が詰まってたところ全部無視だものｗ

179:名前は開発中のものです。
09/02/07 03:46:47 dNGvkNLd
俺はweak_ptr使って実装するっての一つにしても為になったがな
まあ、あの記事から何も学べない奴は学習能力がアレなんだろうな

180:名前は開発中のものです。
09/02/07 03:56:42 zBw0rbcy
ID:lLkuERdrは10年以上プログラムやってて( >>123 )、
C++が使えない( >>125 )ってぐらいだから、まあ、本当にアレなんだろうけどな・・

181:名前は開発中のものです。
09/02/07 04:20:56 lLkuERdr
>>179-180
あんたが複数ＩＤを使えるのはもうわかってるよ
このスレのはじめのほうでもやってただろ？
でもいいの？
あんた自分より賢い人には絶対にたてつかないクズじゃん
俺なんかに噛み付くと反撃が痛いんじゃない？ｗ

182:名前は開発中のものです。
09/02/07 04:26:54 XPRCk6pD
weak_ptr とかはもうすでにみんなやってるでしょ。
そこはそんなに。本質とは違うというか。
別にタスクが死ぬごとに各タスクのOnDeleteTask(Task *)がコールされるとか言う実装でもかまわないわけで。
全般にわたって高速化のことしか書かれていないが、そんなの正直どうでも良い。
ってのが感想。

183:名前は開発中のものです。
09/02/07 04:52:05 dNGvkNLd
>>182
> 別にタスクが死ぬごとに各タスクのOnDeleteTask(Task *)がコールされるとか言う実装でもかまわないわけで。

それは、何かweak_ptrを勘違いしてそうだな・・。

OnDeleteTaskのときに、被参照ポインタをどうやって無効にするんだ？

184:名前は開発中のものです。
09/02/07 04:55:04 dNGvkNLd
>>181
> あんた自分より賢い人には絶対にたてつかないクズじゃん

それは、俺を他の誰かと勘違いしてねーか

俺はC++わからないとか、デザパタわからないとか、
そんなド素人と話しても得ることがないから、そういう奴とは話さないだけだよ

185:名前は開発中のものです。
09/02/07 05:10:37 XPRCk6pD
>>183

class my_task : public task
{

task *m_ptask1;

public:

virtual void OnDeleteTask(task *ptask)
{
if(m_ptask1==ptask){ m_ptask1=NULL; }
}

};

186:名前は開発中のものです。
09/02/07 05:15:04 dNGvkNLd
>>185
ああ、言わんとしていることはわかったし、あんたはまともなプログラマに属すると言えるとは思うが、
そのコードだとオブジェクトの削除はO(N^2)になるよな。

俺の現場ではそんなコードは全然現実的じゃないんだが。
あんたは本当に数万オブジェクトの出てくる規模のゲーム書いたことあるの？

187:名前は開発中のものです。
09/02/07 05:18:34 XPRCk6pD
ただ、これらの話題で絶対出てくるのが、
オブジェクトのdeleteが、他のオブジェクトの何かの処理の引き金になるのは変だって話。

188:名前は開発中のものです。
09/02/07 05:20:49 dNGvkNLd
もちろん185の実装は別に間違っちゃいないので、俺の183は発言を撤回する。
185があまり良くない実装だと理解した上で確信犯的にやっているんだろうから。

189:名前は開発中のものです。
09/02/07 05:24:50 dNGvkNLd
>>187
> オブジェクトのdeleteが、他のオブジェクトの何かの処理の引き金になるのは変だって話。

(そういう議論が発生するのはわかるが)それは、変じゃないだろう。
被参照ポインタの無効化というのは、そもそもそういうものだから。

190:名前は開発中のものです。
09/02/07 05:43:13 XPRCk6pD
>>186
まぁ10000も出すとなぁ・・・
ともかく、weak_ptrぐらい自前で書けるし、他の方法もあると言いたかった。
つーか、10000もオブジェクト出すって、何のゲームよ。

191:名前は開発中のものです。
09/02/07 05:54:06 dNGvkNLd
>>190
> ともかく、weak_ptrぐらい自前で書けるし、他の方法もあると言いたかった。

weak_ptrと同性能のものを自前で書くだけでも結構大変だと思うがな。
少なくとも現場のプログラマがやるのは時間の無駄で車輪の再発明以外の何物でもないと思うのだが。

> つーか、10000もオブジェクト出すって、何のゲームよ。

いまどきの3Dのゲームでは、足や手のパーツごとに接触判定を持っていて、それぞれのパーツが
独立していて、それぞれがC++のオブジェクトになってたりするのだが。

192:名前は開発中のものです。
09/02/07 06:30:12 XPRCk6pD
いや、ま、どういうか。
再発明だろうがなんだろうが、あまりどうでもよくて、
要するに、そういうところで困ってる人はいないだろうと。

余談だが、
そもそも、不正なポインタをオブジェクトが抱え込んでしまっているような状況事態がバグに近いわけで。
昔weak_ptrのようなものを使ったコードも書いたことがあるが、釈然としなかった。
だって、lock出来るときと出来ないときでコードが分岐するなんて、変だ。
そういう仕組みに頼ってると、オブジェクトの所有権がどこにあるのかわからないコードになりがち。
オブジェクトは作ったやつが削除すべきという結論に達したが。。

193:名前は開発中のものです。
09/02/07 06:46:43 dNGvkNLd
>>192
> そもそも、不正なポインタをオブジェクトが抱え込んでしまっているような状況事態がバグに近いわけで。

そんなことはない。

シューティングで、子分より親分が先に倒されることは普通にありえるだろ？
子分は親分のポインタを保持していてはいけないのか？違うだろ？

そういうとき、どういうコードを書くつもりでいるんだ？コードで示してくれ。

194:名前は開発中のものです。
09/02/07 06:49:26 dNGvkNLd
>>192
> オブジェクトは作ったやつが削除すべきという結論に達したが。。

これも全くのでたらめ。

シューティングでボスがザコをどんどん生成するときのことを考えてみてくれ。
ボスはザコより先に逝っちまうことがあるだろ。

ザコから参照されているからボスはいつまでもオブジェクトを解放しないのか？違うだろ。

オブジェクトの所有者は、そのオブジェクトを生成した奴(ボス)にあってはいけないんだ。
もしそう設計しているならそれは設計上の誤り。

195:名前は開発中のものです。
09/02/07 07:11:16 XPRCk6pD
>>193
>シューティングで、子分より親分が先に倒されることは普通にありえるだろ？
>子分は親分のポインタを保持していてはいけないのか？違うだろ？

>そういうとき、どういうコードを書くつもりでいるんだ？コードで示してくれ。

親分も子分も、シーンクラスが管理すればよい。

>シューティングでボスがザコをどんどん生成するときのことを考えてみてくれ。
>ボスはザコより先に逝っちまうことがあるだろ。

なぜボスがザコを生成する必要がある？
シーンクラスがザコを生成、削除すればよい。

Cのmallocにはweak_ptrのような仕組みは用意されていないが、世のプログラムはちゃんと動いている。
windowsのウィンドウハンドルにもweak_ptrのような仕組みは用意されていないが、ちゃんと動いている。
なのにゲームではweak_ptrに頼らざる得ない状況になるというのなら、それは設計が悪いからだろう。
だけど止めはしない。weak_ptrをつかってゲームを書いてみるといい。きっと後悔するから。

196:名前は開発中のものです。
09/02/07 07:23:17 dNGvkNLd
>>195
> 親分も子分も、シーンクラスが管理すればよい。

うわ。それはひどい。なんか、またド素人と話している予感。

子分を生成したくなるタイミングは親分が親分のロジックにおいて決定するのだから、
あんたの作りでは、親分がシーンクラスに対して子分の生成を依頼するコードが必要になる。
どんな依頼コードを書くの？それ書いて見せてくれないか。

> windowsのウィンドウハンドルにもweak_ptrのような仕組みは用意されていないが、ちゃんと動いている。

何を勘違いしているのか知らないが、WindowsのHANDLEもweak_ptrも目的は全く同じなんだが。

197:名前は開発中のものです。
09/02/07 07:27:41 Smy/5DJP
シューティングでボスとザコが居て、ボスとザコが何故か紐で繋がってたとする。
紐の管理はボスとザコのどちらですべきか？

答えはどちらでもなく、
ボスとザコと紐を管理するボス戦クラスを作って、全部纏めてそっちで管理すべき。

198:名前は開発中のものです。
09/02/07 07:28:38 dNGvkNLd
>>195
> ゲームではweak_ptrに頼らざる得ない状況になるというのなら、それは設計が悪いからだろう。

「ゲームではweak_ptrに頼らざる得ない」なんて俺は言ってないからな。

weak_ptrを使えば簡単に書けるものを、馬鹿が車輪の再発明したり、weak_ptrを知らないがために
複雑な設計になっていたりすると言ってるだけなんだが。

199:名前は開発中のものです。
09/02/07 07:37:27 dNGvkNLd
>>197
> ボスとザコと紐を管理するボス戦クラスを作って、全部纏めてそっちで管理すべき。

まあ、それは否定しないが、「そっちで管理すべき」の「管理」の方法は？

200:ID:XPRCk6pD
09/02/07 07:40:43 Smy/5DJP
ID変わってしまったけど、俺がID:XPRCk6pDな。

>>子分を生成したくなるタイミングは親分が親分のロジックにおいて決定するのだから、
>>あんたの作りでは、親分がシーンクラスに対して子分の生成を依頼するコードが必要になる。
>>どんな依頼コードを書くの？それ書いて見せてくれないか。

依頼などしない。直接シーンクラスに書く。直接がいやなら、子分と親分を管理する大親分クラスを作って
そっちで管理する。

>>何を勘違いしているのか知らないが、WindowsのHANDLEもweak_ptrも目的は全く同じなんだが。
ハンドルは同じ値が再利用される可能性もあるわけで。

201:ID:XPRCk6pD
09/02/07 07:50:35 Smy/5DJP
>>199
>まあ、それは否定しないが、「そっちで管理すべき」の「管理」の方法は？
好きにすれば？
複数のクラス同士が双方向にコミュニケートするような状況さえ回避できれば、
あとは考えることなんてないね。

202:名前は開発中のものです。
09/02/07 07:55:22 dNGvkNLd
>>200
> 依頼などしない。直接シーンクラスに書く。直接がいやなら、子分と親分を管理する大> 親分クラスを作ってそっちで管理する。

まあ、それでも組めなくはないのであんたが実際にゲームを書けないとは
言うつもりはないが、しかし、あんたは、大きなゲームを作ったことがなさそうだな。

オブジェクトが無数に出てきて広大なフィールドを歩けるタイプの
汎用的な3Dエンジンなんかを作れば俺が言ってる意味がわかると思うんだが。

まあいいや。お互い意見が対立しているわけでもなさそうなので、俺はもう寝る。

203:名前は開発中のものです。
09/02/07 08:17:52 lLkuERdr
>>200
俺もシーンクラスに書く
その設計でいいと思うぜ

ID:dNGvkNLdは普通に頭悪いだろｗ
質問攻めしてるけど明らかに予想外の答えにうろたえてるだろｗ

204:名前は開発中のものです。
09/02/07 08:28:02 dNGvkNLd
>>203
C++すら使いこなせないド素人は黙ってな

205:ID:XPRCk6pD
09/02/07 08:57:06 Smy/5DJP
>>202
そういうコテコテしたプログラムも書いたことがあるが、今では間違いだったと考えている。
少し前までは私も「オブジェクトは自立しているべきであり、周りの状況を判断し、自分で行動すべきだ」、
と考えていた。私もまだ若かったし、C++がそういう設計思想であることも手伝って、そういう勘違いをした。
作ってみたらうまくいかず、考えてみたら、オブジェクト同士の関係を見落としていることに気がついた。
ゲームはオブジェクト同士が関係しあって初めてゲームになる。
そこを重点的に記述できないことには楽しいゲームを作ることは難しい。
昨今の大作ゲームがどことなく味気ないのもそのあたりが原因では？

206:名前は開発中のものです。
09/02/07 09:17:54 dNGvkNLd
>>205
> 昨今の大作ゲームがどことなく味気ないのもそのあたりが原因では？

それは、全然的外れだろう。

本当に現場のことは何も知らないんだな。

せいぜい同人ゲーでも作ってなよ。

207:名前は開発中のものです。
09/02/07 09:21:58 lLkuERdr
>>206
苦しくなると話の趣旨と違うところだけつまんで
人格批判からレスの全部否定に入るっておきまりのパターンなのなｗ

208:名前は開発中のものです。
09/02/07 09:29:38 dNGvkNLd
>>207
C++すら使いこなせないド素人はこなくていいよ

209:名前は開発中のものです。
09/02/07 10:06:26 iAQtrtU5
c++使わなければどうでもいい話題ばっかだな

210:名前は開発中のものです。
09/02/07 10:18:48 hO/vsQBF
>>192
deleteされたポインタを直接参照しているオブジェクト全てにその旨通知するように設計したいと思った。

>>193
子分::親分からの指令(親分へのポインタ) みたいなメソッド作って、
子分は親分からの指令があった時だけ、親分へのポインタを参照しながら協調動作すればいいんじゃね。
子分が親分のポインタを持つ必要は無いよ。

>>197
ボスと雑魚は紐なんか無視して、それぞれ独立に動いていい。
紐は自分のグラフィックを表示しつつ、ボスと雑魚に対して「これいじょう伸びないよ」的な力(or メッセージ)を与える。
それ以外の点では、紐は普通の登場キャラと同じような扱いで良いと思う
シーンクラスに何か特別なことを書く必要なんて無いよ。

211:名前は開発中のものです。
09/02/07 10:51:31 lLkuERdr
>>210
どっちにしてもシーンみたいなクラスあったほうがいいじゃん

212:名前は開発中のものです。
09/02/07 11:11:23 lLkuERdr
>子分は親分からの指令があった時だけ、親分へのポインタを参照しながら
子分のクラスなんだから子分の処理だけで完結したいと思わないんか？
カプセル化っていうの？

213:名前は開発中のものです。
09/02/07 11:13:45 hO/vsQBF
>>211
うん、あった方が良いと思う。
実際にシーンクラスが何を担当するのかはここに居る人それぞれが全く違うイメージを持ってそうだけど。

214:名前は開発中のものです。
09/02/07 11:47:33 hO/vsQBF
>>212
子分は親分と協調し、親分は子分と協調するのだから、
お互いに通信しあう仕組みは必要で、完全に分離するのは不可能だと思う。

ふと思えば、俺の方法だと、子分が死んだことを親分はどうやって感知するんだって思ったw

215:名前は開発中のものです。
09/02/07 15:40:54 NuBn44S3
>174
おまえはタスク=ゲームオブジェクト派か。
プログラミングなんて、正しく動くなら何やったっていいんだよ。くだらない価値にこだわってると
伸びないぞ。

216:名前は開発中のものです。
09/02/07 16:25:49 21jTa7Aw
シーンクラスって作る価値があるのかね
シーンってメニューやスコアやRGPならフィールドや戦闘なんかのことだろ
一つのゲームに必要なシーンなんて十もないんじゃないか
そしてそれぞれのシーンに共通点なんてほとんどない
共通しているのはデータ取得メソッドみたいなのだけ
各シーンは遷移するけどstateパターンを適用しても
メリットはほとんどない
そんなどうでもいい部分を考えている暇があるなら
うんこでもして寝てしまえ
このうんこ野郎ども

217:名前は開発中のものです。
09/02/07 18:36:36 vE7+xmqT
>>216
2個以上なら作る価値はあると思うがね

218:名前は開発中のものです。
09/02/07 19:39:16 21jTa7Aw
なんでもできちゃうクラスみたいなのを作るからバカになる
つけちゃえばぱわーあっぷみたいなガキの発想じゃあるまいし
なんでも作ればいいってもんじゃない
二つしかないクラスに親クラス作ってクラスが三つになって
すごいんだぞーとかバカじゃねーの
ばーかばーかしんじゃえ
そんなとこに柔軟性持たせる暇があったらうんこでもしてろ
うんこうんこ

219:名前は開発中のものです。
09/02/07 19:48:57 B+kDbAoq
なんでもできちゃうクラスみたいなのを作るからバカになる
つけちゃえばぱわーあっぷみたいなガキの発想じゃあるまいし
なんでも作ればいいってもんじゃない
三つしかないクラスを統合してクラスが二つになって
すごいんだぞーとかバカじゃねーの
ばーかばーかしんじゃえ
そんなとこに柔軟性持たせる暇があったらうんこでもしてろ
うんこうんこ

220:名前は開発中のものです。
09/02/07 20:03:53 lLkuERdr
>>214
だからシーンに書けよｗ

221:名前は開発中のものです。
09/02/07 20:08:26 VeizsAKm
シーン。。。

222:名前は開発中のものです。
09/02/07 20:10:02 qvO9PNvj
>>219
でもよ、
「あれもしなきゃ、これもしなきゃ」って状況で、修正作業が発生して、
２回だけでも同じ修正作業をやるのって、憤慨「ウガアーゥアーッ！！」状態にならね？
C++使ってるなら、template（汎用クラス）の親クラスは使わな損々。

223:名前は開発中のものです。
09/02/07 20:22:54 21jTa7Aw
シーンをまたがって修正しなければならない項目なんてほとんどないから
考えるだけ無駄
メニューと戦闘のシーンでの共通項目なんてあるのかよ
メニューと戦闘で使う共通キャラのモーションがおかしいから修正だぜ
サブクラスにしておいてよかった俺天才超天才
なんて場面は百年に一度しかねーよ
どうしても作りたければ似たようなシーンで共通の親クラス持てばいい
何度も言う、そんなくだらないコードを書く暇があるなら
うんこしているほうがまし
うんこをしていると新しいアイデアが生まれると過去の偉人も言ってた

224:名前は開発中のものです。
09/02/07 20:43:13 hO/vsQBF
>>223
>共通項目
それはつまり、タスクシステムのことだと思うよ！

225:名前は開発中のものです。
09/02/07 20:47:22 B+kDbAoq
>>222
？
親分クラスと子分クラス間の通信をシーンクラスが受け持つなら
シーンクラス１箇所で修正済むんじゃない？

>>223
シーンクラス否定したり肯定したり、立場がワカンネ
もしかして否定したいのって「シーンクラス」じゃなくて
「抽象化されたシーンを統一的に管理するクラス」？

226:名前は開発中のものです。
09/02/07 20:47:40 21jTa7Aw
すげぇぜタスコシステム
共通項目がない、なんの関係もなかった複数のオブジェクトを
無理やり関連付けやがった
やべぇな、俺には真似できねぇぜ

227:名前は開発中のものです。
09/02/07 20:48:43 qvO9PNvj
「シーン＝メニューと戦闘」の入出力の具体が不明だが、
ウンウンきばっている段階（＝設計の段階）で、
なんであれ抽象化できる部分はなるべく抽象化しておくんじゃねえの？

期限が決まっている状況であれば、なおのこと、それくらいの安全策は取るよな。

228:名前は開発中のものです。
09/02/07 21:01:07 21jTa7Aw
>>227
一気に食おうとするな分けろ
夏休みの宿題なんてものは毎日少しずつやるもんだ
共通点なんて無理に抽出してもそれはオナニーだ
シーンごとに分けろ、目標を分けろ
メニューだけ作って完成させろ
戦闘だけ作って完成させろ
最後に適当にくっつければいいだけだ
全部同時に作って完成させる能力もないくせに
一度に全てをこなそうとするな
俺らは凡人だから、凡人にふさわしいやり方がある

規模の増大が複雑さのインフレを招くのは常識
それを回避するためにそれぞれの規模を抑えて
できるだけ分離して開発するんじゃねーか
完成した複数のシステムをできるだけ触らないようにしてくっつければ
それでいいんだよ
俺らは天才じゃねーから
スーパー天才のやねうらお連中の言うことなんて聞かなくてもいいんだよ
俺らは凡人だ、凡人には凡人にふさわしいやり方がある

そして余った時間を使って
スーパーウンコタイムを楽しもうじゃないか
存分に

229:名前は開発中のものです。
09/02/07 21:01:45 B+kDbAoq
>>227
そして実装も終盤に差し掛かった段階で唐突に仕様変更が入り
抽象化して見えなくしておいた情報を使うために苦しむんですね
わかります

230:名前は開発中のものです。
09/02/07 21:05:45 qvO9PNvj
>>229
仕様変更に柔軟に対応できるような抽象化を見極めるのもワザのうち。

231:名前は開発中のものです。
09/02/07 21:09:34 lLkuERdr
そんなのするから無駄に時間がかかるんだよ
って俺の１０年以上の経験が言ってる

232:名前は開発中のものです。
09/02/07 21:13:12 B+kDbAoq
>>229
そう、ワザ要るよね
初めてのゲームジャンルとかだとまだワザが足りないから完全には見極め切れない
全く抽象化しないか本当にかるーくしとく位でちょうどいい

次ページ