US20100016074A1

US20100016074A1 - Apparatus and methods for game conversion

Info

Publication number: US20100016074A1
Application number: US12/407,752
Authority: US
Inventors: Uwe Prochnow
Original assignee: GDI Game Domain International PLC
Current assignee: GDC GAME AND DOWNLOAD Co AG
Priority date: 2008-03-20
Filing date: 2009-03-19
Publication date: 2010-01-21
Also published as: WO2009115826A2; WO2009115826A3; TW200950859A; EP2268372A2

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.

Description

TECHNICAL FIELD

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

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.
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.
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.
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.
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

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.
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.
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.
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%.
According to another embodiment of the invention, the computer game conversion apparatus further comprises: a tolerance control module for defining the degree of likeness.
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.
According to another embodiment of the invention, the game element categorisation module generates metadata for each game element.
According to another embodiment of the invention, the metadata comprises one or more of: FileID; FileName; FileTypeID; FileLink; GameID; FileSize; ReferenceStatusID; ReplacementFileID; ClassID; SubClassID.
According to another embodiment of the invention, the game element categorisation module tabulates the game elements according to the one or more metadata categories.
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.
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.
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%.
According to another embodiment of the invention, the computer game conversion apparatus further comprises: a tolerance control module for defining the degree of likeness.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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%.
According to another embodiment of the invention, the multiple-pass similarity optimiser further comprises: a tolerance control module for defining the degree of likeness.
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.
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.
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.
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.
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%.
According to another embodiment of the invention, the game conversion apparatus further comprises: a tolerance control module for defining the degree of likeness.
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.
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.
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.
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.
According to another embodiment of the invention, the game engine checker module is configured to identify any parameters for configuring the game engine.
According to another embodiment of the invention, the code sorter module generates metadata for each game element.
According to another embodiment of the invention, the metadata comprises one or more of: FileID; FileName; FileTypeID; FileLink; GameID; FileSize; ReferenceStatusID; ReplacementFileID; ClassID; SubClassID.
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.
According to another embodiment of the invention, the tabulated individual game elements are stored in a storage device.
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.
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%.
According to another embodiment of the invention, the computer game analyzer further comprises: a tolerance control module for defining the degree of likeness.
According to another embodiment of the invention, at least some of the identified game elements are identical to the individual game element.
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.
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.
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.
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.
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.
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.
According to another embodiment of the invention, the degree of likeness between elements comprises 100% likeness.
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%.
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.
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.
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.
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.
According to another embodiment of the invention, the method further comprises: generating metadata for each game element.
According to another embodiment of the invention, the method further comprises: categorising the game elements according to the metadata.
According to another embodiment of the invention, the method further comprises: storing the categorises of game elements in a storage device.
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.
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.
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.
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.
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.
According to one embodiment of the invention, there is provided a computer program product comprising programme code means for performing the method described above.
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.
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

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:

FIG. 1 illustrates schematically a gaming system;

FIG. 2 illustrates schematically a game conversion module;

FIG. 3 illustrates schematically a game analyzer module;

FIG. 4 illustrates schematically a log generated by a game training kit;

FIG. 5 illustrates schematically a process performed by a game analyzer module;

FIG. 6 illustrates schematically a process performed by a raw optimization module;

FIG. 7 illustrates schematically a data splitter module; and

FIG. 8 illustrates schematically a n-pass similarity optimizer.

DETAILED DESCRIPTION

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.
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.
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.
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.
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.
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.
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”.
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.
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.
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.
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:

- 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.
- FileName—a record containing the given name of the file including its extension e.g. “tree1.jpg”, “bang2.wav” etc.
- 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.
- 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.
- 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.
- FileSize—the size of the file, e.g. in kilobytes.
- 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.
- 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.
- 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.
- 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.

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Any data which is part of the essential minimum clone discussed above is classified as passive data regardless of it size.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

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:

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;

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:

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.