Abstract:
A system and method for updating parameters of a video game is provided. As events occur in the real world that may influence a game attribute, a parameter is recorded on a server. A video game player may connect to the server and download the parameter. The parameter is stored by the video game and changes an attribute of the video game. Thus, for example, the new performance characteristics of the rising star may be recorded on the server as improved performance parameters. When these parameters are downloaded by the video game player, the video game incorporates the star-like qualities of the rising star.

Description:
RELATED APPLICATIONS 
       [0001]    This application is a division of U.S. patent application Ser. No. 14/034,530 filed on Sep. 23, 2013 entitled METHOD AND SYSTEM FOR INCREASED REALISM IN VIDEO GAMES, which is a continuation of U.S. patent application Ser. No. 10/266,795 filed on Oct. 8, 2002 entitled METHOD AND SYSTEM FOR INCREASED REALISM IN VIDEO GAMES, the contents of both patent applications are hereby incorporated by reference herein. 
     
    
     BACKGROUND 
       [0002]    Many video games attempt to recreate realistic situations. For example, video games simulating sports games and matches are popular. They commonly even show actual leagues with correct teams. Hometowns may be shown, with realistic stadiums. Athletes&#39; uniforms represent professional athletes&#39; actual uniforms. Specific athletes are represented. For example, an image of Shaquille O&#39;Neil may be used as one of the players on the Los Angeles Lakers basketball team. Kobe Bryant and all of Shaquille&#39;s actual teammates may be on the team with him. 
         [0003]    But the realism goes far beyond just images. The video game characters have characteristics approximating their real life counterparts. For example, the video game Shaquille may be very good at dunking the basketball, but horrible at shooting free-throws. Parameters are stored on the video game medium that cause the different characters to replicate their real life counterparts&#39; performance. 
         [0004]    Video game producers typically produce professional sports video games once per year. The performance parameters and visual aspects are typically specified based on the most recent year. For example, Barry Bonds of the San Francisco Giants baseball team had a homerun average of (73 home runs)/(476 at bats)=15.3 percent during the 2001 season. This average can be used to set a video game parameter so that the video game character Barry Bonds has a similar tendency to hit homeruns. A problem with this system is that the performance parameters and visual aspects of a video game are fixed at the time the video game is produced. 
         [0005]    The players of this type of game continually demand increased realism in such games. For example, more and more parameters are added to distinguish one character from another and to more accurately simulate the performance of real life athletes. Also, the realism of the visual aspects of players, teams and stadiums is continually increased. For example, the ivy on the outfield wall of Wrigley Field in Chicago may be shown in a baseball video game. 
         [0006]    The problem remains that visual aspects and performance characteristics of real life sports players, teams and environments change throughout the year. 
       SUMMARY 
       [0007]    Sports video games attempt to achieve realism. Particularly, sports video games frequently attempt to emulate professional sport details. Actual professional athletes are shown, frequently including such details as jersey numbers, physical stature and even facial features. Performance characteristics are emulated. For example, in a baseball video game, an individual professional athlete&#39;s batting average may be used to influence a video game character&#39;s batting performance. Frequently, actual professional teams are provided for video game play. For example, in a basketball video game, players can play the Los Angeles Lakers versus the Chicago Bulls, complete with rosters, players and even a stadium. Video game players are demanding more and more realism like this. 
         [0008]    A major problem with this system is that professional sports change in many ways. Athletes&#39; performances change over the course of a season, or even a day. Additionally, athletes may be traded from team to team, or become injured. Stadia may change. Sports announcers may change. This leaves a video game behind, in an unrealistic state. For example, if a new star rises on the professional sports scene, during the middle of a season, that new star&#39;s incredible performance will not be duplicated by the video game. Video game players are stuck playing the game with the star having his pre-star characteristics. They must wait for the video game producers to produce a new video game incorporating the new star-like performance of the rising star. This is unsatisfying for video game players. They want to play a video game that matches the professional sport performance characteristics, look and feel. 
         [0009]    Accordingly, a system and method for updating parameters of a video game is provided. As events occur in the real world that may influence a game attribute, a parameter is recorded on a server. A video game player may connect to the server and download the parameter. The parameter is stored by the video game and changes an attribute of the video game. Thus, for example, the new performance characteristics of the rising star may be recorded on the server as improved performance parameters. When these parameters are downloaded by the video game player, the video game incorporates the star-like qualities of the rising star. 
         [0010]    This quantifiably increases realism. Video game players can download up-to-the-minute statistics and visual aspects for incorporation into their video games. Instead of playing with last season&#39;s teams, video gamers get a simulation of the fresh new events of the week, day, or hour. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0011]      FIG. 1  is an external view showing a structure of a video game system and a historical event. 
           [0012]      FIG. 2  is a high level block diagram of a video game system. 
           [0013]      FIG. 3  is a block diagram of a video game system. 
           [0014]      FIG. 4  is a block diagram of a game medium. 
           [0015]      FIG. 5  is a block diagram of the players stored in ROM. 
           [0016]      FIG. 6  is a block diagram of a RAM. 
           [0017]      FIG. 7  is a flow chart for choosing whether to update a video game. 
           [0018]      FIG. 8  is a flow chart for updating a video game. 
           [0019]      FIG. 9  is a flow chart for loading data into RAM and playing a video game. 
           [0020]      FIG. 10  is a block diagram showing a portion of a flow diagram for authenticating a user of a video game. 
           [0021]      FIG. 11  shows a portion of a process for authenticating a video game user, continued from  FIG. 10 . 
           [0022]      FIG. 12  is a flow diagram showing a process for signing up a new user of a video game with downloadable statistics. 
           [0023]      FIG. 13  is a flow diagram showing a download process of a new game parameter. 
           [0024]      FIG. 14  is a flow diagram showing game play in a case in which an AC is required. 
       
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       [0025]      FIG. 1  is an external view of a video game system and a historical event. A historical event  11  takes place. For example, the event may be a World Cup soccer game, or an American football game. In a more specific example, the event  11  may be the occurrence of a new yearly completion percentage, or other performance statistic, of a specific quarterback in a specific professional American football game. 
         [0026]    A datum  17  relating to the historical event  11  is recorded on a computer readable medium known as a network server  14 . A game machine  20  is coupled to the network server  14 . The game machine  20  downloads the datum  17 , which may, for example, represent a quarterback&#39;s completion percentage, a basketball player&#39;s free throw percentage, or any other outcome of a realistic event. The datum  17  is then used to play a video game, which is displayed on a monitor  24 . A user  28  plays the video game using controller  30 . In this way, the user gets to play a video game the more accurately simulates the real world. 
         [0027]    For example, a datum representing a quarterback&#39;s new completion percentage is loaded into memory (not shown) in the game machine  20 . Then, the user  28  can play an American football video game with current statistics. This makes the video game more enjoyable to the user  28 , adding increased realism. As real life professional players&#39; performances change, users can still play with statistically accurate players. 
         [0028]      FIG. 2  is a block diagram of a video game system. The video game machine  20  incorporates a central processing unit (CPU)  32  and coprocessor (CP)  34 . The CP  34  includes a bus control circuit  38  for controlling buses, a signal processing unit (SPU)  40  for performing polygon coordinate transformation, shading treatment, etc., a display processing unit (DPU)  45  for rasterizing polygon data into an image to be displayed and converting the data into a data from (dot data) stored on a frame memory. The CP  34  is coupled to a cartridge connector  50  for detachably mounting with a ROM cartridge  52 , a disc drive connector  54  for detachably mounting with a disc drive  56 , and a RAM  58 . Also, the CP  34  is connected with an audio signal generating circuit  61  for outputting a sound signal to an audio output device  62 , processed by the CPU  32 , and an image signal generating circuit  64  for outputting an image signal to a display  65 . Further, the CP  34  is coupled with a controller control circuit  67  for serially transferring operational data for one or a plurality of controllers  70   a - 70   d  and data for a RAM cartridge  73  for extension. 
         [0029]    A modem  72  is coupled to the bus control circuit  38 . The modem  72  is also preferably coupled to the internet (not shown). As discussed with reference to  FIG. 1 , a server coupled to the internet stores performance, visual image and audio parameters. The modem  72  couples to the server and downloads a parameter for play in the video game. The CPU  32  sends a signal through the bus control circuit  38  to initialize the modem  72  and control the modem  72  to download the parameter. Preferably, the parameter is stored in RAM  58  for play of the video game, as discussed below. It will be understood by those of skill in the art that other configurations of video game machines are possible. For example, the CPU  32  and the CP  34 , or portions of the CP  34 , may be incorporated as one component. Also, for example, RAM  58 , may be divided into more than one memory element, or other types of memory elements may be included. 
         [0030]    Referring now to  FIG. 3 , a block diagram of a video game system is shown. A data server  82  is coupled to a network  85 . The network  85  may be, for example, what is commonly referred to as the internet, or, alternatively, the network  85  may be another type of network, such as a local area network (LAN). The data server  82  stores information for use in video games. Advantageously, new statistical results or parameters can be stored on the data server  82 . For example, when a real professional athlete changes a performance rating, the changed performance rating can be stored on the data server  82 . For example, when a professional baseball player changes his batting average, the changed batting average can be stored on the data server  82 . Or, as a second example, if a professional American football quarterback changes his completion percentage the changed completion percentage can be stored on the data server  82 . This allows a video game player to play a video game with the new statistics. The changed statistic may be stored as the actual number that the statistic represents. For example, if a batting average goes from 0.275 to 0.278, then the number 0.278 may be stored on the data server. Or the new statistic may be stored on the data server as a parameter of a video game. The parameter can then be used to affect how the video game character interacts with the video game environment. 
         [0031]    Referring again to  FIG. 3 , the user (not shown) plays the video game by entering inputs through a user interface  87 . The user interface  87  may be, for example, a video game controller (not shown). The user interface  87  is coupled to a video game machine  90 , which may be a video game machine  20 , as shown with reference to  FIG. 2 . The video game machine  90 , is coupled to a RAM  95  and a local memory  99 , preferably a read only memory (ROM). The RAM  95  is used for storing data and rules (described later with reference to  FIG. 4 ) from the game medium  103 . Advantageously, the parameter is also stored on the RAM  95 . Thus, the video game is played with the changed statistic. Advantageously, a video game character, such as, for example, an American football quarterback, will play more realistically based on the video game character&#39;s real life performance, such as, for example, a completion percentage. 
         [0032]    The video game machine  90  is coupled to a modem  107  for coupling to the network  85 . The parameter is downloaded by the video game machine  90  from the data server  82  by means of the modem  107  and the network  85 . As will be understood by those of skill in the art, the modem  107  may be incorporated as part of the video game machine  90 , or a separate component. 
         [0033]      FIG. 4  is a block diagram of a game medium, preferably a ROM  109 . The game medium may be, for example, a compact disc (CD), a digital video disc (DVD), or a cartridge. The ROM  109  includes many rules and parameters for the video game. Rules  111  are stored on the ROM  109 . The rules  111  are shown as Rule  1 , Rule  2 , Rule  3 , etc. The rules govern how the game is played and displayed on the user interface. Advantageously, the rules can be updated to match the rules of the real world. 
         [0034]    There are also other parameters stored on the ROM  109 . For example, stadium parameters  113  may be stored. For example, the game may display Wrigley Field for play by the Chicago Cubs and Fenway Park for play by the Boston Red Socks. For example, the ivy on the homerun wall of Wrigley Field is green and flourishing during certain parts of the year, such as from May to July. During April, August and September, the ivy is browner. The color of the ivy shown in a baseball video game showing Wrigley Field can change based on the time of the year that the video game is played. 
         [0035]    As another example of how realism can be increased, new memorials to great players can be implemented in the video game stadiums. For example, in 2002, Ted Williams&#39; number, “9”, was displayed in the leftfield grass of Fenway Park after the start of the season. Baseball video games were already produced. So the video game fields did not have the number on the field, failing to duplicate real life. Now, the field can be changed to match real life after the game is produced, sold and played in the user&#39;s home. 
         [0036]    Referring again to  FIG. 4 , referees  115  may be stored. Referees&#39; appearances and performance may be stored. For example, some referees in basketball call technical fouls frequently. Some referees rarely call technical fouls. Parameters can be stored regarding the individual referees that simulate these real life differences. 
         [0037]    Team statistics and other parameters can also be stored, such as, for example, the city, owners, trainers, coaches, players, etc. For example, Mike Bibby of the Sacramento Kings, during the 2001-2002 regular season averaged 13.7 points and 12.3 shots attempted per game. In the playoffs of the same season, he averaged 20.2 points and 16.1 shot attempted per game. These improved playoff statistics can now be downloaded. A video game player can play a basketball video game with a Mike Bibby character incorporating the better performing real world Mike Bibby. 
         [0038]    As another example, the 2000-2001 Chicago Bears&#39; opponents scored an average of 22.2 points per game with an average of 114.2 rushing yards per game. The 2001-2002 Chicago Bears&#39; opponents scored an average of 12.7 points per game with an average of 82.1 rushing yards per game. This change was not reflected in video games played during the 2001-2002 season. At that time, the newest video games reflected the statistics from the 2000-2001 season. Thus, the Chicago Bears on the video games played poorly, whereas the Chicago Bears on the real football field played very well. This dichotomy between video game and real life is frustrating to many video game players. 
         [0039]      FIG. 5  is a block diagram of the players stored in ROM. Player  1 , Player  2 , Player  3  and several other players are shown. Under each player, several statistics are shown. For example, if the video game is basketball, Statistic  1  may be a player&#39;s field goal percentage. Statistic  2  may be a free throw percentage. Statistic  3  may be blocks per game. One skilled in the art will appreciate that the number and type of statistics stored will vary with the game and with the way the video game designer choses to design the game. 
         [0040]      FIG. 6  is a block diagram of a RAM  135  used to store game parameters for play of a video game. RAM  135  may be used to store game parameters as are RAM  58  ( FIG. 2 ) and RAM  95  ( FIG. 3 ). Preferably, items are loaded from ROM  109  ( FIG. 4 ) into RAM  135 . Preferably, all of the rules  111  ( FIG. 4 ) are loaded into RAM at  138 . However, only one stadium is loaded from ROM to RAM. Also, only two teams, shown as Team  1  and Team  2  are loaded. As discussed with reference to  FIGS. 1-3 , above, a new parameter is downloaded from the server and stored in RAM  135 . Preferably, the new parameter is stored in RAM in addition to the parameter as loaded from ROM. 
         [0041]    Referring now to  FIG. 7 , a flowchart is shown. In step  221 , the method starts. In step  224 , it is determined whether auto update is enabled. If auto update is enabled, the method continues by going to  FIG. 8 , as shown at step  227 . If auto update is not enabled, the main menu is displayed at step  230 . In step  232 , a user chooses to start a game or request an update. 
         [0042]    In step  234 , it is determined whether the user requested an update. In step  236 , the method continues by going to  FIG. 9 , if the user did not choose to update the video game. If the user did choose to update the video game, the method continues by going to  FIG. 8 , at step  238 . 
         [0043]    Referring now to  FIG. 8 , in step  241 , the CPU initializes the modem. In step  243 , the modem establishes a network connection. Next, in step  245 , the CPU sends a request for data to the data server. At  247  and  249 , the data server  247  sends the requested data  249  to the CPU. Advantageously, the requested data  249  may be updated, or changed, statistics for playing a more realistic video game. For example, as mentioned above, the user may be requesting updated batting averages for game characters in a professional baseball video game. Or, to continue the example from above, the video game player may be requesting a newly established completion percentage for an American football quarterback. Preferably, the request is for all the new statistics resulting from a real game that has already been played, or from a plurality of games. 
         [0044]    Referring again to  FIG. 8 , at step  250 , the CPU receives the requested data and stores it in local memory  254 . In step  251 , the CPU disconnects the modem from the network. Next, at step  253 , the user is prompted that the data transfer is complete. The main menu is displayed at step  255 , and the method continues to  FIG. 9  for play of the game. 
         [0045]    In  FIG. 9 , a flowchart is shown for the play of the video game. At step  265 , the game starts. Next, at step  270 , the CPU loads the game engine  275  from the game medium  280  into RAM  285 . Next, at step  290 , the CPU loads the requested data  295  from local memory  300  into RAM  285 . The requested data  295  is preferably the changed statistics requested by the user and stored in local memory as shown in  FIG. 8 . This way, updated statistics, such as new player performance parameters resulting from current, real professional games can be used to play a more realistic video game, as shown at step  305 . 
         [0046]      FIG. 10  is a block diagram showing a portion of a flow diagram for authenticating a user of a video game. At step  334 , a CPU initializes a modem. The modem connects to a network at step  337 . The game machine displays a login/sign-up screen at step  340 . The user selects either to sign up or login in at step  342 . If the user selects to login, the next step depends upon whether an authentication code (AC) is required, as shown at step  344 . If no AC is required, the CPU sends the login data to the server at step  346 . The flow then continues at  FIG. 11 . 
         [0047]    Alternatively, an AC may be required by the network, as shown at step  348 . This allows the network to verify that the user has a proper authentication code. For example, the authentication code may be provided at sign-up (described with respect to  FIG. 12 ) by the network to the user. This way, the network administrator can verify that the user is a paying user. As another example, a new authentication code may be provided on a periodic basis, such as, for example, monthly. Thus, if a user is paying on a monthly basis, correct authentication is only available if the user&#39;s dues are current. As yet another example, the AC may be associated with a specific game machine by either the network or the CPU. This allows for security for preventing portability of AC&#39;s from one game machine to another. 
         [0048]    Referring again to  FIG. 10 , if authentication is required, it depends whether the AC is auto-sent or not, as shown at step  351 . If the AC is auto-sent, the process continues at step  346 . If the AC is not auto-sent, the user enters a user verification code, at step  354 . At step  357 , the CPU compares the user verification code to a game machine authentication code. If the user verification code matches the game machine authentication code, at step  360 , the process continues at step  346 . As stated in step  346 , the login data  363  is stored at a network server  366 . Next, the process continues at  FIG. 11 . 
         [0049]      FIG. 11  shows a portion of a process for authenticating a video game user, continued from  FIG. 10 . At step  369 , the server attempts to authenticate the login data and any AC present. The AC may include a user verification code, to verify that the user is authorized to receive updated game parameters. Also, the AC may include a code identifying a specific game machine. This identifying code may, for example, be a serial number from the game machine. Alternatively, the identifying code may be a code assigned by the network administrator to the game machine at sign-up (described with respect to  FIG. 12 ). Further, the network administrator may verify that the identifying code, the verification code, and the user login data all match. The verification code may be a password. 
         [0050]    At step  372 , the network checks whether the login data and any AC is authenticated. If the login data and any AC are authenticated, at step  376 , the server sends a menu of available data to the game machine. Then, at step  384 , the CPU displays the menu to the user and continues to  FIG. 13 . If the login data and any AC are not authenticated at step  372 , the server sends a failure message to the CPU, at step  380 . The CPU displays the failure message to the user, at step  388 . Preferably, the CPU next displays the login/sign-up screen to the user again. The process returns to the beginning of  FIG. 10 , at step  334 . 
         [0051]      FIG. 12  is a flow diagram showing a process for signing up a new user of a video game with downloadable statistics. In step  390 , the CPU displays, a sign-up screen. In step  393 , the user enters the user&#39;s name and chosen password, and possibly other identifying information, such as a birthdate, address, etc. In step  396 , the process depends upon whether the AC is auto sent. If the AC is auto sent, the CPU sends the sign-up data  404  to the server  408  in step  400 . In step  412 , the server sends account options  416  to the game machine. 
         [0052]    In step  420 , the CPU displays the account options to the user. In step  424 , the user selects what type of account the user chooses. In step  428 , the CPU sends the users choice of account type to the server  408 . For example, the user may choose to pay for downloads of new game parameters on a monthly basis. As another example, the user may choose to pay for downloads of new game parameters for an entire sports season. Or, as yet another example, the user may choose to pay for downloads of new game parameters on a pay per use basis. Other business models will be apparent to those of skill in the art. 
         [0053]    In step  432 , the server verifies the information, creates an account and sends a menu of game data to the game machine. In step  436 , the CPU displays the menu to the user. Next, the process continues as shown in  FIG. 13 . 
         [0054]    Alternatively, if in step  396 , the AC is not auto sent, the user enters an AC, in step  440 . In step  444 , the CPU compares the user input AC with the game machine authentication code. In step  446 , the CPU determines whether the user input AC matches the game machine AC. If not, the process continues at step  448  and the CPU displays an error message to the user. If the user input AC matches the game machine AC, the process continues at step  400 . 
         [0055]      FIG. 13  is a flow diagram showing a download process of a new game parameter. In step  450 , the user selects a set of desired game parameters. For example, the desired parameters may comprise a complete set of new parameters for all teams in the game. As another example, the desired parameters may comprise the results of a single sports game for a single team. In step  453 , the CPU sends the request to the server. 
         [0056]    In step  456 , the process depends on whether the game machine requires an authentication code. In step  459 , the server sends the requested parameters to the CPU if the game machine does not require and authentication code. In step  462 , the CPU stores the new game parameters in local memory  465 . 
         [0057]    Alternatively, if in step  456 , the game machine requires an AC, the process continues to step  468 . In step  468 , the server attaches account information and the AC to the parameter. In step  471 , the server sends the parameter to the CPU. In step  474 , the CPU compares the AC with the game machine AC. In step  476 , the game machine determines whether the AC sent by the server matches the AC stored on the game machine. If there is no match  476 , the CPU displays an error message in step  482 . If there is a match  476 , the CPU stores the data at step  479  in local memory  465 . The data, or new game parameters, can then be used for play in a game with quantifiably increased realism. 
         [0058]      FIG. 14  is a flow diagram showing game play in a case in which an AC is required. In step  490 , the CPU displays a game menu. In step  495 , the user selects to load saved data  500 , which has been stored in local memory  505 . In step  510 , the CPU reads data from local memory. In step  515 , the CPU compares an AC associated with the data to the game machine AC. In step  520 , the process determines whether the AC associated with the data is the same as the game machine AC. If they don&#39;t match, the CPU displays an error message in step  535 . If they match, the CPU loads the parameter data into RAM  525  in step  530 . Then, the new game parameters are used for play in a game with quantifiably increased realism.