machia's diary

この文書は読取専用です。文書のソースを閲覧することは可能ですが、変更はできません。もし変更したい場合は管理者に連絡してください。
8/11日記

===== ゲーム開発 =====
  * こういうの読んだりしてスクリプト改造したほうがいいかなあとかは思ったりした。
  * https://www.famitsu.com/news/201508/28087129.html
  * https://magazine.cygames.co.jp/ja/archives/123153966/

----
  * CryPic.のスクリプトは、攻撃とモーションを同時に動かして、かつ場合によってはモーションをプレイヤー側に依存して配置する等を行っている。
  * そのため攻撃とモーションのスクリプト分割が難しく、どうしても全部を1ファイルにぶち込む必要が出てきていた。
  * また特殊な分岐（HPが低くなったら別パターンに移行）を考慮すると分岐自体が複雑な条件を持っている。
  * 実際St5の攻撃パターンは、第1・第2・第3形態でそれぞれ更新パターンが違ってきて、かつHPがしきい値を超えたら次のパターンに移行する、ということを行っている。

----
  * なんとか分岐して管理を煩雑にならないようにすべきと考える。
  * 今のところ、内部でモーション＋攻撃をワンセットとして分岐させて、これを実現している。
  * よって、少なくともモーション＋攻撃を同期させることが大前提で、次に形態によってループする必要が出てくる。
  * 勿論モーションはプレイヤー依存の配置や攻撃をする前提になる。
  * と考えると、まず分割をざっくりすると「①形態の指定（HPやその他条件）」「②モーション＋攻撃の指定」での分割は可能そう。

----
  * 今度は②について考えると、モーションはパーツごとに配置を設定している。これと攻撃の指定を同期するように作る必要がある。
  * これはこれで作りが面倒になる。モーションはいいとして、攻撃の指定についてもフレーム単位で管理してどのパーツから弾を吐く、みたいなのを別ファイルに書き出す必要がある。
  * あとモーション同士の補間が必要になってくるわけで、これをどうやって補間するのかという問題もある。
  * ただこれができれば、同じモーションで別の攻撃みたいな事もできる。
  * また、モーションを別途並べかえてフェイントかけて攻撃みたいなこともできる。そこまで必要かは置いておいて。

----
  * ということで、ボスのスクリプトは以下の単位で分割できそう。

  - 形態と攻撃の指定（HPの条件も含める）
  - モーション
  - 攻撃

  * ステージ・敵・エフェクトは最初から分割済みなので、改造するとしたらボスだろうなと思った。

----
  * あとは自前フレームワークの改修はどっちみちしないとダメそう。
  * ちょっと書き出し。

  - 画像とスプライトパターンの指定、キャラクター情報をScriptableObjectから読み込む形式にする
  - 共有リソースとステージ限定リソースの読み込みを分けて行えるようにする
  - メニュー周りを作りやすくする（メニュー項目だけ指定できるようにする等）
  - 地面の指定を坂にもできるようにする（以前実装していたけど、作り直しのときにオミットした）
  - 描画プライオリティと描画順をScriptableObjectもしくはスクリプトから指定する（描画順はフラグ切り替えでOKそう）

  * これができればゲームも量産しやすくなるはず。
  * 元々仕事の都合上ゲームを短時間で作りやすくするフレームワークを作りたい、という目標を建てているので、今のやつでもだいぶ楽ではあるけど、上記項目が解決できれば更に楽になるという考え。

===== プログラム =====
  * 次使うスクリプト言語どうしようかねえと悩む。

  - MiniScript2\\ https://github.com/JoeStrout/miniscript2
  - Quirrel\\ https://github.com/GaijinEntertainment/quirrel
  - umka\\ https://github.com/vtereshkov/umka-lang
  - PocketLang\\ https://github.com/ThakeeNathees/pocketlang
  - PocketPy\\ https://github.com/pocketpy/pocketpy
  - Lua\\ https://www.lua.org/

  * 用途としてはゲーム開発および音楽アプリケーション開発なんだけど、処理に時間かかるところはC++で書いて、そうじゃない部分はスクリプト言語で書くようにしていきたい。
  * MiniScriptは正直使い慣れてる言語ではある。2の正式リリースももうすぐの模様。2になって全体的な速度の向上、コンパイル後の言語を読み込み可能になっているため、今より速度が上がるのは間違いない状態。
  * Quirrelは元はSquirrelというLuaからの派生言語（LuaをもうちょっとC言語寄りにしたやつ）。元々LuaではなくSquirrelをちょくちょく使っていたこともあり、こっちを使いたい気持ちもある。過去にはWiiのFFシリーズにつかわれてたっぽいね。
  * umkaは（リアルタイムではないにせよ）レイトレーシングにも使えるくらい処理速度が早いスクリプト言語。あとゲーム用のライブラリもあるので、これ使ってゲーム開発が可能。
  * PocketLangは今ほとんど更新されてないけど、メモリ観点での最適化が行われている言語なので、こっち使うのもひとつかなーと思ったりする。言語もクセがないし。
  * PocketPyはPython3.xの仕様が1個のヘッダーにまとまったもの。アプリに組み込むなら公式よりこっちがいいとのこと。
  * Luaはおなじみの組み込み言語。ただ正直バインダを書くのが辛いのです。

----
  * あとはGodotEngineで使われているGDScript。
  * Godotを使うのを前提にするため、高速化の手法が他と違う可能性があるし、ベース部分からして実装しなきゃいけないので最適化の範囲も違う。

----
  * これはどちらかというとベース部分の実装の最適化ではあるけど。
  * スクリプトがPythonに似ているのもあるためか、配列へのアクセスが遅い（インデックス化を頻繁に行うせい）よう。弾幕STG作るのにあまりよろしくない。
  * そのためにPackedVector2Arrayのような専用設計の配列を使うことになる。
  * https://docs.godotengine.org/ja/4.x/classes/class_packedvector2array.html
  * 別のページでは削除新規を毎度行っていくサンプルを記載していたが、新規削除にするとメモリを再確保することになり、キャッシュミスは防げるけど、メモリが似たような位置にあるか？と言われると怪しい部分ある。SOAとして扱う意味ある？とも思うし。
  * ということでシーンの開始時に確保して、削除したものも再利用していく使い方になりそう。
  * ゼロクリアすれば再利用できるし、別の配列で空き状態を管理する必要が出てくるだろう。（Unityベースでも似たようなことしてる）
  * こんな風に最適化はできそうだけど、まだノウハウがたまってないので、GDScriptで全部作り直しも視野にいれるかなー。
  * ちなみに細かいところだけど、GDScriptはホットリロードもやりやすく、デバッグ中に更新しても動きが反映される。だいぶ楽。

----
  * ほう。SIMD使う実例ねえ。なんか珍しいと言うか。
  * https://dev.classmethod.jp/articles/cpp-simd-audio-gain-benchmark/
  * 正直SIMDまわりはあまり実例ないし助かる。