BarrageLL の目指すべき場所とか

ひきこもりにっき。@はてだら

からご意見を頂きました。ありがたい事です。
とりあえず前回の記事ではいろいろと足りない点が多かったので、頂いた意見にコメントする形で補足してみようと思います。

スクリプトフォーマットはコア部分にするとのことだけど、そこに弾幕風との互換性由来な専用書式を混ぜ込むのはよろしくないと思う

弾幕風との互換性由来というよりは、スクリプトにメタ情報を持たせたい、という需要あってのことです。
これは前回の日記にきちんと書かなかった僕の落ち度ですね。
例えば、弾幕シミュレータとして使う場合、フォルダ内のスクリプトをリストアップしたい要求というのが存在します。
その場合にメタ情報がないと、フォルダ内の全ファイルを一度 Lua スクリプトとして実行して云々、という、非常に無駄な処理が発生していますので。
無論、弾幕風のような形式のシミュレータでない場合は、メタ情報が不要な場合もあるでしょう。
しかし「各処理系毎に仕組みを用意する」というのは嫌です。
なので、コア部分の仕様で指針くらいは示してもいいのでは、と思う次第。
今のところのアイデアとしては、Luaスクリプトとしてそのまま実行出来るよう、特殊形式のコメントで書く感じですね。

# 冒頭が#で始まる場合はその行を無視する(スクリプト行)
--#script-type: BarrageLL
--#title: '○符「スペルカード名」'
--#description: 'スペルカードの概要をここに記述'

-- スクリプト本体( --# で始まらない行が有った場合、それ以降は解析しない)

こんな感じ、と。構文はもっと良いものがあるかもしれないので、いろいろ調べようと思います。
本来ならば Lua 自体の機能として、このようなメタ情報をスクリプト内に埋め込めるのが一番なのですが。

抽象化し過ぎて可搬性が下がるというのはどういう状況だろう?

抽象化しすぎると、具体的にスクリプトを書くとき、コア部分だけで完結したスクリプトを書けなくなる、ということです。
そもそもコア部分だけで完結している必要はないのですが、それだったら、いちいちコア部分と処理系部分で仕様を分ける必要はないなぁ、という感じ。
そもそもコア部分と処理系部分という二つの部分に分割している事自体、かなり無駄なことなので。

というか、まず確認しておきたいこととして、「このプロジェクトは何を目指すのか」ということ。つまり、処理系あるいはゲームエンジンを作るのが目的なのか、言語を作るのが目的なのかということ。ゲームエンジンの方だとは思うんだけど、言語レベルでのあれこれが書かれている割に処理系全体の見通しがわかりにくい。

目指すべきところは、良くも悪くも、弾幕Lua で記述出来るようにする、ということです。
処理系を作るのは目的の一つではありますが、本質はあくまで「言語を作りたい」ですね。
例え仕様を決めたところで、そのままでは絵に描いた餅なので、仕方なくエンジンも作る、といった感じでしょうか。

僕の方の意見はというと、MOD上等にするのであれば、その気になって弄るなら”Luaだけ使って”ほとんどのことが出来る方がいい。つまり気合があれば花映塚だろうが文花帖だろうが出来るのが理想。

MOD は上等ですが、そこは BarrageLL 自体とは関係ない部分の方がいいと思います。
とりあえず、花映塚文花帖弾幕は普通に記述できるように作る予定です(実際、それらはシステムが特異なだけで、弾幕自体は普通ですし)。

弾幕風だとタイトルメニューの見た目なんかも弄れないし、シーン遷移も出来ない。完成品のゲームを作るためのエンジン、という位置づけにする場合はUI変更とシーン遷移は出来ないまずいと思う。

UI変更やシーン遷移は指定出来て当然ですが、そこを BarrageLL に含めるべきかは、疑問です。
そこは弾幕とは関係ない部分ですから、別の仕組みを用意する方が良いのではないか。
ただ、スクリプトの連続再生はどうするか、といった境界部分もあるので、一概には決めがたいですね。
それから、少なくとも、完成品のゲームを作るためのエンジン、という位置づけにはしません。
あくまでも BarrageLL は「弾幕を記述する」という目的に使われる感じであり、
それ以外の部分は、完成品のゲームを作る人が頑張って作るべきかと。


とまぁ、こんな感じです。
全体的に、僕の記述不足が原因で、いろいろ誤解を招いている状況でしょうか。
どうも考えをアウトプットするのは苦手ですが、頑張っていかないと。
とりあえずサンプルスクリプトを書いたら、その辺を纏める作業に移りたいですね。