シューティングゲームを作りたい！！

初心者なんですが・・・作れますかね。
よくありがちな、縦（横）スクロールであるタイミングで敵が
出てきて、敵がタマ打ってきて、敵やっつけて＾＾；。
どうなってるんでしょうか・・・。

やはり、そういったプログラムを一度読んでみるべきですかね。
手に入るのかわからないですが・・・。

まず調べろよ。
本でも、ネット検索でも。
それでどうしても分らないことがあったらここに聞きに来たら？

>>1
http://www.google.com/
どうぞ。

>>1
とにかくさぁ、シューティングツクールなんかで作ってみろよ。
明確な目的も決まって無いのに、いきなりプログラムは無駄！

なかなか参考になる
http://mentai.2ch.net/test/read.cgi?bbs=kyoto&key=969000016

>>1
とりあえず、インベーダーかギャラクシアンかギャラガあたりを
『自力で』コピってみれ。どんなやり方をしても構わん。
他人がどうやってるのか探るのはその後でよかろう。

本格的につくるつもりなら4の言うとおり！
遊びのつもりなら・・・。

10 入力
20 移動
30 表示
40 GOTO 10

初期化がない

Syntax Error in 10
Ok
■

new
Ok
■

system

ここでも参考にしてがんばってくだちい。>>1

アーケード板「ギコディウスを作ろう」
http://yasai.2ch.net/test/read.cgi?bbs=arc&key=982466986

ここでも参考にしてがんばってくだちい。>>1

http://giggle.cside6.com/hotate/index.html

ギコディスがでたので、これも
http://piza.2ch.net/test/read.cgi?bbs=mona&key=983053600

思ったよりつくりがしっかりしてて、完成度高いし・・・。

最初は誰でも初心者。
絶対に完成させると意気込んで作り始めてみな。
そうすると、今の君に作れるか作れないかわかるよ。
他人のソースを読むのは、慣れてないと案外大変だから、
自分で作り始めた方がいいかもね。
ま、がんばれ！

とりあえず「インベーダ」ではなく「ギャラクシャン」を目指しなさい。
実は「インベーダ」の方が作るのが難しいのだ。

>この勢いで「ゴルァーガの塔」も作ってほしいナ・・・。

1よ、シューティングはやめてこっちを作れ。

すいません、インベーダーとギャラクシアンの違いを教えてください。

1はもう死んだのか？

>>19

17じゃないけど回答。

インベーダーは敵の列隊が左右に動くとき、残っている右端と左端の列が画面端に着くまで移動し折り返るけど、
ギャラクシアンはそんな動きしないので移動時の折り返し位置の判定が不要です。

ギャラクシアンは飛んでくるじゃん。

>>22

そっちは大した処理でも無いだろ。

インベーダは”どの列が端の列か”を一々検出せにゃならんのよ。
例えば右端１列をすべて倒すと、その時点で列隊の折り返し位置が変わるだろ？
この判定がウザイつーの。

↓の人達へ。煽らずマターリでいこう。

>>23
なるほどね。
仕組み考えると面白いナリ

インベーダーはバリア（？）の処理がめんどいんじゃない？

>>23
なんでなんで？ 至って簡単だと思うナリが。
こんなんウザイゆーてたら何も作れまへんで。

＞ギャラクシアソ
隊列編成や攻撃の際の動きをいかに華麗に見せるか
アレコレ工夫するのも楽しそうですね。つーか萌える。

>>27
そりゃ煽りっぽいですよ。
主観の相違を気にしちゃなるめぇよ。人それぞれさ。

思わずMAME起動してみたりしたが、どう見てもインベーダのが簡単ナリよ。
時代が古いからとかじゃなく、内容的に。敵は単純な二次元配列でいいし、
折り返し位置は敵を倒したときに再設定すればいいでしょ。
（個々の敵を今流のタスク管理でやっちまったりしたら逆に面倒かもね）
バリアはビットマップで持っといて、当たったら特定のパターンで消すだけ。

ていうか、そこまで完全移植する必要もないんだけどね。
＃折り返しやバリアが面倒っちゅーならやらなきゃいいんですから。

最近の人達はシューティングの面構成や攻撃パターンを
加工するときってどうやってるんだろう？やはりBCBとかで
GUIなオーサリングツールのようなもの作ったりするのかしら？
う〜ん、か、かっこいいかもしれない。

私自身はPC-98の頃に趣味程度でチョロっとしたもの作る
場合が多かったんでテキスト形式のファイルにシコシコと
手打ちでスクリプト(テーブル?)書いてました。（つーかこれヘタレかな

インベーダの場合、防波堤があるでしょ？
それ難しいのだ。
１Dot単位で穴が空いてたしね>>オリジナル

だから、ギャラクシャンの方が無難だね。

あるいは防波堤のないインベーダだとか。
試しで作ってみるにはいいかも。

>>32

マターリな。
「難しいのだ」といきなり断言しても無意味でござそうらわずや？

>個々の敵を今流のタスク管理でやっちまったりしたら逆に面倒かもね

ごもっとも。あの程度のオブジェクト数なら難しく考える必要も無いか…
生き残りの敵を全て調べて折返し位置設定しても大した処理でもないし。
まぁ折り返しとバリアを考慮しない分だけはｷﾞｬﾗｸｼｱｿの方が楽つーことで。

あっと、折り返しについてはかなり迂遠だった。
単にどれかのインベーダが画面端に当たったら
全部のインベーダの進行方向を変えればいいですな。ほらめっちゃカンタン。

>>32
ま、インベーダの頃はグラフィック面直書きですからね。

だんだん面白くなってきたぞ。
単なる駄スレではなかったぞ。

漏れはこの本でしゅーちんぐの作り方を学んだよ。
Turbo Cゲームプログラミング PC-9801シリーズ / 青山学/共著 日高徹/共著
http://shopping.yahoo.co.jp/shop?d=jb&id=18763073
98エミュと Turbo Cがあればそのまま試せる。
古本屋になら売ってるかも。

>>35
さっき気が付いた。
敵一匹ずつObjectとして管理しようとするクセが抜けない自分駄目スギ。
鬱山車脳。

>>36

たまには駄スレを救済してみるのも悪くないナリよ。
1が登場しないけれど、皆でスレを育てれば何とかなるさ。

>>37

な、懐かしいタイトル。中身はよく知らないんだけど
93年頃には本屋でよく見かけた憶えアリ。今でも置いてあるんかな。

ところで今までシューティングゲーで「これどーやってんの」みたいな複雑なアルゴリズムってある？

とネタふりするテスト。

>>31
云われてみれば確かに。今じゃこれだけ便利なツールに囲まれてる
わけだし、そういうスタイルが定着しても不思議じゃないですね。
実際のところどうなんだろう。＞最近の趣味ゲープログラミング事情

DirectorやFlashライクなツールで、シューティングのバランス
調整とかしてる図を想像。絵になりますなぁ。（； ´Д｀）ﾊｧﾊｧ

雷電IIのプラズマレーザー（紫色のクネクネ曲がるヤツ）の実装方法教えて。

どうも、遅れまして、駄目スレ立てました１です^^;。
スレ立ててから次に回線つなぐまでちょいと時間がかかってしまいました。

レスの数々どうもです。
そうですね、やはりまずは自分で調べるべきですね。良いＨＰを紹介して
くれた人もいるようで、ありがとうです。勉強してきます。

目的なんですが、シューティングが作りたいというよりは（まぁ作りたい
んですが）、趣味でゲームプログラミングしたいので、まずはゼビウスの
ようなゲームを作れるようになりたいという思いがありまして。
上達したいという方が強いです。こういうゲームのアルゴリズムの部分
をまだ覗いたことがなかったので。とりあえずいろいろやってみます。

http://faculty.web.waseda.ac.jp/parity/professor.html

プラズマ教授とセイブ開発を絡めるのか（ﾜﾗ

ゲームに使われているアルゴリズムって、教えて貰うとめちゃ
単純なんだけど、普通こんなの思い付かないって物が多い。
「この処理どうやってんだ？」と思う事でも、作った人にに聞い
てみたらすげー単純な事だったり…。

>>47
そーそー。
よくもまあ、そんな簡単に出来たなぁと感激する事が
多々ありますよね。

>>48
昔はマリオのジャンプが再現できなくて泣いてましたよ
その後、数学の授業で放物線を習ったときには
喜びのあまり小躍りしたもんです

>>49

えーっと、質問。
数学で習う放物線は、物理の天体の軌道などで使いますけれど
地上わずか数メートルを飛び跳ねるマリオに適用しても大丈夫
なんでしょうか。

だいじょうぶでしょ。

>>50
もちろん問題ない。

というか、放物線を使わないとデコゲーになってしまう。

>>51
>>52
いや、これをあえて選択するのは辛いということなのでは。
http://130.158.186.11/mathedu/forAll/kikou/labo/stconic2.htm
http://www2m.biglobe.ne.jp/~funatsu/advanced5/fnat33par1.htm

>>50
むしろ、数千メートル以上飛び跳ねるマリオには
採用しないでください。

速度とか加速度みたいなのって、
作るうちに自然に出てこなかった？
それが速度かどうかなんて、後で知ってへー？みたいな。

だからかしらんけど、はじめおれはx軸の加速度が理解できなかった(藁
y軸の加速度＝重力ってわ置き換えてすぐわかったけど。

マリオはこれで良い。

/* 重力加速 */
vy += g;
/* 空気抵抗もどき（縦の速度抑制） */
vy *= 0.98;

x += vx;
y += vy;

雷電のプラズマレーザー……すまん、考え中だ。←ヘタレ

>>57
それ以前に、誘導兵器一般について標的の選択

雷電のプラズマレーザーはデカブツを優先的にロックしてたかしら。

http://www.getplus.co.jp/ProductImage/170211.jpg
これか。

曲がりっぷりがイマイチだけど、プラズマレーザー発見。
home.earthlink.net/~wshin/games/review/ra/raiden2.htm

ロックはレーザーに引っかかったものすべてだと思うナリ。ザコキャラはすぐ壊れるし。

んで、あとは１フレームごとにロックしている敵を順番に通るよう
スプラインなりで……と思ったけど、
このレーザー、一定間隔のスプライトの集まりなのよね。
スプライン曲線上のポイントを一定間隔で得る方法とかありやす？
もっと単純なアルゴリズムなのかも。

http://www.hf.rim.or.jp/~idaka/bs.html
これか。

>>56
空気抵抗は、速度の2乗に比例して、逆向きに作用するから、
dy += g - u*y*fabs(y);
y += vy;
だろ。fabs()は邪魔だが。
uは粘性と質量をパラメータとした定数。
軽いモノのほうがデカくなる。
dtにあわせててきとーに設定しろ。
ま、どこまでリアリティを追求するか...

>>62
面白そうなゲームなんだけどネタなんだよな…

質量は空気抵抗に関係ないっしょ。
「速度に比例」は割とよく使われる近似値かと。

速度に比例する粘性抵抗と、速度の２乗に比例する慣性抵抗の両方かけるのが正解。
マリオのジャンプ程度の速度なら、
慣性抵抗はほとんどかからないので考慮しなくてよいかも。

なお、この慣性移動する物体に空気抵抗をかけるのは
ごく簡単に物体に重量感を持たせることができるので、どんどん使おう。

＞６４
そうなの？本当にこのゲーム作ったんだったらこれはすげえなあと思ったんだが。

ごめんネタでした。ていうか気付けてくれ > 68

宮本茂はリアリティーよりもプレイ感覚で調整したと聞いたが？

>>70

バランス調整云々の話をすると、それこそ個々の作品の
『味』や作者の『好み』といった主観的な話になるので
あえて持ち出すことも無いさ。

ここでの話題は、参考程度に知っておく分には何ら害の無い
ごく簡単な技術的なものなので、これではこれで有意義だ。

× これではこれで有意義だ
○ これはこれで有意義だ

鬱だ氏脳

ｺﾚﾃﾞﾊｺﾚﾃﾞ ｺﾚﾃﾞﾊｺﾚﾃﾞ ｺﾚﾃﾞﾊｺﾚﾃﾞ・・・・・

／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
|　粘着荒らしですか。ﾊｧﾊｧ。私とネトーリと愛を育みませんか？
＼
　 ￣￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　∧＿∧　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　 （　・∀・）　 ∧ ∧ ＜　か、勝手に覗くんじゃねーｺﾞﾙｧ！！
　（　　⊃ ）　 (ﾟДﾟ；)　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣ （つ>>73つ
￣￣￣日∇￣＼| BIBLO |＼
　　　 　 　￣　　　=======　　＼

プロでも意外とインベーダすら作れない人、多いよ。

俺もだけどね。

75はsageという概念も理解できないのか。

xinvaders - インベーダ
xgalaga - ギャラガ
xバトルス - バトルス(ゼビウスクローン)

どれもUNIXのX-Window版。古くからのUnixユーザなら
一度は遊んだことのあるゲーム達。当然ソースからmakeできる。
探してみそ。

マリオとかって、ボタンをちょこんと押したらちょこんってジャンプ、
ボタンを長めに押したらびよーんってジャンプするじゃないですか？
あれってどうやってるかわかります？昔からの疑問です。

�dでる間もボタンを読み続けてるのでは？

ボタンが押された→少し上に移動→まだ押されてるな→少し上に移動
→もう押されてないor一定以上上がった→減速開始

xsoldierのソースは参考にしないほうがよいぞ。

>>82
何故？

>というか、放物線を使わないとデコゲーになってしまう。

どこかでSin関数で近似してる奴がいるって話し聞いたけど
デコゲーだったのか

>>84
それは「山崎式正弦跳躍法」アル。

山崎由喜憲著『ゲームプログラマになる本』CQ出版
ISBN4-7898-3564-2
http://mentai.2ch.net/prog/kako/981/981281595.html

>>1
＜必要になること＞
・キャラ描画方法
・デバイス入力方法
・当たり判定の方法
・三角関数の知識（アークタンジェント等）
・連結リストの知識
・キャラのデザインセンス
・効果音を作るなら、ＷＡＶＥの知識
・ＢＧＭを流すならＭＩＤＩの知識（フェードイン、フェードアウト等）
・時間
・根気
・他人の意見を素直に聞ける能力

これら全てをクリアしてシューティングが可能となります。
まだあるかなぁ

>>83 見れば分かると思う。

>>88
見た。了解。

>>87
あと超重要なのは、
・キャラ(敵)配置のセンス
やね。
一見クソでも配置が絶妙だとゲームになる。
センスがなくても
・時間
・根気
でなんとかなるかもしれんけど。

>>88-89
うおおおーーッ！何がダメなんだ。気になるじゃないか。
オレも見よっと。

何気に>>90が一番難しかったりします。

基本的なことですが、敵弾は他のキャラに隠れないように一番手前、
もしくは自機のすぐ下に表示しましょう。
敵弾はプレイヤーが（ふつーの）シューティングを遊ぶにあたって
最も見えなくてはならない「情報」であります。

ちなみに、蒼穹紅蓮隊、レイストーム、Ｇダライアスといったゲームで
「いつのまにか死んでいる」といったケースが多いのは、
これらのゲームが奥行きのある3D画面なため、2Dシューティングのように
無条件に敵や敵弾の表示優先度を高くすることができないからであります。

LINE文でビームを描くと、撃ってる間は移動できなくなるぞ(藁

>>84
デコゲーのジャンプは直線軌道。最初は dy/dt = a で上がっていって、頂点に
達すると dy/dt = -a で落ちてくる。

デコジャンプで検索すると Web サイトが引っかかるよ。

>>96
私はそれをソーサリアンジャンプと呼んでた。

２ｃｈであの遠藤氏が言っていたんですが、ゼピウスの敵の動き
ってすべて加減算のみなんですってね。

>>98 昔の2Dゲームはほとんど全部そうでし。

まず自機を表示してキーボードで動かせるようにするべし。
その次は、ショットかな。
あたり判定とかはとりあえず後回しだ．

ええと、DirectX5ゲームプログラミング入門という本を読みまして、
とりあえず背景を表示してその上でスプライトを動かすという程度
なら出きるようになりました。ただ描画の度に全部描き直している
という感じです。普通は変更のあった個所だけなんですよね？
でもスクロールとなるとやはり全部ですかね・・・。
あとあたり判定というのは、自機や敵にRectを設定して、それが
重なってるかどうかってことですよね？

今想像できないのは、たくさん敵が出てきて、それぞれがタマを
撃ってきて、中には画面外にいって消えてしまってるのもあって
みたいに、それだけたくさんの敵やタマをどうやって管理すれば
いいのかってところです。何言ってるかわからないかもしれません
が・・・＾＾；。
では、また勉強してきます。

最近はVRAMにサーフェスを全部作って、
描画タイミングでセカンダリサーフェス全域を合成しなおすのが
普通の書き方らしい。
2Dはみんな十分に速いしね。

>今想像できないのは、たくさん敵が出てきて、それぞれがタマを
>撃ってきて、中には画面外にいって消えてしまってるのもあって
>みたいに、それだけたくさんの敵やタマをどうやって管理すれば
>いいのかってところです。何言ってるかわからないかもしれません
>が・・・＾＾；。
構造体配列を使えよ。1フリップ間に全てのキャラクタを動かす。
構造体には、速度情報、座標情報を用意して、全てのキャラクタを
動かし（全てのキャラクタの座標位置に速度を足す）、表示させる
ループエンジンを一つ作ってフリップ毎に呼び出せばなめらかに動
かせるようになるよ。
あとは、配列ごとに障害物用やら、背景用、自機用をつくって、相
互のあたり判定をかましてやれば、ゲームになるよ。

・・・＾＾；。 ←何で初心者ってこの顔文字書くやつ多いんだ？むかつくぜ？ボクゥ・・・

できない奴と人に頼るしかできない奴が良く使う顔文字。

ていうかオマエ、どこかのサイトの掲示板でFFとかいう名前でMSXの質問して、いくら教えても全くわかってないから管理人から明らかにうざがられてた奴じゃないか？

>>104

わるかったね。10年以上前から使いまくりだよ。^^;

104は自分を客観的に見直す必要があるな（藁

104〜106
すぐキレるあなたにカルシウム！

ファイナルトリトーンのジャンプの方が、クセがあるのだけど。

>>103
配列よりも連結リストの方がベターです。
処理的に効率よい。

>>110
ｻﾞｲﾝﾏﾝｾｰ?

そんなのどうだか知らないけど複雑にはしないでね。
物事を考えるときは可能な限りシンプルにしなさい。
偉い人のお言葉です。

>>111
NextとBackを構造体に使って連結する方法ね。
知ってるけど、相手は、素人だから、まずは、配列からお勧めするよ。

永遠に２段ジャンプ・・・

お利口なテクおぼえたところで、個人プログラマは
システム実現→満足→終了
てなパターンが多いので、面白いゲームを作る方に集中した方がいいよ。

＞面白いゲームを作る

面白いゲームを完成させる
だね。

みんなエラそうだね。

なぜかゲームプログラミング系のスレには、無分別に相手を厨房と
みなして御高説をたれる「お偉い」方が多いんだよ。他スレでは
なかなかお目にかかれない光景だね。

>>119
無分別とは失礼な
まじめな回答の方が多いじゃないか
オレならこんな質問を発している時点で「あんたにゃムリ」で放置モード

>>120

憤る前に過去ログを読みましょう。
このスレでは>>1の質問はもう終了してまして、消防相手の
FAQスレだったのは過去の話。今ここにいるのはSTGプログラ
ミング話が好きな連中ばかりで、マターリと技術話に華を咲
かせたいだけなの。

ここで能書きたれてる「お偉い」方にどんな製品（ソフト）を
リリースしてるか名前の後に加えてほしいねぇ。
いい仕事は能書きより説得力あるし。

遠藤さんが釣れたりして（藁

>>120
浮いてるぞ。スレの流れを追ってくれ。

>>122
そう煽るなよ。マターリな。

>>122
ゲハ板に逝ってくれ。

なんだかんだいっても、このスレはゲーム系では珍しくよく育ってるぞ。

1じゃないけど。

DX8でインベーダー作ってます。敵も味方もメッシュで、弾はスプライトです。

でもって、スペースキーを押したときに自機の弾の出現する位置を計算するところで妙な誤差が出てしまって困っています。

↓カメラ
D3DXMatrixLookAtLH(&mat,
　　&D3DXVECTOR3(0.0, 200.0, 0.0),　//　カメラ座標 x = 0.0f, y = 200.0f, z = 0.0f;
　　&D3DXVECTOR3(0, 0, 0), // 視点 x = 0.0f, y = 0.0f, z = 0.0f;
　　&D3DXVECTOR3(0, 0, -1)); // カメラの上 x = 0.0f, y = 0.0f, z = 0.0f;

↓透視
FLOAT fAspect = m_d3dsdBackBuffer.Width / (FLOAT)m_d3dsdBackBuffer.Height;
D3DXMatrixPerspectiveFovLH (&mat,
　　D3DX_PI / 4, // y 方向視野角
　　fAspect, // アスペクト比
　　1.0f, // カメラに近い方のクリップ面 z 座標
　　1000.0f); // カメラに遠い方のクリップ面 z 座標

という状態で、スペースキーを押したときに

TamaPosition = FighterPosition

としています。
でもって、レンダリングするときに、

float X
= ((float)BackBuffer.Height / 2.0f) * (fAspect - TamaPosition.x / (200.0f * tanf(D3DX_PI / 8)));
float Y
= ((float)BackBuffer.Height / 2.0f) * (1.0f + TamaPosition.z / (200.0f * tanf(D3DX_PI / 8)));

として、

TamaSprite->Draw(TamaTexture, &rct, NULL, NULL, 0, &D3DXVECTOR2(X - 16, Y - 16), 0xffffff00);

としてるんですが、Yは問題ないんですが、 X は TamaPosition.x に 3.0f を足してあげないと適正な位置に弾が表示されません。
この理由がわからないです。

わかる方、教えてください。

姉妹スレあげ。
化けることを祈ろう。

セがラリーみたいなの嫌、そのものをつくりたい
http://piza.2ch.net/test/read.cgi?bbs=tech&key=990538812

>>114
双方向リストにする必要まではないよーな気が。
シューティングゲーでそういう状況ってあるのかな？
ちょっと想像つかない。

双方向にしておくと、キャラクタ削除の時に、前後関係を直接
参照できるから、高速で切り離しできるんだよ。
これがもし、片方向だったら、順次に追っていかないといけないので、
ループバックのオーバーヘッドが痛いから、容易に扱えない。
状況的には、あるキャラとキャラどうしがぶつかって消滅するときに、
片方向リストのやり方だと、もう一方のキャラクタの前後関係がわか
らないから、いちいち追わないといけないが、双方向だと、そんなこと
をいちいちやらなくてもよくなる。

なんではじめから配列にしないの？
ゲームなんだから不規則に変化するなんてことまずないでしょ？
メモリの変化はできるだけ押さえて、ハードディスクなどへのデータのやり取りは一括しておこなう。
リストを使う利点なんてないでしょ？
それともコンシューマででも組んでるの？
はっきりいってリストを使った話を聞くとややこしく感じる。
だいたいシューティングで一度に画面にでるキャラは何体で一度に入れ替わるキャラの数は何体だろう？
それをふまえたうえでもっともシンプルな組み方はどうなんだろうか。
それがきっと一番いい動作さ。

>リストを使う利点なんてないでしょ？

はぁ？

リストも配列も手間はそんなに変わらんと思うが。
動的にメモリを確保して云々までしなくても、
構造体の配列にして要素をリストもどきのように扱うこともできるよね。
リストと配列のいいとこどりでうまく扱える方法はあると思う。

教科書どおりのリストや木なんかにとらわれないで、
自分的に効率のいいと思えるデータ構造を設計するのも楽しいですよ。

>>131

煽りなさんな。マターリな。

>>127
二匹目のドジョウを意図的に狙うのは勝手だが
他スレでの宣伝行為は批判を買うだけで逆効果だぞ。
さだめは甘受せよ。

毎回思うがリストや可変長データの設計がぼろぼろでてくる人は
一度コーディングから離れたほうがいいナリ。
このリストの問題だってポインタとってきて配列で纏めた方がよっぽど管理がしやすいナリ。
双方向リストなんてこれまで生きた人生眺めても使ったことナイナリヨ。

もう少し具体的な用途で両者を比較すれば
話の見通しがよくなると思うなぁ。

今、キャラ管理の話だったっけ。

例えば、弾幕STGの弾丸管理という前提でどうか。

自分もシューティングゲー作成に挑戦しとりますが、単純に構造体の配列にしてます。
シューティングゲーのオブジェクトなんて画面上のオブジェクト全部ひっくるめても1000を超える事はまず無いと思うんですよ。
その程度の大きさなら複雑（と言うほどでもないが）なアルゴリズムは不要だと思うのですが…

>>127
アレと一緒にされてはかなわん。（笑

ただ単純に1000個の配列とかにして、それにキャラデータを入れることにすると、
新規のキャラを出すときに頭から順番に空きを探さなければいけないし、
表示のときにも１つ１つの要素についてキャラデータがあるかを調べなくてはいけない。

だから、配列の要素数は固定にしておいて、
使用リスト、不使用リストを使って管理をするようにすると楽。
新しいキャラを出したいときには、単に不使用リストの先頭の番号をもらうだけだし、
キャラを使い終わったら使用リストから削除して、不使用リストの最後に足せばいい。

動的メモリ確保とかいらないしね。

＞１３９
なるほどー。

どうせ描画以外の部分の負荷は微々たるものなので、
余計なことに気を使うくらいなら、保守性を高めるベシ。

イテレータはダメ？

ああっ、別スレの名前が。
私の場合139さんの言う「いちいち探す」方式です。

全キャラひっくるめて2000個程管理してます。
１フレームあたりの描画を除いた全ての処理を行っても1ms程度しかかかりませんでした。
＃Athlon700です。
そんな訳で手抜きしてます。（藁

それよりMode-X 16bpp環境でのDirectDrawの描画が遅い方が遥かに問題。
そんなにキャラ表示させようとすると16msに収まらんのじゃぁぁ！

その１ｍｓが命とり

オタの中には１ｍｓの違いを感じ取る能力があるやつがいるらしい。

結局、
『ノード毎にヒープ確保するからリスト管理はうざい』
『自己管理のメモリプール使えばオッケーだよ』

という話だったのかな。純粋にデータ構造と検索アルゴの
話だと思ってたよ。キャラ管理でのね。

>>142

お、それだけじゃよく分からんぞ。
もう少し詳しく書いてくれ。

このスレ、レベル低いなぁ・・・
固定長配列が一番いいってことでまとまってるし(藁

>>147
だからレベル高いこと書けって（藁

>>143

「いちいち探す」方式って表現、個人的に好き。
でも「線形探索」,「リニアサーチ」といえば一発ナリよ。

>>147
はっはっは。
これでいいの。煽らない。焦らない。

お〜い、みんな頑張れよ

>>144,147
ここは低レベル厨房お断りだ。
セ"が"ラリーツリーにでも逝け。

まぁ現実的には2000キャラも表示する訳には行かないので、半分以下に減らす予定ではいます。
これで更に処理が軽くなると。（笑

いずれにせよ描画の方が内部処理より遥かに高コストなんでアルゴリズムに拘りすぎるのも不毛のような気もしますが。

＞不毛のような気もしますが
いやん。そういうときはリップサービスでいいから
「有意義」と言っとくんだよ。スレが終わっちまう（藁

>>147
是非とも素敵なアルゴリズムとデータ構造を提示してくれ。
知識ばっかりで実践への応用経験が無さそうな君には無理かな？

配列を扱う場合は、キャラクタ数が少ない場合は、そんなに問題ないが、
キャラクタが増えてくると、使われていない配列をいちいちアクセスす
ることに過負荷が生じる。

俺の場合は、使われないキャラクタをスタックにためておいて、使用する時に
連結リストに結合させる。　この方法が一番高速に実現できる。

おまえらバカばっかだから、段々、説明する気が失せてきた。

なんで使われてない配列にアクセスするの？
なんでスタック？
お前のアルゴリズムなんかおかしいんちゃう？

>>147
お前、ｷﾃｨ確定。
処理ループ内で動的に配列サイズを可変させるつもりか？

>>156
全体の処理コストを考えたら無視できるレベル。
連結リストにしたって一件毎に「挿入・切り離し」処理をする事を考えると139の使用・未使用リストを使った方が速い。
なんだか専門学校あたりの教科書を盲信しているようにも思われ。

>>159
同意。
なんでスタック？って感じ
コードマスター言う割には根本的な間違いをしていると思われ（藁
若気の至りって奴かもな

なんかすぐカサカサしちゃうの止めようぜ。くだらねぇじゃん。
煽る奴も反応する奴も落ち着いてくれ。マターリな。

ﾊｧ？ 配列を線形探索？ んな処理速度が不安定になることしてどーするんだ。
可変フレームレートとか、処理落ちする場合とかにモロに動きがガタガタになるぞ。

とりあえず、メモリプール＆双方向リスト使え。
C++でやりたいヤツはEffective C++の第２章10項のコードを見ろ。

自称コードマスターつうだけでｷﾃｨ

だがまあ、初心者はこのようなこと気にする必要はなかろう。
（トーンダウンしてみました）

このスレ、バカだが根が素直な奴はちゃんといるんだよ。
学習すれば改善する見込みがあるし、だから許してやれ。
バカで煽り厨房な奴は根が腐ってるからアカン。捨てろ。skip it

カサーリしてるのが若干一名ほどいらっしゃるような。
一人でエキサイトして荒らしてるんじゃないかな。
もう止めてくれといいたい。マターリと頼む。マジで。

自作自演荒らしがいるね。

リストにして、自己組織化探索なんてどうよ。>自称コドマスタ

>>162

>ﾊｧ？ 配列を線形探索？ んな処理速度が不安定になることしてどーするんだ。

私のは手抜きだし、2000件処理しても1msなので取り敢えず実装優先で手抜きしますが。
＃しかも更に減らす予定だし。

シューティングでは処理する対象の数が状況によりガンガン変わって行くので不安定は当たり前では？:-)
前にも書きましたが、内部処理は一瞬で終わるのでこの部分の「処理速度が不安定云々」は無意味でしょ。

ペドマスタ

このスレ読んで双方向リストのメリットが良く分からん。
双方向リスト使うと、たとえば自機と敵とのあたり判定の時、
全敵データ調べなくて済むようになるわけ？
弾と敵の当り判定で、弾数×敵数の回数だけ判定するのはあほ？
このスレみて疑問に思った。誰か教えてけれ(;´Д｀)

ゲーム系プログラマってさ、自分より下を見つけると
徹底的にコキ下ろす奴、多いんだね。ハタから眺めて
るけど、了見狭すぎるよアンタら。

>>172
オマエモナー

>>170=>>173
頼む。アンタ恥ずかしいからもうゲハ板逝ってくれよ。

しかしまぁ、シューティングって熱いなぁ（笑
目に見える事を実装しようって話でこれだけエキサイトできるんだから。
ある意味珠玉のスレとも言えるような。

話を変えてと、
懸案の「プラズマレーザー」はどうなったんだっけ？

>>169
Athlon700なんてすっげーいいモン使っておいて、
1msなんて言われても困るんですけど(笑)。

>シューティングでは処理する対象の数が状況によりガンガン変わって行くので不安定は当たり前では？:-)

そりゃタスクが増えれば処理が重くなるのは当たり前です。

しかし、線形探索ではタスクの生成にかかるコストが不定（2000件なら１〜2000）。
すると、タスクの生成・破棄・処理を含めた全体の処理コストの変動が激しくなる。
分かります？

ついでにゲームはリアルタイムアプリケーションであるとか、
タスク数５桁のゲームもあるよとか言っておくとして。

138さんへ

是非、計算機工学の基礎本を一冊購入されることを
オススメいたします。きっと損はしませんよ。

＞このスレ読んで双方向リストのメリットが良く分からん。

オブジェクトの生成・破棄が「安定」かつ「一瞬」で済みます。
メモリアクセスも最小限で、キャッシュを荒らしません。
（情報処理技術者試験にでも出てきそうな話ですが……）

＞弾と敵の当り判定で、弾数×敵数の回数だけ判定するのはあほ？

処理を軽くしたければ、画面をたくさんの矩形領域に分割して、
それぞれの領域内で判定する方法があります。掛け算を分解するわけ。
ただ、典型的な2Dシューティングのオブジェクト数と
最近の高速なマシンでは、あまり効果ないと思いますけど。

数百数千のオブジェクトがそれぞれ相互作用するときなんかは
かなり有効、というか必須ですね。

処理なんてどうでもいいから、面白いもの作れよ

>>179
野暮な煽りはもう止めとけ。

ソフト開発の基本原則から言えば、重い部分を効率化すべきだから、
ここでのデータ構造の議論は実際上あまり意味が無い。

それよりゲームとしての質をどう高めていくか考えたほうがいいと思うよ。
例えばキャラのあたり判定とか。
雑魚敵はともかく大ボスとかで丸いキャラなのに判定が四角いのは変だよね。
そういうのをどうやって処理するかとか考えると面白いよ。
有名な方法だと８角形に近似して計算とかあるけど。

>>178
簡単に言うと双方向リストは高度なゲーム向きってことらしい？
かりに2D→３Dっていうと、リストや画面分割は必須？

高度なゲームっていうか、リストとかは情報工学の基礎だから、
適材適所で必要と思ったときに使えると劇的に生産性が向上するって話じゃ。

>>181
激しく同意。
ゲームプログラムでデータ構造がスピードのボトルネックになんてならんよ。
キャラを５万個くらい管理してるならともかく。

>>183
いやいやゲームに限ってのお話でして…

>>176

何か激しく勘違いしてませんか？
まずAthlon700で1msなら速度が3分の1(PII-233程度)でも3ms。
これが動作ターゲット下限の環境。
これに比べたら描画処理の方が遥かに重いと何度も言ってるのですが、最適化すべき処理を間違えてやしませんか？
1msが0.9msになったとして、それには自慰行為以上の意味があるんでしょうか。
描画は10倍以上コストがかかるのにね。

>タスクの生成・破棄・処理を含めた全体の処理コストの変動が激しくなる。
分かります？

タスクの生成・破棄…？なんでここでタスクって単語が？
もしかして弾一個とかのオブジェクト単位でタスク生成しようとしてるんですか？

因みに前述の1msってのは処理対象1024件のダミーデータ入れた上での計測結果。
でも貴方の言う「タスク」とやらは１つで、処理ループ内では生成・破棄等は行いません。
おわかり？
つうかシューティング作った事ないのでは？

>>177
持ってます。でも実装では手を抜いてます。
既に結論出てますが双方向リストは使いません。
しかも、あの手の本に載ってるアルゴリズムでシューティングに適用できるのは結構少ないです。
でも139さんの使用・未使用リストは簡単に適用できて効果も大きそうなので、大まかな雛型が完成してから適用しますよ。
まずは全ての機能を実装してから最適化するつもりなんで。

int M_X[8],M_Y[8];
int M_P=0;
void MissileSet(int x,int y)
{
if(M_P<8)
M_X[M_P]=x,M_Y[M_P]=y,M_P++;
}
void MissileDel(int pos)
{
if(--M_P>0)
M_X[pos]=M_X[M_P],M_Y[pos]=M_Y[M_P];
}
これじゃだめ？

あたり判定のあたり、知りたいナリよ。

なんか口先だけのお花畑出身の人が混ざってるみたいね。

煽るほうもアレだが、ダイレクトに反応するほうもアレだ。
落ち着いた大人の会話が成立してないのが残念でならない。

煽り煽られ２ちゃんねるの王道を逝ってると思うよ。

自機や弾の位置を(x1,y1)、敵の中心の位置を(x2,y2)、敵の半径をaとすると、

abs(x1-x2)+abs(y1-y2)<a*sqrt(2) && abs(x1-x2)<a && abs(y1-y2)<a

これが成り立つときに衝突とみなすのが８角形で近似する方法。
(x2,y2)を中心とした半径aの円に外接する正八角形の内部に居るかという判定になってる。

どうにかならんものかね。
相談室が荒れてばかりだから、こっちでマターリとSTG話でも
してようかなと思ったら、今度はこっちで喧嘩始めやがるし。
ほんと鬱になるよ。

abs()やsqrt()はこういう計算って意味で出しただけだから、
型については突っ込まないでね。

>>191=193です。スマソ

>>191
あ、なるほどね。円に外接する正方形と、その正方形を45度回転させたものとの共通領域にいるかどうかって事なんだね。
もーらい♪

ﾀｽｸとか言い出してるｺｰﾄﾞﾏｽﾀｰﾍﾞｰｼｮﾝ逝ってﾖｼ
ｵﾚﾓﾅｰ

当たり判定なんてそんなに重要なの？
とりあえず物体同士は2Dでは円。3Dでは球だね。壁とかは2Dは直線で3Dは平面。だね。楽だし。
あんまり凝っても疲れるだけよこの辺は。
マターリマターリ。

こいつら、タスクとスタックの違いも分からないと思われ...

＞とりあえず物体同士は2Dでは円。
レクチャーだよ。バカ。

>>197
当たってないと思っているのに死ぬと、かなりストレスがたまります。
だから当たり判定は結構気を使わないとダメです。
まぁ小さめにとっておけばいいんだけど。

最近は、あたり判定は小さめに、その代わり弾の量が尋常じゃない
ってスタイルのゲームがはやりみたいですね。

タスクとスタックの違い……？
タスクは処理単位みたいなもので、スタックはデータ構造(FILO)だよね。
違うも何も比較できないのですが。

３次元の場合は、物体を囲む巨大な球どうしで最初に当たり判定
をかまして、当たっていたら細かい部分まであたり判定を行うよ
うにするとオーバーヘッドが減るぞ。

おお！！コードマスター様がご光臨なされたぞ！！
ありがたやありがたや・・・・

タスク
http://www.ascii.co.jp/ghelp/23/002320.html

スタック
http://www.ascii.co.jp/ghelp/19/001988.html

やっぱ、分かってなかった。
命令用のスタックじゃなくて、俺が言ってるのは、データ用の共有スタックだよ。
ポインタをスタックとしてあらかじめ溜めておけば、mallocとかfreeとか一々
しなくて済むって事だよ。

わかってなかった……って、
あなたの「俺解釈」をわかれって言われても。
さらに>>205も意味不明なのですが。

予め沢山mallocしておいて、そのポインタをスタックに積んでおいて、
必要になったらスタックから取り出して使用、不要になったら積みなおす
という解釈でよろしいのでしょうか。

それだと予めメモリを沢山確保しておくことになりますが、
配列に対してアドバンテージが何も無いような気がするのですが。

その前に、mallocとfreeにかかる時間を計測してみろよ。
半端じゃないから。

矩形=rectangleを”レクチャー”って言うの初めて見たヨ。
言いたい事はわかるし同意もするが。
しかし珍妙なマイ解釈を他人に押し付けるのもダメだぞ。単にスタックゆーたら、204のと解釈するのが普通だ。
人にバカ言う前に己を見つめ直し、我が振り直す方が先っぽいぞ。

あと上の方で突然タスク言い出す奴が出てきたのもワカンネー。
処理時間の計算もできん奴が寝言ぬかしてる感じだ。
キャラ管理のデータ構造のハナシだったはずだし。

まぁデータ構造管理は宗教論争っぽくなってるからみんな>>141読み直そうや。


２Ｄ当たり判定は単純に矩形交差判定。あんまり凝った判定しても遅くなるだけーヨ。
大きなキャラなら絵より一回り小さめの矩形、自機は絵より極端に小さい矩形を
用意して判定してやれば今時の弾幕STGになるとオモワーレ。
あ、あと自機が撃つ弾は逆にちょっと大きくしたら良いかも。
この辺は自分で思考錯誤しながらやると楽しいかもナ。

ぷれい中の確保したメモリの変化は極力避けろっていってんだろゴルァ！

とりあえず、138とコードマスター追放きぼん。

日本語勉強しなさい>205 & その他大勢

今日もいい感じに荒れてるな

>>210
コテハン叩きやめとけ、程度低すぎるぞ。

>>207
ついでに、malloc とfreeで出来るメモリーの断片化も気になる。
普通、リアルタイムではやらないですな。

心配すんな。malloc/freeの話題自体程度低い。>>213

なんぞめちゃくちゃであるな。話がまるでかみ合っておらぬよ、貴殿ら。
ひとりひとりのカキコのバックグラウンドにある思想・実装を想像すると
そう変な人がいるわけでもないと思うのだが。

さしあたって、実際のコードでも出し合ってみてはどうか？

C-FAQでも見ろや

じゃあまずいいだしっぺのお前が出せ。>216

ゲーハー厨もそうだけど、
非PC系ゲースレの方たちが乱入してきて、余計荒れてる気が・・・
ﾏﾀｰﾘいきましょうよ。

PC系ゲーのオレは、双方向リストもつかってるし可変長配列もばりばり使ってる。
クラス化してどちらも使いやすくしてあるので、適材適所で適当で使いやすい方を採用してる。

まあ、そんなのよりもやっぱ圧倒的に描画の方が時間かかるから、そっちのほうが問題だよね。

>>218
とはいえ、吾輩はこの話題に参加しておらぬからな(笑)。
いや、人間とは面白い生き物だて。

流れはぇ〜。なんかその話もう終わってるし・・・。

　ところで、フリーで楽しめるシューティングゲームの置いてあるページって
誰か教えていただけませんか？
　久しぶりに、シューティングがやりたくなってきたもので。

　よろしくお願いします。

いやしかし、描画のほうがずっと重いからって配列をリニアサーチで空き要素探索、
それで何も疑問に思っていないというのはさすがにどうかと思われるが。
こういう手合いの常として、たぶん他の部分（描画周りも含む）も
ヘタレアルゴリズムがギッシリなんじゃないのか。

で、ソフトが完成する段階になっても、時間がない、面倒くさい、
見落とし、構造上アルゴリズムが変えられなくなってしまったなどの理由から
十分な最適化ができず、水準よりも妙に重いアプリが完成というのがよくあるケース。

もっとも、趣味レベルならどうでもいい話ではあるが・・・。

Thanks guys. ^_^ I'll be doing this for my next project, and it's good to have a comprehensive discussion of what
I'll need to do. :)

PCゲーム板に、「フリーソフトで面白いゲーム」という優良スレがあるので
チェックされたし。

>>225
さんくす。
早速逝って来ます。

>>233=176?
ﾅﾝｸｾﾐｸﾞﾙｼｲ､ﾈﾝﾁｬｸﾔﾒﾃﾄﾘｱｴｽﾞﾏﾀｰﾘｼﾄｹ｡

>>208
そういうことだったのか
理解に苦しんだｗ
「何をレクチャーしたんだろう？」ってね

なんか一晩たったら見事に荒れてるしー。

100ぐらいまではゲームスレとしては珍しくまったりとして良いスレだったんだけどな。
場の雰囲気を読めない奴ら、逝ってよし。

>>222
はいよ。
happousyu.hoops.livedoor.com/GAME.HTM

ここレベル低いな

223は馬鹿。アホが検討違いなことイッテンジャネーヨ。

煽り、騙り、ｼﾞｻｸｼﾞｴﾝ。もう沢山だ。
スレがどんどん劣化していく。忍びない。

HPを作ったものの、全くアクセスが上がら
ずに悩んでる方に朗報です。ただいま、私
のサイトからへそクリックに仮入会された方
には、一ヶ月間、厳選した約600の掲示板に
一日二回書き込みするサービスをさせてい
ただきます。書き込む先は普通の宣伝掲
示板あるいは商用・ビジネス系掲示板です。

http://home9.highway.ne.jp/cym10262/

粘着荒らしが一人いるんだよ。

>>223
UNIX Version 6 のソースコードとか読んだことあるかい？

んー、速度的なことはもうわかったから「扱いやすさ」という点で話を進めてはいかが？

そしたら配列にキマテンジャネーカ。

レクチャーだって．．．

>>229
すまん。俺がリストの話を蒸し返したからかもしれん。

俺も一晩たって覗いて唖然。
単方向で充分じゃね？っつーちょっとした感想だったんだが。

ゲーム論理ヲタにはいまだにタスク信者が多いんだよ。
好きなだけ講釈させてあげようではないか

リスト自体いらんでしょ。

例えば、三節根があったとして、それを地面に置いて､一方の端を持ち
真横につーっと動かしたときつられて後ろの二根もついてきますよね
それを具体的にどういう風に示すのか が今の壁です

ありゃりゃ…流石に責任感じるわ。一応自分が参考にしている文献を載せときます。
「アルゴリズムＣ　第２巻　探索・文字列・計算幾何」ISBN4-7649-0256-7

これの51ページに線形探索法が載っており、そこに書いてある
理由がそのまま採用した理由です。
勿論この手法が完璧な訳もなく、デメリット（ロスなど）も記載されてますが、
これは139さんの手法で簡単に改善可能。

コードマスター氏の連鎖リストも考えたけど、弾等の消去時に連鎖
してる前後の他の管理レコードを触りたくなかったのと、速度的な
メリットがあまり出ない環境(Win+DirectX)なんで不採用としました。
最終的には使用・未使用リストと速度は変わらなくと思われます。

オブジェクトの数も全体で1000件に達しない様に作るので、この辺を
落し所としても十分と考えます。それよりもクソ遅いDirectDrawがね…。
自分はここで終了しといて、あとは一介の名無しとしてﾏﾀｰﾘしときます。

厨房でスンマソ
ドミノ倒しのサンプルってどっかに無いですか？

Ｗｉｎｄｏｗｓ環境で、シューティングゲームなんて作るなや。
あれは、アーケードゲームだから萌えるんだ〜ぁ！

普通ゲームを作るときは、敵の最大数とか決めて作らない？
行き当たりぱっだりで作ると、ゲームバランスが滅茶苦茶になるよ。

話の流れがむちゃくちゃだが「扱いやすさ」という話だと、
可変長要素を持つ可変長配列および双方向リストだな

>>247
突然誰に何を言ってるノカ？
そろそろ話題変えようや。

とりあえずオブジェクトは全部で1000個も出ないから1000個の
配列用意しておけば問題ないだろうとか言っている奴は、
プログラムのセンスもなけりゃシューティング作るセンスも無しだ。

ほらほら、又だよ。
いつまでも言ってると見苦しいだけだぞ。>>250
何か悔しい事あったのかは知らんが取り敢えず引いとけ。

帰れよぅ
ゲーハー板に帰れよぅ… >>250

大容量メモリと高速CPUの世界で生きているとアホになるんだね

縦シュー萌え〜

相変わらず粘着荒らしがいるね。
書くことといえば中傷混じりの一行文。
論理的、具体的な指摘など何所にも無い。
これがエンジニアなのかと思うと情けない。

センスという一言で片付けるのは簡単さ。
論理で説明できなければセンスを問う。常套手段。
個々人の主観に依存した議論ほど不毛なものはない。

知恵を使うことを止めた奴が負けなんだ。

>>243
自立して動く側を親オブジェクト、従属して動く側を子オブジェクトとすれば、
子オブジェクトの座標系は親からの相対位置にしておいて、
表示等する場合には加算して絶対位置に変換するというのがセオリーですよね。

移動処理時に親オブジェクトを先に計算しないといけないとか、
衝突判定時にいちいち絶対位置への変換がめんどくさいとかが難点ですかね。

聞いて >>256♪ ちょっと言いにくいんだけど
聞いて >>256♪
＼＿＿＿＿＿＿　＿＿＿＿＿＿＿＿＿＿／
　　　　　　　　　　|/


　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣）
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ／　　　　　　　ﾉ（　　　　　　　　　　 ＼
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　／　　ﾉ（　　　　　⌒　　　ﾉ（　　　　ﾉ（　　 ）
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　/　　　　⌒　　　　　　　　　⌒　　　　⌒　　 ＼
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　|　　　　　　　　＿＿＿＿＿＿＿＿＿＿＿＿__）
　　　　　　　　　_,--、＿　　　　　　　＿＿＿＿＿＿＿|　　　　　＿／＿＿＿＿＿＿＿＿＿＿＿　　）
　　　　　　　　（_（∇）（@）＼　　　／　　＼'Ｘ,'Ｘ,　　　　　　　　／＿／〜〜〜〜〜〜〜〜〜〜〜＼ノ
　　　　　　　　　|（@）l,＼（@）＼／　＼'Ｘ,'Ｘ,　　＼'Ｘ,'Ｘ,　　 ／＿|　|　　 |　　 |　　 ,|　　 |　　 |　　 |／
　　　　　　　　　|（@）|　　＼（／　'Ｘ,'Ｘ,　　'Ｘ,'Ｘ,　　　　　　〈＜＼／＼／＼／＼／＼／＼／＼／|
　　　　　　　　　|（@）|　　　／'Ｘ,'Ｘ,　＼　　　　'Ｘ,'Ｘ,　　　　 ＼￣|　　 |　　 |　　 |　　 |　　 |　　 |　　＼
　　　　　　　　l⌒'ー―――――'　　'Ｘ,'Ｘ, _／￣￣￣|　　　　＼ ￣＼〜〜〜〜〜〜〜〜〜〜〜／）
　　　　　　 ／（∇）（@）（@）（@）（∇）＼_／　　　　　　.|　　　　　 ￣＼　￣￣￣￣（￣￣）￣￣￣￣ノ
　　　　　／（@）,―――――,　〜　＿／　　　　　　　 .|　　　　　　　　 ￣￣￣￣￣（￣（￣￣￣￣￣）
　　　_／（@）／　／＼／　　'Ｘ／＿／　　　　　　　　　＼　　ﾉ（　　　　　　　　　　　 ）　 ）　　　　　　／
　　 （_（∇）〈　／＼__／／／＿_／　　　　　　　　　　　　＼　⌒　　　　　　ﾉ（　　　 （　（　　　　　　　）
　　　　＼（@）＼＼　 | l ＼＿／＿＿＿＿＿__／メ-／　　 ＼　　　　　　 ⌒　　　　） ）　　　　 　／
　　　　　 ＼（@）＼＼＼＿／（@）（@）（@）（@）―＋∈―　　　＼＿＿＿＿＿＿__（_（＿＿＿＿）
　　　　　 / ＼（@）＼＼／￣￣￣￣￣￣￣￣＼メ-＼　　　　　　　　　　　　　　　 Ｕ
　　　　 ,/＼　＼（@）＼' 　　　　　　　　　　　　　　　　　　　　いい加減にしろ。変に理屈っぽいだけの
　　　　〈＼＼＼＼（@）＼　　　　　　　　　　　　　　　　　　　 中身のない煽りはいらん。
　　　　（＼＿＿　,,＼（@）＼＿＿＿＿＿＿＿／メ-／ 　
　　　　（＼＿＿　／）＼（∇）（@）（@）（@）（@）―＋∈―　　　　　　　　　　　　　　Ｕ
　　　　（＼　＿／／）　 ヽ＿ノ￣￣￣￣￣￣＼メ-＼
　　　　（＼＼＿／　）　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 　 　 　 　Ｕ　. ∧＿∧ ･････
　　　|￣￣￣￣￣￣| 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　∩（　・∀・）
　　　|　 　 　 　 　 　 |　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ＿,._＼　Ｕ⊂⌒ 　 つ　 つ
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　　　　　　∧
　　　　／￣￣￣￣￣￣￣　 ￣￣￣￣￣￣￣￣￣
　　　　|　　聞いてくれてありがと♪ >>256

シューティング作るセンスとプログラムのセンスを直接結びつけるとは片腹痛いわ。

ゲームプログラマは理論ヲタより、実績を残したゲーム職人を見習うべきだと思けど

ドブゲラのしっぽみたいな動きですか？

敵の弾と自機とのあたり判定で質問です。

敵の弾と自機のあたり判定は、画面を四分割して自機のいるエリアの中にいる弾に関してのみあたり判定をしてやれば良いというのを聞いたことがあるのですが、
たとえば自機が境界線上にいた時は両方に関してやるの？

それと、境界線と数ピクセルのみしかずれてないときも、その境界線の向こうに関して当たり判定をする必要がないの？
おしえてくらさい。

>>259

まぁまぁ。片腹を痛めるにはまだ早いナリよ。
２ちゃんねるでは書き込む一人一人の実績など
知る由もないのが辛い。匿名マンセー文化だからね。
面と向かい合う会話とのギャップを埋め、有意義な
ものにする唯一の手段、それは論理性と具体性、それと
AAだ。

実績のある手法があれば、きちんと示せば大丈夫さ。

境界線で明確に切ろうと思うから問題なんであって、
例えば各領域を自キャラのおおきさぶん位大きめに、重なるようにとって、
自キャラがすっぽり覆われる領域について計算すればいい。
簡単な判定法としては、自キャラの中心と領域の中心がもっとも近いもの、
ってことになるのかな？

>>259

>>256の書いてることには何の抵抗も感じないなぁ。
それに、実績のある手法とは常に具体性に長けるものさ。
それを否定する書き込みには見えないよ。

初っ端からフィルター付きの穿った見方をすると
他人は全て敵に見えてしまうものさ。マターリな。

??具体的になったものが実績なんじゃないの??

>>259
いやいや、それもやはり君の主観にすぎないところであって。
思うに、この議論は典型的な技術者と職人の対立というやつであるな。
「擬似タスク」でも思ったことだが。

>>261
吾輩は画面を64分割してやっていた。
当たり判定が重なる領域すべてに、判定を登録していく感じだ。
自機弾が40発前後、敵が30前後の状態で、
通常のＯ(nm)の判定よりも３倍ほど高速化されていたようだ。

しかし、この程度の負荷なら、今のPCやPS2、DCクラスのマシンならば
まったく鼻にもかけぬのではないか。
かなり面倒であるし、やらぬほうがよいかも知れぬ。

……すまぬ、勘違いしていた。自機対敵弾の判定についてだったか。
やはり寝起きはいかんのう。

自機の判定が１つだけ（オプションなどなし）なれば特に小細工の要はない。
普通にやるのが最もエレガントかと存ずる。

>>265
それを否定する書き込みはまだ何所にもないよ。

みんな弾多すぎ．．．

>みんな弾多すぎ．．．
君もひとつ東亜シュー・ケイブシューでも作ってみないかね？

ほんとに最近たま多いな
後ろで見てる分にはキレイだけど

>>261
オレは分割も何も総当りでやってたよ・・・
つーか、その辺高速化してもぜんぜんかわらねーんだもん(泣

むしろ描画性能が・・・

Microsoft Visual C++ 6.0 による最適化コードの開発
http://www.microsoft.com/Japan/developer/visualc/techmat/feature/optcodedev/

配列構造を使った検索アルゴリズムは、通常、動的に割り当てられるリンクリストを使った検索アルゴリズムより速く動作しますが、これは、配列がメモリに連続的に格納され、仮想メモリの数ページにまたがって存在する可能性が高く、とりわけ RAM 上に存在することが多いからです。一方、動的に割り当てられるリンクリストは、メモリ内に分散して存在することが多く、リンクリストの検索では、ページ違反が発生する可能性が高くなります。しかし、順番に並べられたリンクリストに要素を追加したり、リンクリストから要素を削除する操作は、通常、それと同等の配列を使った操作より速くなります。これは、リンクリストではほかのリスト要素を動かす必要がないからです。

キャッシュっていえようるせぇな。

class Hikouki{
int x;
int y;
public:
int move();
int shot();
int delete_me();
}
自機のクラスってこれで足りる？

>>274

ははは、相変わらずカサーリしてるね。

カサーリ？

！マターリ

やはり今晩も荒れますか。＞ココ

ageると荒れるよね。
ゲーム系スレはこの板では嫌われてますから。

ゲーム系に限らず、マターリするならsage進行が普通だ。
下がってても読んでる人はちゃんと読んでるものだから。
定期的な書き込みさえあればdatに逝くこともない。（あまり知られてない）

このスレの何が不幸かというと、スレの題が
典型的な駄スレの臭いを醸し出してることだ。

今夜もみれるかなぁ
職人とコードグルメの対決

期待sage

ということで、皆様sage進行で

どうせお前らワンパターンなゲームしか作れないんだろ？(ｶｻｰﾘ

素晴らしいお言葉

http://www11.u-page.so-net.ne.jp/ga2/no-ji/reseach/20001219.htm

早速煽り厨が出てきてますが、放置でﾏﾀｰﾘいきませう。

>>286
表面的な事ばかりで重要なこと書いてないね。
>ゲーム作りで、もっとも大切な事は「絶対完成させること」なのです
には共感。

否ぁ！断じて否ぁ！
糞なプロジェクトを潰す！
これもまた勇気！

とりあえず、sageようや

ときに、プラズマレーザーはどうなったんだろう。
実は誰も実装できないハイテクですか？

どうでもいいsage

　　敵　ーーー敵
　　　　　　　　　　 ＼
　　　　　　　　　　　　＼
　　　　　　　　　　　　Ａ
　　　　　　　　　　／
　　　　　　　　／
　　　　　　　 |
　　　　　　　自


Ａ点は、レバーによって左右に動く。

Ａ点をすぎたところで一番近い敵を捕捉、通過する点リストに追加。

次に一番近い敵を・・・の繰り返し・・・で何とかならん？

追加、レーザーは何て言うか速度ベクトルに相当する物を持っていて、そのせいでレーザーの軌道が曲がるとする・・・ってなかんじでどう？

ちがうよ！あれはどう見てもそれぞれ係数が違う２次関数だよ。ある点で傾きを変更、そして敵を補足！敵のところまでの距離を計算してちょうど敵にあたるような係数を導き出して２次関数レーザーを発射！！！

一番近い敵だとジグザグに動いたりして具合が悪いから、
現在のレーザーのベクトルを加味してあげたほうがいいと思う。
レーザーの進行方向の逆に居る近い敵よりも、
少し遠くても正面に居る敵を優先するというような。

それか敵の検索範囲を、進行方向の±15度以内とかにするか。

もうこのスレ沈めて。ウザイ
sage進行でお願いします。>>288 >>289 >>295 など

あのレーザーってランダムで曲げてるらしいよ。

キミィ！？ウザイヨ！>298

きり番get!

>>297
真面目な話題までsageさせるなよ・・・。

ゲーム系の板いきなはれ

ゲーム系でも技術の話だからここで良いんじゃないか？

多分、ゲームってだけでウザイんだろう
クソスレ乱立しまくるしな。

各ターゲットを通過するようにホーミング連射でできないかな？

ホーミング連射って？

単語からホーミングミサイルの連射しか思い浮かばないんだけど‥‥‥。

>>301

スレのためだ。sageる者達に気を悪くしないでくれ。
http://piza.2ch.net/test/read.cgi?bbs=tech&key=990219336&st=279&to=282&nofirst=true

>>305
ターゲットが A, B, C とあるときに、ホーミングミサイルを３発発射すると
それぞれ A, B, C に向かうって意味か？

レイフoースのホーミングレーザみたいなものかな。
あれ、複数のザコキャラ貫通してたような（うろ憶えナリ

ロックした複数の敵キャラを、一発のレイフ゜ース式ホーミングレーザーで
撃墜したいってことか。フレーム毎に接続点(ロックした敵キャラ座標)が変化
する３次スプライン曲線？

レイストームの２号機でしょ？

あれはその瞬間のサンダー先頭位置から一定距離、敵に近づくだけ。べつにスプラインでも何でもなかったですけど。

そうそうコードな技術は使ってないよ。

昨夜は盛り上がらなかったのか．．．

ホーミングミサイルをターゲットに当たっても消えないようにして
慣性や、回折のパラメータいぢると結構面白い動きしてくれるよ。

試してみたら？

以前雷電IIやってましたが、プラズマレーザーがロックオンする対象は１つだけだったような気が。
画面上の硬い敵を探してロックオン。あとは293さんと同じように一旦レバー方向に曲げてからロック対象に曲げ直す、と。
#レーザー１キャラ分づつ曲げ>曲げ>曲げってな感じ？
この曲げる時、レーザーのスプライト１つ分の曲げる角度に一定の制限をかければ良いのかとも思ったけど、
この方法だと曲げる目標となる角度が定まった時点でレーザーが直進しそうだから多分これは違うな…。

一見２次曲線に見えるけどゲーム進行中にそんな計算してるかは謎。
もっと簡単な方法ありそうに気はするのですが。

確かにロック点（終点）は一カ所だけど、途中にターゲットがあるときは
ウネーっと変形する。　ガンダーラでも同じレーザーだったような。

自分でやるとしたらホーミング連射が一番楽そうなので、取り敢えずそれで
試してみるとしよう。

とりあえず、誰か雷電IIの基盤のCPU分からぬか？
そこからなにぞ使えるアルゴリズムの範囲が分かると思うのだが。

s/基盤/基板/

MAMEによると初代はV30が２個なんだけど、IIは不明。
ただ、この手のアーケード基板って大抵コプロ載ってないですよね。
（少なくとも手持ちの基板では皆無）
だから実数演算を含むアルゴリズム（２次曲線の算出とか）は
考えにくいんではないかと…

>>319
実数演算そのままやる必要はないのでは？

相手が描画なんで、精度はかなりラフでもいけそう。
大胆に丸めてもかまわんしょ

固定小数なりでやるにしても、
１フレームに１回補間っちゅーのはけっこキツイような気も。
あと、定間隔のスプライトに置き換えるのはどーしましょ？
小刻みにt増やしてってある程度の距離になるたびに描画、とか・・・。

どうも記憶に頼りがちなんで、実物見てこよっと。
たしかRAIDEN FIGHTERSにもあったよね＞プラズマレーザー

SPI基板は386ですよん。
雷電IIからRFJetまでずっとこの基板使ってたんだから凄ぇ、のかな？

あ、あとコプロの類は無いと思われ。
よって実数なんて夢の話ではないかと思われ。
ただし仮想86でなくネイティブだと思われるので、
ギリギリ32bit固定少数演算は可能と思われ。

というわけで、
ここまでは絞り込んでもokなのではないかと思われ。>>317

PS版中古で買って久しぶりに見たナリ。＞プラズマレーザ
ビュンビュンクネクネしなるしブルブル震えとる。
こりゃtry&errorで実際コード書いて見ないとニントモカントモ。

ageて見るけどﾏﾀｰﾘ逝こうね

シューティングと関係ない質問なんですが、アーケードゲーム
の画面みたいに横（縦）に線を入れるというのは、どうやれば
いいのですか？また、これの目的ってなんでしょうか？

for(i=0;i<unko;i+=unkoburi){
Bitblt(......................................);
}

プログラムと直接関係ないけど敵の動き考えるの大変じゃない？
っつっても一番大事だし（敵の動き＆配置）
しかも量いるし。

いや。モーションキャプチャをハエやゴキブリにつけてそれをゲームに移すだけだから。

はははは、やぱーりsageは要るなこりゃ。

330大爆笑！

>>330
主任、ノイズ除去したら何も残りませんでした。

>>332
お〜い、頼むからageないでくれ（泣

>>327
？
基盤起動時のチェックのこと？
あれって、VRAMとかベクトル描画とか画面比のチェック？

ちびまるこみたいに、顔に縦線を入れるにはどうしたらいいんでしょ？

>>335
Σ（ﾟдﾟlll）ｶﾞｰﾝ

ageるヤツはハゲ板住民認定するぞｺﾞﾙｧ

>>327
アーケードゲームは縦の解像度が低いのが多くて、
走査線が少ない（224本前後）ので隙間が見えてるだけでし。
バーチャファイター３とか高解像度のは見えないハズ。

ていうか、ゲーム機の低解像度ノンインターレースのゲームでも見えるんだけどね。
ゲーセンではRGB接続だから隙間もハッキリクッキリ。

モッコリムックリ。

ピッチリムッチリ

>>339-340
ハゲはハゲ山に帰れ。

>>341
童貞は童貞スレに帰れ。

もういやだ！！

ありゃ、せっかくいい感じにマターリしてきたと思ったのだが．．．
ーーーーーーーーーーー
手持ちの環境で、発射位置とターゲットの位置により弾の軌跡がどう変化するかちょっと試したところ、なんとなくそれらしくなりました。

　　＃ホーミングの特性は、発車後時間が経つほど方位決定の
　　　スパンを短くするように設定。

ただ、60フレ程度だと、着弾までに時間がかかりすぎるため、実際には連射ではなく毎フレーム毎に着弾までのステップ分だけオブジェクトを配置すれば良いと思われます。
（注意：あくまでもこの方法でやる場合の話しね）

┌─────────┐
│　 　 　 　 　 　 　 　 　 │
│　ageナイーデください│
│　 　 　 　 　 　 　 　 　 │
└―――──――――┘
　　　　　ヽミ´ー｀ミﾉ
　 　 　　　 ミ　 へミ
　 　 　 　　く

Javaでシューティングゲームを作る場合、
よくJavaの入門書にあるように
全てオブジェクトで管理した方がいいの？

>>346
ageたので教えてあげません。

>>346
それしか方法ないでしょ。Javaの仕様上。

>>364

なにいっての？？？

Javaの勉強しなさい

おかげでsage効果の素晴らしさを再認識したよ。
しつこくageる皆さん、頼むから他所へ逝ってくれ。
俺達はマターリとSTGプログラミングの話がしたいだけなんだ。

ライデンレーザーはいくつか通過点が固定されていて・・・という話を聞いたこと
がある。教えてくれたのは、某ＳＴＧめーかーの人間だよ。

基板もってるなら、がりがり動かしてみるべし。ビデオとってみるのもいいかもね。

予言者も混じってるようなので、sageで行こう。

はぁ？
なんでやらなくてもいいほかのゲームのパクリなんかに力入れてるの？
ビデオまでとって。
独自のアルゴリズムでやればいいじゃん。
つまらねーな。
最近作り手の心が腐ってるよね。
だいたいこういうところってオリジナリティの見せ所じゃん。
それすらないならゲームつくるのやめろよ。
つまらねーageちゃえ。

「オリジナルです！！」と声高らかに叫ぶ奴。
でも実際はありきたりのゲームしか作れない。

オリジナルといっても、二つある。

１．他の方法を知っててなおかつオリジナルに走る場合
２．知らないでオリジナルに走る場合

２の場合は自己満足に陥りやすいけど、１の場合はそれを応用したものが作れる可能性がある。

もちろん１の場合でもその方法にとらわれすぎて、「あー雷電レーザーのまねだね」とか言われてしまう場合もあるし、２の場合でも素晴らしいものができることもある。
ただ、>>353みたいな短絡的なやつには素晴らしいやつはどう逆立ちしてもできないだろうな。藁

いいんだよそれで。
自分で考えて作った結果がそれであれば問題はない。
問題は何故他のゲームを研究までして自分のオリジナリティを切り捨ててしまうのかということ。
技術を盗むとかそういうのとは違うんだよね。
いまこういうやつが何故か非常に多い。
あのゲームのあの部分あの部分・・・

パロディならいいべさ。

実際にパクリを採用するのは別の話でしょ。
今は、そのアルゴリズムがどうなっているのかをマターリとsage談義してただけなんだから。

短絡的な思考の莫迦が混じってくるのは嫌なのでsage

また他のゲームの研究に力をさいてしまうのも問題。
研究しないのも問題だけど。
確かにすべてをしっているのはいいかもしれないけど、それで自分を磨くのを忘れてしまっては本末転倒。

キミの事ですか？

まさか一般論．．．なわけないよね。そんなの聞いたこと無い。

実際問題使うかはともかく、あれがどーなってるの、って疑問を
持てない人間は開発に向いちゃいないと思うなー。
>あのゲームのあの部分あの部分・・・
特定のパクリゲーの批判をしたいならゲー板逝ってくれ。

>実際問題使うかはともかく、あれがどーなってるの、って疑問を
>持てない人間は開発に向いちゃいないと思うなー。
はげしく同意。それを実際に使うかどうかは別問題だし。
とりあえず実装してみて「はー、なるほどねー」で終わる私。

MSXのコナミのゲームは、全てのゲーム会社の教科書であり目標だった

クリエイターに好奇心は必要だね。あたりまえだけど。
エジソン然り、ガリレオ然り。

パクルかどうか別として、興味があるエフェクトとかアルゴリズムを探求するのは悪いことじゃないっしょ。
むしろ、やらないとゲームなんかつくれないよね。

じゃまたsage進行でマターリいきませう。

キャラ管理の方法に関する話題は荒れるのでうんざりだけど。

オリジナルだのパクリだのゲームだの一般系だのは別にして、
「分からないことがあるとなんだか気持ち悪い」というのは
プログラマの習性だと思っていたのだが、最近は違うのかね。

>>363
あの技術は、同じVDPを搭載していたぴゅう太ので培われたものです。
MSXに参入する前はTOMYの下請けでぴゅう太に移植してたんで。

VDPだけでなくPSGのノウハウも一流だったような

コナミビブラート萌え

そういえば、みなさんホーミングミサイルの標的の選定ってどうやってます？

俺が以前やってた方法だと、発射時、右発射は自機に対して最も右方にる敵をソートして決定
左は逆からという風に。

まだこんなくだらねースレ残ってんのか？
ホーミングのターゲットだぁ？
そんなもん自機の進む方向から敵へ曲線引いて曲率半径が大きい奴からターゲットするって昔からキマッテンダヨ！
感覚的にわからねーか？あぁ？

（・∀・）ﾑｷﾆﾅﾙ ｶｺﾜﾙｲ

自機からのどっかのオフセット座標基準にして
いっちゃん近いやつから順番にロックすればい〜んじゃない。

イージスシステムを参考にせよ。

ステロタイプ発見！

すみませんイージスシステムとはなんでしょうか？
ゲームなので余り複雑なアルゴリスムは組み込みたくはないんです。

あと、372はゲームのことを書いてるのでしょうか？

372だけど。
ゲーム以外なんだっつーの？
まさか曲率半径もしらんでゲームの研究？
基礎体力がたりんのでは？
画面といくらにらめっこしてても曲率半径の意味はわからないよ。
計算自体は高校生だってできるものなんだよ。
複雑？お話にならないよ。

>>378
なにムキになってあげてんのかね？キミは
他のスレの迷惑だからsageてくれや
ただでさえage荒しが多くてウゼえのに。

（・∀・）372ｵﾓｼﾛｲ!!

他のスレだってゴミばっかじゃねーか。
何を失うものがあるというのか。

「昔からキマッテンダヨ！ 」だってさ。へぇ〜（^^;

>>379
>>372は自分の知っている情報は自分「だけ」が知ってる情報と思い込んだり、
高圧的な態度で出るしか他人との交際法を知らなかったりする、
かわいそうな人なのです。
健常者である我々はあたたかく見守ることしかできないのです。

他のソフトがどうやってたって、
デザイナーは好きなように実装していいんだよ。
それが独創性ってやつ。

他者の尻を追っかけるだけならまだしも、
それが絶対のものだという思考はダメだよね。

昔から決まってるのか。
じゃ372はファミコンゲームでもその計算をするというわけだな

本当にここはゴミばっかりだな。
オレモフクメテナー。
知らないことはわかるように努力するんじゃなかったのか？
高校程度の数学でもうダウンか？
知識は発想力のガソリンのようなもの。
もちろん使えばなくなる。
経験は磨耗でしかない。すべりがよくなり使いやすくなったころには交換だ。

http://piza.2ch.net/test/read.cgi?bbs=tech&key=990219336&st=350&to=350&nofirst=true

2Dのゲームにポンポン実数演算持ち込もうとする人はスキルが低いと思われ。

まぁ俺は普通の弾幕STGが好きなんで、ホーミングミサイルとか
プラズマレーザーは好きじゃないんだけどな。（藁

何ぃ！マターリと話がしたいだと？
俺が折角荒らしにきたってのに！
つまらん！もう帰る！

>>389
（・∀・）ｶｴﾚ

なんでもいいよ。曲率半径(ﾌﾟ　だろうが他の方法だろうが。
お馬鹿なホーミングミサイルを上手いこと働かせるように自機を動かすのも
シューティングの醍醐味のひとつだろう。
ゲームのデザインによるってことだな。

もちろん、仕事で賢いホーミング作れやｺﾞﾙｧと言われて
実装できましぇ〜んではプログラマとしてアホだけどな。

知識や技術は多ければ多いほうがいいのは確か。
そのための勉強も大事。
っていう当たり前の事が言いにくい雰囲気になっちゃったね（藁

本当に偉いのは実際に作ろうと思って頑張ってる人だけどね（藁

>>388
スキルが低いのは実数演算が要求されるアルゴリズムの実装で、ホントに
リアルタイムに実数演算しちゃう奴。
実数演算が要求されるようなアルゴリズムが持ち込まれたら適当な範囲の
適当な精度のテーブルをあらかじめ作っておいて適当に加工して使うのが
セオリー。

>>393
まあ、「昔の」セオリーではあるが……。

分数使おうぜ
32bitで分母8bit分子24bit

高校のときこれ思いついて俺って天才とか思ったけど、
至極あたりまえのアルゴリズムなんだよね。他人に自慢しなくてよかった（藁

最近のハードは早いから大丈夫でない？
リアルタイムでやってみて、遅かったら、作り直せばＯＫ。
下手に作ると直せなくなるけど、それは論外って事で…。

>>396
それを確認しないでそのまま実装する奴は厨房。
実数演算と整数演算のコストが違うプラットフォームはまだ山のようにあるよ。

>>395
値の表現としてはいいかも知れないけど、乗算以外の演算を実装するのが大変そう。
加減算と除算なんて精度の確保を考えただけで鬱。

>>398
符号の扱いも大変。

単に32bit全体を1/256して考えるってのがいいよ。
加算も減算も符号もそのまんま。

PCとかムキャとか某２とかだと、
2Dゲームでfloatやdouble使うのと
固定小数点数のクラス作るのとではどっちがいいですか？

>>400
分数の表現なんだろ？
通分しないでどうやって加減算するんだ？

だから分母が256固定なんだってば。
32bitには分子しか入れないの。

>>395
よくわからんけど、固定少数とは違うわけ？？

たぶんそのものだと思われ

同じ

今更、固定少数はないだろ？携帯ゲーム機？

オレもPCで固定小数使ってたけど、最近バカらしくなってやめたよ。
しかも、速度ぜんぜんかわらなかったし。
最近はCPUはやくなっていいねぇ。

そいうや、浮動小数点の弊害って速度以外に何かあるの？
自分の場合、環境によって微妙に計算結果が違うという現象に遭遇したことがあるけど。
いつのまにかでFPUのコントロールワードが変化してるってのが原因で、
解決不能だった。(まさか毎回計算前に、コントロールワードを初期化するのか？)
なぜか富士通のPC(FMV)だけで起こる（泣

ゴメンナサイ。クレティカルな部分では固定小数使ってました。
描画ライブラリとか。

お前等MMXって知ってるか？
いまは不動少数点数の方が速いの。

漢字間違えた。
アイモードダカラゆるして

>>410
誰もプラットホーム限定の話しとらんわ
しかもsageない>>410お呼びでない

アルゴリズムの話なんで特定CPUに特化した話されてもね。
つうか当方MMX知りませんが、あれって実数演算について考慮されてたっけ？

一般のゲーム画面に表示されている出力結果からアルゴリズムを推論する事として、
アーケード基板のようなコプロ無しの68000系16Mhz程度のCPUでも難なく使える実装方法
を論じた方が話題としては面白いと思われ。

68000に
68881を10個積もう

コンパイラでやるなら型変換やってくれるからいいけど

>>415
型変換？

>>410
MMXは整数の積和とかを並列実行するためのもんだぞ。
しかも、MMXの最初の実装だとFPUモードとの切り替えコストが異様に
高いので、MMXと浮動小数点演算は事実上排他使用だ。

>>414
ネタに反応するのも何だが、それ読んで手持ちのNAMCOのSYSTEM-II
基板思い出しちまったよ。
メインに68000が２個、その他I/Oやら画面Rotate用（だっけ？）
で全部で４つだか５つCPU載ってたような。考えたらゲテモノだな。

アルゴリズムと関係無い話でｽﾏｿsage

>>408

おいら、まだ固定少数使ってるよ。
ゲームのタイミング計測の時に使ってるだけだけど。

now = 0;
last = now;
interval = (1000 << 8) / 60

　　・
　　・

now = timeGetTime();

keika += (now - last) << 8;
last = now;

while ( keika < interval)
{
　　動作
　　keika -= interval;
}

よくわかんないんだけど、丸め誤差とかってどれくらい気にすればいいのかな。
普通の2Dゲーの範囲じゃ影響なし？

　　　　　　　　おにぎりワッショイ！！
　　　　　＼＼　 おにぎりワッショイ！！　／／
　+　　　+　＼＼　おにぎりワッショイ！！／+
　　　　　　　　　　　　　　　　　　　　　　　　　　　　+
.　　　+　　 ／■＼　　／■＼　 ／■＼　　+
　　　　　　（　´∀｀∩（´∀｀∩）（　´∀｀）
　+　　（(　（つ　　　ノ（つ　　丿（つ　　つ　)）　　+
　　　　　　 ヽ　 （　ﾉ　（　ヽノ　　）　）　）
　　　　　　　（＿）し'　し（＿）　（＿）＿）

>>420
有効桁数に依る。
まぁ、小数点以下４ビット以上持ってれば、２Dゲーなら大丈夫でしょ〜ね。

だって、最終的に必要なのは、１ドット単位の情報だからぁ〜

>>420-422
メール欄に sage って入れてくれ。

>>423
これでいいの？

ま、>>421は age 狙いみたいだけどね。

>>423
421はともかく他はいいっしょ？

>>424-425
このスレ頭から読めば経緯が解るかと思うけどageると荒れるんですわ。
421はアレだけどね。
そんな訳でsage進行しております。一つ宜しく。

ゲームにリプレイつけるときに、キー入力だけとってると、
環境による浮動少数の計算違いが起こったときにオーマイガー。
ていうかマジでおこってるんでー、もう勘弁（；´д｀）

>>419
経過時間(デルタ値)求めて、増加分うにうに動かすやつっすね。


自分も「バカらしくやめたよ」とかいいつつまだ迷ってるんだよね。
やっぱ、固定のほうが考えやすいときはつかっちゃっうしー。

そいや、固定少数の人って、やっぱ、乗除算のライブラリみたいのもってるんだよね？
精度とか速度とか稼げてる？どう？

>>428
そんなに精度を気にするようなゲームじゃないんであんまり…（笑
乗算は出来うる限りシフトで済ませるようにしてるだけです。
キリが良くない場合は乗算使っちゃいますね。
自分は今のところ除算だけは何とかシフトだけで済ませるようにはしてますが。

うわー馬鹿、途中ですげー馬鹿がいるよ。
MMXの別名は浮動小数点数ユニットですがなにか？
インラインアセンブラでMMXを使った後必ずやることがあったはずですが記憶にないですか？

浮動小数点ユニットとレジスタの場所を共有してるだけで、
中身は別物だよね。
MMXは単なるベクトル演算ユニットだよね。

430は某スレの101さんですか？

emms命令ですか？
あれはMMXとFPUがレジスタを共用しているので、
MMXにて格納した値がFPUに浮動小数点値として解釈されてしまって
例外が発生するのを防ぐために、設定を初期化する命令ですよね。

>>430
もういっぺん>>417をよ〜く読め。

うぁ、>>419のwhileの条件式、思いっきり逆じゃん！(藁・・・。って自己レス。

>>430はMiss[c/c++]スレの110に決定。
もしくは同等の馬鹿。

>>435
110じゃない101
鬱だから俺も逝く

>MMXの別名は浮動小数点数ユニットですがなにか？

痛い、痛すぎる…見てるこっちが恥ずかしい。
誰か>>430に頭の病院紹介してやれ。

勉強になったーよ

みんな頭いいね。
んでそれを踏まえて考えてもやっぱり固定小数点の方が速いの？
浮動小数点ユニットってなに？使うと速いの？

>>408
うみゅう。ということは、リプレイ実装するなら（デモプレイとかも）
問答無用で固定小数点数ってことになるっすか？ うあー、めんどくせー。
ゲーム専用機マンセー！

>>439=430
もういっぺん>>393から下をよ〜く読め

アイモードだから見れないダーヨ。

とんでもない粘着馬鹿がいるな。
ご愁傷様です。

スレッド順位70〜80ぐらいでうろちょろしてるのが一番いいんだけどな・・・。

>>410=430=438=439=442
恥ずかしい知ったか厨房はお呼びでない。
相変わらずsageねえし。

だれかi-mode用のブラクラ張っといてくれ

アイモードにブラクラはキカネーヨとりあえず踏めるだけ踏んでみたけどなにもオコラネーヨ。
ところで本気で固定少数点は速いのカーヨ。

加減算については浮動小数点よりは速いんでない？

でもそれは固定か浮動かっていう問題じゃなくて、
それを生かしたアルゴリズムを作れるかって問題でしょ。
難しい知識をいっぱい持ってたって生かせないと意味無いってのと同じ(ﾌﾟ

>>446
そんな質問が出るって事はプログラムを知らない厨房確定
この程度自分で確かめて見ろや

ついでに>>439にコメントしといてやる

>みんな頭いいね。

お前がバカなだけ。

なんだかさ、固定小数ナントカって昨日今日出てきた技術でもないよね。
ごく当たり前の技術なんで今更この話題してもちと不毛のよーな気が。

>>446みたいな厨房はヨソで勉強してもらうとして、別な話題にしては？

ちなみに200辺りからさげてないのはホトンドオレダーヨ。
ココロ残りなのは結局固定しょーすーてんはどーなっターヨ？

固定にも浮動にも一長一短があり優劣は決定できない。
プログラマが必要と思ったほうを適材適所で使うべし。
唯一無二の絶対的手法など存在しない。
＝＝＝＝ 終了 ＝＝＝＝

>>450
粘着荒らしｳｻﾞｲ、お前sage知らねぇのか
得意のMMXでなんとかしてみろや（藁

と、これだけだとアレだ。一例を出そう。
状況にもよるが、ある画像処理ルーチンで実数演算を全て固定少数を
使った整数演算に直したら6.5倍速くなった例がある

教えてやったんだからもう来んな

その使うべきところってのはドコダーヨ？
中身のねー発言は駄目ダーヨ。
オレモナー
ところで明日は部活があるからもう寝るだーよ。

悩みがあるんだったら先生はいつでも相談にのるぞ。

>>453
やはりﾘｱﾙ厨房だったか…
プログラムもわからん奴がMMXとか言ってた訳ね、
全く親の顔見たいわ、ｳﾞｧｶはおとなしく部活だけやってろと言っておくよ

452の固定少数はｳﾞｧｶには解らない所に使用されてます
理解できるか判らんけど画像の回転だ
と言っても厨房には想像も付かないんだろうなぁ…

取り敢えず、以降はi-modeﾄﾞｷｭｰｿは無視しときませう
馬鹿に一々講釈してやる義理もないし

固定小数って、整数２つで小数点より上と下を保持するんですか？

>>457

違う違う。たとえば、32Bitのうち、24Bbitを整数、8Bitを少数
として扱うの。

加算は、普通に加算でOKだよね。

この例の場合の乗算だと、乗算した結果を16Bitシフトする
ことになります。

123.456 とかを 1234560 とかするのが固定小数点。

本来の値を左シフトして10^n倍(10進の場合)された整数にしてしまって、小数点を消してしまうのを固定小数点と思っておくとよい。

コンピューターの場合は、左シフトしたら 2^n 倍だよね。

人間だって固定小数点はよくやるよ。 200 M + 100 M とかね。この場合は右シフトだけどなー。

>>458-459
どうもありがとうございました。
左シフトして整数で考えるというのでピンときました。

ていうか、整数と実数どっちが速いかってすでに環境依存やね。
DSPみたいなプロセッサだと実数演算の方が速かったりするし。

>>461
まあ、そうだわな

だからふつーのPCではどっちなんダーヨ？

自分で調べてみればぁ？ヽ(´∇｀)ノ

>>463
まだいたのかね。
アルゴリズムの話をしてるのに環境依存の条件なんかどうでもいいって
まだ気付かない？

相手にしちゃだめなんだってば

環境も考慮したシューティングゲームがいいダーヨ

俺も画像処理の組み込み（68k）で固定小数使ったなぁ。
あんときは小数点以下の精度が結構必要だったのと、整数部の精度が
あまり必要なかったんで16bit+16bitで実装した。

どんなＣＰＵでも、固定少数演算の方が、断然早いだろ、普通。
・・・スカラー演算専用の大型コンピュータでもない限りな。

>>496
それがﾄﾞｷｭｰｿには理解出来ないようなので皆ほとほと困ってます（ｗ


話変えて、STG以外のアルゴリズムの話は如何かな？
マリオジャンプ・デコジャンプの話しもあった事だし。

×496
○469
ｽﾏｿ、未来指してどうする>俺

>>469
いや、DSPみたいなハーバードアーキテクチャのプロセッサだと、スカラ演算ユニット
搭載してたりするんで侮れません。
加えて、整数演算と論理演算を同じユニットで共用してたりするので、レジスタパスの
競合が起こらない分浮動小数点演算の方が速くなったりします。

>>469

プログラミング作法に掲載された実測値。
少なくともMIPS R10000においては整数演算と浮動小数点演算に
差は無いし、むしろ除算に至っては浮動小数点演算のほうが高速。

いい加減時代の変化に気づけない化石は氏んでくだちー。

>>473
確かに浮動小数点も整数も演算速度には、ほとんど差がないらしいよな。
いい時代になってきたねえ。
でも浮動小数点<->整数の変換は、まだ重いような気が。
結局最後に整数にしなければアカンのなら、固定小数点のほうが有利かもよ。

表示装置にそのままスカラー量ブチコンだれ！！（藁

取り敢えずﾏﾀｰﾘな
>>473
少なくともR10000載せたゲーム機（板）俺は知らんよ。
例としては不適当と思われ。

>>474はsage進行に協力してくれ。意見には同意する。

まぁゲームの話しなんで現実にゲーム基板とかに使われてるCPUを
前提に話し進めた方が良いかと
現実は実数演算遅い化石みたいなCPUが主流だしな。

>>476
わからん。別にアーケードやコンシューマーゲーム作りたいって話では
ないように思うけど。

MMX266とか、ＰＣ系のCPUを基準にするならまだ解るけどね。

>>477
うん、まあそうなんだけど、
スレの流れとして「あのゲームのこの動きはどーやってるの？」ってのを
色々論じてたりするんで、そのオリジナルの物は高速なCPUは載ってない事
からR10000のような例を出すのは不適当と思うのですよ。
ちょっと前の雷電IIのプラズマレーザーにしたってCPUはコプロ無しの
386だったりするし。
現実にその環境で使われているアルゴリズムを考えているので「R10000
使えば全てオッケー」じゃ論点が合わんのです。
それじゃスレ終わっちまうし（ｗ

もちろんR10000が適切だとは思わないです。
でも、ゲーム基盤に使ってるが適切でもないと思ったので。

シューティング作るっていったって、例えばZ80を基準に、ではあまりに
時流からはずれてると思うし、ULTRA SPARCなら、っていうのも違う。

ＳＨ４でも基準にする？（ｗ

個人的には汎用的なアルゴリズムや考え方でスレが進んでくれると
楽しい。

>>479
まぁ「汎用」って言葉の捉え方だと思うよ
例えば上の「固定小数か浮動少数か」の話しにしても、
「固定小数を使ったアルゴリズムならコプロ無しの
環境でもOKなので汎用性がある」とも言う事が出来るし。<ﾁﾄ語弊ｱﾘ
実際のところ実数演算の方が速い環境は特殊な部類でしょう。

>個人的には汎用的なアルゴリズムや考え方でスレが進んでくれると
>楽しい。

この辺はかなり同意。
そんなんで特殊なプラットフォームを持ち出すのはちと抵抗アリです。

固定小数がいいと思いますよ。
普通に考えるといまどき固定小数を使うなんて
アホ丸出しなんですが、浮動小数はまれに
環境によって計算結果が違うことがあるので
ゲームに使うとリプレイが保証されなくなります。
だからシュ−ティング程度だったら
迷わず固定小数でよいと思います。
よって、CPUも8bitまで退行してしまわなければ
何でもいいんじゃないでしょうか。

最近のＣＰＵは、整数演算より、浮動小数の方が速いんじゃないの？
と言ってみるテスト。

処理系の話題は特に「○○という石を使ってデジタルフィルタ設計しろ」、というわけでもないんだからこの辺でいいのでは。

今のところアマチュアがターゲットにできる環境もPalmからPC、プレステ２多岐にわたってることだし。

C++で固定小数点数クラス作ろうと思うんですが、クラス名どうしましょうか？

ジャンプの話題も面白いね。

メタスラなんか空中操作できるかできないかでゲーム性は全く変わるし。
（基本的に空中操作できないシステムのは憤死が多い）

>>484
FixedPointRealNum とか。

＞リプレイ
3Dで固定少数使うのもアレなんだけど、
それだとキー入力でリプレイとるわけにいかなくなる・・・。
どうしましょう？

やっぱ、座標とかその辺を記録しとくの？

>>487
大丈夫、リプレイが必須のアーケード基盤なら、どう考えても同時に他のアプリは走ってないからさ・・・。

>リプレイ
ネタにしか聞こえないかもしれないけど
録画で出来ちゃったらすばらしいと思う。
巻き戻しとかも出来るようにして。
いや、ネタにしか聞こえないけど。

座標記録のリプレイ、、、
結構鬱だ。

キー入力記録以外でリプレイとる方法ってどうよ？

>>484

固定少数と意識させないような名前にする、
というのもひとつの手かと。

vecmathていうライブラリがあるから
それを参考にしてみるのもいいかも。

テンプレートを使って、うまいこと定義してるよ。

ワークメモリ全部保存して差分でも取りますか？
って、考えるほどに鬱になるな。

ようは、バーチャのりプレイどうやってんのよってことになるんかな。
KO後に、KOちょい前から再生されるよねアレ？たぶん。

>>493
数秒前のワークエリアすべてと、そこから先の入力を
毎フレーム記録するようにしておけばよいと思われ。

……じゃ駄目やん。

リングバッファ用意して、ゲーム中の過去数秒間のオブジェクトの状態を
全部まるごと記録してしまえばいいと思われ。
格ゲーなら記録するべきデータ少ないし。

>>495
何故かグラディウスのオプション思い出した。
以前マウスカーソルを追いかけるオプションってのをWindowsで作った時に、
位置座標を格納する配列要所を循環させて読み書きしてたけどそういう感じ？

>>494-495
なるほどん。
あらかじめ効率よく記録できるようなオブジェクト構造にして、
プログラム組まないといけないのね。
ゴチャキャラゲーだときつそう。

それに、オブジェクトを１個１個クラスなんかで定義してると、余計きつそうだ・・・(速度的に)。
うーん。

そういや、QuakeとかUnrealみたいなFPS系もリプレイついていたような・・・。
そういうのも見てみる価値アリだな。

半透明キャラクタってやはり描くのは一番最後？

オブジェクトの上下関係にもよるけど

http://www1.odn.ne.jp/~cca57640/age_01.jpg

>>501
このスレが好きならageないでくれ。頼む。

>>501
arashikettei

>数秒前のワークエリアすべてと、そこから先の入力を
>毎フレーム記録するようにしておけばよいと思われ。

こっちでも上手くやれば使えるんじゃなかろうか？ メインループ１回で、
現在のワークエリアとリプレイ開始点のワークエリアを両方１フレームぶん進めるの。

メリットはワークエリア２つぶんのメモリで済むこと。
（シューティングとかにも適用できるんじゃないかしら）
デメリットは倍の処理負荷と、やや実装面倒くさげなこと。OOでエレガントにやりたい。

＞OOでエレガントにやりたい。
それ重要なんすよ。


やっぱ、498でも書いたけど、FPS非固定系の処理がきになるなあ。

＞以前マウスカーソルを追いかけるオプションってのをWindowsで作った時に、

ついでにボタンをクリックするとレーザーやミサイルが発射されるようにして
公開きぼん。

>>506
元ソースもう無いよ
まぁ、マウス軌道を追いかける部分だけならほんの数行だから
すぐ書けるけど

沈んでいても多くの人がみているのでレスはsageでOK。

だからsageてるじゃん。

でもって、誰も書かなくなるのな

某所の斜めスクロールの話だけど、画面をずらしてから隙間を描画・・・と一枚絵からどかんとコピー・・・はどっちがどれだけ速くなるかな？

>>511
本題は、鬱直罰スレにすでに移ってる気がするが、それはおいといて。

BG面が複数あるゲームだとずらしは使えないから、
今更、あまり意味のある議論ではないかと。
そもそもずらして描画で速度がかせげるという状況下は、
・マップチップ等のパワーを食うな処理が入る場合。
・スクロール自体がハードウェアの機能で実現できる場合
って感じだからな・・・。
１番目なんか、　今のPCマシンでそんなオーバーヘッド気にすることか？って気もするし。

＞・マップチップ等のパワーを食うな処理が入る場合。
・マップチップ等のパワーを食う処理が入る場合。

>>508
見てるだけじゃダメじゃん(age

>>511
いずれにせよ全画面書き換えせにゃアカンだろうから、今時
の環境ならどかん一枚絵の方が速いだあよ。

携帯系のような、リソースがプアな環境なら結局環境依存ぽい。

さんくす〜

http://www.intel.com/design/pentium4/manuals/248966.htm
より、レイテンシ／スループットは

整数
ADD 0.5/0.5
IMUL 14/3
IDIV 56-70/23

短精度浮動小数点
FADD 5/1
FMUL 7/2
FDIV 23/23

ＳＳＥ
ADDSS 4/2
MULSS 6/2
DIVSS 22/22

和差なら圧倒的に整数ですけど、乗除算の多い最近のプログラムなら
浮動小数点使った方が速そうですね、ただ浮動小数点から整数へ変換する
FIST命令が載ってなかったので参考までにＳＳＥ命令のCVTPS2PIは
7/2となっています。

　ですから、最近のＰＣで開発するのなら浮動小数点でも十分では
ないでしょうか？特にDirectXは浮動小数点が基本ですしね。

sage

縦シュー雑魚の肝、ヘリ雑魚の移動ってどうやってます？
自分は一定フレームごとに目標点を再設定して、そこまで乱数加速とか…
んーいまいち。

>>517
いやあ、普通にやるなら素直に浮動小数でいいってのは
誰も異論ないと思う。

ただ、リプレイ処理が加わった場合、浮動小数の演算結果は
プロセッサによって変わってくるので
どうしたものかって話みたいッス。

同じ環境でリプレイかけるだけなら問題ないと思う。
問題は、デモプレイとか、リプレイデータをネットでやり取りしたいときとかですな。

浮動小数点数の演算結果が変わる要因てのはCPUだけ？
CPUでも、メーカーで異なるという位のレベルなのか、
それともコアによっても変わってくるのか？　ワカラン

浮動小数点数で判定する時、少数点３位辺りで切り捨ててから
判定すれば良いのか？　ワカラン

>>522
そうそう。浮動小数点のおかげで結果が変わるのはわかるんだけど、
どこがどうでどういレベルでどうってのが詳しくわからない。

>>521
というわけで、解析用にデモプレイ搭載のゲームのソース落ちてないかー。

でも最近は大抵リプレイ機能搭載してるよね。
縦シューだから浮動小数点は使ってないのか？

2DのSTGに限定すると浮動小数の出番は殆ど無いんではないかと
固定少数＋各種計算のテーブル化で実数演算の大半を排除できるし

リプレイで思い付いたんですが、
・入力は全部記録していく
・一定時間（又はフレーム）毎に座標も記録する

で、リプレイ再生時は入力をトレースさせるけど、一定間隔で座標を修正するってのはどうでしょ
３Ｄ限定っぽくなるかもしれませんが、座標修正時に視点も変えれば多少のズレはバレないと思われ

リプレイ + 浮動小数点の問題って、googleなんかで検索してもでてこねぇ。
以外にみんなこの辺は気にしてないのか、既知の解決法があるのか・・・。

でだな、問題は浮動小数バリバリの3Dゲームなんだよな。
たぶん、その辺のレベルで考えれば、2DのSTGなど楽勝だろう。

つーわけで、手始めにlinuxdoomのソースみてみた。

記録部分は、
*demo_p++ = cmd->forwardmove;
*demo_p++ = cmd->sidemove;
*demo_p++ = (cmd->angleturn+128)>>8;
*demo_p++ = cmd->buttons;
こーんな感じで、毎フレームバッファにプレイヤーの前後方向の移動量とか
角度とかボタンの状態とか記録してるだけー。
むー。

＞毎フレームバッファに
毎フレームごとに、バッファに

援軍を求めるためにageてもよいだろうか？（葛藤モード）

このスレほどよく育ってきたから、あげてもいい気がする。
むしろ下がってるのがもったいない。

>>531
せ、責任はとらねぇぞ！age

（・∀・）ﾆﾔﾆﾔ

このスレほどよく育ってきたから、さげてもいい気がする。
むしろageて荒ませて廃れさせるにはもったいない。

なるほど。

テレホタイムを避けて、たま〜にageる分には
“ほど良い刺激”が味わえていいかもね（； ´∀｀）

＞リプレイ処理の話

以前ヘタレゲーを作ったとき
リプレイの開始時点、全ての情報を記録。
残りは、キー入力と時間のみ記録してました。

リプレイ時の処理は、ゲームプレイ時のそれと
同じものを走らせました。初期条件と、途中の
外乱要素さえ記録、再利用すればfloat精度に
よる誤差の蓄積を再現できるためです。

以下感想↓

■処理が再現できない場合の、ありがちなミス(自分の場合)
　(a)乱数の生成を管理していない　(Ex:擬似乱数のseed)
　(b)FPS可変でゲーム進行速度を一定に保つよう調整しているが
　　フレーム間の時間偏差が実行毎に未知である点を考慮していない。

・・・的外れだったら申し訳ない。

訂正
×　FPS可変で
○　FPS可変という条件の元にある場合に、

自機を狙って飛んでくる弾の、高速なフローって無い？
ｱｸﾀﾝ2使えばいいのはわかるが
ﾌｧﾐｺﾝのﾒﾓﾘ量で、変換表使ってるとも思えないのよね。

>>538
ピタゴラスの定理

ブレゼンハム

>>536
残念ながら、今回は的外れと思われ。
>再利用すればfloat精度に よる誤差の蓄積を再現できるためです。
その浮動小数演算の結果が再現できないから困っておるのだよチミ。

Intel系CPUの場合、floatだろうがdoubleだろうが
常に80bit精度で浮動小数演算していると聞いたのだが、
AMD系やCrusoe他ではどうなのであろうか？
Javaにはstrictfpなんてキーワードもあるな。

>>538
68のHDDから引っ張り出してきたじょ。

static uint8 *angle_t;
#define PRS 256 /* もっと精度下げてもいいかも */

/* atanテーブルを作るらしい */
int angle_init(void) {
　　angle_t = malloc(sizeof(uint8) * (PRS * 2 + 1));
　　if (angle_t == NULL) return -1;
　　angle_t += PRS;
　
　　for (int i = -PRS; i <= PRS; i++) {
　　　　double a = atan2(i, PRS);
　　　　if (a > 0) a += PI2 / 256 / 2;
　　　　else a -= PI2 / 256 / 2;
　　　　angle_t[i] = a * 256 / P12;
　　}
}

/* 0〜255で角度を返すらしい(本当はアセンブラ) */
uint8 angle(int16 x, int16, y) {
　　if (x == 0 && y == 0)
　　　　return 0;
　　if (y < x) {
　　　　if (y > -x) {
　　　　　　return angle_t[(int32) y * 256 / x];
　　　　}
　　　　return angle_t[(int32) -x * 256 / y] + 192;
　　} else {
　　　　if (y > -x) {
　　　　　　return angle_t[(int32) -x * 256 / y] + 64;
　　　　}
　　　　return angle_t[(int32) y * 256 / x] + 128;
　　}
}

>>539
低脳ＣＰＵでも、毎回^2をやってられるですか？
傾き量で、ｲﾝｸﾘﾒﾝﾄする側もﾁｭﾝｼﾞせなあかんし。

>>541

Aというハードウェアで記録したデータを
Bというハードウェアで再生したら結果が違う。困った。
という話をしていたのかー。

俺、てっきりプレイ直後に再生するリプレイ機能の話をしてる
のかと思ってたよ。

これやっぱ勘違いかな？

とりあえず、>>520以降を見られい。

ホーミングなんて外積で一発ではないのか？

>>544 >>546 頼むからあんまりageないでくれ。
荒らされるから。

■■■■■■■■■■■■■■■■■■■■■■■■

いままでありがとうございました
今回で終了させていただきます
長い間本当にアリガトウございました

■■■■■■■■■■■■■■■■■■■■■■■■

軍事板の「ジパング」スレが繰り返しレス飽和攻撃を受ける事態が
発生しているが、ここもその手のキチガイがはりついてると思われ。
世の中にはマジで変な人がいるから、ageないようにしましょう。

>>547
すまん。ってもう遅いか。
鬱だ氏脳

でもさあー。
あれないと面白くないよー。
なんか古いんだもん。
ここの話題。
変なとこばっかり気にしてゲームを面白くする話題はもうないの？
おれが気にしたことなんかない話題ばっかりでてくるよ。
せめてターゲットマシンはどれくらいなの？
なんかシューティングゲームが廃れちゃった理由もわかるよ。

ゲームを面白くする話題はゲームを作る上で最重要だからこそ、
ここで話し合いたくないんじゃないのかな(藁

むしろ、どうでもよくて軽く流したいのに、
なぜか面倒くさくて泥臭いことに対しての解決策を話し合いたいというか。

>>544
そうそう、前半の方。それっす。いや、後半も重要なんすけど、途中で流れが変わったというか。

>おれが気にしたことなんかない話題ばっかりでてくるよ。

キミの少ない脳ミソでは理解できない話題の間違いだろう。
ここはプログラミング技術を語る板だ。
ハゲはゲーハー板に帰れ。

>>542
超弩級ｻﾝｸｽ

俺がアホなんじゃなくてここの話題はやっぱり変だよ。
いまのマシンじゃ気にしたって意味の無い話題が多いよ。
それと不必要に下げろ下げろうるさい割りには人のこと煽るよね。

（・∀・）ﾏｧﾏｧ

ｱｵﾙｻ!

>いまのマシンじゃ気にしたって意味の無い話題が多いよ。
つーか、実際現場で問題になってるんで（泣

>いまのマシンじゃ気にしたって意味の無い話題が多いよ。

リプレイの件は今のPC環境だからこそ問題に挙がっとるのが分からんか？
テーブル使ったatanも、浮動小数演算を避ける場合には必要になろうし
無意味にはほど遠い。

リプレイは意味のある話題だね。
現場で問題になっているなら、俺なら、固定小数点＋キーにするけど、
今更無理かな？

あと、基本的な事なんで、誰も話題にしてないけど、
制御系のワークと表示系のワークの切り離しは必要だね。

制御系のワークとキーデータのみで、完全に処理が再現でき、表示系のワークが作成され、
表示系のワークのみで、完全に表示が再現できるようにすること。

制御系のワークも表示系のワークも必要なものだけにして、できるだけ絞りこむこと。

1.再現性がある場合(固定小数点、不定でない乱数使用、同期通信)は、ある時点での
制御系のワークと、それ以降のキーデータを保存して再生する。
2.再現性がない場合(浮動小数点、不定乱数、バグ、非同期通信)は、表示系のワークを
保存して再生する。

素人意見でした。

↑あげてもた。
スマソ。

浮動小数演算をさける理由が変だよ。
別に浮動少数演算だからって計算するたび値が違うわけじゃないし。
マシンによってちがくとも一つのマシンで同じ結果がでてくれれば問題ないでしょ？
でもって速度についてはDirect3Dを使うとかいう話になれば
浮動少数演算の方がぶっちぎりで速いです。

561 名前：sage 投稿日：2001/06/09(土) 13:01
リプレイは意味のある話題だね。
現場で問題になっているなら、俺なら、固定小数点＋キーにするけど、
今更無理かな？

あと、基本的な事なんで、誰も話題にしてないけど、
制御系のワークと表示系のワークの切り離しは必要だね。

制御系のワークとキーデータのみで、完全に処理が再現でき、表示系のワークが作成され、
表示系のワークのみで、完全に表示が再現できるようにすること。

制御系のワークも表示系のワークも必要なものだけにして、できるだけ絞りこむこと。

1.再現性がある場合(固定小数点、不定でない乱数使用、同期通信)は、ある時点での
制御系のワークと、それ以降のキーデータを保存して再生する。
2.再現性がない場合(浮動小数点、不定乱数、バグ、非同期通信)は、表示系のワークを
保存して再生する。

素人意見でした。


562 名前：デフォルトの名無しさん 投稿日：2001/06/09(土) 13:03
↑あげてもた。
スマソ。

>>563
あの、できればスレの流れをキチンと押さえて下さい。
http://piza.2ch.net/test/read.cgi?bbs=tech&key=990219336&st=408&to=408&nofirst=true
http://piza.2ch.net/test/read.cgi?bbs=tech&key=990219336&st=427&to=427&nofirst=true
http://piza.2ch.net/test/read.cgi?bbs=tech&key=990219336&st=520&to=523&nofirst=true
http://piza.2ch.net/test/read.cgi?bbs=tech&key=990219336&st=541&to=541&nofirst=true
http://piza.2ch.net/test/read.cgi?bbs=tech&key=990219336&st=544&to=545&nofirst=true

>>563
浮動小数点の話に関していえば、論点がずれとると思うぞ。
あと、頼むからsageてくれ。粘着厨房でもなかろう？

理由もなしに論点がずれていると言われても
つまりなんの為にやってるんです？
ageますよ。

>>567
>>565のリンク先をよく読め。読んでわからなかったら二度と書き込むな。

要は異なるPCでのデータのやり取りのサポートの話をしてるわけね。
うわぁ、かんけーねー。
ってか見たことねーよそんなゲーム。
わかりました。なんだか小難しいことをやっておられるのですね。
どうりで見たこと無いはずです。
ありがとうございました。

　　ﾊﾊﾊ
　 ∧＿∧　　／￣￣￣￣￣￣
　（　＾∀＾）＜　見たことないてさ
　（ つ ⊂ ）　＼＿＿＿＿＿＿
　 .）　 ）　）
　（_＿）＿）　　　　　（＾∀＾）ｹﾞﾗｹﾞﾗ

じゃあ、有名なんだ？

>>571
とりあえず、ここ(>>521)を読んでみてはどうか。

ゲーム全体に意味のない制限をもたせてしまうなら。
デモプレイなんて真面目にやる必要なんてなし。
適当に派手に魅せておけばいい。
大事なのはあくまでゲーム本体。
ということはやはり異なるPCでのデータやりとりだけですな。
もしPCでパネキットが出たら、結果が変わると萎えるとか。

>>573
＞ゲーム全体に意味のない制限をもたせてしまうなら
あのさ、別に制限をもたせようという趣旨の話
では無いと思うのだがね。何所の話なんだい？

思いっきり制限でしょう。
0から1で変化する媒介変数や正規表現が使えなくなると3Dだとちとつらい。

おっと、ageちった

>>575
それは実装上の制限であって、同じ事を実現するのに別の手段を
使えばゲームの制限にはならない。
で、ここではその等価な手段について議論してるんだが。

>>575
素人なんだけど、質問していいですか。
例えば>>525氏のような対策案では解決できない
根本的な問題があるということでしょうか？

＞0から1で変化する媒介変数や正規表現が使えなくなると3Dだとちとつらい。
もし宜しければ詳しく解説していただけると有難いです。
あと、正規表現てgrepやawkで使うアレのことでしょうか。
恥ずかしながらこれしか思いつかないのです。

苦労してこんな面倒なことする必要はないのだが。
媒介変数の問題はどうするの？
これなんとかしたら大したもんだよ
あと正規表現は正規化の間違い。すまんす。
でもないと3Dじゃこまったゲームしかできないと思うんだ。

>>575=>>579
＞媒介変数の問題はどうするの？
＞これなんとかしたら大したもんだよ
すみませんが具体的にお願いします。
媒介変数や正規化が使えなくなる状況とは？
媒介変数の問題とは？

ごちゃごちゃいわずにやってみれ。

>>581
いや、ハタから見ててもここまで抽象的に
書いてあれば流石に意味不明かと思われ。

戯言癖の妄想厨房と区別できるような書き方
にせんとマズイだろうに。

http://www.watch.impress.co.jp/game/docs/20010417/scei.htm
>■「GT」のネットワーク対応版もすでに構想に! その名も「GTN」
まったくコンシューマ機はうらましいですな。

デモプレイなんかは、描画に必要なデータ全部記録して適当に圧縮かけて
ストリームで流すのがいっちゃん楽かも知れん。

演算で誤差がでるのならば、絶対値で記録するのがよいかと。
毎フレームの絶対値（？）ならば、そこからの誤差ぐらいは気にしなくても
よいかと。データ自体は互換性を保つためにＩＥＥＥで決められた方式で吐
き出されているハズなので。データ量が多すぎる？

っちゅーわけで一度実装して確認してみよー

>585
それが面倒だからグダグダ逝ってんじゃないのか？

>586
んー、だとするとちょっと問題かな
色々な案が既に出てる訳なんで一度実装するか、脳内コーディング（笑）した上で
良いマズイを評価して欲しいんだけど。
実装上問題があれば、そこからまた話が進むだろうし

あと上で「媒介変数の問題」って突然でてるけど、具体的にどう問題に
なるのか説明が欲しかったね。スレ読んでてちと説明不足を感じるし。

12　デフォルトの名無しさん　　2001/06/10(日) 00:22最近の粘着系の奴らはfjなのかな？
嫌に無意味にしつこいやつがいるよね。
あげ足とり系の奴ら。
あと嫌に馴れ合いの好きな奴ら。
シューティングのスレは今頃ゴミになった技術をさも重要そうに話してて気持ち悪い。
し、なによりも排他的な思考がどうも2ちゃんらしからんにほひがする。
13　デフォルトの名無しさん　sage　2001/06/10(日) 00:23>>11 は荒らし。
暇な人はいいねー。
14　779　age　2001/06/10(日) 00:24>>12
そうやって２ＣＨに自分のイメージを押し付けるのはどうかと思うぞ
自分の技術が足りずに恥をかいたからって批判するのはどうかと
15　デフォルトの名無しさん　　2001/06/10(日) 00:34いやそうじゃなくて、あのスレってまさにゴキブリのいない厨房なんだよ。
荒らす気もおきないほどつまらないっての？
いつもはゲーム系の話ならつっこんでいくんだけど今回はお休み。
やっぱり話題がシューティングだから？
STG作る奴らはなにかつまらないところがあるのかもね。
あのスレがいい例かな。

とりあえず、オレはシューティング作ってるわけではないので念のため(藁

まあ、正解は掲示板でだべってないで設計なりコーディングなりしろってことだな。

>>588
ﾜﾗﾀ

デモプレイは、CPU間で差があるゆうても
たいしたことあらへんやろと決め付けてやるのがええかもしれへんよ。
どっかで判定狂うてカオスになるかもしらんけど、
ひととおりのPCで動く操作データ使えばええんちゃうか。
ちゅーか実際ワイはそれでうっちゃっとる。

機種間のデータのやりとりは・・・
ゲーム的によっぽど必要でない限り、あきらめるってのでどない？
たしかにプレイデータのやりとりとか結構盛り上がるんやけどね。

age

ティム

その前に3Dシューチングは自分以外の環境で動くかどうかの方が問題だったり

現実的かつより深刻な問題が出たところで終了。

お前らってDirectXで背景をBGチップ使って描いてる時に
背景のパターンアニメってどうしてるよ？
BG表を、一個ずつ進行に従って書き換えるのか。

ふりっぷ

>>598
パターン数がチップによって違う場合は？

画面解像度と同じ大きさのオフスクリーン(orテクスチャ)サーフェス2,3枚。
その場面で必要な全キャラ分のデータを配置。番号付け。番号←→U,V表。

・・・かなりイイ加減にやった。

むしろ参照する画像を逐次変更するという方法もある。

Pentium 4向けの3D CG技術デモ「Actor - Technology Demo」v2.0が公開
http://www.forest.impress.co.jp/article/2001/06/12/actor.html

どうよ。

デモスレと間違えたスマソ。

>>597
よく覚えとらんけど。
アニメーションする奴だけ別で作ったような気がするが。

BG
アニメBG
キャラその他スプライト物
スコアなど

の順で描いてた。

>>604
アニメＢＧは、毎回領域全部に置換かけるの？

>>604
アニメＢＧは、毎回領域全部に置換かけるの？

参照するを書きかえるといっせいにアニメするけどいいのか？
アニメする領域が大きい場合と小さい場合で向いている方法が違うとは思うけど。

>>605
へ？
置換えを全部？
よく判らないのだけど。

>>608
BGマップで00FFを全て00FEに書き換えたいな〜って時に
全領域サーチして置換するのか？って思ってしまた。

>>608
ちなみに「置換」は「チカン」と読む。

>>608
ちゅぼーはけーん
「置換」っていつ習う漢字だっけ？小学校？

俺が知ったのは水上置換法とかいう理科の実験だな。
なんとも怪しい名前だ。
下方置換もあったっけ？

ちなみに「代替」は「ダイタイ」と読む。

　　∧ ∧　 　 　┌─────────
　　( ´ー｀)　　 ＜　シラネーヨ
　 　＼　< 　　　 └───/|────
　　　　＼.＼＿＿＿＿__／/
　　　　　 ＼　　　　　　　／
　　　　　　　∪∪￣∪∪

>>611
チカンは二十歳から

スレと関係ない話ならsageろよ・
せめて

あーあ、置換を置き換えって読んだら厨房ですか。
まぁ、どうでも良いけどね。

>>609
マップとは別に、アニメーションするＢＧってのを用意するんですよ。
だから、置き換える必要ないとね。

ターゲットは、DirectXです。
SFC 等のハードを使うなら、確かに置換処理は必要ですけど。
今時無いし。

判官贔屓

お前ら頭良いな（ｗ

？？？？
置換は「ちかん」
置き換え、置換えは「おきかえ」
だろ？

>>605
わかりづらい
>>608
言葉が悪い
>>610
勘違い、いらんお世話
>>611-613
痛いフォロワー
>>614-615
好き
>>621
ザ・厨房

>>620
それぞれの意味は？
同じじゃないの？

もしかして、置換　と　置き換え　って全然違う意味だったの？
もしそうなら　俺　マジデ厨房だ

と思って調べてみた

■［置換］の大辞林第二版からの検索結果　


ちかん ―くわん 【置換】

（名）スル

（1）置き換えること。
（2）〔数〕 相異なる n 個のものの順列を、他の順列に移す操作。また、一般に一つの集合 M から M 自身の上への一対一の写像のこと。
（3）〔化〕 ある化合物の原子または原子団を、他の原子または原子団で置き換えること。また、その反応。置換反応。

良かった、意味があってて。

>>622
わざわざ辞書まで引いてひっぱらんでもいいに。まともな
奴ならあんたが間違ってないことは分かってるよ。

ただ、エディタとかいじってる人にとって、「置換」という言葉は
一種のテクニカルタームの様な響きを持つのかも知れないね。
実際オレ自身、>>605は置換と読んだ方が理解しやすかった。

ワリィ。異音同意語(?)だって言いたかっただけ。

俺の周りだとチカンって言うと(ﾟДﾟ)ﾊｧ?なんてされる事がたまにあるんで、わざわざ「置き換え」って読み直してる。（藁
意味が同じだからどっちでもいいけどな。
関係無いのでsage

ワロてしまった。スマソ

最近はセクハラがどうとかウルサイからね

先頭をチカンして！

さて、そろそろ本題に戻ろうか。
いや、もともと本題からずれて育ってるけど。

>>624
理解。

初心者でゲーム、
べーマガ読むのじゃ

ゲーム業界に入りたい連中の集まるサイトで、ベーマガをすすめてやったら、
「毎月カネのかかる月刊誌なんてもってのほか！」とさんざ叩かれたのう……

見当はずれの理論書ばっか読んでないで、アマでもしっかりゲームしてる奴の
ソース見ろやｺﾞﾙｧ!　とか思ったもんだ。

僕はゲーム会社につい先日入ったばっかりの者なんですが、
ベーマガはバイブルでした。
小学生　中学生の頃は、あれでソースを読んで勉強？してましたし
(勉強って感じ全くなかったけど)

プログラムの能力って　色々な人のソースを読んで作られていくべきであって。
ヘッダーファイルにソース書くなゴルァ
.Cppが一つの物作るなゴルァ
人に読めるソース書けやゴルァ
とかついつい思ってしまいます。(他の応募作品とか見ても)

まぁ、当時ベーマガが、何故か市立図書館に有ったから
読破してたんですけど。
ここまでは　関係ないか

結局、自分への投資に渋ったら、そこで脱落決定ですね。

>>632
そう言う人たちは、海外のGameDevelopersMagazineに対しても
同じこといいそうな気がする(藁

>>632
勉強に対しての金をケチるやつ＝勉強に対する比重が軽い
＝・・・結局その程度の熱意ってことだと思う

勉強の仕方なんていろいろあるだろう。やりたいようにやるのが効率が良いの
ならそれでいいんじゃない？　金がないってんなら、しょうがないじゃん。

デバッグのアルバイトをすすめてみたら？

やりたいようにやって遠回りでも本人の責任だからな。
別にいーんじゃねーの？

ただこれだけは言っておくが俺と同じ職場には来るな。来たら殺す。

>>636-637
そういうやつは教えてクン率高そうな気がするぞ。（推測）
だとしたらこっちにとばっちりがくる。

２Ｄで斜め移動するときですが、移動量はどれくらいにしてます？

>>639
普通移動が１なら。
横１　縦１だよ。
後はいい加減に調整してみる。

確かに、横２の時に　斜めが横１縦１の方がリアルっぽいけど、
どーせ２Ｄだし。

と、あげてみるテスト

___
ﾀﾋ ﾈ

移動量は固定だよ。
sin cos で方向からXY分離しましょう。
勿論座標は固定小数点でね。

>>640

ageるなよ〜sage

縦1、横1なら、斜めは√2だわな。普通は。

ただ、ゲーム性によっては斜め移動を高速なことを利点にさせたいなら、
斜め移動も1か√2以上でいいかもしれん。
スターフォースなんかも斜めは1:1でないけど若干はやいよね。

げ、なんで√2なんだ。おいおい。スマソ。縦横斜め1:1:1だ。

原点からの距離換算ね

>>640
おいこらちょっと待てい。クソゲー作るな（ガレッガ含む（俺的偏見

>>639
45度方向なら、

vx=±speed/√2
vy=±speed/√2

を使いましょう。任意方向なら三角関数使ってねん。

>ただ、ゲーム性によっては斜め移動を高速なことを利点にさせたいなら、
>斜め移動も1か√2以上でいいかもしれん。

うむ。操作感を重くするためにちょっと遅くしたりします。
でもこれは高等テク。（そうか？）

>>647
ガレッガは斜めが√2になってないってこと？詳細きぼん。

趣味で作るんならターゲットマシンのドット比に合わせて、
自分の感性で「気持ちいい」という数値を使ったほうがいいよ。
ドットの縦横比違うときもあるし、自機のデザインからくる違和感とかもあるし。
計算上では、固定少数で>647の式でＯＫだけど、
実際にやると斜めが少し遅く感じるかも。
個人的には、ほんの気持ちだけ斜めは早く移動できると気持ちいいです。

>>647
ちっ
遙か昔のゲームは　そーゆーのおーかったのにっ
（つーか　俺がそーゆーの好きなだけ。

普通の感覚だと等速度なんだけど、わざと斜めだけ速くしてるゲームあるよね。
その方が逆に気持ちいいというのはあるね。それを利用したさばき方なんかでてくるし。

そう言えば慣性のあるシューゲー
って見たこと無いな・・

>>653
ピストル大名（藁

>>653
FM-7のゲームとか。

Oh, I'm just kidding!!! HAHAHAHAHA!!!

弱い慣性がかかってるゲームって結構ないかな。
ブレイジングスターとか。

慣性って言ったらエクセリオンだろ。
これ常識。

レイストームが慣性ちょこっとかかってるね。
賛否両論だったけど。
あれの移動速度も、計算は3Dだけど感覚は2Dなので、
移動計算は相当調整してあると思う。
正直に計算すると、方向によって移動速度が変わるし。
て、実は正直に移動距離比1だったりして（藁

レイストームって、カメラが遅れて追従するから、
動かしてると自機の正確な位置見失うんだよなあ。
弾避けしにくいったらありゃしねー。

＞て、実は正直に移動距離比1だったりして（藁
ありうる(w

>>654
ピストル大名でageるあなたは男だ。

勘違いスマソ。

雷電�Uの「不意打ち」に泣いた
(真後ろから撃ってくるなんて・・・ひでぶっ)

追加。「ドンパチ」(漢字忘れた)
で確認したところ画面下1/5位からは打ってこない

これではプログラムの話と言うよりは
ゲームデザイン関係の話だな

>>664
むしろ美学の類では

流れに全然関係ないけど、
ステートマシンなんていまどき古いって、どういうこと？
替わりに何を使えって言うの？
もう、この話題は禁止？

つーか、ステートマシンってなんよ？

おれもわからん

>>667
ぷあ！自分で調べれ！

ﾁｮﾝの方言です

標準語では何て言うの？

>>671

ステートマシンだよ

http://www.google.com/
検索しろよ。つーか、「ステートマシン」あるいは
「状態マシン」のキーワードがわからんって
それでもプログラマのつもりか？

とか言ってみるテスト

うーん、つまり状態を表す変数を用意して
それに対応した関数を呼び出す、ってことか?
うまく飲み込めないな。

自分は技術屋だと勘違いしているため感覚がマヒしていると思われ。

素人だから何にもわからん

何事にも初めはあるのさ。

飽きっぽいので初めしかないさ

と言うわけで。
移動量　縦４　横４　斜め押したとき、縦４　横４　で移動するシューティングゲーム
作り出しました。
（やっぱ　俺にはこれだよなぁって）

それで、今３２Ｂｉｔ　ＤＩＢで作ってるのですが、自分のマシンで15Fps
で安定させるのが限界みたいです。
このままＤｉｒｅｃｔＸに移行させようかと迷っているのですが、
３Ｄのテクスチャーとして表示させると、なんか色がくすんで見えるんです。

キレイに表示させられるような方法が書いてあるページが有りましたら
教えて欲しいと思っています。

よろしくお願いします。

agaれ！

（・∀・） ﾆﾔﾆﾔ

「とか言ってみるテスト」は自分が考え出したんだ！
って言ってるサイトがウザイよなぁとか言ってみるテスト。

>>663
1943とか目の前で撃ってきて避けようがなかった。

ゲームデザインといえば
1発食らったらお終いの残機制のシステムって嫌い。
エリア88みたいなエネルギー制の方が
敷居が低くてありがたいんだけどな。
エリア88とUSネイビーが未だにオレのベストSTG。

エリア88か・・・懐かしいな。100万$貯めても新しい機を買えるだけという・・・
除隊させてくれ〜

「とか言ってみるテスト」をつければ
なんでも許されるってもんじゃねえぜ

とか言ってみるテスト

何故か解決。
ウツダシノウ。

>>679
3Dのテクスチャー？
ああスプライト(デカール)のことか。
DX8で縦シューも全部擬似３Ｄ化してしまうのか。

そしてage

エネルギー制かぁ、俺が今作ってる奴は
取りあえずエネルギー(ライフ)制だけど。
エネルギー制はゲームのスタイルがかなり絞られるからね。
作るほうとしてはエネルギー制のほうが楽なんだけど
ストライカー19xxみたいな堅いゲームだと
著しくゲーム性を損ねるから辛いね。

俺もエネルギー制にしたかったけど
周囲の(って１名だけど)の猛烈ギッコギコ反対で
シールド+残機制に(ライフが3Point与えられてて
全部失うと１ミス)

ところでミスって戻されるシューゲーってこのごろ見ないな
グラ�Wくらい？

>>689

プロギアの二周目は戻されるよ。

プロギアは2週目が本当のプロギアらしいな・・・。

最近のゲームは低難易度だからね。

エネルギー制か・・・オレ的には、即死+バリア(1発くらい)がバランスとりやすいけどな。

お前らバトルゴリラやれ

その辺バトルゴリラやると、目から鱗だよ

なにそれ？

XTALのゲームらしいが・・・PC88ゲー？

生身の兵士が、戦車砲の直撃数百回受けても、死なない奴な

バトルゴリラは名作だぞ、おい！！

知るかー!

バトルゴリラのせいで寂れちまったぞ

>>701
ﾜﾗﾀ、ないすつっこみ

回答はﾊﾞﾄﾙｺﾞﾘﾗって事なのかｺﾞﾙｧ

誰か、ちょっとはageろよ

バトルゴリラ、おもろいんだけどなぁ。

だから知らないっての

それ以前に、なんかアルゴリズム的に面白いところがあるのか？＞バトルゴリラ
無ければスレ違い。

ゲームシステム的に特徴があるとか

ターン制アクションシュミレーションシューティングっていうのか？
類似ゲームは見たことねぇ

>>709
ほほーう。

>>709
ガチャポン戦士?

>>709
シュミレーション？
ATOKですら、《「シミュレーション」の誤読》と言って来るぞｗ

くだらないのでsage

>>708
　システム的に特徴のあるゲームと言えば、
「GUYS＆DOLLS」なんてどうだ？
縦スクロールＳＬＧなんて名乗っているが、
その実体は……

バトルゴリラはこういうアプローチもあるんだぁ、程度の参考にしか
ならないかもね。

自分がなにかアクションをやっている間だけ、時間が進むんだよ。なにもしてなければ
全体がポーズかかっている。タマの発射などに時間がかかるので、それなりにアクショ
ンになっている。

敵固くてなぁ。いま作りなおしたら結構良いかもしれん。

「Gays&Dolls」には誰も突っ込まないのね。
コイツは、シューティングゲームをリアルタイムＳＬＧ化したモノ。
一般向けのＰＣゲームで、出たのはつい最近。

アプローチはバトルゴリラに似ていると思う。
どちらも遊んだ事は無いケド。

また寂れたぞ

バトルゴリラ、超面白いと思う。
軍曹落としとかね。

というか、板が違うね

>>687
確かにスプライトだったかも。
それにしても、Ｄｉｒｅｃｔ３Ｄって簡単ですね。
さくさく作れてしまう．．．。
（まあ、３Ｄのモデル表示とか　そこら辺が難しいのかもしれないけど。

>>718
昔あったRetained Mode(保持モード。恐らくスペル違う)
は死ぬほど楽。また3Dでなんか作る機会あったら
使おうと思ってる

Rmは、、痒いところに手が届かないから嫌いです。

RM使わないと、どうにも痒いところしか手届かなくないか？

>>720
RMは、ちょっと柔軟なことをやろうとすると結構つらい
フェースごとにテクスチャ変えるとか

>>721
良い事言うね〜♪。
そうだよ〜。痒いところにしか手が届かないよ〜。

でも、まあ、一応プロ目指してるから（謎

>>722
RMとIMを組み合わせれば良いジャン

>>724
うっ！そんなことが出来るのか！
RM宙なので知らなかった

>>724
学生の時はそれで乗切りました〜。

敵キャラの処理に関数へのポインタ使うと
カタストロフィー(アーマゲドンになったこともあった)の確率がアップ

>>727

どーゆーいみ？

>>728
>>727は、ポインターの管理の仕方が　怒平太だと思われ

>>729
アーマゲドンじゃなくてサリンで自殺したって事なん？

>>726
え？学生以外はRM使っちゃ駄目ですか？

>>731
うん
て、答えたく成っちゃいましたけど。

そんなこたぁ無いです。
でも、趣味でやるとかなら、いくらでも時間がかけられるから
ＩＭでやった方が良いじゃんって思ってますYO。
(学生の頃って　三ヶ月って期限があったからRMでやっちゃいました)

>>732
言われてみればそうですね。

考えてみれば、データ構造等を自力生成すれば、
RMらしきモノは作れるし、汎用性も効くネ。

>>729
うむ、その通りだ。
「カタストロフィー」(大崩壊とか言う意味。256倍シリーズより)
はエラーが出る前にプログラムが止まる
「アーマゲドン」(これはわかるよな)
ってのは、OSごと落ちるってこと

>>733
ラッパ作っちゃえば
結局は簡単に出来るってことね
なるへそ
そーいや、某解説本で
RMをさらにラップしてたのがあったな。(激楽、自由度ゼロ)
3dplusとかいうやつ。すっげー完成されてたけど

なんか、2Dシューティング作り出して全然完成しなくて寂しいから
　 ∧ ∧　　／￣￣￣￣￣￣￣￣￣￣
　(,,・д・)＜　あげー
　＠＿）　　＼＿＿＿＿＿＿＿＿

　　　　ζ
　　　 ／￣￣￣￣＼
　　 /　　　　　　　　　＼
　　/＼ 　　　／　 ＼　｜
　　|||||||　　　●　　● ｜
　　(6　　　　　 　 ▼ 　｜　　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　｜　　　　 　 ||||||||| ｜ なんじゃい？
　　　＼　　 　 ＿人_ ／ 　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　 ＼＿＿＿_／

　　　　　　　　　　 　　 ∩
　 　 　 　 　 　 　 　 　 | |
　 　 　 　 　 　 　 　 　 | |
　　 　 　 　 ∧＿∧ 　 | |　　　／￣￣￣￣￣￣￣
　　／￣＼（　´Д｀）／/　　＜　 逝ってよし！
.r ┤　＠　ト､　 　 　 /　　　　＼＿＿＿＿＿＿＿
|.　 ＼＿／　 ヽ　　 /
|　　　＿_（￣　 |　　|
|　　　 ＿_）＿ノ￣￣￣￣＼
ヽ＿＿＿） ノ 　　　　　　 　 ＼
　　||＼||￣￣￣￣￣￣￣||￣
　　||　 ||￣￣￣￣￣￣￣||
　　 　 .||　 　 　 　 　 　 　 ||

　　　　　　　　　　　　　　　　　　　　人
　　　　　　　　　　　　　　　　　ノ⌒　丿
　　　　　　　　　　　　　　＿／　　 ::（
　　　　　　　　　　　　　/　　　　　:::::::＼
　　　　　　　　　　　　 （　　　　　:::::::;;;;;;;）＿
　　　　　　　　　　　　　＼＿――￣￣::::::::::＼
　　 ∧ ∧うわわわ　 ﾉ￣　　　　　::::::::::::::::::::::）
　　（,,ﾟДﾟ）≡つ　　　（　　　　　::::::::::::::;;;;;;;;;;;;人
　　 |つ つつつつ ／￣―――――￣￣::::::::＼
　〜.　　 |　≡つ　（　　　　　　　　:::::::::::::::::::::::::::::::::）
　　 ∪ ∪　　　　　＼＿＿::::::::::::::::::;;;;;;;;;;;;;;;;;;;;;;;;ノ

　　　　　　　　　　人
　　　　　　　ノ⌒　丿
　　　　＿／　　 ::（
　　　/　　　　　:::::::＼
　　 （　　　　　:::::::;;;;;;;）＿
　　　＼＿――￣￣::::::::::＼
　　 ∧ ∧あああ! ﾉ￣　　　　　::::::::::::::::::::::）
　　（,,ﾟДﾟ）≡つ　　　（　　　　　::::::::::::::;;;;;;;;;;;;人
　　 |つ つつつつ ＝　／￣―――――￣￣::::::::＼
　〜.　　 |　≡つ　（　　　　　　　　:::::::::::::::::::::::::::::::::）
　　 ∪ ∪　　＼＿＿::::::::::::::::::;;;;;;;;;;;;;;;;;;;;;;;;ノ

　　　　　　　人　　　　　　　　　　　￣::::::::::＼
　　　　　ノ⌒　丿　 ∧ ∧あああ! ﾉ￣　　　　　::::::::::::::::::::::）
　　＿／　　 ::（ 　　（,,ﾟДﾟ）≡つ　　　（　　　　　::::::::::::::;;;;;;;;;;;;人
　　/　　　　　:::::::＼ |つ つつつつ ＝　／￣―――――￣￣::::::::＼
　 （　　　　　:::::::;;;;;;;）.　　 |　≡つ　（　　　　　　　　:::::::::::::::::::::::::::::::::）
　　 　＼＿――￣∪ ∪　　＼＿＿::::::::::::::::::;;;;;;;;;;;;;;;;;;;;;;;;ノ

　　　　　　　人　　　　　　　　　　　￣::::::::::＼
　　　　　ノ⌒　丿溶け込んでしまった！　　　　　::::::::::::::::::::::）
　　＿ ∧ ∧　　 ::（ 　　≡つ　　　（　　　　　::::::::::::::;;;;;;;;;;;;人
　　/　（,,ﾟДﾟ）　　　　:::::::＼ ＝　／￣―――――￣￣::::::::＼
　 （　　　　|つ つつつつ　:::::::;;;;;;;）　（　　　　　　　　:::::::::::::::::::::::::::::::::）
　　 　＼∪ ∪　＿――￣　＼＿＿::::::::::::::::::;;;;;;;;;;;;;;;;;;;;;;;;ノ

　　　　　　　　　　　　　　　　　　　　　.,... ...,,,.:...
　　　　　　　　　　　　　　　　.,.._,,,. :.' ﾞ　　 .ﾞ　　 .,;l,,
　　　　　　　　　　　　　　　,.:'lii:;li;. .,:'',i(,:.,l,i,.;i_;iill;l',,...,
　　　　　　　　　　　　　　　 .'.iillll!.i,',.',l,l,l'!lll'i,,,l,,;;,;'!;l'lll,
　　　　　　　　　　　　　　　　.l!l'l|ill|l,'ll|li'l!li.llllililllllllllllllll,
　　　　　　　　　　　　　　　　　 .',llll!'lil| . .''.:,l''ll,llllllllllllllll,
　　　　　　　　　　　　　　　　　 .l..lll..:''ﾞ　　..lill;l!,llllllllllllll'll,
　　　　　　　　　　　　　　　　　 .!.:l.l'li,,_　　　...,li|.lll,lllllil!.!|
　　　　　　　　　　　　　　　　　 . ..:i'l;l|.!　',l'i,,,l:,l'lllli''ll'l!'
　　　　　　　　　　　　　　　　 .,,,.;llllllllll;illllllllllllllll!ﾞ.'　!
　　　　　　　　　　　　　　　 'llllllllllllllllllllll|　　 .
　　　　　　　　　　　　　　　　.,.,,lllllllllll,llllll! 　　 ..'l,:, ''l;;,
　　　　　　　　　　　　　　 .,,illlll'',lllllllllllllllll| .'　　 .''.:;.'':.lll,,
　　　　　　　　　　　　　.,.,lllllll'ﾞ.i'lllll!''''':...'ﾞﾞ　..　　　 .'.､　.ﾞ.;,,_
　　　　　　　　　　　　.,:',lllllllli,,.lllllll|　. .':.　　 ..　,.iillllllllllll,,_,lll!
　　　　　　　　　　　　..ﾞ...ﾞﾞ'''''''lll,lllll_　　 ﾞ'':,　 ,,l,';llllllll''ll,,..'ll''
　　　　　　　　　　　　　　　　l;llllllllllllllli,,,,,,,,,;,illll' .'lll,:',,'.,;,i'.,,
　　　　　　　　　　　　　　　　　 ,llﾞl'l',illllllllllllll''　　..'i;;.';',l::i,::''i,
　　　　　　　　　　　　　　　　 :.:ﾞ,,:''i':;;;l'l''l.l',..,'';,..　 ':'.ii'.,.'','''.llli,,
　　　　　　　　　　　　　　 .,..:'...,ll',:i:...,;';,',;;,,'.l'.';lllllill;llii,,,;,l,i;;|l:;;liilll! .,
　　　　　　　　　　　　　 .,lll;i,llll;;...,'':....,.;;.l!ii'.'.il;;;llllllllllllllllll,ll.;l''ﾞ　 　 ﾞ.
　　　　　　　　　　　 ...' ..'lllll'',l,ll'll',,,;;;;'ll:l;llllll,ll',llllllllllllllllllllll　　illllllll;,i
　　　　　　　　　　　 .　　 ,.',;,i'';l,',;,,!l;,ﾞl.l:,,l;;ll;lllll,l,llllllllllllllllll' ...,iilililllllllll,.
　　　　　　　　　　,::! llllli.,'''.il',ll'.i.'';.'.l..;;;,llllli'lll.llllllllllllllllll''ﾞ ._,,ili;l|llilllllillllllll,,
　　　　　　　　　 .,!l,,'illlllll;llll;llll: |l,'',,;l;illlll!lllllll''''''ﾞﾞ'ﾞ.'..',,,ii;lll;lllli;,llllll'lllllllllllll;ll,,
　　　　　　　　　.,lll:l|ll;lllil'll;l;lllﾞ　 .''.''';:'''''':!'''..li;;i;;;;i;llllllllllllllllllll;,l|lllll'lililllllllllllllll,
　　　　　　　　　,lil;'lllil,,llllll'l'll;,_　　　|　　　 llllllllllllll'li','llllllllll!;l'|l|'lll'li;lll;llllililll!

　　　　　　　　 .l'':ll!|l'lllll.:lllll;llllllllii,,,,,.l,,,,,,,,,,,,,ill.iil';llll,;l''lllllllllllllli.l'lilll'illlllllllillllllllli
　　　　　　　　.lll.;lll.l;il;lll'l'l;llllllllllllllllll,,lllllllllllllllllll,illliil,illllllll''lll'lll;l;,llll,,lllllllllllllllllllll!
　　　　　　　 .,lllilil;;l'l'lll,lll,ll'llllllllllllllllililllllllllllllll''ll;lllllllllllllll'lllll;ll'llli;li'l|l'l',llllllllllllllll!
　　　　　　　..l;ll;iil|,l'l!l;li,l;l'l'lllllllllllllll'''lllllllllllllllllllllllllllll'l'll'lllllll,ll'l;lil;llllllll!,llllllllllllll|
　　　　　　 ..l'lll''';llil,ll'|:lill;;,ll''lllllllllllllli;lllllllllllllll'llllll;'ll;l'lllllllll'll!l''!llii,lllil,,ll,ll',lllllllllll,
　　　　　　,:ll;ll|'l;'ll:iiil,''l|i.ll;,'l''''lllllllllllllllllllllllllll;'lllll'illlllliill'llli'ililll;lllii,ll,llll,;;i;,lll,lllllllll!
　　　　　 ,.lll:lll''llllliii,l;,''l!iill;liliil'l''llllllllllllllllllllllllllllllllii,l,iilllll';lli;llll|'|:lllllllllllllllllllilllllll'
　　　　 .lllili;llliiiill!,!,lllllllil,ll;'lll;''lll'''lllllllllllllllllllllllll,,,ll',;llllllllilllllllll!i,,lllllilllllllllllllllllll;!
　　　　.,,,llll:;'llll|...ﾞ'.'.'llllll,,!;l|'l'lllllllll''llllllllllllllllllll,l!;ll'llilllilllllllllllll'l!,lllllllllllllllll'llllll'''ﾞ
　　　 .,',ll'll''''llll|　　　...ﾞ''''''''lllllllllllli,ll'llllllllllllllllllll;lllllllllllllllllllll!l|i',llllllllllﾞ
　　　 :'lll,lliilllllll'　　　　　　 'l|llllllllllll''llllllllllllllllllllllllllllll''''''''ll,ll'llillillll'
　　　　.'''ﾞﾞ..　　　　　　　　　 'lllllllllll'''''''lllllllllllllllllllllll'　　　:''l'''''.'.｀
　　　　　　　　　　　　　　　　 ..ﾞ...ﾞ　　 .lllllllllll,,'''''´
　　　　　　　　　　　　　　　　　　　　　.lllllllllllllll,
　　　　　　　　　　　　　　　　　　　 ,.,illilllllllllllllll!
　　　　　　　　　　　　　　　　　　. ,,llllllllllllllllll,ﾞ
　　　　　　　　　　　　　　　　　　.''lll,llllllllllllllll
　　　　　　　　　　　　　　　　　　 :illllllllll'ﾞ.ﾞﾞ
　　　　　　　　　　　　　　　　　 :,iillllllllll!
　　　　　　　　　　　　　　　　　 .''''''ﾞﾞﾞ

　　　　　　　　 _
　　　　,- 、　/ ヽ
　　　　_　 ヽ/　_ _
　 　 , ´｀　　￣　｀ヽ＼
　　/　|//~~ヽ＼　ヽ｀ ヽ
　　|l　| /　　 ヽヽ、　 ヽ ＼ 　　　＿＿＿＿＿＿＿
　　|　| | ／　 　 ＼＼ )　 ｀ 　 ／
　　|　|l|　●　　　●　| |l 　| ＜　　なにやってんのよ
　　|　l | ﾞ ゛゛ ▼　゛゛　| | 　|　　＼ 私も仲間に入れなさい
　 |　 | ||ヽ　 _人_ 　／| | 　|　　　￣￣￣￣￣￣￣￣
　 |　 川l　|｀　　l´　ｌ　 | |　 |
　 || l|　||　l 　 　l、__　ｌ| |人
　|　 |　 ||´　、 ,　　　｀ヽ|l l｀

　　　　/|＼　　　　　　／|＼
　　　 /｜⊂l⊃⌒⊂l⊃｜　ヽ
　　　（　|　　__∧__∧___　|　　）
／⌒ /　　｜　 ／　　 ＼ ｜|⌒ヽ
|　t　 | 　　 |　　 ・　　 ・　　|｜t　 ）
ヽ_|__、　　　フ　　⊂⊃　ヽフ _|_ノ
　　　 |￣￣　　　＿＿｜ _｜　　　　／￣￣￣￣￣￣￣￣￣
　　　 | 　　　　 /＿＿/　 　|　 　　＜　消えろ、醜い生物！
　 ／｜ 　　　　　　　　　　ノ＼　　　＼＿＿＿＿＿＿＿＿
　　　　　　　　　 （┬）

　　/|　　　　 　　　　　Λ_Λ　　　∧_∧　／￣￣￣￣￣￣￣
　（ 人　　　　　　　　　( ﾟДﾟ)　　( ´ー`)＜　 シラネーヨ！
　（　ノ＼　　　　　　　　＼　＼ /　 /　 　＼＿＿＿＿＿＿＿
　 （　ﾟ。ノ＼__ 　　　　　　＼Λ＿Λ　　／￣￣￣￣￣￣￣
　　（　 　｡ο｡￣￣￣￣￣（　´∀｀）＜　進化したのか？
　　 （　　　　οﾟ。Ο　　◎　 ／￣ 　　　＼＿＿＿＿＿＿＿
　　　（／⌒＼）―（／⌒＼）

　　　　　　　　　　　　　　　　　／￣￣￣￣￣￣￣￣
　　　　　　　　　　　　　　　 ／　　融合だぞ！
　　　　　　　　　　　　　　／
　　　　／￣￣￣￣＼　￣∨￣￣￣￣￣￣￣￣
　　　/●　　●　　　　＼　Λ_Λ　　　 ∧_∧　　 ／￣￣￣￣￣￣￣
　 ／　　　　Ο 　 Y　　Y|　( ´ー`)　　　( ﾟДﾟ)　∠　俺の方がすごいだろ！
　| ▼Ο ο 　　　 |　　 | |　＼　＼ 　/ νν　　　＼＿＿＿＿＿＿＿
　|_人＿　　ο｡　｡＼／ |∧∧＼　Υ　 ノ
　＼＿＿　 　｡ο｡　｡Ο ￣￣　（　´∀｀）　　／￣￣￣￣￣￣￣￣
　　　　　 ＼　　Ο　　　　　　　　｡ο｡　ソ　　＜　　キャラ総融合だぞ！
　　　　　　（-＿-)　οﾟ。　Ο　　　　ソ　　　　　＼＿＿＿＿＿＿＿＿
　　　　　　（／⌒＼）――（／⌒＼）

　　　 ／￣￣ Y＿_
　 　 /　　,―-〈 　　＼
　　/　 ／ ／　 〉　　　|￣ミ
　　|　/　　,（･）〈 （◎）|――ミ
　　 (6　　　　 つ（）　 | 　＼ |
　　 |　　　　＿_〈＿___|　● | 　　 　　　／￣￣￣￣￣￣￣￣
　　 | 　　　/＿＿HH/　　　 |　　　　 ＜　あーあーあーあー
　　｜　　 　 　〉 ￣|￣＼　 |　　　　　　＼＿＿＿＿＿＿＿＿
　　　　　　　 〈＿／__＿/ ／
　　　　　　　　　　　〉 U／

　　　　　　, ＿＿＿＿
　　　　○　　　　　　　 ○
　　　/　　 __∧＿∧__∧ |
　　 /　　　|　 ／　　 ＼ | |
　　 |　　　 |　　 ・　　 ・　| |
　　　、　　　フ　　⊂⊃　ヽフ
　　　 |￣￣　　　＿＿｜_　|　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　 | 　　　　 /＿＿/　　|　 ＜　あんた、やっぱり体だけが目的だったのね。
　 ／ | 　　　　　　　　　　ノ＼　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

　　　　　　　　　　　　　/￣＼
　　　　　　　　　　　　　| 　 　 ＼
　　　　　　　　　　　　　| 　 　　　＼
　　　　　　　　　　　　　| 　　　　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　　　　　　　　|＿ ,　‐　′￣　　　　　　　　　　　　　　　　　　　＼
　　　　　　　　　　 　　丿　　　　　　　　　　　　　　　　　　　　　　　 ●　　●､
　　　　　　　　　　　／ 　 　 　 　 　　　　　　　　　　　　　Y　　Y　　　　　　　 ＼
　　　　　　　　　／ 　　　　　　　　　　　　　　　　　　　　　|　　 | 　　　　　　 ▼ |
　　　　　　　／　　　　　　　　　　　　　　　　　　　　　　　 ＼／　　　　　　＿人.|
　　　　　／　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ＿＿＿ノ
　　　／＿＿＿＿＿＿＿＿＿　　 　 　 　 　　　　　/　/　/　　　　　　　 　 /
　　/ ＜＿＿＿＿＿＿＿＿＿　　　　　　 　　　　 /　/　/　　　　　　　　／
　/　 　　　　　　　　　　　　　　　　　　　　　　　　　（　（　（　　　　　 ／￣
　|　　　　　　　　/￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　＼　　　　　　丿
　　 ＼　　　　< 　 　 　 　／|
　　　　＼　　　＼＿＿／　/
　　　　　 ＼　　　　　　　　/
　　　　　　　＼＿＿＿　　＼
　　　　　　　　　　　　　＼＿＼

　　　　　　／￣￣￣￣￣＼
　　　　　　　|　　おまえらも　|
　 ∩_∩　　|　　　　　　　　　　|
　（´ー`）　<　　暇な奴ら　　　|
　（　　　）　 |　　　　　　　　　　|
　 |　|　|　　 |　　だなぁ　　　　|
　（___）__）　 ＼＿＿＿＿＿／

　　　　　　　　　　　　　　　　　　　　　∨
　　　　　　　　　　　　　　　　　　 ／⌒ヽ⌒ヽ
　　　　　　　　　　　 　 　 　　　 ....:::..　Ｙ.　 .
　　　　　　　　　　　　　　　　 　 .::::::::.（･）（･）::ヽ
　　　　　　　　　　　　　　　　（ ::::::::;;;／ ● ヽ;.:;）
　　　　　　　　　　　　　　　　丶1;.' ≡　|　≡!/
　　　　　　　　　　　　　　　　　 ζ, 　t-┴‐' .j
　　　　　　　　　　　　　　　　　　i　　 ｀'ー‐'　.j
　　　　　　　　　　　　　　　 　　 |　 　 　八 　 |
　　　　　　　　　　　　　 　 　 　 {=====(T)===}
　　　　　　　　　　　　　　　　　 | i し　"　i　 　'|
　　　　　　　　　　　　　　　　　|ﾉ　(　　　i　 　 i|
　　　　　　　　　　　　　　　　 (　'~ヽ　　　!　　‖
　　　　　　　　　　　　　　 　 　 │　 　　　i　 　‖
　　　　　　　　　　　　　　　　　|　　　　　　! 　 ||
　　　　　　　　　　　　　　　　　|　　　 │　　　　|
　　　　　　　　　　　　　 　　　|　 　 　 　| 　 　| |
　　　　　　　　　　　　　　　　| 　 　　　　|　　　| |
　　　　　　　　　　　　　　　 | 　　　　 　 !　　 　| |ゝ
　　　　　　　　　　　　　　ノ　 　　　　 　　　|　　　ヽ
　　 ／ ⌒ヽ　／　 ＼　￣￣￣　 　　 ノノ 　 　 　 ＼
　　|　 　 　 |´　 　 　　|￣―--―― ´ヽ 　 　 ＿　　／⌒＼
　　＼_ 　 _/-―――.|　　　　　　　　　　｀l 　 　 Τ（　 　 　 ）
　 　 　 ￣　　　　　　 |　　　　　　　　　 　}　 　 　 |　＼＿／
　　　　　　　　　　　　 | ､--―　￣|　 　　/　 　 　 |
　　　　　　　　　　　 　 | ＼＿＿ノ　　 ノ　　　　　　|
　　　　　　　　　　　 　　〉―----― ´　　　　　　　|ー○
　　　　　　　　　　　 ＿|＿＿　 ,-――-､　 　 　　|
　　　　　　　　　　 （　　　　　￣)　 　　 ,｀――― ､
　　　　　　　　　　　 ｀ ―――´　 　　（＿＿＿＿_）

　　　　　　　　　/,..　　 ...::::::::　......::　　..　　　　　......　　　　､ﾞﾞ＼
　　　　　 　 　 //::::::::::::::....::' '　.:::/::..:/ .::::::／::::;:::　　　　　__）　 ｀i
　　　　　　　　,ﾚ::::::/:::::::::::,;;;;:''::::i':::::/:.:::;イ::::::／　　　　,,;i;i;i/ヽ_,,. l
　　　　　　　　|;;;;;/:::::::,,,-'':::::::,ノ|::::|::::;/_i':::::/::　.　.::.,イ;i;i;/;;jjj）｀｝ 〉
　　　　　　,..-;''l､,|;;;;／:::::::::,-''::::::l､|'i'''|'''{''';/:: .:.:::.／　　｀ﾞ'i))/　/｀i
　　　　 ,／;;;;;;;;;/::::,,-‐､;'~::::_,-‐'´｀ ﾞ'｛　|::||:::::::／　　　,,,,, }'　,/} ｝.｝
　　　 ,/;;;;;;;;;;;;;;ｲ;;/,r'ヽ./':':'ﾌ　　;;;;iiiillllliii;'i|'i:::/　　　　'"ﾞメ|／丿ﾉﾉ
　　 ./;;;;;;;;;;;;;;;/;|;;| ' /＾l::::::/　　 ''"(　ﾟ∀ﾟ)｀`'　　　　　 ￣/ ノノ ﾉ
　　/;;;;;;;;;;;;;;;;;|　|;|, （'~{:::::|　　　..:::.　　　　　　　　,;;ii'ﾞﾞﾞ|} /彡彡'´
　 /;i';;;;;;;;;;;;;;;|　iﾞ'l;i､｀ﾞ'||::|　　　　 '"''-　　　　　 i,(　ﾟ∀ﾟ)=-､
　 |;;|;;;;;;;;;;;;ｲ |　ﾞi､ﾞ''＼| ﾞt　　　　　　　　　 　 　 ﾞi　"'' i　　｀｝
　 |;|'ｌ;;;;;;;;/|　ﾞi　　 _,,（）　.　　　　　　　　　　 '' -'"　　l'　　丿
　 'i| ﾞi;;;;;;| |　 ﾞi,,.-'´_,/ 　..＼　　　　　 'ｰ-‐-､,,　　　/
　　'　ﾞ'i;;;;;|.|　　　,イV　　 ::::::＼_　　　　　　　　 ,,,-'"
　　　　 ﾞ''┘　,／/　 `''ｰ.､_｀'''''''＾''>､,,___,,,,-‐''´
　　　　　　 ,イ　ﾞi,　　　　　 ｀''-､,/　 ﾞi'ｰ､ ｀`'''‐-､
　　　　 ,／:::|　　 ﾞi､　　　　　　　〉､,　ﾞl　｀i､　　　 ＼
　　　　" ::::::|　　　　＼　　　　 /￣｀'i　}　 ｀i,
　　　　　　　|　　　　　 ＼　　 l'＼,,_/∨'i,　　|
　　　　　　　ﾞl　　　　　　　＼_|　　::|:｀＼,ii
　　　　　　　 ﾞl　　　　　　　　 ＼　::|::.　 ﾞﾞﾞ
　　　　　　　　ﾞi､　　　　　　　　　＼}:::
　　　　　　　　　

夏休みだねぇ

２ちゃんの夏、厨房の夏・・・か・・・ﾌｯ

久しぶりに上がってると思ったら荒氏か

こう、完全に上まで上がらない上げかたって有るのでしょうか？

週一ぐらいで定期的にsageとけば、大丈夫でしょ。
sage忘れると消えるがな。

な　なるほど。

じゃあage

>>759定期sageなんてあるのか？

>>762
sageでも何か書いておかないとdat逝きになる。
が、ageるまでもない、という場合に使われる＜定期sage

定期sage

sageだよ。

定期sage

とりあえずシコシコと作ってるよsage

これやりてー
http://www.finalburn.com/shots.htm

需要ないんじゃ…

当たり判定に関する話だの、
敵の配置に関する話だの、
ネタは色々あると思うケドね。

まあ、ツッコミがないと答えないケド

とりあえず超連射68K for Windowsでもやってモチベーションを
ttp://www2.tky.3web.ne.jp/~yosshin/ch68/ch68.html
……逆に鬱になるだけかもしれん。

僕も、こそこそ作ってますsage。

>>771
あんまりインパクトないんですが・・

>>773
元はかなり前に作られたゲームだからだな。
だがシューティングとしての完成度は激高。
771じゃないが鬱になる。

ところで、
最近　あたり判定に関して色々考えています。

昔ながらの方法って奴で　矩形同志のあたり判定って考え方がありますよね。
でも、超連射68Kの場合、斜めの弾とかも結構気持ちよく避けれたので…

弾幕系のシューティングの場合、どんな方法のあたり判定が良いのでしょう？
それと、けっこう複雑っぽいキャラクターとのあたり判定の時はどうしたら
良いんでしょう？？

シルバーガなんかは攻略本みるかぎり斜めのレーザーなんかもすべて矩形でやってる模様。
斜めの長い判定は、いくつかの矩形に分割して判定。
超連射も、たぶん矩形だけではないかな

シルバーガってなんだよ。シルバーガンだよ。

ﾊﾞｰｶﾞ

なるほど。
斜めの長いレーザーは　分割してですか。

とりあえず　やってみますー
サンクス

>>640
色判定というのもあるよ。

通常弾のBMPの抜き色を自機の中心に1ドット書く
→弾を描画→色のチェック

って感じ。レーザーなら大概中心からグラデーションが掛かってるから
中心に近い色の時だけ当たったと判定する。とか。
半透明が重なるとかなりあやしいが。
私もシューティング作ってるけど、一部この方法を使ってるよ。←手抜き

ＳＴＧって円判定はよろしくないの？

輪郭線同士の交差判定は？

>>781>>782
とりあえず実験してみ。どんなゲームかによって違うでしょ。
でも自機に関しては円判定はやりませんでした。＜以前

レーザーなら線対矩形とか線対円とかでいいじゃん。

>>780
僕も、最初その方法取ってみようかなぁって思いましたけど、
僕のプログラムでは　その方法は採れなくなってしまいました ^^;

>>781
円だと複雑なあたり判定がとれないんですよね。
とりあえず、今は円でやっちゃってますけど。 ^^;

とりあえず、僕は　矩形同士のあたり判定って感じで作ってみる事にします。

むかし、ここか、マ板でリフレッシュレートのスレがあったよね。
ログのURL教えてください。

・・・いちおう探したんだけどミツカン内んだよ。

Googleで「2ch リフレッシュレート」とかしてみんしゃい。

弾のあたり判定で質問。
上の方で、弾の当たり範囲識別の方法はいろいろあるにしても、
判定は対象物の特定の範囲に入った時としか書かれていないけど、
その対象物が小さかったときや、相対速度が大きすぎた時に
弾が突き抜けてしまうことがあると思うのだけど良い解決方法はあるの？
もう少し詳しく書くと、作画間の間に弾が移動した（とする）線分と
対象範囲が線分の一部を共有しているのだけど、始点と終点がその範囲以外にあるとき、
当たっているはずの弾がすり抜けてしまう。
これまで上に書かれていた判別方法だとすり抜けてしまうけど、
そんなことみんな気にしていないのか、それとも速度が遅いのか・・・。

間を補完して判定するだけじゃあ・・・

>>788
既存のアーケードやコンシューマのシューティングゲームの判定は
ほとんどその問題抱えてます。でも、遊んでいて気づかないっしょ？

もともと、ゲームの当たり判定は必ずしも正確である必要はないのです。
例えば2Dシューティングでは、「プレイヤーは身勝手な生き物である」
ことを見越して、自機の当たり判定は小さく、
自機弾の判定は大きくするのが常道で、
最初からそういうファジーな調整を施している中、
正確に判定したところでンなもん吹っ飛んでしまうのですな。

#怒首領蜂なんかは、CPUパワーが足りないため
#１フレームに半分の敵弾しか判定していないというウワサも。

これは「間違った答え」ではあるのですが（俺も書いててちと恥ずい）、
こういう話を聞いてどうするかはキミ次第でござる。参考までに。

>>788
作画と判定を同じタイミングでする必要はない

ちなみに弾の判定は自機との距離だけで十分と思われ

うわーこれどうみてもすり抜けててまずいだろーくらいヤバイ時は
その物体だけ間を補完して判定した。

ゲームなんてのはプレイしてて違和感を覚えなければ内部で何やってもいいんだ。

ま、そゆことやね。

みんなありがとう。
変に見えるところだけ補正するようにするよ。

保全age

ネタが無いのでsage

斜めレーザーの場合は、領域計算をした方が処理速度を稼げるne

誰もいないのかな？

800getな俺がいる

亀レスだが、雷電のプラズマレーザの再現は、初心者には超難易度高いぞ。
各敵の強さを計算しつつ複数を同時にロックし、「魅せる」経路を毎フレーム計算。
さらに、主ビームから伸びる細い放電で雑魚を殺してる。

ちなみに雷電２の基盤には、専用のコプロセッサが載っている。
雷電２用にセイブが自社開発したコプロセッサだが、でかいチップだから基盤見ればすぐわかるよ。

そんな事よりマリナーズを応援しよう！

Yahoo! Sports: MLB - Seattle at Cleveland Box Score
http://sports.yahoo.com/mlb/scores/20011014/seacle.html

マリナーズ vs インディアンス第４戦　実況スレ４
http://choco.2ch.net/test/read.cgi/dancesite/1003093922/l50

>>801
つーてもPS1で実装できてるわけで。それも処理落ちなく。

>>803
処理速度の問題じゃあないんだよ。

つまるところ、Buzzれればナンデモイイ

誰か試しに実装してちょ。

誰かファミコンロッキーであった
連射するほど奇跡が起こるような
秘密が盛り沢山なSTGとか作ってくれ。
そうすればきっと再び連射ブームが巻き起こり
停滞気味のゲーム業界が再び賑わうかもしれんぞ。

　骨川

　Σ￣￣|
　 　|00 ∂
　 Σ＿/

>>807 これもきちんと使ってくれよな。

小さい弾なら　補間じゃなく、そのフレーム間に移動する軌跡を線分にして
　点と線分の距離を使うとか

従来の１フレ／１処理に対し、１フレ／１０処理程度の計算を行うのはどうよ（Ｗ

ある程度大きくたってそれでいいよ >>809

隠しコマンドに炎のコマを入れたことならあるが。

スーファミ版ギャラクシーウォーズ？

ゴーデスをどうこうするってわざがあった気が・・・

熱い縦シュー作りてえなあ

>>815
作れ作れ。
作ってしまえ。

俺は　横シュー挫折したから．．．

点と線分の距離って高速な方法あるの？

直線迄の距離は(rx*dy-ry*dx)/√(dx2+dy2) 　ってのは見つけたけど

せいぜい、いかるがのムービ見てゲンナリしたまえ。

ﾊｧ・・・

>>816
作りたいけど、絵かく人いないかならあ。
挫折した横シューって、どんなの？

>>819
箱と線だけで作ってみなはれ、それを公開してドッターを探すのじゃ。

>817 単純にその値と、線分の始点終点迄の距離の３つの一番小さい値でいいんのかと
　　思ったけど、それじゃダメだね

>>822
線分 AB があったとき、点 P から直線 AB におろした垂線の足 H が線分 AB に乗っている
か分かれば良いのか？　乗ってれば点と P と直線 AB の距離が最小だし、乗っていなけれ
ば |PA|, |PB| のうち短い方が最小ということで。

H が線分 AB 上にあることは A, B, P の位置ベクトルを各々 a, b, p とすると（俺の計算が間
違ってなければ）

　(a - b, p - b) ∈ (0, |a - b|^2)

で判定できるから、これで場合わけかな。ただし a - b = 0 だと上の式では求まらんので、
a, b, p に下駄を履かせて a + x, b + x, p + x を代わりに使って逃げるとか、細工が必要。

[計算]
二点 A, B を通る直線上の点 X (位置ベクトル x) は、媒介変数 t を用いて x = ta + (1 - t)b
と表せる。特に t ∈ (0, 1) のときに点 X は線分 AB 上にある (1)

ここで二点 P, X の距離を考える。PX のベクトルは x - a と表せるから

|PX|^2 = (x - a)^2 = (ta + (1 - t)b - p)^2 = {(a - b)t - (p - b)} ^ 2

となる。特に点 X が点 P から直線 AB に下ろした垂線の足 H に一致するとき |PX| は最小値
|PH| をとる。ことのきの t の値を求めると (a - b != 0 の条件下で)

t (X = P) = (a - b, p - b) / |a - b|^2

となる (2)。あとは (1), (2) 合わせて、上の式が導ける。

ありがとう。　考え方判ったから　関数作ってみるよ

double　distance(double　x0,y0,x1,y1,px,py)　//型指定省略
{
　double　xc=px-x1;　//点を平行移動
　double　yc=py-y1;
　double　x2=x0-x1;　//線分のもう一方の端を平行移動
　double　y2=y0-y1;
　if　(x2*xc+y2*yc　<0)　{
　　return　hypot(xc,yc);
　};
　　xc=px-x0;
　　yc=py-y0;
　　x2=x1-x0;
　　y2=y1-y0;
　if(x2*xc+y2*yc　<0){
　　return　hypot(xc,yc);
　};
　return　fabs(y2*xc-x2*yc)/hypot(x2,y2)　;
}

hypotは多角形近似で荒くやれば、整数でも計算出来そうだね

んで、１はどこまでできたのじゃ？
もう５ヶ月たつぞよ。

どなたか蛇キャラの作りかた教えてください

丸いスプライト並べろ。それで十分。

>>829
スプライトの大きさ以上の移動が出来ないので

>>830

よー分からん。

＞スプライトの大きさ以上の移動

とは何ぞ。それは蛇なのか。そうなのか。

>>830
どんな動作をするヘビにしたいの？
それが分からないと答えようが無い。

>>832
ほんとに蛇のようなキャラクタなんだが、
頭を親にして胴体、尻尾が複数のキャラクタに分かれていて
くねくね曲がるものを作りたい。
親に結構不規則な動きをさせたいし、
親が死んだら子も死ななければいけないなど
色々な条件があるので蛇キャラが最適かと思ったんですが。

>>833

それって、よくある普通の多関節キャラの処理で出来るよ。
適当な数の関節を定義して、その情報を木構造で持ってさ。
各フレームの姿勢は、適当な拘束条件で移動アルゴリズムを組むなり
アニメーションデータから参照するなりして、とりあえず荒い姿勢を取得。
より滑らかなものにするなら各関節に曲線の制御点情報を加えて
適当に補完すればいい。

表示はポリゴンでも2Dスプライトでも何でも可。
どちらにしろ大して重い処理でもないし、好みの問題。

×　補完
○　補間

>>833-834
ちょっと難しいアルゴリズムかもしれんが、
スプライン関数を使うのも一つの手だね。
多少のムチャな動きなら、勝手に補完してくれる。

ちなみに、ポリゴンでスプライン関数を上手く使うと、
生物みたいにぐねぐね曲がる物体を作る事も出来る。

制御点使った曲線、曲面つったら
大抵どれも『スプライン関数』だべ。

うぐぅ・・・

あ、ゴメン。横槍のつもりはなかった。

いや、反応があった方が良いかなと
このスレ淋しいし

>>801
普通のDirect3Dを使った
２Ｄシューティングです。

ドット絵描く人間が捕まえられなかったのとか、
敵の動きのパターンを、適当に何種類か作れなかったのが敗因でした。

>>825 に
a*b+c*d の符号を返す関数
(a*b+c*d)/e を計算する関数
それに荒いHypot
http://piza2.2ch.net/test/read.cgi/tech/1003559977/5
があれば整数演算出来る訳か・・・・

>>841
＞敵の動きのパターンを、適当に何種類か作れなかったのが敗因でした。

敵の行動管理の部分を、システム化（汎用化）できなかったっていうこと？
絵に関しては、>>821さんが言うように最初は□とか×でも良いと思うけど。

ドット絵要員がいなければ、こういう手もあるぞよ。
ttp://ueno.cool.ne.jp/the68bank/works/kukei/kukei.htm

ゲームプログラマって大抵絵はそこそこうまいやん。って昔の話？

それは授業中に方眼紙にドット絵描いていたような
連中のことですな？(Y/y)YYYyyy■

16x16でスプライト２〜３色とかの時代までならなんとかなったんだけどねえ。
今はやっぱ普通の絵心がないと辛いッスよ。

>>845
　昔はみんな下手なりにキャラクターも考えてたりしたんだが、最近は
10秒で描いたと思われる「棒人間」みたいなキャラを平気で使ってる連中
が増えてきたな。（でまた、それを受け入れるベ○マガ）

　どうやらVBなお子様たちには「時間をかけてじっくり作る」という
考えが無いようで。

２、３色で良い絵が描けない人には、
何色使っても良い絵は描けないよん。
色が増えると、技術で誤魔化しが効くだけ。

むしろ単色シルエットなど難しすぎる。

確かに

白黒Macintoshアイコンにセンスを感じたあのころ

誘爆処理っていうのをやってみたいのですが、
いまいちイメージがつかめないでいます。
なにか参考になるゲームとかありませんか？

>>852 ミサイルコマンド

>>853
レスどうもです。
さっそくやってみました。
なんとなくイメージがつかめたのですが
画面がショボぃですね。
難しい〜。

>>852 ボンバーマン

>>843
それ以前の部分でして。
ステージの構成をどうしようとか、
何種類くらい敵を出そうかな？って部分で詰まりました。

結局、シューティングの企画も何も考えずに
プログラムだけ作ってしまった所に問題があったかもしれません。

とりあえず、
そこら辺をもっとしっかり練るべきでした．．．

プログラムの勉強ならいざしらず、ゲームを作りたいなら、
どんなシューティングゲームを作りたいか、何をプレイヤーに訴えたいのかを
しっかり決めておく必要があると思われ。
る。

>>856
いいんじゃない、仕事で作ってるわけじゃなさそうだし、自由にやればいいと思う。
でも趣味とはいえ、アプローチがまずいせいで挫折するのは心残りだよね。

まず、「プレイヤーをどう満たしてあげたいか」だけ考えて、プロトタイプ作ってみれば？
脳内企画書が一番重要だよ、最後まで。

2点の間にぶら下がる鎖ってのを作りたいんだけどどうしたら良い？
ショットで打つと鎖がゆれたりするようにしたいんだけど…

適当な間隔で質点をつなげばいいんじゃないの？

とりあえず物理と数学のお勉強を。

物理法則にのっとったやり方は労力の割には得る物が
少ないのでそこまでせんでいい。
要は見た目。
製作経験（もちろんゲームの話）が少ない輩ほど物理法則にこだわる。

複数ブロックに分かれている敵を作りたいんだけど、
どんな風に構造体を作れば良い？

やっぱし、その敵専用に構造体を作るの？
それとも、一つの構造体で全種の敵を処理するの？

>>863
こういう用途こそ多態を使うべきだと思うがどうか。

>>863
構造体は１種類で押さえたほうがいいよ、メモリ（ＲＡＭ）の制限が無いならね。
主従関係を示す、構造体へのポインタをメンバに加えるがよろし。

物理的な考え方は適用できるジャーン。
ていうか>>859のネタはそういうアプローチが一番楽だと思うが。

オレは859見た瞬間頭痛くなった。
静止した状態のみで弾が当たるならまだしも、複数の節のある物体が
前後に左右に振れているとき数カ所に弾が当たったらどうなるか
なんて物理的に考えようなんて思わない。

これの現象を敢えて「シューティングゲーム」でシミュレーションしよう
とするなんて偉い。

シューティングゲームと言ってもフライトシム型やFPSなら
物理法則は必要だけどな。
例え3Dでもアフターバーナー程度までは意味ないだろ。

鎖の運動を『物理法則に則って表現する』というのは
anharmonic oscillation とか chaotic oscillation みたいなのを
糞真面目にシミュレートするようなアプローチを指す言葉だべ。

で、ゲームの場合そんなことは普通しないわけで、その代わり例えば
鎖の要素一つ一つを質点に見立て、それを数珠繋ぎにしたものを
(隣接する要素同士の)拘束条件付きで自由落下させるような
『似非処理』を使って誤魔化しちゃうんだよね。

要するに>>834で書いあるような多関節キャラのアニメーション処理と
全く同じ方法ってわけさ。

スレがたってから、５ヶ月たちましたが
1はゲームを作れたのでしょうか？

きっと立派な業界人に成長したと思われ

>>870
「ヒット＆ブロー」あたりを必死に作ってんだろ（ｗ

>>869
それを似非処理と言ってしまうのには疑問があるが、まあ同意。

質点方式も立派な物理演算でないかい。

てゆーか、現実世界の事象を完全にシミュレートするなんて
不可能なんだから、どうモデル化するかの問題であって。
物理演算／NOT物理演算で切り分けるのはアレな予感。

>>873､>>874
あーゴメンゴメン。その手のコードを今まで書いてきて
「こりゃ似非だなぁ」と自分自身で感じてたってだけで
まぁその辺は主観だから許してよ。

俺もこの辺は程度の差に過ぎないと思うよ。あくまでも
目的は面白くするための味付けなんだから。別に難しく
考えることはないさ。

>>874

で、その辺の大学の工学系の研究室に飛び込んで
僕の立派な物理シミュレーション見てください！！


　　　　　甘酸っぱくて痛い風景

いやぁあああああああ

>>874

誤解があることに気付いたのでちょっと補足しとく。
俺が似非と感じた処理というのは質点に見立てた部分じゃないんだ。
本来は解かねばならないはずの高次微分方程式の数値解を一切端折って
節に適当な優先順位を付けて順番順番に移動アルゴリズムを適用して
済ましちゃうような(かなりセコくて精度の悪い)方法を使ったこと。

見た目上はそれらしい動きになるし実用に耐えたけど、あんなのを
シミュレーションだとは口が裂けても言えなかったの。上手く説明できなくてスマンコ。

>>876
キミ、大学が凄いことやってると思ってるだろう。

というか、大学でも、リアルタイムでやろうとしてる連中は
ゲーム系とそう変わらないアプローチでやってるよ。ほんとに。

１の報告期待あげ

>>878
シミュレーションの妥当性は用途によるんだよ。
いいだろ、みかけのシミュレーションなんだから。

ビリヤードとかだとソフトコアでやっちゃうことが多いね

>>878
それを似非とかインチキとか言ってしまう時点で学の無さを露呈してるよ。
学術的にも意味があることだし、ちゃんとそういう論文もあるし、IKなんかではよく
用いられる手法だよ。

似たようなので「補間してない」と言いながら零次ホールドで思いっきり補間して
るとか多いよね。

そんなヒドい方法じゃないから自信を持て・・・みたいな事を書こうとしたのに
ただの嫌味になってた（笑

定期age

いまさら定期ageせんでも。
次スレ作るならゲ製作技術板だな。

>>879
大学内の研究用プログラムのソースを
初めて見たときのことを思い出しました。
どっかのサンプルを使い回してるため（ＷＡＰＩまで）
ファイル数がアホみたいな数になってました。
ヘッダとcppの中身がゴチャゴチャに混ざっていて
どうやって動かしたのか不思議に思いました。
何時間くらいデバッグしたのか聞いたのですが答えませんでした。
なんかの数式を使って線グラフを表示するという内容です。
そいつら（研究生）の半数がＰＧになりたがっているそうです。

次スレつくるのか！！

ゲ製作技術板は勘違いした妄想君やゲヲタに荒らされてて
プログラミングの話しなぞできませんよ。

>>889
暗いと不平を言うよりも（以下略）
ていうか、そうでもない。

当方ただいま、一体ずつ敵を出現させるところまで
作っていて敵キャラのグループ化で悩んでるのですが、
どのような形でまとめればスマートに行くでしょう。
敵キャラを複数羅列して、グループＩＤを振った定義は
まずいりますよね…。それから、そのグループＩＤと
出現座標を対応ずける定義もいるだろうし。
この二つがあればとりあえず出現だけは出来そう…。
あとは、敵キャラ配置エディタとかも作るんでしょうか。
マップエディタはマップ配置するときに作ったので、
これを改造かな？

>>891
出現位置と、敵のＩＤで　時の出現位置を指定できるスクリプトを作ってみると
良いかもね。
私はそうやったから。


ふうむ。
仕事が一段落付いたら　私も続きを作ろうかな。
絵も四角で作るか。

「シューティングゲームを作らない？」スレでもたてるか

>>892
なるほどスクリプト化するわけですね。
それならあとからいろいろ拡張できそうですね。
でも、そうなると敵キャラの配置はカンで？
とりあえず、考えるより作ってみよう…
ダメだったら、また作り直すということで。

>>893
いいですねー。

＞891
グループ化って、グラディウスの最初に出てくる敵編隊みたいなものだよね？
漏れは管理用のダミーキャラを画面外に出現させて、
そいつのが複数の子キャラを吐くようにして作ったよ。
管理用のキャラがいるお陰で、全滅時にボーナス点入れたりとか
アイテム出したりとかすることもできるし。
（子キャラな奴が死んだら、そいつが親キャラのカウンタを減らしてく）

言ってることが違うようだったらスマム。

いくらなんでも寂れすぎだけど質問

敵はスクリプトで動かすべき？それともプログラムで動かすべき？
スクリプトは限界が生じそうなんだけど。

最初からスクリプトにしようとすると、スクリプトの仕様を考えているだけで終わらない。
とりあえず、先に動くようにしてから考えたほうがいいと思う。

>>897
ということは最終的にはスクリプトにするべきなの？
市販ゲームのような複雑な動きがスクリプトで出来るとは思えない。

>>898
それはスクリプト言語の仕様の出来による。
けど、言語作成が目的じゃないから
全部スクリプトにする必要ないんじゃない？

ツクールとして公開するとか
最低グラディウスシリーズくらいは
続編出したいとかなら別だけど。

>>896
「出現後30frame後に減速，プレイヤーの方向をサーチしてそちらへ
5frameの間に向く．25フレーム後に変形スタート，その40フレーム後に
変形終了，変形の間隔は3frameごと．プレイヤーの方向へ3発，通常弾を
20フレームの間隔で発射．その時に体力が30以上なら変形スタート，
30フレーム後に変形終了，砲塔を20フレームの間光らせてレーザーを発射．
レーザーの発射時間は240frame．体力が少なければパーツを分離．分離
したパーツは別オブジェクトとして管理．プレイヤーの方向をサーチして，
その反対方向へ20frameで向く．エンジン点火アニメーションを18frame
行ったあと，そのまま直進して画面外へ．画面外に出たらオブジェクト破棄」

・・・という動きを記述できるスクリプト言語は漏れには無理と
判断したので，プログラムでバリバリ書きましたとさ．

あ，追加．プログラマとモーションプログラマが分かれている
場合はスクリプトにしたほうがいいかもな．モーションプログラマが
プログラム知らない場合とか．

でも，モーションプログラマにプログラミング叩き込んだ方が
将来的にも安上がりになると思うのだが・・・

>>896
>敵はスクリプトで動かすべき？それともプログラムで動かすべき？
>スクリプトは限界が生じそうなんだけど。

私は今シューティングゲームのシステムを作っているけど、敵を
はじめとしたキャラクタはクラス化して、そのクラス内にaction
という「自分の行動を定義する」関数を作りましたね。これだと
敵や誘導ミサイルなどの複雑な動きもクラス内に閉じ込められる
んで、全体のシステムが簡単になって敵の種類を増やしやすい。

>>900
面白い、私もこういうのを作ろうとしたけど挫折した。
敵が1種類なら簡単だけど複数になると、スクリプトは難しい。

そいうや前のとき
struct{
　　int frame;
　　MODE mode;
}ACTION;
ACTION Action = {5,MOVE_LEFT,12,MOVE_UPnSHOT0,…,-1};
とかプログラム中に動きを記述した覚えがあるな…

>>902
それって普通じゃないの
void Action(){
　　switch(mode){
　　case:
　　　　break;
　　case:
　　　　break;
　　}
}
とかやって。

>>900
例にツッコむのもアレだが、余計な処理が多すぎ。

>5frameの間に向く
>その40フレーム後に変形終了，変形の間隔は3frameごと
たとえばこの辺はプログラム側の「制約」にすべきであって、スクリプトで処理することではない。

久々に定期sage

age
ゲ製作板はおもしろくないし

1 名前：Harry-Potter ◆HArry/x. 02/03/27 07:29 ID:F7hs7htj
われらの敵ACCSに立ち向かうときがｷﾀ。
F5攻撃でダウソ板人民の力を見せ付けろ。

攻撃対象　http://www.accsjp.or.jp/　(210.143.97.106)
攻撃日時　2002/04/01 23:05
攻撃方法　F5キー連打による連続再読み込み（あくまで人力で）

もし、F5以外の方法で攻撃する場合は念のため串を駆使することをお勧めする。
http://www8.big.or.jp/~000/CyberSyndrome/


なお、F5連打は通常の再読み込みを連続で行うだけなのでﾀｲｰﾎの危険は無い。
ほかの方法は業務妨害等で告訴の危険もあるので推奨しない。

>>906

迷惑だからやめてくれ。頼む。

age

1から読み返してみると、
900超えたのに内容の無さに驚く
大差のない選択肢を延々と議論してオナニースレかよお前ら。
そもそも、いろいろなゲームジャンルがある中で、
2DSTGを作ろうとすることが負け犬・キモオタ・センス無し。

あのー、自分のＰＣのメモリってどうやったら調べられます？

GlobalMemoryStatusか?

多分･･･よくわからんですけど…

箱あける。

>>906
ほれ、910みたいな厨が来ちまっただろーが。
このスレも終わったな。

初心者でもエスプレイドやぐわんげみたいなｶｺｲｲシューティングゲームつくれるの？
つくれるの？

>>911
「マイコンピューター」アイコンを右クリック＞プロパチー

ごめんなさいsage

ま、いいや、もうすぐ1000だし。問題は、
次スレを何処の板に建てるかだな……

次を起てるのか…

まぁ、どうでも良いけど。

>>919
わざわざ新規に用意しなくても、ゲーム制作技術にシューティングゲームを
作るスレがあったと思うが。

コイツか？スレの趣旨が違うんだが……

「STGを最初からみんなで作るスレ」
http://game.2ch.net/test/read.cgi/gamedev/1014709311/l50

ボスラッシュのようにage

まあ同人ソフトみてても思うな。
なんで弾幕シューティングばかり作ってんだろ。

>>924
技術における、労力対効果の問題かと。

つーか、漏れが作ってるのはSTGではないが、このスレは参考になる。

クラス使ってSTG作ってる所なのですが、
・敵1体毎にクラスを作る
・1面、2面…のように小分けしてクラスを作る
・全部1個に統一
のどれが一番良いですか？

どんなＳＴＧを作りたいか？それによって変わるが……

それ以前に、ＳＴＧを作った事は？
無いならまずは、インベーダーゲームモドキから始めましょう。

　中学生の頃、タイトー社の「ＮＩＮＪＡ−ＷＡＲＲＩＯＲＳ」の製作スタッフ
インタビューでＣとアセンブラで記述されたと知り、あんなに素晴らしい
ゲームを記述したと言う言語に深い興味を持った。

　社会人になって、スコルピウスと言う痛すぎる糞ゲーのプログラマ（確か、
ＧＯＤ鈴木と言ったっけ）の連載記事でシューティングのキャラ管理の
基礎の基礎の糸口を掴む。
　ＭＴＪ氏のゲームデザイン講座も連載末期しか知らないけど、参考になった。

　横シューを作り始めたものの、参加表明した連中からデータが集まらず
ソースをまとめて飛ばしてしまい、白髪死。
　ありがち（笑）。

　ゲームを作るなら、製作者のインタビュー記事はヒントの山じゃないかな。

保全age

sage

もうすぐ一周年だな

保守sage