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

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

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

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

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

■ 前スレ

シューティングゲーム製作技術総合
http://bbs.gamdev.org/test/read.cgi/gamedev/1056635103/

**名前は開発中のものです。** · 04/02/17 01:03

>>524
そうなりますたｗ

**名前は開発中のものです。** · 04/02/17 01:54

見栄えのする弾幕と長く遊べる弾幕とを両立できればベストだが、
入門には見栄え弾幕をやってみると良いと思うYO
それどまりなのはマズいけど、発表すればプレイヤーが厳しくツッコミ入れてくれるだろう

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

見栄えのする弾幕　＝　自機の現在位置に関係なく全方向囲に放射ってことかな？

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

>>527
たしかに、それは見栄えがするな。最初のオススメかも。

そこに他の敵からの自機狙いを混ぜるのが定番。
お手本の例は怒蜂2面後半の巨大戦車とザコの複合攻撃。

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

>>526
見栄え重視といえば東方～やね。
あの弾幕は打上げ花火みたいで好き。

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

ttp://ueno.cool.ne.jp/lsound/d0402.htm　の2/14
俺みたいなド素人には大変勉強になったが、一体何を指してたんだろうか。

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

ここまで細かく書かれてると、あっさり特定されそうだな。
とりあえず明らかに俺のゲームではない。

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

常識的なことが並べられてるだけな気がする。
ってか、そんなことすら出来てないのもあるのねぇ

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

これだから個人日記は嫌いなんだ…
読んでて不快

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

>>530
痛い電波の人晒しage

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

ウチのサークルのゲームでもないな

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

きちんと「こうするべきだ」ってのが提示されてるし
これで不快だって人は他人の言うこと一切聞かないタイプなんだろうな

まぁ、イチイチ日記に書くなんてリスク背負い込むのもアホだけど

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

>>536
きめつけはよくないぞ…
オレが嫌いなのは日記でこういう意見を言うまえに作者にいえよ、
不特定多数相手に愚痴いうなよ～、って点なのね。
書いてあることはほんと同意。

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

あら、ID変わってるな、533だ

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

>>537
すまん。
でも実際>>530みたいに勉強になったって奴もいるやん？必要悪みたいなもんかと
作者に伝えようという気はそもそも無いんだろうね

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

でも斜め移動を1/√2にするのが常識ってのはどうかと思うな
あれタルいから嫌い。

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

最初東方かと思った。

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

縦STGで前後と左右が1：1じゃないゲームもあるのにね。

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

>>540 8ビット時代の方ですか？

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

>>543
8ビット時代って何？

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

縦STGなら斜めが早いゲームは結構あると思う。
おそらく戦略として残しているんだと思う。

横STGで斜めが早いのはあまり見ないね。

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

>>542
ギャプラス以外になんかあったっけ？

**名前は開発中のものです。** · 04/02/17 15:24

少なくともセイブシューはそうだよ。斜めも考慮してない。

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

つーか、DOOMとか普通にサイドステップしながら前へ進むのがテクになってなかった？

**名前は開発中のものです。** · 04/02/17 15:29

>>546
ドラスピのニューバージョン

**549** · 04/02/17 15:38

旧バージョンも1:1じゃない気がしてきた。
確認できず。

**509** · 04/02/17 16:07

>>514
なるほどね。作るのはムズイ？
>>516
やってみます。

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

「作るのはムズイ？」ってのはどういうこと？
どの言語で作ろうとあまり変わらない気がするけど・・・

**名前は開発中のものです。** · 04/02/17 18:45

ダブルバッファリングは必須ですか?

**名前は開発中のものです。** · 04/02/17 18:47

Direct3Dの描画の話？
だとしたら最早必須な気がする。

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

DirectDrawでも事実上必須な気もするが

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

昔は必死になって差分描画とかやってたもんだよｗ

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

・・・といってもちらつき抑えるためには
ダブルバッファリングしないと駄目だったなあ
結局必須ってことで

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

ダブルバッファリングしない場合は、操作が遅延しないほうを優先した、と言い訳しよう
それでいて処理順序を間違えて遅延が出てたりするとボロクソに叩かれるわけだが

**509** · 04/02/17 22:00

あーそうなんだ。どもです。
とりあえず弾幕いじってみるわ。

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

どちらかといえば
ちらつき抑止のほうが重要だわな。目立つから。
操作遅延は一部の人間しか意識できん。

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

今話題にしているちらつきはこれのことかな
http://www.google.com/search?num=100&hl=ja&ie=Shift_JIS&newwindow=1&q=%83e%83B%83A%83%8A%83%93%83O%81@%82%BF%82%E7%82%C2%82%AB&lr=lang_ja
ウィンドウモードのときはどうやって対策するんだろ

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

COPY_VSYNCとかだと大丈夫じゃなかった？
知らんけど

**名前は開発中のものです。** · 04/02/18 01:30

俺はＶＢからＶＣ移行組だけど、しょうじきＶＣで作ったやつ全部ＶＢで作れる。（速度も含めて）
ていうか、ＶＢの実行速度に不満があるならそれを力技を駆使してなんとかするのが面白いと思うのだが。
その傑作が（仮）だと思うし。俺がＶＢで初シュー作ったのが（仮）が出た頃とダブルから
そう感じるのかもしれないけど。そのころＶＢはＤｉｒｅｃｔＸ使えなかったしな。

まぁ今のすんごいＰＣならＶＢとＶＣの違いって気分でしかないよ。

**名前は開発中のものです。** · 04/02/18 01:37

VBだとキャラクタの管理とか厳しくないですか？
キャラクタを基礎クラスから継承しまくってるスタイルに慣れきってるためか、
JAVAですら面倒に感じるときがあります。
もう駄目だ_|￣|○

**名前は開発中のものです。** · 04/02/18 01:45

JAVAの方が継承とからくだとおもうんだが？
シューティングなんて雑魚キャラとか継承しまくりなのが普通だからな

JAVAもフルスクリーンや解像度変更、VSYNCフリップとか
ＶＲＡＭ直書きとかふつうにあるから
２Ｄゲームにはまず何の問題もない

２００ＭＨｚクラスじゃ厳しいが４００ＭＨｚあればそこそこ問題なしで
６００ＭＨｚあればだいたい大丈夫

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

JAVAだとクラスの多重継承できないですし。
まあインタフェイスクラス使えばいいんですが、
一貫性のある記述のできるC++のほうがどうしても楽に感じてしまうという事で・・・。

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

クラスや継承を知ってたほうが楽だが、
まあ知らなくても作れるしな

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

そんなこといってると、みんな俺みたいにC言語で開発できなくなるぞ
組み込み系やりたくなくなるから注意しろ！

>>561
ウインドウモードでは無理
と結論した

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

>>561
D3DPRESENT_INTERVAL_ONE

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

C++に毒されたのでもうC言語ではつくれないな。。。
遊ぶ側にとってはVBとVCの違いって気分でしかないかもしれないが、
つくる側にとってはぜんぜん違う。

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

遊ぶ側にとっては何も違いは無いだろう

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

>>571
同意。
その作品が「ゲーム」と名乗る以上、価値基準は「面白いか否か」だからなあ。
使われてる言語がどうこうってのは、語りたい人同士で語ればいいだけのウンチク話になる。

ゲームのように見えるが実は自分のプログラムテクニックを披露したいだけの
環境ソフトなんです、って言うんなら話は別だが。

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

ここ製作技術スレですよ。ウンチクを語る場でもあるわけで。

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

いや、中には「ＶＢで作ってるくせにシェアウェアにするなんて生意気だ！」
なんて言い出すグルメもいるわけで（ｗ

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

>>574
そういうこと言う奴は作ってる側の人間だろうな。

**名前は開発中のものです。** · 04/02/20 01:30

大体遊ぶ専門の人は、ほとんどがVBとかVCの区別なんてつかないだろ

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

つかんだろうね。
そもそも俺も何で書かれてるかなんて興味ない。

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

ttp://www.n2de.com/la/
Flashで弾幕系作ってる奴居るんだな。
ソースも落とせた。

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

作ってる側のコメントとしては、HSPやVBで作ってても
VC++製品を遥かに凌駕する面白さの作品が存在してるね、というくらいしかないな
いまやどんなスタイルでゲーム作っても 60FPS+DirectX を満たせるし

**名前は開発中のものです。** · 04/02/20 12:34

HSPやVBのすごいシューティングって見たことがないんだけど。

2Dシュー程度ならできることに大差はないとはいえ、
C++プログラマとの技量の差が、そのままゲームの出来にも反映してるように思えてならん。
因果関係ではなく相関関係だけどな。

つーことで、俺の偏見を覆すスゲーシューがあったら教えてたもれ。

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

VBでも面白ければシェアウェアで良いと思うけど・・・
「VBのくせに生意気」は精神的にガキなんだろ。
プロでそんながヤツ居たらアホ。

でも俺も>>580と同じく

**名前は開発中のものです。** · 04/02/20 13:37

>>580
月姫の城。面白いかはおいといて、
これをHSPでつくったというのだからすごい。
C++、Delphi等でつくっていたならすごいとは思わなかっただろう。

まあ、VB、HSPは中規模以上のゲーム製作は苦労しそう。
シーンが増えてきたときの管理方法はどうやるの。
全部if、selectでわけるのは面倒では。

あと、VB、HSPでつくっている人って敵の動きからステージデータまで
全部ソースに直書きしている気がする。そのつくり方だといづれ限界が見えてくるよ。
スクリプトデータに分離しようにも、VB、HSPでは字句解析、構文解析を行えないのでは。

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

遊んでて楽しく、長く遊べるのは飛翔鮎、ガンデモニウム、D-Force、D-Force2、
STARSHIP FIGHT、HSPじゃないけどやる気無シューあたりかな。
凝った演出ならサイヴァリアみたいな奴があったな。名前忘れたけど。
相関関係については同意。
因果関係が無いと言いたかっただけだしな。必要条件でも十分条件でもない。

**名前は開発中のものです。** · 04/02/20 18:33

>>582
テキストファイルから文字型配列変数に読み込んでnotepad命令群とかを使えば
できないことはない。
大きくなるほど管理が大変になるのは直書きと一緒だけど。

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

>>582
HSPでスクリプト動かすように書くと
HSP自体がスクリプト言語だから
スクリプトでスクリプトを動かすという妙なことにならないか？ｗ

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

妙でも何でも無いし、必要で有ればそういう手段をとるってだけの話じゃ？

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

HSPエンジンがオープンソースでなおかつX11ライセンスのような
配布形態ならば妙な話ではないな。

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

メモリノートパッドって、データでかいと無視できないくらい遅くなるから
あまりお勧めできない。

**名前は開発中のものです。** · 04/02/21 12:45

>>580
　単純にユーザー数の違いだと思うけど。
C++を使っている人が多いから自然と良いゲームも増えるんじゃないかな。
俺の検索が足らないのかもしれないが、Delphiで作られた凄いシューティングって
聞いたことが無い。
　知ってたら誰か教えてくれ。

**名前は開発中のものです。** · 04/02/21 12:57

>>589
CreatureJungleはDel。
凄いかどうかは知らん。

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

初期クドリャフカもDelphiだったはず。CJともども、遊んで面白いゲームだ。

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

同人のブルーセイバーズと続編のOOHはLGP製だったな。
とりあえず完成度が高いといえる作品だと思う。
LGP自体マイナーでこの板では評判云々以前みたいだけど。

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

OOH、LGPだったのか。あそこまでの作品が作れるなら十分実用言語だな。
BASIC風でなくC言語風だったら今すぐ試してたかも。そのうち試してみるかな…。

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

Delphiはネイティブコンパイラだし、C++とポテンシャルは同じ。
単にC++を使っている人が多いだけ。
DelphiはコンパイルがC++とは比較にならないくらい高速だし悪い部分は特にない。
遜色があるのってtempleteがないくらいでは。

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

DelphiやBCBはわるくないんだが
DirectXまわりで多少苦労する

それだけできついと思うか問題ないレベルと感じるか

どっちにしろ言語なんてよほどへぼくないかぎり問題じゃねー

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

>>592-593
LGPは機能面、パフォーマンスもかなりいいと思うんだけど
コンパイラの安定性に不安面が多い
一時期導入しようと試してたんだけど
コンパイル段階で例外処理出ることが多くて断念した。
その辺りを回避できれば、かなりいいと思うよ

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

>>589
既出のとおりDelphiはDirectXとは相性が悪い。
Delphi使えるようなプログラマならたいていC++も使えるから、当然C++を選ぶさ。

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

プログラムから絵まで一人で作っている人にお尋ねします。

ゲームで使用する『絵』は作業行程の中でいつ描いていますか？

例えば敵を１体作るとき、ゲームで使う絵をしっかりと描いてからプログラムを組んでいますか？
それとも、とりあえず▲○など適当に絵を用意してプログラムを組んでいます？

▲○などの仮絵を使ってプログラムを組んでいた人は、いつゲームで使用する絵を描き始めますか？
敵を１体作ってから？それともゲームをしてある程度できてからですか？

返信お願いします。

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

×　ゲームをしてある程度
○　ゲームとしてある程度

訂正です。

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

最初は適当な立方体メッシュで作ってました。
グラフィック作り始めるときは気分。プログラムに疲れたらとか。
どうせ使いまわしするのでそんなに量は要りませんでした。

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

自機と敵弾はかなり早い段階で用意しておいたほうがやる気が湧くなぁ。
あとは逐次敵移動パターンを考えた後でデザイン、又は敵をデザインした後、
その形から連想させる移動パターンをインプリメント。

**598** · 04/02/22 12:52

うほ。返信ありがとう。

そうか、自機だけでも用意しておこうかな。
だけど、絵を描き始めると、描いては消しての繰り返しで全然進まない。

絵が描けない人は、下手でも割り切った方がいいのかな。

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

私は絵は先に用意します。
絵に時間がかかるので、先にやらないとプログラムに触らない期間が長くなって
忘れてしまいそうなので…ｗ。

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

適当にやってる。
モデリングする気分だったらモデリングして、
プログラムする気分だったらプログラムという感じに。

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

>>602
絵は事前に用意できる限り用意しといたほうがいいと思うなぁ。イメージを固めやすい。
ただ、いずれにせよ後から手を加えることになるのは確実なので
なるべく後付けできるようにしておく準備は必要。
下手でも割り切ったほうがいいというか、割り切らないと完成はしないと思う。

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

絵が上手いとか下手とか関係なく割り切りは必要だと思う

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

おもろけりゃABAさんとこみたいなのや、爆烈矩形弾みたいなのでも可。

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

時間によって変化する敵の動作ルーチンを上手く書けないよ…
動きﾊﾟﾀｰﾝ分全て関数書くのﾏﾝﾄﾞｸｾ

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

ハードコーディングで敵キャラ書く場合、
int mode;
int time;
switch
キーワードはこの3つ。
これだけ分かってて上手く書けないと言っているなら、
そうなるとスクリプトでも実装するくらいしかないかな。

2Dシューティング製作で一番時間食うのは敵キャラの行動の実装だと思う

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

敵キャラ行動はツール使っちゃってるからそんなにはかからないなー。
やっぱ絵に時間かかる。

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

動きﾊﾟﾀｰﾝが増えたり、キャラの種類が増えたりすると、なかなか大変だよな。

このスレで紹介されているページのいくつかに、
ハードコーディングによる敵動作ルーチンがあったはず。
見やすく、それでいてﾏﾝﾄﾞｸｻくならない記述の参考になるかも知れない。

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

現在画像の回転のアルゴリズムでつまっています。
正攻法でやると回転後の画像に穴があくので、
逆の、ここの画素は、あそこからのものだ。
という方法で考えています。
ですが、この逆に導けばいいと分かったまではいいのですが、
どうやって導けばいいのか、式、法則が分かりません。
アドバイスいただけないでしょうか？

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

その回転行列の逆行列を使えば元の画像の位置が分かります。
画像の位置を割り出したら、最近傍点か、近傍4点の線形補完から色を取得しましょう。
D3DFILTER_POINTとかLINEARとかと同じことです。
つまりその考え方って3Dなんかでポリゴン描画するときと一緒なんですね。

**名前は開発中のものです。** · 04/02/23 16:38

ttp://www.sm.rim.or.jp/~shishido/kaiten.html

**名前は開発中のものです。** · 04/02/23 16:56

>>614
途中の式が知りたいのです。
なぜ、この式になったのかどうかです。
わがままですいません。
行列は習ってないのです・・・

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

>>612
アフィン変換

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

ttp://www3.omn.ne.jp/~renas/3D/TransProcession.htm

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

行列習ってないってことなら方程式で説明ね。
ソースからディスティネーションを求める式は知ってるようですが
dest_x = cos(a)*src_x + sin(b)*src_y
dest_y = -sin(a)*src_x + cos(b)*src_y
この連立方程式をsrc_xとsrc_yについて解けばよいのです。
そうすればdest_xとdest_yからsrc_xとsrc_yが求まります。

逆行列を求めるってのはそれと同じ話です。
式の見た目が変わっても所詮行列なんて同じことやってますので。

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

数学の基礎からやり直します。
ありがとうございました。

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

ここは勉強になるインターネットですね。
今まで調べ方がヘタでわかんなかったんだけど、>>613-618でわかった気がします。

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

転送元→角度a回転→転送先，が分かるなら。
転送先→角度-a回転→転送元，で分かるハズ。

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

ゲームプログラミング練習長を買いました。

この本でのキャラクタの描き方は、for文で透過部分以外の色を
（背景をコピーしたバックバッファの）アドレスに書き写すというやり方なのですが、これって普通ですか？

バックバッファをDCで持ってBitBltのANDとXOR（だっけ）でやるのが一般的＆簡単だと思ってたのですが。

**612** · 04/02/24 18:29

おかげさまで無事回転させることに成功しました。
今ではなんでも回ってます。
今の僕に回せないものはありません。
どうもありがとうございました。

**612** · 04/02/24 18:56

>>622
>バックバッファをDCで持って
というのが何を意味するかわかりませんが、
ゲームには画面の書き換えが必要です。
画面の書き換えには時間が必要です。
この書き換えの時間が長いと、描いている途中の画像がユーザーに見えてしまって、
気持ちよくありません。
ホラーゲームなどで、「わっ」とおどろかせるところで、途中の書き換えている
シーンが見えてしまってはだいなしです。

なので、たいていのゲームでは、いったん裏の画面に次の画面を
すべて描き込んでから、あたかも切り替えているかのように、
表の画面に一気にコピーします。
まとめていっかつコピーの方が処理が早いので、このやり方が
よく使われています。

また、別の理由でもこのいったん別に裏の画像をつくって
ここで、絵の具を混ぜるかのように、コネコネして・・・という利用方法もあります。
まだ、納得できないのであれば、ご自身のやり方でやっていけば
よいかと思います。

普通かどうかは知りません。基準がありません。

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

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