ユーザ用ツール

サイト用ツール


2026:08:11

文書の過去の版を表示しています。


8/11日記

ゲーム開発


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

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

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

  • ということで、ボスのスクリプトは以下の単位で分割できそう。
  1. 形態と攻撃の指定(HPの条件も含める)
  2. モーション
  3. 攻撃
  • ステージ・敵・エフェクトは最初から分割済みなので、改造するとしたらボスだろうなと思った。

  • あとは自前フレームワークの改修はどっちみちしないとダメそう。
  • ちょっと書き出し。
  1. 画像とスプライトパターンの指定、キャラクター情報をScriptableObjectから読み込む形式にする
  2. 共有リソースとステージ限定リソースの読み込みを分けて行えるようにする
  3. メニュー周りを作りやすくする(メニュー項目だけ指定できるようにする等)
  4. 地面の指定を坂にもできるようにする(以前実装していたけど、作り直しのときにオミットした)
  5. 描画プライオリティと描画順をScriptableObjectもしくはスクリプトから指定する(描画順はフラグ切り替えでOKそう)
  • これができればゲームも量産しやすくなるはず。
  • 元々仕事の都合上ゲームを短時間で作りやすくするフレームワークを作りたい、という目標を建てているので、今のやつでもだいぶ楽ではあるけど、上記項目が解決できれば更に楽になるという考え。

プログラム

  • 次使うスクリプト言語どうしようかねえと悩む。
  • 用途としてはゲーム開発および音楽アプリケーション開発なんだけど、処理に時間かかるところは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のような専用設計の配列を使うことになる。
  • 別のページでは削除新規を毎度行っていくサンプルを記載していたが、新規削除にするとメモリを再確保することになり、キャッシュミスは防げるけど、メモリが似たような位置にあるか?と言われると怪しい部分ある。SOAとして扱う意味ある?とも思うし。
  • ということでシーンの開始時に確保して、削除したものも再利用していく使い方になりそう。
  • ゼロクリアすれば再利用できるし、別の配列で空き状態を管理する必要が出てくるだろう。(Unityベースでも似たようなことしてる)
  • こんな風に最適化はできそうだけど、まだノウハウがたまってないので、GDScriptで全部作り直しも視野にいれるかなー。

2026/08/11.1786472831.txt.gz · 最終更新: 2026/08/12 03:27 by machiaworx