オフラインポーカーの魅力を引き出すために

近年、テキサスホールデムポーカーのプレイヤー人口は拡大傾向にあり、ポーカー施設の数も増え続けています。その一方で、ゲームアプリを使いオンラインでポーカーを楽しむ層も目立つようになりました。そのため、ポーカー施設の運営者はオフラインならではの価値を売り出すことが今まで以上に求められています。

POKER Jamは、このような状況の中で、オフラインでしか味わえないポーカーの楽しさを引き出し新たな来店体験へとつなげることを目指して立ち上げられたプロジェクトです。

Jamする感じをモチーフに

オフラインポーカーの魅力は、なんといっても実際に生身の人間と相対してプレイすることにあります。現場ならではの緊張感や相手の顔色と息遣いは、オフラインポーカーではどうしても体験できないものです。

サービスの随所で使用されるグラフィカルなアイデンティティは、このようなオフラインポーカーならではの性質を反映されたものを目指しました。

さながらジャズのようにプレイヤーの思惑と熱狂が入り混じりセッション(Jam)する様子、オープンされたカードによって瞬時に移り変わるゲーム展開の明快さを、アクションが繰り広げられるポーカーテーブルをモチーフとしたパターンによって表現しています。

合わせて、オリジナルのトランプカードも作成しました。

ゲームデータを"溜めて、通いたくなる"体験へ

POKER JamはRFIDを内蔵したポーカーテーブルと同期することができるので、ユーザーはプレイ中のあらゆる情報を自動的に取得し、リアルタイムにUI上で確認することができます。もちろん、それらのデータはプレイ後の分析にも利用可能です。より良いポーカー体験のためには集まったデータをどのように表示すべきか、どのような演出が次も来店したいと思える体験につながるのか。POKER Jam導入店舗に思わず通いたくなるような仕掛けを、エンジニアや熟練のポーカープレイヤーたちと共に検討していきました。

プレイ改善につながるデータの見せ方

各画面では、RFIDによって収集された膨大なデータをプレイヤーが直感的に理解し、プレイ改善にも活かせる形で提示することを意識しました。ハンド別スタッツでは、一般的なポーカー戦績の統計手法を踏襲しながらも色数を抑え、数値同士の比較がしやすい構成としています。

また、その日の最新セッションへすぐに遷移できる導線を設けることで、分析のためだけの画面で終わらない体験を目指しました。ポジション別スタッツでは、実際のポーカーテーブルの配置をそのままUIに落とし込み、どの席でどのような傾向があるのかを瞬時に把握できるようにしています。

複雑なゲーム進行を破綻なく表現するために

さらに、POKER JamではRFIDとディーラーの音声AIデータを活用し、店舗で気軽にゲーム配信や振り返り映像を作成する仕組みも構築しました。RFIDで読み取られたカード・アクション・ポットの状態をリアルタイムでUIに反映するため、Riveを用いてモーションを設計・実装しました。

この開発において特に難易度が高かったのは、ポーカー特有の複雑なゲーム進行をアニメーションとして破綻なく表現することでした。ポーカーは単に役だけで進行するゲームではなく、アクションの種類やチップの有無、プレイヤー人数、サイドポットの生成、フロップ・ターン・リバーごとの進行管理など、多数の条件分岐が存在します。さらに、RFIDの読み取りタイミングの揺らぎや例外ケースも考慮する必要がありました。

これらの複雑な情報をすべてリアルタイムに可視化するため、情報を整理・抽象化し、Riveで制御可能なStateMachineとDataBindingの構造へ落とし込んでいます。その結果、複雑なポーカーのゲーム進行を正確かつ視覚的に分かりやすく表現し、ライブ配信とゲームアーカイブのどちらにも耐えうるアニメーション基盤を構築することができました。

データを"体験"に変換するためのモーション設計

RFIDで読み取られたカード・アクション・ポットの状態をリアルタイムでUIに反映するため、Riveを用いてモーションを設計・実装しました。

リソースの制約から関わるエンジニアの人数が限られていたこともあり、フロント側で完結できる表現や制御は可能な限りRive側に集約し、アプリ側の実装負荷を抑える構造が求められました。単に見た目を作るのではなく、データと演出をどこまでRiveに持たせると破綻しないか、将来の更新にも耐えられるかという点まで含めて設計しています。

Riveをチームで扱える技術にするための設計と運用整備

Rive実装をスムーズに進めるため、単にアニメーションを作るだけでなく、チーム内で共通認識を持てる設計と運用ルールの整備にも取り組みました。エンジニアと綿密にコミュニケーションを取りながら、ViewModelやStateMachineの役割が誰にとっても分かるよう、命名規則や設計方針をチーム内で定義しています。これにより、Rive側とアプリ側の責務が曖昧にならず、実装・レビューのどちらも進めやすい状態を作ることができました。

また、Riveを個人のスキルに閉じずチーム全体で扱える状態にすることも、このプロジェクトを進める上で重要な役割でした。特に、他のデザイナーがRiveを初めて触る際には、ツールの基本的な使い方やViewModel設計の考え方を共有し、すべてのRive実装に対してレビューを行い、表現のクオリティだけでなく、実装視点での懸念点や改善余地まで含めて確認しています。実装側がどこを気にするのか、この構造は今後の拡張に耐えられるか、といった観点でフィードバックを行いました。これにより、Riveを作れる人が限られた技術ではなく、チームとして使い続けられる技術にすることを目指しました。