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

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

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

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

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

■ 前スレ

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

**delphian** · 04/02/09 00:45

>>355

なるほど…。

ちなみに、タスクが自殺やチェンジする場合、全タスク実行後に処理したいので、
（削除済みのタスクへの不正なアクセスを防止するため）
その場合、Taskクラスではフラグを立てるだけにして、
TaskListのexecute時に削除等すればよいということですよね！

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

そういうことになります。

うーん、ぶっちゃけてC#のDelegateですね。

**delphian** · 04/02/09 00:58

>>357

typedef void Worker::(*Work)(); // Workerクラスのvoid method(); の形のメソッドポインタの型＝Work

delphiで↑のような型の宣言ができるかどうか…、
それが一番の問題ですが、これさえできそうなら、
クラスを使ったタスクシステムができそうです！

タスクシステムを使わない、クラスでの処理の構成もわかりましたし、
なんとか、今よりはスマートになりそうです。

また、わからなくなると思いますが、
そのときはアドバイスもらえればと思います。
今日は寝ようと思います。
また、結果報告します！
ありがとうございました！！

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

１日でスレすすんでてびびった

うちのは >>340風。
case文だらけが嫌になって、stateパターンを導入するも、
溢れ返った状態を記述しきれず泥沼化。
リファクタリングしようと、共通部分を is-a、 has-aでくくりだして、
フラットな状態遷移マシーンから、複雑な階層化状態マシーンに。
把握しきれずに、頭おかしくなりそうになった。

古典的タスクも考慮して組んで見たい今日この頃です。

>>354
Delphi使いはC++も読めると、世界が広がりますよ
考えようによっては、(C++ + Delphi)分の情報が得られるわけで

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

>>358
すれ違いになっちゃうけど

Delphiだとこうかな？
type
　TWorkerMethod = procedure of object; // クラスの procedure Method(); の形のメソッドポインタ型

　TTask = class
　　FWorker: TWorker;
　　FWork: TWorkerMethod;
　　:

クラスのメソッドへのポインタは、"of object"をつけてね

**delphian** · 04/02/09 07:26

>>360

ありがとうございます！
これで、できそうです！

>>350

追加で質問です。お願いします。
ちなみに、>>341の方法で実装したとして、
各クラスごとにタスクにあたる各メソッドを書くので、
リストへの登録・チェンジができるのは、登録したm_workerとそのクラス内のメソッドのみになるってことですよね？

あ、m_workerの登録を変えれば、他のクラスのメソッドにもチェンジできるのかな？？
でも、それだと、変数が保持されないか…。

各クラスで共通で使うタスク（メソッド）があるときは、各クラスごとにメソッドをかかないといけないわけですよね？

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

登録クラスとは別クラスのメソッドを呼ぶ必要はありません。
クラスのメソッドは所属するクラスに密接に関わる関数だから。
もし別クラスのメソッドを呼ぶような必要がでてきたのならば、
それはそのクラスにあるべきメソッドではないということです。

それから各クラスで共通に使うメソッドがあるならば、それは基底クラスで定義します。
タスクにメソッドを登録するときは基底クラスのメソッドを登録すれば問題ありません。

余談ですが341の方法は基底クラスの仮想関数を登録すると派生クラスの仮想関数が呼ばれます。
ややこしいので↓を見て実行すると分かりやすいかも。こちらもソースコードがややこしいことになってます…
http://www.emit.jp/prog/prog_cpp0.html

**Delphian** · 04/02/09 12:48

ということは、>>341の方法では、共通のタスクは使えないということですか？

共通の関数を仮想関数として基底クラスに書いたとして、タスクリストに登録ししても、
実際、呼ばれるのは派生クラスの仮想関数ということですか？

つまり、派生クラスの仮想関数を登録するのとかわらない、ってことですか？

共通のタスクを使うにはどうすればいいんでしょうか？

質問だらけですみません(>_<)

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

基本中の基本だけど、基底クラスで仮想関数を定義しても
派生クラスでオーバーライドしなければ基底クラスの関数が呼ばれるよ。
というか初めから基底クラスで仮想関数として定義しなければ
派生クラスでオーバーロードしても派生クラスの関数は呼ばれないよ。

**Delphian** · 04/02/09 13:57

ぁ、そうですよね。

オブジェクト指向を勉強しはじめて、一ヵ月ならないもので(>_<)

ちょっと混乱してしまいました。
仮想関数をオーバーロードすると派生クラスの関数が呼ばれて、
仮想関数として定義しないと、基底クラスの関数が呼ばれるんでしたよね。

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

どうでもいいけどオーバーロードとオーバーライドは別物だよ
googleで双方の単語入れて検索してみればすぐわかる

**Delphian** · 04/02/09 15:48

ぁ、すみません、間違えました。

全然違いますね。

とりあえず、帰ったら今日まで覚えた知識でクラス版タスクシステムをつくってみようと思います。

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

どうでもいいんだけどさ、ドット絵で透明感（背景が透けて見える等）を出すことは出来るの？

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

>>365
Delphiなら virtualなメソッドを、派生クラスでoverrideつけないで再定義すると、
警告出るからすぐにわかるよ

>>368
半透明つかえないのが前提だよね？
VSYNC同期前提でよければ、抜き色で市松模様にして交互に表示する
もしくは、単純に表示/非表示を繰り返す
同期取らなくてもそれっぽく見えるけど、ちらついてしょうがない

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

表示/非表示は楽な割に高い効果があるね

場合によっては、赤青非表示　のように
補色と非表示を組み合わせて
輝きのある半透明感を出すのもいい。やりすぎるとドギツイだけになるので注意

市松模様もそのうちやってみてえなあ

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

点滅は処理落ちに弱い。
素直にアルファ使おうよ

**Delphian** · 04/02/09 19:31

type
TWorker = class
end;

type TWork = procedure of object;

//タスククラス
type
TTask = class
protected
FStat: TStat; //タスクステータス
FPrio: Word; //処理優先度
FDelay: Cardinal; //待機フレーム数
FPrev: TTask; //前タスクへのポインタ
FNext: TTask; //次タスクへのポインタ

FKill: Boolean; //キルタスクフラグ
FChng: Boolean; //チェンジコールフラグ

FWorker: TWorker;
FWork: TWork;
FAttr: Word; //タスク属性（ユーザーが自由に使用できる）

public
constructor Create(Worker: TWorker; Work: TWork);
destructor Destroy; override;
procedure Execute;
end;

**Delphian** · 04/02/09 19:34

>>341 >>372

こんな感じになったんですがどうでしょうか？
タスククラスにワーカークラスを登録する場合、
あらかじめ生成したワーカークラスを引数として渡して登録したほうがいいのか、
それとも引数にクラス型を渡して、タスククラス生成の中でワーカークラスを生成したほうがいいのか、
どうしたらよいでしょうか？

次から次にわからないことが…

**Delphian** · 04/02/09 19:53

class Task {
　Worker* m_worker;
　Work m_work;
public:
　void execute() { m_worker->(*m_work)(); }
};

の部分は

class Task {
　Worker* m_worker;
　Work m_work;
public:
　void execute() { m_worker->(*m_work)(Task); }
};

にした方がいいですかね？
じゃないと、処理メソッドの中で自殺等できませんよね？
でも、処理メソッドの中でdelete Taskとかされたらこまりますよね…

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

>>374
その必要はないよ。
ちなみに俺も数年前はソレと同じやり方でやってたんだけどね

タスクを登録するときタスクリストでTaskのインスタンスを作るんだけど
そのインスタンスのポインタを登録関数の戻り値としてやって、
それを各ワーカーが保持しておけば何時でも参照できるよ

**Delphian** · 04/02/09 20:52

>>375

実装の段階になると、壁にぶちあたりまくって、
タスクはやめようかと思ってきました（＞＿＜）

登録関数がインスタンスのポインタを返すとしても、
登録したタスク（クラス）の外部では保持できても、タスクの内部では保持できませんよね？

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

各ワーカーの初期化関数中からタスクリストに登録すれば問題ありませんよ。

**Delphian** · 04/02/09 21:12

>>377

つまり、ワーカークラス（を継承した各クラス）のコンストラクタでタスクリストに登録するということですか？
で、ワーカークラスを生成すると、自動的に自らをタスクリストに登録するような構造にするということですか？

なんか、そういう手間を考えると、やはりクラスとリストを使ったほうがいいのかなぁ…
汎用性はなくなりますけどね…

クラスを使ったタスクシステムや、>>329 >>341のような方法の載った
サイトや本がありましたら、教えてください。
C++でもかまいませんので…

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

大体そういうことです。回りくどいですがこれには色々と理由があるんで…。
タスクシステムを辞めた理由の中にはそういうのもあります。

具体的に実装方法が載っている本のことは知らないけど、
私はABA Gamesさんとこのゲームのソースコードがいいかなと思います。
shot.cなんか読んだら、なんだ、こんな簡単なことなのか、と思うんじゃないかな。
ゲーム自体も名作なので一押し。

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

ごめん、プログラムの名前書くの忘れてた。noiz2saです。
http://www.asahi-net.or.jp/~cs8k-cyu/windows/noiz2sa.html

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

ってCじゃん
>181がC++でやってたみたいだが、消えてるし

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

俺の実装方法は、タスクを処理の基本パターンとして、
親タスクから小タスクへどんどんタスクを生成して、階層上に回す。
状態はStateパターンの亜種で実装。破壊とかね。
管理は親タスクで、その管理はその親タスクで。
こんな感じの実装だったな。
利点はタスクによる処理の一貫性が得られる点と、
どの階層からでもタスクを再構築できる点。
オブジェクト指向とは相反する。
当然最良の方法でもない。

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

画面にNOW　LOADINGとかの画像なりを表示させつつ
その間にデータを読み込むというのはどうやったらできますか？

使っている言語はC言語です　よろしくおねがいします

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

必死で考えて考えて考えたやつ→作れる
すぐ諦めて訊くやつ→無理

383、内容が薄すぎる。
自分で考えたんならもうちょっと建設的な質問ができるはずだぞ

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

画面にNOW　LOADINGとかの画像なりを表示させつつ
その間にデータを読み込めば良い

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

自機を動かしながら、敵を動かすのと同じやり方でいいでしょ
それともマルチスッドレにしたいのかな？

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

マルチ的手法とか、リアルタイム的手法とかいろいろ考えられるね。
NOW　LOADING処理表示中に、細切れにしたデータを逐次読み込むか、データ
読み込み中にNOW　LOADING処理を逐次呼び出すとか。

後者が楽だと思うけど、俺は画面処理を軸にしたいから前者の方が好きかな。

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

>>383
CreateFile 非同期で検索汁

**Delphian** · 04/02/10 12:58

>>379

ぁ、ワーカークラスのコンストラクタでタスクリストに登録すると、
継承したクラスごとに優先度とか変えられないですね。

そういういろいろややこしくなることを考えると、
やっぱりゲームごとにクラス作っていこうと思います。

みなさん、ありがとうございます！

**Delphian** · 04/02/10 17:06

ぁ、コンストラクタに引数もたせれば、いいんですよね(;^_^A

実際、タスク使ってつくる人より、
普通にクラスを使ってつくる人のほうが多いんですかね？

C++でいいのでゲームプログラミングでおすすめの本があったら、
教えてもらえるとありがたいです。

できれば中高度くらいで…
3Dものは作る予定ありません。

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

ああん、コンストラクタとかタスクとかクラスとか何話してんだか全然わかんないポ

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

動けば問題ないよ、面白ければ問題ないよ

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

>>391
まずプログラムの基礎を勉強するべきかと。

この辺の本とか、
http://www.amazon.co.jp/exec/obidos/ASIN/479800314X/ref=sr_aps_b_/249-6758129-5407516
http://www.amazon.co.jp/exec/obidos/ASIN/4798006033/ref=pd_bxgy_text_2/249-6758129-5407516
C++の便利な使い方も書いてあるので読め。

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

コンストラクタもタスクもクラスもわからなくても
古典的手法でガレッガや怒蜂は十分作れるYO

本が合う人は本でやってみるのもいいと思う。
もしそれでできなくても挫けるな。
どんな泥臭い方法でも、まずは動いて遊べるゲームを一つ完成させることだ。

一つもできないうちからウダウダやってると限りある人生ムダにすることになるぜ

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

まず、泥臭い方法で作る。
で、もっと良い方法ないかなと模索する。
結果、タスクなりオブジェクト指向なりに行くと。
タスクに関してアセンブラと少ないメモリで少しでも
すっきりした形で作ろうした結晶のひとつ。
いきなり理解しようとするのが間違っている。
オブジェクト指向しかり。

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

自分で問題に直面してみないと分からないことは多いからね

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

Cとタスクの一本槍人生。
WS→GBAと渡り歩いたら必然的にこうなったような。

しかしC++を覚えにくくなるという諸刃の剣。
結城浩尊師が御本を執筆なさる日を待っているとかいないとか。

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

int x[MAX];
int y[MAX];
int kind[MAX];
for (int i = 0; i < MAX; i++) { ... }

こういうBASIC時代の身も蓋もない実装を、アセンブラやCで正常進化させていけば、
勝手に古典的タスクに行き着きますな。
俺も含めて、すべてのオヤジゲームプログラマが辿った道でしょう。
んでもってC++覚えたらゲームオブジェクトやらエンティティやらシーングラフやら
OO的アプローチで取り組んでみると。

歴史をそのまま辿ってるので、今どきのわきゃーモンにとって効率のいい道かは……
まあ、若いんだし、回り道してみてもいいんじゃない？と思うけどね（ｗ

**Delphian** · 04/02/11 16:05

>>398

とりあえず、ここでアドバイスをいただいて、
オブジェクト指向でのゲームプログラミングについて、
わかってきました。

同じキャラクタが簡単に複製できるのでよいですね！

もう一歩レベルアップしたいのですが、
それは、あたり判定、、、（？）です。

シューティングというか、アクション要素の強いものにするつもりなんですが、
どういう方法をとればいいのかわかりません。

**Delphian** · 04/02/11 16:06

画面は斜め上からの見下ろしタイプ（？）で、
移動とか描画のイメージとしてはボンバーマンをイメージしてもらえると、
わかりやすいかと思います。

たとえば、１キャラ３２×３２のサイズだとして、
１キャラ単位の移動の場合には、
（右に移動するときは、８ドットずつ描画。
　１キャラサイズ分移動するまでは操作できない）
キャラの座標を元に、スプライトを優先度順に描画して、
当たり判定も座標位置から処理することができますよね？
（この場合、当たり判定というより、座標からのチェックですね。）

これをドット単位の移動にしたい場合、
どうすればよいのでしょうか？

**Delphian** · 04/02/11 16:14

ドット単位の移動の場合には、
通常でいう当たり判定を実装すればいいのでしょうか？

たとえば、３２×３２サイズのキャラの場合、
足元（キャラの下半分＝３２×１６）にのみ当たり判定をもたせて、
敵・障害物にも当たり判定を持たせて、
その当たり判定によって移動の制限・敵との接触を判断するような形でよいですか？

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

ある程度やり方が想像ついているのなら、聞く前にまず組んで見ろ。
それで、何か問題があれば聞きに来るようにしてみては。

**Delphian** · 04/02/11 18:54

>>402

すみません（＞＿＜）
すでにやってみてわからなかったので、質問しました。
>>401の方法でたしかに移動はうまくいくんです。
しかし、描画がうまくいかないんです。

たとえば、障害物があって、
その下に自キャラがいる場合は、
障害物にかぶって自キャラが手前に描画されます。

しかし、障害物の後ろにいる場合でも、
障害物にかぶって自キャラが描画されてしまいます。

この場合、どのように描画していけばいいのかわからないんです。

障害物を２つのスプライトに分ける、以外に何か方法はありますか？
それとも、障害物を優先度の違う２つのスプライトにわけるしかないんでしょうか？

それによってはだいぶかき直しがでてきてしまうので、
なにかよい方法があればと思って聞きました（＞＿＜）

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

具体的にどう組んでるか判らないが、一番単純な方法は
自分も含めて奥から順番に並べていく。

**Delphian** · 04/02/11 19:13

>>404

できました！！
ありがとうございます！！

原因は、自キャラの描画優先度が常に最優先の順位になっていたためでした。

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

うーむ…。
何故タスクを使っているのかということを知らずに、タスクを使っていたのではどうしようもないよ。
タスクを使うなら使うなりにその利点とかをちゃんと理解して使わないと。

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

>>397
あーわたしも同じような感じだ。
いい加減Winに移行しようと思っているけど
どこから手を付けたものか。

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

そういや全員がパソコン用シュー組んでるわけじゃないんだな

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

>>407
今俺はLUNAってライブラリ(DX9版)使ってどうにかこうにかスプライトドライバらしきものは作ったってとこ。
楽することしか考えてないし。
1つのテクスチャからしか画像引っ張って来れないクソだけど。

ま、先達の足跡をなぞらせてもらうってのがいいんじゃないかと。

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

D3DXSpriteを使おうと思っているのだけど、半透明や加算合成はサポートされていますか？

理想としては、DirectDrawみたいにサーフェスから矩形転送で半透明や加算合成がハードウェアで
サポートされている機能があればいいんだけど。
そんなやつ知りませんか？

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

↑のは、DirectDrawみたいに手軽な矩形転送（ＢＬＴ命令）の方法で半透明や加算合成がハードウェアでサポート
されている便利な機能は無いのかなってことです。

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

DrawPrimitive使ってスプライト描画ライブラリ作ればいいじゃん。
ゲーム作るよりは簡単だと思うが。

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

D3DXSpriteの話題なら、スレ1_53あたりから出てるようだね
あとはdxスレが参考になるのかな
俺は直接directx触ったことないので間違ってるかも知れないが

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

あんまOOに拘らん方がいいと思うが

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

まぁ、目的はそれぞれ。
完成することが目的じゃなく、オブジェクト指向を楽しむためのシューティングプログラムであっても結構。

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

質問した本人の迷いが晴れて少しでも進歩してくれるなら、それでよい
が…迷わせてるだけの回答もあるようだ
まあ2ちゃんねるだから回答の質など低くてあたりまえなんだけどな

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

>>709
Lunaは導入を検討中…まあ楽にというのは同意。
別にシステムを作りたいってわけじゃないからね。

**delphian** · 04/02/12 21:16

>>401

だめでした！！
せっかく書き直したのに…（；＿；）
この方法には問題点がありました…。

障害物、自キャラ共に足元（下半分程度）だけにあたり判定を設けています。
これで自キャラが障害物の手前にいるときは、障害物に少しかぶる程度になります。
障害物の後ろにいるときは、後ろに少し隠れるようになりました。

しかし、、、マップをつくった時に判明しました…
障害物が縦に二つ並んだときはだめでした！！
画面上では障害物がつながって並んでるのに、
自キャラがすりぬけてしまいました…。

横から障害物にぶつかると、あたり判定の隙間をすりぬけてしまうんです…
障害物のあたり判定が小さいとかですかね？
それともやり方自体が間違ってるとかでしょうか…

せっかくうまくいったと思ったのに、かなり悩んでいます…
斜め見下ろしタイプにするんじゃなかった（；＿；）

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

表示だけ斜め見下ろしにすれば良いのでは。
判定自体は平面で十分かと。
てかシューティングゲームなのか？ｗ

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

自キャラと地形の当たり判定が問題ですよね。
自キャラの当たり判定を見た目より大きくして
壁のキャラ同士の隙間を通れないくらいにしたら。

自キャラと敵などの当たり判定は普通の大きさでするとして。

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

あたり判定を地形用と敵キャラ用で２種類作ればいいんじゃないだろうか。

**delphian** · 04/02/12 22:43

>>419

表示と判定ってきりはなすいい方法ってありますか？
障害物の前に表示させたり、後ろに表示させたりするのに、
平面にしちゃうと障害物の後ろに隠れるように表示できない気がするのですが…

ちなみに移動はアクションっぽい感じで、
敵の出現とか攻撃方法がシューティングっぽい感じです。
アクションシューティング！？みたいな感じを予定してます。

**delphian** · 04/02/12 22:48

>>420
>>421

２種類ですか、なるほど。
でも、判定が２種類だと重たくなりそうな気がしますが平気でしょうか？

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

２種のあたり判定は、確かに処理は重くなるけど
かなりの数比較しないと目に見えて重くならないハズ。

作画順序が問題なら、作画前にソートしてはどうか。

**delphian** · 04/02/12 23:35

>>424

ありがとうございます！
とりあえずやってみます！
つまり、
自キャラ→敵キャラ
自弾→敵キャラ
敵弾→自キャラ
自キャラ→地形

と４回当たり判定すればいいんですよね！？
うーん、重くなんないかなぁ…。
とりあえずやってみます（＞＿＜）

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

>>422
これは一般的に広く使われている方法だと思うけど、当り
判定用の仮想マップを作る。

プロック単位なら1ブロック1バイトとかで十分。
ブロックのサイズで割り算すれば仮想マップでの位置は
簡単に求められるよね。

表示に関して言えば見る方向が限られているわけだから
位置で優先順位が決まるはずだよ。

**delphian** · 04/02/13 00:10

>>426

ただ、自キャラの移動がドット単位なので…
ずれて障害物にぶつかったときは、判定がおかしくなっちゃいますよね？

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

>>427
ドット単位でも殆んどの場合仮想マップで十分だよ。
1点だけで当り判定しなければいいだけの話。

移動前に移動するはずの位置(オフセットさせて)での当り
判定を取ればめり込むことも無い。

例えば上に移動したいなら上の辺の2点でどちらかが当る
かどうかを調べてどう移動するかを決めると。

**delphian** · 04/02/13 00:39

>>428

障害物や自キャラすべてのキャラが３２×３２のサイズだとすると、

　　自キャラの位置÷３２が仮想マップでの位置

とかそういう感じですか？

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

へえ、こんなところがあったんだね。
もっと何て言うか、プログラム的なテクニック以外の話題かと思ってたんだけど
タスクとかオブジェクトとか、みんないっぱい勉強してるんだなぁ。
そういう専門用語なんて全然わかんないよ。
ＣとかＤｅｌｐｈｉとかも、全然わかんないよ。

でもちゃんとシューティング作れたよ。
こういう人間もいるから、みんなくじけず頑張れ。

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

>>430
貴重な人材ようこそ
実際にシューティング作れた人の経験談ってのは、何より大事だよ

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

>>429
そうそう。
で、自キャラの当り判定用に4つの点が移動すると
考えてみればわかるかな？

**430** · 04/02/13 01:34

>>431
どうも、話の腰を折っちゃったみたいで申し訳ない。

今Windowsの２作目をやってるけど、大バグ出しちゃって大変だよ。
敵を動かすメインの部分を再設計するはめになったよ。
技術的なことより、モチベーションの維持が大変かもしれない。
２ちゃん見てる暇あったらさっさと直せって言われそうだけど・・・
ユーザー様販売店様ごめんなさい。

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

モチベーションの維持はなかなか大変だよね。最近読んだ記事では
ttp://www.radiumsoftware.com/0402.html#040205
このあたりが俺もそんな経験あるなあって感じだった

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

１日８時間エンジン全開にできれば制作サクサク進むだろうになあ。

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

やる気を高揚させるためにゲーセンに逝く。

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

むしろシューティングが殆ど無くてｼｮﾎﾞｰﾝとする罠

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

>>434
俺もそこみてて共感した
自分含めて周りにもいるので。。。

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

G-わんげ鳩大往生XII～絆ダウン～ 4stage
http://game4.2ch.net/test/read.cgi/arc/1069685469/

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

>>434
なるほど、目から鱗が落ちるとは正にこの事。
だから今日も頑張るよ。
ついでに新しい敵動作も追加するよ。

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

学校の卒業研究で３Dシューティングを作ってるのですが、ここって製作物の晒しOKですか？

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

おｋでう

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

>>1嫁

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

>>439
自分たちで責任もってやりなさい。

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

卒業研究でシューティングって何気に凄いな
物理屋？

**441** · 04/02/14 00:11

ただの専門学校です（´Д｀；
今確認してみたらメモリリークしてた個所があったので
晒すのはもう少しかかります・・・

>>443
すみません。

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

>>446
期待してる。
ソース月だったら神

**441** · 04/02/14 02:14

おそらくまだ問題を色々内包してたり、
システムやグラフィックにまだ未完成な部分も多いですが、いったん晒し。
ttp://gamdev.org/up/img/237.zip
Zキーでショット、Xキーでボム、カーソルキーで移動して、ESCで終了です。
タイトル画面ではZキーを押してスタートしてください。

>>447
すみません。今はスパゲティ状態になっているので、
どれだけ先になるかわかりませんがソースを整理できたら晒させて頂きます。

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

ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━!!!!

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

せ、先生！！
ゲームが物凄いスピードで進みます！！
なんか処理をCPUとか描画依存とかにしちゃってるのかな？

P4　2.4GC
RADEON9800Pro
VRAM128M　RAM1G3100
WinXPPro

**441** · 04/02/14 02:33

あ、しちゃってます。
というよりもFPSを一定に保つ処理入れ忘れてました。
フルスクリーン状態ならなんとかなりませんか？

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

うちもウィンドウモードだとマッハで動くな。
AthlonXP2200+
RADEON9500pro
PC2100/1GByte
WinXPpro

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

GetTickCountでウエイト入れればいいだけっしょ。

**441** · 04/02/14 03:26

ttp://gamdev.org/up/img/237.zip
ファイル名同じですが中のバイナリ変えました。
秒間約60FPS固定になっているはずです。
が、リフレッシュレートとの兼ね合いで
描画がカクカクするようになった・・・

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

必要なところがしっかり押さえてあっていい感じだね。この調子でｶﾞﾝｶﾞﾚ

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

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