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

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

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

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

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

■ 前スレ

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

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

いろんな方法があるよな

俺は効率の追及以前に、自分にとっては高度すぎる配置と動きを組もうとして挫折したことがある
いまはやれる範囲でいろいろやってるので、時間がかかっても結果は出せてる
少しずつ高度なこともやれるようになってきた

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

>>135
道中が長いと面後半の調整は大変ですな。
昔作ったシューティングでは途中を飛ばす機能を入れておいた。
単に無敵にして目的の場所まで画面を表示しないようにしただけだけど。（ｗ
当時は画面表示が占める処理が大きかったので結構使えた。

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

俺が作ってるタイプは、やっぱり今でも画面表示の占める処理がほぼ全部だぜ
表示しないモード、描画同期待ちしないモードの切り替えはいろいろ役立つな

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

敵出現用のマップエディタは便利

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

敵動かすのって、敵テーブルに種別と座標、耐久力、弾に関係するフラグやカウンタ、動きに関係するフラグやカウンタを持っておいて、
色んな角度に直進する動きだけ書いた敵動作関数にインデックス渡して、種類と動作関係フラグ毎に角度と速度決めて動かせばいいんでしょ？

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

＞色んな角度に直進する動きだけ書いた敵動作関数
気が向いたら曲線も入れてやれ

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

>>141
曲線なんていつ使うの？
1フレ毎に角度変えればいいだけじゃん。

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

>>142
データが小さくできるから変更が楽ですよ？

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

CatmullRomとかで通過点指定するだけで滑らかな動きが実現できるんだから使わない手は無い

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

へぇー。
便利な関数があるってわけだ。

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

特殊な動きをさせるのでない限り、スプラインとかそういう奴でパスを作って
それをなぞらせるだけのほうが開発効率いいかなぁとか最近ｵﾓﾀ

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

敵出現のタイミングも一考ものだな
毎フレーム、敵テーブルや敵配置マップから情報を読み取って、淡々と出現させるものと
一度にある一定数を出現させた後、プレイヤーが全部を倒すか、画面から消えるかすると
改めて、また一定数の敵を出現させる物
アーケードでは前者は怒首領蜂大往生、後者は式神１が当てはまるな

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

>>140 敵は与えられたルートに従って動くだけならこれで良いかも。
敵が自分で判断して挙動を変えたりとかはしないの？

**名前は開発中のものです。** · 04/01/29 13:40

>>147
後者の代表例はゼビウス、スターフォース、ザナックあたりかな
出現時刻がアナログに変化するところが前者との大きな違いだ

前者のほうが確実に組めるので調整はしやすいが、
後者にもいろいろと可能性がありそう

**名前は開発中のものです。** · 04/01/29 13:48

ZANACは早回しとか入ってないよ。

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

テキトウ言っちまった。スマン。
ZANACは敵消滅が次の敵のトリガになるわけじゃなかったね(キャラオーバー時のぞく)。
武器を取った瞬間にテーブルが変わって新しい敵が出る(ことがある)ので、それとごっちゃに語ってた。

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

戦車とか砲台を地形にシンクロさせるためには出現時刻の細かな調整が欠かせない。
しかし地形を意識しなくなると途端に作業が楽になるな。

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

地形とのシンクロをしっかりやってるのって
同人とかだと少なくない？

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

大往生の1面中ボス後の中型機とかは、
時刻じゃなくてスクロールに同期してるよな

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

>>153
最近は美しい弾を多く出すことが重要なんで、近代～近未来的な重厚なメカは流行らないからではないかな？
俺はＧストリームのキャラに感動してたけど。（ｗ

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

漏れは激しく戦車が好きだ

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

今、ボタンを押すと自機の少し右斜めに爆弾が表示されてずっとそこから動かず
敵と触れると爆発するという罠みたいな武器を作っているんだけど
爆弾が一個の時はうまく爆発アニメーションもしていけたのに
爆弾を5個にしたらなぜか爆発アニメーションもせず、その座標にずーっと
表示され当たり判定も全然触れてない敵と当たっているし・・・
ﾓｳ頭ｶﾞ大混乱・・・

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

がんがれ。ときには一歩戻ることも大事だ。1個に戻すとか。
当たり判定表示モードを用意する手もある

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

>>157
確実に変数がかぶってるでしょ。
構造体にフラグ持たせて、爆弾一個一個ごとにフラグもカウンタも持たせればいい。

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

>>157
いいなぁ。。。俺もそんな時期があった。。。
あのころにはもうもどれない

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

>>160
なーに、ちょっと記憶喪失になればスグだ

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

C/C++でシューティングゲームを作ろうと思い立ったけれど自機・敵機などのオブジェクトの管理法や
当たり判定などごく基礎的なことからわからず調べている始末…
みなさんこういう入り口ってどこから学びました？

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

まず、アクションゲーム作り慣れしよう

webでの情報は…なかなか有用なものは無いんだよね

atanだけ知ってれば弾は吐けるから、そこをスタートにしてみるとか

アマチュアが作ったもので技術的に参考になりそうな作品を
ひととおりチェックしてみるといい
ソースを付けていたり、サイトでプログラム系コンテンツを展開していたりするものもある

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

あい、週末にいろいろ思いついたことを実際に組んでみて実験したりして
慣れようと思います。
ソース付きのサンプルは探しているけれどなかなか見つからず…
あとは本も探してみるかな。
みなさんが参考にしたサイトや書籍などを教えていただけたらうれしいです。

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

まずは、ソースを見ること、ソースを読むことかな。
漏れはBASICからスタートして、BASICで一応STGと呼べるものを
作ってからWindowsに来たから、何ともいえないけどね。

まだ起きてるなら、
参考になれそうに無いサンプルでよければ上げるよ。

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

>>165
162じゃないけどサンプル(　ﾟдﾟ)ﾎｽｨ…

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

そういえばここのスレはそういった情報はあまり見ない気がするな

ttp://giggle.cside6.com/hotate/shoot/frame.htm
発見
関数ポインタのリスト、と言われてわかるならオススメ

一年前にこのサイトを見てもほとんど理解できなかったろうなあ…
今でもソースすいすい読めるとはいかないが

**165** · 04/01/30 02:48

|ﾟωﾟ)ノ ttp://gamdev.org/up/img/215.lzh

>>167を見て
|Д｀))) うわぁ、漏れのコード(ry
|)三　　ｻｯ

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

>>168
㌧ｸｽ
キャラの管理にクラスは使ってないのね。
漏れはいつもクラス設計で迷ってなかなか先に進まない…ｱﾌｫか＿|￣|○

**165** · 04/01/30 03:05

>>169
なんてゆーか、動的メモリ恐怖症なんです(((´Д｀;;)))
今、このシステムをベースにしてゲーム作ってるんですが、
やっぱりクラスを使わないとできることが限られてしまうワケで。

次回作にはちゃんとクラスで実装して、
もう少しいろいろできるコアを作ろうと思ってます。

|Д｀)。o (newしてdeleteするだけなのに出来ないチキンな漏れ…。

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

コンパクトで可読性高くて、助かります。勉強させていただきました
gamdevうｐろだを使う手があるのかーそーなのかー

**162** · 04/01/30 07:28

おはようございます。

>>165
うわー、ありがとうございます。これから穴があくほどじっくり読ませてもらいます。

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

newもdeleteも基底クラスでメモリ管理クラス作っちゃえばよし。
こいつらの関数は派生するからサブクラス側でも使える。
固定サイズの作業領域を用意するなどのことは簡単

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

シューティング作ろうと思ってシューティングツクール95導入しようかと考えたんだが･･･
だめぽ･･･＿|￣|○

参考サイトとかそこらにあるゲーム見て回ったんだが･･･
弾幕作れない(最大敵弾数が低い)上に妙に重い･･･

おとなしく他のもの使おうと思います･･･

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

VC++使え

老人 · 04/01/30 11:15

最近はVBやC++から入門した人が多いみたいだけど、みんな授業でやってるから？

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

>>170
＞なんてゆーか、動的メモリ恐怖症なんです(((´Д｀;;)))

つか、ゲームループ中での動的確保は流石にやらないのが普通では？
例えばタイトル->ゲーム本編->ゲームオーバー処理みたいに状態が大きく偏移するときならまだしも、
ゲーム本編のループ内で１キャラ出したり消したりする度に一々new/deleteなんてやらんでしょ

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

遅かったらあとでoperator new/delete書けばいいやーなどと思いつつ
まだ書いたこと無いな

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

俺もフリーのソフト何本か作ってて
デフォのnew/delete使ってたんだけど
困ることってなかったけどね

今作ってる奴はそういうオブジェクトの基底クラスのnew/deleteを書き換えてるけど
そもそも開発環境のPC性能が圧倒的だから全然変わった気がしない

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

>>177
オレは一々動的確保してます。
むしろ、動的確保しないで立ち回る方法がわからん・・・

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

うぷろだがあるなら
途中で飽きてほったらかしにしてあるのでもあげてみるか。
C++でいろいろと無駄なことをやって分かりづらいと思うけど。
ttp://gamdev.org/up/img/216.lzh

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

作るのを途中で飽きないで最後まで完成させるための技術を教えてください。

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

>>167
なんとも古典的な内容のサイトだなあ。
今から始めるのなら参考にしないほうがいいよ。てゆーかするな。
こっちの「オブジェクト指向風シューティングゲーム」とかのほうが今風で役に立つと思う。
http://www.sm.rim.or.jp/~shishido/gamedev.html

あと、OOスレとかいろんなとこで話題になってるけど、
new/deleteは今のハードなら忌避する必要ありまへん。俺は16ビット時代に捨てたし。

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

>>182
・完成までの工程を計画する。
・開発日誌をつける。
・ToDoリストを作る。

これだけでだいぶ違う。

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

最も重要なのは「仲間と喧嘩しない」かな
喧嘩してもいいけど引きずるとアウト

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

>>183のは短いコードでオブジェクト管理を学べて良いね
時間管理の不備がツッコミどころかな…
まあこれを読める人ならそれくらいは自力でなんとかできるかな

>>167は、古典的タスク管理以外はじゅうぶん真似すべき
プログラムはともかく、シューティングづくりの基礎がつまっている

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

>>183
adjest
予想されるキーワード： adjust

ちょっと気になった。

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

>>167はどちらかというと将来エンジニアになりたい人には向いてる。
マイクロチップを自在にプログラムできる技術は重宝するよ

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

悪い技術ってわけじゃないからな。
C++でやることをCでやったらこうなりました、って感じかのうｗ
完全移植するならvfテーブル使えってことにはなるけどな。
あれに無理に固執する必要は無いってだけで考え方は大切だと思うー

確かスーパーマリオとか既にああいう感じで作られてたと聞いたことあるけどそうなのかな？
だとしたら任天堂ってすげーなー。ｗ

**名前は開発中のものです。** · 04/01/31 01:38

わしはクラスとか使わないで
配列だけでゲーム作ってるけど・・・

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

ﾅｶｰﾏﾊｹｰﾝ

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

>>190-191
例えば、あるキャラのみで使う必要な変数が増えたらどうすんの？
固定長だとキャラ(=タスク？)共通の汎用のワークエリアみたいなのを増やすわけですか？
で、1キャラで大きな容量のメモリ領域を使いたいときは、
無駄にワークエリアを増やすのは無駄だから、
他のところで確保したメモリへのポインタを指すだけにするわけ？

あ、なんだか出来そうな気がしてきた・・・

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

最低限のパラメータで様々なバリエーションの動きをプログラムできるセンスを磨く必要があるな。
もう少しシューティングを研究してみたらいいと思う

**190** · 04/01/31 12:07

>>192
とりあえず、ハードの容量にも寄るけど1タスクで64バイトくらいあれば
ゲームのキャラは動かせるので、それをゲームで使いそうな分を実行時に確保。
よっぽど足りない時は2タスク分確保してそっちも使う。
使ったこと無いけど。
自機弾なんて凝らなければ、座標と移動値か向きとタイマーと耐久力くらいがあればいい訳だから、弾は16バイトもあれば十分かな。

04/01/31 18:06

>>167のサイト実行ファイルが無いのは不親切だな。

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

>>131の者なんですが、スクリプト化っていうのは

７８９
４敵６
１２３

数字が敵の動きとして

static int e_houkou[]={1,2,3,4,8,7,9};
e_flg=0;
int ex=100,ey=100;
int e_cnt;

～(省略)～

if(e_flg==1){

switch(e_houkou[e_cnt]){
case 1: ex-=10; ey+=10; break;
case 2: ey+=10; break;
case 3: ex+=10; ey+=10; break;
～（省略)～

という風にして配列に数値を最初に入れておいてその数値によって敵の動きを移動方向を決めれば
良いと言う事ですか?。
どのタイミングで敵の移動方向を出せば良いのだろう・・・＿|￣|○

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

ディレイカウンタを一個作る

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

スクリプト化ってのは、敵のパターンなんかを
C言語でそのまま記述するのではなくて、
もっと簡単に動きを記述できる中間言語を用いることだよ

**168** · 04/02/01 11:34

>>196
スクリプト化は>>198さんが言ってる通りのこと。
スクリプト化する利点は、本体のコードを修正せずに変更できること。
(コンパイル不要。他人の協力を得やすいこと)
欠点は、処理速度の低下、本体のコードの複雑化など。

>>196のコードでe_houkouをファイルから読み出して使うようにすれば
一応スクリプト化は出来てると言えるんじゃないかな、とは思うけれども、
その言語仕様では柔軟性が無い。(敵弾は吐けないし、曲線を描く行動も、
自機追尾もできない。)
だから、といって十分柔軟な仕様のスクリプトを実装しろ、というわけでは
なく、目的に合った方法を使えということ。

敵行動に関して、漏れは以下のパターンでやってる。
実物は>>168に。

if(enemy.type[t] == EN_ENEMY1)MoveEnemy(t);

// >>131のカクッと折れる敵の行動
void MoveEnemy(t){
enemy[t].timer++;
if(enemy[t].timer < 120){
enemy[t].x -= 4;
}else{
enemy[t].y += 4;
enemy[t].x -= 4;
}

各敵にtypeとtimerを記憶させておいて、
それに応じて行動させている。

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

＞その言語仕様では柔軟性が無い。(敵弾は吐けないし、曲線を描く行動も、
＞自機追尾もできない。)

文字列にしてa～ｚにもコマンドを割り振ったりなんかしたりして。

いや言ってみただけ言ってみただけ

**168** · 04/02/01 15:26

>>200
その考え方で正解だよ。

ただ、コマンド数を延々増やしてると、そのうち自分でも
ごっちゃになる。すると、それなりの言語設計をしたり、
パーサー(構文解析)を作ったりする必要が出てくる。
本来の作業に加えてね。

しかし、それを実装したところで、ゲームが面白くなるとは
限らない。そもそも、プレーヤーはゲームの中を見ることが
ない。

まぁ、利点欠点を考えて適材適所ってことなんですが。

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

>>201
スクリプトに限らず、仕様ばっか凝り出してゲームが進まないってのは良くある罠だよね

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

二度ほどそれで臍を噛んでるYO
なので今回はスクラッチとダウンサイジングと仕様削減を合言葉に作ってる

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

GAっぽいの使ってホーミングレーザー育成STGでも作ろうかな。

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

言語仕様がさっぱりどっきり手探りな人はRobocodeやるとｲｲ!!
弾回避や予測射撃の知識も身につくYO！
いや、はじめからSTG向けのスクリプトを弄れ！という指摘もあるだろうけど :P

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

＞なので今回はスクラッチとダウンサイジングと仕様削減を合言葉に作ってる
というか、きっちりしようを決めて作るべし。

仕様を凝る(＝拡張可能な柔軟なつくりばかり追求する)って、実は
一番重要な部分を先送りしてるだけなんだよね。
オレはやっと最近それに気づいたヘタレ…完成しないわけだよ…

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

作る課程を楽しむのも由

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

全方向シューティング作ってて、64方位のうち0～15方位まで画像用意して、
あとは90度回転で済ませたいんですが、画像を回転させてコピーする(Bitbltみたいに)APIってないですか？
開発環境はBCC5.5で32APIゴリ書きです。

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

0方位だけであとは起動時に微回転させてビデオRAMに持たせておくのもいいかもな
ディザかけるなどの処理が無くてもよいバトルガレッガ程度の画質の回転ライブラリ、欲しいね

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

無くて結局自力描画になるからD3Dを進める訳なんですが。

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

素直にポリゴンで出せって。何時の時代に生きてんの？

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

http://www.talula.demon.co.uk/allegro/
一応こういう有名なゲーム用ライブラリがあるけど。回転拡縮スプライトあるにょ。
ただしAPIを見ても分かるとおり、かなり古風な作り。（DOS時代からのものだしな）

まあ、素直にDirect3D使うのが一番素直でしょう。

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

ってちょっと日本語壊れてるな、俺。徹夜なんでゆるして。

**208** · 04/02/02 11:32

なるほど。
色々とご意見ありがとうございます。
まあ時代遅れなのはわかってるんですが、winプログラム覚えたてなもんで…
いずれはDirectXに移植したいんですけどね～

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

BCC5.5ならDirectX導入に問題はないな
DirectX導入による保守性の低下が懸念なら、
回転オブジェクトの描画をきっぱり諦める。
または何か適切なラッパライブラリを使い、
コーディングの幅が狭くなるかわりに見通し良い状態にする。
のがいいんじゃないだろうか。
ラッパライブラリで何が適しているかはわからないけど。elとかdxlibとかは有名だね

**208** · 04/02/02 15:00

了解です。調べてきます～

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

他人の書いたラッパを理解するより自分で書いたほうが手っ取り早かったりするんだよな（ｗ

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

BCCとかだとD3DXライブラリ(D3DXSpriteもこの中)が直接使えないから
注意が必要だ(デバッグ版はDLLになってるのでそのまま使えるけど)。
いや、D3DX使わないなら関係ないけどね。

**208** · 04/02/02 19:35

>>218
そうなんですか…やっぱBCCでDirectXは険しい道のりなんですね～
さっき本屋にも逝ったけどVC関連ばっかりで…
「VCの機能を最大限に生かしたプログラム」しなくてええっちゅーねん。

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

そんな時こそOpenGL

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

ABA gamesのシューティングはBCC+OpenGLだな

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

>>221
ABA Gamesのは(少なくともrRとかは)BCCじゃなくてMinGWな気が。

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

rRootageもPARSEC47もOpenGLを使ってはいるな
あとのC++とかDとかはおいといて

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

敵を動かすのは良いけど
複数の敵を一つのグループで動かす場合は
どうすればいいのかわからない＿|￣|○

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

>>224
編隊のこと？
俺は、編隊も１匹も同じで敵キャラの出現タイミングと出現場所を書いたデータファイルを
作成してステージのはじめに読み込むようにしてた。
これが正しいかわからんけど。

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

>>224
変態タスクを作って雑魚タスクを管理。

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

>>225のように、それぞれはバラバラでも、同じ法則で動いていれば、
結果的に群れてるようにも見える。大往生4面雑魚とかはそんな感じだろう。

一方、グラディウスで雑魚が全滅したときにアイテムが出るが、これは
複数の敵をグループとして管理すると実現しやすい。
グループリーダー(実体はなく、アイテムを出すだけの役割)に
一匹一匹が「やられましたー」と報告して、最後の一匹がやられたらアイテムを出す。
リストで管理して削除していくのが一般的かな。

いきなり複数のグループを扱おうとする前に
まずは単純に画面内の敵すべてを1グループとして
敵全滅判断の処理を組んでみると、わかりやすくていいかもよ。

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

そういや回転といえば、ケイブのやつとかはちゃんと光源の方向を考慮した回転
パターンを用意してない？
達人とかビッグコアみたいに真上（真横）から光を当てたような、真ん中が明るく
エッジが暗い左右対称なデザインだと、回しても違和感が無いけど、今となっては
ＰＣ猿人のゲームみたいで貧乏臭く感じるんだけど。

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

>>228
3Dでモデル化したやつから2D画を起こしてるんじゃなかたっけ？
手法は違えど角度毎に別な画を全て用意するというのは古典的（かつ効果的）な手法だよな

よく2D絵を回す為にD3Dで2D絵を回転とか言うﾔｼ見かけるが、あらゆる意味でセンス無えと思う

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

ケイブはプリレンダですな

> D3Dで2D絵回転
プログラマ的視点から言えば正常じゃねーの？
うちでも、立体感ない回転させた日には、ドッタさんが腹立てて
「回転パターン書く！」とか言い出します。

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

バトルガレッガだってD3Dで2D回転させるのと大差無い絵でしょ
素人作品はむしろモデリングやドット絵がボトルネックになっているもののほうが多い

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

プログラム的に回すとしたらレイフォースのレーザーみたいな奴だろうね。
まぁポリゴンならプログラムで回せて光源も正しく処理されるわけだが

**208** · 04/02/03 22:09

とりあえず今は64枚全部書いて一通り完成まで持ってきます(^^;)
色々調べたら、OpenGLはLinux上でも動くっぽいのでどうせVC++を持ってないならOpenGLにしようかなとも考えてます。
まだ大分先のことになりそうですけどね…

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

シューティングゲーム（仮）だっけ？フリーのやつ。
あれなんか、WAVの爆発音を重ねるのが重くなるからか、
「どかーん」というWAVと「どかどかーん」というWAVを用意して
複数の敵を倒したときは「どかどかーん」を鳴らしてる。

けっこう力技の方が一般的なんだよね。光源の２D化とかも。

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

>>229
ドット絵１枚描くよりも、プリレンダリング用のモデル１つ用意するほうがコストかかるじゃろ。
ちゃんとしたデザイナーさんがついてて今風の絵にするならともかく、
古典的な2Dゲーではグリグリ回してもあまり問題ないケースが多いと思われ。

まあ、光源の方向が決まってる絵をむやみに回すなってのは基本ではあるわよね。
あと昔のハードに必ず載ってた左右／上下反転も、今では使えないケースのほうが多い。

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

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