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

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

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

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

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

■ 前スレ

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

**名前は開発中のものです。** · 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++でとまってます(--;

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

>>331
管理タスクがタスクにする状況って例えばどんな時ですか？

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

>>333

316に対するレスだったんですが、

つまり、キャラの移動・当たり判定・描画を例にとると、
タスク処理の流れは、

　　１．移動タスク
　　　　（移動タスクはキャラクタ数分、存在し、
　　　　　各タスクは自分のワークエリアに座標を書き込む）
　　２．あたり判定タスク
　　３．描画タスク

となると思うのですが、
移動タスクでは、ワークエリアに座標を書き込みます。
そして、当たり判定タスク・描画タスクでは、各キャラの座標を参照して処理するわけです。

リンクをたどるということですが、
たぶん、次のようなことですよね？

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

>>332
ごめん、俺はDelphi全然知らんから文法に関する記述はなんとも言えんわ。
とにかく、タスクは目的ではなく手段なんだから、それに捕らわれてはいけないよん。

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

各タスク（ＴＣＢ）のアドレスがわからないと、ワークエリアを参照できないので、
　１．管理タスクが、登録されている一番最初のタスクのアドレスを返す。
　２．そのアドレスをたよりに、次々とタスクをたどっていく。

316のような方法にするには、
まず、先頭タスクのアドレスがわからなければ、リストをたどれません。
タスク管理クラスが先頭タスクのアドレスを返す処理をしないといけないわけです。

えーと、つまり、
外部から各タスクのワークエリアを参照するには、リストをたどる必要があるわけで、
そのリストのたどり方の実装の仕方を聞きたかったわけです。

わかりにくい説明ですね(>_<)

**delphian** · 04/02/08 22:15

ややこしいので暫定的に名前つけます(--;

>>335

329のクラスの読み方は、

class Character { //キャラクタークラス
　Vector2 m_pos;　//位置情報を持つ型の変数
public:
　Vector2 getPosition() { return m_pos; } //位置情報を返すメソッド
　virtual void move() = 0;　//オーバーライドして使う。移動メソッド
　virtual void render() = 0;　//オーバーライドして使う。描画メソッド
};

でいいでしょうか？
このクラスを継承して、各キャラクタのクラスを作るんですよね？

**delphian** · 04/02/08 22:18

>>335

class World {
　list<Character*> m_characters;　//各キャラクタクラスのリスト
public:
　updateOneFrame() { for(...); it->move(); }
　renderScene() { for(...); it->render(); }

ここで、for(...); it->move(); 等がわかりません。
delphiとの文法の違いによるせいだと思いますが。
各キャラクタクラスのmoveメソッドをすべて呼び出す、
ということなのでしょうか？

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

>>337
あと、俺なら、CharacterクラスはTaskクラスから継承させるけど、
この辺は、実装次第かな。

>>338
updateOneFrame() { for(...); it->move();
は、331と同じ意味です。
そもそも331でキャストする必要はないけど。
何か古いタスクシステムに頭が固まっているような。

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

>>337 は、合ってます。

>>338 は、ごめん、そこ面倒でかなり素っ飛ばしてた。
STL知ってることを前提で書いてたので…。正確にはこんな感じ。

class World
{
　list<Character*> m_characters;

　void moveAllCharacters() {
　　for( list<Character*>::iterator it = m_characters.begin(); it != m_characters.end(); it++ ) {
　　　Character* target = *it;
　　　target->move();
　　}
　}

　void checkCollision() { /* まあ適当に… */ }

public:
　void updateOneFrame() {
　　moveAllCharacters();
　　checkCollision();
　}
};

ちと具体的過ぎてアレだが、俺のプログラムは大筋でこんな感じです。

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

蛇足だけど、俺はCharacterクラスはTaskクラスからの派生じゃないと思ってるよ。
何故ならタスクとは「誰が何をするのか」ということで、キャラクタは仕事ではなく"誰"の部分。
だからCのタスクリストをC++のソースで移植するとしたらこうなるんじゃないかな。

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

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

class TaskList {
　list<Task> m_tasklist;
public:
　void executeAllTask() { for(...) it->execute() }; //また手抜き
};

タスクリストは仕事を保持しているだけで、オブジェクトのリストは保持していない。
全ての敵キャラや敵弾を参照したいときにタスクリストを使うとおかしな話になるのは、
この辺を混同してるのが原因かなーと思ったり。

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

その通りなんだが、
その誰が必要ない部分をタスクとして管理するわけよ。
そのための継承。
全てをタスクでするわけではないよ。

**delphian** · 04/02/08 23:16

>>340

ＳＴＬ、、、
見かけたことはありますが、よく知りません。
イテレータってのもよくわからない…。
ちょっと調べてきます。

ようは、つまり、、、
タスクシステムを持ちいらずとも、
リストとクラスを使えば、似たようなことができるんですね！！
しかも、この方法はオブジェクト指向という感じがします。

１．キャラクタークラスを作って、それをオーバーライドして、
　　各キャラクターをつくる。
　　キャラクターごとの動作、描画登録を記述する。
２．管理クラスを作って、
　　そのクラスがそれぞれのキャラクターなどをまとめて管理する。
（各キャラクタの移動メソッドと描画メソッドを呼び出す）

ということですね？

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

自機弾タスクの優先度を0x1000～0x1FFF、敵タスクの優先度を0x2000～0x2FFFの範囲に生成すると決めておいて

TCB* tama = 一番先頭のタスクのアドレス;
while( tama->prio < 0x1000 ){
　tama = tama->next;
}

TCB* enemy = 一番先頭のタスクのアドレス;
while( enemy->prio < 0x2000 ){
　enemy = enemy->next;
}

while( tama->prio <= 0x1FFF ){
　while( enemy->prio <= 0x2FFF ){
　　GameObject* t = (GameObject*)(&tama->work);
　　GameObject* e = (GameObject*)(&enemy->work);
　　if( hitcheck(t->rect,e->rect) ){
　　　t->hitflag = true;
　　　t->hitflag = true;
　　}
　　enemy = enemy->next;
　}
　tama = tama->next;
}

とか考えているのですがどうでしょうか？>334&>ALL

**delphian** · 04/02/08 23:31

>>344

やはり、そのように優先度で管理する方法が一般的ですかねぇ。
自分のタスクシステムは属性フラグを用意してあるので、
その属性フラグを使って処理することもできます。

このようなタスクシステムだと、
タスクのデータを保持したまま、
別のタスクにチェンジできるのがいいですよね。

>>340 >>341のような方法もオブジェクト指向という感じでいいですが、
チェンジタスクができないのが、唯一の難点のような気がします。

キャラクタごとにクラスを継承して作れば対応できる気もしますが、
どうなんでしょう。

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

二重ループのenemy = enemy->next;辺りがおかしいですね

それからこの板は古典的タスクシステム＝悪みたいな風潮があるようなので
趣味だけでひっそりやっていくことにします
さようなら

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

>>342
それは主語がない(クラスに属さない)処理が存在する、ということでいいですかね？

>>343
そういうことだと思ってます。タスクが目的ではなく手段だってのはそういうことです。

>>344
衝突判定中のenemyポインタを保存しといて各弾についてenemyを復元しないと駄目よん。

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

俺は古典的手法も悪くないと思うけどね。実用になればいいんで。
より直接的である、という古典的手法のメリットと富豪プログラミングの相性も良い。
古典的手法を飽きるまでやるのも入門に向くし。
飽きたら抽象度の高いものでちょっと頭をパズル向けに使って楽をすればよい。

いきなり理想論でたたみかけて初心者を煙に巻くのはオタクさんの悪い癖だ。

**delphian** · 04/02/08 23:53

とりあえず、古典的タスクシステムにしろ、オブジェクト指向のタスクシステムにしろ、
ようは、リストをたどって、各タスク（各クラス）を順に処理していくってことになりそうですね。

それで、当たり判定まではよいとして、描画でどうするべきか…。
描画は、同じく順にリストをたどって各キャラを描画していけばいいと思うんですが、、、
たとえば、当たり判定により自機と敵が衝突した場合、、、

古典的タスクシステムでは、自機タスクなり敵タスクなりを、
当たり判定のときに、チェンジタスクで爆発タスクに切り替えればいいですよね？？
と同時にフラグを立てて、
描画タスクでは、フラグによって描くキャラを変えればいい、んですよね？（＾＾；

>>340
のようなシステムの場合は爆発等に移行するにはどうすれば…

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

>>345
>>340のは出来ないね。オブジェクトの状態をオブジェクトの内部で保持してオブジェクトの内部でswitch。
>>341のは古典的タスクをC++に移植しただけなのでタスクチェンジできるよ。Task::m_workにメソッドを代入。

>>348
全くどの発言内容もご尤もだと思います。俺オタクだな…
ただこの方法が一番初心者に向いてると思うから書いてるわけで。
タスクってそれ自体はわかりやすいけど実際にコード組むと混乱の種にならない？
(実際に最初の質問の種はタスクから発生してるものだと思うし)

>>349
オブジェクトに衝突したことを知らせるためには、
オブジェクトにOnConflictという関数を持たせればOKだよ。
衝突したら、例えばこんな感じで。
enemy->OnConflict( shot );
shot->OnConflict( enemy );
後は各関数内で適当に状態移行。

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

>>341

あ、これはもしかして、次のようなことですか！？

Workerクラスを継承して、各キャラクタクラスを作る。
Workは各キャラクタクラス内で使う処理メソッド。

これらを含めてタスククラスとする。

Workerクラス内で変数等を宣言、各処理メソッドを必要数分書く。

処理の変更の際には、m_workのみを書き換えれば、
変数等を保持したまま、処理のみを変更できる。

実行、処理の変更等は、TaskListクラスが管理する。

ということでしょうか！？
文法がdelphiと違うので、はっきりとはわからないのですが、
もしかしてそういうことですか！？

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

>>351
大体合ってる。古典的タスクを使ってるなら馴染みやすいと思うんだけど…
補足するとTaskはTaskListに登録する際にハンドルとして受け取るような感じかな。
んでTaskクラスにsetWorkMethodが付くから処理の変更はTaskクラスでやります。
TaskListクラスにsetAllTaskWorkMethodみたいのを付けてやれば一気にEndとかもできる。

あと>>348にも言われちゃったのでどのやり方がいいとか言うのはやめることにします…

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

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