System, method, and program for inspecting game

Abstract

An object is to provide a system capable of detecting inter-version mismatch of a game. A system according to one embodiment of the present invention detects an inter-version mismatch of a game, the game state of which can be updated in accordance with a user operation, is provided with: a first processing unit that executes a game of a first version using a virtual instance generated in order to virtualize a user terminal or a software environment of the user terminal, and executes a game of a second version using a virtual instance generated in order to virtualize the user terminal or the software environment of the user terminal; executing game playing based on an operation log included in one game log, and acquiring a game state; a second processing unit that executes a game of a second version using the virtual instance, executes game play on the basis of an operation log included in the one game log, and acquires a game state; and a mismatch detection unit that detects an inter-version mismatch on the basis of a comparison between the game state acquired by the first processing unit and the game state acquired by the second processing unit.

Description

Technical Field

[0001] The present invention relates to a system, method and program for checking games, and in particular to a system, method and program for detecting mismatches between game versions. Background Art

[0002] In recent years, the number of players who play online games that multiple players can participate in has increased. The game is implemented through a game system that allows a portable terminal device to communicate with a server device of a game operator, and a player who operates a portable terminal device can play a game against other players. When providing a game, a game operator needs to check the game program in advance to detect loopholes (bugs). For example, Patent Document 1 discloses a system that can infer actions that are more likely to be performed by users to check the game program.

[0003] Prior art literature

[0004] Patent Literature

[0005] Patent Document 1: Japanese Patent No. 6438612 Summary of the invention

[0006] Problem that the invention aims to solve

[0007] As an online game, a card game called a digital collectible card game (DCCG) is known, which performs various actions according to a combination of cards or characters (hereinafter referred to as a "card combination"). For example, when operating an online game for a long time, with the version update of the game application, there is the following situation: the changes in the behavior (game rules) in the game that the developer did not expect occur due to the installation (implementation) inside the game application, bug fixes, and changes in the specifications of the library (library). In addition, there is the following situation: after the installation of the behavior that deviates from the developer's expectations is released and the behavior forms a fixed cognition among users, the installation of the regular behavior results in a change in the behavior in the game. In the past, in order to detect such unexpected changes in the behavior in the game between versions, that is, mismatches between game versions, only manual confirmation is an effective means. However, there are many games such as DCCG where the types of cards are exploding, and it is impossible to fully confirm the mismatch.

[0008] In one aspect, the present invention is made to solve such a problem, and one of its objects is to provide a system capable of checking a game.

[0009] Solutions for solving problems

[0010] [1] A system according to one embodiment of the present invention is a system for detecting a mismatch between versions of a game, wherein the game state of the game can be updated according to a user operation, wherein:

[0011] The system has:

[0012] a first processing unit that executes a first version of the game using a virtual instance generated to virtualize a user terminal or a software environment of the user terminal, performs game play based on an operation log included in a game log, and obtains game state information;

[0013] a second processing unit that executes a second version of the game using a virtual instance, performs game play based on the operation log included in the one game log, and acquires game state information; and

[0014] A checking unit detects a mismatch between versions based on a comparison between the game state information acquired by the first processing unit and the game state information acquired by the second processing unit.

[0015] [2] In one embodiment of the present invention,

[0016] The system according to [1], wherein:

[0017] The game is a battle game, and the game log includes the operation logs of the matched first user and the second user.

[0018] The first processing unit uses two virtual instances to execute the first version of the game and matches the two virtual instances. In one virtual instance, the game is played based on an operation log of a first user included in a game log. In the other virtual instance, the game is played based on an operation log of a second user included in the game log, and game status information is obtained.

[0019] The second processing unit uses two virtual instances to execute the second version of the game and matches the two virtual instances. In one virtual instance, the game is played based on the operation log of the first user included in the one game log. In the other virtual instance, the game is played based on the operation log of the second user included in the one game log, and game status information is obtained.

[0020] [3] In one embodiment of the present invention,

[0021] The system according to [2], wherein:

[0022] The system obtains the operation log of the first user and the operation log of the second user respectively from the obtained game log.

[0023] [4] In one embodiment of the present invention,

[0024] A system according to any one of [1] to [3], wherein:

[0025] The game log of the game is a game log obtained by a user playing the first version of the game.

[0026] [5] In one embodiment of the present invention,

[0027] A system according to any one of [1] to [4], wherein:

[0028] Game status information is data that can be output in a specified format.

[0029] The first processing unit and the second processing unit respectively obtain a plurality of game status information obtained according to the executed game play,

[0030] The checking unit detects an inter-version mismatch based on a degree of matching between corresponding game state information acquired by the first processing unit and game state information acquired by the second processing unit.

[0031] [6] In one embodiment of the present invention,

[0032] A system according to any one of [1] to [5], wherein:

[0033] The first processing section and the second processing section execute the game in a headless mode in a virtual instance so that at least graphic processing and sound processing are disabled.

[0034] [7] A method according to an embodiment of the present invention is a method executed by a computer for detecting a mismatch between versions of a game, wherein the game state of the game can be updated according to a user's operation, the method comprising:

[0035] A first acquisition step, using a virtual instance generated to virtualize a user terminal or a software environment of a user terminal to execute a first version of the game, playing the game based on an operation log included in a game log, and acquiring game state information;

[0036] A second acquisition step of executing a second version of the game using a virtual instance, performing game play based on the operation log included in the one game log, and acquiring game state information; and

[0037] A detection step is performed to detect a mismatch between versions based on a comparison between the game status information obtained in the first obtaining step and the game status information obtained in the second obtaining step.

[0038] [8] In one embodiment of the present invention,

[0039] The method according to [7], wherein:

[0040] The game is a battle game.

[0041] The game log includes the operation logs of the matched first user and second user.

[0042] In the first acquisition step, two virtual instances are used to execute the first version of the game, and the two virtual instances are matched. In one virtual instance, the game is played based on the operation log of the first user included in a game log, and in the other virtual instance, the game is played based on the operation log of the second user included in the game log, and game status information is acquired.

[0043] In the second acquisition step, two virtual instances are used to execute the second version of the game, and the two virtual instances are matched. In the virtual instance of one party, the game is played based on the operation log of the first user included in the one game log, and in the virtual instance of the other party, the game is played based on the operation log of the second user included in the one game log, and game status information is obtained.

[0044] [9] A program according to one embodiment of the present invention is a program that causes a computer to execute each step of the method of [7] or [8].

[0045] Effects of the Invention

[0046] In one aspect, in accordance with the present invention, games can be checked. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Figure 1 This is an overall structural diagram of a system according to one embodiment of the present invention.

[0048] Figure 2 This is a block diagram showing the hardware configuration of a management server according to one embodiment of the present invention.

[0049] Figure 3 This is a block diagram showing the hardware structure of a virtual instance server according to one embodiment of the present invention.

[0050] Figure 4 This is a block diagram showing the hardware configuration of a test game server according to one embodiment of the present invention.

[0051] Figure 5 This is an example of a functional block diagram of a system according to one embodiment of the present invention.

[0052] Figure 6 This is an example of a functional block diagram of a system according to one embodiment of the present invention.

[0053] Figure 7 This is a diagram showing a flowchart of the processing of the system according to one embodiment of the present invention.

[0054] Figure 8 1 is a diagram showing an example of a game screen of a game G displayed on the display of the user terminal T. DETAILED DESCRIPTION

[0055] Below, the embodiments of the present invention are described with reference to the accompanying drawings. The system of the embodiments of the present invention is a system for checking games by detecting mismatches between versions of games (game programs or game applications), and the disk of the game can be updated according to the user's operation. In the embodiments of the present invention, mismatch between versions refers to: with the version update of the game application, accompanied by the installation, bug fixes, and specification changes of the library within the game application, the behavior changes in the game that the game operator (developer) did not expect; or after the installation of the behavior that deviates from the expected behavior of the game operator is released and the behavior forms a fixed cognition among users, with the version update of the game application, the regular behavior of the installation results in the behavior of the game changing.

[0056] The game of the embodiment of the present invention is a battle card game in which the board is updated when an action (attack, event, etc.) is performed based on a user operation on a certain board. In the following description, for convenience, the game of the embodiment of the present invention is referred to as "game G" to indicate that, for example, different versions of the game are games of the same theme, but game G is not limited to a specific game and can be set to any battle card game. In the embodiment of the present invention, "board" is an example of "game state", but "game state" can also represent the "board" itself. Game G of the embodiment of the present invention is an online game that can be played on a mobile terminal such as a smartphone, and is a game that the game operator can update as needed. In the embodiment of the present invention, the first version of game G is a currently released game that can be played by a user, and the second version of game G is a game that is scheduled to be released in a newer version than the first version of game G. For example, in the case where version 3 of game G is to be updated to version 4 of game G, the first version is version 3 and the second version is version 4. In the embodiment of the present invention, an application can refer to an application installed on a smartphone or a tablet terminal, and can also refer to all applications. In the embodiment of the present invention, a game can also refer to a game program or a game application. In this specification, for the sake of convenience of description, unnecessary detailed description may be omitted in some cases.

[0057] The game G of the embodiment of the present invention is provided by a game server S (not shown), which has the same structure as a general game server that provides online games. The game server S is a server that is accessed by a user terminal T (not shown) such as a smart phone when a user actually plays the game. For example, the user terminal T is connected to the game server S via a specified game application A, and when the user ID and password are used to be identified and authenticated, the user can play the game G as a user of the user ID via the user terminal T. The test game server 30 can have the same structure as the game server S, but is different from the game server S in that it only accepts access from the virtual instance server 20. The game G provided by the game server S is the first version of the game G.

[0058] The game server S stores application programs (game programs) for games and is connected to the user terminals T of each user playing the game via a network. During the period when each user executes the game application A installed on the user terminal T, the terminal device T communicates with the game server S, and the game server S provides game services via the network. The game server S accepts a request to start a battle game from the user via the user terminal T, matches two users (a first user and a second user), and starts the battle game. A battle game starts when two users are matched, and ends when the winner is determined, the game is determined to be a draw, or the game is determined to be an invalid match. In addition, in this specification, a battle game is sometimes simply described as a battle.

[0059] Figure 8 4 is a diagram showing an example of a game screen 40 of a game G displayed on a display of a user terminal T. The game screen 40 shows a game screen of a card battle between the user and other users. The game G of an embodiment of the present invention is a game in which a user selects a card from a holding card group consisting of a plurality of cards and places the card in a field (game field) 43 to perform various events corresponding to a combination of cards and occupations (classes) and progress. The game G is a battle game in which the user operating the user terminal T, i.e., the user, and other users operating other user terminals T each select a card from a holding card group and place it in a field 43 to battle. In one example, in the game G, each card 41 has card definition information including parameters such as a card ID, a card category, life value, attack power, and attributes, and each occupation has occupation definition information.

[0060] The game screen 40 shows a first card group 42a as the hand of the user and a first card group 42b as the hand of other users. The first card group 42a and the first card group 42b include cards 41 associated with characters, props or spells. The game G is configured so that the user cannot confirm the cards 41 of the first card group 42b of other users. The game screen 40 also shows a second card group 44a as the card pile of the user and a second card group 44b as the card pile of other users. In addition, the user or other users may not be actual players, but game AI, etc., operated by a computer.

[0061] The held card group held by each user is composed of the user's hand 42 (42a or 42b) and the user's card pile 44 (44a or 44b), and is generally referred to as a card group. Whether each card 41 held by the user is included in the hand 42 or in the card pile 44 is determined according to the progress of the game. The hand 42 is a card group that the user can select and put into the field 43, and the card pile 44 is a card group that the user cannot select. The held card group is composed of multiple cards 41, but depending on the progress of the game, the held card group is sometimes composed of a single card 41. In addition, the card group of each user can be composed of all different types of cards 41, or it can be composed of a part of the same type of cards 41. In addition, the type of cards 41 constituting the card group of this user can also be different from the type of cards 41 constituting the card group of other users. In addition, the held card group held by each user can also be composed of only hand cards 42.

[0062] The game screen 40 shows the character 45a selected by the user and the character 45b selected by other users. The characters 45a and 45b selected by the user are different from the characters associated with the cards, and are used to determine the occupation representing the type of the card group held. In one example, the game G is configured so that the cards 41 held by the user are different according to the occupation. In one example, the game G is configured so that the types of cards that can constitute the card deck of each user are different according to the occupation. However, the game G may not include the occupation. In this case, the game G may not perform the above-mentioned occupation-based limitation, and may also be set to not display the character 45a selected by the user and the character 45b selected by other users on the game screen 40.

[0063] During the period when the user terminal T executes the game application A, that is, during the period when the user terminal T executes the game G, the game server S stores log data related to the game, that is, the game log. The game log includes a log that can reproduce the user operations of each user in the game, that is, the playback log, including the operation logs of the matched first user and the second user.

[0064] The game G of the embodiment of the present invention is a battle (card battle) including a plurality of rounds of battle games. In one example, in the game G, in each round, the user or other users can attack the opponent's card 41 or character 45 by performing operations such as selecting their own card 41, or can use their own card 41 to produce a prescribed effect or trigger an event. In one example, in the game G, when the user selects the card 41 and attacks, the opponent's card 41 or character 45 can be selected as the attack object. In one example, in the game G, when the user selects the card 41 and attacks, the attack object is automatically selected according to the card. In one example, in the game G, in response to the user operation on a card or character on the game screen 40, the life value, attack power and other parameters of other cards or characters are changed. In one example, in the game G, when the board meets the prescribed conditions, the card 41 corresponding to the prescribed conditions is excluded from the field 43, or the card 41 is moved to the card deck of the user or other users. For example, it can be set to a playback log that comprehensively includes the historical records of the information as described above.

[0065] In an embodiment of the present invention, the game log stored by the game server S includes a log that can reproduce the user operations of each user who plays against each other in each battle, that is, a playback log. For example, the playback log (game log) of a battle is a playback log (game log) from the start of the battle to the end of the battle or a playback log (game log) from the start of the battle to the termination of the battle. The playback log contains action data. In one example, the playback log of each battle contains information about the card 41 selected by each user and the attack associated with it for each round and each user. In one example, the playback log of each battle contains information about the card 41 selected by each user and the prescribed effect associated with it for each round and each user.

[0066] The board information at least represents information that the user can visually confirm or recognize by playing the game, for example, by game operation or display on the game screen. The board information includes data of the card 41 placed on the field 43. Each piece of board information is data corresponding to the board at each moment corresponding to the progress of the same game. The board information can include information of the card 41 of the first card group 42a (or the card group held) of the user, and can include information of the card 41 of the first card group 42b (or the card group held) of other users. The game log includes board information history record data that records changes in the board, and thus, the game log includes board information at the start of each battle and board information at the end of the battle. The board information history record data is stored in association with the playback log of each battle.

[0067] The action data includes the operation (input) selected or determined by the user and the content determined (executed) by the game program (game server S) based on the operation. The action data included in the playback log includes data showing the user's operation (for example, user input related to playing the game), that is, the operation log. An action is executed on a certain disk surface based on a user operation and can cause the disk surface to change. For example, a user operation is a user selecting a card 41, etc., and an action is an action executed based on the user selecting a card 41, etc. The data of each action included in the playback log is data corresponding to the action executed on each disk surface based on the user operation.

[0068] In one example, an action is an attack on another card 41 of a card 41 or a character 45, or a character 45. In this case, for example, the action data includes the card 41 or character 45 selected as the attacker by the user operation, the card 41 or character 45 as the target of the attack, and the attack amount (damage amount) of the attack. In one example, an action is a prescribed effect produced by a card 41 or a character 45. In this case, for example, the action data includes the card 41 selected by the user operation to produce the prescribed effect, the card 41 or character 45 as the target of the effect, and the effect amount of the effect (e.g., the amount of health restored).

[0069] In one example, a replay log is defined by a column of data about actions that were performed on each board. n It is an array that includes actions arranged in chronological order and the final state that ultimately determines the outcome, and can be expressed by formula (1).

[0070] Replaylog n :=[Action o , Action 1 ..., Win_Lose] (1)

[0072] Here, Replaylog n Indicates the nth playback log (for example, the nth battle), Action i It indicates the i-th action that was executed, and Win_Lose indicates the status that determines the win, loss, draw, or invalid match.

[0073] In one example, the board information history data is defined by a column of board information generated by playing a battle game. n It can be expressed by formula (2).

[0074] Statelogn :=[State o , State 1 …, State e ] (2)

[0076] Here, State i Indicates the i-th disk information. 0 Indicates the board information when the battle starts, State e Indicates the board information at the end of the game, such as win, loss, draw, or invalid match.

[0077] In one example, State i is the set of cards 41 placed on the field 43 and cards 41 held by the user, and can be expressed by equation (3).

[0078]

[0079] Here,

[0080]

[0081] The cards are the 0th to nath cards on the first user (first player) side placed on the field 43,

[0082]

[0083] are the 0th to nbth cards on the second user (back attack) side placed on the field 43,

[0084]

[0085] It is the 0th to ncth cards added to the hand of the first user (first striker),

[0086]

[0087] The second user (back attack) has added the 0th card to the ndth card in his hand. For example, if the first user's card placed on the field 43 is 1, in State i In the example, the card of the first user placed on the field 43 has only

[0088]

[0089] In the case where the first user's card placed on the field 43 is 0, in State iIn the example, data indicating that there is no card is included as the card of the first user placed on the field 43. The same is true for the card of the second user placed on the field 43, the card added to the hand, and the like.

[0090]

[0091] This is information other than the card 41 itself, such as data such as predetermined points associated with the card 41 or the character 45 .

[0092] In one example, each card i It can be expressed by formula (4).

[0093] card i :={name, explanation} (4)

[0095] Here, name is text data indicating the name of the card, and explanation is text data explaining the ability and skill of the card.

[0096] Figure 1 FIG. 1 is an overall structural diagram of a system 1 according to an embodiment of the present invention. Figure 1 As shown, the system 1 includes a management server 10, a virtual instance server 20 and a test game server 30. The management server 10, the virtual instance server 20 and the test game server 30 are connected to a network 2 such as the Internet and can communicate with each other.

[0097] In an embodiment of the present invention, a virtual environment that realizes the virtualization of all elements of the game service constituting the system 1 is used. For example, the management server 10, the virtual instance server 20, and the test game server 30 are respectively implemented by virtual servers such as virtual machines or cloud systems. Technologies related to virtual environments can use technologies described in Japanese Patent Gazette No. 2021-145939, for example. System 1 can be either a single device or a plurality of devices. For ease of explanation, in the following description of the hardware structure, the case where the management server 10, the virtual instance server 20, and the test game server 30 are each implemented by one device is described.

[0098] Figure 2 1 is a block diagram showing the hardware structure of a management server 10 according to an embodiment of the present invention. The management server 10 includes a processor 11, an input device 12, a display device 13, a storage device 14, and a communication device 15. These components are connected via a bus 16. In addition, an interface is provided between the bus 16 and each component as required.

[0099] The processor 11 controls the overall operation of the management server 10. The processor 11 is, for example, a CPU. The processor 11 reads and executes programs and data stored in the storage device 14 to perform various processes. The processor 11 may be composed of a plurality of processors.

[0100] The input device 12 is a user interface for accepting user input to the management server 10 , such as a touch panel, touch pad, keyboard, mouse, or buttons. The display device 13 is a display that displays application screens and the like to the user of the management server 10 under the control of the processor 11 .

[0101] The storage device 14 includes a main storage device and an auxiliary storage device. The main storage device is, for example, a volatile memory capable of high-speed information reading and writing, and is used as a storage area and a work area when the processor 11 processes information. The auxiliary storage device stores various programs and data used by the processor 11 when executing each program. The auxiliary storage device is a non-volatile storage device or non-volatile memory, such as a flash memory such as eMMC, UFS, SSD, or a removable storage device.

[0102] The communication device 15 is a module, device or apparatus capable of exchanging data with other computers such as user terminals or servers via a network. The communication device 15 can be a device, module, etc. for wireless communication or a device, module, etc. for wired communication.

[0103] Figure 3 2 is a block diagram showing the hardware structure of a virtual instance server 20 according to an embodiment of the present invention. The virtual instance server 20 includes a processor 21, an input device 22, a display device 23, a storage device 24, and a communication device 25. These components are connected via a bus 26. In addition, an interface is provided between the bus 26 and each component as required. The components of the processor 21, the input device 22, the display device 23, the storage device 24, and the communication device 25 correspond to the above-mentioned processor 11, the input device 12, the display device 13, the storage device 14, and the communication device 15, respectively, and have the same structure, so the description thereof is omitted. The virtual instance server 20 may not include the input device 22 and the display device 23.

[0104] Figure 43 is a block diagram showing the hardware structure of a test game server 30 according to an embodiment of the present invention. The test game server 30 includes a processor 31, an input device 32, a display device 33, a storage device 34, and a communication device 35. These components are connected via a bus 36. In addition, an interface is provided between the bus 36 and each component as required. The components of the processor 31, the input device 32, the display device 33, the storage device 34, and the communication device 35 correspond to the above-mentioned processor 11, the input device 12, the display device 13, the storage device 14, and the communication device 15, respectively, and have the same structure, so the description is omitted. The test game server 30 may not include the input device 32 and the display device 33.

[0105] System 1 is a system for the following processing: executing a first version of a game G and a second version of a game G, causing an execution robot (bot) to play the game by following the operations of operation logs of two users obtained (generated) from a playback log, and comparing the historical records of the board information in the two versions generated as a result, thereby detecting a mismatch between the versions of the game G.

[0106] Figure 5 1 is an example of a functional block diagram of the system 1 according to an embodiment of the present invention. The management server 10 includes a game execution control unit 50, a check unit 53, a game log database (game log DB) 54, a first game state database (first game state DB) 55, and a second game state database (second game state DB) 56. The game execution control unit 50 includes a first game execution control unit 51 and a second game execution control unit 52. The virtual instance server 20 includes a first virtual instance control unit 61 and a second virtual instance control unit 62. The test game server 30 includes a first game server control unit 71 that controls the process of providing the first version of the game G and a second game server control unit 72 that controls the process of providing the second version of the game G.

[0107] In the embodiment of the present invention, the management server 10, the virtual instance server 20, and the test game server 30 are implemented by a virtual environment. However, when the management server 10, the virtual instance server 20, and the test game server 30 are implemented by a single device, the functions of the system 1 are implemented, for example, by the following method: at least one of the processors 11 of the management server 10, the processors 21 of the virtual instance server 20, and the processors 31 of the test game server 30 executes a program and stores data in at least one of the storage devices 14, 24, and 34 as needed, or on this basis, data is delivered or received between the management server 10, the virtual instance server 20, and the test game server 30 as needed. At least one of the game log DB 54, the first game state DB 55, and the second game state DB 56 may be implemented only by the storage device 14. In this way, since various functions are implemented by reading in programs, part or all of one functional unit (for example, a software module) may also be included in another functional unit. In the embodiment of the present invention, these functions of the system 1 can be realized by the operation of each component based on the operation when the management server 10, the virtual instance server 20, and the test game server 30 are each realized by a single device.

[0108] The game log DB 54 stores the game logs stored by the game server S. The playback logs stored in the game log DB 54 are playback logs in the form of data represented by formula (1). The game log DB 54 stores the playback logs of each battle, and stores each playback log in association with the board information at the start of the battle. In an embodiment of the present invention, the system 1 determines whether there is a mismatch between versions of the game G according to the playback log of each battle. The playback log of the battle that is the object of determination is called an object playback log. For example, the game log DB 54 only needs to store a game log containing multiple object playback logs for which mismatches are to be verified and data associated with the object playback logs.

[0109] The game execution control unit 50 replays the log from one object. n ) respectively obtain (generate) the operation log of the first user (e.g., the first-hand user) and the operation log of the second user (e.g., the second-hand user). In one example, the game execution control unit 50 extracts the part associated with the operation log from the object playback log to generate the operation log of each user. The game execution control unit 50 obtains the board information at the start of the battle from the board information history record data associated with the object playback log to generate the card deck at the start of the battle between the first user and the second user.

[0110] The first game execution control unit 51 controls the actions of the first virtual instance control unit 61 and the first game server control unit 71, so that the virtual instance 63 executes the first version of the game G, plays the game based on the operation log generated according to the object playback log, and obtains the board information. The second game execution control unit 52 controls the actions of the second virtual instance control unit 62 and the second game server control unit 72, so that the virtual instance 64 executes the second version of the game G, plays the game based on the operation log generated according to the object playback log, and obtains the board information.

[0111] The first virtual instance control unit 61 generates a virtual instance 63 for virtualizing a user terminal for playing a game or a software environment of the user terminal according to a control signal from the first game execution control unit 51. The second virtual instance control unit 62 generates a plurality of virtual instances 64 for virtualizing a user terminal for playing a game or a software environment of the user terminal according to a control signal from the second game execution control unit 52. The virtual instance 63 is a virtual instance for executing the first version of the game G, and is connected to the first game server control unit 71, so as to be able to execute the first version of the game G. The virtual instance 64 is a virtual instance for executing the second version of the game G, and is connected to the second game server control unit 72, so as to be able to execute the second version of the game G.

[0112] In one example, the first virtual instance control unit 61 generates 2N virtual instances 63 for N (N is a natural number) object playback logs, and the second virtual instance control unit 62 generates 2N virtual instances 64 for N object playback logs. The first virtual instance control unit 61 assigns the deck of the first user at the start of the battle to one of the two virtual instances 63 generated for one object playback log, and the deck of the second user at the start of the battle to the other, based on the board information associated with the object playback log, and causes these virtual instances 63 to send a battle start request to the first game server control unit 71. The second virtual instance control unit 62 assigns the deck of the first user at the start of the battle to one of the two virtual instances 64 generated for one object playback log, and the deck of the second user at the start of the battle to the other, based on the board information associated with the object playback log, and causes these virtual instances 64 to send a battle start request to the second game server control unit 72.

[0113] Virtual instances 63 and 64 are virtual instances for virtualizing a user terminal or a software environment of a user terminal, and can be realized, for example, by using an operating system-level virtualization technology called a "container" such as docker (registered trademark). Docker (registered trademark) controls the Linux (registered trademark) container provided by the Linux (registered trademark) kernel, and can realize virtualization in units of processes, that is, provide a space separated from other processes in terms of CPU utilization and file system utilization. Since each container is separated from each other, it can behave as if it is the only game application that performs actions in the operating system. Therefore, by executing the game application in each container and starting the process of the game application, the execution of the game application in the user terminal can be virtually realized. Therefore, multiple virtual instances can be generated in a server device, and multiple game applications can be executed in parallel in isolation to generate verification results. In an embodiment of the present invention, as virtual instances 63 and 64, docker (registered trademark) "containers" are used. For example, virtual instances 63 and 64 are virtualized smartphones.

[0114] The first game server control unit 71 selects two virtual instances 63 for battle from the virtual instances 63 for which the battle start request has been received, matches them, and executes the battle game using the matched virtual instances 63. The second game server control unit 72 selects two virtual instances 64 for battle from the virtual instances 64 for which the battle start request has been received, matches them, and executes the battle game using the matched virtual instances 64.

[0115] When the first virtual instance control unit 61 assigns the first user's deck to one of the two virtual instances 63 generated for one object playback log and assigns the second user's deck to the other, the first game execution control unit 51 attaches or associates the same ID to the two virtual instances 63. The ID only needs to be able to be used to uniquely identify the object playback log. The first game server control unit 71 is configured to match the two virtual instances 63 attached or associated with the same ID. Similarly, when the second virtual instance control unit 62 assigns the first user's deck to one of the two virtual instances 64 generated for one object playback log and assigns the second user's deck to the other, the second game execution control unit 52 attaches or associates the same ID to the two virtual instances 64. The second game server control unit 72 is configured to match the two virtual instances 64 attached or associated with the same ID.

[0116] In an embodiment of the present invention, the virtual instance 63 executes the first version of the game G by executing the game application A executed in the user terminal for playing the game in a headless mode. For example, the first game execution control unit 51 or the first virtual instance control unit 61 executes the first version of the game G by executing the game application A executed in the user terminal for playing the game in a headless mode in the virtual instance 63 in an autopilot manner, so that at least the graphics processing and the sound processing are invalidated. The virtual instance 64 executes the second version of the game G by executing the game application A in a headless mode. For example, the second game execution control unit 52 or the second virtual instance control unit 62 executes the second version of the game G by executing the game application A in the headless mode in the virtual instance 64 in an autopilot manner, so that at least the graphics processing and the sound processing are invalidated.

[0117] Virtual instance 63 executes the first version of game G and plays the game based on the operation log, outputting board information each time an action is performed. Virtual instance 64 executes the second version of game G and plays the game based on the operation log, outputting board information each time an action is performed.

[0118] The first game execution control unit 51 obtains the board information output by the virtual instance 63, generates the board information history data obtained by arranging the board information in chronological order, and stores it in the first game state DB 55. The second game execution control unit 52 obtains the board information output by the virtual instance 64, generates the board information history data obtained by arranging the board information in chronological order, and stores it in the second game state DB 56. The virtual instances 63 and 64 output the board information in a data format such as JSON, XML, CSV, etc., from which differences can be extracted. The board information is data represented by formula (3). The board information history data generated by the first game execution control unit 51 and the second game execution control unit 52 is board information history data in the data format represented by formula (2).

[0119] The checking unit 54 generates the board information history data (Statelog) based on the board information acquired from the virtual instance 63 by the first game execution control unit 51. n ) and the board information history data (Statelog′) generated by the second game execution control unit 52 based on the board information obtained from the virtual instance 64 n) to detect the mismatch between versions, the virtual instance 63 executes the game based on the operation log generated according to an object playback log, and the virtual instance 64 executes the game based on the operation log generated according to the object playback log. Here, in the disk information history data (Statelog n ) in the i-th disk information

[0120] State i

[0121] The state log data generated by the second game execution control unit 52 is n ) in the i-th disk information

[0122] State' i

[0123] In case of inconsistency,

[0124] That is, in

[0125] State i ≠State′ i

[0126] In the case of , the inspection unit 54 determines that a mismatch is detected or exists. That is, the system 1 detects that a mismatch occurs between versions in the game play based on the operation log generated based on the object playback log.

[0127] State i =State′ i

[0128] In the case of , the inspection unit 54 determines that no mismatch is detected or that there is no mismatch.

[0129] According to the above, the inspection unit 54 can be called a mismatch detection unit, which detects the disk surface information (State i ) and the disk information (State ') obtained from the virtual instance 64 i ) to detect version mismatches, the virtual instance 63 executes the game based on an operation log generated according to an object playback log, and the virtual instance 64 executes the game based on an operation log generated according to the object playback log.

[0130] Figure 6This is an example of a functional block diagram of the system 1 according to the embodiment of the present invention viewed from the perspective of the entire system 1. The system 1 includes a first processing unit 81, a second processing unit 82, a checking unit 83, a game log DB 84, a first game state DB 85, ​​and a second game state DB 86. Figure 5 The functional block diagram shown is Figure 6 The checking unit 83 , the game log DB 84 , the first game state DB 85 , and the second game state DB 86 are functional units corresponding to the checking unit 54 , the game log DB 54 , the first game state DB 55 , and the second game state DB 56 .

[0131] The first processing unit 81 includes a first game execution control unit 51 , a first virtual instance control unit 61 , and a first game server control unit 71 , and the second processing unit 82 includes a second game execution control unit 52 , a second virtual instance control unit 62 , and a second game server control unit 72 .

[0132] The first processing unit 81 uses two virtual instances 63 to execute the first version of the game G, and matches the two virtual instances 63. In the virtual instance 63 of one side, the game is played based on the operation log of the first user included in the object playback log, and in the virtual instance 63 of the other side, the game is played based on the operation log of the second user included in the object playback log, and the board information is obtained. Similarly, the second processing unit 82 uses two virtual instances 64 to execute the second version of the game G, and matches the two virtual instances 64. In the virtual instance 64 of one side, the game is played based on the operation log of the first user included in the object playback log, and in the virtual instance 64 of the other side, the game is played based on the operation log of the second user included in the object playback log, and the board information is obtained. The inspection unit 83 checks the board information (State i ) and the disk information (State ' i ) to detect the mismatch between versions. In one example, the first processing unit 81 and the second processing unit 82 can be respectively implemented as an execution robot that plays the game and outputs the board information in accordance with the operation log.

[0133] Figure 7 This is a diagram for explaining an example of a flowchart of the processing of the system 1 according to one embodiment of the present invention.

[0134] In step S1, the first processing unit 81 uses the virtual instance 63 to execute the first version of the game G. In step S2, the first processing unit 81 uses the virtual instance 63 to play the game based on the operation log included in the object playback log, and obtains the board information. In step S3, the second processing unit 82 uses the virtual instance 64 to execute the second version of the game G. In step S4, the second processing unit 82 uses the virtual instance 64 to play the game based on the operation log included in the object playback log, and obtains the board information. In step S5, the inspection unit 54 determines whether there is a mismatch based on the board information obtained in step S2 and the board information obtained in step S4, thereby detecting a mismatch between versions.

[0135] In this flowchart, as long as steps S1 and S2 are executed in the order of steps S1 and S2, steps S3 and S4 are executed in the order of steps S3 and S4, and step S5 is executed after steps S2 and S4 are executed, the order of other steps can also be changed. In addition, in this flowchart, step S2 is executed while step S1 is being executed (step S1 is executed while step S2 is being executed), and step S4 is executed while step S3 is being executed. For example, the execution of steps S1 and S3 may be started at the same time, and the execution of steps S2 and S4 may be started at the same time.

[0136] Next, main functions and effects of the system 1 according to the embodiment of the present invention will be described.

[0137] In the past, the only effective means to detect mismatches between game versions was manual confirmation. However, for battle card games such as DCCG, there are many games with explosive card types, and it is impossible to fully confirm mismatches. Although there is technology that can automatically detect invalid match (No Contest) failures, in order to manually confirm mismatches between versions, a lot of time needs to be allocated to the debugging process.

[0138] In the embodiment of the present invention, a virtual environment that realizes virtualization of the management server 10, the virtual instance server 20, and the test game server 30 constituting the system 1 is used to realize the functional units of the system 1, such as the first processing unit 81, the second processing unit 82, and the inspection unit 83. The first processing unit 81 reproduces the game playing environment of the first version of the game G, plays the game G according to the operation log obtained (generated) from the playback log obtained from the operating game server S, executes actions and obtains (generates) the changed board information. The second processing unit 82 reproduces the game playing environment of the second version of the game G, plays the game G according to the operation log obtained (generated) from the playback log obtained from the operating game server S, executes actions and obtains (generates) the changed board information.

[0139] By setting such a structure, the inspection unit 83 can detect mismatches between different versions of the game G only by performing pattern matching of two disk information. For example, it is possible to mechanically determine in which specific game state (disk) and action combination a mismatch will occur, and it is possible to verify the mismatch for the playback logs of a large number of users (ideally all users), so that all behaviors of the game software presented to the end user can be fully verified. Therefore, for example, according to an embodiment of the present invention, the debugging man-hours of a long-term operation theme can be reduced.

[0140] As described above, there has not yet been proposed a technology that virtualizes the entire game environment including everything from the client to the server, reproduces the game play environment of an arbitrary version of the game, and uses actual playback logs to discover mismatches between versions.

[0141] In addition, the embodiment of the present invention can convert a large amount of playback logs that have been idle until now into a resource for improving game quality, such as for verifying the compatibility of different versions of the game G.

[0142] Unless otherwise specified, the above-mentioned effects are also applicable to other embodiments and modifications.

[0143] The system 1 of the embodiment of the present invention may also be a device. The embodiment of the present invention may also be a method, a program, or a computer-readable storage medium storing the program for realizing the functions of the system 1 described above, the information processing method shown in the flowchart, or the program. In addition, the embodiment of the present invention may also be a server that can provide a computer with a program for realizing the functions of the embodiment of the present invention described above, and the information processing method shown in the flowchart. The same is true in other embodiments and modified examples.

[0144] The system 1 of the embodiment of the present invention is, for example, a system that can detect mismatches after checking different versions of the same theme game G. Therefore, the system 1 of the embodiment of the present invention can be set as a system for checking games, and its purpose is to solve the following problem: to provide a system capable of checking games. In this embodiment, the checking unit 54 can be set as the following functional unit: the board information history data (Statelog) generated by the first game execution control unit 51 based on the board information obtained from the virtual instance 63 is recorded in the state log. n ) and the board information history data (Statelog′) generated by the second game execution control unit 52 based on the board information obtained from the virtual instance 64 n) to determine whether there is a mismatch, the virtual instance 63 executes the game based on the operation log generated according to an object playback log, and the virtual instance 64 executes the game based on the operation log generated according to the object playback log. For example, the inspection unit 54 is configured to determine the board information history data (Statelog) generated by the first game execution control unit 51 for all i (i = 0 to e). n ) in the i-th disk information

[0145] State i

[0146] The state log data generated by the second game execution control unit 52 is n ) in the i-th disk information

[0147] State' i

[0148] In this case, the inspection unit 54 may determine whether there is a mismatch but may not detect the mismatch. The same is true for the inspection unit 83.

[0149] In a modified embodiment of the present invention, the system 1 can be configured as a system for checking a game, for example. For example, in this modified embodiment, the first processing unit 81 and the second processing unit 82 execute the same version of the game. For example, in this case, the second processing unit 82 also uses two virtual instances 64 to execute the first version of the game G, plays the game in the two virtual instances 64, and obtains the board information. By setting such a structure, it is possible to check for a fault in the operation of a certain version of the game.

[0150] In one or more embodiments of the present invention, the game log stored by the game server S and stored in the game log DB 54 can include a seed value of a random number. For example, the seed value of each random number is stored in association with each playback log, or in association with the data of each action executed using the random number in the data of the action contained in the playback log (data obtained by performing random number processing). For example, when a seed value of a random number is used when generating a random number through a certain battle game, the seed value is stored as part of the game log in association with the playback log obtained in the battle game. For example, in this embodiment, the first game execution control unit 51 causes the virtual instance 63 to execute the first version of the game G, so that it plays the game based on the operation log generated according to the object playback log, and when causing the first game server control unit 71 to perform random number processing, it uses the seed value of the random number associated with the object playback log or the seed value of the random number associated with the data of the action as the object in the object playback log to perform random number processing and obtain disk information. In this example, the processing of the second game execution control unit 52 is also the same as the processing of the first game execution control unit 51. In addition, for example, in this embodiment, the first processing unit 81 uses two virtual instances 63 to execute the first version of the game G, and matches the two virtual instances 63, and plays the game based on the operation log of the first user included in the object playback log in one virtual instance 63, and plays the game based on the operation log of the second user included in the object playback log in the other virtual instance 63, and when performing random number processing, the seed value of the random number associated with the object playback log or the seed value of the random number associated with the data of the action as the object in the object playback log is used to perform random number processing, and obtain the board information. In this example, the processing of the second processing unit 82 is also the same as the processing of the first processing unit 81. By setting it as such a structure, it can be configured that the random number when the first game server control unit 71 (first processing unit 81) and the second game server control unit 72 (second processing unit 82) perform actions is set to the same value. Thus, completely identical disk surface information can be generated through operations in the same operation log.

[0151] In one or more embodiments of the present invention, the management server 10 , the virtual instance server 20 , and the test game server 30 may each be configured to include one or more devices.

[0152] In one or more embodiments of the present invention, in the game G, the card 41 (card set) can be set to a medium (medium set) such as a character or an item, and the held card set can be set to a held medium set composed of a plurality of media held by the user. For example, when the medium set is composed of the medium of a character and an item, the game screen 40 will show the character or the item itself as the card 41.

[0153] In one or more embodiments of the present invention, the object playback log used to determine whether there is a mismatch between versions of game G can be the playback logs of as many users as possible, the playback logs of high-ranking users, the playback logs of users who play the game frequently, or the playback logs of any sample users.

[0154] In one or more embodiments of the present invention, game G may not be a battle card game. In one example, game G can be set as a single-player game. In the case where game G is a single-player game, the game log stored by the game server S and stored in the game log DB 54 includes a log that can reproduce the user operation of one user, i.e., a playback log. In this case, for example, the first virtual instance control unit 61 generates N virtual instances 63 for N object playback logs, and the second virtual instance control unit 62 generates N virtual instances 64 for N object playback logs. In this case, the first game server control unit 71 and the second game server control unit 72 do not match the virtual instances 63 and 64. In this case, the game execution control unit 50 generates an operation log of one user based on one object playback log. In this case, the first processing unit 81 uses the virtual instance 63 to execute the first version of the game G, plays the game based on the operation log generated according to the object playback log, and obtains the board information. The second processing unit 82 uses the virtual instance 64 to execute the second version of the game G, plays the game based on the operation log generated according to the object playback log, and obtains the board information. The inspection unit 83 obtains the board information (State i ) and the disk information (State ' i ) to detect the mismatch between versions. In this case, for example, the board information does not need to include information related to the second user, and therefore is data in a form that is different from the data represented by equation (3) and does not include information related to the second user. In this way, the system 1 of the embodiment of the present invention can also be applied to games other than fighting card games. In the case where game G is not a fighting card game, the State s obtained from the first processing unit 81 and the second processing unit, respectively, are i and State′ iThe game state information may be other than the board information. The system 1 according to the embodiment of the present invention can also be applied to a battle-type card game participated in by three or more users.

[0155] In one or more embodiments of the present invention, the first version game G and the second version game G only need to be different versions of games and are not limited to currently released games and games scheduled to be released.

[0156] In one or more embodiments of the present invention, the second version of the game G may also be a game that supports a platform different from that of the first version of the game G. For example, the first version of the game G may be a game for iOS, and the second version of the game G may be a game for Android. As such, games that support different platforms are made of binary data for different platforms, and therefore require action guarantees. Therefore, in such an embodiment, it is also necessary to determine whether there is a mismatch between game versions.

[0157] In the embodiment of the present invention, the game G is assumed to be a game of a Web application, but the present invention is not limited thereto. In one or more embodiments of the present invention, the game G may also be a browser game or the like.

[0158] In one or more embodiments of the present invention, the game log stored by the game server S and stored in the game log DB 54 may include a playback log for each specified event or each specified time instead of including a playback log for each match. In this embodiment, the target playback log is a playback log for a specified event or a specified time.

[0159] In one or more embodiments of the present invention, the game log stored by the game server S and stored in the game log DB 54 may not include the historical record data of the board information of each battle as long as it includes the board information at the beginning of the battle or the board information at the end of the battle. In this case, the board information at the beginning of the battle or the board information at the end of the battle is stored in association with the playback log. In the case where the game log does not include the board information at the beginning of the battle, the game execution control unit 50 can generate the board information at the beginning of the battle based on the playback log and the board information at the end of the battle, and the first virtual instance control unit 61 and the second virtual instance control unit 62 can allocate the card group at the beginning of the battle to the virtual instances 63 and 64.

[0160] In one or more embodiments of the present invention, the replay log can include the board information at the beginning of the battle and the board information at the end of the battle. In this case, the game log may not include the historical record data of the board information of each battle.

[0161] In one or more embodiments of the present invention, the action data contained in the playback log may not include the content determined by the game program according to the user operation. In this case, the action data is the user's operation log.

[0162] In one or more embodiments of the present invention, the first virtual instance control unit 61 may not generate two virtual instances 63 for one object playback log, but may select two virtual instances from pre-generated virtual instances that have not been used to play games, and assign the first user's starting deck to one side and the second user's starting deck to the other side. Similarly, the second virtual instance control unit 62 may not generate two virtual instances 64 for one object playback log, but may select two virtual instances from pre-generated virtual instances that have not been used to play games, and assign the first user's starting deck to one side and the second user's starting deck to the other side.

[0163] In one or more embodiments of the present invention, the checking unit 54 may also be configured to detect mismatches based on the degree of matching.

[0164] State i

[0165] and

[0166] State' i

[0167] Not completely consistent, that is, not

[0168] State i =State′ i ,

[0169] However, the allowable range of the difference is set to ±N. By setting such a structure, the range of the error of the mismatch detection can be adjusted, and a structure that allows a part of the error can be set. For example, in this case, the action can be confirmed in an environment closer to the actual game server S without using the seed value of the random number contained in the game log stored by the game server S. Therefore, in this case, the game log stored by the game server S does not need to contain the seed value of the random number.

[0170] In the embodiment of the present invention, the system 1 can also simultaneously use multiple object playback logs as objects to perform mismatch detection between versions of the game G.

[0171] In an embodiment of the present invention, the headless mode is a mode in which the graphics processing of accessing the GPU is invalidated and the sound processing of accessing the sound source chip and the access processing to the external server are invalidated. Thus, the game can be executed only by using the CPU, memory, and secondary storage device, that is, only by accessing the resources enclosed inside the container, so that the speed limiting factors (factors that determine the speed) such as the animation processing speed based on human browsing and the sound playback speed based on human listening can be eliminated. In addition, these graphics devices and sound devices are usually installed as external devices located outside the CPU, and the waiting time for synchronization consumed by the I / O processing between the CPU and the external device can also be omitted. Thus, the game can be operated at a high speed by omitting the waiting processing such as the waiting for human performance and the synchronization waiting for the external device, and relying only on the CPU's own processing speed. Therefore, the battle game can be executed in a shorter time.

[0172] In one or more embodiments of the present invention, executing a game program (game application) in headless mode may refer to executing the game program in headless mode or executing a headless game program. As long as the game can be progressed in a headless state, it can be executed in any manner. In Unity, which is a widely popular game engine, a headless game program can be easily generated simply by selecting the headless mode from the GUI. That is, the game program for user terminals can be reused to easily prepare a game program for verification. In one or more embodiments of the present invention, the game program may be executed in normal mode instead of headless mode.

[0173] In one or more embodiments of the present invention, the system 1 may be configured to not include the first processing unit 81. In this embodiment, the system 1 does not include the first game execution control unit 51, the first virtual instance control unit 61, the virtual instance 63, and the first game server control unit 71. In this embodiment, the checking unit 83 may be configured to check the game server S based on the game log DB 54 and the game board information history records. i ) and the disk information (State ' i ) to detect the mismatch between versions. In this embodiment, the following embodiment is preferred: the game log stored by the game server S and stored in the game log DB 54 includes a seed value of a random number. For example, when the second processing unit 82 performs random number processing, it uses the seed value of a random number associated with the data of the action of the object in the object playback log to perform random number processing.

[0174] In a modified embodiment of the present invention, each functional unit included in the system 1 may be implemented by hardware by configuring an electronic circuit or the like for implementing a part or all of the functional units.

[0175] In the processing or action described above, as long as there is no contradiction in the processing or action, such as using data that should not be used in the step in a certain step, the processing or action can be changed freely. In addition, the various embodiments described above are examples for illustrating the present invention, and the present invention is not limited to these embodiments. The present invention can be implemented in various ways as long as it does not deviate from its main purpose. For example, in the case of having the same effect as the system 1 of the embodiment of the present invention, the playback log stored in the game log DB 54 is not limited to the data form represented by formula (1), the disk information history record data generated by the first game execution control unit 51 and the second game execution control unit 52 is not limited to the data form represented by formula (2), and the disk information is not limited to the data represented by formula (3).

[0176] Description of Reference Numerals

[0177] 1: system; 2: network; 10: management server; 11: processor; 12: display device; 13: input device; 14: storage device; 15: communication device; 16: bus; 20: virtual instance server; 21: processor; 22: display device; 23: input device; 24: storage device; 25: communication device; 26: bus; 30: test game server; 31: processor; 32: display device; 33: input device; 34: storage device; 35: communication device; 40: game screen; 41: card; 42: hand; 42a, 42b: first card group; 43: field; 44: card pile; 44a, 44b: first card group; 45: field; 46: field; 47: field; 48: field; 49: field; 50: field; 51: field; 52: field; 53: field; 54: field; 55: field; 56: field; 57: field; 58: field; 59: field; 60: field; 61: field; 62: field; 63: field; 64: field; 65: field; 66: field; 67: field; 68: field; 69: field; 70: field; 71: field; 72: field; 73: field; 74: field; 75: field; 76: field; 77: field; 78: field; 79: field; 80: field; 81: field; 82: field; 83: field; 84: field; 85: field; 86: field; 87: field; 88: field; 89: field; 90: field; 91: field; 92: field; 93: field; 94: field; 95: 4b: second card deck; 45: character; 50: game execution control unit; 51: first game execution control unit; 52: second game execution control unit; 53: checking unit; 54: game log DB; 55: first game status DB; 56: second game status DB; 61: first virtual instance control unit; 62: second virtual instance control unit; 63: virtual instance; 64: virtual instance; 71: first game server control unit; 72: second game server control unit; 81: first processing unit; 82: second processing unit; 83: checking unit; 84: game log DB; 85: first game status DB; 86: second game status DB.

Claims

1. A system for detecting mismatches between versions of a game, in, The game state of the game can be updated according to the user's operation, wherein: The system has: a first processing unit that executes a first version of the game using a virtual instance generated to virtualize a user terminal or a software environment of the user terminal, performs game play based on an operation log included in a game log, and obtains game state information; a second processing unit that executes a second version of the game using a virtual instance, performs game play based on the operation log included in the one game log, and acquires game state information; and A checking unit detects a mismatch between versions based on a comparison between the game state information acquired by the first processing unit and the game state information acquired by the second processing unit.

2. The system according to claim 1, in, The game is a battle game, and the game log includes the operation logs of the matched first user and the second user. The first processing unit uses two virtual instances to execute the first version of the game and matches the two virtual instances. In one virtual instance, the game is played based on an operation log of a first user included in a game log. In the other virtual instance, the game is played based on an operation log of a second user included in the game log, and game status information is obtained. The second processing unit uses two virtual instances to execute the second version of the game and matches the two virtual instances. In one virtual instance, the game is played based on the operation log of the first user included in the one game log. In the other virtual instance, the game is played based on the operation log of the second user included in the one game log, and game status information is obtained.

3. The system according to claim 2, in, The system obtains the operation log of the first user and the operation log of the second user respectively from the obtained game log.

4. The system according to claim 3, in, The game log of the game is a game log obtained by a user playing the first version of the game.

5. The system according to any one of claims 1 to 4, in, Game status information is data that can be output in a specified format. The first processing unit and the second processing unit respectively obtain a plurality of game status information obtained according to the executed game play, The checking unit detects an inter-version mismatch based on a degree of matching between corresponding game state information acquired by the first processing unit and game state information acquired by the second processing unit.

6. The system according to claim 1, in, The first processing section and the second processing section execute the game in a headless mode in a virtual instance so that at least graphic processing and sound processing are disabled.

7. A method, implemented by a computer, for detecting a mismatch between versions of a game, in, The game state of the game can be updated according to the user's operation, and the method includes: A first acquisition step, using a virtual instance generated to virtualize a user terminal or a software environment of a user terminal to execute a first version of the game, playing the game based on an operation log included in a game log, and acquiring game state information; A second acquisition step of executing a second version of the game using a virtual instance, performing game play based on the operation log included in the one game log, and acquiring game state information; and A detection step is performed to detect a mismatch between versions based on a comparison between the game status information obtained in the first obtaining step and the game status information obtained in the second obtaining step.

8. The method according to claim 7, in, The game is a battle game. The game log includes the operation logs of the matched first user and second user. In the first acquisition step, two virtual instances are used to execute the first version of the game, and the two virtual instances are matched. In one virtual instance, the game is played based on the operation log of the first user included in a game log, and in the other virtual instance, the game is played based on the operation log of the second user included in the game log, and game status information is acquired. In the second acquisition step, two virtual instances are used to execute the second version of the game, and the two virtual instances are matched. In the virtual instance of one party, the game is played based on the operation log of the first user included in the one game log, and in the virtual instance of the other party, the game is played based on the operation log of the second user included in the one game log, and game status information is obtained.

9. A program for causing a computer to execute the steps of the method according to claim 7 or 8.

Images