JP3244476B2 - GAME DEVICE, GAME DEVICE CONTROL METHOD, AND COMPUTER-READABLE RECORDING MEDIUM - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

TECHNICAL FIELD The present invention relates to a game device, a game
Relates to a control method and a computer-readable recording medium of the beam device, in particular, a game device, a control side of the game device can be re-display the game content player has performed
The present invention relates to a method and a computer-readable recording medium for operating a computer as such a game device.

[0002]

2. Description of the Related Art Some game devices record the behavior of an operating tool operated by a player so that the content displayed on a display device during game execution can be replayed (redisplayed). Have been. Such a game device is disclosed in, for example, Japanese Patent No. 2777353 and Japanese Patent Application Laid-Open No. 10-216358.

[0003]

If the above-described game device having the replay function is used, the same screen as when the game is executed can be displayed on the display device. However, the screen displayed during the execution of the game includes many monotonous screens (scenes). For this reason, when replaying the execution result of the game, redundant reproduction has been executed.

[0004] Therefore, an object of the present invention is to provide a game device capable of reproducing a required scene during execution of a game,
An object of the present invention is to provide an event generation method and a computer-readable recording medium that allows a computer to operate as such a game device.

[0005]

According to the present invention, there is provided a game apparatus, a method for controlling the game apparatus,
Computer-readable recording media
It has a configuration.

[0006]

[0007]

[0008]

[0009]

[0010]

[0011]

[0012]

[0013]

A game device according to the present invention is a device having a function of recording data for reproducing a game result in a storage means, and displaying an image corresponding to a content of a player's operation on an input device on a display device. Means of execution;
Each time an image is displayed on the display device by the game execution means, a replay code storage means for generating a replay code including information capable of creating the image, and storing the generated replay code in a storage means in a form in which the generation order can be understood; When an image in which any of predetermined events of a predetermined type has occurred is displayed on the display device by the execution means, the predetermined type of event is displayed .
Type information that indicates which of the events occurred
An index code comprising an index code storage means for storing in the storage means in association with the replay code related to the image, stored in the storage means Replenisher
Index stored in the storage means
For each code, associated with that index code
Including the replay code, the
Identify the number of replay codes according to the
All specified for any index code
Multiple replay codes, one by one
Replay means for creating and outputting the images in time series .

That is, when a special event occurs on an image, the game apparatus according to the present invention includes a replay code for reproducing the game content and a predetermined type of event.
An index code including type information indicating which one of the events has occurred is stored in the storage means. Furthermore, the game device of the present invention includes, for each index code stored in the storage unit, a replay code associated with the index code among the replay codes stored in the storage unit, and the generation order is continuous.
The number of replay codes corresponding to the type information included in the index code is specified, and all the replay codes specified for any one of the index information are used one by one in the order in which the replay codes are generated. Of the present invention.
According to the game device, the content of the game played by the player can be reproduced in a form in which a monotonous portion is omitted, and in a form in which the length of reproduction is different depending on the type of the event that has occurred .

In realizing the game apparatus of the present invention, replay event designating means for designating an event to be replayed out of predetermined types of events is added, and the game execution is performed as index code storage means. By the means, when an image in which any of predetermined events of a predetermined type has occurred is displayed on the display device, an index code including type information indicating which of the events of the predetermined type has occurred, Using the means for storing in the storage means in association with the replay code for the image, as the replay means, only for the index code determined to be related to the event specified by the replay event specifying means based on the type information, the index code and Associated replay code Wherein, order of generation may be used a means for specifying a predetermined number replay code continuous.

Also, a storage event designating means for designating an event for storing an index code from a predetermined type of event is added, and the game executing means serves as an index code storage means.
Among events of a predetermined type predetermined on the display device,
When an image in which one of the events specified by the storage event specifying unit has occurred is displayed, a unit may be used in which an index code indicating this is stored in the storage unit in association with the replay code related to the image. .

When one or both of the replay event designating means and the stored event designating means are added to the game apparatus of the present invention, only the event desired by the player can be reproduced. Therefore, such a game device operates as a device having a replay function that is more easily used.

In implementing the game apparatus of the present invention, replay code storage means for generating and storing a replay code including absolute position information may be employed. It is preferable to use a replay code storage unit that generates and stores a replay code including the replay code, since the storage capacity required for storing the replay code can be reduced.

Further, the association between the replay code and the index code in the game device of the present invention may be performed by any method. For example, even if the replay code and the index code are set to codes of the same size, a means for storing the index code so as to be associated with the replay code by a storage position in the storage means may be employed as the index code storage means. As a replay code, one having an index code field for setting an index code is used, and as an index code storage means, a means for storing an index code in an index code field of a replay code to be associated is adopted. Is also good.

The method of controlling a game device according to the present invention includes operating the game device as a game device according to the present invention.
The computer-readable recording medium of the present invention includes steps for causing a computer to operate as a game device of the present invention.

[0022]

[0023]

[0024]

[0025]

[0026]

[0027]

[0028]

Embodiments of the present invention will be described below in detail with reference to the drawings.

The game apparatuses according to the first to fourth embodiments are realized by executing different programs on information processing apparatuses having the same configuration. Therefore, before describing the operation of the game device of each embodiment, the hardware configuration of the information processing device will be described with reference to FIG.

As shown, the information processing apparatus 20 used in the game apparatus of the first to fourth embodiments
For example, the control unit 21, the RAM 22, the sound processing unit 23, the interface unit 24, the input unit 25, the MDE
C26, a graphic processing unit 27, a CD-ROM drive 28, a bus 29, and a communication interface 32. Of these components, the components other than the input unit 25 are interconnected via a bus 29. The communication interface 32 is connected to the bus 29 and can be arbitrarily connected to the network 100 via the communication line 33.

The control unit 21 is a circuit including a CPU, a ROM, and the like.
Each part is controlled according to the program stored in the OM). The sound processing unit 23 is a circuit having a function of generating music, sound effects, and the like.
A sound corresponding to the data stored in 22 is generated.

The input section 25 is a device used by a user of the present apparatus to input various information (instructions) to the information processing apparatus 20. The input unit 25 is connected to the bus 29 via the interface unit 24. The interface unit 24 is a circuit to which the memory card 31 can be connected, and transfers data between the circuit (mainly the control unit 21) connected to the bus 29 and the input unit 25 or the memory card 31. Is performed. The components of the information processing apparatus 20 except for the input unit 25 are housed in a single housing, and the input unit 25 is connected to the housing by a cable (called a controller or an operation pad). Equipment).

The MDEC 26 has an inverse DCT (discrete cosi
ne transformation: A circuit that can execute the discrete cosine transform (JPEG) operation at high speed. JPEG (Joint Photographic E)
xperts Group) and MPEG (Moving Picture Expert Gr)
oup) or other data (CD-RO
It is used when decompressing image data and moving image data compressed and recorded in M10. Graphic processing unit 2
Reference numeral 7 denotes a circuit provided with a frame buffer.
Draws an image (polygon) according to the instruction given from 1 on a frame buffer, and generates a video signal according to the image information stored in the frame buffer;
Output. Further, the graphic processing unit 27
A process of outputting a video signal according to the result of the decompression at 26 is also performed. The information processing device 20 includes the graphic processing unit 27
And is used by being connected to the display device 30 via the.

The CD-ROM drive 28 is a CD-RO drive.
The reading device of M10, the game device of each embodiment is:
This is realized by causing the control unit 21 to perform control according to a program recorded on the CD-ROM 10.

First Embodiment First, the overall operation procedure of the game device according to the first embodiment will be described with reference to FIG. Note that some of the control operations performed by the game devices of the embodiments include those in which a circuit other than the CPU performs actual control. Will be described assuming that the CPU is directly controlling.

The game device according to the first embodiment is a device capable of playing a racing game. When the game device according to the first embodiment is started, C according to a program stored in the ROM is used.
The program (O) recorded in the ROM by the PU
S) or the game program recorded on the CD-ROM 10 is read into the system area and the program area of the RAM 22 (step S101). In this step S101, the recording environment information is prepared in the work area of the RAM 22 by the CPU according to the game program read on the RAM 22. The specific usage procedure will be described later, but the recording environment information is 1 to 1 respectively.
It consists of 10 pieces of flag data (data of “1” or “0”) associated with an index value of 0, and in step S101, the recording environment information in which all data is “1” is prepared.

Thereafter, the CPU according to the game program
Accordingly, a process for alternately displaying a title screen or a demonstration screen (hereinafter, referred to as a demonstration screen) on the display device 30 while monitoring the state of the start button provided on the input unit 25 (step S1)
02, S103) is started.

That is, the CPU displays the title screen on the display device 30 using the graphic data for the title screen recorded in the CD-ROM 10 while monitoring the state of the start button. When it is detected that the predetermined time has elapsed, the MDEC 26
The reproduction of the movie data for the demo screen recorded in the CD-ROM 10 is started, and when the reproduction of the movie data is completed, the title screen is displayed again.

The CPU repeats such control until it detects that the start button has been pressed, and detects that the start button has been pressed (step S103; Y).
In ES), a menu screen is displayed to receive an operation mode instruction from a user of the apparatus (hereinafter, referred to as a player) (step S104).

The present apparatus is provided with three operation modes such as a race mode, a replay mode, and a recording environment setting mode. When the race mode is selected (step S105; race), the CPU operates the input unit of the player. A race screen (step S107), which is a process of creating a replay data in which a specific vehicle is caused to perform a behavior according to the operation content of the specific vehicle 25, and recording the race content is executed. Further, when the replay mode is selected (step S105; replay), the CPU performs a replay process (step S105) for redisplaying the content of the race performed in the past based on the replay data.
108), and if the recording environment setting mode is selected (step S105: environment), a recording environment change process (step S106) for changing the recording environment information is executed. Then, when each process is completed, the process returns to step S102, and a title screen or the like is displayed again.

Hereinafter, the recording environment change processing, the race processing, and the replay processing will be described in detail. First, the race processing will be described.

FIG. 3 shows the overall operation procedure of the CPU during the race processing. As shown in the figure, at the start of the race processing, the CPU obtains, from the player, the number and type of vehicles used in the race and the identification information of the course used in the race (steps S201, S202). In these steps, data is acquired in a procedure similar to the procedure for acquiring data performed in a general game device. For example, at the time of the process of step S201, the CPU first determines the type of vehicle (hereinafter, referred to as the own vehicle) whose behavior is controlled by the player, and the vehicle whose CPU controls the behavior (hereinafter, referred to as the own vehicle).
A screen is displayed to allow the player to select the number and type of enemy vehicles. Next, the CPU changes the display content according to the player's operation on the input unit 25, and based on the display content at the time when the operation indicating the completion of the setting is performed, the number of vehicles used in the race. And the type of each vehicle.

After receiving instructions from the player such as the type of vehicle used for the race, the CPU performs pre-race processing (step S203). During this race pre-processing, the CPU
Performs the following processing.

First, data necessary for performing a racing game using the designated vehicle and course is prepared on the RAM 22. At this time, the CPU divides the RAM 22 into a system area, a program area, a work area, a replay data area, a course data area, a vehicle data area, other data areas, and a stack area, as shown in FIG. .

The system area is an area where the OS itself stored in the ROM of the game device (information processing apparatus 20) is stored, and the stack area is a work area of the OS.
The program area is an area from which a game program recorded in the CD-ROM 10 is read. The work area is an area used for storing data whose contents may be updated.

The replay data area is an area for recording replay data created by the race processing. The course data area includes, for example, terrain data representing the shape of the course as schematically shown in FIG. 5 and CG (c) used to graphically display each point on the course.
This is an area where course data including omputer graphics) data is stored. The course data of a plurality of courses that can be used for a race is recorded in the CD-ROM 10, and during pre-race processing, the course data corresponding to the course identification information acquired in step S202 is stored in the CD-ROM.
10 and stored in the course data area.

The vehicle data area includes CG data of the vehicle,
A plurality of vehicle data including performance data (acceleration, maximum speed, cornering performance data, etc.) used for calculating the amount of movement of the vehicle is an area in which a plurality of vehicle data can be stored. , Data other than course data and vehicle data, such as coordinate data of a viewpoint and sound effect data. CD-ROM1
0, various vehicle data and sound effect data are recorded. During pre-race processing, vehicle data and sound effect data associated with each vehicle identification information acquired in step S201 are stored in the CD-ROM 10. And stored in the vehicle data area and other data areas.

After preparing such various data on the RAM 22, the CPU initializes (creates) race situation data. The race situation data is data including position data and posture data (data indicating the direction of the vehicle) in the course coordinate system of each vehicle participating in the race. This race status data is data whose contents are updated as the race progresses.At the time of pre-race processing, race status data in which position data at the start point and attitude data are set for each vehicle are created, Stored in the work area.

The CPU uses the vehicle data and the course data prepared on the RAM 22 to display a race screen (in this case, a start point screen) in accordance with the created race situation data, and performs pre-race processing. To end.

After the race pre-processing (step S203), C
The PU generates a header code which is an element of the replay data, records the header code at the head of the replay data area, and initializes the value of the recording position pointer to “0” (Step S204). The recording position pointer is a pointer whose value is used to specify the position at which recording of the replay code, index code, and end code, which are elements of replay data, is started, and is realized by a register in the CPU. ing.

Here, the overall structure of the replay data and the structure of each element forming the replay data will be described with reference to FIGS. 6 is an explanatory diagram of replay data, FIG. 7 is an explanatory diagram of a header code, and FIG. 8 is an explanatory diagram of a replay code, an index code, and an end code, which are elements of the replay data.

As schematically shown in FIG. 6, the replay data created by the game device includes a plurality of replay codes 42 and a plurality of index codes 43 between a header code 41 and an end code 44. Is sandwiched.

As shown in FIG. 7, the header code 41 has a course identification information field 51, a vehicle number field 52, and a vehicle information field 53. The course identification information field 51 is a field for storing the course identification information, and uses the header code created in step S204.
1 is set to the course identification information (“A course” in the figure) acquired in step S202.

The vehicle information field 53 is a field in which a plurality of vehicle information including vehicle type identification information, position data and attitude data can be stored, and the vehicle number field 52 is stored in the vehicle information field 53. This is a field for storing the number of vehicle information items. That is, the vehicle number field 52 of the header code created in step S204 includes step S20.
The number of vehicles (“2” in the figure) acquired in step 1 is set. Then, in the vehicle information field 53, step S
The vehicle information including the vehicle identification information acquired in 201, the initial values of the position data and the posture data (the copy of the position data and the posture data included in the race situation data created in step S203) is set.

As shown in FIG. 8, the replay code 42 has a code identifier field 55 and an operation content information field 56. The index code 43 is
It is data having a code identifier field 55 and an index value field 57, and the end code 4
4 is data having only the code identifier field 55. The code identifier field 55 is a field in which a code identifier indicating the type of the own code is stored, and includes a replay code 42, an index code 43,
In the code identifier field 55 of the end code 44,
Replay code ID and index code I, respectively
D, an end code ID is set.

The replay code 42 is data added to the replay data area every time one frame is displayed. The operation content information field 56 in the replay code 42 is a field in which operation content information (details will be described later) on each vehicle participating in the race is stored. Further, the size of the operation content information field 56 is set to a size capable of storing a specified number of operation content information, and the replay code 42 indicates that even if the number of operation content information is smaller than the specified number, It is stored in the replay data area as data having a size equal to the size when a prescribed number of operation content information is stored.

The index code 43 is data that is added to the replay data recording area when a predetermined event has occurred. The index value field 57 is a field in which an index value indicating the type of the event that has occurred is set. ing. Index code 43
Is data having only the code identifier field 55 and the index value field 57, but is stored in the replay data area as data having the same size as the replay code 42.

Returning to FIG. 3, the description of the operation procedure of the CPU during the race processing will be continued. After recording the header code (step S204), the CPU recognizes the operation content of the player on the input unit 25 (step S20).
5). Then, the recognized operation content and the race status data at that time (the race status data used for the previous display)
Then, the position data and the attitude data of the own vehicle and the enemy vehicle on the race screen to be displayed this time are obtained, and the race situation data is updated with the data (step S206). Next, the CPU executes the replay code recording process (step S
207).

FIGS. 9 to 12 show the operation procedure of the CPU during the replay code recording process. As shown in FIG.
At the time of the replay code recording process, the CPU first records a replay code including operation content information of the player at a position indicated by the value of the recording position pointer (step S301). More specifically, the replay code including the operation content information corresponding to the operation content recognized in step S205 and the operation content information corresponding to the operation content performed by the user on the enemy vehicle is stored in the replay data storage area. From the beginning,
Recording is performed such that the head is located at a position separated by “header code size + recording position pointer value × replay code size”.

Next, the CPU increases the value of the recording position pointer by "1" so as to indicate the recording position of the next code (step S302). Thereafter, the CPU determines (detects) whether or not the own vehicle is in contact with the enemy vehicle based on the race situation data.
3; YES), it is determined with reference to the recording environment information whether or not the event of “contact with an enemy vehicle” is an event that requires recording of an index code (hereinafter, referred to as a recording required event) ( Detection) (step S304).
The specific procedure for referring to the recording environment information will be described later.

If it is determined that the event requires recording (step S304; YES), the CPU sets an index code (“1”) with an index value of “1” at the position indicated by the value of the recording position pointer. An index code indicating that an event “contact” has occurred is recorded (step S305). Next, the value of the recording position pointer is increased by "1" (FIG. 12: Step S33).
3), end the replay code recording process. On the other hand, when the event “contact with the enemy vehicle” is an event that does not require the recording of the index code (step S30)
4; NO), the replay code recording process ends without changing the value of the recording position pointer.

If the vehicle has not contacted the enemy vehicle (step S303; NO), the presence or absence of skidding is determined (detected), and the vehicle has skid (step S30).
6; YES), by referring to the recording environment information, the CPU determines whether or not “side slip” is an event that requires recording of an index code (step S30).
7). If the event requires recording (step S307; YES), an index code whose index value is set to “2” is recorded at the position indicated by the value of the recording position pointer (step S308). Thereafter, the process proceeds to step S333, where the value of the recording position pointer is changed, and the replay code recording process ends. On the other hand, if the “side skid” is an event that does not require the recording of the index code (step S307; NO), the replay code recording process ends without changing the value of the recording position pointer.

If side skid has not occurred (step S306; NO), the CPU determines (detects) whether or not the own vehicle has jumped (step S309). If the vehicle has jumped (step S309; YES), it is determined whether or not “jump” is a required recording event by referring to the recording environment information (step S310). If “jump” is a recording required event (step S310; YES), an index code with the index value “3” at the position indicated by the recording position pointer is recorded (step S311;
After performing S333), the replay code recording process ends, and when the event is not a recording required event (step S31).
0; NO), the process ends without recording the index code.

If the vehicle has not jumped (step S309; NO), the CPU determines (detects) whether the vehicle has contacted the wall (FIG. 10: step S31).
2). When the vehicle is in contact with the wall (step S31)
2; YES), by referring to the recording environment information, the CPU determines whether or not the event is a recording required event (step S313). If it is a recording required event (step S313; YES), after recording an index code with the index value set to “4” at the position indicated by the recording position pointer (steps S314 and S333), Then, the replay code recording process ends. If the event is not a recording required event (step S313; NO), the process ends without recording the index code.

If the vehicle has not touched the wall (step S312; NO), the CPU determines (detects) whether or not the vehicle has passed an enemy vehicle (step S315). If the own vehicle has passed the enemy vehicle (step S315; YES), C
The PU determines whether or not the event is a required recording event by referring to the recording environment information (Step S).
316). If the event is a recording required event (step S316; YES), an index code with the index value “5” at the position indicated by the recording position pointer is recorded (steps S317 and S317).
After performing 333), the replay code recording process ends. If the event is not a record required event (step S31)
6; NO), the process ends without recording the index code.

If the vehicle has not passed the enemy vehicle (step S315; NO), the CPU determines (detects) whether or not the vehicle has been passed by the enemy vehicle (step S318). When the own vehicle is overtaken by an enemy vehicle (step S318; YE)
S), the CPU refers to the recording environment information,
It is determined whether or not the event is a record required event (step S319). If it is a recording required event (step S319; YES), recording of an index code with the index value “6” to the position indicated by the recording position pointer is performed (step S319).
320 and S333), the replay code recording process ends. If the event is not a record required event (step S319; NO), the process ends without recording the index code.

If the vehicle has not been overtaken by the enemy vehicle (step S318; NO), the CPU determines (detects) whether or not the vehicle has rolled over (FIG. 11: step S32).
1). When the own vehicle rolls over (step S321; YE)
S), the CPU refers to the recording environment information,
It is determined whether or not the event is a record required event (step S322). If the event is a recording required event (step S322; YES), recording of an index code with the index value “7” at the position indicated by the recording position pointer is performed (step S322).
323 and S333), the replay code recording process ends. If the event is not a recording required event (step S322; NO), the process ends without recording the index code.

If the vehicle has not rolled over (step S321; NO), the CPU determines (detects) whether or not the vehicle has fallen off the course (step S324). If the own vehicle has fallen (step S324; YES), the CP
U refers to the recording environment information to determine whether or not the event is a required recording event (step S325). If it is a recording required event (step S325; YES), recording of an index code with the index value “8” at the position indicated by the recording position pointer is performed (steps S326, S33)
After performing 3), the replay code recording process ends.
If the event is not a record required event (step S325; N
In O), the process ends without recording the index code.

If the vehicle has not fallen off the course (step S324; NO), the CPU determines (detects) whether or not lap measurement of the vehicle has been performed (step S).
327). When lap measurement has been performed (step S32
7; YES), by referring to the recording environment information, the CPU determines whether or not the event is a required recording event (step S328). If it is a recording required event (step S328; YES), after recording an index code having an index value “9” to the position indicated by the recording position pointer (steps S329 and S333), The replay code recording process ends. If the event is not a recording required event (step S328; NO), the process ends without recording the index code.

If the lap measurement of the own vehicle has not been performed (step S327; NO), the CPU determines (detects) whether the own vehicle has reached the goal (step S33).
0). When the own vehicle has reached the goal (step S330;
YES), by referring to the recording environment information, the CPU determines whether or not the event is a required recording event (step S331). If it is a recording required event (step S331; YES), after recording an index code having an index value “10” to the position indicated by the recording position pointer (steps S332 and S333), The replay code recording process ends. If the event is not a recording required event (step S330; NO), the process ends without recording the index code.

The CPU determines whether or not the event is a record required event by setting the flag data in the recording environment information corresponding to the index value of the event to be processed to “1”.
Or “0”. As described above, the recording environment information prepared in the work area at the time of startup is the recording environment information in which the flag data corresponding to each of the index values 1 to 10 is all “1”. When the race process is executed after the start-up, and when any of the above-described ten events occurs, “YE
The branch to the S ″ side is performed, and the index code is recorded.

At this time, for a specific event, the processing for branching to the “NO” side is the recording environment change processing. That is, in the recording environment change processing, the flag data associated with each event, which constitutes the recording environment information, is changed from “1” to “0”
This is a process for changing from “0” to “1”.
At this time, the CPU receives the designation of the event in which the index code is not recorded (the designation of the flag data whose value is “0”) from the player by displaying the screen as shown in FIG.

After recording the replay code or the replay code and the index code in the above-described procedure, the CPU repeats the processing of step S209 (FIG. 3) at a fixed cycle (1/30 second cycle). (Step S208). Thereafter, the CPU controls each unit such that a race screen corresponding to the race situation data updated in step S206 is displayed (step S209). That is, in this step, the CPU converts the position data and the attitude data of each vehicle included in the race situation data, the course data stored in the course data area, the vehicle data stored in the vehicle data area, and the like. For example, a race screen including images of the own vehicle PC and the enemy vehicle EC is displayed as shown in FIG. Further, in step S209, the CPU also performs processing for controlling each unit so that a sound corresponding to the race situation data is emitted.

Thereafter, the CPU determines whether or not a predetermined condition is satisfied, thereby determining whether or not the race has been completed.
In (Step S210; NO), the processing from Step S205 is executed again. On the other hand, if the race has ended (step S210; YES), step S2
The processing exits from the loop from 05 to S209 and records the end code in the replay data storage area (step S211).
And complete the replay data.

Next, when the player instructs to save the replay data, the CPU saves the replay data stored in the replay data area in the memory card 31 (step S212). I do. Then, display processing of race results (history ranking etc.) is performed (step S213), and the race processing is completed (return to step S102 in FIG. 2).

As described above, in the race processing executed by the game device of the first embodiment, the replay data in which the index code indicating the type of the occurred event is inserted into the portion where the predetermined event has occurred is created and stored. Processing

Next, the replay processing will be described. The replay process executed by the game device of the first embodiment is a process of redisplaying the contents of a race that has been performed in the past based on the replay data. Or the replay data in the replay data area. Also, the present game device includes an index code in the replay data,
It is a device that can replay only the scenes rich in changes, further, it is configured to be able to replay only the scene where the specific index code was recorded among the scenes where the index code was recorded. I have.

Therefore, as shown in FIG. 15, at the time of the replay processing, the CPU firstly executes the processing for inputting the instruction information of the operation content from the player.
A mode input process is executed (step S401). That is, in this step, the CPU determines whether the replay data to be replayed is the replay data in the memory card 31, the replay data in the RAM 22, or the replay data from the network 100 via the communication line 33.
When the player receives an instruction as to whether or not to use the replay data supplied to the AM 22 and performs processing in an unconditional replay mode in which all race contents are replayed,
An instruction is received as to whether or not to perform processing in a conditional replay mode in which the content of the race is replayed in a form in which a monotonous portion is omitted.
When an instruction is given to perform processing in the conditional replay mode, an event to be displayed is specified by displaying a screen similar to the screen shown in FIG.

When data in the memory card 31 is selected as a replay target (step S402; stored data), the CPU performs a process of reading various data from the memory card 31 and the CD-ROM 10 (step S402).
403). In other words, the replay data stored in the memory card 31 is read into the replay data area of the RAM 22, and the course identification information included in the header code of the replay data, the course data identified by the vehicle identification information, The vehicle data and the like are read into the course data area and the vehicle data area. And CPU
Creates and stores race situation data using the position data and the attitude data as initial values, and sets "0" in a register used as a read position pointer (step S4).
04).

On the other hand, when replay data in the replay data area is selected as a replay target (step S
402: current data), without reading data from the CD-ROM 10, the race status data and the read position pointer are initialized based on the data in the header code already existing on the RAM 22 (step S40).
4).

Next, the CPU determines whether or not conditional replay has been selected as the replay mode, and if conditional replay has not been selected (step S40).
5; NO), the unconditional replay processing of steps S406 to S411 is started.

At the time of unconditional replay processing, the CPU first
A start point screen is displayed (step S406). Next, the code at the position indicated by the value of the read position pointer is read (step S407), and it is determined whether the read code is an end code, an index code, or a replay code (steps S408, S409). If the read code is an index code (step S409; YES), the CPU increases the value of the read position pointer by “1” (step S41).
1). Then, the process returns to step S407 to read the code indicated by the read position pointer whose value has been updated. That is, when the read code is an index code, the CPU reads the next code without actually using the data in the code.

On the other hand, if the read code is a replay code (step S409; NO), a frame replay process for displaying one frame of the race screen based on the data in the code is performed. Perform (Step S410). That is, new position data and attitude data for each vehicle are obtained based on the operation content information included in the replay code and the position data and attitude data in the race situation data at that time. Then, the race status data is updated with the obtained data, and a race screen for one frame is created and displayed based on the data. In this step, the CPU performs timing adjustment for displaying a screen every 1/30 second, as in the race processing described with reference to FIG.

The CPU repeats such processing for each code stored after the header code, and when the read code is an end code (step S408; YES), the unconditional replay processing is performed. (Replay processing) ends.

On the other hand, when the replay mode selected by the player is conditional replay (step S405;
YES), the CPU executes the conditional replay process (step S
420).

As shown in FIG. 16, during the conditional replay processing, the CPU first initializes the status data pointer SP to “0” and sets the status data pointer SP in the replay data area.
The code stored at the position indicated by the read position pointer is read (step S501). The code is any of a designated index code (an index code having an index value instructed to be displayed by the player in step S401), a non-designated index code (an index code that is not a designated index code), and a replay code. It is determined (step S502). If the read code is a replay code (step S502; replay), C
The PU creates race situation data using the data in the replay code (step S503).

Next, the CPU stores the created race situation data at the position indicated by the situation data pointer SP in the work area of the RAM 22 (step S504). Then, using the expression “SP = (SP + 1) MOD 300”,
Update the value of the status data pointer SP (step S5)
05). That is, in step S505, the CPU
Indicates that the SP is "1" if the SP is 298 or less.
Is added, and when SP is 299, SP is set to “0”.

Thereafter, the CPU increments the value of the read position pointer by "1" (step S506), and reads the code at the position indicated by the read position pointer (step S5).
07). If the code is not an end code (step S508; NO), step S50
Returning to step 2, it is determined whether the code is a designated index code, a non-designated index code, or a replay code.

If the read code is a non-designated index code (step S502; non-designated index), the process from step S505 is performed, and if the read code is a designated index code (step S502).
(502; designated index), a replay parameter setting process (step S510) and a partial replay process (step S511) are executed.

As shown in FIG. 17, at the time of the replay parameter setting processing, the CPU determines that the index value of the target index code at that time is one of 1 to 3 (step S601; YES). , The value of the read position pointer and the value of the situation data pointer are respectively reduced by "60", and "150" is set in the reproduction time counter (step S602).

If the index value is one of 4 to 6 (step S603; YES), the CPU
Reduces the value of the read position pointer and the value of the status data pointer by “90”, and sets “240” in the reproduction time counter.
Is set (step S604). Further, when the index value is one of 7 to 9 (step S60)
5; YES), the values of the read position pointer and the situation data pointer are each reduced by "150", and "360" is set in the reproduction time counter (step S606). If the index value is not 1 to 9 (step S605; NO), that is, if the index value is 10
If it is, the value of the reading position pointer and the value of the situation data pointer are respectively reduced by "300", and "600" is set in the reproduction time counter (step S607).

In the above-described subtraction of the SP value in each step, the SP value is M (M is a value subtracted from the value of the read position pointer) before the most recently recorded race situation data. It is performed to indicate the race situation data. For example, the subtraction of the situation data pointer SP in step S602 is performed by the expression “SP = (SP + 240) MOD30.
In addition, when M (60, 90, etc.) is subtracted from the value of the reading position pointer, the value of the reading position pointer becomes negative.
The same value as the read position pointer is read position pointer,
Subtracted from race situation data.

As described above, the replay parameter setting process sets values corresponding to the current value and the index value to the read position pointer and the status data pointer, respectively.
The processing is to set a value corresponding to the index value in the reproduction time counter. In the partial replay process, the replay of the event occurrence scene of the race content represented by the replay data is performed in the following procedure based on the value set in the replay parameter setting process.

As shown in FIG. 18, first, the CPU
Reads the race status data stored at the position indicated by the status data pointer and the code stored at the position indicated by the read position pointer (step S701).
Next, it is determined whether or not the read code is an index code. If the read code is not an index code (step S702; NO), that is, if the read code is a replay code, the same processing as that performed in step S410 is performed. The frame replay processing (step S703) is executed. Next, the CPU decreases the value of the reproduction time counter by "1" (step S704), and increases the value of the read position pointer by "1" (step S705). Then, the code at the position indicated by the read position pointer is read (step S706).

If the read code is not an end code (step S707; NO), the CPU determines whether or not the value of the reproduction time counter is "0" (step S708). The value of the playback time counter is "0"
If not (step S708; NO), the process returns to step S702 to process the code read in step S706. If the code is an index code (step S702; YES), C
The PU omits execution of steps S703 and 704,
The processing from step S705 is executed. Although not shown in the figure, when branching on the “YES” side in step S702 immediately after the start of the partial replay processing, the CPU
The value of the situation data point and the value of the read position pointer are each incremented by "1", and the processing from step S701 is executed again.

The CPU processes each code according to the above-described procedure. When the value of the reproduction time counter becomes "0" (step S708; YES), the CPU ends the partial replay processing. Then, the processing from step S506 in FIG. 16 is started. Also, when the end code is read before the value of the reproduction time counter becomes “0” (step S707; YES), the CPU ends the partial replay processing. However, in this case, the replay processing ends as well as the partial replay processing. That is, the CPU proceeds with the process as indicated by the dotted line in FIG.

Here, at the time of the replay parameter setting processing, the value to be subtracted from the read position pointer and the value to be set for the reproduction time counter are changed in accordance with the index value. I will briefly explain why.

For example, during the race processing, the 63rd frame (the start point screen is set to the 0th frame)
Now, consider a case where the own vehicle contacts an enemy vehicle. In this case, in the replay data area, replay data having an index code having an index value of “1” after replay code # 63, which is replay data having the configuration shown in FIG. 6, is recorded. . Therefore, if the re-display of the race content is performed using some replay codes existing before the index code and some replay codes existing after the index code, the game device can display the enemy vehicle. The replay of the scene in contact with the car can be performed.

As for the event of “contact”, it is usually possible to reproduce the screen for about 2 to 3 seconds before and after the time when the contact actually occurs (detected), so that the occurrence of the event can be recognized. Can be obtained. In addition, when an enemy vehicle is pulled out or when an enemy vehicle is pulled out, it is often better to perform the reproduction for a longer time. For this reason, in the game device of the first embodiment, the replay parameter setting is performed in order to change the time at which the reproduction of the race content is started and the reproduction time as shown in FIG. 19 according to the type of the event that has occurred. In the process, the change of the reading position pointer and the setting of the reproduction time counter are performed as described above.

The replay code employed for storing the game contents in the present game apparatus does not include the absolute position information of each vehicle in the course coordinate system in order to reduce the size of the entire replay data. Data. Therefore, even if the content of the operation performed on the input device 25 after the display of the i-th frame (that is, the replay code) is known, the position of each vehicle in the i-th frame (race situation data) is not known. Then, the (i + 1) th frame cannot be displayed.

Therefore, in the game device of the first embodiment, the race condition data necessary for the partial replay
The latest 300 to be stored in M
The process of storing (storing) individual pieces of race situation data is performed.

As described in detail above, according to the game device of the first embodiment, the content of a race that has been performed in the past can be replayed with a monotonous portion removed, in other words, it can be seen. Only interesting parts can be displayed in a short time. Therefore, if the present game device is used, the game can be more enjoyed.

<Second Embodiment> In the game device of the second embodiment, replay data is created by the same header code, replay code, index code, and end code as those used in the game device of the first embodiment. Device. The basic operation procedure is the same as that of the game device of the first embodiment. For this reason, the operation of the game device of the second embodiment will be described below focusing on the differences from the game device of the first embodiment.

First, a replay code recording process performed in the game device according to the second embodiment will be described with reference to FIGS. It should be noted that the flowcharts shown in these figures do not show the step of determining whether or not the event is a recording required event. In other words, it is a flowchart showing the operation procedure of the CPU when it is instructed to record all events.

As shown in FIG. 20, at the start of the replay code recording process, the CPU in the game device of the second embodiment, like the CPU in the game device of the first embodiment,
Processing for Recording Replay Code (Step S801)
And the process of increasing the value of the recording position pointer by "1" (step S802), then it is determined (detected) whether or not various events have occurred (step S80).
3, S805, etc.).

However, C in the game device of the second embodiment
When detecting that an event has occurred, the PU performs processing different from that of the CPU in the game device of the first embodiment. For example, if your car and an enemy car were in contact,
The CPU in the game device according to the first embodiment records an index code with an index value of “1” at the position pointed to by the recording position pointer at that time. (Step S
803; YES), the CP in the game device of the second embodiment.
U shifts the storage position of the recently recorded 60 codes backward, and records the index code having the index value “1” in the storage position vacated by the shift.
(Step S804).

For example, let us consider a case where it is detected that the replay data area is in contact with an enemy vehicle when the state is as shown in FIG. In this case, the CPU in the game device of the second embodiment executes replay codes # 4 to # 4.
The storage position of # 63 is shifted backward by one code, and the index code whose index value is set to "1" is recorded at the position where replay code # 4 was recorded, thereby changing the state of the replay data area. FIG.
Change to the one shown in 2 (b).

Further, when skidding has occurred (FIG. 20:
Also in step S805; YES), instead of recording the index code at the position indicated by the recording position pointer, the storage positions of the 60 most recently recorded codes are shifted backward, and An index code having an index value "2" is recorded (step S806). As shown in FIGS. 20 and 21, even when other events have occurred, the CPU
Performs a similar process. If the required number of shiftable codes is not necessary, the CPU shifts all codes except the header code.

As described above, the CPU of the game device according to the second embodiment does not add the index code to the end of the replay data at the time of the replay code recording process. The index code is inserted at a position corresponding to the type, ie, at a position where the partial replay should be started.

For this reason, the game device of the second embodiment
23, 24, and 25 are performed as the conditional replay processing, the replay parameter setting processing, and the partial replay processing, respectively.

That is, the flow chart shown in FIG.
As is clear from comparison with the flowchart shown in FIG.
In the conditional replay processing executed in the game device of the embodiment, in a step corresponding to step S501, the situation data point is not initialized, and only the code indicated by the read position pointer is read (step S901). Also, each time a replay code is read (step S902; replay), one race situation data is updated based on the data in the replay code (step S903).

At the time of the replay parameter setting processing, as shown in FIG.
Processing for setting a value corresponding to the index value (step S
1002, S1004, S1006, and S1007) are performed. At the time of the partial replay processing, FIG.
As shown in the figure, in the first step S1101, except that the race situation data corresponding to the value of the situation data pointer is not read, the partial replay processing executed by the game device of the first embodiment Exactly the same processing is performed.

As described above, the game apparatus of the second embodiment shifts the replay code at the time of the race processing, so that it is necessary to hold a large number of race situation data during the replay processing. There is no equipment.

<Third Embodiment> A game device according to a third embodiment uses a replay code having a different configuration from the replay code used in the game devices according to the first and second embodiments. ing.

Specifically, as shown in FIG.
The replay code 45 used in the game device according to the embodiment is obtained by adding an index value field 55 to the replay code 42 used in the game device according to the first or second embodiment.

In the game device according to the third embodiment,
As the replay code recording processing, the processing of the procedure shown in FIGS. 27 and 28 is performed. These flowcharts are shown in FIG.
As in the case of 0 and 21, the step of determining whether the event is a recording required event is not shown.

As shown in FIG. 27, when the replay code recording process starts, the CP in the game device of the third embodiment is set.
U is, like the CPU in the game device of the first embodiment,
First, the replay code is recorded at the position indicated by the recording position pointer (step S1201). In this step, the CPU records a replay code in which “0” is set in the index value field.

Next, the CPU starts determining (detecting) whether or not various events have occurred (step S).
1203, S1205, etc.). Then, when it is detected that the vehicle is in contact with the enemy vehicle (step S1203; YE)
S), the CPU sets “1” in the index value field in the replay code identified by the value obtained by subtracting “60” from the value of the recording position pointer at that time (step S1204).

That is, the CPU in the game device according to the third embodiment determines that the state of the replay data area is, for example, as shown in FIG.
9 (a) (replay code # 6
3 is recorded), if it is detected that the vehicle is in contact with an enemy vehicle, the index value field of replay code # 3 is set to "1" to change the state of the replay data area to the state shown in FIG. Change to the one shown in.

When the occurrence of another event is detected,
The PU performs the same processing. For example, when it is detected that the wall has been contacted (step S1209; YES),
"4" is set in the index value field in the replay code identified by the value obtained by subtracting "90" from the value of the recording position pointer at that time (step S121).
0). If it is detected that the rollover has occurred (FIG. 28: YES in step S1215), the index value field in the replay code identified by the value obtained by subtracting “150” from the value of the recording position pointer at that time is added to the index value field. 7 "is set (step S1216). If the value obtained by subtracting “90” or the like from the value of the recording position pointer is negative, the CPU sets a value corresponding to the event that has occurred in the index value field in the replay code identified by “0”. I do.

Then, the CPU always increases the value of the recording position pointer by "1" (step S1223), and ends the replay code recording processing. Note that the value of the recording position pointer is increased in step S12.
This is because the replay code is added in step S011, and this process may be performed immediately after step S1201.

As described above, the replay data recorded by the game device according to the third embodiment is data using a replay code which also has a function as an index code. For this reason, the game device of the third embodiment is configured so that replay is performed in the following procedure.

As shown in FIG. 30, during the replay processing (unconditional replay processing) executed by the game device of the third embodiment, the step corresponding to step S409 in FIG. 15 is not executed. This is because the replay data created by the present apparatus does not include an index code.

As shown in FIG. 31, during the conditional replay processing, in step S1402 corresponding to step S902 (FIG. 23), the value set in the index value field in the read replay code is replaced with the designated value. It is determined whether the value is an index value. If it is not the designated index value (step S
1402; other), the race status data is updated, and the race index data is the designated index value (step S1).
402; designated index value), a replay parameter setting process (step S1410) and a partial replay process (step S1420) are performed.

The replay parameter setting processing executed in step S1410 is exactly the same as the processing (FIG. 24) executed in the game device according to the second embodiment.
The partial replay process is a process of the procedure shown in FIG.

That is, in the replay code read from the replay data area, if the value set in the index value field is the designated index value (step S1502; designated index value), the replay parameter setting process (step S1502). (Step S1510; the same as the processing in step S1410), and thereafter, is subjected to frame replay processing (step S1503). On the other hand, when the value set in the index value field is not the designated index value, the frame is directly subjected to the frame replay processing (step S1503). And
The process of executing the frame replay process using the read replay code is repeated until the read replay code becomes an end code (step S1507; YES) or the reproduction time counter becomes “0” (step S1508; YES). It is.

Note that step S1502 and step S150
1510 is provided because the reproduction time counter is “0”.
If the replay code in which the specified index value is set in the index value field is read before the value becomes, the value of the playback time counter is reset, and
Even without these steps, the illustrated partial replay process functions without any problem. That is, the replay of the event occurrence scene can be performed.

<Fourth Embodiment> When creating (recording) replay data, the game device according to the fourth embodiment performs a first
A replay code (see FIG. 8) having the same configuration as that used by the game device of the second embodiment is used. However, the game device according to the fourth embodiment is a device that records an index code having a different configuration in a different form when various events occur and are detected during a racing game.

First, the operation of the game device of the fourth embodiment during the race processing will be described. The race processing executed by the game device according to the fourth embodiment is different from the race processing shown in FIG. 3 in the processing executed in steps S207, S211 and S212.

Specifically, in a step corresponding to step S207, a replay code recording process whose flow is shown in FIG. 33 is performed. That is, during the replay code recording process, the CPU in the game device of the fourth embodiment first records the replay code at the position indicated by the value of the recording position pointer (step S1601), and increases the value by “1” (step S1601). Step S1602). After that, the CPU
It is determined (detected) whether or not various events such as “contact with an enemy vehicle” have occurred (step S1603). If it is detected that any event has occurred (step S1603; YES), it is determined whether or not the event is a recording required event based on the recording environment information (step S1604). If the event requires recording (YES), an index code of a predetermined size consisting of a frame number (a value obtained by subtracting “1” from the value of the recording position pointer) and an index value is stored in the replay data area (see FIG. 4). (Step S1605). And
The CPU ends the replay code recording processing.

If the event to be detected has not occurred (step S1603; NO), if any event has occurred but the event is not a recordable event (step S1604; N
O), without adding an index code,
The replay code recording process ends.

In a step corresponding to step S211, the CPU in the game device according to the fourth embodiment executes
The end code is recorded in the replay data area, and an index code in which both the frame number and the index value are “0” is added to the index code area.
That is, in the game device of the fourth embodiment, replay data in which only a plurality of replay codes are sandwiched between a header code and an end code, and an index code which can be expressed as shown in FIG. Groups are created.

[0133] Then, in the step corresponding to step S212, when the storage of the replay data is instructed, the replay data recorded in the replay data area and the index code group recorded in the index code area are stored in the memory card. Is done.

Next, replay processing executed by the game device according to the fourth embodiment will be described. The overall flow of the replay processing executed by the game device according to the fourth embodiment is shown in FIG.
This is the same as the replay processing in the game device of the third embodiment shown in FIG. However, in a step corresponding to step S1303, the replay data and the index code group are read into the replay data area and the index code area, respectively.

At the time of conditional replay processing, FIG.
Processing of the procedures shown in 5 and 36 is performed. That is, C
First, the PU sets “1” to the variable m and sets “0” to the write end position variable PE (step S1).
701). Next, the CPU reads the m-th index code (frame number NF and index value IV) (step S1702). That is, data of the index code size is read from a position separated by (m-1) × index code size from the head of the index code area.

Thereafter, the CPU determines whether or not the read index value IV is "0" (step S17).
03), and if not “0” (NO), IV =
It is determined which of 1-3, IV = 4-6, IV = 7-9, IV = 10 is satisfied (steps S1704, S17)
06, S1708), and when IV = 1 to 3 is satisfied (Step S1704; YES), “NF-60” is set in the writing start position variable PS and “150” is set in the reproduction frame number variable LP. Is set (step S
1705). If IV = 4 to 6 is satisfied (step S1706; YES), the CPU sets “NF” in PS.
In addition to setting “−90”, LP is set to “240” (step S1707).
When 7 to 9 are satisfied (Step S1708; YES)
, Set “NF-150” in the PS,
LP is set to “360” (step S1709), and I
When V = 10 is satisfied (Step S1708; NO)
, Set “NF-300” in the PS,
“600” is set to LP (step S1710).

After setting the value corresponding to IV to PS and LP, the CPU determines whether or not PE <PS is satisfied (step S1711).
Contains the values of the array variable FD (i) as PE + 1 to PS-1.
Is set to “0” for each i (step S1712).
Then, in a succeeding step S1713, the CPU:
Change the value of PE to PS + LP, and change the value of FD (i) to
"1" is set for each i of PS to PE. Further, “1” is added to m.

If PE <PS is not satisfied (step S1711; NO), the CPU executes step S1713 without writing "0".

The CPU repeats such processing, and
When V = 0 (step S1703; YES), the value RP of the read position pointer (PR is initialized in a step corresponding to step S1304 in FIG. 30)
Is determined to be greater than or equal to PE, and if not (FIG. 36: step S1720; NO), the replay code at the position indicated by the RP is read (step S17).
21). Then, the race situation data is updated using the replay code (step S1722), and the FD (R
Only when P) is “1” (step S1723), the frame replay processing is executed (step S17).
24). Then, “1” is added to the value of the read position pointer (step S1725), and the process returns to step S1720.

As described in detail above, when the occurrence of a certain type of event is detected, the game device of the first to fourth embodiments sets an index code indicating that occurrence to a replay on the screen where the event has occurred. Since it is stored in association with the code, the content of the racing game played by the player can be omitted from the monotonous portion and only the scene where the event occurs can be reproduced.

Note that the game device of each embodiment can be variously modified. For example, the game device of each embodiment is a device for playing a racing game, but it is obvious that the present technology may be applied to other games. Further, the game device of each embodiment is realized by causing a general information processing device to execute a program recorded on a CD-ROM, and the medium on which the program is recorded is a floppy disk, CD-RO such as MO
A medium other than M may be used. Furthermore, a game device corresponding to each embodiment may be configured as a dedicated device.

In the game device of each embodiment, the reproduction time is set at the time of the replay processing. However, information indicating the reproduction time may be included in the index code. Furthermore, the game device of each embodiment is a device in which race contents are stored by a replay code including operation content information. However, similar to the game device of each embodiment, the game device uses a replay code including absolute position information. A functioning device may be configured. However, with such a configuration, the size of the replay data becomes large. Therefore, when the memory size is limited, as in each embodiment,
It is desirable that the race content be recorded by a replay code including the operation content information.

[0143]

According to the present invention, it is possible to reproduce the contents of a game played by a player without a monotonous portion, in other words, to reproduce only interesting scenes in a short time at the time of reproduction. So you will enjoy the game more.

[Brief description of the drawings]

FIG. 1 is a block diagram illustrating a schematic configuration of an information processing device used in a game device according to each embodiment of the present invention.

FIG. 2 is a flowchart showing an overall operation procedure of the game device of the first embodiment.

FIG. 3 is a flowchart of a race process executed in the game device of the first embodiment.

FIG. 4 is an explanatory diagram of a use form of a RAM in the game device of the first embodiment.

FIG. 5 is an explanatory diagram of a race course.

FIG. 6 is an explanatory diagram of replay data created by the game device of the first embodiment.

FIG. 7 is an explanatory diagram of a header code which is an element of replay data.

FIG. 8 is an explanatory diagram of a replay code, an index code, and an end code which are elements of replay data.

FIG. 9 is a flowchart of a replay code recording process executed in the game device of the first embodiment.

FIG. 10 is a flowchart following FIG. 9 of a replay code recording process executed in the game device of the first embodiment.

FIG. 11 is a flowchart following FIG. 10 of the replay code recording process executed in the game device of the first embodiment.

FIG. 12 is a flowchart following FIG. 11 of a replay code recording process executed in the game device of the first embodiment.

FIG. 13 is an explanatory diagram of a screen displayed during a recording environment setting process.

FIG. 14 is a diagram illustrating an example of a race screen displayed by the game device according to the first embodiment.

FIG. 15 is a flowchart of a replay process executed in the game device of the first embodiment.

FIG. 16 is a flowchart of conditional replay processing executed in the game device of the first embodiment.

FIG. 17 is a flowchart of a replay parameter setting process executed in the game device of the first embodiment.

FIG. 18 is a flowchart of a partial replay process executed in the game device of the first embodiment.

FIG. 19 is an explanatory diagram of a relation between an occurrence event, a reproduction start time, and a reproduction time.

FIG. 20 is a flowchart of a replay code recording process executed in the game device of the second embodiment.

FIG. 21 is a flowchart of a replay code recording process executed in the game device of the second embodiment, following FIG. 20;

FIG. 22 is an explanatory diagram schematically showing an index code recording procedure of a replay code recording process executed in the second embodiment.

FIG. 23 is a flowchart of a conditional replay process executed in the game device of the second embodiment.

FIG. 24 is a flowchart of a replay parameter setting process executed in the game device of the second embodiment.

FIG. 25 is a flowchart of a partial replay process executed in the game device of the second embodiment.

FIG. 26 is an explanatory diagram of a replay code used in the game device of the third embodiment.

FIG. 27 is a flowchart of a replay code recording process executed in the game device of the third embodiment.

FIG. 28 is a flowchart of the replay code recording process executed in the game device of the third embodiment, following FIG. 27;

FIG. 29 is an explanatory diagram schematically showing a replay code recording procedure in a replay code recording process executed in the game device of the third embodiment.

FIG. 30 is a flowchart of a replay process executed in the game device of the third embodiment.

FIG. 31 is a flowchart of a conditional replay process executed in the game device of the third embodiment.

FIG. 32 is a flowchart of a partial replay process executed in the game device of the third embodiment.

FIG. 33 is a flowchart of a replay code recording process executed in the game device of the fourth embodiment.

FIG. 34 is an explanatory diagram of an index code recorded in a replay code recording process in the game device of the fourth embodiment.

FIG. 35 is a flowchart of a conditional replay process executed in the game device of the fourth embodiment.

FIG. 36 is a flowchart of the conditional replay process executed in the game device of the fourth embodiment, continued from FIG. 35.

[Explanation of symbols]

 DESCRIPTION OF SYMBOLS 10 CD-ROM 20 Information processing apparatus 21 Control part 22 RAM 23 Sound processing part 24 Interface part 25 Input part 26 MDEC 27 Graphic processing part 28 CD-ROM drive 29 Bus 30 Display device 31 Memory card 32 Communication interface part 33 Communication line 41 Header code 42, 45 Replay code 43 Index code 44 End code 51 Course identification information field 52 Number of vehicles field 53 Vehicle information field 55 Code identifier field 56 Operation content information field 57 Index value field 100 Network

Claims (21)

(57) [Claims] 1. A game device having a function of recording data for reproducing a game result in a storage means, wherein the game execution means causes a display device to display an image corresponding to a content of a player's operation on an input device; Each time the image is displayed on the display device by the game execution means, the replay code storage means for the image to generate a replay code containing information that can be created and stored in the form of the order of generation is seen in the storage means when the by the game execution means, said when the image in which any of the display device a predetermined type of event that has been determined in advance has occurred is displayed, Izu among the predetermined type of event
Index code storage means for storing, in the storage means, an index code including type information indicating whether or not this has occurred , in association with the replay code for the image
If, containing from replay codes stored in the storage means, wherein each index code stored in the storage unit includes a replay code associated with the index code, the order of generation is continuous, its index code
Identify the number of replay codes according to the type information included , and create and output multiple images in chronological order using all the replay codes specified for any one of the index codes in the order in which they were generated. And a replaying means. 2. The apparatus according to claim 2, further comprising: a replay event designating unit for designating an event to be replayed from the predetermined type of events, wherein the replay unit is configured to perform the replay based on the type information included in the index code. Only for an index code determined to be related to the event specified by the replay event specifying means, a predetermined number of replay codes including a replay code associated with the index code and having a continuous generation order are specified. The game device according to claim 1, wherein 3. A storage event designating means for designating an event for which an index code is to be stored from among the predetermined types of events, wherein the index code storing means is configured to: When an image in which any of the events of the predetermined type predetermined in the display device is specified by the storage event specifying unit is displayed, the index code is stored in the storage unit. 2. The game device according to claim 1 , wherein the game is performed. Wherein said replay code storage means, the game device according to any one of claims 1 to 3, characterized in that to generate the replay code containing information indicating the operation content for the input device of the player . 5. The replay code and the index code are codes of the same size, and the index code storage means is configured to store the index code so as to be associated with the replay code by a storage position in the storage means. the game device according to any one of claims 1 to 4, characterized in that storing. 6. The replay code has an index code field for setting the index code, and the index code storage means stores the index code in an index code field of a replay code to be associated. The game device according to any one of claims 1 to 5 , wherein: Wherein said index code storage means as associated with the replay code should start replay, according to any one of claims 1 to 6, characterized in that storing said index code game apparatus. 8. A method for controlling a game device in which data for reproducing a game result is generated in a storage device, wherein a game execution step of displaying an image corresponding to an operation performed by a player on an input device on a display device. Each time an image is displayed on the display device by the processing of the game execution step, generates a replay code including information capable of creating the image, and stores the generated replay code in a storage device in a form in which the generation order can be understood. a code storage step, when any of the game execution step predetermined type predetermined for the display device by the processing of events resulting image is displayed, of the predetermined type of event
An index code including type information indicating which of the following has occurred, an index code storing step of storing the index code in the storage device in association with the replay code for the image , and a replay code of the replay code stored in the storage device. From inside, before
For each index code stored in the storage device,
Replay code associated with the index code
Included in the order of generation
Number of replay codes, and determine which index
All replay codes specified for
Multiple images in chronological order by using
And a replay step of creating and outputting the game device . 9. A replay event designation step for designating an event to be replayed from among the predetermined types of events, wherein the replay step is based on the type information included in the index code. Only for the index code determined to be related to the event specified by the processing of the replay event specifying step, specify a predetermined number of replay codes including a replay code associated with the index code and having a consecutive generation order. 9. The control of the game device according to claim 8, wherein
How . 10. A storage event designating step for designating an event for which an index code is to be stored from among the predetermined types of events, wherein the index code storing step is performed by a process of the game execution step. When an image in which any of the events specified in the storage event specifying step is displayed in the predetermined type of events predetermined on the display device is displayed, an index code indicating that is displayed, 9. The method according to claim 8, wherein the image is stored in the storage device in association with the replay code for the image. 11. The replay code storing step,
Game apparatus according to any one of claims 8 to 10, characterized in that to generate the replay code containing information indicating the operation content for the input device of the player
Control method . 12. The replay code and the index code are codes of the same size, and the index code storing step is performed so that the index code is associated with the replay code by a storage position in the storage device. The method of controlling a game device according to any one of claims 8 to 11 , further comprising : 13. The replay code has an index code field for setting the index code, and the index code storing step stores the index code in an index code field of a replay code to be associated. control method for a game device according to any one of claims 8 to 12, characterized in that. 14. The index code storing step, as associated with the replay code should start replay, game according to one of claims 8 to 13, characterized in that storing said index code How to control the device . 15. A game device having a function of recording, in a storage means, data for reproducing a game result in a computer, wherein the computer executes a game for displaying an image corresponding to an operation performed by a player on an input device on a display device. Means, each time an image is displayed on the display device by the game execution means, generates a replay code including information capable of creating the image, and stores the replay code in a storage means in a form in which the generation order can be understood. storage means, by the game execution means, said when the image either has occurred in the display device predetermined predetermined type of event is displayed, Izu among the predetermined type of event
Index code storage means for storing, in the storage means, an index code including type information indicating whether or not this has occurred , in association with the replay code for the image
When, from among replay codes stored in the storage means, before
For each index code stored in the storage means,
Replay code associated with the index code
Included in the order of generation
Identify as many replay codes as
All replay codes specified for
Multiple images in chronological order by using
A computer-readable recording medium on which a program for operating as a game device having replay means for creating and outputting the same is recorded. 16. The program, further comprising: a replay event designating means for designating the computer to perform an event to be replayed from the predetermined types of events.
Further, the replay unit is associated with the index code only for an index code determined to be related to the event specified by the replay event specifying unit based on the type information included in the index code. 16. The computer-readable recording medium according to claim 15 , wherein the computer-readable recording medium is operated as a game device that includes a replay code and functions as a unit that specifies a predetermined number of replay codes in a continuous generation order. 17. The program further comprises: a storage event designating unit for designating the computer to store an index code from the predetermined type of events, wherein the index code storage unit When the game executing means displays an image in which one of the events of the predetermined type predetermined by the storage event specifying means is displayed on the display device, the effect is displayed. The computer-readable recording medium according to claim 15 , wherein the computer is operated as a game device that functions as a unit that stores an index code indicating "?" In the storage unit in association with the replay code for the image. 18. The replay code storage means, claim and generates a replay code containing information indicating the operation content for the input device of player 1
A computer-readable recording medium according to any one of claims 5 to 17 . 19. The replay code and the index code are codes of the same size, and the index code storage means is configured to store the index code so as to be associated with the replay code by a storage position in the storage means. a computer-readable recording medium according to any one of claims 15 to claim 18, characterized in that storing. 20. The replay code has an index code field for setting the index code, and the index code storage means stores the index code in an index code field of a replay code to be associated. The computer-readable recording medium according to any one of claims 15 to 19 , wherein: 21. The index code storage means,
As associated with the replay code should start replay, computer-readable recording medium according to any one of claims 15 to claim 20, characterized in that storing said index code.