【雑記】あっという間に2月が終わった

雑記

あっという間に2月が終わった。
何もしてなかったかというと、そうでもなくて、

シュクメルリ食べたり、
A5和牛の焼肉食べたり、
弘前にクラフトビール飲みに行ったり、
同級生と久しぶりに飲みに行ったり、
喫茶＆バーで飲んだくれたり、

振り返ってみると、結構いろんなことをしていた。

ただ2月はたくさん外に出たことで、考えさせられることも多かった。
そして、プライベートな時間でパソコンを起動しなかったという事実が一番の衝撃だったかもしれない。
一応、仕事ではパソコン使うし、日常生活ではスマホとかタブレットは使っていた。
なのであまり共感はしてもらえないかもしれないが、プライベートな目的でパソコンを全く使わないというのは「ずっと一緒だったテディベアを失くしてしまったのに、他のおもちゃでも日常を過ごせてしまう。でも高度に遊ぶ習慣が消え失せた」みたいな感覚だった。

正直、スマホ（タブレット）とパソコンそんな変わらないやろという人も多いと思う。
でもパソコンは日常の様々なことのハックに使いやすいのが楽しい。

例えばCi-enのマイページにNSFW画像が表示されるのを防いだり、
DLsiteの作品ページから直接ギフトページを開けるようにしたり、
桃色CODEのサイトにみちくさびゅあーを直接埋め込む機能作ったり、
Etc...

こういうことはスマートヒョンだけでは中々できないので、パソコンの便利さを実感する。

ちなみに私物のデスクトップパソコンはあまりにも使わなすぎたので、離れて暮らす兄に貸し出している。
なので手元にあるパソコンはSurfaceGo(初代)という開発には向かない貧弱パソコンだけ。
こうやってCi-enの記事書いたりする程度には使えるのだが、タブレットでもできるからなぁ……みたいな。

そういえば久しくノートパソコンを買っていないので、アマゾンを徘徊していたら中古のリテール品がWindows11のノートPCが大量に出ていた。
しかし、CPUをみてびっくり。

Win11が正式サポートしてない世代のCPUじゃん……

ネットでの買い物も難しくなってきているなと思った。

Mes

.NET8がリリースされたら移行しようと思っていたMes。
結構致命的な設計ミスにも悩まされていて、イチから再設計しています。
正直なところ勉強も足りてなくて、このまま再実装するのも得策じゃない気がして勉強しながら設計してはバラしてを繰り返しています。

Mesの言語自体は初期の頃からコンセプトは素晴らしいと自負しています。
「デコレーション」という概念でメタ情報を扱い、それを構造化されたデータとして簡単に扱うことができ、既存のシナリオテキストをMesに書き直すのは非常に簡単なのもコンセプトが洗練されているおかげです。

テキストシナリオをプログラムで扱いやすいように構造化されたデータとして提供することで、「【Mes】ADVで使えそうな分岐管理を試験的に組み込んでみた【試験実装】」みたいな機能も比較的スムーズに開発できました

一方で、Mesの開発で一番苦労しているのはコアライブラリの実装です。
しかも、Mes本体の解析処理ではなく、Mesを便利にするための外野のフラットレイヤーとコンフィグレイヤーと呼んでいる部分で一番苦労しています。

フラットレイヤーはMesとして解析する前に、テキストに前処理を施す層です。
脚本でよく使われる表記方法の一部をMes形式に変換したり、削除していいコメントアウト部分を消したりします。
そうすることで一般的なシナリオ記述でもMesで解析できるような工夫がされています。
置換ルールと処理を書くだけなのでフラット処理単体の実装は難しくありません。
問題はコンフィグレイヤーとの関係にあります。

Mesではヘッダーと呼ばれる記述エリアに各種設定用の変数を記述することができます。
キャラ名も省略したときのデフォルト名や、各種デコレーターの記号などMesに関する設定をMesテキスト内で設定できる仕組みです。
この仕組みはMesのヘッダー部分の解析時にコンフィグへ情報の上書き処理を行います。以降の処理では上書きされたコンフィグ情報で解析されるので、デコレーター文字などの設定書き換えも可能になっています。

フラットレイヤーはヘッダー解析よりも前の段階なので、このコンフィグ書き換えの恩恵を受けられません。
フラットレイヤーでもヘッダーの変数解析をするしかありませんが、そうするとヘッダーの役割と重複します（このような役割の重複がバグの温床になります）
そうなると、ヘッダーの変数解析はフラットレイヤーに移譲するのが正しい気がしてきますが、フラットレイヤーは必ず実行されるような仕様ではなく、ライブラリ利用者が任意に外すことができる使用になっています。
（元々がテキストの前処理をしたいケースでの拡張機能的な役割なのでこのような仕様になっています）

というわけで、フラットレイヤーの前にコンフィグレイヤーを新たに作り、コンフィグレイヤーを通過したときはヘッダー解析で変数解析をスキップできるような仕様なら効率よくできそうだなとか。
そういった再設計をしています。
特にコンフィグレイヤーはまだ仕様が固まっていないのもありますが、MesEditorのようなサードパーティツール製作者がコンフィグ設定用の機構を実装しなくても機能するような柔軟な仕組みづくりを念頭にして考えています。

まだまだ時間がかかりそうですが、ここさえ満足いく作り方ができればサードパーティツールの開発はすごく楽になるのでスキルアップも兼ねてじっくり作り込もうと思います。

【Mes】ADVで使えそうな分岐管理を試験的に組み込んでみた【試験実装】

どうもいらにかです。

Mesもβテスト準備のためにバグ洗い出しなど色々進めています。

そんな最中でした。

https://twitter.com/alumiloid/status/1642074031330557952?s=20

すごく面白いアイデアです。
いずれは、ティラノスクリプトへの変換など構想はありましたが、Mesで分岐管理がいい感じにできたら面白そうです。

元ネタのアイデアではMermaidという作図記述言語をMesの派生として生み出すみたいな発想ですが、すごく着眼点がいいです。
というのもMesの思想として、記述言語が目的にそぐわない場合は「内部のデータ構造だけ再利用して、記述言語を再設計する」ことを初めから意識しています。
（Unix哲学的に言うと、捨てる準備をしておけみたいな）

ただ、色々と考えていくうちに「Mesの構造をぶっ壊さずにいい感じに実装できるんじゃないか？」という気がしてきました。
Mesの設計思想として、「脚本（書きやすさ）と台本（読みやすさ）の分離」があるため、脚本記述には複雑性を持ち込ませずに台本側でビジュアライズ（要は図の生成）できたら理想形だと思います。

Mesには非推奨ですが「拡張フィールド」というデコレーターが存在しています。
このデコレーターは「好きなデータを突っ込んでいい」という無秩序があるため、すごく便利なんですが同時にバグの危険性と仕様の複雑化が懸念される諸刃の剣です。
まぁ、今回はこいつを使えば既存の仕様を破壊せずに分岐管理を実装できるかも知れません。

知れませんでは確証が持てないので、とりあえず実装してみます。

セクションという持て余していた機能

分岐管理において必要なのは、「AからBへいく」という情報です。

例えばAというシーンにおいて、分岐からBとCに行くとき、
A-->B
A-->C
のような情報があれば表現できます。

ただ、これだともう少しリッチな表現ができるよう「どういう場合にAからBへいく」みたいな情報も持たせたいですよね。
Mermaidの場合はこんな感じの記述になります。

A-->|Bを選ぶ|B
A-->|Cを選ぶ|C

一般的なゲームエンジンやスクリプトでは、ラベル(場所)とgoto(jump)で記述されます。
ラベルも拡張フィールドで定義してもいいかもしれませんが、Mesにはセクション(==)というシーンの区切りみたいな機能があります。
今回はセクション名をラベルの代わり使うことにします。
（要は上記のABCの代わりにセクション名で関係を定義します）

セクションを明記するとこんな感じ。

== Aルート

ここはAルートです

== Bルート

ここはBルートです。

== Cルート

ここはCルートです。

これに、選択肢の内容とジャンプ先の情報があれば作れるはずです。
ちなみに、選択肢が無く、矯正ジャンプの場合もあるので選択肢の内容は記述しない場合もあり得ますね。

というわけで、30分くらい考えてみました。
?の中に設定値としてchoose:<value>,とjump:<セクション名>,を設定する感じにしました。
（試験的な実装なので、カンマは末尾でも必ず必須にしています）

とりあえず、サンプルテキストも書いてみました。

== 共通ルート

ここは共通ルートだぜ。

どこにジャンプする？
? choose:Aを選ぶ, jump:ルートA,
? choose:Bを選ぶ, jump:ルートB,
? choose:Cを選ぶ, jump:ルートC,


== ルートA

ここはルートAです
?jump:共通エンド,

== ルートB

ここはルートBです。
ルートBはCとAルートの選択があります。
? choose:Aを選ぶ, jump:ルートA,
? choose:Cを選ぶ, jump:ルートC,

== ルートC

ここはルートCです。
? jump:共通エンド,


== 共通エンド

ここは共通エンドです。

で、これをMermaidで分岐を作図するとこんな感じになるはずです。

graph TD;
共通ルート-->|Aを選ぶ|ルートA;
共通ルート-->|Bを選ぶ|ルートB;
共通ルート-->|Cを選ぶ|ルートC;
ルートA-->共通エンド;
ルートB-->|Aを選ぶ|ルートA;
ルートB-->|Cを選ぶ|ルートC;
ルートC-->共通エンド;

※共通ルートとルートAのように語順の統一がされてないのはMermaidで使える文字をテストするためなのであまり気にしないでください。

Mesで解析
→拡張フィールドを解析してグラフ用のデータ構造に変換
→それをMermaid形式に書き起こす（PlantUMLとか他の記述言語でもいい）

こんな感じの処理を実装すれば実現できそうです。

試験実装をsmweに公開

というわけで、MesのテキストからMermaidテキストに変換する機能を実装してsmweに試験実装しておきました。

https://smwe.iranika.info/

一番下のサンプルテキストから「分岐図のサンプル」を選ぶと上記のサンプルテキストに切り替わり、詳細＞デバッグ情報＞分岐グラフ用のMermaid　からMermaidに変換されたテストが見れます。

あとはMermaidの作図ライブラリとか入れれば、smweのアプリ内でもビジュアライズ（可視化）できますね。
ただ重くなりそうなので、グラフ表示の実装はスキップします（いつかやるかも）。

ちなみに、生成されたMermaidテキストをmmdcコマンドでpngに出力したのがこれです。

Mesでの記述仕様や実装したコードはまだまだ改良の余地があるので、これから検証と検討を重ねて合理化を詰めていきます。
とりあえず、Mesを使う人に「こういうことも出来そうだよ」と提示できたのは良かったなと思います。

Mesのポテンシャルはまだまだあるので、これからも伸ばしていきたいですね。

余談：Mermaidは使えない文字がある

MermaidはGithubのMarkdownに組み込まれたりして活用場面が広くなりましたが、個人的にはPlantUMLで事足りているので、話題になった時に少し触ったくらいの知識でした。

ただ、今回の実装にあたって一番ハマったのが直接使えない文字があることです。
【Markdown】Mermaid.jsで使えない？文字

これらの文字は文字参照するしかないみたいで、結構手間がかかります。
文字参照

今回の実装では、なにも手を加えていないので使えない文字はそのまま出力されます。
（それをMermaidにくわせてもエラーになるだけ）

PlantUMLはダブルクオートで囲ってしまえばどうにかなるので、このあたりの文化の違いに一番時間を溶かしました。

余談：ソースコード

ここにあります。
https://github.com/tokakuya/Mes/blob/main/Mes.Extension/GameBookExtention.cs

勢いで書いたので汚いですが、今回書いたソースコードです。
命名が微妙だったり、一部は汚いです。
どうせ後からリファクタするのでいいんですが。

Mesテキストをパースすると、Mes.core.Mesという構造化されたデータになります。
そのMes.core.Mesの拡張メソッドとして、Mermaidへの変換処理が実装されています。

なのでmes.ExportMermaid()のように呼び出せて便利です。
別の記述言語へのExport実装も簡単にできると思います。

【近況報告】「脚本から始める創作設計入門（仮）」という本を書いてます

どうも、いらにかです。

今回は執筆中の本の話をしようと思います。

事の発端はこのツイートに添付してある、「はじめに」を書いてしまったせいです。
最初はこんな本あったら面白そうだなくらいのノリでしたが、書き始めたらなんか本格的になってきたので本当に書いてみることにしました。
※コミケは嘘ですが、執筆しているのは本当になりました。

https://twitter.com/happy_packet/status/1584477667725701121?s=20&t=2ux4vzE_rgQMt8erpTItaQ

執筆に至った経緯を雑にまとめてしまえば

• 実は脚本の利便性と創作設計ノウハウを皆が知らないのでは？
• そんな状況でMeSをプロモーションしても響かないのでは？
• ネームやラフ絵や脚本は、品質管理の設計図であることをわからせよう！
  • 品質管理のノウハウを身につければ創作体験は向上できる！
  • ついでに物語構造とかシナリオ創作のノウハウも教えちゃえ！
• そして品質管理で脚本が便利なことを理解してもらおう！
• というわけで、本を書こう！
• 最終的に私がつくった台本テンプレの一部をMeSと親和性良くして、MeSを広めたろ…グフフ…（隠された事実！）

ということです。

ちなみに、現時点ではこんな感じです（一部をチラ見せ）。
※内容は変わるかもしれないので、詳しく読まなくていいです。

あくまで目次も内容も確定したトピックではありません。
レイアウトや見やすさ等はまだ整えていませんが、創作設計において最低限書きたかったことはとりあえず書き出した気がします。
ページによっては文章を詰め込みすぎた気もしますが、未来の私がいい感じに直すでしょう。頑張れ。
創作設計の章で残っている作業は、私が創作設計をする過程の思考をトレースした参考実例集「おいおい、設計の話があまり無いじゃないか！」の節で、不足している創作スタイルを吐き出すことと、全体の体裁を見やすく整えることです。
活用例の章は、創作別に最適化した台本レイアウト（台本構成）の解説が中心の話なので、ブラッシュアップしたレイアウトを用意すれば終わるでしょう。

ここで、ふと嫌なことが頭をよぎりました。

私が伝えたい事は概ね書いた気がしますが、読者が知りたかったことは十分にかけているのだろうか？
創作設計の章は8割くらい完成してるけど、そもそも読者がこの内容で満足してくれるのだろうか？

本書は脚本執筆の入門書ではなく、「設計図として脚本の使い方を考える入門書」という要素が一番強いです。ストーリーを面白くする手法等は、品質管理に関わってくるのでオマケとして書いていますが、一般的に脚本教室等で教えるような書き方についての指導内容はあまり書いていません。
というのも、「そういった基礎は他の本が扱ってるから、そっちを読めばいい」からです。今の時代ならネットにも転がっています。

何でもかんでも書いてしまうと、膨大になって書き終えることができませんし、本当に伝えたいテーマがブレるので、本書はなるべく「私が伝えたい内容」に絞って本の厚みが薄くなるように意識しながら書いています。
こうなってくると、本書の仮タイトル「脚本から始める創作設計入門」も誤解を招きそうなので変更したほうがいいような気もしてきます。
良い着地点がわからなくなってきました。

そこで、ひらめきました。

この問題の本質は「読者が知りたかったことが十分に書けているのか？」です。

つまり、読者の意見を取り入れてしまえば解決するのでは？

まずは本書を、当初の私が書きたいと思っていた内容でアルファ版として手頃な価格でリリースします。内容的には創作設計の章と活用例で台本レイアウト3つくらいかなと。

そのアルファ版を元に、読者の意見や要望をなるべく反映して、完成版としてフルプライス（価格未定）でリリースします。台本レイアウトも増やしたいですね。
この時、アルファ版を購入していた人は、完全版の価格からアルファ版の価格を引いた差分の値段で完全版を購入できるようにします。要は内容の差分にお金を払うスタイルです。
加えて、アルファ版からの更新差分だけを知ることができるよう、改版差分早見表（差分だけ抜き出したもの）も提供します。こうすれば、完全版への知識アップデートは改版差分早見表を読むだけで終わります。めっちゃ楽！！

まとめると

アルファ版：いらにかが伝えたかった内容。早くお届けできる。
　　完全版：読者が知りたかったことをできる限り反映した内容。満足度高そう。
　　　　　　アルファ版の購入者は内容の差分に支払うスタイルであまり損しない。

と言った感じです。

私としては「基礎は他の本を参照するから、いらにかの視点から、もっと研究的かつ実用的なノウハウに注力して書いてくれ」みたいな読者をメインターゲットにしているので、そういう読者に早く届けるためにも、このアルファ版が最適解かなと思いました。
ぶっちゃけ、アルファ版で読者が満足してくれるなら完成版を作る必要もないので。

というわけで、色々忙しいですが、年内を目標にアルファ版リリースを目指します。
マジで冬コミの時期に間に合うかもしれない……（リアルコミケには出れないですが）

もし本の内容に興味がある人は、この記事にいいね！とCi-enのフォロー、Twitterのフォローをよろしくお願いします！！（ユーチューバーみたいな締め方だ）
もし先に内容への意見やリクエストがあればコメント下さい！

それでは、続報をお待ち下さい。
無事脱稿できるように祈っててね。

(๑•̀ㅂ•́)و