ある世代のゲームユーザーであれば、ビデオゲームを商品としてとらえがちです。かつては、パッケージ版のゲームソフトを購入し、家に持ち帰ってインターネットに接続されていないゲーム機でプレイするというのが、購入体験でした。

最近のゲームは大きく違い、商品というよりサービスのようなものになっています。店頭で物理的に入手するものから、サイトやプラットフォームでオンラインダウンロードするという提供方法の変化だけでなく、ゲームの実際のデザインや構成は、常にオンライン接続された方式を支持しています。最近のゲームは、セーブポイントをクラウドにアップロードする機能のためだけに、インターネットに接続する必要があります。

しかし、その違いはもっと深いところにあります。ビデオゲームのデザインにインターネットの使用が最初から備わっていることから、Live Operations」を短縮した「LiveOps」という言葉が生まれました。LiveOpsの革命はビデオゲーム業界を完全に変え、世界中のゲーム開発者にチャンスとチャレンジの全く新しいエコシステムをもたらしました。

LiveOpsの定義

LiveOpsとは、簡単に言うと、ゲームソフトがサービスを開始した後、つまり、ダウンロード公開され、ユーザーがプレイを開始した後の管理プロセスのことです。これは、何らかのインターネット接続が可能な、最近のゲームの大半に限った話です。不具合の修正、新機能、期間限定コンテンツ、限定特典・機能、ユーザーフィードバックに基づくコンテンツ、既存機能の調整などゲームの開発者の目標や構想に応じて、LiveOpsには1つ以上の要素に影響を及ぼすことができます。これらのアップデートを実施するためには、ゲーム開発と品質保証のチームが必要です。

かつてLiveOpsの機能は、ゲーム発売後の不具合の修正だけに限定されていました。インターネットに接続により、パッチの配信は比較的簡単で、ゲームを起動して修正プログラムのダウンロードとインストールを待つだけでよかったのです。これは明らかな利点のように見えました。PCゲームのプレイヤーは、これまでパッチを探し、ダウンロードし、手動で適用する必要がありましたから。しかし、開発者は、今後修正パッチをリリースできると理解した上で既知の問題を含むゲームをリリースし非難を浴びたことがあります。このやり方は、最初から明らかな問題があるゲームをプレイするよりも、もっとしっかりと動くゲームの発売を望むプレイヤーから、コミュニティ上で多くの批判を呼びました。

そのうち、LiveOpsは今日のようになっていきました。開発者は、ゲームの最も基本的なバージョンを最初にリリースし、プレイヤーの評判に基づいてさらなるコンテンツの追加やアップデートをしていくようになったのです。このようなコンテンツには、新しい外見を実装するキャラクタースキン、実際のゲームプレイに影響を与えるアイテムや武器、さらにはゲームの環境やプレイスタイルに大きな影響を与えるゲームの全体的な見直しなどの要素が含まれます。最初のリリースは現在では「ストック型」のコンテンツとされており、それ以降のアップデートなどはゲームに飽きさせないためのものです。多くの場合、これらのアップデートは、プレイヤーが支払うであろう月額課金以外の追加収入をもたらすために収益化されています。

LiveOpsゲームの例

LiveOpsの初期の例として、モバイルゲーム向けの『Bingo Bash』現在はScopelyが所有、2011年にAndroidとiOSでリリースされたもの）があります。『Bingo Bash』は、オンラインカジノのビンゴゲームです。発売当時の『Bingo Bash』は、必要最低限のビンゴのゲームプレイメカニズムを備えていました。現在、このゲームは既存の追加コンテンツが豊富で、積極的なLiveOpsの更新（変更がリリースされる頻度）があり、アップデートや新しいコンテンツが2、3週間に一度という頻度でリリースされています。

より顕著な例としては2012年にBlizzard Entertainmentから発売された『ディアブロ Ⅲ』が挙げられます。現在のこのゲームのバージョンには多くのコンテンツがあり、多くの変更が加えられているため、このIPの人気や熱心なファン層がいるという正しい証明となっています。また、『Diablo Ⅲ』は「オークションハウス」を搭載して発売されたことが有名ですが、これはコミュニティからのフィードバックにより、後にゲームから削除された大きな機能です。現在、ゲームそのものは、初心者にもわかりやすく、かつ長期的なファンが何度も戻ってくるようなやりがいのある、きめ細かなRPGになっています。その他、超人気ゲームである『Fortnite』、『エーペックスレジェンズ』、『クラッシュ・オブ・クラン』などは、パブリッシャーが新しいコンテンツと共にゲームをアップデートし、ゲームをより長く運営していくためにLiveOpsを活用するさらなる例となっています。同時に、これらの本質は、コアとなるゲームプレイのバランスを崩さないように注意しなくてはならないということです。

LiveOpsにおけるコミュニティの重要性

開発とプレイヤーはいつでも本質的に繋がっているにもかかわらず、LiveOpsがプレイヤーから切り離され、純粋に開発者にフォーカスされた流れであった時代から、明らかに業界は脱却しました。一般的に、ゲームの健全性と成功は、プレイヤーの積極的な参加に依存します。しかし、 コミュニティの影響力の真の効果は、近年になってようやく重要視されるようになりました。ゲームによっては、コミュニティの幸福度によって成功か、失敗かが決まるものもあり、特に早期アクセスのあるゲームでは、プレイヤーの意見が重要なカギとなります。

プレイヤーは、大好きなゲームに最高のものを求めていて、現行のバージョンと、その改善に貢献することは、プレイヤーにとってLiveOpsの重要な要素となっています。。『モンスターハンター』や『ドーントレス』のようにゲームのロードマップが共有されるなど、誰もが確認できる場所での開発者からの情報は、プレイヤーにとってありがたいものです。また、開発者の配信やプレイセッション、AMA（Ask Me Anything の略、ライブ形式の質疑応答）のように、ゲームに直接影響を与える提案やフィードバックができることで、自分の意見を聞いてもらえたとプレイヤーは感じます。そのうち、繰り返されるフィードバックの傾向によって、開発者は、定期的な季節のイベント（例えば、『GTAオンライン』内での雪や『Fortnite』のお祭りのような競技イベント）などの、プレイヤーが本当に楽しんでいるものを知ることができます。

また、プレイヤーの意見やアイデアを聞くことで、重要な不具合報告にも役立ちます。これは、開発者、ゲーム、そしてプレイヤーの間で相互に影響し合う健全なフィードバックループの重要な部分になっているのです。

LiveOpsが適する所

どんなゲームでも、そのライフサイクルにLiveOpsを組み込むことができます。ただし、ゲームによっては向いているものもあります。小規模な、ストーリー重視のゲームやキャンペーンモードしかないゲームでは、LiveOpsは不具合の修正や小規模なバランスパッチ、不定期な新コンテンツのアップデートに限られる傾向があります。よりオープンエンドで、長期的なプレイヤーの維持を念頭に置いて作られたゲームは、強固なLiveOpsパイプラインを持つ傾向があるのです。

LiveOpsは、競争が激しいモバイルプラットフォームで多く普及しています。ほとんどのゲームやアプリは無料で公開されているため、開発者がお金を稼ぐには、広告やアプリ内課金、そしてユーザーに繰り返しゲームに戻ってきてもらい、課金で収益を最大化する方法しかありません。新しいコンテンツを頻繁に追加し、プレイヤーの関心に応えることで、開発者はユーザーを長期的に維持し、収益化できる可能性が高くなります。このマネタイズモデルは、モバイルから漏れて、他のプラットフォームにも広がっています。

コミュニティの観点からは、マルチプレイゲームや定期的なコンテンツ更新があるオープンワールドゲームなど、“公開”のLiveOpsプロセスが他のゲームよりも有益である場合があります。非常に込み合ったロードマップを持つゲームでは、プレイヤーコミュニティとのオープンなコミュニケーションが非常に有効なのです。との効果的なフィードバックループを活用してプレイヤーの知見を収集し、プレイヤーの意見収集を促進する透明性の高い変更を提供することで、より長期的な報酬とアドボカシーを構築します。

一方、最小限のアップデート（重要ではない小さな修正、調整、変更）が非常に長い期間にわたって行われるゲームは、プレイヤーを待たせすぎて、興味やゲーム離れにつながることがあります。特に、過剰に期待された要素が期待外れだった時には、コミュニティは意気消沈し、コミュニティの健全性と維持に悪影響を及ぼすでしょう。

ゲームにLiveOpsを統合することを検討する場合には、初期の計画段階から念頭に置いておきましょう。開発ロードマップは、ゲームのリリース前にLiveOps特有の要件を考慮に入れなければなりません。そうしないと、さらに先の問題を招くことになります。

LiveOpsの技術的な側面

ゲーム業界では、コミュニティからのフィードバックはLiveOps初期から存在する要素 であるため、開発者はLiveOpsのエコシステムで経験しうるすべての技術的な課題を認識することが重要です。技術的課題の中には不具合の修正などがあります。不完全なパッチを導入してしまうと、技術的な問題がさらに引き起こされるだけでなく、プレイヤー層を憤慨させてしまう可能性があるため、実装前に徹底的にテストしなければなりません。他にも、新機能の導入は刺激的ですが、設計が不十分だと既存の機能を壊す可能性がありますし、プラットフォーム要件は一見任意で変更できそうですが実際はそうではありません。広告SDKを統合すれば開発者側に大きな収入源となるため、複数の広告SDKや広告集約の仕組みを統合することもありますが、適切に計画しなければ複雑な問題になり得ます。

その他、技術的な側面が方向性の決定やロードマップの更新に影響する要素には以下のようなものがあります。

分析: 積極的に有用なフィードバックを提供してくれるのは、ゲームコミュニティのごく一部だけです。そのため、これだけを分析するのは信頼性に欠ける方法です。コミュニティからのフィードバックは詳細でない場合が多いため、実際にアクションを起こすまでには至りません。信頼性の高いデータを得るためには、あらゆる状態を追跡してサーバーに保存（パッシブフィードバック）できるツールを、開発側で組み込みましょう。このデータを分析することで、開発者はプレイヤー層の実際の行動を把握し、今後の判断材料にすることができます。LiveOpsを重視するゲームでは、最もよく使われるツールだと思われます。

クラッシュの分析: どんなに優れた技術で作られたゲームでも、ゲームのクラッシュは避けることができません。クラッシュを特定するには、開発者がゲームにコードを組み込み、クラッシュをリモートサーバーに記録して、後のアップデートで分析・修正できるようにします。

プレイヤーのセグメント化: これは、開発者が特定のプレイヤーグループだけを対象とする際に使用する重要なツールです。例えば、あるゲームの機能を特定の地域のプレイヤーにのみ表示する必要がある場合、セグメント化ツールを統合することで実現できます。別の例では、提案された新機能が非常に実験的なものである場合、開発者はそれを少人数のグループにのみ公開し、分析によってその反応を確かめられます。その結果を受けて、フルリリースを進めるか、必要に応じて変更を加えるかを決めるのです。

A/Bテスト: このテストは、ある選択肢を他の選択肢と比較してテストする必要がある場合、あるいは複数の選択肢についてテストする必要がある場合に、開発者の重要な武器となるものです。プレイヤーのセグメント化を補完してくれます。例：クリスマスに同じように良いテーマを2つ実装したが、どちらをリリースするのが良いか分からない場合、それぞれのテーマをどちらかのプレイヤー層に限定的に提供できる。開発者は、どのテーマが最もポジティブなフィードバックを受けたか（分析されたもの）により、どのテーマを採用するかを選択できます。

サーバーサイドの構成: 理想を言えば、開発者は新機能や変更をできるだけ早くリリースしたり、テストしたりしたいものです。しかし、プラットフォーム（AppleのiOS App Store、Google Play ストア、Steamなど）に提出し、新しいゲームクライアントが承認されるまでのプロセスには、恣意的に長い時間がかかります。これを避けるために、開発者はゲームにツールを組み込み、サーバーから小さな設定ファイルをダウンロードした後にゲームプレイ体験が変更されるようにします。同じゲームクライアントでも、設定ファイルのデータによって動作が異なることがあります。これにより、開発者はプラットフォームに再提出することなく、ゲーム体験に小さな、あるいは大きな変更を加えられます。この設定ファイルは、ゲームクライアントを起動するたびにダウンロードすることも、一定の間隔でダウンロードすることも可能です。

LiveOps の責任

関係者にとってLiveOps の価値を確認をすることは簡単です：常に更新されるコンテンツでゲームを新鮮に保つことで、既存のプレイヤーを呼び戻し、新しいプレイヤーを惹きつけることができるのです。これにより、開発者はROIを最大化することができるのです。

しかし、これには、開発者やパブリッシャーがシステムを悪用しないようにするという責任も伴います。単にコンテンツの充実を約束するだけでは不十分で、そのコンテンツは、プレイヤーが何度も訪れたくなるような刺激的なものでなければなりません。また、コミュニティの観点から、プレイをする空間は安全で居心地の良いものであるべきです。開発者は、ハッカーや仲間を食い物にする荒らし、自分たちに有利なようにシステムを操作しようとする人たちを監視し、改善することでこれを達成することができます。また、開発者はSNSや活発なフォーラムを通じてプレイヤーの声に耳を傾け、好意的な意見と悪い意見の両方を把握することが良いとされています。この点、ゲームの機能や反復に直接貢献できる機会があれば、コミュニティはスムーズで意味のあるLiveOpsに大きな期待を寄せることができます。

フィードバックのループ：アップデートがリリースされ、コミュニティがそのアップデートの反響を開発者に伝え、開発者がコミュニティのフィードバックを考慮して次のリリースを行う、このサイクルが繰り返されるのです。理想ですが、適切に実行されれば、両者が満足し、ゲームの寿命が延びるという健全な共生関係になります。

LiveOpsのプロセスにコミュニティを巻き込むことで、開発者と、お気に入りのゲームにベストを尽くしたいと願う、熱心で親切で賢いプレイヤーたちとの間で、有機的で信頼性の高いコミュニケーションが可能になります。構築されたものがコミュニティのために機能することを確認するための機能や項目に焦点を当てたテストにつながることがあります。全体として、すべてのパブリッシャーの最終的な目標である、ゲームが長期にわたって存在することを保証することができるのです。

まとめ

LiveOpsは、今やゲーム業界では定着しています。開発者にとっては、ライブゲームをサポートし、プレイヤーコミュニティを喜ばせるための強力なツールになります。しかし、適切に対処しなければ、LiveOpsはプレイヤーベースを蔑ろにし、ネガティブなフィードバックや他のゲームへのユーザー離れにつながる可能性もあります。ゲームのコミュニティとは関係なく、LiveOpsは設計プロセスの最初の段階で慎重に計画し、エラーや障害を回避する必要があります。LiveOpsは、開発者やパブリッシャーが製品としてのゲームに対する考え方を変え、ゲームタイトルの寿命をかなり長く延ばし、その結果、投資に対するリターンを得る機会もより長く持続されます。

業界をリードするゲーム開発,プレイヤーサポート、そして品質保証のサービスなどでお客様のゲームのLiveOpsをサポートする方法についてはこちらにお問い合わせください