【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/09/22(水) 22:27:36

>>937-938
何かしら使ってるタスクはリストボックスで色でも変わってくれたら
見やすいだろうなーとは俺も思ってたな（特に誰かのスクを見る時）
困ってるって程でもないから書かなかったけど

**名前は開発中のものです。** · 2010/09/22(水) 23:27:57

タスクは、リストボックスよりもタブにしてもらえると、見やすいかなと思った。

**名前は開発中のものです。** · 2010/09/22(水) 23:33:59

要望する奴は今までに上がった奴をちっとはまとめたらどうだ

**名前は開発中のものです。** · 2010/09/23(木) 00:21:26

1～500まで要望まとめたけどいる？//発言のみ抽出。実装されたものあるかも知れないけど未確認

**名前は開発中のものです。** · 2010/09/23(木) 00:27:05

wikiにでも上げておけば？

**名前は開発中のものです。** · 2010/09/23(木) 00:36:03

wiki面倒だからUPLのstg0725.txtにうｐ
ついでに便乗してstg0724.pngに素材うｐ

**名前は開発中のものです。** · 2010/09/23(木) 00:37:07

>>944
@wikiなんて使わなくていい

**名前は開発中のものです。** · 2010/09/23(木) 01:28:27

>>938
むしろそのせいで気がつかない内に
勝手に選択項目変わってしまって不具合出た事があって
原因探すのにものすごい手間がかかったので
怖くてホイールボタン使えなくなったよ。

**名前は開発中のものです。** · 2010/09/23(木) 04:55:08

タスクをいっぱい使用するようになると、どこまでユーザータスク使ってたかとか
どのタスクが抜けてたとか確認しにくくなるからね

>>937と>>940を合体しても面白いかも
上の段をタブに使用して、使用されている（ゲート作成されている）タブは色が変わるとか

**名前は開発中のものです。** · 2010/09/23(木) 08:48:12

>>946がよく分からない

**名前は開発中のものです。** · 2010/09/23(木) 13:19:32

>944
うｐ乙

**名前は開発中のものです。** · 2010/09/23(木) 14:58:24

素材提供者が現れるなんて、この業界も大きくなったものだなあ～

**名前は開発中のものです。** · 2010/09/23(木) 16:24:57

スプライと用の画像って、ビデオカード依存とあるけど
最大で、だいたいどのくらいのサイズまで良いのかって目安はないですかね。。。

**名前は開発中のものです。** · 2010/09/23(木) 16:47:23

8192*8192ぐらいの無茶なサイズで無ければ大丈夫でしょ

たぶんだけど

**名前は開発中のものです。** · 2010/09/23(木) 16:58:17

>>927
ここやニコニコに依存してない奴はいるだろ。
確か過去スレで紹介されてなかったか？

**名前は開発中のものです。** · 2010/09/23(木) 16:59:48

そら、スレに参加する義務もニコにうぷする義務もないからね

**名前は開発中のものです。** · 2010/09/23(木) 17:03:27

作品をうぷろだに挙げた順に会員番号でも付けていくか

顧問：ＳＢ氏
名誉会員（ハンドル名あり）：Ｓぷ氏、トリフィド氏、バニ氏、わんけ氏、729氏、ＮＳＳ氏など
一般会員（ハンドル名なし）：・・・

**名前は開発中のものです。** · 2010/09/23(木) 19:00:17

メモがエラーになるバグ修正されたけど既に壊れたメモを直すのは無理？

Ｓぷ ◆n3VrL7XRbc · 2010/09/23(木) 19:09:00

>>951
目安というか、2048*2048が限界。

・・・だったはず。
要検証です。

**名前は開発中のものです。** · 2010/09/23(木) 20:10:16

ビデオカードにより、最大1024ピクセルまで、2の階乗サイズのみなどの制限あり
・・・とのこと

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

ありがとう！でもせっかく大きなフィールドを手に入れたのに
試しに弾丸とかとか、アニメを作ろうとして挫折したよ(T_T)

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

>>959
せっかく弾丸素材の提供あったんだから、使ってみたら？

**名前は開発中のものです。** · 2010/09/23(木) 22:55:27

>>960
静止画ではなくて、ちょっとでもアニメーションする弾が良いなぁ～って
また間を空けて挑戦してみます^^;

あ、それまで素材借りようかな…そうしよう

**名前は開発中のものです。** · 2010/09/23(木) 23:36:36

>>948
タスク表示に限らずプルダウンで表示が出る選択項目は
選択されている状態でホイール動かした時にその選択内容が変わってしまうので
ついうっかりタスクが選択されているものと勘違いしてホイール回して
設定項目が切り替わってしまう事が度々あった。
しかも変わったこと自体に気付きにくい。

>>957
406×2973というキャラを使ってるけど問題なく動いてるよ。

**名前は開発中のものです。** · 2010/09/24(金) 01:25:55

俺も縦1200だったけど動いてた
つーか1024までっての見てびっくりした

**名前は開発中のものです。** · 2010/09/24(金) 10:53:24

ビ・デ・オ・カ・－・ド　によっては・・・なので、
もし配布が前提であれば、2の2乗サイズで1024までにしておいたほうが無難。

相手のグラフィックカードがわからないわけだから・・・

**名前は開発中のものです。** · 2010/09/24(金) 10:58:57

ビルドした後は関係ないのかな
上限1024*1024の環境でそれ以上のサイズを使ったゲームを動かしてほしい

**名前は開発中のものです。** · 2010/09/24(金) 11:31:43

普通はグラボなかったらメモリを
VRAMの代わりにするから基本的に問題はないよん
速度は著しく低下するが

1024*1024越える画像とか使ったこと無いんだけど

画像がでかいからSBの拡縮機能使って小さくします＞＜
とか、
フルHDで作ります！！
とかそんな馬鹿な理由ででかくなってるわけじゃないよな

**名前は開発中のものです。** · 2010/09/24(金) 12:59:00

グリーンインフェルノみたいなのを作ります！！
とかだったらデカくなってもしゃーないかも
まあそれもパーツ分けすれば解決だけどね

**名前は開発中のものです。** · 2010/09/24(金) 17:00:16

>>966
敵のグラフィックが多すぎていいかげん画像わけんの面倒になったから、一枚一枚をできるだけ大きい画像にしてみた

**名前は開発中のものです。** · 2010/09/24(金) 17:09:16

でかすぎて困るから分けるのに・・・

**名前は開発中のものです。** · 2010/09/24(金) 20:25:12

次スレ立てた
http://hibari.2ch.net/test/read.cgi/gamedev/1285327418/
スレタイ、ver10　でいいのか・・・

**名前は開発中のものです。** · 2010/09/24(金) 21:18:54

スレ立て乙
10でいいと思う

**名前は開発中のものです。** · 2010/09/24(金) 22:59:12

>>969
多すぎて管理しきれないより大きい方がいいよ

**名前は開発中のものです。** · 2010/09/25(土) 12:30:56

HD6000系のラデは16384x16384まで対応するんだっけ・・・

**名前は開発中のものです。** · 2010/09/25(土) 13:05:15

2048x2048オーバーの画像を適用しようとしたら
2048x2048の範囲までしか読み取れず
はみ出た部分は描画されなかった？覚えがある

**名前は開発中のものです。** · 2010/09/25(土) 13:39:59

やってみた
　スプライト編集でイメージを取り込み、4分割
　スクリプトでボタン押してパターン番号の変更をつけた自機でテストプレイ
テスト結果
　1024×1024　→　問題なく使用可能（スプライト編集およびデバッグでのテストプレイ）
　2048×2048　→　問題なく使用可能（スプライト編集およびデバッグでのテストプレイ）
テスト環境
　Windows Vista SP1
　Celeron 1.73GHz
　2.5GB
　ATI Radeon Xpress 1250

あんまり問題はないみたい
イメージ取り込みのファイル指定欄の下の「画像のプレビュー画面」をドラッグすると、
画像の全貌が見れることに、はじめて気が付いた or2

**名前は開発中のものです。** · 2010/09/25(土) 13:54:42

検証乙

2048でもグラボがそこそこならいけるんだろうけど
オンボードの人もいるだろうから1024以下で2の累乗が無難なのかな

**名前は開発中のものです。** · 2010/09/25(土) 13:57:53

975だが、、、

3072×3072では、スプライト編集で2048×2048までしかプレビューできず、
3×3で自動分割をしたところ、682×682が9個できた

おそらく、前記環境での最大読み込みサイズは「2048×2048」と思われる

個人的な要望ですまんが、2048×2048の全体像が見れるように、
プレビュー画面を、倍率変更可能にして欲しい
具体例）
　小：256×256の全体像を縮小表示（現在の縮尺）
　中：512×512の全体像を縮小表示
　大：1024×1024の全体像を縮小表示
　特大：2048×2048の全体像を縮小表示（おそらく最大サイズ）

**名前は開発中のものです。** · 2010/09/25(土) 15:02:00

スプライト編集のプレヴューは倍率変更できると思うけど・・・
＋－のボタンで

**名前は開発中のものです。** · 2010/09/25(土) 17:05:39

>>978
orz...　orz...
　orz...　orz...
　　orz...　orz...
プレビュー画面の下にある「-」と「+」ボタンは、プレビューの拡大・縮尺だったのか・・・
　押すたびに、×1/2または×2になる様子

2048×2048以上のサイズの画像は、縮小表示した際に、
2048×2048を超える部分がクリップアウトされていることを確認

**名前は開発中のものです。** · 2010/09/25(土) 17:12:49

要望をする時は十分に調べ吟味するように

**名前は開発中のものです。** · 2010/09/25(土) 19:38:53

まあ、検証してくれただけ良いじゃないの

倍率変更できたのに気が付かなかったのは、単にケアレスだし

**名前は開発中のものです。** · 2010/09/26(日) 00:12:11

そういや信号送信で変数送れるようになってるけど、あれって何の意味があるの？
単に条件分岐を親側でやるか子側でやるかの違いだけに見えるんだけど

**名前は開発中のものです。** · 2010/09/26(日) 00:18:05

たとえば親の向いてる方向と子の向いてる方向を同期させたりとか
少なくともあって困るものでは無い
”見える”だけじゃ分からない。使ってみて初めてその利便性が分かる

**名前は開発中のものです。** · 2010/09/26(日) 01:45:55

信号の便利な点：
・信号送信では加算代入ができるので、カウンタ変数で変数計算のパネルを節約できる
・システム変数を介さずに、変数の保持や受け渡しができるので、親子間やセルフでのフラグ管理がしやすい
・信号受信では受信と同時に分岐できるので、変数の条件分岐のパネルを節約できる

とにかく、フラグ管理やボタン判定の条件分岐などで、省スペースで展開できるのがシグナルの強み
変数を取り込めるようになったので、例えば武器インデックスの参照→条件分岐を親子で共有したり、
やり取りしてるシグナルの中身を変数を介して外へ出力したりできて、便利になったよ

**名前は開発中のものです。** · 2010/09/26(日) 02:16:37

勉強になります

**名前は開発中のものです。** · 2010/09/26(日) 04:24:21

送れるのが即値だけなら、条件分岐してオンオフ的なシグナルを送るのがメインになるんだろうけど、
変数を送れる様になったので、より柔軟な数字の送受信が可能になったということだろうね。

欲を言うならば、シグナルが今受信している値を取り出して送信することが変数を介さないと出来ない
ので、「即値」、「変数」に加え、「受信値」なんかも送れる様になれば、さらに万能って感じはするけど、
まあ、そこまでなくても困らないかも？というのはあるな。

**名前は開発中のものです。** · 2010/09/26(日) 07:48:41

つまり

親：変数が○○だったら信号0-1を送る
子：信号0-1を受信したら分岐

これが

親：変数○○を信号で送る
子：信号が○○だったら分岐

になってパネルが1枚だけ節約できるってことなんだな
たった1枚節約のためにわざわざ変数送信を導入する意味はあったのだろうか
親側で変数が○○かどうかをループで監視してる場合、子にループで信号を送り続けることにならないか？
その間は他の信号送れなくなるよね
それと、子側で変数で受け取って分岐するのと信号の値が○○だったら分岐するのに違いってあるの？

>>983
もちろん使ったうえで言ってるよ
親と子の向き同期は別に信号送信しなくても始めから設定出来るよね

**名前は開発中のものです。** · 2010/09/26(日) 08:19:39

>>987
パネル節約の効果は、分岐が多くなればなるほど、じわじわ効いてくるよ

他の信号は独立してるから送信できるよ
むしろシステム変数はゲーム内共有だから、複数のキャラクタで共有されてしまって、変な挙動して困っていた
信号は親子間では共有だけど、別の親子間には影響しないから、とても使い勝手が良い

逆説的だけど、親子間の向き同期フラグをあえてオフにした上で、あるタイミングになった時だけ、
親子の向きをいずれかの向き（親→子，子→親）に揃えたい時がある

**名前は開発中のものです。** · 2010/09/26(日) 08:23:26

>>986
加算値0で送信すると、受信値がそのままの値で送信されたような？

そうじゃなくて、受信値をシグナルへ代入ってこと？
だったら、ローカル変数パネルで、シグナル→変数で良いかも

**名前は開発中のものです。** · 2010/09/26(日) 10:27:01

かなり初歩的な質問で悪いんだけど、
弾が壁に当たって跳ね返るってどうすればいいの？

**986** · 2010/09/26(日) 10:37:05

>>987
＞親：変数が○○だったら信号0-1を送る
＞子：信号0-1を受信したら分岐

変数の値が1～100の範囲だったとして、変数が1ならシグナル１を送る
変数が2ならシグナルで2を送る、変数が3ならシグナル3を送る～～100なら100

シグナルで送りたい値が0か1かみたいな場合だったらそれでもいいんだろうけど、
親の持ってる変数情報を直接送れた方が、より応用性に富むよね？って話。
分岐でオンオフ的使い方ではなく、変数情報を共有する的使い方。

「システム変数は、キャラクタすべてで同じ数字を共有できる」だけど、
「シグナルは、各親子間毎で同じ数字を共有できる」←この部分がやりやすくなった
といえる。
パネルが１枚節約できるというのは、やりやすくなった部分の一つにすぎないと思う。

＞その間は他の信号送れなくなるよね
なんで？
シグナルナンバーはいくつもあるのだから、他のシグナルを使って送信すればいいんじゃないの？

**986** · 2010/09/26(日) 11:15:16

>>989
＞ローカル変数パネルで、シグナル→変数で良いかも

もちろん、今は変数が送信できるので、それで事足りる。
だけど、それをするために、変数１個を使うってどうなのよ？って意味で。

シグナルってさ、変数を使わなくても計算できるじゃない？でもその計算結果を取り出して
送信するのに変数を使うって、じゃあ初めから変数使って計算すればいいじゃんってことに
なるんだよね。

シグナルって、現在の受信値がなんであれ、送信する毎にその場で指定した「即値」だけしか
送れなかったところが、短所でもあり長所でもあったんだよね。

「変数」を送信できるようになってより柔軟性を増したと思うんだけど、「受信値」を送れるように
なれば、よりシグナルの短所を補える形になると思ったので、「受信値送信」の案を書いた。

＞加算値0で送信すると、受信値がそのままの値で送信されたような？

Ω　Ω＜な、なんだって～！？

もしそうなら、「受信値送信」はなくてもいいな。
ちょっと試してみるか。

**名前は開発中のものです。** · 2010/09/26(日) 11:31:55

>>990
ろだにサンプルがあった気がする

**986** · 2010/09/26(日) 12:09:21

＞加算値0で送信すると、受信値がそのままの値で送信されたような？

試してみた。

シグナル0に100を受信している子が、親に対してシグナル0を加算0で送信

結果：子のシグナル0受信値「100」は、親に送信されなかった。
　　　　ただ単に、「加算」での「即値0」、いわゆる「+0」が送信された。

**名前は開発中のものです。** · 2010/09/26(日) 14:03:40

自機で試してみたら、自機内のスクリプトでは、加算0で受信値がそのまま送信されていることを確認
Aボタン：送信）代入 0　→受信値に関係なく、常に0が代入される
Bボタン：送信）加算 1　→受信値に、1が加算されて代入される
Xボタン：送信）減算1　→受信値に、1が減算されて代入される
Yボタン：送信）加算 0　→受信値に、0が加算されて代入される（受信値がそのまま代入される）

親子で受け渡しすると変わるのかな？
試してみよう・・・

**986** · 2010/09/26(日) 14:38:07

＞加算0で受信値がそのまま送信されていることを確認

それは、解釈を少し取り違えてないかな？
受信値はそのままで、加算0のみが送信されているってことだと思うんだけど。

すでに受信値が入っている自スクリプト内で、加算が0されても受信値のままってのは、
ある意味当たり前。

その受信値を、他の親や子に受け渡そうと思ったら、なにかの形でその受信値を送信
してやらないといかんでしょ？

現在の受信値に何かの数値が入っているとして、親や子にその受信値そのものを
送信値として送信することは、変数を介さないとできませんよ、って話なんだけども。

**名前は開発中のものです。** · 2010/09/26(日) 14:49:33

親（自機）と子の間でやってみた
シグナル→ローカル変数→システム変数にして、デバッグウインドウで確認

親（自機）
　信号送信：子へシグナルに加算1
　→①親のシグナルを確認すると0のまま

子
　→②子のシグナルを確認すると1,2,3,4・・・と増えていく
　信号送信：子へシグナルに加算1
　→③子のシグナルを確認すると②の時のままで変わりなし

親（自機）
　→④親のシグナルを確認すると、子とは独立して1,2,3,4・・・と増えていく

**名前は開発中のものです。** · 2010/09/26(日) 14:55:22

>>986，>>996
確かに、解釈が間違っていたよう・・・

確実に言える事実：
・親と子では同じシグナルでも独立している
　「親→子」で受け取った「子のシグナル」，「子→親」で受け取った「親のシグナル」は共有されていない
・信号送信の加算は、現在のシグナルの値とは無関係
　前回送信したシグナルの値に加算される

確かに、受信値を送信することは、通常（信号パネル送受信のみでは）できない
セルフで信号を受信している場合は、受信値ではなく、前回の送信値に加算が行われているだけ
親と子では同じシグナルでも独立している（お互いにすれ違いで送りっぱなしの状態）

**名前は開発中のものです。** · 2010/09/26(日) 14:57:14

>>997で間違いあり訂正
（誤）
＞子
＞　→②子のシグナルを確認すると1,2,3,4・・・と増えていく
＞　信号送信：子へシグナルに加算1
＞　→③子のシグナルを確認すると②の時のままで変わりなし
（正）
子
　→②子のシグナルを確認すると1,2,3,4・・・と増えていく
　信号送信：親へシグナルに加算1
　→③子のシグナルを確認すると②の時のままで変わりなし

Ｓぷ ◆n3VrL7XRbc · 2010/09/26(日) 15:11:23

1000get

**１００１** · Over 1000

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。