■NSLisichka

・NSLuaのNSD系列使って弾幕STG動かしてみた→動いちゃった
・せっかくだから3Dモデル→2D画像のパターン作成試したい
　素材借りてやってみよう→やった

↑の２点について＆出来上がったものについてほんっとうにダラダラっと書いた、自分用メモの様相↓


10日くらいでスクリプトの土台はほぼ完成した
が、20日頭を唸ってもステージ道中構成を60秒以上作れなかった。
遅回しを一切セットしなかったので攻撃しないと嫌な感じに圧殺される。
「動くだけのクソゲー」という言葉について考えざるを得なかった
半年仕様を考えてちょろちょろ実装、
当初の予定以上に中途半端だがライブラリ機能は一応揃ってしまい、動作サンプルにはなっている
ので公開。


■素材
自弾と敵弾：Gimpで手描き(手打ち)
背景　　　：大昔撮っていた写真からトリミングして実写加工　前景はGimpで描いた
敵のすべて：みんな大好きメタセコイアの図形組み合わせて転写、Gimpでそれっぽく組み合わせて加工
自機（人）：↑の手法ではさすがに無理、大人しく3Dモデル(MMDモデル)を借りて転写
　　　　　　本当は各姿勢に中間(移行)モーションが一枚ずつあるとよいが、力尽きた
自機背景　：みんな大好きSekkaで描いていた魔法陣？を適当に二枚組んだらそれっぽくなり採用
効果音　　：フリー素材の加工に99%徹した

3Dモデル→2D画像(スプライト、テクスチャ)という手法は同人だとあまり見ない
　ドット絵打てる人が多いためかもしれない
商業では古くから盛んに使われている　労力の観点から言ってなかなか有用だと思う
ドット絵描けないしこの機会に真似してみようと思った


以下スクリプト面

■描画
NSDSpは表示サイズが小さければ恐ろしく軽い。
NScripterで60fpsゲーなどさすがに狂気の沙汰だと思っていたが、意外や意外
秒間60回更新(60fps)前提でも13*13ピクセルくらいの弾は何百発も出せる。
デフォでbltと同等〜それ以上の速さはありそう。

■画面更新を行う領域による？
大きな敵は表示が重く、フレームレートを維持できる弾数限界にも影響する。
背景一枚に純粋な弾描画では2000発近く出せたし

このような「スクロール背景に小さな三角形たち」でも1400発くらい出せたが、
ゲームとしての体裁を整え(STGに必要な弾の変化を一通り可能にする仕掛け)
ゲーム画面としての体裁を最低限整えた(片方透過画像の二重スクロール、それなりに大きな敵たち)ところ
せいぜい600〜800発程度が限界になった。
弾に関して必要であろう機能を何もかも備えたところ350発くらいが安全ラインかなという感じに。
PCのSTGは処理落ち度合いが読めないので60fps安定がスタンダードなやり方だけど、
ソフト側で処理落ち完璧管理する自信があるならもっと出してもいいね

■NSLuaの潜在力
　60fpsのゲームが動いてしまったので
　　アクションゲーなど、2D古典ジャンルはだいたい大丈夫そうな感じ。
　　格ゲーはメモリがどうだろう、案外大丈夫かも？
　一方、サウンドノベルやRPGじゃ一切意識しなかった効果音再生負荷が厳しい。
　　ミリ秒単位の戦いにおいては深刻な遅延となる。
　　このサンプルでフレームレート落ちる原因は半分くらい音である。
　　NSExecでdwave呼ぶ方が結局負荷としては軽い？
　　NSLua側の命令Ogg系列使うと逆に重い？(こんなゲーム作らない限りは無視してよいレベルの差)。
　　同一チャンネルの連続使用は負荷が跳ね上がる。
　　スペック不足気味のタブレットで確認。
　　再生終了から何秒も間を置かない限り、二回目以降の利用が数十倍まで重い負荷になる。
　　↑NScripterDS.dllの導入で万事解決。


■巷のSTG制作講座について思ったこと
　STG制作講座をググると計算レベルでの負荷軽減策が様々に言い伝えられている
　　現代PCゲーの負荷は本当にもうほとんど描画周りなのであまり気にする必要はない
　　点と点の当たり判定をどう計算しようが主だった負荷はそんな場所じゃなかった
　あらゆる軽量化が効果ゼロってわけではない
　　毎フレーム何十何百回＝毎秒何千回も呼ぶループに「while(グローバル変数の判定)」は露骨に重い
　　言い換えるとグローバル変数以外はあまり気にしても効果が出ない？
　　テーブルの削除を頻繁に行ったが、
　　　ループ回数を増やしてテーブル消さないようにした方が速くなる可能性はある。
　でも描画と効果音再生負荷が大半。
　参考になる情報・ならない情報は適宜見極める必要がある


■STGの土台・ライブラリとしてのこいつの実用性
弾
　機能
　　・いわゆる加減速弾やWAY弾は自在に撃てる
　　・変な軌道の弾撃つための仕掛けも一通り整えた
　　・記述の省略可能性を高めに取った
　　・なるべく少ない関数( creb(), crebc(), crebj() )に押し込める形にした
　コンパクトさ
　　・概ね生成関数に与えるパラメータ一つで済むように。弾吐き弾も数行以内に収まってくれる
　　・ソース手打ち勢のための関数と言っても過言ではない
　　・弾吐き弾の記述(1.事前にセット→2.第二性質内で番号指定)は若干汚い
　可読性
　　・やや戸惑う　弾速指定はピクセル/フレームだが、10倍単位の記述にすべきかもしれない
　　　(メモ帳の場合、"."と","は人間の目にとってややきつい　海外勢どうしてるんだろう)
　　・way/kaku/speed/ini/henka/lmtの順さえ覚えれば基本は問題ないが、
　　　省略をかなり認めたので、混じると可読性に響くかもしれない

ステージ
　・ステージ構成の記述はLuaのコルーチンに毎フレーム丸投げ
　　　十分シンプルだと思う
　　　敵を出す関数　弾を作る関数　Luaべた書きであるためあまり文法を意識する必要はないはず
　・敵のAIは本当にLuaの関数ベタ書き
　　　こちらは土台定まる前に中身肥大化すると修正めんどそう(スマートでない)
　　　敵に何か性質を持たせるような特別な仕掛けはまだパラメータ側に用意していない
　　　(地上敵と特殊当たり判定は実装済み)

視覚等
　・モニタによってはティアリングが酷い　サンプルでは誤魔化したが縦長の画像は768px族モニタだとなかなか
　　こればかりは仕方がなさそう

■ゲームパッドの入力検知
　みんなご存じ君影草工房様のgetkey.dll使用させてもらいました
　　みんなJoyToKeyあたりでどうにかしている気もする
　　360コン×非公式ドライバ以外でもスティック付いてりゃ動くかな？
　　　→PSもどきコンの十字キーでも動作確認
　　　スティック入力っつう代物は遊び値の設定や斜めを切る角度など、意外に快適な調整が難しかった
　　　みんなJoyToKeyあたりでどうにかしている気もする
　　　みんなJoyToKeyあたりでどうにかしている気もする
　　　今回は360シュー標準より僅かに滑るかな？程度に調整
　　　(同人シューの平均よりちょっと斜め入力入りやすい。
　　　　今回は大雑把に避けさせる配置なのでそのようにした)

■NSLuaをこういう無茶な使い方することについて
　無茶ではある。でも思った以上に何でも出来ちゃいそう
　敵が小さいゲームなら弾やエフェクトに多くのリソースを回せる
　　縦シュー作りたければ東方弾幕風とかBulletMLとかSTGビルダーでもいいんじゃね？(それもどうなのか)

「NScripterと一緒に走る」がNSLua最大の強みであろうことは確定的に明らかなので
　戦ってると突然本格サウンドノベルが始まるSTG(やめた方がいい)
　戦闘がSTGのダンジョンRPG(やめるべき)
　メニュー画面やオプション画面やリザルトなど、
　リアルタイムじゃない部分をNスク側で楽に作れてしまうのは十分な利点だと思う(今回はやっていないが)
　ただまあ、モニタによってはティアリングが最大の障壁。

いっそ30fps前提でよければエフェクト盛りまくりでも超余裕だが、これは2DSTG的にはやや論外
　弾が遅いゲームならどうにかいけなくもないが
　(やる側のスペックが不定なPCゲーの場合、処理落ち前提の調整は難しい。
　　60fps維持に拘る同人STGが多い理由でもある。
　　余裕もたせた上でわざとソフト処理落ちをかける、ケイブが360でやっていたような手法は
　　少なくともNSLuaにおいてはちょっと難しいと思う。)
NSDSp2は90度刻み以外だとSpの何倍も重い、可能な限り使用は避ける。
　今回のサンプルでは弾数をさほど出していない事もあり　面倒臭がって
　針弾(細長いやつね)をSp2で回転させた。
　実際にカリカリまで攻める場合、最大24方向くらい回転した状態の絵を用意しておく。
　前述の90度回転と併用すれば良いんじゃなかろーか
複数の背景を多重スクロールさせたい場合、ギリギリまでNSDBltで戦う。
　背景A/継ぎ目だけ透過/背景Bみたいな。
ただし、NSD命令を呼び出す回数の多さも負荷につながる印象。

というより

今まで一切意識していなかったティアリングが非常にきつい、すっごい目に付く
縦768ピクセルのモニタが地獄
画面更新で線走るあれ　無理やりフルスクリーンにすると軽く地獄
必死こいて(縦長の物体をなるべく避ける絵作りで)誤魔化そうとした。
でも縦768ピクセルのモニタでフルスクリーンにすると地獄