架空伝統ゲーム「ケセリマ」を Elm で実装した話

この記事はボードゲーム・パズルプログラミング Advent Calendar 2022 と Elmのカレンダー | Advent Calendar 2022 および筆兵無傾 Advent Calendar 2022 の 12 日目の記事です。

背景 part 1

(記事の技術的内容には本質的な関わりがないので、お時間のない方はこのパートは読み飛ばしていただいても構いません。)

こんにちは、hsjoihs です。

過去記事にも書いた通り、創作の種類の一つに「架空世界創作」、つまり、架空の世界の言語・文化・地理などを創作するという形態があり、ご縁あって、2017年頃から私もファイクレオネという架空世界についての創作を手伝わせていただいております。

hsjoihs.hatenablog.com

具体的には、架空世界の言語を創作し、その言語で説話を書いたりしつつ、

架空のボードゲームの細かなルール差が生んでいる社会問題をその言語で語り、

f:id:hsjoihs:20211222185515j:plain

y1 huap1 cet2 kaik zui1(官定机戦論)。机戦にある地方ごとの細かなルール差が金銭トラブルなどを生んでいる実情を重く見て、「統一規則を制定することで人々の相互尊重が期待できる」「ルールの差を論じるにも、統一規則があると便利である」といった趣旨の文章。

それを元に公式の統一ルールを整備し、それをこれまた架空世界の言語で書き、

AIL PANIT LETI CETKAIK LETI KULANTE(アイル統一机戦書)の一ページ

そのボドゲオンライン対戦バージョンを実装していたりします。

f:id:hsjoihs:20211222184715p:plain

オンライン対戦の入り口ページで、言語設定で異世界の方を選んだ場合

背景 part 2

(記事の技術的内容には本質的な関わりがないので、お時間のない方はこのパートも読み飛ばしていただいても構いません。)

さて、このように、架空世界創作というのは、ゆったりまったりダラダラと何年も続けていくことのできる趣味であり、世界というものが壮大であるがゆえに無限に続けていくことができてしまうタイプの趣味です。

それはそれでいいのですが、逆に時間を区切って「一ヶ月でどこまで架空世界創作ができるか」という方面も面白いのでは、という話が持ち上がっていました。ちょうど小説投稿サイトノベルアップ+が「異世界ファンタジー設定コンテスト」というというのを2021年6月末締切で開催していたという経緯もあり、このコンテストの趣旨にあんまりそぐわないのを重々承知の上で、我々が今までやってきた

を整備するという作業を締切厳守でやってみよう、と考えてみたのです。

novelup.plus

 

なお、「ケセリマ」という名前の由来については、これまた過去記事に書いたのですが、

hsjoihs.hatenablog.com

 

hsjoihs「この前無意味語をパッと思いつく必要が発生し、その際に「ケセリマ」でググったら一切ヒットしなかった。ラテン字表記は Queserima とかでいいか。」

SY「ケセが光という意味でリマが闇という意味です。」

hsjoihs「じゃあそれで。」

 

というスピード採用によるものです。

Elm を採用したわけ

過去記事にも書いたように、架空伝統ゲーム「机戦」のオンライン対戦では生 DOM を弄り倒すコードを書いていったので、全体像を追いづらかったという事情がありました。

hsjoihs.hatenablog.com

 

今までフレームワークを使ってのフロントエンド開発をあまりしたことがなかったという経緯があり、別の Web アプリを雑に組んでみようと思った際に「今度こそはフレームワークを使おう」と考えました。こりーさんと話した際にその旨を口にしたところ、

となりました。

そこで、2021 年 4 月 5 日の新幹線内で特にやることがなかったので、「せっかくなら前々から興味のあった Elm を学ぶか」と思い実践してみました。

その結果、The Elm Architecture がことボードゲームを書く上でかなり適しているということを実感しました。「机戦」の実装は既にコード負債がだいぶ積み重なっており、そもそもゲームそのものがかなり複雑ということもあって、現状これを別フレームワークへと移し替える目処は立っていないのですが、今回「ケセリマ」を一から実装するにあたっては Elm を使ってみようという気になりました。

採用してみての感想

幸い、中学生の頃に情報オリンピック夏季セミナーで Haskell を習っていたこともあり、基本的に特に困ることなく実装していくことができました。

また、実装する対象がボードゲームなので、Model - View - Update からなる The Elm Architecture がかなり上手く適合し、非常に書きやすかったです。

github.com

 

エスケープハッチが用意されておらず、部分関数を用いない「正しい」実装を強いられるというのも、なかなか良い体験でした。

 

ということで、Elm を使ってもう一度ボードゲームを 2022 年 3 月に実装することになるのですが、まあそれについては別の機会に話せればと思っております。

今後の展望

一方で、https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/ とかを見ると、

  • 内部的で不自由な特権機構が形成されてしまっているっぽい
  • コミュニティ運営やコントリビューションに関するメタプロセスがしっかり整備されていないっぽい

(これはこりーさん言語化で、かなり私の感想と合致しているので引用させてもらう)

 

という事情があるらしく、「Elm そのものはフレームワークとしてせっかくの素晴らしさがあるのに、それを帳消ししてしまっているなぁ」という気持ちも若干……(React が Elm のいいところを上手く回収してくれているからという事情もある。書いた HTML タグをドキュメント見ながら全部 Elm の関数に手作業で翻訳していく作業を経た結果、後に React を使った際に「JSX って便利だなぁ」という感想になったし)