US20060089200A1

Movatterモバイル変換

Info

Publication number: US20060089200A1
Application number: US11/228,470
Authority: US
Inventors: Timothy Twerdahl
Original assignee: Inventec Appliances Corp
Current assignee: Inventec Appliances Corp
Priority date: 2004-09-15
Filing date: 2005-09-15
Publication date: 2006-04-27

Abstract

A system for processing game metrics includes a handheld computing device and a game metric server. The handheld computing device captures the game metrics for a game and transfers the game metrics. The game metric server receives the game metrics from the handheld computing device via a computer system and a communication network and processes the game metrics.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No. 60/610,317 filed Sep. 15, 2004 and titled “Systems and Methods for Processing Game Metrics from Handheld Computing Devices” which is incorporated herein by reference.

BACKGROUND

1. Field of the Invention

The present invention relates generally to handheld computing devices, and more particularly to systems and methods for processing game metrics from handheld computing devices.

2. Description of the Prior Art

Video games have historically stored a list of high scores, so gamers can measure their own performance and their performance against other gamers. The list of high scores also provides a sense of competition between gamers and goals for gamers to achieve. Some arcade games are connected to a network, so an aggregate list of high scores can be displayed at each arcade game.

In one example of a video game called Zelda for console games, a user receives a code upon completion of the game. The user could then call an 800 number with the code to win a competition for the first to complete Zelda. Handheld gaming devices also keep high scores for certain games. For some games, a user receives a code from the handheld gaming device. The user then manually enters the code and the score at a website for a certain game. The website can then display a list of high scores for games on the handheld gaming device. One problem with this system is that there is no way to automatically generate a list of high scores for games on handheld devices.

SUMMARY OF THE INVENTION

The invention provides systems and methods for processing game metrics from handheld computing devices. A system for processing game metrics includes a handheld computing device and a game metric server. The handheld computing device captures the game metrics for a game and transfers the game metrics. The game metric server receives the game metrics from the handheld computing device via a computer system and a communication network and processes the game metrics.

The system for processing game metrics from a handheld computing device automatically transfers the game metrics to a game metric server that can manage and share game metrics such as high scores for games. Thus, players with a high score can let the world know of their achievement for a particular game and compare their abilities with other players around the world. Besides simple high scores lists, the system allows for development of time-dependent tournaments and competitive game ladders for games on handheld computing devices.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an illustration of a system for game metrics in an exemplary implementation of the invention;

FIG. 2 is a flowchart for a handheld computing device executing a game metric reporting application programming interface in an exemplary implementation of the invention;

FIG. 3 is a flowchart for a computer system executing conduit software in an exemplary implementation of the invention; and

FIG. 4 is a flowchart for a game metric server executing game metric processing software in an exemplary implementation of the invention.

DETAILED DESCRIPTION OF THE INVENTION

The embodiments discussed herein are illustrative of one example of the present invention. As these embodiments of the present invention are described with reference to illustrations, various modifications or adaptations of the methods and/or specific structures described may become apparent to those skilled in the art. All such modifications, adaptations, or variations that rely upon the teachings of the present invention, and through which these teachings have advanced the art, are considered to be within the spirit and scope of the present invention. Hence, these descriptions and drawings should not be considered in a limiting sense, as it is understood that the present invention is in no way limited to only the embodiments illustrated.

The invention provides systems and methods for processing game metrics from handheld computing devices. Game metrics include any score, measurement, or status that indicates progress in a game. One example of a game metric is a high score for a game. The game metrics are transferred from the handheld computing device to a game metric server that manages and shares high scores for games. Thus, players with a high score can let the world know of their achievement for a particular game and compare their abilities with other players around the world. In one embodiment, the game metric is a type of score that is a 32 bit unsigned integer.

Other examples of game metrics are points, times, goals, and scores for tournaments. Game metrics may be organized by different score types, where each score type is treated as a totally independent score category. In some embodiments, a ‘normalized score’ is not displayed to the user via a high score manager or a website running on the game metric server. A formatted string accompanies each score and is displayed for the user. This provides flexibility to the applications to report scores in various ways such as times, points, kills, or goals. If a combination of variables is important to game play (e.g. best time and most kills and most secrets discovered), then the game can combine these values into one 32-bit value for comparison purposes. The string for the game metric can be formatted to describe different score attributes. The scorer for a given game can be considered to be the registered owner of the device. In some embodiments, there is one date included for each high score record.

FIG. 1 depicts an illustration of asystem100 for game metrics in an exemplary implementation of the invention. Thesystem100 includes ahandheld computing device110, acomputer system120, acommunication network130, and agame metric server140. Thehandheld computing device110 is coupled to thecomputer system120. Thecomputer system120 is coupled to thecommunication network130. Thecommunication network130 is coupled to thegame metric server140. The elements inFIG. 1 can be coupled together by either wired or wireless connections.

Thehandheld computing device110 is any handheld device that includes a processor for executing instructions and is configured to capture the game metrics for a game and transfer the game metrics to thecomputer system120. Some examples of the handheld computing devices are handheld gaming devices, personal digital assistants, and mobile phones. One embodiment of thehandheld computing device110 is the Zodiac gaming device from Tapwave of Mountain View, Calif.

Thehandheld computing device110 includes a game metric reporting Application Programming Interface (API)115. In some embodiments, the gamemetric reporting API115 can be any other type of software program operating in accord with the invention. The operation of thehandheld computing device110 executing the gamemetric reporting API115 is described in further detail below inFIG. 2.

In some embodiments, the gamemetric reporting API115 includes a high score manager configured to store all the high scores for all games on a given device. In some embodiments, each application on thehandheld computing device110 can control how many high scores are saved.

Thecomputer system120 is any computer with a processor for executing instructions and that is configured to transfer game metrics from thehandheld computing device110 to the gamemetric server140 via thecommunication network130. Thecomputer system120 includesconduit software125 for synchronization to transport the data between thehandheld computing device110 and the gamemetric server140. The operation of thecomputer system120 executing theconduit software125 is described in further detail below inFIG. 3. In some embodiments, the conduit software transmits only the highest local score per game and score type to the gamemetric server140.

Thecommunication network130 is any network of communication devices. Some examples of thecomputer network130 are the Internet, PSTN, local area network, and wide area network.

The gamemetric server140 is any system or server configured to receive and process game metrics from thehandheld computing device110. In some embodiments, the gamemetric server140 includes a web front end to sort, filter, and display the high score data. The gamemetric server140 includes gamemetric processing software145. The operation of gamemetric server140 executing the gamemetric processing software145 is described in further detail below inFIG. 4.

FIG. 2 depicts a flowchart for thehandheld computing device110 executing the gamemetric reporting API115 in an exemplary implementation of the invention.FIG. 2 begins instep200. Instep202, thehandheld computing device110 executing the gamemetric reporting API115 captures scores from game software running on thehandheld computing device110.

Instep204, thehandheld computing device110 generates a master record for score type and game. The high score manager also allows each game to include a 32 bit “checksum” value with each score, which can be used to validate that the score was actually achieved during game play, and not simply added to the database using, for example, PalmOS APIs. It would be up to the game developer to decide how to generate and validate the checksum, and conspire with the web site developer to filter scores that fail checksums. Checksums assist with integrity of the game metrics because some game players may be tempted to get higher scores by either hacking the game or hacking the score reporting mechanism.

In some embodiments, all high score data is stored in a single record database, with the records laid out in a 68K (big-endian) format. The high score database can be a record database, with the name “High Scores”, the creatorID ‘twHS’, and the data manager type ‘DATA’. The creatorlD associates the high score database with a dummy “High Score” application, which is embedded in the ROM of thehandheld computing device110, always present, and thus should always allow the conduit software to run. The high score database has an applnfo structure which should contain the following information:



TYPE
(size)	Field Name	Field Description

Int32 (4)	syncWithServer	If non-zero, the conduit should
		attempt connections to the server.
Chars (16)	deviceSerialNum	The 16 digit base-34 device serial
		number, read from the hardware.
		This is just a copy of the serial
		number, and it will be validated (and
		changed if necessary) during normal
		device operations.
UInt32 (4)	serverSyncTimeUTC	Time in seconds since midnight Jan.
		1, 1904 in the UTC time zone that the
		server sync was last completed. 0 if
		never synced.
Char*	Alias	The alias used by the user on the
(var)		Tapwave website, created at
		registration, cached here for use by
		games.

There are two types of records stored in the database, a ‘master’ record for each combination of score type and game, and one ‘score’ record for each saved score. Both the server pool and the local pool use the same record format. Both the master record and score records have the same format for the first 3 fields, which aids sorting.

The database is maintained in sorted order for efficient access. Overall the records are kept sorted by creatorID and scoreType, so that all records for a given game/type combination will sort together. Within this set, the master record is always first (and always present if any scores are present), followed by 0 or more local scores and then 0 or more server scores. The following table illustrates one embodiment for the master record.



Type (Size)	Field Name	Field Description

UInt32 (4)	CreatorID	The unique, registered creatorID of the game.
UInt16 (2)	ScoreType	The arbitrarily chosen type identifier for this
		score.
UInt16 (2)	RecordType	Identifies a master record (and sorts first).
	MASTER_ID = 0
UInt16 (2)	numLocalScoresToKeep	An integer that specifies how many scores to
		keep in the local pool for this game.
UInt16 (2)	numServerScoresToKeep	An integer that specifies how many scores to
		keep in the local pool for this game.
UInt16 (2)	reportScoresToServer	TRUE (1) to report scores to server for this
		game and score type, FALSE(0) to not report
		scores to server.
Char* (var)	GameName	The rest of the record is character data that
		contains the user-visible name of the game for
		the High Score manager.

Instep206, thehandheld computing device110 generates a score record for the saved score. The following table illustrates one embodiment for the score record.



Type (Size)	Field Name	Field Description

UInt32 (4)	CreatorID	The unique, registered creatorID of the game.
UInt16 (2)	ScoreType	The arbitrarily chosen type identifier for this score
UInt16 (2)	RecordType	The record type, 1's for local scores and 2's for
	LOCAL_POOL = 0x1111	server scores. All the local scores come before
	SERVER_POOL = 0x2222	any server scores.
UInt32 (4)	Score	The normalized score value.
UInt32 (4)	Checksum	A checksum, used to validate the score value.
UInt32 (4)	timeAndDateUTC	The date and time that the score was reported, as
		time in seconds since midnight Jan. 1, 1904 in UTC.
Char*	userString	The (null-terminated) string that goes with the
(var)		score. For server scores, the user string is
		prefixed with the alias of the scorer followed by
		the tab character.

Instep208, thehandheld computing device110 stores the master record and the score record for synchronization between thehandheld computing device110 and thecomputer system120. Instep210, thehandheld computing device110 determines whether synchronization is occurring. If there is no synchronization, thehandheld computing device110 proceeds to step214. If synchronization is occurring, thehandheld computing device110 transmits the master record and the score record to thecomputer system120 instep212.FIG. 2 ends instep214.

FIG. 3 depicts a flowchart for thecomputer system120 executing theconduit software125 in an exemplary implementation of the invention.FIG. 3 begins instep300. Instep302, thecomputer system120 executing theconduit software125 determines whether synchronization is occurring between thehandheld computing device110 and thecomputer system120. If synchronization is not occurring, thecomputer system120 proceeds to step318. If synchronization is occurring, thecomputer system120 receives the master record and the score record from thehandheld computing device110. Theconduit software125 transfers all scores from thehandheld computing device110, effectively backing up the high score records. Any records deleted on thehandheld computing device110 will also be deleted on thecomputer system120.

Instep306, thecomputer system120 then determines whether the score from the master record and the score record is the high score. If the highest score for a given master record (game+scoreType combination) is new, then the score needs to be transmitted to the gamemetric server140. If the score is not a high score, thecomputer system120 proceeds to step318.

If the score is a high score, thecomputer system120 then checks whether the sync with server flag is set instep308. Theconduit software125 checks an “opt in” setting stored on thehandheld computing device110. Server connections will only be attempted if the user has enabled them, by setting the appropriate flag on thehandheld computing device110. If the sync with server flag is not set, thecomputer system120 proceeds to step318. If the sync with server flag is set, thecomputer system120 determines whether the server is enabled for a game and score type instep310. If the server is not enabled for a game and score type, thecomputer system120 proceeds to step318.

If the server is enabled for a game and score type, thecomputer system120 determines whether a connection is established to the gamemetric system140 via thecommunication network130 instep312. In some embodiments, the connection to the gamemetric server140 needs to be live during synchronization for the transaction to take place. In one example, if thecomputer system120 is not connected to the Internet at the time of synchronization, or if the server is unresponsive, then the data is not transferred. In this example, the user needs to synchronize again to re-attempt the connection. During ahandheld computing device110 restore, all records should be restored to thehandheld computing device110 during synchronization. In some embodiments, conflict rules are fixed: thehandheld computing device110 overrides thecomputer system120 for game master records and local scores, thecomputer system120 overrides thehandheld computing device110 for server based scores.

If a connection is established, thecomputer system120 transmits the game metrics to the gamemetric server140 instep314. If a connection is not established, thecomputer system120 stores the master record and the score record for future synchronizations instep316.

In one embodiment, the game metrics that are transferred to the gamemetric server140 are in an Uniform Resource Locator (URL) format. In this embodiment, game score submission consists of sending a URL with specified name/value parameters in the query string to the gamemetric server140 that describes a score for a particular game played on the user's device. The server component that handles this request can be a Java Servlet. The Servlet should be written such that either an HTTP Post or HTTP Get message of the specified URL will be handled in the same manner. In other words, the doGet( ) and doPost( ) methods of the Servlet should be written to call the same logic. An exemplary URL and appropriate parameters are described below: Example URL: http://hsupload.tapwave.com/desktop/reportScore/?hardwareID=0T000139C111601J&cr eatorID=0x54574853&scoreType=1001&score=1000&checksum=0x000003e8&recorde d=1067899622000&userString=1000%20points



Name	Data Type	Description

hardwareID	A 16 digit base-34 value	A unique value that identifies the hardware
	“0T000139C111601J”	device. This value comes from the Road
		Dawg hardware ROM.
creatorID	32 bit unsigned hex integer	A 4-byte value that unique defines an
	“0x00000000 . . . 0xFFFFFFFF”	application developer. While this value is
		most likely a 4 letter value (e.g. DOOM,
		ADDR) its representation it is still defined
		as an integer. The CreatorID is also
		assigned by Palm.
scoreType	16 bit unsigned decimal	A value used to define which game type
	integer	this score is associated (used primarily for
	“0 . . . 65535”	game tournaments to identify a score being
		submitted for a tournament).
score	32 bit unsigned decimal	A numerical value that describes a score
	integer	achieved for a particular game.
	“0..4294967295”
checksum	32 bit unsigned hex integer	Used to verify a score was created on a
	“0xFFFFFFFF”	device, rather than a faked score. Currently
		not evaluated on the server.
recorded	64 bit unsigned decimal	A numerical value that defines when the
	Long	high score was achieved on the device.
	“10678996222000”	This value is the number of milliseconds
		since the Epoch (Jan. 1, 1970 00:00:00)
		in GMT.
userString	(escaped) String	Provides a user friendly display format for
	“1000% 20Points”	the high score

Whether or not this is a high score for the game (for this user) is determined by the gamemetric server140. The information is recorded that this particular user has played a particular game and achieved a score. If the gamemetric server140 determines that the score is a high score (for this user) for the game, it will be stored in a high score repository.

The scoreType value will be used to relate a score to a particular tournament being played. The checksum value is used as a further check to verify the integrity of the score being submitted. Ultimately, the checksum value will be used to ensure that the score is genuine. The recorded parameter is used to timestamp when the high score was achieved. It should be sent as a long value, which contains the number of milliseconds since the Epoch (Jan. 1, 1970 00:00:00) in UTC (i.e. GMT).

The userString value defines a displayable format for scores and is used on the Zodiac/Zorro device. This value should be stored within the server database for a high score. There can be characters within the string that may have to be escaped when sending back to the client (e.g. a space needs to be converted into %20).FIG. 3 ends instep318.

FIG. 4 depicts a flowchart for the gamemetric server140 executing the gamemetric processing software145 in an exemplary implementation of the invention.FIG. 4 begins instep400. Instep402, the gamemetric server140 executing the gamemetric processing software145 receives the game metric in the URL format from thecomputer system120 via thecommunication network130.

Instep404, the gamemetric server140 determines whether the score is the high score for the user ID, game creator ID, and score type. If the score is not the high score, the gamemetric server140 proceeds to step410. In some embodiments, the gamemetric server130 stores all score data (as defined above) for only the highest score for each combination of: user ID (looked up from device serial number)+game creatorID+game scoreType. If a higher score with matching user ID, creatorlD and scoreType is sent, the existing record is replaced with the new higher record.

In some embodiments, the algorithm for taking into account whether a new score belongs in the high score table includes the following:

- Verifying that the new score is better than the current score achieved by this user for this game. This is done by comparing the unsigned 32 bit values. Higher values are typically better.
- If a game high score is submitted to the server, and that game cannot be found in the high score database, then the assumption is made that this is a new game and the score is entered as the current high score for this user.
- The checksum value associated with a high score is stored in the database.
- The scoreType value associated with a high score is stored in the database. The scoreType value can be used for tournaments.

If the score is a high score, the gamemetric server140 stores the master record and the score record instep406. Instep408, the gamemetric server140 stores the checksum value for future validation.

Instep410, the gamemetric server140 transmits an Extended Mark-up Language (XML) response back to thecomputer system120 indicating the status of the high score submission. The response to the score submission may be an XML-formatted message that provides status for the operation. One field will describe the message status. A description field will provide more detailed information about what happened.



	For example:

	<?xml version=1.0 encoding=”ISO-8859-1”?>
	<highscore>
	<status>100</status>
	<description>A new high score for Tony Hawk was registered
	</description>
	</highscore>
	Or
	<?xml version=1.0?>
	<highscore>
	<status>104</status>
	<description>All data in the database was corrupted -
	ouch</description>
	</highscore>

A successful high score submission to the gamemetric server140 returns in the HTTP sponse header the status value of 200 (which is the well known value returned by HTTP servers for a success request operation). In this case, the XML-formatted response will exist. In the event of a server error, the status code of 500 (Internal server error) will be returned, and no XML-formatted response message will exist.

In the case of a successful request operation, the status field within the XML response message will describe what took place on the gamemetric server140 when this high score submission was made. The value of this field is numeric, and can take on the following values:



Status
value	Description

100	A score did not exist for this user and game; therefore a new
	high score was added into the high score database.
101	A score did exist for this user and game, and the submitted score
	is higher; therefore the existing high score was updated.
102	A score did exist for this user and game, and the submitted score
	is not higher; therefore the existing high score remains.
103	The specified user (identified by the SecurityID value) does not
	exist within the system. No high score was added to the system.
104	A general error occurred while parsing the input parameters

Instep412, the gamemetric server140 displays the high score for a creator ID and score type.

For tournaments, the games on thehandheld computing device110 can have a play mode that is validated for tournaments. In this play mode, cheats are disabled, and as much as possible the game experience is normalized to that scores on different devices can be compared. The resulting scores are reported as a new scoreType for the same game.

A tournament can be run on a server by looking specifically for high scores from the given game and game type, reported within a particular time range, and generated on thehandheld computing device110 within a particular time range. For tournament play, special attention should be given to the checksums for the scores.

For social policing of high scores, similar features such as “block” and “warn” for instant messaging can be implemented in the gamemetric server140. This would allow the customers to self-police, claming that scores for a given user are phony. Since scores are necessarily tied to the device serial number which is associated with a registered account, the names of people that may be cheating can be registered, which would discourage from making fake high scores. The threat of disabling all high score posting for a given account can be used to further dissuade people from making up fake scores.

Instep414, the gamemetric server140 receives a high score request. In some embodiments, an application on thehandheld computing device110 requests that a certain number of highest scores can be retrieved from the gamemetric server140, which depends on other variables such as whether the user is registered with the website and how often the user synchronizes. If enabled, theconduit software125 queries the gamemetric server140 for the top N high scores for each game and score type, and the existing server score records on thehandheld computing device110 is replaced with the new scores from the gamemetric server140.

In some embodiments, the userString for the high scores is prefixed with the alias that corresponds to the original high score, followed by the tab character. For example, if device A reports a high score as “100 points”, and is registered to “Mad Bob”, the gamemetric server140 reports the high score with the user string “Mad Bob\t100 points”.

The table below provides information about data types that are relevant for the high score API's. Along with the name of the data, its type information and a brief description of what the information is will also be given. Example URL: http://hsupload.tapwave.com/desktop/listGameScores/?scores=5&creatorID=0x54574853 &scoreType=0



Name	Data Type	Description

HardwareID	A 16 digit base-34 value	A unique value that identifies the hardware
		device. This value comes from the Road
		Dawg hardware ROM.
CreatorID	32 bit unsigned hex integer	A 4-byte value that unique defines an
	“0x00000000 . . . 0xFFFFFFFF”	application developer. While this value is
		most likely a 4 letter value (e.g. DOOM,
		ADDR) its representation it is still defined
		as an integer. The CreatorID is also
		assigned by Palm.
ScoreType	16 bit unsigned decimal	A value used to define which game type
	integer	this score is associated (used primarily for
	“0 . . . 65535”	game tournaments to identify a score being
		submitted for a tournament).
Scores	Integer	A value used to limit the number of scores
	“0 . . . 32767”	for a game returned. A practical maximum
		value is the largest signed 16 bit number,
		which is the maximum number of records
		that can exist in a PalmOS database.

Requests for game scores can be made on the server, which will return the information as an xml-formatted message. One embodiment for the format of the request for game scores is defined as follows:



	<?xml version=1.0 encoding=”ISO-8859-1”?>
	<games list=”1”>
	<game title=”Doom”>
	<highscores list=3>
	<highscore>
	<displayName>ray</displayName>
	<score>50000</score>
	<scoreType>1</scoreType>
	<checksum>0</checksum>
	<userstring>xxx:xyzzy</userString>
	<recorded>1058470322000</recorded>
	<submitted>1058470322000</submitted>
	</highscore>
	<highscore>
	<displayName>bob</displayName>
	<score>45000</score>
	<scoreType>1</scoreType>
	<checksum>0</checksum>
	<userstring>xxx:xyzzy</userString>
	<recorded>1058470322000</recorded>
	<submitted>1058470322000</submitted>
	</highscore>
	<highscore>
	<displayName>neal</displayName>
	<score>44550</score>
	<scoreType>1</scoreType>
	<checksum>0</checksum>
	<userstring>xxx:xyzzy</userString>
	<recorded>1058470322000</recorded>
	<submitted>1058470322000</submitted>
	</highscore>
	</highscores>
	</game>
	</games>

Instep416, the gamemetric server140 transmits the high scores in an XML formatted message.FIG. 4 ends instep418.

The above-described functions can be comprised of instructions that are stored on storage media. These instructions can be retrieved and executed by a processor. Some examples of instructions are software, program code, and firmware. Some examples of storage media are memory devices, tape, disks, integrated circuits, and servers. The instructions are operational when executed by the processor to direct the processor to operate in accord with the invention. Those skilled in the art are familiar with instructions, processor, and storage media.

Those skilled in the art will appreciate variations of the above-described embodiments that fall within the scope of the invention.

Claims

1. A system for processing game metrics, the system comprising:

a handheld computing device configured to capture the game metrics for a game and transfer the game metrics; and

a game metric server configured to receive the game metrics from the handheld computing device via a computer system and a communication network and process the game metrics.

2. A method for processing game metrics, the method comprising:

capturing the game metrics for a game into a handheld computing device;

transferring the game metrics from the handheld computing device;

receiving the game metrics into a game metric server from the handheld computing device via a computer system and a communication network; and

processing the game metrics in the game metric server.