【SB】Shooting Game Builder ver9【ｼｭｰﾃｨﾝｸﾞ】

**名前は開発中のものです。** · 2010/05/31(月) 08:27:19

SB ◆.if.Xu7A6c氏が作った開発ツール"Shooting Game Builder"について語るスレ

Shooting Game Builder公式サイト
http://maglog.jp/sb/

SHOOTING GAME DEVELOPER UPLOADER
http://www.esc-j.net/stg/

SB@wiki
http://www41.atwiki.jp/stgbuilder/
ニコニコ動画チュートリアル
http://www.nicovideo.jp/watch/sm8707904
http://www.nicovideo.jp/watch/sm8711074
http://www.nicovideo.jp/watch/sm8728404

前スレ
【SB】 Shooting Game Builder ver.8 【ｼｭｰﾃｨﾝｸﾞ】
http://pc11.2ch.net/test/read.cgi/gamedev/1263321872/

**名前は開発中のものです。** · 2010/07/19(月) 23:59:19

WRRRRRRRYYYYY！！
マウス搭載キタアアァアアアァ！！！！！！

**名前は開発中のものです。** · 2010/07/19(月) 23:59:35

ぱいtouchをしろってことだな！

**名前は開発中のものです。** · 2010/07/20(火) 01:37:08

俺も真っ先にその用途が思い浮かんだ

**名前は開発中のものです。** · 2010/07/20(火) 07:45:43

>>405
更新どもです

**名前は開発中のものです。** · 2010/07/20(火) 09:15:43

マウス移動はメニューセレクト・ランキングでは非対応だから
スクリプト組み込まないとダメですね
リプレイではマウス移動拾ってくれないので再生できないみたい
でも期待大ですね

**名前は開発中のものです。** · 2010/07/20(火) 09:17:45

>>405
更新乙です
PARAM修正助かりました。ありがとうございます

ようやく規制解除・・・長かったけどまたすぐになるんだろうなぁ
OperationSB ver 0.20 マウス対応上げときましたー

**名前は開発中のものです。** · 2010/07/20(火) 09:18:38

>>411
> Ｘ，Ｙ方向の速度から計算するのに平方根なくてできませんし、
> 角度から計算するのにも三角関数がなくてできません
目で見て動きがカクカクせん程度なら
精度だって三桁もあれば十分だろうから、
近似式でなんとかなりそうに思うが。
マジで桁一杯の精度で高速に計算するんなら、
ＣＯＲＤＩＣとか使って実装する手も
あるんだが、精度保証やらオーバーフロー処理とか
真面目にやってると結構な手間だぞ。

**名前は開発中のものです。** · 2010/07/20(火) 12:20:55

>>420
だから、進行方向の速度を変数に取得できるようにしてくれってことでは？
パネルでは速度の向きと速さを代入しているわけだから、システム的にはそれが保管されている変数の中身を返してもらうだけだし。
無理に計算で求めようとするから大変なだけで・・・。

ただ、マウスの座標取得ができるとなると、そこからターゲットまでの距離が必要になる場面も出てくるかも。
XとYに変数や数値を入れると、斜辺の値を変数に返してくれる関数パネルがあっても良いかもね。

>>419
マウス対応乙です。

**名前は開発中のものです。** · 2010/07/20(火) 12:27:12

>>411
速度を減速する時にマイナスになってしまわないようにするために、速度を取得して条件分岐ができるようになりますね。

進行方向の速度を条件分岐できるようになれば、この間の速度の倍速指定も実現可能だね。
例）現在の速度を変数に取得→それを×2倍して、再び現在の速度に代入

**名前は開発中のものです。** · 2010/07/20(火) 15:27:07

>>421
最近はマシンがもりもり高速化しているので
漏れの貧乏性のほうが問題なのかとも思うが、
内部的にはＸ方向・Ｙ方向の分速度を
単位フレームあたりのピクセル数かなんか
（固定小数点表示のサブピクセル位置とか）に変換し、
座標上のＸ・Ｙ位置をインクリメントしとるんだと思うんだよな。
向き（角度）はＸ方向・Ｙ方向の分速度の比の
アークタンジェントを取ることで求めていそうなので、
若干は負荷になるような気がせんでもない。

>>422
> 進行方向の速度を条件分岐できるようになれば、この間の速度の倍速指定も実現可能だね。
> 例）現在の速度を変数に取得→それを×２倍して、再び現在の速度に代入
裸のＸ方向・Ｙ方向の分速度が見えるようにすれば、
「Ｘ方向・Ｙ方向の分速度をそれぞれ×２倍して、再び現在の値としてセット」
というやりかたで同じことができる。
あるいは粘性というのは速度の自乗に比例するので、
「分速度の自乗に一定値（０．９９８とかいった
１．０に近い値）を掛けてから
平方根を取って元の値に代入」とかすれば、
「粘っこい液体の中での運動」が表現できる。

……とはいえ中身まで見てないんで、なんとも言えんのだが。

**名前は開発中のものです。** · 2010/07/20(火) 15:40:48

おまいら物理エンジンを要求する気かｗ

**名前は開発中のものです。** · 2010/07/20(火) 17:18:56

ソフトの性能が上がってもユーザーがついて来れてないか？

**名前は開発中のものです。** · 2010/07/20(火) 17:29:53

ソフトのバージョンなんか古くてもスト魔女レベルのものは作れると実証されてるしどうでもいい

**名前は開発中のものです。** · 2010/07/20(火) 17:38:59

懐が深い分には問題ないしょ

**名前は開発中のものです。** · 2010/07/20(火) 17:39:14

>>424
> おまいら物理エンジンを要求する気かｗ
ビルダーのユーザが、物理エンジンみたいな
お手軽な方法を希求するのは
むしろ当然じゃね？
どうやって実装したらいいか解んねーからビルダー利用すんだから。

内部表現がどうとか物理法則がこうとか、
そのあたりが解っててコードレベルでどういうふうに
落ちるか（つーかどう処理するか）分かるんなら、
Ｃなりアセンブラなりで書いたほうがたぶん早いっつーか、
マシンの性能ぎりぎりまで使えて面白いっつーか、
あるいは「フリーで使える固定小数点の基本演算パッケージなんか
どこにもないだろうから俺が書こうか？」とかいって
ビルダーの開発のほうに参加しとるだろうし
（おれなんか、アプリとしてのゲーム開発より、
むしろそっちの方が面白そうだと思う）。

Ｘ方向・Ｙ方向の分速度を差分でいじくるという発想があれば、
螺旋を描きながら飛んでく物体とか、
引力が働いて相互作用しながら飛んでく物体とか、
いろいろ（処理系にそれほど負荷をかけずに実現できる）
面白いネタも思いつくだろうが、
なまじそんなテクが広まっちゃうと、
「なんかハードル高そう」とかいって
一般ユーザにはかえって敬遠されそうな稀ガス。

とりあえず学生には、「ゲーム製作もいいけど、
学校の数学や物理の勉強もね？」と
言っといたらええんとちゃう？

**名前は開発中のものです。** · 2010/07/20(火) 18:34:06

まあ面白いSTG作るのに必要な人は頑張れば良いんじゃね

自分の作ってるシステムの面白さというか、方向がわかってれば
何が必要かわかるんだしさ
俺はいらねえや

**名前は開発中のものです。** · 2010/07/20(火) 18:45:15

個人的にはボタン判定分岐に
【コントロールフラグOFF時は分岐しない】チェックが欲しい
スプリクト上で追加した操作はこれと同期を取らせる作業で一番苦労するから
これがあれば一発でかなりラクになる

**名前は開発中のものです。** · 2010/07/20(火) 19:46:21

>>430
今のところは、コントロールを切る際にシステム変数を変更してます。
各スクリプトで、そのシステム変数を条件分岐することで、ポーズON時の挙動とOFF時の挙動のスクリプトを切り替えてます。
ただ、自機の破壊なんかがあると、タスクのタイミングがずれて、同期が取れなくなったりするのがつらいですが。

>>423，>>428
X，Y速度の合成とかあまり難しいことをしたくないから、入力・保持されてある進行方向の速度を取得できれば良いだけなのですが。

**名前は開発中のものです。** · 2010/07/20(火) 19:50:22

あと、武器のインデックスやレベルが、参照はできるのに変更だけできないのが解せないところ・・・。
自機のインデックスの変更ができるのなら、武器のインデックスやレベルなんかはもっと簡単にできそうなのだけど。

特に、インデックスはボタンで変更もできるからいいですが、レベルアップは必ずアイテム使用しないといけないのがツライです・・・。

**名前は開発中のものです。** · 2010/07/20(火) 20:01:25

今回の更新はエロ方面に力を入れろという解釈でいいんだろうか

**名前は開発中のものです。** · 2010/07/20(火) 20:09:59

>>433
マウスでキャラクタをクリックすると、ラスターで揺れるようなゲームを作成する気ですか？

**名前は開発中のものです。** · 2010/07/20(火) 20:16:42

>434
たとえばflashと比較すると得手不得手があるけど
マウス対応になったことで十分に実用可能だと思う

XX-CAKEとかと併用すれば揺れなんて簡単につくれるし

**名前は開発中のものです。** · 2010/07/20(火) 20:31:18

>>431
そういう手法をセマフォというんだが、
結局はシステム側でセマフォ管理をしてくれると
便利だっちゅー話だと思われ。

システム側で値の書換えをしたらセマフォをオンし（初期値はオフ）、
参照があったらセマフォをオフする。
参照側に返す値は、セマフォがオンだったら
状態変数から求めた戻り値を定数にセットしてからその値を返し、
オフだったら定数の中身をそのまんま返す。

ただ、実装が面倒臭いんじゃねぇかと想像するが。

**名前は開発中のものです。** · 2010/07/20(火) 21:38:41

>>436
勉強になった。
要するにフラグを使ったタスク切替え管理って感じだな。

**名前は開発中のものです。** · 2010/07/20(火) 22:20:54

>>437
そう。

実際には、セマフォを書き換えたり
値をセットしたりするような
“きわどい（クリティカルな）領域”で、
タスクが切り替わらないように
排他制御を行なう必要があるので、
タスク切替の割込をマスクするだの
（コードを自己書換えして処理をバイアスしたりする）
割込がマスクされている間の要求をキューイングするだの
相当にいやらしい処理がまとわりついていて、
こういう、きわどかったりいやらしかったりする処理
（制御用のスタックの内部をまさぐったりとか、
ポインタの逆探知をしたりとか）が
大好きな変態が言語処理系の開発者には
多かったりするのだ。

したがってユーザも、
処理系の中身を妄想しながらスクリプトをカく程度の
変態力を身につけていただけると嬉すい。

**名前は開発中のものです。** · 2010/07/20(火) 22:23:06

夏休み前にエロス機能充実とか、俺を引き篭もりにする気か！

**名前は開発中のものです。** · 2010/07/20(火) 22:30:07

夏休み・・・

**名前は開発中のものです。** · 2010/07/20(火) 22:53:56

>>439
> 俺を引き篭もりにする気か！
おまいはシステム開発をなめとんのか！
マシンに向かってコードをカいているだけで
システム開発ができると思っとんのか！
海なりプールなりへ行って、
表現すべき対象の形状とか動的特性とか、
観察してこなくてどうする！
貴様にエロゲ開発者としての誇りがあるのなら、
「お願いですからじっくり観察させてください」と
土下座してお願いするくらいのことはやってみせんかい！

**名前は開発中のものです。** · 2010/07/20(火) 22:59:49

ま、女体のサンプルは必須よな
引き篭もってないでナンパしてこい>>439

でないと俺のように婚活でヒーヒーいう毎日がまっている

**名前は開発中のものです。** · 2010/07/20(火) 23:07:54

一方で結婚なんかしないと既に固く決めた俺に隙はなかった

**名前は開発中のものです。** · 2010/07/20(火) 23:15:37

んなこというヤツに限って・・・
いや、なんでもない。今度飲みいこうや>>443

**名前は開発中のものです。** · 2010/07/20(火) 23:20:42

>>441
でも、リアルで追及すると逆にリアリティ無くなったりするんだよな・・・ｗ

**名前は開発中のものです。** · 2010/07/20(火) 23:24:18

>>442
> 婚活でヒーヒーいう毎日が
ヒーヒーいってんのか(w

まるっきりスレ違いだが、
技術を活かしてくい込んでいけそうな
公共・福祉関連のサイトの掲示板とかに
こまめに顔出ししてると、けっこう釣れるぞ。

あとは仕事で繋がってて逃げられない女を
精神的に追いこんでおいてから
ちょっと優しくしてやると簡単にオチる。

うわぁ鬼畜だ　○|￣|＿

**名前は開発中のものです。** · 2010/07/20(火) 23:25:47

>>445
あるある(w

**名前は開発中のものです。** · 2010/07/20(火) 23:35:29

おまえは黙ってろ>>446

女子ＳＢ部が見ていたらどうするつもりだ。

**名前は開発中のものです。** · 2010/07/20(火) 23:42:57

>>448
> 女子ＳＢ部が見ていたらどうするつもりだ。
『エロゲ製作に関する技術』スレとか、
『【企画】ギャルゲー製作！！』スレとかに
誘導するとかっつーんじゃダメか？

**名前は開発中のものです。** · 2010/07/20(火) 23:48:22

そうだな・・・
あくまで「シューティングゲームビルダー」だからな
エロメインの話題を振った俺が悪かったよ>>449

**名前は開発中のものです。** · 2010/07/21(水) 00:15:34

みんな、幼女で止めておけ

**138** · 2010/07/21(水) 01:51:53

水平反転、垂直反転の原理・方法について、まとめまておきました。
一応、サンプルをあげておきます。

（原理）
・水平垂直反転＝180度回転＝-100%拡大縮小
・水平反転：ミラーモードでU値をマイナス
・垂直反転：ミラーモードでV値をマイナス

（注意）
・180度回転と-100%拡大縮小は、相対をONにすることによりトグルします。
　180度＋180度→360度
　-100％×-100％＝100％
・U値はスプライトにおけるアイコン画像のX座標、V値はスプライトにおけるアイコン画像のY座標です。
・U値，V値は、アイコン画像のX座標，Y座標とアイコン画像の幅Wと高さHを用いて、
　「U＝－（X＋W），V＝－（Y＋H）」になります。
　左上（0,0）にあるアイコンの場合は、「U＝－W，V＝－H」になります。

**138** · 2010/07/21(水) 01:57:10

STG好きがメカ派と少女キャラ派に極端に分かれる（あるいは両方好き）なのは、軍オタに萌オタが多いのと関連はあるのだろうか？

**名前は開発中のものです。** · 2010/07/21(水) 07:56:54

両極にあるものは実は相性がいい
軍と萌、青と黄色、ＳとＭ、チンコとま（r

**名前は開発中のものです。** · 2010/07/21(水) 08:00:30

マウス座標の更新以降の話題を見て思ったのは、SBに手を出す奴には萌えオタが多いってことだな

**名前は開発中のものです。** · 2010/07/21(水) 08:02:01

>>454
>青と黄
相性良かったっけ？？
　青＝クールなライバル
　黄＝カレーが大好き

>>452
久しぶりのサンプル挙げですね。
研究お疲れ様です。
でも、画像の反転とかはデフォルトで対応して欲しいな。
反転パネル：□左右を反転，□上下を反転
・・・みたいな感じで、フラグを入れ替える方式にして

**名前は開発中のものです。** · 2010/07/21(水) 08:30:20

>>456
> >青と黄
> 相性良かったっけ？？
補色だろう。
白色ＬＥＤは青色発光体と黄色蛍光体の組合せだったはずだ。
ただ、当てる光と蛍光の波長（λ）には、
蛍光の波長＞当てる光
という関係があてはまる。
波長が短い方がエネルギーが強い（ｅ＝ｈｃ／λ。
ｈはプランク定数、ｃは光速）。
したがって青が責で黄が受だ。
字もなんとなく似ておろうが。

**名前は開発中のものです。** · 2010/07/21(水) 12:13:07

青×黄
責めなの？攻めじゃないの？

青黄色系擬似白色発光ダイオードのことか。
確かにLEDは単色だから、白色にするには3原色混合か、補色混合が必要だものね。
もっとも、青色LEDが出るまでは、蛍光体を組み合わせた白色蛍光ダイオードだったけどね。

**名前は開発中のものです。** · 2010/07/21(水) 15:30:52

何スレだよｗ
夏だねー

**名前は開発中のものです。** · 2010/07/21(水) 17:09:21

大変だ！！
＞Vectorブログサービス『maglog』
＞＞ttp://pc11.2ch.net/test/read.cgi/blog/1149261035/l50

**名前は開発中のものです。** · 2010/07/21(水) 18:16:55

だんだん何のスレだか判んなくなってきたが

>>458
> 責めなの？　攻めじゃないの？
「責⇔受」だよ。
そもそもＳＭプレイっつーのはＭが主体なの。“受”が主なの。
とはいえ“責”がいないと「責⇔受」というプレイが成立しないだろ？
だからＭだけど“責”の役割を演じるの。
だけど、本来は“受”に回りたいのに、
“受”の欲求に応じて“責”の役割を演じるのは疲れるの。
ストレスが溜まるの。
プロの女王様が、私生活ではＭだったりするの。
だから、ガス抜きのために
ときどき「責⇔受」の役割交換が起きるわけで、、
いわゆる“下克上オチ”っていうのはそれを踏まえているの。

続きはエロゲ関連のスレでやろうな。

**名前は開発中のものです。** · 2010/07/21(水) 18:45:32

BL用語では「攻め」

**名前は開発中のものです。** · 2010/07/21(水) 19:16:38

ＳＴＧ用語だと
「攻⇔守」とか「攻⇔防」とかになるのかな。
「攻⇔受」だとプロレス用語みたいな感じだが、
ＢＬの攻防というのはプロレスみたいに
「すべて受けきってから反撃」という感じなんかな。

シューティングゲームだと、
重爆爆撃機＋護衛戦闘機ＶＳ対空砲火＋局地戦闘機
みたいな設定になるのかな。
戦闘機の制御（ＡＩみたいな形になりそうだ）が
ムズい感じがするが、
そのあたりをうまく処理できたら、
けっこうゲームとして面白くなりそうだ
（『頭上の敵機』とかいうタイトルがもうあったりして）。

**名前は開発中のものです。** · 2010/07/21(水) 19:45:07

拠点防衛型　横STG
①～空母大和を死守せよ～
　高空から襲い来る急降下爆撃機・護衛戦闘機、海面スレスレを忍び寄る艦上攻撃機を、艦載機を操作して、対空砲・対空機銃の援護のもとで迎え撃つ。
　制限時間は日没まで。日本の海を守り抜け！！
　大和が沈没したらGameOverです。（相手に魚雷を撃たれると致命的です）
拠点防衛型　横STG
②～東京大空襲を阻止せよ～
　遠方より次々と襲い来る大型爆撃機B-29を、迎撃機月光と対空放火の支援で迎え撃つ。（B-29の飛行高度には届かないので注意）
　制限時間は夜明けまで。日本の大地を守り抜け！！
　皇居が爆撃されたらGameOverです。

**名前は開発中のものです。** · 2010/07/21(水) 19:51:22

攻⇔守のバランスはやはり大事なのかなと思う。
基本は、攻→ショットで攻撃、守→敵の弾を避ける
なんだろうけど。

ここら辺にもっとシステムを絡めていくと、ハイリスクだが近距離で高火力攻撃を出すとか、
ハイリスクだが敵の弾をギリギリで避けるとカスリゲージがたまって高火力が出せるとか。
敵の弾を防げるバリアをはれるが、その分攻撃もしないと、バリアが出せなくなるとか。

このあたりの攻守のバランスをとりつつ、シューティングならではの爽快感やテンポのよさ、
ビジュアルの美しさなどをうまく絡められれば、いいんだけどねぇ。

だがそれがむずかしい。

**名前は開発中のものです。** · 2010/07/21(水) 20:02:59

放置プレイSTG
・自機を操作することは一切できない
・時折際どい絶妙プレーを見せてくれることもあれば、凡ミスしてしまうお茶目な場面も
・プレーヤーは画面から目を離せない！！

**名前は開発中のものです。** · 2010/07/21(水) 20:05:37

>>466
イメージはDQ4程度のAI
　なぜボス戦なのに、馬鹿の一つ覚えでザキばかり～？
　はぐれの残HP1のその場面で、キメラの翼？？

**名前は開発中のものです。** · 2010/07/21(水) 20:12:16

キャラ特性を色々カスタマイズできれば、面白そうだな。
攻撃力主体、防御力主体、呪文主体、近距離物理主体とか。

あそびにん主体だといつまでも相手を倒す兆しが見られないが、時たまものすごいことをするかもな。

**名前は開発中のものです。** · 2010/07/21(水) 20:26:19

>>464
防衛側はフラストレーションが溜まりそうでヤだな(-_-!)

基本は縦スクロールの精密爆撃だが、
背景のスクロールは表示に負荷がかかりそうなので、
夜間爆撃という設定にして背景は基本真っ暗、
炎上する一部施設と敵機の排気炎と対空砲火の表示でごまかす。
画面も縦長で狭くして、敵機の表示は
負荷の軽そうな表示精度の低い機載レーダー表示で補助する。

だけど第二次大戦中の夜間低高度精密爆撃って
歴史上有名な例が思い当たらないんだよな……
英空軍にウラニウム精製工場とかＶ２の開発チームを
狙わせるとか、独空軍に対エニグマ暗号解読機を
狙わせるとかしてみるか？

**名前は開発中のものです。** · 2010/07/21(水) 20:46:51

～Deep Sea～
潜水艦STG

敵の位置は基本見えない。自分の位置も相手には見えていない。
敵が魚雷を自機へ向かって発射してきた時に、魚雷の来る方向から判断する。

探索波を打つことで、自機を中心として一瞬円が広がるように拡大して、周囲の敵の様子がわかる。
代わりに、相手にも位置を知られてしまい、誘導魚雷の対象になってしまう。

武器：
　直進魚雷（長射程の接触爆発、短射程で周囲に及ぶ時限爆発）
　誘導魚雷（ロックした敵をソナーで追尾して爆発）
　爆雷（発射位置から動かず、一定時間後に広範囲を巻き込んで爆発）
　探索波（ボム扱い、相手にもロックされる欠点あり）

移動：
　前方は100%、左右は自由に旋回、後方は70％、左右は50%で移動
　アップで表層へ浮上、ダウンで深層へ潜行
　表層では魚雷が「対空攻撃」属性に、深層では「対地攻撃」属性になる
（同じレイヤーのキャラクタ同士しか当たり判定なし）

**名前は開発中のものです。** · 2010/07/21(水) 20:55:01

>>468
こんなのどうだ？
攻撃側は坊さんと従者数名、
敵は妖怪と妖力で操られた村人。
敵はパワースポット周辺の一定エリアから出られないし、
妖力もその範囲にしか及ばない。
坊さんは物理攻撃に弱く、従者は物理攻撃力が高い。
妖怪は物理攻撃ができず、村人は物理攻撃しかできない。
坊さんは村人にかけられた呪いを解除して、
一時的に行動不能にしたり、正気に戻して逃走させたりできる。
従者は呪力に対抗できるし、妖怪を足止めできる程度の法力もあるが、
反面呪力によるダメージも受ける。
坊さんが妖怪に十分に接近し、法具と経文によって調伏すれば勝利。

……『西遊記』だな。

**名前は開発中のものです。** · 2010/07/21(水) 21:17:57

>>470
それ、
『スター・トレック』とか
『宇宙戦艦ヤマト』とかいったタイトルで、
すでに似たようなゲームが
出ているような気がして心配なんだが。

**名前は開発中のものです。** · 2010/07/21(水) 21:27:15

>>471
自機→坊さんとして、従者はその周りを囲い回るオプションかな？
効果の違うオプションのフォーメーションを駆使して、パワースポット内の村人に近づき掻き分けつつ、
隙を見て妖怪に近づきアタック？

システムの方向性では、シューティングというよりは、アクション寄りしてみたりも出来そうだな。

**名前は開発中のものです。** · 2010/07/21(水) 21:27:58

>>465
> 攻⇔守のバランスはやはり大事なのかなと思う。
> 基本は、攻→ショットで攻撃、守→敵の弾を避ける
> なんだろうけど。
「攻」のないシューティングゲームの名作も
あったような記憶があるんだが。
『チョップリフター』は攻撃用兵器ってあったっけ？
戦場から離脱するとき、乗り遅れた奴が
「待ってくれぇぇぇぇ！」みたいな感じで
手を振りながら追いかけてくるのと、
アメリカ軍施設に到着したときに、
建物の中に入ろうとしてから、
最後尾の奴がちょっと引き返して
「ありがとぉ～！」みたいに手を振ってくれるのが
やたら可愛かった印象がある。

**名前は開発中のものです。** · 2010/07/21(水) 21:44:42

>>473
> アクション寄りしてみたりも出来そうだな。
妖怪→宇宙生物
パワースポット→宇宙生物の影響で不時着した異星人の宇宙船
呪われた村人→宇宙生物の幼生にコントロールされた村人
坊さん→超能力者
従者→警察＆自衛隊のエリート混成部隊（機密保持のため少数精鋭）
妖怪調伏→幼生の苗床として利用されている村の女たちの奪還

ああなんかもう似たような設定の作品がいくつも脳裏を
うああぁあぁぁあ

……まあ設定はベタなほうが説明少なくていいし
プレイヤーが設定に入りこむのも楽だろうし
キャラデザインだってどっかで見たようなのを
ちゃちゃっと簡略化した奴でプレイヤーも納得してくれるし
結果システムの負荷が減って動きが滑らかで気持ちよくなるし
結構いいことづくめ

**名前は開発中のものです。** · 2010/07/21(水) 21:50:32

>>474
チョップリフターって名前は聞いたことあったんだけど、プレイ経験もみたこともないな。
なので一応今プレイ動画を見てみたが、ヘリで敵を攻撃するのはあったな。
それで救助地に着陸、人を救助みたいな感じだったな。

シューティングと呼ばれるゲームが、敵を打ち落とすところにどれだけ重きをおいてるかにもよるが、仮に「攻→弾で攻撃」
のまったくないゲームをはたしてシューティングとしてカテゴライズできるのかな？って疑問はあるな。

仮に「攻」のないシューティングゲームってのがあるんなら、既存の考えからどうやって抜け出して、違うもの、新しいものを
つくりあげてやろうかっていうところからうまれるのかもな。
うまくいけば新境地、悪くなれば奇をてらってクソゲー、あるいは未来過ぎて理解されない、そんなイメージだな。

**名前は開発中のものです。** · 2010/07/21(水) 22:03:54

ほんと夏だな

**名前は開発中のものです。** · 2010/07/21(水) 22:14:18

捕虜救出シューティングっていろんなの出てたね
トップビューからサイドビュー、はては自機がヘリからジープまで

**名前は開発中のものです。** · 2010/07/21(水) 22:26:50

>>473
キングスナイトを思い出した

**名前は開発中のものです。** · 2010/07/21(水) 22:38:59

>>476
> 仮に「攻→弾で攻撃」のまったくないゲームを
> はたしてシューティングとしてカテゴライズできるのかな？って
> 疑問はあるな。
いや、敵は撃ってくるわけだし。
こっちも一応武器は持ってるわけだし。
威嚇射撃くらいはやっちゃっていいと思うし。

♪飾りじゃないのよ軍備は　ＨＡ－ＨＡＮ
撃つわと言ってるじゃないの　ＨＯ－ＨＯ

**名前は開発中のものです。** · 2010/07/21(水) 23:33:19

>>477

ああ。夏だ。
だがまたこれもよし

**名前は開発中のものです。** · 2010/07/22(木) 09:29:28

誘導

俺が考えたシューティングゲーム
http://schiphol.2ch.net/test/read.cgi/gamestg/1123162660/l50

**名前は開発中のものです。** · 2010/07/23(金) 23:07:51

Detonationで小さめの爆発1個作ってるだけで今日が終わる・・・

**名前は開発中のものです。** · 2010/07/23(金) 23:43:29

>>452
やはり、X/Y別の拡大縮小の実装を

>>460
『maglog』なくなるのか？？

**名前は開発中のものです。** · 2010/07/24(土) 00:50:38

ｓｔｇ０６４４が、ｘ、ｙ別の拡大縮小サンプルっぽいけど、これじゃあダメなのかい？

**名前は開発中のものです。** · 2010/07/24(土) 00:57:18

>>484
いま閃いたんだが
画像を１ドットの幅できりとって（1*640pixとか）パターン登録して
少しづつ幅をせまくしながら並べるスクリプトを組めばよいのでは？

最初は大変だろうけど一度組んだらあとは流用すれば楽っしょ

**名前は開発中のものです。** · 2010/07/24(土) 01:10:48

>>485
多分>484が言っているのは台形変形のことだろう。
正直需要は少ないだろうな。

**名前は開発中のものです。** · 2010/07/24(土) 02:00:08

へぇ～、おれは詳しいところはよくわからんなあ。

そういえば、多関節の遅延で関節数を少なくして頭と尻尾が離れれば、伸び塩梅になるかもな。

**名前は開発中のものです。** · 2010/07/24(土) 04:09:58

>487
俺も欲しいぞ
表現の幅が一期に広がる

グラ関係にこだわらない人には不要だろうけどね

**名前は開発中のものです。** · 2010/07/24(土) 04:38:35

想定ハード決めて、機能縛りで作るのも楽しいよ

**名前は開発中のものです。** · 2010/07/24(土) 04:45:20

>490
ココの要望全部に言えるわな

**名前は開発中のものです。** · 2010/07/24(土) 05:23:24

そう？　結構できないことあって困るけど

**名前は開発中のものです。** · 2010/07/24(土) 10:22:06

多分、何故必要なのか伝わってない要望が多い気がするんだよね

こういうの作りたくて、こういう努力をしてるんですがこれがないから
どうしても作れないんです！

っていうアピールも必要だと思う。現機能での代替案を教えてくれる人もいるし

**名前は開発中のものです。** · 2010/07/24(土) 12:29:25

>>493
正直に言おう。
横STGを作成してるものだが、曲射系の武器や敵の落下運動を作成するのに、加速運動が設定できないと不便だ。

いつもローカル変数でY速度を取り出して、変数計算で加算or減算させる処理をループさせているが、かなり面倒くさい。
特に、地面で跳ね返そうものなら、結構大変だ。
もしも、初速と加速度を、X方向・Y方向を別々に設定できるパネルあれば、おそらくそれ1毎で事足りる気がする。

**名前は開発中のものです。** · 2010/07/24(土) 12:32:29

直交座標のパネルを流用して、
加速移動パネル）
　X方向の初速度Vx＝○○，X方向の加速度Ax＝○○
　Y方向の初速度Vy＝○○，Y方向の加速度Ay＝○○
　加速を継続するフレーム数○○
・・・ていうパネルが1枚あれば、変数なら最低でも4パネル以上が必要な処理が1枚で足りる

**名前は開発中のものです。** · 2010/07/24(土) 12:54:51

>>494
わかるけど・・・
面倒でも実現できてるように読み取れるんだけど

そういうのって一回雛形作っちゃえば
継承スクリプトなりで手間かけずに流用できそうなんだが・・・

俺はたとえば難しい挙動関係はいくつかのタスクにまとめておいて
雑魚はみんな継承スクリプトでそれを参照して共有できるようにしている

**名前は開発中のものです。** · 2010/07/24(土) 13:13:33

あとはビジュアルがイメージできないとつらいかもな

なんだかんだで完成させてる人とかサンプル上げてる人の要望の方が
通りやすい気がする。心情的にも

ガシガシ手え動かして完成させてる人は現況の機能でなんとかしようとするから
そもそも要望自体少ないかもしれんが・・・

**名前は開発中のものです。** · 2010/07/24(土) 13:42:55

加速移動は速度パネルをループするだけで出来ますがな

**名前は開発中のものです。** · 2010/07/24(土) 13:48:32

>>498
放物線移動は無理
水平は等速、垂直のみ加速が必要

**名前は開発中のものです。** · 2010/07/24(土) 13:51:04

確かにSBは主に縦シューティング重視の設計は否めない

**名前は開発中のものです。** · 2010/07/24(土) 15:20:25

今後、どんだけ凄いゲームがでるのか楽しみですなあ
はっはっは

**名前は開発中のものです。** · 2010/07/24(土) 15:25:50

>>497
たとえば>>494を例にして言うと、
494は「このままだと作るのが面倒だから」要望を出しているが、
完成させてる人は「面倒だったけどもう作りきっちゃったから俺はべつにいいよ」ってことで要望など出さない

完成した人オンリーにしたら、「どう頑張っても現状では実現できない仕様」以外は要望なんて無くなる

**名前は開発中のものです。** · 2010/07/24(土) 15:44:52

>>502
内容によっては文字で全て伝えるのには限界があって
ビジュアルで示せたほうが採用されやすいのでは？ってこと

俺も面倒だなと思うところは書き込みしてるし
要望自体を否定してるわけじゃないしね。

**名前は開発中のものです。** · 2010/07/24(土) 16:11:32

>>501
面倒な事が簡単になる要望、が通れば「最高のゲーム」になるんだろうなあ

**名前は開発中のものです。** · 2010/07/24(土) 16:50:28

>>484
> やはり、Ｘ／Ｙ別の拡大縮小の実装を

ひとつ確認したいんだが、
１）原画像を実行時にＸ方向・Ｙ方向に限定して
拡大縮小（ちょっと負荷あり）
２）原画像を実行前にＸ方向・Ｙ方向に限定して
拡大縮小した画像を自動生成しておいて、
（画像切替なので負荷は最小）
３）原画像をパースのついた感じで
実行時にリアルタイム変換（かなりの負荷あり。
>>487 が言っているのはこれか？
いわゆる射影変換というやつ）
のどれがやりたいんだ？（あるいはこれ以外の
ことがやりたいのか）

（３）はちょっとやったコトがないし
できる気もしないが、
（１）（２）に共通で使える拡大縮小ルーチン
（任意長方形のピクセルマップから
任意長方形のピクセルマップへの変換）なら
ロジック自体はそう難しくないぞ
（どう実装するかは、また別問題だが）。

**名前は開発中のものです。** · 2010/07/24(土) 17:02:06

>505
射影変換てやつだな
やっぱパースつけると負荷上がるのか
そういう理由で実装されないっていうのが正解なのかな

ちなみに１）と２）は現状でもできるように思うんだが・・・

**名前は開発中のものです。** · 2010/07/24(土) 17:03:42

>>502
「頻繁に出てくるパターンなので、
時期バージョンでは表現が簡潔になるような
（ついでに、それが効果的なら実装上も軽くなるような）
工夫をしていただけると嬉しい」という声が
それなりに集まってくれば、
考えてもらえるんじゃないだろうか。

あまりにも当たり前すぎて、書くのもこっぱずかしいが。

**名前は開発中のものです。** · 2010/07/24(土) 17:44:12

>>507
要望レスにケチつけるやつなんて
俺たちが苦労して組んだんだからお前だけラクするのはゆるさねえって事なんだろ
ほんとくだらねえ精神論だ。

**名前は開発中のものです。** · 2010/07/24(土) 18:48:13

>508
んなわけない。

俺だって楽したいし賛同したいけど
ちょっと文章に読み取れないところがあって
え？それってどういうこと？っていう流れだべ

**名前は開発中のものです。** · 2010/07/24(土) 19:25:37

いやー本当に今後の新作で凄い作品がでるのを期待しちゃうなあ
ガハハハ

古参じゃなくて新人なー

**名前は開発中のものです。** · 2010/07/24(土) 19:26:00

>>494は、現在の機能で実装してみた上で、利便性のための改良を要望しているわけだから、無茶な要望ではないと思う。

>>505
２）の目的であれば、はじめからXまたはY方向に拡大縮小したアイコンを用意しておいて、パターン番号で切り替えることは、現在の機能でも割と簡単にできる。

１）のXまたはY方向にリアルタイムに拡大縮小アニメーションさせる機能は現状で実装されているの？
>>485で言ってるサンプルをまだ確認していないからわからないけど、ラスターとかでできるのか？？

３）の頂点変形はやっぱり負荷が大きいよな。
SBでリアルタイムに処理できそうなのは、きっとアスペクト比の変更くらいでは。

**名前は開発中のものです。** · 2010/07/24(土) 19:46:47

>511
ラスターできるよ。
stg413

そういえばトリフィド氏のラスター背景サンプルが見つからなかった。
なくなってしまったんだろうか？

**名前は開発中のものです。** · 2010/07/24(土) 20:21:25

>>511
> リアルタイムに処理できそうなのは、
> きっとアスペクト比の変更くらいでは。
画質と計算量のトレードオフだな。
ラスターデータを抜いて画像の縮小（拡大のときは
コピーして挿入）をやると
計算量は減るが画質は落ちる（スピードが速いから
画質が少々悪くても問題ないっていう意見もあるが）し、
画質を落とさないように真面目に処理すれば、
それなりに重くなる。

真面目に処理するほうはちょっとしたギミックがあって、
もちろんピクセル毎の加重平均を取るわけなんだが
トップレベルで縦横拡大・縦横縮小・縦拡大横縮小・縦縮小横拡大に
場合分けしてそれぞれ処理を分けるというのが
けっこう思いつかない(w

一本のルーチンで済まそうとして自爆する香具師がけっこういる