EP1410183A2

EP1410183A2 - Multi-platform interactive applications

Info

Publication number: EP1410183A2
Application number: EP02751314A
Authority: EP
Inventors: Douglas Mcpherson Little; Neil William Stewart
Original assignee: Steel Monkeys Ltd
Current assignee: Steel Monkeys Ltd
Priority date: 2001-07-16
Filing date: 2002-07-16
Publication date: 2004-04-21
Also published as: WO2003009135A3; WO2003009135A2

Abstract

A system (10) and method for executing an interactive software application such as a game. The invention enables a game developed on one platform to be ported to another incompatible platform without recompilation or modification while the performance of the game is not reduced on porting. The system has a game application (11) that defines model objects; an engine (13) that generates and stores model objects (14); and a hardware module (15) that retrieves the model objects and executes corresponding hardware methods. The engine does not make a sequence of procedure calls to the hardware module. An abstraction layer (17) provides synchronous communication between the hardware module and the game application and further provides synchronous communication between the engine and the hardware module.

Description

Multi-Platform Interactive Applications

This invention relates to technology for implementing real-time interactive software applications. In particular, the implementation of such applications on multiple incompatible platforms which use different hardware.

At the current time some of the most widespread and demanding real-time interactive software applications are 3-Dιmensιonal (3-D) computer games. There are a large number of different platforms that each comprise different hardware modules implementing different methods to generate the graphics, audio and input, etc. needed by a 3-D game application. For example a PC (Personal Computer) , a Playstation 2©, a GameCube© and Xbox™, will all comprise different hardware modules and methods. A hardware method may be implemented by a hardware module comprising both software programs and physical circuitry.

Developers of a game on one platform can gain access to a larger market by providing the same game on multiple platforms. The marketing budget and impact of a game on the whole market can both be improved by releasing a game on multiple platforms in rapid succession. However, it has traditionally been difficult to convert a game written on a first platform to run on a second platform (known as porting the game to the second platform) . Even when the port has been done, the performance suffers on the second platform, as will be described below, which may necessitate changing the gameplay on different platforms, for example having to reduce the number of cars displayed in a racing game. Such differences in gameplay undermines concurrent marketing for multiple platforms .

In order to port a game that is developed for use on one platform for efficient use of another incompatible platform, part or all of the game needs to be converted by modification and recompiling of software code. In order to minimise the effect of this problem, a number of approaches have been tried.

One approach with a software application such as a game has been to split off part of the game application's functionality into an engine, giving an architecture of: game module/engine/hardware module. The game module manages the game specific functions, including the position and behaviour of objects in a scene within the game. The engine then manages generic functionality that is independent from specific games, for example rendering, audio and input. In this architecture, it necessary for the game module to request the functionality of the hardware module by making procedure calls to the engine which map directly onto specific methods used by the hardware module. These requests are typically prepared each as nodes on a "scene graph" whose construction by the game module depends on assumptions about the way in which the hardware module will display graphical objects, for example the order in which the objects are displayed; starting either at the back or at the front of a set of overlapping objects in a 3-Dimensional scene.

The game module communicates the nodes in the scene graph to the engine using a protocol which defines further assumptions that the game developer makes about the functionality and methods of the hardware module. These assumptions may relate to how the graphical elements that make up graphical objects are drawn, for example using elements which are triangles, or the order in which such graphical elements are drawn. If the engine is implemented in the C++ programming language, then the protocol may be defined by the game module source code compilation directly including all of the header files (filenames suffixed with .h) of the engine source code, which define the procedure calls and methods available in requests to the engine.

The engine then communicates with the hardware module and makes sure that the requests from the game, e.g. by procedure calls, are executed correctly and in the right order. The engine source code compilation may itself include header files of the hardware module, if supported, but at least some protocol of allowed requests to the hardware module have to be defined.

In this prior art architecture, the engine ensures synchronous communication between the game module and the hardware module. The scene graph is constructed by the game module and the order processing of nodes in the scene graph is preserved through to execution of the methods by the hardware module.

A first problem with this game module/engine/hardware module architecture is caused by the assumptions defined in the construction of the scene graph by the game module. The construction of the scene graph will assume a certain order of drawing of graphical objects by the hardware module of a particular platform. But a hardware module of an incompatible platform may draw objects in a different order. When porting a game to the incompatible platform, such fundamental differences as the order of drawing graphical objects will, by necessity, require modification of the game module (including the scene graph structure and ordering of nodes) and then recompiling, in order to correct corruption of the drawn images visible to the game player.

A second problem with this game module/engine/hardware module approach is that the assumptions defined in the protocol used by the engine may well be appropriate and closely matched to the methods used by the hardware modules of a particular platform, but may be inappropriate to those methods of hardware modules of incompatible pre-existing or newly developed platforms. For example, if the protocol assumes that the hardware will use a method of drawing graphical objects using triangle graphical elements and the game module is programmed to use 1,000 triangles to draw a graphical object, such as a wheel, there is a problem when a new enhanced platform becomes available whose hardware module draws using more complex graphical elements such as NURBs (Non-Uniform Rational B-Splines) that represent 3-D curved surfaces rather than 2-D triangles. Using NURBs may ideally facilitate the drawing of objects, such as a wheel, with many fewer NURB elements than triangle elements. In this case, however, a game module to engine protocol that did not recognise NURBs would force the game to draw the wheel using 1,000 NURBs that would each be constrained to be triangular in shape, thus losing the benefit of the enhancements developed in the new platform. Although the drawn wheel would look satisfactory to a game player, the same effect might have been achieved using many fewer NURBs, so releasing the game module for other processing such as adding more detail to the gameplay. Therefore, when porting a game to a new platform with its enhanced engine already developed, it is necessary to modify the game module including the nodes of the scene graph and then recompile in order to take advantage of the hardware module's new features. For example, the game module could be changed to request fewer than 1,000 NURBs to draw a wheel. Other examples of different ways that hardware modules use different methods are as fundamental as basic maths libraries (e.g. how addition is performed) and where the origin of a co-ordinate system is (left or right) . In summary, it has been shown that if the assumptions defined in the protocols do not match the hardware module's methods particularly well, which is usually the case when porting a game to a new platform, then the engine is forced to implement the requests in a non- optimum manner with a corresponding performance penalty that can only be reduced by modifying and recompiling software. A third problem with the game module/engine/hardware approach is that the synchronous communication results in performance bottlenecks in the system. Consider a game module that can generate an updated scene graph of given complexity at a maximum frame rate of 30fps (frames per second) , which is the approximate minimum for smooth perception of animated movement. The hardware module may be able to display the scene at a faster rate of lOOfps, but is limited by the need to wait for the synchronous delivery of requests from the game module via the engine. Simply reducing the scene complexity in order to increase the game module's performance to lOOfps would unacceptably detract from the appearance of the scene. Therefore in practice a user with a PC upgrading his or her computer graphics card that comprises the hardware module may not get the full benefit of its performance, because the frame rate is limited by the game module running on a general purpose central processing unit in the PC.

Although this game module/engine/hardware module architecture approach means that it is possible to write a game once on one platform, and then to port the game without modification (while accepting the performance penalty) to another platform, it is still necessary to write an engine for every platform supported. Although the development of the engine will only have to be done once per platform, it is very time consuming and therefore expensive. It also takes continuing maintenance to ensure that all of the different engines are entirely game compatible, that is making sure that a game works correctly using the engine on one hardware module also works correctly using another engine on another hardware module. The more software development that is done, then the more opportunities for errors in the development arise.

In order to try and get over this problem of developing engines for each platform, the industry came up with a further approach. A "hardware abstraction layer" (HAL) is added between the engine and the hardware, giving an architecture of: game module/engine/HAL/hardware module. The HAL shields the engine from the specific details of the methods of the hardware module in the same way that the engine itself shields the game module from the hardware module. Usually only approximately 20% of an engine is directly hardware module specific and so this approach was designed with the aim of using only one engine for all platforms. A HAL must still be written for each platform, but this is easier than having to develop and maintain a complete engine on each and every platform.

The addition of a HAL suffers from the same problems when porting a game to an incompatible platform as described for the addition of an engine, i.e.: • Firstly, inappropriate assumptions in the order of the scene graph lead to having to modify the scene graph and recompile to fix corruption of drawn images; • secondly, inappropriate assumptions about hardware methods in protocols lead to performance problems and having to modify scene graph nodes and recompile to take advantage of a new platform's hardware methods (e.g. triangles versus NURBs); and • thirdly, synchronous operation leads to performance bottlenecks (e.g. the hardware module is limited to 30fps by the game module) .

Inserting a HAL actually exacerbates the second problem, because an extra layer of protocols is required. So even with the most optimum implementation of the HAL architecture there is typically a 20/30% impact on speed performance.

Another problem with the HAL architecture is that it adds another layer of procedure calls which have their own performance penalty. This is because computer instructions and processing cycles are needed purely to handle the transfer of program control and passing of parameters during a procedure call.

An extreme example of a type of HAL which makes very few assumptions about the methods used by the hardware module to display graphical objects and text objects, thereby giving very little coupling (i.e. large abstraction) between the application and the hardware module, is the HTML (Hyper Text Mark-up Language) protocol used in the World Wide Web. This type of HAL allows the application to display documents on a very large number of hardware platforms, but the very severe performance impact results in it being unsuitable for interactive real time applications such as games, particularly 3D graphical games. Alternative architectures are known, such as 3D computer aided design packages and^' windowing operating systems, where a controller application is used to build a model stored as objects in a table or a database, and a separate viewer application asynchronously retrieves the object information and renders it on a computer screen. Such packages may be used to concurrently build and display a 3D model or window. However tight coupling between the controller and the viewer applications results in poor performance of such systems so they have not been used for 3D gaming. The coupling in such architectures is tight because firstly the model itself is passive in that it does not itself do any processing of the objects, and secondly the controller is used for obtaining user input, rather than the viewer application.

Thus in the prior art there has been a trade-off between the effort required to rewrite software and the performance loss caused by inserting abstraction layers between the application and the hardware. Other approaches at asynchronous maintenance and viewing of a model have been limited because the approaches have been accompanied by tight coupling between the application and the hardware.

It can therefore be seen that it would be beneficial to provide a system which allowed software applications, such as games, to be written on one hardware platform and then transferred for use on another hardware platform, without either negatively affecting the performance of the software application or needing the software application to be partially or wholly rewritten and recompiled. It would be further beneficial to provide a system which removes the HAL from between the engine and the hardware with its associated performance overhead.

It would be further beneficial to provide a system which avoided synchronous requests for all hardware methods, and the resulting potential performance bottlenecks and need for a scene graph.

It is an object of the present invention to enable a software application developed on one platform to be ported without modification to another incompatible platform.

It is a further object of the present invention to enable a software application developed on one platform to be ported to another incompatible platform, wherein the performance of the software application is not reduced on the second hardware platform.

According to a first aspect of the present invention, there is provided a system for executing an interactive software application comprising: • a software application adapted to define model objects; • an engine adapted to store model objects responsive to said software application; and • a hardware module adapted to retrieve information about said model objects and to execute at least one method responsive to said retrieved information. Typically the interactive software application is a computer game .

Preferably the engine does not make a sequence of procedure calls to the hardware module.

According to a second aspect of the present invention, there is provided a system for executing an interactive software application comprising: • a software application; • a hardware module; and • an engine that does not make a sequence of procedure calls to the hardware module.

Preferably, there is further provided an abstraction layer adapted to provide synchronous communication between said hardware module and said software application.

More preferably, said abstraction layer is further adapted to provide synchronous communication between said engine and said hardware module.

Preferably source code compilation of said engine does not include any procedure and method definitions common to the hardware module source code.

More preferably the system further comprises a plurality of stored model objects that define the requirements of processing by the hardware module. Most preferably said software application communicates with said engine in order to define said model objects which are stored by said engine.

Preferably said hardware module communicates with the engine in order to retrieve information about said model objects.

Preferably said communication between the hardware module and the engine is initiated by the hardware module.

Preferably said communication between said hardware module and said engine is asynchronous with respect to said communication between said software application and said engine.

More preferably said hardware module executes at least one method responsive to said information that it has retrieved from said engine independently of the sequence that said model objects are stored by said engine.

Optionally the platform that comprises said hardware module is a platform selected from the list of platforms: PC; Apple Macintosh; Playstation 2®; GameCube©; Playstation©; and Xbox™.

Typically the software application is a game software application. Preferably the engine comprises software executed on a general purpose computer.

According to a third aspect of the present invention, there is provided a method for executing an interactive software application, the method comprising the steps:

• a software application communicates with an engine and defines model objects which are stored by said engine;

• said engine stores said model objects;

• a hardware module communicates with said engine and retrieves information about said model objects that the hardware module requires to execute its methods; and

• the hardware module executes at least one method responsive to said retrieved information.

Preferably said interactive software applications are computer games.

Preferably said engine does not make a sequence of procedure calls to said hardware module.

Preferably the method further comprises the step of synchronous communication between said hardware module and said software application via an abstraction layer. More preferably the method further comprises the step of synchronous communication between said engine and said hardware module via said abstraction layer.

Preferably the system is implemented by computer software comprising program instructions which, when loaded onto a computer, cause said computer to perform as the system.

Preferably the method is implemented by computer software comprising program instructions which, when loaded onto a computer, cause said computer to carry out the method.

In order to provide a better understanding of the present invention, embodiments of the invention will now be described by way of example only and with reference to the following Figures, in which:

Figure 1 is a schematic diagram of the components in the system in accordance with the current invention; and

Figure 2 illustrates two flowcharts of the steps performed in accordance with the current invention.

The invention is an improved system and method for developing and executing interactive software applications.

Although the embodiments of the invention described with reference to the drawings comprise computer apparatus and processes performed in computer apparatus, the invention also extends to computer programs, particularly computer programs on or in a carrier, adapted for putting the invention into practice. The program may be in the form of source code, object code, a code of intermediate source and object code such as in partially compiled form suitable for use in the implementation of the processes according to the invention. The carrier may be any entity or device capable of carrying the program.

For example, the carrier may comprise a storage medium, such as ROM, for example a CD ROM or a semiconductor ROM, or a magnetic recording medium, for example, floppy disc or hard disc. Further, the carrier may be a transmissible carrier such as an electrical or optical signal which may be conveyed via electrical or optical cable or by radio or other means.

When the program is embodied in a signal which may be conveyed directly by a cable or other device or means, the carrier may be constituted by such cable or other device or means.

Alternatively, the carrier may be an integrated circuit in which the program is embedded, the integrated circuit being adapted for performing, or for use in the performance of, the relevant processes.

With reference to Figure 1, a system 10 is provided for overcoming the problems identified in the prior art. A game 11 communicates 12 to an engine 13 about what the game wants hardware to do. The engine, which is implemented purely in software, then executes as much of this as possible in a hardware independent manner and stores the results as model objects 14. The hardware 15 then reads 16 this information directly from the engine asynchronously with respect to the game to engine communication 12 and executes its hardware methods, e.g., rendering, audio or input, in order to do what is required by the game. This architecture may be described as two overlapping components: game/engine; and engine/hardware module

With each of these two components executing asynchronously, the key difference between this architecture and the previous prior art solutions is that the engine does not assume anything about the hardware. There is no hardware abstraction layer interface dictating how and in which sequence the hardware methods are to be called. In other words, the hardware is completely decoupled both from and the engine and therefore the game.

With this system, is possible to compile and build both the game and the engine without having any hardware attached. It is even possible to run the game without having any hardware attached to it. Without visual display or audio, the game would be unplayable, however such a configuration demonstrates that both the game and the engine are completely decoupled from the hardware. Because the order in which the game communicates about these model objects to the engine does not determine the order in which the objects will be processed by the hardware module (e.g., rendered), then there is no need for the game to construct a scene graph which defines the order that objects will be drawn or processed. The main program loop of the game can therefore be slowed down to, say, 30fps, with the knowledge that the hardware will not be constrained by this bottleneck and will be able to execute its methods as its own (faster) rate. Having slowed down the main loop to 30fps, the game is able to process more detail in the main loop itself, e.g., more cars in a racing game or other gameplay related improvements.

Using the example of drawing a wheel, the following pseudo code describes the steps necessary to define the wheel and cause its rendering:

EN=NewEntity; {create entity} SetModel ("wheel") ; {method call}

Unlike in the prior art, the hardware 15 knows about the engine, i.e., instead of the hardware having its low level (HAL) interface called by some unknown entity (the engine) , the hardware can directly query the engine and retrieve exactly the information it needs in order to execute its methods. The engine contains information about what needs to be done and the hardware decides how, when and if it needs to do anything. In doing this, the hardware is free to execute as fast as it can, unconstrained by the frame rate of the game.

If the engine is implemented in C++, then the source code compilation of the hardware can directly include all of the header (.h) files of the engine, but the engine and the game cannot include any header files of the hardware. It is also the case that the hardware cannot include any header files from the game. This again enforces the decoupling between the hardware and both the game module and engine. Having retrieved the model objects from the engine, the hardware may use a model library to enable it to execute its methods. For example, the model library may describe a design for a wheel, described either as a collection of NURBs or triangles, as appropriate to the hardware itself. Similarly, the hardware module may use any maths library or any order of drawing graphical objects in order to execute its methods, e.g., rendering.

A useful analogy in describing this system and its differences from the prior art is that here the game defines objectives in the way that a manager may define objectives, and then it is up to the hardware to achieve the objectives to the best of its ability, in the way that an employee may achieve objectives in an individual way, according to his or her ability. Using this further, a prior art game acts as a manager who uses a directive approach that dictates at a detailed resolution the particular tasks and order of execution of the tasks that are required to achieve the objectives.

There are problems with the embodiment described thus far, in that the hardware sometimes needs to ask the game about specific things, e.g., the title of the game, or the engine needs to ask the hardware about specific things, e.g., hit detection. Because of the asynchronous decoupling, the system described thus far does not allow such communication.

In order to solve this problem, a limited abstraction layer 17 implemented in software makes it possible for the hardware to talk synchronously to the game 18, 19, and the engine to talk to the hardware 120, 18 using a protocol that shields the hardware from the game in the first case, and the engine from the hardware in the second case.

The abstraction layer is only used for a limited set of communications that are common to all games and hardware, but will not depend on the specific methods used either by hardware in the execution of its methods or by games in the differentiating aspects of their game play.

The hardware is completely decoupled from the game and engine for nearly all of the system functionality and any coupling is limited to game generic functions. This makes it possible for the hardware to implement all of its tasks in a potentially 100% optimum manner. Using this architecture, it makes it possible to produce a game once on one platform and then port the same game without software modification or recompilation to other target platforms without any performance penalty on the target platforms.

Figure 2 illustrates two flowcharts that describe the steps related to the communication between the game and the engine 20, and the steps related to the communication between the engine and the hardware 21.

The game defines model objects that describe, for example, the form, co-ordinates and vector of motion in a 3D space 22. Next the engine stores the model objects 23. These may be stored in a database or a table, and the model objects thus stored may be constructed directly by the game and passed to the engine or the model objects may be constructed by the engine in response to requests or procedure calls from the game.

Concurrently, steps are performed 21 in relation to communication between the hardware and the engine. The hardware retrieves 24 the model object or information about the model object from the engine using a request, for example a database query. The order in which model objects or information about such objects is retrieved from the engine is independent of the order in which the model objects have been stored in the engine. Therefore, for example, the use of a first-in first-out stack for storage of the model objects would be unsuitable in this architecture. Having retrieved the model objects or information, the hardware executes its methods 25 using the information or model objects it has retrieved.

Further modifications and improvements may be added without departing from the scope of the invention herein described.

Claims

1. A system for executing an interactive software application comprising:

• a software application adapted to define model objects; • an engine adapted to store model objects responsive to said software application; and • a hardware module adapted to retrieve information about said model objects and to execute at least one method responsive to said retrieved information.

2. The system of Claim 1 wherein the interactive software application is a computer game.

3. The system of any previous Claim wherein the engine does not make a sequence of procedure calls to the hardware module.

4. A system for executing an interactive software application comprising:

• a software application; • a hardware module; and • an engine that does not make a sequence of procedure calls to the hardware module.

5. The system of any previous Claim further comprising an abstraction layer adapted to provide synchronous communication between said hardware module and said software application.

6. The system of any previous Claim wherein said abstraction layer is further adapted to provide synchronous communication between said engine and said hardware module.

7. The system of any previous Claim wherein the source code compilation of said engine does not include any procedure and method definitions common to the hardware module source code.

8. The system of any previous Claim further comprising a plurality of stored model objects that define the requirements of processing by the hardware module.

9. The system of any previous Claim wherein said software application communicates with said engine in order to define said model objects which are stored by said engine.

10. The system of any previous Claim wherein said hardware module is adapted to communicate with the engine in order to retrieve information about said model objects.

11. The system of any previous Claim wherein said communication between the hardware module and the engine is initiated by the hardware module.

12. The system of any previous Claim wherein said communication between said hardware module and said engine is asynchronous with respect to said communication between said software application and said engine,

13. The system of any previous Claim wherein said hardware module executes at least one method responsive to said information that it has retrieved from said engine independently of the sequence that said model objects are stored by said engine.

14. The system of any previous Claim wherein a platform that comprises said hardware module is a platform selected from the list of platforms : PC; Apple Macintosh; Playstation 2©; GameCubeΘ; Playstation©; and Xbox™.

15. The system of any previous Claim wherein said software application is a game software application.

16. The system of any previous Claim wherein said engine comprises software executed on a general purpose computer.

17. A method for executing an interactive software application, the method comprising the steps:

• a software application communicates with an engine and defines model objects which are stored by said engine; • said engine stores said model objects;

• a hardware module communicates with said engine and retrieves informatiori^' about said model objects that the hardware module requires to execute its methods; and

18. The method of Claim 17 wherein said interactive software applications are computer games.

19. The method of any previous method Claim wherein said engine does not make a sequence of procedure calls to said hardware module.

20. The method of any previous method Claim further comprising the step of synchronous communication between said hardware module and said software application via an abstraction layer.

21. The method of any previous method Claim further comprising the step of synchronous communication between said engine and said hardware module via said abstraction layer.

22. Computer software comprising program instructions which, when loaded onto a computer, cause said computer to perform as the system of any previous system Claim.

3. Computer software comprising program instructions which, when loaded onto a computer, cause said computer to carry out the method of any previous method Claim.