1 :
名前は開発中のものです。:
ゲームプログラマなら誰もが通る、もしくは、通った道。青春の香り?
それは「シューティングゲーム製作」・・・。
このスレでは、そんなシューティングゲームの製作技術や技術の検証、成功談
失敗談笑い話、難易度の設定方法論、多弾の是非などについて語り合いましょう。
もちろんBulletMLなどで弾幕を作成してみたり、自分の作ったシューティングを
晒してみたり、プロジェクトをはじめてみるなどもOK!
ただし、シューティングの未来とか既存のゲームの話題などは、関連する他の
スレでやってくれ。
過去スレ,関連スレは
>>2-3で。
昔のスレからリンク集引っ張ってきてリンク切れ等も修正しといたぞ
なんかナウい情報あったらぽまいら張れよな
>>1おつ
aBOM(あぼ〜ん)消えたと思ってたので地味に嬉しかった
>>1乙
全方位シューティングは、敵配置に
あまり気を配らなくてもいい(個人の感想)から
小物としては適しているんじゃないかな
と思っている
4年ぶりの新スレか・・・胸が熱くなるな
基本的に話題のループと話題の否定ぐらいしかする事が無いからな
スクリプト否定する人って、基本的に技術力の無い人が多いよね?
ステージの配置と敵の動作と弾の動作をスクリプト化するだけでも、
ずいぶんと色々こだわった処理が作れるようにならね?
まあ、ステージの配置や敵の動作、弾の動作にこだわらない人には
どうでも良い事かもしれんが。
つーか修正作業が楽になるってだけでしょ。
未完成品が完成品になるぐらいに楽にはなるな
それは言いすぎ
ゲームバランスの調整するのは楽になるでしょ。
スクリプト化って技術力うんぬんを言うほどの技術じゃないだろw
みんなはどんなスクリプト使ってるの?俺のは劣化C言語。
使えるループはWhileのみ。ifはあるけどelseはない。
+=や-=はあるけど++や--は無い。使える変数は整数型のみ。
といった具合。
ただ、いくつもの関数を並列に実行させられるように作ってあるからか、
かわりになるようなスクリプトが見あたらない。オブジェクトが複数あったら、
それぞれがスタックとプログラムカウンタを持ってるだけなんだけどね。
で、Pause命令が呼び出されたらスクリプトの動作を元の言語に戻していて、
次に呼び出された時はPause命令の次の所からスクリプトの動作を再開してるわけ。
え?PythonやRubyを使うって話じゃないの?
プログラマーなら簡単なスクリプトくらい、自前で組めるようになれ!
っつ〜か、最近のゲームになればなるほどスクリプト無しでは作れないほどに規模が膨らんでいるからな〜
既存の汎用スクリプト言語があるのに車輪の再開発する意味が分からん
手段の目的化だろ
23 :
名前は開発中のものです。:2013/02/24(日) 20:40:27.73 ID:dkN/Sn8s
スクリプト言語自体を作るのなんて時間の無駄
それならゲーム調整なり作り込みに時間を使えと
1人で作るならスクリプト必要ないしな〜
プランナーが配置なり調整するってなら、スクリプト必要だが
趣味だと基本ぼっち開発だからロジックをプログラムの外に追い払う
積極的な理由ってそうそうないんだよね。データ(プロパティ)を外に
追い払うのと同じ感覚でロジックまで追い払うのは変態趣味の類かと
強力な開発用PCによる高速なビルド、それにエディットコンティニュー。
こういう快適な開発環境があると「スクリプト化すれば調整作業が楽になる」
というのも無理があるし
>>23 調整や作り込みに時間を割くなら、なおさらスクリプト言語を作った方が早いと思うけどな
時間のかかるゲーム製作で作業を単純化するのは明らかな作業効率の向上が期待できるからな
>>21 既存の汎用スクリプトには欲しい機能が無いから自分用の汎用スクリプトを作った。
自分の場合は楽に作れるようになったから他人も楽に作れるようになるはずだと考えるのはごく自然な流れだと思うが?
>>24 ロジックを分断する事で余計な事まで考える要素を無くせるのは
大きな違いだと思うが?そりゃ、自分の作ったコードを隅々まで
覚えておけるような奇特なスキルを持ってるなら必要ないかもしれないが、
生憎とそんなレアスキルを持ってる人間ばかりじゃないからね。
スクリプトの有難味を否定している奴は、
大してビルド時間のかからない小規模な作品か、
もしくは当たり判定がレガシーで、素材作成奴隷から搾取して見た目だけ目新しくした金太郎あめゲー
しか想定していないんだろうな。
見た目大事だよ
見た目の有難みを否定している奴は(ry
見た目だけで作ってると信者が付かないよ
延々と焼き畑農業をやってるような物だからね
>>26 機能分割や結合度の制御の話なら、プログラムから追い払って別の言語で
記述しなくても出来ることではないかと
>>27 否定される場合の条件が書かれてるのだから、全否定されてるわけではないし
そんなふうに毒づくようなことでもないのではないかと
ビルド時間云々については、少なくともPCゲーの場合については
例えばVC++ではデバッグ実行中に一時停止してコード修正して
継続実行できるので、スクリプトとして外部に追い払う積極的な
動機付けにはなってないんじゃないかな
吉里吉里みたいにプログラムが書けない人向けに作るなら分かるんだけどな
>機能分割や結合度の制御の話なら、プログラムから追い払って別の言語で
>記述しなくても出来ることではないかと
そんな便利な方法がスクリプトを使う以外にあるなら教えて欲しいな
例えばマルチスレッドは、同期の問題やらメモリーの問題やらがあるから扱いに手間がかかりすぎる
後、スクリプトの保守性の容易さもスクリプトを用いる要因として挙げておく
バイナリーデータで作業するよりテキストデータで作業する方が楽なんだよ
他には、プログラムは上から下に読める方が楽というのもあるな
やり方は一つじゃない
個々の事情に合わせたやり方でやればいいだけ
アーケード進出した某同人シューティングゲームでは
敵や地形の動作が全部C++のベタ書きで組んであった。
ステージ中のギミックが細かいから、スクリプト化するメリットが
薄いと判断し、この方針にしたらしい。
スクリプト言語が必要かどうかはその都度考えればいい。
俺も個々の判断が正しいと思うわ。
どっちにしろ押し付けるのはいいとは思わない。
そして完成させた奴が一番正しい。
>アーケード進出した某同人シューティングゲーム
動画見たよ
かっこいいなコレ
クソッ、やられてるぜ
>>33 >そんな便利な方法がスクリプトを使う以外にあるなら教えて欲しいな
便利な方法というか、機能分割やら結合度やらは構造化設計の基本だし
これは別にスクリプトでなければ出来ないというような話ではないかと
>例えばマルチスレッドは、同期の問題やらメモリーの問題やらがあるから扱いに手間がかかりすぎる
どういう使い方をしてるのか知らないけど、ターゲットハードウェアが
そこらのPCであればSMPの素直なスカラー機だから並列プログラミングに
ついての先人の知見は豊富だし各種ライブラリもあるわけで
で、スレ趣旨に従って無難に2DSTG前提とすれば計算リソースについては
別に厳しい要求にはならないわけで、並列処理の粒度が粗い、オーソドックスな
マルチスレッドプログラミングで問題ないわけで。例えば
・ファイルI/O
・サウンド
・グラフィックス
・OSとのメッセージ処理
・ゲームのシミュレーション部
のような分割単位で。シミュレーション部なんかシングルスレッド処理でも
別に問題はないと思うよ?
>後、スクリプトの保守性の容易さもスクリプトを用いる要因として挙げておく
>バイナリーデータで作業するよりテキストデータで作業する方が楽なんだよ
>
>他には、プログラムは上から下に読める方が楽というのもあるな
C/C++のソースコードはテキストだよ
スクリプト言語の類を用意することで最も利得を得るのは組織が大きくなる
場合だと思うんだよね。能力が異なる人間(非プログラマ)のために異なるロールを
用意する。開発プロセスの分割統治の都合で採り入れられる場合が多いと思うよ
吉里吉里とかツクールはプログラマ不在の開発環境でゲームを作れるよね?
こういう採用方法に比べればプログラマのぼっち開発ではどうしても利得は
減ると思うよ
うん。だからプログラマーが1人で作るならスクリプトいらないと思うよ
42 :
名前は開発中のものです。:2013/02/25(月) 23:53:40.29 ID:w9I6p7eL
>>41 ああ、そうか
そもそもアルゴリズム組むのに
「自分の作ったコードを隅々まで覚えておけるような奇特なスキル」
こんなスキル全く必要ないもんね
定数はスクリプトでもプログラム言語でも直書きなんてしないし、
座標系なんかにも依存した書き方しない
スクリプトはアルゴリズムを自分以外の人間が組む場合のみ必要かな
それ以外はデメリットの方が多い
スクリプト自体を作る勉強だったり、悦にはいるなら止めはしないけどね
>>42 >「自分の作ったコードを隅々まで覚えておけるような奇特なスキル」
>こんなスキル全く必要ないもんね
そうなんだよね。
>>26の人のその部分の主張は意味わからずスルーしてたけど
OOで言うところのオープンクローズドとか依存関係逆転とかの原則をわざと
無視しない限りそんなスキルは要求されないと思うよ
スクリプト(脚本)にも複雑なものから単純なものまで色々あるよな。
「アクタの舞台上での動きをコーディングする」ってのが、そもそもの「脚本」の発想だよな。
>>31 >VC++ではデバッグ実行中に一時停止してコード修正して継続実行できる
どういう開発スタイルか、今一つ理解できないんだが、
アクタの行動タイミングってのは、レベルデザインでは非常に重要な要素だと思うんだが、
行動タイミングをいじったら、その局面を最初からテストプレイしないと、
つまり実行し直さないと、
行動タイミングが最適化されているかどうかを確認できないんじゃないか?
>>38 並列処理の必要な敵や敵弾の動作、マップ上でのオブジェクトの配置でスクリプト使ってるんだけど、
これをマルチスレッドでやろうとしたら大変な作業になった事がね。
スレッドの処理は基本的に頻繁に強制停止&強制終了出来ないし、
同期で手を抜いたら同じ変数に複数の処理が同時にアクセスしただけでアウトだったし、
あんまり良い記憶は無いな。
>>38 CやC++は関数型言語だからな
必ず上から下の順番で処理されるわけじゃないだろ
いわゆる継続が分かってないんだな
>>46 言いたい事はなんとなくESPで分かるけど、C/C++は手続き型だと思うよ・・・
うむ。
C/C++は思いっきり後方参照できない言語だ。
>>44 あ、ごめん。誤解されてそうなので補足すると
継続実行云々の話は、スクリプト使わないとビルド時間ガーに対して、一例として
エディットコンティニュー機能とかあるんだよー(ドヤァ って説明しても、それが
何なのか分かってもらえなかったので、その機能を噛み砕いて説明しなおしたんだ
ゲームワールド内の時間を巻き戻す仕組みとはまた別の話だよ。指定した時間に
戻れる仕組みがなければそれは不便だと思うよ。もちろんそれは同意だよ。
で、大抵はゲーム途中のスナップショットを取ってたりユーザー入力みたいな
外乱要素を記録しとくよね。
ステージ開始点でもスナップショットを撮った時点でも何でも構わないけど
初期値が揃ってる時点を選んできて、そこをシミュレーション開始点にして
記録しといたユーザー入力情報使って数値積分していけば、その後の任意の
時間のゲームワールド状態を再構築できるよね。もちろん修正内容次第では
コケるから多少の工夫は必要だけど
シミュレーション部のみ全速力で計算し直すから時間ステップ数が多少増えても
計算リソースを余らしてる軽いゲームなら瞬きしてる間に計算は終わるよ
>>45 そうなんだ
というか、そういう微細な粒度の並列化っていうのは計算リソースをギリギリまで
使い倒さなきゃならないような過酷な要求がなければ基本避けると思うんだけど
もし仮にそんな追い詰められてる状況なら、細粒度タスクを高効率で計算リソースに
充填できることをウリにしてる既成のフレームワークを採り入れる選択肢だって
あると思うんだよね
個人的には、必要がなければこういうのはやらないに越したことないと思ってるよ
>>51 マルチタスクをいかにして実現するか?に話が移ってきたな
自分の場合は、始めは関数ポインタを使って実装していた
が、これだと上から下に処理が読めないし、ループを実装する度に構造体に変数を追加しなきゃいけないし、
条件分岐を入れると分かりにくくなるし、関数名は考えなきゃいけないし
で非常に面倒だったんだよな
デバッグの度にどの関数に跳ぶかも変わるからエラーの原因を突き止めるのも一苦労だったし
で、色々やってみてスクリプトに移った。
たぶん
>>17の中の人であってるのかな?
なんか「コルーチンって便利だよね」というような話だと思うんだけど違うのかな?
フレームを跨ぐ一連の手続きを(適当な所でyield文で区切りながら)ズラズラ
書ければ便利だよねーって話については同感だよ
コルーチンって言うんだ。なるほど。
本に載ってなかったからなぁ……
コルーチン、ファイバー、グリーンスレッド、タスクシステム
呼び方はいろいろだけど最近のスクリプト言語ならだいたい入ってる機能だな
異物を後挿する性的嗜好
C#でも簡単にできるよね > コルーチン
でも実はあまり使わなかったりする
C#のコルーチンって、リセットする方法がよく分からん
普通に未実装
仮想マシンを初期化出来ないとゲームでは扱いづらいな、コルーチンって
まあ、大概のスクリプトでは初期化出来るけどな
つまり車輪の再開発するぐらいなら既存のスクリプトをつかえと?
いいじゃん別に、使い慣れたツールを好きに使えば。
こうして似たようなツールが増殖するわけだ
公開されてないスクリプトとか含めると、どのくらいあるんだろうな〜
気にすることか?
どんな記述で書いてるかが気になるんだよな
Schemeみたいなので描いてる人とかいるかもしれないじゃん
とはいえ、PythonとかRuby、Lua、Squirrelすら、実は使った事は無いわけだが……
何がオススメなんだろ?
ハックシッ、ヘーックシッ(花粉症)
PAUSEを切って、ブラーを切って、パーティクルを控えめにして遊びながら弄ってるだけなんだけど
Haxeのコードって読みやすいなぁ。ActionScriptの書き方はもうすっかり忘れちゃってたけど
すぐに馴染めたよ。で、STGLに馴染むほうに手間取ってる有様
Notifyのあたりがよくわからんかった・・・
リプレイずれ直らなくてモチベだだ下がり・・・
@キー入力を保存・再生できてるつもりが凡ミスしてて実はできてなかった
AΔt可変なのに保存・再生してなかった(してたつもりが凡ミスで実は)
B乱数生成器のseed値を設定してなかった(してたつもりが凡ミスで実は)
C中性子線量の異常に伴うソフトエラーと意欲の減退
地上物との衝突判定なんだけど
スターフォースはチップ単位で判定してるのは何となくわかる
だけどゼビウスのようにランダムに配置している場合はどうすればいい?
アケ版ゼビウスの地形、あー見えて8x8ドットのタイル(マップチップ)を
格子状に並べてるんだよね
でも今様のハードウェアならタイルもBGもOBJもへったくれもないんだし
計算資源も使い切れないほど潤沢に用意されてるんだし、好きなようにやれよ
機械語プログラミングだから、
「クラス」ってのは適切な表現じゃないかもな。
>>78 俺75だけど、地上物の実装については
>>76が的確。
>>75は勘違いレスだごめんよ
「ゼビウスのランダム要素って飛翔体以外にあったのか。俺おつむボケてきたか」
↓
「地形や地上敵の出現位置やパスを動的生成する改造・亜種・移植版が存在したのか」
↓
「当時で地形生成してたのならなかなかすごいな。可能なのか?ゼビウスの地形は
あー見えてタイルの組み合わせだから、やろうと思えばできなくはなかったのか?」
↓
「今ならパーピクセルでもどうとでもなりそうだし、どんな実装でもありだわな」
てなわけで、未知なる地形生成ゼビウス亜種のほうに興味が向いてたんだ
で、だんだん思い出してきたんだけど、スパセビの何面か忘れたけど中盤あたりで
地上敵の配置が変化してたような朧げな記憶が蘇ってきた。あれのことだったのか > ランダム
スパセビ→スパゼビ
オリジナルのゼビウスは地上物の配置も動きも一定だね
つまりスクロール位置で地上物の出現を決めてるわけですよね
出現位置になったら配列にセットして出現
クラスというのはC言語のクラスのことだろうか
>>82 ゼビウスの地上物は空中物と同じく、スプライト(オブジェクト)だろう、というのが
>>76の言ってる事。俺(
>>75)もこの回答が的確だと思う
クラスはスプライトに置き換えて読めばいいんじゃね。細かい事は横に置いといてさ
つまり普通の敵をスクロールに同期して下に移動させるだけだよねこれ
変なのが住み着いてるな
クラスでもオブジェクトでもスプライトでも、そういう言葉に縛られててゲーム作れるのかねぇ
そりゃコーダーレベルでは必要な知識だろうけどさ。
ぐへぇ
早よ逃げ
89 :
名前は開発中のものです。:2013/07/28(日) NY:AN:NY.AN ID:IwCHNRAy!
インベーダーの弾の発射に付いての質問なのですが、配列と配列リストどっちを使えばいいでしょうか?
将来、自機の性能が上がって弾が一度に3発ぐらい発射出来るようになったり、弾に属性(鉛、鉄)を付けたりしたいと思います。
また、方向弾もやりたいな〜と思っているので各弾が独立したオブジェクトになって扱われると思います。
配列リストの方が色々柔軟?な気がするのですが。
ならリストでいいじゃないのさ
インベーダー程度なら、わりと真面目にどっちでもいいんだよね
91 :
名前は開発中のものです。:2013/07/29(月) NY:AN:NY.AN ID:2MIOnVLd!
分かりました。リストにしたいと思います。
92 :
名前は開発中のものです。:2014/03/01(土) 01:37:14.24 ID:/1bQVuAb
寺尾純二
X68はゲーム機みたいなもんだからなぁ
95 :
名前は開発中のものです。:2014/05/22(木) 22:17:12.75 ID:atWzWVTj
今更BulletMLを使い出したんだがaccelタグ辺りが
うまく動いてくれなくて困ってる
つか位置情報とかもBulletML側で管理/計算してくれると
もっと使いやすくなると思うんだがなんでこうなったんだろう
libbulletml使ってるん?
あれはゲーム内の弾クラスとの橋渡ししかしなかったはずだし
管理したければ弾クラス側で位置持っておいて然るべきだと思う
97 :
名前は開発中のものです。:2014/06/11(水) 02:56:28.45 ID:sQFlfZJ8