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

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

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

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

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

■ 前スレ

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

**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ゲーではグリグリ回してもあまり問題ないケースが多いと思われ。

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

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

16色時代ならともかく256色のドット絵で要塞のような大型物体を
3D使わないで動かして、なんて発注されたら逃げたくなるが…。

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

>>232
レイフォースのレーザーも全部キャラクタで持ってますが…。

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

そんな裏事情俺らは知らん。

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

>>235
３Ｄモデル１つ用意すればあとは32方向分でも64方向分でもすぐに用意できるﾜｹだが
モデルを起こせる環境さえ整ってればむしろこちらの方がローコストなんだよ

**235** · 04/02/04 05:24

話が通じてないなー。

あたしゃ、（回転可能な）ドット絵を１枚描いてそのまま回転させるのと、
モデル１体作ってそのまま回転させるコストを比較してるんであって。

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

>>239
そうだね。
例え一枚でも規模によってはモデリングしたほうが楽なこともある。
ただ、手作業の擬似3Dには別の味があるので、一概に比較できないけど。

**241** · 04/02/04 05:27

あら、タイミングいいなｗ＞240氏

まあ書いたとおりだが。

**235** · 04/02/04 06:24

>>241
> 例え一枚でも規模によってはモデリングしたほうが楽なこともある。

それは認める。

というかなんだ、前処理で回転パターンを生成するにせよ、ハードウェアの回転機能を使うにせよ、
手描きの一枚絵をそのまま回転させてるゲームは山ほどあるわけだ。
そりゃいまどきの市販ソフトの映像クオリティだと流行らんけどさ、
誰もがそういうの作ってるわけでなし、モデラーや鬼のドッターを用意できるわけでなし、
個々の制作者の事情を無視して、あらゆる意味でセンス無えとかってのはどうかと思うわけよ。

俺はクロノトリガーのタイトル画面好きだぜ。関係ないけど。

**241** · 04/02/04 07:19

まあ確かにそうね。
適材適所と言っても常に適材が用意できるわけじゃなし。
2D3D両方のスキルを持ってないと比較は出来んわけだし。

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

そこでレリーフテクスチャを使ってかいｔ（ｒｙ

ネタです。突っ込まないように

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

>>243
禿同

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

ヴィジュアルにセンス無くてもええやん、面白ければ

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

あくまで人的リソースが不足しているプロジェクトの苦肉の策と捉えるべき＞１枚絵の回転
少なくとも手抜き目的以外で積極的にやるもんではない

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

>>245
バンプマッピングでそこはかとなく立体感を出すとか！

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

同じ絵で光源だけ一周させた絵たちを角度ごとに呼んで、その角度で回して表示するのは？

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

>>250
それだと余計に手間がかかるだけじゃねーの？
光の角度一回点分の絵を全て用意した上で更にソフトで回転処理？
いっそケイブ方式の方がラクのような気がする

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

真上から見た絵を書くならそれでいいんだろうけど、
斜めだと使えないね。

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

メモリ問題
CPUコスト問題
製作コスト問題
クオリティ問題

宗教の問題なのかね？

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

パルスターも忘れないでねん

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

>>253
宗教というよりはトラウマだな。

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

>>248 1枚絵をソフトで回転させて、ドット修正もなしに使うって
ことだよね？　たしかにそれじゃスーファミレベルだな。

漏れが昔2Dゲー作った時は、ドッター氏がソフトで回転させたのを
手修正してくれた。久々に連絡取ったら、彼は携帯アプリやってる
らしい…。

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

フォントは環境によって有る無しが変わるからな。
ＶＡＩＯで作ったヤツに使ったフォントはその機種にだけ入っていたフォントなので
修正に苦労したよ。

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

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

マイナーかも知れないけど
任天堂のスターフォックスタイプの３Ｄシューティング作ってる人居ませんかね？

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

スペハリのパロを製作中。
あの独特の疑似３Ｄ感をＧＬで出すのに苦戦してます。

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

おっ、いいねえスペハリ。
あの市松模様をやるわけね。
自分もポールポジション的コースの再現に凝ったことあるよ。

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

ラスタースクロールを使った擬似3Dのカーブの表現ってこｔかな

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

う～んと、シューティングにはタスクを使えって言われたのですが
タスクってなんなんですか？

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

タスクについての有名っぽいページ↓。

コンピュータゲームのからくり
http://www.hh.iij4u.or.jp/~peto/Games/games_top.html

古い技術なので、別に無理して使うこと無いと思う。
参考にするくらいはしてもいいと思うけど。

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

タスクを使わない場合はどうなるんでしょう？
「タスクを用いない作り方」はいかにも悪例のようですけど

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

>253
メモリコスト問題
CPUコスト問題
製作コスト問題
クオリティコスト問題
コストの問題のような気もします。
MEMORY < CPU < QUALITY < PRODUCTION

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

このスレのみなさん、当方STG好きなのですが、
みなさんがんばってください！！力になれないけど
応援します！プログラミング出来たらおれも作り手ー

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

応援はいらん！作品でしめせ！
新作を見せ付けられることが、製作者の燃料だ！！

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

煽りとかじゃなくて真面目な話し、やはりシューティングの演出に美少女キャラは
必須っすかね？
同人作品全般、並びにシューターサイトを眺めてみると、その嗜好は
明かなので、そのあたりのクオリティが低いと認知されにくいのかなぁと。

このスレの多くはプログラマさんだと思いますが、オブジェクトや音楽以外の
要素をどのくらい重要視されてますか？

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

好きなものを好きに作るのが一番良いのでは？
売れると思ったら美少女でもカッコいいメカでも出せばいいでしょうし。
いらないと思ったら出さなきゃいいだけだし。
同人なんで、自由にやりましょうよ。

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

なんでシューティングに美少女キャラが出るんだろう
頭おかしいんちゃう？

**269** · 04/02/07 01:47

んー、何でシューターと２Ｄ美少女は相性がいいんでしょうかね？
私も知りたい。

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

>>269
同人で美少女キャラを入れてる人は、自分が入れたいから入れてるんじゃないの？
ベツにそれが必須かどうかなんて考えてないと思われ。
少なくとも自分は、ＳＴＧが遊びたいのであって、美少女ゲームが遊びたいわけではないので、
ＳＴＧとして面白ければどっちでもいい。

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

昔からゲームやってる層が多いのでオタクな趣味として重なるんでしょう。
そうじゃない人もいるでしょうけど。

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

兄貴ばっかの某シューティングみたいなのじゃ嫌だろ？
むしろ好みって人もちょっとは居そうだけど。

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

頭おかしいとまではいわんけど、単に物語を語る道具として
シューティングというジャンルを選んでるゲームは解せんよ

>>275
おいらはそっちの方が好きだけどな

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

あぁ、なんか頭が痛くなってきた・・・
なんかシューティングのソース付きで解説しているサイトとかってないものかね？
なんかいまいちうまくいかないところがあるからさ

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

>>276
実は俺も超兄貴好きで・・・

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

俺はケツイが…

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

俺もガキの頃はSTGに美少女キャラとか恥ずかしいから出すなとか思ってたなあ

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

>>277
過去ログ嫁
>>168　>>181　>>167　http://www.sm.rim.or.jp/~shishido/gamedev.html

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

>>269
他の方も書いているが、自分が必要だと思えば使いましょう。
ただ演出として美少女が有効だったSTGというと、なにかあるだろうか。
レイフォースが美少女の範囲から外れるが、有効に機能していたと思う。
他のなにかありますかね？

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

有効に機能してたかどうかはかなり怪しいもんがあるが、
XEXEXとフェリオスから美少女を抜いたら味気なくなるな。
気恥ずかしいがｗ

チチビンタリカは美少女の範疇だろうか？

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

アーケードに限って言えば、美少女を前面にだしてるほうがマレじゃない？
フリーのシューティングにもそんなに多くないような気がする。

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

実は俺はテングお面がｗ

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

フリーのシューティングはプログラマが無理に描いたのを見かけるけど？

逆にキャラクターがあって、シューティングが付いたみたいのも結構あるな
ブレスタとか。（結果的には内容も○だったと思うが）
ストライカーズは皮肉になってるのかな。
でも、キャラがうければイラストやCGなど２次創作での話題持続が期待できるね。

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

>>286
同人でそこまで（二次創作）狙って成功してるのなら、むしろ天晴というべき。
むろん、ＳＴＧ部分が面白いという大前提あっての話だが。

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

でも、なんだかんだで美少女っていうかビジュアルがいいと受けるよねぇ。
昔はほとんど気にしなかったけど俺はゲームでなくてもユーティリティソフトでも
見た目を重視して作るようにしてるよ。（多少性能を犠牲にしてもねｗ）

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

遊びやすさとか使い勝手が悪いのだけは勘弁

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

>>283
フェリオスはまだいいとしてXEXEXはどうか。
「私自らが出る！」の人はいないと寂しいが…ｗ

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

ほとんどのケイブ作品の美少女はゲームと関係なく機能してるな
まぁ、それを期待してる人もいるのもまた事実。

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

斑鳩のカガリたんは美少女扱い？

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

>>291
エスプのガラ婦人を忘れちゃいけません。

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

ケイブの割り切り方はいいな
キャラクター要素がまったくウザくない
プログラマさん（IKDさん？）は、シューティング部分にしか興味ないっぽいし、わかってるわ

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

ケイブと言えば、ほとんどの人はエレメンタルドール＝パイロットだと
思ってるんだろうな。
エンディングとかも意味不明だろうし。
尤もエンディング見るような人は設定を知ってるだろうけど。

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

ケイブシューはIKDからの挑戦状なんです

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

プロギアのキャラクター要素は結構うざいけど．．．
カプコンが入れ知恵したのか？

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

声無しのモードがあれば文句無かった。エスプガルーダも。
まぁ現状でもじゅうぶん許容範囲だが

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

怒首領蜂に声ありモードが欲しかった

死ぬがよい

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

つか、ケイブは実にせこいな。
関係無いならスッパリ切り捨てるこだわりが無いものか．．．大人の事情ってやつ？

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

流れに割り込むけど
SCORE SOLDIER -WINTER FESTIVAL 2004-のソースがいつの間にか上がってたから
見てみたが、すごいな。まさに富豪的プログラミング。
まあちゃんとプレイ出来て面白ければ、中で何してようが関係ないんだけど。

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

メンテとステージづくりが楽ならどんなプログラミングスタイルだろうがﾏﾝｾｰしちゃうかも

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

1ステージにどのくらい時間かかる？

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

>>300
そうそのとおり！

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

>>301
ぅぉ！データの定義にマクロアセンブラを利用するとは
そんな手があったのか

この書き方は、元々コンシューマの人なのかな？
あまり富豪的に見えなかったのは、俺がPCどっぷりだからか？
しかし、この見事なデータ駆動っぷりは見習わねばならん

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

プログラミング言語のマクロ機能は字句解析器としてけっこういけるね
使い慣れてる点も強み
実は俺もシューティングじゃないけど同じ方法使ったことが

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

俺はパーサーまで自力で書いちゃってるけど、
かなり無駄な労力だなあと思うことはあるなあ
テキストファイルから読み込めるようになれば
調整段階までいけばコンパイルしなくていいから便利

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

現在ゲーム製作のための擬似（マルチ）タスクシステム(クラス)を作っています。

そこで質問なのですが、

１．キャラクタを動かす場合、基本的に

　　各キャラクタのタスクを生成→キャラクタ移動タスク（座標の移動）→
　　　→当たり判定タスク→描画タスク

　　という流れになると思うのですが、
　　当たり判定タスク・描画タスクで、
　　各キャラクタの座標をどのように取得すればよいか悩んでいます。

　　座標は各タスクのワークエリアにもっています。
　　今、思いつくのは、

　　　　１）当たり判定クラス・描画クラスを別に作って、
　　　　　　各キャラクタの座標を登録する形式にして、当たり判定タスク・描画タスクが、
　　　　　　自動的に処理するようにする。

　　　　２）各タスクのリストを順にたどっていき、タスクの属性（敵・味方等）を元に、
　　　　　　各タスクのワークエリアから座標を取得する。

　　です。
　　
　　なにかよい方法はないでしょうか？

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

２．タスクシステムは、双方向リストで動的にメモリを確保・開放しています。
　　動的確保のため、タスクの生成・削除が多いとメモリが虫食い状態になってしまいます。
　　
　　静的配列を使った方がよいのでしょうか？

　　ただし、静的に確保するためには各タスクのデータ構造は構造体で定義しなくてはいけないため、
　　（クラスだとポインタを使うのと代わりないため）
　　外部から操作される可能性がでてきてしまいます。

　　それを考えると、
　　やはりクラスを使って動的に確保したほうがよいでしょうか？
　　

３．現在、各タスクの登録時には実行する関数を登録しています。
　　関数ではなく、基本となるタスククラスを継承した各クラスを登録したほうが、
　　
　　コンストラクタ・デストラクタを自然に使えるので実装も簡単なのですが、

　　ただし、そうすると、タスク内でタスクをチェンジした場合に、
　　タスクの情報（座標等）を引き継ぐことができません。

　　そのへんがクリアできれば、クラスの利点を生かしたタスクシステムが作れそうなのですが。

長くなってしまいましたが、ぜひ、アドバイスをよろしくお願いします。

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

２．タスクシステムは、双方向リストで動的にメモリを確保・開放しています。
　　動的確保のため、タスクの生成・削除が多いとメモリが虫食い状態になってしまいます。
　　
　　静的配列を使った方がよいのでしょうか？

　　ただし、静的に確保するためには各タスクのデータ構造は構造体で定義しなくてはいけないため、
　　（クラスだとポインタを使うのと代わりないため）
　　外部から操作される可能性がでてきてしまいます。

　　それを考えると、
　　やはりクラスを使って動的に確保したほうがよいでしょうか？
　　

３．現在、各タスクの登録時には実行する関数を登録しています。
　　関数ではなく、基本となるタスククラスを継承した各クラスを登録したほうが、
　　
　　コンストラクタ・デストラクタを自然に使えるので実装も簡単なのですが、

　　ただし、そうすると、タスク内でタスクをチェンジした場合に、
　　タスクの情報（座標等）を引き継ぐことができません。

　　そのへんがクリアできれば、クラスの利点を生かしたタスクシステムが作れそうなのですが。

長くなってしまいましたが、ぜひ、アドバイスをよろしくお願いします。

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

私の独断と偏見による意見ですが…

１．に関して。そーいう実装方法は止めたほうがいいかなぁー？
無理に複雑な実装方法を選んでプログラムを複雑にしてるという印象です。
もっとオブジェクト指向的に考えてみては如何でしょうかね。

2，3に関して。最近のPCは性能が良いので動的メモリ確保しても問題ないけども、
気になるようなら、オブジェクトの基底クラスを作って、
operator new/deleteのオーバーライドを考えてみては。

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

そうそう、タスクループに拘りすぎると、ろくな目にあいません。（ｗ
ゲームを実装するためにタスクループの考え方があるのです。
タスクループ上でゲームを実装するにはどうすれば？とは本末転倒。

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

>>308
俺も昔同じようなところで悩んだな。
結局、良い方法思いつかなかったけど。
１の当たり判定は、全てのキャラ移動→一括して当たり判定
ってのをしていた。そうしないと変な判定するんで。
２は、結局動的で押し通した。その際になるべく、
虫食いにならないようにタスクの生成順番と
削除のタイミングを注意した。
デバッグ用途も含めて、new/deleteはオーバーライドしてたけど、
タスクごとのオーバーライドはしなかった。
やってもいいと思う。
３は、そもそもタスクの切り分け方を従来の方法と
変えてしまったんで、普通に継承して問題なかった。
実装の仕方が違うと思うのでなんとも。

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

アドバイスありがとうございます！！

やはり、汎用的なタスクシステムを作るより、
ゲームにあわせてクラスを構成したほうがいいですかね。

ただ、クラスのみを使ってつくるとした場合、
基底キャラクタクラス（敵１クラス）から派生した各キャラクタクラス（敵１－１、敵１－２等）を作るとして、

結局は、グローバルな変数（またはクラス）等で、各派生クラスを管理しなくてはならないですよね？

グローバルな配列の各要素に、各派生クラスを結びつけて、
その配列を元に各派生クラスのメンバにアクセスする等でよいのでしょうか？

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

そんなとこかと。
俺ならclass World(＝ゲーム世界全体を表すシングルトンクラス)を作って、
そいつにキャラクタを保持させる、という感じですかね。
class World { list<Character*> m_characters[NUM_CHARA_TYPES]; };
特化させてクラス別リストを用意するとか、色々と方法はあるかと。

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

>>314
俺は管理タスク（クラス）を用意した。
管理タスクからすべてのキャラクタタスクにアクセスする形。
アクセスは、キャラクタタスクの先頭へのポインタだけを持っていて、
あとは、リスト構造（リングバッファ）で辿る形。

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

みんなアニメーションのデータ構造は
どんな感じにしてる？

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

アニメーションと一言で言っても
2Dと3Dの違いもあれば、拡大縮小回転や口パクアニメなんかもあるわけで
なんと答えていいか分からんのだが

**317** · 04/02/08 18:26

2Dのアニメーションです

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

とりあえずグラディウスの時代からある敵弾アニメを例にとってみようか

敵弾オブジェクトごとに、アニメ用カウンタが用意されてる
表示関数で、そのカウンタを使ってアニメ

ここまでは基本だよな
あとは使う言語によるかな。

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

2Dでアニメーションというと普通のキャラクタアニメーションでそ？
悩むところではないと思うんだけど。

RPGツクールみたいに32*32限定でいいならソーステクスチャを32*32で区切って左上から番号振る。
アニメ順序にあわせてIDを配列で並べて、ついでにアニメ速度とかを定義とかすればいいし。
汎用性持たせるならソース上の矩形ごと並べてしまうとかでもいいし。

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

テクスチャ1枚に複数絵を用意してUVで切り替え

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

グラフィックデータ（テクスチャなりサーフェイスなり）は
どこに配置させてどうやって参照させるのが賢いのだろうか…
いつも悩んでます。

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

>>316

自分もタスククラスとタスクマネージャークラスを作っています。
たしかに、先頭のタスクのアドレスを取得すれば、
リストをたどっていけますが、
どうもいまひとつの気がしてやってませんでした。

ようは、
　１．先頭タスクのアドレスを取得して、
　２．次のリストへのポインタを取得する、を繰り返す
ってことですよね？
結局、外部からタスクの内部を参照するわけであって…。
総当りの上に、書き換えられる可能性もあるわけですよね。
そう考えるとやっぱりクラスを使ったほうがいいのかぁ。

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

以上をふまえた上で質問です！

もしクラス版のタスクシステムを作ったとしても、
（クラスを登録して、タスクを生成・削除・チェンジするタスクシステム）
座標計算と当たり判定・描画処理を独立してやることを考えると、
（座標計算と判定・描画を同関数内でやると、すりぬけ、が発生するため）
関数版のタスクシステムと同じく
　１．座標情報等のデータをグローバルで持つか、
　２．各クラスのアドレスをグローバルで持って参照するか
しないといけないわけで、
タスクシステムでつくる意味がほとんどないわけですよね？

そう考えると、タスク自身のワークエリアをなくして、
データ類はグローバルな配列で別個で管理するほうがいいんですかね？
単なる関数ポインタを使ったテーブルジャンプみたいになってしまうけど。

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

ttp://www.interq.or.jp/black/minami-m/

↑にクラスを使った基本的なタスクシステムがありますが、
これって、当たり判定・描画処理を各タスクごとに行ってるんで、
すりぬけや、思わぬ動作を引き起こす可能性がありますよね。

そう考えると、一番いいのは、
各クラスを割り当てた管理配列等を、forループ等で処理したりでしょうか？？

なんかわけわからなくなってきました(T_T)

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

>>324
書き換えられる可能性ってのはないと思うけど、
そもそも書き換えられて困るから、一括処理な訳で。
リスト構造にしてる意味は、動的生成な訳で、
それをやめるなら、配列でいいかと。
グローバルにする意味はあんま感じないな。
Singletonって意味ならそうだけど。

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

>>326
それ読んでないけど、処理が終わったタスクとのみ
当たり判定を行っていけば、タスクごとの当たり安定でもできると思う。

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

>>324-326
迷っておりますなｗ

まず一つ言うが、>>326のタスクシステムはCのタスクシステムよりうんこだから無視せい。ｗ
真にCのタスクをC++に移植するならば、
ワーカークラスのインスタンスポインタとメソッドポインタのペアをリスト化しなきゃならん。

個人的には初心に戻ってオブジェクト指向的に考えることを勧めるよん。

キャラクタはどんな情報をもち、何をするのか？→位置情報を持ち、移動や描画を行う
class Character {
　Vector2 m_pos;
public:
　Vector2 getPosition() { return m_pos; }
　virtual void move() = 0;
　virtual void render() = 0;
};

キャラクタのリストは誰が保持するのか？→ゲームの世界が保持して管理する
ゲームの世界はどんな機能がある？→世界の時間を一定量進めるとか、世界全体を描画するとか
class World {
　list<Character*> m_characters;
public:
　updateOneFrame() { for(...); it->move(); }
　renderScene() { for(...); it->render(); }
};

こんなんでよいではないか、と思うけどネェ。

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

って当たり安定ってなんだよ orz...

あ、あと、当たり判定に関して言えば、
ソートとかして高速化は必須な気がしてきた。
それ考えると、配列のがいいかもしれないな。
俺はそこまでせずに作るの辞めてしまったけど。

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

>>327

管理タスクからタスクにアクセスする処理はどのようにしていますか？
参考にさせてください。
先頭タスクのから、順にたどっていくんですよね？
各キャラの移動タスクは独自のワークエリアに座標を書き込むとして、
当たり判定タスク等で、

　Temp = 先頭タスクのアドレス;
　while(Temp <> null);
　 {
　　Work = (EnemyRecord)Temp->WorkArea; //敵パラメータ構造体にキャスト
　　（各種処理）

Temp = タスク->次のタスクへのポインタ;
}

みたいな感じでワークエリアを順に取得して処理してるのでしょうか？

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

>>328

ですが、各タスクはタスク内で別の関数にチェンジすることを考えると、
タスク内での判定処理等はあまりよくない方法のような気が…。
実行優先度を自ら把握して管理することができれば問題ないでしょうけど。

>>329

用語がいまひとつわかないです(>_<)
実は、Delphiなんです ;>_<;

ゲームのためのシステムの構築となると、
参考資料が少なすぎて…（泣

やっぱりCですかね…。
CはDOSのTurbo C++でとまってます(--;

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

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