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

**名前は開発中のものです。** · 04/08/09 19:53

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

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

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

■前スレ
シューティングゲーム製作技術総合　３機目
http://pc5.2ch.net/test/read.cgi/gamedev/1087339516/l50

**名前は開発中のものです。** · 04/09/17 09:48:16

>>611
1.テーブルサイズが88の倍数
2.何か元ネタがある
3.バランス調整のために増減してたらそうなった

たぶん3.だろうけど2.の可能性も捨てきれない。

**名前は開発中のものです。** · 04/09/17 10:20:48

まだやってんの。
ここの住人ならそれほど語るレベルの話じゃないと思うんだが…。

**名前は開発中のものです。** · 04/09/17 10:21:41

よく分からんが東方の世界では意味のある数字とかかもしれないな
作者はいろいろ設定みたいなのも考えてるみたいだし

**名前は開発中のものです。** · 04/09/17 11:31:44

88と言ったら神聖なるエリア88だろ。
東方なんてとんでもねー話だ！（大げさだが）

**名前は開発中のものです。** · 04/09/17 12:17:36

エリ8を神聖視するのはどうかとｗ

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

>607
>なんで256って数字にこだわるんだろう?

おそらく、角度を保持する変数が1Byteに収まるからでは。
まあ今どきのPCではこんなメモリ節約意味ないけど。

**名前は開発中のものです。** · 04/09/17 13:34:26

大量の実数演算の使用に抵抗が無いハードウェア能力に頼った富豪プログラミングか、
旧来の手法（つっても現役の技術だが…）を駆使し、実数演算を排除して最適化を優先
するか。
宗教論なんだよな。

**名前は開発中のものです。** · 04/09/17 13:55:07

ラクチンなほうがいいなあ。

**名前は開発中のものです。** · 04/09/17 14:29:38

メモリアクセス速度も結構馬鹿にならないから
マクローリン展開で求める方法もあるというのを
Gemsだったかどっかで見たような…
ただ収束半径の問題であまり大きな範囲の値を使えないってのはあるけれど
2Dシューなら普通に-PI～PIの間に収まるから結構いいんでない？
もちろん256分割どころじゃなくFPU並みの精度で求まる

**名前は開発中のものです。** · 04/09/17 15:31:10

メモリをあまり喰わない方法としては
おおざっぱなテーブル+隙間は線形補間って手もあるね

ただ、今の計算機だと有効的に使える状況はほとんど無さそうだけど。

**名前は開発中のものです。** · 04/09/17 15:39:46

もうメモリとか気にするのは
へぼハードぐらいか

**名前は開発中のものです。** · 04/09/17 16:09:58

>>622
携帯JAVA

**名前は開発中のものです。** · 04/09/17 16:22:09

携帯のCPUだとFPUとかは期待できないんで自然とテーブル＋固定小数を使った
手法に限定されるんだろうな

あんなんでシューティング作るケイブも相当なもんだな…

**名前は開発中のものです。** · 04/09/17 21:12:31

>>620
マクローリン展開なんて・・・

「こんなもん覚えたって一生つかわねぇよ！」

なんて言いつつ昔公式覚えた記憶が。
まさかこんなところで再び聞くことになるとは・・・

当然「まくろーりん展開」がなんだったのかさえ、既に記憶の
彼方なのは言うに及ばず。
テーラー展開とセットで覚えた記憶はあるんだけど　＿|￣|○

**名前は開発中のものです。** · 04/09/17 21:22:27

>>620
> メモリアクセス速度も結構馬鹿にならないから
> マクローリン展開で求める方法もあるというのを
> Gemsだったかどっかで見たような…
自由に使える実装どっかにある？
何となく試してみたいな～、と思ったりしたのだが。

**名前は開発中のものです。** · 04/09/17 21:34:00

いや、至って普通のマクローリン展開でしたよ(;´Д｀)
sin(x)=x - x^3/3! + x^5/5! - x^7/7! +... って奴ですな。

templateを使ってループをインライン展開すると爆速だって話もあったかな？
ただIntel系CPUの場合はアキュムレータでループさせたほうがいいとかなんとか。
まあ詳しいことはGemsに書いてあるはず。俺は持ってるわけじゃないので…。

**名前は開発中のものです。** · 04/09/17 21:48:58

>>627
そうですか。情報thx。

**名前は開発中のものです。** · 04/09/17 22:15:27

-PI～PIで収束させようと思ったら何次の項までいるんだろ？
それによっては使い物になりそうなんだが……。

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

気になったのでちょいと計算してみた。
13～14乗の項まで使った場合、sin,cosの±PIでの誤差は10^(-4～-5)に収束するね。
ちなみに256分割テーブルでの最大誤差は1.2x10^(-2)
256分割テーブル+線形補間の最大誤差が7.5x10^(-5)

条件分岐を使っていいって話であれば
正負反転で-PI/2～PI/2、sin,cos入れ替えで-PI/4～PI/4まで範囲が限定できるので
もうすこし次数を落として収束させることは可能。
ただ、条件分岐多用して何が高速化だ？って話もある。

**名前は開発中のものです。** · 04/09/18 00:27:15

実は２５６分割というのは４５度分であって１０２４度だったとか・・・はないか
１０２４になれば綺麗に追いかける弾でもまず精度は問題にならないねぇ

問題は面白いかどうかだ
いくら精度がよくても面白くないのでは意味無し

そして精度は面白さに直結するものでもない

**名前は開発中のものです。** · 04/09/18 00:38:42

おまいらそうやっていつまでも三角関数使わないのか？

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

>>632
別に特定地点狙うだけならブレゼンハムでいいし。
ただの思考遊びだよ。

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

ブレゼンハム、ってホントに使ってるのか？
斜め弾早くてＯＫ？

**名前は開発中のものです。** · 04/09/18 01:23:19

>>630
Gemsによれば条件分岐使わないらしい
つまりループのインライン展開
FPUよりも速いとか書いてあった

でも俺はめんどくさいからFPU使ってるけど

**名前は開発中のものです。** · 04/09/18 02:57:43

>>632
色々な手法を模索するのは悪いことではないぞ？
現状ではベストではない手法でも
条件が変われば良い手法に化ける可能性だってある。

**名前は開発中のものです。** · 04/09/18 03:09:04

まあ何度も言われてるけど面白いSTGができれば何使おうと構わない
「そんな技術使わずとも面白いものが作れた」
「これを使ったおかげで楽できて、そのぶん面白いものが作れた」
どちらもある

**名前は開発中のものです。** · 04/09/18 03:34:53

>>634
速度と軌道は別計算

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

どのゲームがどうなってるとか議論するより
それぞれのメリットデメリットについて議論するほうがいいんじゃね？
自分理論押し付けならよそでやってくれと
東方だのケイブなのそんなのどうでもいい
処理の選択をするための指針を論議するほうが意味があるだろ

**名前は開発中のものです。** · 04/09/18 20:35:49

最近だとためになりそうなのは >>484-491,519,571,580,593,605 あたりかな
自分理論の押し付け合いでこういった良情報が流されるのはもったいない

**名前は開発中のものです。** · 04/09/18 20:50:57

というか、ココしばらくは東方だのケイブだのから離れて
純粋に技術話だったと思うんだけど……

**名前は開発中のものです。** · 04/09/18 20:54:59

ブレゼンハムを使って軌道、速度は別計算ってのに興味が。
どうやってんの？
実用性が気になります。

**名前は開発中のものです。** · 04/09/18 23:14:55

距離で割るだけじゃないの？

**名前は開発中のものです。** · 04/09/19 01:05:29

>>642
テキトーにググれ。オレもググった。

結論、今時使う理由がねぇ。

**名前は開発中のものです。** · 04/09/19 03:07:14

大きさが正規化されたブレゼンハムって
ただのベクトルベースでの処理の気がするんだが……
いや、ベクトルベースでの自機狙い自体はメリットも多いんだけどね
atan求めなくていいし、誤差少ないし。

自機狙いN-way弾(間隔θ)がちょっとめんどくさそうだけど
実は三角関数計算はsinθ,cosθをそれぞれ一回だけで済む(なんなら固定値で持ってしまえばいい)。
ただ、誤差の蓄積の関係上、自機狙い全方位弾は辛い。

**名前は開発中のものです。** · 04/09/19 08:33:25

>645
意味することは判るが、
何かものすごく変なものに聞こえるな＞自機狙い全方位弾

**名前は開発中のものです。** · 04/09/19 12:30:47

もっと変な言い方をすると、奇数全方位弾または偶数自機狙い全方位弾のことか
偶数弾はこういう言い方のときは使わないほうがいいな…ベターな言いかたあったっけ

**名前は開発中のものです。** · 04/09/19 12:32:34

普通偶数弾は自機に当たらないものに対してのみ用いる言葉だが、
偶数個撃たれて自機に当たる全方位弾のことな
別に(全方位弾を偶数奇数の)区別なんかしねーか

**名前は開発中のものです。** · 04/09/19 12:53:35

ガルザカートって16方向（＋誘導ｘ4）なのに自機に当たるなあ。

**名前は開発中のものです。** · 04/09/19 13:06:42

命名案、固定型全方位弾、照準型全方位弾、演出型全方位弾。

**名前は開発中のものです。** · 04/09/19 13:14:47

自機狙い偶数散弾、自機狙い奇数散弾なら、そのままなんだけどな。
偶数弾は動かなければ当たらないから。

**名前は開発中のものです。** · 04/09/19 13:39:26

>>650
演出型全方位弾、ってどんなの？

自機が止まってれば当たらない、偶数弾みたいなやつのこと？

**名前は開発中のものです。** · 04/09/19 17:46:48

肝心なのは当たるかどうかかなあ
・自機が止まってると当たる (奇数弾etc.)
・自機が止まってれば当たらない (偶数弾etc.)
・自機が止まってても当たるか当たらないか不定 (遅延発射etc.)
まぁ作ってるときは名称気にしないな

**名前は開発中のものです。** · 04/09/19 18:20:55

奇数、偶数ってのがどうもわかんねーね。
敵がただ一発撃って、それで
　・自機が動いてる　当たらない or 当たる（当たってしまう場合もある）
　・自機が止まってる　当たって当然（故意 or ミスってハズしてしまう場合もある）
だと思うんだが。

**名前は開発中のものです。** · 04/09/19 18:23:33

>>652
動かなければ当たらない弾幕って、単体だと演出かもしれないけれど、
組み合わせると凶悪な障害物だと思うけどな。移動範囲が狭くなるし。

**名前は開発中のものです。** · 04/09/19 18:36:03

当たる当たらないの前に
射出方向が
自機位置に依存する・依存しない
じゃないかなぁ

**名前は開発中のものです。** · 04/09/19 19:29:28

>>656
そうじゃなくて、自機を狙った弾を中心として左右に等間隔で撃ち出すのを奇数、
自機を挟むように等間隔で打ち出すのを偶数、と呼んでいるんだと思う。

**名前は開発中のものです。** · 04/09/19 20:41:50

>>657
それ両方とも射出方向は自機位置依存でしょ

自機位置に対して
├　依存するよ　┬─　奇数弾
│　　　　　　　　　└─　偶数弾
└　依存しないよ　┬─　方向固定弾
　　　　　　　・
　　　　　　　・
　　　　　　　・
って話

**名前は開発中のものです。** · 04/09/19 21:00:59

自機狙い偶数弾(?) → 「奇数弾＋１」でいいじゃん。
偶数弾に見せかけてるだけの奇数弾のことじゃないのん？

**名前は開発中のものです。** · 04/09/19 21:07:17

>658
やはりファンタジーと呼ばれるものを撃ったりするのか？

**名前は開発中のものです。** · 04/09/19 23:10:03

**名前は開発中のものです。** · 04/09/20 00:59:52

狙い方向を中心とした左右対称なN-Way弾の場合
奇数弾→中心の弾が狙い方向→動かなければ当たる
偶数弾→狙い方向がちょうど隙間→動かなくても当たらない
って認識で通常は問題ない。

ただ、全方位弾の場合、
弾の偶数奇数と狙ってる角度に弾があるのか無いのかは全くの無関係。
それなのにN-wayの時の慣習を使って実際の弾数と無関係に
当たるのを全方向奇数弾、当たらないのを全方向偶数弾と読んだりすることがあるので大混乱。

**名前は開発中のものです。** · 04/09/20 01:03:53

>>661
http://that3.2ch.net/test/read.cgi/gline/1095432644/2-3n

**名前は開発中のものです。** · 04/09/20 03:49:20

＞中心の弾が狙い方向

だからその一発の精度の話をしてるんじゃないの？。
いや、敵弾を全て単発にしろって意味じゃなくてさ

つまり単発だとボロが出るからｺﾞﾆｮｺﾞﾆｮと･･･(ry

**名前は開発中のものです。** · 04/09/20 12:26:58

今は誤差の話なの?
N-Way弾と全方位弾の種別による呼び名がややこしいよな、って雑談レベルの話じゃないの?

いや、その話がSTG製作に重要か?といわれると微妙だけど。

**名前は開発中のものです。** · 04/09/20 12:35:55

衝撃波が広がってくようなエフェクトってどうやって作ればいい？
ドーナツ状の画像をジョジョに拡大してくしか思いつかないんだが、プログラムだけで作れないですか？

**名前は開発中のものです。** · 04/09/20 13:10:03

>>66
プログラムだけってのがよくわからんけど、画像を拡大するのがＮＧだとしたら
小さい画像を円形に配置して全方位弾よろしく徐々に拡大するとか・・・

**名前は開発中のものです。** · 04/09/20 13:10:17

>>666
TriangleFanで円形状のポリゴンを作る。

**名前は開発中のものです。** · 04/09/20 13:17:18

拡大がダメな理由って、衝撃波の幅もいっしょに拡大されてしまうから?
だとしたら
ドーナツ状の平面ポリゴン作ってテクスチャ貼って
外側の円と内側の円の間隔が一定になるように大きくすればいい

**名前は開発中のものです。** · 04/09/20 13:26:30

円を描くプログラムを使って、半径を増やしていくとか？

**名前は開発中のものです。** · 04/09/20 13:36:40

スト３の真昇龍拳の衝撃波はかっこよかったな。>>669のは良さそう

**名前は開発中のものです。** · 04/09/20 15:10:50

ここはどんな質問もすぐにレスが返ってくるいいインターネットですね。

>>667
それだと結局拡大するにつれて荒が出るのでは・・・

>>668 >>669
なるほど。２枚重ねるのは思いつかなかったです。
これなら幅は均等ですね。
試してみます。

>>670
凄い素直なやり方ですね。ていうか衝撃波っぽく見えなげな気ガス・・・(´д`;)

**名前は開発中のものです。** · 04/09/20 15:16:07

BGとパレットチェンジ

…ああっ

**名前は開発中のものです。** · 04/09/20 16:41:50

衝撃波用の、普通に塗りつぶしてある円を描いてから
それより少し小さく背景を描く透過円を描画するのは？
（円マイナス小さい円で輪を作る）

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

>>674
そうやって俺をイラつかせて、何をしたいんだ。
俺に恨みでもあるのか。それとも人をからかうのが好きなのか。
どちらにしても、お前は悪意をもって人を傷つけようとした。
こういう事はこれで最後にしろ。

**名前は開発中のものです。** · 04/09/20 17:15:05

ストリップで幅のある輪でいいじゃん。

**名前は開発中のものです。** · 04/09/20 17:44:26

なんかスクリプトが来てるな。

**名前は開発中のものです。** · 04/09/20 17:55:51

衝撃並とはちょっと違うかもしれないけど
エッジを外側に向かって伸ばす

**名前は開発中のものです。** · 04/09/20 20:46:25

エフェクト類はアニメとか非常に参考になるよ。
画像の荒れはあんま気にしなくて良いんじゃないかな。
見せ方と動きのほうがカッコ良く見せるためには重要だと思う。

**名前は開発中のものです。** · 04/09/21 00:20:16

でかいワッカ画像を用意して、縮小状態から元のサイズに戻すんじゃだめなのか。

**名前は開発中のものです。** · 04/09/21 00:27:09

荒さや衝撃波の幅が問題になるなら
拡大(縮小)用画像を何段階か用意するって手もある。

**名前は開発中のものです。** · 04/09/21 01:59:40

だからストリップでわっかでいいと何度言えば判りますか。

**名前は開発中のものです。** · 04/09/21 02:26:20

ポリゴン使えない環境はどうすんだよバーカ

**名前は開発中のものです。** · 04/09/21 02:35:23

>>684
んなもんでかいテクスチャのミップマップ使えばええよ。

**684** · 04/09/21 02:35:49

>>681＿|￣|○

**名前は開発中のものです。** · 04/09/21 02:40:53

>>683
パレットチェンジでいいんじゃないかしら？

**名前は開発中のものです。** · 04/09/21 04:05:34

>>683
ポリゴンが使えないなら別の案を出すだけ。

・矩形転送だけしか出来ないなら拡縮
・輪のエッジを算出してフィルで塗りつぶしてなんちゃってポリゴン
・２Ｄだけど半透明がつかるなら自力描画でポリゴン。
・任意変形スプライトがあるならそれで。

ていうか、２Ｄベースか３Ｄベースかで解が違う。
どうなんだ666

**名前は開発中のものです。** · 04/09/21 08:21:18

そもそもポリゴン使えない場合は、
表現自体かなり制限がかかるからな・・・。
>>666がどのレベルのものを望んでいるかによるわけだが。

**名前は開発中のものです。** · 04/09/21 09:17:34

小さいのから大きいものまでの絵を用意して順番に表示すればいい

**名前は開発中のものです。** · 04/09/21 11:22:25

最初から低スペック向けで考えない限り
ポリゴン使えない環境なんて想定する必要ないだろ

**名前は開発中のものです。** · 04/09/21 11:53:51

使えない環境というか、使わない環境で作ってるかもしれないけどな。

**名前は開発中のものです。** · 04/09/21 15:04:03

最近のPCだとかえって遅くなったり

**名前は開発中のものです。** · 04/09/21 18:01:15

つか、ポリゴン使えないから拡大縮小意外でって事じゃないのか？
そもそもポリゴン使えるなら、テクスチャ貼ってサイズ変えて終わりでは・・・

**名前は開発中のものです。** · 04/09/21 19:13:43

テクスチャ貼ってサイズ変えてってのは
ドーナツ状の画像をジョジョに拡大してくのと
どう違うのかね
このままじゃ無限ループだぞっと

**名前は開発中のものです。** · 04/09/21 22:13:00

お前の衝撃波なんか誰も気にしてねーよ(ﾌﾟ

まあ、適当にやっとけばいいんじゃないでしょうか。

**名前は開発中のものです。** · 04/09/21 22:14:22

自機に慣性のあるゲームの場合、最大速度の制限はどっちがいいかね？

１　Ｘの最大値とＹの最大値で制限（斜め方向が速くなる）

２　総ベクトルの最大値で制限（斜め方向でも同じ）

**名前は開発中のものです。** · 04/09/21 22:22:23

圧倒的に２かと

**名前は開発中のものです。** · 04/09/21 23:26:32

もちろんエクセリオンタイプ

**名前は開発中のものです。** · 04/09/22 00:01:46

エクセリヲンと言われても糞ゲーってことしか記憶に無いんだが

**名前は開発中のものです。** · 04/09/22 00:18:15

エアバスターｗ

**名前は開発中のものです。** · 04/09/22 01:14:21

Zwei!タイプ

**名前は開発中のものです。** · 04/09/22 01:54:35

>696
商品にするなら２が無難。
ただの趣味なら自分の好みで選べ。
どっちにするか決めかねるならオプションで選択できるように。
あとは自機１号機と２号機で変えるとか、アナログスティック専用にしてしまうとかｗ

**名前は開発中のものです。** · 04/09/22 08:07:00

エクセリヲンは名作
糞ゲーだと感じた輩は己のセンスを呪え

**名前は開発中のものです。** · 04/09/22 09:59:56

おみゃーら様聞いてください。
リプレイを付けてたんですがフレーム毎のキー入力を記録して再現させようとすると
別のPC持っていったときどうしてもズレてしまいます。
どうしたら良いんでしょうか？

**名前は開発中のものです。** · 04/09/22 10:36:00

そのPCは例の浮動小数点の計算がアレなパソコンなんじゃね？

**名前は開発中のものです。** · 04/09/22 10:55:43

CPUはインテルやAMDなどメーカー系列が違うと、一方でうまく動いていたものが、
もう一方では動かない（動作表示が変わる）といったことが起きるらしい。
同じプログラムのものが、表示レベルで変わってしまうことがあるんだよ。
ネタじゃなくてマジ、2年程前にあった話。
仕方がないので、最適化されてると思われるプログラムを、まわりくどいやり方で
くずして、なんとか両方に対応させたことがある。

でも考えてみれば、Windows以前は、CPUどころかスペック一つ違えば
プログラムって変わって当たり前だったよね？
今もときたま、OSやコンパイラで吸収されるはずのPCの性能が、
プログラムによっては効かないことがあるのかも知れない。
最適化や裏技使ってたりとか、かなり特殊なプログラムの場合にそうなるのかも。

**名前は開発中のものです。** · 04/09/22 11:16:15

描画その他は機種で挙動が変わるのは当然だが
内部の計算で挙動が変わるようなものは使いものにならないぞ
規格どおり組んで挙動がおかしいならOSかコンパイラのバグだ。

アーキテクチャに依存するコード書いといて『挙動がおかしい!!』って叫ぶのは当人のバグだ

**名前は開発中のものです。** · 04/09/22 12:07:26

エフェクトの有無とかフレームのスキップとかで乱数の消費具合が変わるとか
いう初歩的なミスだったりしない？

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

どのような操作でどうズレるのかいろいろリプレイ作って、多少なりとも切り分け(できるかわかんないけど)

**名前は開発中のものです。** · 04/09/22 14:34:36

>>707-708みたいなお決まりな指摘は置いといて、>>705-706に興味があるわけだが。

AMD機は持ってねーけど、IntelとAMDで完全に演算結果が同じとは思えんのだがどうなのよ。
四則演算程度ならIEEE754かなんかで保証されとるのかも知れんが、
三角関数命令とかSSEとか微妙じゃねーのか？

どっかそのあたり詳しく検証したものはないのか。

**名前は開発中のものです。** · 04/09/22 17:22:28

三角関数はともかくSSEは機種依存じゃないの？

今回は 707-708 じゃねーの？
とりあえず、何がどう狂うのかを挙げれ。

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

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