JP2019508179A - Synchronization model for virtual tournaments - Google Patents

Abstract

Data characterizing the two players is received, which is registered for an online video game tournament. Each player is running a separate instance of an online video game. Online video games are asynchronous between two players. The data is separate from the game server, which is received by the tournament server hosting the tournament and provides game data to clients associated with the two players. Instructions are generated for synchronization of gameplay between two players. The instructions are transmitted to the client associated with the two players, and the instructions result in the asynchronous start of the asynchronous game for the two players. Related devices, systems, techniques, and articles are also described.

Description

(Cross-reference to related applications)
This application claims the benefit of U.S. Provisional Patent Application Ser. S. Claiming priority under C 119 119 (e), the entire content of which is incorporated herein by reference.

  The subject matter described herein relates to ad hoc creation and hosting of digital online video game tournaments.

  The video game streamer is involved in showing the audience a live video of their gameplay. Streamers are currently limited in their ability to engage with their audience, as there is no general solution that allows them to host interactive, live and competitive content for their viewers. Be done.

  In one aspect, data characterizing two players are received that are registered in an online video game tournament. Each player is running a separate instance of an online video game. Online video games are asynchronous between two players. The data is separate from the game server, which is received by the tournament server hosting the tournament and provides game data to clients associated with the two players. Instructions are generated for synchronization of gameplay between two players. The instructions are transmitted to the client associated with the two players, and the instructions result in the asynchronous start of the asynchronous game for the two players.

  One or more of the following features may be included in any viable combination. For example, the instructions may cause game play to be initiated when received by the client. Each client includes a game instance and a peer tournament module that receives the instructions, and may be responsive to receiving the instructions to initiate game play by performing a game initiation callback with the game instance. Each client includes a game instance and a peer tournament module for receiving the instruction, and responsive to receiving the instruction, transmits a second instruction to the game server, for transmitting game data from the game server to the game instance. May cause the start of communication.

  The instructions may define a time for the start of the game. Each client may include a game instance and a peer-to-peer module that receives instructions, and may cause the game to start at a defined time by performing a game initiation callback with the game instance. Each client includes a game instance and a peer-to-peer module receiving the instructions, transmitting a second instruction to the game server at a defined time to start, and communicating game data from the game server to the game instance Can cause an onset of

  A match identifier, a player identifier, and game parameters may be transmitted to each client. The match identifier may define a unique identifier for the tournament. The player identifier may be a unique identifier for the user's entry into the tournament. The game parameters may include data for configuring each game instance to run.

  Simultaneous video streaming of gameplay for side-by-side viewing by a viewing client may be enabled.

  The subject matter allows a streamer (e.g., an "event host") to create and host a tournament in any mobile game on an ad hoc basis, and whether the viewer is created privately for the audience of the streamer. Or joining into a match that is either exposed to all players of the game, and the event is hosted in an optimized manner for engagement and play for any audience Can include tools that enable the

  A non-transitory computer program which, when executed by one or more data processors of one or more computing systems, stores instructions causing at least one data processor to perform the operations herein. A product (i.e., a computer program product physically embodied) is also described. Also described is a computer system that may include one or more data processors and a memory coupled to the one or more data processors. The memory may store, temporarily or permanently, instructions that cause at least one processor to perform one or more of the operations described herein. In addition, the method is implemented by one or more data processors, either within a single computing system or distributed between two or more computing systems. obtain. Such computing systems may be connected, including but not limited to, connections via networks (eg, the Internet, wireless wide area networks, local area networks, wide area networks, wired networks, or the like), multiple computing Data and / or commands or other instructions or equivalents may be exchanged via one or more connections, including connections through direct connections between one or more of the systems, etc. .

  The details of one or more variations of the subject matter described herein are set forth in the accompanying drawings and the description below. Other features and advantages of the subject matter described herein will be apparent from the description, the drawings, and the claims.

FIG. 1 is a process flow diagram illustrating a process that enables tournament lobbies and players to access event streaming. FIG. 2 is a system block diagram illustrating an exemplary system for implementing a peer-to-peer digital game tournament. FIG. 3 is a system block diagram of a system with an exemplary media management server that enables video streaming of tournaments. FIG. 4 illustrates an exemplary tournament table. FIG. 5 is an exemplary graphic user interface (GUI) of event streaming video control and display. FIG. 6 is a process flow diagram illustrating a method of initiating gameplay synchronization for an asynchronous game instance. FIG. 7 is a data flow diagram illustrating data flow between components of a peer tournament system.

  Like reference symbols in the various drawings indicate like elements.

  The subject matter allows a streamer (e.g., an "event host") to create and host a tournament in any mobile game on an ad hoc basis, and whether the viewer is created privately for the audience of the streamer. Or joining into a match that is either exposed to all players of the game, and the event is hosted in an optimized manner for engagement and play for any audience Include tools that enable you to

  In some implementations, the present subject matter may allow game synchronization, which is otherwise asynchronous, to enable live tournaments. Asynchronous games include games in which the gameplay of two opponents is not always performed simultaneously. For example, each of two players playing a one-player game results in asynchronous game play. The subject matter may include a server that synchronizes an asynchronous game such that two (or more) players begin playing at substantially the same time. This enables live tournaments, including each player's gameplay and streaming of real-time comparisons among multiple players. Such comparisons may be performed, for example, as part of an eSports tournament.

  In some implementations, the streamer may create and host tournaments within any mobile game on demand. The streamer can sign up for an account and access the web portal of the event. Using this portal, the streamer can create events for display on the host and its streaming page. Options for the streamer to set prior to the event are the date and time of the event, a description of the event, the number of participants in the event, the winnings distributed to the event winner, the entry fee for the event (if applicable), and the event is played. Games, seed types, round time limits, and tiebreaker time limits. Tournaments are referred to as "bracketed events" in order to conform to the one-on-one battle format commonly found in athletics.

  The viewer may subscribe to a match that is either privately created for the audience of the streamer or published to all players of the game. The logic of the tournament lobby and event streaming access is that the streamer actively plays the game, although it is not related to two groups of users: (1) its current audience and viewers, and (2) the streamer. Make it possible to interact with existing users.

  The first set of viewers can easily download and play the game via automatically generated instructions placed on the streamer's display. From within the game, a new player may enter a match code that includes automatically generated instructions. The match code allows the user to sign up for an event, purchase entry tickets if necessary, and play against other viewers.

  The event host has the option of including or excluding the second group of users, ie, the players actively playing the game. If included, these players will notice the option to join the tournament from within the game menu. This includes not only the ability to register for a tournament, if space is still available, but also includes instructions for viewing event broadcasts with links to streamer pages.

  Events may be hosted in an optimized manner for engagement and competitive play for any audience. The event host may stream using a streaming management server. Streams and events are optimized to increase engagement and competitive play by setting up structures that reduce downtime and maximize the potential for exciting winning structures.

  The players in the first round are seeded against each other by matching opponents of similar skill levels. This ensures the exciting, attractive first round that pulls the user into the match, even in the case of defeat. The rounds are then synchronized and start simultaneously for all players so that the opponents play against each other at the same time despite being asynchronous gameplay. The opponent receives notifications and updates on his or her performance and progress through the winning game on his device. Alternatively, the player may track the progress of the tournament in real time via the event stream, even if it is excluded from the tournament.

  FIG. 1 is a process flow diagram illustrating a process 100 that enables tournament lobbies and players to access event streaming. The events may be subscribed via a peer tournament module, which will be further described below with reference to FIG. The peer tournament module may be implemented by the game developer using a software development kit (SDK) associated with the tournament server. If the user chooses to enter the tournament, the server will have available space in the tournament based on the current number of registered users and the number of participants defined by the event host To verify. If there is an available spot, the user is moved forward to register, otherwise the user is notified that the tournament is full and provides information about where to watch the event stream Be done.

  For events with entry fees, the user will be prompted to purchase a ticket for the event as part of registration. In the case of a free event, the user may be registered by confirming that they wish to enter the tournament. Once registered, the user is called back to the home page until the event starts.

  Once the event has started, all registered users may be notified that the first round has started. Subsequent rounds will follow the same logic as the winning tournament.

  FIG. 4 illustrates an exemplary tournament table 400. Smart seed places the opponents in an optimal match, increases player engagement, and maximizes audience excitement. This feature uses a database and determination of the player's game skill elements to generate a tournament table that maximizes the potential for both hot fight and amazing upset.

The smart seed follows the following process (example is specific to the tournament of 16 players, but will fit in any number of tournaments). Rank all players based on their ratings and pair them with # 1 and # 2, # 3 and # 4, and equivalent. Then, each winning pair is seeded, with player # 1 being the game for player # 1 vs. player # 2, game # 2 being the game for player # 3 vs. player # 4 and the like. Then, using the standard seeding method for each win, win # 1 (# 1 vs. # 2) will be the win on the other side of win # 2 (# 3 vs. # 4).
· Winning seed # 1 = Player seed # 1 vs. # 2
· Winning Seed # 2 = Player Seed # 3 vs. # 4
· Winning Seed # 3 = Player Seed # 5 vs. # 6
· Winning seed # 4 = Player seed # 7 vs. # 8
· Winning Seed # 5 = Player Seed # 9 vs. # 10
· Winning seed # 6 = Player seed # 11 vs. # 12
· Winning seed # 7 = Player seed # 13 vs. # 14
· Winning seed # 8 = Player seed # 15 vs. # 16

  FIG. 2 is a system block diagram illustrating an exemplary system 200 for implementing a peer-to-peer digital game tournament. The system 200 includes a tournament server 260 that enables tournament play between players of the game.

A plurality of players 210 _i (i = 1, 2,..., N) operate individual player clients 220 _i . Each player client 220 _i includes a third-party game application 230 _i. Game application 230 _i may be any online digital game (eg, a video game). In some implementations, multiple players 210 may play online against one another. The game may be consistent across game applications 230 (eg, when player 210 plays chess, each game application 230 is an instance of an electronic chess game). Each game application 230 may communicate with the game server 250 and receive game data therefrom. The game server 250 provides game data necessary to operate the game. Game server 250 may be, for example, a third party game server that is separate from tournament server 260 and with limited access capabilities by tournament server 260 (eg, tournament server 260 has communication with the game server). Either not or have limited API call access to it). Player client 220 may include mobile devices (e.g., smartphones, tablets, and the like), and player client 220, game server 250, and tournament server 260 may implement tournaments via a network such as the Internet. .

Each game application 230 includes a peer tournament module 240 _i . The peer tournament module 240 is integrated into the gaming application 230 to allow the player 210 to register and participate in an online game match. Peer tournament module 240 communicates with and cooperates with tournament server 260. An internal game that changes over time as the associated player 210 interacts (eg, plays) with the associated player 210 while the game application 230 is launching a game (eg, a game instance) It has a state. Peer tournament module 240 may capture game state data periodically and / or continuously, and transmit the captured game state to tournament server 260. The game state data may include user action data including characterization of user input to the interface such as key presses, mouse / joystick / direction pad input, and the like. The tournament server 260 may receive game status from the plurality of peer tournament modules 240. The games may be separate in that they do not share game state. For example, each game application 230 may be an asynchronous single player game. In some implementations, games share game state (eg, multiple players interact within one game environment).

In some implementations, the peer tournaments module 240 and the tournament server 260 does not provide game data to the game application 230 _i. In other words, in some implementations, they do not contribute to implementing the game instance, but rather observe the game, capture the game state, and enable a separate layer of multi-game tournament functionality.

Game being played (e.g., a game instance 230 _i) is, when it is asynchronous, the game server 250 and / or game instance 230 _i do not have a fundamental mechanism for starting the game play at the same time . The subject matter may include the steps of synchronizing the start of a plurality of asynchrony games in order to enable the live tournament to be played by the players simultaneously using the asynchrony game. This allows for live tournaments and may allow for direct comparison of gameplay (eg, by a commentator streaming a comparison of two video feeds). In some implementations, tournament server 260 and peer tournament module 240 _i may allow for synchronized initiation of game play.

  FIG. 6 is a process flow diagram illustrating a method 600 of gameplay synchronization initiation for an asynchronous game instance. Tournaments host tournaments and may be implemented by the tournament server 260 separate from the game server 250, which may provide game data to clients associated with each player.

  At 610, data characterizing two players registered in an online video game tournament may be received. Once the tournament server receives a request from the associated client that the player wishes to participate in the tournament, the player may be registered.

  At 620, instructions may be generated for synchronization of game play between two players. Once all player clients needed for the tournament match have registered and accepted the handshake from the tournament server 260, an instruction may be generated.

  At 630, the instructions are transmitted to the player client. The instructions cause the asynchronous start of the asynchronous game for the player client. The match may be considered to be synchronized when both clients start game play at similar times, this is within 10 seconds, 5 seconds, 2 seconds, 1 second, 0. It may be within 1 second or less.

In some implementations, the instructions, upon receipt by the client, cause game play to begin. Peer tournament module 240 _i may receive the instructions and perform a game start callback with game instance 230 _i . The callback may include executable code to be delivered to other code (in this case, game instance 230 _i ) as an argument, which is expected to recall (execute) the argument at a given time There is. This execution may be immediate as in synchronous callback or may occur at a later time as in asynchronous callback.

In some implementations, the peer tournament module 240 _i transmits another instruction to the game server 250 can cause the initiation of the communication of the game data from the game server 250 to the individual game instance 230 _i. The second instruction may be sent in response to receiving the first instruction from the tournament server 260.

In some implementations, the instructions define a time for the start of the game. For example, the instructions may specify that each game instance 230i should start game play at 9:00. In some implementations, the peer tournament module 240 _i receives a command to call the game instance with the game instance, either by receiving a command at or at a specified time, or at a specified time. By performing the back, the game can be started at a defined time.

In some implementations, the peer tournament module 240 _i transmits another instruction to the game server 250 can cause the initiation of the communication of the game data from the game server 250 to the individual game instance 230 _i. The second command may be transmitted at a defined time or upon receiving a command to initiate communication at a defined time.

FIG. 7 is a data flow diagram that illustrates data flow between components of peer tournament system 200. As shown in FIG. System shown includes two players, each with a separate game instance (230 ₁ and 230 _2), a peer tournament module (240 ₁ and 240 _2). Although two players are illustrated, it should be understood that more than two players are possible.

At 705, each peer tournament module (240 ₁ and 240 ₂ ) sends a request to join the tournament. The player may then be considered to be registered in the tournament. The player may join the lobby until there is a suitable match. Tournament server 260 may determine who will play the game.

For example, player 1 attempts to subscribe to the game by, for example, notifying tournament server 260 via an application programming interface (API) call. The tournament server 260 begins trying to find a match. Similarly, player 2 may attempt to join the game, for example by notifying the tournament server via an API call. In some implementations, while the player is waiting, the user interface control of the client may be communicated to the individual game instances (230 ₁ and 230 ₂ ), thus the game instances (230 ₁ and 230 ₂ ) may be , May display its own user interface over the duration of the match. The tournament server 260 determines whether Player 1 and Player 2 can be matched together. The matching process may depend on the number of elements, eg, relative skill and / or experience levels within the current or other game.

The first player may be considered as a host and may begin an initial order. In some implementations, the peer tournament module 240 _i is obtained by transmitting the authentication token to the tournament server 260, therefore, the tournament server may confirm the validity of the subscription request.

At 710, the tournament server 260 and each peer tournament module (240 ₁ and 240 ₂ ) may perform a handshake to complete the joining process. The handshake process may handle cases where the player has started matching but exits before the match is played. Prior to starting the game, the tournament server 260, the peer tournament module 240 _i, all players still confirms that it is waiting to play. If the peer tournament module 240 does not respond, the tournament server 260 may return to matching players who responded.

At 715, synchronization instructions may be generated and transmitted from the tournament server 260 to each peer tournament module (240 ₁ and 240 ₂ ). Synchronization instructions may be generated and transmitted in response to a successful match process. In addition, tournament server 260 may deduct the entry fee from the account associated with each player.

At 720, the tournament server 260 may also transmit data, including a game identifier (ID), a player ID, and game parameters. If the peer tournament module (240 ₁ and 240 ₂ ) still has user interface control, that control may be conveyed to the individual game instances (230 ₁ and 230 ₂ ). The match ID may include a unique ID (e.g., a numeric identifier) for a given specific instance of the tournament. The player ID may include a unique ID (eg, a numeric ID) for the user's entry into the tournament. The game parameters may include any information for configuring each game instance for execution / start of game play. For example, game parameters may include time periods, levels, and level abilities (eg, time limit = 3, match place = random, level_ability = disabled). While the game ID and game parameters transmitted may be the same for each player, the player ID may be different.

In 725, the game parameters can be transmitted to the individual game instance (230 ₁ and 230 ₂₎ from the individual peer tournament module (240 ₁ and 240 _2).

In 730, each peer tournament module (240 ₁ and 240 ₂₎ can cause the initiation of game play by the game instance (230 ₁ and 230 _2). This may be implemented, for example, by making callbacks or other API calls. In some instances, callbacks may be performed using game parameters.

At 735, normal game play proceeds simultaneously between each game instance (230 ₁ and 230 ₂ ) and the game server 250.

In some implementations, the player waits for a match (e.g., in the lobby) for only a limited amount of time before a match failure is declared. In some implementations, the peer tournament module 240 _i may wait for a defined amount of time, and then display an error to either leave the lobby or allow the player to continue waiting It will be either. In some implementations, the tournament creator or host may specify a maximum allowable wait time.

  In some implementations, player client connection information is stored by the tournament server 260. This may allow for reconnection by disconnected clients. The connection information may include an API key, an internet protocol (IP) address and / or domain name, and a port for connection. The existing match identification and tournament player identification may be used to identify the player (during reconnect) and connect players for individual matches via the tournament server 260.

  In some implementations, tournament server 260 may provide tournament management within the developer portal, player matching, payment processing and user balance management, video streaming, fraud / forgery detection, and game analysis.

  In some implementations, in-game scores and final score reports from the normal process of the game occur.

  In some implementations, the tournament server generates one or more random numbers or random seeds, and the same numbers and / or seeds all participate for use within the execution of the game instance. Can be sent or streamed to a client. By having each game instance use the same random number, the fairness between game instances can be improved.

  FIG. 3 is a system block diagram of a system 300 with an exemplary media management server 310 that enables video streaming of tournaments. Exemplary system 300 includes components as described above with reference to FIG. 2 and further includes media management server 310. Media management server 310 interfaces with tournament commentators 320, which may be tournament hosts, participants, or third parties (also referred to as streamers 320). The commentator 320 may be a client device. Media management server 310 may provide an automated virtual broadcast studio, such as, for example, an electronic sports tournament, for coverage by tournament commentator 320. Media management server 310 may receive video streams from clients and / or game state data from tournament server 260 to enable commentators to generate unique content associated with the tournament. The commentator video stream may be provided to the viewing client 330 and / or the player 210 and / or used to assemble the proposed broadcast for the tournament commentator 320. Media management server 310 may broadcast a live video feed (as controlled by tournament commentator 320) to player 210 and / or viewing client 330.

  FIG. 5 is an exemplary graphic user interface (GUI) 500 for event streaming video control and display. Event streaming video control and display 500 includes an interface in the tool that provides a streamer with the ability to bring a tournament in an efficient and attractive manner. Video control is available within the web browser, and the streamer is automatically seeded with the following abilities: replay of the top performers, player-seeding the individual opponents gameplay, Selecting and streaming based on the rounds, matches that have become tie-breakers, and whether the player's adversary has ended, sorting the video play order by rounds and / or seeds, and for real-time comparisons It may be provided to display replays of multiple players side by side.

  Video control panel 500 includes a video cue interface 510 for the streamer 320 to view, select and play videos or clips. Video queue interface 510 allows the streamer to interact with and control what is being broadcast to that stream. Video queue interface 510 includes two components: stream 510B currently playing, and queue 510A.

  The currently playing stream 510 B indicates to the streamer 320 which replay is currently being broadcast (eg, a live video stream or feed). This allows the streamer 320 to monitor what is currently sharing, even while previewing the stream or using a window to adjust replay so that it will not be shared with the audience It is a permanent space.

  Queue 510A provides streamer 320 with the ability to control the order in which video portions or replays will be shown. The streamer 320 may add the individual video portions that we want to show next, or change the order of the upcoming video to be broadcast. If the streamer 320 chooses to add nothing to the cue, or if the cue is empty, the system uses, for example, the top three best performing players 210 using match cross comparisons. By streaming one video, the video of player 210 having the highest score change over a one minute time period, and the like, the video of one of the players may be streamed automatically.

  Video control panel 500 includes a list 520 of players participating in the tournament game, video capture for which is available for broadcast to a wider audience. The player list 520 includes an option to preview 520A the replay or add 520B to the cue 510A. The video control panel 500 further includes a preview space 530 for viewing the list 540 of video and history game replays with an option to preview 540A the history game replays or add 540B to the cue 510A.

  In some implementations, the media management server 310 automatically breaks down the video captured at the player client 220 into highlight reels and key segments and assembles the proposed broadcast for the streamer 320. Thus, the media management server 310 enables automated functionality that acts as a "behind-analyst team" of the streamer 320 itself. This allows streamer 320 to act as a team of one person and easily select the right video to play without having to interrupt from the live stream to examine past videos or statistics. . Automatic analysis and features include the step of ranking the order of replays, causing the replays and player lists to appear in queue 510A in the order of their current ranking in the tournament. This makes it easy to find replays for any player based on their ranking. Prior to watching the video, the streamer can figure out what level of player they are selecting and what the outcome of the game might be.

  Although some variations are described in detail above, other modifications or additions are also possible.

  One or more aspects or features of the subject matter described herein may be digital electronic circuits, integrated circuits, specially designed application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), computer hardware It may be realized in hardware, firmware, software and / or a combination thereof. These various aspects or features may include an implementation in one or more computer programs executable and / or interpretable on a programmable system, including at least one programmable processor, which comprises: , Special purpose or general purpose, may be coupled to receive data and instructions from a storage system, at least one input device, at least one output device, and transmit data and instructions thereto. The programmable system or computing system may include clients and servers. Clients and servers are generally remote from one another and typically interact through a communication network. The relationship of client and server arises by virtue of the computer programs launching the individual computers and by having a client / server relationship to each other. Programmable systems or computing systems may include mobile devices such as tablets, phones, laptops, gaming platforms, and other similar devices.

  These computer programs, which may also be referred to as programs, software, software applications, applications, components or codes, contain machine instructions for the programmable processor, and are high level procedural language, object oriented programming language, functional programming language , A logical programming language, and / or an assembly / machine language. As used herein, the term "machine-readable medium" refers to providing machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. Refers to any computer program product, apparatus, and / or device used, such as, for example, magnetic disks, optical disks, memory, and programmable logic devices (PLDs). The term "machine readable signal" refers to any signal used to provide machine instructions and / or data to a programmable processor. A machine readable medium may store such machine instructions non-transiently, such as, for example, non-transient solid state memory, magnetic hard drive, or any equivalent storage medium, and the like. A machine-readable medium may alternatively or additionally include such machine instructions, such as, for example, a processor cache or other random access memory, etc., associated with one or more physical processor cores. It can be memorized in the form of hypersensitivity.

  One or more aspects or features of the subject matter described herein to provide interaction with a user may include a display device, such as a cathode ray tube (CRT) or liquid crystal, for displaying information to the user. It can be implemented on a computer with a display (LCD) or a light emitting diode (LED) monitor and a keyboard and pointing device, eg a mouse or trackball, which the user can provide input to the computer. Other types of devices can be used to provide user interaction as well. For example, the feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback, and input from the user is not limited to acoustic, audio or tactile It may be received in any form, including input. Other possible input devices include touch screens or other touch-sensitive devices, such as single or multipoint resistive or capacitive track pads, voice recognition hardware and software, optical scanners, optical pointers, digital image capture Devices and associated interpretation software, and the like, including but not limited to.

  In the above description and claims, phrases such as "at least one of" or "one or more of" may follow the conjunctive list of elements or features. The term "and / or" may also occur within the list of two or more elements or features. Such terms are used to individually refer to any of the listed elements or features, or otherwise of the listed elements or features, unless otherwise explicitly or explicitly contradicted, depending on the context in which they are used. It is intended to mean the listed elements or features in combination with any. For example, the phrases "at least one of A and B", "one or more of A and B", and "A and / or B" may be "A only, B only, or Both A and B are intended to mean ". A similar interpretation is intended for lists containing three or more items. For example, the phrases "at least one of A, B and C", "one or more of A, B and C", and "A, B and / or C" respectively , “A only, B only, C only, both A and B, both A and C, both B and C, or both A and B and C” are intended to mean. In addition, the use of the term "based on" in the above and in the claims is intended to mean "based at least in part" such that unlisted features or elements are also acceptable. Ru.

  The subject matter described herein may be embodied in a system, apparatus, method, and / or article, depending on the desired configuration. The implementations set forth in the foregoing description do not represent all implementations consistent with the subject matter described herein. Instead, these are merely some examples consistent with aspects related to the subject matter described. Although several variations have been described in detail above, other modifications or additions are also conceivable. In particular, further features and / or variations may be provided in addition to those described herein. For example, the implementations described above can be directed to various combinations and partial combinations of the disclosed features and / or combinations and partial combinations of some of the additional features disclosed above. In addition, the logic flows depicted in the accompanying figures and / or described herein do not necessarily require the particular order shown, or sequential order, to achieve desirable results. Other implementations may be within the scope of the following claims.

Claims (11)

Method,
Receiving data characterizing two players registered in an online video game tournament, each player executing a separate instance of the online video game, the online video game comprising: Async between players, said data being received by a tournament server hosting said tournament, said tournament server being separate from a game server providing game data to clients associated with said two players There are steps, and
Generating instructions for the synchronization of game play between the two players;
Transmitting the instruction to the client associated with the two players, wherein the instruction results in the start of synchronization of an asynchronous game for the two players. ,Method.   The method of claim 1, wherein the instruction causes game play to be initiated when received by the client.   Each client includes a game instance and a peer tournament module that receives the instruction, and responsive to receiving the instruction, starts game play by performing a game initiation callback with the game instance. The method of claim 2, wherein   Each client includes a game instance and a peer tournament module receiving the command, and in response to receiving the command, transmits a second command to the game server, and the game instance from the game server 3. The method of claim 2, causing initiation of communication of game data to.   The method of claim 1, wherein the instructions define a time for game start.   Each client includes a game instance and a peer-to-peer module for receiving the instruction, and causing the game to start at the defined time by executing a game initiation callback with the game instance. The method described in.   Each client includes a game instance and a peer-to-peer module that receives the instruction, and transmits a second instruction to the game server at the defined time to start, from the game server to the game instance The method according to claim 5, which causes the start of communication of game data. Transmitting to each client a game identifier, a player identifier, and game parameters, wherein the game identifier defines a unique identifier for the tournament, and the player identifier is for the entry of the user into the tournament The method according to claim 1, further comprising the step of: a unique identifier of the game parameters, wherein the game parameters include data for configuring each game instance to run.   The method of claim 1, further comprising: enabling simultaneous video streaming of game play for side-by-side viewing by a viewing client. A system,
At least one data processor,
A memory storing instructions which, when executed by the at least one data processor, cause the at least one data processor to perform the method according to any of the claims 1-9.
A system comprising:   A non-transitory computer program product storing instructions that, when executed by at least one data processor of at least one computing system, performs the method according to any of claims 1-9.