Blog

本メールアーカイブは 百合SS Advent Calendar 2020 の ２３ ２４日目です。

本当は一本で終わらせる予定でしたが、中間発表で疲れ切っており、間に合いそうになかったので二本立てにしました。ごめんなさい。（ニ）もすぐに出します。

Godotでもルビを振りたい！

皆さんはゲームを作るとき、何のエンジンを使いますか？　……なになに、「既製エンジンを使うとは限らないじゃないか」ですって？　いやいや、今時、フルスクラッチで自作する硬派な人は希少でしょう¹。エンジンっぽいものを作るにしても、既製のツールの上にオリジナルのものを実装するケースが多いのではないかと思います。車輪の再開発はできるだけ避けたいでしょうから。
既製エンジンで言えば、UnityやUnreal EngineのようなAll-in-Oneなエンジンを使う方も多いでしょうし、あるいはGameMakerやRen’PyやPhaser (≒Pixi.js)のように強み重視なエンジンを使う方もいらっしゃると思います。どれもそれぞれ特徴があって面白いですよね。
有名なゲームエンジン間の比較や各エンジンの強み・弱みを解説しているgamesindustry.bizの記事を読んでみると、いろいろあるんだなあと改めて実感します。

ところで最近、私はGodot Engine²というFLOSSのゲームエンジンを触り始めています。シングルバイナリ（60MBほど）で動作し軽量、マルチプラットフォーム（Linuxでも動きます）に対応、おまけにFLOSS（MITライセンス）なのでソースコードも読み放題！　という個人的な理想が詰まったエンジンなのです。控えめに言って神、というのはこのことでしょう。
そして、私は事あるごとにノベルゲームのような何かを作る習性³があるため、今回もGodot Engine上でノベルゲームっぽいものを作ることにしました。

海外ではそれなりに人気もあるエンジンということもあり、大体の機能は揃っています。テキスト表示も詰まることなくオーケー。各種画像表示⁴や音源再生もオーケー。基本的なノベルゲームっぽいものは難なく完成。
しかし、ちょろちょろとスクリプトを入れ込んでいるうちに、あることに気が付きます。そう、振り仮名、所謂ルビを振る機能がないのです。Godotは海外産である上に日本でもマイナーな存在ということもあって、ルビのようなレア機能は当然実装されていないのでした。

調べてみると、Unityでもデフォルトでルビはサポートされていないようですが、流石有名なUnity、いくつか実装例が存在しているようです⁵。しかし、Godotでの実装例は見当たらず……。
Godotに心を奪われてしまった一ファンとして、これは見過ごせません。というかファン云々以前に、とにかくGodot上でルビを振りたいのです。

前置き

今後を見極める意味で購入した『創の軌跡』

去年の七月、PS Storeで買って放置していた閃の軌跡I:改をたまたまプレイして以来、私は日本ファルコムのファンになりました。冒頭 (のっけ) から人が死んでおり¹、テンションが上がるBGM（この曲は今でもお気に入りです²）と共にガレリア要塞を駆け抜けるシーンは今でも思い出すことができます。閃の軌跡I/IIはテーマ性も良く、特にIIでリィンが慟哭するシーンは屈指の出来栄えでした³。
そして、続けて閃の軌跡IIIをプレイし終えたところで、これはIVをプレイする前に過去作全部やらないとダメなヤツだなと察知し、約一年かけて⁴空の軌跡三部作/零・碧の軌跡をプレイして、その後に閃の軌跡IVをプレイし終えました。

我ながらよくやったと思いますし、過去作を全てプレイしたことで、一ファンとして作品を語る上での自信にもなりました。例えば、去年に私が閃の軌跡I/IIをレビューした際には過去作知識が全く無かったために、当時存在していた過去作との比較による批判は理解ができなかったわけです。今であればそういった批判も理解できますし、その上で再度述べさせてもらうと、閃の軌跡I/IIについての個人的な評価は全く変わっていません。良作だと思っています。I/IIについては。
空三部作、零・碧も本当に良い作品でした。私は特に零・碧を推したい。テーマ性が極めて明確で、プレイした後でも胸に残るものがあります。特に零の終盤、古戦場に向かうシーケンスの震えるほどカッコいいこと！⁵　リアルタイムでプレイしていた時は深夜だったのですが、テンションが上がり切ってしまい、結局朝方までプレイしたのを覚えています。

軌跡シリーズは本当に良作揃いなんですよ。再度書きますが『プレイ後に残るものがある』のです。テーマ性が描き出した主人公らの葛藤が、プレイヤーの心に欠片を残してくれるのです。
プレイヤーに消費されるだけで（あるいは、それのみを意図して開発されて）一ヶ月後には内容をさっぱり忘れられる作品とは違います⁶。

……と、ここまで褒めちぎっていて何なのですが、上記文章で私が褒めていない作品があることにお気づきかと思います。そう、閃の軌跡III/IVですね。

散々言われていることですが、もうはっきり書きます。閃の軌跡III/IVについては、ファンである私も評価できませんでした。特にIVについては、褒めるところがほとんどありません。
まあ、IIIはまだ良かった。新しいキャラと共に、主人公であるリィンの先が語られたわけですから。グラフィックも向上して、新鮮味もあって、まだ褒める点もありました。

IVはダメです。（好きな方がいたら申し訳ないのですが）空・零・碧・閃の中で唯一、ラストで全く感動できない作品でした。IIIから引っ張った展開で目新しさがほとんどなく、ラストで不要・冗長なエンディング分岐をさせてみたり⁷、分かりにくい謎の当て字を多用してみたり⁸、何度も同じ言い回しを使ってみたり⁹、悪い点は枚挙に暇がありません。
終盤のミシュラムでの絆イベントもコピペレベルで、見ていて辛いものがありました。そりゃ怒る人も出るでしょうと。
ラストに辿りつく頃には疲労困憊。挙げ句の果てに、残念バッドエンドです、トゥルーエンドを見るには追加でモンスター倒してラスボス再攻略してください、と言われてコントローラーを投げそうになりましたね。あれは一種のトラウマです。

そんな事情もあり、IVのプレイ後、直前にプレイしていた零・碧の出来が極めて良かっただけに、私の中で一種の疑念が生まれていました。曰く、「ファルコムは、今後どういう舵をきるのか？」と。
私はファルコムの思想はすごく好きです。音楽に力を入れていて、プレイヤーに一定の利用許可を出すほどの胆力もある。ゲームの起動時に邪悪で不快な『警告』メッセージ¹⁰を出すこともない。ゲームの細かな機能、UXも悪くない。GOG.comのような、プレイヤーの自由を尊重するDRMフリーのストアにもPC移植版をリリースしている¹¹。こちらのことをよく見てくれているなと感じます。だから海外での人気が高いのでしょう。
しかし、シナリオを重視するRPGと謳っているからには、相応の質が必要です。伴っていなければ、『ゲーム』としてはやはり失敗ですから。

つまるところ、IVの路線で今後続けるつもりであれば、購入の継続も厳しいなと本能的に感じてしまったわけです。
そのため、今後もイースシリーズ含めファルコム製品の購入を継続するか――すなわち、ファルコムを応援し続けるかを見極める試金石として、今作『創の軌跡』を購入してプレイすることにしました。

前置きが長くなってしまいました。これらの事情を踏まえた上で、ここから『創の軌跡』についての感想と評価・レビューを述べていきます。

ご注意

発売されて間もないこともあり、ネタバレは最低限に押さえていますが、感想（批評）の都合上触れざるを得ない点がありますので、ネタバレが気になる方はクリア後の閲覧を推奨します。

ネタバレリスクを認識した上で、読みたい方はread more。

HugoでMarkdownのテーブルに属性を付加する

Hugo、便利ですよね。当ブログはHugoを使って作成していますし、私が管理しているいくつかのサイトでも積極的にHugoを採用しています。
少なくとも管理者が一人である限り、HugoのようなStatic Site Generatorはメチャクチャ強力だと思っています¹。

さて、そんなHugoですが、0.60.0からCommonMarkに準拠したgoldmarkと呼ばれるMarkdownパーサー²をデフォルトで使うようになりました。
その結果、いくつかの機能が非推奨になったり変更が加えられたりしています。その影響を受けるものの一つがMarkdownのテーブルです。

最近、特にオープンソースという言葉の乱用についてよく考えます。理由は単純で、その結果もたらされるFLOSSの未来が不安だから。

少し長いうえ、序盤から後半にかけての流れが冗長かもしれません。駄文かもしれませんが、自分の考えを整理するのも含め、一度自分の抱えている不安について書いてみます。

自由ソフトウェアの偉大さ

私は自由ソフトウェアの思想が好きです。私が物心ついた時には、用途問わず自由に利用できるライブラリやフレームワーク、ソフトウェアが既に多数ありました。さらに、プロプライエタリに匹敵、あるいは凌駕する偉大な自由ソフトウェアの数々を見てきました¹。GNUのウェブサイトを読んで、素晴らしい思想だとも思いました²。
GPLを好んで使うかはともかくとして、少なくとも、誰であっても差別なく自由に再配布、改造、組み込み、利用できるソフトウェアというのは、本当に価値があることです。そういった自由のあるものにこそ、人は協力するのが良いと考えています³。

人がわざわざ車輪の再開発をする必要は（独占を防ぐ等の一部程度で）ほぼありません⁴。もし自由ソフトウェアがなければ、各々は自分たちで全て手作りする必要があったでしょう。あるいは、高額な金を払って何らかのライブラリやフレームワークを買うかです（かつてはコンパイラすら高額だったように）。結果として、実質的に開発できるのは膨大な資本力と体力がある一部の企業に限られ、それ以外の中小は末端の仕事しかできなくなります。そうなると、自由に誰もが参入して発展させられる場所はないでしょう。進歩の速度は低下し、ITの導入は高額になり、多くの人の興味を削ぐ。プログラミングをするのに鉱山を削ったり物資を調達する必要はほぼないにも関わらず、です。

自由ソフトウェアの概念が発達したおかげで、人々は多くのソースコードを大手を振って共有することができるようになりました。そして現在のように、誰もが気軽に高品質なソフトウェアを書ける世界ができたわけです。何より、自由ソフトウェアはその開発者が開発を止めてしまったとしても別の誰かによって開発を継続させられます。これは(A)GPLが目指した理想の一つです。プロプライエタリは作者の死後70年まで誰もメンテナンスできないのと対象的ですね。
その他にも自由ソフトウェアの利点は挙げられますが、とにかく、様々な利点を我々は享受しています。