マーケティングの実現: ユーザーインタラクションバス

優れたアクティビティには、魅力的なゲームプレイだけでなく、ユーザーに完全な体験を提供し、インタラクティブなフィードバックを適切に処理し、ユーザーの全体的なインタラクション感覚を高めることも必要です。では、この目標をどう達成できるでしょうか? 「ユーザーインタラクションバス」を構築してみるのもいいかもしれません。それを具体的にどのように理解し、確立するかについて、著者の分析を見てみましょう。

1. はじめに

以前、ゲームプレイ間の分離と接続についてお話ししましたが、これによって機能上の問題の 50% が基本的に解決されました。基本的にアクティビティを完全に構築することはできますが、主にユーザー エクスペリエンスとアクティビティの効果の点で、優れたアクティビティとはまだギャップがあります。この記事では、バックエンドの観点から、アクティビティに参加するユーザーのインタラクションの問題を処理する方法について説明します。

システムアーキテクチャの設計や機能の抽象化を行う際に、スケーラビリティなどの理由からシステム機能が分割されました。各ゲームプレイは独立して存在し、動的にリンクできます。システム アーキテクチャの設計は優れていますが、このように構築されたアクティビティは、インタラクティブなフィードバックが全体として処理されない場合、ユーザー エクスペリエンスを損なうことになります。ある程度、ユーザーはまだそれがパズルのようなアクティビティであると感じています。各ゲームプレイは独自のインタラクションを処理し、そのリンクはユーザーに強く認識されず、ゲームプレイ間のインタラクションに競合が発生する可能性があります。整合性が十分に強くありません。

私たちのシステム全体によって生み出される活動は、断片的ではなく完全なものであるべきです。各カスタマイズ プロセスのコストが高すぎるため、ゲームプレイの振り付けをあきらめると、最初からやり直すことになります。したがって、より優れたユーザー インタラクション エクスペリエンスを提供し、アクティビティ インタラクション ロジックの開発コストを削減するには、全体的なユーザー インタラクションを担当する集中型の「バス」が必要です。

2. 解決策

1. 問題分析

インタラクション バスの役割は、「ユーザー インタラクション中にイベント フィードバックを集中的に処理し、インタラクションの全体的な感覚を管理すること」です。イベントは、その発生源に応じて分類されます。

確立されたアクティビティ相互作用ルール (ゲームプレイ自体、ゲームプレイ間) と運用操作という 2 つの主要なカテゴリがあります。

1. 表現形式によって、トースト、ポップアップウィンドウ、インアクティビティ通知、プライベートメッセージ、プッシュなどに分けられます。
2. タイミングによって、基本的にはリアルタイムリーチ（受動的受容）とインタラクション中にトリガーされる（能動的トリガー）に分けられます。

本質的に、これらのアクションはすべて、アクティビティとユーザー間の「相互作用におけるフィードバック」です。タッチの本質を捉え、その「フィードバック」の場面、形、タイミングを分析し、要約・抽象化すればいいのです。

2. 位置決めの決定

インタラクション バスは、ユーザー インタラクション プロセス中のアクティビティのフィードバックを担当するため、「スライス」のような存在である必要があります。すべてのインタラクション フィードバックはここで発生します。つまり、ゲームプレイ バスとビジネス イベント バスは統合された機能プレゼンテーションを提供し、インタラクション バスは統合されたユーザー インタラクション フィードバックを提供します。これら 2 つの部分は、ユーザー参加のコンテキストに関する優れたユーザー エクスペリエンスをユーザーに提供します。

3. 要約

まずコンテキストを決定します。アクティビティ フィールドでのユーザー参加中のインタラクティブなフィードバックの問題に対処します。処理の中心的な目的はフィードバックです。解決すべき主な問題は、インタラクション プロセス中のフィードバックの一貫性のなさ、フィードバックが多すぎるか少なすぎること、集中管理ができない、メンテナンス コストが比較的高いことです。

オペレーターにとって、フィードバックは、構成、管理、およびトリガーする必要がある一種のアクティビティ相互作用ルールです。ユーザーの場合、アクティビティに入るときにフィードバックを積極的にプッシュまたはプルできます。これらのフィードバックには、それぞれ固有の内容、さまざまな表現形式、受け取るユーザーが存在します。フィードバック間には優先順位や相互排他的なロジックなどがあります。一般に、フィードバックは次のように大まかに抽象化できます。

したがって、フィードバックを生成および維持し、フィードバック間の関係を均一に処理できるサービスを実装するだけで済みます。

4. 実行ビュー

まず、全体的なランタイムビューを確認し、次にインタラクティブなフィードバックの統一された処理を実現する方法について詳しく説明します。

まず、インタラクティブ バスのイベント ソースは、タスクの完了、アシスタンスの成功などの非同期イベントである場合もあれば、ユーザーのクリックやインターフェイスのオープン、または操作によって発行される集中的な連絡先のリコールである場合もあります。イベントを受信した後、イベント自体のインタラクティブなフィードバックと、イベントに関連するインタラクティブなフィードバックを作成する必要があります。たとえば、タスクが完了するとトースト プロンプトが表示され、タスクが完了すると更新アクションや特殊効果が発生して賞品を獲得する可能性が高まります。

対応するフィードバックを取得した後、既存のバッファに流し込むか、後続のプロセスを直接通過し、その後、イベントはルールに従って標準化されます。バッファが存在する場合、バッファは他の現在のイベントとマージされるか破棄され、現在のフロントエンドのインタラクション シーケンスと統合されて、消費を待機している現在のバッファの最終シーケンスが決定されます。

最終的な消費可能シーケンスは、サーバーのロングリンクを通じてユーザーにアクティブにプッシュすることも、ユーザーが操作したときにユーザーに提供することもできます。

5. 消費ルール

バス全体の消費ルールを維持することは、実装全体の中で最も複雑な部分です。通常、消費キューの消費方法は、プルとプッシュの 2 種類に分けられます。プルの通常のロジックは、最後のインタラクションと現在のインタラクションの間のユーザーのインタラクションのフィードバック動作を取得することですが、プッシュは通常、時間制限のある定量的な消費ロジックであり、フィードバックの消費は、特定のゲームプレイに関連するものだけを消費したり、このインタラクションに関連するものだけを消費したりするなど、多次元処理をサポートする必要があります。

そのため、フィードバックには重い業務処理機能が備わっています。この部分の実装は、ビジネス シナリオに応じて、非常に複雑になることも、非常に単純になることもあります。一般的に言えば、アクティビティ ディメンションではルールを少しパッケージ化するだけでよく、非常に複雑に拡張されることはありません。

簡単に理解していただくために、比較的一般的な例を挙げてみましょう。

• 消費モード <プル、プッシュ <タイミング、数量>、プル＆プッシュ <タイミング、数量>;
• 機能セット <マージされた機能、優先度、破棄フラグ、フィードバック タグ>。

多くの単純なアクティビティでは、強力なフィードバック要件はありません。現時点では、デフォルトのタイミング ルールの単純なセットのみが必要であり、特別なルールは必要ありません。

この部分でのルール設計の実践は、ビジネス シナリオに深く関連しています。ルールを柔軟にプラグインしたりプラグイン解除したりできることを保証するだけで十分です。コミュニケーションを取りたい場合は、別途詳細をお話しすることも可能です。

3. 最後に

とりあえずこの記事はここまでとさせていただきます。 DSL の定義、テキストの生成方法、ストレージが Redis か MySQL か、SDK がサービスを提供するか、外部に対して RPC が使用されるか、バッファ カウント メカニズム、プッシュ メカニズム、パフォーマンスとデータ一貫性の保証など、関連する多くの技術的な詳細は詳細に説明されていません。これらは、企業のテクノロジ選択とビジネス シナリオに基づいて決定できます。関連する質問がある場合は、個別にチャットすることができます。この記事で説明するアイデアは、アクティビティ シナリオに限定されません。一部の通知システムや連絡システムでも、この考え方を利用して問題を解決しています。