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

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

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

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

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

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

**ゆうき** ◆MU2000.LWc · 04/07/15 00:01

ひとつ前の作品なんか、
ノーウェイトでFPS=300ぐらいだったから、
単純に2.4を5で割って500MHz　とかｗ
かなり無責任なこと書いてました。

今回はいろいろ報告があってウレシイんですが。

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

自作やってる仲間が多いと、低スペックPCの1台や2台
タダですぐに組めちゃうんだけどねｗ

**偽ガルーダ** · 04/07/15 00:13

>>590

＞もはやＵＭＡビデオカードより低スペックだしなぁ
これ以外だった。RADEONというのに騙されたかな？9000以上は非常に良いっぽいけど。

モバイルで開発ってのは、まだ厳しいのかな？
VC,DirectXは動作確認したので、一応は出来るようだけど。
今VC#入れてます。

**ゆうき** ◆MU2000.LWc · 04/07/15 00:18

>>594
みんな　もってない　or 最近の企業の　なんです('A`)
って、俺も自作なんて良くわからんヘタレですが。。。

っていうかHSPなんで、描画なんてライブラリ作った人まかせ。
偉そうに動作環境とか書く権利すらないような・・・。
ウインドウズの知識はおろかCPUとかの動きなんて何も知りません（´・ω・`）

**名前は開発中のものです。** · 04/07/15 00:27

CPUの動きなんて俺も知らぬｗ

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

>>595
というかUMAのチップセットがここんところ速度品質ともに進歩しすぎ
元々ネックはメモリ帯域だったんだけどDDRが標準になってきたり
PentiumMや90nmのPen4とか大容量キャッシュが当たり前になってきたりとかね

あと地味にクロックが上がっていたり(855GMEあたりは250MHzなはず)
パイプライン数が増えていたり確実な進歩しているよ

単純な速度的にはノートのは無印RADEONとほぼ同じと思っていいはず
ただ、VRAMがUMAのほうは64MBまでとれるので何かと便利
最近は同人レベルでも16MB超えるのがあったりしてるしねぇ

ただ、こういった底辺のチップセットはまだまだDirect3Dは重く、
速度的にDirectDrawに大差つけられてる
回転機能が欲しかったら３Ｄで実装するよりＶＲＡＭ１６Ｍくらいくってもいいから
１６方向分起動時に描画してバッファに持っておくとかすれば低スペックマシンで
快適になるだろうといった考え方が必要かな

**582** · 04/07/15 00:52

>>595
Mobility-RADEON-D(16MB)は
GF256(DDR) ～ GF2MXの間ぐらい。

Fixed-T&L機能搭載のﾋﾞﾃﾞｵﾁｯﾌとしては
最低ﾗｲﾝだが、PIII-1GHz程度のCPUとの
組み合わせならば3DMark2000の点数で
3500程度は出る。

俺のサブノートがこの組み合わせなのだが
Unreal Tournamentが60FPSで動いている。
2DSTGが重たくなるのは、比較的派手な
演出をしているかコードがおかしい場合のみ。

**582** · 04/07/15 01:03

>>598
16MBの内蔵DDRメモリにテクスチャが収まる場合
よほど間抜けなコードを組まない限り軽快に動く。
　
BF1942でさえ30FPS出るのだから、要は組み方の問題。　

**偽ガルーダ** · 04/07/15 01:47

>>598,>>599
ナルホド。参考になりました。

＞派手な演出
特にないです。
回転についても、まだ保留しています。
（完全に再現するなら、パターンで持つしかないんですが）

＞コードがおかしい
ＣＰＵについては、まだ全然チューニング出来てないです。
特に、メモリプール、ハッシュ等は。

まあ、追々やってきます。

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

>>600
2Dのほうが大幅に早いってのは855GMの話な
さすがに１フレームあたりスプライト数１０００は変わるので
かなりかわるというわけさ

**582** · 04/07/15 12:20

>>602
それは全く事実ではない。
i855GMの内蔵グラフィックス機能（Intel Extreme Graphics2）は
RivaTNTクラスに相当する。ハードウェアT&Lを搭載していないが
ラスタライズはハードウェアが行ってくれる。
　
このような構成のビデオチップでは、アプリケーション側のコードで
行列計算を行い、T&L済みの頂点データを流し込んでやるのが
一般的だ。2Dゲームの場合は特にパフォーマンスが改善される。

**582** · 04/07/15 12:24

http://pc.watch.impress.co.jp/docs/2003/1105/hotrev234.htm
　
参考までに。

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

>>604
それ7500やん
無印とだいぶ違うぞ

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

一応補足しておくけどDirect3Dで全く回転させない描画とDirectDrawの比較な

だからT&Lがどうのこうのというレベルではないよ
単純にバッチで処理するようになってるので
単体使用ではオーバーヘッドが大きいというだけさ

だからこそ低スペックＰＣでの話な＞回転機能OFFでDirectDraw

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

>>603
そうですね。私はi854ユーザーですが
Quake2エンジン系のゲームちゃんと遊べます。
Direct3DのソフトウェアT&Lパイプラインは
2DSTGには非効率ですから自前でやりますね。
　
>>605
ベンチマーク結果の表を見ましょう。
右隅はi855GM。T&L未搭載でUMAです。
真ん中はモバラデIGP。モバラデのUMA版です。
Quake3-Arenaに注目してください。

**582** · 04/07/15 13:58

>>606
つまり、フルスクリーン256色モードでカラーキー使った
VideoMemory(UMA)->VideoMemory(UMA)のBlt()と
Direct3Dを比較していたということか。

別にそれでも構わないが、DirectDraw VS Direct3D の
重い軽いを比較するにはやや不条理な前提であろう。
　
前者はVideoMemory(UMA)->VideoMemory(UMA)の矩形転送。
つまり全ての描画はハードウェアラスタライザの支援を受ける。
　
それと同じ処理をDirect3Dでやるということはハイカラー以上。
VideoMemory(UMA)->VideoMemory(UMA)の矩形転送では
データ転送量は最低でも倍になる。

古いビデオチップであろうと新しいビデオチップであろうと
DirectDrawにとって極めて有利な条件といえる。

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

俺は昔からハイカラーしかつかわんよ
riva128クラスからは256色のほうがblt遅かったし

多機能な３Ｄのほうに不利な条件ってのは分かってるけどね
だからこそメモリ使用量を抑えて３Ｄ描画より回転させる程度ならその分用意すればいいといったまで
省メモリと速度とのトレードオフだが、要16MBくらいなら今は許してもらえる範囲か？という話な

あとQuake３の結果はまったく当てにならん
CPUがPenM1.4GHzと高速な割に可変フレームレートで70fps程度しかでてないことから
１ＧＨｚ以下を対象に２Ｄの固定フレームレート維持は結構厳しそうだ

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

前にも出た気がするけど、みんな画面の解像度いくつでやってる？
横STGなら俺は320ｘ240でやりたいんだけど、縦で画面比3:4にこだわると
縦240ドットだとどうしても小さすぎるんだよな。
レトロコンシューマ風なら横長320ｘ240もアリだと思うけど、アーケード風で
やりたいので…。でもアーケード風だと縦480は細かすぎる罠。

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

じゃあ300x400でどうよ

**名前は開発中のものです。** · 04/07/15 23:54

今なら躊躇無く640×480でいいんでない？

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

320*240はちゃんと表示されない環境多いし
誰でも出せる640*480だろう

自分さえよければいいという人はしらね

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

320*240を2倍に拡大するのがいいのかなー。

**名前は開発中のものです。** · 04/07/15 23:59

アーケード風縦画面縦STGなら横360縦480で決まり
640x480の解像度以外は遊べないプレイヤーが出てくる
画面全体を任意拡大できるSTGもいくつかあったな

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

個人的には、2DSTGもD3D必須となっている今、
多少VRAMを多く使うとしても、800*600に移行し始めてもいいと思うんだけどな。
今どき320*240なんてみみっちいものを選ぶ理由ってなに？

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

ドッターが死ぬ

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

>>616

>>610はアーケード風でやりたいから、と書いてるぞ

**610** · 04/07/16 02:09

レスThx。
主にアーケード2DSTG風ね。
やっぱVGAの縦をいっぱいに使った360ｘ480に落ち着くかなあ。
ちょっと細かいんだけどね～。
800ｘ600にしてピクセル縦横2倍のほうが（実質300ｘ400）雰囲気は
近いかな。速度とメモリが問題なければこれもアリか。

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

往年のは縦320なんだよな。
ウィンドウモード限定にして縦640または960なんてことをやると…環境によってはマズいかな？

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

240*320で縦シューつくって
フィルターかけずに
1240*1024の解像度に
3.0倍拡大させて描画

**610** · 04/07/16 03:40

今更619の訂正
×＞800ｘ600にしてピクセル縦横2倍のほうが（実質300ｘ400）
○＞800ｘ600にしてピクセル縦横2倍のほうが（実質225ｘ300）
何やってんだ俺様orz

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

関係ないが、今開発のために1280ｘ1024の液晶モニタを縦にして
2台横並べで使ってるんだけどさ、
この環境だと殆どのフルスクリーンのゲームが動かないんだよな。
当たり前だろといわれればそうなんだが…。
（Radeon9600pro使用、ドライバによる90度画面回転）

縦シューを縦画面でやりたくても、そういうのってなかなか無さそうだ。
そもそもSXGA液晶だと縦横比4:3じゃないしね。

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

今の俺の案
ゲームワールドは240x320（縦）で作成。
これを２倍に拡大して画面解像度1024x768の中心に。（表示域は480x640）

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

モニタを横倒ししてください、という同人ソフトがあってもよいと思う。

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

同人じゃないけど、キャリーラボのギャプラスを思い出す。

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

98VM以前だっけ…？

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

DirectDrawで縦2DSTGの雛型作ってるんだが、各描画オブジェクトを実際にDraw
する時の順番の管理に悩んでる。

つうのは各キャラクタには”高度(z)”の情報を持ってて、高度が低いｷｬﾗは小さく、
高いｷｬﾗは大きく描画する予定（レイフォースの敵雑魚を想像してくれい）なんだが、
ここで描画の順番を考慮しないと高高度を飛んでるキャラクタの上に低空を飛んでる
小さいキャラが上書きされてしまう事がありｶｺﾜﾙｲ。

１フレーム毎に全ての雑魚を高度情報を元に描画順をソートしてると時間がかかりそうなもんだが…
なんか良い手はないんかね？

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

ふつうにソートしろ

２００ＭＨｚ以上がターゲットならば
スプライト１０００くらいバブルソートでも余裕だぞ？

６０ＭＨｚクラスだと少し厳しいかもしれない

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

>>628
そんなに時間かからない。2Dシュー程度のオブジェクト数なら、
何も考えずCのqsort()とかC++のsort()とか使って平気なくらい。今時のPCは滅法速いからな。

ソート時間実測してみて、本当に重いようならバケツソートとか基数ソートとかを検討のこと。

**628** · 04/07/16 19:40

気にし過ぎだったかな
普通にソートしてみるよ
ﾏﾝｶﾞﾄ

ﾉｼ

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

２Ｄの場合ソートする必要があるオブジェクトの方が少ないんでは？
少なくとも敵弾のプライオリティは他のオブジェクトよりも上だろうし

**偽ガルーダ** · 04/07/16 22:58

定期報告です。

敵情報設定ツール、ステージ設定ツールに敵配置機能を追加。
どちらも仮実装で、まだまだ仕様が固まってないです。

ランタイムの方は、配置データを食わせるのと、
仮タイトル画面＜＞ゲームの行き来を実装。
これからボスにかかります。
その後は、無断使用している素材の全書き直し、、。

自分の場合、２Ｄのソートはとりあえず避けました。
拡大すると不味いんだけど、取り合えず、アルファテスト使ってます。

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

古典的な方法なら、初めから高度別にリストを何本も用意しておくのが普通ですな。

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

毎回ソートしない手としては、
描画専用のリスト構造を用意して、それを常にソートされた状態にしておく、ってのがある。
挿入やZの移動が発生したときだけリストを辿ればいい。

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

PSのオーダリングテーブルと同じ方法でいいんじゃねーかな。

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

>>634
>>636
うむ。それがバケツソート（bucket sort）。

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

ほんとだ。調べたらそのまんま説明が出てた。
バケツソートを使うのが普通じゃなかろうか。

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

素材で思い出したんだが、開発途中の素材の管理も面倒じゃね？
沢山のキャラや各パターンのビットマップを最終的に１枚のビットマップに纏めてるんだけど、
>633みたいに後から差し替えるとなるとかなり手間なんだよなぁ
もっと簡単に管理したいんだが･･･

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

バケツはその名前しらなくても少しでもプログラムやっていれば
自然とみんな使うようになるアルゴリズムの代表だね

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

オレは最近は手抜きで、
バケツは使わずにC++のstd::multimap使ってる。

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

ぶっちゃけゲーム、とくにＳＴＧなんて
コレクション系使いこなすための勉強にすぎない

といいたくなるくらいコレクション分かっていればどうにでもなるからな
一番技術的なレベルが低くても作れる物だけに熱くなれるというか

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

>>639
素材は１パターン１枚のビットマップで作る。
最終的にそれを編集して一枚のビットマップにするツールを自作。
マップチップツールの応用で結構いける。
ツールにはパターンマップを吐かせる。
後から配置換えしたくなっても、ツールでいじればいいので簡単。
場合によってはパレット管理つけるとかお好きなように。

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

>>642
バカは帰って寝てろ邪魔だ

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

>>644
俺なんかへんなこといったか？

ＳＴＧは制作者側にとって一番敷居が低いゲームだろ
絵や音楽が優れてなくともアイディアとかバランス面でなんとかなったりするものだ

それだけにゲーム本編に力を入れることが可能だし、
職業プログラマなら気にしなくとも日曜プログラマのような趣味で作る場合
少しずつの時間の捻出でなんとでもなるというのが大きい

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

シューティングを作る技術＝プログラム技術と思われたらかなわんな・・・。
そのアイデアやバランスのノウハウも含めてのスレタイじゃないのかい。

百歩譲ってそうだとしても、君の理屈だと（例えば）ポリゴンＲＰＧやらＡＤＶの
プログラマーなら、ＳＴＧなど朝飯前で作れるという事になるのか？
そこまで言うのなら、自らの作品を以て実証して頂きたいものだ。

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

真っ先にゲームプログラム開始してそれなりに形になるのがＳＴＧだから
８ｂｉｔ時代にＳＴＧから勉強下って人は多いんじゃないのか？
いっておくけど、他のジャンルと比べて簡単というのは単純に技術力だけの物じゃない

ＲＰＧやＡＶＧなんかはボリューム出すためにだれやすく最後まで完結させることは難しい
また絵や音楽が重視される傾向にあるために一人で作るのは難しい

とりあえず最初に進むべき基本となるのが２ＤＳＴＧと思っただけだ
ＸＹとスプライト表示さえわかればどうとでもなる
それだけに基本は非常に単純であるが奥深いもので初心者から上級者まで
一緒に語りやすいいいジャンルじゃないのか

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

おいおい、釣られるなよ。
６歳並の絵しか描けない大学の教授だって、
絵について能書きたれたいこともあるんだよ

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

朝飯前で作れても
それが面白いかどうかは
また別の問題になるしな

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

テキトーなもんならシューティングに限らずどれも大して変わらないと思うが。

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

結局何が言いたいのかも不明だしな
口だけなら何とでもという典型

**偽ガルーダ** · 04/07/18 09:05

>>641,>>642
コレクション系ねー。何が良いのかちゃんと研究してないな。
これが良かったとか教えてくれると嬉しいな。

現在使用してるのは、ms標準のvectorとlistだけ。
（しかもベクターモドキ使ってる。標準のだと、中身が見辛い。それだけの為にｗ）
ファクトリーにはmapのが良いらしいけど、何かの本にmapは遅い。と書いてあったのでこれもvector。
にしても、オーサリングツールが整ってくると、結局汎用クラス作った方が楽な気がしてきた、、、。

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

ファクトリにvector？　逐次探索使ってるんか？
それに比べたらmapのほうが高速だと思うが。
それともハッシュと組み合わせたらvecto

mapが遅いのはおそらく同様の

mapは内部構造が二分木だから遅いんじゃなかったっけ？
ハッシュ二分木のhash_mapってのがSTLに追加されたと思う。
そちらを使ってみては。

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

ああ…編集中に書き込んでしまった＿|￣|○

mapが遅いのは同様の機能を別の方法で実装したときのほうが速い
というだけであって逐次探索に比べたらよほど速い。
で、この程度のことならハッシュを使うのがいい、ってことかな。

**偽ガルーダ** · 04/07/18 09:42

>>653
ファクトリに、newされたポインタを返すstaticメゾットと
オブジェクト名をセットにしたクラスを登録してます。
まんまmapの分野なんですがね、、。

文字列検索はそこらじゅうで使ってます。ｗ
ハッシュを使うのがいい。てのは判ってるんですが、
差し迫ってないので、保留してます。ｗ
それとアロケート系がＣＰＵ負荷の殆どだと予想してます。
どちらも、数の上で重要であろうは、タスクステータス関連ですが、
アルゴリズムとメンバの分離をやるべきかと思うけど、手付かずです。

そもそも、ＣＰＵと描画の負荷をチェックする機能そのものがないですが、、。
追々やります。（最初にやるべきか？）

公開出来たら、追々ソースも晒そうかと思ってます。
酷くショボイので、勇気要りますが、、、。

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

SGIのSTLが元になってる系列のSTLならhash_mapは標準装備されてる(gccとかSTLportとか)。
デフォルトアロケータも一旦プールを作って使い回すような作りになってるので、
別にOSのメモリアロケート速度が遅くてもそんなに影響しないようになってると思う。
結局は思い込みでチューニングせずに、ちゃんと計測しないと却って遅くなってるかもよ？

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

このスレも３機目のようなので
よくわからないけどエクステンドしておきますね

(・ω・)ノ　[1up]

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

10upくらいしちゃった（茸）

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

ろじっくかよ。

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

今週末はグラディウスVをトコトン調べつくそうぜ！

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

グラ5ってアケじゃないのかよ・・
もう達人シューターがギャラリーはべらせて超絶プレイを披露する
時代は終わったのか・・orz

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

今は達人シューターがリプレイをupして
超絶プレイを世界中に披露する時代、なのかな？

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

>>661
100円で10分以上遊べるゲームはもうアーケードじゃ無理。

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

物価が上昇したから？

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

100円で10分以上遊べるゲームのほうが多いと思うが…
対戦格闘とか音ゲーくらいじゃないか？すぐゲームオーバーになるのは
それはともかくうちの近くのゲーセンはシューティング含む古いゲームが1プレイ50円なんだ
1プレイ20分として、ひっきりなしにプレイする人がいると仮定して（実際はガラガラなんだが）1時間で最高150円
開店時間が10：00～24：00までだから1台につき1日2100円しか入らない
機械のメンテナンス代、アルバイト代、エアコン代等差し引いたらどれくらい残るんだろう
どうやって経営成り立ってるのか非常に不思議だ

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

成り立ってないんじゃないの？
回転率のいいゲームがそれらの穴埋めをしているわけで。
バーチャや音ゲー、大型の多人数筐体()とかの
稼ぎのいいゲームしかないゲーセンってのも増えて来るわけだし。
まじで、シューティングとかは常連の為のサービスみたいなものだと思うけど。

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

それだと昔の1980年～1990年頃のゲームセンターは
経営できないってことになってしまうよねぇ。

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

今のゲーセンの話。
もしかしてゲーセンは今も昔も変わらないと思ってる？
ゲームの寿命(製品サイクル)が短くなってるし、平均単価は上がっているし。
アケ板覗いてくると良いよ。

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

ゲーセン通い歴25年だから、歴史的なことはわかる。
金額やゲーム時間そのものより、アーケードゲームそのものが
衰退したことによる影響が大きかったってことかね。

シューティングゲームは今でも製品寿命が長いように感じるけど、
同じゲームをずっと設置してあるのは、なかなか償却できないから？

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

アーケードは衰退してないっての。
ビデオの数が減っただけで、最近は増収傾向だし。

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

>>670
はぁ？
最近までアーケード店舗自体は減少傾向にあったのよ。
今年度は増収傾向だけど、それは単なる数が減ったからにすぎない。

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

ゲーセン減ってるよ
ほとんどパチンコ屋になってたりする

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

アーケードゲームは衰退してない。
ビデオと田舎のゲーセンがなくなっただけだ。
大型店舗は増えてる。

近所のローソンがなくなったからって、コンビに業界は衰退してるって
言う馬鹿はいないぞｗ

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

これ以上語るつもりなら、ゲームハード・業界板に行ってくれ！マジで頼む。
せっかくスレが良い感じになってきたからさー。
じゃ、気を取り直して、次どうぞ↓

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

>>673
ふぅ・・・アホはは疲れる。
近所のゲーセンがなくなったからアーケードが衰退しているというわけじゃない。
全国的に減ってるてこと。

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

わらた

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

秋葉原はゲーセンがやたらと増えました

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

>>675
>>677
(　ﾟДﾟ)ｙ－~~~

じゃ、気を取り直して、次どうぞ↓

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

で、思ったんだけど武器のパワー調整ってどうやってる？

武器ごとに攻撃力を持たせるのが簡単なんだけど、
昔のゲーム、例えば達人とかでレーザー取ると
次から出現する敵が固くなったりして更に調整してるみたいなんで
他にも色々な方法があれば聞いてみたい。

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

>>679
達人みたく敵の固さをパワーの分母にするテクニックは
整数演算時代の遺物と言えなくもない。
弾の強さに浮動小数点が気兼ねなく使える今時のＰＣゲーの場合は、
わざわざ敵の固さまで差し替えずに弾の威力だけで表現する方がすっきりする。
整数演算時代でも、気の利いたシステムだと威力を固定小数点で持ったりしていたね。
達人は基本的に飛翔鮫ベースの古いシステムの建て増し構造なので、
ああするしか方法がなかったとも言える。

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

武器攻撃力、敵の固さ、ともに固定小数点で扱うのがいいんじゃないかな。
大往生とか、一番柔らかいザコですら自機の体当たりで何十フレームも当てないと倒せないし
オプションショットも2発以上当てないと倒せなかったりする。
こういった微妙な調整のしやすさは固定小数点の利点だと思う。
あぁ、たぶん浮動でも構わない。そこはお好みで。

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

それだったらint32で、ショットミニマムのパワーを1000とかすればいいと思うが。
わざわざ小数で考えるメリットが分からん。

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

固定少数はもう旧世紀の遺物。

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

>680
>681
おまえら、何をどうしたら、たかが小数にそんな幻想を抱けるんだ？

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

まぁ、固定少数も使いどころはあるけど、大抵は浮動少数でいくでしょ。
シューティングに限らず、 >>682 みたいな使い方はよくやる。RPG、SLGやアクションとか。

関係ないけど、かなり小規模のファミコンチックなシューティングって需要あるかなぁ。

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

多くは無いけどある。

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

>>685の言う「ファミコンチック」が何を指すのかによる。

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

>>683
つまり、PS2も過去の遺物？

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

>>682
そのミニマムを256だったり65536だったりと考える、
というのが「固定小数点」の考え方の基本なんだが、
用語の意味わかって言ってるか？
わざわざシフト演算しづらい１０進で内部データを扱う意味こそわからないぞ。

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

あ、書いてから気づいたが、
一部RISC系CPUなんかは小数点掃うために上位にバイトレベルでアクセスしたり、
ビット単位でシフトするより、割り算一回かました方が早かったりするので、
そういうことを言いたいのならスマソ。
でも、もしそうだとしたら、それは本当に一部コアなので、汎用的じゃないぞ

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

いや，別にシフトとかしなくてもいいってことだろ．

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

みんな回答ありが㌧
ちなみに漏れは敵の固さ固定で武器や敵の固さを0x10000を1とする固定少数でやってます。
浮動少数のほうも試してみます。

>690
共用体を使うのもご法度？

>691
敵の固さとかは座標みたいに整数へ丸める必要がないんで、
漏れはシフトとかしてないです。

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

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