# JACKEYES 7月のトロイメライリリースに寄せて
# はじめに
SCRAP (opens new window)さんから、リアル脱出ゲーム『JACKEYES 7月のトロイメライ』 (opens new window)が2025年11月13日にリリースされました。
本ゲームは、株式会社東雲火山が全面的に開発に関わっています。
オープンソースのアドベンチャーゲームエンジン、ティラノスクリプト (opens new window)を利用させていただいた他、Live2D (opens new window)も活用しました。いずれの要素も触った事はありますが、商用ゲームのリリースまでこぎつけたのは東雲火山としても初めての経験になります。
本文書は、開発にあたってかなりの苦労が多かった本プロジェクトについて振り返るとともに、特にiPhoneでのブラウザゲーム開発の知見を共有する事を目的として記述します。
# 制作の流れ
本プロジェクトは、以下のような流れで制作進行を行いました。
- SCRAPさんから場面再現にこだわったアドベンチャーゲームを制作できないか打診を受ける
- Live2Dを使うということで、市場調査をした結果、最初の試作期間ですぐに使えそうなティラノスクリプトを採用
- 試作の結果、良好な手応えを得て本制作に移行
- 本制作において発生したあまたの苦労を乗り越え、リリース
# 試作期間での振り返り
東雲火山でもティラノスクリプト + Live2Dは初めての試みで、Live2Dのモデラーさんは社内にいなかったので、インターネット上で探すところからでした。ここでいつ (opens new window)さんと巡り合うことができたのは一つ幸運だったと思います。いつさん、その節は大変お世話になりました（今後ともよろしくお願いします）。
Live2Dのモデルができても、それをゲーム上に登場させる必要があります。色々調べましたが、ティラノスクリプトがブラウザで動くアドベンチャーゲームでLive2Dを使うのに一番近道そう、ということで採用させていただきました。おそらく、2025年11月現在、改めて市場調査をしても同じ結論になりそうです。
最初は制作手法を固めず、4コマ漫画のような形で場面イメージをもらい、そこに表示する詳しいテキストを羅列した形でもらい、それらをベトナム人開発者に丸っと渡して形にしてもらうという手法を取りました。
試作の結果として、コスト感も動作イメージも良好な手応えを得て、本制作に移ることになります。・・が、この頃、後日起きる問題をあまり予見できておらず、開発会社としてもうちょっと先手を打てなかったかなという反省があります。
# 本制作で工夫したところ
本制作期間に入って工夫したところは色々ありますが、項目として列挙するとこんな感じでしょうか。
- スプレッドシートからティラノスクリプトを直接吐き出す仕組みの構築
- Webシステムとティラノスクリプトを分離し並行開発
- セーブデータの独自実装
1について。SCRAPさんは、伝統的にGoogle系のプロダクトを多く使っており、特にGoogleスプレッドシートの利用が多いです。SCRAPさん側の企画者がなるべく直接編集できるよう、Googleスプレッドシートにマスターデータを集約し、それをスクリプトでゲームに反映という仕組みを構築し、企画者がシナリオ等にこだわっても開発工数が膨らみ過ぎないような構成にしました。
この取り組みは半分くらい上手くいきました。シナリオにはこだわっていただけたと思います。ただ、本当はもう一歩踏み込んで、開発者が全然知らんところでゲームが更新されている～くらいまでやれるとよかったのですが、そういうことをするにはプレビュー機能とかも持ったエディタの開発とかも必要になるので、志半ばといったところでしょうか。
2について、今回のシステムだと4択で入力する部分がありますが、多くのゲームエンジンは入力系の取り扱いには苦労するため、最初からここはゲームから分離して作る事を決めていました。
他にもチュートリアルやメニュー系の制御等、ゲームが苦手そうな部分を予め切り離して、Web系開発者とゲーム系開発者が並列稼働できるようにしました。また、大した事はやってないのですがCloud Functions for Firebase (opens new window)も一部利用しているので、このゲームはCloud Functionsで動くサーバーシステム、ティラノスクリプトで動くゲームシステム、複雑なUIを制御するWebシステムの3つを連動して作られています。
各所の連動については、比較的上手い事制御できました。
3について、ティラノスクリプトのセーブデータは行番号ずれ等で壊れてしまう他、画面の情報なども保存していてちょっと複雑だったので、セーブデータは完全に独自実装にしました。プロジェクト途中まで、行番号ずれセーブデータが壊れて開発効率が悪いことが続いていたのですが、この仕組みを入れてから開発効率が上がりました。
今から振り返ると、もっと早く決断してもよかった気もします。
# 苦労したところ
ここから、この記事の本題です。
ここには書ききれない多くの苦労があったのですが、特に開発知見として共有する価値のある知見を共有します。
# 動画編
JACKEYESは当初、ゲーム中演出はデザイナーさんのこだわりをなるべく直接反映できるよう、動画を重ねて流す事で実現しようとしていました。
容量の問題からWebM (opens new window)形式を選択し、動作自体に支障がないことを確認。いくつかの演出を実際にWebM動画の再生で実現しました。この時点で、動画の制御はティラノスクリプトもそれほど上手くない（再生開始や終了が取りにくい等）という問題等に遭遇しつつ、落としどころを見つけながら実装していました。
雲行きが怪しくなってきたのはプロジェクト途中からで、「ゲームをやっていると（特にiPhoneで）落ちる」という報告が多発するようになります。
動画再生が重い可能性を疑い、WebMを再生するだけのHTMLページを作成して検証したところ、WebMをいくつか再生するだけでSafariが落ちてしまうことを確認しました。iPhoneがVP9のハードウェアデコーダをほぼ持っていないため、発熱・CPUの過大な消費等が発生しているという説が有力なようです。演出単体での再生テストはしたのですが、WebMを使うと判断するのにもう少し慎重な検証をするべきだったと開発会社としては反省しています。
上記を踏まえて、プロジェクト途中からmp4に変更し改善はされたのですが、それでもまだ重いことが多く、動画を重ね掛けて実装したかった演出のいくつかは、プロジェクト終盤にカットされることになってしまいました。当初、ジャックアイの発動演出はもっとリッチだったのですが、落ちる問題を軽減するため苦渋の決断で今の演出レベルになっております。
ここでの反省として、iPhone Safariでの動画再生は鬼門です。WebMの商用利用は時期尚早というのは挙げておくべきかと思います。
現代のブラウザゲームで演出にこだわりたい場合、コストをかけてJavaScriptで実装するのか、落ちるリスクをかけて動画を使うのか、演出レベルを落とすのか等の議論を重ねていく必要があるという事になります。
# アニメーション編
SCRAPさんのこだわりもあり、JACKEYESは画面をよく動かします。
演出レベルのこだわりは画像のサイズにも反映されており、大きなサイズの画像をティラノスクリプトのcameraやkanimといったタグでよく動かしました。なお、東雲火山はブラウザゲームの開発実績は多いのですが、その大半はAkashic Engine (opens new window)を利用した低解像度のゲームで、特に480x480の解像度での制作を推奨しており、このレベルの画像解像度で作るのは当初から少し懸念はありました。
動画の項でも触れたように、プロジェクト途中からiPhoneで落ちるという報告が出るようになってきます。
動画とは別の問題として、「一定以上の解像度の画像をcameraやkanimで動かすとiPhone Safariが落ちる」という現象を突き止めました。（先人の記事 (opens new window)も参考になりました。ありがとうございました。）
Appleの公式なアナウンスは見つかっていませんが、AI等も活用して調べたところ、2048x2048以上の画像に対してCSSアニメーションをかける際、Safariが内部でGPS処理に移行するのですが、iPhoneは比較的VRAMが少ないためこのGPS処理でVRAMを使い切ってハングアップする、という報告が多数あるのを見つけました。
「プロジェクト途中」と書いてますが、このプロジェクトは先に全シーンを作る進行になっていたので、この問題の発覚はかなりプロジェクトの進行に影響があり、以下のような対応を行う事になります。
- 実装済の全てのシーンの画像サイズを精査し、大きな画像を使っておりかつ同種のタグを使っているシーンを精査
- 該当するすべてのシーンの画像サイズの縮小と、画面への再配置を実施
以上の作業を経て、バグるシーンを少しずつ減らし、手元のiPhone端末全てで全部動いたと思ったら、別の端末でまた落ちたという報告が上がり・・と、イタチゴッコをしながら、少しずつ安定性を高めていったのですが、リリース後まだ落ちるという報告は来ており、潰し切れなかった事に対して申し訳なく思っています。
この「別の端末」というのも条件が不明で、明らかに手元のiPhone SE第二世代よりスペックがいい端末なのに落ちるので、何が原因で端末ごとにこのような差異があるのか調べて回りましたが、原因が特定しきれておらず、「なぜか落ちる確率の高い端末がいる」という状況の中、手探りで対策を続けるのはなかなか心理的にも厳しいものがありました。
この項の反省として、iPhone Safariで動作させたいのであれば、アニメーションさせる画像サイズは最大でも2048x2048に留めなければいけないというのは言えると思います。
1024x1024まで落とせるとより良い、という説もあります。
2025年11月現在、ブラウザゲームを作るのであれば画質の妥協は必須要件という事になりそうです。JACKEYESは当初からかなり落としたのですが、ぎりぎりのラインで構築されています。
# ティラノスクリプト編
今回採用したティラノスクリプトについては、OSSのゲームエンジンなので利用させていただく以上はOSS貢献もしたく、途中まではティラノスクリプトへのプルリクエストなども出しておりました。wait_preload (opens new window)というタグは、このOSS活動の一環でティラノスクリプト本体に実装されたタグです。
cameraタグやkanimタグの挙動は前述のiPhone固有問題以外でも制御方法にかなり苦労し、本体にPull Requestを出したもののまだマージされていないもの (opens new window)もあります。これまでそれで動いていた仕組みに対して、パフォーマンス向上やコードとしての正しさの向上を果たせるからといって、本体へ取り込むことが必ずしも正しいとは限らないということもあり、OSSのゲームエンジンをどう活用するか対応方針に苦慮しました。
こういった本体に修正提案を入れるもの以外に、途中から本体に手を入れないとどうにもならないことも多発し、本体にマージを諦める一部改造を施したティラノスクリプトで最終的には動作させることになってしまいました。
例えばJACKEYESにはいわゆるポポポ音が入っていますが、これは本体をハックする形でしか実装できなかったのでハックする形で実装しています。巷にあるプラグインも本体コードを上書きする形になっていますが、上書きしている本体コードが古いコードを対象にしているので、使いにくいものになっていました。ハックしないと作れないので、そうならざるを得ないんですよね。
また、ティラノスクリプトだけでなく、Live2Dの画質を調整しようにも、Live2Dプラグイン (opens new window)のコード本体を修正しないといけませんでした。
このように、JACKEYESの演出を実現するためには本体に手を入れざるを得ないケースが頻発し、結果的に少しいじりすぎる状態になってしまいました。
詳細は割愛しますがiPhoneでの音や動画の再生に関する挙動、プリロードしてるはずの画像が出てこない等の挙動、おそらくゲームエンジンとしてのメモリ解放処理が甘いため連続稼働時にiPhoneが落ちる問題が頻発する等、挙動として最後まで納得いかなかったところもあります。
注意点をよく事前に理解し、本体コードにもある程度手を入れる覚悟があれば、JACKEYESと同程度の品質のアドベンチャーゲーム制作には問題ないエンジンです、という実績にはなりました。
ただこの項の反省として、スマートフォン向けの商用ゲーム制作にティラノスクリプトを用いたことが本当に正解だったのかは、開発会社としてしっかり振り返って評価し、結論を出さなければいけません。
# その他
他にも色々ありますが、キリがないので程々に、箇条書きにて。
- Live2Dの読み込み完了を待つ方法が無く、Live2Dで制作したカオルというキャラクターがいない状態で画面を出す作りにせざるを得ないケースが出てしまう
- Live2Dのモデルは実は机とキャラクターがセットになっている等、あの画面を実現するためにパーツの制御に苦労したところが多々
- ティラノスクリプトのキャッシュ制御は細かい制御方法が無く、ゲーム配信サーバとしてはコストがかかりやすい作りになってしまった
- とある事情でFirebaseの匿名認証が信用できなくなってしまい、ユーザーの識別方法を独自実装にせざるを得なくなってしまった
# 総評
東雲火山は比較的ブラウザゲーム開発を得意にしている会社であるという自負があったのですが、本プロジェクトでは経験の浅さが出てしまったように思います。
特に、iPhoneでの大きな画像や動画の扱いは本プロジェクトを進行する過程で初めてわかり、後からできる限りの対策は施したものの、SCRAPさんにも、楽しみにしてくださっているユーザーの（特にiPhoneで遊んでいるユーザーの）皆様にもご迷惑をおかけしました。
良かった点としては、開発としては二度手間三度手間になるのですが、シナリオ関連はSCRAPさん側企画者の直接管理領域をできる限り増やして、シナリオ面のクォリティ向上には貢献できたのは挙げられると思います。シナリオが良かった、というユーザー評価を見かけると、この手間は無駄ではなかったのではないかと、少し報われた気持ちになります。
色々と苦労をしましたし、未熟なところもありますが、リリースできたこと自体は大変嬉しく思っています。
ティラノスクリプトで動くブラウザゲームがどういうものか、SCRAPさんがプロデュースするWebゲームとはどういうものか、あるいは東雲火山がゲームとWebをどう分離した作りにしているのか等、興味がある人は是非遊んでみてください。
購入はこちらのページ (opens new window)から。（体験版もあります）
# 技術者向けに
試作の項で触れたように、Live2Dを使ったブラウザゲームの実装において、ティラノスクリプト以外の選択肢が少ないのが現状です。
ティラノスクリプトが悪いという訳ではないのですが、選択肢があまりに少ないので、Live2DをサポートするOSSのゲームエンジンはもう少しあってもいいように感じます。
ティラノスクリプトはブラウザゲームの中ではいわゆるDOMベースのゲームエンジンで、jQueryやCSSなども多用して制御しています。もし、別のOSSのゲームエンジンを作るのであれば、CANVASベースのゲームエンジンがいいでしょうね。
東雲火山でも、何かしらの形で予算をつけることができたら、このようなアドベンチャーゲームエンジンの制作や、そのエンジンに対応したシーンエディタ等を作り、SCRAPさん他がより安定したスマホ向けのアドベンチャーゲームを気軽に作れる環境の構築に、モチベーションを持っています。
モタモタしていると時代が進んで周辺状況によって解決してしまうかもしれませんが、今回大いに苦しめられたiPhone Safariには、また別の機会にリベンジを果たしたいと思います。
もしこういった課題に取り組みたい個人、法人の方がいらっしゃったら、お気軽にお声がけください。
2025年11月21日
株式会社東雲火山
代表取締役 告原豊和