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

**名前は開発中のものです。** · 04/06/16 07:45

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

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

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

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

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

どうでもいいようなとこに拘りすぎると
いつまでたっても完成できないのが問題なんだよ。

**名前は開発中のものです。** · 04/07/05 11:02

無圧縮bmp使うなんて無神経なこと俺にはできねーよ！ってやつは
作るものもそれなりのものである・・と考えたい。

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

敵の動きとか配置を考えるのが難しくて面倒だ…。
これじゃ物足りない…、もっと早くするか…、
これだと全て倒しきれないな…、もっと動きを複雑にするか…
配置が美しくないな…、何度も作り直して延々と時間食う。

**名前は開発中のものです。** · 04/07/05 15:40

ドラクエとか、マザーとか

**名前は開発中のものです。** · 04/07/05 17:53

？

**名前は開発中のものです。** · 04/07/05 19:02

bmpってボトムアップで格納されてるから
上にスクロールする縦STGとは相性がいいのかもしれんな

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

>>407 君、ゲーム作ったことないだろ。（＾o＾
このスレに居て楽しい？

**名前は開発中のものです。** · 04/07/05 19:24

クラスで最も嫌われるタイプ

**名前は開発中のものです。** · 04/07/05 19:31

>>405
さすがにマザーは一枚BMPは無理だね。
ファミコン画質で東京ドームぐらいの広さがあるんだっけ？

**名前は開発中のものです。** · 04/07/05 19:36

ここに馬鹿すぎてこっちが恥ずかしくなる奴が居るんだが
（４０７とか）何が目的なんだろ？

**名前は開発中のものです。** · 04/07/05 19:43

そんな反応することかよ

**名前は開発中のものです。** · 04/07/05 19:45

>>407
言いたいことはまあわかるけど･･･

**名前は開発中のものです。** · 04/07/05 19:55

XxYマスの縦STGのマップを考えてみる。
ドット絵エディタでXxYドットの8bitBMPを作成する。
パレット番号とマップチップ(敵配置マップなら敵番号)を対応させれば
マップエディタを作成せずとも視覚的にマップを作れるかもしれない。
描くときは下から上へ、読み込むときは先頭から読めば良い。

だからなんだの域を出ないような気もするが。

**名前は開発中のものです。** · 04/07/05 20:00

あ、もちろんBMPのヘッダは読み飛ばして。
バイナリエディタ直書きに比べればきっとマシだと……思う、自信なし、所詮思いつきだし。

**名前は開発中のものです。** · 04/07/05 20:00

むっちゃ反応する人がいるなぁ
mIaBS7Ac乙

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

スクロールは上下左右労力同じ（移動加算値変えるだけ）で
ＢＭＰと相性がいいスクロール方向なんて無い。
というか絶対にありえない。

**名前は開発中のものです。** · 04/07/05 20:06

>>414-415
BASIC時代にマップチップを1チップ1画素で表示したのを思い出して懐かしくなった。
遊びとしてはそういうのもアリだと思うよ。

**名前は開発中のものです。** · 04/07/05 20:08

>>414
マップエディタを作るのが面倒くさい場合は有りかもしれんが
パレットとチップの対応を人力管理しなくちゃならないので
却ってそっちのが面倒くさいだろうな

大抵のドット絵エディタは256色ずつでしか管理できないので
それ以上のチップを扱うときにややこしくなるのも難点か

**名前は開発中のものです。** · 04/07/05 20:31

ボトムアップだと上下逆？そこまで難しく考えなくても良いよ。
視覚的にはＢＭＰの絵柄と描画を同じにした方が分かりやすい。

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

以前からゲーム製作未経験者のような発言でもスルー
されたけど微妙に気持ち悪かったから407のような
発言に突っ込みいれたくなる気持ちも分かる。
それでもスルーしたほうが良いかもしれないけど。

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

その程度の細かいこと気にするんだったら、
もっと他にすべきことがあるだろう…

**300(114)** · 04/07/06 07:12

レイピア、スローモード、
スロー時の、撃った弾がアイテムになる処理等を入れました。
スローにすると、敵の動き（到達地点）が変化してしまうので、修正しないと、、。
後は、宝石の数、倍速モード、ボス等を入れる予定。

因みに、背景は16bitでやってます。良いツールを使えば8bitでも遜色ないでしょうが、
実験してないです。

**名前は開発中のものです。** · 04/07/06 07:49

>>423
レス番号を書いてくれ。前半4行が唐突すぎて分からん。
独り言のエクスキューズとして後半2行を加えたように見えるぞ。

**名前は開発中のものです。** · 04/07/06 08:27

流れが読めないなら、無駄なレスはやめとこうぜ。

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

つーか、blog代わりに使いたいなら
板公認の報告スレを活用したほうがナンボかマシだろ。
　
■自主製作ゲーム：開発状況報告スレVer0.3■
http://pc5.2ch.net/test/read.cgi/gamedev/1071809112/l50

**名前は開発中のものです。** · 04/07/06 10:48

スクロール方向なんぞ足すか引くかの違い。
上下反転？　テクスチャの貼る方向を逆にすりゃええ。
DirectX8じゃない？　ヽ(・∀・)ﾉｳﾝｺｰ

シューティング製作以前の問題だな

**名前は開発中のものです。** · 04/07/06 15:08

>>388
踏み絵を踏みに行くような気分だが
背景レイヤーのうちの1（遠景）を
丸々一枚絵方式でやったことはあるぞ。
　
システムメモリ上に圧縮データ1ステージ分。（約2MB）
ステージ進行中に圧縮データをデコードしつつ
（差分）転送。フレーム単位の転送量は1[KB]程度。
問題なく60[fps]出ていた。
　
そんときのメモリ上の圧縮データは
展開してもせいぜい7MB程度（256*7200*32[bpp]）だったので
むしろそっちでやったほうが良かったという罠があったが。

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

背景レイヤーのうちの“1枚”ね。ｽﾏｿ

**名前は開発中のものです。** · 04/07/06 15:42

>>428
データ圧縮＆1INT内での展開ならOkじゃない？

**名前は開発中のものです。** · 04/07/06 16:18

うん。たしかに一枚絵の場合でもシステム→ビデオメモリの転送にかかるコストは
どうってことないんだよな。俺はテクスチャ上のパターンデータ（8x8テクセル）を
フレーム毎に数個づつ書き換えたりするんだけれど、そんときのデータサイズも
似たようなものだし。
　
結局、一枚絵の弱点はパッケージサイズの肥大化ぐらいかね。
ネットで配布するようなケースでもなければ無問題だと思うよ。

＃つーか、漫画板のアゴ無しスレに誤爆した･･･鬱

**名前は開発中のものです。** · 04/07/06 16:57

一枚絵だとステージとステージの間でファイルから画像読みに行くときに
固まりそうでｲﾔｰﾝな気がする。演出とか入れてごまかせばいいのかも
しれんけど、シームレスに次のステージに行きたいときは無理。

うまくやれば別スレッドで画像を読みつつスムーズにステージ切り替え
できるかもしれんけど俺はあんましやりたくないな・・

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

うい。お察しの通りシームレスは無理だたよ･･･。
得点算出画面を描画しながら裏でガリガリとロード。

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

>たしかに一枚絵の場合でもシステム→ビデオメモリの転送にかかるコストは
>どうってことないんだよな。

そうか？
かなり前にDirectDrawでシステムメモリのオフスクリーンサーフェイスから
Bltさせた時、タイル化してBltを繰り返した時と１枚絵を１発Bltした時で結構
差が出た記憶が…
オーバーヘッドを少なくする為１枚絵のBltで実装しようとしてる俺は
負け組みですかそうですか

**名前は開発中のものです。** · 04/07/06 18:50

差分だけだからたいしたことないだろ
たとえば１ピクセルのスクロールごとに処理なら１ライン分の転送だけですむわけだし

**423** · 04/07/06 19:03

>>426
では、そうします。
質問や相談もやりつつ、結果を報告出来ると思ったんですが。

１枚絵の背景も、ＣＡＶＥ系を再現したい。てので出た話題なのだし。

自分の場合は、１画面を１ＢＭＰで保持して、３画面分同時に描画。
で、１画面スクロールするごとに、一番下の画面を上に移動＆テクスチャ再セットしてます。

**名前は開発中のものです。** · 04/07/06 19:12

俺は興味あるからここに報告あると嬉しいけど。

**名前は開発中のものです。** · 04/07/06 19:16

俺も。1週間に一度くらいなら気にならないし。

**名前は開発中のものです。** · 04/07/06 19:26

>>434
俺もDirectDrawでハイカラー以上でやるときは
システムメモリ上でソフトウェアレンダラーで全て
描き込んでからビデオメモリに一括Blt()するよ。
　
Direct3Dでやるときは
ビデオメモリ上でハードウェアレンダラーで全て
描き込んだほうが圧倒的にお得だから、組み方が
変わる。
　

**名前は開発中のものです。** · 04/07/06 19:48

>>434
程度（サイズ）にもよるが、
Direct3Dで背景をマップチップでやるときは
固定サイズの頂点メッシュを使ってスプライト機のBGテーブル的な
組み方が出来るんだよ。差分書き換えするのはマップチップの
インデックスではなく頂点のテクスチャUV値になるけどね。
背景の描画はDrawPrimitive2回で済む。

**115** · 04/07/06 21:31

>>423
＞１枚絵の背景も、ＣＡＶＥ系を再現したい。てので出た話題なのだし。

はあ？

33 · 04/07/06 21:42

>>441
お前は一体何しにこのスレにいるのかと小一時間(ry

**名前は開発中のものです。** · 04/07/06 21:49

>>442
オフコース

**436** · 04/07/07 00:34

ではでは、たまーに、何か大きく進展したら報告するという事で。

>>440
最初はメッシュ＆ＵＶ設定ツールでも作ろうかと思ってました。
しかし、だったら３Ｄツールでいいんじゃないかと思ったりして断念。

今のやり方は、>>117を参考に組んでみましたが、半画面で１チップにした方が
効率が良いので、改良してみます。

当面の目的は、ツールに敵配置機能を追加する事ですが、ガルーダ等みてると、
配置と動きが連動していて、（戦車、中型機等）
現在の、敵の動きをハードコーディング部分から
見直す必要があるという問題で煮詰まり中です。

**436** · 04/07/07 00:34

ではでは、たまーに、何か大きく進展したら報告するという事で。

>>440
最初はメッシュ＆ＵＶ設定ツールでも作ろうかと思ってました。
しかし、だったら３Ｄツールでいいんじゃないかと思ったりして断念。

今のやり方は、>>117を参考に組んでみましたが、半画面で１チップにした方が
効率が良いので、改良してみます。

当面の目的は、ツールに敵配置機能を追加する事ですが、ガルーダ等みてると、
配置と動きが連動していて、（戦車、中型機等）
現在の、敵の動きをハードコーディング部分から
見直す必要があるという問題で煮詰まり中です。

**436** · 04/07/07 00:38

二重投稿すんません

ついでに
Ｘ　敵の動きをハードコーディング部分から
○　敵の動きをハードコーディングしてる部分から、

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

道なりに動く戦車のコーディング、ゼビウスとかはどうやってたんだろ？
(1) 地形と全く相互作用せず、進行方向への加減速と移動方向相対変化で記述
(2) 初期ウェイトと移動方向のみ指定、あとは道に埋め込まれているオブジェクトに反応
脱線するが、怒首領蜂大往生の戦車はカーブをなめらかに曲がっているように見える。
実際は少し移動して方向転換、の繰り返しだとは思うけど。

**名前は開発中のものです。** · 04/07/07 06:28

ゼビウスか…。
あれバカでかいマップがあって、それを面によってX座標ずらして表示してるんだよな。
ドモグラムの盆踊りや伸縮移動を見るに、画面上の座標と関係なくマップ上の座標で
動かしてるんだろうが、細かいことは判らない。

たしかゼビウスは3つCPU使っててキャラクタデータ管理とかは分けられていた筈…。

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

　基本的には移動パターンをいくつか作っておいて、カウンタの初期値を変えてるだけじゃない？
　でも、ゼビウスって今以上にボーナスポイントの設定とか細かいことにこだわって作られてるんだよなぁ。
　ブラスターを避けるグロブダは今でも感動する。

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

フリーや同人だとそこまで動きにこだわった作品は
少ないな…

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

超連射での加減速をうまく使った見栄えのする敵機動には見習うところがあるかも。
アケシューならザコヘリの等速運動→減速→ホバリング→加速+旋回でUターンといった動きを
ちょっと真似してみるだけでも学べる。

まぁ最初からそこまでやる必要はないけど。
慣れてきたら等速運動や状態遷移なしの動作から先に進んでみると
敵にｲｲ動きをさせることができるよ、ってことで。

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

良い動きする敵がいると、それだけで気持ちが良いね

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

ゼビウスのザコの動きは制作初心者はよく研究してみるといいかも
ゾシーやタルケン等々
テラジなんかはいまだに動きの代名詞となってたり。

最近のザコは寿命が短いせいか、集団で突っ込んでくるのばかりでチトさみしい

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

テラジる……(ﾎﾞｿｯ

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

>>447

昔そういうの作ったよ。
だけど戦車がわらわらと出てきて壊せるだけ。自機は弾に当たっても何もなし。
しかもボスがなければ、タイトルもエンディングもない。道中でスクロールが止まって終了。
ゲームとしての形になってません。こんなのでよかったらアップしますけど、やってみますか？

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

プレイするより技術的な話したほうが良いんじゃないの

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

ギャラクシアン・ギャラガ・ギャプラスの敵の動きのアルゴリズムが
よくわからんです。自機の方によりつつもループ描いたりとか。

**名前は開発中のものです。** · 04/07/07 23:36

3つ並べて書いてるがそれぞれ大分違うぞ。

**名前は開発中のものです。** · 04/07/07 23:42

ギャラガの動きに感動したガイジンは結構多いらしい

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

>>456

そうだね。アップはやめておきます。

**名前は開発中のものです。** · 04/07/08 02:06

ソースをアップするのなら、技術的な話に繋げられると思うけどな。

**名前は開発中のものです。** · 04/07/08 15:40

>>459
あの滑らかな動きはテーブルでもってるのかね～？

**名前は開発中のものです。** · 04/07/08 16:54

>>462
当時、（参照）テーブルを一切用いずに済むような
（現実的な）実装方法があったのかを考察してみ。

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

いきなり敵が空中回転した時は心が躍った。

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

今では反省している。

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

テーブルでいいよ

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

ちゃぶ台でもいいよ。

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

>>463
アルゴリズム的に、自機と自座標から、加速量をパラメタとして変えてくとか。

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

道に沿って地上物が移動する、ての簡単にやる方法模索中。
エディタ自作せんと難しいかな。
ツクールとかのデータ流用できないものか。

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

>>468
例えば、そのパラメータとして渡す加速度は
行動パターン毎に1セット(圧縮データ)に
なっているとする。
すると行動パターン番号から参照するための
テーブルが必要になる。

**470** · 04/07/09 10:14

よく読んだら、プレイヤー座標と自座標を入力すると
加速度を出力するような関数（orロジック）を用意する
って話か。
　
参照テーブルを一切使わないってことは
敵キャラ1種につき関数1個といった粒度を想定しているのかな。
容量の肥大化はまず避けられないだろうが非現実的ではないな。
　
俺なら、ロジックの粒度を小さくして呼び出しのシーケンスを
テーブル化するような形に持って行くけどね。

**名前は開発中のものです。** · 04/07/09 10:32

>>469
透明オブジェクトとして線データをマップの上に置いといて、
それに沿って移動するような形はどうだ？
…この方法だとゼビウスみたいに分岐があった場合の処理がめんどうだな。

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

>>471
中身のありそうでなさそうなレスだね。

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

>>472
ああーなるほど。
透明オブジェクトに触れたら方向転換、でもいいかもね…。
やってみよ。

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

>>471
うん。たしかにテーブルの類を一切使わないという条件があると辛いですね。
敵キャラ加速度データのグラフは直線（矩形やノコギリや三角）を組み合わせた
不連続関数だったりするので、アルゴリズムでやるといっても中で条件分岐が
入りますね。連続関数に分解してテーブル化ってのは至極まっとうな選択だと思います。
　
加速度の制御だと円弧を表現しにくいので、動きパターンに応じた条件分岐も
出てくるでしょう。ここでもハードコーディングを避けるならテーブル使いますね。

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

>>472
マップチップでやるならラクができるよ。
自分のいるマップチップ番号を見て、三叉路や
交差点のマップチップ{┤,├, ┴, ┬, >- , -< , Ｙ ,人,┼,×}
ならば経路決定用の関数を呼び出す。

　　　　　　　　始点
　　　　　　　　　|＿＿
＿＿＿　　　／
　　　　＼.／
　　　　 │
　　 ──┼
　　　　｜
　　 ──┴─終点

上図の戦車の分岐シーケンスは
{右折、左折、直進、左折}
この2bitデータの配列を各戦車に
持たせるだけで済む。

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

パックマンと一緒か

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

>>476
あーそっか。マップが格子状に区切られてるから、自分のいる地形の
属性情報をBGテーブル経由で参照できたんだね。たしかに
マップチップだと色々と簡略化できるね。　
　
道路上の戦車の移動は逐次処理だけで済むってのは納得。
けっこう複雑だと思ってたんだけど、ちょっと考えすぎだった。

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

>>475
円弧や正弦曲線は、ゲームデータ用に
エクスポートする際には近似曲線に
変換するといいよ。特例扱いしなくて済む。

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

>>476
それだと戦車に与えるパターンが少なくなる代わりに、戦車が存在しうる背景パターンは
１０倍の数になるのでわ？
背景がベタな砂漠とかコンクリだけならなんとかなりそうだけど、自然な背景にしたいなら
マップエディットで力つきそうな気がする。

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

戦車が参照するマップと、表示用のマップが同じである
必要は無い。

マップ編集はちょっと面倒かも知れんけど。

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

>>480
話の発端はゼビウスとかマップエディタ流用の話なので
そういう無茶な突っ込みしないように。

　・マップチップ毎にアトリビュートを付加できない
　・マップチップをマルチテクスチャ化できない
　・マップを多層化（複数レイヤー化）できない

低機能マップエディタを使ってリアルな背景を
追求したいなら、相応の工夫をしましょう。

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

確かにそうだけど、実際やってるところあるのかな？
ちなみに漏れはオブジェクト出現テーブルに移動パターンとカウンタオフセットを与える方法で
やってたけど。
戦車ってそれほどハードにくねらないから30フレくらいの頻度でパターン構成してもそれなりにみえる
でも結局、停止->前進->停止の奴が一番多かったんだけど（ｗ

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

おっと被った
483は481へのレスです

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

>>482
道路パターンを地面に馴染ませるときは道路パターンを
アルファ付きテクスチャにして地面パターンにかぶせると
楽チンでいいな。
　
自然な描写を目指してくとマップエディタ自作にしたほうが
楽だと痛感した。

**ガルーダ週報** · 04/07/09 23:04

敵配置ツールは手付かずです。

その他のガルーダ仕様や基本的な処理（スコア、パワーアップ、アイテム効果等）は
一通り出来たので、後はボムの実装ぐらいです。

低レベル層の描画周りを見直してたら、致命的なミスを発見、
修正したら処理落ちが全くなくなりました。
（出現キャラ数は調べてませんが、アーケード版の後半ぐらいは出してる）

後はバランス調整、敵配置、ボス実装、最後に絵を直せば公開出来るんですが。
ボスの考案、絵を描くのが一番しんどい。
フィルタ掛けるとかじゃ不味いんですかね。細かい修正は色々してますが。

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

道路の上を進む戦車って移動はなんとなく分かったんだけど、
建物の中から出てくるときの敵の当たり判定はどうやるんだろう？
まだ建物の中にある部分は弾が当たっちゃいけないんだし・・・。
やっぱりチップで判定するのかな？

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

>>482
そうね。
絵的なクオリティを上げていくなら3Dカードの機能を活用しない手はないでしょ。
あとマップエディタ。最近は出来のいい汎用エディタがあるのかもしれんけど
俺が作ってたときはマップに深度値を付加したりマップを複数枚重ねられるような
エディタが見つからなかった。この手の機能が無いとマップ編集作業をやってく
うちに不満が炸裂する。
　
>>485
俺は、森林地帯を戦車が通り抜けるシーンを作るためだけにエディタ
自作しちまった香具師なので、むしろアフォの部類かもしれんけど
独自の拡張がどんどん出来るので、自作したほうが結果的に楽ってのは同感。

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

>>487
チップで判定してもいいし。チップのZ値で判定してもいいし。
戦車が何かの下にいれば弾に当たらなければいいということで。

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

マップチップの話だけど、
元のマップの画像は、巨大な一枚絵で描いて、
それを１６×１６とか適当な単位で分割して、チップをあとから作ればいいんじゃない？

**名前は開発中のものです。** · 04/07/10 00:15

>>490
>>338

**名前は開発中のものです。** · 04/07/10 00:40

HSPｽﾚからきますた。

･･･最も速いと思われる当り判定のアルゴリズムを
伝授して欲しいんですが･･･。
CPU500MhzのPCで動かせることを考えると
どうしても処理速度と格闘せにゃならんので･･･。

飛翔鮎が500MhzのPCで軽快に動いてるのが
不思議でたまらないんですが･･･。

**名前は開発中のものです。** · 04/07/10 00:50

>>492
条件次第で変わるから、もう少し限定した条件を出してもらえると答えやすいかも。

判定する物体の形状とか、数とか。
あと、ハードウェア的な制約もあれば。メモリ量も重要だね。

MSXならスプライト同士の接触で割り込みが、とか。

**492** · 04/07/10 00:50

すまそ、質問しといて説明不足だったんで補足

敵弾ｖｓ自機の判定は
HSPスレのほうで解決してきたんスけども、
自弾ｖｓ敵の判定で凄まじく重くなってしまって。
現在実装中の当り判定は

自弾の数だけループ(1)
　　自弾の移動
　　　　敵の数だけループ(2)
　　　　　　自弾ｖｓ敵の当り判定
　　　　ループ(2)終
ループ(1)終

ってなってます。
当り判定の基礎はコレで良いと思うんですが、
うちではコレをやると処理落ちしてしまうんスよ。
（程度の低いSTGしか出来ていないのに････）

**名前は開発中のものです。** · 04/07/10 00:51

本当に当り判定の問題？
敵一個の場合とｎ個の場合の速度比べてみ

**名前は開発中のものです。** · 04/07/10 00:58

５００ＭＨｚもあるならインタプリタでもその程度かなり余裕だろう
それ以外のところがおかしいと思われ

**492** · 04/07/10 01:05

>>495-496
うむぅ、一番処理食ってるのが
自弾ｖｓ敵のループと
敵弾ｖｓ自機の判定
だと思うんだけど、
やっぱ別のところで無駄してるんですかねぇ？
敵1コとｎコの場合、明日辺り試して見ますわぁ

**名前は開発中のものです。** · 04/07/10 01:28

まぁ、良くある方法としては、
敵や弾の移動時に、y座標単位のテーブルに登録しておいて、
自機と一定以上近い座標にあるものに対してのみ当たり判定を行うとか。

それ以前に、その重さは考えにくいから、
やっぱ当たり判定自体かループがおかしい気はするが。

**492** · 04/07/10 01:29

思いっきりＨＳＰのソースで申し訳ないんですが、
当り判定ルーチンにはこういう内容のものが詰まってます。
http://cgi.members.interq.or.jp/hiphop/youhama/up/source/yaguyasu0495.txt

**名前は開発中のものです。** · 04/07/10 05:42

>>499
この程度で遅くなるかなあ…。
描画じゃないの？回転とか使ってるし。
ビデオカードによってはそれだけで結構遅くなるよ。

**ガルーダ** · 04/07/10 06:53

>>499
コードよくわからんけど、
貫通弾じゃない限り、ヒットしたら敵のループから抜ける
というのがなさげだけど？
あったほうがいいと思う。俺も全然やってないけど。
それ以前に、タスクのリスト総舐めしてる。

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

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