1 :
名前は開発中のものです。:
ゲームプログラマなら誰もが通る、もしくは、通った道。青春の香り?
それは「シューティングゲーム製作」・・・。
このスレでは、そんなシューティングゲームの製作技術や技術の検証、成功談
失敗談笑い話、難易度の設定方法論、多弾の是非などについて語り合いましょう。
もちろんBulletMLなどで弾幕を作成してみたり、自分の作ったシューティングを
晒してみたり、プロジェクトをはじめてみるなどもOK!
ただし、シューティングの未来とか既存のゲームの話題などは、関連する他の
スレでやってくれ。
■前スレ
シューティングゲーム製作技術総合 3機目
http://pc5.2ch.net/test/read.cgi/gamedev/1087339516/l50
3 :
名前は開発中のものです。:04/08/09 19:58 ID:oKoFsB2n
4 :
名前は開発中のものです。:04/08/09 20:05 ID:9hA/J4qX
4ゲト
やっぱり男なら触手フェチでないとな。
>1乙
触手の再現なら別のスレでやってたな。
基本はPenII233でよろ
ありえない。何かの間違いではないのか?
乙一。
そういやハイスペック要求するクソゲー作ったけど何処からも文句でなかったなと言ってみるテスト
それは無反応だったといウボァー
_| ̄|○
ら、ランキング登録は100件くらいあったもん!
>>10 Thanks!
しかしこのスレ、思ったより人が多かったんやね。
スレ建てて、こんなにも乙と言われたのは初めてだす。
>>14 シューティングの場合、
ある程度スペックが上昇するのはやむを得ない
と思っている人が多そうやね。特に弾幕系は。
まあマシンが重くても、多少は遊べるしな。
PenII400〜500は、もはや許容範囲?
そのクラスのマシン、今から用意しようとすると大変なんだよね。
うちも今ある古いPC壊れたらもう無理。パーツ揃えるのも面倒すぎる。
対応したくてもできなくなりつつあるのが実情。
俺はAthlonの1.0GHzを750MHzに下げてテスト用にしている。
ビデオカードはGF2MX。よってこれ以下は外部の報告待ち。
秋葉の某ゲーセンでCAVEの蟲姫を先行プレイしたけど
今回はデカキャラが多いね
おっぱいがデカイよネ
最低環境=開発環境(P3-600のノート)なんで無問題
>>19 中古屋でいくらでも売ってますよ。
PenII233MHz+RageII合わせて1500円ぐらい。
BXマザーせいぜい3000円ぐらいでしょ。
だれか>13がグラディウスVだってのを指摘してやれよ。
>>24 いくらなんでもそこまでの低スペックには対応しません。
>>25 ありがとうw
>>24 最新で格安で最低限の性能を持つG/Bと、
中古のPenII400を積んだPCを買っても、
1万を切る状況になったら、もう一台買うかな?
とか思っていたけれど・・・もうすぐそこだな。
あるいは、PenIIIの1Gクラスが買えるまで待つかな?
??
PenIIIの1Gをテスト用に使うの?
パソ買い増すより部屋がスッキリしてたほうがいいやん
セキュリティ対策で、
ネットから隔離したPCが一台欲しいというのが本音。
あと、ゲームを遊ぶために必要なスペック自体が、
もう、極端に上昇する事が無さそうなんで、
そのぐらいで十分かな?と。
東方の入力遅延って単にFPS処理とかウェイトの処理がうんこなだけだよ
それなのにプログラムは合ってるというからどうにもこうにも…
手元では「垂直同期を取らない」で改善されたので、
これは垂直同期取ったら1フレーム遅れるんだろうな、程度に認識してた
まぁ明確な改善手段があるなら公開すればいいし、そうでない場合は改善の見込みは薄いな
ショップ製の一番安いやつ買えって。3〜4万からあるから。けろよん2GHzくらいの。
セロリンは2GhzでPentiumIII 1GHzに劣ったりもするから
あまりお勧め出来ない。
スペックに不満が出ればpen4に載せ換えれるから良いじゃん。
pen3だとそれ以上は買い換えになるし。
>>36 何を求めてるのか判らん。
感想?技術的な話?
感想please
できれば技術的に見てどうかも
ねらい撃ち弾が今のところ限界です
タイトル画面で無駄弾を撃つと隠しモードに入れます
今までは乱数で敵を発生させていたのを今日からマップファイルを読み込んで
出現させるようにしたのです
感想なら2DSTGスレでいいだろう。
2DSTGスレ?検索しても出ないぞ。別の板か?
>>31 >東方の入力遅延って単にFPS処理とかウェイトの処理がうんこなだけだよ
そう言うのであればどのようなゲームループが最も遅延を感じさせないか
議論するのもいいかもしれんな
漏れの場合は、メインスレッドとタイマースレッドを使用。
タイマースレッドはSetEventとSleep(17)で回す。
メインスレッドには、WaitForSingleObjectを
フリッピングの手前に配置して同期させてる。
ある意味、ゲームループと言えるかどうかは微妙だな。
>>44 パッドの入力値はどのタイミングで拾うのん?
>30
うちはHDDラックで一台をLINUXとWINで使い分けてます。
低スペックの問題ですが、ドリームキャストってどのくらいの
スペックなんでしょう。ゲーセン用に開発されたものがいまだに
ドリキャスに移植されてるって、アルゴリズムマニアックスに
あったんだけど、ということは弾幕系シューの基盤とドリキャスって
同じくらいの能力なのでしょうか。
こちらは高水準言語でプログラムするのだし、少しマシンのレベルを
高くしても。
何言ってんのかよくわからん
ちょっと良く出来た翻訳ソフトの出力みたいなレスだな。
文体も内容も、LINUXとWINを使い分けて使ってるような奴がする質問とは思えないw
スプライトをハードがサポートしてる環境で開発してるんだが
入力遅延の話に混ざっていいかい?
一々断らんで参加しる
アーケード基板だとNAOMIの遅延が結構気になるな
シューティングも何作か出てるけどやっぱ遅延を感じる
NAOMIって遅延あるの?
NAOMIのシューティングってあんまやってないからなー。
じゃあお言葉に甘えて
まず現在見ている画面に対して超反応で入力したとき、それが次のフレームで
反映されていれば遅延0フレームと定義しとくな。
理想は
VBLANK→入力取り込み→諸々の処理→仮想オブジェクト生成→オブジェクト転送→VBLANK終了→ビデオ出力
で遅延0フレームだけど、俺の場合VBlank期間中に処理が間に合わないので
VSYNC→オブジェクト転送→VBlank終了→ビデオ出力→入力取り込み→諸々の処理→仮想オブジェクト生成
こうしてる。これだと1フレーム遅延だよね。
PCの場合は・・・よく分からんのだがリフレッシュレート論争を参考に
B宗1派:タイマ割り込み→入力取り込み→諸々の処理→仮想オブジェクト生成
VSYNC→フリップ→ビデオ出力→バックバッファ生成
B宗2派:VSYNC→フリップ→ビデオ出力→入力取り込み→諸々の処理→バックバッファ生成
A宗:dt経過→フリップ→ビデオ出力→入力取り込み→諸々の処理→バックバッファ生成
こんな感じ?B宗1派だと、どれだけ遅延するか、予測が難しくないか?
B宗2派はダブルバッファリングで1フレーむ、トリプルで2フレーム遅延。
A宗は問答無用で遅延0。もしくは最大dt秒遅延。
生温かい突っ込みよろしゅう。
補足。
東方に関しては
>>32から察するに、B宗1派からVSYNCを除いてみたら
フリップしまくりで遅延がなくなっちゃいましたーな状態だと思う。
AとB1の混合。
>>45 DirectInputで普通に。
昔は、キー入力が欲しい時に拾ってた。
今は、一度拾ったら、画面の再描画が行われるまでは、
記憶しておいた値を使うようにしてる。
ごちゃごちゃ言わずとも
>まず現在見ている画面に対して超反応で入力したとき、それが次のフレームで
反映されていれば遅延0フレームと定義しとくな。
それが常識なんですよタコ。 ←生暖かい突っ込み
うひーあったけー。
そりゃ垂直同期を待たなければ入力に対するレイテンシが小さくなるかも知れないが、
その代償がティアリングと不安定なレイテンシでは、
シューティング的にいいことないと思うんだけど。
アーケードやコンシューマのシューティングは普通に1/60秒待ってるわけだし。
59 :
58:04/08/12 01:51 ID:k/nH6te4
おっと、不安定なレイテンシは撤回。
Lunatic制覇がまだな程度に下手の横好きな自分は、
ティアリングがあっても自機がキビキビ動くほうを選んだ
他の人がティアリングのない美しい画像を選んでもよいし、
どちらかを選択する自由のある現状に不満はない
61 :
偽ガルーダ:04/08/12 02:21 ID:S2SW3FD3
最近、体調崩して進行してません、、。
偽ガルーダの場合、
描画>更新処理>V待ち の順なんで、
>>53と同じなのかな?と。
1フレームの遅延は確実にありそう、、。
最初に描画しといて、CPUとGPUの処理を並列でやらす。
という一般的な処理だとは思うけど。
因みに、appウィザードで生成されたコードを元に組んでます。
input,music,初期化,メインループは、ほぼまんまです。
>>61 遅延があるよーと言った者だが、流石に1フレ程度の遅延はわからないと思う…。
とりあえずお大事に。
入力の遅延についてですが、CPUが忙しすぎるとジョイスティックの入力値テーブルを更新するタスクに処理がまわらないって可能性は考えられますか?
FlipでVSYNC待つならありえないかも知れないけど。
俺はティアリング容認でタイマで更新してる
んで、どのタイミングで取得するかだけど
画面更新->処理->17msWait->次の画面更新という流れの中で、画面が更新される->プレイヤーが
それを見て反応となるからには入力を取得するのは可能な限り次の画面更新の直前がいいと思ってみたり
上の流れだと「処理」の一言で済ませてるけど、背景書いたり敵を動かしたり、自機以外の
オブジェクトを先行して描画したりして、可能な限り後で入力取得・自機移動・当たり判定
・自機の描画なんかを行うとか。
いっそ1フレーム17msの時間で更新直後に全ての処理を一気に行うんではなくて、
更新->(a,入力不要な処理)->(b,腰溜めで数ms時間を潰す)->(c,入力を拾った後の処理)->(d,更新から17ms経過までwait)->次の更新
みたいにしてなるべく画面更新->入力取得までの時間を延ばすってのはどうよ?
NAOMIは相当の遅延があるよ。大往生とかケツイやった後に式神2とか斑鳩やると顕著に分かる
以前テストプログラム書いてみて色々試したんだが、
フレーム進行速度の管理部分をPresentに任せてしまった時に入力関係に何らかの支障が出てたような記憶があるなぁ。
遅延だけでなく「入力データ落ち」っていうこともあった。東方と全く同じ現象だな。
ところがtimeGetTime使ってフレーム進行を管理したら遅延とかが全くなくなることがあった。
アイドル時間中にSleepを呼ぼうが呼ばなかろうが関係が無かった。
このときのPresentは垂直同期待ちを使ってる。
サンプルソース無くしちゃったのが残念なんだけど、どうもPresent前後が怪しい気がするな…
あの関数、内部でSleep呼んだりせんから、CPUパワー丸ごと奪ってくし
>>36 ムズイ。個人的にはあまり面白いと思わなかった。
コンボシステムは面白いかも、
だけどコンボしようとすると敵の移動がランダム過ぎて当たらないし
当てられない。狙っているうちに敵が増えて死ぬ。
なんていうか、敵が突っ込んでくるクレスタ? いや違うな。敵軌道がランダムっぽいし
自機と敵弾共に速すぎると思う。
弾よけようとして敵に当たることがしばしば。
とりあえず難易度を低めにしてみてはどうだろうか。
良いスコアシステムを持ってるのだが、稼ぐ暇が無いのは残念。
インターフェイスがマズイ。
ゲームパットで操作させたいなら、ゲーム開始/終了もゲームパットでできるように。
ところで、残機はなしの方針なのかな。
実際の入力操作 と 画面更新 とのタイムラグがもっとも少なくなるように組むのが理想
でも、処理の都合で、そうは行かないことが多い
ということ?
主に、描画処理の都合で、かな。
>やっぱシューティングってあんまり乱数はつかわないものかい?
そんなことはないよ
>>やっぱシューティングってあんまり乱数はつかわないものかい?
昨今のアーケードならほぼ皆無に等しい
固有の種からの乱数は未だに使っていると思うけど。
ケイブのばらつきのある弾幕とか、斑鳩の撃ち返しとか。
パーティクルとかには当たり前に使う。
73 :
69:04/08/13 01:21 ID:jogizV9Z
だいぶ敵の動きから乱数を取り除いてみました
やっぱこうするとランダムな動きって恐ろしい事この上無いね
シューティングを作るとき敵の動きってスクリプトを作って動かしてるかい?
if とか実装するのムズそう
マップに画面上の敵が全滅するまでスクロールを停止ってマップチップ番号を実装してみようと思う
敵の動きはソースに直接書いてる.
>>69 >乱数はなんとか使わないようにしたい
>やっぱシューティングってあんまり乱数はつかわないものかい?
上の行と下の行、繋がるのか?お前さんなりの理由・事情があって
『乱数はなんとか使わないようにしたい』という結論に行き着くのか
それとも『乱数はなんとか使わないようにしたい』が
『乱数を使わない』積極的な動機になるのか気になるところだが。
俺の場合、ゲーム中の主要な構成物(自機・敵機・弾)の処理に
乱数が全く絡まないことはあるが、それは主にゲーム内容というか
ステージデザインの都合で、たまたまそういう形に行き着いたという
だけの話で、乱数つかわないようにしたいという発想が出発点に
なったことはないな。
76 :
75:04/08/13 02:03 ID:2hwTrV1s
かぶっちまったな。
>>73を読んで事情がわかった。
>>73 「誰が動き作って諸々のバランス調整するか」によってやりかたは色々だが
個人でやるなら最小限の手間でそれなりにラク出来そうなところで、luaあたりを
使ってみたらどうだ。
luaって何?
スクリプト言語でそれらしきモノはあるみたいだが・・・
>>72 >固有の種からの乱数は未だに使っていると思うけど。
そりゃ勿論だが、それを「乱数」と呼べるのかは疑問がある
今時のアーケードシューティングには純粋な乱数はまず使ってないと思うよ
おいおい、純粋な乱数なんていったら…
ゲームじゃまず使わないぞ?
だからそれを>69に言えと
その前に純粋な乱数って何だ?
使わないものの話をしてもしょうがないじゃな〜い
純粋な乱数が何であるかも分からないのに、使わないと決めつけるな。
使わないならその理由を説明してくれよ〜。
SRAMに更新した種を保存しとくとかRTCを内蔵しとくとか?>アーケードシューティングに純粋な乱数
そこで電池切れを利用した電源パターンですよ
>>83 コンピュータで作られる乱数は基本的に
「擬似」乱数だってのは知ってるか?
>>85 本物の乱数か、擬似乱数か、なんてそんな話の流れじゃないだろ。
>>78 の最後の行の
>今時のアーケードシューティングには純粋な乱数はまず使ってないと思うよ
今も昔も、本物の乱数なんか使っていない。
つうか
>>78 が意味不明なこと言ってるだけだから流したほうがいい。
これだからモノ知らないヤシは困る
NAMCOのSYSTEM2にはセキュリティチップ兼用の乱数発生器が付いてるぞ
メモリマップされてて、特定のアドレスは読み出す度に常に一定しない値になる
それ他となんか違うの。
そもそもシスIIのシューティングでランダムってどこに使って竹。
別に乱数を使ってもいいし使わんでもいいだろ
・リプレイを取らない簡易STGなら、どんな乱数を使おうと構わない
・敵の攻撃が大雑把で良いのなら、乱数をどう利用しようと構わない
とくにプログラム練習用の手抜きSTGなら、乱数をお気楽に使ってもよい
・ちょっと凝りたいとか、アーケードに見習うとかするなら…
・種を与えることができない乱数は、制御ができないのでリプレイに使えない
ygs2kのrandなどが相当(srandを持たない)
・対策は、乱数用ライブラリを使ったり、自前で乱数処理を書いたり、乱数テーブルを用意したり
・敵の攻撃を乱数に頼りすぎると、大雑把なSTGになってしまう
膨大なので省略するが、乱数を使わずに多様な変化を起こすよう組むのが理想
そこまでやって想定してなかった安地や永パが発覚したら目も当てられんな
永パは今のシューティングのつくりだとそうそうできないだろ
ケイブボスのゆらゆらとかは安置封じに役立ってるらしい
>>87 で、昔時のシューティングは本物の乱数使ってたのか?
本物の乱数なんて存在するのか?
96 :
75:04/08/14 01:06 ID:RNsB3r9g
>>77 >はあるみたいだが・・・
で、それがどうかしたんでしょうか。
疑問の趣旨がわかるように語尾をしっかり書いてほしいね。
97 :
75:04/08/14 01:14 ID:RNsB3r9g
>>95 んー。例えば高校物理を学んでいれば
答えを知ってるはずなのですが。(電子雲とか)
実際に入手可能な乱数発生器としては
熱電対を使用したもの等があります。
STGとは無縁の話なので、後は勝手に調べるなり
勉強してください。
SYS2だとメタルホークあたりかな>ランダム性高いの
小波のスクランブルとかタイムパイロットの時代だと結構再現性の無い
出現パターンのゲームは珍しくも無いし
メタホは自機の自由度が高いからどういうランダムなのかよくわからん
100 :
:04/08/14 02:15 ID:NwfcnNwI
最近のケイブ系のラスボスは運に左右されることがよくあることらしい。
射出方向次第でミス回数が変わると言われてる世界だし。
本物とか擬似とかどうでもいいって
ところで乱数を効果的に使ってるSTGってどんなのある?
102 :
:04/08/14 11:32 ID:NwfcnNwI
>>101 はっきりいってないと思う。
ドラゴンブレイズのランダム面はクリア優先の人もスコア目指す人も振り回されるほど最悪だったし。
ただ単に覚えるだけではだめ、というスパイスにはちょうどいいが、
やりすぎるとどうしようもないものになる。
雑魚の出現等にランダムを使う様な気がするけど
ケイブのヘリは、自機X座標で出現位置が変化するのとしないのとをそれぞれ組み合わせてたな
「自機などに影響されて多様に変化するが、乱数ではない」という仕組みは多い
エスプの近江覚の攻撃のバラツキがランダムっぽいけど。
というか、固有のシードからの乱数は色んなところで使われてるでしょ。
わりと昔からあったね。
自機の位置と反対方向から出現するとか、
点数によって、1upの発生する場所が変わるとか。
パワーアップによって、攻撃が苛烈になるとか。
点数の偶数奇数というのは、なかなか分かりにくい。
つまり
ランダムなんて無い方が攻略性が上がって良いし
多様性を出すにしても
>>104で十分、ってことだな
なにが充分なんだよワロタ!
不規則性=ランダム(乱数)って頭では到底わかんだろうけどね。
昔地形マップをプレイ毎に自動生成するシューティングってあったな。
自機が多関節の竜みたいなので、全方向スクロールするやつ。
名前が思い出せんしぐぐってもみつからないが、誰か覚えてない?
サイバリオンか?
シューティングとは微妙に言いがたいが。
サイバリオン 自動生成 でぐぐると、それっぽい話題がいくつか読めた。
114 :
109:04/08/14 16:33 ID:FYvwCjIR
>>110 _, ._
(;゚ Д゚) …?
藻前が理解できん・・・
漏れは乱数なんて使わなくていいなぁって言っただけなんだが
もしかして多様性=不規則性って頭ですか?
キモイ絵文字使ってる
>>109がいるなw
乱数使うも使わんも勝手にすればいい、不規則性は多様性のひとつだ一緒にするな
そんなこともわからんのか!
狭い見解で「これで充分」などと抜かすのが叩かれる原因なのだヨ
「まず日本語の勉強」
その言葉そっくりてめぇに返してやるぜ♪
なんか変なのがいるがスルーで良いのかな
∩___∩
| ノ _, ,_ ヽ
/ ● ● |
| ( _●_) ミ _ (⌒) 夏だよな♪
彡、 |∪| ノ
⊂⌒ヽ / ヽノ ヽ /⌒つ
\ ヽ / ヽ /
\_,,ノ |、_ノ
120 :
109:04/08/14 17:22 ID:FYvwCjIR
あー
つまりお前は十分という言葉を硬くとらえすぎなわけだな。
ファジー機能搭載しる
はいはい、それでおっけーっす(泣)
自分@かなり大人げなかった
でもキミもちょっと、必死すぎて(ry
123 :
111:04/08/14 18:37 ID:KSESjClW
>サイバリオンか?
そうそう、作者自身も攻略を楽しめるんじゃないかって、マップの自動生成にはあこがれたよ。
結局自分のゲームに実装したことは無いけど。
質問です。
誘導レーザーを作ろうと思っているのですがどう作ればいいか分かりません。
レーザーの構造体配列(またはクラス?)を作って、尻尾?になるやつは一つ前の構造体の
座標を代入していけば、くっついて来ると思うんですけど、誘導なので、レーザーの発射角度が
変わるときのレーザーの画像をどう描画すればいいのか分かりません。発射角度に対応した画像を
作っておくのか、それとも画像自体を回転させた状態で描画したらいいのかが分かりません。
というかその場合どーいうプログラムを組んでいいのか分かんないです(つД`)
環境はWindowsで、VC++6.0、DirectX7.0です。
どうかお助けを。できることなら協力しますので。
まず、誘導しない360度全方向に撃てる短いレーザーを作ってみるのがいいんじゃないかな。
>発射角度に対応した画像を作っておくのか
>それとも画像自体を回転させた状態で描画したらいいのか
よくわかんないけど、レーザーがぐにゃぐにゃ曲がる部分の絵をどうしようってこと?
そうだったら
⊂⊃
こんな感じのレーザーの絵用意して、画像自体を回転させて重ね合わせていけば
綺麗にまがるんじゃないかな
おう 書き忘れ
プログラムのほうは
尾を引くんじゃなくて、頭を伸ばしていく感じにしたら?
レーザーを動かすんじゃなくて、
レーザーの先頭から新しいレーザーの先頭を次々置いてくかんじでさ
>124
とりあえず、おまえが思っている「誘導レーザー」を使っているゲームをよく観察し、よく考えろ。
>できることなら協力しますので。
そんな他力本願な意識じゃ、いつまでたっても分からないと思うよ。
>>123 マップの自動生成ネタは、多分、これだけで一スレ建てられる。
>>124 ⊂⊃
こういうレーザー全体の形を表すテクスチャを用意して
⊂======⊃
こういう風にテクスチャを引き伸ばせ。
頂点座標を適当に置けばぐにゃぐにゃする奴も簡単に作れる
>>124 どうするかってセオリーがあるわけじゃなし、いくつか表現の方法がある。
具体的にゲーム名挙げてみるのもいいかもよ。
>>123 マップ自動生成とはちょっと違うけど、KOBO deluxeってゲームの要塞生成は
面白いなと思った。内容はボスコニアンアレンジなんだけどね。
134 :
124:04/08/14 23:25 ID:s5UuKyHo
沢山の意見ありがとうございます。
>>128 自分が参考にしてるレーザーはレイストームのやつです。
(ロックオンしてから発射という機能はいりません)
画像は
>>131の意見を参考にします。先頭、中間部分、尻尾の3つ。
描画については、レーザーの発射角度を求めたら、その角度に画像を
回転させて描画する処理、でいいのでしょうか?
ていうかとにかくやってみまつ。
ホーミングレーザーはSTGアルゴリズムマニアックスに出て無かったかな?
買ってないから判らないけど。
>>134 「ポリラインストリップ」は3Dのポリゴン技術じゃ基本中の基本
3Dグラフィクス数学でも読め。必読書だ
>>134 画像回転でやるなら
レーザーが曲がるトコでスキマが出来ないようにガンガレ
138 :
名前は開発中のものです。:04/08/15 16:36 ID:o5VncmOG
すいませんが、どなたかここの過去スレ3本分、全部保存してる方いませんか?
できたらアップしてほしいのですが。
よろしくお願いします。
シューティングゲームアルゴリズムマニアックスってどうよ?
自分で考えても9割型わかるようなことばかりかいている本。
わからない1割のために頓挫したり、放り出す羽目になることを考えれば良いのでは。
問題は、その1割をちゃんとわかるように解説してあるか、という気がする。
それでもマニアクスというタイトルの割りに、マニア向けでない点は批判されているみたいだね。
にわかにシューティングを作ってみようと思った人には参考になるかも
そういう人にも向いてないような。
なんというか小手先テクニック集という感じがした。
>>134 レイフォースじゃなくてレイストーム?
レイストームは画像回転じゃないのでは?
シューティングゲームアルゴリズムマニアックスは124見たいな人向けの本だな
誘導ミサイルだとか曲がるレーザーとか特定の方法が分からない場合には役に立つか
既にシューティング1作完成させたことがある人ならちょっと考えれば分かるような事ばかりだし不要だな
課題スレのSTGを終わらせたぐらいが丁度いいと思った
解説自体は小中学生がわかるぐらい噛み砕いてる
やね本で補完すれば人前に出せるぐらいのものが作れるのでは?
シューティング好きがプログラムを学ぶというより
プログラム好きがシューティングを学ぶ本かな
課題スレ等この板でうぷされるものでも弾や敵の軌道で悩む(というか実装しない)人は
多いから需要はあるんじゃないかなぁ
このスレの人には年齢的にも経験値からみても関係ない本だとは思うよ
Flashとかでシューティングやってる意欲的な若者向けですか
>>65 ムキャやNAOMIはPower VRだからね。パイプラインの都合で通常3フレームの遅延がつく。
なにげにゲーマーにはおすすめできないハードだ。
148は勘違いしてると思われ
どのように?
シューティング作るのにおすすめなサイトおしえて〜
やっちゃった
質問です。
人のソース改造してシューティングゲームを制作してるんですが、
横スクロールタイプシューティングの「放物線を描いて落ちる落下弾」が作れません。
(ちなみにSTGアルゴニズムマニアックス読んでるのに作れない素人・・・)
なにとぞご教授ください。
(C++とDirectX9です)
以下の文はまっすぐ右に飛ぶ弾です。
p->vec2.x += 7.0f;
// 変換行列を作成
D3DXMatrixTransformation2D(&p->Matrix, NULL, 0, NULL, NULL, 0, &p->vec2);
y=y+ay;
ay++;
>>155 あなたの人となりを否定するつもりないけど
>人のソース改造してシューティングゲームを制作
そんなことしたくないなあー・・・
だって出来てからの満足感がまるでないし、つまんねーじゃん?
時間かかっても0から作ったほうがいいと思うよ。
急がばまわれだワン1
>>157 ベーマガ世代やオープンソースを完全否定するようなことを……(笑
>155
1.元のソースが理解できないので、改造して落下弾を作ることができない
2.STGアルゴニズムマニアックスの落下弾の説明を読んでも意味がわからない
どっちだろ・・・
なんか1っぽいんだけど(汗
もし2だとしたら、STGアルゴニズムマニアックスのLIST2-22にサンプルのソースが
そのまんま載ってるので、自分のプログラムに合わせて変数を変えるだけで動くかと。
放物線の運動の理屈がわからないのでしたら、中学校の物理の教科書でも・・・
回答ありがとうございます。
>>156 やってみたんですが・・うまくいかず。
>>157 0からやってみます。まずはウインドウ作成からですね・・・
>>159 1も2も該当してる気がします。いや、該当してます。
放物線ってy=axですよね?
vy+=accel;
x+=vx; y+=vy;
足し算あるけど掛け算ないぞ???って思いました。
いい年した成人なんすけど、頭固くてプログラムむいてないっすね。
>>156のayとか、
>>160のaccelとかが小さすぎる値だと、
実際には加速していないように見えるかも知れない。
わからないことはこまめに試して、身体で憶えてしまえ。
ゲームに使う数学に関しては、体系だてて数式で憶えなくとも、
プログラムで憶えてしまえば(趣味の範囲では)十分通用する。
164 :
159:04/08/24 01:51 ID:1kP3mPcm
>160
その2行だけだと分かりにくいですけど、vyの値が呼び出し側に戻されてる(&)がミソです。
前回関数が呼び出されたときのvyの値が保存されてるので、vyには毎回差分を足すだけで
OKなわけです。要は、
1回目:vy=accel
2回目:vy=accel*2
3回目:vy=accel*3
って毎回計算するのと、前回の計算結果を利用して
1回目:vy =accel
2回目:vy+=accel ( accel+accel )
3回目:vy+=accel ( accel+accel+accel )
の違いかと。
>>160 横へ移動する速度は等速
縦へ移動する速度は増えていく
ここまではいいですか?
x=x+1
y=y+1
だと右下へ直線に動いていきます
x=x+1
y=y+2
これだと角度が急になりますがやっぱり直線です
x=x+1
y=y+3
これだとさらに角度が急になりますが直線です
と、ここで今まで引いた線を順番に繋げてみてください
放物線に見えませんか?
+4,+5,+6……とさらに続けていくともっとわかりやすくなります
p.56の加速弾は理解してますか?
xとyで加速する量が違うのが落下弾です
もし元のソースがよくわからないのであれば斜めに真っ直ぐ進む弾を撃ってみてください
これができれば放物線もそれほど変わりません
たぶん、y=ax^2+bが頭にあるんだと思いますがこれは忘れてください
今回は関係ないです
つーか中学生の理科の問題だろ…
小学生理科で10スレ近く消費するとはレベルの高いスレだな
そもそも放物線ってのは等加速度運動の軌跡のことだ。
xを位置、vを速度、aを加速度、dtを経過時間(=1フレームの時間)とすると、
等加速度運動なんだから「速度の変化量=加速度*経過時間」なわけで、それを数式で表せば
v+=a*dt
だな。「位置の変化量=速度*経過時間」だから、
x+=v*dt
だ。dtは普通固定だから事前にaやvにdtを掛けた値を使う。最終的にプログラムは、
v+=a;
x+=v;
で済むわけ。こんな説明でOKかいな?
放物線がわからんのに微分とか持ち出してもわからんだろ・・・
中学理科で台車ころがして「差が段々でかくなる〜」みたいなのなかったっけ。
>>170 1063.4
低めの弾道で跳ねさせたほうが飛ぶね
よい放物線サンプルですた
車輪の再発明をする必要はない。
とはいえ
糞ソースを改造するのは気が退ける。
必要ある無しじゃない。自己満足の部分だな。
それ言ったら、ウィンドウ開く一つとっても全部自前でないし、
ファイル、入出力、 etc・・・何をするにしたってそうだ。
0からなんて言ったらキリがない。
しかし、シューティングゲーム製作スレだろ。
>>157は
>人のソース改造してシューティングゲームを制作してるんですが、
に対しての一意見がそれで、車輪の話などしとらんだろ。
それにフリーで一人でやってるんなら全部一人でやってればいい。
時間があればの話だけどね。さらに言うと良いプログラムを読み書きできるのと、
良いソフトウェアを製作するのとは別だよ。
とりあえず、STGマニアックス本のような流動食ですら
消化不良を起こす155のような層が存在することが
再確認できた。
彼らにとっては、あの本のタイトルはハッタリではなく
その名に相応しい難解でマニアックな本だったのd ΩΩΩ < ナ、ナンダッテー
ああいう馬鹿がいるからって
「ひょっとしたら自分は数人に一人しかいないプログラム適正をもってるんだ!」
とか思っちゃだめだぞ!
馬鹿とは言ってないぞ。
世の中色々。STG作る人も色々。
うむ、馬鹿といってるのは俺だなw
だけど意外とそういう馬鹿が作ったゲ=ムのほうが面白かったりしてね。
作ってから言え
プログラム技術があっても面白いゲーム作れない、言うだけの人は沢山いるし、
技術が無くても面白いゲーム作る人も沢山いるし、
それらに当てはまらない人も沢山いる
技術がゲームを面白くしないことは明白だからなあ
技術がないよりはあったほうがいいのは事実だけど
技術があるだけじゃ、何もならないからなぁ
たとえ車輪の再発明でも、自分で作れば実力になるよ。
一回できあがりかけたころ、最初から作り直すと美しいプログラムになったりもする。
そしてそのほうが原因不明のバグに悩まされることも無かったり。
>185
一応完成させてからリファクタリングした方がいいと思う。
そうじゃないと永遠に完成しない罠。
まあ俺は、オブジェクト指向的にシューティングをコーディングする、というのが目的だから、
完成は二の次でも無問題。
187 :
185:04/08/25 16:24 ID:4lm3WJsn
>>186 確かに。
漏れは、仕事でゲーム作ってるとき、新しいデータを組み込みつつ、待ち時間にプログラムを
改良してまつ。じゃないと納期間際におそろしいことに…orz
改良しきれずバグが出ないように祈りつつ運用する場合も多いですがorz
どうもソースが複雑になりすぎ
書き直そうか悩んでる
orz
>>188 時間があるなら書き直した方が良いかもね。ただし、
趣味でやってるならほどほどにしといた方が良いぞ。
それこそ本気で終わらなくなる事も・・・or2
構造をメモっておかないので
しばらくいじってないと呼び出し元とか使われ方とか
わからなくなることがよくある。
191 :
188:04/08/25 19:17 ID:lT5JyHro
>>190 まさに俺もその罠に嵌ってる
特定の自作ライブラリにはもう手を付けないだろうと思っていても、後から変更しなきゃ
ならなくなったときにもう覚えて無かったり
オレはそれがわからん。
自分で書いたプログラムなのに後で見て分からなくなる?信じられん。
数年前のコード見ても即座に手をつけられるぞ。
コメントもほとんど書かないしな。
193 :
名前は開発中のものです。:04/08/25 20:39 ID:fNQzeNru
でも、技術がないとアイディアが具現化できないのもまた真実だったりするねぇ。
そんな漏れは技術そこそこで糞詰まらんゲームを製作していまつ。
とりあえず完成までは持ってけてる点だけが唯一の救いかも。
俺もたまにショボいゲーム作るがそんなもん公開する勇気もないから
俺一人だけ遊んで終わり。めっちゃ虚しいぞ!!!
>>192 忘却能力の働かない人間って、たま〜にいるよな……
すごく悩んだところは覚えてるもんだし、全然悩まないところは見たらわかるもんです。
データ構造、パラメータの意味はどこかにコメントしといたほうがいいかもね。
3ヶ月前のコードは他人のコードって、よく言ってたもんだがなぁ。
まあ俺もその類だな。流石に1ヶ月くらい前ならまだなんとかなるけれど
アルジャーノン・ゴードン現象という。
セガの人みたいに手入れすればいいのか。
そだね。
可読性重視でほとんど全部書き直してからは、覚えて無くても、
あんまし悩まなくなったな。理解は出来るから。
相変わらずコメントとか付けてないケド。
目に沁みる程の微笑ましさだなヲィ
中学生の自由課題を張るスレじゃないんだから、な?
sin cosの固定小数点によるテーブルと
atan2の640x480を64*48のテーブル処理使っているんだけど
グラフィックとかしょぼいと駄目だな
>203
「固定小数点を使う」と、「グラフィックとかしょぼいと駄目」がまるで繋がらないのだが?
あと、atan2の64*48テーブルって何?
>>204 固定小数点とか独自のパックファイルとかプログラムに結構力を注いだんだけど
見た目のためか評価が低いことをからの感想
atan2の64*48テーブル ってのは
イカベーダの画面の解像度が640*480だから
配列のサイズを考えて(1/10)^2の64*48にって事でこうなる
たとえば弾の発射元座標が(0,0)でプレイヤーの座標が(640,480)だとしたら
atanTbl[64][48]を参照すればatan2のテーブルから45度とか帰ってくるわけ
それで方向弾を撃つと アルゴリズムマニアックス読みますた
それと第二から第三象限であると判断した場合には
180度足したりして返すと
sqrtはとにかく使わない 角度が得られないとn-wayで狙うとかできないし
今の超高速なPCの処理速度なら
テーブルなどいらぬはずだ!
豪華に atan2 そのままつかっちゃおうぜ
つうかsinもcosもsqrtも結構速いぞー
サインテーブルを使ってる部分を
普通のsinに置き換えてみたら分かる。
処理スピードなんざ全然変わらん。
まあ別に速度だけが固定小数点の利点ではないけどな。
>205
そら、見えない部分を評価することは出来ないし、ゲームとはそういうものだ。
あと、そのatanテーブルだと誤差が大きすぎる気がするが。
実用に問題がないなら、それはそれでいいけど。
でも、DirectXGraphicsでやる場合、特に理由がないなら、素直に浮動小数点を使っとけ。
絵が多少しょぼくてもエフェクトに凝るとか効果音の使い方とかで大分印象は変わってくるぞ
プログラムと爆発エフェクト作成ツールだけで派手な爆発とかは作れるし
>>200 ジョイパッドが刺さってるとキーボードが使えないので使えるようにして欲しい。
マニュアルにジョイパッドの操作説明がなかった。
最小化して元に戻すと背景の星が横一列に並んでしまう。
Xでコンティニューだけどタイトルに戻りたい場合はどうすれば?
何処を評価して欲しいのか具体的に書いたほうが良い。
そうしないと突っ込みやすいところばかり突っ込まれるだけ。
絵とか音はどうでもいい、絵は気にしないし、音は嫌なら消して好きな曲流しながら遊ぶだけなので
技術もatan2使おうぜ、という点以外は問題なさそう
たぶん、まだゲーム内容に凝る予定じゃないんだよな
だから、今のところは良くできてるよ、と言っとく
個人的に固定少数やatanテーブルは技法として好きな方なんだが…
#今のCPUじゃ言うほどの利得は無いのは承知
>イカベーダの画面の解像度が640*480だから
>配列のサイズを考えて(1/10)^2の64*48にって事でこうなる
非常に些細な事なんだが”もうひと工夫”欲しかった
固定少数を使うという事は根底に高速化したいという思想があるはず
であれば俺なら「1/10」にはしない
さて、何でだと思う?>205
本当に些細な事なんだけどな(w
215 :
名前は開発中のものです。:04/08/28 12:12 ID:3c0hiz+o
>>214 やっぱ1/10 にする割り算がかえって
高速化が目的のテーブル処理を遅くしてるってことなんかな
やっぱテーブルって大きいものとか
最初にアルゴリズムマニアックスを読んだときは円形の方向弾が四角くしか飛ばなくて困った
タイトル画面で弾を撃ち続けるとエキストラモード入れるよ
>>215 良いものを置いといてやろう
|)つ [ シフト演算 ]
リプレイ機能つけるならテーブルの方が良いらしい。
CPU(の浮動小数点演算ユニット)に依存する可能性がある、以外に理由はないよな
実際に発生した例があるとわかりやすいんだが
今のCPU(といっても200MHzクラスから)だと並列具合によっては
シフト多用すると遅くなるんだよな
200MHz!?
MMXPentium?!
もれ8ビットCPUでアセンブラでプログラムしてたりするので節約技法はかなり大事でつ。
256x224の座標でatanだと16x14持ってれば良い?
必要とされる精度はキャラの当たり判定の大きさなどで変わってくるのでは
自機止まってるのに普通の狙い弾が当たりもしないよ…なんて事態にならなければ、
適度に粗くしていいのかもな
>222
多少CPUを使えば、角度数/4のサイズでかなり正確な、
/8でも割と正確なatan2ができるけど。
そういや、Lapislazuliは何処へ行ったんだ・・・
プロセッサやマシンの状態により微妙に演算結果が変わってしまうことがあるという…
ああおそろしや。
リプレイングデータ再生とかさ
>226
小数点以下の精度を固定できる。
任意の進数で小数点以下を表現できる。
浮動小数も、IEEE754準拠のフォーマットが使える環境同士なら
制度は固定できるけどな。
でもさあ浮動小数点は精度が高くても誤差はあるって事だよね
たとえば80%だったらのこり20%は狂ってきて再現性がなくなるってか
ん?
>>231の通りじゃないか?
普通IntelでもAMDでも浮動小数の演算結果はIEEE準拠で実装してれば同じになるはず。
バグとかはともかく、いわゆる普通のIntel系CPUで結果がずれることってそんなにあるの?
>>229 世の中のリプレイ機能付きはみんな固定少数点数でやってるの?
浮動小数点数使わずに?
>>230 なるほど。ってゲームでそんなこと気にする?
>>231 よかった。オレのリプレイ付きゲーム内で使われている浮動小数点数すべてを
固定少数点数に置き換えなきゃいけないのかと思った。
>>232 別に固定小数点数でも誤差は出ると思うけど
>>233 オレも疑問です。
そもそもシューティングにリプレイいるか?
ま、軽く遊んで終わりの消費型シューティングにはいらんわな
むしろシューティング以外にリプレイいるのか?
>>235 上手い人のプレイは見てて面白いですよ。
あとデモとして流すとかにも使えますよね。
>>237 うーん、例えばカーレースでしょうか。
大抵リプレイ機能、ゴースト機能ついてますよね。
>231
そうじゃなくて、((π + 10) - 10) != πとなってしまう事を言いたかったのだが。
「浮動」である以上、桁が大きくなると少数に割り当てられる精度が落ちてしまう。
まあ普通のシューティングでは、まさに誤差の範囲内で済む事だけど。
もちろんリプレイに影響が出るとか言うものでもないし。
>>238 ああ、たしかにレースゲーのリプレイはアリだな。
241 :
231:04/08/29 00:32 ID:dvcQQr7Q
>>239 ん?
>>230氏と同一人物かな?
>>239の内容はその通り。
オレが気にしてたのは、
>>227>>229>>232あたりは間違いなんで、
変なことが常識として広まらないで欲しいなぁ、ってこと。
浮動小数を使用した場合確かに((π + 10) - 10) != πだが、
その誤差や演算結果は毎回同じ。
なので、リプレイがずれたりすることはありえない。
無知だなぁ…
某メーカーが昔出したPCでは演算結果がほかと異なるということがあった
だからPCゲームではそのへんを気を使わなきゃならんと。
BBXでも何回かでたぞこの話題。
あ、BBXで出たのは一部のアプリケーションを同時に使用したときに
演算結果が変わるだったかな?これはどの機種でも関係ありそうだ
そうなの?
昔、初代Pentiumで浮動小数計算にバグがあって
演算結果がずれるとかいうのがあったのは知ってましたが。
他にはx86系(Pentium以降かな?)には
IEEE754互換モードと、もっと精度の高い(80bit)モードがあって、
違うモードだと当然結果が異なるとかいうのもあるけど。
>>243氏が言ってるのは
ttp://bbx.hp.infoseek.co.jp/cgi-bin/bbx.cgi?log=36&vew=261 このあたり?
# 裏で動いている他のアプリがレジスタのモードを変えちゃって
# 計算結果がずれる、とかかなぁ。
いや、煽りとかじゃなくて、自分が知ってる原因以外で誤差が出ても困るんで
ポインタあったら教えてくださいってことで。
あぁ、それじゃあない、フォトショがなんたらかんたらってやつ
浮動小数点の場合比較でも単純に「==」とかやっちゃいけないってあたりでかなり気を遣うだろう
なんか呆れる展開になりつつある悪寒
>>236 じゃあアーケードシューは全て軽く遊んで終わりの消費型シューティングだな
ネットにうpされてるアケシュームービーの数をみたら
どれだけアーケードシューのリプレイをみんな待ち望んでるかわかるだろ。
ついてないのはアーケードだからと考えるほうが自然なのに。
アホだ
>>245 ありがとう。けど見付けられなかった...orz
>>242 無知じゃないあなたはどう解決してるの?
まったく浮動小数点数を使わず固定小数点数オンリー?
そもそもリプレイなんて実装しないの?
というか、某メーカーとか言わずに、はっきりとメーカ名、機種名等書いていただけませんか?
じゃないとあなたの脳内メーカーか本当の話か判断がつきません。
>>246 大した問題じゃないでしょう。一度こんな関数を用意したら終わりな話です。
inline bool NearEqual(float a,float b,float eps){ return absf(a-b)<eps; }
整数しか使ってない'`,、('∀`) '`,、
斜めはどうしているのかと小一時間
>>248 >ネットにうpされてるアケシュームービーの数をみたら
>どれだけアーケードシューのリプレイをみんな待ち望んでるかわかるだろ。
ほんとバカだな
そんなに需要があるならなぜアーケードにリプレイが無いと思う?
自分が見てる狭い狭い世界が全てか、アホ
アーケードにリプレイはいらないから
アホだ
なんだこりゃ
>>254 >なんか呆れる展開になりつつある悪寒
とか言ってる人が呆れる展開にしてどうすんですか。
予言は自分が実行すれば確実に当たるのは確かですが
2chでそんなことをしても虚しいだけでしょう。
>>ID:al7btGsh
そろそろ自己矛盾に気づけヲタ
何が自己矛盾だ、ぼけかこいつわ
アーケードにリプレイが無いのが何故か判らない人は誰ですか
まあ結果的にリプレイが再現できていればいいよ
誤差で当たらないはずの弾に当たったりなんてないよな
固定小数点は内部計算用で表示には四捨五入した整数値を使ってるよw
Dx8になったら回転とか浮動小数点使わざる終えないね
そういえば話題が変わるけど NowLoadingみたいな 読み込みながらも処理するのって
1フレームで読み込むデータのバイト数とか決めてやってるのかな
そうなるとテクスチャとかD3D3DXGetImageInfoFromFileInMemoryとかでメモリに読み込むのか
それとも1フレーム1ファイル?
スレ違い話引っ張って申し訳ないんですが。
なぜアーケードではリプレイ無しが多いのか、考えたことも無かったので、
今考えてみました。
「完クリのリプレイ流された日にはインカムに影響が出るので付けない」
と言う答は何点ですか?
>>260
>>263 60点かなぁ。
完クリでなくても、ゲームが終わった人にはさっさと席をどいてほしいので、
リプレイに限らず過度な(「派手な」という意味ではなく「長い」という意味ね)演出はアーケードでは禁物。
(エンディングでも、あまり長いのはオペレータに嫌われる)
そういや、アーケードのガンダムもリプレイあったよね。
あれって内部浮動小数じゃないんかなぁ?と思ったり。
リプレイで一番簡単なのは、ランダム要素一切無し、
入力キーのみ記憶しておく方法でしょ。
あとは、同じ状態で動かすだけ。
>>264 PC以外の環境ではCPUその他のハードが完全に固定なんで、
そもそも上のほうで議論されてたような問題
(マシンによってはリプレイがずれるかも?)ってのは起こりようが無い気が。
# 一応、TYPE-Xとかで将来CPUのアップグレードがあったら
# アップグレード前に保存しておいたリプレイが…なんてのはあるのかもしれんが。
>>265 ランダムは自前で疑似乱数を用意して、
種を保存しておくだけで問題無い。
>>267 それをランダム要素と呼ぶかどうかは、微妙だな。
あれ?この流れ最近どっかで見たぞ
敵の動作はどうやって決めてる?
ソースに直書きしてる人も多いのかな?
漏れは自前スクリプトで定義してるが。
1作作ったらもうそのシステムを顧みることはないだろうから直書き
同じようなゲームをいつまでも作りたくないし。
別に同じようなゲームを作るために直書きしないのではなくて
試行錯誤しやすいからスクリプト等、コードの外に出すのだと思うよ
自分はlua使ってますね。
実行中に書き変えることも出来るようになってます。
luaってのは時機の動きにも対応するとかってできんの?
何度も使うような動きはスクリプトで書くが
単発でしか使わないような処理を伴うものは直書き。
どっちがベストってことはない。
>>250 この答えが出てくるあんたみたいな人ならいいんだけどねぇ
何も考えずにやる人はこの程度ですら苦しんでそうだ
デモプレイはリプレイそのものだったり…w
デモプレイで前回のプレイ内容の一部を再生するものも。
>>274 そういうことはluaのリファレンスマニュアルやチュートリアルを
ちょっと読めば分かるはずなんですが…。(当然、出来ます)
それと、何か誤解なさってる模様なので補足させてもらうと
luaはあくまでもコンパクト・シンプルな汎用スクリプト言語ですよ。
アプリへの組み込み用途に比較的使いやすいというだけですから
だから、別にluaじゃなければ出来ないことはありません。
274じゃないけど
なんとなく思った程度でリファレンスまでは読まないのでは。
どうしてみんな
さいばりありびじょん(あーけーどばん)のこと
わすれてるんですか!
>>280 漏れもそう思ったんだけど、デモで最後までリプレイされるか疑問だったので書き込むのをやめた。
リビジョン見たことないんで教えて。
>>280 ごめん。知ってて当然だと思ってた。ぶっちゃけそこまでの流れってネタで、
マジレスする価値も無いかと。
サイヴァリアリビジョンのアケ版は覚えとらんなー。リプレイ?
PS2版買ったけどすぐ売っちゃった。
かわいそうに…キミには理解できなかったんだね
クソゲだし
サイヴァリアリビジョンのアーケード版の仕様は
その後どこも真似しなかったし、2でも搭載されなかったから
結局のところ、いらんものだったということだろう。
然り
上でテーブルどうこう逝ってる香具師、キャッシュのヒット効率とか
考えてる? 考えてるなら文句言わんが。
キャッシュヒットまで気にしなきゃならないほどスペック要求するSTGって
どれほどの物ですか。
PCじゃないと思われ
292 :
名前は開発中のものです。:04/08/30 22:31 ID:RcSNTd6M
そういえば昔、X68kのプログラムに対して
キャッシュどうこう言っていたヤツがベーマガサイトにいたな。
割り算使ってたけどX68kでは割り算使った時点でアウトだと思った。
まったくの余談でスマソ。
弾を撃つたびにインスタンスをnewするおれってどうよ
>>293 別にいいんでね?一フレームで増える弾数なんて多くて100も行かないっしょ。
遅くてもとりあえず動くもの作れた奴の勝ち、最適化はその後。
C++ならnew演算子、DelphiならInitInstance(だっけ?)を書き換えれば全く問題ないし。
>>290 スペックどうこうじゃなくて、
>>289は、普通に三角関数呼ぶより
テーブル引く(変なメモリアクセスする)ほうが遅いんちゃうのかって話だと思われ。
どの道どうでもいいような差だろうけど。
つーか、今時のPC、出力も特性も10年前、20年前と比べてデタラメなまでに違うから
あの頃の感覚で「最適化」してると無駄骨折るぜ?
このスレはスレ的にオヤジが多いからアレだが、
一度富豪的プログラミングを試してみたらどうかと。
CPUベンダやコンパイラベンダの中の人も、「普通」に書かれたプログラムを
より高速に動かすよう、不断の努力を続けてるワケだし。
>>295 > スペックどうこうじゃなくて、
>>289は、普通に三角関数呼ぶより
> テーブル引く(変なメモリアクセスする)ほうが遅いんちゃうのかって話だと思われ。
> どの道どうでもいいような差だろうけど。
それもふまえて。
テーブルだろうと関数使おうと全然速度には影響でない。
今更な議論じゃないすか。
3Dで斑鳩とかのの2倍3倍物が出てジオメトリでキツキツならまだしも、
2Dなんて計算量は微々たる物だし。
やりやすいようにやればいいでしょ。
ゲーム部分に注力した方が有益。
自分がつくりやすいほうが一番いい
>>292 >割り算使ってたけどX68kでは割り算使った時点でアウトだと思った。
PS2とかでも怒られるよ。
浮動小数点の割り算は。
テーブル使う状況って固定小数点の時じゃないのか?
>>298 オレ余裕で使ってるよ。
>>299 別に浮動小数点数でもテーブル使えるだろう。
つうか、固定小数点数の時だったら何?
>300
浮動小数点コプロセッサに頼れない。
浮動小数が理解し切れないため、
恐くて使えないオールドタイプが吠えてるだけです。
気にしないように。
ひょっこりひょうたん島ですね
>>304 けど、Windows環境に限ればnewが失敗するようなケースでは
どのみちまともにゲームが動くことは期待できない。
そんな状況の時はどのみち
さっさとエラーログでも吐いて強制終了したほうがマシなので、
newに頼っても頼らなくても大した違いはない。
307 :
名前は開発中のものです。:04/08/31 08:45 ID:MDLtX/q0
ごちゃごちゃ言ったって結局
>>200 >>203 できたものがそれじゃね。グラフィックじゃないよ。
見た目以前の問題だ。
その内容でその処理速度じゃまるで話しにならん。
つっこみがまるでなく、あれから急に書込みが増えたところ見ると
この程度のゲームがスタンダードなスレだったのかと(ry
308 :
名前は開発中のものです。:04/08/31 08:55 ID:MDLtX/q0
アーケードにリプレイは要らないとか、あるはずないという意見があるけど
タイトルからデモ画面になる場合そこで上手なリプレイを
見せるって方法もあるし、何らかの形でユーザーがデータ記録できるようにする等
別にリプレイがあってもなくてもいいけど、あったほうがおもしろいと思う。
完璧なリプレイを作りたいなら、半ムービー化すればいい!
全くズレないリプレイが完成する。
マシンスペックや記憶媒体の容量を、気にしなければの話だが(藁
完璧な乱数が無いのと同じように完璧なリプレイなんて無かったのさ。
今はね。
あと5年や10年もすれば、マシンをフル稼働させられる
ようなプログラムは、ごく一部に限られて来るんじゃないかな?
というか、フル稼働する必要の無い処理でフル稼働している場合、
設計自体に問題を抱えている可能性が大きい。
313 :
200:04/08/31 10:38 ID:++NQBSnT
>>307 あのゲームは毎フレーム スプライトがy座標でバブルソートしているからますます遅くなってるね
qsort使えよ……
Y座標だけならOTで良いんじゃないの?
アケでリプレイがつかないのは経費に見合わないからだろ
ここは趣味でPCのSTG作ってる暇人のスレなんだから、リプレイを搭載しない理由がない
PCのまともなSTGはリプレイが当然のようについてるしな
釣りなのか大真面目なのかサッパリ分からん
そもそもゲームのプレイ中のデモ画面は
ある意味リプレイが実装されているとも取れるがな
車ゲーならライン取りとか時間軸にそった流れを見たいからリプレイの需要はあるだろうが、
STGだとその場限りのミスなんて見ても仕方ないから意味が無い。
一般プレイヤーとしても他人のヘタクソなリプレイなんぞ見たかないし、ほんの一握りのトップ
プレイヤーの超絶プレイならそれこそビデオ撮りしてムービーとしてあった方がいい。
一握りのプレイの再現の為にリプレイ実装なんぞ無駄。
更に言えばメジャーなアーケード作品ならまだしも、誰も知らんようなマイナーな
同人シューにリプレイなんぞ付けられても一体誰が見るんだと(ry
家庭用とかならともかく
アーケードでリプレイ付けるのは
いろいろ問題があるかもな
>>320 攻略性の強いゲームの場合
リプレイがあるとないとじゃ大違いなこともあるぞ?
プレイ中には見えないことも多い。
>>275 スクリプトというより、中間言語インタプリタにしてます。
1フレーム分実行し終わったら次のタスクを実行しに行くようにしてます。
スクリプト内に書くか、テーブルでデータ化するかは状況によりけり。
8ビットCPUフルアセンブラorz
bulletml使ってる人はいる?
bulletml使ってみなよ、というレスはときどき見るが、
実際に使ってる人のノウハウとかはあまり見た憶えがないな。
>ここは趣味でPCのSTG作ってる暇人のスレなんだから、リプレイを搭載しない理由がない
個人的趣向により搭載しない。
根拠というくらいの意味合いでの「理由」だったのかなぁ…
それはともかく別件として、リプレイ集とかあると面白いけどな〜
まぁこのへんはムービーでも構わないけどさ。
配布したいときとか、容量が違ってくるやん?
となると、リプレイ「機能」を搭載しているくらいのものが丁度いいのかな。
アーケードでもメモカなんかを利用して、1リプレイ1コインの価値があるような
リプレイを提供するなりしてくれればあるいは…
それこそ90年代ならいくつか遊び倒すくらいのシューティングがあって、その頃の
リプレイ機能には感動したけど、今ではflashのようなあたらしいオモチャが毎日
あるんで基本的にゲームはクリアしたら終わり。クリアできそうになかったら放置。
だから今は、延々と遊び倒すようなユーザは大抵知ってる人間で、数える程度しか
いない気がするので結局自分のも搭載しなくなった。
(逆に厨房と興ざめな影響の方が多いような気がするので)
> 基本的にゲームはクリアしたら終わり。クリアできそうになかったら放置
>>236だな。
最後の行はよくわからんが、身内じゃない人間のクソリプレイなぞ見たくもないという心理か。
ゲームならどんな人間にどんなプレイされても構わんとも思うが、いずれはその心境になるのかな。
これがツールなら、使ってショボいもの作られて萎えるということはあるのでわかるが。
>323
おお、仲間が。
LOOPADR:
db COM_DIR,100,10 ;100度に10フレーム移動
db COM_DIR,200,10 ;200度に10フレーム移動
db COM_JMP ;JUMP命令
DW offset LOOPADR
MASMでCOMとしてアセンブルして拡張子はBINに。
プログラムからはバッファに読み込んでバッファ先頭からの
オフセットでJMPなどの飛び先アドレスを解決しています。
プログラムが進むにつれ、謎の暴走をするようになりまして。。。
古い人間なんて知らなかったんですが、アラインメント
というのがあるのですね。。。他にも怪しいところがあるのですが、
このデータ処理で異常アドレスになったときに変なところに書き込む
のが暴走の原因ではないかと。エラーを吐き出すように改造すれば
いいのですが、動けばいいみたいにぐちゃぐちゃにコード書いてたんで、
もうお手上げに。。。それっきり。
まあ、くだらない愚痴でした、はい。
掲示板然り、僕のリプレイをホームページにのせてくださいとか、次回の
テストプレイヤーになってあげます等、厨房はとどまることを知らないから恐い
>>332 必死すぎ(w
一般人が知らんような同人ゲーのリプレイ見たがる人種がどんな奴らか知れるな
一般人はシューしません
そこまで逝き着くとヤバそうなふいんき(ry
けど否定してみたところで、
一般人がシューティングしないのも
PCで一番売れてると思われるシューティングがリプレイ完備なのも
事実だろうしね。
アーケードはともかく、コンシューマに移植されたらリプレイ機能は普通についてるしな。
同人ゲーでシューティングが多いのは、
売れ筋ジャンルの中では一番作りやすく、
かつ、見栄えが良いからだと思うぞ。
作り手の腕の差も露骨に出るし。
まーそんなことはどうでもいいっていうか脱線しすぎ
リプレイデータの持ち方あたりの話じゃなかったっけ?
それとも異機種で毎回同じ結果を出すための計算方法だったかな?
もうちょっとさかのぼると
>>200に到達するな。まとめは
>>295-297あたりで。
途中で派生した中間言語インタプリタやスクリプト、luaやbulletmlの話のほうが興味ある。
俺はXML解析の知識がてんで無いからlibBulletML使ってみようかな、と思ってる
当然だが、すべての動きが記述できるわけじゃないけどなぁ・・・
そういえば、某同人シューティングは、スクリプトにRuby使ってるなんて噂を聞いたんだけどさすがにデマだよな・・・?
ちと思いついた事がある。漏れの場合は、
弾や敵の動作には自前のスクリプトを使っているけれども、
これは、リプレイにも応用できないか?と。
少しばかり処理が重くなるけれど、
描画処理をするための中間データを作る。
この中間データを用いて画像の描画処理を行う。
さらに、この中間データをリプレイのためにも保存しておく。
これなら完璧にリプレイできるし、ムービーのように、
データサイズが膨れ上がる事も無い。
>>342 その中間データがなんなのかよくわからないんだけど
描画するものの座標とかを保存するってこと?
そんなことしなくても、乱数の種と、キー入力だけ保存するようにすればいけるよ
リプレイ機能付けたことないのかな?
機種ごとに結果が違ってしまう計算が含まれてたらダメだけどさ。
それとも漏れが考えられることよりもはるかに高度な話をしているのか?
>>343 まあ、即興で考えたネタなんでアレだが、
要は、スクリプトの実行コードの集合体。
他ジャンルにもソースを流用できそうだ
というのが本音。
>>341 もし俺の思っているゲームと同じならば、それは
スクリプトのコンバートなどのツールにRubyを使っている
を聞き間違えたのだと思われ。
とはいえ、ジャンル違いではあるけど、
RPGツクールの最新版はスクリプトにRuby使用だから、
そう無茶な話でも無いのかもしれず。
>>331 このスレは、プレイヤーがリプレイが必要かどうかを論じるところじゃなくて、
製作者がリプレイ機能を作りたかったらどうすれば出来るかを論じるとこじゃないの?
リプレイ付ける事を嫌ってる人がいるから。
作りたくない人はわざわざ作る必要ないし。
いい加減にしる
そんなにリプレイが好きなら自分でゲーム作って好きなだけリプレイ実装しろっての
以降リプレイの話題禁止
次の話題ドゾー↓
勝手に禁止するなよ。
>>347が正論だな。
ただ、リプレイ機能を作りたい人が質問するたびに
>>235が涌いて出てくると、ちょっと疲れるな。
でもリプレイの話するとなぜかすぐ噛み付く奴がいるのは事実。
>>350 いい加減にしる
お前の支離滅裂な理論を使うと、どんな話題も禁止できるじゃん。
以降お前の発言禁止
次の人ドゾー↓
PC(Windows環境)で浮動小数使ってると
リプレイがずれるとか言ってた人がいるけど、
その後明確なソースが提示されてません。
不安をかかえたまま開発続けるのもすっきりしないんで、
誰かはっきりさせてください。
無限ループだな
固定少数で小数部の初期化を忘れて整数部の初期化だけしてたおかげで
ずれたことはあるなぁ。
358 :
名前は開発中のものです。:04/09/01 21:38 ID:1NYwUGUd
リプレイはキャラが変な動きしたときの再現に役に立った。
だから漏れにとってリプレイはデバッグルーチンのひとつでつ。
>>355 ソースが無いから余計混乱させることになるかもしれないけど
BBXに昔、商用3D格闘ゲームをWinで作ってる(自称)の人がきてた。
で、リプレイでずれることがあるとかいう話を展開してたのは覚えてるけど
もうずいぶん前だなぁ・・・。BBX過去ログにはのこって無いのか?
>>359 ありがとうございます。
と、その後もう一度ググってみたところ、該当すると思われる情報をひとつ発見しました。
ttp://bbx.hp.infoseek.co.jp/cgi-bin/bbx.cgi?log=36&vew=256 # 「似たような検索結果を表示」にしないと出てこなかったので前は気付かなかった…。
多分
>>243で言われてたのはこれかな?と。
同時に、同じスレッド内で初代Pentiumの演算バグについても述べられていたので、
もし当たりなら、昨日言われてたことについてはほぼはっきりした気がします。
で、これを見た上での自分の結論としては、
この問題への対処としては「浮動小数を使わない」ではなくて、
「ゲーム中に裏でヘンなソフト動かさないで」で終わりにしようかと。
こんなことのためにプログラムに変な足枷を付けるのは、
個人的にはトレードオフとしてやってらんないレベルだという感想だからです。
>>358 俺もその経験あった。
リプレイ中に任意早送りつけたら便利なこと便利なこと。
リプレイ?
AVIで出力汁。コレ完璧
次の話題どうぞ
さすがに巻き戻しは考えたことねえな
365 :
名前は開発中のものです。:04/09/03 13:31 ID:CJRrnDNj
>>361 あー、それ俺もやってた
というか、完成した奴にも普通にその機能実装してたけど
>>364 便利そうだが、大変だな
ステートセーブ付けるとデバッグに便利かも。
いろいろ面白いことができそうなんだよなー、ステートセーブ。
巻き戻しはステートセーブの応用でもいけそう。
ただ、1面1リプレイというスタイルでいまどきのCPUなら描画適宜スキップすれば
面の最後まで数秒で早送りできるだろうから、大抵のことは早送りで済む。
その数秒が惜しいような機能には、ステートが有効かもな。
どうせならコマ送りも欲しいな。
当たり判定のアラがバレるケド(藁
ステートセーブで巻戻し実装するとなると
フレーム毎にステートセーブすることになるのか?
オブジェクト多いと少しえらいことになりそうだな
60フレームごとなら軽くなるかな
別スレッドでステートセーブ…は途中までセーブしたところで変化してしまうから意味ないか
ステートセーブなんて言葉、初めて聞いたが、
みんな平然と使ってて何かと思ったら、エミュで使われている言葉か。
そうやってエミュ叩きの流れを作ろうとしているわけですか?
まぁ、CPUレベルでのデバッグとかハードウェアとかにある程度詳しくないと見ない用語だし、
知らないのは恥ずかしいことじゃないよ、たぶん。
システムによっては相当な量になるだろうね、音声とか画像のように
垂れ流される情報とかあるし。
でも再生点を自在に設定できれば、復習したい場所から何度でもやり直しプレイ
ができるので面やボスが長いゲームにはいいかも
ステートセーブって、どうやるんでしょうか?
タスク内のデータを全部保存しておく、って感じでしょうか?
状況を再現するのに必要な情報を保存。
まぁ、とりあえず保存して、再現してみればいい。そうすれば何が足りないのかわかる。
ゲーム中で、出力命令があったら出力処理している部分を、
いったん組み直す必要があるわな。
ゲーム中の出力命令を中間データに変えるようにし、
今のフレームのすべての出力命令がそろったら、
中間データを用いて出力処理を行う形に組み直す。
この形にすれば、逐次、中間データを保存することで、
ステートセーブが完成する。
え?敵の位置などの状態、変数を保存するのがステートセーブなんじゃないの?
VMで組んで
VM上のメモリをそのままHDDにセーブすんだよ
>>378 それ、出力部分しか保存してないから
ステートセーブにはならないんじゃないか?
TypeXはPCベースらしいですね。
ここのやり取りが色々参考になるかも。(ならんか?)
なにほざいてんだバーカ
ステートセーブなんて真のステートセーブはエミュならではのものなんだよ!
考えてみると構造体の中にポインタがあったらそれだけでmallocされたメモリとかアドレスとか
あれこれ違ってくる。RPGのセーブはステータスと場所とフラグぐらいだが
シリアライズの実装は難しい
ステートセーブは大変だよな…普通はステージごとのセーブとリプレイ早送りで十分だ。
ステージ開始にセーブ/ロードするだけなら、普通は敵や弾の座標は一切記録する必要が無い。
自機のステータスとランクなどだけですむ。
そういや、ボス前に雑魚を出さない仕様にするとかあるな。
ボスの必殺技を何度も何度もチャレンジしてみたいというのはあるが...
しかし実装し(てもらい)たいのは自分のゲームじゃないんだな。
最近の言語ならシリアライズは標準実装で余裕だろ
よし、あれだ。
巻き戻したい場合は1フレーム目から計算しなおせば良うわなにおする
音楽プレイヤーでシークを「冒頭から指定時間までの早送り」として実装するようなもんだな
多少時間はかかっても実用に堪えればそれでよい
CPUとGPUを上手く並列に処理できるよう書いてる人って居ますか?
要するに現フレームのバックバッファへの描画を終えて垂直同期の待機中、
CPUは次フレームの計算を初めても問題がない、って部分っす。
実際2Dシューってそこまでする必要はないと思うけれども…
そうなるとマルチスレッドにしてイベントで同期を取るって感じになるのかな。
>実際2Dシューってそこまでする必要はないと思うけれども…
計算だけになるから凄く速くなる。先の分を処理しても
一回先の計算を終えて待っていることになりあまり効果が無いかと…
むしろ表示が原因で処理落ちが発生しているときに、タスクの
座標計算だけ処理して表示を何回か飛ばしてしまう処理の方が
ほしいのではないでしょうか。
397 :
396:04/09/05 06:58 ID:9hrBJRap
ただし、うちは観音蜂の作者じゃないので、間違っても観音蜂の作者に改変についての動作不都合報告とかしないように。
とりあえず動作確認はしてありますが、ウイルスチェックはしたほうが安全かもしれませんし、
また、ノークレームでお願いします。
そんなものをここに貼るのはまちがっている。
技術的にも見るものがない
>>394 まぁすでに3Dの描画でもネックじゃないしねぇ
レスポンスがおくれるほうがまずい
>>398 見るべき所があるかどうかは、見る人が決めること。
藻前が決めることでも無いだろ。というか、
見るべき技術のあるヤシが、こんな所に張るわけがないだろ。
技術的に見るものがないかどうかはともかく
勝手に改変したものを貼るのはどうかと思うが?
改変の具体的な内容とその手段が明らかにされればそれでいいや
俺は触ったことがないが、チートツール使えば一発ですむようなネタかな
まあとりあえずアフォがいることだけは連絡済み。
405 :
396:04/09/05 22:21 ID:9hrBJRap
>>402 正式に配布されているパッチ03とdiffしてください。
2箇所を数バイト書き換えた程度です。
2回目以降のエクステンドを劇ヌルにしますた。
とりあえず弾幕の研究などに役立ててみてください・・・って役立つのか?
408 :
396:04/09/06 01:16 ID:seHK1QkI
>>407 ADSLでネカフェに入れるようなお金持ち合わせてないんで、無茶です。
チートは板違いやね。
じゃ、作者側としてはチートに対抗する手段を考えよう。
完全に防御するのは無理としても、シロウトに毛の生えた程度のレベルの奴らの解析モチベーションを萎えさせるような。
全てのキャラにスレッドを持たせてマルチスレッドで動作。
順序が必要な場合はきっちりイベントでスレッド同期を取る。
スクリプトは実行時コンパイルでマルチOS対応だぜ!
タスク処理を知ってるかい?
メモリ上の変数のアドレスが起動ごとにころころ変わればいいんだっけ?
パターンマッチ検索にもひっかからないように、さらにシャッフルしてみるとか。
例えばチートの手法ってどんなのがあるか浮かぶものとして、
・プログラムファイルの解析&修正→デフォルトの残機数を記載してある部分を修正
・メモリの変化をサーチ→ダメージを受けたり、残機やライフが減ったときの前後の
メモリの変化を調べ、残機値が格納されたアドレスの値を変更
などあると思うけど、他にどのようなものがありますかね
415 :
初心者シューター:04/09/06 16:11 ID:MAHnG5m3
1機目から読ませていただき大変勉強になっています。
質問したく書き込みしました。一般的に機体・敵・弾にどのくらいの変数を持たせるのでしょうか?
ネットサーフィンをしていて弾には50以上の情報を持たせているというのを見て驚き質問しました。
ちなみに自分はフラグなども合わせて10個前後です。
30から36バイトだなぁ…
自分に限れば、敵は多くて30個、敵弾は曲げない場合多くて10個
でも凝っていろいろ増える場合もあるし、ちゃんとした理由があり保守や速度で対策がとってあるなら
やたら多くても構わない
>>414 自機数の増減を行う部分に、暗号化したコピーを別の場所に作成しておく機能を
付加しておく。暗号化したコピーと、自機数が異なったら終了にする
メモリアクセスを検知したら強制終了みたいなことはできないのかねえ
自機の数とか正規に増やすには専用のイベントを呼んで増やしていくみたいにして
不連続&&イベントで増えていないと判断した場合は1機にしちゃうとか
実装するにはフラグを作るって感じで
フラグがONになってないのに増えていた場合は不正と
でフラグも変えられたらとなるかもしれんがフラグはmallocで確保して
どこにあるのかわからないようにすればいいのかな
不正を関知したときの罰をどうするかだね
これ次第では解析をやる気を無くすことになる
普通なら1にもどるとかだけど
場合によってはセーブが消えるゲームの例もあるそうだし
DQ IV(PS)は改造王 ? だっけて称号になるとか
シューティングならタイトルに戻るとかがいいね
某シェアウェアみたいにロジックボムは・・・
ワークラムのチェックサムとるとか。
とにかく軽い事が前提って感じもするな
不正チェックでFPSが下がったりしたら目も当てられない
内部処理の範囲内だから
余程大げさなことしなければ
処理速度に影響は出ないでしょ。
場合によっては、毎フレームチェックする必要もないし。
普通にパラメータのチェックサム取るだけでも、処理速度に影響しない割に
かなりの効果はありそうだと思う
できるだけ対象のパラメータが変化する部分をまとめたほうがいいかな。
>415
たくさんの変数を持つオブジェクトを作ってるのは、
最小公倍数的な設計をしているからじゃないの?
OSレベルのクラッシュコードを走らせる>罰
それは誤爆したら洒落にならん。
しかも誤爆じゃなくても、製作者の評判が貶められる自殺行為。
即タイトル画面に戻す → 無難
増やしたはずなのに増えていないような…いや、増えたように見えているだけ?
ボス体力が無限になっていて自爆もしない?など混乱させる
→ 解析への嫌がらせとしてはこちらのほうが効果があるか
東方みたいなストーリー性の高い奴を作る場合なら、1回不正を検知したら
クライマックスで突然
「お前メモリいじったろ」
「この卑怯者!」
とか罵声浴びせてバッドエンドとか……はて、どっかで見たような。
何か一昔前のプロテクトみたいだなw
ああ、別にどういうタイプでもエンディングでスタッフロール流す代わりに悪口を延々流せば良いのか。
>>412 擬似タスク処理を無駄にCPUとOSの機能で実装して
意味不明なことをすることに意義があるんじゃないかw
wingroov関係の記事ググって読んでみ。
正直怖くなる。そんなことできなくなるから。
>バッドエンド、クラッシュコード
「別のプロセスにより書きかえられました」
とか丁寧で無難なメッセージを表示してexit。
クラッシュコードは冗談で言ったんだろうけどさ・・・
まぁ、俺はPCのシューティングゲームはリプレイで競い合うもんだと思ってるし
凝ったチート対策なんていちいちしないけどね
意図的な処理落ちによるスローモーション対策とかはがんばってるよ
ねこまんまが脅威だ・・・
メモリアクセス検知ありそうなんだけどねぇ。
ある?
ねこまんまのプロセスがあったら終了で
チートやクラック対策は別板に行った方がレベル高い情報得られると思う。
STG特有の話でもないし、俺や素人が思いつくレベルのことなら既出だろうし
クラック方法もほぼ確立してるだろうし。
APIフックやIsDebuggerPresentでとりあえず対策してたつもりだったけど
破る方法さっくり言い当てられちゃったし。
正直、クラック対策より完成を急ぐ方が先だろ
然り
納期があるわけじゃあるまいし
急ぐ必要はないだろう
他人にゲームとして遊んでもらえる最低限の出来、を完成とするなら、
一般的にはできるだけ急ぐほうが良いのでは。
(調整が完了するという意味での)完成は永遠にしないよ、という宣言は例外としておいとく。
まあのんびりやって長くモチベーションを維持できるスキルを身に付けてる人なら、特に急ぐことも無いか。
「ゲーム」の質を優先させるべき、と言いたかったのではなかろうか。
チートさせる気を起こさせないほどの、「ゲームとしての面白さ」が最強のプロテクトだ!
とか言ってみるテスト。
ソレダ
ヤシらはゲームする前にコード探してる気がするw
そもそも完成してない奴はチート対策に興味を持たないだろ
完成してない奴ほど気にする
ってか俺は
>>442は名言だと思う
なんつーか攻めの考えで、良いね
そうなん?
漏れは
>>446じゃないから完成してない奴の気持ちは分からんけど、
インターネット見る前まではチートなんか気にしたことなかったよ。
気にするようになったのはネット上でチート対象となっていた情報を得てから。
現実を見る限り、チートするしないにゲームの面白さなんか関係ないけど。
チート対策しなきゃいけないほど多くの人にプレイされてるのか?
っつかシューティング好きな奴で、ここぞとばかりにチートしまくるやつもあんまいないだろう
そんな奴は実はシューティングが好きじゃないからすぐ離れていく
つい最近からこのスレ見始めたんだけど
意外と質問に来るヤシとかいないんだな
>意外と質問に来るヤシとかいないんだな
実装案はちょっと考えればすぐに解かるものばっかだからだろ>STG製作
改めて質問するほどの内容なんてそうそうなさげ
作るにあたっての最大の難関は素材かと
プログラム初心者が自分の理解度などの情報をちゃんと明かして質問してくれれば
答えるほうも楽なんだろうけど、なかなかそういう例が少ないな
テキトウにSTG用絵素材を生成するツールを作ろうかと思ったが、いまだに影も形もできてない
できたところで自分の好みにあってるだけの、汎用性の低い素材しか作れない可能性も大きい
素材生成つっても爆発とフラクタル雲、あとはせいぜいショットくらいだろう?
他に何か自動生成で作れそうなのあるかね。
巷にあるようなすごい素材をボタン一つで自動生成!というレベルは自分には到底無理なので、
単色8x8ドットの質の素材を自機、敵、背景チップなどで用意するときに手抜きしよう、という程度。
ある程度できれば色数や形はそれなりに拡張できるだろうし。
8x8ドットじゃ小さいだろ → ネタゲーのように単純拡大 といった方向。
最初は低画質だが、自分の好みの粒の揃った素材を用意できるかも、あたりが発想だったかな。
爆風ツールとかドット絵ツールで普通に素材用意もしてるんだけどね。
うーん、うまく説明できないや。ともかく大幅に期待外れな内容でスマンかった。
携帯コンテンツ作成の敷居が下がれば需要が出るかも
でも携帯用のゲームなんか作りたくないなぁ・・・。
ケイブもやってるし
ケイブもやってるから何?
ケイブもケータイやってるよ
だからそれがどうかしたのか?
現実世界でも良く見る光景だ、うむw
ワロタ
ガイジンがむかつくんだけど
ガイジンにプレイさせないようにするにはどうすればいいかな?
OSはWindowsなんだけど、
Windowsが日本語版かどうか判定すればいいの?
無変換キーの入力を要求するとか。
ガイジンだって日本語Windowsで日本語キーボード使ってるかもよ?
音声入力いれる。
日本語フォントの有無をチェック
APIで国コード拾うとかできないかな?
基本言語設定変えてまで遊ぶヤシは稀にしかいなそうだし。
あ、でもメリケンのヲタは気合入ってるみたいだから、
日本語マシーン1台作ってでも遊びそう・・・
日本語でクイズを出してそれに答えられたら出来るようにすればいいじゃん
マシンだけじゃどうにもならないさ
「テロリストによる銀行強盗が起きました。
犯人は銃器を持っている危険な強盗のようです。
数人の人質を捕まえて、銀行に立て籠もりました。
犯人は警察に向かって、「見逃してくれないと人質を殺す」と人質に銃を突きつけて叫んでいます。
さて、警察はどうするべきでしょか?
1. 断固として犯人の要求を受けずに、隙を見て犯人を射殺する。
2. 人質の生死を最優先に考え、場合によっては犯人の要求も受ける。
先進国の多くのガイジンは1を選ぶ。
3. 「人質を殺せばお前もここで死ぬことになる」と逆に犯人を脅す。
先進国の多くのマンガ野郎は3を選ぶ。
質問させてください。
Direct3D8で2Dシューティング作ってるんですが、
(半透明を多く使いたいので)
マップスクロールで良い実装が思いつきません。
画面上の2倍ぐらいのサーフェイスを持ってそれに
レンダリングターゲットを切り替えてマップチップ単位で
少しずつ転送すれば行けるんでしょうか?
ただ、これだとサーフェイス->バックバッファ->メイン描画の
三段階の転送になるので、スクロール速度が早くなると
描画遅延が気になるんですが…。
マルチテクスチャとかは使えないです…。
なぜ描画の遅延が出てくる?
三段階の転送がパイプラインで並列に動いているなら考えられるが、
普通に組んでいたらありえないよ?
遅延やらマルチテクスチャやらはまるで関係ない。これっぽっちも。
普通にバックバッファにチップを並べても速度的には何の問題も無い。
とりあえず作ってみれ。
それでもだめならもう一度ここに書き込み。
ちょっと質問
ステージ構成はハードコーディングでも最初はいいと思うけど、
最終的なステージ情報の管理はどのようにしてますか?
マップチップとスクリプトと進行タスクで管理。
進行タスクって何?
マップやシーンの切り替えの管理を一元的にするヤツでは?
漏れは非表示キャラで管理してる。
さんくす
画像ってやっぱpng使ってる?
ていうか東方とか有名ゲームのアーカイブの内部でpngあるかな?
2Dなら機能が足りてるし
サイズが小さい上にアルファチャンネルが付くし
便乗質問
自分の攻撃が敵に当たったとき光るようにしたいんだけど、フルカラーだと
パレットチェンジできないから光った画像を別に用意するしかないのかなあ
テクスチャでやれば赤くしたり、透明化したりいろいろ簡単にできるよ
>484
Direct3Dなら、SetTextureStageStateをいじれば色々出来なくもない。
うーん
普通に頂点カラーとMODULATEだな、俺は
うむ、TextureFactorが便利なんで色々使ってる。
TFACTORはVGAによっては駄目な奴があるらしい…。
そいつとMODULATEしようとしたら影響しなかった。VGAの仕様らしい。
というかTFACTORだとポリゴン同時に描画するときに同じファクタしか使えないから
やっぱり俺は頂点色を入れるのをお勧めしたいな
ただのMODULATEだと、明るくすることが出来ないのが弾にキズだけどな。
MODULATE2Xとか使えば?
パレットとか言ってるからDirectDraw前提じゃないの
俺なら別画像用意する
メモリ食うけどお手軽
フルカラーでDDraw使う意味ってあんまりないよな。
回転・αがないなら速いとか?
速度を求めてたら
>>492 の言うように別画像。
自力描画で好きなように色換えるってのもあり。
エロゲヲタの古いノーパソで動かす事を視野に入れたらDDrawもありかと
オタなら意味もなく高スペックかもしれんといってみる
古いノートが視野ならフルカラーはなさそう。
特に理由はないけどDraw、ってことかな。
使ってるライブラリがDirectDrawのみに対応してるとか
漏れもDirect3Dは使って無いぞ。とりあえず、
今作ってる奴が完成するまでは手を出さないつもり。
最近ウチのモニタ、640×480だと画面がブレるんだよな。
まあ、Windowモードを用意しておけば無問題だが、
次のゲームからは800×600にしとくかな?
走査線のぶれ?
壊れてるだけでしょ
よく三角関数をテーブルにするやり方を見るけど、1周が65536とかって感覚的に凄い分かりづらくないですか?
1フレーム毎に1度ずつ回すときとか、65536/360度にしなきゃいけないけど、
これってプログラム全体を1周=65536度として作る(つまり1度=182度として考える)のか、
その都度×65536/360してからテーブルに渡すのかどっちなんでしょ?
普通は後者っぽいけど、なんか掛けたり割ったりで重そう。それでも標準関数のsinより早い?
>>501 sin関数が2回以下の計算で算出できてると思う?
なんで度で考えるのだろう?小学生かな。
>>501 今日から1周は360度から65536度に変更された!
これでいいじゃないか。
でもテーブル化必須の時代は256度でも十分すぎるくらいだったが、コレも弾幕流行の影響かしら。
>>501 そのうちπ使わなきゃいけなくなったりするから
今のうちに慣れとけ
俺は三角関数使いまくりだし正規化とかも思う存分やりまくってるけれど、
速度に関しては十分すぎるよ。ソレくらい今のCPUは馬鹿みたいに速い。
Celeron系とかだとキャッシュ容量すくないし計算した方が早い場合もそろそろ多いと思われ
まぁ、俺も直接三角関数で計算してるが、昔からのながれで256度で作ってるな
でもケイブあたりのを見てると今でも256度もありゃ十分だと思うんだけどどうなんかね
一周256段階のテーブルでの一単位の差は
400ピクセル離れた場所だと10ピクセルにもなっちゃうからなぁ。
今の弾幕シューでそれやるとちょっと穴だらけになりそう。
1/4周を256段階なら2-3ピクセル、これでもちょときつい
>400ピクセル離れた場所だと10ピクセルにもなっちゃうからなぁ。
そんなに発射位置と目標が離れた状況はあまりなさげだし、それだけ
離れてたったの10ピクセルならもう十分な希ガス…
まあそのおかげで大往生2-3安置が出てきたりするんだがな
そういやグラディウス2とかは精度が低いからこそ楽しい気がしてきた
>>511 ボスが固定砲台だったりすると安置だらけになるぞ
距離取って砲台と軸合わせて1回チョン避けすれば
そいつからの直線弾はどうやっても当たらないわけだし
どんなに離れても最低限自機狙い弾が当たるレベルの精度は欲しい。
精度の低さを組み込んだ上でのゲームデザインならこの限りじゃないけど。
>>514 今頃何言ってるよ…そのスレにいる人間がそんな事判らないとでも?
256度もあれば後はゲーム内容でどうとでもなろうっつう話なんだが
また引き合いに出してなんだがケイブシューのボスなら基本的にボス本体を動かし
射出点を常に変える事で安置を潰すのは当たり前
それに自機狙いの弾でもある程度の精度の荒さを持たせないと逆に避けるのが楽に
なってしまう(常に移動してれば当たらない)
ある程度の精度の荒さや狙いの「揺らぎ」もゲームを面白くするための技術だろうよ
東方くらいの弾幕鑑賞ゲーになると角度の誤差によって見た目が悪くなるよ。
あの弾幕で256度は流石にいけてない…
ケイブシューで256度が最適だとすると、
それよりも解像度の高いPC環境でも最適間隔はいっしょなの?
自機を中心としたランダム弾をならともかく、
自機狙いが当たらないって状況はアウトだと思うんだけど…。
ケイブシューの戦車とかって狙い方向荒くなってるよな。
大往生とかは進行方向を基準にした12方向にわざと制限してる。
だから2-5開幕でハイパー打ったときの戦車の弾とか、
まるで壁が押し寄せてくるような錯覚をするわけだ。
ケツイはそうじゃなくて基本的に自機狙い。
>>515 段階をわざと落としたり、弾に揺らぎをもたせたりする「演出」と
最大精度でも当たらない位置関係が発生する「問題」の区別がついてないのかな?
というか、ケイブシューの解像度および当り判定なら
256段階でその「問題」が起こらない(起こりにくい)ってだけでじゃないの?
精度が低いおかげで
>それに自機狙いの弾でもある程度の精度の荒さを持たせないと逆に避けるのが楽に
>なってしまう(常に移動してれば当たらない)
>ある程度の精度の荒さや狙いの「揺らぎ」もゲームを面白くするための技術だろうよ
これらが有効的に組み込まれてる例を知らないんだが……。
>517
あんま関係無いと思うが
解像度(というかゲームワールドの大きさ)に比例して当たり判定サイズも
数値的に大きくしないの?
解像度だけ大きくしてキャラは元のままケシつぶにするなら問題だろうけど
あと引き合いに出されてるケイブのも256度かどうかは知らんが実際
自機狙い弾には精度の荒さがある
そもそも1ドットの狂いも無く狙うような敵弾デザインって少数派かと
>518
意図的に荒くしてあるね
見たとこ16〜32方向ぐらいか?
>520
>これらが有効的に組み込まれてる例を知らないんだが……。
うんざりする程引き合いに出されてるケイブシューがそうでしょ
大往生・ケツイ・ガルーダあたりのボス弾とか観察してみ
>>521 当たり判定の問題というよりも、見た目の問題。
東方みたいな弾幕で絵を描くような演出をする場合、かな?
>>522 ケイブシューって
>>520の言う「演出」ってのはたくさんあるけど
最大精度?が足りてない「問題」のほうがゲームを面白くしてる例ってあるっけ?
そもそも、最大精度が足りてないって問題が発生してるんだろうか?
>そもそも、最大精度が足りてないって問題が発生してるんだろうか?
してないと思うよ
そもそもあれは演出でこれは問題と分ける方が理解できん
技術的な問題じゃなくてゲームデザインの問題だろうに
自機、敵機、敵弾の全ての当たり判定が全て1x1ドットの大きさしか無いので
あれば精度が足りないとかいう言い分も判るけどね
まぁあんま多くは語らんでおくよ
あんまわかってない自分に言わせると、
弾は32方向もあれば充分だと思ったりしまつ。
いくら精度が細かくても、方向によって弾の速度
が目に見えて変わってしまうほうが、よっぽどダサイでつw
方向によって弾速が変わる??
まぁ、あんまりわかってないらしいからさ・・・。
そりゃあ敵弾の座標をドットと1対1の整数で持ってりゃ速度も変わるかもな
初代ファミコンのシューティングでも珍しいタイプだと思うが
PC6001のタイニーゼビウスあたりは斜め弾の方が早かったような
古い話ですまん
完全に狙うなら角度にこだわる必要は無いと思う。
単位ベクトル求めれば良いだけの話でわ。
>>527 うるせーバカ。
最近やったいろんな同人シューやってみての経験談でつ。
アーケードでもあったなw
>>530 なんだ自分の実装したゲームの話じゃないのか
手抜きや技術不足も演出の一部と思って遊んだ方が楽しいよ
>>528 いや、それとは全然ちゃうケースだと思いまつ。
ファミコンの斜め弾が速いのは、多分スターフォース。
>>531 自分のじゃないよ。ヘンだな〜?
と思ったら、そうならない様にするでしょ。
なぜか途中で送信してしまっつ。
>演出の一部
グラIIの赤いレーザー安地とか美しいでつね。
連投スマソ、
>>527もごめん。怒らないでねっつ。
完全に狙ってると言われてもスターフォースくらいしか思い浮かばない。
256度で荒いとか言ってるヤシは多分自分でゲーム作ったこと無いんでないかと…
(自機の当たり判定半径)+(最小の弾の当たり判定半径)以上の誤差を持つのはチョト辛い。
だから640x480サイズだと、当たり判定の大きさによっては256じゃ辛い場合も出てくると思う。
そういやWindowsに移行してからテーブル使ってないや。
ちょっと気になって去年作ったショボいシューティングのソースを見てみた
sin = new int[360];
cos = new int[360];
for(n=0;n<360;n++)
{
sin[n] = (int)(Math.sin(n*Math.PI/180)*256);
…
俺も小学生(´・ω・`)?
>>503
|ω・)ノシ 俺も小学生かも
誰でも昔は小学生、経験を積めばいつか卒業できるときがくる...ハズ?
>>536 だから東方の弾密度は256分割では無理、
って何度も出てるのに無視すんなって。
SRDも正確だった覚えが
そんな同人シューに基準を置かれてもな
かといってケイブシューに基準を置かれてもなぁ
>東方
基準におく必要はないけど、実際に256度で再現不可能なゲームがある、
そしてそれがPC同人シューティングでは一番プレイ人口が多いと思われる、
といった点を無視して話すのもどうかと。
256度が荒いと言わないヤシは多分自分でゲーム作ったこと無いんでないかと…
>529
俺もそう思っていたんだが、よく考えると、
単発ならいけるけど狙いnWayが撃てない。
作ってるゲームによるだろ
549 :
名前は開発中のものです。:04/09/15 22:56:33 ID:0OsHBWyP
メリットがあるとと感じない部分は大ざっぱに作るけどな、漏れは。
ヘタレシューターだし。
550 :
547:04/09/15 23:01:05 ID:kDXNVxjY
いや、撃てるか。
単位ベクトルの90度回転ベクトルは簡単に作れるから、sinとcosの比率で足せば。
やりたいヤツは好きなだけ方向細かくして、好きなだけ憧れのゲームをパクればいいじゃん
誰に強制されることも無いでそ
なに怒ってるの
つうか散々言われてるけど、テーブルなんか使わなければ解決だって
>>550 角度で管理したほうが楽じゃね?(´ω`)
特定の点を確実に通過させるにはBresenhamしかない。
Sin,Cos,TanをPentium4-2.4BGHzで10000回ループで実行させるとそれぞれ
222万、143万、260万クロック前後だった。平方根は44万クロック前後。
Windowsでスレッドの優先順も変えずにやってるベンチなので、1割は誤差が
あると思うけど。
4096度系のテーブル使って二次元ベクトルの回転するのに35万クロック程度
なので、キャッシュを汚すことを考えなければテーブルの方が依然として
10倍は早い。
ただ、画像の一ピクセル毎をソフトウェアで回転とかでもなく、一キャラに
つき数回計算される程度である回転用のSin,Cosの速度に拘っても仕方ない気
はするけどね。一直線に飛ぶ弾だったら、生成時に一回計算するだけだし。
557 :
547:04/09/15 23:39:14 ID:kDXNVxjY
>554
いやまあそうだけど、あくまで角度で狙えない位置を正確に狙う時に出来るかどうか話。
そもそも単位ベクトルを求めるのに、平方根を求める必要があるからなぁ。
まあ、角度で狙う場合もアークタンジェントが要るからどっちもどっちか。
ヒマなんで昔の自作ライブラリこねてみた
http://cgi.2chan.net/up2/src/f62638.zip 画面はアーケードライクに240x320
左上を原点として8x8ピクセルの弾(つっても数字の"0")を真下から
反時計回りに32度分流してみた
8x8ピクセルはちょうど敵弾サイズだからイメージつかめやすいかと
弾の隙間がかなり下にいかないと空かないのがわかる
なおちょっとガタついて見えるのはFlip時に同期を取ってないからだから気にするな
こんなんじゃダメ? > 特定の場所を通過する弾
# 検証してない擬似コードなんで間違いがあるかもしれんが、察してくれ
class Bullet {
const Vec2d from;
const Vec2d vec;
Vec2d pos;
float timer;
public:
// fから発射して、tを通過する。sはスピード
Bullet(const Vec2d& f,const Vec2d& t,float s) :
from(f),vec((t - f) / (Distance(f,t) / s)),pos(f),timer(0) {}
void Update() {
timer += GetDt();
pos = from + vec * timer;
}
const Vec2d& GetPos() {return pos;}
};
561 :
558:04/09/16 00:20:32 ID:u12e8KYs
むぅ、速攻で消えたか
適当なうpろだ無いかね?
>560
それは単に>529をコード化しただけだな。
しかし、例でそのUpdate()の仕方は……まあ個人の自由だけど。
>561
http://gamdev.org/up/ ここでもいいんじゃね?
正直、ソースも付いてないし、具体的に何をしているかも書いてないから、
たいして参考にならんかったけど。
563 :
558:04/09/16 00:31:36 ID:u12e8KYs
んじゃ止めとくわ
単に256度の精度でも十分だって事を示しただけだからな
間隔がどれだけかってのはわざわざコード書かなくても2*PI*r/(分割数)で分かるだろ……
自分がやりたいこと、表現したいことで最適なテーブルサイズは異なるのに
なんで共通の最適値があると思い込むんだろうか?
昔のゲーム知ってりゃ一周64度でも十分なことくらいは判る。
でも十分じゃないゲームを作りたい人もいる。
なぜそれが判らんのか。
弾幕シューだけがstgだと思ってる坊やばっかだからさ。
裏を返せば、
自分にとって最適化されていないコードを許容できないジジイがいるから、
とも言える。
東方東方言ってるのはじじいじゃなような気が
>>568 いやだから、ジジイと坊やの間で話がかみあってないだけだよ、と言いたかった。
こんなところにもジェネレーションギャップが…
レトロチックな非弾幕系作りたければ1周64度でも十分。
東方みたいなのだったら256でも足らない。
自分の作りたい内容で解像度を決めれば良い。
これだけの話で何故もめるのか…。
>>571の発言の具体例を書きまくってたけど思いっきりまとめられてしまったw
要するに作りたいゲームに合ったものを使えばいいんですよ。適所適材
いや、テーブルはもう適した場面無いって
ま、画面サイズが240x320だったり
固定小数の精度が8bitだったりするのにもかかわらず
テーブルサイズが65536とかなら突っ込みたくなる気持ちもわからんでもない
1度の差が(最大)0.5ビット未満って精度はいらないだろ、と
×0.5ビット未満
○0.5未満
なんかいらないものが入った
綺麗にまとまったな。501はいい話題を提供してくれた。
>>573 そんな、ワンダースワンじゃ重すぎて使えないよ!
…ワンダーウィッチでがんばってたけど、上には遥か上がいると嫌でも知らされるな、こういうハード。
三角関数が抜けてた。
「覚えてなきゃ死ぬ」攻撃の理想的な含有率ってどのくらいなんだろう、とか考えたけど
世間の面白いといわれるSTGを観察すりゃ終わる話だしなー。
1つの難易度で初心者も上級者も楽しめるSTGの方法論ってのも無理があるかしら。
1面から最終面にかけて徐々に難しくしていけばよい話だと思うんだけれど、
ただ1面は稼ぎシステムが有効に使えないと上級者が飽きる。
俺はその点でガルーダはかなり上手いと思ったなぁ
憶えといっても
・来るとわかっていれば大丈夫なもの
・来るとわかっていても解法がわからないうちは安定しないもの
・解法の有無で難度が激しく変わる場合と、安定度が多少増す程度に収まる場合
・解法の知識ではなく、体得が必要なもの (解法がわかっただけでは実行できないもの)
いろいろあるな
こんな抽象的ではダメでもう少し具体的に書くべきかな
どの面白さもバランス良く含むのが理想、しかしいろいろな要素を入れてもそれぞれがつまらなければ失敗、
と書くのは簡単なんだが…
とりあえず開幕極太レーザーは何も面白さを感じない。
引っ張ってスマンが、一周N度方式を使うとき、atanの実装はどうするの?
atanテーブル作るけど?
>>583 パワーに余裕があれば素直にatan使う。
無ければ
>>205のみたいなテーブル使うかな?
(テーブルのサイズはNの大きさによって変える必要はあるけど)
しばらくスレ見てなかったけど
一応言っておくと
紅魔郷はおそらく256分割
敵から離れた所にいれば、自機狙いがよく当たらなかったりするよ
紅魔郷以降の作品は知らないけど
>>587 必死なのは結構だがヨソでやれや
うぜぇ
589 :
名前は開発中のものです。:04/09/17 00:03:02 ID:a0f2gCix
喧嘩でも始めますか?
狙撃弾が少々ずれる程度で大騒ぎしてるバカは余程凄いゲーム作ってるんだろうなぁ
試しに公開してみ?
それが出来なきゃおとなしくすっこんでろと
争ってる奴らが作品で勝負してくれるのが一番なんだがな。
テーマはボス戦の弾幕。
期限は一週間。
はじめぃ!
みたいなノリでw
>587>590>592
あーいえばこーいう
ガキ
うざ
東方が256度と指摘されて逆ギレした>520が暴れてる?
593がいいこと言った
ボス戦だけとはいえ1週間で1から作るのは骨だけどな
ゲーム作るまでには至らなくとも弾幕1パターンのモデルだけとかなら実現性はあるな
要は弾の”模様”だけとか
それでも結構面倒だが
自分で書いといてなんだが、白い弾幕くんと変わり映えしないから意味ないか
…まだやんのかよ
どうでもいい。
ちなみに、等分じゃないと方向弾が撃てないわけじゃないと思うよ?
方向なんて計算で出してるんだからさ。
for(cnt=0;cnt<88;cnt++){
angl = (cnt*ANGLE_MAX)/88 ;
とかやってるんだからさ。
なんか、真新しい感じのアイデア出そうと考えてくると、
どんどんアクションゲームっぽいまとまりになってくる。
アクションっぽいシューティングってどうだろうか。
>>600 素直にアクションゲームにしとけ。
漏れはアクション作成がメインで、シューティングは試作。
プレイヤーは既存のシューティングという枠でものを見がちなので
あまり既存の文脈に通じてない「新しい」ものをリリースしたいなら
アクションと銘打つほうが余計な先入観なく受け取ってもらえるかもな
シューティングと銘打つと、シューティングとしても文法にある程度沿ったもの
じゃないと取っ付きが悪くてやってもらえない可能性大。
604 :
603:04/09/17 08:06:37 ID:8qMx6btT
書いてる途中に直したら602と同じこと言ってるだけになったorz
アクションっぽいシューティング → アクションシューティングで木鞠
>>600 ここで問題なのは、nWay弾が等分じゃないと撃てないかどうかじゃなくて、
SSの88Way弾が見た目に綺麗に88等分になっていることだろ。
1周256度のテーブルで88Way弾を撃ったら、
間隔が2度と3度のところが混ざって綺麗な88等分に見える軌跡にはならない。
256分割で88wayだと角度が3の場所と2の場所が9:1で混在することになるね。
だから、間隔が他に比べて66%の場所が10個に1つ現れるはず。
でも、十分に広がった後の弾間隔を見てみても
66%になってる場所があるようにはちょっと見えない。
(実は196段階や88段階だったって可能性もあるけど)
でもこれは東方がその精度が必要だっただけ。
自分が作りたいSTGで必要な精度を用意すればいいだけなのに
なんで256って数字にこだわるんだろう?
弾の方向数の多さが、そのまま自機を正確に狙い撃ち
ではないところが・・・。
例えば動いてもいないのに、自機と正反対の方向へ弾を撃ってたり。
萎えるね。パッターンな弾幕に多いんだなーこれがw
いいかげん、そろそろ作業ゲーは勘弁!
だいたい段階を増やすだけなら、いくらでも出来るだろ( ´_ゝ`)
当たり判定が1ドットしか無いワケじゃあるまいし
不毛すぎる
しかし88wayってめちゃくちゃ半端な数だな
作った人は何で"88wayにしよう"と思ったんだろうか
>>611 1.テーブルサイズが88の倍数
2.何か元ネタがある
3.バランス調整のために増減してたらそうなった
たぶん3.だろうけど2.の可能性も捨てきれない。
まだやってんの。
ここの住人ならそれほど語るレベルの話じゃないと思うんだが…。
よく分からんが東方の世界では意味のある数字とかかもしれないな
作者はいろいろ設定みたいなのも考えてるみたいだし
88と言ったら神聖なるエリア88だろ。
東方なんてとんでもねー話だ!(大げさだが)
エリ8を神聖視するのはどうかとw
>607
>なんで256って数字にこだわるんだろう?
おそらく、角度を保持する変数が1Byteに収まるからでは。
まあ今どきのPCではこんなメモリ節約意味ないけど。
大量の実数演算の使用に抵抗が無いハードウェア能力に頼った富豪プログラミングか、
旧来の手法(つっても現役の技術だが…)を駆使し、実数演算を排除して最適化を優先
するか。
宗教論なんだよな。
ラクチンなほうがいいなあ。
メモリアクセス速度も結構馬鹿にならないから
マクローリン展開で求める方法もあるというのを
Gemsだったかどっかで見たような…
ただ収束半径の問題であまり大きな範囲の値を使えないってのはあるけれど
2Dシューなら普通に-PI〜PIの間に収まるから結構いいんでない?
もちろん256分割どころじゃなくFPU並みの精度で求まる
メモリをあまり喰わない方法としては
おおざっぱなテーブル+隙間は線形補間って手もあるね
ただ、今の計算機だと有効的に使える状況はほとんど無さそうだけど。
もうメモリとか気にするのは
へぼハードぐらいか
携帯のCPUだとFPUとかは期待できないんで自然とテーブル+固定小数を使った
手法に限定されるんだろうな
あんなんでシューティング作るケイブも相当なもんだな…
>>620 マクローリン展開なんて・・・
「こんなもん覚えたって一生つかわねぇよ!」
なんて言いつつ昔公式覚えた記憶が。
まさかこんなところで再び聞くことになるとは・・・
当然「まくろーりん展開」がなんだったのかさえ、既に記憶の
彼方なのは言うに及ばず。
テーラー展開とセットで覚えた記憶はあるんだけど _| ̄|○
>>620 > メモリアクセス速度も結構馬鹿にならないから
> マクローリン展開で求める方法もあるというのを
> Gemsだったかどっかで見たような…
自由に使える実装どっかにある?
何となく試してみたいな〜、と思ったりしたのだが。
いや、至って普通のマクローリン展開でしたよ(;´Д`)
sin(x)=x - x^3/3! + x^5/5! - x^7/7! +... って奴ですな。
templateを使ってループをインライン展開すると爆速だって話もあったかな?
ただIntel系CPUの場合はアキュムレータでループさせたほうがいいとかなんとか。
まあ詳しいことはGemsに書いてあるはず。俺は持ってるわけじゃないので…。
-PI〜PIで収束させようと思ったら何次の項までいるんだろ?
それによっては使い物になりそうなんだが……。
気になったのでちょいと計算してみた。
13〜14乗の項まで使った場合、sin,cosの±PIでの誤差は10^(-4〜-5)に収束するね。
ちなみに256分割テーブルでの最大誤差は1.2x10^(-2)
256分割テーブル+線形補間の最大誤差が7.5x10^(-5)
条件分岐を使っていいって話であれば
正負反転で-PI/2〜PI/2、sin,cos入れ替えで-PI/4〜PI/4まで範囲が限定できるので
もうすこし次数を落として収束させることは可能。
ただ、条件分岐多用して何が高速化だ?って話もある。
実は256分割というのは45度分であって1024度だったとか・・・はないか
1024になれば綺麗に追いかける弾でもまず精度は問題にならないねぇ
問題は面白いかどうかだ
いくら精度がよくても面白くないのでは意味無し
そして精度は面白さに直結するものでもない
おまいらそうやっていつまでも三角関数使わないのか?
>>632 別に特定地点狙うだけならブレゼンハムでいいし。
ただの思考遊びだよ。
ブレゼンハム、ってホントに使ってるのか?
斜め弾早くてOK?
>>630 Gemsによれば条件分岐使わないらしい
つまりループのインライン展開
FPUよりも速いとか書いてあった
でも俺はめんどくさいからFPU使ってるけど
>>632 色々な手法を模索するのは悪いことではないぞ?
現状ではベストではない手法でも
条件が変われば良い手法に化ける可能性だってある。
まあ何度も言われてるけど面白いSTGができれば何使おうと構わない
「そんな技術使わずとも面白いものが作れた」
「これを使ったおかげで楽できて、そのぶん面白いものが作れた」
どちらもある
どのゲームがどうなってるとか議論するより
それぞれのメリットデメリットについて議論するほうがいいんじゃね?
自分理論押し付けならよそでやってくれと
東方だのケイブなのそんなのどうでもいい
処理の選択をするための指針を論議するほうが意味があるだろ
最近だとためになりそうなのは
>>484-491,519,571,580,593,605 あたりかな
自分理論の押し付け合いでこういった良情報が流されるのはもったいない
というか、ココしばらくは東方だのケイブだのから離れて
純粋に技術話だったと思うんだけど……
ブレゼンハムを使って軌道、速度は別計算ってのに興味が。
どうやってんの?
実用性が気になります。
距離で割るだけじゃないの?
>>642 テキトーにググれ。オレもググった。
結論、今時使う理由がねぇ。
大きさが正規化されたブレゼンハムって
ただのベクトルベースでの処理の気がするんだが……
いや、ベクトルベースでの自機狙い自体はメリットも多いんだけどね
atan求めなくていいし、誤差少ないし。
自機狙いN-way弾(間隔θ)がちょっとめんどくさそうだけど
実は三角関数計算はsinθ,cosθをそれぞれ一回だけで済む(なんなら固定値で持ってしまえばいい)。
ただ、誤差の蓄積の関係上、自機狙い全方位弾は辛い。
>645
意味することは判るが、
何かものすごく変なものに聞こえるな>自機狙い全方位弾
もっと変な言い方をすると、奇数全方位弾または偶数自機狙い全方位弾のことか
偶数弾はこういう言い方のときは使わないほうがいいな…ベターな言いかたあったっけ
普通偶数弾は自機に当たらないものに対してのみ用いる言葉だが、
偶数個撃たれて自機に当たる全方位弾のことな
別に(全方位弾を偶数奇数の)区別なんかしねーか
ガルザカートって16方向(+誘導x4)なのに自機に当たるなあ。
命名案、固定型全方位弾、照準型全方位弾、演出型全方位弾。
自機狙い偶数散弾、自機狙い奇数散弾なら、そのままなんだけどな。
偶数弾は動かなければ当たらないから。
>>650 演出型全方位弾、ってどんなの?
自機が止まってれば当たらない、偶数弾みたいなやつのこと?
肝心なのは当たるかどうかかなあ
・自機が止まってると当たる (奇数弾etc.)
・自機が止まってれば当たらない (偶数弾etc.)
・自機が止まってても当たるか当たらないか不定 (遅延発射etc.)
まぁ作ってるときは名称気にしないな
奇数、偶数ってのがどうもわかんねーね。
敵がただ一発撃って、それで
・自機が動いてる 当たらない or 当たる(当たってしまう場合もある)
・自機が止まってる 当たって当然(故意 or ミスってハズしてしまう場合もある)
だと思うんだが。
>>652 動かなければ当たらない弾幕って、単体だと演出かもしれないけれど、
組み合わせると凶悪な障害物だと思うけどな。移動範囲が狭くなるし。
当たる当たらないの前に
射出方向が
自機位置に依存する・依存しない
じゃないかなぁ
>>656 そうじゃなくて、自機を狙った弾を中心として左右に等間隔で撃ち出すのを奇数、
自機を挟むように等間隔で打ち出すのを偶数、と呼んでいるんだと思う。
>>657 それ両方とも射出方向は自機位置依存でしょ
自機位置に対して
├ 依存するよ ┬─ 奇数弾
│ └─ 偶数弾
└ 依存しないよ ┬─ 方向固定弾
・
・
・
って話
自機狙い偶数弾(?) → 「奇数弾+1」でいいじゃん。
偶数弾に見せかけてるだけの奇数弾のことじゃないのん?
>658
やはりファンタジーと呼ばれるものを撃ったりするのか?
?
狙い方向を中心とした左右対称なN-Way弾の場合
奇数弾→中心の弾が狙い方向→動かなければ当たる
偶数弾→狙い方向がちょうど隙間→動かなくても当たらない
って認識で通常は問題ない。
ただ、全方位弾の場合、
弾の偶数奇数と狙ってる角度に弾があるのか無いのかは全くの無関係。
それなのにN-wayの時の慣習を使って実際の弾数と無関係に
当たるのを全方向奇数弾、当たらないのを全方向偶数弾と読んだりすることがあるので大混乱。
>中心の弾が狙い方向
だからその一発の精度の話をしてるんじゃないの?。
いや、敵弾を全て単発にしろって意味じゃなくてさ
つまり単発だとボロが出るからゴニョゴニョと・・・(ry
今は誤差の話なの?
N-Way弾と全方位弾の種別による呼び名がややこしいよな、って雑談レベルの話じゃないの?
いや、その話がSTG製作に重要か?といわれると微妙だけど。
衝撃波が広がってくようなエフェクトってどうやって作ればいい?
ドーナツ状の画像をジョジョに拡大してくしか思いつかないんだが、プログラムだけで作れないですか?
>>66 プログラムだけってのがよくわからんけど、画像を拡大するのがNGだとしたら
小さい画像を円形に配置して全方位弾よろしく徐々に拡大するとか・・・
>>666 TriangleFanで円形状のポリゴンを作る。
拡大がダメな理由って、衝撃波の幅もいっしょに拡大されてしまうから?
だとしたら
ドーナツ状の平面ポリゴン作ってテクスチャ貼って
外側の円と内側の円の間隔が一定になるように大きくすればいい
円を描くプログラムを使って、半径を増やしていくとか?
スト3の真昇龍拳の衝撃波はかっこよかったな。
>>669のは良さそう
ここはどんな質問もすぐにレスが返ってくるいいインターネットですね。
>>667 それだと結局拡大するにつれて荒が出るのでは・・・
>>668>>669 なるほど。2枚重ねるのは思いつかなかったです。
これなら幅は均等ですね。
試してみます。
>>670 凄い素直なやり方ですね。ていうか衝撃波っぽく見えなげな気ガス・・・(´д`;)
BGとパレットチェンジ
…ああっ
衝撃波用の、普通に塗りつぶしてある円を描いてから
それより少し小さく背景を描く透過円を描画するのは?
(円マイナス小さい円で輪を作る)
>>674 そうやって俺をイラつかせて、何をしたいんだ。
俺に恨みでもあるのか。それとも人をからかうのが好きなのか。
どちらにしても、お前は悪意をもって人を傷つけようとした。
こういう事はこれで最後にしろ。
ストリップで幅のある輪でいいじゃん。
なんかスクリプトが来てるな。
衝撃並とはちょっと違うかもしれないけど
エッジを外側に向かって伸ばす
エフェクト類はアニメとか非常に参考になるよ。
画像の荒れはあんま気にしなくて良いんじゃないかな。
見せ方と動きのほうがカッコ良く見せるためには重要だと思う。
でかいワッカ画像を用意して、縮小状態から元のサイズに戻すんじゃだめなのか。
荒さや衝撃波の幅が問題になるなら
拡大(縮小)用画像を何段階か用意するって手もある。
だからストリップでわっかでいいと何度言えば判りますか。
ポリゴン使えない環境はどうすんだよバーカ
>>684 んなもんでかいテクスチャのミップマップ使えばええよ。
685 :
684:04/09/21 02:35:49 ID:4JrSMSOm
>>683 パレットチェンジでいいんじゃないかしら?
>>683 ポリゴンが使えないなら別の案を出すだけ。
・矩形転送だけしか出来ないなら拡縮
・輪のエッジを算出してフィルで塗りつぶしてなんちゃってポリゴン
・2Dだけど半透明がつかるなら自力描画でポリゴン。
・任意変形スプライトがあるならそれで。
ていうか、2Dベースか3Dベースかで解が違う。
どうなんだ666
そもそもポリゴン使えない場合は、
表現自体かなり制限がかかるからな・・・。
>>666がどのレベルのものを望んでいるかによるわけだが。
小さいのから大きいものまでの絵を用意して順番に表示すればいい
最初から低スペック向けで考えない限り
ポリゴン使えない環境なんて想定する必要ないだろ
使えない環境というか、使わない環境で作ってるかもしれないけどな。
最近のPCだとかえって遅くなったり
つか、ポリゴン使えないから拡大縮小意外でって事じゃないのか?
そもそもポリゴン使えるなら、テクスチャ貼ってサイズ変えて終わりでは・・・
テクスチャ貼ってサイズ変えてってのは
ドーナツ状の画像をジョジョに拡大してくのと
どう違うのかね
このままじゃ無限ループだぞっと
お前の衝撃波なんか誰も気にしてねーよ(プ
まあ、適当にやっとけばいいんじゃないでしょうか。
自機に慣性のあるゲームの場合、最大速度の制限はどっちがいいかね?
1 Xの最大値とYの最大値で制限(斜め方向が速くなる)
2 総ベクトルの最大値で制限(斜め方向でも同じ)
圧倒的に2かと
もちろんエクセリオンタイプ
エクセリヲンと言われても糞ゲーってことしか記憶に無いんだが
エアバスターw
Zwei!タイプ
>696
商品にするなら2が無難。
ただの趣味なら自分の好みで選べ。
どっちにするか決めかねるならオプションで選択できるように。
あとは自機1号機と2号機で変えるとか、アナログスティック専用にしてしまうとかw
エクセリヲンは名作
糞ゲーだと感じた輩は己のセンスを呪え
おみゃーら様聞いてください。
リプレイを付けてたんですがフレーム毎のキー入力を記録して再現させようとすると
別のPC持っていったときどうしてもズレてしまいます。
どうしたら良いんでしょうか?
そのPCは例の浮動小数点の計算がアレなパソコンなんじゃね?
CPUはインテルやAMDなどメーカー系列が違うと、一方でうまく動いていたものが、
もう一方では動かない(動作表示が変わる)といったことが起きるらしい。
同じプログラムのものが、表示レベルで変わってしまうことがあるんだよ。
ネタじゃなくてマジ、2年程前にあった話。
仕方がないので、最適化されてると思われるプログラムを、まわりくどいやり方で
くずして、なんとか両方に対応させたことがある。
でも考えてみれば、Windows以前は、CPUどころかスペック一つ違えば
プログラムって変わって当たり前だったよね?
今もときたま、OSやコンパイラで吸収されるはずのPCの性能が、
プログラムによっては効かないことがあるのかも知れない。
最適化や裏技使ってたりとか、かなり特殊なプログラムの場合にそうなるのかも。
描画その他は機種で挙動が変わるのは当然だが
内部の計算で挙動が変わるようなものは使いものにならないぞ
規格どおり組んで挙動がおかしいならOSかコンパイラのバグだ。
アーキテクチャに依存するコード書いといて『挙動がおかしい!!』って叫ぶのは当人のバグだ
エフェクトの有無とかフレームのスキップとかで乱数の消費具合が変わるとか
いう初歩的なミスだったりしない?
どのような操作でどうズレるのかいろいろリプレイ作って、多少なりとも切り分け(できるかわかんないけど)
>>707-708みたいなお決まりな指摘は置いといて、
>>705-706に興味があるわけだが。
AMD機は持ってねーけど、IntelとAMDで完全に演算結果が同じとは思えんのだがどうなのよ。
四則演算程度ならIEEE754かなんかで保証されとるのかも知れんが、
三角関数命令とかSSEとか微妙じゃねーのか?
どっかそのあたり詳しく検証したものはないのか。
三角関数はともかくSSEは機種依存じゃないの?
今回は 707-708 じゃねーの?
とりあえず、何がどう狂うのかを挙げれ。
同じOSで動いている以上、計算結果が異なったらダメだろ、違ったら違ったで大騒ぎだ罠
研究機関とかで製品指定理由に搭載CPUが考慮されるなんてことあるのか?
エクセルでCPUチェックして計算結果補正してたらそれはそれで笑えるけど。
とりあえず704は詳細を書け
>>710 浮動小数の演算結果はINTELとAMDはもちろんいっしょ。
ただ、同じfloatでも
SSEの浮動小数演算とFPUの演算は結果が変わる。
(内部処理というかレジスタの幅が違うため)
ただ、CPUによってSSEとFPUを切り替えるようなプログラムを『自分で』書かない限り
そんな問題は起こらないと思うんだけどね。
もしくはそういった切替を行なってくれるようなライブラリを使ってるか。
だから固定小数点が最強って言ってるんだろ
当たり判定とかの内部計算にまで浮動小数点使ってたらド笑い
PS2じゃあきっと固定小数点を使ってるに決まってる
>>715 使ってないよ、少なくともウチは。
つうか、今時固定少数点使うとか言ってたら
ド笑いされるぞ、っつーかしてるぞ。少なくともオレは。
固定少数とか言ってる奴は既製の思考から永久に脱却できないんだろうなぁ
アマの戯れ言だと思ってくだされ
>>717 本職が組み込み系なもんで、趣味のゲーム作りでも職業病発動で苦しんでおります。
#define fixdiv(A,B) ( ((A) * divTable[(B)])
>>16 )
const int divTable[256] = {
0x0000,0x10000, 0x8000, 0x5555, 0x4000, 0x3333, 0x2aaa, 0x2492, 0x2000, 0x1c71, 0x1999, 0x1745, 0x1555, 0x13b1, 0x1249, 0x1111, 0x1000,
...
0x0113, 0x0112, 0x0111, 0x010f, 0x010e, 0x010d, 0x010c, 0x010b, 0x010a, 0x0109, 0x0108, 0x0107, 0x0106, 0x0105, 0x0104, 0x0103, 0x0102,
};
げらげらげら
>>710 いつの間にCPUが三角関数命令持つようになったんだ?
精度が必要なら浮動小数点使うし
速度が必要なら固定小数使う、それだけの話でしょ?
まさか片方でしか組めないからもう一方を否定してるってわけじゃないよね?
>>721 Pentiumにはfsinとかfsqrtとかの命令があるが・・・
「それはFPUだろ」ってこと?
>>722 精度?、速度?
根本的に勘違いしてない?
笑えることに今は浮動小数点計算のほうが速いことがあるというIntelCPU
好きなようにやって問題が出たら替えればいいじゃん。
つーか最近のパソ用CPUは普通に浮動小数レジスタ持ってるから
そっち使った方が演算は速い
昔からは考えられんな。浮動のほうが速かったり、2Dより3Dの描画の方が速かったり。
うんうん
3Dが高速に同意
ほんとDirectDrawで表示してたゲームを
DirectX8に移植したら軽いの何のって
なぜか2GHzのマシンでもたまに滑らかさを欠いたりしていたのが
ぜんぜん低スペックマシンでやったときも楽になって
浮動小数演算のほうが速いなんてことはいまのCPUでも無いぞ
大きな差はないって話なら分かるけどさ。
Pen4は浮動小数点について強化されているから
整数演算についてはPen3の方が同クロックでは高速らしい
つまり浮動小数点に最適化されてるみたいな
>>730 それはビデオカードのDirectDrawの実装が悪いだけだろ
大概はDirect3DのほうがDirectDrawで出来る範囲なら遅いよ
DirectDrawで出来る範囲のゲームなんて
今時ありえねーくらいショボくねぇか?
そう見えるなら、残念ながら神はあなたにクリエイターの資質を
雀の涙ほども与えてくれなかったのでしょう
2Dがショボいというのなら単なる釣り認定だが
DirectDraw自体は確かにショボい。つーかもう消滅してるし。
DirectDraw単体でできる機能がDirect3Dより遅いってのはまず無いだろうけど、
DirectDraw+テクニカルな実装がいるような状況だと
Direct3Dに任せてしまうほうが高速ってことのほうが多いだろうね(半透明とか)。
しかし、ビデオカードによってテクスチャの扱いがまちまちな現状では
ポリゴン使った擬似スプライトだけはどうしても使う気にはなれない。
ま、ドッド絵マンセー世代の戯言なんだけどね。
>737
テクスチャの扱いがまちまち、ってどういう事よ?
2Dスプライト的に使う状況で問題になるようなことがあるか?
そんなことより、Drawでも3Dでもだけど、
フルスクリーン時にはちゃんとリフレッシュレートを設定してくれ。
いちいちこっちで設定し直すのめんどくさい。
GeForce系とRADEON系以外は捨て
>>738 リフレッシュレートは設定しようにも動かないという場合が多い
DirectDrawは今よりもと高機能になる予定だったんだけどな
アルファブレンドとかAPIあるのになんで実装しなかったんだろうなぁ〜
>>739 Matrox萌えな折れはどうしたら・・・
凄い速い弾の当たり判定ってどうすればいいですか?
1.1フレームで移動した軌跡の線分として判定する
2.1フレームよりもさらに細かい時間単位にして判定する
この2つしか思いつかないんですが・・・
なんか前にもそんな話題出たような
まあ稀にすり抜けるくらいキニスンナ!
意図的にすり抜けるギミックは付けてるが、ビームには超高速タイプ含めて絶対に当たる。
ヘタなごまかしは効かないよ。ゲームがつまらなくなるぽ。
つーか、当たり判定は基本のきほんじゃないの?(だからこそ、重要。)
>>740 3D系PGを増やしたがっている、マイクロソフトの陰謀。
商業では、3Dプログラマーが2Dプログラマーを
見下す傾向が強いからなぁ・・・
よくある話でしょ
3Dなだけですごいとか言われたり
2Dなだけでショボいと言われたり
北米じゃポリゴン使ってないゲームはそもそも流通で蹴られるとか聞いたが。
PS2版怒首領蜂大往生の話だったかな?
あ、内部的な話じゃなくて見た目ねw
>>748 まあ、2Dで「真におもしろいゲーム」ができない者が、3Dやったところで
(静止画の)見た目だけってことよくあるからね。
とても遊べるもんじゃなかったりとかw
違うな、おもしろいゲーム -> まともに起動して動くゲーム でしたー
動かないんじゃ面白いかどうか評価しようが無いが。
よくわかんねーけど、2Dしかできない奴が、3D出来る奴を僻んでるのか?
なんかコンプレックス丸出しのレス多いなぁ。
とりあえずゲームのツボを押さえてなければ、
2Dだろうが3DだろうがダメってことでFA?
このスレ的には2D・3Dそれぞれの良い表現方法を模索するのがいいかもね。
全然関係ないけど、751のIDは危うく凶箱だw
ここでいう3Dシューってのはどういうの?
ここで言う3Dシューは、エスプガルーダやグラV等、
縦横シューの表現に、ポリゴンテクスチャを使ったもの。
最近では、ほとんどのシューティングゲームだと思います。
しかし、あれは見た目と内容が両立してるから良いのであって、
PC同人シューではよくあるけど、まず、
まともに動かないことにはゲーム評価できません!
3D表現もポリゴンにテクスチャでなくても、回転+拡大縮小等
スプライト表現でも充分おもしろくできると思うんですよ。
見た感じスーファミみたいな感じでもw
内容しだいで充分いけます!
(縦横シューではないし、最近やってないけど、
未だに、アフターバーナーやブルーサンダーとか大好きな自分ですw)
どうしても,3Dポリゴンでやりたいんなら、もっと
フライトシミュレータやCGフルアニメ等,沢山あるわけですから。
それと「まともに動かない〜内容を優先」と言うのは、
起動しないのではなくて、キー反応がわるかったり
異常に描画が遅かったり等、とてもゲームにならないと言うものです。
長くなりましたが、一応753〜756投稿者さんへのレスでした。
まぁ超連射68Kはおもしろいよな
エフェクトとか演出のこだわりがすばらしい
あれは3D化とかそれ以前のセンスの問題
あの粋にまで演出の技術とセンスを磨いてみたいもんだ
>>757 なんか最初の2行と後ろの4行を抜かした、間の部分の話つながりが良くわからんのだけど・・・
ポリゴンテクスチャ使った物が3Dシューとはねぇ...
しかもプリレンダも入るのか...
>>746 マイクロソフトの陰謀ってアホか。
じゃーPS2とかで描画は全て3Dになったのは、ソニーの陰謀か?
Drawが無くなったのは必然だろ。ソフト面もハード面も色々とすっきりするし。
2Dプログラマ見下すっつーか今時商業で、3Dが出来ない、とか言ってたら、
じゃーお前一体何すんの?って話だよ。
2Dしか出来ないヤツが不勉強なだけ。見下されてもしょうがないんじゃねーか?
リアルタイムポリゴンのみ3Dという常識的な定義で語るのが無難だと思う
というか、誰も今3Dの質問してない自然発生雑談なので、他の話題にしちまってもいい
でも別に2Dシューに限るスレでもないのに、FPvSとかの話は出ないよね。
まあ3D系の話をしたい人はフライトシミュレータとかの方へ行ってしまうの
かもしれないけれど。
>>766 >>200で飽きたからそのネタはもういいよ
>>765 3Dになると「シューティング」という名前が共通しているだけの別ジャンルに思える
スレタイには2Dと入ってないが、2Dに限ったほうがわかりやすい気がする
もちろんここの住人もFPvS作ったりはしてると思うから質問自体は問題ないだろうけど
2D3Dの差はゲームの面白さとは関係ないことくらい
ここの住人なら分かるだろ
>>766 ここの住人は、まさかこの程度のレベルじゃないよね?
2Dと3Dの問題じゃない。遅すぎ。基本を組む段階でダメポだ。
グラフィック含めて、その程度の処理内容なら超高速で動くはずで、
ウェイトをどう入れるかの問題になるはずだよ。
今のままでは、それベースにいくら内容を調整するだの、CG強化するなどしたってorz
残念だが、プログラムの素質がゼロとしか言いようが無い。
>2D3Dの差はゲームの面白さとは関係ないことくらい
表現手法が変わっても面白さは変わらない、と言う意味なら同意だけど
3Dと言う概念が存在するか否かってのはゲームの面白さに影響すると思うぞ
>>766 ぶっちゃけ、
凄く・・・つまんないです・・・
>>769 遅いか?
どのへんが?
766が2Dの面白いゲームとしてなぜこれを上げたのかは謎だが。
この作者が前から自演しまくってんだよ。
こんな小学生が作ったような糞プログラムを何回も見せられてマジうぜぇ
最初に出てきたときにちょっと反応あったから
味しめちゃったんだろ
ガイシュツだけど、敵や弾の動作を全てハードコーディングしてもいいと思う?
ファイル読み込みや中間言語うんぬんマンドクセって感じなので直書きなんだけど・・・
ソース汚いのと実行ファイルが異様に肥満するのが悩み・・・
>>766 つーか、いきなりぶち落ちて起動しません。
ところで製作技術かどうか微妙だけど、radmeの書き方って
みんなどうしてる?自分は未だに他人のreadmeをテンプレ
にして書いてる訳ですが。
>>775 結局、好みとスキルに合わせて、だと思いますが。
自分は、データ変えただけでexe作り直すのマンドクセので外出し。
あと、「ハードコーディング=ソース汚い」ってのは因果関係が
よく分からないのですが。
>>776 量が増えてごちゃごちゃする、って意味です。
汚いのは単に漏れが素人だからです。
ハードコーディングでベタ書きしてると微妙な数値とかコードががたくさん
ソース上に出てくるってのはあるな。それを好むか好まないか、ちゃんと管理できるか否か
ってのは作ってる人と環境によりけり。まあ動作のロジックとデータくらいは内部で分離
させといた方がいいとは思うが。
漏れとしては、状態変移の管理が面倒なんだよな・・・
何やってたか忘れるから。
>>777 スリーセブンおめ。
汚いコーディングは直せるとしても、ハードコードしてソース・実行モジュール
肥大って、当然の結果で悩んでも意味無いし。ガイシュツだけど共通化可能な
動作を式で代替とか?で、行き着く先はファイルに出す事になると思うんですが。
ファイルIOがマンドクセんでなくて理解してないなら、ム板行くことをお勧めします。
ハードコーディングだとやれることに制限がないぶん、敵の動きとかの凝り方に
歯止めがきかなくなって、細部をいじるあまり全体の開発が停滞して萎えたり。
むしろファイルに出すときに「ここまで制限があると作りづらい」と思うくらいの規格にしてしまったほうが
ことがスムーズにはこぶかも知れない。
ファイルに出すといっても、luaなどを使うとほとんど制限なくて
ハードコーディングなみのこともやれるよね?
ゲームに使うグラフィックって書くの大変でないかい
なんか簡単に綺麗な素材をPhotoshopで作る技みたいなのない?
>>782 どういう素材だ?
フォトショのフィルタで結構面白いもの作れるよ。
デザイン系の雑誌でよくテクスチャの作り方特集とかしてて
結構勉強になるから見てみると良い。
そういえば昔、(上から見た)雲のパターンを作るのに苦労したな
最近ではフルカラー&アルファマスクの恩恵を受けられるようになったけど
昔からの手ドット打ちの手法が使えなくなったのがつらい。
いや、使えるんだけどどうしても見劣りしちゃってね。
って、いちおう補足。
最近だとホントアレでしょ。2Dレンダでも
機械物→3Dプリレンダ
自然物→フォトショのテクスチャ
みたいな。
単にプリレンダやらフィルタのほうが手間がかからずにクオリティを維持できること、
そしてドットより個人差が出づらく分業しやすいことがメリットかと。
手打ちのドット絵で大きな絵や色数の多い絵は本当に大変だし。
うん。
>手間がかからずに
極端に言えばプログラムとは別個(スプライト 絵)の問題だからね。
それならプログラムができてた後いくらでもクオリティを上げられる。
漏れは、プログラムが完成してしまうとモチベーションが激減するので無理だ罠
俺はプログラムが終わってからがお楽しみタイムなんだがなあw
>>789 それってば、できたゲーム(開発途中含む)に満足してないからじゃない?
>>790 なんとなくワロタ。
お楽しみタイムってw
完成した頃にはもう遊び飽きて、次のゲームをどんどん創りたいと思う
同じゲームを内容も変わらないのに延々と修正してバージョンアップする人の気が知れん
趣味でやってる場合、納期がないからいくらでも時間かけられるでしょ。
だから一つのゲームに集中して、満足いくものにしたいのでは?
確かにずっと同じゲームしてれば飽きるだろうけど
また、しばらくしたら遊びたくなるようなものを。
でも完成したら、バグフィックス以外の修正はしたくない。
どの時点で完成とするか、趣味でやってる場合また微妙ですけど。
で、次はシューティングはもういいから、別のタイプのもの創りたい
そんなとこだね。
良い絵が偶然できてしまったときは
それをゲームで動かしたいからプログラムのモチベーションが高いかも知れない
>>792 そのジャンルに対する愛情の問題かと。
一途な深い愛情もあれば、広く浅い愛情もあると。
世の中には、深く広い愛情を持ってるお方もいるわけでつが・・・
漏れには真似出来ん。
ジャンルではなくて、ゲームでしょう。
その時、取り組んでいるゲーム。
同じジャンルばかりか、そうでないかで意味が全然変わってくるよ。
面白いゲームにするには調整期間がかなり要るんじゃないかなー
少しいじっただけでやけに面白くなったりするから馬鹿にできん
神のバランスとか言う奴かい
ゲームとかで+30%とかケチくさいなあって思うような事があるじゃん
あーいう風に少ないかなぐらいに設定するって基本なのかな
スレ違い発言スマソ
横スクロールシューティングに比べて
横スクロールアクションゲームって作るのって大変かな
重力を付けるだけじゃなく何かが必要とか
>>799 ゲームデザイン上の付加価値を作るのが難しいような気がする。
シューティングなら「弾を撃って避けるだけで楽しい」けど、アクションは
「ジャンプしてるだけで楽しい」というのはないから、その分を埋め合わせる
だけの面白さが必要になるんだけど…
スーマリレベルの「当たり判定つき地形」の存在するアクションゲームすら作ったことないから俺には比較できないや。
両方作った人がいれば経験談が聴けるかな?
具体的な方法論はアクションゲームスレ(あるのか?)に譲るとして。
システム的にはスクロールアクションを先に作ると簡単にシューティングへの応用が利く
グラやRタイプみたいな敵や弾が地面を走り回るゲームも楽
>>800 ジャンプする事で、敵や障害物を避けたり、
高い所に行けるようになったりすると(・∀・)イイ!!
でないと、ジャンプできる意味って無いよな。
>>801 レベルの低い所しかないの・・・(´・ω・`)
ワンキーゲームスレでも立てようかな?
>>802 ある意味、シューティングとアクションは、
ゲームの肝の所で、応用の効く部分が多いぞ。
風が…風がとまった!
…お父様の身になにか!?
鳥の鳴き声が…
ババさま、みんな死ぬの?
3分だけ待ってやる。
40秒で仕度しな
見ろ!弾がゴミのようだ!
そこでドラゴンセイバーですよ。
早くエクステンドしないと5機目が遊べないぞ!
なんかネタ投下してみっか。
戦車の砲塔の先から弾が出てるように見せるのに簡単な方法ある?
とか。
砲塔の回転中心座標から向いてる方向+距離で発射元の座標を算出できんか?
俺はそういうパーツには発射座標のパラメータ持ってる。
砲身が2本とか、オフセットがずれてるとかでも基本は同じ。
戦車の砲塔の先から弾を出せばいいんじゃない?
発射時に砲先に煙出してごまかす
画像解析アルゴリズムを用いて
砲台の弾発射部分を計算。
一定時間経つまで弾のアルファ値を0にする
>>819 それは楽で良いなあ。
エスプガルーダの大型砲台みたいな奴だと815氏のやり方にすべきかも試練が。
でもパースがあると楕円になってちょい面倒ね。
そんな至近距離の場合は弾封じで撃たせなければ良いんじゃない?
1ステージ開始デモ(エスプガルーダや怒蜂みたいな)作る場合、
関連するキャラのタスクのOnMove(毎回呼び出される関数)の中でif文で書くか、
専用のイベントシーンを作ってその中で全てのキャラ絵をイベントに沿って描画するか(デモが終わってからキャラのタスクを作る)、
どっちがいいかな?
STGに限った質問じゃないけど・・・
よくわかんないけど背景とか敵とかと一緒の扱いで記述。
>>823 見た目が自機と同じな別オブジェクト(敵と同等)として扱う。
>>824氏の言ってることも多分同じかな。
826 :
825:04/10/02 03:39:00 ID:235RvFAX
ああ、うん。
そう。
あ、俺824でした。
スマソ。
>>823 ゲームパートとイベントパートで、
同一オブジェクトを流用すれば良いのでは?
もしかして、グローバル変数を必要以上に嫌ってない?
グローバル変数はつかったらイカンですよ
イベント部分とゲーム部分、ルーチン分けてないし…。
ゲーム部で流用できればそれが一番楽。
グローバル変数とかgotoはヴァカと初心者が使うから収拾つかなくなるだけ。
必要に応じて使えばいい。
gotoは使わんな
まぁswitch-case/breakもgotoと同じといえば同じだけど
834 :
823:04/10/03 02:20:35 ID:7hKd8GUk
レスどうもです。
とりあえず
>>825の「グラフィックが同じの別オブジェクト」でやってみようと思います。
>>828 よく分からないけど、キャラのタスクにゲーム中とイベント用の動作を両方書くってことですか?
>>823の2行目と同じってことかな・・?
プログラム初心者にすらたどり着かない漏れがBulletML使ってみようと思ったんだが、
例えば初期位置から左右に弾を打ち続けるのを記述するのに、
<action label="top">
<repeat>
<times>600</times>
<action>
<fire>
<direction type="absolute">90</direction>
<bullet/>
</fire>
<wait>3</wait>
</action>
</repeat>
</action>
<action label="top">
<repeat>
<times>600</times>
<action>
<fire>
<direction type="absolute">270</direction>
<bullet/>
</fire>
<wait>3</wait>
</action>
</repeat>
</action>
とわざわざ記述してるんだが、
それはなんか間違ってる気がするので、どう記述するのがセオリーなのか知りたいんだが、
とかの値を複数指定する方法が解らないので、知りたい。
しかし、これから弾幕開発するにつれて、そういう初心者的質問は多発すると思う。
だから詳しく解説してるサイトがあればいいと思うんだが、なにぶんプログラムに関してもど素人なので
公式とか見てもイマイチ解らん。
そんな漏れが弾幕を開発するには、どうやて学んだらいいでしょうか?押してください。
まずはプログラムで直に動かしてみたら?
スクリプト系の理解もいいけど、まずプログラムになれないことには。
セオリーっつか、効率的な処理はそのうち感覚的にわかるようになるよ。
「あー、敵いっぱい出すのに一体一体 一々コード書いてたらキリないな」
と思って、とりあえず敵の宣言だけしとけばいいようにして、
なんかうまく行かなくて調べたらいい線まで行ってた、みたいな。
>>835 それを間違っていると感じられる嗅覚はとても大切だと思います。
<action label="600shots">
<repeat>
<times>600</times>
<action>
<fire>
<direction type="absolute">$1</direction>
<bullet/>
</fire>
<wait>3</wait>
</action>
</repeat>
</action>
<action label="top1">
<actionRef label="600shots">
<param>90</param>
</actionRef>
</action>
<action label="top2">
<actionRef label="600shots">
<param>270</param>
</actionRef>
</action>
あたりが良いかと。
840 :
835:04/10/03 19:46:10 ID:/O26POx0
レス有難うございます。
>>837 うーん、やっぱりプログラム習得してからですかね。順番としてまずはスクリプト程度を習得してそれから応用でいけるかなーと思ったんですが。形として出てくるし。
>>838 調べてもなかなか出てこない・・・
まずは経験ありきですか・。
>>839 なるほど。やっぱりそういうのってプログラム経験からですかね。
ある程度の分量のコード読み解けるなら、BulletMLの人が作ってる
STGのソースを読んでみるとか。サンプルじゃなくて遊ばせるため
の物なんでかなりの量あるけど、逆にSTGプログラムの定石みたい
なの山盛りでいいよ。
スクリプト言語とかならスクリプトからはいるのもいいだろうけど
BulletMLは正直仕組みがちゃんと分かってからじゃないとつらいような
XMLなんだからJavaのIDEのようにその辺はツールが解決というのが正しいんだろうけどね
こんばんは。つい数日前、VC++をはじめた。
とりあえず単純なシューティングゲームを作ろうと思い、とっつきがよさそうなelを落としてみた。
しかしなにやらDirectX9SDKに対応してないらしくコンパイルできない。
対応させたelを公開してないかと探し回ったがだめだった。自分で改造しようにも全くわからない。
ということで、その次にとっつきのよさそうなDxLibを使ってみた。うん、わかりやすくていい。
けど明らかにelのほうが使い勝手がよさそう。
どうにかする方法ないですか?
どうにもならないならDxLib使います。
>844
98 // DirectSound
#include "dplay.h"//add
99 #include "dsound.h"
低いバージョンで動かすためのやり方は
#define
忘れた。後で調べとくよ。
古いバージョンのDirectDrawを動かす場合、
共通のヘッダファイルに
#define DIRECTDRAW_VERSION 0x0300
と入れておけば、3.0を用いることが出来る。
5.0を使いたいなら
#define DIRECTDRAW_VERSION 0x0500
とやれば5.0が、
#define DIRECTDRAW_VERSION 0x0700
とやれば7.0が使える。
DirectSoundやDirectInputも、
#define DIRECTSOUND_VERSION 0x0500
#define DIRECTINPUT_VERSION 0x0500
と入れておけばいい。
elのヘッダファイルの先頭に、
#define DIRECTDRAW_VERSION 0x0700
#define DIRECTSOUND_VERSION 0x0700
#define DIRECTINPUT_VERSION 0x0700
#define DIRECT3D_VERSION 0x0700
#define DIRECTPLAY_VERSION 0x0700
と入れておけば良いんだっけ?
849 :
835:04/10/04 21:08:41 ID:OPxeCw47
>839
BulletMLはよく解らんが、一番単純なのはこれじゃないの?
<action label="top">
<repeat>
<times>600</times>
<action>
<fire>
<direction type="absolute">90</direction>
<bullet/>
</fire>
<fire>
<direction type="absolute">270</direction>
<bullet/>
</fire>
<wait>3</wait>
</action>
</repeat>
</action>
漏れもBulletMLは良く解らんが、
839のほうはプログラム的に見るとパラメータ変更で他の角度でも簡単に呼べそうだ。
851のは一番単純だね。
で、とりあえず836を押してやったヤツはいるのかね?w
いなけりゃ漏れがやるけどね(б´∀`)б)´д`;)コノコノ
プログラムを組めるのは当たり前で
面白い弾幕とは何かを考えるレベルになりたいものだなあ
がんがれ
いまどき弾幕を出す時点でゲームデザイナーとしてシロウト。
例えば俺
弾幕を真似られるのが普通のプログラマ。
弾幕を考えられるのがマトモなプログラマ。
んなこたーないだ
真似る事と思いつく事は誰でもできるが、
考えつく事のできるヤシは限られてると思うぞ。
真似をしたあとのバランス取りが問題かと。
避けてて楽しく感じられるかどうかは、ひたすらテストプレイしないと・・。
バランスと呼んでいるうちはまだまだ要修行。
何が肝かを特定し、それを応用できるぐらいにならんと。
弾幕を考えられるのはシューター
でも実際はパクリ
パクリA+パクリB+α=オリジナリティ
アイデアとは、99%のパクリと1%のひらめきですよ?
究極タイガーがじれったいのは自機のせいだなw
アレで判定が小さくなって速度が上がれば今でも楽しめそうだが。
高速弾切り返しは敷居は高いが楽しいぞ。
複数の属性を持たせて様々な変化のある弾ができないかなと妄想してみたりする。
無属性だと真下に撃つだけの弾で、(狙)属性で自機を狙ったり、(追)属性で追いかけたりする。
(連)やら(三)やら(分)やらが複数組み合わさって・・・なんかシレンみたいだな。
精霊戦士スプリガンのことかー!
違うか。
>>868 銀銃のことかー!!
ACとかABCとか「混ざったとは思えない仕様」だが。
1行目だけ読んで脊髄反射で
>>869を書いたが、よく読んだら敵弾のことなのね、反省。
敵弾の機能を組み合わせて敵の攻撃を作ることだったら
いくつも作ってれば普通にたどり着く領域だと思うから
違うんじゃないか?
真下とか自機とかだから敵だろうな
そういったエディットでSTGが作れるのは間口広げそうで良いかも知れない
いろいろできる環境があっても、やりたいことが一つでもできない(または非常な手間)ならやる気がしない、
ならいっそやれることはほとんどないがラクに作れる環境のほうが導入には向くかも知れない
Javaなどでいくつか導入があったが、あそこまで簡単であっても
(ゲームについてくるようなエディットモードに比べると)まだ敷居が高い
868です。色々説明足りんかった。弾は敵弾の方です。
ボスクラスの弾は流石にこの手法じゃ無理ですが
雑魚の弾のバリエーションってのは道中退屈させないためにも
変化が欲しいということでこういうのを想像してみました。
あと、できればLVも欲しいトコ。(狙)はレベルが高いほど精度が良くなったり
(追)ならしつこくなって(連)なら五連六連とたくさん連なったりすんの。
まぁあくまでも妄想なんで処理に色々矛盾が出たりするかも。
ザコの動き自体がしっかりしてないと、いろんな弾撃たせても画面が
だらしなく弾だらけになるだけで面白くはならん気がする。
いつかどっかで見た
「こっちが弾幕張るゲーム」をやってみたい
敵がドット単位の避けをしながら攻撃してくるんですね?
撃っても撃っても避けられちゃうと腹立たしいだけのような。
そこらへんが弾幕対戦STGが成り立たない理由かも。
自機が散弾打つSTGって、弾幕張ってるのと違うのか?
避けさせる為の弾幕ってことだろう
>>874 自機狙いは精度がある程度低いと、避けにくくなったりする。
逆に正確な狙撃はチョン避け安定する。
矛盾以前の問題だ。もっと精進しる。
>>874 どっちかってーと自機弾の方で生きるアイデアって気がするな。
出撃するときにプレイヤーが自機の弾幕の張り方を設定できるゲームとか。
で、画面上に一度に発射できる上限内で効率の良い弾幕を張って行かないとクリアできない。
多方向にするに従ってカバー範囲が広がるけど連射が弱くなる、
でもこのシーンは連射力が必要だ、とかさ。
武器切り替えで3種類くらい変えられると戦略性が出るかな?
そういえば工画堂の出したゲームで、
シューティングゲームのSLGがあったけれども、
そんな感じか?
ボタン押しで溜めてから放つと密度の濃い弾幕がぶわわ〜!とか?
ボス戦がだるそう
んじゃアイデア。
ボスのいろんなパーツがステージの中に配置されてて攻撃してくるんだが、
それをあえてスルーするとボス戦のときに残したパーツがくっついて
本体と一緒に攻撃してくる。
当然残せば残すほど厳しい弾幕になるが得点も超アップ…とか。
まあ単純に難しくしないとか得点が上がるだけじゃなくても良いかもしれん。
道中の行動がボス戦に影響を与えるというのはなかなか良さそうだね。
大抵のSTGでは、道中とボス戦が完全に切り分けられているし。
>>888 全3ステージぐらいにしておいて、ボスパーツを
全部スルーして、最強ボスモードにしてから倒すと、
幻の第4ステージが始まるわけだな。
同じステージを繰り返し遊ばせるなら、
これぐらいのボリュームでないと、やっとれんしな。
作る側も、遊ぶ側も。
>>888 そのルールをプレイヤーに教える方法が必要かと。
前提知識のないシューターは何も考えずになぎ倒すと思われ。
892 :
888:04/10/12 02:15:42 ID:45Gn9JKi
>>891 道中のパーツを破壊しやすいものと若干破壊しづらいもの(逃げるとか)をそれぞれ配置し、
ボス突入時に「破壊しなかったものがボスに装着される」ことを明確にする演出と、
「パーツを残したことによるメリット」の演出(破壊時の得点表示等)をすれば良いかなと。
ボスの難易度は破壊しづらいパーツを装着した状態でバランスをとり、
さらに楽に進みたければ道中のパーツを処理し、稼ぐならパーツを残すという選択を
プレイヤーが自分で選択できて、自動的に難易度に幅が生まれるのも良いかなと。
熟練者向きのシステムだと思うけどなかなかいいんじゃないか
「パーツを破壊して進むことは楽だけど、倒さずに進もうとすると辛い」
ぐらいの難易度にしておけば盛り上がると思う
でも一代限りのアイデアだよな…
破壊しないことを推奨するのは
シューティングとして矛盾している。
雷電のラスボス合体演出は結構ワクワクしたもんだ...結局安置逃げだったけど。
じゃ矛盾だな
ナイトストライカー・・・
>>894 頭が固い。枠を設けてしまっては発展が無い。
枠の中で何が出来るか
の方がこのスレの趣旨に合う気がする。
シューティングの醍醐味は、破壊の楽しさが第一かもしれんが、
避ける楽しみというのも、面白さの一つかと。その意味では、
自分で難易度を上げることが出来るというのも、
ある意味では妙案かもな。
それがルールというものなのか、雷電!?
どうでもいいよ。
作ってできたものがおもしろきゃ
903 :
888:04/10/13 02:36:18 ID:j8KRPElj
まあ888はまだ素案だしね。プレイヤーがストレスを感じないように、
うまくデザインできれば良いと思う。
でも893の言うとおり一発ネタというか、いろんなゲームに応用できる
ようなアイデアではないかな…。
>>888の「敵を撃たずに残す」というのは「敵を瞬殺せずに泳がせる」という
ゲーム(銀銃とかサイヴァリアとかガルーダとか)の延長だと思うんだけど、
「敵を撃たないシューティングはストレスが溜まる」というのが最近の意見
なんじゃない?
まあ、トレンドに乗るだけがゲームじゃないけど。
905 :
ROM:04/10/13 21:32:53 ID:yBEKcIkw
2DSTGスレ住人だが、個人的に敵を撃たなかったり撃つタイミングを調整したりっつーのは嫌い。
でも、それを理由にこのスレで話し合わない理由はないと思うが
でもまぁ、「出現した敵をかたっぱしから撃つ」STGはそれこそ山の数ほどあるわけで、
差別化を狙うならばアリだと思うけどね。
従来のSTGとはまた違う爽快感をどうやったら出せるかな。
耐えて耐えて耐えて一気にドーン?
でも強制スクロールだと「一気にドーン」が難しいな、敵出現関係とかで。
自機を追尾する感じの敵を作り
ゾロゾロ群を引きつれてから連鎖爆発。
>>905 あんたが嫌いかどうかはどうでもいいわけだが。
そういうあなたの意見も負けず劣らずどうでもいいよ
耐えて耐えて一気にドーンといえば、怒蜂2だな
信者には叩かれてるけど、俺はあのシステムかなり好きだったよ
究極まで詰め込んだのがバンガイオー
溜めて出すって気持ちいいわね
>>906 レイシリーズのロックシステムはまさにそれでしょ。
それだけだと、もう既にあるものだけど
レイフォース初めて遊んだ時は新鮮だったし、
このシリーズは十分爽快感ありありだと思うよ。
何でも新しいシステムやルールは、
最初は、やったことがないものなので実感できないけど
実際に動くものを遊んで初めてわかることだからね
なんか想像するなー。
ゲーム中盤に、画面下から砲台パーツつきのユニットが移動してくるの。
普通に撃ってるだけだと砲台は壊れて耐久力高いユニット画面上に消えていって
ボス戦で砲台の壊れたユニットが装着。砲台は壊れてるから攻撃力は無いけど
ボスの耐久力が増えるからボス戦に時間がかかる。
耐久力を減らすために道中のユニットに撃ち込んで倒しておけばボス戦が楽になるが点は低い。
逆に撃たずに砲台を残しておけばそのユニットに砲台ぶんの倍率点が加わるの。
レーザーユニットと追跡弾ユニットが同時に上昇してくるけど、時間的にどっちかしか倒せないとか
それとは逆に、扉を撃つことでユニットの封印を解いてボス戦が激しくなるものとか、色々想像してしまう。
>>913 個人的には、同じキャラの得点が上下するのは、あまり好きではないな。
ユニット同士のドッキングは、シチュエーションによってはいいと思うけどね。
(914のつづき)
レイシリーズのロックオンレーザーも得点に倍率かかるけどね
単純にかっこよさだけで、得点のことは気にしなかった。
パーツ残してボス戦云々ってシステムだと得点増加させないと意味ないよ。
得点じゃないメリットを考えるなら話は別だけど。
ボスキャラの攻撃が派手になるとか?
完全体にしてから倒すと、隠しステージに入るとか?
ループしてるぞ
最低でも、完全体ボーナス得点ぐらいは欲しいよな。
ボス戦直前まで得点倍率が上昇していけばパーツ残すメリットになるんじゃ
だんだんと妄想スレになってきたね
結構なことだ
弾が画面外に出る判定って
設定してる画面サイズを超えた場合とあとなにかある?
ウンコ
ワロタ
>>923 画面外に破壊不可能なオブジェクトを用意しておいてそいつとの当たり判定。
一定時間が経過すると自爆。
いいかげんクソゲー宣伝するのやめたら?
何回も何回もやるとこ見たら自分は良くできてるとおもってるんだろうけど
はっきり言って小学生レベルだからさ。
まあ領域越えたら削除が特に軽そうだな
誰もやってくれる人がいないので見て欲しかったりする訳よ
まあ スルーで 敵の出現はウェイトを混ぜながら時間差で出現が普通みたいだね
そこら辺はわかった.
>>924 あー、なんかもう、プログラミング初心者が最初に作る典型的シューティングって感じだな。
シューティングに最低限必要なフィーチャーを何も考えず実装するとこういうのになる。
同じようなシューティングはネット上にたぶん軽く100本は転がってるぜ。
俺自身も大昔に作ったことがある。
俺が言いたいのは、
気持ちは分からんでもないが、とっとと次のゲームを作れ。
ちゃんとゼロからゲームデザインして。
>>924のイカベーダー
確かに何の特徴もないし、普通すぎるけど
だいぶよくなってきてると思うよ。
最初の頃なんて操作反応が遅かったり、
画面がのろたらしててもう、散々だったもんね。
でもホント、いまは十分たのしめるものになってる。マジで。
確かに動作軽くてゲームになってる
でも背景は流れ星だけだし
キャラとか弾とかのイメージがチグハグしすぎ
絵を上手く描けなくても、もうちっとやりようはあると思うけど・・・?
まぁあとはセンスの問題か
どのレベルで評価するかによるな…。
まぁ、死ぬほどダメじゃあないよなぁ。。
はっきりいってこれより酷いのも結構あるのが事実だとおもう。
だからといってこのレベルで張るなっていいたいがな。
もしおまえのようなレベルの作品を張るやつがこのスレにたくさんいたら
このスレはクソスレになるだろ?そんくらいわかれ。
このくらいの頻度なら貼るのはかまわんと思うが、自己満足っぽいし
なんか褒めて欲しそうな意図が見え隠れしててイタタなのが叩かれるんだろ。
そもそも、話題に出来るようなLvのヤシが、
こんな所に張るメリットなんてあるのか?
というか、デメリットの方がデカイと思う。
まあ俺は
>>938に同意かな
シューティングそのものの内容の問題じゃないよ。
まあ内容についてだが俺は背景も弾もこんなんでいいと思う。
その辺は俺的には「やる気なシュー」レベルのグラフィックがあれば十分
とにかくイライラしたのが画面外に出ずにうようよしつつ弾撃ってくる敵が
0距離射撃しまくること、しかも接近前に落とすのが非常に難しい。
このタイプのゲームを作りたいのなら一般的なアケシューを勉強したほうがいいと思うが
追加でもうちょっとやってみての感想
自律行動な敵を大きく回避しつつ切り替えしてれば道中は大丈夫
中ボスの打ち返し弾とかの組み合わせはなかなかいいかなと思いましたよ
音楽も結構いけてると思った
あとコンボについてはオマケにしか過ぎない(切れやすいし配置や敵の行動のこともある)
まあ「とりあえずコンボ表示」ってのがまさしくシューティング製作初心者って感じだな
実際に怒蜂とか大往生とかやってみればわかると思うんだが
この程度のコンボならバッサリとシステムごと捨てるべきだと思いました
あと中ボスっぽいのを早く破壊したときとそうじゃないときで続きがあったりなかったり?バグっぽ
初心者の特徴
・背景は星
・敵の出現がランダム
・とりあえずコンボ表示
orz
3つめは流行に左右されやすい初心者の特徴を表しているかもしれんが
最初の2つは奥が深いぞ。
ソースもはってくれないなら、そのへんのアケシューのほうが勉強になる。
完成してもいないのにはるなら、単なるテストユーザとしてしか見られていないようにも感じる。
あるいは褒めてくれっつーことか、よくがんばってるとでも言ってもらいたいのか。
まだ「評価」の段階ではなさそうなのが正直な感想。
いや、俺からしたら実際がんばってるというか着実に一歩ずつは進んでるように思うんだけど。
製作途中で何かしら衝撃を受けたとき、ふと気が付いたときに化けそうな気が…する。
自分との比較対象がいない(わからない)から
ここに張るべきレベルかどうか判断できないんじゃないの?
おまいら模範を示してくださいよ
そこで話題になるような作品と比較されたら初心者はつらいんじゃ…w
これだけは付けておけ、みたいなガイドラインとか考えてみないかい?
脱初心者って事で
それはまた別のスレのような。
あんまり荒まず、自分が初心者(?)だったときの気持ちを忘れずに、適度に優しくしてやれよ。
うpするやつも、何のためにうpするかを明確に。
遊んで欲しいのか、技術的なものを見て欲しいのか、ゲーム性を見て欲しいのか。
罵倒されたくないなら、意思疎通はきちんとな。
はっきりいってそこにあるやつ未満のやつは
ここに張る価値まったく無いと思う。
ソースがあるでもなきゃね。
はっきり言うとそこの先頭にのってるやつどれもツマンネ。
ゲーム性で見ると、イカベーダーのほうが遊べるよ。
見た目で勝負すんのは、コンシューマーや
アーケードにしてくれ(ビデオチップではじかれるのは勘弁。)
どれが見た目で勝負してるのかよくわかりません
漏れも948が買いかぶり過ぎてると思う…つーか中の人だしょ
どうもクソマシン使って動かないと文句言ってる奴がいるな
イカベーダ こんな感じで敵の配置にスクリプトを実装し始めた
値はすべてchar
00 ENEMY [種類][X座標][Y座標]//敵を配置
01 WAIT [時間]//ms単位で停止
02 SOUND [種類]//SEを再生
03 MUSIC [種類][動作]//音楽を再生 動作で再生,停止を指示
04 IF [種類][値]//種類が値を満たしたら下へ進む
05 GAME [動作] //00 クリア 01 ゲームオーバー
命令は増やし中 00〜03は実装できた
今までの配置は一定時間毎に一行分の敵を呼び出すって言うシステムだからツマンネーのが分かった
スクリプト式はなんだか高感触です 初期のランダム配置の頃の絶え間なく出てくる敵を避ける面白さに近いものが
ここはお前の日記じゃ(ry
テキストのパーサを作るのは後回しでバイナリエディタで配置してます.
ま、クソユーザーよりはマシだな。
>>958,960
上のはあんたに言ってるんじゃないよ。
これからもがんばれ
基本的な部分ができずに、ただ見た目やエフェクトだけのゲームよりずっと良いよ。
土台がしっかりできる人のようだから、最終的には3Dや
見た目で勝負しても上等なはずだ。
普通につまらんが。面白い?
好みといわれればそれまでか。
あ 公開してるのはまだ旧システムのままだよ
更新はまだ先
うぜえなこいつ
966 :
名前は開発中のものです。:04/10/16 02:50:15 ID:SPf0tNVp
>>950,952
ここのレベルが高いという事で、叩かれるの覚悟で
昔作った偽ガルーダのソースを公開したいと思ってます。
内容はパクリなんで、技術的なもので、ここはこうしたら?
というのを参考にしたい。
それは期待する。
以下ベーダみたいな自己満足貼られても叩きと擁護レスしか付かんし。
・他人がみても得るものが何も無い、張る意味がわからん
これに尽きる、自己満足といわれる所以もこれだし
そんなに悪くないぞと擁護されることがあるのもまぁ然りというか…
>偽ガルーダ
以前某スレで見たような・・・
おまえら本当にプログラムしてんのかと。もしくはゲームの製作を。
ゲームの内容を評するのは結構だが、居るスレ間違ってるんじゃねーのかな。
(マルチポストして叩かれるのもしょーがないとは思うが。)
>>958 ランダムが面白いならそこを追求するのも良し。より面白くするためにランダムをあえてはずすのもまた良し。
どんどん作って、他人のソフトと比べて開発すすめれ。
ランダムなんぞ調味料にすぎない。
入れる奴もいる。入れない奴もいる。
早い話ルーチンワークが大好きなプレイヤーもいれば、
嫌いなプレイヤーもいるってことだ
一応、フォローを入れるなら、ルーチンワークを捜し当てて、
それを完璧にこなすのが好きなだけで、
ルーチンワーク自体が好きというわけではないぞ。
ここ昔と雰囲気変わったよね
ランダム要素はやっぱり面白さの中には必要ですよ。
そしてランダム要素を攻略パターンによって封じ込める攻略が面白い。
それほど忙しくないなら、プログラミング経験が無い人でも
適当な描画ライブラリ使えば、半年ぐらいがんばれば、そこそこ遊べるのが作れると思うんだが
おまいら、DirectX9.0SDKになってから楽になってますよ。英語のドキュメントもみなきゃならなくなるが
今年でたSDK使えば絵を表示するまでは結構すぐだから使ってみれと。
>>974 前からいるがそんな変わったとは思わんが
>>974 そういや今は、自作ゲーを張ると叩く奴がいるよな。
まあ、昔と違うのはそのぐらいか。
技術的なスレで単に「遊んでください」と言ったら叩かれるのはしょうがないね。
スクリプトの話がちょっと出てたみたいだけど、
「敵制御のスクリプトをどういう構造にするとデータ入力が楽か」とかその辺りのなると面白いかも。
981 :
名前は開発中のものです。:04/10/17 00:20:17 ID:sKQjhGOP
>>967 では頑張ってみます。コード整理等に時間下さい。
どういう感じか、大雑把に言いますと、
C++で記述、DX9.0、STL、XMLパーサ(COM)を使用、
OOP、デザパタをテスト的にゲームに組み込む(お勉強)が目的。
・グラフィックエンジン(中身はDX9.0のラッパー)
・ゲームエンジン(汎用的なゲームアプリクラス、タスク管理等)
で、1プロジェクト、スタティックライブラリでビルド
もう1つは偽ガルーダプロジェクト、
現在はキャラクターの概念(プレイヤ、敵、敵ボス等)ごとにクラス化、
敵nの状態Aという単位でクラス化、完全ハードコード
(ここが微妙な所。理想としては、ツールでオーサリングがメイン、
例外ケースをハードコードで記述、リソースデータを上書き、もしくはバイパスする。なのかな?)
後は、オーサリングツール。
C#で記述、リソースはXMLで吐き出しで、
・マップ画像構築&敵配置ツール、
・アニメ編集ツール(未完成)
も添付しようかと。ソースは、C#入門レベルなんで、付ける意味ないかもです。
>>969 ここでしか公開してなかったんですが、晒されてたのかな?
×BuletML
○BulletML
G-わんげは既に風呂敷広げすぎてる気がするんだけど大丈夫かね。
コードで書くのも結構楽、まぁ素人のたわごととおもって…
開始フレームで「ステージ1」と表示するタスク出現
そのときから60フレーム経過で敵1が出現
またそのときから60フレーム経過で敵2が出現
void update(){
int cur = 0;
if(count == cur)InsertTask(new TextDisplay("ステージ1", 60));
if(count == (cur += 60))InsertTask(new Teki1(100, 10, 10,);;
if(count == (cur += 60))InsertTask(new Teki2(100, 10, 10,);;
/*
ひたすら出現コードを書く
*/
count++;
|
for文とか制御文使えるから規則的に敵が出てくるスクリプトとかが楽でねぇ。
負荷はちょっと気になるけど
>>985 最初から最後までif文でやるのは流石に…。
どうしてもfor文とか使って制御したければ
オブジェクトジェネレータをスクリプトで起動すりゃいいのよ。
>>986 そこなのよなー、俺もスクリプトで作ってて
オブジェクトジェネレータ生成してたんだけど
今作ってるゲームだとそういうのがかなり量必要になって
それならスクリプト意味ね-じゃん、って思い初めてね。
ひたすらif続けるって書いたけど実際にはステージタスクに記述してる。
そろそろ次スレの季節です〜
よし、俺が
>>990に新スレ立ててくれるように
頼んでくるからちょっと待ってろ。
ごめん、おれホスト制限でスレ建てられないんだよ
待機中の微妙なこのタイミングで質問でつ。
Vsyncを待つ場合、60fpsだとすると処理が1/60秒を僅かでもオーバーすると描画がスキップされるから30fpsになるって聞いたんだけど、
これって本当?
真偽だけでいいので、bool値で答えてください。
true
アケシューなんかプレイしてたら分かることだろうが…
スキップではないな
>>992 thx
アケシューって意図的な処理落ちしか見たことないけど・・・
いくらでもあるぞ。わかりやすいのはグラIIIとか…って普通置いてないか。
エスプガルーダは分かりづらいしな。
駒落ちと処理落ちを近藤してないか
字刷れまだか〜
998 :
5週目1面:04/10/18 02:45:27 ID:oCJmbNzb
いわゆるアーケード処理オチしたければ
処理>フレームフリップを絶対に交互にやるようにすること。
ただし処理オチして全体が1フレームに収まらなかったらフレームフリップをVsyncに同期させずに
描画が終ったら即座にフレームフリップとする。
そうすれば主観的には30FPSではあるだが、1秒で45FPSとかになるんで、たしょうマシな感じに。
大前提として、たいていの落ちて欲しくないところが1フレームで動くようにしなきゃ処理オチしっぱなしになる。
Windowsじゃマシンスペックで大きくフレームが変動してしまうのでターゲットで納得いく程度の動きでバランス調整
するしかない。
>主観的には30FPSであるだが〜
瞬間的には30FPSではあるのだが、1.5フレームくらいの進行なら1秒で45FPSとかになる。(のでマシなきがする)
つまんねー1000になってしまった。ひゃはあー。
1001 :
1001:
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。