Networked computer game system with persistent playing objects6009458Abstract The mapping of playing objects from one game to another. In one embodiment, generic attributes of an object may be mapped to game-specific attributes. The mapping may either change or maintain the look and feel of an object. For example, a fast but lightly-armed starship in one game may be mapped to a quick but weak warrior in another game. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
______________________________________
"Quickness"
"Power" "Mobility"
attribute attribute
attribute
______________________________________
Super Chess
Range Attack Mobility
War & Peace
speed
Might
Terrain
______________________________________
So, range in Super Chess becomes speed in War & Peace, attack becomes might and mobility translates into terrain traversal ability. Value By mapping attributes appropriately and scaling values accordingly, we are able to preserve the value of a given playing object across games. For instance, we can see that the phlier is a valuable, powerful playing object in both games. Likewise, the simpletron is of average value in both games. Feel Our mapping algorithm mapped the mobility in the chess game to the ability to traverse certain types of terrain. A "mobile" piece such as the phlier, can move in any direction on the chess board, and cross most terrains in the risk game. In this manner we attempt to preserve some sort of intuitive notion of the behavior of a given playing object across games. Obviously, for some games this might be difficult to do. Look By having legacy data that persists across all games and the use of icons, sounds and the like, we attempt to preserve some of the visual aspects of a given playing object across games. D. Value In an embodiment, the different playing objects have a real world value. The value may arise because of at least one of the following factors. 1. Legacy Data. The different playing objects may include a set of data and other aspects referred to herein as "legacy data". The legacy data can remain constant from game to game, or could be varied. The legacy data can be stored with the DNA attributes, or be pointed to by a pointer associated with the DNA attributes. The legacy data can give the playing objects a collectability value, similar the collectability value attached to baseball cards. The legacy data is one aspect that allows a user to develop an emotional attachment to a playing object. 2. Usefulness. The value is also impacted by the effectiveness of the playing object in different games and what the user can do with it. 3. Rarity. The central authority creating playing objects can control rarity by making few playing objects of a given value or with given characteristics. If users are allowed to replicate, mutate, recombine or otherwise alter their DNA, limitations could be placed on this ability to preserve rarity. Note that none of the above three factors controls the real world value of a playing object. In practice, the real world value of a playing object may be determined by users interacting with each other in a real world marketplace for playing objects. The marketplace facility described below facilitates such a real world marketplace by providing a (non-exclusive) forum. E. Playing Object Database FIG. 5 illustrates the format in one embodiment where a database facility maintains the association of playing objects with individual users. Specifically, a table 502 contains a column of user Ids in correspondence with a column of pointers to respective lists of playing objects which are associated with each user ID. It will be appreciated that while the system associates playing objects with individual users, it does so only by user ID number; the "user", as the term is used herein, can in actuality comprise a group of users which are represented in the database facility by a single user ID. The table 502 contains a row corresponding to each user ID. In row 504, the user ID column contains the identification number for user #1 and the pointer column contains a pointer 506 to a list 508 of identifiers for the playing objects which are associated with user #1. The list contains the identifiers (DNA #) for a playing object 510, a playing object 512, and so on. Similarly, a row 514 in the table 502 contains the identification number and pointer of user #2. The table 502 also may contain rows with a pointer to a list of identifiers of playing objects which are not then associated with any user. The playing objects on such a list are available for acquisition by users. All of the playing objects whose identifiers are included on any of the lists which are referred to in FIG. 5, make up the universe of playing objects which exist at any one time and are usable in the games supported by the gaming facility. A further breakdown of the data stored for playing object 510, with its given DNA serial number is set forth in list 516 in FIG. 5. This list includes generic DNA data 518 and game specific DNA data, such as data 520 for game number 1. The components of this data are shown in more detail in FIG. 6. As is shown in FIG. 6, the generic DNA 518 is a block of data which includes attributes 1-P, and state data 522. An example of the data for attribute number 1, block 524, is shown as including a class 526 of the attribute, its value 528, its importance 530, and its range 532. Additional or different aspects may also be included. The class attribute 526 might indicate, for example, membership in a race class as either Human, Klingon, Vulcan, etc. A value 528 is typically a numeric quantity within a range, such as indicating a strength between 0 and 1000. The importance block 530 can be used to identify the importance of the attribute, and may be used by a mapping function to identify similar attributes or classify attributes. The tolerance 532 specifies acceptable values for the attribute, and could also be used by a mapping function to identify similar attributes. The actual location of the attribute values may vary. For instance, in one example, all the data may be maintained on a central game facility, rather than at the user's computer. Alternately, a DNA serial number associated with the user's ID may be all that is stored on the central gaming facility, with the rest of the data being stored on a CD ROM or other storage device at the user's computer or access terminal. This would allow a peer-to-peer game, for example, without contacting a central server, except perhaps for a game authorization code, which could be obtained in advance. In addition, portions of data may be shared by playing objects. Game DNA 520 may also be present in a number of different places and forms. In one embodiment, it is not stored at all, but a mapping function is provided either at the game facility, internally to the game, or at the user's site. The mapping could be done each time from the generic attributes, with the mapped characteristics being discarded after the game is completed. Alternately, the mapped values can be stored after the mapping function has been calculated, such as in a list 540 corresponding to game number 1 data 520. That list could have the ultimate values 1-Q determined for each of the attributes used in that game. Finally, state data 522 associated with each user would include data which is not specific to or mapped to any particular game. That would include the user ID 542, an optional date of last use 544, or other fields. In addition, legacy data 546 would contain the information provided on the display setting forth a description of a particular playing object. F. Mapping 1. General Mapping Algorithm. In general, any mapping scheme may be used, including one which inverts or otherwise modifies the value of playing objects, or modifies their look and feel. In one embodiment, a mapping scheme which preserves the playing object's relative value is used. In addition, it is preferable to also maintain the look and feel (value and "look and feel" are not the same, since the overall value could be the same, with individual attributes varied to give a different look and feel). There can be a one-to-one mapping, or one playing object can be mapped into many, such as a race car driver in one game becoming multiple elements of ammunition in another. In another example, many playing objects can be mapped into one playing object or a different number of playing objects. Alternately, a playing object could be mapped into a manager of playing objects, such as a commander of a starship fleet. The mapping may be done in any location and at any time. The central server may do the mapping, or the user may have a mapping algorithm stored locally for its playing objects. The mapping could be done at the central server for all available games at the time of creation of the playing object. In one preferred embodiment, the games include the mapping algorithm. The mapping may be done before the game is begun, with mapping results stored with the generic DNA of the playing object, as illustrated in FIGS. 5 and 6. The game may prompt the user to provide an input of the generic playing object, or the user may simply provide a user ID, with the game then accessing the central server or the user's memory for the stored generic DNA, or previously translated game-specific DNA. Any mapping algorithm may be used, such as a proportional mapping, a boolean mapping, a greater than or less than test, a combination of the above, etc. FIG. 7 is a flow chart illustrating the steps performed in the embodiment described herein for mapping a playing object for use in a specific game. In Step 702, the generic DNA data is fetched by the game program. In one embodiment, the game designer knows what the DNA attributes are and where they are stored in the generic DNA data structure. Thus, the program can simply fetch certain predesignated locations. Alternately, a game can be made more dynamic, and look for attributes having a certain type tag (i.e., speed), as set forth in optional step 704. This also allows forward compatibility to new generic DNA that may have additional or differently located attributes from those in existence when the game was designed. It would also be possible to search for the most closely related attribute if there is not an identical match (optional step 706). This could be done, for example, by looking for attributes in the same class (a movement class could include speed, range, directions; a strength class could include armor, weapons, etc.). Matching attributes are then scaled in step 708 with an importance coefficient or scaling factor which indicates the importance of that attribute in the game (i.e., speed may be more important in a car race game than a boxing game). Non-matching attributes may then be assigned a value in any number of ways (step 710). Game attributes may be given the average value of the generic attributes in the simplest example. Or remaining attributes could be randomly matched or matched by class. Or non matching generic attributes could be separately averaged and mapped to non-matching game specific attributes. A default value could be assigned for each of the attributes which are needed for the game but which are missing from the playing object. Next, the attributes are normalized in step 712 to avoid having the scaling change the overall value, as shown in the example below. The generic attribute classification (i.e., speed) is then associated with the game specific attribute classification (i.e., quickness). Finally, the new game specific attributes are stored in step 714, either with the game data, or with the central server or user data structure as shown in FIGS. 5 and 6. Note that the order of the steps may be varied, different games may use different mapping algorithms, including algorithms different from that shown in FIG. 7. FIG. 8A is an illustrative example of mapping for three attributes of generic DNA 802 listed in table 804. The three attribute values for traits A, B, and C are provided to a specific game, Game 1, in step 806. The mapping occurs in step 808 to the game specific DNA structure 810. As can be seen, trait A is simply multiplied by an importance coefficient, or scaling factor, of 10. Trait B is tested to see if it is greater than 0.5 to determine a class Y for Game 1, which is one of two classes, male or female. A characteristic Z of Game 1 is determined by a combination of the value of trait A and trait C, scaled by a scaling factor of 10. The resulting characteristics of a playing object for Game 1 are stored in a table 812. FIG. 8B is a flow chart illustrating how a new generic DNA, with attributes that do not match those of existing playing objects, can be mapped to the existing attributes. A new generic DNA 814, with new speed attribute 816 and strength attribute 818 is provided to a game 1 mapping process 820. In step 822, the nearest DNA class is determined. This can be understood by reference to FIG. 8C, which is a graph of strength vs. speed showing the new generic DNA and four playing objects, 824, 826, 828 and 830. The playing objects have their closest attributes to strength and speed mapped to strength and speed. For example, the playing objects might be chess pieces, with 828 being a rook and 830 being a bishop. For this example, the number of directions of movement could be mapped into strength, and the distance of movement could be mapped into speed. With this mapping into the generic attribute space (speed and strength), the type of playing object most closely matching the new generic DNA attributes can be determined by comparing strength and speed values to see which is closest, or, where a range is specified, which playing objects range the generic DNA falls within. Alternately, the mapping could be done in the game specific space (directions and distance), with the generic strength and speed being mapped into directions and distance first. This mapping could be done, for instance, by any number of algorithms or tags which would relate strength and direction, for instance. 2. Scaling and Normalization. An example of the scaling step, showing why normalization is needed, will now be described for a case in which each playing object has only two attributes (SPEED and WEAPONS). Two games will be assumed, namely a race car game (game #1 and a fighting game (game #2). In this case, the intrinsic value (IV) of two playing objects A and B are defined as follows : IV.sub.A =(SPEED.sub.A +WEAPONS.sub.A)/2 IV.sub.B =(SPEED.sub.B +WEAPONS.sub.B)/2 In Game 1, SPEED, which is called `velocity` in the game's parlance, is expressed as being 1.5 times as important as WEAPONS, which are called `guns`. In Game 2, WEAPONS, which are called `swords`, are 2.5 times as important as SPEED, which is called `responsiveness`. Then in Game 1, A and B's values are mapped to the game-specific value (V) as follows: V.sub.A =(1.5(SPEED.sub.A)+WEAPONS.sub.A)/2.5 V.sub.B =(1.5(SPEED.sub.B)+WEAPONS.sub.B)/2.5 Relative values of A and B are next restored ("normalized") by multiplying SPEED.sub.A and WEAPONS.sub.A by a factor that makes the revised V.sub.A =IV.sub.A, and by multiplying SPEED.sub.B and WEAPONS.sub.B by a different factor that makes the revised V.sub.B =IV.sub.B. The proper factors are: F.sub.A =IV.sub.A /V.sub.A F.sub.B =IV.sub.B /V.sub.B To create a specific example, let: SPEED.sub.A =100, WEAPONS.sub.A =500, SPEED.sub.B =400 WEAPONS.sub.B,=100. This yields intrinsic values of IV.sub.A =300 and IV.sub.B =250. In Game 1, substituting yields V.sub.A =260 and V.sub.B =280. Thus playing object A is intrinsically more valuable than playing object B but due to scaling, its valuation is less than that of B in Game 1 without normalization. This is because a particular attribute has been scaled to such an extent that it changes the overall relative value of the playing object. So, in order to maintain relative value, we calculate the normalization factors and apply them: F.sub.A =300/260 F.sub.B =250/280 Velocity.sub.A =115.38 Guns.sub.A.sub. =576.92 Velocity.sub.B =357.14 Guns.sub.B =89.29 So we see that playing object A remains more valuable than playing object B in game 1 but that it also retains its feel of being slow and well armed. Playing object B remains less valuable than playing object A and retains its feel of being fast and lightly armed. In Game 2, A and B's valuations prior to normalization are: V.sub.A =(SPEED.sub.A +2.5(WEAPONS.sub.A))/3.5 V.sub.B =(SPEED.sub.B +2.5(WEAPONS.sub.B))/3.5 In our specific example: V.sub.A =385.71 V.sub.B =185.71 Here A has a greater valuation than B in Game 2 before normalizing but its valuation is too much greater. So applying the normalization formulas: F.sub.A =300/385.71 F.sub.B =250/185.71 Responsiveness.sub.A =77.78 swords.sub.A =311.11 responsiveness.sub.B =538.47 swords.sub.B =134.62 Note that the normalization factors change depending on the game. However, in Game 2, A is still the slower, more heavily armed playing object and B is still the faster, more lightly armed playing object. And, the normalization preserves the relative value of the two playing objects. 3. Forward and Backward Compatibility. As mentioned, an embodiment of the invention can fill in default values for attributes which are used by a game but not included in the playing object. In the above mapping algorithm, the value for each missing playing object attribute is given the value that is the intrinsic value of that playing object. Thus the intrinsic value of the playing object, being an average, is unchanged and its worth in the undefined attributes are comparable to the overall worth of the playing object. For example, using the playing object A above with a new attribute of STRENGTH that was defined after the creation of playing object A, then the new game would set STRENGTH=300 for playing object A. It would then go through its standard normalization procedure as described above to set the game-specific values for each of the attributes. If on the other hand a new playing object is brought into an old game which does not recognize all of the attributes in the new playing object, the object's "extra" attributes can be ignored or can be averaged into the values of the attributes that are used by the game. Mathematically, since the intrinsic value of the playing object should remain the same, the system multiplies the values of the attributes that are used by the game by the ratio of the true intrinsic value divided by the average of the used attributes. In fact, this is exactly the above-described normalization algorithm where the relative value of the new attributes is considered to be 0. For example, let playing object C have the following attributes: SPEED.sub.C =100 WEAPONS.sub.C =500 STRENGTH.sub.C =450; and hence IV.sub.C =350 Then if playing object C is used in Game 1 described above whose valuation formula is: V=(1.5(SPEED)+WEAPONS)/2.5, then the normalization factor for this playing object in the game is: F.sub.C =350/260 This yields game play values of: Velocity.sub.c =134.62 Guns.sub.c =673.08 Note that playing object C has the same values for the attributes of SPEED and WEAPONS as does playing object A in the Game 1 example above. However, because the value of its STRENGTH attribute is greater than its intrinsic value, playing object C has both higher velocity and higher guns capability than does playing object A within Game 1. The above procedure works the same whether the playing object has new attributes and the game was written before the new attributes were defined or if the game is merely designed to utilize a subset of the DNA attributes. Hence, game designers do not need to figure out how to map all numeric attributes into meaningful capabilities, thereby lessening the constraints of game design. 4. Preferred Game Design Mapping Guidelines Preferably, each game will map a basic set of generic attributes to similar attributes to maintain look and feel, rather than simply assign an overall average value. Some playing object attributes are numeric values, whereas others define membership in a class (such as race). The values of all of the numeric attributes preferably range over the same scale and hence are comparable. It is desirable (but not essential) that games be designed such that only the numerically defined attributes provide differential value to the playing object. For example, a game designer preferably should not use a RACE attribute as a modifier to a numerically defined attribute such as STRENGTH. Another desirable (but not essential) feature of playing objects is that there be no inherent higher worth of one numerically defined attribute over another numerically defined attribute. In this situation, an "intrinsic value" of a particular playing object can be expressed as the average (or the sum) of the values of all of its numeric attributes. A playing object with a higher "intrinsic value" means that it "tends" to provide the player with a greater probability of a favorable outcome in a game or an event in a game, all other factors being equal. Such other factors might include game play choices, reaction time, all other playing objects in play, and so on. Also, in one embodiment, the rarity of playing objects is controlled such that the higher the intrinsic value, the more rare the playing object. Note that in some situations the above mapping algorithm will not faithfully preserve the feel of the playing object. This can happen for playing objects that are terribly unbalanced in their attribute values. Playing object designers can avoid this problem by not creating playing objects where the feel is concentrated into a single attribute. Part of meeting this goal would be to create a sufficiently rich set of attributes that they are expressive of subtlety. Game designers preferably also practice certain procedures to make good use of the value preserving algorithm. For example, it is desirable that games try to balance many attributes in the game play. This will let the algorithm give the user a real sense of preservation of both feel and value of the DNA. As another example, it is desirable that the game as much as possible makes use of the specific capability values that the algorithm has calculated. That is, it should avoid merely testing numeric values to see if it is greater or less than some fixed value. As another example, when comparing the numeric values of attributes in opposing playing objects to calculate the outcome of an event in a game, it is desirable that the ratio of two values be used and not the difference between the two values. Since the algorithm is performing its actions as a resealing, it is preserving the relative value between two attributes in their ratio, but not in their difference. Note further that the algorithm as described above is based on a simple linear transformation of the attribute values in order to compute the valuation function for the game. In other embodiments, any valuation function can be used if it is the sum of functions for each individual attribute and that the individual attribute functions are invertible. The only feature that is lost if the individual attribute functions are not linear is that there is no denominator that allows for normalization of the valuation function. However, normalization of the valuation function is a convenience to the game designer, not a requirement of the algorithm. The algorithm also can be extended to support randomization in order to make a game be less predictable from one instantiation to the next. Preferably all such randomization is limited in range such that the overall feel of the playing object remains substantially constant. Intentional enhancement/degradation of the value of specific attributes can also be employed by the game designer. Again, however, it is desirable that such modifications be limited so as to preserve the overall feel of the playing object. Although the algorithm does an automated mapping of generic playing objects into game-specific playing objects, the game designer may wish to "special case" certain playing objects. Including code that performs a particular mapping based on a particular playing object's unique identification is outside of, and in addition to, the above algorithm. G. User Hardware Example Returning again to FIG. 1, the server 102 and the two clients 106 and 108 each include both hardware and software. In each case, the hardware can be any general purpose computer since no specific hardware platform is required. Alternately, other displays could be used, such as a network box, a dumb terminal, or a television. To aid understanding, however, FIG. 9 illustrates a typical hardware computer system platform on which the software might run for a client or server. The hardware platform of FIG. 9 comprises a CPU 902, a memory subsystem 904, a storage subsystem 906, a display subsystem 908, a sound subsystem 910, and a network connection 912. These components are all shown connected to a single CPU 902, but it will be understood that in other embodiments, the CPU 902 can be replaced by two or more CPUs coupled together via one or more buses. Connected to the storage subsystem 906 is a CD-ROM drive 916, a hard disk drive (HDD) 918, and a floppy disk drive (FDD) 920. Other storage units might also be included, such as PCMIA cards or tape drives. The memory subsystem 904 includes main memory, one or more levels of cache memory, and optionally a memory management unit. The display subsystem 908 includes a video monitor and the necessary driver hardware, as well as optionally graphics rendering hardware. Alternately, a television or monitor could be used. The sound subsystem 910 includes a speaker system together with appropriate amplifiers and driver hardware. The network connection 912 includes whatever hardware the system uses to connect to the network, such as a modem. In one embodiment, the graphics of a particular program or game are stored on one of the user's memory devices, while the connection to the network over network connector 912 allows interaction with a central server or other users, such as for the graphics of an opposing player's movements. Whereas FIG. 9 illustrates a single computer system, it will be understood that the server 102 and/or the clients 106 and 108 can be made up of any "computer system structure". As used herein, a computer system structure can include one or more CPUs and/or other processors, can include parallel processors, distributed processors distributed locally or across a network, and so on. FIG. 10 is a block diagram of the software architecture of the server 102. It comprises a user interface facility 402, a database facility 404, a marketplace facility 406, and a gaming facility 408. A financial processing facility may also be included. The user interface facility 402 connects to the network 104, and provides the environment in which a user initially finds him or herself upon connecting to the server 102. The user interface facility 402 provides a number of services to users, one of which is to allow different users to rendezvous with each other, choosing teams or opponents, and selecting a game to play (if the server 102 supports more than one game). Once a game and a group of players are selected, the user interface facility 402 communicates this information to the gaming facility 408, which conducts the specified game among the specified users. As shown in FIG. 10, the gaming facility 408 is programmed to conduct a number of different games. Specifically, game #1 facility 410 conducts a first game, and game #2 facility 412 conducts a second game. As used herein, the term "facility" is merely a logical concept. In one embodiment, each of the facilities illustrated in FIG. 10 consists of software running on corresponding respective hardware computer systems, all of which are part of the central server 102 (FIG. 1). In another embodiment, all of the facilities illustrated in FIG. 10 represent separate software modules or tasks, all running on a single computer system platform with a single CPU. In yet another embodiment, the individual facilities illustrated in FIG. 10 are all integrated into a single overall software program running on one or more CPUs, but undifferentiated as individual software modules. Alternately, a distributed processing system could be used instead of a single central server. The gaming facility 408 conducts games with reference to playing objects which have been associated with the individual users. The database facility 404 maintains the association between users and playing objects. The marketplace facility 406 allows users to manipulate these associations in a number of ways. For example, if a user acquires a CD-ROM from a retail outlet, the CD-ROM may entitle the user to a certain number of playing objects stored on a central server by providing an appropriate verification, such as a password. Alternately, the CD-ROM may contain the identities of a number of playing objects, or even the DNA data for the playing objects, and the user can register these playing objects with the server 102 by inserting the CD-ROM into the user's client 106 or 108 and interacting with the marketplace facility 406 on the server 102. The marketplace facility records the new association between the user and the new playing objects, using the database facility 404. As another example, a user can acquire new playing objects on-line from a central authority using the marketplace facility 406. In one embodiment, the user legally owns the playing objects which he or she acquires on-line through the marketplace facility 406. In another embodiment, the user merely licenses the playing objects which he or she acquires on-line. In either case, the system may require the payment of money or an obligation to pay money in the future to the central authority in return for acquisition of a playing object. As another example, users may have the marketplace facility 406 transfer the association of a playing object from one user to another, with or without compensation, or can have the marketplace facility trade playing objects among users. In an embodiment, the marketplace facility is accessible from inside games as well as from outside the games. The database facility 404 may implement the tables and lists of FIGS. 5 and 6 using standard relational database management software or any other suitable software. In addition, the database facility 404 can also perform other functions such as maintaining an accounting or a line of credit for each user; maintaining high-score records by user and/or by game; maintaining user passwords and authenticating signatures (digital or otherwise) for playing objects to be registered on the server; maintaining user demographic information; maintaining statistical data; maintaining handicaps for individual users; recording persistent modifications to playing objects resulting from game play; and disallowing the use of a playing object in a particular game session in accordance with exclusion criteria which were predefined for the playing object upon acquisition. H. Marketplace Architecture FIG. 11 is a flowchart illustrating one embodiment of the software supporting one embodiment of the marketplace used by the present invention. In a step 1010, a user can post a listing offering to buy, sell or trade particular playing objects which that user owns or is looking to acquire. A second user can view the listings in a step 1012. In a step 1014, the second user can make an offer to buy, sell or trade, which is then either posted or sent directly to user #1, who can then view it and respond, as indicated in step 1016. The two users can exchange messages with offers and counter-offers until both agree upon a particular exchange of playing objects for other playing objects or value (i.e., a charge to an on-line credit card account). Once agreed upon, user #1 in step 1018 transmits to the central gaming facility the agreed upon exchange of playing objects for both sides and the value for both sides, where applicable, along with the user ID for the playing objects owned by user #1. Similarly, user #2 in step 1020 transmits the same information on the agreed upon exchange, along with its ID number for the playing objects which it owns. The central gaming facility, in a step 1022, will determine whether the agreed upon exchange matches between the two messages. In addition, it determines whether each user indeed has ownership of the playing objects it intends to exchange by comparing the user ID numbers submitted to those associated with the playing objects in its database. If either of the IDs do not show ownership, or the agreed exchange descriptions don't match, an error message is returned (block 1024). If there is a match, the central database is updated to switch the playing objects to the appropriate user Ids in accordance with the exchange as set forth in step 1026. The marketplace could be implemented in alternate ways. For example, each user could have a marketplace program, with only playing object identities and bids being sent to another user in a peer-to-peer arrangement. In another embodiment, the marketplace could be conducted within a game. I. User Interface Facility (Example Screens) The following example of one embodiment of certain portions of the user interface will help illustrate the operation of the invention. Effectively, a menu-based system is implemented for the initial set of screens, allowing the user to navigate through various menus which are linked together by hypertext link. These menus, or screens, are described below. When a client such as 106 logs onto the server 102, it communicates initially with the user interface facility 402. The user interface facility first requests the user's identity from the client 106, or, for a new user, prompts the user to establish a user identity. Introductory Screen When the client (106, for example) first connects to the central server 102, the user interface facility 402 displays an introductory screen. This screen has registration forms for playing the games' supported by the system, order forms for acquiring products for use in or related to the system or its games, and a link to a system login screen. System Log-In Screen A system log-in screen lets newcomers view the available games and download demonstration versions to the client. For an example game described in more detail below, the demonstration version includes pre-generated characters and playing object decks. Authorized users with a valid character (Playing Object) can go directly to the Chat Room to find opponents. Main functions: 1. GAME VIEWER 2. DOWNLOAD BUTTON 3. Links to registration and order forms 4. Links to each of the available games 5. Link to central authority's home page 6. Link to Character Creator 7. Link to Playing Object Viewer 8. Link to Chat Room Playing Object Viewer This screen lets the user examine the user's playing objects and see how they work in the available games. The default view is the "Master Playing Object" that is external to (and generic to) the games themselves. This view presents the playing object in the game-generic form described above. At the bottom of the screen are icon buttons, one for each of the available games. Selecting an icon changes the playing object picture and description, showing how the object appears and is used in that game. This screen can be used in conjunction with a Deck Builder screen for a particular game to create the play decks. Main functions: 1. GAME ICON BUTTONS 2. PREVIOUS BUTTON 3. Link to Deck Builder 4. Link to Character Creator 5. Link to Chat Room 6. Link to Game Options Chat Room This area serves a number of uses in the system including discussing playing object sales and challenging other users to play or compete. Main functions: 1. USER CHAT BUTTONS 2. Link to Character Creator 3. Link to Save/Load Character 4. Link to Trade Room 5. Link to Bulletin Boards 6. Link to Hall of Fame 7. Link to Challenge 8. Link to Game Options 9. Link to Introductory Screen for particular game Trade Room Users who wish to sell, trade or give away playing objects use this screen, which is managed by marketplace facility 406. All transactions are conducted privately via user interaction. Finalized trades are registered with the server 102 and the database facility 404 enters the trade into the master user database. Main functions: 1. PLAYING OBJECT AUCTION 2. PLAYING OBJECT TRADE 3. REGISTER PLAYING OBJECT TRANSFER BUTTON 4. Link to Chat Room 5. Link to Character Creator 6. Link to Save/Load Character 7. Link to Game Options Bulletin Boards The user interface facility 402 supports a number of bulletin boards on which users can post messages. Halls of Fame This screen shows the top ten ranked users and clubs. J. Gaming Facility The gaming facilities 410 and 412 are implemented as additional clients of the user interface facility 402. The act of launching a game therefore does not require clients such as 106 to disconnect from the user interface facility 402. Launching a new game is accomplished by sending a message to a game facility indicating that it should launch a new game instantiation with a list of the identities of all the players. While a group of users are playing a game, the public game flow control traffic from the game facility to the clients may be directed through the user interface facility 402 via a communications channel which is similar to an Internet Relay Chat (IRC) channel. In this way, observers can join the channel to watch the traffic. Player chat traffic may be directed through a second IRC-like channel, which the user interface facility 402 could repeat on the first channel so that observers can see the player chat, but not vice versa. Alternately, the observers may chat with the players. Private information (i.e., game control information) could be exchanged between clients and the gaming facility 408 directly, rather than via an IRC channel. A running game facility 408 manages all instantiations of a given game. It knows which users are players in the instantiation, and executes game commands from them. It notifies all interested parties (including both players and observers) of game events by multicasting through the user interface facility 402. When the game facility launches an instantiation, it registers its identity as a game facility with the user interface facility 402, specifying what multicast channels it intends to use to notify players and observers of game events. During game play, the game facility may communicate information with the database facility 404 via the user interface facility 402, regarding game events which have persistent effects on users' profile or on playing objects. At a minimum, the database facility 404 is notified of the outcome of the game instantiation. K. Modification of Generic Playing Object Value In one embodiment, the value of a playing object may be modified (permanently or for a period of time) as a result of activity in a game, such as injuries impacting a playing object's health. Alternately, the playing object may be lost altogether, such as by dying or being captured by another user. As mentioned, playing objects are represented in the system of FIG. 1 as a collection of attributes, each of which has a value. A persistent change in the health of a playing object is represented by a persistent change in one or more of the values in the playing object. When this occurs, referring back to FIG. 10, a particular game facility 410 communicates the information to the database facility 404 for recording. In an embodiment in which the mapping of playing objects to game-specific objects includes temporary weighting of attribute values according to game-specific importance values (as described in more detail below), the system performs an appropriate reverse mapping in order to determine the correct modification to be made to the values in the generic representation of the playing object as maintained in the database facility 404. Also, at an appropriate time, if the playing object exists in part at the client 106, the system 102 downloads the modified playing object onto the client 106 hard disk drive. The values in the hard disk drive copy of the playing object will supersede any that are stored on the user's CD-ROM for purposes of the browser utility (or a version number may be assigned. In alternate embodiments, the CD-ROM contains pre-computed mappings for different games, and the central server could download ten new pre-computed versions of the persistently modified playing object (plus the one generic version), or it could download only the modified generic version, with all game-specific versions thereafter being computed on the fly or as needed. L. Overall Operation of the System--User's Viewpoint FIGS. 12A and 12B (sometimes referred to herein collectively as FIG. 12) is a flow chart illustrating a sample set of activities that a user can perform using the above-described system. Beginning at step 802, the user (referred to as user #1) acquires a CD-ROM from a retail outlet. The CD-ROM contains client software for two games (game #1 and game #2), as well as legacy data and most attribute values for 300 playing objects. These playing objects are represented on the CD-ROM in generic form, as well as in a form pre-computed for game #1 and in a form pre-computed for game #2. Of the 300 playing objects, 240 are locked, leaving the user with an initial set of 60 available playing objects. Also, not all of the attribute values required for game play are present on the CD-ROM; some exist only on the server 102 and are downloaded to the client 106 only during game play. In step 804, user #1 connects to the server 102 via the network 104 and his or her client 106. At this point the user is communicating with the user interface facility 402. After authentication (for example, a user password is verified), the client 106 communicates with the user interface facility 402 and registers the user's initial set of 60 playing objects. At this point the user interface facility 402 communicates with the client 106 and determines that a new game, game #3, is available in the gaming facility 408 but that the client 106 does not yet have the necessary client software. The user interface facility 402 informs the user via the client 106 of the availability of game #3, and asks whether the user would like to download the client software presently. If the user responds affirmatively, then the software is downloaded to the client 106 via the network 104. Pre-computed playing objects may be downloaded at this time as well. In a step 806, user #1 selects a character #1 for use in game #1. In step 808, user #1 builds a deck #1 (i.e. selects a subset of his or her available playing objects) for use in game #1 by character #1. For purposes of this illustration, it is assumed that deck #1 includes 40 playing objects numbered 1-40. While the user could play game #1 solitaire if desired, it is assumed for purposes of FIG. 8 that he or she wishes to play competitively. Therefore, in a step 810, user #1 enters a chat room of the user interface facility 402 and selects opponents for game #1. This information is communicated to the gaming facility 408, and in step 812, the user proceeds to play game #1, in a first instantiation and a first session. Depending on the outcome of the events in the game, one or more of the attribute values in the objects in deck #1 might be persistently modified. One or more attribute values of an object might be persistently modified at this point also due to non-play factors, such as being modified in dependence upon the value of an attribute which is hidden in the playing object. After completion of the game instantiation, in step 814, user #1 acquires additional objects from the central authority by communicating with the marketplace facility 406 via the client 106, the network 104 and the user interface facility 402. In step 816, user #1, still in the marketplace facility 406, acquires additional objects from another user, user #2. In step 818, user #1 trades objects with user #2, and in step 820, user #1 transfers objects to user #2 in return for consideration of some kind. The marketplace facility 406 registers the results of steps 814, 816, 818 and 820 with the database facility 404. In a step 822, user #1 modifies deck #1 by removing playing objects 11-40 and adding playing objects 41-50. User #1 registers the new version of deck #1 with the database facility 404 via the user interface facility 402. In step 824, user #1 selects opponents for a second instantiation of game #1. This information is communicated by the user interface facility 402 to the gaming facility 408. In step 826, user #1 proceeds to play game #1, instantiation #2, session #1, using the modified deck #1. After completion of game #1, instantiation #2, in step 828, user #1 enters the chat rooms in user interface facility 402 again, but this time to select opponents for an instantiation of game #2. (The flow chart of FIG. 12A now continues in FIG. 12B, as indicated by the circled symbol "B" appearing in both figures.) In step 830, user #1 proceeds to play game #2 in a first instantiation, using the same modified deck #1 (including playing objects 1-10 and 41-50). Because of the lateness of the hour, in step 832, user #1 pauses game #2 instantiation #1 and logs off for the evening (step 834). This completes session #1 of instantiation #1 of game #2, at least as far as user #1 is concerned. However, game #2 in one embodiment is designed to allow the remaining players to continue playing even in the absence of user #1. Another embodiment does not permit this. Accordingly, depending on the embodiment, the game #2 instantiation can continue with the remaining players as indicated by dashed step 836 in FIG. 12B. The next morning, user #1 returns and continues playing game #2, instantiation #1 (step 838). At least for user #1, the current session is now considered session #2 of instantiation #1 of game #2. After completion of the game instantiation, in step 840, user #1 builds a new deck of playing objects, deck #2. Deck #2 includes playing objects 6-15 and 41-69. It can be seen that the set of playing objects in deck #2 is not equal to the set of playing objects in deck #1, although some playing objects are common to both decks. In step 841, user #1 begins a new instantiation of game #2, using the new deck #2. The process then continues with steps similar to those previously described. M. Mutation, Replication, Recombination In one embodiment of the invention, the DNA of playing objects can be modified over time, either by a central administrator or the users themselves. The playing objects may simply be duplicated, or they may mutate, replicate, recombine, regenerate, repair, otherwise modify or some combination. For example, multiple playing objects, or simply portions of the DNA from multiple playing objects, could be recombined into one or more different playing objects. The playing object registration system of the present invention allows controls over such modifications of a playing object by a user. A user can be required to register any new playing object before being able to import that playing object into a game. The registration, or verification of earlier registration, could be done as part of the game, or immediately prior to playing a game on the network. Alternately, a user could obtain an authorization code for a peer-to-peer game. In another embodiment, a user can be allowed to create a playing object, with the playing object requiring registration before it can be used in any game. The playing object creation or modification could occur through role-playing or otherwise in a game or other program. N. Playing Object Use Outside Games The playing objects of the present invention, or representations of them, may have an existence outside of any game. As pointed out above, they may be viewed with a browser or traded in a marketplace. They may be represented with cards, action figures, or other physical items. They may be imported into other programs, for example aspects of a playing object (i.e., its legacy data) could become part of a screen saver, or could be used as part of audio-visual addressing in an e-mail program. Alternately, a playing object could be used in an interactive story-telling program. A playing object may be stored on a user's local memory with use authorized in a manner similar to electronic cash (e-cash), with a verification or authorization code, which may be encrypted, allowing use of the playing object independent of any central server. The foregoing description of preferred embodiments of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Obviously, many modifications and variations will be apparent to practitioners skilled in this art. For example, the playing objects could be mapped and traded independently of an electronic network. Also, playing objects might be used in programs that aren't games, such as a video or a teaching program. In addition, mapping could be done without a computer program to generate products with pre-computed game specific playing objects. Alternately, a playing object may be used in different games without any mapping. Programs could be combined or separated in a variety of manners. For example, a separate program could be used for viewing, mapping, or simply selecting playing objects, which are then presented to a separate game or marketplace program. Accordingly, it is intended that the scope of the invention be defined by the following claims and their equivalents.
|
Same subclass Same class Consider this |
||||||||||