『シン・エヴァンゲリオン劇場版:||』良かったですね。これはネタバレではないと思いますが、当時TV版に対して「なんだか分からないけど面白い番組が、最終回だとすら気付かないままなんとなく終わっていた……」と思った子供としては、あんなに面倒なものを終わらせることができた、終わらせてくれただけでまずは最高だと感じていますし、話を畳めないままに最終回ということにしなくちゃならないタイトルは世の中にごちゃまんとあるのでした。
ズッ友（正式表記「ずっとも」）にも、なれなかった……。
去る2020年6月3日、ついに『ららマジ』のサービスが終了しました。開発のWright Flyer Studio改めWFS社にはガチの確率操作だったアナザーエデン事件のツケを今からでももっと真面目に払うべきではないのかと思っていますが*1、それは置いても色々と惜しいタイトルでした。暫定最終回イベント「ホニャららDREAM」のストーリーは本当に面白かった。
ただ記事タイトルの通り、今日するのはイベントの話でも写真の村山下貯水池第一取水塔の話でもないです。
本作は一部プレイヤーの間で「データ通信量が多すぎる」「タイムアウトエラーが多すぎる」という苦情を抱えていました。今回は1年3ヶ月ほど前の読みづらいエントリのリライトとして、ららマジに何が起きていたのかをそこそこ分かりやすく説明するつもりになり、また何が起こらなかったのかを指摘していきます。
いや、サ終タイトルの不備なんてそんな死んだ子の歳を数えるような、後知恵で人の仕事をつつきまわす真似はいかがなものかと私も思うのですが。
ららマジはこんなゲームでした
改めて『ららマジ』は、東奏高校・器楽部の生徒たちを編成し、彼女たちに「ドレス」と呼ばれるカードを装備させて戦う横スクロールアクションゲームです（……でした）。
キャラクター自身は戦闘パラメータを持たず、ドレスの組み合わせが戦闘能力になる仕組みを採用しています。
1チームには最大4名を編成し、ステージセレクトの際に他プレイヤーからヘルパーキャラを借りて5名でゲームを開始します。
また上の画面では左右スワイプでチーム編成を切り替えることができ、10チームまでの編成を保存できます。
編成中キャラクター詳細画面。画面上部に大きく表示されているのが操作キャラとなる必須のメインドレス、中央から下部にかけて「通常ドレス」「イベントドレス」と書かれているのが能力を底上げするサブドレスとなります。
サービス運営当時、キズナLv（キャラクター親愛度）は13まで解放され、サブドレスのスロットが5個まで使えるようになっていました。
（ドレスノートって何？ - 【ららマジ】アンサンブルを奏でたいより）
それぞれのドレスは経験値などの付帯情報を持つ他、ドレスノートと呼ばれる最大64個前後のスキルツリー・アンロック要素のリストを持っています*2。これは解放数が多いほど増える可変長のデータです。
- チーム(x 10)
したがって「チームの編成」とは、ざっくり上記のような階層構造で表せます。
大きすぎる通信データサイズの内訳を検討する
階層構造を簡単な図に開いてみます。
図の右下に、チーム1個分に必要なデータ量をラフな実測に基づき追記しているのですが、1カラムあたり数バイト～十数バイトで済んでいるはずの他のデータに対してドレスノートだけが異常に大きいため、実質的にはチーム編成のデータ量≒ドレスノートの数であると言えます。
実際に計算していきましょう。
| 単位 | ドレスの数 | ドレスノートの数 | データサイズ |
|---|---|---|---|
| ドレスノート1個あたり | - | 1 | 100byte |
| ドレス1着あたり | 1 | 64 | 6,400byte |
| キャラ1人あたり | 6 | 384 | 38,400byte |
| 1チームあたり | 24 | 1,536 | 153,600byte |
| 10チームあたり | 240 | 15,360 | 1,536,000byte |
ドレスノートはなぜか1個あたり約100バイトの情報量を持ちます。したがってドレス1着分なら6.4キロバイト、キャラ1人あたりドレス6着で38.4キロバイト、チームには4人居るから153.6キロバイト、10個小隊を編成すれば1.53メガバイトです（同じIDのドレスを参照していてもドレスノートは重複します）。
ららマジのストーリー・ステージ選択画面、階層遷移では430キロバイト程度のダウンロードが毎度発生するし、フレンド・ヘルパー選択画面ではリフレッシュの度に1.5メガバイト弱のダウンロードを走らせているとみえる(さすがにヘルパー選択画面内での階層上下には通信がない) pic.twitter.com/vjG9RUuZ6H
— 稲葉 (@eps_r) 2019年10月24日
ステージ準備画面（ヘルパー選択画面）の応答データでは、画面のオモテに現れないはずのこうしたドレスノートなどの仔細をなぜか内包していたと考えられます。このため画面遷移は極度に遅くなり、イベントなどの混雑時にはサーバーや通信経路の帯域を食い潰すようなタイムアウトがしばしば起こっていました*3。
裏を返せば、10チームすべてを実戦的な編成にはせず、キャラを減らし、ノートを解放していないドレスだけで「空きチーム」を組めばデータの増加を遅らせることもできてしまう。データの伸び縮みが激しすぎる印象です。
……というのが通信量監視ソフトなどから推測した起こっていた事の話で、前回の記事（同じことを書いているので読まなくていいです）のおさらいでした。
「ずっとも」になれない！
ここからは起こらなかった事を検討します。
注目すべきはキズナLv（親愛度）に応じてサブドレスの装着スロットが開放されるという仕様と、画面上で10個まで用意だけはされていた空きスロットの存在と……。
そして、キズナLvは「仲間(Lv13)」が到達上限であり、「いないと寂しい(Lv16)」「ずっとも(Lv19)」「親友(Lv22)」「大切な人(Lv25)」「？？？(Lv28)」の解放予定は未定のままだったという事実です。
なぜキズナLvとサブドレススロットはリリースされなかったのか？ ゲームバランス調整など運用上の工数も当然考えられますが、しかし理由として大きいのはやはりデータ量とタイムアウトではないでしょうか。
この記事の前半では、「チームにセットされているドレスの、解放済みドレスノートが多いほどデータ量が膨らむ」という構造を示しました。ならばキャラクターあたりの装着可能ドレスが増えていくと、データも合わせて肥大化するのが道理です。
| 1人あたり装着数 x 編成 x チーム数 | ドレスの数 | ドレスノートの数 | データサイズ |
|---|---|---|---|
| ドレス6着 x 4人 x 10チーム | 240 | 15,360 | 1,536,000byte |
| ドレス7着 x 4人 x 10チーム | 280 | 17,920 | 1,792,000byte |
| ドレス8着 x 4人 x 10チーム | 320 | 20,480 | 2,048,000byte |
| ドレス9着 x 4人 x 10チーム | 360 | 23,040 | 2,304,000byte |
| ドレス10着 x 4人 x 10チーム | 400 | 25,600 | 2,560,000byte |
| ドレス11着 x 4人 x 10チーム | 440 | 28,160 | 2,816,000byte |
全チームが実戦的な編成であれば、データ量の推定値は実に2.8メガバイトにのぼります。たかが出撃準備画面ひとつに3メガ近いダウンロードが発生するのは強烈なゲーム体験と呼ぶほかなく、外出先で軽く周回するだけで月のデータ利用枠を食い潰す……なんて話が冗談になりません。
結論はこうです。
エンドコンテンツの深化に向けて、キズナLv（≒装備スロット）の拡張は動作としては可能であり予定もされていたが、「通信量が膨らむ」というユーザー体験・サーバー帯域等の限界に突き当たり、無期限の延期に至ったのではないか。
多くの運営型ゲームの目指すところの「ゆるやかなインフレ傾向」の行く先のひとつが、実はあらかじめへし折られていたとしたら。このデータ量問題は表面上のユーザー体験以上に、開発運営にとってのゲームデザインに影を落とし続けたのではないでしょうか*4。
余談ですが、これに近いことはドレス一覧画面やドレス着脱操作など多くの画面で「所持中の全ドレス・ドレスノートのデータが毎回ダウンロードされる」挙動として確認されており*5、要するに、全体的に、長くしっかり遊んでいるプレイヤーほど一直線に体験の悪化するゲームでした。長く運営することを目標とするタイトルにあってヘビーユーザーに新カードを取ってもらうのをメインの収入源としていた以上、そうすればするほど強い不利益を受けるなどという悲惨さが修正されなかったのだから、ある意味では「先のないシステムが終わるべくして終わった」という言いかたはできます。
以上です
ここまで言うからには自分だったらどうするか。通信量だけで言えば返却データをコンパクトに整形するのが正道として*6、邪道としては編成可能チームを3くらいまで減らすとかでしょうか。いずれにせよ怠慢だとか技術力が低いとか言いたいのではなく、起こったことには致し方ない理由や事情があり、そしてたかがデータダウンロードに見えても色々な工夫や落とし穴があるねというスクメロの回と全く同じ結論になってしまいますね……。
と同社後続タイトルでは直っているであろう胡乱なことをブツブツと書いてきましたが、サービス終了後もららマジは変わらず応援しております。ノベライズ版は書籍・電子のセットに出資しました。グッズやクラウドファンディング、噂の聞こえてくる中国版など、ゲームが終わっても今後のプロジェクト展開に一層の実りがありますよう祈っております。
*1:「引き直し」という意図がはっきりしていた以上、ドッカンテーブルのごとき表示上のバグなど吹き飛ぶレベルで悪質じゃないのか、と個人的には思っています。
*2:実際のデータ構造として内包されているか（Object-in-Objectのようになっているか）は本題ではないし、確認していません。
*3:いわゆるソーシャルゲームの、ステージ1周あたりに必ず呼ぶAPIで1メガバイトを超える通信を行う例はかなり珍しいと感じます。また多くのタイトルでは、大量のデータをAPIに載せると予期される場合は通信内容を圧縮するのが一般的です。本作でもgzip圧縮の跡はありますが、圧縮前から暗号化により見かけ上の情報量が限界近くまで激増しているため意味をなしていません。
*4:キズナLvの上限だけ先に解放して（ストーリーだけ進展させて）おいて、スロットの拡張を後回しにすれば「ズッ友」にはなれたと思いますが、それは根本的な解決ではない……。
*5:他にも「ステージ一覧は裏で期間限定ベントを含む全ステージのクリア情報をダウンロードしているらしい動きをする」など、チューニングの微妙な箇所は多かったようです。
*6:ローカルキャッシュを活用するというのが第一として、後はおそらくノートのレコードをそのまま返しているところを、画面によっては返さないようにするとか、必要だとしてもノートで増幅されるパラメータの合算値で返すとか、解放済みノートIDの配列で返すとか、方法そのものは幾つか思いつきます。暗号化のせいでgzip圧縮が全くと言っていいほど効いてないのを改善するのも有りだと思う。
