ハロチャオ！株式会社オルトプラス(AltPlus Inc.) 開発マネージャーの青井 裕紀(Yuki AOI)です。
本日は オルトプラス Advent Calendar 2023 の22日目、ゾロ目の記念としてオルトプラスの中でも最大規模となった『DMMオンクレ』開発チームで使われている技術や開発プロセスを語っていければと思います。
DMMオンクレとは、合同会社DMM.comが提供する、PCやスマートフォンを使って実物のクレーンゲーム機を遠隔操作し、ユーザーが24時間どこからでもクレーンゲームを楽しめるサービスです。
サービスサイト：https://onkure.dmm.com/
突然ですが、あなたはオンクレ(オンラインクレーンゲーム)を遊んだことはありますか？
複数のオンクレで遊んだことがある人は解ると思いますが、ゲームセンターで遊ぶクレーンゲームとの技術的に大きな違いとして『アーム操作の気持ちよさ』という要素が重要だったりします。
この記事では特に『アーム操作の気持ちよさ』にまつわる"仕組み"と、それの改善ストーリーをつづりました。
オンラインクレーンゲームにおける基本的な仕組み
まずはオンラインクレーンゲーム全般に言える話ですが、おおまかに分けて下記の仕組みで動いています。
- 筐体操作：クライアントの操作をインターネット経由で伝搬し、クレーンゲーム筐体を動かす。
- 状況表示：クレーンゲームの筐体を撮影し、Webカメラ映像をクライアントに伝搬する。
時間軸で追っていくと下記のような流れになります。こちらの方がイメージが湧きやすいでしょうか？
📲スマホ操作
↓ (internet)
クレーンゲーム基板
↓ (筐体内)
アーム操作
↓
Webカメラ撮影
↓ (internet)
👀画面表示
この[スマホ操作]から[画面表示]までの秒差を『レイテンシ』と名付け、この値が早い方が『アーム操作の気持ちよさ』が高いと仮定し、2023年の3月に我々はそれを改善するプロジェクトを発足しました。
それが『最速のオンラインクレーンゲーム』を目指すプロジェクトです。
レイテンシを計る
まずは現状を知らないと始まりません。スマホで動画を撮りながら各社の反応速度をフレーム単位で確認。何回もプレイし、そのレイテンシの平均値をスコア化しました。
具体的な数値は省きますが、バーが短いほど速度が早いと思ってください。
計測の結果、業界内で『最速』には程遠い数値が出てしまいました。薄々知ってましたがこれは悔しい。
その後、何処にどれだけの時間がかかっているのかを細かく計測したところ、(施策1)動画のエンコーディングと配信方法、(施策2)スマホ操作が筐体に届くまで の両方に改善の余地があり、施策1、施策2と分け順番に対応することにしました。
改善施策1：映像配信
当サービスでは今まで、クレーンゲームの筐体をRaspberry Piに繋いだWebカメラで撮影し、それをMotionJPEGにソフトウェアエンコーディングしたものを配信、imgタグで表示する形で配信していました。
施策1、映像配信側の改善の方法としていくつものアイデアがあがり、最終的に2案が残りました。
- 1案. Webカメラでハードウェアエンコーディングされた映像をそのまま取り出す
- メリット：ハードウェアの変更がない。
- デメリット：早くなると思われるが効果は未知数。エンコードされた映像は同じなので伝送速度は変わらない。
- 2案. B社と同じくWebRTCを使う
- メリット：他社実績があり、秒間の転送速度もMotionJPEGより軽い。
- デメリット：(概ね)外部サービスを利用する必要があり、利用コストが結構かかる。
元々利用していたWebカメラがハードウェアエンコーディングに対応しているカメラだったため、1案を採用した場合『ハードウェアが変更されず、かつ他社サービスを利用しない』ため運用時に特段のCostが発生しないということで、まずは1案の検証に入りました。
改善施策1-1：Webカメラのハードウェアエンコーディング
Webカメラからハードウェアエンコーディングされた映像を取得しようと思ったところ、公式からドライバが提供されておらず、シンプルな利用が難しい状態でした。
私達は、Raspberry Pi用にハードウェアエンコーディングされた映像を取り出すドライバを自作することにし……その環境でスコアを測ってみました。
遅くなっとるやないかい！
ネット上でも「Webカメラのハードウェアエンコーディングは思ってるより遅い」との書き込みを見つけましたが、スコア計測することで『ハードウェアエンコーディングされた映像を取得すると高速化できる』という幻想が打ち砕かれました。
Webカメラに積んでいるCPU性能ではRaspberry Piを超えられませんね。頑張ってドライバを開発しましたが、日の目をみることはなくお蔵入りとなりました。
改善施策1-2：WebRTCのサービス導入
1案は幻想に終わってしまったので、2案のWebRTCを利用する方向で進めていこうと思います。
早速、WebRTCの既存サービスやライブラリを一覧化してメリデメを比較してみました。
- Amazon Chime / Amazon Kinesis Video Streams (Amazon KVS)
- Sora Cloud / WebRTC SFU Sora (オンプレミス版)
- Agora
- etc...
その中でも様々別サービスで実績があり、とにかく早いと思われる『WebRTC SFU Sora』が一番の候補にあがりましたが、オンプレ環境の構築を含めると、どうしてもCostがかかり引き返せない状態になるので検討順位が悩ましいですね。
同じ理由で『ライブラリを利用してWebRTC環境を開発・構築し配信』というのもCostがかかる上、Deliveryが遅れるすぎるという事で、一旦Cloud型を検討することに…。
Cloud型はオンプレに比べ物理経路が長い分レイテンシが遅くなるのでは……という不安もありましたが、AWS Cloud と DMMオンクレの倉庫間の回線はDirectConnectにより直接接続されているので比較的早いだろうと思われます。
まずはAWSサービスから検証しようという事できまりました。
AWSの担当者と密なコミュニケーションをしたところ、ChimeよりもKinesis Video Streamsの方が低レイテンシで動作する事などがわかりKinesis Video Streams(Amazon KVS)を最初の検証対象とすることにしました。
という訳で実装後のスコアは……
期待値には届きませんでしたが、十分に導入効果が見込めますね。
という訳で映像配信側の改善施策は一先ずとし、次の施策に移ります。
改善施策2：筐体操作
スマホの画面でボタンを押してから筐体が動かすために、AWS上に用意したAPIエンドポイントを経由して伝送していました。
私は「物理経路の短縮とAPIサーバーのLaravel起動コストを短縮する為に、ユーザー端末から操作基板に直接接続させる仕組みに変えたい」という提案をし、これを検証してみる事になりました。
倉庫側にも新たなファイヤーウォールを導入し、各Raspberry PiにPort Forwarding設定を行い、アプリのFrontendから直接信号を送るように変更しました。
当初想定ではスコア変化は軽微だと試算していましたが、エンジニアからは「予想以上の効果が出ている」との報告が……さっそくスコア計測してみたいと思います。
なんとついに！確認した他のオンクレサービスに引けを取らない結果が出ました。
実際のサービス提供時はユーザー環境に大きく左右されますが、私達が行ったテストではWi-Fi環境下、4G回線で街を歩きながらなど、概ねの環境で気持ち良いアーム操作となりました。
終わりに
サービス当初から課題となっていた『レイテンシ遅い問題』も一定の改善が見受けられました。まだまだ改善に努めていきますが、お客様の環境でも体感が飛躍的に向上されてましたら嬉しく思います。
これからもQualityの高いサービスをお届けできるように邁進していく所存です。
この記事が公開される頃には施策は既に展開されていると思いますが、変化に気づいていただけましたでしょうか？
まだ施策適用後の台を試してない方、「オンクレをやったこと無いよ」という方は、是非『DMMオンクレ』を遊んでみてください。
ここまで読んでくださり、ありがとうございました。
記事を楽しんでもらえた方は『いいね』と、他の『オルトプラス Advent Calendar 2023』記事も読んでみてくださいね。
もっと書きたかったけど割愛したこと
- Amazon KVS導入時に苦労したアレコレ
- 施策2導入時にセキュアにする為にしたアレコレ
- ここで触れていないレイテンシ短縮に貢献したインフラ側の技術のアレコレ