1 :
名前は開発中のものです。:
ゲームプログラマなら誰もが通る、もしくは、通った道。青春の香り?
それは「シューティングゲーム製作」・・・。
このスレでは、そんなシューティングゲームの製作技術や技術の検証、成功談
失敗談笑い話、難易度の設定方法論、多弾の是非などについて語り合いましょう。
もちろんBulletMLなどで弾幕を作成してみたり、自分の作ったシューティングを
晒してみたり、プロジェクトをはじめてみるなどもOK!
ただし、シューティングの未来とか既存のゲームの話題などは、関連する他の
スレでやってくれ。
過去スレ,関連スレは
>>2で。
2 :
名前は開発中のものです。:2006/06/04(日) 21:04:34 ID:XO9D1QcD
PO!
Wikiが放置されてんな。
可哀想だからスレのリンクだけ更新しといたぞ。
>>前1000
8年前にはあったのか・・・
昨今のWiFiブームに便乗すればもう一花開かせられそうなんだけど
まあ無理なんだろうかねw
2Dシューティングの対戦は今まで成功例が少ない。
ティンクルスタースプライツは上手くいってる。
東方の前のもその形式あったよな。
対面だと成功例はないに等しい。
閃光の輪舞は成功例と言っていいのか('A`)
東方の対戦ゲーもシリーズの中じゃ評価は今一つみたいだし
ティンクルスタースプライツも(2DSTGとしては)そこそこヒットしたとは言え
結局当時の対戦型ゲームに比べると盛り上がりに欠けてた感は否めないし。
やっぱり根本的にシステムにマッチしてないんじゃないだろか。
3DだとFPSなんて海外じゃあ正に王道・花形ジャンルだし日本でも
星狐やらACやら対戦のあるSTGは有るんだけどな・・・
ティンクルはキャラで売れただけ
否定はしない。
ところでおまいら、参考までに聞きたいんだが、
コンパイラとライブラリ、何使ってる?
HSP
Visual Studio C++ 2005
SDL
OpenGL
Lua
最近VisualStudioの無償版に乗り換えた。
2Dオンリーだと未だBCC&DXlib使ってるが。
せっかく無償になったついでにC#.netも弄くって遊んでるんだが
やっぱり.net Framework環境下じゃないといけないのは痛い。
MSもさっさとネイティブ吐くようにしてくれたら良いのに。
1.1ならFramework無い環境のがめずらしいけどね
Delphi6Per+QuadrupleD
Python+Pygame
VC++&DXライブラリが最強
面倒くさいからもうそれでいいよ。
FLASH ActionScript
22 :
名前は開発中のものです。:2006/06/05(月) 18:09:18 ID:wEs4Px8x
HSP
>>12 C++
boost
Lua
自分用lib
25 :
名前は開発中のものです。:2006/06/06(火) 19:20:42 ID:d3KomKMZ
boostってソースみたらソースコードがぐちゃぐちゃっぽくて
ゲームに使ったら遅そうだから使ってない
やっぱライブラリは自作じゃなきゃなw
boostはMSVCに組み込む時点で既に挫折した
サイトのとおりにやってもコンパイル通らないってどうなってんだorz
今はJavaに浮気中。・・・いやもう本命かも。
VC++
Lunaライブラリ
SDL
だな。
>>27 上のサイトだね。使ってたのは6.0アカデミックだった。
VC Expでまた試してみようかなぁ
>>12 Delphi2006 + DirectX
boost::spiritのぐちゃぐちゃは芸術的なぐちゃぐちゃ
>32
boost::MPLも前衛的にぐちゃぐちゃ。
正直irrlichtってどうよ。
海外モノを使うならもっと優れたライブラリが沢山あるからなんとも言えないなあ。
ただ見た感じ導入が楽なライブラリっぽいので、
そういうライブラリに手を出し始める最初の段階としては良さそう
36 :
名前は開発中のものです。:2006/06/10(土) 14:39:52 ID:NQRW26dW
とまってるのであご
C++なんか使うとロクな事にならないという好例だな。と煽ってみるか。
ざっと議論を流し読みしてみたが、
STLのdefault allocator自体がいきなりnew/deleteしたりせずに
自前でプール作ってる実装が多いのは考慮に入ってないんだな
俺はそれ見た瞬間、STL使ってる時に自前でプールとか断片化とか考慮するのは
実際に問題になってることが明らかなケースにあたるまで考えないと決めたのだが
画面に弾が最大500発出るとわかっていれば500発分の領域を確保しておけばいいんじゃないか?
いまどきのPCなら全てチェックしてもたいした負荷じゃないだろう
C++使ってるけど、クラスと継承くらいしか使ってないや
俺プログラマじゃないし
ほのかに40に同意…
俺は継承すら使ってない
STL?、何それ、喰えんの?
C++を「なんかしらんけどCに毛が生えたもの」という認識で使うのはどうかと思わないでもない
関数をクラス化できるだけでもC++を使う価値はあるぜ?
要は使う人間が楽できりゃいいんだよ。習うより慣れろってな感じ
使っているうちに、継承やら演算子の定義とかわかってきて
おーいいじゃんこれ、みたいな
自分ひとりで使う分には好きなように使えばいいんじゃないかな
オレはSTL使ったほうが楽だから使うが、
全部固定配列に入れるほうが楽だと思うならそっちを使えばいいと思う
シューティングぐらいどっちでも作れるだろうし
つーか、ゲーム作るうえでは、細かい実装の違いなど
対して意味のあるものではないように思う。
ゲームの内容を充実させようぜ。
>>49に同意なんだけれど
それだとコーディングネタが終わってしまうから少し引っ張るか
どっかの有名人が言ってたと思うんだけれど
コーディングレベルで最適化してもたいして速くはならなくて、
アルゴリズムレベルで効率化すると効果が高いという話。
っつーわけで最適化するならアルゴリズムレベルで改善できる場所に力を入れるべきだね。
例えば2Dゲーで衝突判定を総当りでやってたら四分木を導入するとかさ
> 例えば2Dゲーで衝突判定を総当りでやってたら四分木を導入するとかさ
遅くなってからな
めんどくさいから速いPCにする
それより俺は弾幕のネタ切れて困ってるんだが
そういう時みんなどうしてる?
そんなときは弾幕やめて高速弾を織り交ぜる
どっかのゲームの神プレイムービーでも見る
自分で考える
58 :
名前は開発中のものです。:2006/06/12(月) 10:34:39 ID:kDf7AUL6
寝てしまえ
シューティングを作り始めたんだけどリプレイ機能って必須?
ついてるゲームは多いんだけど使ったことないんだよねぇ
自分がイランと思ったらイランだろ。
大抵リプレイなんて自己満足のための機能さ
上手い人がリプレイうpしてくれたりすると
すげー嬉しいから俺はおすすめしとく
デバッグに便利。
リプレイを記録するのにとりあえず全フレーム連番ビットマップ出力することにした
結構重い
えと、それはつまり、毎フレームごとにスクショ取ってるってことか?
釣り?
60fpsのゲームを640*480の24bppのbmpで保存するとして、
1秒あたり55296000Byte≒52.73MB
1ゲーム5分とすると、15.45GB
>>64 保存はJPGかPNG使おうぜ
>64
たいていはキー入力のログだけど。
使いやすいクラスだれかUPしてくれないかな。
バッファがいっぱいになったとき確保し直しとか面倒。
みんなどうしてるんだろう。
>>66 早いマシンじゃないと圧縮が間に合わないぞ
まあでもムービー出力する機能も、マシン性能が無駄に必要とはいえ、
あればあったで微妙に便利かも。
それリアルタイムに生成する必要なくね?
リアルタイムに生成とは?
動画を撮るのって、
1)プログラムでキャプチャしまくり
2)出力端子を録画機器に繋げて録画
3)モニターを光学的に撮影
ぐらいじゃないの。
で、1)の機能を内蔵するのも、ありなしで言えばありかもしれない。
あ、もしかして、リプレイファイルを元に内部でムービーを出力するって事か?
確かにそれだとマシン性能も要らないし、結構便利かも。
うちFraps入れてあるから
弾幕姉妹のALL動画とったことあるんだけど
生データで録画したらえらいことになった
1プレイの動画サイズ>100GB
でした
mpegにしないと。
俺は面倒くさがり屋だから
長時間録画するときは普通にS端子経由で
家電(HD/DVDレコーダー)に渡してるよ。
楽でいい。
変数やアルゴリズムにfloat使ってる?
リプレイに誤差でそうな気がするんだよな
まだ調査はしてないが整数か固定小数の方が安心かな?
>>77 リプレイに誤差の意味がよく分からない=B
同じ変数使ってる限りは同じ結果だと思うが
俺小数嫌いだから座標は整数型に64倍して入れてる
俺1000倍
float(=32bit)なら関係無いかもしれんが、
fp64モードとfp80モードの違いで誤差が出ることはあるぞ
>>78 CPUによって浮動少数演算の結果に誤差が生じる場合がある。
IEEE754モードにちゃんと従ってるCPU同士なら誤差が出ないことになっている
…一部バグ有りのCPUとかでずれることはあるが
そりゃ困るね
CPUの演算精度によってはスレッド切り替えのタイミングで保持される
浮動小数点レジスタの値と、計算途中の値で誤差でちゃったりしない?
適当な事いってるけどスマン
必要スペックにCPUも書いておけw
「推奨しないCPU」の方がよかろう
昔、富士通のFMVで付属のランチャーから立ち上げると、リプレイがずれるというバグ報告をもらったことがある。
多分、浮動小数点のモードがらみ。
それ以来、毎フレーム、浮動少数のモードリセットを仕込んでる
俺も自分で作った別のアプリ同士で計算結果が違ってたことがあった。
片方DirectX使ってたからモードが変わってたんだろうか・・・。
固定小数点かなんかで代替しろ、としかいいようがない
ムービーでリプレイ残せばいいんじゃね?
>>90 数学関数使うとそうもいかないこともある。
いまさらテーブル持つもの嫌だしw
>93
それは単なる我が儘だろ
サインテーブルはどれくらいの精度で持つのがいいの?
short×360個とかで間に合うのもの?
>95
君が必要とする程度の精度
俺はint×360だ。
てかintとboolean以外使ったことない・・・
ええと・・・いつの時代の人ですか?
( ・∀・)<型なんて使ったことないよ!
最近は型無しのスクリプト言語でも
実用になりそうなぐらいのスピードになってきたってことだな
まあFlashでもSTG作れるからね
弾幕は無理だろうけど
Flashはさすがに重いよな
>>101 最近は型とか無視して
文字列やら浮動少数やらポインタやらまぜこぜにして突っ込んでも
平気で動いたりするから逆にワクワクしてきて困る
だからこそ精度が気になる
浮動小数点をどこで丸めてるとか
整数と浮動小数の区別がないならなおさら
整数のゼロと浮動小数でのほぼゼロは、表現的には似てるが
判定ルーチンにとって大きな違いだからな
アーケードシューティングの大半はFPUすらないCPUで動いている
そんな細けえとこ気にしてないでコンテンツとしてのレベルを高めるべき
同意だな。
どうせおまいらが作ったゲームじゃ
凄いことしすぎてCPU100%使い切ってしまって
重くて仕方が無いなんてことないだろ?
俺もだけど。
HSPとかだときついのかな。スクリプト言語は使ったことないから分からん
HSPはまともに構造化できなくて挫折した。今はDelphi使ってる
HSPでも速度的には問題はないっぽ
HSP製のゲームとか試しても、かなり弾出ても問題なく動く
まあようは適材適所だな。これを言うと話が終わるが。
flashとjavaどっちが早いかな?
fps20くらいでブラウザシューティング作ろうと思うのだが
javaに決まってるだろ
>どっちが早いかな
評価版があるんだから自分の目で確かめろよ
Flashのが生産性が高いし、多くの人が遊べる
Flashのほうが早く作れるということで、Flashの勝ちで依存は無いね?
勝ち負けでしか考えられない低脳が来た
俺の圧勝のようだな。これだからjava厨はダメなんだ
そう。よかったね。
ぷぷぷ、「javaに決まってるだろ」とか勝ち誇ってた
>>112のぐぅの根も出ない現状に泣けるw
実行速度が速いのはjavaに決まってるけど。
驚きと戸惑いと感動と畏怖と尊敬の念のあまり言い訳に走ってるね。
君も次があるだろうし、この挫折を糧に成長していけばいいさw
まあJavaもFlashもうんこだけどね
言語なんて何でもいいからまともなの作れよw
>>121 で、実行速度が速いのはjavaだろ?
それに対して
>>114のような言い訳をしたのはお前だろ?
111までの流れで、実行速度が速いかどうかを聞かれていることも読み取れない低脳ぶり、
ホント驚きと戸惑いを隠せないよ。
111から始まって114で完結した流れでしょw
剥きになるその青臭さに青春を感じるな
言語論争の時だけ盛り上がるなこのスレ。
いつも皆どこに隠れてるんだ。
ネタかと思ったら本当に読み取れてないのか。バカだなぁ。
てか、なんで噛み付いてきたんだ?
javaとflash比べたら、javaの方が処理はやいのは常識だろうに。
そんなことも認めたくないほどのflash盲目厨なのか?
いや、flashでシューティング作ってるヤツなんか少数だしなぁ。
単なる、javaが嫌いな'アンチjava'厨ってところか。
いつまでねちねちしてんの?
111が早いって聞いてるからFlashでいいよねって話だろ
噛み付くとか寒いレスいらないからw
グダグダしてないで、
JavaSTGとFlashSTGで競作すればいぃ〜じゃない?
>>130 ああ、完全に文意を読み取れないアホでしたか。
あの文面で、開発速度を聞いてると思ってんのか。バカすぎですね。
>いつまでねちねちしてんの?
とか言ったんだから、もうレスすんなよw
これ以上やると、笑いが止まんなくなるからw
じゃあR18君にはレスしないから透明あぼーんでもしといて。
もう噛み付いてくんなよ。
いや噛み付いてるのは君だから
あぼーんしないの?w
ほら、来たw
明らかにお前だろw
自分でネチネチするなとか言った癖にw
>いつまでねちねちしてんの?
とか言った自分があぼーんしろよバーカ。
二人とも透明あぼーんしたお^^
111へのレスに何故彼が絡んできたのかちょい疑問だが
面倒なのでこの辺にしとこうか
ぷぷぷ、「Flashの勝ちで依存は無いね?」とか勝ち誇ってた ID:msfIS4LLのぐぅの根も出ない現状に泣けるw
>>138 明らかにお前が先に絡んでるから。
119 名前:名前は開発中のものです。[sage] 投稿日:2006/06/17(土) 12:21:30 ID:msfIS4LL
ぷぷぷ、「javaに決まってるだろ」とか勝ち誇ってた
>>112のぐぅの根も出ない現状に泣けるw
ご自分の115は無視ですか、ご都合主義ですねぇ
アホレスに突っ込むのは「絡む」と違う。
てかそうかw
115のレスでカーっと頭に来たわけかw
この単細胞がw
食事から戻ってきたら喧嘩してるし(;´Д`)
ID:hTCHGRYjの物凄い自爆がSTGスレらしい
そんなだからバグだらけなんだろうな
147 :
名前は開発中のものです。:2006/06/17(土) 14:27:49 ID:u7en60a+
どうみても114の書き込みが諸悪の根源なんだが。
釣り目的で、早いを意図的に誤読したのか
本気で間違えたのかは知らんが。
勝ちとか言われただけでこんなに反応してるのも如何な物か。
正直な話fpsは後から指定すればいいと思う
12fpsなら83ミリ秒、24fpsなら42ミリ秒、30fpsなら33ミリ秒のタイムリミットがある
Webで公開するならどのスペックの42ミリ秒なら
どの程度クオリティを出せるかから入ったほうがいいと思うよ
> 42ミリ秒ならどの程度クオリティを出せるか
お前さんの言い分だと、先にFPSを決めているように読めるんだが…
ああ、そう読めちゃうね
12fps、24fpsってのは、Webアニメでクオリティを示す基準だから
その間ならどこに収まっても気にしなくて良いよと言いたかった
確かにいきなりベンチマークから始まってると読めるなぁw
先ほどのフラッシュ厨はフラッシュ使ったことない。俺にはわかる。
やつはJAVA使いだ。暇なんで釣るつもりが熱中してしまったんだろう。
ミイラ取りがミイラというやつだな。
ねちねち邪魔
なんで言語の話になると盛り上がるンだここはw
そもそも Flash は言語じゃないわけだが
FLASH、JAVAどっちにしてもシューティングだともっさりするから嫌だな
いいゲームほど普通に作ればいいのに勿体無いと思ってしまう
Flashは当たり判定の精度がいいから乱用するとすぐ限界
矩形を使わず直接MovieClip(スプライト)の当たり判定を使いがち
Javaがもっさりするのは何でだろう?
身の丈に合わない量のスプライトを使ってるのかな?
JAVAとFLASHてジョイスティック使えるの?
C++でDirectX直叩きが最強なのはもうわかったからいいよ。そういうことでいいよなみんな?
後はC派対C++派でム板でもマ板でもいいから存分にやれ。
.NETで作れますか?
Google Map APIでも作れるよ
ABA氏辺りがネタで作ろうとして投げてなかったけ?
164 :
名前は開発中のものです。:2006/06/17(土) 17:40:59 ID:tOjBGZ2t
MapAPIでもやった、JavaでもやったしFlashでも弾幕シミュレータではあるがやった。
おまいら仲良くしろや。
わるいわるい。収まってたところに火をつけちゃって。
このとーり。
流れが存在を忘れ去った頃に出てくるこの性質の悪さ…
「俺はこんなにカコイイ言語や開発環境で作ってるぜ」ってのはもういいから、Google Map API みたいに
「俺はこんな変な言語や開発環境で作ったことあるぜ」自慢を要求する。
俺は変な顔だぜ
ぶっちゃけなにで作ったか、なんてどうでもいい。
他人がどんな言語で作ってるのか知って、俺にとって何の役に立つって言うんだ?
もっとアルゴリズム寄りの話してた頃に戻りたい…
じゃあアルゴリズム戦士はちゃめちゃ大進撃の話しろよ
製作技術まとめでもまとめますか
Wikiには当たり判定のコラムしかないから
ホーミングレーザーの作り方とか載せてくれ
よっしゃ
ホーミングミサイルをビームにすればよい
綺麗なホーミングオブジェクトの作り方と訳せばよい
心地よい追尾性能、綺麗な軌跡とlook&feelの芸術性が求められる
レーザーを重力で曲げるんじゃないのか
しらんけど
>177
うっかりすると周回軌道に乗らんか。
何気に一番難しいのは
>綺麗な軌跡とlook&feelの芸術性
ではなかろうか。
例えば壁に削られながらもある程度強引に追尾するミサイルとか
たまに周回軌道に入ってしまう無機質なビームとか
癖の作り方というのは面白いトピックになるかもな
そういえば、ギャラクシーなんとかはどうなったんだ?w
はてなんの話だったかのう
なにそれ?
そういや雷電IIのリーマンレーザーの実装で盛り上がったのって初代スレだっけ?
基板のCPUはV30、勿論FPU無し。float演算に頼らず実装するのが漢道。
まぁ今の実行環境考えると固定小数による高速化メリットの恩恵ってのはあまり無いんだが、
昔の人はFPU無しの低速CPUで実装してたものを、俺らは比較にならんほど高速なCPUでやっとこさ
実装してるってのはなんとなく先人に対して負けかなと感じてしまう。
技術的分野に関して差が付くのは仕方ないよ。
どうしてもその分野で張り合いたいのなら、最先端技術を取り入れていかないと。
今で言えば3D技術とかになるんだろうけど。
あれ、雷電IIってもうi386の基板になってたんじゃなかったっけ?
>>186 初代がV30(10MHz)2個
IIとDXがV30(16MHz)
ViperPhase1やファイターズからi386(25MHz)
らしいよ。
いずれもFPUは無い。
>>184 今の時代にそんな意味不明な拘りしてる時点で、
過去現在未来全ての人に負けてると思う
外見でちゃんとうごいてりゃ技術なんかどうでもいいんですよv
制限の大きい環境での実装から学べる技術は今なお多いけどな
まぁ向上心も無くつまらん煽り入れてる奴が一番の負け組みって事で
ある部分で手抜きができればそこに余裕ができ、他の要素に力が回せる
1フレームにどれだけ詰め込むか考えた事あるなら判りそうなもんだが
16.6ミリ秒の世界は手を出したくないなぁ
リソース管理すると一番きついのがFPSだと思う
処理時間効率と開発時間効率は相反することが多いってのを肝に銘じておくべきだな
結局どこにリソースを裂くのか、ってことだけだと思うよ
>処理時間効率と開発時間効率は相反することが多いってのを肝に銘じておくべきだな
('-`)このスレで言う事かな…?
皆趣味でやってるはずだよね。
どうでもいいところに労力割いてブツがいつまでたってもできあがらないのは趣味でやってても問題だろ。
俺のことだな
いや俺のことだ
お前らじゃ相手にならん、俺のことだよ
まずはライブラリから作ろうと考え、途中で最初から直接作ったほうがと迷い
無駄なことをしたと実装に掛かるや、やっぱライブラリから作ったほうが…とエンドレスワルツ
完成品?劣化インベーダーくらいだなw
そこは完成するまで我慢だな
俺は毎回ライブラリ作り直してるしw
一つ作る→このライブラリはもっと上手く作れる!→
→次回作→ライブラリ作り直し→完成→このライブラリはもっと上手く作れる!→
→そのまた次回作→以下略
使い回し?再利用?何それ?
ライブラリなんかよりオブジャクトの管理方法やら
データ構造から入るとうまくいきそうな気がする。
前回作ったライブラリを参考にしながら作るから全くの無駄ではない、と思いたいorz
>>199 次回作に移れるだけまだマシw
一つも作品が出来上がらずにライブラリばっか修正してるようなのもいるからな
よーし、リソース管理API(4クラス構成)のうちの1クラスを2日掛けて作ったぞorz
>>197 もうあきらめてNスクでノベルゲーでも作ってろ
今日TDDの本読んだけど
コレ趣味でも適用できるかな?>いつまでたっても出来上がらない
それより設計しなおさない勇気みたいなものが欲しい
俺がはじめからシューティング作ろうとすると
初めの方の面は張り切って作って難易度が高くなる。
魅せる弾幕も多い
↓
面が進むにつれて難易度がもっとあがる
↓
ネタが切れる
↓
敵のHPが上がっていくだけのクソゲーに
はじめはデザエモンでどうぞ
すぐにツクールとか言い出す馬鹿がいるな。
むしろ俺はツクールを作ってるんだけどね。
順番としては間違ってないっしょ。
ツクールあたりで動作方法を覚えるってのは至極真っ当な方法じゃね?
ツクール否定する人は一体何から始めて欲しいんだ?
というかできあがったブツが良ければ開発言語や環境は関係ないだろ。
ツクールあたりで動作方法を覚えるって意味不明だろ
おまえツクール触ったことないだろ
お前プログラムしたことないだろ
ゴメン、正直自分で書いておいてなんだけど、動作方法を覚えるは意味不明orz
何かを覚える時は制限のキツイものから覚えた方が迷わなくていいんじゃね?ってことを言いたかった…
>>213 おれも基本的にその意見には賛成だけど、「初心者が作る」「とにかく動くもの」って前提だとそうも言ってられないかな、と。
オブジャクトってかっこいいな
うん、あいつ強いよね
結果が同じなら言語とか技術なんてどうでもいいってば
ツクーラーは皆そう言うよね。そう言って、自分を慰める。
俺ツクールつかったこと無いけど…
ねちねちが戻ってきたのか?
食わず嫌いの自称食通が「フォアグラ以外は美食ではない。それがわからないような貴様にはアンキモ程度がお似合いだ」って吠えてるみたいだな。
で、至高のメニューは完成しましたか?
結果が同じじゃないからどうでも良くないんだよ
デザエモンはいいツールだな。
同じじゃないなら仕方がないな
つーかここプログラマーしかいないのか
他に来る可能性のある人っているのか?
スレタイ的に。
つーか派手さに凝らなきゃ一番簡単だからな
ゲームシステムなんて馬鹿の一つ覚えと切り捨てても問題ないし
ここできっちり育って他のジャンルに行けばいいよ
東方ってどういうコンパイラとライブラリ使って作ったのか、だれか知りませんか?
ライブラリは俺も気になるな。
本職だから自作しているんじゃないか、と聞いた事はあるけど。
235 :
名前は開発中のものです。:2006/06/20(火) 19:46:14 ID:I+u3SMpM
>232 VISUALSTUDIOと描いてあった(文花帖(本)にて
ライブラリは自作じゃない?
自分も東方に引かれ、同じようなシューティングを作りたくなった香具師なんだが、
一応、頑張ってC++の基本は大体理解したと自負できるくらいにはなったんだが、
その後、何をやっていいか、さっぱりわからない、、
(DXライブラリを使おうかと思ったが、東方のように3Dの背景はかけないようだからやめた
だれか、助言お願いできませんか?
>235
ゲームを重視するなら、DX使ってとりあえず表示できるようにしてゲーム部分に進む。
3D描画を重視するなら、3Dのライブラリを探すなり、DirectXを直に触るなり。
237 :
235:2006/06/20(火) 21:18:48 ID:I+u3SMpM
3D部分を重視したいので、
3Dのライブラリで、これだ!!
と言うのがないか探してみたが見つからない、、、(知識が足らない&敷居が高い
DirectXを直で触るとしたら、どのような知識が必要となるんでしょうか?
あと、DXライブラリを用いながら他の3D用のライブラリって使えるんでしょうか?
プレステのデザエモン買えってばよ
>DirectXを直で触るとしたら、どのような知識が必要となるんでしょうか?
・ライトの設定を無効orちゃんと設定しないと真っ黒。
・ポリゴンには向きが有り裏側からは見えない。
2DSTGのドット絵の代わりに使うぐらいなら、これっくらいじゃないかな(推測
3DSTGも同様。つかDirect3Dは表示に使う程度で、移動&諸判定は自力orz(経験則
東方に感化されたって人間が増えて、あのタイプが王道になっていくんかなあ。
俺は今だに突然変異STGにしか見えないがw。好きだけどね。
やっぱりサイボーグ化した魚とか蜂じゃないとなぁ
アンチってわけじゃないが、東方は総じて展開がダルいのであんなものに感化されて欲しくないな
プレイ途中で飽きるんだよあれ
ゲームなんて突然変異を繰り返して進化してきたようなもんだからねぇ
というかゲーム全体からみればSTGはすでに王道ではないし。
>243
まあ、道中の構成が適当だなぁとは思う
EXTRAはまあそうでもないが
246 :
237:2006/06/21(水) 00:04:06 ID:IcPsCunV
東方に限らず、最近のSTGに背景が3D使われているのが多いと言う事で、
3Dを使いたいだけなんだが、それを達成するための壁が大きいですな、、、、、
結局WindowsAPIは学んだ方が良いのかしら、、、、、?
(因みに他に感銘を受けたSTG(同人)は五月雨とスグリかな、
特に自分としては前者が結構好きなのに名声があまり高くない、、、、
今は2DSTGでも3D使うわけだが。
あとWindowsAPIはゲームそのものと直接関係ない部分(ファイル管理など)で使うから
少なくとも資料となるものは確保しておくべき。
とにかく237とは好みがまったく合わないのは判ったw
おー、五月雨ファン発見。俺もすきよ
ファイル管理とかは標準C/C++の範囲で充分。
知り合いがfopenつかてて萎えた
何故よ
253 :
名前は開発中のものです。:2006/06/21(水) 09:19:41 ID:GZ4mL36B
fopenは普通に使うだろ!!
俺はC++のios系に移行した
結構作れるようになるまで大変そうだなぁ。
AVGとかだと吉里吉里みたいな開発用のソフトあるけどああいうのはSTGには無いもんなの?
あったら便利なのかどうかも知らんのだけど。
先に2Dだけでも作れるようになれと助言する奴はいないんだな。
fopen ってC++の stream よりなんとなく軽そうだからfopen使ってる
>258
ストリーム使えないなら、そりゃ萎えるが
単にfopen使うことに萎える理由が感じられない
懐古主義も甚だしいから
>258
単なるファイルアクセス(特にバイナリ)にストリームは無駄が多すぎる。
速度効率より利便性の時代に(ry
ストリームってそんなに便利かね。
使ってないから萎える、という時点で萎える
>>261 んん?
今やシューティングを作ること自体が懐古主(ry
Java使うとSTGあたりは糞簡単でびっくりする。
画像読み込んで矩形埋め込んで三角関数でちょめちょめ。
あとは入力受け付けて実行させればハイできあがり。
STGに関してはツクール勧めるよりJavaを勧めたい
俺の場合プログラムはともかく画像が描けん
そこでグラディウスの逆火山面メロディを、どうぞ!
vs2005でc++だけどfopenバリバリ使ってるよ
文字表示はsprintfだしcの標準関数使いまくり
セキュリティ上sprintf_sを使ってくれだそうだ。
ごめん
許す
どうしてもライブラリ作成途中でぐだぐだになってしまう…orz
割り切り方が下手なんだな>俺
いっそライブラリ開発のみに専念したら?
つか今の俺はそう
ローダだけ凝ったらゲームを作る、スプライト管理だけ凝ったらゲームを作る
そんな感じでスパイラルに肥やしていけばいんじゃないでしょか。
適当発言で申し訳ないですがw
おまいらにはツクールスレがぴったりだな。さっさと行け
俺はもうHSPでOK
>>278 ずっと一人でうるさいな。さっさとオマエの素晴らしいシューティングゲーム晒せよ。
>>280 妄想乙。
晒すってなんだ?ここのスレタイも読めないチョンか?
>>277 コンポーネント単位で作ってしまうと、
あるコンポーネントの仕様が全体のボトルネックになってしまうから、
グローバルな段階で設計を詰めておかないと駄目なこともある
>>281 シューティング製作技術総合って書いてるからShow&Tellでもいいんじゃね。
ほれ、晒せ。
実際に作っている人はここにはいませんから
君はそうかも知れんが...
>>282 ネックになりやすいコンポーネントって何?
>>286 抽象的に言ってしまえば、上位層まで処理を行ってしまうコンポーネントかな。
そのコンポーネントを使うためには、その層以上の処理しか行えないでしょ。
これはカプセル化の利点と双極に位置する問題なのでどうしようもない。
下位層に影響するような処理を上位層でやりたくなった場合、
下位層のコンポーネントを書き換える必要が出てきてしまうことになる。
だから上位層から設計しておけば、書き換えなんていう手間は出てこないんで、
どうせならきちんと設計しようぜってことです。
でも完成はしないと
208 : はじめはソープでどうぞ
209 : すぐに風俗とか言い出す馬鹿がいるな。
210 : むしろ俺は風俗嬢なんだけどね。
211 : 順番としては間違ってないっしょ。
ソープあたりで動作方法を覚えるってのは至極真っ当な方法じゃね?
風俗否定する人は一体何から始めて欲しいんだ?
212 : というか射精して気持ち良ければリアル彼女か風俗嬢かは関係ないだろ。
213 : ソープあたりで動作方法を覚えるって意味不明だろ
214 : おまえ童貞だろ
215 : おまえ彼女とセックルしたことないだろ。
217 :
>>215 童貞必死だな
220 :
>>217 素人童貞性病持ち必死だな
221 : 結果が同じならプロとか素人とかなんてどうでもいいってば
222 : 素人童貞は皆そう言うよね。そう言って、自分を慰める。
275 : いつまでたっても彼女ができない。
276 : いっそオナテク開発のみに専念したら?
つか今の俺はそう
まで読んだ
誤爆ですよ
>>288 結局上と下を行ったり来たりするのが一番現実的ってことだな
>>290 ご苦労さん。無駄にマメな奴だってよく言われないか?
後はその熱意をゲーム完成させる方に向ければ最高だな。
どどど
りふの
だいば
くしょ
わらっ
また来週
みなさんはじめてシューティング初めて完成させるまでにどのくらいかかりました?
プログラミング初心者ですがシューティングに挑戦したいと思いまして。
3時間あれば十分じゃないかな
人に公開するレベルからだよエターナルのは。
クオリティ次第だなw
俺は休日にちょこちょこつくって四面×ニ周のを半年ぐらいかかった
プログラムより画像に苦労した
シューティングってプログラムの手間はかからないから
それ以外の部分の調達にどれだけ時間かけるかが全てだな。
>>247 どっかオススメサイトないっすか?>WinAPI資料
DirectXもだけど、WinMain内で使えるC側の関数や命令がどれなのか
よくわからん…
大概何の説明もなく混在したソースだったりするので
>>306 やたらと関数が多くて何を使ってよいか分からんということはあるな
俺の世代はPetzold本を嫁、ってことでよかったのだが今はどうなんだろ
猫プロなんかでいいんじゃないの
その程度のCGで動かなくなるほどJavaはヘタレじゃない。
グラフィクスの動的加工をするような判定以外にCPUを裂くネタにまで及ばないだけ。
仰々しい演算レーザーじゃなくてアニメレーザーなら余裕だろ。
その仰々しいレーザーってどんなものかわからんが
別にCと大きく速度かわらんだろ>Java
クライアントJVMはそこまで優秀じゃないよ
サーバーJVMなら確かにCと変わらないレベルだけど
統合してしまえばいいのになぁ
iアプリはJAVAだろ
ID:E/U5R3L/の日本語がよく解らないのは俺だけか?
>>311 クライアントVMでもだいたいCの8割がたの速度は出てるわけだし問題ないと思われ
それにサーバーVMは強度の最適化のためにゲームに向かないよ
ゲーム中の軽い部分はほとんどインタプリタで動いてるけどまぁ問題ないようだね
Javaで派手なエフェクト関係するならJOGLが必須だけれども標準APIになってくれればいいんだけれども
JavaSE6で内部的には使うこともできるけど表面に出てこないのがちとつらい
>>308 その程度の画面でもっさりしていたら、そもそも言語として使い物にならないと思うw
>308
ブラウザシューティング作ろうと思うって話だったから
JAVAアプレットの話じゃないか?
2DSTGで遅い部分ってせいぜい描画部分だけでそ?
JOGLならopenGL、Java2Dなら(Winなら)DirectXが使われるわけで
演算部分の差は出ないよな。20MHzくらいあればゲーム部分は余裕だろうし。
だからそれは何の20MHzだよ。
MIPS-R5900とか
想像では、Z80
MSXの
たしか88で8MHzと4MHzの切り替えがあったような気がする
X68000が10MHz、X68030が25MHzだった希ガス。
Z80の20MHzって結構凄くね?
FM-7は2MHzだったよ
>>323 流行のデュアルコアにするより、
Z80 20MHzの150コアにする方が早そうな気がする
マジレスすると並列化処理はコアが倍になれば倍速になるわけじゃなくて
大抵は1.9倍とかそんなもんだから数だけ増やしてもあんまり意味ないよ
しかもクリティカルセクションを20MHzで処理されても…って事態に陥る。
>>321 それは88FH/MH以降のV-1モードのH/S切り替えだな。
ただ体感的にSだとmkIISRより遅かった気がしないでもない。
あ、失礼V1/V2は88mkIIまでとSRとの切り替えだった。
4MHz/8MHzとはまた別だ。
なんでおまいらこんなことに詳しいんだよw
実際使ってたからな
意訳 : デジタル8色のエロゲで抜いてたからな
何でといわれても普通知ってr
デジタル8色って更に2世代ぐらい前の話じゃねーか
88でいうと元祖とmkIIの時代だからな。
ねぎ麻雀とかマリちゃん危機一髪の時代。
初代msxでゲーム作ってた人いる?
あれでシューティング作るの大変だったな
スプライト1色しか使えない横に5つ並ぶと消えちゃうし
グラディウス2とか作ってたあの頃のコナミは輝いてみえた
最低動作環境はメインメモリ8kバイトだもんな
8192バイトなんて今時メモリ境界調整用領域扱いだな
なんか、古参が多くて安心した w
シューティングお達者倶楽部と聞いて来ました
昔は無理あるAC移植が沢山あったね〜
MSX版ファンタジーゾーンは笑えるぞ
見えない弾を心眼で見て避けなければならない
当時はROMもメモリにマッピングされてたんだから
全部RAMに展開しないといけない現代とはちょっと容量の概念が違うけどな
>>336 たしかにつらいが、スプライトのおかげで背景との重ね合わせを考えずになめらかな表示ができたのはいい
しっかし初代ザナックはバランスや雰囲気でFCよりいい出来だったな
MSXの方が易しかったな
お前しかやったことないとでも思ってる?
> 初代ザナック
えー!最初はファミコンじゃないの?
MSX版が先だよ
つーか、おまいら一体何歳だw
永遠の中2
>>348 背伸びすんなよ
ピアニカや一輪車に夢中だろ?
一輪車が出てくるのはなぜだ?
俺が中2の時は88でベーマガに投稿してた頃だ
あの頃からずっとシューティングを作ってる
だが俺の理想とするゲームは未だ完成しない
>ピアニカや一輪車に夢中だろ?
ピアニカなんて、すぐ歯形がついて、
なんか不潔で最も忌むべき存在の1つだな。
授業以外で触れるものかなかった。
1輪車も無くは無かったが定着はしなかった。
ローラースケートの方がまだ持ってる奴がいた。
スーパーボールやラジコンに夢中だろ?
山の彼方の空遠くにあるんだろう、きっと
中2の頃というと、ファンタジーゾーンだな
あーあ
また懐古ネタが始まったか
ガキは黙れ
351はアミバだな
なんか流れ切る上に遅レスすまん
>>307 レスサンクス。やはり猫っすか…
ハア…俺のprintf…
中2の時、同級生であだ名が「アイダ2」ってのがいた
名字が「相田」だからではなく顔が「アイダ2」に似ていたから
>>359 printfは、fprintfの出力がstdoutバージョンだと思えばいい。
ところがWindowsではstdoutがあるか?って話。
標準出力というかゲイツ出力ならあるけどね。
リダイレクトでファイルに吐き出してる俺は何か勘違いしてるんだろうか
標準出力を使う意味が判らん
何に使うんだ?
ログとってデバグだろ
それこそデバッグ出力で事足りるが
そんなん人それぞれじゃね?
好みや環境によりけり
技術的な話をしろよ
技術的な話をしろと言ったとたんスレが止まった件について
そのゲームについての技術的な話をするならいいんだが
質問があって成り立つスレだからなぁここは。
プログラムに関してはあんまり質問がないのだが
爆発エフェクトとかショットとか敵弾とか
そういうのをどうやって書いてるかというのには少し興味ある
edge
んじゃ聞いてみるか。
1フレームが
・行動の決定(移動方向の決定)
・当たり判定
・状態の更新(座標の更新)
という処理の流れとする
貫通しないレーザーがある。
これは当たり判定時に、最も手前でヒットするオブジェクトを探してそこで途切れる。
このとき描画処理の位置をどうするか。
・更新の後だと、レーザーを発射しているオブジェクトが移動していると、
発射オブジェクトとレーザーの位置関係がずれてしまう。
・判定の後だと描画が1フレーム遅れることになる。
さてどうしよう?
やってみてうまくいったほう
座標更新の後に当たり判定を取って、
そこの結果でレーザーの長さを修正したものを描画
ってやってるなぁ。
処理順序やらの問題は色んなとこでどうしてもつきまとうけど、
実際には1フレームの誤差で致命的になることは少ないんじゃないかと思う。
>>377 答えになってないんだけど、
やりたい事が大前提で、それを実現するために処理を作るわけで、
そう考えると、そもそも処理の流れを変えるしか方法がないと思うのだけれども。
どうしても同一フレーム中で当たりの判定を実現したければ
行動決定→状態更新→当たり判定→当たりによる位置修正→描画
しかないと思うが、どう?
というか、
> 発射オブジェクトとレーザーの位置関係がずれてしまう。
当たり判定でレーザーが修正された場合に発射元とずれることってあるか?
途中で遮断されても発射元からの距離が変わるだけであって、
レーザー自身が発射元からずれるように自立移動しない限りずれないような。
そういうことではない?
とりあえずすぐ答えられるのだけ、えーとこれで解るかな
>381
・行動の決定
|
Ф
|
△→
・当たり判定
○
|
△→
・状態の更新
◎
|
△
んー提示した条件だけだと、やっぱり順番入れ替えか……
>>382 グラとか怒蜂のレーザーみたいに自機の軸と同期するタイプのレーザーは
自機とレーザーの位置関係について1フレームの遅れが出たら
まずプレイヤーに気づかれるので、そちらのほうは同期させるしか選択肢はないかと。
位置情報は全てのオブジェクトの時間を統一したほうがいいと思う
・行動の決定(移動方向の決定)
・座標の更新
・当たり判定
・状態、フラグの更新
・描画
でええやん
1フレーム遅れてもわかんねーよバカ
>>385 1フレームの遅れが画面にどう影響してくるかによるから、その発言だけだと単純には賛同できんな。
例えば移動速度が毎フレ4ドットだとして、レーザーの進行方向に対して垂直移動すると、
中心線が常に自機から4ドットずれてしまう。流石にこれは分かるよ。
でも敵に弾が当たったタイミングとかは割とどうでもいい。
余談だが最近のゲームは描画中に別スレッドで衝突判定して次フレームで反映させたりしている。
GPUが重い作業をしている間もCPUが作業できるので効率がよいのだが(マルチコアPCならなおさら)、
弾幕シューだとそもそもの全体処理が軽すぎてどのみち変わらないのがなんとも
> 余談だが最近のゲームは描画中に別スレッドで衝突判定して次フレームで反映させたりしている。
はつみみです。
メインループと描画ループとで別々にFPS管理しようかなと思ってる。
メインループは30,60fpx、描画は任意fpsでコントロールしたい。
> 余談だが最近のゲームは描画中に別スレッドで衝突判定して次フレームで反映させたりしている。
ありえん
脳内乙
突っかかるねぇ。それじゃ脳内と思う理由は何よw
理解できないから
最近は、っつーけど最近の何?
業務用の話?
>>388 60なんて言わずに120でどうよ。
ていうか描画が任意fpsなら内部もフレーム単位に拘らなくてもいいんじゃない?
業務用っつーか家庭用っつーか。次世代機はマルチコアだから並列化すんだよ。
PCでもデュアルコアが出回っているしPCも数年後はそうなるんじゃねーの?
現状でもGPUがある時点で並列化して作業してんだけどな。
(例えばDrawPrimitiveはポリゴン描画命令投げて帰ってくるだけ)
今まで描画だけが並列化の対象だったのが、
これからは何でもかんでも並列処理になるわけだ
>>393 内部を120まで上げるとどんな利点が考えられる?
あと内部は固定にしないと精度に差が出るよ。
低すぎるとすり抜けが起きるし、そこは固定でいきたい。
某コンシューマゲーム会社のプログラマーだけど俺の知る範囲では
少なくともPS3や360で判定にスレッドなんか使ってないなぁ
基本的にシングルコア、シングルスレッドだよ
使うときはファイルの裏読み程度だな
並列化するとリプレイとかが死にたくなる仕様になりそうだ
>>397 そう?内部だけリプレイさせればいいんだから同じでしょ。
(弾の)当たり判定と、
衝突判定(物理エンジン)を混同しているんじゃないか?
覚えたての言葉を使ってみたかったんだろうが。。。
>>398 理屈の上ではそうなんだが
操作感や遅延解消に気を使いながら反映させていくと
どうも並列化の旨みより手間のほうが多くてね。
同期とらなきゃいけない時点でメリットがかなり減るし。
非同期で高速化最優先の並列化なんかやったら、そりゃ、手間隙
かかりすぎるだろ。必要な機能から徐々に並列化させんとな。
考えるべきは並列化ではなく、アルゴリズムを工夫すべきかと。
当たり判定とかは基本的には領域分割して別個に処理する方が、
処理としては格段に高速化できる。
ネタ投下してみたが盛り上がって何より
>>396 マシン全体のパフォーマンスがコア1つ分で頭打ちになるでしょ?
PS3なんかSPU使わなかったら単なるファンヒーターじゃねw
>>397 >>400 リプレイやるならロジック部を直列にする。
確かに同期はめんどくさいから余分な力は使いたくないな
>>399 当たり判定と衝突判定は別の処理のこと言ってるの?
>>401-402 並列化なんてシングルコアだったら余計パフォーマンス悪くなるしなあ。
同人シューのプレイヤーがみんなデュアルコアなわけありえないし。
領域分割のほうが色々と利点多いよな
>>401 通信部分とかムービーのデコードとかサウンドモジュールを別コア別スレッドにしてるね
ゲーム内部の並列化は必ず議題になるけど議論だけで実際の作業には進まないw
>>395 いや内部は固定以外あり得ないだろう。
ループと描画が同期しなくていいならループは16ms単位に拘らなくてもいいじゃんってことが言いたかっただけよ。
リフレッシュレート論争で言うところのA宗。
で、内部を120fpsにすると60連射が出来る(笑
というのは冗談として、20,30,40,60Hzに対応できる。
内部300fpsなら75Hzにも対応できる。くらいかなぁ利点は。
ごめん、内部を固定する場合はA宗1派か。
120fps厨を黙らせるキーワードとしては聞いたことがある<リフレッシュレート
あ、描画の方ね。誤解なきよう。
>
>>399 > 当たり判定と衝突判定は別の処理のこと言ってるの?
むしろ「口を開く前に考える癖をつけて方がいいよ?」と言ってる。
俺はお前の思ってることを理解できるほどエスパー能力はないんですよ。
ちゃんと説明したら?
俺といわれても誰だかわからんのですが
おれだよおれ
おまえら目を離すとすぐ喧嘩するんだな。仲良くしろよ。
>業務用っつーか家庭用っつーか。次世代機はマルチコアだから並列化すんだよ。
>PCでもデュアルコアが出回っているしPCも数年後はそうなるんじゃねーの?
こいつプログラム書いたこと無いな
バカ丸出し
CPUの数によって最適化させる奴らは現れるだろうけどね
まあこのスレにはこないだろ
417 :
名前は開発中のものです。:2006/07/02(日) 00:41:29 ID:8TUWerH3
>415
OSのスレッド管理やマルチスレッドプログラムにおけるスレッド同期について
正しい知識を持ってればそんな事考えもしないはず
半可通の発想
>418
自分で出来もしない事をのたまうのは止めたら?
恥ずかしい奴w
みんなは夏に向けて何か作ってんの?
彼女
子供
スレッドも組めないのか、なんか相手にするだけ無駄
>>423 言うに事欠いてそれか、ホント馬鹿だなw
同期する必要なけりゃ普通に使ってる
お前こそスレッド同期させるコード書いた事ないんちゃうかと
わかった!判定で、スレッドうんぬんという話は、あれだ、
XBOX360のジオメトリーウォーズだな!違ったか?
ID:dAtEfMTLではないが…
>>386 >余談だが最近のゲームは描画中に別スレッドで衝突判定して次フレームで反映させたりしている。
これは余談というかむしろ無関係に近い。脳内開発者でなければすぐ分かる。
この並列化処理で恩恵(安定した高速化)を得るにはある条件が必要であり
弾の衝突判定においてその条件は満たされないからだ。
>>424 純粋に疑問なんだけど質問していい?
もちろんCPU2つを同時に使えることくらい知ってるよね?
スレッド使える人が
>>414とか
>>417のような発言をすることが理解できないんだわ
>>420 去年の冬に向けて調整してたものがようやくマスターアップしそう。
長かったなぁ・・・。
みんな!ちゃんと歯を磨いてから寝ろよ(←微妙に失敗談)
そもそもどんだけCPUを積んでても、バス幅やバスクロックの壁がある品
並列化をすればするほど、この壁が大きく足を引っ張るから、
CPUを数積む事にゃ、あんまし意味無い罠
2D限定なら今のPCなら高速化とか考えなくても良いんじゃ
可読性重視、面倒なことはしない、じゃダメですかw
市販じゃないならそれでいいと思う。
完成するかどうかのほうが大事だし。
>>427 純粋に質問なんだけど、OSのスレッド管理理解してる?
プログラマは2つのスレッドを意図的に個別のCPUに割り当てる事は出来ないし、
OSがスレッドを同じCPUに割り当てるのも(1/CPU個数)の確立であるんだが。
431のblogは前半は真っ当な内容なんだが、後半は自分で何書いてるか
理解してるのか首を捻る。
正直そのblog書いてる奴もマルチコアに夢見すぎてるな。
取り敢えずスレッドは「システムの都合上必要に応じて使う」程度の認識で。
ことリアルタイム性が至上のゲームプログラミングで”スレッド分割で
パフォーマンス向上”ってのは眉唾。
ハードの宣伝文句を拡大解釈して信じている、純朴な人なんだろ
>431
>いわゆる処理落ちが発生する。
>人間の脳は適当に補間してくれるので、処理落ちが発生しても秒間30コマくらいまでは気が付かない。
これは、いくらなんでも鈍感すぎだろ
通常60で動いてたら1フレでも遅れれば分かるっつーの
(小間落ちならまだ分かるけど・・・それでも30はないよな・・・)
スレッドも使えない奴がぎゃぁぎゃぁうるさいよ
もう夏休みか?
>>435 CPU1個を使い切れてないのに並列化したところで意味ないだろ。
1つのCPUを使い切っているからこそ並列化するんじゃ…
最終的にはOSの判断だけど、
片一方が常にbusyなのに、その片一方に別の作業を割り振るほどWindowsは馬鹿じゃない。
>CPU1個を使い切れてないのに並列化したところで意味ないだろ。
>1つのCPUを使い切っているからこそ並列化するんじゃ…
この言い方でまだ理解できてないって事がワカル
俺に何が足りてないの?
俺が間違ってるなら認めるから教えてくれよ
>>440 はぁ?実際処理と描画は別スレッドでやってるっての
能力ないことをそんなに自慢すんなって
>最終的にはOSの判断だけど、
> 片一方が常にbusyなのに、その片一方に別の作業を割り振るほどWindowsは馬鹿じゃない。
馬鹿ですよ。Sleepさせてる処理に作業を割り振るほど馬鹿ではないが、
優先順位を割り振らなければ等価に作業を割り振るし、きちっと同期処理
を入れなければ、デッドロックや書き込みエラーを平然と発生させるし。
処理同期のオーバーヘッド考えたらシューティングでマルチスレッドって意味無いと思うけど
次の処理に進むとき前の処理が終わってなきゃ進めないなんてのがゲームプログラムじゃ当たり前
並列化できる部分は少ないし、出来ても同期処理で結局一方のスレッドを待たせなきゃいかんので
結局プログラマのオナニーになるだけでパフォーマンスは上がらない
勿論BGM鳴らすとかの処理はスレッド別けるけどね
同期せんでもいいしこっちの方が楽
>>445 すまん、それほんとに理解できない。
CPU1を100%で消費していてCPU2が0%なのに
わざわざCPU1にスレッドを割り振ろうとするOSがあるってこと?
プログラマ自身が割り当てできない時点で既に的を外してるとオモ
内部処理と描画処理は非同期でいいんだよ。
トランザクションはmemcpyして抜ける一瞬だけ。
あと処理の流れが同じ向きを向いてるなら
デッドロックなんて発生しない。基本中の基本。
>>447 負荷を等価にするために、スレッドの割り当てを順番に回してるだけ
それ以上の事はしてないとオモ
単純なシングルスレッドよりはマルチスレッドにした方が良いけれども、
スレッドを増やしまくっても意味は無い。
そっか。スレッドを使いこなして無いがために、
無闇やたらと並列化するような発想は、まだ頭に無いんだな。
スレッドて2ch語だよねー
微妙に噛みあってない気がするのは俺だけか?
正直興味ねー
スレッドも、タスクシステムと同じ運命か。
飽きられてて続けるとヤメロと言われそうだけども
>>450 そうだよね?
あと
>>451って俺へのレス?
確かに使いこなしてるとは言いがたいよ。
数値計算で2CPUを100%でぶん回すことくらいしかしたことない。
ゲームだと
>>436が言うようなリアルタイム性が重要だから
数値計算みたいな理屈は通用しないことがあるのかね
理屈じゃなくて実践すりゃ解るんじゃね?
うんざり('A`)
処理の依存関係がない場合に並列化できるわけで、
複数のCPUを効果的に動かすには、それ用に組まないと駄目そう。
あと、スレッドの起動やレジューム自体オーバーヘッドが大きいから現実でない気がする。
現在のスレッドの使用シーンとしては、waitが絡むところ(ファイルIOとか描画待ちとか)に
あるわけだけど、今後もそれが変わるとは思えないんだよなー。
キャラクターごとにスレッドとして処理するのもやってやれないことはないんだろうけどね。
なんか大変そう&意味なさそう。
ウンザリアン二世
?な発言集
>386> 余談だが最近のゲームは描画中に別スレッドで衝突判定して次フレームで反映させたりしている。
>394> 業務用っつーか家庭用っつーか。次世代機はマルチコアだから並列化すんだよ。
>415> CPUの数によって最適化させる奴らは現れるだろうけどね
>431>
>>386の例は弾幕シューだと矩形判定程度なのでショボイのだが、一応これに該当かな。
>431> > それにしてもこの記事の最後の一文が痛快すぎて仕方がない
>440> 片一方が常にbusyなのに、その片一方に別の作業を割り振るほどWindowsは馬鹿じゃない。
>449> トランザクションはmemcpyして抜ける一瞬だけ。
>449> あと処理の流れが同じ向きを向いてるならデッドロックなんて発生しない。
>457> 数値計算で2CPUを100%でぶん回すことくらいしかしたことない。
俺的メモ
>396
> 某コンシューマゲーム会社のプログラマーだけど俺の知る範囲では
> 少なくともPS3や360で判定にスレッドなんか使ってないなぁ
>426
> この並列化処理で恩恵(安定した高速化)を得るにはある条件が必要であり
> 弾の衝突判定においてその条件は満たされないからだ。
>435
> プログラマは2つのスレッドを意図的に個別のCPUに割り当てる事は出来ないし、
> OSがスレッドを同じCPUに割り当てるのも(1/CPU個数)の確立であるんだが。
>445
> 馬鹿ですよ。Sleepさせてる処理に作業を割り振るほど馬鹿ではないが、
> 優先順位を割り振らなければ等価に作業を割り振るし、きちっと同期処理
> を入れなければ、デッドロックや書き込みエラーを平然と発生させるし。
>446
> 処理同期のオーバーヘッド考えたらシューティングでマルチスレッドって意味無いと思うけど
> 次の処理に進むとき前の処理が終わってなきゃ進めないなんてのがゲームプログラムじゃ当たり前
>448
> プログラマ自身が割り当てできない時点で既に的を外してるとオモ
>458
> 理屈じゃなくて実践すりゃ解るんじゃね?
>>461 お前がそうとうレベルが低いというのは良くわかった。
もう来なくていいよ。
このスレってどうして技術的に中途半端なのが一番偉そうにしてるんだろうな
う〜ん。まぁ、○○システムはSTGに有用か?とか、
○○処理でSTGの処理速度向上するか?とか、
検証するのはいいんじゃな。”たまたま”全敗なわけでwwww
誰も検証しないもんねえ。
あ、「しない」じゃなくて「できない」か
466 :
名前は開発中のものです。:2006/07/02(日) 18:08:25 ID:g1tErj+R
全敗って何だ?もの知らないとそう見えるのか。
このスレは悲惨なレベルのやつばっかだな。
そう、ムキになるな。釣りが全敗と言ってる訳じゃないw
468 :
名前は開発中のものです。:2006/07/02(日) 18:14:34 ID:g1tErj+R
いや単純にお前はレベルが低い。それだけだ。
一応、冗談でならスレッドを100個ぐらい始めに作って、
役割を与えたら役割どおりにスレッドが動作する、みたいな
事なら考えたことはあるが、まだ実践するほどの腕ではない。
誰かやってみる??w
技術的な事にあんま興味ないからなあw
動きゃ良いじゃん。
>>470 流石にそれだとこのスレの存在価値がないので
描画、ディスクIO、BGM
スレッドなんて使ってて当たり前だろ
シングルスレッド一筋ってきもいわ
HSP使いなので、そもそもの用語が分かりません
初めから用意されてる機能を使ってるだけだから
俺はスレッド使ってないぜとか思い込むんだろうな
>>472 ゲームのメイン処理の話してんじゃないの?
ファイル読みやBGMや描画が別スレッドなのは極普通の事だと思うが…
OSのない業務用だとスレッドすらない環境もあるからスレッドが羨ましい時がある
>>461みたいなアホを見るにシングルスレッド教が発狂してるだけどしか思えん
>>472 > スレッドなんて使ってて当たり前だろ
そういう話は既出。
>396> 使うときはファイルの裏読み程度だな
>404> 通信部分とかムービーのデコードとかサウンドモジュールを別コア別スレッドにしてるね
それだけならこんなに突っ込まれないと思うよ。
>441> 片一方が常にbusyなのに、その片一方に別の作業を割り振るほどWindowsは馬鹿じゃない。
あたりのソースとか、
>386> 余談だが最近のゲームは描画中に別スレッドで衝突判定して次フレームで反映させたりしている。
が物理エンジンの話じゃなくて、>431の言う
>431>
>>386の例は弾幕シューだと矩形判定程度なのでショボイのだが、一応これに該当かな。
これの話だって言う根拠が出てくれば、話は変わってくると思う。
>>441 >>片一方が常にbusyなのに、その片一方に別の作業を割り振るほどWindowsは馬鹿じゃない。
>あたりのソースとか、
そもそも1スレッドでビジーループ回したときですら100%/0%にならないだろ。
あと矩形の衝突判定は物理エンジンの機能の一部じゃん。
なんでそこに拘るのかわからない。
レベルが低いと言われたから頑張ってみたけど
やっぱり無理でしたという浅はか君ってことさ
最近のゲームは当たり判定にマルチスレッドやらマルチコア対応してる云々言い出したのがことの始まりだと思うんだけど
具体的になんていうゲームで使われていて、実装例を軽くでいいからここに書いてくれれば参考になる
頭の固いオレにはオブジェクト同士の当たり判定をマルチスレッド化する利点がどうにも理解できないもんで・・・
スレッドを使う=当たり判定なのか、勉強になったよw
482 :
名前は開発中のものです。:2006/07/02(日) 21:46:52 ID:Y1jICERU
シューティングなら爆煙とか飛び散る破片とかは発生した瞬間に
ゲームの処理と切り離せるから並列処理してすごいことができそうだね
へー
そりゃすごいよん
>>480 ひとつのスレッドを審判と見立て、複数の視点からひとつの事象を判断して
たまに審判同士の判定が食い違ったりしてプレイヤーほったらかしで論争始めて…
ごめんやっぱなんでもない
>>478 > そもそも1スレッドでビジーループ回したときですら100%/0%にならないだろ。
「たしかに0%じゃなくて(他のスレッド分)数%あるよねー」ってオチじゃなくて、
1スレッドでも複数CPUに処理が振り分けられるって主張だよね?
マルチスレッドにしなくても並列化されるってことになるね。
実験してみてレポートしてほしい。
> あと矩形の衝突判定は物理エンジンの機能の一部じゃん。
端的に言えば、「それは本当にSTGなどのリアルタイムなゲームに通じる話?」
ということだ。
数値解析している後ろで途中経過を描画しています、なんてのはシューティングの
それと状況が(話を援用できんほど)違う(>426)んじゃねーの?
だから、そもそもその情報ソースはどっから出てきたのか確かめたいわけだ。
>>482 どうせ他のオブジェクトの処理と結局は同期とらんといけなくならないか?
>>484 CPUの弾回避ルーチンを複数用意して、意見を戦わせるってのがあったな。
それをスレッドごとに分けるとすれば、弾幕状況の変化にスレッドの処理が
追いつかなくなると、回避できなくなって負けになるのか。
>>485 >実験してみてレポートしてほしい。
ビジーループ作ってタスクマネージャみれば平均して50%になるでしょ?ガタツキでまくりだけどさ。
もちろん2スレッドでビジーループ回せば両方とも100%に達する。
>マルチスレッドにしなくても並列化されるってことになるね。
全く並列化されてない。
>端的に言えば、「それは本当にSTGなどのリアルタイムなゲームに通じる話?」ということだ。
ここのSPEの使い方のところに物理があって、その中に衝突判定がある。
http://www.watch.impress.co.jp/game/docs/20060331/ps3_2.htm PS3は非対称プロセッサだし使えるSPEの個数を決めることができてしまうので
比べる対象としたらXBOXのほうが適切かもしれないが、PS3もXBOXもやってることは一緒。
いい加減半端な知識でファンタジー垂れ流すのやめて('A`)
なんか面白い話してるじゃん
>余談だが最近のゲームは描画中に別スレッドで衝突判定して次フレームで反映させたりしている。
>GPUが重い作業をしている間もCPUが作業できるので効率がよいのだが(マルチコアPCならなおさら)、
もしそのゲームがPS2、PS3、GAMECUBE、XBOX、360あたりのコンシューマー用なら
その最近のゲームってのを具体的に挙げてくれ。
方法はさておき、当事者として凄く興味がある。
490 :
386:2006/07/02(日) 23:38:07 ID:waMoKihP
>>489 すまんが守秘義務で言えない。
つか技術を書いてる時点で守れてないのだが…
今更だが社会人失格だと思ったよ。ほんと欝だ…
491 :
386:2006/07/02(日) 23:47:32 ID:waMoKihP
ほんとこんな荒れ狂ってしまって話題出した身としては本当に申し訳ないのだが
ちょっと反省中なのでもう出てこないです。
とりあえず負け犬確定でいいので好きにしてください…
>>489 去年のCEDECで、Intelが具体的なタイトル名を上げて
ゲーム(洋ゲー)でのマルチスレッドの利用例について講演していた。
今資料が手元にないので、タイトル名は忘れたけどBlack&White(2?)は
入っていたな。
>とりあえず負け犬確定でいいので好きにしてください…
そもそも内容ではなく、
勝ち負けに拘って書き込みしている時点でキモ過ぎ。
あんたネットに向いてないよ。マジ逝ってください。
コンシューマハードの妄想なら続きはゲハ板あたりでどうぞ
非常に迷惑
くだらん技術話はもういいから完成させようぜ
守秘義務wwww超ウケルwww
脳内社会人乙wwwじゃなくて欝www
>>482 並列処理云々は置いておくとして・・・
超連射68Kの開発後記にもあったけど、爆風の相互干渉はやっておきたいな。
MC68000の頃は無理でも今のPCなら余裕で出来そうだ。
前世紀ハードのNAOMI/DCで爆風計算をこなしてるシューティングがあるので
今のPCなら超余裕じゃないんですかねー
>>499 懐かしいな
今でも1年に一度は68引っ張り出して開発後記みてる
あの時代のよさを思い出してモチベーションがあがるのよ
Win版は8bitカラーのソフトレンダだけど今でも16bitカラーで半透明のソフトレンダやると
VGAはきつそうだな
マルチコアでぎりぎりとか
>マルチコアでぎりぎりとか
いい加減にしろや
デストロイザコア!!
???
>>501は
今のCPUでもVGAごときのサイズで
半透明ソフトレンダがいっぱいいっぱいな
ヘボいコードしか組めないのか?
あからさまな釣り乙
>>506 フィルレートとか考えるときつくないか?
シューティングアヘッド!!
>505
グラディウスしらないの?
若いな・・・
505は503宛
グラディウスUのボス前に弱点を教えてくれる声をいきなり叫ぶ意図がわからない。
まさかマルチコアと……まさかな…はははは
論争一段落したみたいなんでチラシの裏。
14歳からはじめるC言語ゲームプログラミング(横シュー本)
やっと二周した。
本文内の間違いやら不適切な説明やらメモしてたら30箇所近くになった。
約300頁だから10頁に一回は出てくる計算。
本当に校正したのかラトルズ小山。
「どうしてそうなるかは自分で考えてみて下さいね」とか言ってる場合か大槻。
なんか読んでてCとは関係ないとこでフラストレーション溜まった。
っつーかトピックの選択は悪くないのに勿体ない…
初心者本が初心者に間違い探しさせるって('A`)アリエネエだろ…
パソ関連は初期ロット買ってはいかん法則?
>>514 4月発売なのにラトルズのサイトに書籍購入者向けPDFや正誤表が未だにアップされていない罠。
悪い本ではないのだがなぁ・・・
12歳のHSP本にもシューティング載ってるぞ
つまりシューティングは子供向けってこったな
sin, cos, atanを駆使するだけで作れるから子供向けなのは確か。
まあそのころだとこれらは「おまじない」ですまされそうだけどな
いい加減なもんだったらRPGとかアドベンチャーのが簡単に出来るぞ
一番難しいのはパズルじゃねのw
シューティングが一番簡単だって。
そこはもうそれでいいじゃん。何を守ろうとしてんの。
簡単に作ろうとすればなんでも簡単だってだけだよ
守るってなんだw
俺技術的なことにあんま興味ないし
俺は小4の時にMSXを買ってSTGを作り始めた
BASICだけじゃ遅いのでハンドアセンブルでキャラ描画や
2重スクロールを実現させて喜んでいた
その頃はSTGなんてすっげえ簡単にできると思っていた
それから20年、今も作り続けているがまだ完成しない
俺を満足させるゲームを完成させることは非常に難しいのだ
まだMSX動いてる?
難しく作っても、シューティングは簡単だろう
??
プログラマが吐く日本語は難解ですな
いや、さすがにMSX→PC88→PC98→自作機って感じで
環境は変わってるが、タイトルとストーリーは一環してる
ただ、舞台が宇宙から和風ファンタジーになったり、買い物システムや
オプション操作、流行の弾幕や対戦モードいれたりしてなかなか完成しない
その間に推理アドベンチャー、ノベルゲーを3本完成させてるけどね…
タイトルとストーリー以外全部違うんじゃないのかソレは。
そりゃ作り続けてるというのか?w
アルゴリズムやゲームとしての概念は単純で簡単な部類だろう>STG
俺はプログラム習いたての頃、ブロック崩しの次に作ったのがSTGだし
自キャラと敵キャラ適当に配置して経験値とかつけりゃRPGと言えないことも無いw
アルゴリズムやゲームとしての概念ならRPGやADVってSTG以上に単純で簡単な部類な気が…
これらを初心者が作らない理由はAIが作れないとかそんなアルゴリズムが絡むような高次元の話じゃない。
素材が占めるウェイトが大きくて、
単に大抵の人はシナリオやCGを用意してる途中で飽きるからだ。
つか、どんなジャンルでも底辺は大差無さそうだな…
>529
そこで伝説の「縦スクロールRPG」ですよ。
(°Д°)ハァ?
STGなんて自機&敵の移動処理と弾だし、当たり判定程度だろ
簡単じゃんwww
初期ドラクエとグラディウスを比較すれば後者が簡単なのは誰の目から見ても明らか
>>532 どっちが簡単かはとりあえず放置するけど、
RPGの代表:初期ドラクエ
STGの代表:グラディウス
ってのは公平な比較なのか?
比較したいならRPG、STGの最低限の機能を抽出して、それを比べなきゃ。
>STGなんて自機&敵の移動処理と弾だし、当たり判定程度だろ
をもっと詳しく書いて、且つRPGについても同様に述べること。
誰の目から見ても明らか でも述べること。
こういう場所で 誰の目から見ても明らか ってのは通用しない。
俺はお前でもなければエスパーでもない。
文系と理系の大学はどっちが入るの簡単か?みたいな話に見えるね
ランダムで敵がでて経験値が入るだけのRPGなら簡単そうだな。
テキストアドベンチャーはもっと簡単そうだが。
536 :
名前は開発中のものです。:2006/07/05(水) 15:32:37 ID:UZ7PcmL2
なんか前もこんなことやってなかったか?おまえら香ばしすぎるぞ
俺は前のフレーミングのときにシューティングは低俗単純簡単
お子様のつくるゲームジャンルだと言い張ったが
アインハンダーみて心を入れ替えた
>>536 今回は
>>534が早々に結論だしてるじゃん。
それより何故にアインハンダーで心を入れ替えたかを詳しく、丁寧に、かつ大胆に。
なぜよりによってアインハンダーwww
>>515 だよなあ。正誤表くらいさっさと出してほしい。
っつーか追加PDFすらまだなんかい( ゚д゚)ズコー
アインハンダ曲だけ引っこ抜いてゲーム積んでるw
STGがゲームの構造としてシンプルなのは確かだろう。
ただシンプル=簡単という話ではない。
もういいよその話、釣りっぽいし
俺はangelioだな。あれで心を入れ替えた。
インストールフォルダ変えるとその下全部消しちゃうんだっけ?w
angelio?
>>540 お前は一生完成しないSTGをMSXで作ってろ
ある意味修業
546 :
名前は開発中のものです。:2006/07/05(水) 22:49:11 ID:UZ7PcmL2
>それより何故にアインハンダーで心を入れ替えたかを詳しく、丁寧に、かつ大胆に。
多関節ポリゴンモデルのアニメーション制御(恐らくマトリクス垂れ流しでない)+当たり判定の制御
シミュレーションによる頂点位置の計算の部分的導入
ステージ間をシームレスにつなぐ演出(PSの制御についてはしらんから難しいのかどうかわからん)
破壊個所による攻撃パターンの変化
547 :
名前は開発中のものです。:2006/07/06(木) 00:14:19 ID:ipP0XChi
作ってる側からすると、STGやACTはテストプレイやデバッグ過程が案外楽しい
アルゴリズムや出現パターンをちょっと変えるだけで急に新鮮になる
RPGやAVGは、最初は楽しいが何度も繰り返すと結構飽きてくる
格ゲーは作ったことないのでわからん
でもアインハンダーつまんねえじゃん
うむ。シューティングの道は深いがアインハンダーはつまらん。
551 :
名前は開発中のものです。:2006/07/06(木) 02:56:16 ID:RVPQQPQ8
あれをつまらないと言われたらいったい何をつくったらいいのかわからなくなるな
遊んで楽しいのと
作ってて楽しいのは違うからなー
アインハンダーは明らかに後者
551の悩みが理解できないw
遊ぶだけの人間は作る人間と比べて、要求のハードルが高めになりがち。
>遊ぶだけの人間は作る人間と比べて、要求のハードルが高めになりがち。
高めとかじゃなくて的外れ
軽くぺろっと作ったところが何故かエラくほめられて
苦労したとこはスルーされるのはよくある話だ
アインハンダーよりも凝った演出しているSTGって
ここ10年見たことないな。ゲーム内容はともかく
演出だけならSTGでトップじゃね?
さすがスクウェアだけの事はある。
それで?
釣りか?
3DCGのシューティングゲーム作りたいんですが
どんなソフトがいりますか?
MAYA
なんか変なのが付着してるなこのスレ
俺のことか
ゲーム開発者あってのものなんて当然の事実だろ。
開発する人間がいなければプレイヤーは遊ぶことすらできないからな。
そもそもプレイヤーの意見なんて愚痴でしかないからゲームとは全く関係ないんだぞ?
そんなことも理解できないのか?
msxで作ることの何が悪いのか・・
NSXより速いと言う伝説のマシンだな
>そもそもプレイヤーの意見なんて愚痴でしかないからゲームとは全く関係ないんだぞ?
釣りか?
良作だが売れなかったゲームはどうすればいいんだ・・
プレイヤーの意見とかは大事、
クリエーターの意見ばかり採用したゲームは糞
プレイヤーに媚びてばかりも糞
クリエーターとプレイヤーの意向のバランスを考えたものが一番良作
そうそう、重要なのはフィルタリング
ゲハ板池よカス
>釣りか?
見て判らんのかw
カメレスだが
RPGツクールでSTGが作れる。
よってRPG>STG
頭脳戦艦ガルが作れんのかー
ツクール厨はお帰りください
ちょいと質問
沙羅曼蛇の炎面の実装てどうやってんだっけ?
1:チップ書き換え
2:スプライト
昔マップチップだと聞いたような気がするんだが
(そのせいで時々画面内にゴミが残るとかなんとか)
今再現しようとするとスプライトでやったほうが簡単なのかなあ、と
サラマンダが出た時期をかんがえてみそ
いま再現するなら当時のことを考えなくてもいい気がするぞ
MSXFANにプロミネンスのとこだけのゲームあったよね
>>576 当時のアーケードは最先端という印象が。。。
それでもスプライトは無理だったんだっけ?
家庭用ゲーム機がパッツンパッツンだったのは覚えてる。
>>577 それもそうだな。
いやなんかどーにもスプライトの炎っていうと
沙羅曼蛇2の方を連想してしまって
うっかりそっちに似てしまうのが怖い。
出始め
中間
戻り
できっちりアニメ変えておけばいいのかな?
もちろん、円弧移動記述して。
>>578 > MSXFAN
テラナツカシス
>プロミネンスのとこだけのゲーム
そんなのあったんだ
質問です。
線分と円の当たり判定をどうするか教えてください。
30fpsで判定を小さくすると高速弾がすり抜けてしまうので
見たけど分からない・・・orz
まずだんごをかってこい。
円がだんごで、線がくしだ。
買ってきたよ。130円もしちまった
おいしかった
>>581 あー同じようなこと考えてる。
普通の円と円の当たり判定なんだけど、1フレームでのキャラクタの相対的な移動速度が
当たり判定サイズの合計より大きくなってしまうと、すり抜けちゃうよね?
今は、移動速度に上限をつけて対応してるけど、それでいいんだろうか?
>>585 これから解説するんだからまだ食べんな!
もっかい買ってこい。
俺の分も忘れんなよ
俺は1フレームに2、3回判定することですりぬけ回避してる
線分と円の判定知っている人教えてください。
てかだんご普通にもう食っちゃった
もういいよ!
おまえは円を画面よりでっかくしてろ
たまにおこるすり抜けくらい気にするな
>>586 速度上限が邪魔なら
単位速度設定して過去の座標何個か保持してまとめてチェック
↓
最終座標で描画or当たった座標で当たったヨ
でもイケる。イケなかったりする。
駄目かもしれない。
>>590 ごめんなさい。だんごもう一回買うから教えてください。
お願いします。
円と直線の方程式を解けばいいんでないの?
それもそうだな。
円が大きくなかったら方程式解くだけでいいのか。俺馬鹿だ
円大きくてもできるじゃんor2
大きさ関係ねえべさ
つーか矩形のがラクじゃね
線分の端点と円との内外判定と、内積つかって線分内判定と
円中心との距離求めればいーんじゃね?2Dベクトルだし直線方程式に
当てはめるより楽じゃね?
中型機の判定が円だとプレイヤー的には違和感ありそう
1:始点と終点で作られる線上にあり、円の中心との最短距離にある点を割り出す。
(この点から円の中心点に向かって引かれる線は最初の線とは90度に交わる)
2:最短距離の点の位置が、始点と終点の間にあるか調べる。
4:間にあれば、最短距離の点と円の中心点との距離と、円の直径を比較して判定。
5:間に無ければどちらの末端が円の中心に近いか調べる。
6:近い方の点と円の中心点との距離と円の直径を比較して判定。
簡単に書くだけでもこれだけややこしい判定が必要。
移動を半分にして、一回表示の間に二回移動二回判定の方が楽だな。
>>592 アドバイスありがd。
その方法なら、単位速度を最小キャラクタのサイズより小さくしておけば、すり抜けは
回避できそうですね。高速弾を出す時に使ってみたいと思います。
それって、高速にならなくね・・・?
16とか動かさないと高速に見えないし、16の当り判定ってーと・・・・
確かにここでは自分に合ったレスのみ礼を述べれば無問題だ。
604 :
586:2006/07/11(火) 01:39:50 ID:/kT9DlD/
失礼しますた。
漏れの便乗質問に対するレスは
>>588さんと
>>592さんかな?
>>588さんもレスありがとうです。
考え方は
>>592さんのと近いですよね。
>>581さんの質問「円と線の判定」関係のトピは、数学苦手なのでついてけない(´・ω・`)
>>599 キャラクタ回転させようと思ったら、円を使うのが楽なんだよーー!1!!!
>>602 速度の速いキャラクタについては、その速度を単位速度で割った回数だけ1フレーム内で判定チェック、
という感じかな。見た目的には高速になると思われ。
でも処理が面倒そう・・・寝るかOTL
いわゆる「点と直線の距離」で判定するとした場合、
距離を符号つきで考えれば良いのではないだろうか。
フレーム前後で符号が反転したら当たったとみなせそう。
○1
─────3
○2
ワンフレーム前の座標を記憶しておいて
前の座標(1)と今の座標(2)の線分とほかの線分や丸(3)が
交わるかどうかを判定すれば確実だと思うけど。
○1
○2
 ̄ ̄ ̄3
こんな場合に丸がもっと大きかったら引っかかるな。
っていうかさ、対象も判定相手も移動してるんだから、線と線で判定しないと本当はおかしいんじゃね?
もっと厳密にするなら、時間で移動する点と点での最小接近距離で計算しないといけないんじゃね?
ちょっと今、公式思いついたから計算してみる。
wktk
その1
移動している点Aと点Bについて
A始点(Xa1,Ya1)
A終点(Xa2,Ya2)
B始点(Xb1,Yb1)
B終点(Xb2,Yb2)
としておく。
Aを停止している点と考えてAから見たBの移動は
始点(Xb1-Xa1,Yb1-Ya1)
終点(Xb2-Xa2,Yb2-Ya2)
となる。
見た目が面倒なのでこれを
C始点(Xc1,Yc1)
C終点(Xc2,Yc2)
とする。
この線分Cと直角に交差し、原点A(0,0)を通る直線が最短距離なので
(中略)
A点からの距離=(Xc1*Yc2-Xc2*Yc1)/√((Xc1-Xc2)^2+(Yc1-Yc2)^2)
となる。ルートを使っているので、実際はこれを二乗して円の半径の二乗と
比べた方が計算負荷が少なくてすむ。
この場合は
A点からの距離^2=(Xc1*Yc2-Xc2*Yc1)^2/((Xc1-Xc2)^2+(Yc1-Yc2)^2)
ただしこれは交点が始点と終点の間にあるかどうかの判定はしていない。
その2
この交点を点Dとし、上の距離をADと略して
点D(X,Y)=(AD*(Xc2-Xc1)/(Yc1-Yc2),AD*(Yc1-Yc2)/(Xc2-Xc1))
が始点と終点の間にあるかを判定しないといけない。
この判定は素直に、
((Xc1>=Xd) and(Xd>=Xc2))or((Xc1<=Xd) and(Xd<=Xc2)) and
((Yc1>=Yd) and(Yd>=Yc2))or((Yc1<=Yd) and(Yd<=Yc2))
を判定すれば問題ない。
範囲外なら、始点と終点のどっちが近いかを調べる
これは簡単に絶対値の差ABS(Xc1-Xd)とABS(Xc2-Xd)で小さいほうを比べる。
ただし両方とも0なら、Y方向でチェックしておかないといけない。
そして例えば始点のほうが近ければ(Xc1^2+Yc1^2)と円の半径^2を比べればOK。
その3
ただし、これを律儀に全部計算するのは逆に重くなりそうなので。もっと簡単にして
1:終点同士での当たり判定
2:当たっていなければ線分AとBを短形でチェック
短形が重なってなければ当たってない
短形が重なっていれば3:上の距離チェック
としたほうがいいかも。
どっちにしろ厳密にすればするほど重くなる。
>移動を半分にして、一回表示の間に二回移動二回判定の方が楽だな。
先に書いたこっちの方が軽いかも。
その4(追加)
見逃しぶぶんあり。短形チェックの時に、円の半径ぶんの距離を短形に加えて範囲を
広くしておかないと、チェックミスが出る場合がある。
以上、長文駄文失礼しました。
矩形(クケイ)
短形ワロス
学級崩壊?
おや、仲間がいる。俺もつい最近まで端渓(なぜか正常に変換できない)派だ。
派、じゃねえだろ単に間違いだ
コナミ矩形派倶楽部に謝れ
ID:0jf5bSDUが出てきて一言↓
想定内
すみません真違えました。もういいです。こんな漢字かね?
あと、その2の最期。あたり藩邸のチェック字体は感嘆にできるんだから
どっちが誓いか倉部るなんてせずに、良法の天をチェックしたほうが速いな。
tumaran
矩形が読めないバカがこの世に居たんだねぇ
>619
誰も矩形「波」だろって突っ込まなくて寂しい
一瞬字面に違和感を覚えたが気づかなかったw
つーかゲームプログラミングのためのリアルタイム衝突判定を読め
で終わりな気がするな
628 :
名前は開発中のものです。:2006/07/12(水) 10:20:04 ID:mfUrl5lj
なんでこのスレの住人はくだらない誤字ばかりを気にするのか?
>>628 意味が変わるからだろ。
シナリオ:あえて間違ったものを使って「表現」と言い切る
CG:まぁいいか
音:これはこれであり
PG:誤字ってたらコンパイル通らねぇだろ!ふざけんな!
となるかどうかは知らない。
>>628 ヒント:無駄に長文書き散らしておきながらのお粗末さ。
おまいらそう無駄にギシギシするのはやめんかね
>おまいらそう無駄にギシアンするのはやめんかね
そうだな。
夏コミに出す人いる?
出すよ
おー
もう完成した?
636 :
名前は開発中のものです。:2006/07/12(水) 21:18:54 ID:GIq/4pdg
上に書いている話題とかぶるかもしれないのですが
STGにおいて当たり判定の形で 丸と四角を同時に使うことができるんですか?
持っている、STGの本だとどれも当たり判定が四角ののみなので、やり方を教えていただけませんか?
後、STGにおいて、特殊な形の当たり判定って四角を組み合わせてつくっているんですか?
基本は四角。
ドットは四角だからな
四角も円も、動かし方で見た目と判定にずれが出るよね。
見た目と判定を一致させる方法とか、実際にそうしてる作品とかある?
動かし方でずれるってのがよく判らない
>>636 四角が回転することがない軸並行なものならば、円の中心をcx, cy、半径をr、
四角をleft, top, right, bottomで表現すると
int d=0;
if (cx < left) d += (left - cx) * (left - cx);
else if (cx > right) d += (cx - right) * (cx - right);
if (cy < top) d += (top - cy) * (top - cy);
else if (cy > bottom) d += (cy - bottom) * (cy - bottom);
if (d < r * r) { 交差している }
else { 交差していない }
たしかGemsだかに載ってた言葉を借りると、
ユーザーは別に当たり判定の正確さを求めてるわけではない
ってのがあって、それは正論なんで完璧に取る必要はないとは思うけど、
でも当たりが正確だとヒットエフェクトとか出た時に気持ちいいんだよなぁ。
>>636 >STGにおいて当たり判定の形で 丸と四角を同時に使うことができるんですか?
まず、ヒットデータを、このデータは○です、このデータは□です、
データの実体はこのポインタです、全部で何個あります、みたいな構造にして
○と○のヒットチェック、○と□のヒットチェック、□と□のヒットチェック
にそれぞれ飛ばせばおk
>STGにおいて、特殊な形の当たり判定って四角を組み合わせてつくっているんですか
多角形のヒットを実装すればおk
丸い敵がそのまま丸だったり、複雑な形しているのが見た目
そのままだったりするとプレイヤーは激突しそうだが。
多少は重なっても大丈夫っていう認識が出来上がっちゃってるからな
まあ最近のシューティングっぽく作るなら、近づいて撃ちこんだりしないだろうから
平気だとは思うけどね。どっちにしても判定なんか単純な図形で問題ない。
多角形の当たり判定使ってる。
今のCPUなら1000個くらいのオブジェクト出ても、上手いことやれば問題ないよ。
まぁ円は矩形の組み合わせでもいいけどな。
□□┌──┐□□
□┌┼──┼┐□
┌┼┼──┼┼┐
│││□□│││
└┼┼──┼┼┘
□└┼──┼┘□
□□└──┘□□
実際、俺は16bitマシンの頃はこれでやってた。
つか今もこれでやってるw
矩形の配列や矩形のリストでもつのはまず基本だと思う
ここからがスタート地点
さらに進めて矩形というのをシェイプとかにして判定部分を矩形だろうが円だろうが意識させないで独立させるのが常識
円でやってたときは
ルートとらないで計算したり
二乗テーブル用意したりしてたなw
本当にしっかりとりたかったら
ツートンカラーの裏画面をつくって、ドット単位で■アタリ/□ハズレでチェックするといいお。
>>652 それだといくらでも自由にできるよね。
などといいつつ、実際にそれ試したやついるのかな?
満足できたのかどうか。
なぁに、bool型にデータぶち込んで座標適応させてifで判定するのをループさせれば良いだけだからな。
はふへほへ。
自機とそれ以外なら簡単そうだけど、全てのキャラクタ相互の
判定をしようとしたら面倒そう。
妙に判定を細かくやりたがる奴って、
格ゲー作るとしてもそんな風に判定作るんだろうか。
作ってる間の触感が楽しいんだよ。ただし、これにハマるとまるで
無限ループにハマったかのように、永遠に抜け出せなくなる恐れが・・・orz
細かく判定できるようにすると、ゲームとしては細かく作れるようになる。
しかし、全く別のゲームを作ってる気分になる。
つ〜か、バランス調整で経験則が効かなくなる。
結果的に、マニアックで分かりにくいゲームが完成する。wwwwwwww
orz
ロボット物横STGの自機やられ判定は本当に難しいな。
ゲージ制にして自機と同じ高さの縦線1本かもう少し太い位が結局一番なのか。
四角いロボットにすればいいじゃん?
四角いロボットって、東亜プランの敵みたいやな
アトミックロボキッドだな。きっと。
>>649 円で判定した方が早いし簡単なのに、なんでこんなことを?
>>664 乗算が今とは比べ物にならないほど遅かったのと、円以外の複雑な形状にも対応出来るから。凹とか。
今もこれでやってるのは単なる惰性。
矩形メインの場合、円を組み込もうとすると頭いたくなる・・・
nullpo
こういう話題ってこのスレ向きだよね。
偉そうに「これはこうだ」と言い放つ奴も来ないし、
個人が培ったノウハウを交換しあってるのが嬉しい。
横長の矩形キャラクタを回転させたい場合とかどうしてますか?
ふとバキュラに思いを馳せる
回転軸が違うってのw
そして詐欺判定。
OBBでぐぐれ
回転なんか使うな
8x16程度なら、8x8の正方形の判定を中央に置くという手抜きをしても
案外違和感が無い。
>>666 特殊な条件下なら円と頂点の内包判定4回で代用できるっしょ。
これなら簡単。
円の直径より大きい矩形があると途端に駄目になるが
円判定なんてどうせ、巨大ボムと隕石くらいでしか使わんだろ。
一番簡単なのは、矩形を円の半径だけ外側に押し出した矩形に
円の中心が含まれているか判定するやつだと思うな。
四隅で判定の精度が落ちるけど、通常はあまり問題にならないし。
ロバストな方法では、
>>642が一番計算回数が少なくて済む。
このスレでやってる限り
シューティングに厳密なヒット判定は不要
という結論にしかならんなぁ
逆に考えるんだ
厳密なヒット判定が必要な時ってどんな時?
ゆっくり当るとき。
スロー実装したゲーム作ってるけど、確かに衝突判定が見た目と少しでも違うとかなり違和感がある。
俺の作ってるゲーム弾もキャラも全て矩形ベースだから無問題だがな。
>>682 不要だし、やるべきじゃないとも言える。
ちょっと待て。「厳密な判定したいんだけど…」といわれれば、
厳密な判定のやり方を議論すればいい話であって、
厳密な判定が不要なんて意見は論外じゃないか?
技 術 板 の 技 術 ス レ な ん だ か ら!!!
じゃあ議論しろよ
自機敵機地形弾をポリゴンでモデリングしておき、ポリゴンvsポリゴンで判定すれば無問題。
さて、次のお題どうぞw
ヒット判定よりテクスチャよくした方がいいかな・・・
エスプガルーダとかスローあるよね。
あれって当たりは細かくとってるのかな?
細いも何も
自機の判定サイズ自体が既にゑと違う
よね?
>691
細いってなんだよ
>690
よく見てないけど60FPSを30FPSにしてるだけじゃないのか?
眼科に行くんだな
>>693 こまかい→細い
EGBridgeだが
リアル辞書引いたら送りがな間違ってるな…
こまかい 細かい
こんなときに限ってことえりの方が正解だった('A`)
辞書に頼らないと細かいの送り仮名が分からないって、よほどの低脳だな
EGBridge!
9の頃使ってたな…
いやさ、矩形とか細かいとか、なんで本題よりそっちの方に話が行くわけ?
本題が大した話じゃないから
ヽ(´ー`)ノ イッチャッタ、イッチャッタ
本題を語れる頭じゃないから
というか今言ってる本題って何?
ほら、バカがキタ
>>704 バカっていうほうがバカなんだぜ
っていうのは置いておくとして、今の本題ってあたり判定でしょ?
矩形とか細かいとか、って本題からずれた話か?
って疑問だったから本題を何か確認させて欲しかったんだが。
>>706 せっかく置いてくれたのに
バカはやっぱりバカだな
於くもんだというツッコミでなくて?
うるせバーカw
いつまでもシューティングの話なんかしてんじゃねえよ
Σ(゚Д゚;エーッ!
/\___/\
/ / ヽ ::: \
| (●), 、(●)、 | / ̄ ̄ ̄ ̄ ̄ ̄ ̄
| ,,ノ(、_, )ヽ、,, | < まーた始まった
| ,;‐=‐ヽ .:::::| \_______
\ `ニニ´ .:::/
/`ー‐--‐‐―´´\
股始まった?
1秒間に平均40回もsqrt関数を呼び出すのってユーザーに優しくないですよね?
40回じゃねーようんこ!!!
240回だ!!!
なんでユーザー?
60fpsだとすると1フレーム3回?
何故にそんな半端な回数?
たしかにユーザーとしては毎回sqrt計算したくないな
テーブル参照なら楽だけど
>>713 あなたが考えているほどsqrtは手厳しくありません
距離を比較するために使っているだけなら、二乗して√を取っ払ってくださいな
>713
大昔の整数演算しか出来ないマシンでもないのなら、
数万回使っても大した負荷じゃない。
なんかよく距離比較の二乗を気にする人とかって多いな。
当たりだけ見たいならともかく、座標とか諸々後で欲しくなることがあるので
俺はキッチリsqrtかけて距離返すようにしてる。
それ自体が重いって実感したことはないな。
1フレームに4回程度なら全然気にすることはないと思う。
動かしてスローかからないならオッケー
というのは大雑把すぎるのか?
そんなもんだろ
2Dシューで取るべき精度なんてたかが知れてるから、
精度を犠牲にして速度重視の自前sqrt関数作ればいい。
725じゃないけど、テイラー展開とかすればいいんじゃないかな
むしろ2Dで速度重視なんぞ今時必要ない気が。
>>728みたいな奴がいるから書き込みが止まるんだよな〜
最近は遅い弾幕が流行だからね〜
と言いつつ自分で取る
ループは100,000,000回
InvSqrt : 239ms
fastsqrt : 239ms
sqrtf : 241ms
sqrt : 10024ms
・・・sqrtf頑張ってるなぁ・・・
つかコンパイラとコンパイラオプションは?
うちの環境(VC2005)だと、Debug/Releaseどちらの場合にも
sqrt/sqrtfはほとんど同じコードに展開されて差がほとんど出なかったんだが
速度が必要な環境でsqrtなんて2DSTGでほとんどつかわんだろ
まあ描画以外の部分なんて相当無茶してもFPS落ちないしな
>>736 これが真実だと思うんだよ。
素人は速度に拘ってるフリがしたいので、
目に付いたところをまっさきに拘り、
誰に何ていわれようとも拘りつづける。
プロは全体を見渡してボトルネックになってるところを、
落ち着いて発見することができる。
そしてそこに対して適切な最適化を施す。
最適化のつもりでセコイ頑張りをみせてると、
全体的な構造のしなやかさを失っていたりして、
結果として、あとからアルゴリズムを交換したり、
大胆な最適化を行ったりを妨げることになったり。
おっと、俺は知ったかで言っているんで、
そこんとこに突っ込むのはナシな。
俺はヘタレ素人知ったか君だからな。
O(n!)やO(n^2)になってるアルゴリズムところから改善すりゃーいいのさ
どうも知ったか君です。
あと、プロファイラを使わなかったり、
速度の実測すらしてねぇやつが、
最適化とか速度とか言うのはズレてるかと。
ごめんなさい、知ったか君でした。
プロファイラって何?
ドラマでプロファイリングってのは知ってるけど
>>739 いわゆる80:20の法則ってやつだな
まぁその通りなんだが、
VC++な環境だとプロファイラは基本有料なんだよなぁ
そのへんが実測しないで小手先の最適化をやりたがる文化の温床になってる予感
俺プロファイラ持ってないから、どこが遅いかはアルゴリズムを考える時点で頭に入れてる。
かなり不便。
>736
しかし描画を速くするテクニックなんてそうそう無いと思うのだが。
グラボかえrうわなにすwでfrgthyじゅjきぉ
>>733 Athlon雷鳥 1.2GHz
>>734 gcc 3.4.6 -O3
sqrt/sqrtfは展開せずにcallされてる
雷鳥なつかすぃ
>>743 「描かなきゃ最速」ってピコーンひらめいた
…ってよく考えたらリアルサウンドで先越されてたな
描かなきゃ最速ってのは実際そうだから困るw
ユーザにはメモリ内の電圧を肌で感じてもらうとして
弾幕をアナウンスしてもらう。
「左舷、弾幕薄いぞ!何やってん の!」
つぎはプレイヤーの操作速度がボトムネックになる
ボトムネックとは何ぞや
ぐぐれドアホ
首が下についてんのか?
ボトムネック の検索結果のうち 日本語のページ 約 1,190 件
ボトルネック の検索結果のうち 日本語のページ 約 1,310,000 件
かっこいいな753
よくいわれる
お前のあだ名は今日からボトムネック
なんとなく包茎手術の広告を思い出した
よし!俺は今日からボトムネックだ!!
よし!俺も今日からボトムネックだ!!
じゃあ俺が兄だな!!
よろしくな! 双子の弟よ!!
ほほう
つまらん。
敵の出し方とかどうしてる?全部タイムテーブル?
本物のボトムネックが来たか(;;'-')ゴクリ
まぁ、俺の場合はインタプリタ書くの面倒くさいから、普通にソースコードに生で書いてるな。
でもこれはこれで柔軟性があって良いぜ。
敵を連続で幾何学的に大量発生させたい時とかね。
>>764 ランダムですね。
ステージごとに固定のシードを使って、
それをもとに敵を出現させてる。
>>764 tick指定で特定時間にスクリプト走らせてる
さすがに数値指定だと背景と合わせるのはメンドイから
適当なエディタも作ったけど
>>767 いつの間に弟に!
RPG用のマップエディタで背景作ってるから、マップ直に配置してる。
>>770 そこは三男でしょw
しかしみんな色々な方法でやってるなぁ。
もっと奇抜な意見も出てくるかもしれん( ´ー`)y─┛~~
ぶwwww
ファミコン版のスターフォースって、
一個のグループを全滅させたら次のグループが出てくる、
っていうやりかただっけ。
◆←こいつから逃げてるだけでボスまで敵出なかったような気が。
ラリオス誘導でジムダステギとかゴーデスとかやったな
ファミコン版に限らん気が
地上物も撃たなければボスも出てこない
質問です
自機が動き始めの数フレームはゆっくり動いて
いきなり最高速にならない方がいいようですが
今まで動いていた自機が方向を変えるときも少し減速したほうがいいですか?
分かりにくい文章ですみません
慣性つけるってことか?
まあやめとけw
慣性と言っても普通のゲームにもある程度のほんの少しだけです
やってみればいいだろ
>>777 こいつ移動量をx軸とy軸で分離してそうwww
素直にラジアン使っちゃいなよ。
>>777 ゲーム作る前に日本語勉強したほうが良くないか?
分かりにくいっつーよりかなり変だぞ?
っつーか「分かりにくい文章ですみません」とか
エクスキューズ宣言するくらいなら
最初から書き込む前に推敲しろと
要は、どんなゲームを作るか、だと思うよ
スーパーマリオが等速で左右にクイクイと動いたら変だと思うが
ごくフツーのシューティングなら等速で動いても変じゃないし
加速減速やりたいなら、やればいいじゃない
784 :
777:2006/07/22(土) 23:54:16 ID:5C0acDV7
自己解決しました
低いFPSの割に早い動きをしていたので
不自然になっていただけでした
>>782 ごめんなさい。うまい言い方が見つからなくて分かりにくくなってしまいました。
推敲のとき同じ単語続かないようにと
文頭の「自機は」を取ったのが失敗した
自機が加減速するシューティングなんてほとんど知らないぞ?
あーもしかして2Dじゃないのか。
お前がシューティングを知らないだけ
787 :
名前は開発中のものです。:2006/07/23(日) 13:29:26 ID:jvVd+Z4Y
挑発しないで例くらい挙げてくれよ
エクセリオンみたいなのってことだろ?
挙げたらタイトルの羅列で次スレまで埋まるから自分で調べろカス
2Dシューティングでなら、そんなに無い
挙げたら次スレまで埋まるとか、実際に数えもしないで語るな
シューティングってもう新しいシステム考えるの難しいな
カスリ、誘爆、育成?は既にあるし
>>785 自機が動きだしてからほんの少しの間
動きが遅くなるのは殆どのゲームがやってる
ほんの少しの間だけどね。
それやってるとチョコマカ動きが楽
具体的にタイトル挙げてよ
検証してみるから
794 :
名前は開発中のものです。:2006/07/23(日) 16:42:46 ID:jvVd+Z4Y
シューティングなんだけどアーマードコアみたいなのをやってみたいな
ドッグファイトでこつこつのし上がっていく感じのやつ
プレイヤーも自機も一緒に強くなって行く感じをまったり楽しみたい
しつこいといわれてもなあw
2Dでやってるのなんかホントにあるのか?
ケイブシューとかやってるようには見えない。
間違った知識で偉そうなことをいう恥ずかしい人がいるようですが
ほとんどのシューティングはそんなことやってません。
あしからず。
>>792 まじで? ほとんどのゲームが??
ちょっと具体例あげてみてよ。
というか、ほとんどのゲームがやってるってことは、
やってないゲームをあげるのでもいいけど。
つうか、ほとんどのシューティングが加減速しないからなんなんだろう?
ほとんどのシューティングが課原則しないから、俺もしないという思考停止?
ものすごい議論のすり替えを見た
はぁ?これが議論のすり替えなら、そもそも785も議論のすり替えだろアホか。
うわぁ(;´Д`)
ほとんどのシューティングがやってるの知らんのかアホ
↓
具体例だせよ
↓
ほとんどのシューティングがやってないからお前もやらないのか
支離滅裂ですな。
間違い認めろよ見苦しいな。
夏真っ盛り( ´ー`)y─┛~~
>>803 ボケかお前。俺は785にレスしてんだボケ。
それまでの流れで話せ糞が
//\⌒ヽペペペタタン
// /⌒)ノ ペペタタタン
∧∧_∧∧ \ ((∧∧_∧∧
((; ´ДД`)))' ))((・∀∀・ ;)) <みみみんなももちつつけけ
// ⌒ノノ ( ⌒ヽ⊂⊂⌒ヽ
.((OO ノ )) ̄ ̄ ̄()__ )))
))_)_)) (;;;;;;;;;;;;;;;;;;;)(((_((
オレモナー
>>792さんは落ち着いて、具体例を出せばいいんだ。
全方位シューティング作ってる奴いる?
移動も全方位だから慣性バリバリで加減速する方が
カッコいいかなと思ってやってみたんだけど、邪道?
>>805 バカはお前だ
やってるの見たことないから(気づいた事無い)から
教えてくれって785言ってんだろ
お前日本人か?
>>785 俺の見たのはHSP制の縦シューで二つぐらいあった気がする
でも、操作感は微妙だった気がする・・・
なに!?兄貴も作ってたのか。
俺はバンゲリングベイみたいなの作ってるから、加速度で管理してるよ。
ヘリだし。
俺は面倒くさいから加速度をx軸とy軸で分離してるな。
if(myshipX>targetX){ accX-=accAddVal; }
見たいな感じで。
人の事言えねぇww
普通はLOSアルゴリズムとかで移動値求めてそれに加速度を掛けるんだろうな・・・。
夏厨だったのか
普通に質問して損したw
>>810 そろそろコテはずせや
段々ウザくなってくるから
レイストームって自機の移動に微妙に慣性がついてなかったっけ?
動きだしに限らず、停止時もすぐにぴたっと止まらなかったような気が。
記憶違いだったらスマン。
815 名前:兄 ◆As7TgzECyo [sage] 投稿日:2006/07/23(日) 20:23:20 ID:FPkaCEoE
>>813 黙れカス ^^
おまえの方がうぜぇ。つまらん雑談すんな。
正直コテそのものより
>>809や
>>813の展開がウザイ。
けどその展開が始まる原因はコテだからやっぱりコテもウザイ。
>>815 うぜええええええええええええええええええ
なんでこんなに興奮しやすい連中ばっかりなんだ?
夏だから
やっぱり?
このスレはいつも他のスレよりもヒドイような気がする。
そりゃ、厨が一番最初に始めるプログラムはSTGだからさ。
はははは ^^
ID:NK0ksf9Rもウザ
いいからほっとけよ
う〜ん、スルーして話を変えたいところだが、
今テスト週間で物理の勉強が大変でそれどころじゃないから、
しばらく戯れててください。
//\⌒ヽペペペタタン
// /⌒)ノ ペペタタタン
∧∧_∧∧ \ ((∧∧_∧∧
((; ´ДД`)))' ))((・∀∀・ ;)) <みみみんなももちつつけけ
// ⌒ノノ ( ⌒ヽ⊂⊂⌒ヽ
.((OO ノ )) ̄ ̄ ̄()__ )))
))_)_)) (;;;;;;;;;;;;;;;;;;;)(((_((
オレモナー
>>792さんは落ち着いて、具体例を出せばいいんだ。
751 :名前は開発中のものです。:2006/07/18(火) 22:25:54 ID:b8S8ySMX
つぎはプレイヤーの操作速度がボトムネックになる
752 :名前は開発中のものです。:2006/07/18(火) 22:28:26 ID:uZCBYvsL
ボトムネックとは何ぞや
753 :名前は開発中のものです。:2006/07/18(火) 22:38:24 ID:FBBE+JVu
ぐぐれドアホ
--------------------
785 :名前は開発中のものです。:2006/07/23(日) 03:38:07 ID:87sit9HE
自機が加減速するシューティングなんてほとんど知らないぞ?
あーもしかして2Dじゃないのか。
786 :名前は開発中のものです。:2006/07/23(日) 12:14:46 ID:QKkNlc0C
お前がシューティングを知らないだけ
788 :名前は開発中のものです。:2006/07/23(日) 13:34:08 ID:87sit9HE
挑発しないで例くらい挙げてくれよ
エクセリオンみたいなのってことだろ?
789 :名前は開発中のものです。:2006/07/23(日) 13:36:36 ID:OFwki4dk
挙げたらタイトルの羅列で次スレまで埋まるから自分で調べろカス
--------------------
流れが一緒
いわゆる犬の卒倒だな
それで?
ボトムネックはギャグで言ってるんじゃなかったのか
840 :
名前は開発中のものです。:2006/07/24(月) 01:26:35 ID:bw8k3fR9
Cマガの2002年の8月号で「ゲームプログラミング基礎」って特集組まれててさ、自分でゲーム作りたくなったよ。
デジカメなんか作ったりしてる人なので画像処理系はなんとかなるんだけど、
Windowsでゲーム作ろうと思ったら色々ハードルが高い・・・
>>840 ハードルが高いと思ってしまうんなら、DXライブラリとかみたいなラッパーライブラリ使ってみ
それともハードルって素材のことだったりせんよね?
842 :
名前は開発中のものです。:2006/07/24(月) 01:36:37 ID:bw8k3fR9
>>841 いえいえ、デバイスコンテキストを取得してなんか書いて
更新という流れをまだに理解出来てないだけなのですよ。
昔ながらのLCDに直転送してる人間には抽象化されてしまうと
使い方を覚えるのにも一苦労ですよね。って話です。
素材に関してはシステムを作ってからでなんとかなると
考えてるので今はそこまで気にしてません。
ぶっちゃけ、自機は■敵は○でもあとから絵を載せればいいと考えてます。
>ぶっちゃけ、自機は■敵は○でもあとから絵を載せればいいと考えてます。
ダミー素材でゲームを作るとどうしてもテンションが落ちてしまう自分には、
そう考えられるのって偉いよなあとつくづく思う。
ふざけるな ○が自機で ■が敵機 これ以外認めません。
自機は△ 敵は▽でどうでそうか?
846 :
名前は開発中のものです。:2006/07/24(月) 02:05:03 ID:bw8k3fR9
>>843 システムさえ作り上げてしまえば、あとは絵を変えるだけで何本もソフトをリリース出来るではないか!
と考えてしまう自分は多分大切な何かが腐りきってるんだと思います。
>>844 それじゃ、自機は○敵は■にしましょっか。
自機は(^o^)で敵は(^w^)にしろ
848 :
名前は開発中のものです。:2006/07/24(月) 02:09:18 ID:bw8k3fR9
>>845 >>847 OKOK.
それじゃ、自機と敵機のシンボルをコンパイルフラグで決められるようにしましょうね。
((△))悪いがバリアは括弧以外認めない。
弾はもちろん、U ←これな。
じゃあ今月いっぱい、もしくはこのスレいっぱいで祭な
自機
○ □ △ (^o^)
敵
■ ▽ (^w^)
バリア
(( ))
弾
U
敵の撃つ弾は ・ でよろしく。
ポケコンで作ったなぁ。 そういうの。
キャラ画像のネタが切れたら
ミニ四駆のデザイン適当にパクるといいよ
>>855 オマエのツラも目の辺りリアウイング参考にしてるもんな
意味ワカラン
858 :
名前は開発中のものです。:2006/07/24(月) 22:17:04 ID:boNSgTa2
夏なせいか、非生産的傾向が出てきたなww
スレタイ読めないアホが多すぎ
あと殆どがやってるやってないとか知ったか話すんな。
どんだけ世の中にシューティングがあるかも知らんくせに。
俺もだが(とりあえず俺は加減速値を取るシューティングはやったことないな)
で、技術的な話。
配列使ったチップじゃない一枚絵の背景を使ってる場合、どうやって自然に切り替えてる?
ボス戦闘後に真っ暗背景にして、次ステージで切り替え?
それとも繋ぎ用画像作ってる?
859 :
名前は開発中のものです。:2006/07/24(月) 22:18:25 ID:boNSgTa2
ってすげー遅レスな俺ww
暗転させてる
そのままつなげる。
不自然だろうが背景の境目が見えようが知ったこっちゃない。
そんなの好みで良いと思うが…
ボスの背景真っ暗にすれば
切り替えとか考えなくても済むよ!
モーフィン具で自然に
ぐが大きい
ボス倒すと同時に雲消して、次の面の背景
海が真ん中で裂けて次の面へ降下
ワープっぽいエフェクト
おにゃのこの一枚絵出して誤魔化す。
↓これ出して誤魔化す。
STAGE 1-2
○×3
マリオかよ
スポンサーに映像貰ってそれを流す。
サブリミナルも忘れずに。
ボトムネック
何気に面白い話題だな。
シューティングを知らないバカの話題だから面白くないね
このスレの住人ってこんなんばっかなのか(;´∀`)
ネタだけじゃなくて実物も挙げろよくださいクズ様
>>879 実物て…
お前がくださいクズ様じゃねぇかww
シャッターが締まって得点計算に・・・ってそりゃドドンパチ
883 :
名前は開発中のものです。:2006/07/25(火) 23:57:31 ID:ZZNvfgd+
>>879 シューティング製作は某ときめも社の新人教育時の課題レベルですよ。
あまり難しくないっていうか作るの自体は描画更新と操作系が判れば、
作れるくらい簡単だから自分で作ってみなさいな。
でも作るのは確かに簡単だけど、ただしそれが面白いかと言われたら面白くない。
囲碁のようにシンプルなゲームなだけに、面白くする工夫が難しい。
奥が深いよねぇ。
×奥が深い
○ネタが既に出尽くして枯れている
それだけに素人でも勝負できる部分がある。
東方みたいに上手くコンセプトをつければヒットさせることもできる。
そ う で す ね
あれもあれだけウケているのは素直に凄いと思う。
二匹目のドジョウを狙いたいので、ヒットの要因を簡潔に分析きぼん。
東方って万単位で売れてるわけじゃないだろ
業務用、家庭用ヒットに比べればたいしたことはない
>888
弾幕シューとしての目新しさは無い
作者の、オタクの方向しか向いていない姿勢がオタクを呼び寄せただけでは
まぁそういった開拓の余地があるってことだ。
万単位で売れてるとは思うが
業務用、家庭用ヒットに比べればたいしたことはないのは当たり前
1めんボスのつくりかたがわかりません><
かんたんにしたいけどつよくしたいです!
スルーで。
しかし単なるキャラゲーなら他にもあるだろうに、東方だけ突出してる人気がある感があるのはなぜだろう。
(突出していい作品、とは言わん。)
ボスの攻撃に命名w以外の理由としては、やはりシリーズ物としての歴史の重みかな?
東方がSTGだけに留まっていたらあそこまで大きくなってない
確かに土壌となったものはSTGのコアな部分ではあるが、
二次創作で色々なジャンルのゲームが出て
多様性が出てきた辺りから急激に加速した。
格ゲーが出たのがかなりの好タイミングでこれが決定打になっている。
加えて「商業ベース」の副読資料設定的小説のようなもの。
大小さまざまな細かい加速の積み重ねによって
あそこまで到達しているからなかなか真似できるもんじゃないね。
STGをやめたときから今の東方は始まった、とも言える。
世界観とかキャラ設定だけで楽しめる人もいるし
いろんな意味で間口がひろいのが強み。
あと昔のような高速弾はコツが判るまで手も足も出ないが
低速弾幕は慣れて無くてもなんとなく避けられちゃうというのも
間口の広さに一役買っている。
結局のところ根幹部分がゲームとして成立する程度にマトモなら
後は外堀の勝負だから。
キャラがウケたってのもあるし、曲がウケたってのもある。
また、某大手同人サークル主宰者が取り上げたり
2chの口コミでギャっと広がった事も大きかろう。
版権物格ゲーやノベルゲーの全盛期に
非エロでオリジナルキャラのSTGなんて死亡ジャンルで参入したのも却って好影響か。
そーいう周辺部分もある意味STG製作技術、と言えなくも無いか…
このスレの住人が結集して総力上げれば、東方以上に凄いの作れるかもw
すごいの基準はよくわからんけど、あれを超える人気は現状はむずかしいぞw
技術やらアイデアの話ならシューティングなぞたかが知れているし。
世界観とキャラ設定ってこと?
そんな単純な話で済むんならみんな売れまくりで大成功だな
無名のころからある程度のクオリティでコンスタントに作品を発表していったことも大きいと思う。
ヲタは青田買いが好きだからw
>897
>住人が結集して総力上げる
天文学的な幸運に恵まれない限り無理。
凄いの作ったりしたらそれは宇宙の奇跡。
MSX時代から完成しないのだから無理
2chで成功する確立より宝くじで当選して
成功する確立のがはるかに高い
宝くじより架空請求で成功する確立の方が遥かに高い
冗談でもそゆこと言うのやめれ。
2ちゃんでのコラボの成功例ってーとやっぱUNIX板のあれかね。
>>905 ゴミ野郎のゲスな発想は救いようがないな
ボトムネックだからな
口も頭も悪い
ボトムネックて何?
蒸し返すのやめれ。
コラボが無理なら、上にあったAAネタじゃないが、夏祭りでもやらね?
夏祭りの前に質問を一つ.
ゲームに使う関数は,全部ローカル関数にすべきなんでしょうか?
グローバル関数にしておいた方が楽そうなのですが,プログラムの本(独習C)には,
「グローバル関数・変数は無駄なメモリ喰うからヤメレ」と書いてあったもので.
>>911が夏祭り開始のサインだ罠w
全部とは言わないが極力ローカルにすべき。
ってかシューティング関係ないな。
Cでグローバル関数なしでプログラム書けなくないか?
ソースが1ファイルにまとまってるならともかく。
じゃあ1ファイルで作れ
915 :
911:2006/07/27(木) 23:07:43 ID:XO7PMEit
やっぱりローカルにしておいた方が良さそうですね.
その場合,クラス・関数をどうやって配置するのがいいんでしょう?
ゲーム全体を管理するクラスを作り,その中にキャラ表示とか当たり判定など
のクラス・関数を入れる,でいいんでしょうか?
メモリなんか無駄に使ってもたいしたことないよ
個人的には可読性と拡張性を重視したほうがいいと思う。
という点で全部グローバルってのもどうだろうと思うけど、
分かりやすく出来てるんならいいんじゃない。とも。
918 :
名前は開発中のものです。:2006/07/28(金) 01:41:58 ID:ON6FbzLq
>>911 あ。どうでも良いことなので聞き流して頂きたいのですが、
ローカル変数(ここではauto変数って意味で聞いてください)はスタック領域を使いますので、
ローカル変数の方が良いと言って、バカみたいに宣言しまくると、
スタックオーバーランする可能性がありますし、可読性を落としてしまう危険性も含んでます。
なにごともほどほどで。
大雑把に分けると
関数内部で完結できる数値はローカル
関数同士でやりとりする数値はグローバル
これでいいわな
お邪魔します。現在HSPでシューティングゲームを作ろうとしているのですが、
敵キャラに複雑な弾幕を撃たせようと考えているのでBulletMLを使おうと思っています。
一応BulletMLの仕様は理解して、「白い弾幕くん」で弾幕を動かすことができるようになりました。
が、その際に作った弾幕のファイルを、どのようにしてゲーム(HSP)で動作させるのかが
分かりません。
どうかご教授願います。
自分で解読するしかないんじゃない?
STG製作夏祭りイイ(´∀`)ノ
「花火」がお題とかどう?
花火というと東方になってしまいそうだが・・・
弾幕ばっかりになりそうだな
>>920 BulletMLを読み込み「文法を解析してその通りに動く」プログラムを自分で書くしかない。
C++やDだったら↑の括弧の部分を実装したlibBulletMLがあるがHSPには今のところ
そのようなライブラリやDLLが無いため。作れば神になれるよw
打ち上げ花火は見に行かなくなったなー
どうしても目が回避ルートを探してすげー疲れるから
>>921 じゃあ、玉はサイン関数でにょろにょろしてランダム時間で爆発だな。
爆発は形がいろいろあるね円形とハートなど
2種類じゃん
ナイアガラのように、怒涛の如く押し寄せる弾、弾、弾
普通
最近は星型、ニコちゃんマーク、キティちゃんとかドラえもんとかあるよ。
分裂して更に加速したり、精子みたいに泳いだり。
精子、つまりR-TYPEみたいのを作るということだな?
コンピュータシミュレーションが導入されてから
花火もすごい進化してるらしいな
935 :
920:2006/07/30(日) 00:22:04 ID:QTYk6WOv
アドバイスありがとうございました。
当面はHSPの標準命令だけで何とかしてみようと思います。
花火大会行ってきたよー。回避ルートは全然考えなかったけど、
「あ、これ弾幕パターンにしたら面白いかも」とかは考えてしまった。
精子みたいに泳ぐヤツ、ホーミングミサイルの出だしみたいだって言ったら、
彼女に引かれた…。
精子みたい、なら引かれないのか?
卵子見たいって言ってやれよ
じゃあ、精子が卵子にたどりつくシューティングということで。
それって斑鳩だね
R-TYPEかと思った
東京は立川の花火大会いてきた。
板野サーカスみたいな花火があって吹いた。
俺はケーブルテレビでその模様を見ていた。
おれはテレビ東京
2ちゃんのオフで見に行ったw
946 :
名前は開発中のものです。:2006/07/31(月) 22:17:18 ID:4A+XaW5s
いつも気になってたんだけど、このスレって技術スレだよね?
技術スレだけど、(煽りをスルーする)技術がないの。
スルーする以外の技術も無いですよ
ある程度のノリも必要だよ。
3Dで2Dシューティングを作る場合、通常の地上空中で撃ち分けが無い当たり判定ってどうやればいい?
大真面目に判定するとアンダーディフィートとかレイシリーズみたいになってしまう。
雷電IIIとかが理想なんだけど、方法が分からん・・・。orz
ん?
スクリーン座標で判定すればいいだけじゃないの?
スクリーン座標上で何をどう判定すればいいのかが分からないんだ。
オブジェクトの深度によってサイズも変わるし、カメラの角度によって判定の形も変わってくるから・・・。
グラディウスや虫姫3面みたいな
スクロール方向が可変のステージの背景マップ情報って、
どうやって表現すればいい?
一方向だったら簡単なんだけど。
アクションゲームと一緒だぞ
マップを大きめに作っておけ
>>952 サイズは計算で出せるし、形なんか矩形でいいだろ。
>>956-957 なるほど。射影変換をしないとパースが付かなくなるんだっけ?
そして矩形で計算か。なんとかなりそうな気がしてきた。ありがと。
射影変換しないっていうのは正射影でレンダするって意味?
>>959 やってる最中に気付いたよ・・・。寝ぼけてるようだ。
結果がレンダリングと合ってないと意味ナインだった。
やっぱ射影変換して矩形か球かのサイズは自力で算出しないとだめか。
>>921を見て何となく作ってみました。
http://gamdev.org/up/img/6905.zip ステージ構成のものを作りたかったんですけど、時間がかかりそうだったので、
スコアだけを競うミニゲーム的なものになりました。
気が向いたら遊んでみてください。
STG作るのは初めてで、難易度調整に苦労してるので、
遊んでくれた方はスコアを教えていただけると幸い。
ちなみに私は
Normal〜16000、Hard〜10000
程度しか取れません。
>>961 イイ(・∀・)!花火っぽい!w
ノーマルで平均7〜8000点くらいだった。
玉が増えてくるとぱにくりますw
ショットで玉を上部に押しやる事ができるといいな、とか思った。
>>961 ノーマルで11469点しかいかないorz
画面端で反射するので、こっちも画面端に近い位置に張り付いてひたすらショット、
低速移動でちまちま避ける、みたいなチキンプレイ。
>>962氏の、ショットで弾を上に押しやるというアイデアが面白そう。
>>961 俺はNoemalで何とか一万点に届くぐらい。
自機ショットの速度が少し遅めなのが気になるかも。
>960
判定用に1枚板のポリゴンを用意して、それの頂点をスクリーン座標に
変換して、判定したら?
http://gamdev.org/up/img/6914.lzh 3Dで2Dシューのサンプル
ソースはなし(まぁ、HSPだしw)
敵のどの部分を判定に使うか
自分より奥にいる敵は3DY座標を真ん中じゃなく敵の上部を使う
自分より手前に居る敵はそのまま中心の座標を使う
敵の3D座標に大きさ分x,z(yは上で決めた座標)を足した座標を
スクリーン座標に変えて、敵の中心座標(これもYは上で決めたY座標)も
スクリーン座標にしてやってる
この二つの座標の差分を判定範囲として使う
こんな感じ
実際には回転も考慮してるから、判定は回転する矩形と点でやってる
>>962 >>玉を上部に押しやる
面白いアイディアですね。
試してみようかな。
>>963 丸玉は少しばかり自機狙いになってるので動いた方が安全かも。
>>964 今度は速くしてみます。
皆さんプレイしてくれてありがとうございました。
967 :
950:2006/08/03(木) 22:50:15 ID:LE8eDZEp
・・・三次元空間での球をスクリーン座標上での円に変換して判定することにしたんですが、
その半径の算出方法を聞いてもいいですか?
座標変換とかの理解が曖昧でよく分かりませんでした・・・orz
>>965 なんか不思議な方法ですな。参考にさせてもらいます。
矩形が回転しているということは、判定はあの外積とか使って線の交差とか求めるやつでつか。
以前実装したら結構重かった記憶が。
>>967 バカ正直に計算
P : 球の中心座標
r : 球の半径
C : カメラ座標
U : カメラの上方向ベクトル
m : View/Projection/Screen行列
で、画面上の球(円)は
中心(pixel):
P' = m * P
半径(pixel):
V = P + r * normalize( cross-product( U, P - C ) )
r' = |m * V - P'|
もっといい方法がありそう…教えてエロい人(´・ω・`)
970 :
950:2006/08/04(金) 01:38:44 ID:Pfv4JpqV
>>969 やっぱりそのままやるしかないのか・・・。
なんかビュー変換で求めた球の中心点のZ値と射影行列の一部を使えば
何とかなりそうな気がしたんだけど、、、無理?
3Dの2Dシューは技術的なこともそうだが
ステージデータの作成を考えると頭が痛くなりそうだ
そいや昔は擬似3Dって言葉があったがこっちは擬似2Dとでも呼ぼうかw