JP3738857B2 - Sports broadcast receiver - Google Patents

Description

[0001]
[Industrial application fields]
This case is based on sports game progress data distributed by two-way networks using telephone lines, coaxial cables, optical fibers, etc., and unidirectional data broadcasting using terrestrial and satellite broadcasting. The present invention relates to a sports broadcast receiver of a simulation type to be reproduced.
[0002]
[Prior art]
Since there is a time frame for sports broadcasting by TV broadcasting, there are cases where the entire contents of a game cannot be relayed in sports where the game time cannot be predicted, such as baseball. In addition, there are cases where there is no relay broadcast itself, or there are cases where reception is not possible locally depending on the broadcast channel, and the viewer cannot always watch the desired game. In order to solve this problem, Japanese Utility Model Laid-Open No. 55-51060 proposes that a baseball game situation is transmitted by teletext and the game situation is reproduced by a display device provided on the terminal side. In Japanese Utility Model Laid-Open No. 55-51060, since the presence or absence of a runner is displayed corresponding to each base, the progress of the baseball game can be transmitted clearly.
[0003]
In Japanese Patent Laid-Open No. 6-134143, the broadcasted game situation is relayed by text broadcasting, a simulated image is created using graphic data stored in the ROM, and displayed on a TV monitor. Alternatively, a system has been proposed in which a game can be watched regardless of the broadcast time. Further, Japanese Patent Laid-Open No. 6-134143 proposes the use of text broadcasting as a means for updating player data regarding a baseball game which is one of TV game software. This makes it possible to realize a baseball game that can also receive baseball broadcasts. At the same time, JP-A-6-134143 suggests the existence of a service that, as a prior art, transmits data of professional baseball games played in the past and reproduces the game in a personal computer network using a telephone line. Yes.
[0004]
If these techniques are used, the amount of information to be transmitted can be extremely reduced compared to a live-action video in TV broadcasting, so that a large amount of game content can be relayed with a small bandwidth. In addition, since the actual game progress is usually slower than the simulation image, it is only necessary to send data intermittently, and it is possible to transmit all the games of 12 teams with a small number of channels by time division multiplexing. In addition, as mentioned in the prior art of JP-A-6-134143, if the game data is transmitted collectively as “past game” after the game ends, the game will not fit in the broadcast time frame due to the extension of the game time. This problem can be solved. Furthermore, since the latest player data can be used, a realistic baseball game can be performed.
[0005]
[Problems to be solved by the invention]
However, in Japanese Utility Model Publication No. 55-51060, only the results of batters such as outs, hits, and home runs are transmitted, so the movements of individual players in actual matches are not known and lacks reality. In Japanese Patent Laid-Open No. Hei 6-134143, since the movement of the player and the ball is sequentially transmitted, the smooth movement of the player and the ball in the simulation image cannot be obtained, and the game progress is awkward. In addition, since the simulation image usually progresses faster than the actual game, there is a problem in that the viewer who looks at the simulation image looks like the game is delayed.
[0006]
In addition, each player and ball move in the field at the same time in any direction and at any speed, so a huge amount of work is required to accurately convert all these movements and positions. Makes it extremely difficult. However, there is a problem that the simulation image to be reproduced becomes monotonous and lacks a sense of reality if the data amount is reduced and the game is reproduced only from simple result data. Therefore, a transmission data format and a receiving device that can reproduce a realistic image with an appropriate amount of data and that can relatively easily create data are required.
[0007]
In addition, in the case of broadcast broadcasting, in order to watch a game for one game, it is necessary to spend as much time as the actual game time. If the ball strike is counted or if the inning that does not affect the movement of the game can be fast-forwarded, viewers with less free time can view the entire game. Also, in the TV relay, the video of the dramatic part of the game is rewound and played by the operation on the TV station side, which is used as an effect to increase the excitement level of the game. As described above, the fast-forward / rewind function is a very useful function for the viewer, but there is no such function in a sports broadcast receiving apparatus of a type that reproduces a game by a conventional simulation image.
[0008]
Also, in the case of sports, there are many cases of “if you are doing at that time”, and there is a very high demand to reproduce the situation that was not actually performed. However, a conventional sports broadcast receiving device that plays a game by using a simulation image does not have a function for interrupting the game halfway and allowing the viewer to continue playing as a baseball game, and the viewer remains frustrated. I had to watch the game to the end.
[0009]
Therefore, an object of the present invention is to provide a sports broadcast receiving apparatus that reproduces a realistic simulation image with a small amount of data and relatively easily creates data. Another object of the present invention is to provide a sports broadcast receiving apparatus capable of controlling simulation images such as fast-forwarding and rewinding. In addition, another object of the present invention is to provide a sports broadcast receiving apparatus that eliminates viewer frustration by interrupting simulation playback of an actual game that has been actually performed and continuously executing the game as a sports game. That is.
[0010]
[Means for Solving the Problems]
In order to solve these problems, this case is based on command data for controlling the graphics of each player and ball, and command parameters provided corresponding to the command data and indicating the moving direction or position of the graphics. Receiving means for receiving game data composed of a combination of a plurality of commands for each game or every specific break in the game, game data storage means for storing the received game data, and the command data Graphic data storage means for storing corresponding graphic data, and game data The graphic data corresponding to the command is displayed at the position indicated by the command parameter and / or the graphic data corresponding to the command is indicated by the command parameter By displaying in action, Image generating means for generating a simulation image And an input means for inputting an instruction from the viewer, and a game information storage for storing the game situation at the time of interruption when the image generating means interrupts the generation of the simulation image based on the instruction from the viewer Means and a continuous execution means for starting the game based on the game situation and executing the image generation means based on the command instructed by the viewer to advance the game. It is characterized by doing.
[0011]
In addition, the present invention corresponds to a sequence control means for controlling the graphic display sequence, an in-operation instruction means provided corresponding to a specific graphic display sequence, indicating that the sequence is in operation, and the command data. And an execution condition storage means for storing the execution conditions of the corresponding command data, and an execution pause means for temporarily stopping the execution of the corresponding command data based on the execution conditions and the in-operation specifying means.
[0012]
Further, this case corresponds to an input means for inputting an instruction from the viewer, and an instruction from the viewer. Of a part that does not include a specific action of a specific player Cancel the simulation image display, Includes specific actions of specific players Fast-forward playback means for simulation reproduction of only a part, fast-forward / rewind means for changing the simulation image playback position in units of one segment, and playing back the simulation image from the playback position changed based on the image initialization data, It further has a reproduction position changing means for reproducing the simulation image from the reproduction position changed based on the game resetting data by arbitrarily changing the reproduction position for each game break.
[0014]
[Action]
The game data received by the receiving means is stored in the game data storage means and reproduced by the image generating means. When displaying graphic data of players and balls, the image generation means uses the position data blocked in a relatively coarse matrix as the base point and end point, and generates a simulation image by continuously moving and displaying between them To do. Therefore, it is possible to reproduce a realistic game situation rather than simply generating a simulation image from only the result data. Further, it is possible to reproduce the simulation screen with a smaller amount of data than to transmit the player and ball position data every moment, and the data can be easily created.
[0015]
The sequence control means activates the corresponding in-operation instruction means when executing the graphic sequence of the player or the ball. When the image generation means executes the next command, the execution suspension means refers to the execution condition corresponding to the next command from the execution conditions stored in advance in the execution condition storage means, and the in-operation instruction means Compare with the operating state of the sequence shown. If the condition is not satisfied, the execution pause means temporarily stops the next command execution by the image generation means. After that, when the sequence progresses and ends, the conditions are satisfied, and the execution suspension means cancels the command execution suspension and the execution of the next command is permitted. Since the waiting time is generated as necessary by this execution pause means, the speed of the player and the ball can be basically made constant, and it is not necessary to have data on the speed as game data. Therefore, the amount of data to be transmitted is reduced, and the creation of game data is facilitated.
[0016]
The fast-forward reproduction means cancels the display of the simulation image of the part that does not affect the progress of the game in accordance with the instruction from the viewer input from the input means, and the image generation means to continuously reproduce only the affected part To control. The fast-forward / rewind means corresponds to the situation initialization data provided for each game progress break such as a baseball batter unit, in accordance with instructions from the viewer input from the input means, the simulation image Control the playback position. Further, the playback position changing means corresponds to the game resetting data provided at the game breaks such as inning in baseball and before / after the soccer, according to instructions from the viewer input from the input means, Change the playback position of the simulation image. Thereby, the viewer can watch the game in accordance with his / her free time.
[0017]
The continuation execution means executes the continuation of the game as a game based on the content of the game information storage means storing the game situation at the time when the reproduction of the simulation image is interrupted. The continuous execution means generates a random number subjected to statistical processing based on the operation information from the input means, and automatically determines a command to be executed. The determined command is executed by the image generation means and is output to the TV monitor as a game image. According to this, since an event that did not actually occur can be simulated in a pseudo manner, frustration regarding the game of the viewer can be solved.
[0018]
【Example】
FIG. 1 is a system conceptual diagram conceptually describing the system configuration of this case. The data receiving means 104 receives game data from data broadcasting by satellite broadcasting, a network by telephone line, etc., and stores it in the game data storage means 102. The image generation means 120 reads commands and parameters included in the game data from the game data storage means 102, generates a simulation image using the graphic data stored in the graphic data storage means 100 in association with the command, and Display on the monitor. The parameters include blocked position data, and the corresponding graphic data designated by the command is displayed so as to move on the screen with the blocked position data as a base point or an end point.
[0019]
The graphic sequence control means 122 included in the image generation means 120 sets the operating instruction means 108 corresponding to the sequence being executed. The execution suspension unit 110 compares the execution condition stored in the execution condition storage unit 106 with the operation state of the sequence stored in the in-operation instruction unit 108, and executes the next command by the image generation unit 120 until the condition is satisfied. Pause. The fast forward reproduction means 112, the fast forward / rewind means 114, and the reproduction position change means 116 change the position of the game data reproduced by the image generation means 120 based on the operation information from the operation means 118. The game information storage unit 126 stores the reproduction status of the game data reproduced by the image generation unit 120. The continuation execution unit 124 suspends the reproduction of the game data by the image generation unit 120 based on the operation information from the operation unit 118 and starts the game based on the game situation stored in the game information storage unit 126. Then, the continuation of the interrupted game is executed as a game.
[0020]
FIG. 2 shows a system external view of the present invention. Connected to the information processing apparatus 2 are a satellite broadcast receiving adapter 4, a memory cartridge 6, and a controller 8 for a viewer to input operation information. The satellite broadcast is received by the BS antenna 10, and an arbitrary broadcast channel is selected by the BS tuner 12. The subcarrier signal of the selected broadcast channel is demodulated by the BS tuner and output as a bit stream signal described later. The distributor 14 distributes the bit stream signal from the BS tuner 44 into two, and supplies one of them to the satellite broadcast receiving adapter 4. Video and audio signals from the information processing apparatus 2 are output to the TV 16 and displayed. The AC adapter 18 is connected to the satellite broadcast receiving adapter 4 and supplies power to the satellite broadcast receiving adapter 4, the information processing apparatus 2, and the cartridge 6.
[0021]
FIG. 3 is a system block diagram of an embodiment of the present invention. The BS antenna 10 receives broadcast radio waves from broadcast satellites. The subcarrier of a specific channel included in the broadcast radio wave is tuned by the BS tuner 12 and demodulated into a 64-bit broadcast packet shown in FIG. The BS tuner 12 further accumulates 32 broadcast packets, forms a broadcast packet data matrix, and scans this in the vertical direction to generate a bit stream signal of a total of 2048 bits.
[0022]
The generated bit stream signal is given to the PCM decoder 22 via the data channel decoder 20. The PCM decoder 22 extracts audio information from the PCM audio data part of the bit stream signal after the BCH error correction, and reproduces the audio by DA conversion. The reproduced analog audio signal is given to the information processing apparatus 2. On the other hand, the bit stream signal subjected to BCH error correction is supplied from the PCM decoder 22 to the data channel decoder 20. The frame synchronization, control code, and range bit of the bit stream signal are control signals used at the time of reproducing audio and data.
[0023]
The data channel decoder 20 reorganizes only the data channel portion of the bit stream signal into the format of the above-described broadcast packet data matrix to form a data matrix of 15 bits × 32 broadcast packets. One data matrix is called one frame, and a continuous data matrix for nine frames is called one superframe. As shown in FIG. 5, the data channel decoder 20 accumulates nine data matrices for each frame to construct a data matrix for one superframe. This data matrix is scanned in an oblique direction as shown in FIG. 5, and a total of 288-bit data packets are generated. Since the scan in the oblique direction is performed in parallel in 15 columns, 15 data packets are generated in one superframe.
[0024]
In the data packet shown in FIG. 5, 11-bit error correction code 1 is used for BCH error correction for LCI1. LCI1 is an identification code of the data packet, and the data channel decoder 20 determines the packet based on LCI1 and stores it in the buffer. The LSI 2 is a preliminarily provided packet identification code, and is used for packet discrimination and storage, similar to the LCI 1. The scramble control code SCC is a flag that specifies the presence or absence of scramble, and the continuity index CI and the data group control code DCT are used for the construction of data group data to be described later.
[0025]
The data channel decoder 20 performs SDSC error correction on the entire data packet using the error correction code 2 of 82 bits. Further, a plurality of 176-bit broadcast data are accumulated as shown in FIG. 6 to construct one data group. The data group control code DCT described above is an identification flag indicating the first packet and the end packet of the data group, and the continuity index CI is a count value for confirming the continuity of each data packet.
[0026]
The data group includes a data group header, data group data, and CRC data. The data group header is an identification code for identifying the data group, a continuous transmission code indicating the number of continuous transmissions, and a data group link code that is a control signal for accumulating a plurality of data groups to form a larger data group And a data group size indicating the data group serial number and the number of data of the data group. These broadcast formats are described in detail in document 67-14 of the Telecommunication Technology Council Satellite Data Broadcasting Committee report.
[0027]
The data channel decoder 20 performs CRC check on the entire data group using the CRC data, and confirms that there is no error in the data in the data group. The data group data constitutes one data file in this part, and the game data is supplied by this data file. The data file assembled (or being assembled) by the data channel decoder 20 is stored in a buffer in the data channel decoder 20 and transferred to the flash memory 42 or the pseudo SRAM 44 by the CPU 24. When the game data is stored in the flash memory 42, the information does not disappear even if the power is turned off, so that the game received in advance can be viewed at a later date.
[0028]
The ROM 46 stores programs for the CPU 24 to operate as image generation means, sequence control means, execution pause means, fast forward reproduction means, fast forward / rewind means, reproduction position change means, and continuous execution means. The ROM 46 functions as graphic data storage means and execution condition storage means. When the game data is simulated and reproduced, the CPU 24 reads out a command included in the game data from the flash memory 42, for example, reads out corresponding graphic data from the ROM 46, and generates image data to be displayed on the TV 16.
[0029]
Image data generated by the CPU 24 is stored in the video RAM 30 via the PPU 28. The PPU 28 generates a video signal based on the data in the video RAM 30 in cooperation with the DA converter and the video encoder, and supplies the video signal to the TV 16. Similarly, audio data generated by the CPU 24 is stored in the audio RAM 36 via the APU 34 and output as an audio signal by the APU 34. The audio data output from the APU 34 is converted into an analog signal by the DA converter. The mixer 38 mixes the analog audio signal from the APU 34 and the analog audio signal from the PCM decoder 22 and supplies the mixed signal to the TV 16.
[0030]
When the CPU 24 operates as sequence control means in accordance with the program stored in the ROM 46, the CPU 24 sets an operating flag corresponding to the graphic sequence in the work RAM 26. For example, in a baseball broadcast, when a pitcher performs a pitching sequence, a graphic sequence corresponding to the pitcher's pitching form and a graphic sequence corresponding to the trajectory of the ball are executed, and a ball indicating that the ball is moving The flag is set to 1. The ROM 46 stores execution conditions corresponding to each command. For example, for a command in which a batter hits a ball, the ball flag is set to 0. The CPU 24 refers to the ball flag prior to the execution of the command for the batter to hit the ball, and executes the command for the batter to hit the ball until the ball flag becomes 0, that is, until the ball has moved to the batter's position. Pause. In this case, the operating flag stored in the work RAM 26 constitutes an operating instruction means.
[0031]
The CPU 24 changes the reproduction position of the game data stored in the flash memory 42 based on the operation information input from the controller 8. Thus, for example, in baseball broadcasting, a fast-forward playback function that plays a game while skipping the batter's midway count, a fast-forward / rewind function that fast-forwards and rewinds in units of batters, and playback that changes the playback position in units of innings A position change function is realized.
[0032]
Further, the CPU 24 interrupts the reproduction of the game data stored in the flash memory 42 based on operation information input from the controller 8. The CPU 24 scans the interrupted game data in the forward direction, and executes the game program stored in the ROM 46 using the data for resetting the most recent game as an initial value. For example, in a baseball game, the game is normally started once, but since the game is started with the data that has already progressed halfway as an initial value, it is possible to continue playing as a baseball game with the game situation at the point of interruption. In this case, the ROM 46 corresponds to the game progress information storage means. Further, in the simulation reproduction of the game data, the progress of the game may be constantly recorded in the work RAM 26, and the game may be started based on this to enable continuous play. In this case, the work RAM 26 corresponds to the game progress information storage means.
[0033]
7 and 8 show image display examples during game reproduction or continuous play execution when the present invention is implemented as a baseball broadcast. FIG. 7 is a view showing a state immediately before the pitcher is thrown, and the first base, the second base, and the third base are enlarged and displayed in the window. In addition, a window showing the status of the game is displayed on the lower left and right of the screen. With these, the situation in FIG. 7 is 0-0, batter is 4th light △△△, 2 out 2 runners are counting 2 strike one ball. It can be seen that it is. When the pitcher throws the check ball or when the batter hits the ball, the entire image as shown in FIG. 8 is automatically switched so that the movements of the fielder, runner, and hit ball can be seen at a glance. FIG. 8 shows a situation where the second runner has entered the main base due to a hit before light and the fielder of light is back home.
[0034]
When reproducing such a game situation, simply displaying the result only with letters lacks a sense of urgency, and merely displaying the result with a uniform graphic results in poor realism. For example, if you only reproduce the corresponding image based on the result of the pre-write hit, the second over hit or the hit that broke the gap between the first and second bases will all be reproduced in the same image, so the game will It feels monotonous. In this case, in order to solve this, since the subdivided game code for the character on the display is set, the game can be reproduced more realistically. The game code is video and audio control data composed of commands and parameters.
[0035]
FIG. 9 shows an example of commands included in the game code, and FIG. 10 shows an example of parameters described following the commands. Each game code is a code corresponding to the action performed by the displayed character (player on the game), and the situation of the game can be reproduced very realistically by the combination of the game codes. For example, “P022, R2, H382, M938, M438, M368, M646, M564, M286, C9, V2, R3, S986, V4, R1, C2, T2, V3, S246, C6, T6O” In the column, the following game situation is reproduced:
[0036]
P022 ... The pitcher threw a straight in the middle.
R2 ... Second runner start.
H382 ... Batter hit. The ball is second over and one-bound in front of the light.
M938, M438 ... Light and second follow the ball.
M368, M646, M564, M286 ... First, short, third, catcher covers the base.
C9 ... Light catches.
V2, R3 ... The second runner reaches the third. Continue to home.
S986 ... Light throws to the main base.
V4, R1 ... Batter runner reaches first base. Continue to Futaba.
C2, T2, V3 ... Catcher catching, touch, but the runner is alive.
S246 ... The ball is sent to the second without catching.
C6, T6O ... Short catch. Touch out.
[0037]
In addition, commands that are not directly related to the progress of the game are also included as a preliminary. For example, the L command is a command that performs video and audio processing for events such as sounding a fanfare or launching a firework during a home run. Different. By using the R command and the V command simultaneously with the L command, it is possible to display that the runner goes around the diamond in the fanfare. The & command is used to display a comment as a character string in an arbitrary part of the game. This makes it possible to deal with unforeseen situations that cannot be handled by the prepared commands.
[0038]
The game code table shown in FIG. 9 includes control data to be used as an index during game playback. The [command and] command designates a data group that may be omitted during fast-forward playback. For example, if the batter's mid-count is enclosed in [] symbols and the final data of the batter, that is, the striker, strikeout, four-ball, etc. are described outside the [] symbol, the mid-count graphic will be omitted during fast-forward playback. Only the resulting part is played back continuously. Also, the Z command controls to end the game play at that time. For example, even if an unforeseen situation occurs (for example, rain, etc.) and the game is canceled in the middle of the game, the reproduction can be automatically ended by executing this command.
[0039]
The G command is executed immediately before the pitch, and initializes the screen based on the game progress data (X times front / back), score data, batter data, count data, and runner data. The X command is executed at the end of each inning, and redefines the progress of the game based on the game progress data, score (for each innings) data, and participating player data. The G command and the X command are effective when the game play position is arbitrarily changed based on an instruction from the viewer, and at the same time, when game data is partially damaged due to a communication error or the like. is there. It is also possible to set other control data, for example, to display only the scoring scene continuously, or to reproduce a shortened digest version as in the news.
[0040]
In this case, various measures are taken to reduce the number of data to be communicated. In the pitching course code table of FIG. 10, the field is divided into 13 × 10 blocks. When an arbitrary block is indicated in the pitching, the ball moves toward the center of the target block at a specific speed. The hitting course, fielder movement, and ball course at the time of throwing are also controlled in units of these blocks, and are all processed by the movement of the ball or player from the center of each block to the center of another block. The reason why the game can be reproduced with a small amount of data while recording all the movements of the player is because the movement coordinates of the ball and the player are blocked on the field as shown in this figure. Even with this degree of blocking, it is possible to display a reproduced image that is much more realistic than the uniformed image representation based only on the result data as described above.
[0041]
Further, the way of hitting the ball is also classified into several types as shown in the ball hitting type table of FIG. The hit type 1 indicates that the hit ball is directly caught by the fielder. The hit ball type 2 indicates that the hit ball is one bound in front of the fielder. In hitting ball type 3, it indicates that the hitting ball is Goro. In the case of Goro, the bounce width corresponds to, for example, half the width of one block of the pitching course code table, and a graphic or sound effect indicating that the bounce is bounced for each bounce is generated. Preferably, this hitting ball type is further subdivided into a ball that bounces in units of one block, a ball that bounces in 1/10 block width, and the like. By this, it is possible to express a painful goro that crawls the ground or a small goro at the time of a bunt. Furthermore, you may add the parameter which shows the speed of a hit ball.
[0042]
Thus, as the types of parameters increase and the amount of data increases, a more realistic game is reproduced. However, how much realistic the game is and how much the increase in the amount of data is allowed differs depending on the system. However, in order to obtain a completely realistic game reproduction, it is necessary to record an accurate hitting course and an accurate hitting speed, which makes it extremely difficult to create data. Coordinate blocking and hitting ball type classification are also effective for facilitating data creation.
[0043]
In the reproduced image realized in this embodiment, the player and the ball basically move on the field at a constant speed. Therefore, when the game data is continuously read out, a shift occurs between the movement of the ball and the movement of the player, and an abnormal situation occurs in which, for example, a touch-out occurs even though the ball has not reached. In order to solve this, the present case has an execution waiting flag table corresponding to each command as shown in FIG. For example, in the T command indicating the touch of the fielder, when the flag “BALL” indicating that the ball is moving is 1, the command execution is temporarily stopped. In addition, when the fielder X (X corresponds to the position code specified by the parameter) is moving, the flag “DEFX” is in progress, and the runner X (X corresponds to the kite that the runner has made) is moving. In this case, the flag “RUNX” is set to 1, and the execution of the corresponding command is suspended as in the above case.
[0044]
Further, the M command in FIG. 11 is not affected by the flag “BALL”. Accordingly, the fielder can start moving even while the ball is moving. However, since it is affected by the flag “DEFX”, the next movement is temporarily stopped until the once designated M command is finished (until the movement is finished). In this way, by using the execution waiting flag, instantaneous processing or execution waiting processing is performed as necessary, so there is no need for a special time control command, and the game can be reproduced realistically with a small amount of data. Although this method can prevent the command from being executed in advance, it is not possible to prevent a display failure such that, for example, a runner who should be touched out reaches the base before the ball. In this case, adjustment is made so as not to cause a visual problem by changing the moving speed of the ball or the player, or continuing the animation in which the player is running after reaching the ball.
[0045]
FIG. 12 shows an example of the format of the game data file stored in the flash memory 42. The game data file includes player data, game data, and a game pointer table. The player data includes a list of players who entered the bench in the game, score data of each player, home run number, number of steals, etc. and a player list of starting members. The game data is usually composed of 18 inning data consisting of front and back from 1 to 9 times. The inning data includes batter data corresponding to the number of batters standing at batting at the inning and the X command (see FIG. 9) for resetting the game situation.
[0046]
The batter data is composed of a plurality of commands starting with a G command for screen initialization and a P command for pitching. The game progress pointer indicating the current game play position sequentially moves in command units, and based on this, the command is read into the CPU 24 and the graphic sequence is executed. For example, when the game progress pointer is in a P command indicating a pitch, a pitching sequence as shown in FIG. 12 is executed. A pitching sequence corresponding to the P command includes a five-step pitch animation and a one-step ball control. The pitcher throwing animation is composed of five pictures, and each picture is displayed on the screen at a corresponding stage, and is displayed as a series of animations. Ball control is realized by a program routine that controls the trajectory of the ball in accordance with the type of ball and moves the ball from the hand of the pitcher to the vicinity of the batter.
[0047]
During execution of the P command, the flag “BALL” is set to 1 and reset to 0 when the ball control is completed. When the game progress pointer moves to the next command and the H command indicating that the batter has hit is read into the CPU 24, the CPU 24 refers to the flag “BALL” before executing the H command. As shown in the execution waiting flag table of FIG. 11, when the flag “BALL” is 1, the H command is set to pause execution, so that the batter sequence is executed until the ball control in the pitching sequence is completed. Is paused.
[0048]
The game pointer table is an address table used when fast-forwarding / rewinding and moving the reproduction position. In the inning pointer table, the starting position for each inning of the game (that is, the position of the X command) is stored as a relative address from the beginning of the game data, and this relative address value is set in the game progress pointer, thereby reproducing the position. It can be moved. The batter pointer table stores the command start position (that is, the position of the G command) for each batter as a relative address from the beginning of the game data, and the relative address value after one batter or before one batter is used as the game progress pointer. By setting, fast forward and rewind are possible. Of course, instead of using such a pointer table, the match data may be scanned and the X command or G command searched to obtain the relative address.
[0049]
FIG. 13 shows a flowchart of a program executed by the CPU 24 for reproducing the game data. In this embodiment, game data for one game is received from the network or data broadcast and stored in, for example, the flash memory 42 of FIG. The reception of the game data and the initialization of the game progress pointer are performed prior to the game data processing shown in FIG. The game data is played back in three different modes, a fast-forward playback mode, a normal mode, and a step mode, and the game playback position is changed by two types of playback position controls, a fast-forward / rewind mode and an inning jump mode.
[0050]
The fast forward playback mode is time-reduced playback controlled by the [command and] command. The normal mode is full auto playback in which all data is automatically played, and the viewer can watch the game like a TV broadcast. The step mode is a step reproduction in which the game is advanced by the viewer operating the switch for every pitcher's pitch. The fast forward / rewind mode is a step movement mode in which the playback position is moved forward or backward by one hitter by a viewer's switch operation. The inning jump mode is a mode in which the viewer moves the playback position to an arbitrary inning by operating a switch. The operation from the viewer is processed by a routine different from the flowchart shown in FIG. 13 by, for example, interrupt processing, etc., and controls mode switching, transition to continuous play, and the like.
[0051]
In S2, the game code indicated by the game progress pointer is read from the flash memory 42, and a command analysis for executing the corresponding sequence processing routine is performed. In S4, when the game code is a P (throwing) command, a subroutine called mode check is started. The mode check is executed according to the flowchart shown in FIG. 14, and designation of each mode and game data reproduction position change processing are performed based on operation information from the viewer. In S6, if the playback position is changed by the mode check, the process returns to S2, and if the game code is not a pitching command or the game playback position is not changed even if it is a pitching command, the process goes to S8. Transition.
[0052]
In S8, the presence / absence of a wait for the command is checked based on the execution waiting flag table shown in FIG. If a wait is necessary, the process proceeds from S10 to S18, and the execution of the command is temporarily suspended. In this case, since the command pointer is not incremented, the same command is read again when S2 is reached via S18 and S20. If there is no need for a wait and processing is performed immediately, the process proceeds from S10 to S12.
[0053]
In the present embodiment, graphic sequence processing across a plurality of TV frames such as player movement and ball movement is controlled by a sequence execution flag. The sequence execution flag corresponding to the command is set to ON in S12 and reset to OFF at the end of the sequence. The sequence set to ON in S12 is initialized in S14 and executed in S18. For example, the initialization of the pitching sequence corresponding to the P command is executed based on the flow shown in FIG. 15, and the execution of the pitching sequence is executed based on the flow shown in FIG. In S16, the command pointer is moved to the position of the next game code.
[0054]
In S18, each sequence process is executed based on the sequence execution flag. When a plurality of sequence execution flags are ON, these sequences are sequentially executed in a time division manner. Thus, for example, a multitask process is performed in which the fielder moves while the ball is moving and the runner moves. In S18, not only graphic sequence processing but also control data processing is performed. For example, control of fast-forward playback [command is also executed in S18], such as command search and command pointer movement, is performed. In S20, it is determined whether or not the game code is a Z command. If the game code is a Z command, reproduction of the game is stopped. If it is not the Z command, the process proceeds to S2, and the next command execution or command re-execution based on the wait process is performed.
[0055]
FIG. 14 shows a mode check processing routine. In S22, the presence or absence of an operation input indicating a mode change instruction by the viewer is confirmed. If there is no mode change instruction, the process proceeds to S26, and if there is a mode change instruction, the process proceeds to S24. In S24, the mode is changed based on the operation information from the viewer. In S26, the program branches so that the processing is executed for each mode. In the jump mode, in S28, operation information from the viewer indicating the jump destination inning for changing the reproduction position is input. When the jump destination inning is input, the inning pointer table on the match pointer table in FIG. 12 is referred to in S30, and the corresponding address value is set in the match progress pointer. Immediately after the jump, the game is reset by the X command, so that the game is reproduced from the jumping inning.
[0056]
In the fast forward / rewind mode, the position of the batter pointer, that is, the position of the batter pointer table on the game pointer table of FIG. 12, is detected based on the address value indicated by the game progress pointer in S32. In step S34, the batter pointer position is incremented when fast-forwarding and decremented when rewinding. In S36, based on the incremented / decremented batter pointer position, the corresponding batter pointer is read from the batter pointer table and set in the match progress pointer. Since the screen is initialized by the G command immediately after fast forward / rewind, the game is reproduced from the previous or previous batter. In the above-described jump mode and fast forward / rewind mode, all command sequences are stopped in S38, all execution waiting flags are cleared, and the command being executed is cancelled. Also, the normal mode is automatically restored.
[0057]
In the normal mode, the [command and] command is invalidated in S40, whereby all game data is reproduced. In the fast-forward playback mode, the [command and] command is validated in S42, whereby only the main part of the game data is continuously executed. Immediately after the [command and] command is validated, the game progress pointer is moved to the position of the next [command and] command in S44. In step playback mode, the viewer waits for key input in S46 and loops until the key is pressed. In this case, each time the pitcher pitches, the key input is waited, which is effective when the viewer views the game while wearing the score book. In the continuous play mode, the program shifts to the continuous play routine shown in FIG.
[0058]
FIG. 15 is a flowchart showing a pitching sequence initialization routine. In S50, the pitching sequence number is reset to zero. In S52, the pitcher throwing form is determined based on the player data shown in FIG. In S54, both the flag “BALL” and the flag “ACTV” are set to 1, and the suspension process based on the execution waiting flag table shown in FIG. 11 is designated.
[0059]
FIG. 16 is a flowchart showing an execution routine of the pitching sequence. In S60, graphic processing according to the sequence number is performed. For example, in the pitching sequence shown in FIG. 12, the graphic data of the pitching animation is written in the video RAM 30 in sequence numbers 1 to 5 and the ball position is moved in sequence number 6 to execute graphic processing. In S62, the sequence number is incremented, and it is confirmed in S64 whether or not the predetermined number of sequences (6 in the case of a pitching sequence) has been exceeded. If the sequence has not ended in S64, the pitching sequence execution routine based on the sequence number ends. When the sequence is completed, the flag “BALL” is reset to 0 in S66, and the sequence execution flag indicating the pitching sequence is turned OFF. As a result, the pitching sequence ends, and execution of the next command paused by the flag “BALL” is permitted.
[0060]
FIG. 17 shows a program flowchart when the continuous play is selected in FIG. In S70, game status data for continuous play is transferred. In a normal case, since the game situation stored in the work RAM 26 is used as it is in the continuous play, no actual data movement occurs. In the game situation data, game resetting and screen initialization information specified by the latest X command and G command are stored, and thereby, continuous play is initialized. Next, in S72, a player's edit such as a substitution is input, and in S74, a strategy input such as stealing is performed. Further, when the ball type or pitching course is input in S76, the P command is executed in S78.
[0061]
When the stealing is instructed in S74, the R command is executed in S80, thereby starting the runner on the guard. In S82, batting control is performed. The hit rate and long hit rate of the batter are referred to from the player data shown in FIG. 12, the probability of hit is statistically calculated, and the result of this hit is determined by a random number based on the probability of hit. In S72, when neither the pitcher nor the batter is changed, the hit result may be referred to from the actual game data. In the case of an idling or overlook, control shifts from S84 to S86, and stealing control 2 is executed in S86. Here, the fielder's movement is controlled, second pitching, second base cover and touch graphic control are performed, and the success / failure of the theft is based on the runner's running power data and catcher's defensive power data It is determined. In addition, it is confirmed in S87 whether or not it is a strikeout or foreball, and if not, the control moves to S72. If it is a strikeout or foreball, the process proceeds to S100, the batter's processing is terminated, and a G command is generated.
[0062]
When the batter hits the ball in S82, the process proceeds from S84 to S88, and the nearest fielder follows the ball, and the other fielders generate M commands to run on the base cover. The runners and batter runners are controlled by the runner control 1 in S90, and advance according to flyout / goloout / single hit / two strikes / three strikes. In S92, fielder control 2 is executed, and an S command meaning throwing, a C command meaning catching, a T command meaning touch, and the like are generated. In S94, it is determined as a result whether the ball is out or safe by catching or touching. Further, when the runner is moving, the program shifts from S96 to S92, and the fielder control 2 and the runner control 2 are repeatedly executed. When the action is stopped, the program shifts from S96 to S98, and a hit result such as “double hit!” Is displayed in characters by an & command for displaying a comment. After the batting result display in S98, the process proceeds to S100, and the action of the batter is finished.
[0063]
The confirmation of the outcount and the inning step are executed in S100, and it is confirmed in S102 whether or not the game has ended. If the game has not ended yet, the program returns to S72 and the above-described processing is repeatedly executed. According to this continuous play, for example, whether or not a relief is to be inserted or whether or not to use a substitute can be confirmed by simulation. Of course, not all consecutive plays will always produce the same result, so it is not possible to determine the success / failure of the manager's coaching in the actual game, but even if the result is However, viewers' frustration is resolved because the results can be seen for the time being.
[0064]
【The invention's effect】
By using the present invention, it is possible to provide a sports broadcast receiving apparatus that reproduces a realistic simulation image with a small amount of data and relatively easily creates data. Moreover, since simulation image control such as fast-forwarding and rewinding is possible, it is possible to provide a sports broadcast receiving apparatus capable of playing a game in accordance with the viewer's free time. Furthermore, it is possible to provide a sports broadcast receiving apparatus capable of resolving viewers' frustration by interrupting simulation playback of an actually played game halfway and continuously executing the game as a sports game.
[Brief description of the drawings]
FIG. 1 is a system conceptual diagram conceptually describing a system configuration of the present invention.
FIG. 2 is a system external view of the present invention.
FIG. 3 is a system block diagram of an embodiment of the present invention.
FIG. 4 is a bit stream signal configuration diagram illustrating a bit stream signal generation process and a data structure;
FIG. 5 is a data packet configuration diagram showing a data packet generation process and a data structure;
FIG. 6 is a data file configuration diagram showing a data file generation process;
FIG. 7 is an image display example during game reproduction or continuous play execution when the present invention is implemented as a baseball broadcast, and is a screen configuration diagram showing a state immediately before pitching.
FIG. 8 is an image display example during game reproduction or continuous play execution when the present invention is implemented as a baseball broadcast, and is a screen configuration diagram that displays the entire field.
FIG. 9 is a list of commands included in a game code.
FIG. 10 is a setting diagram of parameters described following a command.
FIG. 11 is an execution waiting flag table corresponding to a command.
FIG. 12 is an example of a format of a game data file.
FIG. 13 is a flowchart of a program executed by a CPU 24 to reproduce game data.
FIG. 14 is a mode check processing routine for fast forward / rewind and the like.
FIG. 15 is a flowchart showing an initialization routine for a pitching sequence.
FIG. 16 is a flowchart showing a throwing sequence execution routine.
FIG. 17 is a program flowchart for continuous play.

Claims (5)

In a sports broadcast receiving apparatus that receives sports broadcasts in a data format and reproduces them by simulation, command data for controlling the graphics of each player and ball, and corresponding to the command data are provided, and the moving direction or position of the graphics is determined. Receiving means for receiving game data constituted by combining a plurality of commands consisting of command parameters to be instructed for one game or at specific intervals during the game, and game data storing means for storing the received game data And graphic data storage means for storing graphic data corresponding to the command data, and by continuously executing the commands included in the game data in a predetermined order, the graphic data corresponding to the commands are indicated by command parameters. Displayed at By displaying in operation specified for the graphic data in the command parameters corresponding to and or commands, and an image generating means for generating a simulation image, input means for inputting an instruction from the viewer, an instruction from the viewer When the image generation means interrupts the generation of the simulation image based on the game information storage means for storing the game situation at the time of interruption, the game is started based on the game situation, and from the viewer Sports broadcast receiving apparatus for chromatic and continue execution means for advancing a game by executing the image generating means based on the indicated command. The image generation means includes sequence control means for controlling the graphic display sequence, is provided corresponding to a specific graphic display sequence, and indicates an in-operation indicating means indicating that the sequence is in operation, and the command Execution condition storage means provided corresponding to the data and storing execution conditions of the corresponding command data; and execution pause means for temporarily stopping execution of the corresponding command data based on the execution conditions and the in-operation specifying means The sports broadcast receiving apparatus according to claim 1, further comprising: An input means for inputting an instruction from the viewer, and canceling the display of the simulation image of the part not including the specific action of the specific player in response to the instruction from the viewer , 2. The sports broadcast receiving apparatus according to claim 1, further comprising fast-forward reproduction means for performing simulation reproduction of only the portion including the portion. The game data further includes image initialization data provided for each break in progress of the game, input means for inputting an instruction from the viewer, and a reproduction position of the simulation image corresponding to the instruction from the viewer The sports broadcast receiving device according to claim 1, further comprising fast-forward / rewind means for reproducing a simulation image from a reproduction position changed in units of one segment and changed based on the image initialization data. The game data further includes game resetting data provided for each game break, input means for inputting instructions from the viewer, and the reproduction position of the simulation image corresponding to the instructions from the viewer The sports broadcast receiving apparatus according to claim 1, further comprising reproduction position changing means for arbitrarily reproducing the simulation image from a reproduction position that is arbitrarily changed in units of breaks and changed based on the game resetting data .

Images