シューティングゲーム製作技術総合　9機目

**名前は開発中のものです。** · 2005/12/11(日) 02:45:19

ゲームプログラマなら誰もが通る、もしくは、通った道。青春の香り？
それは「シューティングゲーム製作」・・・。

このスレでは、そんなシューティングゲームの製作技術や技術の検証、成功談
失敗談笑い話、難易度の設定方法論、多弾の是非などについて語り合いましょう。
もちろんBulletMLなどで弾幕を作成してみたり、自分の作ったシューティングを
晒してみたり、プロジェクトをはじめてみるなどもOK！

ただし、シューティングの未来とか既存のゲームの話題などは、関連する他の
スレでやってくれ。

過去スレ，関連スレは >>2で。

**名前は開発中のものです。** · 2006/01/15(日) 01:15:19

>>185 俺も　B＞C＞A＞D

**名前は開発中のものです。** · 2006/01/15(日) 01:20:43

>207
Shadeだと楽になるどころか難しくなる気がするが、楽したいならDOGA使えばいいんじゃないか
どう見てもDOGAです
って絵になるのが嫌なら使えないけど

**名前は開発中のものです。** · 2006/01/15(日) 02:00:23

>>207
オペレーションラグナロクを思い出した(笑)

**名前は開発中のものです。** · 2006/01/15(日) 02:10:01

ﾑｰﾝｦｰｶｰ

**名前は開発中のものです。** · 2006/01/15(日) 09:48:31

DoGaでキャラを作ったSTGってたくさんあるから
自分の作品が平凡なイメージになってしまうと危惧する人はいるかもしれんね。

**207** · 2006/01/15(日) 22:27:37

DoGaは楽だが架空兵器使った平凡STG作ったって面白くないや。
やはり同人らしく漫画やアニメ等の元ネタあるSTG作りたい。
エリア88っぽいの作ろうと思ったが、まだ無理だったので
もう少しレベル下げて中華大仙あたりが作れるようになろうっと。
>209
テストとして六角でモデルにポーズ取らせて取り込んだだけぽ。
元々8頭身モナーだったりする。

**名前は開発中のものです。** · 2006/01/16(月) 00:47:41

>>ttp://gamdev.org/w/?%5B%5BSTG%A4%F2%BA%C7%BD%E9%A4%AB%A4%E9%A4%DF%A4%F3%A4%CA%A4%C7%BA%EE%A4%EB%A5%B9%A5%EC%5D%5D#content_1_25

ここのサンプルコード見てみたんですが、シューティングってｔimeGetTime()と
thread必須じゃないんですね。
弾の管理とかスレッド必須かと思ってたから、道が開けた。（DirectXも必須じゃなry
目標は東鳩2シュー。

**名前は開発中のものです。** · 2006/01/16(月) 00:49:57

シューティングにかぎらず必須ではないさ

**名前は開発中のものです。** · 2006/01/16(月) 01:13:59

>>217

速度的に厳しいのかと思ってました。

**名前は開発中のものです。** · 2006/01/16(月) 01:34:19

つかなんでスレッド必須？　どこで使うんだ？

**名前は開発中のものです。** · 2006/01/16(月) 03:41:08

ストリーミングにBGMを再生する時に欲しいな。
まあ適当なライブラリを使えば隠蔽してくれるが。

伝統的なタスクシステムによる並列動作が基本としてあるから、
ゲーム部分を作る時には要らんわな。
そこそこ精度のいいタイマーは、あるにこしたことはないが。

**名前は開発中のものです。** · 2006/01/16(月) 07:18:45

>>219
別個に連続した動作をさせる場合に、初心者だと必要だと思うものだよ
これはこれでわりと便利だから、使い方を覚えるにこした事はないしな
まあ、使い方を間違えると、何が起きるか予想もつかんケド

**名前は開発中のものです。** · 2006/01/16(月) 08:07:45

まさかスレッド300個くらい作って弾1個にスレッドに割り振るとか（ｒｙ

ごめんきっと誰もが一度は考えるお馬鹿ネタでした。
真面目な話だとマイクロスレッド使ってやると面白そうだね

**名前は開発中のものです。** · 2006/01/16(月) 08:25:10

>>221
初心者はスレッドなんて知らねーよアホ

**名前は開発中のものです。** · 2006/01/16(月) 08:37:51

>>223
Windowsプログラムを勉強する時に、
一度ぐらいはＯＳにどんな機能があるのか調べるだろ？

俺、何か間違った事を言ってるか？

**名前は開発中のものです。** · 2006/01/16(月) 08:43:05

>>222
俺、今やってる・・・orz

そのために自前スクリプトを改良してるんだけどな・・・
スクリプト作りは大変だよ・・・

**名前は開発中のものです。** · 2006/01/16(月) 09:23:10

>>224
おまえが日本語を知らないチョンということはわかったから「初心者」の意味を調べてこい

**名前は開発中のものです。** · 2006/01/16(月) 11:11:38

スレ違い

**名前は開発中のものです。** · 2006/01/16(月) 12:09:59

>>226
君も君で、耳年増という単語をググってこい

**名前は開発中のものです。** · 2006/01/16(月) 16:32:15

ここでDXライブラリが良いと聞いて今日導入してみたが
ほんと分かりやすいなこれ
解説ページも基礎の基礎から書いてるから
初心者の俺でもキャラ移動させることができた

**名前は開発中のものです。** · 2006/01/16(月) 19:55:09

>>226
初心者と書かずに素人と書くべきだったか・・・

**名前は開発中のものです。** · 2006/01/16(月) 20:22:21

でも実際、いろんな物体を同時に動かすのにスレッドは便利じゃない？

**名前は開発中のものです。** · 2006/01/16(月) 20:49:04

まあな。あと、今のＣＰＵなら、うまく使えば速度ＵＰにも使えるしな。

ただ逆に、同時処理ゆえに扱いづらい部分もある。
同時に同じ場所に書き込むと、何が起きるか分からないし、
イベントとかミューテックス等の同期オブジェクトの使い方を間違えれば、
即座にデッドロックだ。

**216** · 2006/01/16(月) 22:10:43

>>223

スマソ、スレッド知ってるけど初心者です　orz
普段はインフラの仕事してるから、開発は初心者。
でもシューティングはすっげ好き。
初代R-TYPEからのシュータ（ｒｙ　

みなさん、批判ともどもアドバイスサンクス！

**名前は開発中のものです。** · 2006/01/16(月) 22:11:18

今後はパフォーマンスを伸ばすのに最も効果的な方法でもあるしな

シングルスレッドでアセンブラレベルでチューニングするよりマルチスレッドが容易に扱える
Javaや.NET等でさくっとつくったほうがパフォーマンスはまず上だしな

並列具合とか設計を考える必要はあるが

**名前は開発中のものです。** · 2006/01/16(月) 22:25:14

うそだ

**名前は開発中のものです。** · 2006/01/16(月) 22:31:03

シューティングにパフォーマンスってｗ

**名前は開発中のものです。** · 2006/01/16(月) 22:35:11

弾１個に１スレッドって効率悪すぎ。

**名前は開発中のものです。** · 2006/01/16(月) 22:43:29

スレッド切り替えってそんなにコスト低いか？
そもそも、1フレーム＝16.6msで100や200の切り替えとかOSが対応してると思えないんだけど。

普通に擬似タスクや、配列で管理した方が普通にパフォーマンス出るよな？

もしかしてネタにマジレスしちゃってる？

**名前は開発中のものです。** · 2006/01/16(月) 22:48:02

ただでさえメッセージのやりとりが多いゲームオブジェクトを
正しく排他処理してさらにパフォーマンス上げろとか地獄に聞こえるんですが

**名前は開発中のものです。** · 2006/01/16(月) 22:49:24

表示と計算くらいは別スレッドで走らせてもいいんでね？
流石に全部一つ一つなんてｷﾁｶﾞｲぢみてる

**名前は開発中のものです。** · 2006/01/16(月) 22:51:24

スレッドで何が面倒かって、同期とることじゃね？
デッドロックでもう死に掛けたことあるよ。
あとは、リプレイするときに、同じ状況再現できねえとか、問題山積。

プリエンティブでないマルチタスクは、ゲームにはないと逆に面倒だよな。
ようは、擬似タスクとか、マイクロスレッドとか。

**名前は開発中のものです。** · 2006/01/16(月) 23:02:58

>>234はデュアルコアが今後増えていったときの話をしてるんだべ
やるとしたらせいぜい>>240くらいか
あとは裏でVSTiを立ち上げて無駄にリアルタイムにサウンド合成するとか・・・

**名前は開発中のものです。** · 2006/01/16(月) 23:20:03

>>242
補足さんきゅ
今後マルチコアが当たり前になるのでということ

>>241
マルチスレッドがリプレイに影響出るとかってのは設計の問題だろう

>>238
さすがにそんな馬鹿はいないはずだが
スレッドプーリングで意外と何とかなるのかも

その辺を使うとなると中間言語系レベルのの高級言語がほぼ必須になってくるわけだが
まぁGCとマルチコアの関係もわりといいしちょうどいいのかも

>>236
2DSTG以外にもあるだろ、パフォーマンス要求するSTGは
ま、有り余るマシンパワーで雷電2以上のエフェクトをだしてみたいけど

**名前は開発中のものです。** · 2006/01/16(月) 23:56:25

>>243
スレッドをプールしといても、スレッド生成のコストがなくなるだけで
切り替えのコストはなくならない。

>マルチスレッドがリプレイに影響出るとかってのは設計の問題だろう
リプレイに影響が出ないように設計しちまったら、マルチスレッドの利点が殺ぎ落とされるだろ。

>その辺を使うとなると中間言語系レベルのの高級言語がほぼ必須になってくるわけだが
おいおいアホぅか。スレッドプール如きで「必須」て。
第一スレッド系はお前の挙げたJavaでもC#でもC++でも手間は対して変わらん。
織田信長とか挙げたら説得力あったのにｗ

>2DSTG以外にもあるだろ、パフォーマンス要求するSTGは
>ま、有り余るマシンパワーで雷電2以上のエフェクトをだしてみたいけど
必要なのはGPUのパワーだろ。マルチスレッドにすると描画も速くなると主張するか？

**名前は開発中のものです。** · 2006/01/17(火) 00:32:06

>>244
スレッドプールはスレッドの数を調整できてアプリ側からは気にしないのが売りなので
並列動作させるオブジェクトが数百あろうがコアが2つだからスレッドは２つ、
4コアになったからスレッド4つというふうに使うのが普通では?

**名前は開発中のものです。** · 2006/01/17(火) 00:36:14

マルチスレッドは最後の手段だと思っておけと。

>>245

**名前は開発中のものです。** · 2006/01/17(火) 00:37:55

書き込んじまった。
>>245
まあそうなんだけど、OSが1000個くらいスレッド走らせてるからな。

４コアくらいに分割しなきゃパフォーマンスに問題があるわけじゃないなら
やらないほうが軽くていいと思うけど。

**名前は開発中のものです。** · 2006/01/17(火) 00:38:06

最後の手段というか、技術には向き、不向きがあって
STGにマルチスレッドは不向き、それだけ。

**名前は開発中のものです。** · 2006/01/17(火) 00:45:32

>>245
>並列動作させるオブジェクトが数百あろうがコアが2つだからスレッドは２つ、
>4コアになったからスレッド4つというふうに使うのが普通では?
何言ってんだ。お前は。

スレッドプールの説明はメンドクサイので、ググって見つけた記事嫁
http://www.atmarkit.co.jp/fdotnet/mthread/mthread02/mthread02_01.html

スレッドが２個しかなかったら、同時に動けるオブジェクトが2個ずつじゃねーかｗ
一個撃墜されたら、キューから出てきてまた一つ産まれるのかｗ

**名前は開発中のものです。** · 2006/01/17(火) 01:05:22

>>249
フィックスドプールはそうだよ。
いわゆる同時に動かす数をきめといてあとはブロッキングされる。

キャッシュドプールはスレッドを基本的には作るんだけど、
すでに作られていてプールされていればそれを使う、
一定時間使わなければスレッド自体破棄ってやつだ。

通常はフィックスドプールがパフォーマンスの把握が出来つてつかいやすい。

先ほどからあおってる、あなたにはたぶんマルチスレッドのプログラムは
無理だから今までどおりシングルスレッドでやってください。
上でもいってるけど必須科目ではないんだし。

**名前は開発中のものです。** · 2006/01/17(火) 01:13:15

>>250
はぁｗ　そうですかｗ

で、

>並列動作させるオブジェクトが数百あろうがコアが2つだからスレッドは２つ、
>4コアになったからスレッド4つというふうに使うのが普通では?

↑この自分で書いた恥ずかしい文章はどうするのｗｗ？

**名前は開発中のものです。** · 2006/01/17(火) 01:25:34

みんな詳しいなｗ
俺ついてけねえｗｗｗ

**名前は開発中のものです。** · 2006/01/17(火) 01:46:19

俺もだ。
暇なので252と酒でも飲む。

**名前は開発中のものです。** · 2006/01/17(火) 07:58:56

リフレッシュレート非依存にしたい場合はスレッドは有効でしょう
計算部分をスレッドにして16ミリ秒とか33ミリ秒ごとにコールするようにして
描画部分はメインループで処理すればｆｐｓとリフレッシュレートが
一致しない事による画面のカクツキを抑えることが出来る
同期の問題で実装が難しいけどな

**名前は開発中のものです。** · 2006/01/17(火) 09:51:04

スレッドプールにすることでスレッド切り替えの回数は減るから
切り替えコストが少なくなるのは当然じゃねーのか

**名前は開発中のものです。** · 2006/01/17(火) 10:47:29

自分はBGMのストリーミングくらいしか使ってないよ。
スレッド使ってややっこしくしてバグ生む要因を増やすなら、素直にシングルで
作って、その労力や時間をゲームの方に割り当てたいよ。
PCみたいな動作環境がバラバラで、ゲームのコア部分にスレッド使ってシビアな
同期取るとか、考えただけでも頭こんがらがりそうだ。

243はやたらマルチスレッドが重要だ！って言ってる気がするが、マルチスレッドが
必要になるくらいパフォーマンス要求される2DSTGってどんなんだよ。
出てくるオブジェクト全部が物理演算で動いてて、しかも常時1000個以上がグリグリ動いて
とかだったら、それは必要かもしれんが。

**名前は開発中のものです。** · 2006/01/17(火) 13:26:05

> ゲームのコア部分にスレッド使ってシビアな
> 同期取るとか、考えただけでも頭こんがらがりそうだ。
ここでのシビアな同期って？　例えば何？

> マルチスレッドが必要になるくらいパフォーマンス要求される2DSTGってどんなんだよ。
> 出てくるオブジェクト全部が物理演算で動いてて、しかも常時1000個以上がグリグリ動いて
> とかだったら、それは必要かもしれんが。
それはマルチスレッドで解決するの？　たとえば60FPSを目標にしたばあい、
次のフレームまでのわずかな時間に演算を終らせるかどうかが問題であり、
その話題にマルチスレッドうんぬんがどうからんでくるの？
複数のプロセッサの場合スレッドがそれを有効に使うんだっけ？

**名前は開発中のものです。** · 2006/01/17(火) 16:04:39

ム板のmegademoスレでも今ちょうど似たような話題出てるから見てくるよろし
http://pc8.2ch.net/test/read.cgi/tech/1115311515/643-

**名前は開発中のものです。** · 2006/01/17(火) 21:25:41

>次のフレームまでのわずかな時間に演算を終らせるかどうかが問題であり
マルチコアを有効に使うには、まずこの考え自体を破棄しているのが、最近の流れだな

わずかな時間で処理する物と、フレームを飛び越えて長い時間をかけて処理するものと、など

**名前は開発中のものです。** · 2006/01/17(火) 22:03:47

そもそも、元々はオブジェクト１つに１スレッド使うとかいう発言が発端なんだから
おまいらが今話していることはどうでもいい！
スレッドの１つや２つ使うことに関しては個人の自由だ勝手にしやがれ！

って友達が言ってた。

**名前は開発中のものです。** · 2006/01/17(火) 22:14:58

その元々はオブジェクト１つに１スレッド使う云々っていう話は
>>222のそういう発想は誰もが一度はするかもね
で終わってるんだが。>>237みたく引っ張ってるやつもいるけど。

**名前は開発中のものです。** · 2006/01/17(火) 22:17:08

友達は大事だな

**名前は開発中のものです。** · 2006/01/17(火) 22:51:03

>>261
終わってねーよボケ。

お前の人生は終わってるけど。

**名前は開発中のものです。** · 2006/01/17(火) 22:54:10

>>263 終ってねーの？　やだなぁ。

**名前は開発中のものです。** · 2006/01/17(火) 23:09:07

threadの話飽きた。

↓次の話題ドゾー↓

**名前は開発中のものです。** · 2006/01/17(火) 23:10:27

スレッドは待ち時間がもったいないぞっと

**名前は開発中のものです。** · 2006/01/17(火) 23:54:42

スッドレ

**名前は開発中のものです。** · 2006/01/17(火) 23:56:03

(　´ｰ｀)y─┛~~　なにこの流れ

**名前は開発中のものです。** · 2006/01/18(水) 00:26:10

なんか一人口の悪いのが常駐してるな

**名前は開発中のものです。** · 2006/01/18(水) 00:36:32

プログラムやりたくないんで誰かやってくれませんかねｗ

**名前は開発中のものです。** · 2006/01/18(水) 00:38:34

>>270 あーあヽ(´ー｀)ノｲｯﾁｬｯﾀ､ｲｯﾁｬｯﾀ

**名前は開発中のものです。** · 2006/01/18(水) 01:49:01

ツクールでいいじゃん。機能十分でしょ？

**名前は開発中のものです。** · 2006/01/18(水) 02:08:34

いやそうじゃなくて作業分担できる仲間が欲しいなあって意味ねｗ
俺は絵描き＆音屋なんでプログラムはできれば誰かにやって欲しいんだが
誰もいないので仕方なく全部一人でやってるというわけさorz

**名前は開発中のものです。** · 2006/01/18(水) 02:19:09

絵描き＆音屋に要求する仕様が激しくがんじがらめのオンパレードでよければやったるぞ
絵は1パターンにつき16色、サイズ16*16の組み合わせ、パレット16本を使いまわし
音はMDXでPCM8無し
それでも良ければやってやる

**名前は開発中のものです。** · 2006/01/18(水) 02:38:24

PCM8無しかよッ！
んじゃあらかじめ複数パート合成したPCMでPDXを用意して…

**名前は開発中のものです。** · 2006/01/18(水) 02:51:16

>>273
えらく東方の人くさいｗ

**名前は開発中のものです。** · 2006/01/18(水) 02:51:58

結構贅沢だなぁ

**名前は開発中のものです。** · 2006/01/18(水) 04:22:16

>273
プログラムはできるけど絵、作曲ができない人なんてごろごろいるから本気で探せばすぐ見つかるんじゃないか？

**210** · 2006/01/18(水) 09:31:31

>>273 おれはおまいさんが羨ましいよ。絵も音楽も出来ません。
絵と音楽の問題はいつも俺のモチベーションを下げる（苦笑）。

**名前は開発中のものです。** · 2006/01/18(水) 12:53:48

大丈夫、全部出来ないヤツだって居る

**名前は開発中のものです。** · 2006/01/18(水) 13:53:06

フォローになってねーｗ

**名前は開発中のものです。** · 2006/01/19(木) 01:38:30

俺の場合会社で絵を描いてるので家に帰ると気力が…

**名前は開発中のものです。** · 2006/01/19(木) 23:51:19

じゃあ音楽でも作れよ

**名前は開発中のものです。** · 2006/01/20(金) 01:20:09

クラスって作った方がいいの？カプセル化ってしたほうがいいの？

**名前は開発中のものです。** · 2006/01/20(金) 01:40:22

＞クラス
作りすぎはそれはそれでよくない

＞カプセル化
変数を勝手なタイミングで書き換えたり関数を呼んではいけないタイミングで呼んだりしてほしくないならしたほうがいい
そこらへんを完全に管理できる自信があるんならしなくてもいい

**名前は開発中のものです。** · 2006/01/20(金) 01:49:28

クラスは必須。
カプセル化は最初のうちは気にしなくてもいいが、
1メソッドはなるべく50行以内にするべし。

変数のスコープを最小限に抑えるようにしよう。

**名前は開発中のものです。** · 2006/01/20(金) 05:22:28

>>286のような具体的な例については
「なぜそうしなければならないのか」
それが分からないうちはやる必要がないよ

**名前は開発中のものです。** · 2006/01/20(金) 08:28:37

なぜクラス化が必須か書けよ

**名前は開発中のものです。** · 2006/01/20(金) 09:40:12

それは俺への質問か？ｗ

俺は、オブジェクト指向プログラミングという概念があって、
それを実現するためにクラスを使うと表現が洗練される、という程度の問題で、
クラスを使うことは必須ではないと思うんだけれど。

そーいった意味で必須なのはモジュール化だと俺は思う。

**名前は開発中のものです。** · 2006/01/20(金) 11:36:21

まぁ必須と言っているのは>>286だから説明を待とう。

>>285 なにかおかしい。
クラスの作りすぎが良くないの意味がどうにも分からん。
何をどうクラス化するか、粒度とか役割のバランスをきちんとすれば、
その結果、クラスの数が多くなる事だってあるでしょ。

**名前は開発中のものです。** · 2006/01/20(金) 13:55:41

なんだかわからんがHSPで作ってる俺には関係ないなｗ

**名前は開発中のものです。** · 2006/01/20(金) 18:42:19

>290
＞バランスをきちんとすれば
いや俺は作り｢すぎ｣はいくないと言っただけであって
たくさん作るなとは言ってないわけで
適正に考えた上での数なら別に文句は言わんよ。

極端すぎる話だが1関数につき1クラスとか、どう考えても多いでしょ。

**名前は開発中のものです。** · 2006/01/20(金) 18:51:51

レスサンクス。ごめんね噛み付いて。

> 極端すぎる話だが1関数につき1クラスとか、どう考えても多いでしょ。

うん、まぁこれについても、「多い」のが直接の問題というよりは、
「そもそもその設計で正しいのか？」という匂いがするのが問題かな、と思う。

（余談：一個の関数のみオーバーライドした派生クラスなどは、関数一個と数えるのかな）

**名前は開発中のものです。** · 2006/01/20(金) 21:52:57

どっちにしろ>>284に対して>>285の回答は唐突だな。

**名前は開発中のものです。** · 2006/01/20(金) 23:52:53

>>284
クラスは基礎をかじっただけでも飛躍的にプログラムが組みやすくなる

**名前は開発中のものです。** · 2006/01/21(土) 00:29:20

「多い」っていくつ？

**名前は開発中のものです。** · 2006/01/21(土) 00:30:08

クラス化しないとやってらんないというレベルまではやらなくてもよい。

**名前は開発中のものです。** · 2006/01/21(土) 00:30:18

具体的数字を出さない（出せない）から「多い」なんじゃないのか？

**名前は開発中のものです。** · 2006/01/21(土) 00:31:52

設計によって変わる

**名前は開発中のものです。** · 2006/01/21(土) 00:39:49

クラス設計は、細々とした設計にはあんまし向いて無いんだよな
どちらかといえば大雑把な設計向け

**名前は開発中のものです。** · 2006/01/21(土) 00:49:30

そういや、関数ポインタを知らずに仮想関数を知ったりすると、
クラスの数が異常なまでに増えたりするわな

漏れの事だが

**名前は開発中のものです。** · 2006/01/21(土) 01:02:30

当たり判定の関数作ったんだけど、プレイヤーと敵の引数が入れ替えられなくて困ってるんですが何か良い方法ないでしょうか？しょうがないから現状では二つの関数を作ってしまっています。

現状、
関数A1(&player, &enemy)
関数A2(&enemy, &player)

理想、
関数A3(&player, &enemy)
関数A3(&enemy, &player)

ちなみにplayerとenemyは構造体です。

**名前は開発中のものです。** · 2006/01/21(土) 01:07:12

その構造体用のswap関数でも作っとけば？

**名前は開発中のものです。** · 2006/01/21(土) 01:11:33

>>302
方法１
playerとenemyの基底クラスを揃える
方法２
共用体を使う
方法３
構造体の内容を無理やりにでも揃える
方法４
当たり判定に必要なデータを入れ子にして保持する
方法５
入れ替える必要あんの？どっちが主で従でも当たってるかどうかがわかればいいのでは？

方法４がお手軽で汎用的
構造体の中にx、y、width、heightをバラバラに持つのではなく
player構造体やenemy構造体にrect構造体を持たせる

**名前は開発中のものです。** · 2006/01/21(土) 01:13:55

方法1がスマートだと思うが

**名前は開発中のものです。** · 2006/01/21(土) 01:19:01

Cなら4、C++なら1

**名前は開発中のものです。** · 2006/01/21(土) 01:23:16

クラスが必要かどうかって話にちらっと関係するとおもうけど、
OOPで作ってる場合はほとんど当然方法１になっており、
悩む必要が発生しない。クラスを使うかどうかというより、
OOPを自分が採用するかどうかに悩めばいいのに！とおもふ。

**名前は開発中のものです。** · 2006/01/21(土) 01:27:04

などといいつつ>>302よく読むと意味がわかんないやorz

**名前は開発中のものです。** · 2006/01/21(土) 01:31:53

クラスの継承関係が複雑になる場合には、OOPを使わない事を検討する事もある

シューティングゲーム製作技術総合 9機目

シューティングゲーム製作技術総合　9機目