技術的限界で「ズッ友」になれません――『ららマジ』にみる仕様の衝突

『シン・エヴァンゲリオン劇場版:||』良かったですね。これはネタバレではないと思いますが、当時TV版に対して「なんだか分からないけど面白い番組が、最終回だとすら気付かないままなんとなく終わっていた……」と思った子供としては、あんなに面倒なものを終わらせることができた、終わらせてくれただけでまずは最高だと感じていますし、話を畳めないままに最終回ということにしなくちゃならないタイトルは世の中にごちゃまんとあるのでした。

f:id:appalerm:20210316235857p:plain

ズッ友(正式表記「ずっとも」)にも、なれなかった……。


f:id:appalerm:20200603174552j:plain

f:id:appalerm:20200603174213j:plain

去る2020年6月3日、ついに『ららマジ』のサービスが終了しました。開発のWright Flyer Studio改めWFS社にはガチの確率操作だったアナザーエデン事件のツケを今からでももっと真面目に払うべきではないのかと思っていますが*1、それは置いても色々と惜しいタイトルでした。暫定最終回イベント「ホニャららDREAM」のストーリーは本当に面白かった。

ただ記事タイトルの通り、今日するのはイベントの話でも写真の村山下貯水池第一取水塔の話でもないです。

f:id:appalerm:20210317001800p:plain

本作は一部プレイヤーの間で「データ通信量が多すぎる」「タイムアウトエラーが多すぎる」という苦情を抱えていました。今回は1年3ヶ月ほど前の読みづらいエントリのリライトとして、ららマジに何が起きていたのかをそこそこ分かりやすく説明するつもりになり、また何が起こらなかったのかを指摘していきます。

いや、サ終タイトルの不備なんてそんな死んだ子の歳を数えるような、後知恵で人の仕事をつつきまわす真似はいかがなものかと私も思うのですが。

ららマジはこんなゲームでした

f:id:appalerm:20210316231503p:plain

改めて『ららマジ』は、東奏高校・器楽部の生徒たちを編成し、彼女たちに「ドレス」と呼ばれるカードを装備させて戦う横スクロールアクションゲームです(……でした)。

キャラクター自身は戦闘パラメータを持たず、ドレスの組み合わせが戦闘能力になる仕組みを採用しています。

f:id:appalerm:20210316232334p:plain

1チームには最大4名を編成し、ステージセレクトの際に他プレイヤーからヘルパーキャラを借りて5名でゲームを開始します。

また上の画面では左右スワイプでチーム編成を切り替えることができ、10チームまでの編成を保存できます。

f:id:appalerm:20210316231704j:plain
ららマジ MPについて考える | クマー(・ω・)より)

編成中キャラクター詳細画面。画面上部に大きく表示されているのが操作キャラとなる必須のメインドレス、下部に「通常ドレス」「イベントドレス」と書かれているのが能力を底上げするサブドレスとなります。

サービス運営当時、キズナLv(キャラクター親愛度)は13まで解放され、サブドレスのスロットが5個まで使えるようになっていました。

f:id:rarasymphony:20180201131424p:plain
ドレスノートって何? - 【ららマジ】アンサンブルを奏でたいより)

それぞれのドレスは経験値などの付帯情報を持つ他、ドレスノートと呼ばれる最大64個前後のスキルツリー・アンロック要素のリストを持っています*2。これは解放数が多いほど増える可変長のデータです。

  • チーム(x 10)
    • キャラクター(x 4)
      • キャラクターの付帯情報(キズナLvなど)
      • メインドレス(x 1)
        • ドレスの付帯情報(経験値など)
        • ドレスノート(x 64)
      • サブドレス(x 5)
        • ドレスの付帯情報(経験値など)
        • ドレスノート(x 64)

したがって「チームの編成」とは、ざっくり上記のような階層構造で表せます。

大きすぎる通信データサイズの内訳を検討する

階層構造を簡単な図に開いてみます。

f:id:appalerm:20210317003505p:plain

図の右下に、チーム1個分に必要なデータ量をラフな実測に基づき追記しているのですが、1カラムあたり数バイト~十数バイトで済んでいるはずの他のデータに対してドレスノートだけが異常に大きいため、実質的にはチーム編成のデータ量≒ドレスノートの数とであると言えます。

実際に計算していきましょう。

単位 ドレスの数 ドレスノートの数 データサイズ
ドレスノート1個あたり - 1 100byte
ドレス1着あたり 1 64 6,400byte
キャラ1人あたり 6 384 38,400byte
1チームあたり 24 1536 153,600byte
10チームあたり 240 15360 1,536,000byte

ドレスノートはなぜか1個あたり約100バイトの情報量を持ちます。ドレス1着分なら6.4キロバイト、キャラ1人で38.4キロバイト、チームには4人居るから153.6キロバイト10個小隊を編成すれば1.53メガバイトです(同じIDのドレスを参照していてもドレスノートは重複します)。

ステージ準備画面(ヘルパー選択画面)の応答データでは、画面のオモテに現れないはずのこうしたドレスノートなどの仔細をなぜか内包していたと考えられます。このため画面遷移は極度に遅くなり、イベントなどの混雑時にはサーバーや通信経路の帯域を食い潰すようなタイムアウトがしばしば起こっていました*3

f:id:appalerm:20210317001845j:plain

裏を返せば、10チームすべてを実戦的な編成にはせず、キャラを減らし、ノートを解放していないドレスだけで「空きチーム」を組めばデータの増加を遅らせることもできてしまう。データの伸び縮みが激しすぎる印象です。

……というのが通信量監視ソフトなどから推測した起こっていた事の話で、前回の記事(同じことを書いているので読まなくていいです)のおさらいでした。

「ずっとも」になれない!

ここからは起こらなかった事を検討します。

f:id:appalerm:20210316231704j:plain
ららマジ MPについて考える | クマー(・ω・)より)

注目すべきはキズナLv(親愛度)に応じてサブドレスの装着スロットが開放されるという仕様と、画面上で10個まで用意だけはされていた空きスロット……。

f:id:appalerm:20210316235857p:plain

そしてキズナLvは「仲間(Lv13)」が到達上限であり、「いないと寂しい(Lv16)」「ずっとも(Lv19)」「親友(Lv22)」「大切な人(Lv25)」「???(Lv28)」の解放予定は未定のままだったという事実です。

なぜキズナLvとサブドレススロットはリリースされなかったのか? ゲームバランス調整の工数など運用上の理由も考えられますが、大きいのはやはりデータ量とタイムアウトではないでしょうか。

この記事の前半では、「チームにセットされているドレスの、解放済みドレスノートが多いほどデータ量が膨らむ」という構造を示しました。ならばキャラクターあたりの装着可能ドレスが増えていくと、データも合わせて肥大化するのが道理です。

1人あたり装着数 x 編成 x チーム数 ドレスの数 ドレスノートの数 データサイズ
ドレス6着 x 4人 x 10チーム 240 15360 1,536,000byte
ドレス7着 x 4人 x 10チーム 280 17920 1,792,000byte
ドレス8着 x 4人 x 10チーム 320 20480 2,048,000byte
ドレス9着 x 4人 x 10チーム 360 23040 2,304,000byte
ドレス10着 x 4人 x 10チーム 400 25600 2,560,000byte
ドレス11着 x 4人 x 10チーム 440 28160 2,816,000byte

全チームが実戦的な編成であれば、データ量の推定値は実に2.8メガバイトにのぼります。たかが出撃準備画面ひとつに3メガ近いダウンロードが発生するのは強烈なゲーム体験と呼ぶほかなく、外出先で軽く周回するだけで月のデータ利用枠を食い潰す……なんて話が冗談になりません。

結論はこうです。

エンドコンテンツの深化に向けて、キズナLv(≒装備スロット)の拡張は動作としては可能であり予定もされていたが、「通信量が膨らむ」というユーザー体験・サーバー帯域等の限界に突き当たり、無期限の延期に至ったのではないか。

多くの運営型ゲームの目指すところの「ゆるやかなインフレ傾向」の行く先のひとつが、実はあらかじめへし折られていたとしたら。このデータ量問題は表面上のユーザー体験以上に、開発運営にとってのゲームデザインに影を落とし続けたのではないでしょうか*4

余談ですが、これに近いことはドレス一覧画面やドレス着脱操作など多くの画面で「所持中の全ドレス・ドレスノートのデータが毎回ダウンロードされる」挙動として確認されており、要するに、全体的に、長くしっかり遊んでいるプレイヤーほど一直線に体験の悪化するゲームでした。運営の長いタイトルにあってヘビーユーザーに新カードを取ってもらうのをメインの収入源としていた以上、そうすればするほど強い不利益を受けるなどという悲惨さが修正されなかったのだから、ある意味では「先のないシステムが終わるべくして終わった」という言いかたはできます。

以上です

ここまで言うからには自分だったらどうするか。通信量だけで言えば返却データをコンパクトに整形するのが正道として*5、邪道としては編成可能チームを3くらいまで減らすとかでしょうか。いずれにせよ怠慢だとか技術力が低いとか言いたいのではなく、起こったことには致し方ない理由や事情があり、そしてたかがデータダウンロードに見えても色々な工夫や落とし穴があるねというスクメロの回と全く同じ結論になってしまいますね……。

と同社後続タイトルでは直っているであろう胡乱なことをブツブツと書いてきましたが、サービス終了後もららマジは変わらず応援しております。ノベライズ版は書籍・電子のセットに出資しました。グッズやクラウドファンディング、噂の聞こえてくる中国版など、ゲームが終わっても今後のプロジェクト展開に一層の実りがありますよう祈っております。

*1:「引き直し」という意図がはっきりしていた以上、ドッカンテーブルのごとき表示上のバグなど吹き飛ぶレベルで悪質じゃないのか、と個人的には思っています。

*2:実際のデータ構造として内包されているか(Object-in-Objectのようになっているか)は本題ではないし、確認していません。

*3:いわゆるソーシャルゲームの、ステージ1周あたりに必ず呼ぶAPIで1メガバイトを超える通信を行う例はかなり珍しいと感じます。また多くのタイトルでは、大量のデータをAPIに載せると予期される場合は通信内容を圧縮するのが一般的です。本作でもgzip圧縮の跡はありますが、圧縮前から暗号化により見かけ上の情報量が限界近くまで激増しているため意味をなしていません。

*4:キズナLvの上限だけ先に解放して(ストーリーだけ進展させて)おいて、スロットの拡張を後回しにすれば「ズッ友」にはなれたと思いますが、それは根本的な解決ではない……。

*5:ローカルキャッシュを活用するというのが第一として、後はおそらくノートのレコードをそのまま返しているところを、画面によっては返さないようにするとか、必要だとしてもノートで増幅されるパラメータの合算値で返すとか、解放済みノートIDの配列で返すとか、方法そのものは幾つか思いつきます。暗号化のせいでgzip圧縮が全くと言っていいほど効いてないのを改善するのも有りだと思う。