CEDEC2019に行ってきました - Day.1レポート

こんにちは、プログラマのyamauraです。
9月4日〜6日の3日間、ゲーム開発者の祭典「CEDEC2019」が開催されました。
今年は1日目の参加で、最近話題になったスマホアプリ「くまのレストラン」の開発者が語るインディーズゲームでの成功の秘訣や、個人的にドハマリしたスマホアプリ「リンクスリングス」のPhoton活用事例などのセッションを聴講してきましたので、その内容をレポートしたいと思います。

ちなみに去年参加したときのブログ記事はこちらです。
はじめての「CEDEC2018」Day.2レポート - gracetory’s blog

---

ゲームの、そのさらに先へ - 新たな体験の創造に向かって

エンハンス代表取締役: 水口 哲也 様

1990年にセガからゲームクリエイターのキャリアをスタートし、現在は米国法人エンハンスの代表取締役を務める水口氏による、いままでやってきたことの先に見ているゲームの未来についてのお話。

概要

ビデオゲームとは何か？

「テクノロジーと共に進化する体験のメディア」
インターネットやVRなど、時代が進むにつれて新しく登場するテクノロジー。
そうした技術をその時代の夢や欲求に即した形で取り込み、エンターテイメントや遊びに変えていくことこそがビデオゲームの意義。
言語や国境を超え、体験を提供する代表的なメディア。

体験のメディアとしての取り組み

セガの「R360」、NASAの「仮想環境表示システム」からインスピレーションを受けたことでVR信奉者に。
セガに入社後、はじめに取り組んだのは誰にも頼まれていなかったARのプロトタイプ。
携帯ゲーム機ゲームギアに発泡スチロールやミラーを取り付けた試作機を役員会議にもっていくも受け入れられずARを一時的に封印。 その時代がくるまでアーケードやコンシューマゲームの開発に従事。

• セガラリーチャンピオンシップ(1994年)
• スペースチャンネル5(1999年)
• Rez(2001年)

PSPの大きなイノベーション

体験のメディアとして前述の代表的な3作品のほか20本もの開発に携わるも、結局はどの企画も2Dのフラットな画面から抜け出せないことが大変なストレスだった。
そんな折、「インタラクティブウォークマン」というキャッチフレーズとともに登場したPSP(プレイステーション・ポータブル)に強いインスピレーションを受ける。
スマホで当たり前になってはいるが、ゲーム機は今まで音が冷遇されてきていて、PSP以前のコンソール機でイヤホンジャックのついたモノはほとんどなく、いつでもヘッドホンとともにゲームが遊べる体験はPSPからはじまった。

VR元年と「Rez infinite」

2014年、日本ではVRの関心が薄い一方でアメリカでは様々なVRヘッドマウントディスプレイが登場。
これを機にエンハンスを米国法人として立ち上げ、「Res」をVR対応させるとともにVRに特化したステージを追加した「Rez infinite」を2016年にリリース。
本作はVR元年とも呼ばれる同年に初代最優秀VR賞を受賞。
体験プレイヤーの感想で共通していた「言葉でうまく説明できない」という内容はいままでのゲームが表現し得たものではない、新しい体験への反応だった。

泣けるテトリスを作る

「Rez infinite」の次に「テトリスで人を泣かせることができるか」という挑戦を掲げてVRに対応したテトリス「テトリスエフェクト」を開発。
プログラマーがすでに完成されたテトリスにどう手を加えればいいか迷う一方で、アーティスト視点ではいかにエモーショナルにするかという余地があった。
実際にSNSではテトリスエフェクトで泣いたという体験者の投稿が散見し、「解像度が可能にする新しい表現の組み合わせによって、体験が共感覚化していくという流れは、今後強くなっていく。ゲームもアートの領域に入っていく」と直感した。

シナスタジア(共感覚)

「色を聴く、音を見る」など、感覚が複合的に交差するような印象・表現・体験。
解像度が上がり、3Dになり、よりインタラクティブになることでこの感動はさらに深まる。

未来のゲームはどこへ向かうのか？

• つぎの10年で、AR、MRのデバイスは軽量、高解像度、ハイスペックとなり、IOTやAIなどほかのテクノロジーと交わりながら、生活の中に浸透してくる。
• 20世紀は情報の時代でそれが一大産業になったが、これからは体験産業に変わってくる。
• 二次元と四角いフレームの時代がようやく終わり、デザインの考え方も二次元から空間的で体験を前提としたものに変わってくる。
• 結果的に、一人称と三人称がハイレベルで融合して、映画とゲームの真ん中のような、新しいタイプのゲームが出てくるんじゃないか。
• 解像度の進化は頭打ちになる。進化のエネルギーは、感情移入の模索に向かうだろう。
• 600年前に活版印刷が発明されたのと同じくらいの大きな革命。
• ここからの変化はすべて空間的になって体験化していく。

最後に

ゲームはゲームとしてあり続けるが、ゲームだけではなく、ゲームからはじまるものを含めて何が生み出せるのかといった、挑戦的な発想をクリエイター全員が持ったら良いかもしれない。

感想

当時の映像やゲーム画面の動画などを交えた講演は水口氏が「ゲームは体験のメディア」という考えを一貫して具現化していったことが伺え、大変興味深かったです。
ゲームに最先端の技術を取り込んでシナスタジアを実現するという挑戦は水口氏がクリエイターと同時にアーティストであるからこその発想。
ただ単純に自分が楽しいと思うゲームを作る私にはとても考えさせられる内容でした。

Unity C# × gRPC × サーバーサイドKotlinによる次世代のサーバー/クライアント通信 〜ハイパフォーマンスな通信基盤の開発とMagicOnionによるリアルタイム通信の実現〜

株式会社アプリボット: 竹端 尚人様
株式会社Cysharp: 河合 宜文様

Unityでの事例が少ないgRPCや、サーバーサイドの言語としては国内での実績が少ないKotlinをなぜ採用したのか、その理由と実際に導入した上でのノウハウ。そしてCysharp製のOSSリアルタイム通信フレームワーク「MagicOnion」の紹介。

概要

gRPCとは？

• Google製のRPCフレームワーク
• HTTP/2, Protocol Bufferesを標準サポート
• RESTに代わる次の通信方式の1つとして期待されている

gRPCの特徴

• Protocol Bufferesによるインターフェース定義の共通化
• Java, C#, Goなど様々な言語に対応
• 各言語のコード自動生成が可能
• HTTP/2による高速で柔軟な通信

Protocol Bufferesとは？

• 通信のインターフェースを定義できるIDLの一種
• 定義した構造のバイナリデータで通信
• 定義ファイルからインターフェースにに合わせた様々な言語のコードを生成できる

なぜRESTでなくgRPCを採用したのか？（パフォーマンス）

• クライアントはUnity C#、サーバサイドはKotlin
• gRPCはProtocol Bufferes、RESTではjsonを通信のデータ方式とする
• リクエストのシリアライズ、レスポンスのデシリアライズも計測時間に含む

上記の条件でgRPCの場合はリクエストが2倍、レスポンスは4倍速い。

なぜJavaでなくKotlinを採用したのか？

• Javaからの移行コストが低い
• Javaと同等の性能(最終的なコンパイル結果がJavaとほぼ同じ)
• モダンな開発ができる
• 将来性が期待できる(Androidの公式開発言語として採用された)

データダウンロード機構にみるgRPCの注意点

• 大きいデータのデシリアライズはProtocol Bufferesよりjsonのほうが早くなる
• 大きなデータのダウンロードなどはjson文字列で返す
• 基本的には通信回数が増えても細かい単位のデータでやりとりする

MagicOnion

Cysharp開発。 gRPCをC#でラップし、さらにUnityでの動作もサポートしているリアルタイム通信が可能なOSSのネットワークエンジン。

• リアルタイム系だけでなくAPI系も可能
• .NET CoreによるLinuxホスティングと完全なコンテナ対応
• GitHub Starが1000以上と、国内外でも注目度上昇中
• Unity C#も前提として開発されていてC#のためのエンジンとしても高い品質

感想

2019年公開予定のスマホアプリ「世界を解き明かすリズムアクション・SEVEN’s CODE」の開発で採用されている技術について、選定から実装時のノウハウについての具体的な解説。
正直、内容の半分も理解できたか怪しい状態ですが、知見が広がり学びたい意欲が湧いてくるとても有意義な講演でした。
MagicOnionは昨年の12月14日に公開されたクライアントもサーバ開発もC#でやってしまおうというコンセプトのOSSということで、今後どうなっていくのか実はけっこう注目しています。

LAMPで構成されたモバイルゲームのバックエンドのKubernetesへの移行事例

株式会社ＳＮＫ: 泊 久信様/中村 裕也様

新規モバイルゲーム開発の際、アプリのバックエンドとして、旧来のLinux, Apache, MySQL, PHP (LAMP)を用いた構成の旧ゲーム用の実装から、Google Kubernetes Engine (GKE)を活用した構成に少ない手間で作り変えることに成功。実際にリリースされたゲームの事例として紹介。

概要

旧環境の問題点

• 経験や勘に頼る作業を無くし、自動化できるところは自動化して仕事を減らしたい
  • サーバのスケールアップは容易だがスケールアウトは躊躇
  • 障害時のフェールオーバーなど特殊なオペレーションは手動

新規タイトルからKubernetesの導入開始

KOFクロニクル(2019年6月からβテスト)より、旧来のLAMP + Chef構成からKubernetesを使った環境へ移行。
Kubernetesによってインフラ部分の構造を大きく変える一方で、サーバサイドのコードは旧来のPHPで書かれたものを改良・修正することで変更部分を極力減らした。
クラウドはコンテナ運用の実績が長いGCPを選択。
わからないことだらけだったため、エラーが出ては直すという試行錯誤を繰り返した。

• コンテナ化
  • Apache + PHP + プログラム -> 独自作成
  • Memcached, MariaDB, Redis -> Docker Hubのイメージをそのまま利用
  • 外部ライブラリに依存する部分はベースのコンテナを作成
  • アプリのデプロイ時に必要な部分をベースにコピーすることでリリース用のコンテナを作成
• オートスケールの構成
  • ポッド = いくつかのコンテナの集まりで旧環境でいう仮想マシン1台分
  • ノード = GCPでいうVMのことで複数のポッドを導入可能
  • ポッド毎とノードプール(ノードの集まり)にオートスケールを設定する(2段構成)
  • 負荷状況でノード内のポッドが増え、ノードが増えたタイミングで課金が発生する
  • ノードのスケールは明示的に最大数を設定し、不具合などで無限にスケールされるのを防ぐ
• ユーザデータやログなど永続的データはポッドに入れずにマネージドサービスを利用
  • CloudSQL(MariaDB 互換のデータベース)
  • Cloud Memorystore(Redis 互換のサービス)

Kubernetesで動いてから

オートスケールという新しい機能を使い始めた&新しくGCPを使い始めたことで運用の観点で不安が増えたが、結果としては従来環境で手間がかっていた部分(ログ収集・分析、システム監視)が解消できた。

• Stackdriver Logging
  • GCPで作った仮想マシンのログを容量無制限で30日分収集できる
• BigQuery
  • Stackdrive Loggingで収集したログを格納しておき、分析を行う

fluentdでキャッチした標準出力・エラーログ、ファイルログをStackdriveへ渡し、分析対象はBigQueryへ送り、保管目的のログはCloudStorageへ送る。

• Stackdriver Monitoring
  • Kubernetesやグーグルクラウド上の資源のメトリクスを自動収集
  • ログとも連携でき、任意のログでアラートを飛ばせる

まとめ

• オートスケールを中心に、環境の再現性をふくめ多くのメリットがある
• 運用が以前よりはるかに楽になった
• 開発時の使い方やコンテナの仕組みにあわせてプログラマのから協力を得る必要がある
• Kubernetes環境は変化が激しい
  • 来年には今よりさらに使いやすくなっているはず

感想

「経験や勘に頼る作業を無くし、自動化できるところは自動化する」ことを目的として、従来のLAMP環境からKubernetes環境への移行事例をその構成内容から運用、注意点に至るまで具体的な内容をユーモア交えて解説されていて、本当に勉強になりました。
ネットワークやインフラなど低レイヤーの技術は勉強しないとと思いつつもなかなか手が伸びてこない分野だったのですが、業務効率化のためにもしっかりと学ぶべきだと再認識しました。

「リンクスリングス」でのPhoton採用事例および、Photon CTOによる最新サービスPhoton Quantumの紹介

GMOクラウド(株): 萩原 竜二様
株式会社サムザップ: 石井 岳様/二宮 章太様
Exit Games: クリストフ・ウェグマン様

今年の5月にリリースされた対人陣取りスマホゲーム「リンクスリングス」を題材に、Photon Serverの利用用途、GCP上でのPhoton Serverの可用性を突きつめた構成、負荷テストの勘所を紹介。
またすでに海外では好評を博している革命的なネットワークゲームエンジン「Photon Quantum」を日本で初公開！

概要

Photonとその特徴

• マルチプレイを実現するために必要な機能を一通り持っているツール
• サーバとクライアントSDKをセットで提供
• サーバ経由なので接続性が高く、P2Pにありがちな問題が発生しない
• 独自技術による信頼性と低レイテンシーの両方を確保
• クロスプラットフォーム対応
• UnityではAsset StoreからダウンロードするだけでSDKが利用可能

Photon Serverの構成

• メインのバトル部分にPhoton Serverを使用し、マッチングやリザルトは通常のWeb Serverを利用

重視したポイントとトラブルへの対応

• メインコンテンツであるバトルを途切れさせない高可用性
  • データストアをネットワーク上へ移し、マスタサーバを冗長化
• 急な負荷の増大に迅速に対応できるオートスケール
  • 負荷の申告と監視による、人手を介さない最短でのゲームサーバの増減

負荷試験の目的

• 正常に動作することの確認
  • スケールアウト時にCCUがきちんと増えることを確認
  • 長期間高負荷の環境における動作確認
• 効率の良い構成の導出
  • コスパの良いサーバの性能
  • 必要なサーバ数 = サーバ1台あたりの上限CCU

負荷試験の実施

• バトルを大量に行って負荷をかけたい
  • 偽装クライアントを自作して別サーバに大量配置
  • アタック用サーバをスケールして想定CCUを担保
  • Locusによる一斉操作でバトル大量発生
• バトルを模倣した通信シナリオをどう作るか
  • サーバで取得したプレイログ(実データ)を利用
• 正常な動作をどう確認するか
  • 接続時間や通信の応答時間を確認
  • ボトルネックの特定や余裕の見積もりに様々なメトリクスが必要
  • データはDataDogに貯めて、閲覧可能にしておくと良い
• コスパの良いサーバの性能を割り出す
  • サーバのスペックを変えて実験を繰り返し、最適なスペックを算出

Photon Quantum

• 既存のPhotonを利用する際には開発者の高いスキルが要求される部分があった
  • (遅延などによる)プレイヤー間の公平性
  • チート防止のための認証システム
  • トラフィックとバンド幅の制御
  • 切断と再接続
• ユニティの一部だったゲームプレイ部分を切り離して独自開発
• プレイヤー同士のインプットのみをクライアント間で交換
  • ゼロラグ
  • チートプロテクション
  • バンド幅を狭く、高頻度で送信
  • 安いAndroidでも動かせるほどのパフォーマンス

感想

Unityのマルチプレイヤー関連ツール・サービス群であるUnetの機能が段階的に廃止されることを受けてサードパーティー製のネットワークエンジンが注目を集める中、Photonはモノビットエンジン、Strix Cloudなど他社製品と比較して導入を解説する記事が圧倒的に多いように思います。
一方である程度の規模のゲームを事例とした負荷対策・負荷試験の手法などはなかなか紹介されていませんので、そういったお話を聞くことができたのは大変貴重でした。
また先日国内でリリースされたばかりの新製品「Photon Quantum」がリアルタイムアクションゲームにより特化した性能とあり、Unity+Photonの組み合わせがますます勢いを増していきそうです。

好きなゲームを作ることをあきらめない。スマホインディーの生存戦略。

Daigo Studio: 佐藤 大悟様

Google Indie Festival Top3受賞。YouTubeの実況動画など、最近巷で超話題のスマホアプリ「くまのレストラン」開発者が登壇。
シリコンバレーで勤めていた会社が倒産し、露頭に迷った佐藤氏が「くまのレストラン」で花開くまでの2年間のインディーゲーム開発の軌跡を共有。

概要

ゲームデザイン - 期待値を下げる

• 低解像度のドット絵を使用し、高解像度にはしない
• スマホの縦持ちに特化し、横持ちには対応しない
• 画面スクロールはなし
• バトルシステムなし
• オンライン要素なし

なるべく作品に対するユーザの期待値を上げずに、開発工数、管理コストの負担を抑えるよう機能を絞る。
機能を絞って1つのことに特化することが武器となる。

エンジニアリング - 共通化

• 売上 - 開発コスト - マーケティングコスト = 利益
• 最もコントロールできるのは開発コストの部分
• 開発コストを抑えるために徹底的な共通化

課金周りや広告・レビュー依頼、クラッシュレポート、設定画面などデータ以外の部分を徹底して共通化。
新しいゲームを作る際もデータ以外の部品を新たに作る必要がなく、開発コストが抑えられる。

マネタイズ - 継続率が低くても稼ぐ仕組み

• 作品の世界観を変えずに課金できる仕組みを模索
• 有料の追加ストーリー
• スポンサー課金

ストーリーゲームは1回クリアして終わりのため継続率が低く、本編部分を無料にして作品を気に入ったユーザには追加のストーリーを購入してもらう仕様に。
一方で無料で追加ストーリーを開放する手段も用意し、広告を使って収益化につなげた。
またクリア後のスタッフロールに名前を残せる特典を課金要素に加えた。

• ゲームを作るときはどれくらい儲かるか、事前に見積もりをするべき

リリースするまで利益が出るか分からないのは精神的に良くない。
見積もりの結果、明らかに課金の単価が低いのであれば改善が必要ということ。

大事なこと

• グローバルで行こう
• ひとりじゃない
• 積み重ねが最も大事

感想

入場制限がかかるほど多くの参加者から注目を集めていた本セッション。
自分の好きなゲームを作ってそれで稼ぐというのは、やっぱりゲーム開発者にとって大きな目標の1つのようです。
集客しかり、ゲームシステムしかり、「1発当ててやる」ではなく「1発当てるための準備」をどれだけ綿密に計算して、コツコツと積み上げていくことがインディーズゲーム開発で重要なのだと思いました。

総括

去年よりもほんの少し中級セッションを増やしてみた今回のCEDEC2019。
前回と比べるとより技術的なお話が多く情報量も豊富だったのですが、内容が全くわからないといったようなこともなく、少しだけ自分の成長を感じることができました。

エンジニアの熱気に包まれる中、著名なクリエイターや人気アプリの裏側を垣間見ることができ、学習・開発のモチベーションをぐんと上げてくれることがCEDECの会場まで足を運ぶ最大の魅力だと考えています。

ただどうしても見たいセッションが同時間帯に重なってしまう。聴講で予定を埋めてしまうとインタラクティブなブースなどをまともに見ることができない。お昼ご飯が激込みなど残念な点がありますので、来年のCEDECではこのあたりの改善を考えてほしいなぁとは思います。

ちなみに只今LPICの資格勉強中ですが、今回のCEDECを受けて新たにCCNAの勉強を始めたいと思いました。
やるやる詐欺にならないよう頑張ります。