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

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

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

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

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

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

**名前は開発中のものです。** · 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を使わない事を検討する事もある

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

それは設計能力がゼロのやつだけだろ

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

>>310
同じ関数を何度も書きたくないだけなんだよ
テンプレートを使えば良いだけなのかもしれんが・・・なんか抵抗があるんだよな・・・orz

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

>>284
実装の手間を省くための継承、という面がしばしば強調されすぎてるんだとおもふ。
本当のおいしさはいつだってポリモーフィズムなんだから（偏見）、そのために継承を使い､
ほかはオブジェクトコンポジションでゆるーくクラス間を関係させておきたいよね。

クラスがうんぬんというだけじゃ不十分。OOPってもんがどうしてあるのか、
それが自分に役に立つのか、いっぺん調べてみるのが良いかと。

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

クラス～なぜ継ぐの～　クラスの勝手でしょ～♪

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

>>312
同意。んでいかに仕様変更に強い設計ができるかがOOの肝だと思う。

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

いまだにOOPがゲームにむかないとかいってるやつ多いのもあれだよな

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

クラスの実装はOOPの実装を補佐するための実装だからな。
やろうと思えばC言語だけでもOOPで組める。

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

>>315
過去の遺産をOOPに直すには、それなりに時間がかかるからだろ

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

>>316
まだこんなこといってるやついるのかｗ

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

まぁ、実際出来てるしな。面倒くさいけど。

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

完成させることが出来るんなら、その手法はなんでもいいと思う。

そもそも完成すらおぼつかない奴が多すぎる。

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

>>318
>>316は事実だろ、どこが悪いんだ？
それとも周知の事実だから別に言う必要もないという程度のこと？ｗ

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

>>320 が良い事言った！！　しかし耳が痛い(　´ｰ｀)y─┛~~

CでOOP。この発言はちょくちょく見かけるけど複雑な思いがよぎるよ。
ホントにCでしか開発できない状況になったらそんな悪あがきするだろうけど、
C++も選べる状況だったらねー。意地でもC++使いたいけどね…。
OOPで楽をしたいと思ったとき、「Cでも出切る」って意見の意図が俺わからんのよね。
OOPLを軽視しているか、OOPを楽しめていないのか、そんな感じを受けるんだよね（偏見）。

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

このスレはPC等の板だからCが選択できてC++が選択できないってのはあんまり考え付かんな

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

>>323 そうそう。それもある。だから余計に不思議っていうか、
どういう意図があるのか疑問に思ってるんです。

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

どうでもいいじゃん。

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

なんつーか、多くの人が単なる請け売りなんだよなー。

>クラスの実装はOOPの実装を補佐するための実装だからな。
>やろうと思えばC言語だけでもOOPで組める。

だとか

>本当のおいしさはいつだってポリモーフィズムなんだから（偏見）、そのために継承を使い､
>ほかはオブジェクトコンポジションでゆるーくクラス間を関係させておきたいよね。

だとか。何年も前に既に言われてることを、
さも自分の思いついた意見かのように言っちゃってまぁ…。

知識晒して、優越感感じたいだけだろ。

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

> さも自分の思いついた意見かのように言っちゃってまぁ…。

俺の思いついた意見ではありません。受け売りとおっしゃるが、
技術的な基礎、これはこうやって共有していくもんとちがう？
だから>>284への返答をするとなると、こういうレスをつけちゃう。

> 知識晒して、優越感感じたいだけだろ。

あたりまえのことを晒しても優越感は得られません。
あたりまえのことを、あたりまえに言っただけ。

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

>>332
分かってると思うけど、OOPは所詮は概念だから、どの言語でもできるんだよ。
それが「Cでもできる」の意図でしょ。
そして、C++やJavaなどのOOPLな高級言語を使うと概念を記述するのが容易くなる。
例え「Cでもできる」と言い張っても、選択の制約が無いならわざわざCなど選ばんｗ

例えばPrologなんか知ってる奴は分かると思うんだが
手続き型プログラミングの設計でわざわざPrologでやる奴はおるまい？
概念に適した言語を使えばよいというだけだな。

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

>>322だった

**302** · 2006/01/21(土) 16:29:34

>304-all
ちょっと勉強不足せいでどうなるか（どうするか）不明です。けれどとても参考になりました。ありがとうございました。

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

>>326の発言はどうかと思うが・・・。

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

>>327
>俺の思いついた意見ではありません。
なら、
>実装の手間を省くための継承、という面がしばしば強調されすぎてるんだとおもふ。
「おもふ」とか言ってんじゃねーよ。実装継承がうんたらも何年前だよ。

>技術的な基礎、これはこうやって共有していくもんとちがう？
お前は単に情報を劣化して請け売りしてるだけ。ソースだけを示した方が良い。

>あたりまえのことを晒しても優越感は得られません。
お前は当たり前のことに言うのに「（偏見）」とか付けるのか。２回見たぞ。

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

はいはい順番にレスしますね。

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

>>328 例え「Cでもできる」と言い張っても、選択の制約が無いならわざわざCなど選ばんｗ
それなら分かる。

>>332
>> 実装の手間を省くための継承、という面がしばしば強調されすぎてるんだとおもふ。
> 「おもふ」とか言ってんじゃねーよ。実装継承がうんたらも何年前だよ。
>> 技術的な基礎、これはこうやって共有していくもんとちがう？
> お前は単に情報を劣化して請け売りしてるだけ。ソースだけを示した方が良い。

失礼、そのとおり。しょうもないことを言ってしまってごめん。

>> あたりまえのことを晒しても優越感は得られません。
> お前は当たり前のことに言うのに「（偏見）」とか付けるのか。２回見たぞ。

OOPの美味しさはいろいろあるだろう。そんなかでやっぱ特においしいものはといえば、
> ポリモーフィズムなんだから（偏見）
言い切ってしまうのはヘン。俺にとってはと限定しようとすると、偏見、とつけた。

> OOPLを軽視しているか、OOPを楽しめていないのか、そんな感じを受けるんだよね（偏見）。

これはまさに偏見。CでOOP発言をしている人にたいしての、俺の偏見。

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

ずっと口が悪いやつが一人いるから相手にせんでも

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

何人が議論してるのか分からんくなってきたな
茶々入れも含めて、もはや何が何やら・・・

どっかに設計概念全般に関するスレッドは無かったか？

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

Javaみたいな楽な言語がネイティブバイナリ吐ければ
いいんだけどなぁ。

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

GCJではいけないことないが、細かいところで挙動とかがまだまだ
実装率ってあてにならんよね

しかもネイティブだけどSunのVM実装よりかなり遅いしな
ネイティブの意味がないとかよくいわれてる

どの道実行時にコンパイルしてるんだから
その辺はいまじゃこだわる必要はないと思うけどね

あれはNETBSDとか局地専用
そしてネイティブにこだわる人のほとんどは最適化の進んでいるWinだったり不思議なものだ

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

言語に対する我儘を下手に追求すると、
漏れみたいに自前でスクリプトを作ることになるぞ。ｗ

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

OSもCコンパイラも無い環境で仕事することあるから(組み込み)
家では贅沢な環境でやりたいなー

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

なんか荒れてるみたいですが
「ＯＯＰ」を「おっぱい」と読むと楽しくなるぞ

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

ＯＯＰ

横に髪留めを付けたメガネ娘にも見える

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

おしおきが必要ですね

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

話を戻すが、なぜ敵とプレイヤーの当り判定関数が２つ必要なのか想像してみる。
敵とプレイヤーの当り判定。その結果をプレイヤーの構造体に書き込み。
プレイヤーと敵の当り判定。その結果を敵の構造体に書き込み。

まあつまり1つの関数で全部やろうとするから組み合わせ分関数が必要になるわけですよ。
当り判定専用関数とそれ専用の構造体なりクラスなりを持て。
で、当たってた場合の個別の処理は、それぞれの関数で実装すべし。

理想、
関数　bool Collision( &Collision, &Collision )
関数　void プレイヤ判定用( &Player, &Enemy )
関数　void 敵判定用( &EnemyCollision, &PlayerCollision, )

PlayserもEnemyもCollisionリストを持っており、それぞれを使って判定して
当たっていた場合の処理をそれぞれの関数のなかでやる。
C++で設計するならコリジョンクラスの中に判定用メソッドつける。
判定自体を汎用化しときゃバグ取りも1回で住むし、アイテムや敵同士の判定などにも
用意に使いまわせる。

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

話が難しすぎてさっぱり分からんがシューティング作るぐらいでそこまで効率とかにこだわる必要あるのか？

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

趣味でつくとなると普通は時間が早々取れるものでもないから
バグの出にくい、わかりやすい保守しやすいコードは大事ではないかな

ミニゲーム程度ならきにはせんだろうけど、しっかり作るとなると
年単位でかかるのも珍しいことではなかろう

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

>345
ぐらいって、シューティング制作を無礼るな！

効率と言うより再利用性。

まあ>344はちょっと訊かれてもいない実装の詳細を語りすぎている感があるが。

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

再利用なんて、二作以上作ってから言うべき。

シューティングなんて、プログラミング的にはぶっちゃけミニゲーム程度のモンだし。

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

どこまで話をもどすかアンカーつけろよ>>344

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

小さいプログラムこそ何度も吟味して設計したらいいと思う。

何度も書き直せるサイズだからこそ、書き直しも楽になる。
効率や再利用性についても、とことん試せるってもんでしょ。

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

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