U.S. Pat. No. 7,156,733

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1illustrates a game system10for providing one or more games for a user according to one embodiment of the present invention. System10includes one or more game media12(game A, game B, game C), a game device14, and a display16.

One or more game media12include any game applications that may be used by game device14to provide a game for a user. Each game medium12includes logic to provide a game, denoted as game A, game B, game C. In one embodiment, the game provided by game device14is an electronic video game. Games are each individually stored on media, such as CDROMs, digital versatile disks (DVDs), game cartridges, or any storage media. A game, such as game A, is inserted in, coupled to, or in communication with game device14so that game device14may read a game application found on game media12.

Game device14is a computing device that includes a CPU and data storage. Game device14may be connected to a network that allows game device14to provide games that are not included on one or more game media12. Thus, game A, game B, and game C may be accessed through the network and not be individually stored on game media12. The games provided by game applications on game media12are displayed on display16. A game application may be also referred to as a game code and/or a game program. A game application will be understood to include software code that game device14uses to provide a game for a user to play. A user interacts with the game application and game device14through user input/output (I/O) devices.

FIG. 2illustrates an embodiment of game device14according to the present invention. It should be understood that other variations of game device14may be appreciated by a person of skill in the art. As shown, game device14includes a processing unit20that interacts with other components of game device14and also external components to game device14. A game media reader22is included that communicates with game media12. Game media reader22may be a CDROM or DVD unit that reads a CDROM, DVD, or any other reader that can receive and read data from game media12.

Game device14also includes various components for enabling input/output, such as an I/O32, a user I/O36, a display I/O38, and a network I/O40. I/O32interacts with a storage24and, through a device28, removable storage media26in order to provide storage for game device14. Processing unit20communicates through I/O32to store data, such as game state data and any shared data files. In addition to storage24and removable storage media26, game device14includes random access memory (RAM)34. RAM34may be used for data that is accessed frequently, such as when a game is being played.

User I/O36is used to send and receive commands between processing unit20and user devices, such as game controllers. Display I/O38provides input/output functions that are used to display images from the game being played. Network I/O40is used for input/output functions for a network. Network I/O40may be used if a game is being played on-line or being accessed on-line.

Game device14also includes other features that may be used with a game, such as a clock42, flash memory44, read-only (ROM)46, and other components. It will be understood that other components may be provided in game device14and that a person skilled in the art will appreciate other variations of game device14.

As game device14reads game media12and provides a game, information may be read from game media12and stored in a memory device, such as RAM34. Additionally, data from storage24, ROM46, servers through a network (not shown), or removable storage media26may be read and loaded into RAM34. Although data is described as being found in RAM34, it will be understood that data does not have to be stored in RAM34and may be stored in other memory accessible to processing unit20or distributed among several media, such as game media12and storage24.

FIG. 3illustrates an example of data that may be stored in RAM34to provide a game according to one embodiment of the present invention. For example, a game code60, game variables62, game device data64, and other data66may be downloaded from game media12and stored in RAM34. It will be understood that a person of skill in the art will appreciate other data that may be stored in RAM34that will enable game device14to provide the game.

Game code60may be any logic that is found on game media12that is used to provide a game. Game code60includes game logic70, library functions72, and file I/O functions74. Game logic70is used to provide any functions of the game. Library functions72include any functions that are used to provide a game. File I/O functions74are used by processing unit20to perform input/output functions.

Game variables62are variables that are specific to a game and are used by processing unit20to provide variations of games for different users. The variables allow game device14to provide variations to the game based on actions by a user playing the game.

Game device data64is data specific to a game console that game code60is designed for. For example, different versions of game code60may be designed for different platforms supported by different game devices14. Data specifically needed to operate game code60on a specific platform for a specific game device14may be included in game device data64. Other data66may be any other data that is used with the game.

As a game found on game media12is played on game device14, data regarding the state of the game and any other related aspect of the game may be generated. The game state data is then stored in storage, such as storage24, removable storage media26, RAM34, or any other storage media accessible to game device14. The game state data may then be used at another time by game device14to provide a game that is in the same state as when a user last played the game and saved its state. For example, the game state data may include data that allows a user to continue at a same level that the user has completed, data related to certain achievements that the user has accomplished, etc. It should be noted that the game state data does not necessarily start the game at the same exact place as the place when the game was last stopped but rather may start the game at a certain level or time related to when the game was last stopped or its state was saved.

In addition to the game state data that is stored, shared game state data may also be stored. The shared game state data is stored in a shared game state file that may be read from and written to by game code60for multiple games. Data found in the shared game state file may be used by game code60for a first game to provide a game that uses shared data from a second game, where the shared data from the second game affects actions in the first game.

FIG. 4illustrates a simplified block diagram400that shows the interaction of game code with a shared game state file402according to one embodiment of the present invention. As shown,FIG. 4includes a first game code404, a second game code406, and a third game code408. Game code404,406, and408each correspond to a different game. For example, game code404may correspond to a Racing 2004 game, game code406may correspond to a Football 2004 game, and a game code408may correspond to the same Football game but a 2005 version of the game. Game code404,406, and408are each found on different game media12. Additionally, portions of game code may be read into RAM34. Each game code404,406, and408includes a product I.D. (PID) that may be used to uniquely identify the game. For example, the PID for game code404is “Racing 2004”, the PID for game code406is “Football 2004”, and the PID for game code408is “Football 2005”. It should be understood that these PIDs are being used for illustrative purposes and the PIDs may be represented by other representations, such as numbers, characters, 32-bit integers, etc.

When appropriate, game device14and game code404,406, and408interact to provide data that should be stored in storage24. For example, game code404,406, or408is read by game device14through game device interface401. In one embodiment, each game code404,406, and408has a unique file that includes game state data specific to each game code in storage24. Although game state data is stored in storage24, it will be understood that game state data may be stored in any medium, such as RAM34, removable storage media26, a server through a network, and the like. As shown, game code404is associated with a game state file410, game code406is associated with a game state file412, and game code408is associated with a game state file414. Each game state file410,412, and414is uniquely identified by its corresponding game code PID.

In one embodiment, each game code404,406, or408may access files in storage24at different times. For example, the Racing 2004 game may be played by a user where data is accessed and/or stored in game state file410and/or shared game state file402. Then, the user may play the Football 2004 game where data is accessed and/or stored for game state file412and/or shared game state file402. While playing the Football 2004 game, data for the Racing 2004 game may be read and used by the Football 2004 game.

In addition to storing individual game state data, game device14stores shared game state data in shared game state file402. The data stored in shared game state file402may include data from, if applicable, game code404, game code406, and/or game code408. Thus, shared game state file402is configured to store data associated with different games. For example, data from the Racing 2004, Football 2004, and Football 2005 game applications may be stored in shared game state file402. The multiple game codes can thus read and write data associated with the game to shared game state file204. A version number may also be included in shared game state file402to insure compatibility between different versions of games for game state data.

As a game is played (e.g., the game associated with game code404), game device14reads game code404to provide the game to a user through display16. As a user plays the game, certain achievements may be reached in the game. Game device14then communicates with game code404for the game to determine the appropriate data that should be stored in the game state file410and shared game state file402. For example, if a user reaches a certain level in the Racing 2004 game, game code404may store achievement data corresponding to the achievement in shared game state file402. Another game code, such as game code406, may then read the achievement data for game code404that was stored in shared game state file402and that achievement data may be used by game code406to affect actions in the Football 2004 game corresponding to game code406. For example, certain unlockables or passwords may be provided to a user if a certain achievement has been achieved in another game. Also, certain levels or special features may be attained depending on data stored by another game code in shared game state file402. As the Football 2004 game is played, data corresponding to the game play may also be stored in shared game state file402. In some embodiments, shared game state is also stored in a game state file that also maintains game state for one of the games. Although in this case, the shared game state will be accessible by other games or another shared game state file may exist.

FIG. 5illustrates an embodiment of shared game state file402according to one embodiment of the present invention. As shown, shared game state file402includes header data504, game data506, game data508, . . . , game data510, and other data512.

Header data504is used to identify the shared game state file402. Header data504may also include the version number of shared game state file402.

Game data506,508, and510illustrate different game data that have been stored for different games. For example, game data506may be game data for the Racing 2004 game, game data508may be game data for the Football 2004 game and game data510may be game data for the Football 2005 game. In one embodiment, each game data is identified by its PID. Additionally, each game data506,508, and510may be stored in an index and retrieved using the index. In one embodiment, game data, such as game data506, is used to affect actions in another game, such as a game associated with game data508, and vice versa. Additionally, game data506,508, and510may be read by any game code and any game code may write data either to game data506,508,510, or to a new game data entry.

FIG. 6illustrates an embodiment of game data in shared game state file402, such as game data506, according to the present invention. As described above, shared game state file402may include game data for multiple games. Additionally, each individual game data may include game data for different users. As shown, game data506includes a shared game state data602for a user1, a shared game state data604for user2, a shared game state data606for a user X, etc. Thus, game data in shared game state file402may be classified by different users, such as user1, user2, . . . , user X. In one embodiment, shared game state data for user1may be used to affect actions for a game played by another player, such as user2, and vice versa. In this case, user1and user2may be partners in a game. However, in most cases, shared game state data for a specific user will be used to affect actions in another game for only that specific user.

FIG. 7illustrates another embodiment of game data, such as game data506according to the present invention. As shown, data for a shared sports bio is stored in game data506. In one embodiment, as shown, a shared sports bio file may be stored for each user. Game data506includes a shared sports bio file702for a user1and a shared sports bio file704for a user2. Shared sports bio files702and704illustrate shared files that include data for certain games classified as being sports games. Also, other bios, such as bios for adventure games, fighting games, etc., may be stored. In one example, if a certain level, such as all “Super Bowl” level is reached in a football game, certain data corresponding to the user and game is stored in shared sports bio file702or704. Then, when another sports game is played by the user, the data corresponding to the achievement in sports bio file702or704may be read and used for to affect actions in the second sports game. Additionally, the second sports game may write data corresponding to the second sports game in game data506.

FIG. 8illustrates a system800that shows the interactions between an interface801for a game code and game device14according to one embodiment of the present invention. Interface801includes one or more functions802. One or more functions802are functions that include actions that are used by processing unit20to perform the action on shared game state file402. Interface801includes logic, such as game code, that is stored in media12and possibly downloaded to RAM34.

When a call is made to interface801from processing unit20, a corresponding function802that is associated with the call is made available to processing unit20, which performs an action in one or more functions802. Function802may include logic that is used by processing unit20to determine which game data, such as game data506,508, or510, and which shared game state file, such as shared game state file602,604, or606, to access and an action that should be performed. For example, if a user1is using a game provided by interface801, a shared game state file602may correspond to user1. As user1plays a game, an action in one or more functions802may be triggered. In this case, processing unit20reads function802and uses logic found in function802to perform an action with shared game state file602. The action effected by processing unit20using shared game state file602may use data from a first game to affect actions in a second game that the user is playing. Also, the action may be to write data to shared game state file402when data written by multiple games is present in file402.

FIG. 9illustrates a software infrastructure, such as an infrastructure found in game code60, that might be used in support of shared files according to one embodiment. As shown there, software components such as a game application1000, a tag handler1005, a shared file I/O handler1010, a file system I/O handler1015, a checksum handler1020and an encryption handler1025interact.

In particular, for an access to a shared file, game application1000, which may be part of interface801, might determine that a write to the shared file is needed. The write is packaged as a “tag” element (described below) that is passed to tag handler1005, which might invoke checksum handler1020and/or encryption handler1025if those components are used, to provide checksum services and/or encryption, respectively. Thus, checksum handler1020might calculate and add a checksum to the write request and encryption handler1025might encrypt the write request data. Tag handler1005then passes the write request to shared file I/O handler, which deals with the organization of the shared file and in turn passes the write request to file system I/O handler1015.

In one implementation, a game designer designs game application1000and file system I/O handler1015and a shared file infrastructure designer designs tag handler1005, shared file I/O handler1010, checksum handler1020and encryption handler1025so that the game designers do not need to be concerned with those elements and the shared file infrastructure designer does not need to be concerned with particular game operations or basic file I/O that might be specific to game device14on which the game was designed for. As an example of how this might be implemented, when file system I/O handler1015wants to perform a function, a callback is supplied from game application1000. Callbacks provide access to a function. Thus, because callbacks from game applications are used, different game applications may supply different callbacks for the same function request from SFIO1015. The file system I/O handler would handle the memory allocation and other low level tasks.

An example of a checksum handler is a program that provides 32-bit checksums of the data to be written (and verifies 32-bit checksums of data read from a file). An example of a tag hander is a component that reads and writes data in a tag based format, wherein each “chunk” of data includes a tag. Where data is stored as (tag, data) tuples, later programs can read the shared file correctly and just ignores those tags not understood by the reader.

On some game devices14, shared file I/O might require that a title have more than one game ID, such as a game ID (for accessing single game data) and a shared file ID (for accessing shared game data).

In some implementations, most of the functions are asynchronous functions, such that they return to the code that called the function once they start. A periodically run process can check to determine if the function is complete. Where the SFIO is asynchronous in nature it might be implemented as follows with one operation at a time, and functions being called to start an action ( e.g., SFIOStart( ) (whereis create, find, write, etc.). To the caller, each ACTION represents one atomic operation at the shared module level, however each ACTION may in reality be composed of multiple sub-atomic operations at the callback level. A status process, SFIOProcess( ), might be called every frame to determine the actual status of the previous requested action. This function might have its own internal state machine to track the progress of the requested operation, returning a response indicating whether the process is complete, incomplete or that no process is active.

Tag Handler

Tag handler1005provides a platform and product agnostic interface that formats and unformats data between the application layer and the IO layer. This layer packages data based on tags, wherein chunks of data can be stored in a file and a reader that does not understand some tags will just leave the data of those tags alone, without trying to process it. An example of a file format on which this might be based is Electronic Arts' IFF file format. For example, each chunk of data might be stored as 1) a tag name, 2) a size indicator, 3) a checksum, and 4) the data stored. Each file might have a unique file ID that is checked on every read and modified on every write to track files between each access. Further details of the file format are shown below.

File Format

One example of a format for a shared game state file such as a bio file is shown below. In this format, the file is a fixed size and contains a fixed format. Unused portions of any struct element are filled with initializer values to distinguish empty entries from valid ones. The use of tags, however, provides for a file format that is extensible and backwards compatible. As long as the meaning and the data connected with each tag does not change from year to year and product to product, additional data can be added to the file to accommodate future products while still supporting past products. The tags can be transparent to the game logic, through the use of a tag handler, as described above. Game logic should only ever request data for tags that it understands. The shared game state file might be organized as shown in Table 1 (the overhead of the tags themselves, the size and the checksums is not shown).

TABLE 1File FormatFieldValueBytesCommentChunkKIND4The kind of file (e.g., EASB)ChunkVER4Version chunk.ChunkHeaderT42Header data chunk.ChunkIDProductT2315Product data chunk for product 1.. . .. . .. . .. . .ChunkIDProductT2315Product data chunk for product 50.ChunkIDImageT17206Image data chunk for product 1.. . .. . .. . .. . .ChunkIDImageT17206Image data chunk for product 25.

Table 2 lists some constants that might be used in constructing and using a shared game state file. It should be understood that other suitable values for these constants might be used without departing from this disclosure. As used in Table 2 and following tables, the “type” column refers to the type of the constant or the field, with Uint8, Uint16, Uint32 referring to 8-, 16- and 32-bit unsigned integers respectively, Time referring to a time value (such as a 32-bit number representing the number of seconds elapsed since some time in the past) and Color referring to a color value (such as a 24-bit color value without any alpha as an RGB value with eight bits per color).

TABLE 2ConstantsNameTypeValueCommentsNUM_PRODUint850Maximum number of products in ashared game state file.NUM_IMAGESUint8NUM_-Maximum number of imagesPROD(might be zero, or less thanNUM_PROD).NUM_ACCOMPLISHMENTSUint832Maximum number ofaccomplishments.LENGTH_IMAGE_SIDEUint8128Length of the side of an image inpixels.NUM_COLOR_INDEXUint8256Number of distinct colors that canappear in an image. This is usedto index into the color table.TEXT_COPYRIGHT_LENGTHUint831Maximum length of the copyrighttext.TEXT_PRODUCT_TITLE_-Uint835Maximum length of the productLENGTHtitle text.TEXT_PRODUCT_GAMES_-Uint819Maximum length of the “type ofPLAYED_TYPE_LENGTHgame” games played text.TEXT_ACCOMPLISHMENT_-Uint863Maximum length of theLENGTHaccomplishment text.MAX_GAMESUint8250Maximum number of gamestracked.

Tables 3, 4 and 5 show examples of what might be a format for the HeaderT, ProductT and ImageT chunks, respectively.

TABLE 3HeaderT FormatNameTypeCommentsstrCopyright[TEXT—CharCopyright string.COPYRIGHT—LENGTH + 1]uSecondsGamePlayUint32Total game play time.uSecondsNonGamePlayUint32Total non game play time.uNumProductsUint8The number of products in thisbio file, from 1 toNUM_PROD.uNumProductsPlayedUint8Number of titles ever playedwith this file from 1 toMAX_GAMES.

TABLE 4ProductT FormatNameTypeCommentsstrProductTitle[TEXT_PRODUCT_TITLE—CharProduct Title (alphanumeric).LENGTH + 1]strProductGamesPlayedType[TEXT_PRODUCT—CharThe type of game played. ThisGAMES_PLAYED_TYPE_LENGTH + 1]string contains the word(s) thatdescribe the unit of “game” forthis product (e.g., match, game,race, contest etc.).(alphanumeric)DateLastPlayedTimeDate and time product was lastused.uSecondsGamePlayUint32Total game play time.uSecondsNonGamePlayUint32Total non game play time.uGamesPlayedUint32Number of games played.uGameWonUint32Number of games won.NextRewardAtUintl6If rewards are present for thisproduct, this indicates whatlevel the next reward isavailable at, from 1 to someupper limit, such as 1250 (fivetimes MAX_GAMES).Accomplishment[NUM_ACCOMPLISHMENTS]AccompList of accomplishments, of a[TEXT_ACCOMPLISHMENT—type described below.LENGTH]

TABLE 5ImageT FormatNameTypeCommentsImageHeaderHeaderContains the standard headerstructures for a DIB file(corresponds to the standardBITMAPFILEHEADER andthe BITMAPINFOHEADER inthe Windows DIB format).ImageTable(sizeof(Color)*Uint8The color table for the image.NUM_COLOR_INDEX)uImage[LENGTH—Uint8This contains the data for anIMAGE_SIDE{circumflex over ( )}2]image.

The accomplishments type “Accomp” might be further divided as indicated in Table 6.

TABLE 6Accomp FormatNameTypeCommentsstrAccomplishmentTitle[TEXT—CharWhat the accomplishment is.ACCOMPLISHMENT—(alphanumeric)LENGTH + 1]DateAwardedTimeDate accomplishmentoccurred.uAccomplishmentValueUint8Value of accomplishment. Avalue of 0 indicates an invalidaccomplishment. An examplerange might be from 0 to 250.

The individual product accomplishment array can have up to NUM_ACCOMPLISHMENTS (32, for example) accomplishments per product saved off as text strings (potentially two separate arrays for major and recent accomplishments). For the two arrays, the top five or so accomplishments in terms of value are kept and, while preserving the top five, the oldest accomplishment is overwritten with the new one. That way both the “Major Accomplishments” and the “Recent Accomplishments” can be displayed. Example:Name=“Madden NFL 2004”AccompBio=0−31AccompText=“Aug. 16, 2003—Won the Super Bowl in Franchise Mode”AccompValue=20AccompDate=Aug. 16, 2003 11:43:02 pm

The Individual Product Reward Array can have up to NUM_REWARDS (32, for example) unlockable rewards per product. This data can be product specific and need not be supported by each product. Each game can set up its own rewards and criteria. Example:Name=“Madden NFL 2004”RewardBio=0−31RewardLevel=2RewardUnlocked=FALSE

The RewardUnlocked field indicates whether the user has rewards waiting in another game.

Some products may have severe memory constraints and may not want to store the full text of an accomplishment in memory. They may prefer to use their own proprietary mechanism to store this text. An example mechanism for dealing with this is: each product specifies how many bytes to allocate for the accomplishment string. If this is less than the default, the text is considered “packed”. Products that choose to use packed accomplishment text will also provide an unpack callback. This unpack callback will convert the packed text into the unpacked text. This unpack callback will be called while merging the data in memory and the data on the card (when more memory is available). This merge will take place automatically if needed when a “load product data” function is called by the product. When an accomplishment occurs, the product will call a “set accomplishment” function with the packed data as one of the parameters.

Shared game state files allow for features such as a “game player bio” that represents a player's accomplishments and other details over multiple games. Thus, when a player reaches a level of accomplishment in one game, it can affect the player's interaction with another game, such as by providing access to additional features, levels or the like.

In each game that supports a shared game state, it might provide a menu item where the player can look at the contents of his or her bio file. This might include individual product accomplishments as well as an overall level, view basic product statistics, global EA Sports statistics, and reward information for each product listed. At any given level, each individual product can choose to unlock its own special rewards. As the user gains experience and plays more titles, he or she is rewarded with unlockables in each of the games found in the bio file.

The first time a user completes an accomplishment and has a valid storage device, the game might ask to create a bio file. In game device14where saved files are specific to, and can be accessed only by, the game ID that created the saved file, a game might include a “shared” game ID for use in accessing (reading/writing/modifying) the shared game data file. As the first title writes data, the shared access file is stamped with this shared game ID.

Where the number of distinct games for which a bio can track is limited, older games (in terms of when the user last played them) can be removed, but overall levels or experience values might remain.

Examples of statistics saved for games include time logged, last date played, and recent accomplishments (such as game-dependent text strings that get saved when accomplishments are made). To allow for a current game to display icons for each of the prior games referenced in the bio file, each game that adds a new entry in the shared file will also include an image file representing that game. That way, each game need not include icons for all other possible games that could be in the bio.

Examples of screens presented to the user are shown inFIGS. 10–11. The product listing screen shows basic statistics that are a combination of all of the statistics from each game in a bio file. In one embodiment, a bio file corresponds to information in shared game state file402. The information displayed on this screen includes sports level, number of sports titles played, the total sports game time, and a listing of each product in the bio file.

The sports level might be a number calculated based on the number of sports titles played and the sports game time. As shown inFIG. 9, the logic for interfacing with the shared game data file can be separate from the main game logic, to allow for different development paths. This separate logic might include the actual formula for calculating the level. An example formula is that each game can add five levels to the overall level and playing a game for some number of hours (such as five hours) increases the level that that game awards. Thus, a user can play a game for 25 hours of total game time to get to a level five for that game. To get beyond five levels, the user would have to play another game and gain experience there. In some variations, the total game time determines the level, but it is limited based on the games. In that variation, a user who played 50 hours on one game would be at a level 5 until playing another game (and saving it to his or her bio file), at which point the user would get to level 10. Preferably, even if a game is removed from the bio file to make room for newer games, the levels achieved through the removed games are not lost. Even if the number of games storable in a bio is limited, a count of the total games ever played and stored and the total sum of all the hours played might be tracked in the bio file. If that is the case, then the total play time might not be a sum of the play time for all of the games currently listed in the bio file.

The basic information stored for a game might include the product listing as well as the “box art” of the game. When the user highlights one of the game titles in a display, the box art would show, as illustrated inFIG. 10by box art image1050. This box art is copied to the shared bio file from the game media for the game represented by the box art, so that other games can display the logo for it without those games needing to be loaded. In one embodiment, box art image1050is an 8-bit image with resolution of 128 by 128 pixels. To save some space, some of the box art might be deleted from the bio file or not loaded, but the statistics saved. For example, where up to 50 game entries are stored in a bio file, the box art might be limited to the most recent 25 games. In some instances, no box art is stored. Where an image is to be displayed for a game having an entry but no box art, a generic image might be displayed, such as an “EA Sports” logo.

As shown inFIG. 10, a bio listing on one game might indicate (e.g., star icon1060of the right side of the title listings) that awards are pending in another game, thus prompting the user to go back and play a game not recently played.

FIG. 11illustrates a product summary screen according to one embodiment of the present invention. This summary information can be open-ended so there would be no need for title specific features or data. Interesting statistics tracked for each product might be chosen because they work across multiple sports, such as those shown in Table 7.

TABLE 7ItemDescriptionHoursThis is the total of the time spent within this specific title.LoggedIt is up to each title to determine what time gets counted.Last DateThis was the last date the user played the selected title.PlayedRewardsThis lists the number of awards that have been unlocked asUnlockedwell as the number of new rewards that are waiting.Next RewardThis lists the level the player needs to get to unlock thenext reward.
Accomplishments

Accomplishments can be anything each product desires. Each product can implement its own set of accomplishments and the hooks that trigger them. As the user completes an accomplishment, he or she might receive a message stating the accomplishment that was achieved, with the ability to update (save) the user's bio file.

In some embodiments, accomplishments are divided into major accomplishments and recent accomplishments, where major accomplishments are the last N (where N=5 or another number) highest ranking accomplishments. These accomplishments should be sorted by accomplishment value in descending order. Recent accomplishments are the M (M=27 or some other number) most recent accomplishments. These should be sorted by accomplishment date from the most recent.

Examples of accomplishments for Title A include those shown in Table 8.

TABLE 8Accomplishment HookValueText StringFranchise - 30 years255Completed 30-year coaching careerFranchise - Four Champs200Won four consecutive Super BowlsFranchise - World Champs125Won the Super Bowl

Examples of accomplishments for Title B include those shown in Table 9.

TABLE 9Accomplishment HookValueText StringDynasty - 60 years255Completed 60-year coaching careerDynasty - Four Champs200Won four consecutive National ChampionshipsDynasty - Three Champs175Won three consecutive National ChampionshipsDynasty - Two Champs150Won back to back National ChampionshipsDynasty - National Champs125Won the National ChampionshipDynasty - Coach110Won Coach of the YearDynasty - Heisman100Won the Heisman Memorial TrophyDynasty - Recruiting90Landed the #1 recruiting class in the nationDynasty - Conference75Won Conference ChampionshipDynasty - Bowl Win60Won a bowl gameDynasty - Bowl Bid40Earned a bid to play in a bowl gameAny - Defeated #125Defeated #1 team in the nationAny - Defeated Rival5Defeated school rivalAny - Team Pts Scored10Broke the single-game record for most points scoredby a teamAny - Team Total Offense10Broke the single-game team record for mosttotal offensive yardsAny - Team Pass Yards10Broke the single-game team record for mostpassing yardsAny - Team Rush Yards10Broke the single-game team record for mostrushing yardsAny - Team Sacks10Broke the single-game team record for mostsacksAny - Team Interceptions10Broke the single-game team record for mostinterceptions
Saving and Loading

As the title is loading, initialization code of the title should search all storage media currently hooked up to game device14and load the most recently saved bio file. If the bio file has a fixed name, a user will only have one bio file present on his or her storage media. Preferably, if no file is found, one is not created automatically. Instead, the bio file should be first created after the user has completed an accomplishment or manually accesses a “bio” menu option, so that bio files are not created when not intended by the user.

As a user completes an accomplishment, the game should prompt the user and allow for a game save, which would update the bio file as well. If the title has an auto-save feature, the auto-save might be triggered after each accomplishment or after each game played. If game code had loaded a bio file and tries to update the same file after completing an accomplishment, the code should verify that the file is still present on the storage device. If the file is there, the user is prompted to overwrite the file using the interface's normal overwrite message. If the file is not found, the user should be prompted to re-insert the memory card containing the bio file. Also, a checksum may be used to correctly identify a user's bio file of when the memory card is removed.

Game Rewards

Each title would be able to set up its own rewards and assign levels to each reward based on the value of the reward. As a game first writes to the bio file, it should store an array that contains each reward along with the level needed to unlock that reward. The title should be responsible for detecting that a reward has been earned and actually presenting that reward although it is recommended that a check be made at boot so that rewards are given immediately.

Examples of rewards include those shown in Table 10.

TABLE 10Reward HookbioLevelUnlock the EA SPORTS team02Sugar Buzz Team14

Accordingly, embodiments of the present inventions provide a shared game state file that is read and written to by multiple game applications for games. Data in the shared game state file is then used by multiple games to affect actions in each game. For example, a first game may use data in a second game to affect actions in the first game.

While the present invention has been described using a particular combination of hardware and software implemented in the form of control logic, it should be recognized that other combinations of hardware and software are also within the scope of the present invention. The present invention may be implemented only in hardware, or only in software, or using combinations thereof.

The above description is illustrative but not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.