8月21日～23日にわたって開催の「CEDEC2024」。ここでは、8月23日に行われたセッション「ユーザーの記憶に深く残るソーシャルゲームの終わらせ方 ～ユーザー自身がお墓に入る？！唯一無二のゲーム体験とそれを支える技術のはなし～」の内容をお届けする。
登壇者はポケラボより高田美里氏、悦田潤哉氏。2024年1月にサービス提供を終了した「シノアリス」は、メインストーリーの終了と同時にサービスを終了する、という新しいソーシャルゲームの終わらせ方や、エンディングを魅せるための演出や工夫、さらに今まで「シノアリス」をプレイしたことのない人でもストーリーの最後まで楽しんでもらうための施策も話題になった。
また、「シノアリス」から「シノアリスだったナニカ」となったアプリはサービス終了後でも各ストアからインストールすることが可能で、アプリ内でエンディングに到達したユーザーたちの足跡が見られる機能は、ソーシャルゲームの終了後の新しい形としてユーザーから好評の声が上がっている。
本セッションでは、サービス終了間際の運営チームが人員リソースを増やせない中どのようにタスクマネジメントを行いリリースまで行ったのか、リターンユーザーのための施策、エンディングを実装していく上で苦労したエンディング施策の仕様と実装、運営の想定以上にアクセスが来てしまった場合を考慮して用意していた施策の話が紹介された。
「シノアリス」から「シノアリスだったナニカ」にたどり着くために
「シノアリス」は、そもそも立ち上げ時からきちんとエンディングを作る構想があった。そのため、サービス終了告知キャンペーンなどを行い、エンディングをお祭り騒ぎにしていこうという施策を行った。
エンディングの告知から2か月後に、最終章となる「ヨクボウ篇」がリリース。ユーザー自身の手でシノアリスを終わらせるというのがテーマだったので、シノアリス自体がどんどんと壊されていくような流れになっている。
6年半、毎日コロシアムをやってきたギルドメンバー全員で同じ時にエンディングに挑み、これをクリアすると「シノアリスだったナニカ」になるという、熱い施策になっているのだ。「シノアリスだったナニカ」は自分のプレイデータなども見られる、「シノアリス」のお墓である。
だが、エンディングを見るために必要なヨクボウ篇まで、普通にテキストを最初から読んでいくと、およそ16時間ほどかかる。「エンディングが見てみたい」という新規ユーザーには厳しいこともあり、ユーザー救済施策としてSKIP機能を実装した。
ただしSKIP機能はあくまで裏技なので、ユーザーに気付いてもらうのを待ったそう。そしてサービス終了まで残り2週間というところで、暗号を解くことで裏技がわかるようになるポストをXで公開した。
このSKIP機能が認知されてからはかなり活用され、サービス中にエンディングに到達するユーザーが増えたという。
ギルドレイドでエンディングを迎えるために
ギルドレイドは最大15人でボスを討伐するレイドコンテンツで、今回のエンディングではギルドメンバー全員でメインストーリーを同時進行してもらうため、アウトゲームからユーザー同士の同期が必要だった。
エンドロールは動画形式なので、動画が始まるタイミングが合えば、終わるタイミングも同じになる。なので、今回は下図の赤枠部分をどうするかを考慮。
特にアプリ落ちしたユーザーがいた場合、どのように復帰するかなどを考慮し、Firestoreを利用することに。今回のエンディング施策ではDAUの増加を狙ったものの、開発時期にはどの程度増加するのか予想がつかなかったため、負荷への対策が容易だったことが選定の理由だという。
アウトゲームで進行を同期させることは初だったため、特に復帰処理についてはUXを損なわせないよう、誰がどのタイミングで落ちたかによって復帰ポイントを変えるという点に気を配ったそうだ。
さらにギルドメンバー全員でエンディングを迎えるために、サーバーが落ちないようにログイン制限も実施。予算的な限界もあるため、アクセスをコントロールする必要があった。
全APIを対象としてリクエスト数をカウントし、レート制限がかかった時にブロックするのはログインAPIのみ。アクティブギルド所属であれば制限中でもログインAPIを叩ける。リアルタイム性は妥協できるとし、この要件を念頭において、API Gatewayによるレート制限、WAFによるレート制限、PSP＋キャッシュ、CloudWatch＋Batch＋CDNによるログイン制限の4つを検討し、メリットデメリットを考慮した結果、今回はCloudWatch＋Batch＋CDNによるログイン制限が採用された。
想定と異なる様々な出来事をクリアして、オンスケリリースを目指すために
エンディング施策は、季節イベントや周年イベントなど通常施策の開発と平行して進める必要があった。それでも現在のエンジニア数を考慮すれば余裕、くらいのスケジュール感でいたのだが、実際にはそんな上手くはいかず、予定していたよりも少ない人数で開発することになってしまった。そのため、必要工数と確保できる工数のギャップを埋める必要があった。
タスクと実際の工数が合わないときには、タスクマネジメントの基本に忠実に沿って対応すること、全体像の把握をすること、大きすぎるタスクは見えなくなるので小さいパーツに切り出して工数を確認することなどを実施。
また、プランナーの数も当初より少なくなってしまっており、仕様がなかなか定まらなかったという。それでもリリース日が確定している場合、どういうことを実現したいのか一番のコアを明確化すること、それを実装するための工数出しを行うこと、懸念事項などプランナーだけで仕様を策定できない箇所はエンジニアがフォローすることなどを実行した。
このような状況でどのように遅延なしで実装しきれたのかというと、一番の理由はマイルストーンの設定だったという。
2週間単位でプレイ会を行い、マイルストーンと実際の進捗がズレた時に、ならば次のプレイ会でみれるようにするにはどうすればいいかなどを、密にコミュニケーションすることができた上に、定期的に実機で動いているものを目にすることで不安を一掃できたのも大きかったそうだ。
結果、途中で不安視されたエンディング施策は全てオンスケでのリリースが可能となったのだった。
CEDEC2024公式サイト
https://cedec.cesa.or.jp/2024/
(C) 2017-2023 Pokelabo Inc./SQUARE ENIX CO., LTD. All Rights Reserved.
本コンテンツは、掲載するECサイトやメーカー等から収益を得ている場合があります。
