Shard Selection Module for Online Game Latency Optimization
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional systems for associating players of an online game with shards fail to effectively utilize aggregated third-party latency and social graphs, leading to inefficiencies in player placement.
Innovation Solution
A system that includes a shard selection module to determine the best shard for a user to join based on calculated aggregated third-party latency, considering latencies from the user's device to other users and from those users to the shard, as well as social graph relationships, to optimize game performance and user experience.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If conventional systems place a player into a shard based solely on profile characteristics, then the shard selection process is simple and quick, but the player placement efficiency and gaming experience deteriorate due to lack of optimization for latency and social interactions
Solution Approach 1:
The system pre-calculates and stores aggregated third-party latency metrics for multiple shards before player registration. Social graph data is pre-computed and maintained in the system. When a player needs shard assignment, these pre-computed data structures are already available, enabling rapid optimization without real-time computation overhead.
Solution Approach 2:
The patent introduces an intermediary shard selection module that acts as a mediator between player profile data and shard assignment. This module aggregates latency metrics from multiple third-party sources and combines them with social graph information, transforming complex multi-source data into a unified player-shard matching decision.
2Reliability
If the system calculates aggregated third party latency from user device to shard and between users, then the latency optimization improves, but the computational complexity and data processing requirements worsen
Solution Approach 1:
The system performs preliminary calculations of aggregated third-party latency metrics for all potential shards before player assignment. These latency aggregates are pre-computed using social graph relationships and stored in readily accessible data structures, eliminating the need for complex real-time calculations during player registration.
Solution Approach 2:
The patent calculates latency metrics for a limited subset of relevant shards rather than all possible shards. By focusing computational effort on shards that are geographically or socially relevant to the player, the system achieves sufficient latency optimization without the excessive computational burden of evaluating every shard in the network.
3Ease of operation
If the system incorporates social graphs and aggregated latency data for shard selection, then the gaming experience and community engagement improve, but the data processing and storage requirements worsen
Solution Approach 1:
The system extracts and stores only the essential aggregated latency metrics and social graph features needed for shard selection, rather than maintaining complete raw data sets. By extracting only the relevant aggregate statistics (average latency, social connection counts, shard popularity metrics), the system reduces storage requirements while preserving the ability to optimize player placement.
Solution Approach 2:
Social graph data and latency metrics are pre-processed and aggregated into compact data structures before being used for shard selection. This preliminary data preparation reduces the volume of data that needs to be processed during player registration, as the system works with pre-computed summaries rather than raw individual data points.
Data Source
AI summary
One aspect of the disclosure relates to facilitating association of a user of an online game to a shard based on aggregated data related to third party latency and further based on social graphs associated with the user. A first type of aggregated third party latency may be calculated based on one or more of: a plurality of first latencies from a device associated with the user to a first plurality of users associated with the first shard and a plurality of second latencies from the first plurality of users to the first shard. A second type of aggregated third party latency may be calculated based on one or more of: a plurality of first latencies from the device associated with the user to a second plurality of users associated with the second shard and a plurality of second latencies from the second plurality of users to the second shard.