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

**名前は開発中のものです。** · 04/06/16 07:45

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

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

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

■前スレ
シューティングゲーム製作技術総合　２機目
http://pc5.2ch.net/test/read.cgi/gamedev/1073736474/

**名前は開発中のものです。** · 04/06/16 07:45

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

■関連スレ
PCで出来る2Dシューティング(STG)総合スレ12
http://game6.2ch.net/test/read.cgi/game/1083576811/
★シューティングゲームは終わらない-STAGE28-
http://game6.2ch.net/test/read.cgi/famicom/1084795165/
G-わんげ鳩大往生XII～絆ダウン～ 4stage
http://game6.2ch.net/test/read.cgi/arc/1069685469/

■関連スレ
FPS(ﾌﾚｰﾑﾚｰﾄ) VSYNC(垂直同期ﾘﾌﾚｯｼｭﾚｰﾄ)
http://bbs.gamdev.org/test/read.cgi/gamedev/1063274576/
リフレッシュレートに関する論争
http://piza.2ch.net/tech/kako/972/972165437.html

**名前は開発中のものです。** · 04/06/16 07:46

■参考リンク
フリーソフトで面白いゲームまとめページシューティングカテゴリ
http://www.frgm.org/cgi-bin/s.php?g=stg&b=n
BulletML
http://www.asahi-net.or.jp/~cs8k-cyu/bulletml/
白い弾幕くん(BulletML＋Lua)
http://user.ecc.u-tokyo.ac.jp/~s31552/wp/sdmkun/

■エフェクト作成ツール
aBOM
http://www1.odn.ne.jp/ceb94660/
BombMaker(explosion maker)
http://www.pluto.dti.ne.jp/~nkf/
Detonation
http://www.vector.co.jp/soft/win95/art/se173882.html
GraphicsGale
http://www.tempest-j.com/
発色弾
http://diry.net/mia/

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

３機目か……これで最後だな。

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

エクステンドするかもしれないだろ

**名前は開発中のものです。** · 04/06/16 09:15

>>1
乙。

**名前は開発中のものです。** · 04/06/16 16:00

シューティングマニアックスはいまいちですた
…読まないと得られない知識ってあるかね。。

**名前は開発中のものです。** · 04/06/16 18:38

いまいちでもよんどくか…

**名前は開発中のものです。** · 04/06/16 18:41

ステージの組み方とかありました？
前にスクリプト組めって言われたけどいまいちわからないので
そのあたりの解説があれば買ってみようかと

**名前は開発中のものです。** · 04/06/16 20:23

>>9
お手軽路線で lua を活用してみてはどうだろう。↓ム板のスレ
http://pc5.2ch.net/test/read.cgi/tech/1063711237/l50
俺スクリプト言語でイクならboost::spiritでもいいし。

**名前は開発中のものです。** · 04/06/16 20:53

シューティングマニアックスに書いてる内容は、
プログラミング初心者の自分でもちょっと考えれば分かる事ばかりだった。
弾の動きなんてせいぜい高校数学レベルの内容だし。
そんなんじゃなくて、DirectXの基礎を理解してることを前提に、
簡単なシューティング丸々一本作り上げるような本があると嬉しいんだけどね
自分独習なので、クラス設計とかその辺の、他人のやり方が見てみたい

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

正直、シューティング作ってて困るのは技術的なことよりも
センスとデザインなんだよな。そもそも俺全然シューターじゃないし・・orz

あれこれ意見出してくれるシューターがスーパーバイザとして
ついてくれるのが理想なんだろうけど。

**名前は開発中のものです。** · 04/06/16 21:11

>>11
そこでやねうらお本ですよ。

**名前は開発中のものです。** · 04/06/16 21:47

>>12
シューターじゃないってのはシューティングが上手くないって意味？
それとおもシューティングをよく知らないって意味？
後者なら、なんでわざわざシューティング作ってるのか聞きたい。

まあそれはそれとして、あれこれ意見が聞きたければこのスレで聞けば
良いんじゃない？

**名前は開発中のものです。** · 04/06/16 22:35

世界で一番厳しいアドバイザが殺伐と勢ぞろい。

**名前は開発中のものです。** · 04/06/16 22:59

シューティング苦手なら、シューティング苦手な人向けのシューティングを作ればよいと思われ。
下手にシューティング野郎が作ったシューティングより受けるシューティングになるかも知れん。
つーかシューティング多すぎ。

**名前は開発中のものです。** · 04/06/16 23:01

式神みたいなのとか？
あれって、俺の周りだとシューター仲間以外にだけ人気ある。

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

>>12
そこで脱衣シューですよ

**名前は開発中のものです。** · 04/06/16 23:52

自分でシューティングをやらないと
どういうシューティングが面白いのか分からない
ということかと

**名前は開発中のものです。** · 04/06/17 00:05

レイストームに感動してこの道に引きずりこまれた口だが
じゃあなにをどうやったらあんな感動が得られるのが創れるか
って言われると、未だにわからんよorz

**名前は開発中のものです。** · 04/06/17 00:19

>>20
多分作品云々より、プレイヤーの精神状態とか今までやってきたゲームとかの
影響のほうが重要と思われ…

**名前は開発中のものです。** · 04/06/17 10:37

昔から言われているものの未だに決定版が出現してない
「互いに向かい合って撃ち合う」タイプの対戦型STGですが、
やはり最大のネックは敵CPUのアルゴリズムなのでしょうか。

**名前は開発中のものです。** · 04/06/17 13:20

アップルのARCHONがそれに近いｗ
サイドビューだけど…。

**名前は開発中のものです。** · 04/06/17 13:22

どうなんだろう。チンブレにしろTSSにしろ、決定版といえるほどの完成度はある気がする。
でも対戦格闘のほうが楽しいし、普通のSTGのほうがさらに楽しいが。

チンブレの高次面CPU相手に初心者が毎回同じ場所でやられて投げ出す問題は、
・大ダメージ攻撃の場所を憶えきれない
・どう駆け引きなのかがわからない　(序盤の面は普通のSTGと同じ感覚で勝てるため駆け引きを学べない)
あたりが原因か？

**名前は開発中のものです。** · 04/06/17 13:35

最初の2行に関しては知らないが
3行目の敵キャラプログラムが最大のネックという話は疑問だな。
　
洋物FPSのBOTプログラムについて調べてみてはどうだろう。
キチガイじみた強さと人間臭い行動をする作例は少なくない。
浦島太郎の気分が味わえるかもしれないぞ。

25 · 04/06/17 13:35

ﾜﾘ。>>25は>>22へのレスね

**名前は開発中のものです。** · 04/06/17 15:11

洋物FPSのBOTがどんなロジックで動いてんのかは知らんが、
学習型にするというのも一つの手。

**名前は開発中のものです。** · 04/06/17 16:56

学習アルゴリズムだけでコードの７割くらいになりそう

**名前は開発中のものです。** · 04/06/17 18:12

対戦格闘なら相手にして楽しめる程度のCPU組むのも比較的楽なんだが、
STGの、おそらく大部分が弾避けに属するようなのは、
実用で作れるんだろうか。今のところ議会制弾幕回避機関が先端か？

BOTをユーザーがプログラミングできるTSSクローンがあったとして、
それのCPUをまともに組めるかどうか。
原作の嘘避け連発があまり楽しくない、というところからこの問題はスタートしてるようだが…。

対戦格闘程度のCPUで十分楽しめるような対戦STGの仕様を組んだほうがいいか？
撃ちと避けが入る以上、かなり無理っぽい気がするが。

**名前は開発中のものです。** · 04/06/17 18:42

対戦STGか
一応「ネットやろうぜ」の時にこれはというのがあったけど、
検索してもほとんど出てこん

**名前は開発中のものです。** · 04/06/18 01:27

おたがい一度に1発しか撃てない対戦STG、というシステムなら、
対戦格闘のCPUと似たような作り方ができるかもな
それが面白いかはﾜｶﾝﾈ

**名前は開発中のものです。** · 04/06/18 02:25

ペンギンクンウォーズって対戦STG?

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

オフコース

**名前は開発中のものです。** · 04/06/18 07:29

何となく対戦グロブダーっぽい感じで想像してみるが、確かにうそ臭い回避だけなら比較的何とか
なりそうかもしれない。しかし、位置取りでオプション類を配置したりとか敵回避方向への
先読み弾の発射とかいった事になると、ちょっといい方法が思い浮かばない…

27 · 04/06/18 14:59

>>34

何手先までも読むシューターに追従するのは苦手であるが
例えば10秒間生き長らえるための安全領域探索木なら
それほど大きくはならないし、高速だよ。

25 · 04/06/18 15:00

ﾜﾘ。私は>>27じゃなくて>>25だ

**名前は開発中のものです。** · 04/06/18 15:16

あまりベタな弾避けアルゴリズム組むと、常時ドット単位・フレーム単位の神避けとかされそう。

25 · 04/06/18 15:22

>>37
濃密な弾幕の中から「回廊」を見つけ出し「すり抜け計画表」を立てるのは
なかなか骨が折れると思うよ。最初の頃は明らかに行き止まりの「死の回廊」を
見つけ出して得意げに突っ込んでいくから（苦笑
探索ステップに上限を設けるので調整によってはヤケッパチ行動になりやすい。

25 · 04/06/18 15:25

ｺﾞﾒ。補足すると上記の方法論は厳密には弾除けとは別の部分です。
大局的な振る舞いを決定するためのルーチンです。ボードゲーム的で
面白いよ。

**名前は開発中のものです。** · 04/06/18 16:22

>>34
普通の偏差撃ち（相手が等速直線運動を続けるという前提のやつ）
でない場合の話か。その辺になると予想（博打）撃ちの世界に入っちゃうんだよね。
＃相手が回避できるエリア（円）に満遍なく撒く必殺射撃は除くｗ
俺がやったことあるのは、相手の回避方向（の癖）を記録してフィードバックする
という単純な方法。たぶん、発展させれば相手の回避曲線まで記録するカンジ
になるんだと思われ。まぁ、STGはモデルが単純化されまくってるからサンプリング
できる要素も少ないし。比較的組みやすいのでは。

>>38
＞明らかに行き止まりの「死の回廊」を
＞見つけ出して得意げに突っ込んでいく

ﾜﾛﾀ

**名前は開発中のものです。** · 04/06/19 03:15

縦シューつくってるんだけど、パワーアップ削ろうか悩んでる。
パワーアップあってもあんま意味ないんだよな。
死んでもその場復活でパワーアップアイテム拾ってほぼ元通りになるし…。

**名前は開発中のものです。** · 04/06/19 03:18

パワーアップが出ると「ﾊﾟﾊﾟﾊﾟﾊﾟﾜｰｱｯﾌﾟ」が聞ける！

それだけだけど

**名前は開発中のものです。** · 04/06/19 04:35

ﾊﾟﾊﾟﾊﾟﾊﾟｳｧｱｯｯ（・∀・）ｶﾞｲｼﾞﾝｻｰﾝ

**名前は開発中のものです。** · 04/06/19 09:04

最初からフルパワー状態で、やられてもパワーダウンしない方がいい
攻撃が激しい終盤でやられて、最弱な状態からプレイ汁というのは酷だ
フリーや同人、アーケードでパワーアップ制にしている所は猛省して欲しい

**名前は開発中のものです。** · 04/06/19 09:33

グラディウスとかみたいにフルパワーノーミス前提で作られてるならいいけど
最近の一般人にはノーミスクリアが難しい弾幕シューだとあんまり意味ない気がする
死んですぐにパワーアップアイテム出るならそもそもパワーダウンしなきゃいいし
あとパワーアップなしなら敵の体力の調整をしやすいって利点もあるな

**名前は開発中のものです。** · 04/06/19 09:57

ふと思いついた。
空中でうろついてるパワーアップアイテムが弾を防いだら面白そうだ。
何十発か当たると壊れるようにして、すぐ取るかぎりぎりまで盾にするかのジレンマが。
バランス取りは大変そうだけどな。

**名前は開発中のものです。** · 04/06/19 10:59

最近のケイブとかのパワーアップって単に序盤の弱い状態が強くなるという満足感を
得るための演出なんじゃない？　やられても２，３個アイテム出るし。

**名前は開発中のものです。** · 04/06/19 11:59

パワーアップの効果が微々たるものでも、自機の攻撃の見た目の変化がちょっとした楽しみになったりはする
弱い装備でやれることが少ない状態でプレイヤーをシステムに慣れさせ、
本来の複雑なシステムへパワーアップで段階的に発展させてゆく、という方向もある

作りたいゲームの方向によってパワーアップの要不要は大きく変わるし、作っている間でも変わるだろう

シルバーガン、斑鳩、ボーダーダウン…
単純パワーアップを廃したシステムがわかりやすいのって他に何があるかな

>>46
ギミック系にならさほどバランス気にせず取り入れられるかもね

**名前は開発中のものです。** · 04/06/19 12:28

式神2もパワーアップ無いよ
ケツイも無いに等しい(死んでも即時ﾊﾟﾊﾟﾊﾟﾊﾟｳｱｯだから)

**名前は開発中のものです。** · 04/06/19 14:15

システムがわかりやすかどうかは疑問だが、同人ならＯＯＨかな
最初から特殊兵器てんこ盛り

**名前は開発中のものです。** · 04/06/19 15:50

最近の縦だと、俺が知ってる範囲ではアーケードSTGでもパワーアップに
意味があるなと思えるのって無いんだよなあ…。

**名前は開発中のものです。** · 04/06/19 18:02

パワーアップって昔はゲームを易しく（有利に）するフィーチャーだったけど、
それだと上手い人ほど有利になってしまう、というジレンマをなんとかしようと
した結果、事実上パワーアップの意味がなくなったんだろうな。

ちょっと前は、パワーアップすると難易度が上がるので、１段階で止めとけとか。

**名前は開発中のものです。** · 04/06/19 18:36

チマチマとした攻撃力で雑魚のｼｮﾎﾞｲ攻撃にも恐々としながら
避けてかわして耐えに耐えてやっとこパワーアップし、
アリンコをゾウさんが踏み潰すがごとく、さっきまで必死にかわしてた
雑魚を一掃できたりするところに爽快感がある。気持ちイイのれす。
これパワーアップの醍醐味なり。
破壊力があがることで
ゲーム性は低下する。よってすくなからず難易度はあげる。これ定石。
しかし雷電はこれどうなのかね・・

**名前は開発中のものです。** · 04/06/19 18:52

>>53
なぜ雷電がここで出てくるのかわからんけど、少なくとも最近のゲームは
最初ヌルいのであまりそういう感じしないんだけどな…。
後半は死んでもﾊﾟﾊﾟﾊﾟﾊﾟｳｧｱｯｯだし。だからこそパワーアップシステム導入の
是非を考えてるんだけど。

**名前は開発中のものです。** · 04/06/19 21:57

ダライアスとか延々とパワーアップしていくやつは事実上残機無用
だったと思うけど、続編作る上で問題にはならなかったのかな？

**名前は開発中のものです。** · 04/06/19 22:19

初代はショットでもまだミサイル＞レーザー＞ウェーブ等とあって
パワーアップの意味があったけど、IIなんかは中盤で死んだら最後までいっても
フルパワーにならないというシステムだったな。
あんま深く考えてないと思われ。

**名前は開発中のものです。** · 04/06/19 22:44

死んだらパワーが思いっきり奪われるということで、
上級者に刺激を与えているのではないかと。

**名前は開発中のものです。** · 04/06/19 22:46

いまさらな話題だが聞いてくれ。

俺の方法はＢ宗一派に入ると思うのだが、
int time_table[] = { 16, 17, 17 };　のようなテーブルを用意して、
タイマーを調べて delta_t >= time_table[count] のときに画面を更新している。

これと同じような方法を使っている例は見たことがないのだが、
２Ｄゲーを作る場合には、この方法でもいいのか？

**名前は開発中のものです。** · 04/06/19 23:18

なんというかそれは非常にレベルの低い解法だな。
ぴったり60fpsにしたいというならもっと良い方法がある

**名前は開発中のものです。** · 04/06/20 00:16

サンクロとかボスで死ぬと思いっきり萎えたな。
最近はその辺に気を使ってるのかな。＞その場復活のアイテム

**名前は開発中のものです。** · 04/06/20 00:23

>>58
逝ッテヨシ。googleヲ用イテ自己解決セヨ。義務。

キーワード：

サンプリング周波数
ナイキスト周波数
aliasing-error
固定小数点演算
bresenham's algorithm
マルチスッドレ

**名前は開発中のものです。** · 04/06/20 00:43

嘘。逝かなくて（・∀・）ｲｲ
int time_table[] = { 16, 17, 17 };　　←下駄を履かせるとｲｲ
あとはスクロールのガタツキを改善するための工夫をすればｲｲ。

**名前は開発中のものです。** · 04/06/20 00:47

ぶっちゃけ浮動小数点でやってる俺はまんどくさすぎな人間

**名前は開発中のものです。** · 04/06/20 00:49

フルスクリーン等の環境ならほぼ確実にV-SYNC待ちが入るので
誤差蓄積は無いし、問題ないのでは。

**64訂正** · 04/06/20 00:55

V-SYNC待ちを指定する場合は誤差蓄積を容易く回避できるし。

**名前は開発中のものです。** · 04/06/20 01:18

>>57
上手くなってきて稼ぎとか始めた場合や、
普段死なないところでミスしたら捨てゲーすると思う…。

**名前は開発中のものです。** · 04/06/20 05:04

>>66
死んだときに後になればなるほど高得点が入るようにするとか・・・。
この場合、ボス戦で死ぬのは駄目。道中で死ぬことによって点数増加。
この点数は、ラストの残機ボーナスより(最終面で死んだ場合は)多くなるようにするとか
んで、死ぬことによって1、2段階ずつパワーダウンしていく。

ドドンパチでこれを考えると
緋蜂戦に入る前にぎりぎりまで残機を減らしたほうがいいわけだが
それだと、全一を目指そうとすると、緋蜂発狂モードに未パワーアップ＆残機数無しで相手しなければならない。

こんな感じで、安全をとるか、点数を取るか。
とかにしてみるのも面白いやも。
あとこれだと後半で死んでも捨てげーにならない、と、言う利点ができたりするわけですが・・・

どんなもんやろ？

**名前は開発中のものです。** · 04/06/20 05:16

そこまでしてパワーアップの必要性を作ることもないんじゃない？
そういったゲーム性はまた別の組み方があると思う。

**名前は開発中のものです。** · 04/06/20 05:18

死んだら敵機よろしく得点アイテムを吐くわけな。自機が。
特定のポイントで死ねなかったら捨てゲー確定ですな（意味不明かもしれん）。

**名前は開発中のものです。** · 04/06/20 05:49

あと、あんまり高いリスク→高得点を詰め過ぎてプレイヤーにストレスばっか
与えると、根本的につまらんゲームになりかねん。

**名前は開発中のものです。** · 04/06/20 05:59

残機潰したほうがスコアが稼げるというゲームは実際にあるわけだが
そして不評なわけだが

**名前は開発中のものです。** · 04/06/20 06:32

えーとガンネイルとか？
ちがったっけ

**名前は開発中のものです。** · 04/06/20 07:11

>>54
なんだろね？
雷電は結構、パワーアップ重要だったと思うけど（復活ゲーだし）
多分、ボス前のショット＞レーザーのバランスの事とか？

、、そろそろ、２ヶ月あまり停滞していたＳＴＧ作りを再開します。と自分に言い聞かせ、、。
とりあえず、安易な縦シューサンプルが動く所までを目標に、、。

58 · 04/06/20 08:19

>>59
そんなにいい方法があるのなら、ぜひ聞かせてほしいが…。

>>61
キーワードはググりました。
固定小数点使ってもある程度の誤差は免れないと思う。
俺の方法よりはマシですけど。

>下駄を履かせるとｲｲ
無駄足は踏まさせてます。
if(～)
{
before_time = time_table[count] - delta_t + now_time;

>V-SYNC待ち
完璧にV-SYNCが取得できるなら苦労しませんが。
まぁオプションで指定してもらえれば作る側は楽だが、そんなのめんどうだし。

>>63
そうですかね？浮動小数点でも有効数字の範囲なら同じに見えますが。

**名前は開発中のものです。** · 04/06/20 10:55

>>59
自分も聞かせてほしいです…

**名前は開発中のものです。** · 04/06/20 16:05

じゃあ簡単に解説

まずWin32タイマー精度が1000ms分解能
ほしい精度が1000/60ms=50/3ms分解能

dword time_prev_mul3; // ワンフレ前の時間
dword time_cur_mul3; // 現在の時間
dword time_remain_mul3; // 誤差蓄積時間

void FpsTimer60::wait(){
　　while((time_cur_mul3 = timeGetTime()) *3 + time_remain_mul3 - time_prev_mul3 >= 50);
　　time_remain_mul3 = time_cur_mul3 - time_prev_mul3 - 50;

}

remainが大きくなりすぎたら一旦remainを初期化したりする処理
連続49/3日稼動をまたぐ時の処理は省略

…という方法
これでうまく動いてるんだけどどうや！

**名前は開発中のものです。** · 04/06/20 16:07

かってに送信された。一行追加

void FpsTimer60::wait(){
　　while((time_cur_mul3 = timeGetTime()) *3 + time_remain_mul3 - time_prev_mul3 >= 50); // 松
　　time_remain_mul3 = time_cur_mul3 - time_prev_mul3 - 50; // 誤差を記録
　　time_prev = time_cur; // ワンプレ前の値として記録
}

**名前は開発中のものです。** · 04/06/20 16:23

QueryPerformanceCounter は使ってはいかんのか？

**名前は開発中のものです。** · 04/06/20 17:01

別に構わんと思うけど、1回の呼び出しに1us位掛かった気もする。

**名前は開発中のものです。** · 04/06/20 17:11

>>74
で、bresenham' algorithm は無視かよ。

**名前は開発中のものです。** · 04/06/20 17:12

s/'/'s/

58 · 04/06/20 19:22

>>76
ども。
3倍して誤差をなくしてるんだな。

>>78
いいんじゃね？
俺はQPCが嫌いだから使っていないだけ。

>>80
無視しているわけではない、使っていないだけ。
まぁ76のが応用だな。

76を参考にして作ってみたが、delta_tが㌧㌦。

DWORD before_time = timeGetTime(), now_time, delta_t = 0;

int wait_vsync()
{
　　　　now_time = timeGetTime();
　　　　delta_t = (now_time * 3) - (before_time * 3);
　　　　if( delta_t >= 50)
　　　　{
　　　　　　　　before_time = now_time;
　　　　　　　　return 0;
　　　　}
　　　　return 1;
}
で、
while(wait_vsync())

58 · 04/06/20 19:24

追記、
今回は delta_t が使えないので誤差の蓄積は諦めた。

ちなみに>>74に書いたが、58のソースでも誤差の蓄積はしていた。

**名前は開発中のものです。** · 04/06/20 21:13

76だけど
あのさぁ、わざわざ3倍してんのはremainに誤差を蓄積して後フレームで取り返すためにやってんのに
その処理なくしたら何のいみもねーだろ。
そもそもv_syncとか意（ｒｙ

**名前は開発中のものです。** · 04/06/20 21:14

まだブレゼンハムとか言ってる人がいるのか。
タイマ周りなんて容赦なく浮動小数使えばいいのに。doubleで1＝1秒で。

**名前は開発中のものです。** · 04/06/20 21:41

const double FRAME_RATE = 60.0;
double gameTime = 0.0;
double gameDeltaTime = 1.0 / FRAME_RATE;

Boost::timer t;

while (true) {
　　double currentTime = t.elapsed();

　　if (gameTime > currentTime) {
　　　　Sleep(gameTime - currentTime);
　　}
　　gameTime += gameDeltaTime;

　　Update();
　　Render();
}

こんなんでも基本に。

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

>>74
＞完璧にV-SYNCが取得できるなら苦労しませんが。

んー。DirectX7以前ならフルスクリーンでは確実に同期できますが。
（できない珍種ビデオカード環境があるなら例をあげてみなさい）
　
更に、DirectX8以降に対応したドライバならウィンドウモードでも
確実に同期できますが。大抵はスキャンライン単位で情報得られます。
　
まさか、「CRT側のリフレッシュレートと同期できない環境」で
ノイズレスかつスムーズな2Dゲームプログラムを実現できるとお考えで？
　
>>83
＞誤差の蓄積は諦めた。
　
まぁ、勉強中ということなら今回は諦めてもいいんじゃないか。
ただし、精度保証はちゃんとできるんで。数値計算の初歩本ぐらい
買うか借りるかして勉強したほうがいいと思うぞ。

>>85

いや、精度保証付きであれば何でも構わないわけだが。
話の流れ的にも整数演算のみでカタが付くことを58が
望んでる様子だからブレゼンハムって単語が飛び出たのであるし。

**名前は開発中のものです。** · 04/06/20 22:06

vsync同期前提で良いんじゃないかなあと俺は思ってんだけどね…。
綺麗だし。

88 · 04/06/20 22:09

あ、言葉足らなかった。
タイマはリフレッシュレートいじれない人用と考えて
そんな高精度じゃなくても良いんじゃないって話。

**名前は開発中のものです。** · 04/06/20 22:13

ねーねー、誤差蓄積時間って書いてあるけど、
これって単なる前回誤差時間だよね？

**名前は開発中のものです。** · 04/06/20 22:55

ウィンドウモードでVSyncに同期できるってのはどういうことですか？
例えば普段リフレッシュレートを85Hzに設定してる人が、
ゲームのウィンドウだけをVSyncに同期して60fpsで動かすことって不可能ですよね？

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

>>91
私はA宗です。

B宗1派の苦労もB宗2派の不幸も知らないし知りたいとも思わない。

**名前は開発中のものです。** · 04/06/20 23:10

A宗でしたかー。

**92=87** · 04/06/20 23:13

です。

**名前は開発中のものです。** · 04/06/20 23:40

数値計算屋ならなおのことB宗にしそうだけどなあ。
＃ゲームなんて超複雑な偏微分方程式みたいなもんだ

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

でだ、俺B宗なんだけど、ちとA宗の人に質問。

このことを具体的にどう実装してるのか教えてくれ。
「同じ曲線軌道を取る弾を等間隔に連打して曲線を描く弾幕を作りたい」
もちろん軌道は微分形式で表されてる奴ね。

dt可変だと、連射弾の1つ1つの軌道が変わると思うのよ。直線弾ではなくて、曲線弾だから。
結局そんなもんは誤差の範囲ってことでごまかしてるわけかな？
(実際にプレイしてればそんなに気にならないだろうし、どうせ桁外れに小さい誤差だろうけれど)

96 · 04/06/21 00:04

すまん、ちと要点がなんだかわからない文章だった。

要するにこれをA宗の実装方法でやるのに問題点は
「等時間間隔で発射すること」「全ての弾の曲線に同一軌道を持たせること」
の2つだと思うんだけど、実際どうしてるのかな、と。

**92=87** · 04/06/21 00:13

教義をよく読んだら、もすかすてA宗ってオブジェクトのパラメータ更新も
リフレッシュレートに同期させんと異端になるんか。私、原理過激派に抹殺されるかも（・∀・）

>>96
弾幕に関しては、お定まりのアニメーション再生ルーチンと同じでイケルぽ。
空間上のパラメトリック曲線上をナゾルっぺよ。Δtにあわせてスライダー上を
進むようなイメージだべよ。

**92=87** · 04/06/21 00:23

えーと、予定調和的な処理を簡素に作り上げるなら
ゲームワールドの更新に未知のΔtを使うのは嫌過ぎる。ってのは同意。
　
私は「滑らかな2Dゲーム、滑らかなスクロール」のために画面更新は
リフレッシュレートに同期させよう。というつもりでA宗だと思ってたプチ信徒ﾃﾞｨｽ。

**名前は開発中のものです。** · 04/06/21 00:52

>>98
アニメーション再生ルーチンってのが具体的にどういうもんだか分からないのだけれど…。
もしオブジェクトごとに非常に小さい固定dtの数値積分で求めているとしたらそれは本末転倒で、
初めからゲーム全体にクロックを与えて、そいつで駆動したほうが楽でよくない？

**名前は開発中のものです。** · 04/06/21 00:56

>>98
よく、知ったかのゲーマーとかがバカの一つ覚えみたいに60fpsとかいうけど、
実際は59.97Hz前後だから、VSYNCに頼ったところで正確に60fpsにゃならないんだよ。
昔のゲームは、単に高速タイマがなくて、ターゲットのリフレッシュレートは固定だから、
タイミング取るのにVSYNC割り込み使ってたという単なる慣習だ。

PCだったら、タイマとトータルのフレーム数のカウンタを併用して、1/60fps相当で
必要な処理を通すようにゲームループ回して、絵の方をつじつまあわせりゃいい。
ちらつきが嫌ならVSYNC検出して、帰線期間に絵を書き換えりゃいいし、
そうじゃないなら洋ゲーみたいにフレームレート可変って感じで。
今のシューティングゲームは、負荷でスローが掛かる表現にしたって、ソフト的に
ウェイト入れてやるだけなんだから、無理してVSYNC使う必要はないんだよ。

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

俺は敵の挙動を計算式で処理してないので
60FPS固定でやるしかない。

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

ずいぶんと脱線をしている気がする。まあ、76と86が実用になることだけわかってれば問題ないよな。
リフレッシュレート85とかのCRTでのウィンドウモードで
伝統的57～60FPSゲームを動かすのがお題目なんだし。

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

あぁ、76-77と書いておかないと万一のとき大変だ。

**92=87** · 04/06/21 01:30

>>100
補足しようと思ったらかぶってしまった。

んーと、A宗原理過激派として実装するなら
弾幕に関しては予めシナリオが作られた打ち上げ花火なので
Δtを使った数値積分で軌道を決定する必要はないです。
Δtが未知なら避けるべきです。

**92=87** · 04/06/21 01:31

私はFLASH上で編集した弾幕を自作のエクスポーターで
出力させてるんですが、私のフォーマットは
座標値を補間パラメータとする空間上のベジェ曲線で軌道を表現しています。
この制御点には時間tなども入ってます。なぞるタイミングは、制御点間でtを
3次の多項式で補間しています。

ですので、Δtが例え未知の場合であっても弾の軌道が崩れることはありません。

**92=87** · 04/06/21 01:40

>>101
＞実際は59.97Hz前後だから、VSYNCに頼ったところで正確に60fpsにゃならないんだよ。
　
おっしゃる通りです。
　
私はVSYNCに同期した画面更新なくして2Dゲームで滑らかスクロールは不可能
という立場を取りつづけますが、ゲームワールド更新に関してはその限りではありません。

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

リフレッシュレートが59.97Hz前後なら同期で60fpsにならないの？

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

アニメーションってソレね。ベジェ曲線は自由度は高いけれど実はそうでもないのよね。
要するに3次ベジェ曲線で表せるものしか表せないわけ。
俺が「微分形式で表したもの」って言ったのはちょっと表現的には間違いかも。
「微分形式でしか表せないもの」とか「積分がまんどｋ（ｒｙ」なもの。
計算屋なら数値積分がどんだけ楽か分かると思うんだけど、
それなのにA宗でパラメトリック曲線に頼るというのは、なんか変だなと思って突っ込んでみたのよ。
なんかリフレッシュレートっつーよりは数値積分のありがたみの話になっちゃったけど(笑)

**名前は開発中のものです。** · 04/06/21 03:16

59.97HzはカラーNTSC放送の垂直同期周波数ってだけで、
PCがそうであるかどうかとは全然関係無いと思うんだがなぁ。

**名前は開発中のものです。** · 04/06/21 03:59

>>110
厳密にリフレッシュレートを測定したことはないが
俺は一度、timeGetTime基準による「完全なる60Hz」で
V-SYNC完全シカト描画を行ったが、モニタ60Hz動作時
「前画面と新画面の境界線」がヌルヌルポ下がっていった。

**名前は開発中のものです。** · 04/06/21 04:38

>>111
ガッ
それだとリフレッシュレートは60Hzより上という事ですな･･･。

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

これからはデジタルディスプレイでいいんじゃ

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

最近の、書き込んである背景って、どう管理されてるか知ってる？
チップと一枚絵の中間という感じかな？

**名前は開発中のものです。** · 04/06/21 12:54

何を指して「管理」といってるのかよく分からんが
2、3人程度で趣味でやるなら難しい事考えずにチャランポランで平気だけどな。
例えば地上オブジェクト配置するときの命名規則とか。その程度だろ。

　1面.dat
　2面.dat
　3面.dat
　4面.dat

とかで、中身はレイヤー別に

　地上オブジェクトの配置情報
　地上静的構造物の配置情報
　背景ビットマップ
　
セコくやればレイヤー機能付きペイントツールさえあれば足りる。

**名前は開発中のものです。** · 04/06/21 12:55

s/地上オブジェクト/地上キャラ/

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

絵の話？
書き込んである＝2Dと解釈すると、ケイブだったら1画面くらいの大きさのチップ？を
並べてるんじゃないかなあ。あんまり同じ絵を並べてるようには見えないけど。

**名前は開発中のものです。** · 04/06/21 14:32

作画のときにチップをいろんなかたちで並べて、データに落とすときに1枚絵にしてそう。もちろん複数レイヤー

**名前は開発中のものです。** · 04/06/21 16:18

今はそういう力業というか、マシンパワーでごり押しみたいなのが平気で出来るように
なったからなぁ・・・。
１６×１６ドットでマップチップを作ってた時代が懐かしい。
まあそれでも、サウンドの容量に比べれば可愛いもんかも知れんが。

**名前は開発中のものです。** · 04/06/21 17:23

RPGのレベルアップの意味もそのうち薄まってくるんかな。

**名前は開発中のものです。** · 04/06/21 17:59

いやいや。

**名前は開発中のものです。** · 04/06/21 18:19

76のヤツって差が50以上開くまで待つんだから不等号逆じゃね？
このままだとprev_time_nul3が初期化されてなければ、
(now = n * 3) + (remain = 0) - (prev_time = 0)になって、
最初の呼び出しで永久ループだし、
ちょっと前にtimeGetTime()で初期化してたらwhile()で待たない。

58 · 04/06/21 19:11

俺の発言で誤解を招いてしまったが、俺はあくまでＢ宗一派。
>>84=76
3倍しているのは誤差蓄積の他に、俺の int time_table[] = { 16, 17, 17 }; のような
ばかテーブルを作成しないためでもあるのでは？
あと誤差蓄積を無視しているのではなく、delta_tが死んでいるので出来ないだけ。
そのうちソース修正する。
>>85=86
ソースupサンクス。参考にします。
>>87
いままでのソース読めば分かると思うがDirectXは使っていない。
> CRT側のリフレッシュレートと同期できない環境
それだからタイマ使うんじゃねーの。
実現は出来る。ある程度のマシン性能以上の環境ではな。
> 数値計算の初歩本
お薦めの本があるなら教えて欲しい。
安ければ洋書でも読む。
> 話の流れ
そういうことだが、拒みもしない。
>>88=89
> リフレッシュレートいじれない人
それが俺。
だから1000msぐらいは精度が出ないと困る。
timeGetTimeも微妙だけどな。
>>101
それはＢ宗だ。
>>111
興味深い。是非詳しく聞かせてほしい。

**名前は開発中のものです。** · 04/06/21 19:37

正直もっと一般的な環境を前提に、一般的な環境で開発したほうが良いんじゃ…

**名前は開発中のものです。** · 04/06/21 19:54

>>123
だから、なんでDirectX使わないんだ？

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

>>125
Macだからとかじゃない？

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

('∀`)

**名前は開発中のものです。** · 04/06/21 21:56

DirectXを使う使わないとかいう話なんか？

**名前は開発中のものです。** · 04/06/21 23:09

>>128

>>87の発言

　＞まさか、「CRT側のリフレッシュレートと同期できない環境」で
　＞ノイズレスかつスムーズな2Dゲームプログラムを実現できるとお考えで？

に対して、>>123は

　＞いままでのソース読めば分かると思うがDirectXは使っていない。
　＞それだからタイマ使うんじゃねーの。　
　＞実現は出来る。ある程度のマシン性能以上の環境ではな。
　
と反論しているわけだが、おまえどう思う。

58 · 04/06/21 23:16

お陰様で、だいぶよくなってきた気がする。
明日くらいには誤差修正込みの完全版ソース出せそう。
あと、俺は純粋に1/60secごとに描画したいだけだ。

>>124
「ノイズレスかつスムーズな2Dゲームプログラム」が前提だったから
特殊な環境に依存すると言ったんだが。
文句があるなら>>87にどぞ。
俺の想定環境は PenIII以降, Win9x/NT ぐらいか。
リフレッシュレートは60か75くらいしか確認できないが、それぐらいになら変更できるし大丈夫だろう。
>>125
最も本質的な話題だが、俺に答えられる範囲内ではないな。
まぁ、俺の環境と技術が不足しているから。
そもそもDirectXでリフレッシュレート同期できるんなら、こんな質問していない。
>>126
ソース見てるか？win32依存。
>>127
（´・ω・｀）
>>128
ここの方たちから見るとばかばかしいくらいの質問だからこうなる。
でも、正直WIN32APIの範囲内で答えてほしい。
…って言うとDirectXの構成の話になってしまうので、避けておく。

58 · 04/06/21 23:18

>>129
フォローありがとう。

**踊る大走査線** · 04/06/21 23:20

ぶっちゃけ内部処理300fps最強ですよ。（200fpsくらいでも十分かも）

リフレッシュレートが60Hzだろうが75Hzだろうが85Hzだろうが、
３～６ステップ適宜進行→描画→VSYNC待ちのループだけで、
60Hz完全同期との違いがわからんくらい十分ぬるぬるぽ動くよ。
今のCPUは滅法速いから、ゲームロジックの負荷が数倍になろうが問題にならないし。

Δt可変の方法はリプレイのこと考えると全滅かな。

**名前は開発中のものです。** · 04/06/21 23:46

>>132
ガッ
　
うえー。それは3Dゲーム限定の話でないの？いやマジで。（ﾟдﾟ）ﾎﾟｶｰﾝ
にわかに信じられないのでとりあえず確認中。
ちなみに、俺はDirectX7の頃にfpsリミッター解除でD3Dで2D横スクロールとか色々実験したが
流石に2D横スクロールでティアリング誤魔化すのは無理ぽって結論に達したぜ。

この辺は程度問題ということで、気にしなければ大した問題じゃあないという路線なら俺は引き下がる。
　
58の場合、640x480程度の解像度でシステムメモリ→ビデオメモリのBitBlt転送だろう。
ハードウェア支援があっても200fps～300fps安定して出すのは至難と思われ。

**名前は開発中のものです。** · 04/06/21 23:56

更新は1秒間に300回で、描画は1秒間にリフレッシュレート回ってことじゃねーの？

300回は50と60の最小公倍数だからコンシューマ用にもピッタリ

**ID:xW89oDgi** · 04/06/22 00:03

最小公倍数（・∀・）ｶﾞｯﾃﾝｶﾞｯﾃﾝｶﾞｯﾃﾝ

58 · 04/06/22 00:08

おかしい、whileに + remain_time した瞬間値がマイナスになってるっぽい。
あと、wait_vsync という意味わかんない関数名は気にしないでくれ、昔の名残だ。
もう寝る（´・ω・｀）

DWORD before_time = timeGetTime(), now_time, remain_time = 0;

void wait_vsync(HDC hDC)
{
while(((now_time = timeGetTime()) - before_time) * 3 < 50)
;
remain_time = (now_time - before_time) * 3 - 50;
before_time = now_time;
}

**ID:xW89oDgi** · 04/06/22 00:14

>>132
ｺﾞﾒﾝx256。
てーか俺って>>132の書いてること全然読んでないし。
寝ぼけてるので寝る。ごめんあさーせ。

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

素人なのでBoost::timerなんて物があると知らなかったよー
timeGetTimeが1000msまでしか測れなくて悪戦苦闘してたのが馬鹿みたいだ

**138** · 04/06/22 03:27

>>86の方法を使ってみたら、安定して60fps出るようになったのですが、しかし、
>>58のような方法を使ったときよりも、動きがカクカクします。
素人なので原因がよく分からないのですが、Boost::timerの精度が低かったりするのでしょうか？

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

timeGetTimeが1000msまで？
ms単位をDWORDで返すのにそれは無いだろう。

>>86のはSleepの精度の問題かもしれないので、timeBeginPeriod(1)
とかやって見ると良いかもね。
もしくはビジーループに変える。

他にはメッセージループの問題とか色々考えられるかな。

**138** · 04/06/22 03:59

timeGetTimeは1000msじゃなくて1msか。
今は>>58の方法に戻して保存しちゃったからソース残ってないんだけど、
自分はこんな感じで書いたからSleepの精度は関係ないと思う(自信無いけど

const double FRAME_RATE = 60.0;
double gameTime = 0.0;
double gameDeltaTime = 1.0 / FRAME_RATE;
double currentTime;

do{ //ゲームループ
do{ // VSyncに同期しない場合、ループで待機
if(PeekMessage(&msg, 0, 0, 0, PM_REMOVE)){
TranslateMessage(&msg); DispatchMessage(&msg);
}
currentTime = t.elapsed();
}while(gameTime > currentTime);

gameTime += gameDeltaTime;

Update();
Draw();
}while(1);

**名前は開発中のものです。** · 04/06/22 04:12

>>141
Windowsメッセージはビジーループに入れないで一気に処理
しておく方が良いかも。

**名前は開発中のものです。** · 04/06/22 04:14

ありゃ、タブが効いてない…
で、boost::timerの精度が低いのかな、って思ったのは、
下みたいなコードを書いた時に32-40FPSあたりをうろうろしたからなんだけど
下のコード、何か間違ってるかな？
あと、内部でclock()を使ってる、と書いてるサイトを見かけた。

const double FRAME_RATE = 60.0;
double gameDeltaTime = 1.0 / FRAME_RATE;

do{ //ゲームループ
　t.restart();
　Update();
　Draw();
　　do{ // VSyncに同期しない場合、ループで待機
　　　if(PeekMessage(&msg, 0, 0, 0, PM_REMOVE)){
　　　　TranslateMessage(&msg); DispatchMessage(&msg);
　　　}
　　}while(gameDeltaTime > t.elapsed());
}while(1);

**138=143** · 04/06/22 04:19

>>142
PeekMessageの部分は外に出したり中に入れたり、いろいろ試しましたが、同じ結果だったと思います

**名前は開発中のものです。** · 04/06/22 04:29

>>143
そのコードだとt.restart()が良くない。

1フレームの間隔だけを測っていると安定しなくて当然だよ。

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

>>143
clock 関数は、呼び出しプロセスにかかった時間を通知する。

つまり、この用途には使えない。

58 · 04/06/22 20:53

136のソースのバグが取れない…。明日に回す。
>>138
俺が使っているループです、参考になれば。
WM_PAINTで描画、WM_DESTROYでmsg_loop=0にしてる。

int msg_loop=1;
while(msg_loop)
{
if ( PeekMessage(&msg, hWnd, 0, 0, PM_REMOVE) )
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
else
{
InvalidateRect(hWnd, NULL, FALSE);// 画面更新
}
}

58 · 04/06/22 22:10

意外と簡単に直った。が、ウインドウを2秒間ぐらいドラッグするとfpsが601になる。謎。
通常はだいたい60fps。

void wait_vsync(HDC hDC)
{
while(((now_time = timeGetTime()) - before_time) * 3 + remain_time < 50)
;
remain_time = (now_time - before_time) * 3 + remain_time - 50;
before_time = now_time;
}
上の方のソースとあんまり大差ないな。（´・ω・｀）
まぁ、バグが取れただけ良しとしますか。

**名前は開発中のものです。** · 04/06/22 23:37

ようするにおまいらシューティングゲーム製作技術について
語ってないってことでＯＫだな？

**名前は開発中のものです。** · 04/06/23 01:38

OK
スレ違い

**名前は開発中のものです。** · 04/06/23 05:10

>>2の関連スレが生きてるんだから、そちらでやったほうが良いかもしれないな。
質問と正答のやりとりで済むならここでもいいんだが。

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

>>106
＞FLASH上で編集した弾幕を自作のエクスポーター
これってどういう環境で作ったんですか？
関連サイトや書籍とかあれば教えて下さい。

後、アニメーションやキャラ配置、その他のデータ出力とかもやってるんですかね？

**名前は開発中のものです。** · 04/06/23 10:09

俺も気になるな、それ

**名前は開発中のものです。** · 04/06/23 10:55

ABAさんトコで紹介されてた
BulletML対応の弾幕生成FLASHのことじゃないかと思う俺。

86 · 04/06/23 11:35

ああ、boost::timerは機種依存なくて
手っ取り早く浮動小数で時間が返るタイマAPIだから使っただけ（ｗ
boostの中の人はANSI Cのclock関数呼んでるだけだから、精度いいとは思えんです。

**92=87** · 04/06/23 23:06

>>152
http://www.macromedia.com/devnet/subscriptions/
えーと、個人的な感想ですが、あんまオススメできません。
Flash通常版で十分イケます。SWF形式の構造は公になってますので
SWF2●●なコンバータを作るとか、そういう方向でひとつ。
http://www.openswf.org

>>154
別の方です。

**152** · 04/06/24 00:45

ギョエッ。英語かーｗ

ｻﾝｸｽです。
日本語の解説サイトないかググッてみます。
なければ諦めますｗ

プラグイン系のスレって、あんまないですね。
興味ある分野なのですが、、。
ＭＡＸプラグインとかかなり便利らしいけど、日本語解説がないみたいで挫折。

**152** · 04/06/24 01:05

一応少しありました。

多分、SWF形式ってムービーのような構造？
プロジェクトファイル（*.fla？）をコンバートORエクスポートするのがよさげかな？

やっぱ、英語が出来んと駄目か、、鬱

**92=87** · 04/06/24 01:42

>日本語解説がないみたいで挫折

というか正規ユーザーでなければプラグインのテストすら出来ないはずなので
技術的な面で挫折要素はないんですよ。正規ユーザーなら、分厚いマニュアル
入りの小箱が数個ほど届きますから、まずアレと格闘することになります。
API巨大ですがサンプルありますし。デベロッパーも多いのでフォーラムも
充実してますし。DirectXとかOpenGLとかWin32APIを乗り越えてきた人なら
そんなに心配しなくて平気です。
　
Macromediaの製品に関しても同様で、買えば“相応の”サポート情報は
得られますんで・・・（本当か？
英語は避けられないに関しては同意。まぁ、これは慣れる他ないんで。

**92=87（補足）** · 04/06/24 01:47

えーと補足。「お前、割ってるだろ」と言ってるように見えるんで訂正。
挫折するには早すぎるだろ、という趣旨です。

**名前は開発中のものです。** · 04/06/24 07:53

Flashの開発環境って結構たかいのね
言語の開発環境並みかよ！

**名前は開発中のものです。** · 04/06/24 23:58

例のシューティング本でてたが・・・ありゃ、シューティングというよりか、
弾本だな。

**名前は開発中のものです。** · 04/06/25 00:33

これのこと？
http://cgi32.plala.or.jp/higpen/shtbook/shtbook.shtml

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

それそれ。
プログラミングには詳しい人が書いた本だけど、シューティングゲーム・・・
というかゲームについてはイマイチ分かってない人が書いたっぽい内容だった。

あんな当たり判定じゃ、通り抜けしまくりじゃん！とか。

**名前は開発中のものです。** · 04/06/25 13:41

読んでないけど、いろんなゲームの引用してるんでそ？
知らないってことは無いんじゃ…。

**名前は開発中のものです。** · 04/06/25 14:15

実際に遊ばせるレベルのものは作ってない感じがする。

**名前は開発中のものです。** · 04/06/25 14:35

ちゃんと動くゲームを作るのと遊んで面白いゲームを作るのとでは別ものの技術が必要だからな
このスレ自体は>1のとおり両方を扱うわけだが

**名前は開発中のものです。** · 04/06/26 00:17

あれ？前スレによると、その本書いた人は老舗の同人ゲームプログラマじゃないの？

**名前は開発中のものです。** · 04/06/26 00:22

まぁまぁ。このスレの半分は漏れ含めて似たようなもんだし・・・orz

**名前は開発中のものです。** · 04/06/26 00:52

面白いシューティングを作る方法って本で解法できるか？
作り方を載せるくらいしか本では出来ない気が駿河。

**名前は開発中のものです。** · 04/06/26 02:10

>>163
つーかそこのＨＰにあるゲームで
技術の程度が知れるな

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

技術的に見れば、ある程度の物ならどの同人シューティングもたいしてかわらん

**名前は開発中のものです。** · 04/06/26 02:40

あの本よんだら
「そんくらいのことは普通に・・・」
って悲しくなった。

**名前は開発中のものです。** · 04/06/26 02:56

吉田弘一御大が昔書いたノウハウのテキストとサンプル集のがある意味面白いかもね。

**名前は開発中のものです。** · 04/06/26 03:12

今、知りたいのは
シューティングゲームの美しい設計＆リソース管理かな・・・

美しい設計で市販レベルの3Dシューを作るってサンプルなら
結構自分は見てみたいかもしれない。

**名前は開発中のものです。** · 04/06/26 03:28

自分じゃなにもできんのか？

**名前は開発中のものです。** · 04/06/26 03:29

もちろん自分で作ったものがすでにあるが
それでも他人のを参考にしないと向上がないということもわからんのかね

**名前は開発中のものです。** · 04/06/26 05:51

そうはいかんざき

**名前は開発中のものです。** · 04/06/26 05:53

言わせておけば・・・いいか藻前ら！

そういう話題をこのスレで出し合うのだと思います。

**92=87** · 04/06/26 05:57

見た事無いものにはややもすれば幻想を抱くものだから
別に責めたりはしないが･･･。マ○○は甘い香りがすると
思い込んでいたあの夏の思い出（教訓）は忘れないでほしい。

**名前は開発中のものです。** · 04/06/26 05:58

クッキー･･･
　

えーと、気休めかもしれませんが、ソースコードだけなら
洋物ゲームは大股開きで晒してるものがチラホラありますんで
そういうのを覗いてみるものアリかと。
　

　

**名前は開発中のものです。** · 04/06/26 06:06

>>180-181
warota
　
「俺のプラグインはええか、ええのんか。」

**名前は開発中のものです。** · 04/06/26 06:33

まぁアレだ。妄想オナニーが一番楽しいんだよな。本当に。
本物がみたいみたいみたい。とか言ってる>>177みたいな奴に限って
実際に本物を見せるとオエーと叫んで反吐ぶちまけるんだよ。
嫌ならAlienbrainを導入して脱衣シューを作ってみりゃいいのさ。（※楽しくないよ）
それで>>177が幸せならミーハーの真髄。俺は何も言う事は無い。

**名前は開発中のものです。** · 04/06/26 06:34

s/嫌なら/妄想だけじゃ飽き足らないなら/

**名前は開発中のものです。** · 04/06/26 06:42

なんか激しく勘違いしてる人がいるが、まぁわかる人にはわかるか。

**名前は開発中のものです。** · 04/06/26 07:38

>>180
ｴﾛｵﾔｼﾞめ。（・∀・）ｵﾚﾓﾅｰ
　
>>183
ミーハーてのは言い得て妙ではあるが、俺も自分自身の工房時代を回顧するとやはり
激しく妄想しながらカリカリ組みながらベーマガを手垢とか色んな汁でベトベトにしてたので
ID:gUL/HHc+ の「本物が見たい」という感覚には理解を示したい。というか懐かしさを覚えた。
　
>>185
勘違いしてんのはオメーだっつの。タコ
「こんなの漏れにはレヴェル低すぎ！(ﾌｧﾋﾞｮｰﾝ」　で初心者本相手に
ブーブー文句垂れてどうすんだっつの。まだ離乳食が食い足りねーのかクズ

**152** · 04/06/26 07:39

>>175
３Ｄって、スターフォックスみたいなの？
それとも、レイストーム系？

今、２Ｄで作ってるものが形になったら晒そうか？
内部見せるのは非常にみっともないが。

今、フリーズバグ等あるんで、もう少し掛かるけど。

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

>>186
初心者本に「マニアックス」ってつけちゃうのはマズいと思うよ

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

このスレは慈愛に包まれている。

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

>>188
む、そういえば。全くだなオイ（豹変

**名前は開発中のものです。** · 04/06/26 11:39

大抵のゲープロ入門本はSHT、ACT、RPG、AVG等手広くカバーしてるのが
ほとんどだから、SHTのことしか解説してなきゃ、そりゃマニアックだ罠

**名前は開発中のものです。** · 04/06/26 12:06

>188
でも出版社が読者層確保を狙って命名をしたっていう大人の事情かもしれんぞ。

とりあえず読んだヤシが何を期待して読みに行ったかが
このスレの話題にふさわしいのではないかと思われ。
それが出せなきゃ銀の弾を求めに行った厨房ってことでFA?

漏れはプレイヤーの追い詰め方を研究したいなー。
こういう弾で左に追い詰めて右からあるいは前から刺すとかの基礎的なところから
西京ゲーみたいに詰め将棋でプレイヤーを追い詰める方法とか。
あ、でもそうなると弾の撃たせ方と弾の特性を良く知っておく必要が出てくるのか。

**名前は開発中のものです。** · 04/06/26 12:58

SHTのことだけをしっかり説明してたらマニアックを名乗ってもいいさ。
でもあれは、弾の軌道アルゴリズムがほとんど。
タスクやオブジェクト、アニメーション、当たり判定っていうゲームのコアに
なるところはほとんど説明していないからねぇ。

あれじゃ、花火のスクリーンセーバーぐらいが関の山。

**名前は開発中のものです。** · 04/06/26 13:04

>>192
何でも大人の事情で片付けちまうのは負けを認めるようなもんだぞ、っと。

**名前は開発中のものです。** · 04/06/26 13:07

そんなのシューティングに限らない他のゲーム本にまかせりゃ十分だべさ

**gUL/HHc+** · 04/06/26 14:18

なんか市販レベルてことばを使ったのがまずかったのか・・・
別に本物が見たいってわけじゃないんで、やっぱかんちがいされてんなー。

そういやレイストームだったか忘れたが
あれは恐ろしくソースが汚いらしいな。
グローバル変数の嵐だとか

**名前は開発中のものです。** · 04/06/26 14:30

全然関係ないが俺が仕事で触ってるソースもそんなだよ。
しかも前々任者が書いたそのコードを前任者がｵﾅﾆｰで中途半端に
クラス化してるもんだからなんだかどうにも意味不明（藁

こんなソース任されてなきゃ休日出勤なんてしねえのに・・orz

**152** · 04/06/26 15:40

>>196
では、続編は一から組み直しですかね？ありがちですが。

シューティングとは関係ないけど、DX9とMSXML(DOMでいい)の
併用してるケース知らないですか？

今、リソース管理をＸＭＬでやろうとしてて詰まってます。
（一番嫌いなリンクｴﾗｰ。LIBCMTのライブラリが競合してます。）
DX使わなければ、ビルド出来るんですが、、。

上手くいったら公開してみるので、情報あったら宜しくお願い。

**名前は開発中のものです。** · 04/06/26 15:44

やっぱさ、根本的に、管理者が移り気なのか、プログラマが移り気なのかしらんけど、
もっとできるだけ同じチーム内で長くやって、リファクタリングを続けていく文化を持たない
といかんよ。ソフト作る仕事、全般的に。

**192** · 04/06/26 15:59

>194
あー、そうかも。
ただ坊主憎けりゃじゃないけど単なる叩きになりそうだったので水差しますた。

>193
その辺は2ちゃんのスレに全部書いてあるよ・・・（´・ω・｀）
でも確かにそういうのがまとまった本があると嬉しいね。
漏れにもっと能力があればまとめページ作ってみたい気も駿河。
むりぽ。orz

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

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