JP3833097B2 - Bug detection method in game system - Google Patents

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a method for detecting an occurrence location of a bug when a bug exists in the program, a program having a function for realizing the method, and a recording medium on which the program is recorded.
[0002]
[Prior art]
If a program that runs on various computer devices such as personal computers or game machines stops running due to a bug that exists inside the computer, the program may be forcibly terminated, the device reset, You must turn it off and restart a new program.
[0003]
[Problems to be solved by the invention]
However, even if the execution of the program is restarted from the beginning, if the same operation is performed under the same conditions as when the execution is stopped, the execution of the program is stopped again due to the same bug.
[0004]
In addition, it is impossible to determine which step in the program caused the bug, so it is not possible to provide a solution to the user, especially when a bug occurs after the product is shipped. .
[0005]
Therefore, in game software, once a bug occurs, the game cannot be advanced, and there is no solution other than replacing the bug with a new product or upgrading the software. There's a problem.
[0006]
[Means for Solving the Problems]
As a specific means for solving the above-mentioned problems, the present invention comprises a CPU and a non-volatile memory, and the non-volatile memory stores a history table for storing information on commands to be executed, and the history table. A save area where the command information stored in the memory is copied, and a playback counter are stored in the history table for commands executed as the game progresses, and the commands are read from the history table and played back when the game is restarted. This is a bug detection method in a game system in which the number of playbacks can be stored in the playback counter while proceeding from the same state as before the restart, and the commands are sequentially stored in the history table before the commands are executed. At the same time, the commands are sequentially stored in a predetermined area pointed at each playback of the save area and then copied. When the command stored in the history table is played, the data stored in the history table is read sequentially, the value of the playback counter is n, and stored in n consecutive areas of the save area Provided is a bug detection method in a game system for determining whether or not received commands are the same.
[0007]
According to the present invention configured as described above, if the value of the reproduction counter is n and the commands stored in n consecutive areas of the save area are the same, a bug occurs when the command is executed. Since it can be determined that the command that causes the bug occurs before the bug occurs, the occurrence of the bug can be avoided.
[0008]
Furthermore, it is possible to easily identify the step where the bug occurs during the development of the program.
[0009]
DETAILED DESCRIPTION OF THE INVENTION
The game system to which the present invention is applied includes a CPU, a memory, a display screen, buttons, and the like. As shown in FIG. 1, the memory includes a history table H, a history table pointer i, a save area S, a serve area. A pointer j and a reproduction counter C are secured.
[0010]
Here, the history table H, save area S, playback counter C, history table pointer i, and save pointer j are reserved in a non-volatile memory or disk, and their contents even if the power is turned off due to the occurrence of a bug. Will not disappear. In addition, even if the user stops the game and turns off the power without any bugs, the memory is not lost.
[0011]
The contents of the operation performed by the user, for example, in the role playing game, the direction, position, action, etc., in which the main character is moved are recognized as commands in the game system.
[0012]
The history table H is a continuous area for storing executed commands and positions, and the history table pointer i is a pointer for accessing the history table H. The save area S is a continuous area to which data stored in the history table H is copied, and the save pointer j is a pointer for accessing the save area S. The reproduction counter C is a counter indicating the number of times data is read from the history table H and reproduced.
[0013]
In the following, the present invention will be described based on the change in the value of each area on the memory with reference to the flowcharts of FIGS. When the game program is started by turning on the power of the game system or the like, a message for selecting whether to start the game from the beginning or to resume from the beginning is displayed on the screen (S1). For example, when the user presses the A button, When the one starting from is selected, initialization processing is performed. In the initialization process, as shown in FIG. 5, the history table H and the save area S are cleared, and the values of all areas become NULL (S2, S3). Next, the values of the history table pointer i and the save area pointer j are set to 0 (S4, S5), the value of the reproduction counter C is set to 1 (S6), and the game is started from the beginning (S11 to S15).
[0014]
When the player who first presses the A button and selects the one to play from the beginning, as shown in FIG. 6, a command indicating the position and the content of the operation (pressed the A button) is written in the history table H [0]. (S7).
[0015]
Next, as shown in FIG. 7, the contents of the history table H [0] are copied to the save area S [0] (S8). Further, as shown in FIG. 8, after the history table pointer i is incremented in preparation for the next processing (S9), processing corresponding to the command is executed (S10). Then, unless the game is interrupted by the user's operation, the game proceeds by repeating the same operation as described above (S11).
[0016]
For example, when the B button is pressed next time, as shown in FIG. 9, the position and the command indicating that the B button has been pressed are stored in the history table H [1] (S7). As shown in FIG. 10, this information is copied to the save area S [0] (S8). Here, the copy to the save area S [j] is overwritten because the save pointer j that is an index at the time of copying is not incremented.
[0017]
Further, as shown in FIG. 11, after the save area pointer i is incremented in preparation for the next processing (S9), processing corresponding to the command is executed (S10).
[0018]
When the command is written while incrementing the history table pointer i in this way, the position and the command are sequentially written in a continuous area of the history table H. When the user interrupts the operation (S11), for example, as shown in FIG. 12, the position and command (END) are written in the history table H [2] (S12), and as shown in FIG. 0] is copied (S13). Then, the history table pointer i is returned to 0 and the process ends normally (S14).
[0019]
Thus, the contents stored in the history table H do not disappear even when the power is turned off, and the contents are erased only when the contents are cleared by processing by a program.
[0020]
However, for example, as shown in FIG. 14, after the processing shown in FIGS. 1 to 7, the C button is pressed to write it in the history table H [2], and this is stored in the save area S [0] as shown in FIG. If a bug occurs when the command is executed after copying and incrementing the history table pointer i as shown in FIG. 16, the program freezes at this point, so the command is stored in the history table H [3]. (END) cannot be written. In this case, the process ends abnormally, and a command (press C) is stored in the save area [0]. Also, the contents stored in the history table H will not be erased even if the power is turned off later.
[0021]
In step S1 of FIG. 2, when the user presses the B button and chooses to resume from the next, it is determined whether or not the value of the reproduction counter C is 3 or more (S15). It is determined whether or not the first area of the table H is NULL (S16). If it is NULL, the game is started from the beginning (S4 to S14), and if not NULL, the save area pointer j is incremented and a command reproduction routine is executed (S17, S20).
[0022]
On the other hand, if the value of the reproduction counter C is 3 or more, the contents of the save area S are checked (S21), and the past command is forcibly reproduced without any user operation, so that the state is the same as before the game restart. (S20), the game can be advanced from the continuation (S7 to S14).
[0023]
The check of the save area S in step S21 is performed according to the procedure shown in the flowchart of FIG. In this process, it is checked whether the values of three consecutive areas of the save area S are equal (S30, S31), and if all are the same, a process for avoiding a bug is performed (S32). ). This is based on the idea that if a bug occurs three times in the same step, there is a high possibility that a bug will occur again.
[0024]
On the other hand, if even one value is different, the process ends without doing anything. In other words, if a bug does not occur in the same step three times in succession, it cannot be said that a bug occurs again, so no special processing is performed.
[0025]
FIG. 4 is a flowchart showing the procedure of command playback processing performed in step S20 in FIG. For example, as shown in FIG. 17, when data is reproduced in the history table H when it has been normally completed before, the history table pointer i is first set to 0 (S40), as shown in FIG. The reproduction counter C is incremented (S41), and the contents of the history table H [0] are copied to the save area S [0] as shown in FIG. 19 (S42). Then, it is determined whether it is a command (END) (S43). If it is not a command (END), the command is executed (S44).
[0026]
Next, the history table pointer i is incremented as shown in FIG. 20 (S45), and the contents of the history table H [1] are copied to the save area S [ 1 ] as shown in FIG. 21 (S42). Then, it is determined whether or not the command is a command (END) (S43). Since the history table H [1] is not a command (END), the command is executed by the same processing as described above (S44), and the history table pointer i is incremented as shown in FIG. 22 (S45).
[0027]
As shown in FIG. 23, after copying the contents of the history table H [2] to the save area S [0] (S42), it is determined whether or not the command is a command (END) (S43). Since it is a command (END) here, as shown in FIG. 24, all the save areas S are cleared (S107), the save area pointer j is set to 0, and the reproduction process is terminated (S48).
[0028]
By reproducing all the commands stored in the history table H in this way, a state similar to that at the time when the game is ended is obtained. After that, the game can be advanced from the continuation by the user's operation.
[0029]
On the other hand, as shown in FIG. 25, when the value of the reproduction counter C is 3, a save area check is performed next (S 21 ), and here, the same three pieces of data are stored continuously. Considering that the positions and commands stored in the three consecutive areas of the save area S are the cause of the bug, the bug avoiding process is performed (S32).
[0030]
In this process, as shown in FIG. 26, the contents of the history table [i] are replaced with another command.
[0031]
When a command stored in the history table H is executed by the same process as described above, the reproduction process is terminated without causing a bug, and the game can be continued from there.
[0032]
As described above, since a command that causes a bug can be identified before the occurrence of the bug, the occurrence of the bug can be avoided.
[0033]
Further, during the development of the program, it is possible to easily identify the step where the bug occurs, so that debugging is facilitated and development efficiency is improved.
In this embodiment, the process for avoiding the occurrence of bugs is performed when the value of the reproduction counter becomes 3 or more. However, the value of the reproduction counter may be set to an arbitrary value n. Is possible. Corresponding to this, the number of areas for comparing the contents stored in the save area can be changed.
[0035]
【The invention's effect】
As described above, according to the present invention, it is possible to specify a command that causes a bug before a bug occurs.
[0036]
Further, during the development of the program, it is possible to easily identify the step where the bug occurs, so that debugging becomes easy and development efficiency is improved.
[Brief description of the drawings]
FIG. 1 is an explanatory diagram showing a table and pointers used in the present invention.
FIG. 2 is a flowchart showing the procedure of the present invention.
FIG. 3 is a flowchart showing the procedure of the present invention.
FIG. 4 is a flowchart showing the procedure of the present invention.
FIG. 5 is an explanatory diagram showing the contents of the initialized table and pointer.
FIG. 6 is an explanatory diagram showing an example of contents of a table and variables when played from the beginning.
FIG. 7 is an explanatory diagram showing an example of the contents of a table and variables when played from the beginning.
FIG. 8 is an explanatory diagram showing an example of contents of a table and variables when played from the beginning.
FIG. 9 is an explanatory diagram showing an example of contents of a table and variables when played from the beginning.
FIG. 10 is an explanatory diagram showing an example of contents of a table and variables when played from the beginning.
FIG. 11 is an explanatory diagram showing an example of contents of a table and variables when played from the beginning.
FIG. 12 is an explanatory diagram illustrating an example of contents of a table and variables when an operation is interrupted.
FIG. 13 is an explanatory diagram illustrating an example of contents of a table and variables when an operation is interrupted.
FIG. 14 is an explanatory diagram showing an example of contents of a table and variables before a program is frozen.
FIG. 15 is an explanatory diagram showing an example of contents of a table and variables before a program is frozen.
FIG. 16 is an explanatory diagram showing an example of contents of a table and variables before a program is frozen;
FIG. 17 is an explanatory diagram showing an example of contents of a table and variables at the time of command reproduction.
FIG. 18 is an explanatory diagram showing an example of contents of a table and variables at the time of command reproduction.
FIG. 19 is an explanatory diagram showing an example of contents of a table and variables at the time of command reproduction.
FIG. 20 is an explanatory diagram showing an example of contents of a table and variables at the time of command reproduction.
FIG. 21 is an explanatory diagram showing an example of contents of a table and variables at the time of command reproduction.
FIG. 22 is an explanatory diagram showing an example of contents of a table and variables at the time of command reproduction.
FIG. 23 is an explanatory diagram showing an example of contents of a table and variables at the time of command reproduction.
FIG. 24 is an explanatory diagram showing an example of contents of a table and variables at the time of command reproduction.
FIG. 25 is an explanatory diagram showing an example of contents of a table and variables at the time of bug avoidance processing;
FIG. 26 is an explanatory diagram showing an example of contents of a table and variables at the time of bug avoidance processing;
[Explanation of symbols]
H ... History table S ... Save area C ... Playback counter i ... History table pointer j ... Save area pointer

Claims (1)

A CPU and a non-volatile memory, the non-volatile memory having a history table for storing information of commands to be executed, a save area for copying information of commands stored in the history table, A playback counter, and a command to be executed as the game progresses is stored in the history table, and when the game is restarted, the command is read from the history table and played back so as to proceed from the same state as before the restart. A bug detection method in a game system capable of storing the number of reproductions in the reproduction counter ,
Before executing the command stores sequentially in succession the command to the subsequent history table, it executes the command the command are sequentially stored in a predetermined area pointed to each playback of the save area,
When playing back the commands stored in the history table, the data stored in the history table is read sequentially, the value of the playback counter is n, and stored in n consecutive areas of the save area. A bug detection method in a game system that determines whether or not commands are the same.

Images