見出し画像

Lunchtote起動してさわってみた

てんなな

って記事ないですか? と某所で打ち込んで様子を見ていたのですが、そんなものはなかったてんななです。

なにそれ

reifierさんの暗夜迷宮という定期更新ゲームのオープンソース部分です。そろそろゲーム本編が開始される、つまりだいたい機能がそろっているのでは、というのと、似たようなものを蒸気流工房で作ろうとしているので、先行事例だーってことで覗いてみることにしました。

ちなみに、同ジャンルのオープンソース事例としては、さかなさんのteiki-adventureがあります。こちらも以前、Herokuの無料プランが終わるまでのつもりで公開試用環境を作ろうとしたのですが、MySQL独自文法が多用されてて断念しました(HerokuはPostgresでした)

とりあえずはセットアップ

上記のツイートからGithubへ行くと、リポジトリが3つありますが、いったん自分の手元で動かしたいだけならlunchtote-containersとその手順に従えば大丈夫です。わたしはGithub認証にKryptonを使っているのでSSHキーの追加が必要でした(1敗)。

「initialize.shを実行してください」まで進めたら初期セットアップは終わり、以降は以下のコマンドをGit Bashとかで実行すれば起動されます。run~は初回はけっこうかかるのと、起動中は操作できないのでGit Bashの窓が2つ必要です。

$ docker compose up -d
$ ./run-backend.sh
$ ./run-frontend.sh
左がfront, 右がbackend

frontの白い文字を見ると、http://localhost:15679 がアクセスポイントに見えますが嘘です。ここに出ているのはDocker上の話なので、docker-compose.ymlで割り当てられているホスト用ポートの80番、つまりはhttp://localhost/ でアクセスできます。

普通にさわってみる

なにはともあれシンプルにRegistします。己で環境を作ればEno.1を取ることなど造作もありません。

Lunchtote-Frontendは実際にはゲームに合わせてデザインを変えるものでしょうから、そんなに細かく見ていくつもりはありませんが、機能としては結構そろっているように見受けられます。

ハンバーガーメニューからの機能一覧
このアイコンは朝倉さんではなく、百合鏡にいたジニーさんですがわかりやすいので
リアクション機能だ!

執筆時点最新の 310f65d ではプロフィール画面が崩れたりしますが、単純にリポジトリに画像が入っていないようなのでそのうち直るんじゃないかと思います。ここを書いてる時点(2/11)では、「この土日でだいたい仕上げる予定」とのことでした。

返信しようとしたらエラーになりましたがこれもそのうち直るでしょう。

ソースコードをチラ見してみる

セットアップ時には自分でcloneしなかった方を見に行けばソースコードを覗けます。Docker上はnotificationサーバー等分かれていましたが、ソースコードはクライアント(=frondend)とアプリケーションサーバー(=backend)にまとまっています。通知サーバーはbackendの通知機能だけ動かすサーバーという理解で良いでしょう、たぶん。

Go言語は触ってませんが雰囲気で読みます。まずviperは環境変数の管理ツールのようです。恐れる理由などない。

先の通り、フロントエンドは細かく見ませんが、ざっくり眺めた感じ、シンプルめのReactアプリケーションって印象です。先のサイトマップを見ながらpages/以下を見に行けばどのページが何をしてるのかはだいたいわかるでしょう。メッセージの途中保存のためにstoreが多めになっているのが定期ゲーっぽいと言えば定期ゲーっぽいかな?

シンプルめに収まっているのは、フロントエンドでいろんなデータを加工するタイプのシステムではないことと、バックエンドの開発目標によるものです。

高速化のため、フロントエンド側でのユーザーの1操作に対してAPIの操作数は1を原則としています。

backendのREADMEより

本業でもここまで徹底したことはないですね、某ソシャゲは見習え。

この前提であれば、キャラクターに対する操作ってどんなものがあるの、と思えば、/usecase/character や /repository/character.go を見に行けば網羅されています。SQLで見たければ/infrastructure/database/character ですかね。

backendを起動しておけば見られますがGoって速いんだな

SQLでできる加工やチェックはSQLにやらせよう、という思想なのか、ブロックの有無などの検査等がinfrastructure/database以下にあるのがちと気になりましたが、DBが同じネットワークにあるならそちらの方が速いのでそうだね、という気持ち。

おわり

暗夜迷宮もいよいよ18日公開、ということでここからさらに機能修正等が積み重なっていくと思われるので、とりあえずWatchとStarを押してきました。

レンタルサーバー運用をやめてVPS使ってこれ動かしたら楽はできるだろうな……とはとても思うのですが、トークが即時届くなんてクソとか言い出す人なので、採用するとしたら今とは別の企画を動かしたときになるとは思います。それはそれとしてレンタルサーバーでPHPとかやめようかなってぐらい速いよ

また、ユーザーからするとこの機能の充実ぶりが基準のひとつになると思うと、ウボァ……と鳴き声をあげたくもなりましたが。まあぼちぼちやるしかありませんね。
まずはデータベース設計あたりから示唆をもらってこよっと。

おまえは肉を食らってアウトプットを出すのだ、という圧をかけることができそうです。