U.S. patent application number 12/407752 was filed with the patent office on 2010-01-21 for apparatus and methods for game conversion.
This patent application is currently assigned to GDI Game Domain International PLC. Invention is credited to Uwe PROCHNOW.
Application Number | 20100016074 12/407752 |
Document ID | / |
Family ID | 40940630 |
Filed Date | 2010-01-21 |
United States Patent
Application |
20100016074 |
Kind Code |
A1 |
PROCHNOW; Uwe |
January 21, 2010 |
APPARATUS AND METHODS FOR GAME CONVERSION
Abstract
A computer game conversion apparatus for reducing the size of a
computer game comprising a plurality of game elements, the
apparatus comprising: a game element similarity checker for
identifying game elements of the plurality of game elements which
are at least similar to a first game element of the plurality of
game elements; and an optimisation module for replacing the similar
game elements with a reference to the first game element and
deleting the similar game elements.
Inventors: |
PROCHNOW; Uwe; (Essen,
GB) |
Correspondence
Address: |
MCDERMOTT WILL & EMERY LLP
18191 VON KARMAN AVE., SUITE 500
IRVINE
CA
92612-7108
US
|
Assignee: |
GDI Game Domain International
PLC
Southhall
GB
|
Family ID: |
40940630 |
Appl. No.: |
12/407752 |
Filed: |
March 19, 2009 |
Current U.S.
Class: |
463/29 ;
463/42 |
Current CPC
Class: |
A63F 13/12 20130101;
A63F 2300/552 20130101; A63F 2300/5526 20130101; A63F 13/10
20130101; A63F 13/77 20140902; A63F 13/35 20140902 |
Class at
Publication: |
463/29 ;
463/42 |
International
Class: |
A63F 9/24 20060101
A63F009/24 |
Foreign Application Data
Date |
Code |
Application Number |
Mar 20, 2008 |
GB |
0805206.0 |
Nov 19, 2008 |
GB |
0823230.8 |
Claims
1. A computer game conversion apparatus for reducing the size of a
computer game comprising a plurality of game elements, the
apparatus comprising: a game element similarity checker for
identifying game elements of the plurality of game elements which
are at least similar to a first game element of the plurality of
game elements; and an optimisation module for replacing the similar
game elements with a reference to the first game element and
deleting the similar game elements.
2. The computer game conversion apparatus according to claim 1,
further comprising: a game element categorisation module for
categorising the plurality of game elements, and wherein the game
element similarity checker determines the category of the first
element and identifies the similar game elements within the
determined category of the first element.
3. The computer game conversion apparatus according to claim 1 or
2, wherein at least some of the similar game elements comprise game
elements having a predetermined degree of likeness to the first
game element.
4. The computer game conversion apparatus according to claim 3,
wherein the predetermined degree of likeness is greater than one or
more of: 70%; 75%; 80%; 85%; 90%; 95%.
5. The computer game conversion apparatus according to claim 3 or
4, further comprising: a tolerance control module for defining the
degree of likeness.
6. The computer game conversion apparatus according to any one of
claims 1 to 5, wherein, at least some of the similar game elements
comprise game elements which are identical to the first game
element.
7. The computer game conversion apparatus according to any one of
claims 2 to 6, wherein the game element categorisation module
generates metadata for each game element.
8. The computer game conversion apparatus according to claim 7,
wherein the metadata comprises one or more of: FileID; FileName;
FileTypeID; FileLink; GameID; FileSize; ReferenceStatusID;
ReplacementFileID; ClassID; SubClassID.
9. The computer game conversion apparatus according to claim 7 or
8, wherein the game element categorisation module tabulates the
game elements according to the one or more metadata categories.
10. The computer game conversion apparatus according to any one of
claims 1 to 9, further comprising: a multiple-pass similarity
optimiser configured to identify game elements of the plurality of
game elements which are at least similar to game elements of at
least one other computer game, to replace the identified game
elements with a reference to the game elements of the at least one
other computer game, and to delete the identified game
elements.
11. The computer game conversion apparatus according to claim 10,
wherein at least some of the identified game elements which are
similar to the game elements of the at least one other computer
game have a predetermined degree of likeness to the game elements
of the at least one other computer game.
12. The computer game conversion apparatus according to claim 11,
wherein the predetermined degree of likeness is greater than one or
more of: 70%; 75%; 80%; 85%; 90%; 95%.
13. The computer game conversion apparatus according to claim 11 or
12, further comprising: a tolerance control module for defining the
degree of likeness.
14. The computer game conversion apparatus according to any one of
claims 10 to 13, wherein at least some of the identified game
elements which are similar to the game elements of the at least one
other computer game are identical to the game elements of the at
least one other computer game.
15. The computer game conversion apparatus according to any one of
claims 10 to 14, wherein the multiple-pass similarity optimizer
compares the game elements of the plurality of game elements with
the game elements of the at least one other computer game a
plurality of times, and wherein each comparison uses the results of
a previous comparison.
16. The computer game conversion apparatus according to any one of
claims 1 to 15, further comprising: a game training module
configured to receive a log of computer game elements which are not
used during game-play of the computer game from a plurality of
users, to compare the logs from the plurality of users in order to
identify computer game element redundancies, and to delete the
redundant computer game elements from the computer game.
17. The computer game conversion apparatus according to any one of
claims 1 to 16, further comprising: a data splitter configured to
separate the plurality of game elements into active data game
elements and passive data game elements.
18. A computer game conversion apparatus for converting a computer
game comprising a plurality of game elements into a distribution
format, the apparatus comprising: a data splitter configured to
separate the plurality of game elements into active data game
elements and passive data game elements.
19. The computer game conversion apparatus according to claim 18,
wherein the active data game elements have an average file size
smaller than an average file size of the passive data game
elements.
20. A computer game conversion apparatus for reducing the size of a
computer game comprising a plurality of game elements, the
apparatus comprising: a game analyzer for identifying game elements
of the plurality of game elements which are similar to a first game
element of the plurality of game elements; an optimisation module
for replacing the similar game elements with a reference to the
first game element and deleting the similar game elements; and a
data splitter configured to separate the plurality of optimised
game elements into active data game elements and passive data game
elements.
21. The computer game conversion apparatus according to claim 20,
wherein the active data game elements have an average file size
smaller than an average file size of the passive data game
elements.
22. A multiple-pass similarity optimiser configured to identify
game elements of a plurality of game elements of a computer game
which are at least similar to game elements of at least one other
computer game, to replace the identified game elements with a
reference to the similar game elements of the at least one other
computer game, and to delete the identified game elements.
23. The multiple-pass similarity optimiser according to claim 22,
wherein at least some of the identified game elements which are
similar to the game elements of the at least one other computer
game have a predetermined degree of likeness to the game elements
of the at least one other computer game.
24. The multiple-pass similarity optimiser according to claim 23,
wherein the predetermined degree of likeness is greater than one or
more of: 70%; 75%; 80%; 85%; 90%; 95%.
25. The multiple-pass similarity optimiser according to claim 23 or
24, further comprising: a tolerance control module for defining the
degree of likeness.
26. The computer game conversion apparatus according to any one of
claims 22 to 25, wherein at least some of the identified game
elements which are similar to the game elements of the at least one
other computer game are identical to the game elements of the at
least one other computer game.
27. A game conversion apparatus for converting a computer game
comprising a plurality of game elements into a distribution format,
the apparatus comprising: a data splitter configured to separate
the plurality of game elements into active data game elements and
passive data game elements; and a multiple-pass similarity
optimiser configured to identify game elements of the plurality of
game elements which are at least similar to game elements of at
least one other computer game, to replace the identified game
elements with a reference to the similar game elements of the at
least one other computer game, and to delete the identified game
elements.
28. The game conversion apparatus according to claim 27, wherein
the active data game elements have an average file size smaller
than an average file size of the passive data game elements.
29. The game conversion apparatus according to claim 27 or 28,
wherein at least some of the identified game elements which are
similar to the game elements of the at least one other computer
game have a predetermined degree of likeness to the game elements
of the at least one other computer game.
30. The game conversion apparatus according to claim 29, wherein
the predetermined degree of likeness is greater than one or more
of: 70%; 75%; 80%; 85%; 90%; 95%.
31. The game conversion apparatus according to claim 29 or 30,
further comprising: a tolerance control module for defining the
degree of likeness.
32. The game conversion apparatus according to any one of claims 27
to 31, wherein at least some of the identified game elements which
are similar to the game elements of the at least one other computer
game are identical to the game elements of the at least one other
computer game.
33. A computer game analyzer for analysing a computer game
comprising a plurality game elements and converting it into a
distribution format, the analyzer comprising: a code sorter module
configured to identify individual game elements as belonging to a
particular category of game element; a game element categorisation
module configured to tabulate the individual game elements
according to the identified categories; and a similarity checker
module configured to compare each individual game element of a
particular category with the plurality of game elements of that
particular category, and to identifying game elements of the
plurality of game elements which are at least similar to the
individual game element.
34. The computer game analyzer according to claim 33, further
comprising: an optimisation module for replacing the similar game
elements with a reference to the individual game element and
deleting the similar game elements.
35. The computer game analyzer according to claim 33 or 34, further
comprising: a game engine checker module configured to identify a
gaming engine used by the computer game.
36. The computer game analyzer according to claim 35, wherein the
game engine checker module is configured to identify any parameters
for configuring the game engine.
37. The computer game analyzer according to any one of claims 33 to
36, wherein the code sorter module generates metadata for each game
element.
38. The computer game analyzer according to claim 37, wherein the
metadata comprises one or more of: FileID; FileName; FileTypeID;
FileLink; GameID; FileSize; ReferenceStatusID; ReplacementFileID;
ClassID; SubClassID.
39. The computer game analyzer according to claim 38, wherein the
game element categorisation module tabulates the individual game
elements according to the one or more metadata categories.
40. The computer game analyzer according to any one of claims 33 to
39, wherein the tabulated individual game elements are stored in a
storage device.
41. The computer game analyzer according to any one of claims 33 to
40, wherein at least some of the identified game elements have a
predetermined degree of likeness to the individual game
element.
42. The computer game analyzer according to claim 41, wherein the
predetermined degree of likeness is greater than one or more of:
70%; 75%; 80%; 85%; 90%; 95%.
43. The computer game analyzer according to claim 41 or 42, further
comprising: a tolerance control module for defining the degree of
likeness.
44. The computer game analyzer according to any one of claims 41 to
43, wherein at least some of the identified game elements are
identical to the individual game element.
45. The computer game analyzer according to any one of claims 33 to
44, wherein the active data game elements have an average file size
smaller than an average file size of the passive data game
elements.
46. A computer game analyzer for analysing a computer game and
converting it into a distribution format, the analyzer comprising:
a game engine checker module configured to identify a gaming engine
used by the computer game; and a reference table provided with game
engine indicators, wherein the game engine checker module uses the
game engine indicators in order to identify the game engine.
47. A computer game analyzer for analysing a computer game
comprising a plurality game elements and converting it into a
distribution format, the analyzer comprising: a game training
module configured to receive a log of computer game resources which
are not used during game-play from a plurality of users, to compare
the logs from the plurality of users in order to identify computer
game resource redundancies, and to delete the redundant computer
game resource from the computer game.
48. The computer game analyzer according to claim 47, wherein the
game training module is further configured to compare the logs from
the plurality of users in order to identify an essential minimum of
the computer game resources required in order to begin playing the
game.
49. A computer game optimizer comprising: A multiple-pass
similarity optimizer configured to receive computer game elements
from a plurality of computer games, to compare the received
computer game elements of each computer game of the plurality of
computer games with the computer game elements of the plurality of
computer games, and to determine at least similar computer game
elements.
50. The computer game optimizer according to claim 49, further
comprising: a tolerance control module for defining a degree of
likeness between computer game elements considered similar.
51. The computer game optimizer according to claim 50, wherein the
degree of likeness between elements comprises 100% likeness.
52. The computer game optimizer according to claim 50, wherein the
degree of likeness between elements is greater than one or more of:
70%; 75%; 80%; 85%; 90%; 95%.
53. The computer game optimizer according to any one of claims 49
to 52, wherein the multiple-pass similarity optimizer compares the
received computer game elements of each game of the plurality of
games with the computer game elements of the plurality of games a
plurality of times, wherein each comparison uses the results of the
previous comparison.
54. A method of operating a computer to reduce a computer games
size, the computer game comprising a plurality of game elements,
the method comprising: identifying game elements of the plurality
of game elements which are at least similar to a first game element
of the plurality of game elements; replacing the similar game
elements with a reference to the first game element; and deleting
the similar game elements.
55. The method according to claim 54, further comprising:
categorising the plurality of game elements; determining a category
of the first element; and identifying the similar game elements
within the determined category of the first element.
56. The method according to claim 54 or 55, further comprising:
defining a predetermined degree of likeness between the first
element and the similar game elements.
57. The method according to any one of claims 54 to 56, further
comprising: generating metadata for each game element.
58. The method according to claim 57, further comprising:
categorising the game elements according to the metadata.
59. The method according to any one of claims 55 to 58, further
comprising: storing the categorises of game elements in a storage
device.
60. The method according to any one of claims 54 to 59, further
comprising: identifying game elements of the plurality of game
elements which at least similar to game elements of at least one
other computer game; replacing the identified game elements with a
reference to the game elements of the at least one other computer
game; and deleting the identified game elements.
61. The method according to any one of claims 54 to 60, further
comprising: receiving a log of game elements which are not used
during game-play of the computer game from a plurality of users;
comparing the logs from the plurality of users in order to identify
redundant game elements; and deleting the redundant game elements
from the computer game.
62. The method according to any one of claims 54 to 61, further
comprising: separating the plurality of game elements into active
data game elements and passive data game elements.
63. A method of operating a computer to reduce a computer games
size, the computer game comprising a plurality of game elements,
the method comprising: receiving a log of game elements which are
not used during play of the computer game from a plurality of
users; comparing the logs from the plurality of users in order to
identify redundant game elements; and deleting the redundant game
elements from the computer game.
64. A method of operating a computer to convert a computer game
comprising a plurality of game elements into a distribution format,
the method comprising: separating the plurality of game elements
into active data game elements and passive data game elements.
65. A computer program product comprising programme code means for
performing the method according to any one of claims 54 to 64.
66. A computer readable medium recorded with computer readable code
arranged to cause a computer to perform the method according to any
one of claims 54 to 64.
67. A computer programme code means for performing the method
according to any one of claims 54 to 64.
Description
TECHNICAL FIELD
[0001] This invention relates generally to computer game
conversion. More specifically, embodiments of the invention relate
to the apparatus and methods for the optimisation, digital rights
management (DRM) and distribution of computer games.
BACKGROUND
[0002] Digital distribution is the principle of providing digital
content over the Internet, and other networks, in the form of
products or services. With broadband internet becoming evermore
ubiquitous, the digital distribution of all types of media content
is becoming increasingly desirable. Content delivery networks
consisting of systems of servers and desktop computers have been
deployed to deliver digital content to end users operating for
example desktop PCs or consoles across the Internet.
[0003] One existing platform of this type for example is Valve
Corporation's "Steam" product, which is a digital distribution,
multiplayer and communications suite. It is primarily used to
digitally distribute and manage various kinds of computer games,
ranging from first-person shooters and RPGs (role playing games) to
racing games.
[0004] Systems such as this allow users to purchase and acquire
games access through a digital distribution network. In this
regard, instead of receiving a box with a CD/DVD, purchased
software is distributed by a server to the user, for example, via a
pre-registered user account through which the software can be
accessed and downloaded to a local client application running on
the user's computer.
[0005] Known digital distribution platforms have operated with a
distributed file system. The distributed file system allows a game
to launch before it has been completely downloaded locally on to
the player's computer. Most typically, this has been done by
creating lists of essential game files and having a pre-loader
request them from the distribution server only when they are needed
or are about to be needed. According to these systems, it has been
possible for a linear game to begin playing with only the
executable code and a buffer of the first few areas downloaded.
Such systems have been problematic up to now for various reasons.
One major problem is that the game play will generally hang whilst
data downloads in the background because modern games are many
hundreds or even thousands of megabytes in size. Another problem is
that downloads are vastly slowed down on slower connections or when
the service providers get busy and are less able to cope with
providing high bandwidth downloads. This problem is increased
further for non-linear games, where the possibilities for game play
are vast and the data required is always changing. For these
reasons, this kind of content delivery has not been used
extensively to date, since it has been impractical and frustrating
for the end user.
[0006] The present invention provides an improved content delivery
system for computer games. More specifically, embodiments of the
present invention provide apparatus and methods for reducing the
amount of data making up computer games, and allows a user to
receive game data at their computer quickly and securely over a
network such as the internet.
SUMMARY
[0007] According to one embodiment of the invention, there is
provided a computer game conversion apparatus for reducing the size
of a computer game comprising a plurality of game elements. The
computer game conversion apparatus comprising: a game element
similarity checker for identifying game elements of the plurality
of game elements which are at least similar to a first game element
of the plurality of game elements; and an optimisation module for
replacing the similar game elements with a reference to the first
game element and deleting the similar game elements.
[0008] According to another embodiment of the invention, the
computer game conversion apparatus further comprises: a game
element categorisation module for categorising the plurality of
game elements, and wherein the game element similarity checker
determines the category of the first element and identifies the
similar game elements within the determined category of the first
element.
[0009] According to another embodiment of the invention, at least
some of the similar game elements comprise game elements having a
predetermined degree of likeness to the first game element.
[0010] According to another embodiment of the invention, the
predetermined degree of likeness is greater than one or more of:
70%; 75%; 80%; 85%; 90%; 95%.
[0011] According to another embodiment of the invention, the
computer game conversion apparatus further comprises: a tolerance
control module for defining the degree of likeness.
[0012] According to another embodiment of the invention, at least
some of the similar game elements comprise game elements which are
identical to the first game element.
[0013] According to another embodiment of the invention, the game
element categorisation module generates metadata for each game
element.
[0014] According to another embodiment of the invention, the
metadata comprises one or more of: FileID; FileName; FileTypeID;
FileLink; GameID; FileSize; ReferenceStatusID; ReplacementFileID;
ClassID; SubClassID.
[0015] According to another embodiment of the invention, the game
element categorisation module tabulates the game elements according
to the one or more metadata categories.
[0016] According to another embodiment of the invention, the
computer game conversion apparatus further comprises: a
multiple-pass similarity optimiser configured to identify game
elements of the plurality of game elements which are at least
similar to game elements of at least one other computer game, to
replace the identified game elements with a reference to the game
elements of the at least one other computer game, and to delete the
identified game elements.
[0017] According to another embodiment of the invention, at least
some of the identified game elements which are similar to the game
elements of the at least one other computer game have a
predetermined degree of likeness to the game elements of the at
least one other computer game.
[0018] According to another embodiment of the invention, the
predetermined degree of likeness is greater than one or more of:
70%; 75%; 80%; 85%; 90%; 95%.
[0019] According to another embodiment of the invention, the
computer game conversion apparatus further comprises: a tolerance
control module for defining the degree of likeness.
[0020] According to another embodiment of the invention, at least
some of the identified game elements which are similar to the game
elements of the at least one other computer game are identical to
the game elements of the at least one other computer game.
[0021] According to another embodiment of the invention, the
multiple-pass similarity optimizer compares the game elements of
the plurality of game elements with the game elements of the at
least one other computer game a plurality of times, and wherein
each comparison uses the results of a previous comparison.
[0022] According to another embodiment of the invention, the
computer game conversion apparatus further comprises: a game
training module configured to receive a log of computer game
elements which are not used during game-play of the computer game
from a plurality of users, to compare the logs from the plurality
of users in order to identify computer game element redundancies,
and to delete the redundant computer game elements from the
computer game.
[0023] According to another embodiment of the invention, the
computer game conversion apparatus further comprises: a data
splitter configured to separate the plurality of game elements into
active data game elements and passive data game elements.
[0024] According to one embodiment of the invention, there is
provided a computer game conversion apparatus for converting a
computer game comprising a plurality of game elements into a
distribution format. The computer game conversion apparatus
comprising: a data splitter configured to separate the plurality of
game elements into active data game elements and passive data game
elements.
[0025] According to another embodiment of the invention, the active
data game elements have an average file size smaller than an
average file size of the passive data game elements.
[0026] According to one embodiment of the invention, there is
provided a computer game conversion apparatus for reducing the size
of a computer game comprising a plurality of game elements. The
computer game conversion apparatus comprising: a game analyzer for
identifying game elements of the plurality of game elements which
are similar to a first game element of the plurality of game
elements; an optimisation module for replacing the similar game
elements with a reference to the first game element and deleting
the similar game elements; and a data splitter configured to
separate the plurality of optimised game elements into active data
game elements and passive data game elements.
[0027] According to another embodiment of the invention, the active
data game elements have an average file size smaller than an
average file size of the passive data game elements.
[0028] According to one embodiment of the invention, there is
provided a multiple-pass similarity optimiser configured to
identify game elements of a plurality of game elements of a
computer game which are at least similar to game elements of at
least one other computer game, to replace the identified game
elements with a reference to the similar game elements of the at
least one other computer game, and to delete the identified game
elements.
[0029] According to another embodiment of the invention, at least
some of the identified game elements which are similar to the game
elements of the at least one other computer game have a
predetermined degree of likeness to the game elements of the at
least one other computer game.
[0030] According to another embodiment of the invention, the
predetermined degree of likeness is greater than one or more of:
70%; 75%; 80%; 85%; 90%; 95%.
[0031] According to another embodiment of the invention, the
multiple-pass similarity optimiser further comprises: a tolerance
control module for defining the degree of likeness.
[0032] According to another embodiment of the invention, at least
some of the identified game elements which are similar to the game
elements of the at least one other computer game are identical to
the game elements of the at least one other computer game.
[0033] According to one embodiment of the invention, there is
provided a game conversion apparatus for converting a computer game
comprising a plurality of game elements into a distribution format.
The game conversion apparatus comprising: a data splitter
configured to separate the plurality of game elements into active
data game elements and passive data game elements; and a
multiple-pass similarity optimiser configured to identify game
elements of the plurality of game elements which are at least
similar to game elements of at least one other computer game, to
replace the identified game elements with a reference to the
similar game elements of the at least one other computer game, and
to delete the identified game elements.
[0034] According to another embodiment of the invention, the active
data game elements have an average file size smaller than an
average file size of the passive data game elements.
[0035] According to another embodiment of the invention, at least
some of the identified game elements which are similar to the game
elements of the at least one other computer game have a
predetermined degree of likeness to the game elements of the at
least one other computer game.
[0036] According to another embodiment of the invention, the
predetermined degree of likeness is greater than one or more of:
70%; 75%; 80%; 85%; 90%; 95%.
[0037] According to another embodiment of the invention, the game
conversion apparatus further comprises: a tolerance control module
for defining the degree of likeness.
[0038] According to another embodiment of the invention, at least
some of the identified game elements which are similar to the game
elements of the at least one other computer game are identical to
the game elements of the at least one other computer game.
[0039] According to one embodiment of the invention, there is
provided a computer game analyzer for analysing a computer game
comprising a plurality game elements and converting it into a
distribution format. The computer game analyzer comprising: a code
sorter module configured to identify individual game elements as
belonging to a particular category of game element; a game element
categorisation module configured to tabulate the individual game
elements according to the identified categories; and a similarity
checker module configured to compare each individual game element
of a particular category with the plurality of game elements of
that particular category, and to identifying game elements of the
plurality of game elements which are at least similar to the
individual game element.
[0040] According to another embodiment of the invention, the
computer game analyzer further comprises: an optimisation module
for replacing the similar game elements with a reference to the
individual game element and deleting the similar game elements.
[0041] According to another embodiment of the invention, the
computer game analyzer further comprises: a game engine checker
module configured to identify a gaming engine used by the computer
game.
[0042] According to another embodiment of the invention, the game
engine checker module is configured to identify any parameters for
configuring the game engine.
[0043] According to another embodiment of the invention, the code
sorter module generates metadata for each game element.
[0044] According to another embodiment of the invention, the
metadata comprises one or more of: FileID; FileName; FileTypeID;
FileLink; GameID; FileSize; ReferenceStatusID; ReplacementFileID;
ClassID; SubClassID.
[0045] According to another embodiment of the invention, the game
element categorisation module tabulates the individual game
elements according to the one or more metadata categories.
[0046] According to another embodiment of the invention, the
tabulated individual game elements are stored in a storage
device.
[0047] According to another embodiment of the invention, at least
some of the identified game elements have a predetermined degree of
likeness to the individual game element.
[0048] According to another embodiment of the invention, the
predetermined degree of likeness is greater than one or more of:
70%; 75%; 80%; 85%; 90%; 95%.
[0049] According to another embodiment of the invention, the
computer game analyzer further comprises: a tolerance control
module for defining the degree of likeness.
[0050] According to another embodiment of the invention, at least
some of the identified game elements are identical to the
individual game element.
[0051] According to another embodiment of the invention, the active
data game elements have an average file size smaller than an
average file size of the passive data game elements.
[0052] According to one embodiment of the invention, there is
provided a computer game analyzer for analysing a computer game and
converting it into a distribution format. The computer game
analyzer comprising: a game engine checker module configured to
identify a gaming engine used by the computer game; and a reference
table provided with game engine indicators, wherein the game engine
checker module uses the game engine indicators in order to identify
the game engine.
[0053] According to one embodiment of the invention, there is
provided a computer game analyzer for analysing a computer game
comprising a plurality game elements and converting it into a
distribution format. The computer game analyzer comprising: a game
training module configured to receive a log of computer game
resources which are not used during game-play from a plurality of
users, to compare the logs from the plurality of users in order to
identify computer game resource redundancies, and to delete the
redundant computer game resource from the computer game.
[0054] According to another embodiment of the invention, the game
training module is further configured to compare the logs from the
plurality of users in order to identify an essential minimum of the
computer game resources required in order to begin playing the
game.
[0055] According to one embodiment of the invention, there is
provided a computer game optimizer comprising: a multiple-pass
similarity optimizer configured to receive computer game elements
from a plurality of computer games, to compare the received
computer game elements of each computer game of the plurality of
computer games with the computer game elements of the plurality of
computer games, and to determine at least similar computer game
elements.
[0056] According to another embodiment of the invention, the
computer game optimizer further comprises: a tolerance control
module for defining a degree of likeness between computer game
elements considered similar.
[0057] According to another embodiment of the invention, the degree
of likeness between elements comprises 100% likeness.
[0058] According to another embodiment of the invention, the degree
of likeness between elements is greater than one or more of: 70%;
75%; 80%; 85%; 90%; 95%.
[0059] According to another embodiment of the invention, the
multiple-pass similarity optimizer compares the received computer
game elements of each game of the plurality of games with the
computer game elements of the plurality of games a plurality of
times, wherein each comparison uses the results of the previous
comparison.
[0060] According to one embodiment of the invention, there is
provided a method of operating a computer to reduce a computer
games size, the computer game comprising a plurality of game
elements. The method comprising: identifying game elements of the
plurality of game elements which are at least similar to a first
game element of the plurality of game elements; replacing the
similar game elements with a reference to the first game element;
and deleting the similar game elements.
[0061] According to another embodiment of the invention, the method
further comprises: categorising the plurality of game elements;
determining a category of the first element; and identifying the
similar game elements within the determined category of the first
element.
[0062] According to another embodiment of the invention, the method
further comprises: defining a predetermined degree of likeness
between the first element and the similar game elements.
[0063] According to another embodiment of the invention, the method
further comprises: generating metadata for each game element.
[0064] According to another embodiment of the invention, the method
further comprises: categorising the game elements according to the
metadata.
[0065] According to another embodiment of the invention, the method
further comprises: storing the categorises of game elements in a
storage device.
[0066] According to another embodiment of the invention, the method
further comprises: identifying game elements of the plurality of
game elements which at least similar to game elements of at least
one other computer game; replacing the identified game elements
with a reference to the game elements of the at least one other
computer game; and deleting the identified game elements.
[0067] According to another embodiment of the invention, the method
further comprises: receiving a log of game elements which are not
used during game-play of the computer game from a plurality of
users; comparing the logs from the plurality of users in order to
identify redundant game elements; and deleting the redundant game
elements from the computer game.
[0068] According to another embodiment of the invention, the method
further comprises: separating the plurality of game elements into
active data game elements and passive data game elements.
[0069] According to one embodiment of the invention, there is
provided a method of operating a computer to reduce a computer
games size, the computer game comprising a plurality of game
elements. The method comprising: receiving a log of game elements
which are not used during play of the computer game from a
plurality of users; comparing the logs from the plurality of users
in order to identify redundant game elements; and deleting the
redundant game elements from the computer game.
[0070] According to one embodiment of the invention, there is
provided a method of operating a computer to convert a computer
game comprising a plurality of game elements into a distribution
format. The method comprising: separating the plurality of game
elements into active data game elements and passive data game
elements.
[0071] According to one embodiment of the invention, there is
provided a computer program product comprising programme code means
for performing the method described above.
[0072] According to one embodiment of the invention, there is
provided a computer readable medium recorded with computer readable
code arranged to cause a computer to perform the method described
above.
[0073] According to one embodiment of the invention, there is
provided a computer programme code means for performing the method
described above.
BRIEF DESCRIPTION OF THE DRAWINGS
[0074] For a better understanding of the invention and as to how
the same may be carried into effect, reference will now be made, by
way of example only, to the accompanying drawings, in which:
[0075] FIG. 1 illustrates schematically a gaming system;
[0076] FIG. 2 illustrates schematically a game conversion
module;
[0077] FIG. 3 illustrates schematically a game analyzer module;
[0078] FIG. 4 illustrates schematically a log generated by a game
training kit;
[0079] FIG. 5 illustrates schematically a process performed by a
game analyzer module;
[0080] FIG. 6 illustrates schematically a process performed by a
raw optimization module;
[0081] FIG. 7 illustrates schematically a data splitter module;
and
[0082] FIG. 8 illustrates schematically a n-pass similarity
optimizer.
DETAILED DESCRIPTION
[0083] Those skilled in the art will appreciate that while this
disclosure describes what is considered to be the best mode and,
where appropriate, other modes of performing the invention, the
invention should not be limited to the specific configurations and
methods disclosed in this description of the preferred
embodiment.
[0084] FIG. 1 illustrates a gaming system 1 according to an
embodiment of the present invention. The system comprises: a game
conversion module 10, a game server 20 and one or more user devices
running a game client 30, the one or more user devices generally
being game playing devices, e.g. a desktop computer or games
console. The game conversion module 10 may be connected to the game
server 20 via a suitable network connection. Alternatively, the
game conversion module 10 may be a stand-alone module, wherein its
resulting game products are downloaded to a memory such as a hard
disk drive or a computer-readable medium such as CD-ROM/DVD-ROM.
Each of the components 10, 20 and 30 may be in communication via
the internet 40 or other network connection.
[0085] Further details of both the game communication server 20 and
the game client 30 can be found in co-pending applications entitled
"Game Server" filed by the same applicant as this application and
"Game User Apparatus" filed by the same applicant as this
application.
[0086] FIG. 2 shows a more detailed illustration of the game
conversion module 10. The game conversion module 10 comprises: a
game analyser module 101, a conclusion database 103, a raw
optimization module 105, a raw optimized database 107, a data
splitter module 109, an active database 111, a passive database
113, an n-pass similarity optimizer 115, a sum active database 117
and a sum passive database 119.
[0087] FIG. 3 shows a more detailed illustration of the game
analyser module 101. The game analyser module 101 comprises a code
sorter module 201, an element categorisation module 203, element
table generator 205, a 1:1 similarity check module 207 and a game
engine checker module 209. According to one embodiment, the game
analyser module 101 further comprises a game training module 211,
which is described in more detail below.
[0088] The game analyser module 101 takes a computer game as an
input. This is, for example, a master copy supplied directly by the
game manufacturer and is most typically a version of the game free
of any encryption, compression or other modifications supplied on
CD-ROM or DVD-ROM. This type of master copy is sometimes referred
to as a "gold master" copy. The game analyser module 101 is
operable to install the game in a datastore such as a hard disk
drive or datastore such as 213 within the conversion module 10, in
much the same way as a game is installed on a conventional desktop
computer. According to an optional feature, the game analyser
module 101 is operable to determine the total size of the game
package provided on the master copy once it has been installed.
[0089] The game analyser module 101 is operable to carry out at
least two levels of logging; an application level logging and a
hardware level logging. The term "logging" in this context is used
to describe a monitoring of application and system hardware
behaviour during the installation of the game on the conversion
module 10 and creation of a record thereof. Application level
logging, for example, will include: observed registry entries,
system resources required (such as sound, graphics, input
controllers etc.), user access permissions, network resources
required etc. Hardware level logging, for example, will include
records of what the processor is doing during installation, i.e.
system resources called, how the sound device and graphics device
are invoked, a check that the required minimum resources are
available on the client machine etc. In other words, the hardware
level logging is a monitoring and recordal of the behavioural
communication between hardware and software components. In this
regard it may be considered a type of "kernel logging".
[0090] Using the aforementioned hardware and software level logging
files, and the original game code installed from the master copy of
the game, the game analyser module 101 is operable to create a
complete, working version of the game that can be run from the
installation files installed on the conversion module 10 without
the need for the master of the game to be inserted. In effect, a
working clone of the game is installed with all the references to
the installation disc removed or changed such that the game can be
run without the installation CD/DVD. Specifically, the working
clone of the game, in the context of the present disclosure, is
used to refer to a version of a game that imitates the original
master copy in appearance and/or function to the game player.
[0091] According to one embodiment, the game analyser module 101
carries out a testing step once the clone has been created in order
to determine that it is fully functional. Preferably, this testing
step involves a full analysis of the installed files and file
structures at the application level.
[0092] According to one example, the code sorter module 201 is
operable to search through the installed computer game at a source
code level and identify metadata describing game elements present
in the game source code. Broadly, a game element is any game file
data. Examples of game element categories include, but are not
limited to, textures (or skins), 2D and 3D models (or wireframe
objects), videos, audio files, level data, scene data, narrative
data and so on.
[0093] The code sorter module 201 carries out a `search and sort`
operation on game source code. The search and sort operation
involves searching through the source code of a game and
identifying individual game elements, for example, by their file
types, file extensions or data content recognised as belonging to a
particular category of game element. According to one example, the
code sorter module 201 generates the following metadata fields for
each game element: [0094] FileID--a unique code to identify the
file throughout the entire gaming system 1. According to one
embodiment, the unique code is an alpha-numeric code, e.g. two
letters and ten digits in length. [0095] FileName--a record
containing the given name of the file including its extension e.g.
"tree1.jpg", "bang2.wav" etc. [0096] FileTypeID--a record
indicating the file extension, e.g. "bmp", "jpg", "mp3", "wav" and
such like. According to one embodiment, proprietary file extensions
are standardised during the herein described conversion process.
For instance, a standard "*.jpg" file may be renamed as "*.abc" by
a given game developer for a number of reasons. This process may be
reversed so that all standard files have the correct, accepted file
extension format. According to one embodiment, file extensions are
standardised according to a labelling system representing each
individual file types. For instance, the following numbering system
may be employed: 00100 representing the general category of
"graphics files" with 00101=jpeg files, 00102=bmp files, 00103=png
files etc; and 00400 representing "sound files" with 00401=wav
files, 00402=ogg files, 00403=mp3 files etc. [0097] FileLink--is a
marker indicating the position of the file within the file
structure of the installed game. In other words, it is a route
indicator. [0098] GameID--a unique code to identify the game
throughout the entire conversion computer system 10. According to
one embodiment, the unique code is an alpha-numeric code, e.g. two
letters and five digits in length, optionally with a regional
suffix (e.g. "DE" for Germany, "UK" for United Kingdom etc.)
indicating the language version of the game. Note that each
language version of the game will generally undergo a separate
conversion process, although in some circumstances, this may not be
necessary. [0099] FileSize--the size of the file, e.g. in
kilobytes. [0100] ReferenceStatusID--made up of three sub-metadata
flags: "No" (0), "Yes" (1) and "Not Tested Yet" (2), each
indicating whether or not the file is replaceable by a file already
present in the game conversion database 117, 119. According to one
example, this ID is generated by similarity checker module 207.
[0101] ReplacementFileID--if the ReferenceStatusID=1, then the
ReplacementFileIDs comprises a list of all other IDs which the file
is a reference file to. In other words, it comprises a list of all
equivalent files that can be replaced by the present file.
According to one example, this ID is generated by similarity
checker module 207. [0102] ClassID--is made up of two sub-metadata
flags: an indicator of whether the file is classified as active (0)
or passive (1). According to one example, this ID is generated by
the data splitter 109 as described in more detail below. [0103]
SubClassID--is a locking flag which prevents an active file being
replaced by another file. Accordingly, a file may be marked
"locked" (0) or "replaceable" (1). This feature enables the
prevention, for example, of a certain file being replaced based on
performance considerations, and prevents collision between
ClassIDs.
[0104] According to one embodiment, the individual game elements
are then tabulated according to one or more metadata categories
(for example as shown above or otherwise) by the element
categorisation module 203 and the element table generator 205.
These tables are then stored in a temporary or permanent datastore
213 associated with the game analyser module 101 as required.
Certain metadata fields are populated by the code sorter 201 and
others are populated by other modules of the game conversion module
10 as explained hereinbefore. These references are also used
throughout the entire gaming system 1 as shown in FIG. 1.
[0105] The game analyser module 101, and more specifically the game
training module 211, carries out a process called "optimisation by
training" which initially involves delivery of the game clone in a
currently un-optimised state to a plurality of end users. This
process involves installation of the game clone on the end user's
computer (either by download or via a hardcopy of the game
distributed to the user), along with a "game training kit" which is
a piece of software operable to log (monitor and record)
application and hardware level behaviour of the game when it is
played on the user machine.
[0106] From the log generated by the game training kit, it is
possible to determine which resources in the original game
installation are not used during game-play. The outcome of this
determination will vary in different degrees for different games
from user to user based on the user's hardware and software
configuration. Therefore, it is an aspect of the game training kit
that a plurality training results are compared and overlapped in
order to find redundancies, i.e. data which is never accessed by
any user machine during game-play.
[0107] The game analyser module 101 then outputs to the conclusion
database 103 an "optimised clone" of the game. It is optimised in
the sense that all redundant data is removed and the game is still
fully functional.
[0108] FIG. 4 shows an illustration representing the log generated
by the game training kit for a game 400 being run on gaming machine
1 and 2. The cross-hatched regions in each instance 401, 402
represent redundant data that is not used during game play on each
respective machine. The results, which comprise a plurality of logs
of this type from a number of user machines, are compared (see 403
which is formed from common redundancies found in 401 and 402 etc.)
in order to find the required parts of the game 400'. The
crossed-hatched regions in 403 represent data which is never used
by any of the plurality of gaming machines used in the game
training process. This redundant data is removed at 404 and the
result is the "optimised clone" of the game 400'' which does not
include the redundant data. The "optimised clone" of the game 400''
is then copied into temporary datastore 213 for further processing
as required.
[0109] The game training kit may define a test for the entire game
or for predetermined durations of the game. Alternatively, or in
addition, the game training kit may define a test dealing with only
the initial periods of the game play in order to determine an
"essential minimum clone" of the game.
[0110] This essential minimum clone of the game is a portion of the
whole game optimised using one or more of the herein described
optimisation methods. The essential minimum clone contains a
minimum amount of data required in order to begin playing the game
but not enough to give it full functionality. The content of the
essential minimum clone is determined before the clone is split
into active and passive data, as described below.
[0111] The essential minimum clone is comprised of a predetermined
amount of passive data, such that once the predetermined amount of
passive data has been downloaded onto a user device 30, the user
can begin game play. However, in order to continue playing the
game, further passive data will be required and, accordingly,
further active data will be required in order to give that passive
data the correct behaviour. The term "begin game play" may mean
that the essential minimum clone comprises just enough passive data
to enable the game to start up, or to start up and load the first
level but game play cannot commence until the active data has been
received. Alternatively, it may comprise a portion of the first
level or it may comprises an otherwise fully playable portion of
the game.
[0112] Generally, where a user has a fast internet connection it
will be necessary to download only the essential minimum clone
before game play can begin because further passive and active data
can be readily downloaded by the user so there are no bandwidth
issues which may lead to game play freezing. Where the user has a
slower connection, however, it will generally be necessary to
download the essential minimum game clone plus a predetermined
additional amount of passive data calculated based on the hardware,
bandwidth and/or ping-time capabilities of the users device 30. The
slower the connection, the more data it is necessary to `buffer` so
that game play can continue without interruption. The advantage of
this is that by downloading more initial passive data to the user
device 30, only active data (which is much lower bandwidth data) is
required in order to play the game so there is less demand on the
network connection. The downside, however, is that the user
generally has to wait longer before beginning game play because
more initial passive data packets must be downloaded.
[0113] The optimised clone of the game may be further optimised
still. In one further optimisation process, the 1:1 similarity
checker module 207 takes an individual game element (or file) from
temporary datastore 213, and compares each individual element with
all other elements, typically by file type (although other metadata
categories may be used as a basis for comparison where
appropriate). The 1:1 similarity checker module 207 then checks the
similarity of the elements by checking the data content of each
file against another and determines whether there is a 1:1
similarity, i.e. determines which elements within each category are
identical (if any). For example the determination may be made pixel
by pixel in the case of a texture, however, any suitable technique
known in the art may be used to assess similarity of the file
contents as required. For instance, the waveforms of sound files
may be compared for 1:1 similarity.
[0114] Identical elements are game elements which look, sound or
behave the same in a game but have different file names as a result
of the manner in which many games are coded by developers.
Producing high-quality computer games is time intensive and
normally involves a fairly large team of individuals, or even
several teams, working on different aspects of a game. Such teams
might include designers, programmers, animators, graphical artists,
and sound effect artists. The amount of work that it takes to bring
game projects to completion is spread and most teams work to create
certain parts of games. Each of the parts is then assembled
together to form the final product. However, the result is that the
game code is often left `disorderly`, that is to say that the game
contains numerous duplicate files, superfluous data, stray code and
so on, which is generally redundant and often adds large amounts of
unnecessary data to the final game. The result of this problem is
that games can be many times the size they need to be in order to
be played by the end user. The embodiments of the present
disclosure are therefore advantageous over previously known
technology in that game sizes can be reduced to the point where
they can be distributed more quickly to the end user, particularly
over the internet where bandwidth and ping time can be limited.
[0115] Referring again to FIG. 3, element table generator 205
generates a sub category table for groups of identical elements.
For example, where texture001, texture003 and texture100 are all
identical textures to texture020, the element table generator 205
creates a listing in the ReplacementFileIDs metadata holder for the
record representing texture020 for texture001, texture003 and
texture100, thus indicating that they are all identical and
therefore replaceable. In the same way, the ReplacementFileIDs
metadata holder for texture100 lists texture020, texture001,
texture003 and so on.
[0116] The game engine checker module 209 identifies which gaming
engine is being used by the game and any parameters which have been
used to configure the game engine. Where appropriate, this data may
be stored in another metadata field associated with certain files.
A game engine is the core software component of a computer game
which provides the non-game specific technology. A game engine is
modular, and therefore extensible and configurable to allow
programmers to use the core of the game to create new games with
new models, level maps, sounds and such like, or create variations
on the theme of an existing game. Thus, the game engine is
essentially separate from the rest of the game, which is all the
content (objects, sounds, events sequence, physics and such like)
which are referred to herein as `elements`, along with the code
required specifically to make that game work, for example the
Artificial Intelligence (AI), or how the controls work and such
like, which is referred to herein as the engine parameters.
Examples of game engines include: Unreal engine, Torque engine,
Quake engine and Half Life engine.
[0117] The game engine checker module 209 is operable to look for
standard indicators belonging to the various game engines.
According to an embodiment of the invention, the game engine
checker module 209 is pre-loaded with a reference table which
provides a list of such indicators for each game engine. The game
engine checker module 209 can then reference this table against the
game engine provided in the game being analysed and determine which
game engine is present. The game engine checker module 209 may
additionally check database 119 to see if the game engine already
exists on the system. This process may be carried out for any other
game element.
[0118] The further optimised clone is updated accordingly in the
conclusion database 103. The conclusion database 103 is a temporary
database intended to be used for further processing steps within
the game conversion module, and is not always used for long-term
storage of the converted game.
[0119] FIG. 5 shows a step-by-step example of a process carried out
by the game analyser module 101. The master copy of the game is
uploaded to the game conversion module 10 (step S502). The code
sorter 201 searches through the source code of the game and
identifies individual game elements within the game (step S504) and
the game engine checker module 209 identifies which game engine is
used by the game (step S506). The identified individual elements of
the game are then categorised (step S508) by the element
categorisation module 203 and the element tables generated (step
S510). The 1:1 similarity checker 207 compares each individual
element with all other elements and determines which elements in
each category are identical (step S512). Finally, the conclusion
database 103 is populated with the results of the analysis carried
out by the game analyser module 101 (step S514).
[0120] Referring again to FIG. 2, the raw optimisation module 105
checks for and identifies any code calling up elements in the game
for which there is a duplicate element. The raw optimization module
105 then creates a replacement for each duplicate. The process
involves the creation of a reference (ReplacementFileID, see above)
containing a link to the new file. The duplicate element(s) are
then regarded as redundant and are deleted from the game
installation path by the raw optimisation module 105 accordingly.
Thus, when the game calls up one of the duplicate elements that has
been removed, it will instead refer to the relevant
ReplacementFileID metadata holder. The raw optimization module 105
therefore retains only one version of the relevant element and
replaces all other duplicate elements with a reference pointing to
the remaining single version.
[0121] The raw optimization module 105 typically reduces a computer
game by about 40% of its original size, but it may be greater or
less than this depending on how the computer game is initially
coded, i.e. how much redundant code there is etc. In this regard,
the raw optimization module 105 can be said to `compress` the
original game by removing unnecessary data. For example a 3 GB
computer game may be `compressed` by raw optimization module 105 to
only 1.2 GB or less by removing the redundant (duplicate) game
elements.
[0122] FIG. 6 shows an exemplary step-by-step process carried out
by the raw optimization module. The raw optimisation module 105
retrieves the results of the analysis carried out by the game
analyser module 101 from the conclusion database 103 (step S602),
and searches the data (step S604) in order to identifies any code
calling an element in the game for which there is a duplicate
element (step S606). The raw optimization module 105 then creates a
reference containing a link to the new file for each duplicate and
replaces the duplicate element with the reference (step S608). The
redundant files are deleted (step S610) and raw optimized database
107 populated (step S612).
[0123] FIG. 7 shows more detail of the data splitter module 109.
The data splitter module 109 comprises an element separator 701, an
active_passive splitter module 703, an active database 709 and a
passive database 711.
[0124] Broadly, the data splitter module 109 is operable to split a
game into "active" and "passive" data. The active data is then
stored in active database 709 and the passive data is stored in the
passive database 711.
[0125] For a better understanding of active and passive data, the
following explanation of game data types is provided. For
simplicity of understanding, most computer games can be broken down
into six basic data components: game element data; game object
data; game action data; game form data; game state data and game
space data. However, the skilled person will recognise that the
terminology and content of these data components may vary.
[0126] The game element data has already been defined above as any
type of game application file, e.g. one of the following: game
objects, textures, mp3 files, wav files, text files, instruction
documentation and so on. It is any of the various categories of
data, usually combined together in various ways, to form the final
game during game play.
[0127] The game object data is a specific type of game element
which represents any object that exists in a game including the
player character, an obstacle, a 3D article or the like, etc. The
game object is the focus of the game and has a relationship with
all other data components as described below. During game play,
there is a composition of all the basic data components in the game
to create the sophisticated virtual object (sometimes called a
"game token") as seen by the game player. The object data is
therefore the parameters of a game token, it is not the game token
itself. For example, object data which is defined as a human
character becomes a token that represents a human in the context of
a game during game play, but until that occurs, the object data is
merely a set of parameters. In other words, the game token is an
object that has a form, has state, is able to carry out actions,
and exists in the game space (or `world`) while the object data
itself is just a parameter set giving the `potential` for a
particular game token to have these attributes.
[0128] The game action data represents game mechanics and other
rules or constraints of a game. In essence, game actions are the
virtual representation of an event during game play. Some examples
are: run forward, jump up, explode obstruction, fire gun etc.
Action data is mainly invoked by objects, and can affect other
objects. Generally, when an event occurs during game play, there is
some indication that it has occurred. The action data is the
executing game code that represents the event. The action data is a
sequential expression of the states contained within an object. In
most games, this action data is controlled by the game engine.
[0129] The game form data, as distinct from the object data itself,
represents the form or appearance that an object takes during game
play, and is usually represented virtually with a 3D wireframe and
one or more textures. There is thus a distinction between an object
and its appearance in the game. The form data gets rendered to
produce the object as seen by the player (i.e. the game token).
However, again it is not actually the token. The form data contains
a wireframe and using this wireframe, form data can be modelled to
any 3D shape as desired by the game designer. Since the form data
is separate from an object (the game token), it is possible to
separate the form from the object.
[0130] The game state data is used to represent instantaneous
behaviour of objects at a specific point in time and contains data
that all objects need in order to interact with each other. The
state data composes the form data and the object data, and is used
during game play by the action data to modify the apparent
behaviour of an object. In other words, the behaviour of form data
and objects during game play, as well as action data, is controlled
and modified through state data. In most games, this state data is
controlled by the game engine.
[0131] The game space objects are simply collections (or sets) of
the other data types. There are two types of sets that are
generally used. Firstly, the virtual space object contains game
form data that is a virtual representation of an object's physical
form. For example, a car, a soldier, a tree and a horse. These
simply represent what the object data looks like when the game is
played. However, the objects in virtual space are merely a
representation of an object's physical form, for instance as a set
of parameters, and are not the entity itself.
[0132] Other aspects of an object are sorted into logical space.
This is the space where the object interactions occur. An example
might be a player character shooting a zombie with his or her gun.
When this interaction event occurs something must happen in the
code to acknowledge the event, and this data represents that
acknowledgement. In most games, game space data is controlled by
the game engine.
[0133] According to preferred embodiments of the present
disclosure, game data is split into two distinct categories--active
and passive data. Typical examples of passive data are the elements
of textures, mp3 files, wave files, text files and such like.
However, broadly speaking, passive data is any data which can be
downloaded to and stored locally on a user's computer, and can
potentially be replaced by a reference identifier. Typically,
passive data elements have relatively large files. The game engine
itself can also be classed as passive data because, according to
embodiments of the present invention, it is possible to use a
locally stored version of the game engine and simply combine the
necessary active and passive data from the user device 30 and
server 20 with the game engine.
[0134] Active data, on the other hand, is data which is required in
order to give the passive data behaviour during game play. Active
data is transferred to the users device 30 "on the fly" in
substantially real time, and is only temporarily stored at the
users device 30, for example for 5 seconds. Potentially, any data
can be classified as active data. However, according to one
example, it is the game object data (for example parameter data)
which is classified as active data. To this effect, in order for
there to be a composition of all the basic data components in the
game to create the sophisticated, interactive virtual object (or
game token) as seen by the player during game play, it is essential
to combine both the passive data (e.g. the textures, the game
engine, etc.) with the active data (parameters describing its
behaviour). Without the active data, therefore, the game cannot be
played because the passive data will not compile/render/behave
properly on the user device 30 due to the fact that there is no
data describing how the game elements are combined and how they
interact with each other in the game environment. Active data is
downloaded separately to the user device 30, and combined with
locally stored passive data in order to create the playable game.
According to one example, the active data and passive data may be
combined on-the-fly upon separate arrival at the user device
30.
[0135] Certain types of game object data are relatively small when
compared with other data elements such as textures, audio files and
the game engine, which can all have very large file sizes. It is
therefore advantageous to have the object data as active data for
two reasons. Firstly, having the object data as active data
operates as a form of digital rights management in that the game
cannot be played by a user without the necessary active data to
compose the game play. Therefore active data is never permanently
stored locally on a user's computer and must be downloaded from a
server separate to the passive data. Secondly, the object data
being so small means that games can be distributed using only a
limited amount of network bandwidth, with all (or at least a large
majority) of the large data files being stored locally on the
user's machine.
[0136] According to one example, only data smaller than 256 kB is
selected as potentially active data by the data splitter 109. Then
a predetermined percentage of that selection, e.g. 40%, is
classified as active data (the other 60% being classified as
passive) and the game is split out into active and passive data
accordingly by the data splitter module 109.
[0137] Any data which is part of the essential minimum clone
discussed above is classified as passive data regardless of it
size.
[0138] According to one embodiment, active data and passive data
are distributed by separate servers. For example, passive data can
be distributed by a web server, since its delivery speed does not
directly affect game play; a slower delivery speed simply means the
user has to wait longer to begin playing the game. The delivery
speed of active data, on the other hand, is more critical in the
sense that the game cannot be played without it and most games will
be prepared by the game conversion module 10 in a manner that
requires a constant feed of active data in order for the game to be
played. In this regard, therefore, it is more desirable to have a
fast server for distributing the active data. According to one
example, active data is distributed by a blade server and passive
data is distributed by a web server.
[0139] According to one embodiment, the element separator 701
determines whether the data is classified as active or passive and
sets the ClassID. The data may then be stored in a temporary
database 702. The active_passive splitter module 703 is operable to
take all active data from the temporary database 702 and populate
the active database 709 and to take all passive data from the
temporary database 702 and populate the passive database 711. In
another embodiment, the active_passive splitter module 703 may also
determine whether the data is classified as active or passive and
sets the ClassID, such that the element separator 701 and temporary
database 702 are not required.
[0140] FIG. 8 shows more detail of an n-pass similarity optimizer
115. The n-pass similarity optimizer 115 takes active data from the
active database 111 and passive data from the passive database 113
and performs an n-pass similarity optimization process, where n is
any integer (n=3 in the example shown). The n-pass similarity
optimizer 115 is therefore operable to perform a further level of
optimisation on the optimised game clone. While three passes are
used according to one example, due to the resulting balance between
accuracy and speed of optimisation, n can be any predefined
integer. The optimizer 115 performs a further step analogous to
that carried out by the raw optimisation module 105 in order to
remove additional redundant data. In the case of the n-pass
similarity optimizer 115, however, it is not configured to perform
a check for a 1:1 similarity between elements, but rather it checks
for a similarity within a predefined tolerance. For example, the
n-pass similarity optimizer 115 may check for elements which are
90% similar, 80% similar, 70% similar, 60% similar, 50% similar
etc. To this effect, it is possible to further reduce the amount of
data for an individual game, at the expense of losing certain
unique elements. Generally, the tolerance is chosen so that a
greater amount of redundant code is removed without adversely
affecting the overall look and play of the game.
[0141] The n-pass similarity optimizer 115 may also be provided
before the data splitter 109, such that following the 1:1
similarity check the data is then subject to an n-pass similarity
check before the data is split into active and passive data.
Therefore, it is possible to substantially reduce the size of a
game, by removing identical and similar elements, regardless of
whether the data is then separated into active and passive
data.
[0142] The n-pass similarity optimizer 115 processes the source
code of an inputted game clone several times. In the embodiment
shown, this occurs three times but it may occur more or less than
three times according to preference. Each pass takes the result of
the previous pass as the input, and creates an intermediate output.
In this way, the (intermediate) code is improved pass by pass,
until the final pass emits the final code.
[0143] The n-pass similarity optimizer 115 allows better code
structuring (e.g. smaller code size, faster code) compared to the
output of the raw optimisation module 105 which is a one-pass
component, at the cost of higher processing time and memory
consumption.
[0144] The n-pass similarity optimizer 115 is configured according
to a predetermined tolerance. In other words, it is possible to
define the degree of likeness between elements the n-pass
similarity optimizer 115 recognises as similar. For example, rather
than removing textures which are 100% similar (i.e. identical) to
another texture, it may also be preferable to remove textures which
are 75% similar to that texture.
[0145] As well as optimising each game internally, the n-pass
similarity optimizer 115 may also check other games in the database
119 for identical and similar elements. It may first check for
other games of the same name but different version e.g. TOCA Race
Driver 1, TOCA Race Driver 2, it may search according to game genre
(e.g. sports simulation, role play game, shoot 'em up etc.), game
engine, game date or any other suitable class. However, the n-pass
similarity optimizer 115 checks each game with all the other games
in the database 119. Already checked elements can be logged or
tagged with a suitable reference in order that repeat testing is
not carried out, with or without tolerance. For example, TOCA Race
Driver 1 has already been processed and optimised. When TOCA Race
Driver 2 is optimised, many of the files present in TOCA Race
Driver 1 are also used in TOCA Race Driver 2. It is possible to cut
down on the amount of required new passive data by replacing the
TOCA Race Driver 2 files with a reference to the equivalent TOCA
Race Driver 1 files, or vice versa. For example, TOCA Race Driver 2
may have a updated version of the passive data, in which case it
may be desirable to replace the TOCA Race Driver 1 files with a
reference to the equivalent TOCA Race Driver 2 files.
[0146] The quality of replaced files may be better (for example in
terms of resolution etc.) than the original files, yet the overall
game may still smaller due to the amount of redundant data deleted
from the game. In this regard, the embodiments of the present
invention may actually improve the visual and audio quality of a
computer game, enhancing the user's experience whilst still
reducing the overall size of the game.
[0147] Each converted game that is output from the game conversion
module 10 is identifiable by a ContainerID. The ContainerID
comprises the GameID (see above) with an additional suffix
describing game packets. According to one example, the suffix is a
four digit code. For instance, the GameID "TR000001DE" plus the
ContainerID suffix "0109" may represent the first packet (01) of
the German language version of Tomb Raider 1, which has a total of
9 packets (09). In this context, the first packet "01" is the
essential minimum clone as described above. Subsequent packets can
be requested by the user's computer based on the ContainerID. Each
packet may include active and passive data, which is separated at a
for game play. However, each packets may comprise only active or
passive data, for example, the first eight packets may comprise
passive data and the ninth packet may comprise active data. In this
example, the first the eight packets may be stored in the passive
data storage device 119 and the ninth packet may be stored in the
active data storage device 117. Each different language version of
a game is required to be converted using the game conversion
apparatus 10.
[0148] According to one embodiment, each game is assigned a
SourceID. The SourceID is a unique number for each version of a
game. For example a SourceID=001 may represent the original file
from the first optimised game clone and SourceID=002 may represent
an updated version of the game, for instance, a patched version
with bug fixes etc.
[0149] The game server 20 requires a two-way interactive
communication with the user device 30 during game play. This is
because, during game play, not only is it necessary for the game
server 20 to download data (active and passive) to the user device
30, but it is also necessary for the user's device 30 to send data
to the game server 20, such as information about decisions made by
the game player (user) during game play, and thus which data is
required next in the game.
[0150] Those skilled in the art will appreciate that while this
disclosure has described what is considered to be the best mode
and, where appropriate, other modes of performing the invention,
the invention should not be limited to the specific configurations
and methods disclosed in this description of the preferred
embodiment.
* * * * *