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

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

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

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

過去スレ，関連スレは >>2-3で。

■過去スレ
14機目 http://pc11.2ch.net/test/read.cgi/gamedev/1184110374/
13機目 http://pc11.2ch.net/test/read.cgi/gamedev/1173188370/
12機目 http://pc11.2ch.net/test/read.cgi/gamedev/1154792197/
11機目 http://pc8.2ch.net/test/read.cgi/gamedev/1149422610/
10機目 http://pc8.2ch.net/test/read.cgi/gamedev/1143038992/
９機目 http://pc8.2ch.net/test/read.cgi/gamedev/1134236719/
８機目 http://pc8.2ch.net/test/read.cgi/gamedev/1120669295/
７機目 http://pc8.2ch.net/test/read.cgi/gamedev/1110815882/
６機目 http://pc5.2ch.net/test/read.cgi/gamedev/1105176011/
５機目 http://pc5.2ch.net/test/read.cgi/gamedev/1098034919/
４機目 http://pc5.2ch.net/test/read.cgi/gamedev/1092048824/
３機目 http://pc5.2ch.net/test/read.cgi/gamedev/1087339516/
２機目 http://pc5.2ch.net/test/read.cgi/gamedev/1073736474/

初代スレ http://bbs.gamdev.org/test/read.cgi/gamedev/1056635103/

シューティングゲーム製作技術総合　その弐（避難所）
http://bbs.gamdev.org/test/read.cgi/gamedev/1073782910/

■関連スレ
シューティングツクールXPを待ち続けるスレ Part5
http://pc11.2ch.net/test/read.cgi/gamedev/1192682311/
PCで出来る2Dシューティング(STG)総合スレ46
http://game13.2ch.net/test/read.cgi/gamestg/1203080227/

■他
WIKI（シューティングゲーム製作技術総合）
http://gamdev.org/w/?%5B%5B%A5%B7%A5%E5%A1%BC%A5%C6%A5%A3%A5%F3%A5%B0%A5%B2%A1%BC%A5%E0%C0%BD%BA%EE%B5%BB%BD%D1%C1%ED%B9%E7%5D%5D
シューティングゲーム製作技術総合スレまとめページ
http://pcstg.s59.xrea.com/tech.html
ゲムデヴあぷろだ
http://gamdev.org/up/upload.php?page=1

OTU

>>1
□■□　...,,/
■□■￣",　　こ、これは乙だからね！
□□□乙/
　　　　　/

なにこれｗ

ボスＢＧＭが同じＳＴＧが多いのって何で？

何でそんなバカなこと聞くの

作るのがめんどくさいからにきまってるだろ

ボスBGMが無いSTGだってたくさんあるのに
そもそもボスがいないSTGもたくさんある

ステージは長い。つまりステージBGMは長く聞く。
ボス戦は比較的短い。つまりボスBGMを聞く時間は短い。

どっちを重視するか、の問題。


俺的参考例
ステージBGMが多く、ボスBGMがひとつのSTG……グラディウス
ステージBGMがひとつで、ボスBGMが多いSTG　……スペースハリアー
ステージＢＧＭも、ボスＢＧＭも多いSTG　　　　……ダライアス

ＳＴＧにしては最近で、ボスも演出こだわってそうなゲームも
ボスＢＧＭが同じだったりするし
なんか心理学的な理由があるんじゃね？

RPGの雑魚戦の曲とかね
違和感のある曲だと辛い辛いｗ

BGMは場面に関連付けるものだから
ボスとか道中とか関係ない

ボスの個体のテーマ曲があってもいいじゃないかと思ったこともある。
道中は面の曲でライバルならライバルの曲、再登場するたびにアレンジが変わったりさ。

特攻空母ベルーガ

http://www.nicovideo.jp/watch/sm1859220

>>14
日本語でおk

めんどうくさい。

>>18
BGMはどう使ってもいいのではないか
道中もボスも共通のBGMにしてしまうのもアリ
道中にもボスにもいくつものBGMを使うのもアリ

>>20
そういう意味か　把握した

釣りじゃないなら言葉遣い自重

>>22
日本語で(ry

前スレ落ちてたのか…。

好き嫌いによると思うけど･･･
ファミコンのギャラクシャンみたいなゲームを作るとしたら
オブジェクトは
自機。敵。自ショット。敵ショット。ってあるけど
classはどういう風に定義します？
今まで
自機クラス、敵クラス、自ショットクラス、敵ショットクラスってやってたけど流石に細かすぎかと思って
どうすれば、いいのかなと思って質問させていただきます
ていうか、ゲームの規模によっても分け方違ったりするんでしょうか

普通に全部分けるだろう上皇
煩雑に見えるかもしれないけど、大規模になるにしたがって恩恵が出てくるよ。

そうなんですか。。。。ありがとうございます。
聞かなかったらステージクラス作って全部突っ込んでたかもｗ

ライブラリのIrrlichtかLuna使ってる人いる？
これからC++と合わせて作っていこうと思うんだけど
気をつけたほうがいいことってある？

どっちもイイものだから是非使うといい。俺はDXライブラリ派だけどなｗ
イアリヒトは3Dゲーには素晴らしいが簡易な2DSTGにはややオーバーキルな
気がしないでもないかもだが。まぁ一度要領覚えちゃえば関係ねーだろ頑張れ

>>29
まとめ見たらなんか良さげなんだけどチュートリアルがさっぱり分からん
DXライブラリは3D対応になったみたいだね

どっちでもいいといえば どっちでもいいのですが、
現在ゲームを作ってまして、敵の動きを実装するのですが、
C言語で関数のポインタを保持し、タイミングが来たら 保持していた関数を呼び出すのと
C++で、基本のクラスを用意し、それから派生してポリモーフィズムで呼び出すのと どちらが良いでしょうか

開発規模は個人なのでそれほど多くならないです、ですがまだ、仕様が決まってないのでなんともいえないのです。

なにが不満かというと
Cだと 関数だらけになってしまう
C++だと 開発に時間がかかったら保守が大変そうなことです

498デフォルトの名無しさん2008/03/07(金) 08:49:37

どっちでもいいといえば どっちでもいいのですが、
現在ゲームを作ってまして、敵の動きを実装するのですが、
C言語で関数のポインタを保持し、タイミングが来たら 保持していた関数を呼び出すのと
C++で、基本のクラスを用意し、それから派生してポリモーフィズムで呼び出すのと どちらが良いでしょうか

開発規模は個人なのでそれほど多くならないです、ですがまだ、仕様が決まってないのでなんともいえないのです。

なにが不満かというと
Cだと 関数だらけになってしまう
C++だと 開発に時間がかかったら保守が大変そうなことです

どっちでもいいといえば どっちでもいいのですが、
現在ゲームを作ってまして、敵の動きを実装するのですが、
C言語で関数のポインタを保持し、タイミングが来たら 保持していた関数を呼び出すのと
C++で、基本のクラスを用意し、それから派生してポリモーフィズムで呼び出すのと どちらが良いでしょうか

開発規模は個人なのでそれほど多くならないです、ですがまだ、仕様が決まってないのでなんともいえないのです。

なにが不満かというと
Cだと 関数だらけになってしまう
C++だと 開発に時間がかかったら保守が大変そうなことです

どっちでもいいといえば どっちでもいいのですが、
現在ゲームを作ってまして、敵の動きを実装するのですが、
C言語で関数のポインタを保持し、タイミングが来たら 保持していた関数を呼び出すのと
C++で、基本のクラスを用意し、それから派生してポリモーフィズムで呼び出すのと どちらが良いでしょうか

開発規模は個人なのでそれほど多くならないです、ですがまだ、仕様が決まってないのでなんともいえないのです。

なにが不満かというと
Cだと 関数だらけになってしまう
C++だと 開発に時間がかかったら保守が大変そうなことです

そんなに暇ならこれでも見ていやがれ
http://www.nicovideo.jp/watch/sm2258805

IDがogg
歌っちゃおうかな〜
UGA
UGAUGAUGA
カラオケ
UGA

けっ素人童貞の群れか ここは

誰か相手してやれよ

つかえねぇゴミ蟲

そう言うな･････。
個人製作なんしょ
自分で管理しやすいほうにすればいいんだよ
ゲーム作ってくうちにそういう局面はいくつもある
何通りも何十通りものやり方から一々２ｃｈでレスきいてたんじゃ全然進まないぜ
まぁ最近このスレは過疎っているから変なの沸いてるのは許して欲しい

どっちでもいいんだったら
好きなようにしろとしか言えんしなぁ

>>37
悪口って、
自分が言われて痛いことをつい言っちゃうんだってさ

このイケメンどもめ・・・っ！！

みんなに言われる

弾が消失したときの処理ってどうしてます？
Class Ammo{　　　//弾のクラス
〜〜　　　　　　　　//弾のデータ
static int Num //弾の数
}Ammo[N]

として、弾Ammo[i]について判定して、敵にあたるなどして消失したとき、
Ammo[Ammo::Num]をAmmo[i]に代入し、Ammo::Num--する
で、もう一度（代入後の）Ammo[i]について判定する
としているんですが、リストとか使った方がきれいでしょうか？

弾に限らず敵でもなんでも当てはまるな
俺ならリスト使うけど

それよりもAmmoクラスに弾の数を入れるのはちょっとおかしくないか
Ammoを委譲するクラスを作って、その中で弾数を管理した方が・・・

class AmmoContainer {
　std::vector<Ammo*> ammos;
public:
　int get_ammo_num() { return ammos.size(); } // 弾の数を返す
};
とかさ

なるほど、確かにその方が綺麗ですね
自機の弾と敵機の弾でクラスを分けていたのですが、弾のクラスをひとつにして、
MyAmmoContainerとEnemyAmmoContainerのメンバクラスにすることで、区別してみようと思います

ただ、自機や敵機との衝突判定があるので、
＞std::vector<Ammo*> ammos;
はprivateじゃなくpublicの方がいいように思うのですが
（privateだと自機クラス、敵機クラスから見えませんよね）

わざと見えないようにしてるんだ
提案のための単純な例として書いたから端折ったけど
publicなメソッドとしてアクセサなどを用意するのさ
そこは俺の趣味なので、自分の思うように作るのがいいと思うよ

>>48なるほど
極力メンバ外からメンバ内部を直接参照しない方が、
オブジェクト指向っぽいですし、管理もしやすそうですね
その方向で作り変えてみたいと思います

BASIC人なんで、現状staticな変数使いまくり、
構造体もクラスも最小限なアレなプログラム組んでるもので

そしてゲッターセッターだらけのウンコクラスを作って
ゲロ吐いて人間は成長する

友達が作ったクラスにゲットセットが12個以上あって見る気失せた事があるな

クラスに含むものは最小限にして、
単なる変数の分類代わりにしているのは俺だけか

俺なんてC++をBASICみたいな使い方しかしてないぜ。
クラス？　なにそれ？

まぁstructでもメンバ関数作れるしな

クラスの中でクラスをインスタンス化できるから、下記のような構造に

ゲーム世界クラス
　├プレイヤー陣営クラス
　│　├プレイヤーキャラクラス
　│　└プレイヤーの弾クラス(弾クラスを継承)
　├敵陣営クラス
　│　├敵キャラクラス
　│　└敵の弾クラス（弾クラスを継承）
　└当たり判定クラス（staticな関数のみ）
※キャラと弾は全て基本オブジェクトクラスを継承

作りすぎかも。陣営クラスはいらないかなぁ

なお、ふたつの陣営クラスは
弾クラスと弾処理メソッドをメンバに持つ陣営クラスを継承している

可読性が酷いな

is-aとhas-aは区別したほうがいいって
Rubyのお兄ちゃんも言ってたよ

An apple is a fruit.
→appleはfruitの性質と独自の性質を持つ
→appleクラスはfruitクラスを継承する

A car has an engine.
→carはengineを持つ
→carクラスはメンバengineを持つ

って感じか

>>55
ウチはこうかな

シューティング管理クラス
｜
├Unitリストのリスト
│　├０リスト　（プレイヤーリスト）
│　├１リスト　（自機弾リスト）
│　├２リスト　（エネミーリスト）
│　├３リスト　（敵弾リスト）
│　├４リスト　（エフェクトリスト）
│　├５リスト　（ボム効果リスト）
│　└７リスト　（その他特殊用リスト）
└敵出現データ管理クラス

Unitは基本クラスのことね。
プレイヤー陣営とか敵陣営どころかプレイヤークラスや敵クラスの雛形が無い。
弾のクラスはあるけど、シューティング管理クラスから見た場合はUnitを継承していればいいので関係ない。
後々Unitリストの種類を増やすことを想定して、Unitリストをリストで実装してる。

ホーミング弾ってどうやって作ってる？

プレイヤーオブジェクトからホーミング弾発射
→弾に目標のエネミーオブジェクトのポインタを渡す
→エネミーオブジェクトの座標めがけて飛ぶ
こんな感じかな？

でもこの場合、プレイヤーオブジェクトは
エネミーオブジェクトのリスト（のポインタ）を持っている必要があるな
なんかもう全部オブジェクト外（STG管理クラス）で処理するのが楽に思えてきた

STG管理クラスをシングルトンにして直接参照する
オブジェクト指向っぽくないけど、一番楽な方法じゃないかな

弾つながりでちょっと質問です

ｱﾙｺﾞﾘｽﾞﾑﾏﾆｱｸｽパラ見したんだけど
反射ﾚｰｻﾞｰの反射部分ｸﾞﾗﾌｨｯｸってどう処理してるの？

　＼／　　‥ﾚｰｻﾞｰ
━━━━‥壁
　　↑
　　ｺｺ

本だと＼の先端と／の後端を壁にめり込ませている
でもそれだとめり込んだ分、全体の長さが縮むと思うんだ

考えたけどわからない・・
反射部分だけ別ｸﾞﾗﾌｨｯｸ？

>>60
STG管理クラスのインスタンスと、Unitを継承したインスタンスを相互参照になるように作る。
STG管理クラスに指定したUnitリストを取得できるようにしておく。
（自分の座標と、指定したいUnitリストのindexを引数にし、最も近いUnitを戻り値に返すメンバ関数でも可。
というか使う機会も多いので推奨。）


自弾→敵機の場合、管理クラスのメンバ関数に敵のUnitリストを指定して、最も近いUnitを返してもらえばいいし、
敵弾→自機の場合、同様にして自機のインスタンスを返してもらえばいいよ。

こうすれば目標の座標は取得できるから、後は適当に誘導するような処理を記述すればおｋ。

>>59=63
そういうクラス構造してると、
たとえばエネミーはメンバ変数HPを要るけど、エフェクトや弾は要らないから、
UnitクラスにHPがあると、エフェクトや弾に無駄なメンバ変数が生産されない？

エフェクトたんやバレットたんだって命ある生き物です＞＜
　

正確なレーザーを表示したくてグラディウス外伝が作れるか

？？

>>64
ウチの場合Unitは完全な抽象クラス。実装が一つも無い。つまり抽象メンバ関数しかないのさ。
で、メンバはこんな感じ。･･･と思ったが、こっちはC#だからint配列とか戻り値に指定するのは直感的だけど、
C++だとちょっとめんどいな。やり方わからんから適当に察してくれ。


Stg管理クラス　GetOwner()
float　GetAttackPower()
int　GetBelongKind()
VECTOR3　Get/SetPosition()
int[] GetTargetKinds()　　　　　// C++の場合はどうすりゃいいんだっけ?覚えてないや。
VECTOR2　GetTouchRange()

void Act()
bool CanExist()
void Fire()
bool CanStand(Unit toucher)
void Indicate()
この5つは上から順番に、
動作管理、
デストラクタ対象判定、
動作管理で射撃判定boolを作っておいてそれを利用した処理を、
描画処理

4つ目の補足書きわすれたｗｗ
CanStand　は当たり判定をStg管理クラスのインスタンスが行い、あたった時Stg管理が呼ぶ関数。
たたった相手のインスタンスを引数として渡してくる。

座標とかの管理はどこで？

>>70
Stg管理クラスがRectangle（x、ｙ、width、heightで矩形を表す構造体）を何種類か保持してる。
そして各UnitオブジェクトのPositionが、CanExistで矩形の中にいるかを判定してるだけ。

弾同士の相殺判定つけたら処理落ちしてワロス
いい加減当たり判定の方法を最適化して、
オブジェクトの配列をvectorからlistに変えるべきだな

総当りでやってるから重たいってだけの話でねの？
コンテナがvectorだろうがlistだろうが総当りは回避できるべ

と寝る前にエスパーレス

>>73
とりあえず次のことを行ってないかチェックすべし。
Vector変数　−　Vector変数　などの構造体同士の直接演算。ちゃんとメンバをそれぞれ計算するべし。
int4つ分相当超過の構造体/クラスの値返し/値コピー等。　参照渡しのほうが高速。

レスミス。>>73じゃなくて>>72

exceptionが弾（破片）同士の衝突判定やってたな
あれは単純なマス目状の空間分割とマルチスレッド化で高速化してるぽい

しょうもない愚痴にレスくれて�dｸｽ

>>73
一応、自機、敵機、自分の弾、敵の弾、アイテム（、エフェクト）で配列を分けてる
>>76のいうように、空間分割した方がいいかもしんない

>>74
大丈夫なはず

空間分割はともかくマルチスレッドはどうなんだろうか・・・
クアッドコアなら効果ありそうだけど。

ウチの環境だと、CoreSoloってこともあってかほとんどマルチスレッドは効果が出なかったな。
処理内容によって早かったり、かえって遅くなったりまちまち。
CoreDuoとかだと普通に恩恵が得られそうだけど、そんなPCならGPUもよさそうだしなぁ

マルチスレッド興味あるんだが、マルチスレッドを前提にした設計の仕方が思いつかん。
ゲームオブジェクトを非同期に更新する上手い方法なんかないかな。

FPSとかは知らないけど、2DSTGでマルチスレッドが有効利用できる
場面って少なく無いか？
総当り系の判定をスレッドに割り振るのも大変そうだし。

ローディング画面でディスクアクセスしながらアニメーション流す位しか
思いつかないんだが、他になんかある？

ジオメトリウォーズのエフェクトや背景はマルチスレッドで処理してるとどっかに書いてあったような。

エフェクト類は他のオブジェクトに干渉しないのも多いから、
そういうのはまとめておいて別スレッドで処理すればいいかもしれん。

>>80
DDR2メモリ4GBが数千円で買える今なら大声で言える

ゲームオブジェクト全てをダブルバッファリングだな
フレーム(t)バッファはリードオンリー
フレーム(t＋�冲)バッファはライトオンリー
オラ(t+�冲) = オラ(t) + (世界(t)がオラに元気を分けた。差分)(�冲) + (オラのパワー。差分)(�冲)
差分スキームは好きなの使え。ここでは単に一次オイラー

同一フレーム内オブジェクト同士の相互参照は一切ないから
更新順序も排他アクセスも一切不要
メモリが2倍要るという欠点は先述のPC環境なら無視でいいだろ

動作環境
　メインメモリ1GBで動かない時は2GB積んでみてください
　メインメモリ2GBで動かない時は4GB積んでみてください
　…etc…

あなた起動時に全ての画像読み込んでそうですね
俺はちまちまやってます

富豪厨の俺でも流石にそれはないが
ステージ単位でドカっと読み込んでる
boost::progress_displayのゲージがジリジリと動く様を
ティーカップ片手に優雅に待てば良いのだ

それすら我慢できない低属性プレイヤーはrejectだ

はいはい、boostスレに帰ろうなｗ

敵弾をCPUごとに振り分ければよくね。どんな鬼畜弾幕になるのか知らんが。

弾同士が干渉しないならそれが良さそうだが、
2DSTGで複数コア使う必要があるような処理って弾同士の干渉くらいな気がする。
>>83は汎用性あって良いかもしれん。

＞敵弾をCPUごとに振り分ければよくね

よく分からんが
2DSTGでゲームオブジェクトを並列化しようって話をしてるなら
エフェクトや弾が真っ先に候補に上がるのはごく自然なことだよ
エフェクトや弾同士は相互作用が基本的に無いから実装も単純

レスがかぶっちった

２Dシューティングを作りたいなと思ってここにたどり着いたのですが、
フリーソフトで何を使えば一番簡単に始められますか？

HSP

STGビルダー

両方捨てがたいな

>>92-94
ありがとうございます。
両方調べて出直してきます。

ゲーム中のオブジェクトの基本となるクラスがあるとして、
そのクラスの配列を作り、メンバ変数でオブジェクトの種類を区別するか、
そのクラスへのポインタの配列をつくり、放り込む派生クラスの種類で区別するか
どっちのやりかたで作ってる？

前者の方が複雑なポインタを考えない分、簡単かもしれないけど、
後者の方がオブジェクト指向的に綺麗かなぁ

判定アリ背景（接触しても死なない）の処理がとてもめんどうなんですが
こういった処理をしている方、どんな風にやってますか？

どういう処理にしたいのかもうちょっと詳しく

すみません
・接触しても死なない/めり込まない
・縦の壁に対して斜め入力をし続けると、空いてる方向に移動する
・スクロール等で壁が移動する場合、キャラは押される
・画面端に挟まれると死ぬ
こんな感じです
2番目3番目がさっぱりです

2は横移動先が壁にめり込んでたらめり込んだ分横に押し戻し
3はスクロールしてめり込んだらめり込んだ分スクロール方向に押し戻し
とか

２は普通に作ればたいてい空いてる方向に移動すると思うぞ
要するに、キー入力方向に壁があったら、その方向の移動量をゼロにする
あと、地形を重視するなら大きなマップの中で視点がスクロールすると考えるといい
一度アクションゲームを作ってみるといいよ
4点とも簡単に解決できる

ありあとうございます。

>>100
今やっているのだとそんな感じなのですが、斜めの壁のとき
おかしくなる気がします。X方向とY方向を別々に判定してるんで
順番によっても変になってる気がします。

>>101
その場合先に壁と隣接しているかどうか判定するのでしょうか
今考えてるやり方だとめり込んでから戻すって感じなのですが。

>>102
縦壁だけじゃなく斜め壁もあるのか
そしたら斜めの当たり判定のとり方から説明が必要？

それとも壁の角に斜めにぶつかった場合ってことだろうか
>>100はx方向を先に判定すれば壁の角から横に進むしy方向なら縦だし
どっちにも進みたくないなら別の処理が必要だし

どっちにしてもどういう挙動がおかしい挙動なのか仕様がわからいとなぁ

めり込んだら押し戻すで全部解決するはずだがなあ・・・
接触判定がおかしいんじゃないのか？

>>102
「壁ずり」で検索

当たり判定ってどんな形にしてる？
円形または矩形で統一するのが楽だけど、
円形だと細長い弾やレーザーが、矩形だと斜めの弾の表現が難しい
複数の矩形とか？

俺は基本的には矩形以外使わないな
ところで斜めの弾ってなんだ？

俺は楕円にしてる

矩形だけだな
斜めは回転で対応

斜めの弾＝斜め方向に飛ぶ弾、斜め方向に長い弾
矩形だと見た目とずれるし、矩形を回転させるのは手間。楕円も同じ
円形だと、斜め向きでも縦向きでも
尖がった部分に当たり判定が無いのは共通だからまあマシかな、と

円形で細い弾は作らない。

>>110
針弾のこと？
矩形回転くらいやんなさいよｗ
それが面倒なら針弾なんか使わなければいい。
丸い弾だけなら正方形判定だけで出来る。

俺は斜めだろうと楕円だろうと何だろうと正方形で済ませてるど素人です。
自分でプレイしてて全然気にならないんですが、
やっぱ弾幕シューとかだと重要なんでしょうかね。

自分は緻密な弾避け行為にこだわってないから解んないけど
そういうのが好きな人は違うのだろうか。

まぁ、好きな人はそういう仕様まで利用していくから良いと思うよｗ

弾幕目の敵にしすぎﾜﾛﾀ
弾幕ゲーじゃなくても、見た目と違うあたり判定はどうも嫌いだな
某同人弾幕ゲーは見た目と当たり判定の乖離がひどいが

俺は矩形の当たり判定を複数持たせて近似している
地面とかは円形だとうまく表現できないし
本当はビットマップを走査して判定したいけど、さすがに重過ぎる

線分交差判定か何かでいいんじゃないか

見た目と違うというが、昔からゲームやってる人間なら
むしろ見た目どおりの判定のほうがおかしく感じるハズだｗ

何回もやってりゃなれるしな

自機の当たり判定が点なのに
弾の判定が見た目と違うと文句をつけるのもおかしな話だ

んだな

針弾の当たり判定オブジェクトが矩形（正方形のAABBの数珠繋ぎ）でも
判定が甘め（針弾イメージからAABBが飛び出ない）なら俺は気にならん

だが矩形回転（OBB）が面倒とかいうのも
ちと情けないというか。高校レベルの算数だろ

あと針弾をAABB数珠繋ぎでやるくらいなら
円の数珠繋ぎのほうがマシな気がしないでもない

>>120
×算数　○数学

回転矩形同士の当たり判定は結構面倒だと思うが
難しいんじゃなくて面倒

STGスレだから
OBB vs 点 の判定という前提で
簡単と書いたったのゆーしてくらはい

俺は先端に矩形を一個だけｗｗ
手抜きサーセンｗｗｗｗｗ

それで良いんじゃね

難しいとか面倒とかでもあるけど
比較的どうでもいい事に処理を食わせたくないという旧い人間な俺。

たとえば中型のプロペラ機の機体後部とか尾翼とかに判定なんか要らんのですよ
主翼部分だけで良いんです

>>115
どうでもいいけど、確かひとつのオブジェクトに複数の当たり判定を持たせる、
という方法はセガが特許をとっていたはず

知らんがなそんなもんｗ

>>128
3Dオブジェクトの周りに球形の当たり判定を複数つけるというのがセガの特許だから
2Dなら大丈夫なんじゃないか？

そんなんで特許取れるのか……。

＞特許3603898
＞特開2003-299877
＞交差判定方法及びこれを用いたゲーム装置

この辺かなぁ

これ普通に既知・公知の基本技術だよねぇ
趣味野郎にとっては完全無視しても事実上無問題の話だけど
ゲームで飯食ってるその手の業界の競合他社の法務部門は
こういうナメた特許を取られて異議申し立てもせずに
完全スルーしてて大丈夫なのか？タダ飯食って寝てるだけだろ

アメリカで「入力装置による操作で画面の絵が動く」とかいうサブマリン特許で
ゲームメーカー各社が訴訟起こされたりしたからな。そこら辺は防衛手段だと思われ。

もういっそ
「誰でも考え付くくだらない技術で特許を取る方法」という特許を取ればいいのに

普通に矩形判定の回転とかやり方が思いつかない理系の俺はどうしたらいい？

回転した矩形の衝突判定なら、多角形の衝突判定でいいと思う

>>135
中学生？

敵キャラの基本と思ってスライムを作った


あー、STGの空飛ぶ世界でスライムって使いどころが……

横シューでグラVのバスクリン見たいに落ちてくるとか

>>137
えぇ。適当にベクトルの式の立てて解くっぽいことしか想像できないｗ
しかもやり方わからんし
数Cもっとまじめにやるんだったかな・・・ちょっくら高校の教科書とにらめっこしてくる。

一方がもう一方に入り込む可能性を無視するなら、各辺が交わっているか判定する
入り込む場合は、一方の頂点がもう一方の領域に入っていることを判定する

頂点が領域に入っている判定は、
矩形に限定するなら、座標変換した後、普通に矩形と頂点の判定をするとか
凸多角形なら、辺と頂点の位置関係（常に頂点が辺の左側にあるか）を判定すればOK

こんな感じ？

>>139
背景の当たり判定考えてないんだよねぇ
何か土台でも作ろうかな

ライフゲージをスライムの大きさで表示
そしてアイテムは全部スライム

普通に地上キャラでスライムだせばいいのでは・・・

接触したら、コマンド入力方式戦闘シーンに突入すればいいのでは……。

ゲーム中の物体は全てオブジェクトで、
登場するたびにnewでメモリ確保してlistに突っ込んでるんだが、
newは自重したほうが速度的に有利なのかな
いまどきのPCなら問題ないよ・・・な？

そのぐらいの最適化、ちょっと手を加えれば済むんだからやっとけよ
プールして再利用、あとは事前にまとめて確保しておけ

遅くなりましたがいろいろありがとうございました
今試行錯誤中です

>>141
まさにその形で組んだ所だったよ。

内包する場合も141と同じ方式。
前にどこかで拾った式コピペしときま。外積使って頂点が左にあるか。を求めてるのかと。


828 2008/01/25(金) 18:20:24 ID:wCWKO3oH
名前は開発中のものです。(sage)

四角形ABCDと点Pの当たり判定
(Px-Ax)*(Py-By)-(Py-Ay)*(Px-Bx) > 0 and
(Px-Bx)*(Py-Cy)-(Py-By)*(Px-Cx) > 0 and
(Px-Cx)*(Py-Dy)-(Py-Cy)*(Px-Dx) > 0 and
(Px-Dx)*(Py-Ay)-(Py-Dy)*(Px-Ax) > 0
の時は当たり

>>146
ぶっちゃけSTGに可変長配列は要らないな
オブジェクトの配列を最初にまとめて確保して、存在フラグをメンバ変数に持たせる
派生クラスも作らないで、オブジェクトの種類はメンバ変数で管理

ぜんぜん美しくないけどな

オブジェクトのプールってどのように実装しているんでしょうか？

まとめて確保したオブジェクトのポインタをstackに積んでおいて
取り出したり使い終わったら戻したりみたいなやり方と
プールのlistと使用中のlistでやりとりするみたいなやり方
を思いついたんですけど・・・

もっとかっこいいやり方あるんでしょうか？

STLは使って無いんだけど、後者と同様の事をしてる。

任意サイズメモリを確保してそれをローカルヒープとして管理し、
そこからAlloc/Freeってのをやってたこともあったけど、可変サイズに対応可能だけど
メモリ管理ブロック分がもったいないとか、微々たるものだが処理コストが気になる、とか一長一短。
PCなら気にしなくてもいいかな？

PCなら気にする必要は全く無しというのが俺の実験結果
ボス、弾、破片(パーティクル)に至るまで一個一個new(LocalAlloc)してdeleteして
24時間デモシーンをぶん回しても異常なしだったんだぜ

物理演算とか相当煩雑な処理させない限り、
現在のPCの処理速度では最適化の意味がない、ってのは常々言われてるな
処理速度より、生産性とかソースの可読性とかを優先していいと思われ

自分も今はそのままnewを使っているんですが
同じ動作をするなら少しでも軽いほうが精神衛生的に良いかなと。
処理もそんなに難しそうじゃないし。

まあ、一人でしこしこ作ってるので自分が納得できるようにやります。

それが一番だな。＞自分が納得

俺は配列で確保してる

クラスのサイズがバラバラだから、使いまわし出来ないなぁ
最大サイズで確保するのはなんか癪だ

しかし最大サイズで確保するのが最も現実的な罠
断片化を抑えるために色々小細工してるから遅い、という原因には効く

>>157
＞癪だ
富豪厨の俺に言わせれば
boost::simple_segregated_storageでガバッと確保して固定サイズでジャブジャブ融資
原資（メモリ）が足りない？そんなしみったれた貧弱PCユーザーは今すぐrejectだ！

アジャイル、ＵＭＬ，オブジェクト思考、階層化・・・
色々悩ませてくれたが・・・俺は最大の手段を使うことにした


そ れ は ・ ・ ・





goto文

>>157
使いまわせるように作るんだよぅ

単純な直進弾や自機狙い弾と、
ホーミング弾や複雑なAIを持った敵機で、
必要なメンバ変数の数が違うんだよねぇ

で？みたいな（笑）

>>162
3DSTGの敵機に編隊飛行、指令送受信、策敵、射撃、回避、離脱、体当たり
こんだけ積み込んでおおよそ64[Bytes/Instance]
ブースターだの脱出ポッドだのバリoートだのフライ○グアーマーだのといった
子インスタンスを加えても合計128[Bytes/Instance]を上回ることはなかった
誘導弾は64[Bytes/Instance]以下
直進弾は32[Bytes/Instance]以下

敵機200機の飽和攻撃により誘導弾800発と直進弾2000発
合計3000個のインスタンスが画面内を乱舞するとする

割り当て方法は全部同じプールでも別々のプールでも
インスタンス毎にnew(HeapAlloc)でも好きにしたまえだが
毎回HeapAllocだと管理領域分も考慮しなければいけないので
ここでは話を単純化するためプールとする

富豪厨は太っ腹なので全て128[Bytes/Instance]の固定サイズで
湯水のごとくアロケート

種類　　　ｻｲｽﾞ(使用ﾒﾓﾘ)　個数　ｻｲｽﾞ合計　使用ﾒﾓﾘ合計　無駄使い
----------------------------------------------------------
敵.　　　　 　 128(128)　　　　200　　　25600　.　 25600　.　　　 　 　 0
誘導弾　　　　64(128)　　　　800　　　51200　　102400　.　　　 51200
直進弾　　　　32(128).　　　2000　　　64000　　256000　　　　192000
----------------------------------------------------------
合計　　　　　224(384)　　　3000　.　140800　　384000　　　　243200

敵、誘導弾、直進弾、別々のプールから割り当てる場合と比較すると
3倍弱のメモリを使用して約243KBを無駄にすることが分かる
これを「に、243KBも！（#@Д@）」とするか
「たったの243KBで騒ぐ貧乏人はrejectだな」とするかは
各人のエンゲル係数や可処分所得に左右される大変デリケートな問題
ここではあえて言及しないことにする

以上

×　約243KBを無駄にする
○　約237KBを無駄にする

>敵機200機の飽和攻撃により誘導弾800発と直進弾2000発
>合計3000個のインスタンスが画面内を乱舞

これは酷いな。生きのこれる気がしないぜ

一昨日PC2 6400 2GBx2を8000円で買ったんだが
243200バイトの損失なら
8000 * 243200 / (1024^3 * 4) = 4.53E-01
たった45銭3厘の損失かぁ



MSXの32KB拡張RAMカートリッジ、高かったなぁ（遠い目

もまいらいったいいくつから作ってるんだ？

パピコンでBASICゲーム作ってたのは中学んときだけど、
まがりなりにもシューティングらしきのを作ったのは高校ん時だったかなぁ。
やはりパピコンのBASICコンパイラ＋表示部分だけマシン語（ハンドアセンブル）で。

あの頃からほとんど成長してないのは正直どうかと……ｗ

>>169
もまいの故郷

goto文を恐れなく使う兵達のスレ
http://pc.2ch.net/tech/kako/1021/10213/1021364372.html

真の富豪厨は毎回new/deleteだろ。

やった(>>152=俺)が、余りにもアッサリとうまく動きやがったので
面白くないからrejectしてやった

3Dで敵機64バイトって小さすぎない？
姿勢情報とかでどうしても容量デカくなりそうだけど

変位（座標）と回転の情報を4x4行列にぶち込んでればそりゃブクブク膨れ上がるだろうけど
回転にクォータニオンとか使ってれば2要素増えるだけだぜ？（圧縮すれば1要素増加で済む）
変位のほうは単純にz成分（1要素)が加わるだけ

結局、姿勢情報はfloat値6個（24バイト）もあれば十分表現できる
後は速度情報を加えて計48バイトとか

まぁ普通はそんな感じじゃね？

＞変位（座標）と回転の情報を4x4行列にぶち込んでればそりゃブクブク膨れ上がるだろうけど

うっ、それまさに自分だ。。。
クォータニオンか。。。D3DXで提供されてるから素直に使ってみるか

レス�d

そうかなぁ
4x4行列をジャブジャブ使ったほうがある意味で爽快かもよ

>>172
なんという俺

そ、そういう発想の転換もアリだよね、ね
PCならこの程度何の実害ないし
クォータニオンはまたその内検討してみまつ。。。

すまんこアンカー忘れ。>>177だた

>>177
おまいもうboostスレに帰れよｗ

どうもお邪魔しました！

＿＿＿＿___　　　　boostｽﾚの　　　　　STGｽﾚの
|←boostｽﾚ|　 　 　 　 中の人　　　　　　中の人
.￣.||￣￣￣　　　　　　 ┗(^o^ )┳(^o^ )┳(^o^ )┛≡＝-
　　||　　　　　　　　　　　　┏┗　　┗┗　　┏┗　≡＝-
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

絆スキップ

>>175
＞ブクブク膨れ上がる

常日頃からメタボメタボ言われまくってる俺の
センシティブなハートをお前は深く傷つけたよ

メタボ臭とかいう新ジャンルのSTGを開拓すればいんじゃね

それ何てミクロの決死圏
血管の中で中性脂肪の弾幕でもかわすのか？すげぇ既視感あるネタだけど

泡状のとかブニョブニョしたものを描くの面倒臭そうだな
昔のメガデモでよくみかけたMETABALLみたいな手法を使えばいけそうだな


オヤジギャグじゃないからな

ﾒｶﾞﾃﾞﾓ（笑）
ﾒﾀﾎﾞｰﾙ（笑）

オッサンばっか（笑）

メガデモのメタボールの仕組みよく知らないんだが、あれって

　濃度を格納したボリュームデータを用意して
　ある濃度をしきい値にして面を張る

みたいな、ベタなやり方だったのかな
10年近く前にクラシックペンティアム積んだPCでぐりぐり動いてた
ような記憶があるんで、上記の手続きだと（特にボリュームデータの
更新、というかアニメーション？あたりが）かなり重たいものになりそうだし
やっぱ何らかのトリック（フェイク）が使われたのかな

あ、ソース公開されてる作品あるからそれ覗けばいいだろってのは分かってる
話題がないのでなんとなくネタ振りということで・・・

グニャグニャ（連続体？）オブジェクトが出現するSTGとか作ってみたいし

ム板のメガデモスレ池
マジレス

>>188
ソフトレンダもので初代Pentiumでぐりぐり(60FPS以上で)動いてたなら
スクリーン解像度は400*300とか320*240程度だったはず
濃度値を収める三次元格子もかなり荒かったんじゃないかなぁ

濃度値の精度は8ビットで格子数は16*16*16=4096バイトとかで十分
この程度なら当時でも余裕で処理できたはず

つか、今時のビデオカードで2DSTGでメタボールっぽいキャラ出すなら
パーピクセルで描ける
法線マップとアルファ付きカラーマップにぼやけた円を重ね描きしていって
アルファテストで閾値設定して描けば立体感（光沢付き）ぷよぷよだよ！
DirectXのSDKにもそんな感じのサンプルが入ってたはず

背景が黒いなら加算合成で出来ちゃうんだけどな。

メタボはメタボールの略だったのか。

メタルボーク発進

質問
CGってグラフィックボードで描いてるんだよね？
ハード的な理由で描画はマルチスレッドみたいになるの？
てことは、処理落ちの原因はほとんど当たり判定とかのせいになるの？
ということは、当たり判定をマルチスレッド分担すればいろいろ完璧？

今時、当たり判定程度で処理落ちするCPUはない
プログラムにむちゃくちゃ無駄が多かったりしない限り

3Dならポリゴン数が多いと、GPUの性能次第で処理落ちするし、
物理演算があるとCPU性能次第で処理落ちするかな

>>194
「てことは」の前後の文脈がどういう理屈で繋がるのか知らんが、2DSTGの話をしてるなら
今時どんなヘボノートPC環境であろうとも「当たり判定」で処理落ちさせるなんて至難の業だな
5年近く前のモバノート(1GHz前後のペンM…当然シングルコア)でシングルスレッドの総当りで
敵50匹と弾1500発の処理やらせて普通に60fps出るんだから、この時点で既に「いろいろ完璧」

そのスペックで1500の総当りってどう考えてもきつい気がするんだけども・・・

ウチのご隠居チンコパッドX31が初代セントリーノの1.2GHzで
だいたい同世代みたいだけど、1500個くらいならイケてる

ビデオチップがMobileRadeonとやや貧弱だから、計算よりも
描画周りに気を使う

使うっつってもテクスチャをケチりまくるとか
頂点バッファとDrawPrimitiveの使い方を適切に、とか
その程度の話だけどね

総当り以外の当たり判定処理ってのが思いつきません。

ずっと昔に仮想マップみたいなのを用意しておいて
そこにキャラや弾の情報を書き込み、判定の際に使うってのを
何かで見た記憶があるけど、こういうのの事でしょうか。

空間分割ってのがありまして。

完全2Dなら当たり判定のある空間を縦横20くらいに分割して、
それぞれの空間に属するもの同士で判定を取ることで、
当たる見込みの無いものとの判定を事前に回避する。

>>199
http://pc11.2ch.net/test/read.cgi/gamedev/1199303757/762-765n
↑の質問したのお前？
仮に別人だとしてもこの過疎板でこのタイミングで同じ質問が二度出るのは変だな
どっかのゲー専の宿題か何かか？正直に吐いたら褒美をくれてやるぞｗ

違います。
ゲー専の宿題でもないです。

今、自分で２Dゲーム作ってて、
キャラと弾、全部あわせると最高1600強を動かしてて、総当りでやってて問題なく遊べてる。
（もちろんあくまで「最高1600」であって、常にそれだけ動いてるわけではない）
「自機と敵弾」だけの判定じゃなくて、「敵と敵弾」とかの判定もやってるのに
ちゃんと遊べるから、最近のPCの処理速度はすげーなーとか思いつつも
やっぱもっと効率のいい判定方法ないかな、と考えてただけです。

1600*1600の総当りは3年位前のスペックだときつくないかな？

三年前、2005年のスペックというと
athlon64が全盛でathlon64x2が登場、Core2Duoがまだ、という辺り

有り得ないくらい余裕だな

1600*1600だと最新マシンでも空間分割しないときついんじゃないか。
>>196は弾*キャラなんじゃない？

典型的な2DSTGで1600のオブジェクトを表示するったって大半が弾なんだけど
1600*1600という数字(組み合わせ)に一体何の意味があるのか>>203は説明できないだろ

http://ja.pastebin.ca/970731
やっつけだがpen3 1GHzのマシンで平均32ミリ秒
30fpsで間に合わないってところか

http://ja.pastebin.ca/970760
今度は32*32の敵64体と16*16の弾1600発のテストで、弾はヒットしたら壊れるという想定
同マシンで2〜3ミリ秒
余裕すぎるな

ただのジコマンなのに連投してすまん

総当りっていったら、普通は敵だの弾だの関係なく
{1600}C{2} = 1600*1599/2 の組み合わせになるんじゃないのか？
64*1600の組み合わせじゃあ桁が違う

>>209
それは>>207

>>208は単なるジコマンぽ

>>203は
”総当りの意味をちゃんと使ってくれ”
と、暗に言ってるだけだと思うんだが

オブジェクトを敵機・弾など種類ごとにリストにしておき、
あるリストの要素と別のリストの要素の当たり判定を行うことで、
無駄な判定はなくせると思うが

俺もそれだ。

>>212
例えば自機が画面の左下にあるのに
右上に固まってる敵弾と判定と判定を行うのは無駄な判定だとは思わないか？

なんか変な文章に・・・

なんか俺の書いた事について色々あったみたいで、申し訳ないです。

俺が問題としてた話題はあくまで「総当り以外の判定方法」であって、
それ以外（俺がどんな事やってるか）は、この際関係ないから
>>201さんに納得してもらえる程度の情報出せばいいと思って
おおざっぱな説明しただけで、実際に1600*1600の判定やってるわけじゃないです。

常に全キャラ使ってるわけじゃないし、キャラ同士、弾同士の衝突判定は
ある場合より無い場合の方が多いし、そもそも味方同士の判定はやってないし、
というようにかなり減らしてはいます。

という事で>>201さんに納得していただいて、その褒美を貰おうと心待ちにしている次第です。

>>214
当たり判定範囲が矩形なら無駄な判定は生じない
むしろ、空間分割の方が無駄
5〜10個の矩形の複合体とか円形とか多角形なら、空間分割にも利があるけど、
矩形のバウンディングボックスで一度判定すれば十分だろ

俺の日本語がダメなばっかりに変な誤解をさせてしまってるかもしれない・・・
それとも俺が誤解してるのかも？

>>212の方法って敵弾が1000個あったとしたら
1000回自機と判定しなきゃならないってことだよね？

悪い例えだけど（実際はツリーだったり）
敵弾を分割した空間ごとにリストにしておき、
自機のある空間とその空間のリストの当たり判定を行うことで、
無駄な判定はなくせると思うが

組み合わせが多いときは、分割は有効だけどね

グリッドハッシュ
ttp://lucille.atso-net.jp/blog/?p=85

シューティングにここまで必要か？と問われたら
個人的には要らないと答えるが
知っておいて損は無いと思う

昔は、IF文使うときに&&を使わず
入れ子にして速度を稼いだりしたなぁ

確かに1対多だったら労力のわりにたいした恩恵受けるもんでもないんだけども・・・

とりあえず、オマエラ「空間分割 衝突」で１回ググれば幸せになれるんじゃね？

>>221
わざわざ入れ子にしなくても
if( A() && B() )
これA()がfalseならB()は実行されないから
左のほうをfalseになりやすいものにすればいいと思うんだけど
昔のコンパイラは違うのかね

>>209
敵弾とか敵機はお互い衝突しない
つまり敵属性同士は衝突しない
自機と自弾についても同じこと

敵(Enemy)と自(プレイヤー、味方、Friendly)。たった「2種」の敵味方属性
そしてオブジェクトに割り当てられる敵味方属性情報は静的。定数。const
プリプロセッサ、コンパイラにかける前から明らか。火を見るより
ゲームデザインの時点で既に決まってること
それなのに、判定…意味も無く…1600*1600回…あり得ない…愚行…常軌を逸する…愚鈍

BULLET enemybulletarray[1500];
ENEMY enemyarray[100];
PLAYER player;
for(int n0=0; n0<1500; n0++){
　　for(int n1=0; n1<1500; n1++)
　　　CollisionDetection( enemybulletarray[n0] , enemybulletarray[n1] );
　　for(int n1=0; n1<100; n1++)
　　　CollisionDetection( enemybulletarray[n0] , enemyarray[n1] );
}
for(int n0=0; n0<100; n0++){
　　for(int n1=0; n1<1500; n1++)
　　　CollisionDetection( enemybulletarray[n0] , enemybulletarray[n1] );
　　for(int n1=0; n1<100; n1++)
　　　CollisionDetection( enemybulletarray[n0] , enemyarray[n1] );
}
//↑ここまでで1600*1600回

BULLET playerbullet[100];
//2DSTGで総当りで当たり判定するっつったら普通コレ
for( int n0=0; n0<1500; n0++)
　　CollisionDetection(player , enemybulletarray[n0]);
for( int n0=0; n0<100; n0++)
　　CollisionDetection(player , enemyarray[n0]);
for( int n0=0; n0<100; n0++)
　　for(int n1=0; n1<100; n1++)
　　　CollisionDetection( enemyarray[n0], playerbullet[n1] );

BULLET enemybulletarray[1500];
>>226訂正

ENEMY enemyarray[100];
PLAYER player;
for(int n0=0; n0<1500; n0++){
　　for(int n1=0; n1<1500; n1++)
　　　CollisionDetection( enemybulletarray[n0] , enemybulletarray[n1] );
　　for(int n1=0; n1<100; n1++)
　　　CollisionDetection( enemybulletarray[n0] , enemyarray[n1] );
}
for(int n0=0; n0<100; n0++){
　　for(int n1=0; n1<1500; n1++)
　　　CollisionDetection( enemyarray[n0] , enemybulletarray[n1] );
　　for(int n1=0; n1<100; n1++)
　　　CollisionDetection( enemyarray[n0] , enemyarray[n1] );
}
//↑ここまでで1600*1600回

>>225-228
言いたい事は概ね同意だが下手なカイジネタは寒いからヤメレ

自機と敵弾・敵機と自弾以外に衝突判定する必要無いだろ
1600×1600になるのは自機1600機と敵弾1600個みたいな時

弾同士が打ち消しあうときもな

弾同士の当たり判定が無いなんて勝手に決め付けるなよ。
そういうSTG作りたいと思ってる人がいるかもしれないじゃないか。
というより5年前に俺が作った。
ビリヤード風弾幕ｗｗｗとかいいながら。
ひどい処理落ちで泣いた。

計算機アルゴリズムで使われる「総当たり」とか「総当たり法」ってのは
理論的にありうるor考え得る全ての組み合わせ全てを○○する、ことであって
この理論的にありうる、考え得るってのがキモ

理論的にありえない、100%かんがえられない組み合わせを端から除外しても
やはり総当たりだ

敵同士、味方同士は「当たらない」というルールになってるなら端から除外しても
やはり総当たりだ

弾同士が打ち消し合うときは(1599 + 1) / 2×1599じゃないか？

>>229
ウッセー自分で書いて後で赤面してんだからそれ以上言うな

33MHzくらいのCPUでSTGを作ったときは空間分割にしないと重くて大変だった。
そういうプアなハードじゃないなら好きに作った方がいいかもね。

自機の弾が1600発とか弾で画面が見えなくなりそうだなｗ

>>224
私の記憶が確かならば、A()でとっとと打ち切られるのはCの仕様で保証されているはずだ。

O(n^2)の壁は厚すぎる

>>218
矩形同士の判定程度だと、
　　ツリー管理コスト＞＞＞衝突判定のコスト
だと思うのだが。これが3Dでコリジョンも複雑になってくると、
　　衝突判定コスト＞＞＞ツリー管理コスト
になるけど

>240 の頭の中にはどんな木が生えているのだろう？
木ってぐらいなんだから再帰なんだんろうけど、

それよりも、ずっと簡単なs個の空間分割でこんな感じだよ。

比較回数(衝突判定回数)は総当たりが一定でO(N^2)としたら、

s個の空間に分割した時は、
最小 O(N^2/s +N)　〜　最大 O(N^2 +N)
　+Nってあるのは、中心より上とか下とか、左右とか、分割条件との比較。

最大は、全ての判定対象が一つの空間に有るとき。
最小は、全ての判定対象が均一にそれぞれの空間に別れたとき。

最大なんて状態ばかりのゲームはそう滅多に作れない。
必要とあらば中心を移動する事もできちゃうしね。

あれだ





弾幕ゲーが嫌いで、オブジェクト数がさほど多くない俺には不要＞空間分割

空間分割して、空間内にあるかどうかの判定って矩形判定みたいな
もんだよね。差し引きして恩恵あるのかね？あと、空間の境界にいる
場合は隣接した空間も含めなきゃいけないし、その判定のコストも
加わるから、あんまり恩恵がない気がするんだけど。

現空間x-1 <= 判定対象空間x && 判定対象空間x <= 現空間x+1

すみません。
空間分割による判定、のメリットというものがどうもイメージできないのですが、
例えば、縦シューで自機と敵弾（256発）の当たり判定で、

for(int i=0; i<256; i++){
if((自機Ｙ座標-敵弾Ｙ座標)の絶対値＜当たりの深さ）{
if((自機Ｘ座標-敵弾Ｘ座標)の絶対値＜当たりの深さ）{
（当たっている処理）
}
}
}
という単純な座標比較による総当たりを行っている場合、
空間分割にする場合どのように変更して、またそれによりどのくらいの恩恵が
得られるのでしょうか？

>>243
＞空間分割して、空間内にあるかどうかの判定って矩形判定みたいなもんだよね。
それじゃ逆に判定回数増えるだろ。
例えば4分割だとしたらオブジェクトのポインタのリストを4つ準備して
オブジェクトを動かした後にでも空間別にリストに登録する。
判定したいオブジェクトの空間のリストのみ判定する。

空間の境界をまたぐ場合があるから実際はリストよりツリーを使うみたいだけど。
自機対敵弾みたいな1対多のような場合は>>240の可能性もあるが
しっかり最適化すれば恩恵はあると思う。

弾幕ゲーで弾同士の相殺でもない限り、
空間分割の恩恵は誤差範囲だと思うな
80-20の法則的にもっと別の部分の最適化に労力を使えばいい

空間分割なんて16ビット機でやってもいろんなオーバーヘッドで効果は微妙だった。
いくらか弾数が増えてるとはいえ、今のPCでみみっちいことしないでよろしい。富豪的に池
つーかまず衝突判定にそんなに時間かかってるのかプロファイリング取れ。

空間分割自体は当たり判定以外でも使える場合もあるかもしれないから
そういう方法があるとだけ覚えておけばいいんじゃない？

＞＞２４６
難しくて分かりません。
他のレスを見て、合わせて、
必要ないということで納得しました。

シューティングって、三角関数のテーブルは360度で足りる？

それくらい自分で判断しろ

どんなもん作りたいかによる
要するに自分で判断しろ

普通に標準ライブラリ関数使いまくりでおｋ

むしろ度数法を久し振りに見た……。

だからテーブルとか考える前に普通に三角関数使ってみなよ。富豪的に。
たかがシューティングごときを作るのに、
あれこれレガシーな技をどこで覚えてくるんだいったいｗ

弾幕シューが技術的にすごかったのはX68000までよねーｷｬﾊﾊ

微妙に誉め言葉ｗ

俺もそうだったが、
初心者ってどうでもいい部分の最適化にこだわるよなｗ

アセンブラ勉強し始めたりとかなｗ

>>256
たぶん超連射のことを言いたいんだと思うがあれは弾幕シューじゃない。
そもそも68全盛期に弾幕シューなんてジャンルは存在しない。
知ったか乙。

マジレスとな

爆裂矩形弾が泣いてます

敵弾の多さならメルトダウンも負けない
テキストだけどｗ

>>260

爆裂矩形弾懐かしいｗ
あれで弾幕シューは俺には不向きだと悟ったなぁ。

針弾弾幕は、その場で計算して回転で大丈夫？

大丈夫も何も、針弾は角度とか回転情報を持ってなくね
針弾＝曳航弾。尾＝残像＝向きは速度(ベクトル)に平行
所有する変数は座標、速度、尾の長さ。せいぜいこんなもん
表示に際しても、太った線分＝OBBを一個作るだけであり
角度とか回転計算が出る幕はない

その場で回転を計算の意図が今ひとつ掴めないが
俺は弾の情報として角度は持たせてる
前の座標や速度からその都度計算してると完全に停止する場合に困るからね
あとは途中で方向が変化しない弾なら発射時に角度を計算して放り込んで弾が消えるまで使いまわし
変化する場合は毎回計算

まぁ好みでやればいいと思うよ

融通が効くと思う方法にしとけ。
速度で困ることは無いと思うし。

前に、三角関数使いまくったら流石に重かったなあ。

改めて自分のソース見てみたら360度のテーブル使ってた。
不都合無いのでこのままいくがｗ

>271
俺も見てみたら、unsigned charのオリジナル角度表記を使ってた。
意味あんのかな、これｗ

自分は１周＝256分割にしてますね。
360度だと、nWay弾とかの処理するとき、弾と弾の間の角度に端数がでませんか？

2Dでもちょっとした誤差くらい気にならんよ
それに角度を度でやるなら360も約数多いから端数出にくいんじゃねえの

確かに誤差の範囲ですね。組み方次第でどうにでもなる問題かも。
自分の場合、多Way弾の弾と弾の幅を考えるときに、360度法でいうところの
90度からスタートして、半分、半分、半分、って幅を狭めていく考え方を
することが多かったから、１周が２のn乗のほうがやりやすかった、というだけの話。

いまだに三角関数のテーブル使ってる人が俺以外にもいたなんて
俺は1024分割

当然座標も整数だよな

そうか！　座標を整数以外にするという手もあったのか！！

整数つかうときって、何倍かして入れるんだろうけど
当たり判定とか表示のときは毎回戻すの？

何回ってどういう意味なんかよく判らんｗ

>>279

>>278
戻すって、整数部だけが欲しい場合か？
そんなん普通にビット演算子とかシフト演算使えば済むでしょ

おそらく初心者だと思うが、固定小数演算に興味示すのは結構だが
FPU内蔵＆SIMD系の命令でもfloat値が使えて当たり前の今時のPCで
わざわざ固定小数を使うメリットはほぼ無しってことも合わせて理解しとけよ

それでも年寄りの悪趣味懐古趣味に付き合いたいなら別に止めはしない

次に作るSTGにリプレイ機能を搭載しようと思っているのですが、
小数を使う場合、CPUによって小数点以下に誤差がある？という話を聞いたのですが、
例えば敵弾の座標に小数を使っていたら、リプレイを再生する環境によって
微妙に挙動がずれたりする可能性はないのでしょうか？
組み方次第で回避できるとは思うのですが。

＞小数を使う場合、CPUによって小数点以下に誤差がある？という話を聞いたのですが

とりあえず
固定小数点数演算で生じる誤差の話なら、それは整数演算で生じるものと全く同じ
浮動小数点数演算で生じる誤差の話なら、それは「小数点以下」とか関係ないから

浮動小数点数演算の結果はCPUによって異なる、というのは事実だが
それは全く異なるアーキテクチャ上のFPU同士を比較した場合の話であって
x86系のPCに限定すれば_fpcontrol()等できちんとFPUの設定をすることで
インテルだろうがAMDだろうが加減乗除算平方根三角関数の結果は同じになる

FPUに不具合があって回収された10年以上前のペンティアムとかは例外
あとSSE関連はよく知らね

あと、数値計算法の基本をふまえて相応のコードを組んでいれば
異なるFPU間で生じる演算結果の極めて微少な差は問題にならないはず

FPUの演算結果にはたいてい不要な桁数の仮数が入ってるのだから
そういうゴミ情報入りの数値は適切なタイミングで有効桁に丸めること
不要な桁も何もかも後生大事に丸々保存して使いまわすのは
無意味な貧乏根性

D3DXが内部でSSEやら3DNow!を使ってそいつらで誤差が出ると2chで聞いたことがある。
試してないから知らんけど、リプレイで記録するデータはCPUで普通に計算すればOKじゃね。

>>285
http://www.01step.net/tobitsuki/bbs/test/read.php/tobi_bbs/1116256631/18
これだな。
一応対策はできるらしいが。

NyaRuRu氏は同人ゲームのプログラマもやっていたのか・・・。

何やってる人なんだろうと思っていたが
不思議キッチンの人だったのか

似たようなオブジェクトを同じクラスにするかどうか迷うなぁ
違う見た目（＝テクスチャの領域）で同じAI（＝updateメソッド）とか
AIのうち一部分だけ違う場合はifで分岐させるか、別クラスにするか

好きにすりゃいいんじゃねーの。
そんな細かいことに定石も流行りもないだろうし。

AI部分にStrategyパターンを適用して
付け替えできるようにするのもありだ。

残機制にしたいんだけど、キャラの都合上死んだあとにもう一機出てくるのはおかしい
メカシューだから魔法みたいに復活するのも変
どうしよう…なんかいい例ある？

ばらばらに飛び散った破片が元通りに戻ってみたりするとか？

ゲーム内の設定によるだろうけど、例えば
「瞬間的にバリア張って高速自己修復出来るけど、
めちゃくちゃエネルギー消費するから回数制限がある」みたいな感じとか。

夢オチ。

クロノトリガー式に未来からやってきた仲間がダミーと差し替え

思ったんだが普通に被弾したら、例えば片羽が落ちるとか
パーツがこぼれていく描写入れて暫く無敵時間を入れて
残機減らしてもそれはそれで良いんじゃないかな

ナイトストライカーのようにシールド張ってる設定にすれば
被弾エフェクトはシールドの色が変わるとかSEとかで知らせる

夢オチﾜﾛｽｗ

>292
爆発したら首だけすっとんで、新しいからだが飛んできて合体する逆アンパンマン方式。

博士が来て修理するファミコンのアトム方式とか

ツインビーｗｗｗ

バリア張ってる設定にしたら？
残機＝バリアの残りエネルギー
被弾するためにバリアのエネルギーを消費する

×被弾するために
○被弾するたびに

「メカシュー」で「残機制」にしたいという前提を忘れたようなレスが多いですね。

どう考えても無理だから、別の解決策を練ってるんだろうが

復活時にボムが回復するようなSTGだったらどうしようもないだろうな

よく考えたらストーリーあっても別の位置から復活するSTGいっぱい

>292
キャラを搭乗者と読めば、
被弾時は脱出装置で後方に下がって、
後方で自動操縦で追尾している残機に乗り換える
とか、何とでも自分で想像出来ない？

>308
夢オチ

同じ残機制でも、その場で次が出てくるタイプか、
シーンを戻されてやりなおしのタイプか、でやりようが変ってくるねぇ。

戻り復活ならそんなに違和感ないな

そうね
無かった事になるんだと思えば

そもそもプレイヤーは次の機体がどんな出方してこようがあまり気にしていないような。
「人類に残された最後の希望」とか言って設定上試作機１機しかないはずの自機が
バンバン復活して出てくるＳＴＧも結構あるし

アレだな。
漫画でもゲームでも良くある「そこは突っ込むな」って奴で良いんじゃね？

ドラクエだってストーリー上死んだキャラにザオリク使ってあげないし。
オルテガも話してる間にベホマしてやれば助かったと思うぜ。

>>313みたいに固定搭乗者・固定機ありなら夢落ち戻り。
といいたいところだけど、夢落ちだとステージ最初まで戻さないと
パワーアップとかあったときにつじつまが合わなくなるからなぁ。
夢落ちでわざと死ぬ前の状態から再スタートってのもそれはそれで面白い試み
かもしれないけど。
以下みたいな感じならつじつま合わせも可能かな。
パワーアップ > 装備増加 > 被弾 > 装備減少 > パワーダウン > 装備0 > シボンヌ
> 夢落ち戻り > 死亡直前の装備なし状態で復活
つじつままで気にする奴は早々いないとは思うけどｗ


軍vs敵みたいな、固定搭乗者なしなら別機出動演出。
(カラーとかロゴとかでバリエーション持たせたりして同型別機演出とか)
昔ロスト時に空中母艦かなんかが出てきて、新たに別機が出てくる
演出をしていたゲームがあったと思うけど。


> オルテガも話してる間にベホマしてやれば助かったと思うぜ。
あれはオルテガの男を見て「男の戦いに手を出しちゃいけない」と壮大な勘違いということでｗ

勇者たちがザオリクで生き返るのは、神の認めた勇者とその仲間たちだからだ！

とかそんなこじつけ。

ダイの大冒険的には、死にかけにホイミ系は無意味
ザオリクは知らね

撃墜されたの戦闘機に乗っていたのは実は影武者だった！

と言うことは、一機も撃墜されなかった場合影武者が世界を救うわけだな

いや、その場合はそいつが実は本物だったというわけで。

というか機体が複数存在するんじゃないって時点で残機じゃないよな
バリアみたいなものが減っていく普通のライフ制にするしかないと思うんだが

夢オチなら残機じゃなくて残夢だから
鼻ぶく提灯の顔マークを並べとけばいいな

どうでもいいじゃん・・・

シューティング作りたいなーとか思い始めたんだけど、
具体的にどう作ればいいんだろ？

C言語ポインタくらいしか学んでないんだができるかね

まず、画面に画像を出力する方法を覚えないといけない
Windowsで動かすならDirectXか、標準APIの扱い方を覚えないと
てか、まずC++を覚えた方がいいな

HSPが軽視されてると聞いて飛んできました

帰れｗ

ちゃんとしたものを作ろうとしたときやっぱりオブジェクト指向覚えた方がいいのかな？

ポリモーフィズム(C++なら純粋仮想関数 + virtualメンバ関数くらい)を覚えておいて、
あとは、構造体とstatic関数で良いよｗ

構造体自体の種類を示すメンバとか作り始めたときに、
virtualを考えればいい。

>>325
なるほど〜
C++を覚える作業にもどるよ。

オブジェクト指向なんて全然必要ない

むしろ理解してない人が作りながら覚えようとすると
十中八九途中で投げ出すことになる

まあ、そんなの無くても作れるもんな

>>331-332
ありがとう。
講座サイト見てるとオブジェクト指向で書いてある所が多かったからてっきりそうとばかり思ってたよ。

というか、オブジェクト指向でやってる人ってどれぐらい居るん？

8bit時代からあるゲームにC++やオブジェクト指向が必須かと言われればNOだ。
プログラムの勉強を兼ねるならやっておいた方がいいだろうね。

オブジェクト指向を仰仰しく考えることないよ。
文字通り方向性みたいなもので、設計方針の１パターン。

構造化・オブジェクト指向・関数型・総称・イベント駆動型あたりを
広く浅く知っておけば良いんじゃないかな。
異なるパラダイムの異なる要素が結構似ていたりする。

http://ja.wikipedia.org/wiki/プログラミングパラダイム

オブジェクト指向が本当に必要なら作ってるうちに覚えるから
最初から覚える必要はない
ぐちゃぐちゃでいいからとりあえず動くものを作るとこまでが重要

シューティングを作るアルゴリズムというか、パターンというか･･･
そういうのがわからん･･･

1.プレイヤーの入力を受け取る
2.受け取った入力より自機の座標を動かす
3.その他（弾，敵等）の座標を動かす
4.各衝突判定をする
5.ぶつかってたら消すなり体力を減らすなり
6.消えてない物の絵を画面に表示する

1〜6を繰り返す

簡単に言うとこれ位があればシューティングっぽいものが出来るのでは？

ここで聞くのも間違いかも知れないが、今C++とSquirrelでSTGを作っているんだ。

Sqruirrelスクリプト側からC++の関数を呼ぶためには、
SQInteger func(HSQUIRRELVM v)
という形のグローバル関数でなくてはいけないんだけど、スクリプト側から特定のオブジェクトを操作したいんだ。
しかし、上の形だと動的メソッドでもないし、引数にオブジェクトへのポインタが含まれていないため、どうやって呼び出そうか困ってるんだ。
HSQUIRRELVMはスタックになっているので、スクリプト側に操作したいオブジェクトのポインタをあらかじめ渡しておいて
必要なときにスタックにぶち込んで引数として利用しようと考え、

/*Squirrelスクリプト*/
function ExeScript(p) /*引数はポインタ*/
{
　　SetVelocity(p, 0, 5, 0); /*引数は操作するオブジェクトのポインタ、x方向の速度、y方向の速度、z方向の速度*/

　　return 0;
}
/* HSQUIRRELVMのスタックには 1(top):roottable, 2:p, 3:0 4:5 5:0)となっているはず*/

というようなスクリプト側の関数を作り、ExeScriptをC++側から呼び出す時に
引数に呼び出し側のポインタをぶち込んであげようと思ったんだが上手くいかない。
ちなみにpはスクリプト側ではint型で扱っていて、ExeScriptが呼ばれたときにintにキャストし、
SetVelocityが呼び出されたときにポインタにキャストするようになっている。

何かいい方法はないだろうか…？

>>340
作ろうとしているのがSTGってだけなので、
ム板の組み込み言語スレで聞くほうが良いと思うよ。

解った、行ってみる
ありがとう

2Dの弾幕シューを製作してるんですが、画像表示の優先度（Zの値）はどうしたらいいでしょうか？

取り合えず
・スコア、ライフなどの表示系
・敵弾
・自機
・自機弾
・敵
・背景
大体こんな感じにしてみましたが、地上物の弾が空中の敵の上を通るとか不自然じゃありませんかね？
特に重なっている時に地上物が撃った場合上にいる敵から出てるように見えてしまって・・・。
爆風も同じで地上物の爆風が空中の敵にかぶるとか変ですよね？

皆さんはZ方向の値はどういう処理をしてますでしょうか？

既存のゲームをもっとよく観察しようぜ

ちょｗｗｗ　Web上で動くってレベルじゃねー
しかも3D
http://58.13.216.134/humanbench/index.html

６０フレ死守？

暇だから誰か制作中STGのスクショうｐ！

言い出しっぺの法則。

言いだしっぺのｈ・・・ってもう言われてるしｗ

>>343
そんなんで２Ｄシュー作ってるのか・・・

>343
空中キャラのサイズが128*128程度なら気付かないんじゃないかな
違和感が出るのは大型の空中キャラがいるときだから
敵配置を工夫して誤魔化すのがいいかも

地上物からの弾だとしても、空中の敵で見えなくなったらそれだけでクソゲ扱いだなｗ

やっぱり敵配置がポイントですか・・・。
一応他のゲーム（CAVE辺り）は動画でよく見てたんですがイマイチ分からなかったんで・・・すいません。
敵と敵の配置を研究してみます。
アドバイス助かりました。

さっきカスりを取り入れてみたんですが、ライフ回復のためにカスるという危険行為推奨になってしまいました。
やっぱカスりはスコアボーナスとかエネルギー（特殊技用）回復のモノにしたほうがいいですよね。
変に凝ってしまって全て見失うような気がして怖いです。

>>345
いいねぇ！これ作ったの外人さんなのか？
そういやFlashもAction Script3が使えるようになった辺りから
描画速度がだいぶ改善されてるみたいね

一昔前のShockwave(+Lingo)並のことができるのは嬉しいな
あの頃はDirectorが高すぎて手が出せなかったよ

>>343
重なってるときに弾を撃たなければいいのでは

敵弾が低い位置にある場合は当たり判定も無いようにするとか……分かりづらいか。

>>352
深く考えないでカスリとか入れてるっぽいが、
ちゃんとゲームとして必要かどうか考えたほうが良いんでは？

まあ個人的にカスリが嫌いなだけだけどｗ

カスリとかゲーム的過ぎて嫌いだな
まぁSTGは全般的にゲーム的過ぎることが多いが

ゲームなんだから良いじゃん

自分からわざわざギリギリで避けるなんて
両方滝沢キックを喰らってしまいそうだ。

ゲーム的だからってのはどうでもいいが俺もカスリは好かんな

>>358
「ゲーム的」っていうのは、
ゲームとしては面白いが現実離れしている、みたいな意味だ

カスリなんかよりおかしいとこいくらでもあるだろｗ

俺たちが遊んでいるのはゲームだ。
面白いゲームならそれでいい。

まあ、言いたいことは分かるけどな。

58.13.216.134

＞いいねぇ！これ作ったの外人さんなのか？
＞そういやFlashもAction Script3が使えるようになった辺りから
＞描画速度がだいぶ改善されてるみたいね

＞一昔前のShockwave(+Lingo)並のことができるのは嬉しいな
＞あの頃はDirectorが高すぎて手が出せなかったよ

HumanBench作ったのはアドビの中の人だよ

中の人は80年代のアーケードの疑似3Dゲーとかが好きに違いないな！
PC-9801時代のKUNI SOFTとかABAゲイの同人ゲーをふと思い出した

>>365
/yukissalbum2/jam.cgi

作成したシューティング
誰かにプレイさせてみたいのですが、プレイさせる相手が見つからない
こういう時って、どうしたら良いんでしょう？

それ用のスレがどこかにあったと思う。

というか、完成してるのならフリーソフトとして公開すればいいだけでは？

いえ、まだ体験版の段階なのですが
プレイできる段階にまでは仕上がったので、書かせてもらいました。

公開するにしても、みんなにやってもらうためにはどうしたらいいんでしょうか？
ただホムペを立てるだけでは人は来ませんし
公開スレ（適切なのが見つかりませんが）でうｐが良いのでしょうか？
もしくはベクターに登録とか？

ここでうｐ！

自作ゲーム評価スレ
http://pc11.2ch.net/test/read.cgi/gamedev/1010018331/

ここでうpしたほうが意見もらえるんじゃないか？
テンプレにも晒しておkって書いてあるし

＞HumanBench作ったのはアドビの中の人だよ
コリン・ムック氏は実はアドビ人ではないかと。

自作ゲーム評価スレは、STG以外のものも出ていることもありますし、
ひとまずは、こちらでうｐさせてもらいます。

シューティングビルダーを用い製作したSTGで、SB本スレでも一度うｐはしたものです。
4面まで作ったものの、ちゃんと出来ているか不安でたまりません。
どなたか意見いただけると超嬉しいです。

http://www.erc-j.com/sb/
の左上にあるSB-UPLから入れるアップローダーのsb0173.lzhにうｐしました。

>377
ちょっとやってみた
敵の種類とか攻撃パターンも結構豊富だしよくできてると思うよ
全体的にキャラが小さいのが個人的にはあまり好きじゃないけど、まあ好みの問題なので気にしないでくれ
あと単発弾はもうちょっと弾速早くてもいいんじゃないだろうか

つまらなくはないがノーコンで頑張る気にはなれなかった
敵が体当たり狙ってくるのは嫌いだ
好みは別として、とりあえず硬めの敵の爆発は本体の二倍以上の大きさにすべき

よく出来てるけど演出がもったいないな

ヌクモリティに全俺が泣いた
感想ありがとうございます！

>>378
キャラが小さいのはドット絵が素材頼りなこともあって限界があったりします。
弾速に関しては、前半部分だけ少し早めにしてみます。
後半に進むたびに弾速が早くなる感じになっており、後半面では製作者がいっぱいいっぱいなのでｗ

>>379
体当たりに関しては弾幕部分を削減したかったこともあり導入したのですが、すみませんでした。
理不尽に感じた体当たりキャラを教えていただけるとありがたいです。
爆発に関しては改良させてもらいます！

>>380
演出がもったいないとは、全体的に演出が甘いということでしょうか？
それとも、あちゃーな演出があったということでしょうか？

俺も３面途中までやってみたので、多少なりとも思った事を。

一面の序盤から、敵が殺る気まんまんで笑った。
当たったら死ぬボールみたいなの（機雷？）はしょっぱなから難しすぎじゃないかな。

ゲームバランス的にどうかは考えないで言うと、もう少しパワーアップをガンガンやりたかったかな。
たまーーーーにしかパワーアップアイテムが出ないので、存在を忘れてしまう。

演出も面白かったけど、それぞれが単発で「お？」と思う程度だったのがちょっと残念かな。

個人的に前半部も弾の色を分けた方がいいと思った
敵もなんだかところどころ見づらい

難易度ﾀｶｽｗｗｗ
1面の機雷分りにくい。アイテムだと思っちゃうよ。
あと、ウィンドウモードだとFPSが安定しないし、全画面よりもFPSが早くなった。

>>377
d3dx9_30.dllが無いって言われる。
http://d.hatena.ne.jp/ginpei/20060805/1154783971
http://alwei.sakura.ne.jp/index.cgi?date=20070428

最新版とか入れるのはかまわないけど、
出来れば同梱とか依存性切るとかした方がいいかも。（一般ユーザーのために）

レス多くて本当に助かる、ありがとう！

>>382
パワーアップは一面に一つしか出さないようにしてるので、確かに存在を忘れがちかも。
しかしバランスのこともありますが、東方のように初めで攻撃力最強になってしまうのも防ぎたい私としては悩みどころです。
難易度に関しては、調整もう少しするかイージーモードを作ることにします。

>>383-384
弾の色を分けるというのは、どういうことでしょうか？
同系統の弾は変に色分けしない方が良いのでは？
敵が見づらいとか分かり辛いのは、ドット絵が素材頼りなので可能な変更に限界がありますが
とりあえず色などの変更は試してみます。
ウィンドウモードに関しては、少しビルダー製作者に聞いてみます。

>>385
d3dx9_30.dllの同梱って著作権的に問題があったはずなので、readmeにリンク貼ることにします。

ヌルポ

>387
……。（あえて何も言わない）

ttp://www.j-tokkyo.com/2008/A63F/JP2008-023268.shtml
誰か翻訳して

デモプレイで、自機が死なずに居続ける位置取りを算出する特許

・・・普通は人間によるキー操作を事前記録して再生するだろうから関係ないな

さらっと内容に目を通してみたけど

ゲームの魅力を伝えるには、事前記録された物を再生して
決まったデモしか出てこないのは多様性が無く十分ではない

また、ランダムに動くようにしてもすぐ死ぬのでこれまた
魅力を伝えるのには十分な時間見せられない

という上でそんなことしてるみたいだけどな

意味があるのか無いのかは知らん

これを発展させれば自動的にゲームをクリアすることも出来るだろうから、
技術としては面白そうだよな。

格闘ゲームで実現してね？

>>392
これが特許になってるってことは
発展させるにも許諾とか金払わなくちゃいけないんだよ

どの程度の完成度になったらこのスレにうｐして意見貰えるかな？
と、まだ１面ボス作ってる段階の俺が言ってみる

>>394
特許は結果じゃなくて方法に対して与えられるから、
別の理屈で位置から作ればいいじゃん
ぱっと見、あんまりたいしたこｔ（ｒｙ

>>395
プレイできる段階にまで仕上がっているなら、
たとえボスだけでも、道中だけでも俺は意見するよ。

>>397
まじか
じゃあ早いところBGMと効果音を搭載してどこかにうｐできるように頑張ってみるよ

期待してます。
でもそれで満足しちゃって開発飽きちゃわないでね。

経験ある、ってーか常にそうなんだけど、
ある程度形になって、他人にテストプレイしてもらったら
しばらく何もする気なくなったりするから。

スクリーンショットをうｐしたらアドバイス貰えるかな？
完成まで程遠いんだけど、客観的な意見をもらって軌道修正したい気がするんだが

>>400
動くものじゃないと軌道修正するほどの意見は難しいんじゃね
俺的には音もタイトル画面もどうでもいいからうｐ！

>>401
じゃあ俺はGW中に動くものをうｐするよん
３９５と同じく１面ボスまで
今バグだらけでうｐできる状況じゃないから何日か待ってね

敵、敵弾、自機弾をそのつどNewするのって良くないの？

【キーワード抽出】
対象スレ： シューティングゲーム製作技術総合 15機目
キーワード： New
抽出レス数：6

富豪厨の出番と聞いて飛んできました

(; ^o^)

富豪陣営に加勢するぜ。

　　　　　「迷える子羊よ。真の富豪厨はHSPに帰依します。」

私はその言葉に心を強く打たれ、boost原理主義から足を洗いました。
今は玉葱狂信者です。

libneet使ってるのは俺だけのようだな

>>381
敵の動きとか拘ってるのは伝わってくるんだけど、
オブジェクトが小さいせいか安っぽさを感じる。もっと演出を派手にすべき

ttp://hp.vector.co.jp/authors/VA017297/
ここのRagud Mezegisを使って研究するといいよ

3D弾幕で画面を埋め尽くすHumanBench見てて思った。
フラッシュでも普通に2D弾幕シューが作れそうな予感。
IEで普通に遊べれば、2D弾幕の布教活動がしやすくなるのでは。

HumanBenchやってみたが、3.xxxxHzあたりで重くなった。
ｸﾞﾗﾎﾞ無いとCPUだけあってもこんなもんか

Flashでも2D弾幕ゲームはすでにいくつかあるよ

パワーアップすると敵の固さも弾数も激しくなって難しくなるゲームで
難易度を上げないためにパワーアップしない、という遊び方が必須なほど
難易度の上昇が激しいのは、バランス的にやっぱりおかしいと思うんだが、どうだろうか？

個人的にはおかしいと思う。
なぎ倒す為にパワーアップしたいのに、敵まで強くなったら意味ないじゃんと。

特定のアイテムを取ると、パワーアップする代わりに敵も少し強くなるというくらいならアリかなとは思うけど。

アイテムを取ると敵が強くなるから、アイテムを回避しまくる戦闘機
なんか変だよな、どう考えても

バッドエフェクトアイテムみたいにして
パワーアップとは別物として用意するとか

パワーアップアイテムが出た時、それを敵がとったら敵がパワーアップするとか。

敵を撃破したときの点数（レート）が上昇するアイテムを取ると、
雑魚敵が増えるとかは面白いかも。

高難易度と引き換えに高得点てのはバランス取りやすいね。
初心者は手を出さなければ低難易度で楽しむことができるし。

「アイテムを避ける」という行為自体が生理的になんか嫌、
という人も少なくないと思うがどうだろう。

まあ場合によるとしか
結局は作者の好みだな

考えてみた。
パワーアップ方式の問題点は
上手い人はパワーアップの効率が良いので、上手い人ほど楽になるという矛盾。
これを回避するために、パワーアップしたら敵も強くなるってのがあるんだよな。

回避パターンは
　パワーアップが継続しない。時間制。１面リセットなど。
　パワーアップしないと利益がある。しないと高得点。得点倍率アップなど。
　パワーアップすると不利益になる。攻撃力を上げすぎると制限時間やHPが減る。
　パワーアップしない。


いっそ難易度を危険度という名前で大っぴらに表示して
危険なほど高得点が稼げるようにしたほうがいいかもな。
凄く固いエマージェンシーキャラを倒すと一気に危険度が上がったりとか。

過去のゲームのバリエーションでしか無い気が。

パワーアップについて考えるなら、そもそもパワーアップが必要かどうか
から考えてみては。

パワーアップすると難しくなるから第二段階くらいでずっと進んだりね
フルパワーを誰も使わなくなってしまう

ﾊﾟﾜｰｱｯﾌﾟは爽快感をﾊﾟﾜｰｱｯﾌﾟさせるもの

動画サイトで弾幕シュー見て参考にしてたんですけど敵に当たってもアウトだったんですね。
スーパープレイっぽいのしか無くて今まで気が付かなかったです。

でも別に敵とは当たり判定無くてもいいような気がするんですがどうでしょう？
ちなみに縦弾幕シューです。

良いんじゃないかな
マニュアルに当たり判定ないって書いておけば

東方並みの弾幕シューには不要だと思うよ

非弾幕には必要だと思う

敵に当たってミスにならないのは少数派ではある

「敵の突撃体当たり攻撃」パターンが減るけどいいのかな？

体当たりが必要になったら、弾を纏った敵を作ればいい。

むしろ敵のような弾でいいんじゃね

>>433
今まで「敵は当たりませんよ」と思い込ませておいて
いきなり「当たりますよ」はずるいだろ、という意味で。

そもそも弾幕シューだと体当たりしてくる敵なんていない気がするが

え､敵に当たったらパワーダウンだろ?

敵との当たり判定が必要か不要かではなく、ゲームに生かせるか
どうか考えればよくね？

例えば、判定の有無をプレイ中に切り替え可能にして、連続切り替えには制限を付ける。
で、当たり判定有りなら、神風アタックを使えて高得点を取得できるけど
普段の当たり判定が広く弾に当たりやすい。(プラスアルファ要素)
当たり判定無しなら、神風アタックはできないけど、普段の当たり判定が
小さいく弾に当たりにくい。(従来品)
とかやれば、いつ切り替えるかで戦略性が増すと思う。
(リアル性を一切無視しているが)

次のうｐﾏﾀﾞｰ？

リアルから離れるとゲーム性が高まる
離れすぎるとルールの理解に苦しむ

そうだな、そういう視覚的に一見分からないルールだと直感的なプレイからは遠くなる。
特別なルールを設けるんだったら、プレイヤーが「やらされてる感」を感じないように
うまくデザインする必要があるな。

敵にも当たり判定つけてザコラッシュやってみたんですが難易度かなり増しますね・・・。
寸前に警告だしてもいいんですが、戦艦みたいなデカブツを横切らせたりしたいんで当たり判定あると厳しいかなーと・・・。

ボムの代わりに時間を止める技があるゲームなので敵とか気にせず弾幕をすり抜けられた方が良さそうな気も。

昔から体当たりで殺しに来るゲームはムカツク

そう考えると>433は秀逸かもしれない

>>442
奥行きはあるんだろ？戦艦なら胴体部分は奥にあるとか・・・
敵によって、重なってもダメージにならない状況があるのは全然変じゃないぞ

>438
当たり小：飛行形態
当たり大：ロボ形態

を切り換えるとか？

>446
いいね
それぞれの形態のメリット、デメリットを直感的に分かりやすいようにできれば
システムとして活きてくるような気がする。

う〜ん・・・なかなか難しいですね。
色々試したんですが、なんかピンとこないんです。
>446
形態は・・・既にフォース（ボムみたいなモノ）消費で変形するんですよ。
普段は戦闘機、フォース消費で時間を止めて中間形態。
フォース消費ボタンを二度押しでさらに消費してロボ形態に。
ロボ形態時は時間は止まらず操縦不能だけど、無敵状態で手当たり次第に敵に突っ込んでいく感じ。
オメガブースト（知ってる人いるか分からないけど）の必殺技と大体同じ。

まだ今のところ「二つも消費してまで使う必要があるのか」とか「スコアボーナス」とかそういうので仮決定状態なんですけどね。
シューターって、よく追い詰められると（ボムが底をつく等）覚醒したように弾幕を見切れたりするじゃないですか。
それをサポートするためにフォースがゼロになったら当たり判定をさらに小さくして「俺TUEE」状態にさせてあげたいんですがどう思いますか？
「シューターズハイ」って言葉を聞いて「これはいいな」とか思ったんですが・・・。
抱えボムで死ぬのも防ぎたいですし。

長々とすいません。

ボム中に操作不能は個人的には嫌い。ストレス溜まるｗ
中間形態って何かメリットあるの？そもそも二段階ボムになってる理由がわからないよ。

あと俺tueeやりたいなら実感しづらい回避性能より火力を上げたほうがいい気がする。

＞火力
雷電のクラスターとかVIPER Phase2のナパームが個人的に爽快だた
火力というよりも演出か

>>448
> 既にフォース（ボムみたいなモノ）消費で変形するんですよ
変形できるからロボット化を行わなければいけない決まりはないでしょ。
ブースター展開とかいくらでも追加方法はある。(ゲッター123ｗ)

> フォースがゼロになったら当たり判定をさらに小さくして「俺TUEE」状態にさせてあげたいんですがどう思いますか？
俺なら、ボムゼロ時限定で時間停止の弱効果でスローを一発使えるようにする。(もちペナルティ付き)
で、2段ボムの1段階目をスローにして2段階目をストップにして、ストップの時は敵の弾も撃ち落とせるようにする。
さらに弾の破壊にスコアボーナス付ければ「二つ使ってでも」と言う理由付けができると思う。
ボムゼロスローはペナルティもあることだし、弾破壊可能にすればこれも戦略に組み込めるようになるな。
(時よ止まれ、そしてマトリックスがドーピングw)
が、こんなすぐに浮かぶアイディアだし既に存在してそうｗ
(それ以前に大幅システム変更になりそうだから提出時に即却下だなｗ)

>>449
> ボム中に操作不能は個人的には嫌い。ストレス溜まるｗ
次の位置取りとかあるしね。

＞次の位置取りとかあるしね。
そうそう、そもそも即発動型のボムはダメージ与えられるのが嬉しいんじゃなくて
無敵状態で接近して撃ち込めるのが気持ちが良いのさｗ

「ボム＝自機無敵」ってルールはいつできたのかなぁ。

結局気持ちが良いとか面白いとかって
過去の作品の手法を踏襲しろってことなんだよなぁ

別にルールじゃない

>449
> 中間形態って何かメリットあるの？
今のところは・・・無いです。前は火力も同時強化でしたけど、今現在はタイムストップ使用形態みたいになってます・・・。
ホントは「時間とまってるのに戦闘機が後退するのおかしくね？」って事で中間形態は全方位移動型って設定だったんですが、
敵なんか平気で後退したりしてるんでそこまで拘らずに良かったですよね・・・。
> あと俺tueeやりたいなら実感しづらい回避性能より火力を上げたほうがいい気がする。
火力アップも考えたんですが、一応弾避けも楽しみたいということで・・・あえて回避性能にしてみたんです。
「俺ニュータイプ化してるぜー」的な・・・ちょっと無理なこじつけかも知れませんけど。

>451
> 変形できるからロボット化を行わなければいけない決まりはないでしょ。
そうですよね・・・。「今回はロボに変形する戦闘機でいこう！」ってノリだったんで固執しすぎました。
> 俺なら、ボムゼロ時限定で時間停止の弱効果でスローを一発使えるようにする。(もちペナルティ付き)
スローをさっき無理やり実装してみましたが・・・ちょっと挙動不審でした。
しっかり実装させるとなると最初から組みなおさないといけないモノが大量に出てくるのでちょっと今回は見送りさせてください・・・。
とりあえずタイムストップ終了時に敵弾が一気に動き出すので、いくら弾道が読めていても被弾しやすい点があったので
発動時と終了時に短時間ですがシールドを張って切り抜けられるようにしました。
あと、敵弾画像も丸弾を無くしてタイムストップ中でも敵弾の弾道が読めるようにしました。あとなるべく直線弾がメインの方がいいですよね。

あと二段目のボムは・・・操縦不能になるのはやっぱ好きじゃない人いるんですね。
次々と撃破していくあたりの爽快感を出したつもりだったんですが、位置取りもあるとなると厳しいですね。
今のところ終了時に発動場所に戻るようになってます（同時にシールドも発動）。
これも考え直しておきます。
スコア面は敵弾消滅と同時に消した数だけボーナスにしてみようと思います。
あとその時間中に倒した敵も得点が倍加するとか。

>452
> 無敵状態で接近して撃ち込めるのが気持ちが良いのさｗ
怒首領蜂のオーラ撃ちみたいなシステムがあったほうが良いって事でしょうか・・・？
今のところショットは2種類あるんですが、
直線ショット（高速移動時）：連射速め
ロックショット（低速移動時）：連射は直線の半分だけど出る弾の数は倍。自機より前方の敵で一番近い敵を自動で狙う。
こんな感じです。単位時間当たりの威力は同じになってます。
直線ショットの方を近ければ近いほど高威力にしてみてもいいかなと思ったりしたんですが。
例えば「一番離れてるときはロックショットの半分で一番近いと二倍　中間の距離は同じ威力」のような感じで。

長くなりました・・・。
プレイ動画も載せてみたいんですが、重くてマトモに撮れないんで勘弁してください・・・。

人の意見を聞くのもいいけど 度を越すとつまらなくなるよ。
最終的に面白ければ異端はエポックとして受け入れられるから心配するな。バランス取りの方が重要。

音声無し、画質最悪のデモプレイでも晒せばアドバイス貰えるかな？

それなりに。

じゃあ晒してみます
いまのところ、こんな感じ
http://jp.youtube.com/watch?v=H-7NN13A_do
http://jp.youtube.com/watch?v=gRDVPM2VfbM

>>459
ニコにうｐればコメで感想書くぜ
草だって生やしてやる

なんかかぶったｗｗｗｗ
>>461
ようつべかー
家に帰ったら変な外人の振りしてコメ書くとするよ

>>461

早送り？
それともこのスピードが通常？

>>461
だいたいコレぐらいのスピードにするつもりだよ
速すぎかな？

PDA用に作ってるんだが、アルファブレンドとかちょっとしたことでかなりCPU食われる。
デスクトップは無尽蔵なマシンパワーでいろんな派手なエフェクト使えるからうらやましい。

弾幕じゃないし、速過ぎとは思わないな。
アイテムと弾が見分けづらい気がする。弾と同じ速度で降ってくるからかな。

>>461
斜めに移動するときＸＹ要素の速度を1/√2倍してる？低速移動がついてるのだろうか
なんか自機速度が変化してるように見える

あと爆発が明るすぎる。今はいいが敵が多くなってくると弾が見えづらくなってくるはず
弾が見えづらいと撃ち込みに行けない（ワイドショットのとき）から非弾幕の面白さが半減
爆発を白くフラッシュさせるのは初めの一瞬だけで、あとは地味にするべき

余裕があったら敵の動きを増加量で制御する（直線的な動きにしない）と見栄えが良くなる

文句ばっかりだけど、こういうハイスピードなｓｔｇ好きだな
てか今作ってるのに雰囲気が似てる

斜め移動時の速度をどうするかはゲームデザイン次第だよ
1.4倍でも別に構わない

バトルガレッガですね、わかります。

ガレッガもそうだっけ

>>467
そこは盲点だったな
確かにコレは混同しそうだから、アイテムの移動に関しては少し工夫してみるよ

>>468-469
適格なアドバイス感謝
1/√2倍してなかったから、やってみるよ
（自機は攻撃中に減速する設定）
爆発は、明るさの減衰する速度を上げて、もっとシャープにしてみるぜ
爆発の規模はなるべく落とさずに済ませたいんだ

>爆発の規模はなるべく落とさずに済ませたいんだ
ボリューム感や爽快感が欲しいなら、暗い破片を飛ばすといいと思う
ただアイテムが見づらくなりそうではあるが・・・

>ボリューム感や爽快感が欲しいなら、暗い破片を飛ばすといいと思う
じゃあ破片もアイテムとして回収できるようにする、ってのも一つの手かもしれないな

表示の優先順位さえちゃんとしてれいれば、それほど見づらくなることはないと思う。
優先順位は大事だ。

敵機と爆発エフェクトのどちらを上にするかで迷ったけど
見やすさを優先するなら敵機を上にすべきだったか

　↑
その他の敵機
爆発エフェクト
実際に爆発してる敵機
　↓

とかは？

爆風が被って見づらくなるような敵配置を避けるという手もある

爆風で敵が死ぬようにすればおｋ

それ何てグロブダー？

改めて>>461を見て思ったこと
・黄色系の敵弾と爆発の色がかぶってる
・でかい敵が爆発エフェクトと似た弾を撃ってくる（でかいやつ）
・爆発エフェクトが下の方まで飛んでくる
この３点が気になった。
３番目に関しては、爆発エフェクトをゆっくりでいいので上方向に動かしてみてはどうか。
こういうシューティングは嫌いじゃないのでがんばってね。

>>461
見た感じすごく面白そう
たぶんわざとだと思うけど戦闘が全体的に高速なのもスピード感があって良いし
大胆に爆発する敵機を見ても、爽快感を重視しようとしてるのがすごく分かる
ただ欲を言えば、弾を喰らった敵機が死ぬまで何の変化もしないのが残念
弾を喰らった瞬間だけ白っぽく点滅するとか、死ぬ少し前は赤く変色するといった変化を加えると、
さらに爽快感が増すんじゃないかな？

>>482
>・黄色系の敵弾と爆発の色がかぶってる
　本当だ、これも盲点だった
　黄色じゃなきゃダメってワケでもないので、他の色を使うことにするよ
>・でかい敵が爆発エフェクトと似た弾を撃ってくる（でかいやつ）
　うーん、もったいないけど、あの弾は道中では使わない方がよさそうだね
　確かに紛らわしい気がしてきた
>・爆発エフェクトが下の方まで飛んでくる
　上方向に等加速度運動させたほうがリアリティ出るかも知れないね
　やってみる

>>483
>弾を喰らった瞬間だけ白っぽく点滅するとか、死ぬ少し前は赤く変色するといった変化
　なるほど、ダメージ受けてるのかどうか分かるようにすべきか
　素材増やすのはめんどうだから、色が変わるような描画関数を作ってみるぜ

意見を全部鵜呑みにすんなよ

それだけか。
どの意見に反対すべき点があるとかいうキミの意見は無しか。

>486
「頑張れよ」とか「期待してるぜ」みたいな、定番文句だから別にいいんじゃね？ｗ

>>485-486
実際に動かしてみて「何か違うような…」って思ったら元に戻せば良いんだし、
まずは言われたことを試してみようと思ってな
そういう試行錯誤って好きなんだよ俺

鵜呑みにされちゃうのはイヤだから一言書いておこうかとは思ったけどね。
ここまで作れる人ならそれくらい分かってるだろうと思ってそのままにしたよ。

取捨選択は本人がやるべき

>>489-490
色々試してみた後の、取捨選択の結果を簡単に報告しとくよ

　・敵の黄色い弾と爆発エフェクトの色が似てる件に関しては、従来の素材と”黄緑色方向に少しだけ色調補正した弾”と”色が変化する弾”を
　　混ぜて使うことで視認性が確保できたし、より綺麗な色合いになったような気がする。

　・爆発エフェクトと似た大きな弾に関しては、完全にこっちの設計ミスだから、赤色メインなのは変わらずに、特殊な形の弾を作成。

　・爆発が下まで飛んでくる件は、爆炎に上方向の加速度をつけるのを試したけど、なんかイマイチでな、
　　むしろ今までの爆発エフェクトに加えて敵の破片を飛ばしてブッ壊してる感じを強調する方向で素材作ってる。

　・敵の点滅や赤色変化については、攻撃命中時に白色に点滅するエフェクトのみ作成。
　　確かに”攻撃が効いてる”って実感は重要だと判った。
　　あと攻撃が命中するたびに小さな火の粉を飛ばしまくって削り感を出すエフェクトも作成予定。

今のところ、こんな感じ。
なるべく「攻撃してる！」「破壊してる！」っていう感じを出していきたいんだ。

そろそろ俺が動くものを投下する時のようだな

よくわからないが性的な想像をしてしまった

私自らが出る

プログラムとか一切知らないけど東方みたいなの作りたい
どの言語がいいと思う？
あと分かりやすい講座みたいなの載ってるページないかな

HSPあたりか

あえて１からC++を学ぶというのも

プログラミングの知識が全く無いなら、いきなりゲームではなくて
Pythonあたりで勉強した方がいいんじゃないかね。
大事なのは言語の文法ではなくて、プログラミング的な物事の
捕らえ方だから、言語なんて何でもいい。

実行効率やゲームを作るための情報量で言えばC++が一番だけど
C++だと文法の勉強だけで半年以上かかるかと。

Python とか Delphi とか良く聞くけど、いいライブラリでもあるのかい？
HSP か、CでDXライブラリ使っておけばいいんじゃないのかね。
乗り捨て前提で言語覚える必要ないっしょ。

>>499
CとPythonでは学習速度が違い過ぎる。
文法の差もあるが、Pythonの対話モードの存在も大きい。

HSPは言語設計があまりにも古臭い。
PythonからJava, C#, C++への移行はスムーズに行えるが
HSPからだとほとんど0からの学習になる。

pygameっていうゲーム用ライブラリもあるし、配布されている
ゲームは基本的にソースコードが見れるという利点もある。
ttp://www.pygame.org/tags/arcade

というわけで、俺はPythonがおすすめ。

CかC++で先人が作って配布しているライブラリを使うのが一番良い。
マイナー言語では質問を投げても返ってくることは少ないからな。

ライブラリで一番気になるのがGPLのように問題にならないかなあと

なんつーか、そんなこと気にする前に手を動かせよ。

>>503
いやもう別環境では動いてるソース持ってるんだって。
で、PCに最適化するために書き換える部分がいくつかあるんだけど
そこをどうするかで検討してるんじゃん。

ライブラリでGPL絡んであとでごちゃごちゃするの嫌なので
先に調査してるだけ。

手を動かせ＝自分で作れ
のつもりで書いたんだけど分りにくかったな。

ライセンス絡みの話じゃね

シューティング制作者の優しさは異常

シューティングくらい自分で作ってみようぜ！

趣味で2Dシューティング作りたいだけなら一生HSPでも別に困らんけどな
というかSBとかでいいんじゃないか
大多数の人はゲーム一本完成させる前に飽きるし、そういう人は言語習得の段階で飽きちゃうからな

言語によって習得しやすいとかしにくいっていう概念が良くわかんないんだが・・・

どの言語でも
絵を表示したい⇒絵を表示する命令探す
文字を表示したい⇒文字を表示する命令を探す
ってだけじゃないの？

ちょっと書き方が違うだけっていうか

いやーぜんぜん違う
HSPだと進化したBASICって感じで割りと簡単だけど
CでDirectXを使うとなるとそれなりの知識はいる。

その手間が全然違ったりするからじゃない

うむ

>510
言語によっては、机を用意して、その上に置くノートを用意して
ペンしか使わないのに筆記用具一式が入った筆箱を用意しないと
文字が書けなかったりするからな。

導入の手間を除けば、
CとDXライブラリが一番簡単じゃないかな。
それこそBASIC感覚で作れると思う。

>>504がソース持ってるって書いてあるのがすげーーーー気になる
どっかからパクってきたのか？

ライブラリにGPLが〜って気にしてても、自分でライブラリを作る選択が無いところを見ると
同人ゲーをPC基板に移植とかそういう仕事だったりするんかな。

GPLが読める奴はゲームなんぞ作ってませんよ

人権委員会に報告されちゃうっ（ﾋﾞｸﾋﾞｸｯ

BulletMLManager
の使い方がいまいちよくわからんのだがつかってる人います？

新しいgamedeveカキカキ

TopPage - game-develop.com wiki
http://wiki.game-develop.com/

GameDevWikiを何とかするスレ
http://pc11.2ch.net/test/read.cgi/gamedev/1156117275/

ただいまDXライブラリでシューティングゲームを作っているんですが
敵の軌道に凄い迷っています。
何かいいサイトとか教えてもらえると嬉しいです･･･

敵の軌道が軌道に乗らないと。

軌道の作り方？
それともどんな軌道があるかって話？
プログラム的な話ならともかく、ゲーム内容の話だったら他のゲームみて研究しなさいとしか

STGプログラミングとか、STGアルゴリズムマニアックスとか、こういう時には丁度いいと思うよ。

ありがとうございます。
あと質問の仕方が少し悪かったですね。すみません。
えっと、敵の軌道についてどういったプログラムの書き方があるのかを
聞きたかったんです。

>>525さん
ググッたらでてきました。
よさそうな本なので使わせてもらいますorz

>526
ある程度ゲーム作りなんかを経験したことある人間なら、
プログラム的にはそんなに有効なものではないけれど、

・やりたいことはあるけど実装方法が微塵も思いつかない
・あまりSTGに詳しくないので、（プログラマ視点からの）演出リストみたいなものが欲しい

とかなら便利だと思う

>>526さん
ありがとうございます。
とりあえずこれで勉強してみようと思います。

質問があります
敵キャラクターの色に関してですが、
敵キャラクターは背景の色とは、なるべく違う色を使って保護色でない見やすい色の方が良いと言われますが、
その際、敵キャラクターの色はなるべく統一させておいた方が良いのでしょうか？
例えば、
一面の森林ステージは、背景の緑色とかち合わないように敵は全員ピンク色系に。
二面の列車ステージは、背景の線路の色とかち合わないように敵は全員青色系に。
といったような感じで。
既存のゲームでは、どういったパターンで敵の配色を決めているのか教えてもらえませんか？

メカもので世界観を重視するなら
明度・彩度を変えたほうがいいんでは

確かに、やたら派手で目立つ戦闘機ばかりというのはワケ分からんな。
もちろん、わざとそうやる機体があるのは認める。

せめて背景とキャラは区別が付くようにしてほしい。
昨今のゲームってハードの能力が上がってやたら背景とか凝ってるんだけど
弾がわかり難いとかあるし
3Dを使って１軸固定の場合、いつ同一軸に来たのかわかりくいのとかあるからな〜

敵の動きを実装したいのですが、
私の作ったシステムだと、直線と、円書きながら移動の２パターンぐらいしか表現できず、
あまり、おもしろくないというか 見た目に欠けるのです。

そこで、どうやったら、敵の微妙な移動を表現できるのでしょうか？

全てのキャラの色が派手すぎると変だし
背景とキャラが区別ついた方が良いとなると難しい

現在使用している素材は、基本的に青色なんですが
下地が緑の部分では、キャラの彩度や明度を変えても限界がありますし
背景そのものの彩度や明度をかえると、
キャラが浮いてくれるのですが
全ての背景が夜みたいになってしまうのも考えものです

何か方法はないでしょうか？

>>553
システムってのが、どんなのかわかりませんが、
直線移動が実装されているのであれば、
下に直線的に移動した後
左上、右上、と直線的に繰り返し移動
みたいに直線行動の組み合わせでも
わりと微妙なキャラの動きは作れると思いますが。

敵の微妙な移動について詳しく

>>533
他人の作ったゲームを観察すればいいだろう。
まぁ、名作と言われるゲームでも、意外と単純な動きしかしてないけどね。

連隊として出てくるとかねー。

>>533
放物線をはじめとして、いろんな数学的曲線を見て利用できそうなもの探すのはどうよ？

敵、弾の動きとか出現を全部プログラム中に直接書いちゃってんだけど

BulletML以外で自分で弾幕定義とかしてる人いる?

way弾とかの関数は独自に作ってるよ

>>539
void ShotNWay(引数);//NWay弾
こんな感じの関数ならいっぱい作ってるよ

ちょっ速のPCがあればスクリプト言語など不要ですね、わかります。

逆だろ

俺も最初逆に思ったけどたぶんコンパイル速度が速いってことだろう

c++だって、コンパイルなんてせいぜい数秒じゃないか？

マ以外の人に編集や調整を頼むなら簡単なスクリプトは要るかもだが
俺ずっと一人制作だったから弾幕定義まで一個一個全てdllにして
プレイ中に修正可能にしたりとかヘンテコな事やってる

>>546
それってヘッダーファイルじゃダメなの？

>>547
ヘッダーファイル？よく分からんが
リリースビルドのexeでもプレイ中にコード差し替えしたいという
意味不明な俺要求で全部dllにしてた。ただそれだけ。

エディットコンティニュー用のデバッグ情報があるなら
デバッグしながらでも普通に書き換えられるけど

少しスレチかもしれませんが質問です
効果音で、雷電2及び雷電DXのボス破壊時の効果音のような
気持ちいい感じというか、こもった感じではない爆発音って、
配布されている効果音の中には、意外とないように思えるのですが
どなたか、ご存じないでしょうか？

スピーカーのせいなんじゃないの？

的外れなレス発見

>>549
それはアレだ。プロが作り出す音響効果の素晴らしさってやつだよ
音響効果のノウハウに関する公開情報って異様に少ないんで
俺みたいな門外漢のマには何が何やらサッパリだ

アニメ界で有名なサウンド○ィ○のお偉いさんなんて何十年も前から
ずっと現役の職人さんだよ。すげぇよな

>>552
なるほど……
フリーで見つけるのは難しいということですね
亀レスですみませんでした
ありがとうございます

マウスだけで遊べて、パワーアップなしで爽快感UPできる方法
を追及した結果、マウスでコマンド入力し、成功すると一定時間
攻撃力がアップするってのを作ってみたけど、（効果が高いほど
入力操作が多い）コマンド体得するまではいいんだが、
一通り覚えると飽きる気がしてきた･･･。

なんかうまい使い方ないだろうか･･･。

敵クリックで撃破。

>>554
左ｸﾘｯｸで線を描き、右ｸﾘｯｸでｽﾎﾟｲﾄ。

マウスで遊べるシューティングっていうと、喧嘩番長のやつが
結構面白かったよ。
ttp://jp.shockwave.com/games/arcade/shooting/tsubushi/play.html

晩夏県庁

>敵クリックで撃破。
>左ｸﾘｯｸで線を描き、右ｸﾘｯｸでｽﾎﾟｲﾄ。
インスピレーションは得られた。

喧嘩番長30分ぐらいやっちまった・・・。
が、方向性が違うことに気づいた・・・。

もうちっと考えてみるわ。

えられたんだ・・・？

>>539
単純な弾幕は作れるようにしてあるな。
予めリストのように自分の型の変数を持つ弾幕インターフェイスを作ってそこから
n-way弾、全方位弾、連なる弾、発射調整用（ここが色々作れる。）のクラスを作る。

これで初期化時に弾の方向、方向間隔、同時発射数などを初期化できるようにした後、
複数の弾幕インスタンスを組み合わせるだけで、簡単な弾幕は作れる。
例えば5-wayインスタンスの変数に3包囲奇数型全方位弾を登録しておけば、
奇数3方向に5way弾が打てるようになる。

way弾の組み合わせでほぼ事足りるからなー
東方みたいな弾幕作りたければだいぶ変わるけど、あれはあれで別だし…

ストラテジーパターンと、
「弾を発射する弾」で全て済ましてるな

まだ形になっていないけど、コマンドシステムは実装したので、
アゲてみた。
ttp://gamdev3.hp.infoseek.co.jp/cgi-bin/up/upup.html
の
[No_0293.jar] マウスコマンド習作
ってやつがそれ。

ちなみにインスピレーションから得たものは未実装。

発動した技をフル活用させようとするとなんかパズルゲーみたいに
なりそうなんだよな・・・。

思いつきのアイデア求む。

>>564
4軸ｺﾏﾝﾄﾞを簡単な図形に置き換えるとか。

タスクシステム難しいな・・・
どう実装すればいいかさっぱり。

オブジェクト吐いて連結リストにしておわったら削除みたいな感じでいいのかな

リストで繋いだオブジェクト群に操作を加えていけばそれでタスクシステムなんじゃないの

>>566
リストなんか使わずに配列に入れて毎回全走査でいい。
親子関係とかなければ、これで十分。

要点は、
・全てのキャラクタが共通の基底クラスから派生している
・1フレームに1回呼ばれる状態更新メソッドを持っている
この2つだけ。

オブジェクト自身にリスト構造を持たせるのは前時代的な
実装だから、俺は薦めない。

配列全走査なんかしたら処理順序が狂うだろう。
弾幕シューなら敵弾の前後関係とかに影響が出る。

というか双方向リストとかは覚えておいたほうがいいだろ。
それにネットでは解説されてるし、組み込んじゃえば
自分が触るのはリストに関係ない構造体のデータだけだし。

自作でオブジェクトをリスト化するのが面倒なら、
STLのlistで、オブジェクトへのポインタを管理すればいいんジャマイカ？

オブジェクトがリスト構造を持っていなくて、独立したリストがオブジェクトへのポインタを
持たせることも出来るだろうけど、あんまり分ける意味を感じないな。
配列は使い勝手を考えると流石にありえないと思うけど。

配列で領域確保してリストとして作動させるのが簡単ってなんかの本で読んだ覚えがあるな。
もちろん配列を超えないこと前提で。

>>573
そりゃそうだけどね。

でも今となったらどっちもどっちでしょ。

その都度領域を確保する場合はmalloc、freeのコストが発生。
配列で領域確保してリストとして機能させる場合は
使っている配列で構成されるリストと
あいている配列で構成されるリストの
二つが存在して、ややこしくなる。

>>573
たしかHSPとCだったと思うけど、配列を使ったリスト構造の実装をこの板でみたぞ
ついでに情報処理の試験でも出題されたはず

配列を使った場合、静的に領域を確保するので、領域の上限がキッチリ決まってくる。
しかし、動的に確保する場合でも、ゲーム中にmalloc使って・・・なんて事はしないから条件は同じ
（ゲーム開始前に一気に確保）

>>574
>使っている配列で構成されるリストと
>あいている配列で構成されるリストの
これはmalloc等でも（ゲーム開始前に一気に確保）をした場合は同じ処理が必要

あれ？ひょっとしてどっちで実装してもメリット・デメリットあまり大差ないのか？
配列ならポインタでエラーがでないから、デバッグが多少は楽になるかもしれんが・・・。
（ポインタより配列の添え字とにらめっこするほうがらくだよね？ダンプ出しやすいし）

>>566だが頭がおかしくなりそう

基底クラス
│
　├自機クラス→リストへ挿入
　│
　├敵機クラス→リストへ挿入
　│
└弾クラス
　 　├自弾クラス→リストへ挿入
　　 　└敵弾クラス→リストへ挿入

な感じでいいのか？
といってもこれすらどう組んでいいか分からん

C++とオブジェクト指向もっと勉強したほうがいいですね、わかります
　

俺の場合は敵機・自機・敵弾・自弾・・・でリストをわけてる
そうすれば描画順を気にしないで済むし、例えば敵弾に移動速度のパラメータを持たせて
動的に全ての敵弾の速度を一気に変えたりできる

配列でのメモリ確保ってのは要するにメモリプールを作るってことだろ
そんでそのプールを固定長に区切ってそれぞれの領域をオブジェクトとして利用する
プールを使えばfree/mallocに伴う処理とかメモリの断片化を防げるって利点がある

> あれ？ひょっとしてどっちで実装してもメリット・デメリットあまり大差ないのか？
> 配列ならポインタでエラーがでないから、デバッグが多少は楽になるかもしれんが・・・。
> （ポインタより配列の添え字とにらめっこするほうがらくだよね？ダンプ出しやすいし）
サイズの違う領域を確保したり開放したり繰り返すと、
あとで再利用されない領域が発生しやすい。

本棚の本をランダムに出し入れするイメージかな。
（勿論既に本棚に入ってる本を左右にずらすのは禁止でｗ）

おまえら細かい実装の話に熱くなりすぎだろ。
そんなのは個々人が好きなようにすればいいんであって、
もっと全体の設計の話をすべきじゃないか？

class hoge{
public:
　hoge(int id);
　virtual ~hoge();

private:
　int hogeid;
};
typedef std::list<hoge*> hogeList;

main(){
hogeList hogelist;

hogeClass obj1(1);
hogeClass obj2(2);
hogeClass obj3(3);

hogeList::iterator it = hogelist.begin();
hogeList::iterator ++it = hogelist.insert(it, &obj1);
hogeList::iterator ++it = hogelist.insert(it, &obj2);
hogeList::iterator ++it = hogelist.insert(it, &obj3);
}

とりあえずSTLのlistでやってみたがこんなんでいいのかな
これに自機、敵機、自弾、敵弾、その他クラスをつっこんで描画やらのループにいれればいいのか？

STLのlist使うなら

hogeList　objectlist[n]; //n=0自機 1敵機……
objectlist[i].pop_back(new hoge(...)); //オブジェクト生成

あと、hogeクラスのhogeidってなにに使うんだ？

寝ぼけてるな…
pop_backじゃなくてpush_backだよ・・・

何か話をぶった切って悪いんだが、
リプレイで早送りを実装する場合、
本来1/60秒経過したら更新するところを1/240秒経過したら更新、とする以外でいい方法ある?
この方法だと、処理落ちしたところは早くできないんだよね。

だいたい処理落ちの原因は描画だから、
描画を省略したらいいんジャマイカ？

エフェクト類の計算処理を省略するとか
描画処理を間引きするとか

>>584,585
サンクス。レスしたあと席立ったら普通にその考えが出てきたorz

アフリカでは良くあること

オープンアプリ向けに作っている人は少ないのかな

>>581
いんや、適当にオブジェクトを突っ込むのを実装したら
こうなるかな、ってことで別に自機とか弾とかの概念はないです。
あとｔｈｘ。

今度は実際にクラス作って実装か・・・
処理してる物体がPCじゃないだけに怖いな

>>574
つ メモリプール

>>569
＞敵弾の前後関係

表示順序が問題になるような（半透明処理）が無ければ
表示上の前後関係は深度バッファまかせにできるから
std::vectorを使った順序なしリストの走査順で描画しても
何も問題ないよ

>>568
たしかに敵や弾は自身がどんなコンテナにぶち込まれてるかなんて
本来なら別に知る必要のない余計な情報ともいえるから
boost::intrusiveみたいな押し入り癒着してくるタイプのコンテナを下手に使えば
軒先貸して母屋ひっかきまわされるだけで終わることもある

この手の侵入式（？）コンテナがドマイナーなのは利点欠点を勘定したら
欠点のほうが目立つケースのほうがずっと多いから

>>566
>>567
＞タスクシステム

一部でそう呼ばれ、未だに一部レトロマニアに珍重・尊崇されているものの実態は
boost::intrusive同様、コンテナのパラメータがオブジェクトに癒着している。
このパラメータは自前のアロケータ内部でも使われるものなので
アロケータとオブジェクトが癒着しているとも言える。
またオブジェクトのメンバ変数は単なる汎用のワークメモリという扱いで
状態遷移のたびに仮想関数テーブルポインタを上書きして型が別物に化ける。
継承図とか完全無視で型が変化するので状態遷移の前後でメンバ変数が
様変わりする。
これは静的型言語のポリシーを完全に逸脱したものであり、アセンブリ言語を
使っていた自由の時代ならともかく、静的型言語であえてこんなアクロバットを
披露するのはある種の変態プレイとか路上オナニー。人前で自慢できる趣味ではない。

こんな妙なことするなら、動的型言語を新たに創造しそれをエディットする環境を構築するか
既存のスクリプト言語(LuaとかSquirrelとか)を組み込んだほうが良い

話がわき道に逸れた
敵や弾をどんなコンテナに入れるのか、これは配列でも連結リストでも
n分木でも好きなようにすればいいが、その要素を走査して更新いくという
ゲームの基本的な仕掛けを「タスクシステム」って呼ぶのは変かなと

あれはある特殊な、もはや時代錯誤ともいえる実装に付けられた
固有名詞、ローカル用語なのだから

ちなみに正確には擬似タスクシステムな。

>>595
教えてくれ。あれは一体何の擬似なんだ
オペレーティングシステムにおけるマルチタスクシステムのタスクの擬似なのか？
ならば要件を満足してない（コンテキストスイッチすらできない）から擬似ですらないぞ
スケールも素材も使用目的もまるで違うただの玩具というべきだろう

>>596
OSの構造しらない昔のゲームプログラマーが適当に名付けただけだよ。

その昔のゲームはキーボードからコマンドを入力するまで
イベントが動かないのもあった。アニメーションもろくにできなかったしね。

その点アクションやシューティングは一定サイクル(FPS)で処理を続けてるので
タスクといえる。だから擬似タスクシステムとしようってことでしょ。
組み込みのちょっとしたプログラムもRTOSとか呼ばれてるようだし。

擬似なんて言い出したのは素人だろ
エンドたんでも引っ張り出して詰問してみれ

まぁどっちでもいいや
現場では擬似タスクは全く聞いたことないし、タスクにしたって
使わなくなってずいぶんと久しい。ほぼ廃れた言葉といっていい

いまどきタスクシステムなんて単語を駆使してるのは
一部の懐古趣味野郎とかマムコ信者くらいだ。いずれにしろ老害。
痛い素人の真似するのが本望でないならもっとかっこいい言い方を
模索するべきだろう。ゲームエンジンとかオートマトンエンジンとか

めんどくさいからタスクシステム、擬似〜〜でも良くね？

ケチを付けるのが目的だから細かい名称なんてどうでもいいのさ。

>>600
いやゲームエンジンだとか、商業的になるとミドルウェアという言葉で片付く。

擬似タスクシステムってやっぱり古い時代の名残だよ。
マイコンなんかで使う用語が規模も似たようなゲームマシン時代に
当てはめて生み出した造語

描画順はともかく、固定長配列じゃオブジェクトの追加に時間がかかるだろう
毎回走査して空きを探すのか？
富豪的に見えて、面倒なだけじゃね？

>>603
いやだから固定長配列だって、リストにすればOKだよ。

でもテストして最大値を割り出しておかないとだめだけどね。

待って、俺が誤解していない場合、
やっぱりオブジェクトを追加するときに、
空きを探して配列を走査する必要がないか？

>>603-604
富豪厨召喚呪文が唱えられたようなのでム板からカッ飛んできた
配列厨と罵倒されることもあるけど私は元気です

さて、>>591のおじさまが言ってる配列による順序無しリストってのはたぶん
要素削除時に最後の要素をそこに移動＆上書きするものだと思うよ
順序がメチャクチャになるけど条件が許すなら大丈夫だよね

アルファブレンドなしの2D弾幕ならZ値で上下関係は保てるしね

>>605
配列でオブジェクトを8コ取ったとするよね
これには当然リストを構築するためのポインタも入ってるとする。

配列　□□□□□□□□

で、ゲームを起動した際に初期化処理として

使用中リスト NULL
未使用リスト □->□->□->□->□->□->□->□->NULL

こうやって置く。

あとは関数でも用意してオブジェクトを追加したければ

使用中リスト □->NULL
未使用リスト □->□->□->□->□->□->□->NULL

使用中リスト □->□->NULL
未使用リスト □->□->□->□->□->□->NULL

・・・・

使用中リスト □->□->□->□->□->□->□->□->NULL
未使用リスト NULL

使わなくなればまた未使用リストへつなげばいい。
malloc freeのコストはないけど配列で確保した個数以上は管理できない。

ところで富豪厨はシモジモの日々の苦しいやりくりとは無縁なので
タスクシステムとかの貧民的なアプローチに興味ないのですが
このあいだ「タスクも知らないの？プギャー」と貧乏人に煽られたので
ちょっとシメてやろうと思ってタスクスレを開いたら既にタスク派が
盛大に虐殺されていました

あまりの恐ろしい光景に震えあがってム板に帰りました

>>605
空きの部分も線形リストで結んで管理するのが
データ構造では一般的じゃなかったかなあ

>>607
OK理解した
要するにメモリプールに固定長配列を使ってるわけね
って>>577が既に書いてたし
物覚え悪くてスマソ

>>606
コピーのコスト（ｒｙ
これぞ富豪

隔離スレあるんだからタスクシステムそのものについてはそっちでやってくれ

むしろ隔離スレから出てくるというゲハ板→ニュー速現象が・・・
こういう全体の設計って結局は人それぞれだから、あんまり2ch向けの話題じゃないな

しかしレスから見るにＤＳとかＰＳＰ辺りで作ってるのかな？

>>612
今となったらオブジェクトの管理メモリより
素材の方がメモリ食うんだけどね・・・

>>610
富豪厨は厨なのでパフォーマンスとか興味ないんだけど
たまには庶民の期待に応えるためにベンチとり遊びもしてたよ

弾はサイズ小さい（弾種、座標、速度、深度とかで24Bytesくらい）から
削除時のコストは24バイトのブロック転送に過ぎないよ
弾アップデートのための巡回はただのリニアアクセスだから楽だよ
2000発の弾をランダムに飛ばしたり生成削除するテストしたときは
boost::simple_segregated_storageとの速度競争で勝利を収めたよ

ところでboost::simple_segregated_storageの中身って>>607のそれと
よく似ていたんだけど、これは使用中リストから外して未使用リストに
繋げるとき（またはその逆のとき）ポインタ書き換えは何回発生する？
それと弾アップデートのための巡回は隣接要素のポインタ経由の
ランダムアクセスになるよね

まぁ富豪厨にとっては瑣末な問題なので普通に弾一個一個で
malloc/freeしてたけど

>>565
スレありがと。仕事で死んでたんで見れなかったんで。
参考になりますです。

>>603
富豪的に見えるかもしれないが、いまどきのPCはリストをポインタ辿って
走査するよりも配列を順走査する方が同じ要素数なら1.5倍くらい速いよ。
追加のコストが増えても、その他の処理で十分ペイできる。

シューティングゲームに必要な要素数（せいぜい2000以下）だと、確かにそうなるかも
どどんぱちの裏ステージ的な状況だとどうか知らんがｗ

>>617

>>591、>>606、>>614の言ってる配列コンテナの使い方は
削除処理＝削除対象の要素を最後の要素で上書きするだけ。O(1)時間。
当然虫食いはないので要素追加時も空き要素検索は必要ない。O(1)時間。
これらの処理時間は要素数に関わらず常に一定。ただ要素サイズに比例する。
あと最大の欠点は削除・追加を繰り返すことで要素巡回順が不定になること。
だから「順序なしのリスト」なのね

これが問題にならないケースで使えばいい

固定配列にこだわって富豪ってのもなんだかな。
俺は大富豪なので弾幕シューでも容赦なくnew/deleteするが。

>まぁ富豪厨にとっては瑣末な問題なので普通に弾一個一個で
>malloc/freeしてたけど

>>603
シューティングでは最初に発射された弾が最初に画面外に出て消滅(FIFO)するような気がするので、
空きオブジェクトをリストで管理しなくても、キュー(リングバッファ？)っぽく管理してもいいかなと思って、
最期に取得したオブジェクトの位置を保存してみたりして
試している今日このごろ。

>621

Before----------------------------------------

Σ三＞　　　　-　　　　　　　　-
　　　　　　　　　　　　　　　　　　　敵


After----------------------------------------

Σ三＞　　　　　　　　　　　-　　敵　　　-
　　　　　　　　　　　　　　　　　　↑

>>622に言おうとしたことかかれたｗ

敵とか地形が邪魔をしないゲーム（と呼べるのか？）であれば
>>621の言うようにFIFOでも成り立つがゲームらしくすると
敵もしくは地形で後に発射した弾が消滅する可能性だってある。

貫通弾にすればいいというかもしれないがやっぱり
動的にオブジェクトが増えたり減ったりする場合は
リストが向いてる

>>622と>>623のやさしさに泣いた。

そこで、対策としてとりあえず、配列の大きさを十分に大きくしておくことと、
使用中のオブジェクトに関しては、「使用中です」フラグをつけて、スキップしようと思うんだ。

配列さえ十分な大きさがあれば、
配列を一周するまでにきっと最初に撃った弾も画面外に出て消滅してるはずってことで

どっかで

class hoge{
int x;
int y;
char[256];
}

のcharがフリー領域として使えるとかあったが、どういう仕組みなんだ？

sizeof(char*256)バイト分確保しとくから好きな型にキャストして使えってことじゃないの？

んでも、C++でわざわざこんな方法するかね？
もっと別に良い方法があると思うけど。
よくわからん。

Cではそんな組み方してたみたいね

placement new用にメモリをプールするためにchar型の配列使ってる教本があったな
素直にnewしたいオブジェクトの配列にしろよ、と

東方も順番だけ記録して固定長配列でやってそう
最後尾まで行くと最初に戻って描画順序狂ってる時があるし
cave系はlistっぽいけど

普通の2D弾幕系STGなんてどっちで実装しても問題なしじゃね？

ぶっちゃけ最近のPCのスペックならどっちでも余裕だろうな

ブルーセイバーズやテイルズギアのところはBASICで作ってるらしいけど
どうやってオブジェクトを管理してるのか気になる

みんなで一緒に富豪厨になろうぜ。

>>631
富豪厨でなおかつ玉葱狂信者なのでLGPはよく知らないんだけど
マニュアルを流し読みした感じでは配列使ってやりくりする以外の手がないような。
配列の添え字（番号）を使って連結リストとか

3Dのアニメーション用にフレーム（座標系）の親子関係があるみたいだけど
姿勢と座標を自動変更（線形的なアニメーション）するためだけのもので
ユーザー定義の変数を入れ込んだりユーザー定義関数を登録して
ゲーム独自の処理をかませるようなことはできないくさい

ゲームとして面白ければ富豪厨だろうがなんだろうが関係ないぜ、
と言いつつ結構細かいプログラムに拘ってしまう俺降臨
無駄な処理を削って云々とかよりも、はやく体験版を出して色んな人から意見を貰った方がためになるのに…orz

公開してから「フリゲ≒軽くて当たり前」信者の対応がタルくなるけどな！

>>629
それってステージで描画されるすべてのオブジェクトを前もって生成して
あとは順番に描画だけしてるってこと？

東方はやったことないんで推測だけ。

>636
固定長配列を前から見て、「空席があったらそこに座る」ってことじゃないかと。

>>634
よう俺
最近はアイデアが浮かばないから無意識のうちにギミックに凝ってしまうのだと気づいた。
勇気を出して前に進むのも必要だと思うぜ。

ygs2000を使って縦スクロールＳＴＧ作ってるんですが、
インポートライブラリのatan2(y,x)の戻り値が、0から65536になっているんですよ。
どうすれば、戻り値を0から360度の範囲に変換できますか？

ygsは知らんけど、65536 == 360度として考えるなら

int deg = atan2(y,x) / (65536/360);

元がどう見てもintなんだから、360掛けてから65536で割る方がいいだろう。

俺なら

* 360 / 65536

とするけど。

って書こうとしたら既にかかれてたｗ

>>639
勝手な予想なんだが、それ角度が360度　= 2π(rad)を超えても気にせず計算できるようになってるんじゃね?？
大抵の三角関数はラジアンで実装してるだろうから。
違ってたらすまん。

と思ったけどすごく見当違いですね、なかったことに。

>>639
Selene？

むしろ、ゲーム自体を65536度にあわせて設計したほうがいいかもしれない

おまいら話ズレすぎだろｗ

横シューの背景ってどうしてますか？

横にスクロールさせてます。

お前頭いいな

もう決着ついてるかもしれんが、配列の空き走査なんて、
描画の処理時間に比べれば、微々微々たるもんだよ。

ループ中にnew/deleteする方が非効率だと思うけどね。

いまさらすぎて噴いた

空席を見つけて適当に座る、って言って通じるもんだろうか？

つか何この空気コテ

トリップでググれば哀愁漂うLinux板の糞コテ

>>647
シューティングツクール的な発想でいくなら、16x16(ピクセル)のタイルを画面一杯に敷き詰めてた。
あれ、32だっけ？

む？
俺は普通にそうしてるけど、シューティングツクール的発想以外だと違うの？

画面サイズと同じくらいのテクスチャをくるくる回して、
その上に当たり判定のないオブジェクト配置してるけど

インベーダーやミサイルコマンドのように、そもそも背景が動かないというのも一つの選択肢だな。

最近の個人製作なんかでよく見る、雲模様みたいな画像を
加算、乗算処理なんかしつつ流していく手法も結構面白い。

>>656
ずっと前に見たどこかのエロゲ会社が無料で配布してたやつは
画面と同じ大きさのbmpが10枚くらい入ってたよ。

テクスチャを使うゲームの場合、
画面サイズだと正方形じゃないから無駄にVRAM食うのが気になって、
サイズ一つ下(512x512)のテクスチャをフィットするように拡大して使っている貧乏性な俺。

レイヤーのビットマップを設けて、
表示する際の座標をずらせばいいんじゃあ？

皆の言葉を信じて、背景の描画方法を
16×16のマップチップを敷き詰める方法から、
一画面〜四画面分の画像をベタ表示する方法へ変更してみた。

なんかリプレイ時の早送り動作が軽くなった。

リプレイ機能ついてるのか。

人気あるのかな。リプレイ機能って。

初めてリプレイ機能を実装したときは感動した。

今時ないほうが珍しいな
デモ見せるにしても必要だし

>>665

俺もｗ
リプレイ機能自体は早々に作ってたんだけどうまく再生しなくて長い間放置ぎみだったけど、
結局初期化されてない項目があった事に気づいて、ちゃんと動くようになった時は感動した。

リプレイ実装のおかげで、デモの実装も実現したし、デバッグにも役立つようになったｗ
（テストプレイで、キャラが想定外の動きをした時、リプレイを取っておいて
　修正後にリプレイを実行して、ちゃんと直ってるか確認する）

>665
俺も俺も！

その時はリプレイをどうやって実装すればいいかも分からなくて適当だったけどなｗ
（ちなみに全ての入力を保存すると言う、よくある方法だった）

そのリプレイ処理のおかげで、だいたい1日でポインタやファイル読み書き、ビットフィールドの操作とか覚えられたし。
人間、必要だと思ったらすんなりと頭に入るんだなあと思ったよ。

逆に、他人がポインタで詰まってても教えられないという欠点はあるがｗ

非ポインタとポインタは一言で言えば、
変数の中身を取り出す時に、値をじかに取り出すのか、それとも住所を取り出すか。じゃね？
ポインタは住所をやり取りする、と。

リプレイはまだ実装した事無いなー。今度実装してみよう。

キー入力保持のリプレイを他のマシンに持っていくとうまく動かないことがあるんだよな。
浮動小数点の計算誤差が若干違ったりするからだと思うけど・・・

INTELとAMDのメジャーなCPU(要するにIA32互換のやつ)しかサポートしてない俺は
とりあえず

・ゲームの進行に直接作用する計算は全てFPU(x87互換のやつ)に任せる
・_controlfpとか使って計算精度等をきちんと指定する。

これで上手くいってる
FPUバグ持ちクラシックペンティアムとかもう骨董品だから無視してる

>>670
ttp://www.01step.net/tobitsuki/bbs/test/read.php/tobi_bbs/1116256631/18

>669
似たような説明はしたことがあるが、通じてるかどうかが怪しいｗ

XMLでシューティングゲームを記述できるエンジンを作ってるんだが、
敵の動きを高度にプログラムできるようにしようとすると、
結局ソースで実現した方が良いじゃないかという気がして、何だか悲しい。
Flexみたく、XMLの中にプログラム(or スクリプト)書きはじめるような仕様を作ったが最後、
100％エターなる。

XMLてのはデータの構造を記述するためのものだろ
それでロジックを表現しようとするのがそもそも間違いだと思うが・・・

そのXMLによるシューティングゲーム作成にはどんな利点があるんだ？

動作ロジックはハードコーディングして、配置や個体パラメータを
XMLデータで指定するだけでもいいんじゃね？俺がやってる方法だけど。

敵の出現タイミングとか位置だけ外部ファイルで定義するようなもんか
それだったらXMLの方が見やすいかもな
エンジンとして公開するならハードコーディングの部分にかなりの工夫とバリエーションが必要だな

最初は、スクリプトでシューティング作れたら、楽かなあなんて思って始めたんだけど、
XMLだと、最初から読み込んで解析してくれるライブラリがあったから、使ってみた。

ちなみに、某シューティングツクールのように

「自機に向かって移動」「移動」「弾発射」「敵発射」「なにもしない」「自爆」

で敵の動きが完結するなら、
敵の動作ロジックも全てXMLで記述できる。

>>674

XMLじゃないがスクリプトでシューティングのオブジェクト配置したり
するのならすでに弾幕風とかあるぞ。

技術的な会話しているところに、空気を読まず質問

縦スクロールＳＴＧで、アイテムを放出する味方機を出そうと思っているのですが
なんかぱっと見て敵機にしか見えなくて困っています。（普通に避けてしまう）
見るからに味方機として出現させるために、何か良い方法はないでしょうか？

>>680
・軽めのカットインとかメッセージを表示して見方機が来たよをかもし出す
・東方のボス戦の場合は画面下にボスのx座標がわかるようになってるがああいったマーカーを出してあげる。

で、説明書に書いておけばOK?

>>680
その味方機が敵の弾を喰らうとか

味方機と自機のカラーを統一するとか。

>>674
てゆかbulletMLあるよなぁ
674のも使ってみたいが。

>>680

・敵のカラーとは明らかに違う、目立つ明るい色にする。
・デザインの系統を敵とは一目見て違うようにする。
　（敵が直線っぽいデザインなら、曲線ぽいデザインに、敵が生物っぽいなら、メカっぽいデザインに）
・自機と同じ形、同じような色にする。
・明るい色で縁取りするとか、とにかく他のキャラや背景と比べて「浮く」ようにする。

動き方でも差別化をはかりたいね
小型なのにゆっくり現れて消えていくとか

機体に「味方」って書いておけ
ってのは冗談だが、自軍のエンブレム的なものを作っておいて、
それとわかるように機体に表示しておくのも手だな

救急車が飛んでくるしかあるまい

ちょｗそれBeeメイツ

ツインビーも救急車だったような・・・

多くのレス、ありがとうございます！
絵の素材にフリー素材を使用しているため、
デザインの系統分けをしたり
エンブレムを書くのは難しいものがありますが
（雰囲気的な意味でも、救急車も厳しいです）

縁取りや、色の統一、カットインでの表示
なんらかの味方軍に統一の記号をつける
敵の弾を食らうなどの演出は、実装できそうなので、試してみることにします
本当にありがとうございました！

質問者が納得したうえに話の腰を折るが
製作者が気にするほどプレイヤーは見た目にこだわってないし
慣れてしまえば気にならない
だからよっぽどややこしいデザインでなければ結構適当でも大丈夫

こちらも流れに乗って技術的じゃない質問を一つ。

ショットタイプについてなんですが、
ショットボタン長押しで低速移動＆ショット変化ってのと
ショットとショット変更のボタンが別になっているのがあるじゃないですか。
あれってどちらが一般的なんでしょう？
最近は長押しで変化するのが多く見られる気がするんですよね。
でも昔はチェンジするボタンがあったし・・・。

ボタン配置は長押しで変化するタイプは
�@ショット　�Aボム等　�Bフルオート
チェンジするボタンのついてるものは
�@ショット　�Aショットチェンジ　�Bボム
こんな感じなんでしょうかね。

オプションで好みで変えられるようにすればいいじゃないって言われればそうなんですが気になったので・・・。

>>693
メインウェポンのパワーアップアイテムが一定時間で種類が切り替わるようにしとけ.
ウェポンチェンジしたくなったらその色のアイテムをとる,と.

>>693
銀銃みたいにﾎﾞﾀﾝの組み合わせという手もある

ショット変更ボタン式は、
自機の現在の武装を記憶して、目的の武装に切り替えるには何回変更ボタン押さないといけないか、
を常に考えないといけなくて煩わしく感じる。
武器別にボタン用意するか銀銃式にする方が手順を省略できてやりやすい。

>>694
アイテムでチェンジかぁ。
怒首領蜂みたいに最初からタイプを決める形式でやってるんで
通常時と低速時の変更をどうするかで悩んでるんですよ・・・。
アイテムはパワーアップか、ハイパーみたいな感じになるかも知れないです。

>>695
ボタンの組み合わせって事は何種類か武装があるって事ですよね？
今つくってるのはそこまでバリエーションを持たせる予定がないんです。

とりあえず今は機体2種類とビット3種類で全6種類の組み合わせができるようにしてあります。
機体α：高速移動集中攻撃型（ビット可動範囲が狭い）
機体β：低速移動拡散攻撃型（ビット可動範囲が広い）
ビットＡ：機体の前で左右に振れながら前方に攻撃。
ビットＢ：移動した方向に攻撃が傾く。
ビットＣ：前方の一番近い敵を狙う。

ちなみに通常時はメインショットオンリーで低速時（変更時）にビット展開になってます。

高速／低速の切り替えと武器が連動しているのなら
怒首領蜂式がなじみは深いな

ゲーム性＆操作感と連動するべきだろう
即座に武器を切り替えさせる必要があるゲームなら長押しは向かないってだけ

蜂は強いレーザーで押し込むゲーム性と、ボタンを押し込む動作が非常にマッチした
心地いい操作感だよなぁ

そういえば少し前にリプレイに関する実装があったけど、その前段階として入力情報をどう管理してる？
ゲームパッドも管理するのでDirectInputを使うのが一番楽っぽいのでそれを想定して。
・DirectInputを使用して、KeyboardStateやJoystickStateを直接使用する。
・予めキーコンフィグ情報に応じてbool配列を吐き出す様な仕組みを作っておき、bool配列を読み取る。

後者だとリプレイ再生のさい、乱数情報とbool配列を保持していけば良いだけだから実用的かな？

リプレイやキーコンフィグ機能があるかどうか関係なく後者

弾幕風とBulletMLに泣いた。

こいつらに太刀打するには、もっと他の利点を押し出さなきゃな。
XMLスキーマとXSLT書いて、WEBブラウザでゲームの仕様が閲覧できるとかw

>>696 >>698 >>699
今のところプレイ中のショットタイプは2種類だけで、瞬時に変える必要もないので怒首領蜂形式でやってみますね。
アドバイスありがとうございました。

画像しかできてないんだけどどうすればいいの

十分な量の画像があるなら、素材スレかどこかで晒してみれば？

>>700
ゲームパッドやキーボード、マウスといった具象データを、
ゲームに与える抽象データとしてまとめる。
リプレイ用に保存するのは抽象データ。

>>704
その画像が素材として使えるなら欲しいと思ってしまう

おまえら一緒にやれやｗ

ツクール(SB)で製作してる俺は、お呼びでないような気がするから困る

>>702
俺はとにかく高速性を求めたものをこしらえたよ
オブジェクトプール、固定小数点、バイトコード、C/Javaライクetc
しょぼいSTGなのに、見えないところに無駄に時間をかけたぜｗｗ

もう弾幕には心の底から興味がないので、別のもので勝負をかける予定。冬か来年の夏な。

>>707
ttp://www2.uploda.org/uporg1528706.jpg
一応出しておくけど十分な量がない上に
まともなのは爆発ぐらいしかない

グラIIと見せかけてMSX系？

去年くらいから避けゲーとしての弾幕は減ってきてる気がするな。

>712
これ見てるだけで、今やってる仕事を破棄してSTG作りたくなってくるな。
素材だけで。そこまでのパワーを得られる気がした。

jpegなのは敢えてかｗ
まあ使う気はないがｗ

>>712
ゴーファーの野望エピソード2のリメイクを作ってるんだ

日本語は正しく使ってくれ。

つまり、

「ゴーファーの野望エピソード２」のリメイクを個人で遊ぶ目的で作ろうとして、
ドット絵を（トレスなのか１から作っているのか解らないが）作ってる途中。
動かす方の知識は無いままドット絵を作り続けているが、
これからどうすればいいのかわからない。

という話でいいの？

>>718
OK
ゆとりですまん
一応シューティングゲームビルダー使ってみたけど
途中で挫折した
ある程度知識をつけてからまたここにくるよ

まあがんばれや

エピ2を知ってる程度におっさんで今そんなんだと
もう一生かけても無理だな。残念だが。

開発を手伝ってもらうってのもいいと思う
まず音楽どうするんだろ、アレンジじゃなくて原曲かな

>>704
素材の出来が凄すぎて吹いた
しかし作っても公開できなさそう？
この辺の著作権がさっぱりわからん件

ともかくＳＢについては、ＳＢのスレに書き込めば、いろいろわかってくるとは思います
手が入るというなら、自分で良ければ手伝いますよ
未だＳＢを全然使いこなしてはないですが。

エミュからの吸出しを加工したもんじゃ無いの

そうなのか。STGほとんどやったことないから微妙に分からんことがある。

どうもこちらでは初めまして
とあるスレでWiki管理をやってたものです
そこの専属をやめてこの度7/10から新しいWikiにします
http://www.erc-j.com/stg/
STG製作のまとめWikiです
うｐろだもありますので良かったら使ってください

>>726
乙

http://frgm.jp/ フリーソフトで面白いゲーム まとめ（新）
復活したので好きなゲームに投票してくれい。

メタルブラックの1面終了後のボーナスステージの背景の表示ってどんなアルゴリズムなんでしょうか。
2D画を3Dっぽく表示させてるんだと思うんですが、拡大縮小を駆使するんでしょうかね？

よく覚えてないけどラスターと拡縮だっけか

ちょっと製作のモチベが上がらないので
少し作ったものをうｐします
以前、このスレの>>377でうｐして、
いろいろ意見をいただき、出来る範囲で修正を行って続きを作りました
前回プレイされた方もそうでない方も、プレイしていただければ幸いです
良ければ感想、意見お願いします

one case
http://www.erc-j.com/stg/
の左上にあるSTG-URLから入れるアップローダーのstg0261.lzhにうpしました。

>>731
とりあえず二つのモードともやってみたが、スタンダードはちょっとあっさりしすぎてないか。
でも5面6面は面白かったぞ。ここにやりたかったこと詰め込んだ感じｗ
最初なぜか死にまくってコンティニューしたが後半はそのまま進めてクリア。

チャレンジモードは確かに最初から難しいがこっちのが序盤から面白い。
スタンダードとチャレンジの構成をほぼ同じにして難易度調整するだけのが
スタンダードも面白くなるんじゃないかね。後方攻撃にも意味出るし。

ちなみにチャレンジはクリアできなかった。最後のシャッター地帯とか
沙羅曼蛇並に意地悪になってんのかねｗ

>>732
プレイしてくれてありがとうございます！
その優しさに泣きそうｗ

もともとこれはチャレンジの方だけで作っていたのですが
一面から本気すぎる
特に一面の機雷や三面の後方雑魚が鬼過ぎる
という意見を受け、
構成そのものを変える必要が生まれたため、
スタンダードがあんな感じに生まれた感じになりました。
プレイしやすさを重視させたのですが、
そればっかりが重視されてて、確かにあっさりですよね
もう少しスタンダードの調整は考えてみることにします。
難易度調整って、本当に難しい…

沙羅蔓蛇レベルのシャッターほど鬼畜にはしてないですｗ
そうすると自分自身がクリアーできなくなるのでｗ

>>733
>の左上にあるSTG-URLから入れるアップローダーのstg0261.lzhにうpしました。
の左上にあるSTG-UPL

だったのねｗ
試したかったんだけどなんのこちゃって思ってたｗ

>>733

俺もプレイさせてもらったよ。
前バージョンのスタート直後から殺る気マンマンな敵には正直マイッタ（苦笑）が、今回のは普通に楽しめた。
演出的にもおおっと思うようなところがいくつかあったし。
ただもうちょっとにぎやかにしてもいいかもね。

あと、起動にえらく時間がかかるのと、６面がなぜかスローモーションになる
（処理落ち？）のが気になる。

同じくプレイ。
最初なかなか起動しないんで思わずタスクマネージャを開いたら、
メモリ消費200MB超えてて吹いた。
もしや音楽全部起動時にデコードしてないか？

確かに起動に時間かかったねｗ
何か一気に読み込んでそう

プレイありがとうです！

>>734
なんかわかりづらい書き方してて、すまんかったｗ
国語ちょっと勉強し直してくる

>>735
全体的に地味なのは確かに
最低限、自機ショットは派手にしてみようとは思っていますｗ
製作して初めて、既存のSTGの爽快感の良さに気づけた件

>>735-737
起動時やたら重たいのは、自分自身でも気になっていたところ
問題点を調べてみます
うっかりループとかしてそうで怖い
プログラム部分は他の有志が作ってるものなので
>>736の言うようにデコードしてるのかどうかは現時点ではわからないです

6面は処理落ちだと思います。
多重スクロールかけたりしてたからかな……
こちらも軽くなるよう改善してみます

国語じゃなくてUPLがURLになってるだけでしょうｗ

俺も最初わからなかったけど、前回の書き込みみて間違ってると気づいた。

>>739
うああああ、今やっと気づいたｗ
形的に絶対URLだと思っていた俺涙目
わかりづらい日本語使ったから、誤解を招いたものだとばかり
すまんかった、さんくす

東方弾幕風以外でそれくらい機能の充実してるツールって何がありますか？

シューティングゲームの当たり判定って矩形、円形方式以外にあるんでしょうかね？

1回当たり判定が正確なの作ろうとして、
1ドットずつの当たり判定を画像から配列に読み込んだ。

□□■□□
□■■■□
□■■■□
■■■■■
■■■■■

こんな感じに。

それで、まず短形で判定してぶつかってたら、配列で細かい判定をした。
プレイしてみると短形と変わらなかったけどね。

abs(自機座標Xー弾座標X)＋abs(自機座標Yー弾座標Y）＜適当範囲

おれ適当に作ってみたとき、これでやってた。ひし形ですな。

>>744
すげえ、初めて見た

>>743
あーそれと近いことやってます〜

今うちでやってるモードだと１ドットレベルで当たり判定できるんですが
自機の弾の当たり判定の先端と敵の端が丁度のときは思ったようにいかないんですよね・・・

弾などのオブジェクトを基底クラスへのポインタのリストで管理しているのですが、
メモリプールとかどうしてます？
new/deleteは確保・解放速度、メモリ消費量で劣りますが、
boost::poolはサイズ固定なので派生クラスで使いづらかったり
boost:object_poolはクラス固定なので向きません

char型配列の形でプール確保
プールで管理したいクラスのnew/delete演算子をオーバーロードしてメモリをプールから確保

これでやってる

>>745
矩形の方が処理はやいから実際の使い道は微妙ｗｗ

巨大な敵ならいいかもしれません。

なんかみんなハイレベルなことやってんなぁ
クラスとかポインタとかよくわからん俺は全部構造体と配列で敵とか弾とか管理してる

>>747
boost::fast_pool_allocator

>>750
それでいいと思うよ。
抽象化だとか言っても結局は自己満足だ。
自分の作りやすい作り方を模索すれば良し。

>>750
まあ管理機能はあるタイミングで画面に何千もオブジェクトがでないのであれば
配列でいいんじゃね？
千越えるとさすがにリストでも使っていったほうがいいだろうけど。


>>752
でもさ、C言語でゲーム組んでてサイズでかくなってきたら
クラスみたいな実装形態にいつの間にかしちゃってたぜｗ

数種類のデータがあったらそのデータ毎にソースが独立してて
アクセスする際は専用関数を呼び出す。

効率は悪くなるが安全だしな。

それに実は双方向リストもたいしたことないんだよね。
どんなに構造体のサイズが変わろうが、次と前のポインターが入ってて
入り口と最後をさす管理用ポインターさえあればネットに転がってる
ソースをちょこっと修正すれば完成。

>>752>>753
なるほど…自分のやりたいようにやれば良いのか…
弾とか敵とか合計13000個くらい(敵弾が12500発)当たり判定つきでいっぺんに動かしたらさすがに60FPS維持がキツくなったけどこんなもんなんだろうか
CPUはせろりんの1.6Ghzでグラボは8400GS

一画面にそれ全部描画してるの？

>>756
全部描画してることになるのかな…
表示領域？キャラが動ける範囲、そこに全部描画してみた
自機はおろか背景も見えない

移動してはみ出た弾は勝手に削除、敵は常に360/1Fの勢いで弾を出させてたから弾切れ起こしてた

携帯でｽﾏﾇ

>>747
富豪厨はfailmallocが大好きです

なんか>>750が俺とよく似ている……ｗ

自分で自己満足ゲーム作ってる分には問題ないんだけど
Cを使うプログラマ、という観点から見るとダメダメだなぁと落ち込むんだよなぁ。

>>759
別に勉強すればいい。
それにC++とかでクラスを使いだすとあれこれ面倒だけど
Cでリスト程度ならネットで検索すれば解説もごろごろ出てるし
関数化してしまえばぜんぜん問題ない。

どうしてもこの処理がしたい！
でもそれをやるにはポインタが必要だ！

って状況になったら覚えれるよ。

もうC++でクラス使わないと何も作れませんorz

ってかこのスレ技術的な話多いなｗ

>>755
一つ一つ描画命令出すとそのくらいが限界かな
俺だったらポリゴンで一括レンダリングするけど
それなら10万はいける、あたり判定の高速化はまた別な

丁度、プログラムの高速化について雑誌で見てたからカキコ。

・メモリアクセスを少なくする。
・マクロやインライン関数をつかう
・sinやcosの数学関数をそのままではなく、テーブルにしてつかう

　生産性を犠牲にしない範囲で高速化を図るようにと注釈もあった。
　あと、高速化の有効性を自分で確かめる（時間を計測する）ように。
とのことでした。

>>763
まあありったけの負荷を改善する前と後でやってみればその方法はよかったのか悪かったのかわかるよね。

皆さんの自機はどういう設定がありますか？
戦闘機に限らずキャラ等でも。

人類最後の（ｒｙ

人間の母と魔族の父の間に生まれ、左目に破邪の瞳を持つ
外見15歳だが実年齢300歳
意思を持ち人の血を啜りながら生きる魔剣を使う
本気を出すと世界が滅びる
みんな死ぬ

設定が濃すぎてここじゃ語り尽くせないぜ

>>767
なんか俺以外にも厨設定でゲーム作ってる人が居て安心した

>765
目的地に商品や人を運ぶ途中の飛行船。
ぷかぷか〜。

なんで武装してて、なんで敵が襲ってくるのかは知らんｗ

海賊に襲われるから自衛してるんじゃね？
前近代では常識だろ

現代でも海賊いるしね

>>769
767はネタだろｗ

>・sinやcosの数学関数をそのままではなく、テーブルにしてつかう

以前にこの話が出た時に、時代遅れみたいな事言われてバカにされてたなぁ。

前時代の人間である俺はこの方法使ってるが。

>>774
今でも十分有効だよ。

sin cosって戻りがdoubleなんだけど実際そこまでの精度って2Dシューだといらないんだよね。

それにオブジェクトが多くなれば、毎回計算するのは馬鹿にならないし
実際のところ度換算で360度分くらいの分解能あれば十分だしねえ。

そうか、1周を256に分割するオリジナルの角度単位を作って
それ専用の三角関数を作ってる俺はアホなのか

>>776
いや、そりゃ8bitマシンとかでメモリもカツカツとかならそれもありだろうけど
そこまでつめなくてもintもしくはfloatで360度持ってればかなり精度いいよ。

360分割は少なくないか？
あとテーブル使うんなら、2のn乗に分割したほうが気持ちいい

>>778
intで管理して精度上げるために左シフトxnとかでやってるなら2のｎ乗がいいかもね。
うちは面倒なんでfloat管理したから2のn乗管理やめたよ。

>>731
結構遊べた。
機雷のバラマキとか、z軸変化Uターン編隊とか新鮮だった。
はね返りブロックをばらまいてくるボスでやられまくった。
個人的には、パワーアップは気前のいいのが好みだ。
次リリース、待ってるぜ。

三角関数テーブルは数年前に止めて以来使ってない。
正直時代遅れだと思う。

新時代のやり方ｋｗｓｋ

別に普通に数学関数使うんじゃね?

今のマシンだと、キャッシュの関係で、テーブル使うと逆に重くなるんだっけ？
よく分からんけど。

>>784
CPUのL1 L2のサイズにおけるテーブルサイズがどれ位占めるか
数学関数がどれくらいキャッシュを占めるかってことね。

別にテーブルが正解とはいってないよ。
ベンチ取って最適な方法選べばいいだけでしょ。

コンパイル後の機械語ステップ数やメモリアクセス数は
数学関数　＞＞＞＞　三角関数テーブル
じゃないの？

フツーのゲームくらいなら誤差程度の違いしか見られなかったから三角関数を使うようにした。

ただ、doubleを使うと整数系より重くなる、という話も
キャッシュの関係であったような気がするんだよな。
バス幅のバイト数の関係で。

>>786
だからそれはCPUとかハードによってぜんぜん違うんだって。

>>788
CPUの演算命令の実装で違うからなあ。
最近のx86だとSSE系とかあるしな。
バス幅はどうなんだろ？
今ってポイント間はシリアル化されてる場合もあるしな。
過去のパラレルバス互換のプロトコルになってるだけで＞例：PCIe

数学関数の実行ステップとすでに用意されたテーブルの参照とそこから持ってきたデータの掛け算
だったらそりゃテーブル化したほうが早いんだけど、問題はCPUキャッシュの存在。

>>731へ俺もコメント
　全体的によくできてると思う。でも中型機の攻撃パターンが少なく
単調に感じた。攻撃のパターンを増やすか、自機を狙い撃つような
雑魚を一緒にだしても良いかもしれない。
　期待してます！
　
　それとは別に、ボス戦の音楽、ギガウィングで聴いたことがあるような。。。
　似てるだけですよね？

PCと違う処理系で今やってるんだけど思ったより速度が出ない・・・
当たり判定に矩形使ってるけど空間分割のほうがいいのか？

>>792
まずはプロファイリングして、どの処理が一番時間を食っているのかを分析してみたらいいと思う。
unix系ならgprofとか使えるんだけど。

>>742
凸多角形（積分）

>>743
当たり判定を考慮したキャラ形状なら影響ないけど
フリーダムな形をしたキャラなら違いが出てくると思う
今のオーバースペックPCの余剰処理能力の使い道はそこだと思ってる

矩形を複数使って誤魔化すほうが手軽だけど

>>763
PCの難しさは環境によって最速な手法が変わることだよね
INTELとAMD、VCとDelphi、ハードや開発環境が違うとアルゴリズムレベルの見直しが迫られる

>>764
複数の改善策を一度にやると、どれが改善でどれが改悪なのか判断がつかず、
トータルで改善なら良しとしてしまい無駄が見えなくなる

>>778
え、8分割以上必要なんですか？
それ以上の精度で高速化するならBresenhamアルゴリズムでよくないですか？

2Dで当たり判定に拘ると自機と敵弾の高さ判定はするのか?というジレンマが発生する。
3Dだと適当じゃないとプレイする側が正直やってられない。

3Dはどうしても視界から外れる部分が発生するから当たり判定を知覚させるのが難しい。
距離感も影つけるぐらいしかないし。

>>795-796
まーあたり判定を振った本人だけどさ、所詮は擬似なんだしある程度見栄えがよければいいと思うけどね。
あんまり細かく言い出すと30FPSと60FPSだと進む距離も違ってくる。

で、問題なのは昨今の素人って作ったこともないくせに評論家気取りが多くて
やたらリアリティやクオリティは求めるが、手間暇かけてもプレイしてやってるんだから
タダで当然みたいなのもいるしな・・・
別にシェアにするつもりなくてもさ、その態度はねーよとかさ・・・

>まーあたり判定を振った本人だけどさ、所詮は擬似なんだしある程度見栄えがよければいいと思うけどね。
>あんまり細かく言い出すと30FPSと60FPSだと進む距離も違ってくる。
ので当たり判定も結構変わってくるしね。

という一行がもれた。

>>797の続き

で、こういう評論家気取りがまた当たり判定とかうるさいんだわ。

>797
まあ、茶でも飲んで落ち着こうか。

つ旦

固定少数だの三角関数テーブルだのの負荷軽減効果なんて
100個以上のキャラを描画するだけで、みーんな台無し。
いまは計算部分は360FPSで行うのがトレンドなんだよ。

今の開発は書くことより読むことのが多いんだから、
人様が読んで理解しやすいソースを書くことを心がけろよ。

素人の俺には前半が理解できないのはさておいて、
前半と後半が必ずしも繋がらないと思うんだが

>>742
最強の当たり判定は「点」じゃないか？
２Ｄならプレイヤーの当たり判定を点にした方が安心して遊べる気がする

矩形と線分以外ほぼ要らん

当たり判定は全部円

それが俺のジャスティス

>>802
要するに、昔使われた高速化のためのテクニックというのは、
今のCore2Duoではなんの効果もないから、
いたずらに変なテクニックにこだわらないで、
素直な設計を心がけなさい、と言う意味だよ。

>>806
は？
CPUや環境で違うのでベンチマークとって最適な答えを選べだろ？
うそ教えるなよ

CPUや環境の違いで影響を与えるのは、
描画に関連するグラフィックカードの部分。
DirectX使うんなら尚更だな。
メインCPUは貧弱ならXPがロクに動かないからそれでわかる。

結局のところ、一番負荷が大きいのは描画部分で
メソッドを呼び出した先の方で重いんだからどうしようもない。

95が入ったマシンでも動くようにしたいんなら別だが・・・

XPの動作に耐えられる、500MHzオーバーのメインCPUにとっては、
１ミリ秒ってのは相当長い時間だぞ。
60FPSなら、16.66666666666ミリ秒で間に合えばいい。

描画が行われる前からそれが厳しい状況なんてのは、
明らかに設計やアルゴリズムの問題だから、
三角関数テーブルや固定少数とかで何とかなるような問題じゃない。

最新のCPU使ったって、セキュリティソフトとの併用とかで
同じ現象起こるよ。

ここってwindowsというか、PC前提だったっけ？

>>810
おれはその前提で書いてる。
X68000で作るってンならまた別だけど。

だってDSやプレステ３などのゲーム機で作る場合、
シューティング自体、売れないんだから作らんって
上司から言われてるんだろ？

>>810
いーや

ID:XAPPlmlMがwindows前提で言ってるだけ

非公式な開発環境とか含めてると今って下記以外に何があったっけ？

・ソニーゲーム系
・NDS
・携帯アプリ
・windows系

まあ、開発環境自体は、もっとイロイロあるにはあるんだけどね。

MacとJavaの組み合わせもアリだし、LinuxでX使うのもアリだし、
ザウルスもプログラムが作れるらしいね。

少なくとも確実なのは、
ゲームのプログラムで最も処理が重いのが
描画であることがわからん時点で、
そいつは絶対プロ（業者）じゃない。

別の方面でやってた人間が
趣味レベルでゲームを作ろうと思い立った、フォースメーカーだろう。
彼等の環境を考えりゃ、当然Windowsしかないわな。

そもそも皆、三角関数を何に使ってるんだろう。
ループの奥で使いまくりな人と、それほど使わない人で分かれてるって感じだな。
俺は三角関数よりもsqrtの方を多用するんだけど。

そりゃ敵から弾飛ばすという基本的なところから開発環境によっては
画像の回転すら自前で実装しないと厳しいのとかいろいろ

三角関数は、ガルザカートを再現するためには必須とも言える。
ゼビウスの時代は、確かに三角関数テーブルが必須で、
でも、せいぜい16方向分ぐらいしかなかったようだ。

正確に狙いをつける場合は、ピタゴラスの定理を使ったsqrtだろうけど、
３方向弾とかで三角関数が使えるかな。

ガルザカートと言うのは、全方向に丸い状態で球が飛んでいく処理のことだよ。
花火みたいなもんだ。

ちなみに、三角関数テーブル自体は、今でもよく使うよ。
高速化という目的よりも、敵の攻撃処理などを簡単にするためにね。

過去の俺のソース見てたら、
狙い撃ちするためにatanで敵との角度測ってから、
sin, cosで発射する弾のx, y方向の速度決めてたww

>>817
きっとそれは画像を回転させてくれるなというお告げじゃね。
グラフィック部隊に回転アニメーション描かせようぜ。

>>818
3-way, 16-wayくらいなら、sin, cosの値をハードコーディングできそうだけど、
それをやると仕様変更に弱くなりそうだ。

>>820
>グラフィック部隊に回転アニメーション描かせようぜ。
いや、320x240のスクリーンで使うようなドット絵ならまだしも
640x480を超えるスクリーンなんかを想定するとさすがに
全部ドット絵ってのはきついな。

それにソフト書いてる方としてはこれはちょっと手は抜きたくないよな。
どうしてもハード上の制約云々で仕方ない部分は絵を増やしてもらうが、可読性を維持したまま
チューニングでカバーできる部分はソフト屋でやるべき。

>3-way, 16-wayくらいなら、sin, cosの値をハードコーディングできそうだけど、
>それをやると仕様変更に弱くなりそうだ。
そうそう。
適度な落としどころを探してある程度汎用性も持ってないとね。

三角関数のテーブル化は仕様変更に弱いのは確かだな。
方向を元にXとYの移動量を抽出する関数で、その都度計算するやり方でも、
今のCore2Duoなら十分だろう。

方向に少数を使えるようにして、時計と同じ12とか60とかを基準にすれば
素人でもわかりやすいかもしれないねぇ。

ガンダムみたいに「７時の方向に弾を飛ばす」とかいう表現になるわけだ。

誰も言わないんだな。
しょうがない。
俺が言っておくか。









恋の三角関係ならお手の物だぜ。

>>822
ツクールとか作るなら「○時の方向に撃て！」っていうコマンドがあってもいいな。
ちなみに俺は方向はX、Yの移動量(dx, dy)で管理してる。

確かに画像処理が一番のネックであると思う。
背景画像を二枚重ねてスクロールさせただけでも、
俺のPenIIじゃあ、320x200, 32bit, 30fps(その他オブジェクト20個)を維持することが難しい。

それでもロジック的な限界は感じないんだけどな。
(色数が多すぎるって？気にするな。)

>>823
がんばれよ。

>>820
＞狙い撃ちするためにatanで敵との角度測ってから、
＞sin, cosで発射する弾のx, y方向の速度決めてたww

え？バリバリそうやってるんだけど
これ以外に方法あるの？

ペン２だと320x200でも厳しいんだねぇ。
60FPSを目指すなら、スレッドとSleepコマンドが必須。
タイマーイベントなど使い物にならんから注意。

それを見越してなのか、Javaや.NETでは、ミリ秒単位のSleepメソッドが
スレッド関連のクラス内にあるんだよね。

>>825
自分の位置(x1, y1)、相手の位置(x2, y2)があったとき
相手に速度speedで突撃するためのx, y方向の速度(dx, dy)は以下の式で求めております。
dx = (x2 - x1) / sqrt ( (x2 - x1)^2 + (y2 - y1)^2 ) * speed
dy = (y2 - y1) / sqrt ( (x2 - x1)^2 + (y2 - y1)^2 ) * speed

sqrtの所は一回計算してキャッシュしたのを使いまわすけど。
間違ってたら教えてちょ。

>>826
あくまでもLinux/SDLの話だけどね。OpenGLとかは使ってないよ。
もっと良い方法があるかもしれないな。

>>827
これはうちで使ってるやつ

敵が自機に向けて弾打ち出し用だけどさ

float Rag = atan2((Sy - y,Sx - x);

この後
x方向のベクトル x cos(Rag)
y方向のベクトル x sin(Rag)

俺も>>828と同じ方法
ただし、角度は36000分割の整数値でテーブル使用

で、実際のところこの自機狙いの弾撃つ部分はテーブルを使ってない。
なぜかというとたとえば弾幕ゲーにしても自機狙いの弾なんて瞬間で見ると
高々数百オーダーの話。

しかも自機狙いの弾っていうのは画面から消えやすいし、処理負荷がかかるのは
打ち出すまで。

むしろテーブル化で効率化しないいけないのが東方のような移動が遅くて
画面に滞留する時間の長い時間経過であれこれ変化するような弾

分割数が36000にも及ぶと、今度は消費メモリの問題が出てくるから、
その場合、テーブルにはしない方がいいような気が・・・

しかも整数で行うと、ビットシフトなどの処理も必要になるから、
そういうのが時代遅れと言われて以下略。

実際のところ、sin,cosよりsqrtの方が処理重いよな
それと近似値でいいならmath.hのは使わないでライブラリ探すか自作したほうがいいよ
うまくやれば100倍くらい早くなる

>>825
俺もそうやってるからそれがネックなのかね？

テーブル使ってみようかな

unsigned charで256分割なんだけど、精度悪いかな？

>>834
それ以前にわざわざ１バイトに収めるって8bitCPUなのか？
CPUによっては1バイトは扱いにくくて速度落ちるのとかあるぜ。

それにマイコンとかでなければそこまで削減する必要はないだろ。
せめて2バイトとか4バイトで・・・256分割でもそれほどメモリ食わないだろ。

おれの場合、三角関数テーブルを使うのは
ワザと精度を荒くするのが目的だな。
せいぜい３２方向分程度に抑える。

弾幕だらけのシューティングには、
隙間（安全地帯）を設けるのがセオリーってもんさ。

atanで求めた角度をそのままsin,cosに渡すのは、結構恥ずかしい処理だよ。
この辺の処理はベクトルの知識があれば、三角関数は滅多に必要ない。

ただnWay弾なんかは一度角度を求めてからの方が素直に実装できるから、
ケースバイケースだが。
特に綺麗なnWayではなく乱数で散らす感じのは、角度ベースでないと厳しい。

>>837
知ってる。
10倍してテーブル化すれば64分割としてそのまま使えたりするけどね。

昔のシューティングには、45度の角度のみ攻撃可能で、
撃つ前にチョロチョロ走り回る敵とかいたねぇ。

>>837
別に恥ずかしくはないだろ。1wayを後からn wayに変えることだってあるし、
そもそも敵弾発射なんてフレームあたり何回の処理だ。
富豪厨としては、角度を求めてしまうのが直感的で正しいと主張する。

考えてみりゃ、シューティングってのは
仕様変更がアホほど多いんだな。

>>840が言うようにいつでもnWayに変わることなどを
想定の範囲内に入れる必要があるわけか。

ソノヘンの難易度調整が不十分だと、
コナミみたいになっちゃうわけだ。

そういえば、敵の挙動とかってやっぱり行動パターンを作って
それをソース内部に組み込んだりしてるのか？

東方風弾幕っていうスクリプトや、ラノベエンジンのように外部にデータを置いて
本体をいじらなくてもできるようにしてるとか？

>>832
うひひひひ。
ベンチマーク作ったぜ。

#include <stdio.h>
#include <math.h>
#include <time.h>
int main()
{
    int i, LOOP = 1 << 28;
    timespec start, stop;
    double time;
    printf("LOOP is %d.\n", LOOP);
    clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &start);
    for ( i = 0; i < LOOP; i++ ) {
        sqrt(100); /* ここに計測したい関数をおく */
    }
    clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &stop);
    time = stop.tv_sec+stop.tv_nsec/pow(10,9) - start.tv_sec+start.tv_nsec/pow(10,9);
    printf("%f\n", time);
}

ループ回数268435456
結果[秒]：
3.296000 sqrt(100)
3.632000 sin(100)
3.764000 cos(100)
3.852000 atan(100)

ベンチとったのは良いけど、裏で動いてるタスクのせいで値が安定しないw

ループ回数を増やしてみた。

LOOP is 1073741824.
13.080000 sqrt(100)
12.308000 sin(100)
12.640000 con(100)
12.928000 atan(100)

だあああああ、
sqrtが三角関数よりも遅くなったぁぁぁぁぁぁ

>>842
俺はザコ敵の行動制御部分は一つの関数だけでやってる
速度とか角度のパラメータをいろいろ与えてやればどんな動きでもしてくれるから便利

>>844
それよりさ、問題のsin cosのテーブル化した場合もやってみてよ

テーブル化した場合、角度の指定が整数限定になるから、
角度の変数をdoubleからintにキャストする処理を
いれたほうがいいだろうね。

みんなちゃんと考えてるんだな。角度とか

#define tbl_size 36000
double sin_table[tbl_size];
double sin2(double pi)
{
    return ( sin_table[ llrint( pi / ( 2 * M_PI ) * tbl_size ) % tbl_size ] );
}

>>846
テーブル作ってみたけど、初めてだからか、何かおかしい。
１０倍くらい遅くなってる。
実装まちがえたかなー

LOOP is 8388608
0.116000 sqrt(100)
0.312000 sin(100)
0.504000 cos(100)
0.696000 atan(100)
3.984000 sin2(100) /* コレ */

double sin2(double pi)
{
  return (sin_table[100]);
}
こんな邪道をしてみた。

LOOP is 8388608.
0.120000 sqrt(100)
0.320000 sin(100)
0.520000 cos(100)
0.720000 atan(100)
1.188000 sin2(100) /* やっぱり遅い */

グローバル変数へのアクセスが遅いのだろうか。

>>849
double　なんていらんｗ
floatで十分。
しかも36000ってｗ

やはり、キャストの影響が出てる可能性が高い。

多分、関数の引数がintなら、大幅に速くなるんじゃないかと・・

#define tbl_size 36
float sin_table[tbl_size];

float sin2(int pi)
{
    return (sin_table[100]);
}

以上の様に変更してみた。

LOOP is 8388608.
0.120000 sqrt(100)
0.316000 sin(100)
0.508000 cos(100)
0.708000 atan(100)
1.048000 sin2(100) /* ちょっぴり速くなった？ */

ごめん、なんかベンチマークプログラムがバグってるっぽい。
最後にsqrt持ってきたら、sqrtが一番遅くなった(汗)

>>854
つーかプログラムが連続で動くからL1L2が汚れていく -> 最後のほうの処理は
L1->L2->(CPUによってはL3)->メモリの書き戻しをしてからのL1L2へ読み込み
とかしてるんからじゃねーの？
windowsマシンだよね

普通はatanで方向取ってsinとcosでx,y成分分解だろ
sqrtとかでやるほうがアホなやり方

>>855
Linuxとだけ言っておきましょ。

いろいろな不確定要素をごまかすために、
ループ数を増やして、二回ずつ計測してみた。
プログラムは>>853のまま。

LOOP is 1073741824.
13.136000 sqrt
13.468000 sin
14.560000 cos
13.624000 atan
33.208000 sin2
15.084000 sqrt
13.572000 sin
13.788000 cos
14.876000 atan
33.216000 sin2
単位は[秒]

>>857
じゃあさっきいってた並びを変えた場合の速度変化は？

>>856

なぜその方法が「普通」で、それ以外が「アホなやり方」なのかを
解説しないとただ自分のやり方以外をバカにしてるだけですよ。

俺はatanでやっててsqrtの方法ははじめて知りましたたが。

ちょっと試しに測ってみた
timeGetTime で 16777216回ループ　5回平均　単位 秒

sqrt 1.0574
sin 1.9146
cos 1.9788
table 0.1220 (グローバル変数・double型36000)

>>780
ありがとうございます！
パワーアップは気前が良い方がって人は案外多いみたいですね
自分は昔プレイしたダライアスがトラウマになってて、
パワーアップ状況と難易度が密接に関係するシステムに拒否感があったり
おかげで地味なパワーアップにしていましたが、
ちょっとトラウマ克服して、次の作品を作るときの参考にします
……とりあえずネタが出るまでは次リリースできそうにないですがｗ

>>791
中型機の攻撃パターンに関しては、もう一度見直してみます！
道中作成は本当に難しいぜ
ボス戦の音楽はsentiveでぐぐって一番上に出てくるサイトのslosっていうコンテンツの配布曲の一つで
2005年に配布してあるものの56番のmight flowという曲です
ギガウイングとは関係ない……はず

>>860
開発環境とかってどんなんだろ？

>>861
ドット絵の色の雰囲気とかも好きだしプレイしやすかったが・・・

しょっぱなのロードはどうにかしろｗ
マジでフリーズにしか見えん。

まー某ゲーム開発を解説してるところはゲーム素材をパックして・・
とかあるけどさ、まとめすぎｗ

>>858
すまん、わかんね。

gccのバージョンは4.1.0
最適化オプション(-O3)つけたら、ループ回数1073741824で、全部0.016秒になっちゃった。
もうね、わけがわかりません。

いいベンチマークの取り方誰か教えてー

>>862
VC++ ですな

Seleneっていうライブラリが65536分割テーブルを使ったSin関数を
搭載しているので、速度評価してみた
計算回数1億回、関数を呼ばないループオンリーの時間を引いて、

C++標準sin　3.40秒
Seleneのsin　0.45秒
自前のsin 　　0.29秒（直接テーブル参照）

C++標準atan2　13.25秒
SeleneのATan2　2.85秒

計測順を逆にしたり数回計測したが、誤差は10%程度に収まった。
atan2は使う値によって速度がバラけるので参考程度に
環境はXP XP2,VC++9.0（最適化なし）,CPu AthX2 64 5200+

>>865
乙

補足：
sinのほうは0.03秒以内、
atan2のほうは0.1秒以内の誤差

あんまりゲームには関係ないけど、実験用のプログラムで対数(log)の関数を使ったときはさすがに参った。
あれはテーブル化しないとやってられん。テイラー展開の罠。

>>827-828
遅くなったけどありがとう
そんなので求まるんだね

多分誰も言ってないから一応。

C/C++に限った話かもしれないけど、
#pragma intrinsic
で、配列に変換表を作る効果はあまりなくなることもあるらしい。あるいはコンパイラのオプションで。
ゲーム開発のための数学・物理学入門 (ISBN-10: 4797329076 Wendy Stahler 著) に、
ほんのちょっとだけ、さらっと書いてある。

>>870
へえ、勉強になります。
MSDNにもそれっぽい記述があった。
gccはあまり気にしなくてもいいみたい。

C/C++でビルトイン関数を使えば最適化できるなんて知らんかった。

コンパイルオプションに -fno-builtin を加えて、ビルトイン機能を無効にしてみたところ、
テーブルを使ったsinが他より2,3倍速かったので報告しとく。
(sqrtの揺らぎがヒドスw)

LOOP is 16777216. /* ループ回数 */
sqrt(): 4.499229
sin(): 4.613313
cos(): 5.739126
atan(): 6.888427
sin_table(): 2.404845 /* テーブルを使ったsin */
sqrt(): 5.444190
(単位は秒)

>>861
音楽、ちがうなら安心です。
そして良いサイトですね。ありがとうございますm(__)m

三角関数あたりの計算はどれがいいかFA出さない方がよい。のかな・・・？

忘れてた。。
計算してくださった方々、ありがとう！

そして、コンパイラやオプションでここまで結果が変わるとは。。。

関数に渡す値しだいでは、コンパイラ時に関数を呼んで既に値を出しちゃったりするから
（もちろん、ゲーム内ではありえない挙動）
最適化ははずさないとダメだぜ

いや最適化された結果でベンチせんと実用で意味なかろ。
そういう最適化がなされないような検証コードをかかにゃならんというなら同意だが。

その通り。
ゲーム中に変わるパラメータは、最適化されないようにね。

つまり、関数に渡す値が変動すれば良いってこと？
こんなふうに。

for ( int i = 0; i < INT_MAX; i++ ) { hogehoge = sin(i); }

>>878
それ、最適化されて

hogehoge=sin(INT_MAX-1);

になる可能性ないか？

皆、オブジェクトの座標やHPなどのデータはどこに保持させている？
全体を管理しているクラス？
オブジェクトのスーパークラスとなっているクラス？
それとも各々のオブジェクトについての派生クラス？

>>879
double hogehoge;
int main( int argc, char* argv[] ) {
    srand( argc );
    for ( int i = 0; i < INT_MAX; i++ ) { hogehoge = sin( rand() ); }
}
外部入力に依存する変数で種を初期化した乱数なら、流石のコンパイラも最適化できまい。

>>880
OOP的な発想でいくなら、スーパークラスかな。
俺の場合はゲーム内のオブジェクトは
「衝突判定オブジェクト」
「毎フレームごとの行動オブジェクト」
「画面に画像を表示するオブジェクト」
「キー入力処理オブジェクト」の集合体なんで、スーパークラスなんてものが存在しないので、
とりあえず、衝突判定オブジェクトが座標とHP持ってる。

オブジェクト基底クラス（updateメソッド、drawメソッド、グラフィック等）
　→当たり判定ありオブジェクト（当たり判定、HP）
　　→プレイヤーオブジェクト

基底クラスを継承してエフェクトを、
当たり判定ありオブジェクトを継承して、敵、弾、アイテム作ってる

あぁぁぁリストについて色々考えてたら頭がおかしくなってきた。

皆、座標等のメンバ変数だけじゃなくて
描画や移動などのメソッドを持ったクラスごとリストにしてんの？
それだとメモリ食わない？

メソッドってメモリ食わないよ。クラスごとに共通だからね
基底クラスに仮想関数がある場合、インスタンス毎に4バイトだけ増えるけど
ていうか、メソッドがなくしたらOODじゃなくね？

>>883
オブジェクトごとにメソッドが生成されるとでも思ってるのか？
もう少しプログラミングの勉強を重ねてはいかがか。

動的にインスタンスのメソッドを書き換えることのできる言語なら
必要に応じてコードをコピーと言うのもありうる話かもしれないな。

メソッド内でif文で分岐しろｗ
それかメソッドへのポインタを切り替えるか、ストラテジーパターン適応するか

自分も基底クラスの役割と管理方法で最近煮詰まってきた。

いわゆるOOP的な発想の管理方法で自機や弾を管理してるのだが、かなり基底クラスが肥大化してる気がしてならない。
（座標、属性、食らい判定半径、画像ポインタ、体力、攻撃力などを各インスタンスが保持。メソッドもDraw、Moveなど5.6個ある。）

そこはいいんだけど、たとえば特定条件を満たした弾・機体の移動速度の変更や、座標のワープ、
と言った仕様を後から追加しようと思ったとき、あまりに仕様変更に対して融通が利かなくて困ってる。

何かいい基底クラスやその管理方法はないかな。>>881のとかかなり柔軟性が高そうなんだけど。

>>873
結局のところ、CPUとかOSとか、コンパイラとかで性能が変わって来るので、
対象とするマシンごとにベンチマークとった方がいいと思う。

数学関数ベンチマークの続き
- ループ内の変数(sinテーブル除く)はグローバルで、volatile宣言。
- 関数への引数にrand()による乱数使用。
- srand(argc)により、乱数初期化。(argcは、もちろん、mainの引数)
- 三角関数はコンパイラのビルトイン関数により高速化される(VCなら#pragma intrinsic(sin, cos, tan,,,
- テーブル参照型のsinについては人によって実装が違うので、あくまでも参考程度に。
- スペック： gcc4.1.0/Pentium II

arg1 + arg2: 0.018393, 0.017820, 0.017960, 0.017903, 0.018402,
arg1 - arg2: 0.018351, 0.017216, 0.017944, 0.016988, 0.017809,
arg1 * arg2: 0.018655, 0.018498, 0.017475, 0.017424, 0.017912,
arg1 / arg2: 0.312386, 0.312131, 0.311159, 0.312575, 0.311817, /* 四則演算の中で、割り算がべらぼうに遅い */
floor(rand()): 0.359771, 0.360056, 0.360613, 0.359535, 0.360410,
sqrt(rand()): 0.371734, 0.370627, 0.372083, 0.370517, 0.371231,

sin(rand()): 0.496849, 0.498673, 0.497215, 0.497070, 0.496469, /* ライブラリのsin */
sin_table(rand()): 0.275411, 0.273136, 0.273017, 0.275622, 0.272431, /* テーブル参照型sin */

cos(rand()): 0.492284, 0.491513, 0.491417, 0.490797, 0.490769,
tan(rand()): 0.618618, 0.619241, 0.616512, 0.618693, 0.618386,
atan(rand()): 0.580075, 0.580360, 0.578727, 0.580545, 0.580344,
asin(rand()): 1.032839, 1.031955, 1.032328, 1.032158, 1.033706,
acos(rand()): 0.977117, 0.976528, 0.977257, 0.977658, 0.977407,

単位は秒。
ループ回数は1,048,576回。
五回ずつ計測。

>>888
仕様変更に対して融通が利かないのはOOPの思想とは反するよね。
（Open-Closed-Principleなんて考え方もあるし）

スーパークラスに置いておくのは最低限のものだけにしておいて、（インターフェイスを最小化）
サブクラスに対して機能を追加・入れ替えできるようにするのもいいんじゃない？
ストラテジパターンとかコマンドパターンなんかを利用して。
要は>>881のやり方になるね。

うちの場合、基底クラスのが持つのは
・位置
・死亡フラグ
・更新メソッド
・更新メソッドその2
・描画メソッド

更新が2個？いったい何に使ってる？

staticなメンバ変数を使わないで組む方法が思いつかないんだが…
何かないかな？

>>893
エスパーするなら、

1. グローバル変数を使う
2. 必要なデータはクラスが構造体に入れて、そのポインタを配り回る
3. シングルトンパターン(インスタンス自体はstaticフィールドで管理されてるが、、、)

staticじゃないメンバ変数なんてあるの？

>>894
即レスthx。

1は変数のスコープを狭めたいのであまりなぁ。
2か3あたりがいいんだろうけど、実際static使って作るのとどっちがいいんだろ？

基本のクラスからその先の細かいクラスを宣言していって
最初に基本のクラスをnewするんじゃないのか？

キーボードやマウスの個数が変化するかもとか
ゲーム世界はひとつのはずが
気が変わって並行世界も加えることになるかもとか
自機は一機のはずが見えないスタンドが重なるかもとか
そういう「かも」が絶対ないと仕様で決めたものは
何の躊躇もなく静的領域に変数作ってるよ

俺は主に定数の定義や同一クラス内で共有したいデータにstaticを使うな。

>>892
あ、更新その2は基底クラスじゃなくて、コリジョンクラスのメソッドだった
二機編制の敵機とかで、相棒に死亡したとき編制を返るために使う
衝突メソッドで死亡フラグ立てて、更新2メソッドで関連する敵の死亡フラグをチェックする
多関節芋虫型の敵が途中で分離したり

constでないstatic変数なんて使うなよアホか
あんなものはリエントラントの概念すら無かった過去の遺物だ

>>893
staticなメンバ変数を何に使っているのか書けば、もっと適切な
アドバイスが得られるかと。

>>902
staticなメンバ変数は、オブジェクトのリストに使っている。
そして各オブジェクトの派生クラスがそのリストを持っているクラスのインスタンスのポインタを作成して使っているという仕組み。

弾とかアイテムとかの管理をlistで実装したんだけど
1フレームに5000〜6000回程度push_backする必要があるせいかかなり重くなってしまった
これに早送りとか導入すると普通に処理落ちしてしまう
listってこんなに重いものなの？