どうも、いらにかです。
夏もそろそろ佳境ですね。
https://twitter.com/ira2ca/status/1562328627584593920?s=20&t=VUfhWtuojqp8dNnp3qF9yQ
さて、今日は以前から作っているシナリオ軽量記述言語『MeS』の進捗報告を兼ねて、MeSのアレコレを雑多に書こうかなと思ってこの記事を書き始めました。
MeSって何なのって人は過去記事を先に読むことをオススメします。
■過去記事
【近況報告】シナリオ軽量記述言語のMeSを作っています
■MeSのプロジェクトページ
https://github.com/iranika/MeS
■MeSの仕様とかまとめているドキュメント
https://docs.google.com/document/d/12EHzhasXu9RgVpwRYsbSNeKxrcPz_hFJHPN8WPXpfKo/edit?usp=sharing
MeSの進捗(Ver0.3)
MeSは現在Ver0.3のリリースに向けて作業中です。
MeSは現状、『言語仕様』『パーサー実装』『エコシステム』の３セクションにまたがってそれぞれ開発が進められています。
『言語仕様』はver0.3の仕様が策定されました。
https://docs.google.com/document/d/12EHzhasXu9RgVpwRYsbSNeKxrcPz_hFJHPN8WPXpfKo/edit?usp=sharing
ver0.3では新たなデコレーターとして『字幕用タイミング情報』が追加されました。
これは、将来的にVTTなどの字幕ファイルをMeSから生成することを主な目的としています。
『パーサー実装』は言語仕様ver0.3を元に現在開発を進めている段階です。
主要な機能はほぼ実装済みで、あとはVTT形式のテキスト出力などの実装が残っているくらいです。
そして、Ver0.3リリースの最後の壁が『エコシステム』です。
このエコシステムにはMeS EditorやMeS CLIが含まれます。
一般のユーザーはエコシステムを通じてMeSの恩恵を受けることが大半です。
言語仕様とパーサーが機能豊富になっても、MeS Editorがその機能をユーザに提供しなければ恩恵が受けられません。
しかし、MeS Editorをリッチに作り込むことにはリスクがあります。
というのも、常日頃からシナリオを書いている人は「好みのテキストエディタ」が既にあるはずです。
MeSは将来的にVisual Studio CodeとGoogle docsを推奨エディタに位置付けて、その他のエディタでも恩恵が受けられる環境整備をする予定があります。
MeS Editorは元々「MeS記法を試し書きする遊び場」として開発しているので、MeS Editorで本格的に０からシナリオを書く体験は今のところ注力していません。
仮にMeS Editorをリッチに作り込んでも「あのエディタならこれができるんだけど…」といった不満が必ず出始めます。
私がまさしくそうだったので。
そのため、MeS Editorはメインテキストエディタではなく、サブテキストエディタもしくはMeS用の便利な変換ツールアプリとして発展することを目標にしています。
MeS EditorはパーサーがVTT出力できるようになれば、既存の機能を整理してアップデートする予定です。
そもそも、キャラ毎のセリフ文字数集計とかできるのにユーザに機能提供してなかったりするので
ver0.3がリリースされる頃には、Meditorの機能は整理されて少し使いやすくなっていると思います。たぶん。
今のMeSが抱えている課題
そもそも、エコシステムの開発が少し遅れているのは理由があります。
というのは、MeS Watcherというデスクトップアプリの検証開発も同時にしているからです。
もともとエコシステムはWebアプリ(MeS Editor)、コマンドラインツール(MeS CLI)、デスクトップアプリ(MeS Viewer→MeS Watcherに変更)の３つを試作としてつくる計画がありました。
Webアプリは、インストールしなくてもユーザーがさくっと使い始められるので、MeSの入門とカジュアルな利用として。
コマンドラインツールは、MeSが解析したデータをより柔軟に加工したりするための上級者向けとして。
優先度が高かったこの２つは真っ先に開発されました。
で、このMeS Watcherってなんなのか。
簡単にいえば、メモ帳(または他のエディタ)で編集しているテキストファイルが保存されるたびにMeS Watcherアプリの台本ビューが自動で更新されていくやつです。
※台本ビューはMeS Editorに表示される台本っぽいアレです。
Webアプリ開発では、ファイルが変更されるとすぐにそれを反映する『ホットリロード』と呼ばれる機能があったります。
MeS Watcherはテキストファイルを指定すると、ホットリロードによってテキストファイルが更新されたときに自動で再度読み込みます。
これにより、我々はエディタ選択の自由を獲得する機会が手に入るのです！
この課題がようやくクリアできそうなフェーズに入ってきました。長かったぜ。
ただRustで書かれたMeSパーサーの性能を十分に発揮するためにMeS Watcherの開発はTauriというRust製の新しいフレームワークを採用しています。
英語しかないドキュメントを読みながら開発してるので苦しみまくっている……
でもTauriのアーキテクチャはすごく賢いというか、触っていて楽しいです。
この力を習得したとき、また新たなフォースの力に目覚めそうです。
雑記：MeSのハックしやすさ
話が変わって、「MeSってハックしやすいよなぁ」とふと思った雑記です。
MeSはフォーマット（記述形式）の強制力が弱いことが特徴の一つでもあります。
MeSには構文エラーがあまり存在しません。
以下のMeSを例にしてみましょう。
橘は勢いよく立ち上がると机を叩いた
橘「いい加減にしてください！いま優先すべきなのは議論よりも救命指示と統制でしょう！」
周囲は静まり返る
橘「石井さんは消防に連絡してミブチ周辺の被害状況を確認してもらって！課長は地図とってきてホワイトボードに被害マップつくる準備！」
村長「ちょっとーー」
橘「村長は災害対策本部の設置にむけて県と協議！被害状況は村でも収集中って伝えて、今後の体制の話し合いをしてください！」
橘「手が空いてる人は災害時避難先の手伝いに回りつつ被害情報の聞き込み！」
橘が手をたたくと全員動き出した
これは一般的なト書きとセリフのシナリオですが、MeSはこれらのpieceを下記のデータとして解析します。
※一部のデータは...として省略しています
[
{
"dialogue": "橘は勢いよく立ち上がると机を叩いた",
"charactor": "",
...
},
{
"dialogue": "いい加減にしてください！いま優先すべきなのは議論よりも救命指示と統制でしょう！",
"charactor": "橘",
...
},
{
"dialogue": "周囲は静まり返る",
"charactor": "",
...
},
{
"dialogue": "石井さんは消防に連絡してミブチ周辺の被害状況を確認してもらって！課長は地図とってきてホワイトボードに被害マップつくる準備！",
"charactor": "橘",
...
},
{
"dialogue": "ちょっとーー",
"charactor": "村長",
...
},
{
"dialogue": "村長は災害対策本部の設置にむけて県と協議！被害状況は村でも収集中って伝えて、今後の体制の話し合いをしてください！",
"charactor": "橘",
...
},
{
"dialogue": "手が空いてる人は災害時避難先の手伝いに回りつつ被害情報の聞き込み！",
"charactor": "橘",
...
},
{
"dialogue": "橘が手をたたくと全員動き出した",
"charactor": "",
...
}
]
上記の例では、ト書きの部分にはキャラクター情報が付与されていないので""(空白)になっています。
台本ビューでみるとこんな感じ。
これを利用して「キャラクター情報が空白なら、セリフ情報(dialogue)をコメント(comment)に移動させる処理」を行えば、一般的なト書き記法をパースして得られた出力を模範的なMedo形式に修正することが可能です。
逆にエディタや台本ビューを「キャラクター情報が空白なら、ト書きとして扱う」みたいな仕様にしてもいいと思います。
（だって、キャラクターが空白なら他の意味と捉えてもいいでしょ…的な発想）
他にも登場キャラクターがそもそも一人なら「キャラクター情報が空白なら、〇〇に置き換える」みたいにデフォルトキャラクター設定とかも便利です。
（これは今後のMeSパーサーの設定仕様に組み込まれる予定があります）
MeSは「簡素な記述」と「詳細な記述」のどちらもサポートするために、「記述に必須な情報」というものが極端に言えば存在しません。
ある手段を用いればセリフを空白にすることも可能です。
基本的な利用方法がありながら、ハックしやすいところが個人的にMeSのいいところだと思っています。
雑記：MeSから派生して字幕プレイヤーの開発
MeSのVer0.3が字幕サポートを目標にした理由の一つに字幕プレイヤー（Webアプリ）の開発案があります。
（MeSエディタの整理も終わってないのに次々と新しいアイデアに手を出していることは正直褒められたものではないですが）
話が少し逸れますが、私は著作権法や海外の違法アップロードサイトの仕組みとDMCA関連に少しだけ詳しいので相談を稀にもらうのですが、違法アップロードサイトの中には閲覧アプリとして機能が優秀なやつも存在したりします。
特に字幕です。
違法アップロードサイトは法的に許されない存在ですが、一部のユーザーが違法サイト利用に依存する理由のひとつに「正規では得られない機能的メリット」があると考えています。中でも字幕は海外ユーザーにとって結構な依存理由だと思います。
※もちろん、違法サイトの利用を擁護する意図はありません。
「違法サイトをなぜ使ってしまうのか」という心理を紐解き、ユーザを違法サイトから引き離して更生する環境づくりや、そこから得られる予防策を考えることも違法サイト撲滅のひとつだと個人的には考えています。
（倫理観が少しずれている自覚があるので、この発想は避難されるかもしれませんが）違法サイトのユーザーの中には「将来正規顧客になる人」がいるかもしれないので、いかに違法サイトから利益を回収できるかみたいな発想やアイデアも必要なのかなと考えていたりします。
話がだいぶ逸れましたが、そんな事を考えていたときにふと思いました。
**『DLsitePlayってVTTとか字幕ファイルのサポートしてくれないのかな』
まぁVTTファイルのサポートが面倒なのはわかりますが、音声サークルにとっても字幕ファイルをサポートできるようになれば海外の消費者層の獲得も狙えるのでメリットは十分にあると思います。
まぁ、それをDLsite側がやるのは微妙な気がするので「どうにかして音声ファイルと一緒に字幕プレイヤーを同梱できないか」みたいなことを考えていたりします。
DLsitePlayはコンテンツにHTMLをサポートしているので、SPAとして作ればDLsitePlayからも字幕プレイヤーを開いて使うことができる気がします。
（音声の再生はDLsitePlayではなく、独自のプレイヤーになるからDLsitePlayのマイリスとかは使えないし、連続再生とかの機能を独自プレイヤーに組み込む必要はありそうだし、そのあたりのコストが開発者の頭を悩ませているぐるぐる）
まあ、字幕プレイヤーの詳細はともかく、字幕プレイヤー同梱の作品を作る側としては
が簡単かつシンプルにできるようになれば、この字幕プレイヤーアプリは重宝するんじゃないかなと。
DLsiteは一部作品で中国語字幕版とかを売ってたりするけど、あれ別作品として登録されているから販売数とかが合算されない（つまり販売数ランキングで上に行きにくくなる）
単一作品で多言語サポートできるのは、メリットあるんじゃないかな。たぶん。
（最悪な発想だけど、違法サイトから自作品の字幕をパクってくるの面白そう……日本の著作権法では翻訳権は原著作者にあるし、二次的著作物の利用について原著作者は同等の権利を有するし、そもそも許諾してないから共有著作物に当てはまるかグレーだから翻訳者に共同著作の権利があるか謎だけど、もし差止請求しようとするとその根拠が著作権法になるはずだし、無難なのは翻訳権の許諾に関する事後契約みたいな示談になりそう……）
字幕プレイヤーを利用する側は、まぁDLsitePlayと同等くらいかちょい低いくらいの機能があればいいと思う。
まぁ、この字幕プレイヤーで売上がどれくらい伸ばせるかの指標がないと、使ってくれそうにないけど。
まぁ、そのうち出来てるといいな…。
終わりに
現状ではMeSに興味を持ってくれている方も、わざわざMeSで記述することの恩恵をあまり感じていないと思います。
それもそのはずで、まだMeSによる執筆ワークフローのようなモデルを紹介していないからです。
（これはVer0.5以降に紹介する予定です）
（年内を目標にしているVer0.5リリース後に本格的なプロモーションを始めようと考えています)
記述する観点で言えば、MeSは複数人がシナリオに関わるときのほうがより効果を発揮すると思っています。
例えばGoogle docs等でシナリオを共同編集しながら、セリフの演技に対して脚本家と音響監督と声優が意思疎通をしつつ、セリフに注釈的音響コメントを記入することができます。
もしくは声優が演技の疑問点を音響コメントとして付与し、それを音響監督にチェックしてもらって疑問を解消することにも役立ちます。
（セリフや作品に対する疑問点などを関係者一同が共有と振り返りができることは大きなメリットです）
他にもいろんな活用場面があるかもしれません。
「MeSをどのように活用してワークフローに取り込むのか」
この利用モデルのノウハウを蓄積して広めることがVer0.5以降の課題の一つになっています。
（現状ではその領域に達していないので、あえて利用促進の広報をあまりしていません）
また、現状の執筆体験で不満がなければ、わざわざMeSを使う理由もありません。
MeSが目指すゴールの一つに「絵コンテレベルの脚本」があります。
脚本はアクター（演者）だけが読むものではなく、演出家や音響監督など多くの人が触れるものです。
「このシーンはどういう感情を表現するべきなのか」
それを脚本家だけでなく作品に関わる多くの人が意思疎通（共有と議論）できることがMeSが目指している「絵コンテレベルの脚本」に必須だと考えています。
少し話がそれますが、ハリウッドではシナリオデベロッパーという職業があり、シナリオライターが執筆したものを実際のメディア（映画やCM等）作品に起こす上でメディア特性を加味して更に良くなるよう開発していくことがあります。
セリフだけ書かれた音声作品のシナリオを、加筆修正してメディア特性を意識したシナリオに仕上げるシナリオデベロッパーが居てもいいかもしれません。
または、物語構造やドラマ演出などに詳しい演出家がシナリオをさらに脚色していくのも面白いと思います。
MeSは脚本を書くシナリオライターの執筆体験を向上することも目標としていますが、脚本の執筆に多くの人が関わることができる環境作りも目標の一つです。
そして、より良い作品を生み出す環境づくりの一助になれたらと思っています。
雑記：それはそれとして
本音を言えば、MeSを足がかりに物語構造重視を強固にしたい野望もあります（ミジンコサイズの野望です）。
もうこれは完全に私的なイデオロギー主張になりますが、2022年8月現在の音声作品にいおいてシチュエーションボイスに該当するものがトレンドを占めている印象があります。
誤解を畏れずに過激な発言をすれば、シチュエーションボイスの多くは「美味しいシーンだけ摂取する行為」です。
いちごのショートケーキでいちごor生クリームだけ食べる行為なんです。
エロ漫画で導入を省いて、すぐに挿入シーンに突入するようなモノなんです。
（ちなみに、私はシチュエーションボイスが嫌いとか悪いと一言も言っていませんが一部の読者がそう受け取れてしまう日本語って面白いよね……）
私の言う物語構造重視とは、このような会話の配置から読者が体験したり勝手に推測したりする感情もうまく使って「読者にどんな思想と感情を届けるのか」も含まれます。
叙述トリックと似ていますが、少し違う概念です。
これらを巧みに使って構造美が感じられる作品が増えてほしい……。
特に催○音声とか……。
（別に少ないわけじゃないのに、こう書くと現状が少ないみたいに捉えられるのも日本語面白いよね……）
物語構造の重視にはイベント展開や会話の配置を含めて緻密な設計が必要になったりします。
将来的にMeSの周辺ツールとして、機能的イベント配置から物語構造テンプレートを出力するメタシナリオ構築支援ツールみたいなものも作りたいとか、色々と妄想しています。
妄想するだけならかかるコスト低いし、機能スコープを大きくしても怒られないので……。
詳細設計と実装が一番コストかかる……。
